SPEC2006 436.cactusADM performance depends on the length of $LD_LIBRARY_PATH

[Ilya Verbin]

Hi All,

I discovered a strange behavior of SPEC CPU2006 436.cactusADM
benchmark. It’s performance depends on the length of $LD_LIBRARY_PATH
variable.
The benchmark was compiled with "-O3 -funroll-loops -ffast-math
-march=core-avx2 -mtune=core-avx2" using gcc version 4.8.0 20130218.
I used Intel Software Development Emulator 5.38.0 to run AVX2 code:

$ export LD_LIBRARY_PATH=''
$ /sde-bdw-external-5.38.0-2013-01-03-lin/sde -icount -- ./cactusADM
benchADM.par > benchADM.out 2> benchADM.err
ICOUNT: 2593690591

$ export LD_LIBRARY_PATH=''
$ /sde-bdw-external-5.38.0-2013-01-03-lin/sde -icount -- ./cactusADM
benchADM.par > benchADM.out 2> benchADM.err
ICOUNT: 2100709724

In the second case 23% less instructions are executed!

The difference is caused by the code, that checks the alignment of
some pointer in the benchmark. It seems that the environment variables
(including $LD_LIBRARY_PATH) are placed in the app’s memory, this
leads to different alignment, therefore to various execution paths.

Is this a known issue? Is there anything the GCC can do to make the
alignment more consistent?

Thanks,
Ilya

Re: C/C++ Option to Initialize Variables?

[Michael Matz]

Hi,

On Mon, 18 Feb 2013, Alexander Monakov wrote:

> On Mon, 18 Feb 2013, Michael Matz wrote:
> > Automatic variables, as they are on the stack, are unlikely to usually get
> > the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF
> > doesn't make much sense.
> 
> Hm, but the following comment from init-regs.c indicates that GCC will set
> some uninitialized vars to zero, except at -O0:

Yes, that's for pseudos, i.e. scalar automatic variables, doesn't work for 
may-uninitialized or aggregates and would be unnecessary with -Werror, as 
must-uninitialized can be and are detected without false positives.  The 
value could be made configurable but I wouldn't see the point.


Ciao,
Michael.

Re: SPEC2006 436.cactusADM performance depends on the length of $LD_LIBRARY_PATH

[Florian Weimer]

On 02/19/2013 12:14 PM, Ilya Verbin wrote:


Is this a known issue?


I think this might be the phenomenon described in Mytkowicz  et al., 
"Producing Wrong Data Without Doing Anything Obviously Wrong!".


--
Florian Weimer / Red Hat Product Security Team

Re: GCC compiler for ANDROID Nexus7

[Andrew Haley]

On 02/15/2013 01:13 PM, Jerome Huck wrote:
> There seems to be some versions of GCC for ANDROID C/C++/Pascal working
> or even Fortran, see the attached links. Can we hope one day to have
> some official release?

I can't see why not, but it'll require someone to contribute the code
and commit to maintaining it.  I haven't seen any volunteers.

Andrew.

How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

[Stephan Bergmann]

