Re: xtensa PR65730
On Fri, Apr 10, 2015 at 12:15 PM, Max Filippov wrote: > Then configuration w/o multiplication should call helper at -O0 and > use shift at higher optimization levels? That is what I would expect.
GNAT User's Guide /onlinedocs broken? (was: Broken links on gcc.gnu.org/onlinedocs)
On Mon, 9 Feb 2015, EXT-Barrett, James wrote: > The following links are broken at gcc.gnu.org/onlinedocs/4.9.2. The > corresponding 4.9.2-related links at gcc.gnu.org/onlinedocs are also broken: > GCC 4.9.2 GNAT User's Guide (/onlinedocs/gcc-4.9.2/gnat_ugn_unw/) > also in PDF (/onlinedocs/gcc-4.9.2/gnat_ugn_unw.pdf) > or Postscript (/onlinedocs/gcc-4.9.2/gnat_ugn_unw.ps.gz) > or an HTML tarball (/onlinedocs/gcc-4.9.2/gnat_ugn_unw-html.tar.gz) This is not just broken for GCC 4.9.2, but GCC 4.8.4 as well: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw/ https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn_unw/ It does still work for GCC 4.9.1 and GCC 4.8.3: https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_ugn_unw/ https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gnat_ugn_unw/ Arnaud, you updated maintainer-scripts update_web_docs_svn as follows last year, might this be related? 2014-08-01 Arnaud Charlet * update_web_docs_svn: Simplify build of gnat_ugn. Is the patch below a proper fix? Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v retrieving revision 1.147 diff -u -r1.147 index.html --- index.html 6 Feb 2015 22:27:38 - 1.147 +++ index.html 10 Apr 2015 20:00:02 - @@ -53,12 +53,12 @@ href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_rm.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_rm-html.tar.gz";>an HTML tarball) -https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw/";>GCC +https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn/";>GCC 4.9.2 GNAT User's Guide (https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw.pdf";>also + href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn.pdf";>also in PDF or https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw-html.tar.gz";>an + href="https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn-html.tar.gz";>an HTML tarball) https://gcc.gnu.org/onlinedocs/gcc-4.9.2/libstdc++/manual/";>GCC 4.9.2 Standard C++ Library Manual (https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_rm.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_rm-html.tar.gz";>an HTML tarball) -https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn_unw/";>GCC +https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn/";>GCC 4.8.4 GNAT User's Guide (https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn_unw.pdf";>also + href="https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn.pdf";>also in PDF or https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn_unw.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn_unw-html.tar.gz";>an + href="https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gnat_ugn-html.tar.gz";>an HTML tarball) https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/";>GCC 4.8.4 Standard C++ Library Manual (
Re: Selecting an architecture tuple for the Rumprun toolchain
On Fri, 10 Apr 2015, Martin Lucina wrote: > On Thursday, 09.04.2015 at 16:20, Joseph Myers wrote: > > > Why do you not recommend using the vendor component for anything > > > significant? To me it seems the logical place to say "this is a rumprun > > > toolchain", plus the result is easier to parse than putting "rumprun" AND > > > "platform" AND "userspace" all in the last component. > > > > The vendor component is typically a company name - used either in cases > > where only one name is normally used (*-sun-solaris*, *-hp-hpux*, > > *-ibm-aix*, etc.), or, for free software systems, for branding purposes if > > at all (*--linux-gnu*). Presumably multiple distributors might > > each distribute rumprun tools, branded for that distributor, so > > --linux-gnurumprunxen or --netbsd-rumprunxen > > for example. > > You say "typically a company name", presumably that is custom but not a > requirement? Well, config.sub says MANUFACTURER. Presumably multiple MANUFACTURERs could produce compatible rumprun toolchains (and so put their own identifiers in that slot). > "2" and "3" have the advantage of working with existing config.sub scripts > out of the box. "1" would require submitting a patch to autoconf and, until > upstream packages regenerate their build scripts using the new autoconf, > that we run autoreconf before building software in order to get the new > config.sub. This would also mean instructing end users/porters to do the > same. GNU/Linux distributors are very used to needing such regeneration whenever doing new architecture ports (or possibly patching config.sub to exec a system copy so it can be patched once and not need repatching for each new architecture). I don't think whether a config.sub patch is needed should be a relevant consideration. -- Joseph S. Myers jos...@codesourcery.com
Re: xtensa PR65730
On Fri, Apr 10, 2015 at 10:51 PM, augustine.sterl...@gmail.com
wrote:
> On Fri, Apr 10, 2015 at 12:15 PM, Max Filippov wrote:
>> Then configuration w/o multiplication should call helper at -O0 and
>> use shift at higher optimization levels?
>
> That is what I would expect.
Ok, then I see why this doesn't happen: mulsi3 pattern matching is
conditional on TARGET_MUL32, so when TARGET_MUL32 ==0 and
expand_simple_binop emits a call to a helper it's not considered
mulsi3, it's just a call:
(call_insn/u 17 15 18 3 (set (reg:SI 10 a10)
(call (mem:SI (reg:SI 56) [0 S4 A32])
(const_int 0 [0])))
libstdc++-v3/include/bits/atomic_base.h:287 51 {call_value_internal}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("__mulsi3") [flags 0x41])
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list (use (reg:SI 11 a11))
(expr_list (use (reg:SI 10 a10))
(nil
vs.
(insn 15 14 16 3 (set (reg:SI 57)
(mult:SI (reg:SI 55)
(reg:SI 56))) libstdc++-v3/include/bits/atomic_base.h:287 5 {mulsi3}
(nil))
How can we have a mulsi3 pattern that don't get expanded until it's
optimized, and only gets expanded to a call if it couldn't be optimized?
--
Thanks.
-- Max
Re: AutoFDO profile toolchain is open-sourced
> On Tue, Apr 7, 2015 at 9:45 AM, Ilya Palachev wrote: > > In the mentioned README file it is said that " In order to collect this > > profile, you will need to have an Intel CPU that have last branch record > > (LBR) support." Is this information obsolete? Chrome Canary builds use > > AutoFDO for ARMv7l > > (https://code.google.com/p/chromium/issues/detail?id=434587) > > It does not mean that the profile was recorded on an ARM system: they > can gather perf.data on x86 and then produce a coverage file that is > then used in ARM compiles. I tried it and seems to work well. I must say I did not even try running AutoFDO myself (so I am happy to hear it works). My understanding is that you need LBR only to get indirect call profiling working (i.e. you want to know from where the indirect function is called). Depending on your application this may not be the most important thing to record (either you don't have indirect calls in hot paths or they are handled resonably by speculative devirtualization) Some ARMs also has support for tracing jump pairs, right? Honza > > Sebastian
Re: Please document `contrib/download_prerequisites'
On Thu, 30 May 2013, Michael Witten wrote: >> http://gcc.gnu.org/wiki/InstallingGCC > I'm not looking for anything. > > That wiki information should be incorporated into what that wiki page > calls `the official installation docs', and the rest of it should > probably be thrown out as superfluous. I agree. Are you willing to help with this? I commit to support you (review/approve/commit) patches with "some or next day" turnaround whenever I can. Gerald
Re: AutoFDO profile toolchain is open-sourced
LBR is used for both cfg edge profiling and indirect call Target value profiling. David On Fri, Apr 10, 2015 at 3:26 PM, Xinliang David Li wrote: > LBR is used for both cfg edge profiling and indirect call Target value > profiling. > > David > > On Apr 10, 2015 10:39 AM, "Jan Hubicka" wrote: >> >> > On Tue, Apr 7, 2015 at 9:45 AM, Ilya Palachev >> > wrote: >> > > In the mentioned README file it is said that " In order to collect >> > > this >> > > profile, you will need to have an Intel CPU that have last branch >> > > record >> > > (LBR) support." Is this information obsolete? Chrome Canary builds use >> > > AutoFDO for ARMv7l >> > > (https://code.google.com/p/chromium/issues/detail?id=434587) >> > >> > It does not mean that the profile was recorded on an ARM system: they >> > can gather perf.data on x86 and then produce a coverage file that is >> > then used in ARM compiles. I tried it and seems to work well. >> >> I must say I did not even try running AutoFDO myself (so I am happy to >> hear >> it works). My understanding is that you need LBR only to get indirect >> call profiling working (i.e. you want to know from where the indirect >> function is called). >> >> Depending on your application this may not be the most important thing to >> record (either you don't have indirect calls in hot paths or they are >> handled >> resonably by speculative devirtualization) >> >> Some ARMs also has support for tracing jump pairs, right? >> Honza >> > >> > Sebastian
Re: AutoFDO profile toolchain is open-sourced
> LBR is used for both cfg edge profiling and indirect call Target value > profiling. I see, that makes sense ;) I guess if we want to support profile collection on targets w/o this feature we could still use one of the algorithms that try to guess edge profile from BB profile. Honza
Re: AutoFDO profile toolchain is open-sourced
On Tue, Apr 7, 2015 at 7:45 AM, Ilya Palachev wrote: > Hi, > > Here are some questions about AutoFDO. > > On 08.05.2014 02:55, Dehao Chen wrote: >> >> We have open-sourced AutoFDO profile toolchain in: >> >> https://github.com/google/autofdo >> >> For GCC developers, the most important tool is create_gcov, which >> converts sampling based profile to GCC-readable profile. Please refer >> to the readme file >> (https://raw.githubusercontent.com/google/autofdo/master/README) for >> more details. > > > In the mentioned README file it is said that " In order to collect this > profile, you will need to have an Intel CPU that have last branch record > (LBR) support." Is this information obsolete? Chrome Canary builds use > AutoFDO for ARMv7l > (https://code.google.com/p/chromium/issues/detail?id=434587) > > What about Aarch64 support? Is it supported? As mentioned by Sebastian, the current solution is to collect profile on Intel platform (with LBR support) and cross optimize arm/aarch64 target. AutoFDO support with other PMU events (cycles, retired instructions etc) still needs more tuning to match FDO performance. > >> To use the profile, one need to checkout >> https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_8. We are working on >> porting AutoFDO to trunk >> (http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00438.html). > > > For now AutoFDO was merged into gcc-5.0 (trunk) branch. > Is it possible to backport it to 4.9 branch? Can you estimate required > efforts for that? The google gcc49 branch has the autofdo support. David > >> >> We have limited doc inside the open-sourced package, and we are >> planning to add more content to the wiki page >> (https://github.com/google/autofdo/wiki). Feel free to send me emails >> or discuss on github if you have any questions. >> >> Cheers, >> Dehao > > > -- > Best regards, > Ilya
Re: AutoFDO profile toolchain is open-sourced
On Fri, Apr 10, 2015 at 3:43 PM, Jan Hubicka wrote: >> LBR is used for both cfg edge profiling and indirect call Target value >> profiling. > I see, that makes sense ;) I guess if we want to support profile collection > on targets w/o this feature we could still use one of the algorithms that > try to guess edge profile from BB profile. Our experience with sampling cycles or retired instructions to guess BB profile has not been great -- the profile quality is significantly worse than LBR (which can almost match instrumentation based profile). David > > Honza
Re: xtensa PR65730
On Fri, Apr 10, 2015 at 1:18 PM, Max Filippov wrote:
> Ok, then I see why this doesn't happen: mulsi3 pattern matching is
> conditional on TARGET_MUL32, so when TARGET_MUL32 ==0 and
> expand_simple_binop emits a call to a helper it's not considered
> mulsi3, it's just a call:
>
> (call_insn/u 17 15 18 3 (set (reg:SI 10 a10)
> (call (mem:SI (reg:SI 56) [0 S4 A32])
> (const_int 0 [0])))
> libstdc++-v3/include/bits/atomic_base.h:287 51 {call_value_internal}
> (expr_list:REG_CALL_DECL (symbol_ref:SI ("__mulsi3") [flags 0x41])
> (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
> (nil)))
> (expr_list (use (reg:SI 11 a11))
> (expr_list (use (reg:SI 10 a10))
> (nil
>
> vs.
>
> (insn 15 14 16 3 (set (reg:SI 57)
> (mult:SI (reg:SI 55)
> (reg:SI 56))) libstdc++-v3/include/bits/atomic_base.h:287 5
> {mulsi3}
> (nil))
>
> How can we have a mulsi3 pattern that don't get expanded until it's
> optimized, and only gets expanded to a call if it couldn't be optimized?
I'm not completely sure, but I think you want to use OPTAB_LIB as you
described above, and eliminate the TARGET_MUL32 condition in the
pattern.
Re: lto bootstrap fails.
> On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: > > On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: > > > Like this: > > > > > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html > > > > > > ODR rears its head again ... > > > > huh, why is c/c-lang.h getting included in files linked into cc1plus? > > that seems strange. > > readelf -wl cc1plus | grep c-lang.h > doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. Index: tree.c === --- tree.c (revision 221977) +++ tree.c (working copy) @@ -4679,6 +4679,8 @@ build_translation_unit_decl (tree name) tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL, name, NULL_TREE); TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name; + if (main_input_filename) +DECL_NAME (tu) = get_identifier (main_input_filename); vec_safe_push (all_translation_units, tu); return tu; } Index: ipa-devirt.c === --- ipa-devirt.c(revision 221977) +++ ipa-devirt.c(working copy) @@ -979,6 +979,21 @@ warn_odr (tree t1, tree t2, tree st1, tr return; inform (DECL_SOURCE_LOCATION (decl2), reason); + tree name = TYPE_NAME (t1); + tree name1 = decl2; + /* See if we have info about the translation unit. It may not be around + if types was already merged. */ +while (TREE_CODE (name) != TRANSLATION_UNIT_DECL) + name = TYPE_P (name) ? TYPE_CONTEXT (name) : DECL_CONTEXT (name); +while (TREE_CODE (name1) != TRANSLATION_UNIT_DECL) + name1 = TYPE_P (name1) ? TYPE_CONTEXT (name1) : DECL_CONTEXT (name1); +name = DECL_NAME (name); +name1 = DECL_NAME (name1); +if (name != name1 && name && name1) + inform (UNKNOWN_LOCATION, "Conflicting compilation units: %s and %s", + IDENTIFIER_POINTER (name), + IDENTIFIER_POINTER (name1)); + if (warned) *warned = true; }
Need help to install C++ compiler
Hello GCC team, Greetings... I am new user of Linux. I have RHEL 6.0 installed and want to run C++ on my system but I do not know how. Please help me or let me know where to contact. -- Thanks & Regards, Kumar Aditya +919015142426
