Re: The Extension to ELF

[Fumiaki Isoya]

> 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 recommend that you understand how
> the format works before you attempt to extend it.

Thanks for your reply.

I don't necessarily have a thought special to ELF.  I merely thought
vaguely "it will become such a form, supposing it realizes".  If
required, even if it will become a completely different format from
ELF, I don't care.

I showed example.

> Point_do6   .define Object_MMAX .+ 4

What I hope is that this definition is going to be stored in .o file
as the following form.

[Point_do6] [Object_MAX] [4] [+] [!]

My main hope is to keep the principle "What is necessary is to
re-compile only the source files you touched".  I don't care at all if
I must convert the execution file or library file from different
format to ELF after linking or archiving.

Re: The Extension to ELF

[Frank Ch. Eigler]

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),
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.  (It may be similar to the vms-alpha ETIR facility.)

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
in bfd/*.

- FChE

Re: The Extension to ELF

[Ian Lance Taylor]

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 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.  (It may be similar to the vms-alpha ETIR facility.)
>
> 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
> in bfd/*.

Thanks, I was trying to remember that.

It is perhaps also worth noting that the IEEE-695 object file format
supports arbitrary expressions in a number of different ways,
including for relocation calculations.  The format is not widely used
today, for more or less that reason.

Ian

Re: The Extension to ELF

[Frank Ch. Eigler]

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
> > in bfd/*.
> 
> Thanks, I was trying to remember that.
> 
> It is perhaps also worth noting that the IEEE-695 object file format
> supports arbitrary expressions in a number of different ways,
> including for relocation calculations.  The format is not widely used
> today, for more or less that reason.

It is quite different from ELF for sure.  One certainly wouldn't want
to use such a complex-relocation facility unnecessarily - when the
hard-coded normal ones will do the job.  But if you need something
more, and are willing to pay the longer linking time (than what?),
it's worth considering.


- FChE

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

[Elmar Krieger]

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 did it in 14 seconds 
(that's 19x as long, requiring a cup of coffee after each code change). 
(Core i7 CPU).


For completeness, these are the GCC versions:

Slow with 264 seconds:

i686-linux-android-gcc (GCC) 4.6.x-google 20120106 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.

Fast with 14 seconds:

i386-mingw32msvc-gcc (GCC) 3.2.3 (mingw special 20030504-1)
Copyright (C) 2002 Free Software Foundation, Inc.

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, but if you agree on one 
expert to have a look, I'll provide it privately (please contact elmar 
_at_ cmbi.ru.nl). Could be related to the fact that this particular 
source file contains the application's main loop, a single large 
function with 28000 lines.



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 
clutters my code with nasty explicit type casts:


A simple example is the function freesetnull, that frees a pointer and 
sets it NULL (ptradd is a pointer address):


void freesetnull(void **ptradd)
{ free(*ptradd);
  *ptradd=NULL; }

Unfortunately, this function cannot be used in practice, because calling 
it yields an error:


error: passing argument 1 of ‘freesetnull’ from incompatible pointer type
note: expected ‘void **’ but argument is of type ‘char **’
[or whatever pointer you want to free]


If I understand correctly from a Usenet discussion, the reason for this 
error is that the C standard allows pointers to have different sizes (so 
sizeof(void*) might be larger than sizeof(int*) or so).


To get rid of this error, I need to sacrifice type safety and clutter my 
code with explicit casts, e.g.


void freesetnull(void *ptradd)
{ free(*(void**)ptradd);
  *(void**)ptradd=NULL; }

But since I've never seen such an exotic architecture with different 
pointer sizes and am 100% certain that my application will never run on 
such an architecture, I feel the strong need to sit down and contribute 
a GCC patch that turns this error into a warning that can be disabled 
(on mainstream architectures where all pointers have the same size).


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 ;-)


Best regards and many thanks,
Elmar

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

[Richard Guenther]

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 file (~6
> lines) now takes 4.5 minutes, while older GCCs did it in 14 seconds (that's
> 19x as long, requiring a cup of coffee after each code change). (Core i7
> CPU).
>
> For completeness, these are the GCC versions:
>
> Slow with 264 seconds:
>
> i686-linux-android-gcc (GCC) 4.6.x-google 20120106 (prerelease)
> Copyright (C) 2011 Free Software Foundation, Inc.
>
> Fast with 14 seconds:
>
> i386-mingw32msvc-gcc (GCC) 3.2.3 (mingw special 20030504-1)
> Copyright (C) 2002 Free Software Foundation, Inc.
>
> 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, but if you agree on one expert to have a
> look, I'll provide it privately (please contact elmar _at_ cmbi.ru.nl).
> Could be related to the fact that this particular source file contains the
> application's main loop, a single large function with 28000 lines.

Neither version is a pristine FSF released GCC (not to mention the
huge timespan this regression spans).  As the slowdown is for a specific
file it could be due to patches the vendors put in.

I suggest to narrow down the slowdown to a single file, produce preprocessed
source (that happens to compile with both compiler versions) and file a bug
so people can investigate.

Richard.

> 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 clutters my code
> with nasty explicit type casts:
>
> A simple example is the function freesetnull, that frees a pointer and sets
> it NULL (ptradd is a pointer address):
>
> void freesetnull(void **ptradd)
> { free(*ptradd);
>   *ptradd=NULL; }
>
> Unfortunately, this function cannot be used in practice, because calling it
> yields an error:
>
> error: passing argument 1 of ‘freesetnull’ from incompatible pointer type
> note: expected ‘void **’ but argument is of type ‘char **’
> [or whatever pointer you want to free]
>
>
> If I understand correctly from a Usenet discussion, the reason for this
> error is that the C standard allows pointers to have different sizes (so
> sizeof(void*) might be larger than sizeof(int*) or so).
>
> To get rid of this error, I need to sacrifice type safety and clutter my
> code with explicit casts, e.g.
>
> void freesetnull(void *ptradd)
> { free(*(void**)ptradd);
>   *(void**)ptradd=NULL; }
>
> But since I've never seen such an exotic architecture with different pointer
> sizes and am 100% certain that my application will never run on such an
> architecture, I feel the strong need to sit down and contribute a GCC patch
> that turns this error into a warning that can be disabled (on mainstream
> architectures where all pointers have the same size).
>
> 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 ;-)
>
> Best regards and many thanks,
> Elmar

GCC support for PowerPC VLE

[William Swashbuckler]

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/gcc/RS_002f6000-and-PowerPC-Options.html

Can anyone point me in the right direction?

Thx

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

[Richard Henderson]

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 calling stuff like
> MEM[f1+16B]() instead of f2() in g++.dg/template/ptrmem18.C.

Yes.  The ia64 vtable format has the function descriptors directly
in the table.  See TARGET_VTABLE_USES_DESCRIPTORS.  It is unique in
this feature so far (although if another new abi decides to use
function descriptors at all, I would recommend this as well).

Thus &vtable[index] is the "function pointer" that is passed to the
backend for expansion in the call sequence.


r~

Re: The Extension to ELF

[Fumiaki Isoya]

> 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.  (It may be similar to the vms-alpha ETIR facility.)

Did you write some compiler language to evaluate that feature?
How is the idea of adopting it as the standard format of GNU Hurd?

- Isoyaf

Re: The Extension to ELF

[Frank Ch. Eigler]

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 into the
>> binary output.  [...]
>
> Did you write some compiler language to evaluate that feature?

No.  Software for this particular was mainly coded in assembly, and
the assembly language / instruction set were itself very
configurable(!), so relocations had to be general.  If this capability
is useful for a higher-level language, a binding would have to be
created, and the arch gas/binutils would have to start generating the
info.

> 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 support it, since all the action takes place within the
assembler and linker.

- FChE

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

[David Brown]

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** pointer problem', that
clutters my code with nasty explicit type casts:

A simple example is the function freesetnull, that frees a pointer and
sets it NULL (ptradd is a pointer address):

void freesetnull(void **ptradd)
{ free(*ptradd);
*ptradd=NULL; }



I suspect this should be on the gcc-help mailing list rather than the 
development list.  But since you asked here, I'll try to help here.



Normally, good style encourages using static inline functions instead of 
macros, but here I would go for a macro:


freesetnull(_p) do { free(_p); _p = NULL; } while (0)

Note the slight change in the semantics - you pass the pointer, not a 
pointer to the pointer.


I expect this will also have the bonus of improving the speed of the 
resulting program - and possibly even of the compilation.


What's the other dirty hack?


Regarding compile time, modern gcc has "-funit-at-a-time" and 
"-ftop-level-reorder" enabled by default, even with no optimisation 
enabled.  These could take time on such a huge source code.  Try 
compiling with "-fno-unit-at-a-time" (which implies 
"-fno-toplevel-reorder").


mvh.,

David

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

[Andrew Haley]

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-Based Alias Analysis

for one reason.

Andrew.

Re: GCC support for PowerPC VLE

[David Brown]

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 options, see e.g.

http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

Can anyone point me in the right direction?

Thx



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 PowerPC microcontrollers are getting more 
popular outside their traditional market, and CodeSourcery's new parent 
company Mentor might see a future in VLE support.  And of course, there 
may be some other company or contributor that has implemented VLE 
support outside of the main tree.

Re: The Extension to ELF

[Fumiaki Isoya]

> > 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 support it, since all the action takes place within the
> assembler and linker.

OK.  I do discard my idea trying to cover shared library.  But I
believe that if such gas were the standard assembler, anyone will be
able to write lightweight OO compiler language comparatively easily.

- Isoyaf

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

[Elmar Krieger]

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
clutters my code with nasty explicit type casts:

A simple example is the function freesetnull, that frees a pointer and
sets it NULL (ptradd is a pointer address):

void freesetnull(void **ptradd)
{ free(*ptradd);
*ptradd=NULL; }



Normally, good style encourages using static inline functions instead of
macros, but here I would go for a macro:

freesetnull(_p) do { free(_p); _p = NULL; } while (0)

Note the slight change in the semantics - you pass the pointer, not a
pointer to the pointer.

I expect this will also have the bonus of improving the speed of the
resulting program - and possibly even of the compilation.


Many thanks, but this was really just the most simple example to 
illustrate how GCC's prohibition to pass a 'pointer to any pointer' to a 
function expecting a void** causes more problems than it solves. In your 
case, you are forced to use a macro (with the usual side-effects 
problem) instead of a safe 'static inline' to circumvent the problem.


But my code is full of cases that go beyond what can reasonably be done 
with macros.


Just one more complicated example:

A function that loads a binary file from disk and allocates the required 
memory to store the file contents, returning the number of bytes read. 
dstadd is the address where the newly allocated pointer is stored:


int dsc_loadfilealloc(void *dstadd,char *filename)
{ int read,size;
  FILE *fb;

  if ((fb=fopen(filename,"rb")))
  { size=dsc_filesize(filename);
*(void**)dstadd=mem_alloc(size);
read=dsc_readbytes(*(void**)dstadd,fb,size);
*(void**)dstadd=mem_realloc(*(void**)dstadd,read);
fclose(fb);
return(read); }
  *(void**)dstadd=NULL;
  return(0); }

Again, nasty casts all over the place, which would all disappear if GCC 
allowed me to write


int dsc_loadfilealloc(void **dstadd,char *filename)

which could then be used to load anything from text files to an array of 
'struct foo'.



Regarding compile time, modern gcc has "-funit-at-a-time" and
"-ftop-level-reorder" enabled by default, even with no optimisation
enabled. These could take time on such a huge source code. Try compiling
with "-fno-unit-at-a-time" (which implies "-fno-toplevel-reorder").


Many thanks, tried that and the time at -O !increased! (I am writing 
this from a slower computer) from 6 minutes 38 to 7 minutes. BTW, the 
time with -O0 is just 17 seconds.


And to Andrew Haley:

>> 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-Based Alias Analysis
> 
> for one reason.

Thanks, I read the article, but didn't really see how forbidding a 
function with argument void** to accept a pointer to any pointer helps 
with aliasing.


If it's perfectly normal that a function with argument void* accepts any 
pointer, then a function with argument void** should accept a pointer to 
any pointer by analogy, without having additional aliasing problems, no?


All the best,
Elmar

--
Elmar Krieger, PhD
YASARA Biosciences & CMBI Outstation Austria
Wagramer Strasse 25/3/45
1220 Vienna
Austria/Europe
www.YASARA.org

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

[Ian Lance Taylor]

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 accept a pointer to any pointer helps with aliasing.
>
> If it's perfectly normal that a function with argument void* accepts any
> pointer, then a function with argument void** should accept a pointer to any
> pointer by analogy, without having additional aliasing problems, no?

The C and C++ languages could work that way, yes.  But they don't.
GCC attempts to implement the standard language.

Aliasing issues arise when a function has two pointers, and determine
whether an assignment to *p1 might change the value at *p2.  There are
no aliasing issues with a void* pointer, because if p1 is void* then
*p1 is invalid.  That is not true for a void** pointer, so aliasing
issues do arise.  If p1 is void** and p2 is int**, then GCC will
assume that an assignment to *p1 does not change the value at *p2, as
the language standard states.  It's easy to imagine that that could
break a program after inlining.

Ian

Re: at exit alternative for AIX

[David Edelsohn]

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 have utility in other ways.

Perry,

You also might want to look at PR 33704, as well as PRs 17053, 13391
and 2413. It would be good to figure out a way to utilize the patch in
PR 33704.

The problem is AIX semantics is different than SVR4 semantics and GCC
should not assume that it is being used to link code expecting
GNU/Linux semantics.  AIX invokes initializers in the order the
libraries are encountered while SVR4 wisely specifies initializers run
in the proper dependency order.  IBM's C++ compiler works around this,
but it's name mangling, exception handling and initializers do not
follow G++ and the Itanium ABI conventions, so GCC cannot directly use
the same mechanisms.

One can merge the patch from PR 33704, but that raises the question of
when it should be used and what should be the default.

Use the option to build libstdc++? Okay.
Always use the option when linking with G++? Maybe.
Always use the option when linking with GCC? Probably not.

GCC is straddling the GNU/Linux and AIX environments. Should GCC
provide GNU/Linux behavior, IBM VAC++, or IBM XLC behavior?  When?
Which default?

A related situation that applied the GNU/Linux default of enabling
long double support to AIX caused numerous problems because of missing
library dependencies.  G++/libstdc++ had to revert from GNU/Linux
default behavior to AIX default behavior because pushing against AIX
caused too many problems that could not be solved without
re-implementing more and more of the AIX runtime.

Users of GCC on AIX expect different, conflicting defaults and expect
GCC the do the right thing based on context, which is impossible in
this situation.

Providing _cxa_atexit() using the existing finalizer function is the
right direction, but it still may run into problems due to the
lingering finalizer ordering bug.  I am not trying to discourage you
-- on the contrary I want to encourage you -- but I also want to
introduce some context.

Thanks, David

Support for C++11 decltype (N3276)

[Johan Lundberg]

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 important.
I'm wondering if there is any effort on supporting N3276?

  cheers Johan Lundberg

details:

There's an open bug, with a really simple test code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 . As expected it
breaks gcc4.7 (eats memory indefinitely).
The C++11 support page (http://gcc.gnu.org/gcc-4.7/cxx0x_status.html)
lists decltype support as 'Yes' but with reference only to the old
N3243.

The authors of the N3276 document "...do not anticipate that other
implementors will have any difficulty implementing this change.", but
I would not know. I'd love to help but have no experience with
compiler coding.

[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf

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

[Andi Kleen]

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 could file a bug report with just a profile output of the compiler
(e.g. from oprofile or perf)

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: GCC support for PowerPC VLE

[David Edelsohn]

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 PowerPC microcontrollers are getting more popular outside their
> traditional market, and CodeSourcery's new parent company Mentor might see a
> future in VLE support.  And of course, there may be some other company or
> contributor that has implemented VLE support outside of the main tree.

CodeSourcery does a lot of work on GCC, but they are not the main
PowerPC GCC maintainers.

CodeSourcery recently has been committing PowerPC VLE patches to Binutils.

- David