Re: PR 36778: Should we have -Wfatal-warnings

[Paolo Carlini]

Hi,
> 
> This isn't actually necessary, they just need to make their test harness a 
> bit 
> smarter.  

[snip]

Fair enough, I'm going to close the PR as invalid with a link to your 
explanation.

Thanks!
Paolo

gcc-4.7-20111001 is now available

[gccadmin]

Snapshot gcc-4.7-20111001 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20111001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 179416

You'll find:

 gcc-4.7-20111001.tar.bz2 Complete GCC

  MD5=badf970f3355c21639048f6938bbb91e
  SHA1=6cfbf28f728a16fe038b9a4e0f17e982b784bb96

Diffs from 4.7-20110924 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: C++11 atomic library notes

[Andrew MacLeod]

On 10/01/2011 02:55 AM, Marc Glisse wrote:



"The compiler must ensure that for any given object, it either ALWAYS 
inlines lock free routines, OR calls the external routines. For any 
given object, these cannot be intermixed."


Why? You give an example explaining why it is fine to link 386 and 486 
objects, and I cant see the difference. Not that I'm advocating mixing 
them, just wondering whether it really matters if it happens (by 
accident).


If we have an architecture which we cannot generate one of the functions 
for, say __atomic_load_16, then it will have to use whatever the library 
supplies. If you continues to generate all the rest of the __atomic 
builtins for 16 bytes using lock free instructions, and the call to the 
library turns out to be a locked implementation at runtime, then atomic 
support for 16 byte objects is broken. The load thinks its getting a 
lock, but none of the other routines pay any attention to locks. So if 
one atomic operations requires then library, they all do in order to get 
consistent behaviour.




I assume that locks are supposed to be implemented in terms of those 
functions too (it sounds like lock uses atomic which uses lock ;-)


For the atomic version of a user-defined "small" POD type, do you 
intend to query the compiler about the presence of a volatile member 
to dispatch to the right function?
if it is sorted out that volatile does require something different, then 
we'd need to dispatch differently for volatile.  At the moment Im not 
doing anything different for them, just asking "the experts" if we need 
to :-)  I suspect we might need to, but Its easier to add something 
later than to remove something thats already in a compiler.


The design looks a lot like:
http://libcxx.llvm.org/atomic_design_a.html
which is good since the main point seems to be to share it between 
implementations. Are there others on board?


Im not aware that anyone has done anything with an external library 
yet.   Hopefully this will make us all aware of each other and get 
consistent :-).  I hadn's seen that link, I guess the name is a good 
choice :-)


Andrew

Suboptimal __restrict optimization?

[Ulf Magnusson]

Hi,

Given the code

class C { void f(int *p); int q; };

void C::f(int * __restrict p) __restrict {
q += 10;
*p = 7;
q += 10;
}

g++ 4.5.2 with -O3 generates the following for C::f() (prologue and
epilogue omitted):

mov0x8(%ebp),%eax // eax = this (= &q)
mov0xc(%ebp),%ecx // ecx = p
mov(%eax),%edx// edx = q
movl   $0x7,(%ecx)// *p = 7
add$0x14,%edx // q += 20
mov%edx,(%eax)// save q

If C::f() is rearranged as

void C::f(int * __restrict p) __restrict {
*p = 7;
q += 10;
q += 10;
}

the following is generated instead:

mov0x8(%ebp),%eax // eax = this (= &q)
mov0xc(%ebp),%edx // edx = p
movl   $0x7,(%edx)// *p = 7
addl   $0x14,(%eax)   // q += 20

Is there some reason why GCC couldn't generate this code for the first
version of C::f()? Is this a failure of optimization, or am I missing
something in how __restricted works?

/Ulf