Re: typeof woes in symbol renaming, or glibc x gcc

[Andreas Jaeger <aj at suse dot de>]

Alexandre Oliva <aoliva@redhat.com> writes:

> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
> tricks to rename symbols, that have worked on functions for a while,
> but that had never been used on data symbols, and they happened to
> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
> and a few others).  It failed because, given the following code:
>
> extern int foo;
> extern __typeof(foo) foo asm("bar");
> int foo = 1;
>
> we'd call assemble_external() while processing the reference to `foo'
> within typeof, where we clearly don't need to be concerned about
> emitting external declarations in the assembler.  The ill effect was
> that the decl for foo would be bound to the name `foo' within
> assemble_external().  This was a bit too early for asm("bar") to take
> effect.  When we get to the point of processing the second declaration
> of foo, that would give it the name bar, the RTL already generated for
> the first decl is reused, so we keep on generating foo when
> referencing it, instead of using the new name.
>
> The solution I implemented that fixed the problem was to arrange for
> typeof to enter skip_evaluation mode (I was surprised to find out it
> didn't) and then arrange for no RTL or assembly code to be generated
> for references that occur while in skip_evaluation mode.
>
> An earlier version of this patch, that only modified the C front-end,
> passed bootstrap in IA64 (thanks, Jakub!).  Jakub also noticed that
> the problem affected C++ too, and kindly wrote testcases for me
> (thanks again! :-).  I've tested this patch myself on
> athlon-pc-linux-gnu-x-mips-elf.
>
> Ok to install?

Is this something for 3.2.1?  Or does it only fail on mainline?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj