Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Richard Guenther]

On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues  wrote:
> Hello gcc and libtool lists,
>
> Summary: both Autoconf-generated configure tests as well as some Libtool
> construct invoke undefined behavior.  Question is how to deal with it,
> and whether GCC, as QoI, may want to define behavior in these cases.
>
>
> 1) Autoconf-generated configure tests often fake the prototype of some
> function; e.g., AC_CHECK_FUNC([func]) uses
>  char func();
>
> and tries to link that.  Using this is undefined according to C99, if
> func has a different actual prototype, and when all system libraries are
> LTO'ed, gcc -flto may even detect this kind of inconsistency and could
> act accordingly (nasal demons and such).

I suppose autoconf cannot do this for C++ functions then, because
of mangling issues?

Note that the only thing GCC with LTO might do here is to issue
a diagnostic (which of course might confuse the configure script),
but we cannot really reject such programs (as such errors are
unfortunately very common) and thus defer any problems to
link- and/or runtime.

> 2) libtool has a feature that makes it extract symbol lists from
> objects and turn them into fake declarations and function/object
> pointers: fake static preloaded modules.
>
> It currently works by running nm or a similar tool over the object, then
> converting the output with a couple of sed script or so
> (global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
> synthesized extra source file that then contains code like this:
>
> extern int func();
> extern char variable;
>
> typedef struct {
>  const char *name;
>  void *address;
> } lt_dlsymlist;
>
> extern const lt_dlsymlist
> lt__PROGRAM__LTX_preloaded_symbols[];
> const lt_dlsymlist
> lt__PROGRAM__LTX_preloaded_symbols[] =
> {  { "@PROGRAM@", (void *) 0 },
>  {"func", (void *) &func},
>  {"variable", (void *) &variable},
>  {0, (void *) 0}
> };
>
> This is invoking undefined behavior in a couple of respects:
>
> a) Pointers to functions are stored in pointer-to-void variables.
> This could be fixed with an incompatible API change to using a union of
> object and function pointer, I guess.
>
> b) The symbols 'func' and 'variable' likely have the wrong prototypes,
> i.e., elsewhere, they might be declared as
>
>  void func(int, double);
>  double variable[42];
>
> instead.  I haven't come across any actual issues with this yet, except
> now LTO may rightfully complain about it.

Same issue as above.  We try to handle it - there might be bugs
in the current implementation of LTO though.

> Question is, what can we do about this?  We could ensure to never pass
> -flto or -fwhopr to the compilation of the libtool symfile object, and
> remove it from some or all link tests done in configure.  That's ugly.
> Would that even be sufficient though?  Conversely, would GCC developers
> be willing to agree that, when GCC detects such inconsistencies, it
> wouldn't take adverse advantage of it (e.g., by turning off LTO in this
> case, or similar)?
>
> Other possibilities for Autoconf would be to work toward a new set of
> checking macros (or extensions of current one) where the configure.ac
> author passes a full prototype for each function to check (Autoconf
> could keep a list of known prototypes for often-checked functions).
> I'm not sure how to fix the libtool symfile in a C99-conforming way.

I'd say wait and see.  What would be nice to have is a few testcases
that cover the autoconf cases in the GCC testsuite (feel free to
just file them into bugzilla).  We really do not want to break
working setups with LTO - any fancy ODR violation diagnostics
should IMHO be optional, only things that LTO does not get
correct are currently diagnosed IIRC.

Thanks,
Richard.

> Thanks for reading this far.
>
> Cheers,
> Ralf
>

Re: Optimizing floating point *(2^c) and /(2^c)

[Marc Glisse]

On Wed, 31 Mar 2010, Vincent Lefevre wrote:


On 2010-03-30 20:36:04 +0200, Jeroen Van Der Bossche wrote:
> The if statement is there exactly to address under- and overflow and
> nothing else. It's not because it looks simple that I didn't think
> it through. I know exactly how floating point multiplication works,
> and this implementation of *(2^c) doesn't violate under/overflow,
> denormalisation when e=0, rounding rules or rules about
> NaN/infinity.

However, extracting the exponent, and putting the new exponent back
to the floating-point number probably takes significant time (not
even mentioning the tests on the exponent) compared to what is done
entirely in hardware. I think that before anyone looks at this, you
should post benchmarks.

Also, the pipeline can stall due to the "if". Perhaps not in your
case. But a compiler cannot know that (the other branch is taken
when the value is 0, and this should not be regarded as rare).


