Broken links on gcc.gnu.org/onlinedocs
Good morning, I got your email address at https://gcc.gnu.org/about.html, where the footnote on the page says "Comments on these web pages ... are welcome on our developer list at gcc@gcc.gnu.org." I hope I found the right address to report broken links. 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) Thank you for your time, -- James
Fwd: Re: gcc rodata regression
Hi Segher, On 2 February 2015 at 01:16, Segher Boessenkool wrote: > On Sat, Jan 31, 2015 at 05:09:29PM -0700, Simon Glass wrote: >> I have been fighting with a strange problem on ARM where gcc puts all >> the .rodata from a number of files lumped into a single .rodata >> section even when -fdata-sections is used. >> >> I searched and found a bug report here: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 >> >> which exactly describes the problem I see. > > You could try this patch. I think there were still some problems with > it, there must have been some reason I didn't submit it. Cannot have > been just laziness :-P I tried this patch and it solved my problem - the rodata section is now split up and most of it is discarded in the link phase. I hope some form of this can make it into gcc one day soon and a suitable regression test case can be added! Thanks, Simon [snip]
Re: Problem with extremely large procedures and 64-bit code
Hello Renato, thanks for your reply, sorry about the confusion with compilers - since there is a "clang" in the mac, I thought gcc was gcc.. After your suggestion, I modified the code, and installed a bona fide gcc compiler in the Mac I got more data that is kind of interesting, wanted to share with the gcc community. Someone might have an idea why this happens. No matter what compiler I use, gcc or llvm on Linux I seem to have this problem of 64-bit code being 3x slower than 32-bit when very large procedures are called. In my Macbook the 64-bit code is consistently faster regardless of the compiler. I got my hands on an i7 Mac and the 64-bit code is consistently 10% to 15% faster than the 32-bit code and - I am afraid to say something "political" here, have no intention of offending anyone, just the facts - with all the optimizations turned on, modified code to force inlinining here and there, both gcc and llvm yield pretty much the same performance, in fact both are outstanding, reduced the time I reported previously from the 16.2s to 1.1s!!! AVX gave me an extra 10% over SSE (tricky to get AVX to compile in the mac with gcc, but not impossible). Of course is hard to compare apples to apples here with Xeon Westmere at 2Ghz and i7 IvyBridge at 3.5GHz, but almost 15x is quite a difference, given the clock ratios are less than 2. Now I am trying to investigate if the problem is with Linux itself - which is not so good because I need to release code on Linux, or there some strange cache issue, or the way libraries are setup, or with the Westmere vs IvyBridge. I will keep you posted if I find out more. Best, Ricardo On 1/23/15 8:16 AM, Renato Golin wrote: On 23 January 2015 at 16:07, Ricardo Telichevesky wrote: gcc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) - don't know what that means expected a number like 4.2.1 or something like that, 2.53 GHz Intel Core 2 Duo Hi Ricardo, This is not gcc at all, it's Clang+LLVM. :/ I'm not sure why Apple decided to call the binary "gcc", which obviously causes more confusion than solves problems, but that's beyond the point. You should try Richard's suggestions again on the Linux/GCC that you originally started. cheers, --renato
Re: Problem with extremely large procedures and 64-bit code
On Mon, Feb 9, 2015 at 11:11 AM, Ricardo Telichevesky wrote: > Hello Renato, thanks for your reply, sorry about the confusion with > compilers - since there is a "clang" in the mac, I thought gcc was gcc.. > After your suggestion, I modified the code, and installed a bona fide gcc > compiler in the Mac I got more data that is kind of interesting, wanted > to share with the gcc community. Someone might have an idea why this > happens. > > No matter what compiler I use, gcc or llvm on Linux I seem to have this > problem of 64-bit code being 3x slower than 32-bit when very large > procedures are called. In my Macbook the 64-bit code is consistently faster > regardless of the compiler. I got my hands on an i7 Mac and the 64-bit code > is consistently 10% to 15% faster than the 32-bit code and - I am afraid to > say something "political" here, have no intention of offending anyone, just > the facts - with all the optimizations turned on, modified code to force > inlinining here and there, both gcc and llvm yield pretty much the same > performance, in fact both are outstanding, reduced the time I reported > previously from the 16.2s to 1.1s!!! AVX gave me an extra 10% over SSE > (tricky to get AVX to compile in the mac with gcc, but not impossible). > > Of course is hard to compare apples to apples here with Xeon Westmere at > 2Ghz and i7 IvyBridge at 3.5GHz, but almost 15x is quite a difference, given > the clock ratios are less than 2. > > Now I am trying to investigate if the problem is with Linux itself - which > is not so good because I need to release code on Linux, or there some > strange cache issue, or the way libraries are setup, or with the Westmere vs > IvyBridge. I will keep you posted if I find out more. > To compare 64-bit vs 32-bit performance on Linux against MacOS, you MUST compile your code with -fPIC on Linux since -fPIC is the default on MacOS. -- H.J.
Separately build C front-end
Hi, I have been trying to build the C front-end separately for a project, without much progress. I'd appreciate any sort of help or advice in this regard. Thanks in advance. -- Regards Sidharth Chaturvedi