I'm puzzled by the following on Linux, where I don't understand what 
causes it that a given symbol is exported as "u" (when viewed with nm, 
which documents "u" as "a unique global symbol. This is a GNU 
extension...") or not:


* On an older toolchain (SLED 11 with GCC 4.3.4 and binutils 2.21.1), we 
have



$ nm -D /usr/lib64/libstdc++.so.6.0.16 | grep empty_rep_storage
002f7660 u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
002f7580 B _ZNSs4_Rep20_S_empty_rep_storageE


where the latter (aka "std::basic_string, 
std::allocator >::_Rep::_S_empty_rep_storage") is not exported as 
"u" while the former (aka "std::basic_stringstd::char_traits, std::allocator 
>::_Rep::_S_empty_rep_storage") is.  Also, in other dynamic libraries 
linked with that toolchain, _ZNSs4_Rep20_S_empty_rep_storageE is 
exported as "V", and:


** If libstdc++.so.6 is loaded after one of those other libraries, all 
libraries consistently bind to that other libraries' symbol, and 
everything works well.


** However, if libstdc++.so.6 is loaded first, it binds to its symbol, 
but all those other libraries loaded later bind to one of those other 
libaries' symbol, and there is an invalid delete on an address "0 bytes 
inside data symbol '_ZNSs4_Rep20_S_empty_rep_storageE'" from 
std::basic_stringbuf, std::allocator 
>::overflow(int) (in /usr/lib64/libstdc++.so.6.0.16), as reported by 
valgrind.


* But on a more recent toolchain (F18 with GCC 4.7.2 and binutils 
2.23.51), we have



$ nm -D /usr/lib64/libstdc++.so.6.0.17 | grep empty_rep_storage
003c831024e0 u _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
003c831024c0 u _ZNSs4_Rep20_S_empty_rep_storageE


Also, in dynamic libraries linked with that toolchain, 
_ZNSs4_Rep20_S_empty_rep_storageE is also exported as "u" and runtime 
behavior is just fine.


Now, why is _ZNSs4_Rep20_S_empty_rep_storageE exported as "B" resp. "V" 
in the first case, while it is consistently "u" in the second?


Stephan

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

[Florian Weimer]

On 02/19/2013 07:06 PM, Stephan Bergmann wrote:


I'm puzzled by the following on Linux, where I don't understand what
causes it that a given symbol is exported as "u" (when viewed with nm,
which documents "u" as "a unique global symbol. This is a GNU
extension...") or not:


We tracked this down to a bug in ld:



--
Florian Weimer / Red Hat Product Security Team

Re: Question on Undefined Right Shifts

[Ian Lance Taylor]

On Tue, Feb 19, 2013 at 4:19 PM, Jeffrey Walton  wrote:
>
> I've been using John Regehr's Integer Overflow Checker (IOC) on a few
> libraries. It is a Clang plug-in and can be found at
> http://embed.cs.utah.edu/ioc/.
>
> The checker has flagged two libraries I use for performing undefined
> right shifts:
>
> CLANG ARITHMETIC UNDEFINED at <./xxx, (595:22)> : Op: >>, Reason :
> Unsigned Right Shift: Right operand is negative or is greater than or
> equal to the width of the promoted left operand, BINARY OPERATION:
> left (uint32): 2196358166 right (uint32): 32
>
> The fix seems easy enough on the surface: simply validate the
> parameters before performing the shift. However, that could introduce
> a timing difference in the function.
>
> How could one fix the issue without introducing timing differences?

As the saying goes, I can write code that runs as fast as you like, if
it doesn't have to be correct.

If you care about the result of the shift, you need to ensure that the
right operand is within bounds, one way or another.

Ian

Re: Version specific onlinedocs page

[Gerald Pfeifer]

On Mon, 18 Feb 2013, Tobias Burnus wrote:

If "we" means that you are volunteering ;-), absolutely, go for it!

;-)


How about the following patch? If it is okay, I will add the remaining 
index.html for 4.6 and 4.7 and update gcc-4.6/index.html – and then 
commit it.


Looks good to me.

Perhaps you can add a note for the release manager how to "create"
index.html (copy from previous release and adjust)?

Gerald

Can DWARF2 CFI represent a static return location?

[Alan Lehotsky]

I'm looking at a machine with limited stack, and no push instructions or 
displaced-addressing mode.  The call instruction stores the return address in 
the link register.

For non-recursive functions we save the return address in a static memory 
location, but I can't find a way to tell the DWARF2 CFI that the saved location 
is a static MEM rtx.  Am I missing something?

Re: Can DWARF2 CFI represent a static return location?

[Ian Lance Taylor]

On Tue, Feb 19, 2013 at 7:32 PM, Alan Lehotsky  wrote:
> I'm looking at a machine with limited stack, and no push instructions or 
> displaced-addressing mode.  The call instruction stores the return address in 
> the link register.
>
> For non-recursive functions we save the return address in a static memory 
> location, but I can't find a way to tell the DWARF2 CFI that the saved 
> location is a static MEM rtx.  Am I missing something?

You  may have to use DW_CFA_def_cfa_expression with DW_OP_addr.

Ian

Re: Question on Undefined Right Shifts

[Jeffrey Walton]

On Tue, Feb 19, 2013 at 8:52 PM, Ian Lance Taylor  wrote:
> On Tue, Feb 19, 2013 at 4:19 PM, Jeffrey Walton  wrote:
>>
>> I've been using John Regehr's Integer Overflow Checker (IOC) on a few
>> libraries. It is a Clang plug-in and can be found at
>> http://embed.cs.utah.edu/ioc/.
>>
>> The checker has flagged two libraries I use for performing undefined
>> right shifts:
>>
>> CLANG ARITHMETIC UNDEFINED at <./xxx, (595:22)> : Op: >>, Reason :
>> Unsigned Right Shift: Right operand is negative or is greater than or
>> equal to the width of the promoted left operand, BINARY OPERATION:
>> left (uint32): 2196358166 right (uint32): 32
>>
>> The fix seems easy enough on the surface: simply validate the
>> parameters before performing the shift. However, that could introduce
>> a timing difference in the function.
>>
>> How could one fix the issue without introducing timing differences?
>
> As the saying goes, I can write code that runs as fast as you like, if
> it doesn't have to be correct.
Jon Bentley :)

> If you care about the result of the shift, you need to ensure that the
> right operand is within bounds, one way or another.
It looks like they have to use AND rather than MOD:

template  inline T rotlMod(T x, unsigned int y)
{
y &= sizeof(T)*8 - 1;
return T((x<>y));
}

Jeff