IMHO this transformation mostly makes sense for the -ffinite-math-only 
case where you can replace: "put a constant and multiply/divide" by "put a 
constant and add/sub" and never care about extracting the exponent, 
overflowing, or anything else. And in that case, it does look like a nice 
optimization.


Otherwise, some old machines do have a slow enough multiplication that a 
soft-float implementation of /2^n can beat it, so it seems likely that 
some recent processors have the same characteristic, but it may indeed not 
be worth the trouble.



--
Marc Glisse

Re: Optimizing floating point *(2^c) and /(2^c)

[Vincent Lefevre]

On 2010-03-31 11:04:03 +0200, Marc Glisse wrote:
> IMHO this transformation mostly makes sense for the
> -ffinite-math-only case where you can replace: "put a constant and
> multiply/divide" by "put a constant and add/sub" and never care
> about extracting the exponent, overflowing, or anything else. And in
> that case, it does look like a nice optimization.

I suppose that this could be interesting only if a same register
can be seen as a FP one and an integer one (for the addition on
the exponent field), hoping that mixing both kinds of operations
won't stall the pipeline.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

__emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Jack Howarth]

Richard,
   I apologize for the mix up in testing the race
condition patch for value profiling of the indirect
calls on darwin. We may need to regress that out for
gcc 4.5, but first I would like to try to get a PR
opened to define the scope of the problem that it causes.
In particular, it is very strange that darwin appears 
to be the only target exhibiting failures in profiling 
after the race condition patch was committed. On
darwin this patch causes unresolved symbols...

/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
   -fprofile-generate -O3  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
Undefined symbols:
  "___emutls_v.__gcov_indirect_call_counters", referenced from:
  _mem_init in cc591Wfh.o
  _main in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
  "___emutls_v.__gcov_indirect_call_callee", referenced from:
  _mem_init in cc591Wfh.o
  _mem_init in cc591Wfh.o
  _main in cc591Wfh.o
  _main in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Is darwin the only target that really uses emulated tls? I had assumed
from...

case ${host} in
i[34567]86-*-linux* | x86_64-*-linux* | \
  i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
  i[34567]86-*-gnu*)
tmake_file="${tmake_file} t-tls"
;;
esac

in libgcc/config.host that only those targets are actually using
native tls in FSF gcc. Or are there actually different levels of
emulated tls?
   Who has the most expertise on the emulated tls code and could
provide some insight on this issue? There is some concern that
the emulated tls code might not be functioning entirely as expected
on darwin (despite the absence of testsuite failures without the
race condition patch). Thanks in advance for any suggestions.
Jack
ps We certainly have the emutls symbols in gcc trunk in general.
Current trunk shows...

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_s.1.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
00013e20 t _emutls_destroy
00013de0 t _emutls_init
00015100 b _emutls_key
000150a0 d _emutls_mutex
000150fc b _emutls_size

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Richard Guenther]

On Wed, 31 Mar 2010, Jack Howarth wrote:

