Re: GCC support for PowerPC VLE

On Wed, Aug 8, 2012 at 1:17 PM, David Brown wrote: > Where did you read about this? I talked to CodeSourcery (the main PowerPC > gcc maintainers) a while back, and they said they had no plans to implement > VLE - there simply wasn't enough market. That may have changed, however - > Freescale's

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Elmar Krieger writes: > > The slowdown is not the same with other files, so I'm essentially sure > that this specific source file has some 'feature' that catches GCC at > the wrong leg. This raises my hopes that one of the GCC experts wants > to take a look at it. The code is confidential, You co

Support for C++11 decltype (N3276)

Dear all, thank you for a great compiler! I have a question and feature request for C++11 decltype. The C++11 standard definition of decltype is described in N3276[1], but in earlier versions/C++0x it was N3243. The old version has been supported by gcc since a long time. The changes are quite imp

Re: at exit alternative for AIX

On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith wrote: > Thanks. You just provide what I wanted / needed which is a sanity check. > > I'll open a bug report and that might get me some help. > > I think I've concocted a plan to get __cxa_atexit to work. I am going to try > that > first. That may h

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Wed, Aug 8, 2012 at 12:09 PM, Elmar Krieger wrote: >> Not at all high. See Type-Based Alias Analysis >> >> for one reason. > > Thanks, I read the article, but didn't really see how forbidding a function > with argument void** to

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi David, hi Andrew, One other thing I just thought of: GCC has a history of very smart extensions to C that allow to write faster and more elegant code. If I look at my code, there are mostly two sources of 'dirty hacks' left. One that could be fixed easily is the 'void** pointer problem', that

Re: The Extension to ELF

> > How is the idea of adopting it as the standard format of GNU Hurd? > > I have no opinion on this. Note though that these complex relocations > are encoded within a standard ELF file (merely using separate > relocation-type and symbol-type codes). There is no need for an > OS/kernel to suppor

Re: GCC support for PowerPC VLE

On 08/08/12 17:08, William Swashbuckler wrote: Hi, I have recently read in several places that GCC now supports the PowerPC VLE instruction set architecture as a target. However, I have so far been unable to find any actual documentation on this? AFAICS the online doc doesn't show any new target

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/08/2012 03:01 PM, Elmar Krieger wrote: > To me, that just looks like a remnant from the ancient past that hinders > the future. On the other hand, my feeling tells me that this patch would > not be accepted, that's why I'm asking for my chances in advance ;-) Not at all high. See Type-Bas

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/08/12 16:01, Elmar Krieger wrote: One other thing I just thought of: GCC has a history of very smart extensions to C that allow to write faster and more elegant code. If I look at my code, there are mostly two sources of 'dirty hacks' left. One that could be fixed easily is the 'void** poi

Re: The Extension to ELF

Fumiaki Isoya writes: >> It may interest you to know that, for an older Cygnus project (mep), >> we implemented a facility called computed/complex relocations, as an >> ELF extension. This is a way of encoding general symbol/arithmetic >> expressions to be evaluated at link time and substituted

Re: The Extension to ELF

> It may interest you to know that, for an older Cygnus project (mep), > we implemented a facility called computed/complex relocations, as an > ELF extension. This is a way of encoding general symbol/arithmetic > expressions to be evaluated at link time and substituted into the > binary output.

Re: pr45605.C devirtualize call failure in ia64-hp-hpux?

On 08/07/2012 08:29 AM, Martin Jambor wrote: > So I did the testing and unfortunately this only works for the first > virtual function of a class, the sequence calling any other virtual > function has one more statement which adds VMT offset to the > typecasted pointer and after folding we end up c

GCC support for PowerPC VLE

Hi, I have recently read in several places that GCC now supports the PowerPC VLE instruction set architecture as a target. However, I have so far been unable to find any actual documentation on this? AFAICS the online doc doesn't show any new target options, see e.g. http://gcc.gnu.org/onlinedocs

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Wed, Aug 8, 2012 at 4:01 PM, Elmar Krieger wrote: > Dear all, > > while I fully understand that GCC's steadily advancing optimization > capabilities can't be 'for free', the latest versions have become almost > unusably slow for me: > > With simple optimization -O, compiling a certain C source

New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Dear all, while I fully understand that GCC's steadily advancing optimization capabilities can't be 'for free', the latest versions have become almost unusably slow for me: With simple optimization -O, compiling a certain C source file (~6 lines) now takes 4.5 minutes, while older GCCs d

Re: The Extension to ELF

Hi - On Wed, Aug 08, 2012 at 06:23:52AM -0700, Ian Lance Taylor wrote: > [...] > > This has been merged into gnu binutils some time ago, though is not > > widely known, and only used by a single cgen-based gas port. See the > > OBJ_COMPLEX_RELC conditionals in gas/*, the BSF_*RELC/STT_RELC logic

Re: The Extension to ELF

On Wed, Aug 8, 2012 at 4:23 AM, Frank Ch. Eigler wrote: > Ian Lance Taylor writes: > >> [...] >> ELF is designed to permit fast program loading at runtime, and to >> permit fast linking. Changing symbol and relocation values to take >> general expressions works against that goal. >> [...] > > It

Re: The Extension to ELF

Ian Lance Taylor writes: > [...] > ELF is designed to permit fast program loading at runtime, and to > permit fast linking. Changing symbol and relocation values to take > general expressions works against that goal. > [...] It may interest you to know that, for an older Cygnus project (mep), w

Re: The Extension to ELF

> ELF is designed to permit fast program loading at runtime, and to > permit fast linking. Changing symbol and relocation values to take > general expressions works against that goal. > I'm sure it is possible to improve on ELF in various ways. However, > ELF is pretty good. I very strongly re