> Richard,
>I apologize for the mix up in testing the race
> condition patch for value profiling of the indirect
> calls on darwin. We may need to regress that out for
> gcc 4.5, but first I would like to try to get a PR
> opened to define the scope of the problem that it causes.
> In particular, it is very strange that darwin appears 
> to be the only target exhibiting failures in profiling 
> after the race condition patch was committed. On
> darwin this patch causes unresolved symbols...
> 
> /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
> /sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
>-fprofile-generate -O3  -lm   -o
> /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
> Undefined symbols:
>   "___emutls_v.__gcov_indirect_call_counters", referenced from:
>   _mem_init in cc591Wfh.o
>   _main in cc591Wfh.o
>   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
>   "___emutls_v.__gcov_indirect_call_callee", referenced from:
>   _mem_init in cc591Wfh.o
>   _mem_init in cc591Wfh.o
>   _main in cc591Wfh.o
>   _main in cc591Wfh.o
>   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
>   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Is darwin the only target that really uses emulated tls? I had assumed
> from...
> 
> case ${host} in
> i[34567]86-*-linux* | x86_64-*-linux* | \
>   i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
>   i[34567]86-*-gnu*)
> tmake_file="${tmake_file} t-tls"
> ;;
> esac
> 
> in libgcc/config.host that only those targets are actually using
> native tls in FSF gcc. Or are there actually different levels of
> emulated tls?
>Who has the most expertise on the emulated tls code and could
> provide some insight on this issue? There is some concern that
> the emulated tls code might not be functioning entirely as expected
> on darwin (despite the absence of testsuite failures without the
> race condition patch). Thanks in advance for any suggestions.
> Jack
> ps We certainly have the emutls symbols in gcc trunk in general.
> Current trunk shows...
> 
> [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> libgcc_s.1.dylib | grep emutls
> 00013e70 T ___emutls_get_address
> 00014070 T ___emutls_register_common
> 00013e20 t _emutls_destroy
> 00013de0 t _emutls_init
> 00015100 b _emutls_key
> 000150a0 d _emutls_mutex
> 000150fc b _emutls_size
> 
> [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> libgcc_ext.10.5.dylib | grep emutls
> 00013e70 T ___emutls_get_address
> 00014070 T ___emutls_register_common

I suppose they are not exported.

Richard.

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Dominique Dhumieres]

With revision 156618, grepping the assembly of 
gcc/testsuite/gcc.dg/matrix/transpose-1.c
for gcov_indirect, I get

movq___gcov_indirect_call_callee(%rip), %rcx
movq___gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
movq$0, ___gcov_indirect_call_callee(%rip)
movq___gcov_indirect_call_callee(%rip), %rcx
movq___gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
movq$0, ___gcov_indirect_call_callee(%rip)
movq___gcov_indirect_call_callee(%rip), %rcx
movq___gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
movq$0, ___gcov_indirect_call_callee(%rip)
.lcomm ___gcov_indirect_call_callee,8,3
.lcomm ___gcov_indirect_call_counters,8,3

With revision 157836, I get

leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi
leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi
leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi
leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi
leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi
leaq___emutls_v.__gcov_indirect_call_counters(%rip), %rdi
call___gcov_indirect_call_profiler
leaq___emutls_v.__gcov_indirect_call_callee(%rip), %rdi

What is the origin of the "_emutls_v." "decoration"?

Dominique

Fwd: Swap32 built in function

[simeon]

Hi,

I would like to add swap32 built in function to gcc. I looked how other

built in functions are implemented, but I didn't managed.



Can someone give me some idea what to do?



Aleksandar

GNU assembler bug fix

[H.J. Lu]

Hi,

The old GNU assemblers may use memcpy to copy overlap memory:

http://sourceware.org/bugzilla/show_bug.cgi?id=11456

It has been fixed by replacing memcpy with memove. I recommend
all existing GNU assemblers be fixed, especially with glibc trunk on
x86 since it has the optimized memcpy which may trigger the assembler
bug.

-- 
H.J.

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Jack Howarth]

On Wed, Mar 31, 2010 at 02:14:41PM +0200, Richard Guenther wrote:
> On Wed, 31 Mar 2010, Jack Howarth wrote:
> 
> > Richard,
> >I apologize for the mix up in testing the race
> > condition patch for value profiling of the indirect
> > calls on darwin. We may need to regress that out for
> > gcc 4.5, but first I would like to try to get a PR
> > opened to define the scope of the problem that it causes.
> > In particular, it is very strange that darwin appears 
> > to be the only target exhibiting failures in profiling 
> > after the race condition patch was committed. On
> > darwin this patch causes unresolved symbols...
> > 
> > /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
> > -B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
> > /sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
> >-fprofile-generate -O3  -lm   -o
> > /sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
> > Undefined symbols:
> >   "___emutls_v.__gcov_indirect_call_counters", referenced from:
> >   _mem_init in cc591Wfh.o
> >   _main in cc591Wfh.o
> >   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
> >   "___emutls_v.__gcov_indirect_call_callee", referenced from:
> >   _mem_init in cc591Wfh.o
> >   _mem_init in cc591Wfh.o
> >   _main in cc591Wfh.o
> >   _main in cc591Wfh.o
> >   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
> >   global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
> > ld: symbol(s) not found
> > collect2: ld returned 1 exit status
> > 
> > Is darwin the only target that really uses emulated tls? I had assumed
> > from...
> > 
> > case ${host} in
> > i[34567]86-*-linux* | x86_64-*-linux* | \
> >   i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
> >   i[34567]86-*-gnu*)
> > tmake_file="${tmake_file} t-tls"
> > ;;
> > esac
> > 
> > in libgcc/config.host that only those targets are actually using
> > native tls in FSF gcc. Or are there actually different levels of
> > emulated tls?
> >Who has the most expertise on the emulated tls code and could
> > provide some insight on this issue? There is some concern that
> > the emulated tls code might not be functioning entirely as expected
> > on darwin (despite the absence of testsuite failures without the
> > race condition patch). Thanks in advance for any suggestions.
> > Jack
> > ps We certainly have the emutls symbols in gcc trunk in general.
> > Current trunk shows...
> > 
> > [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> > libgcc_s.1.dylib | grep emutls
> > 00013e70 T ___emutls_get_address
> > 00014070 T ___emutls_register_common
> > 00013e20 t _emutls_destroy
> > 00013de0 t _emutls_init
> > 00015100 b _emutls_key
> > 000150a0 d _emutls_mutex
> > 000150fc b _emutls_size
> > 
> > [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
> > libgcc_ext.10.5.dylib | grep emutls
> > 00013e70 T ___emutls_get_address
> > 00014070 T ___emutls_register_common
> 
> I suppose they are not exported.
> 
> Richard.

Richard,
Shouldn't these still show up in the output from...

nm libgcc_s.1.dylib | grep emutls

with a lower case symbol type? I am wondering if the call
is being generated in tree-profile.c but not the actual
subroutine in the libgcc build?
   Jack
ps I have opened PR43602 for this issue.

Re: Fwd: Swap32 built in function

[Paolo Carlini]

On 03/31/2010 03:21 PM, simeon wrote:
> Can someone give me some idea what to do?
>   
If you mean something like __builtin_bswap32, just use it ;)

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins

If you mean something else... explain in better detail.

Paolo.

Re: Optimizing floating point *(2^c) and /(2^c)

[Geert Bosch]

On Mar 29, 2010, at 16:30, Tim Prince wrote:
> gcc used to have the ability to replace division by a power of 2 by an fscale 
> instruction, for appropriate targets (maybe still does).
The problem (again) is that floating point multiplication is 
just too damn fast. On x86, even though the latency may 
be 5 cycles, since the multiplier is fully pipelined, the 
throughput is one multiplication per clock cycle, and that's
for non-vectorized code!

For comparison, the fscale instruction breaks down to 30 µops
or something like that, compared to a single µop for most
forms of floating point multiplication. Given that Jeroen
also needs to do floating-point additions, just bouncing
the values between integer and float registers will be
more expensive than the entire multiplication is in the
first place.

> Such targets have nearly disappeared from everyday usage.  What remains is 
> the possibility of replacing the division by constant power of 2 by 
> multiplication, but it's generally considered the programmer should have done 
> that in the beginning.

No, this is something the compiler does and should do. 
It is well understood that for binary floating point multiplications
division by a power of two is identical to multiplication by its reciprocal,
and it's the compiler's job to select the fastest instruction.

  -Geert

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Dave Korn]

On 31/03/2010 13:34, Dominique Dhumieres wrote:

> What is the origin of the "_emutls_v." "decoration"?

  varasm.c:

> /* Create an identifier for the struct __emutls_object, given an identifier
>of the DECL_ASSEMBLY_NAME of the original object.  */
> 
> static tree
> get_emutls_object_name (tree name)
> {
>   const char *prefix = (targetm.emutls.var_prefix
>   ? targetm.emutls.var_prefix
>   : "__emutls_v" EMUTLS_SEPARATOR);
>   return prefix_name (prefix, name);
> }

  Or is that not quite what you meant?

cheers,
  DaveK

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Paolo Bonzini]

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common


I suppose they are not exported.

Richard.


Richard,
 Shouldn't these still show up in the output from...

nm libgcc_s.1.dylib | grep emutls

with a lower case symbol type?


Not if they end up as private_extern symbols (i.e. hidden in GCC/ELF 
parlance).


Paolo

GCC 4.5.0 Status Report (2010-03-31), trunk is frozen

[Richard Guenther]

Status
==

We have reached the zero P1 GCC 4.5 regressions required for a
release candidate build of GCC 4.5.0.  To allow this state to
prevail the trunk is frozen for non-documentation changes
starting April 2nd (use your timezone for your advantage).
A release candidate will not be built before the end of Easter.

All changes possibly affecting primary or secondary targets
and languages require release manager approval at this point.

Please use extra care even for regression fixes that you want
to get in before GCC 4.5.0.  GCC 4.5.0 will not be the end of GCC 4.5,
there will be plenty of time to fix bugs and regressions for
subsequent releases from the GCC 4.5 branch.

Overall GCC 4.5 looks good.  Thanks for the previous two weeks
of bugfixing!

Please use the Easter holidays for testing and not for introducing bugs ;)


Quality Data


Priority  # Change from Last Report
--- ---
P10 - 16
P2   81 - 17
P34 +  1 
--- ---
Total85 - 32


Previous Report
===

http://gcc.gnu.org/ml/gcc/2010-03/msg00155.html


The next status report will be sent by Jakub.


-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Jack Howarth]

On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
>
 [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
 libgcc_ext.10.5.dylib | grep emutls
 00013e70 T ___emutls_get_address
 00014070 T ___emutls_register_common
>>>
>>> I suppose they are not exported.
>>>
>>> Richard.
>>
>> Richard,
>>  Shouldn't these still show up in the output from...
>>
>> nm libgcc_s.1.dylib | grep emutls
>>
>> with a lower case symbol type?
>
> Not if they end up as private_extern symbols (i.e. hidden in GCC/ELF  
> parlance).
>
> Paolo

Paolo,
   Okay, but it is still very puzzling that no other target seems impacted.
Which other targets should be using emulated tls like darwin? Shouldn't
they have the same issues with undefined symbols?
  Jack

Re: GCC 4.5.0 Status Report (2010-03-31), trunk is frozen

[Jack Howarth]

On Wed, Mar 31, 2010 at 05:54:52PM +0200, Richard Guenther wrote:
> 
> Status
> ==
> 
> We have reached the zero P1 GCC 4.5 regressions required for a
> release candidate build of GCC 4.5.0.  To allow this state to
> prevail the trunk is frozen for non-documentation changes
> starting April 2nd (use your timezone for your advantage).
> A release candidate will not be built before the end of Easter.
> 
> All changes possibly affecting primary or secondary targets
> and languages require release manager approval at this point.
> 
> Please use extra care even for regression fixes that you want
> to get in before GCC 4.5.0.  GCC 4.5.0 will not be the end of GCC 4.5,
> there will be plenty of time to fix bugs and regressions for
> subsequent releases from the GCC 4.5 branch.
> 
> Overall GCC 4.5 looks good.  Thanks for the previous two weeks
> of bugfixing!
> 
> Please use the Easter holidays for testing and not for introducing bugs ;)
> 
> 
> Quality Data
> 
> 
> Priority  # Change from Last Report
> --- ---
> P10 - 16
> P2   81 - 17
> P34 +  1 
> --- ---
> Total85 - 32
> 
> 
> Previous Report
> ===
> 
> http://gcc.gnu.org/ml/gcc/2010-03/msg00155.html
> 
> 
> The next status report will be sent by Jakub.
> 
> 
> -- 
> Richard Guenther 
> Novell / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus 
> Rex

Richard,
   We will have to sort out whether to regress r157822 for the gcc 4.5.0
or if a simple fix is available for darwin either by fixing the export of
the undefined  __emutls_v.__gcov_indirect_call_counters and 
___emutls_v.__gcov_indirect_call_callee or wrappering the
DECL_TLS_MODEL () statements with #ifdef HAVE_AS_TLS/#endif ala...

Author: jiez
Date: Fri Jan 23 04:58:03 2009
New Revision: 143583

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143583
Log:
libmudflap/
* mf-impl.h (__mf_get_state, __mf_set_state): Don't use
__thread when TLS support is emulated.
* mf-hooks3.c (__mf_get_state, __mf_set_state): Likewise.
* mf-runtime.c (__mf_state_1): Likewise.
* configure.ac: Use GCC_CHECK_EMUTLS.
* configure: Regenerate.
* config.h.in: Regenerate.

config/
* tls.m4 (GCC_CHECK_EMUTLS): Define.

Modified:
trunk/config/ChangeLog
trunk/config/tls.m4
trunk/libmudflap/ChangeLog
trunk/libmudflap/config.h.in
trunk/libmudflap/configure
trunk/libmudflap/configure.ac
trunk/libmudflap/mf-hooks3.c
trunk/libmudflap/mf-impl.h
trunk/libmudflap/mf-runtime.c

Jack 

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Jack Howarth]

On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
>
 [MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
 libgcc_ext.10.5.dylib | grep emutls
 00013e70 T ___emutls_get_address
 00014070 T ___emutls_register_common
>>>
>>> I suppose they are not exported.
>>>
>>> Richard.
>>
>> Richard,
>>  Shouldn't these still show up in the output from...
>>
>> nm libgcc_s.1.dylib | grep emutls
>>
>> with a lower case symbol type?
>
> Not if they end up as private_extern symbols (i.e. hidden in GCC/ELF  
> parlance).
>
> Paolo

Paolo,
   So are you saying that we need to use...

Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 157873)
+++ gcc/tree-profile.c  (working copy)
@@ -79,7 +79,7 @@
  get_identifier ("__gcov_indirect_call_callee"),
  ptr_void);
   TREE_STATIC (ic_void_ptr_var) = 1;
-  TREE_PUBLIC (ic_void_ptr_var) = 0;
+  TREE_PUBLIC (ic_void_ptr_var) = 1;
   DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
   DECL_INITIAL (ic_void_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
@@ -91,7 +91,7 @@
  get_identifier ("__gcov_indirect_call_counters"),
  gcov_type_ptr);
   TREE_STATIC (ic_gcov_type_ptr_var) = 1;
-  TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
+  TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
   DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
   DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model 
(ic_gcov_type_ptr_var);

I assume also adding...

Index: tree-profile.c
===
--- tree-profile.c  (revision 157873)
+++ tree-profile.c  (working copy)
@@ -64,8 +64,8 @@
 /* Do initialization work for the edge profiler.  */
 
 /* Add code:
-   static gcov*__gcov_indirect_call_counters; // pointer to actual 
counter
-   static void*__gcov_indirect_call_callee; // actual callee address
+   static gcov*__gcov_indirect_call_counters __attribute__ 
((visibility("default")); // pointer to actual counter
+   static void*__gcov_indirect_call_callee __attribute__ 
((visibility("default")); // actual callee address
 */
 static void
 tree_init_ic_make_global_vars (void)

would be redundant. Or do we just really need to delete the TREE_PUBLIC's 
instead...

Index: tree-profile.c
===
--- tree-profile.c  (revision 157873)
+++ tree-profile.c  (working copy)
@@ -79,7 +79,6 @@
  get_identifier ("__gcov_indirect_call_callee"),
  ptr_void);
   TREE_STATIC (ic_void_ptr_var) = 1;
-  TREE_PUBLIC (ic_void_ptr_var) = 0;
   DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
   DECL_INITIAL (ic_void_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
@@ -91,7 +90,6 @@
  get_identifier ("__gcov_indirect_call_counters"),
  gcov_type_ptr);
   TREE_STATIC (ic_gcov_type_ptr_var) = 1;
-  TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
   DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
   DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model 
(ic_gcov_type_ptr_var);

Thanks in advance for any advice on this.
  Jack

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Paolo Bonzini]

On 03/31/2010 06:00 PM, Jack Howarth wrote:

On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:



[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common


I suppose they are not exported.

Richard.


Richard,
  Shouldn't these still show up in the output from...

nm libgcc_s.1.dylib | grep emutls

with a lower case symbol type?


Not if they end up as private_extern symbols (i.e. hidden in GCC/ELF
parlance).

Paolo


Okay, but it is still very puzzling that no other target seems impacted.
Which other targets should be using emulated tls like darwin? Shouldn't
they have the same issues with undefined symbols?


In general, only ELF targets support visibilities, plus Darwin.

Paolo

Re: __emutls_v.__gcov_indirect_call_counters and ___emutls_v.__gcov_indirect_call_callee

[Paolo Bonzini]

On 03/31/2010 06:24 PM, Jack Howarth wrote:

On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:



[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common


I suppose they are not exported.

Richard.


Richard,
  Shouldn't these still show up in the output from...

nm libgcc_s.1.dylib | grep emutls

with a lower case symbol type?


Not if they end up as private_extern symbols (i.e. hidden in GCC/ELF
parlance).

Paolo


Paolo,
So are you saying that we need to use...

Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 157873)
+++ gcc/tree-profile.c  (working copy)
@@ -79,7 +79,7 @@
  get_identifier ("__gcov_indirect_call_callee"),
  ptr_void);
TREE_STATIC (ic_void_ptr_var) = 1;
-  TREE_PUBLIC (ic_void_ptr_var) = 0;
+  TREE_PUBLIC (ic_void_ptr_var) = 1;
DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
DECL_INITIAL (ic_void_ptr_var) = NULL;
DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
@@ -91,7 +91,7 @@
  get_identifier ("__gcov_indirect_call_counters"),
  gcov_type_ptr);
TREE_STATIC (ic_gcov_type_ptr_var) = 1;
-  TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
+  TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model 
(ic_gcov_type_ptr_var);

I assume also adding...

Index: tree-profile.c
===
--- tree-profile.c  (revision 157873)
+++ tree-profile.c  (working copy)
@@ -64,8 +64,8 @@
  /* Do initialization work for the edge profiler.  */

  /* Add code:
-   static gcov*__gcov_indirect_call_counters; // pointer to actual 
counter
-   static void*__gcov_indirect_call_callee; // actual callee address
+   static gcov*__gcov_indirect_call_counters __attribute__ 
((visibility("default")); // pointer to actual counter
+   static void*__gcov_indirect_call_callee __attribute__ 
((visibility("default")); // actual callee address
  */
  static void
  tree_init_ic_make_global_vars (void)

would be redundant. Or do we just really need to delete the TREE_PUBLIC's 
instead...

Index: tree-profile.c
===
--- tree-profile.c  (revision 157873)
+++ tree-profile.c  (working copy)
@@ -79,7 +79,6 @@
  get_identifier ("__gcov_indirect_call_callee"),
  ptr_void);
TREE_STATIC (ic_void_ptr_var) = 1;
-  TREE_PUBLIC (ic_void_ptr_var) = 0;
DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
DECL_INITIAL (ic_void_ptr_var) = NULL;
DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
@@ -91,7 +90,6 @@
  get_identifier ("__gcov_indirect_call_counters"),
  gcov_type_ptr);
TREE_STATIC (ic_gcov_type_ptr_var) = 1;
-  TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model 
(ic_gcov_type_ptr_var);


I was thinking of DECL_VISIBILITY/DECL_VISIBILITY_SPECIFIED, but if the 
symbols are not public, the visibility should not matter.


You need to do more debugging, including seeing what the decl actually 
looks like (breakpoint on assemble_variable).


BTW, here there seems to be a bug:

tree
emutls_decl (tree decl)
{
  tree name, to;
  struct tree_map *h, in;
  void **loc;
  ...
  DECL_WEAK (to) = DECL_WEAK (decl);
  DECL_VISIBILITY (to) = DECL_VISIBILITY (decl);

  return to;
}

DECL_VISIBILITY_SPECIFIED is not copied; same in 
get_emutls_init_templ_addr.  Also BTW, a possible cleanup in emutls_decl 
should be to change


  if (targetm.have_tls || decl == NULL || decl == error_mark_node
  || TREE_CODE (decl) != VAR_DECL || ! DECL_THREAD_LOCAL_P (decl))
return decl;

to

  assert (!targetm.have_tls && TREE_CODE (decl) == VAR_DECL
  && DECL_THREAD_LOCAL_P (decl));

Maybe looking at these will allow you to find the real cause...

Paolo

Diego Novillo appointed Plugins Reviewer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo as Plugins Reviewer.

Please join me in congratulating Diego on his new role.
Please update your listing in the MAINTAINERS file.

Happy hacking!
David

Ulrich Weigand appointed co-maintainer of Cell SPU port

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Ulrich Weigand as co-maintainer of the Cell SPU port.

Please join me in congratulating Uli on his new role.
Uli, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

* Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
> On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
> > 1) Autoconf-generated configure tests often fake the prototype of some
> > function; e.g., AC_CHECK_FUNC([func]) uses
> >  char func();
> >
> > and tries to link that.  Using this is undefined according to C99, if
> > func has a different actual prototype, and when all system libraries are
> > LTO'ed, gcc -flto may even detect this kind of inconsistency and could
> > act accordingly (nasal demons and such).
> 
> I suppose autoconf cannot do this for C++ functions then, because
> of mangling issues?

Correct.  For C++ libraries, it is more typical to just write a complete
test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.

FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
declarations given by the user (in order to support overloaded
basename, for example).

> Note that the only thing GCC with LTO might do here is to issue
> a diagnostic (which of course might confuse the configure script),
> but we cannot really reject such programs (as such errors are
> unfortunately very common) and thus defer any problems to
> link- and/or runtime.

That's almost exactly the kind of semantics I would like to see.
Can we get this documented in the manual?  Something like this.
Note that it would explicitly contradict one of the design goals
listed in lto.pdf, which is that conflicting declarations might
provoke an error; so really GCC developers should make a conscious
design decision here.


* doc/invoke.texi (Optimize Options): Document that LTO
won't remove object access purely due to incompatible
declarations.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2226cad..85f9c5f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7294,6 +7294,12 @@ regular (non-LTO) compilation.  This means that if your 
build process
 was mixing languages before, all you need to add is @option{-flto} to
 all the compile and link commands.
 
+If LTO encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to ISO C99 6.2.7), it might produce a warning, but
+this fact alone will not cause an access to an object to be optimized
+away.
+
 If object files containing GIMPLE bytecode are stored in a library
 archive, say @file{libfoo.a}, it is possible to extract and use them
 in an LTO link if you are using @command{gold} as the linker (which,


(In practice, Autoconf does not support -Werror at configure time; this
issue only reinforces that.)

> > b) The symbols 'func' and 'variable' likely have the wrong prototypes,
> > i.e., elsewhere, they might be declared as
> >
> >  void func(int, double);
> >  double variable[42];
> >
> > instead.  I haven't come across any actual issues with this yet, except
> > now LTO may rightfully complain about it.
> 
> Same issue as above.  We try to handle it - there might be bugs
> in the current implementation of LTO though.

Bugs are no problem as long as they are acknowledged as such.  I desire
future compatibility, i.e., being fairly certain autotools don't regress
just because of a good improvement in some other tool.  Dealing with
existing cruft is abundant in autotools.

> > Question is, what can we do about this?  We could ensure to never pass
> > -flto or -fwhopr to the compilation of the libtool symfile object, and
> > remove it from some or all link tests done in configure.  That's ugly.
> > Would that even be sufficient though?  Conversely, would GCC developers
> > be willing to agree that, when GCC detects such inconsistencies, it
> > wouldn't take adverse advantage of it (e.g., by turning off LTO in this
> > case, or similar)?
> >
> > Other possibilities for Autoconf would be to work toward a new set of
> > checking macros (or extensions of current one) where the configure.ac
> > author passes a full prototype for each function to check (Autoconf
> > could keep a list of known prototypes for often-checked functions).
> > I'm not sure how to fix the libtool symfile in a C99-conforming way.
> 
> I'd say wait and see.  What would be nice to have is a few testcases
> that cover the autoconf cases in the GCC testsuite (feel free to
> just file them into bugzilla).

I have been doing just that for the failures I've found so far.  I'll
add some more for stuff that ought to work.

> We really do not want to break
> working setups with LTO - any fancy ODR violation diagnostics
> should IMHO be optional, only things that LTO does not get
> correct are currently diagnosed IIRC.

That's a good sentiment.  autotools shouldn't stand on slippery
slope more than it has to.

Thanks,
Ralf

Passing call argument and return values

[Juan Carlos Martinez Santos]

Hi, I'm new in mail list, I expect that it is the right place to ask
for guidance.

I want to track input variables between functions. I already can mark
and track an input variable in the same function; however, when the
program uses that variable (directly or indirectly) as a argument in a
function, I cannot track it. I need to know how I can do it.

Working at middle-end, I cannot find a way to related the name of the
declared arguments with the GIMPLE's name. For example, if I have
something like: int foo (int a, int b), at GIMPLE IR I will see for
example that the argument a becomes a_3, the argument b becomes b_7,
and the return value become _15.

How I can relate the name of function parameters and the return value
when I am working with the GIMPLE IR? In other words, is there a nice
way to know that a_3 is a, b_7 is b, and so on?

Thanks in advance,

-- 
Juan Carlos

State of the mercurial mirror

[Thomas Capricelli]

Hello,

The mercurial mirror of the gcc repository, at http://gcc.gnu.org/hg/gcc has 
been broken for months. and the contact listed there does not answer emails.

Can somebody here at least remove those misleading pages..?

Also, i would volunteer to fix this, and even to maintain the mirror. Is this 
the right place to ask ? I don't even know if that's something that would be 
well accepted. Any interest for this ?

( note: I'm _not_ subscribed  to this mailing list, thanks for keeping me in cc 
)

best regards,
-- 
Thomas Capricelli 
http://www.freehackers.org/thomas