Re: Links to libstdc++ document are inaccessible.
On 28 October 2011 01:57, sxzzsf wrote: > Hi, > > On the page of http://gcc.gnu.org/onlinedocs/, links to following libstdc++ > documents are inaccessible: > > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/manual/spine.html > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual-single.xml.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.html.tar.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/ > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.pdf.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api-single.xml.bz2 > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.html.tar.bz2 Yep, they've been like that since 4.6.1 http://gcc.gnu.org/ml/gcc/2011-06/msg00347.html
Re: Links to libstdc++ document are inaccessible.
On 28 October 2011 08:04, Jonathan Wakely wrote: > On 28 October 2011 01:57, sxzzsf wrote: >> Hi, >> >> On the page of http://gcc.gnu.org/onlinedocs/, links to following libstdc++ >> documents are inaccessible: >> >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/manual/spine.html >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz2 >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual-single.xml.bz2 >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.html.tar.bz2 >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/ >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.pdf.bz2 >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api-single.xml.bz2 >> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.html.tar.bz2 > > Yep, they've been like that since 4.6.1 > http://gcc.gnu.org/ml/gcc/2011-06/msg00347.html I created http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50894 As I point out there, you can replace "4.6.2" with "4.6.0" to get slightly older versions of the libstdc++ docs - I don't think there are changes since 4.6.0 anyway.
PR c++/39480 not really fixed
g++.dg/init/copy7.C makes sure that memcpy() is not emitted with src and dst equal. The fix installed absolutely relies upon a backend implementing the movmem pattern, and essentially that such a pattern will always succeed to emit for arbitrary circumstances. However 1) not all platforms implement the pattern, it is not required, therefore it cannot be relied upon for correct code generation and 2) even those that implement this pattern have certain restrictions which could legitimately be triggered and thus cause the memcpy() with src and dst equal to still be emitted. Sparc is currently failing this testcase for reason #1, but it would be trivial to make minor modifications to the copy7.C test case to get it to fail on a score of several targets as well (even those that provide a movmem pattern). So we should either install a more complete fix or open the bug back up.
Re: PR c++/39480 not really fixed
On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote: > > g++.dg/init/copy7.C makes sure that memcpy() is not emitted with > src and dst equal. The testcase is bogus and should be removed. See the patch I posted (and the PR). Unfortunately the patch didn't get any review yet. > The fix installed absolutely relies upon a backend implementing > the movmem pattern, and essentially that such a pattern will > always succeed to emit for arbitrary circumstances. No, it doesn't. And you can trigger similar C testcases to fail on x86_64 as well. > However 1) not all platforms implement the pattern, it is not > required, therefore it cannot be relied upon for correct code > generation and 2) even those that implement this pattern have certain > restrictions which could legitimately be triggered and thus cause the > memcpy() with src and dst equal to still be emitted. > > Sparc is currently failing this testcase for reason #1, but it would > be trivial to make minor modifications to the copy7.C test case to get > it to fail on a score of several targets as well (even those that > provide a movmem pattern). > > So we should either install a more complete fix or open the bug back > up. We should remove the testcase. Richard.
Re: PR c++/39480 not really fixed
From: Richard Guenther Date: Fri, 28 Oct 2011 11:27:25 +0200 > On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote: >> >> g++.dg/init/copy7.C makes sure that memcpy() is not emitted with >> src and dst equal. > > The testcase is bogus and should be removed. See the patch I posted > (and the PR). Unfortunately the patch didn't get any review yet. Thanks. Which patch and PR are you talking about, 39480? Meanwhile, if the conclusion is that memcpy(x, x, ...) is legal, I disagree. I can think of implementations where this will break. For example, if the memcpy implementation does a cache initializing store on the first cache line of the destination before fetching the beginning of the source, such memcpy() calls with src==dst will produce garbage.
Re: PR c++/39480 not really fixed
On Fri, Oct 28, 2011 at 12:21 PM, David Miller wrote: > From: Richard Guenther > Date: Fri, 28 Oct 2011 11:27:25 +0200 > >> On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote: >>> >>> g++.dg/init/copy7.C makes sure that memcpy() is not emitted with >>> src and dst equal. >> >> The testcase is bogus and should be removed. See the patch I posted >> (and the PR). Unfortunately the patch didn't get any review yet. > > Thanks. Which patch and PR are you talking about, 39480? PR50079, the patch simply deletes the testcase. > Meanwhile, if the conclusion is that memcpy(x, x, ...) is legal, I > disagree. I can think of implementations where this will break. Then we have to fix the middle-end which will happily expand block-moves to memcpy with exact overlap (a = a is valid in C). See the PR and the C testcases therein. Just trying to avoid this in the C++ frontend is bogus. > For example, if the memcpy implementation does a cache initializing > store on the first cache line of the destination before fetching the > beginning of the source, such memcpy() calls with src==dst will > produce garbage. Of course, as Linus would say, such implementation would be "broken" ;) (I expect that such implementations can (and would) easily avoid the situation with almost no cost by doing an early out for src == dst). Richard.
Re: PR c++/39480 not really fixed
From: Richard Guenther Date: Fri, 28 Oct 2011 12:47:30 +0200 > Then we have to fix the middle-end which will happily expand > block-moves to memcpy with exact overlap (a = a is valid in C). > See the PR and the C testcases therein. > > Just trying to avoid this in the C++ frontend is bogus. Agreed. > Of course, as Linus would say, such implementation would be "broken" ;) > (I expect that such implementations can (and would) easily avoid the situation > with almost no cost by doing an early out for src == dst). memcpy is not required to be mindful of overlapping buffers. Otherwise there is no point in having seperate memmove() and memcpy() interfaces in the first place. Even internally inside of GCC there is confusion about the movmem patterns. The documentation explicitly states that movmem need not give special consideration to the posibility that source and destination might overlap. But the comments about the expander in the MIPS backend mention that they might overlap. And reality shows that the middle-end will end up expanding such overlapping cases.
Re: PR c++/39480 not really fixed
On Fri, Oct 28, 2011 at 12:54 PM, David Miller wrote: > From: Richard Guenther > Date: Fri, 28 Oct 2011 12:47:30 +0200 > >> Then we have to fix the middle-end which will happily expand >> block-moves to memcpy with exact overlap (a = a is valid in C). >> See the PR and the C testcases therein. >> >> Just trying to avoid this in the C++ frontend is bogus. > > Agreed. > >> Of course, as Linus would say, such implementation would be "broken" ;) >> (I expect that such implementations can (and would) easily avoid the >> situation >> with almost no cost by doing an early out for src == dst). > > memcpy is not required to be mindful of overlapping buffers. > > Otherwise there is no point in having seperate memmove() and memcpy() > interfaces in the first place. Sure - we are only talking about _exact_ overlap (src == dst), not partial overlap. GCC at the moment requires the memcpy implementation to handle src == dest fine (and it will never emit a memcpy call for valid C source for partially overlapping src and dst). > Even internally inside of GCC there is confusion about the movmem > patterns. The documentation explicitly states that movmem need not > give special consideration to the posibility that source and > destination might overlap. > > But the comments about the expander in the MIPS backend mention that > they might overlap. > > And reality shows that the middle-end will end up expanding such > overlapping cases. Only with exact overlap. Richard.
Re: Float point issue
On 10/28/2011 12:35 AM, Zoltán Kócsi wrote: On Thu, 27 Oct 2011 23:31:14 -0400 Robert Dewar wrote: - I am missing a gcc flag probably you should avoid extra precision and all the issues it brings, as well as speed up your program, by using SSE 64-bit arithmetic (using the appropriate gcc flags) Indeed. -mpc64 fixes the issue and proper 53-bit rounding is applied. Thanks a lot. If you are going to set 64-bit mode, you might as well specify SSE artihmetic, it will be significantly faster for most applications. Zoltan
approaches to carry-flag modelling in RTL
I'm rewriting a back-end originally based on AVR to eliminate insns for multi-word operations (output templates like "add\;addc") and to use MODE_CC instead of an unusual attribute-based approach. The motivation is that I've mostly found gcc does a better job than the existing back-end if it's shown what's actually going on. Part of this update requires correctly modelling the carry flag, for plus/minus and for rotate through carry. As noted in recent email here, preserving the correct instruction order when expanding multi-word expressions requires a set/use relation between the word-mode insns rather than a simple clobber/use relation. I've found several examples where back-ends model the carry in RTL. Sparc does: (plus:SI (plus:SI (match_operand:SI 1 "arith_operand" "%r") (match_operand:SI 2 "arith_operand" "rI")) (ltu:SI (reg:CC_NOOV 100) (const_int 0] RX does: (plus:SI (plus:SI (ltu:SI (reg:CC CC_REG) (const_int 0)) (match_operand:SI 1 "register_operand" "%0,0,0,0,0,0")) (match_operand:SI 2 "rx_source_operand" "r,Sint08,Sint16,Sint24,i,Q"))) stormy16 does: (plus:HI (plus:HI (match_operand:HI 1 "register_operand" "%0,0,0") (zero_extend:HI (reg:BI CARRY_REG))) (match_operand:HI 2 "xs_hi_nonmemory_operand" "L,Ir,i"))) The variation points are: (a) where the carry operand appears in the plus expressions; (b) whether it's expressed as an ltu zero comparison or a zero_extend. I'm inclined to follow sparc's lead, but is one or another of the choices more likely to help combine/reload/etc do a better job? Thanks. Peter
Re: scalar vector shift expansion problem on 64-bit
On 10/27/2011 10:05 PM, David Miller wrote: > > I'm getting an ICE on 64-bit sparc for some vector test cases but > I'm not sure where the fix belongs. > > When the compiler expands a vecor shift by scalar into a vector > shift by a vector it uses expand_vector_broadcast(), which has > a comment which states... I think this is the same problem as Jakub is attacking here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02503.html It's been approved, but I believe .cz has a bank holiday today. If that patch doesn't solve your problem, lemme know and I'll have another look at it. r~
Re: scalar vector shift expansion problem on 64-bit
On Fri, Oct 28, 2011 at 09:07:31AM -0700, Richard Henderson wrote: > I think this is the same problem as Jakub is attacking here: > > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02503.html It has been checked in already. But my patch only deals with the vector << vector case, vector << scalar (including vector << scalar implemented using vector << vector) supposedly still needs fold_const somewhere if the type sizes disagree. Jakub
Re: approaches to carry-flag modelling in RTL
On 10/28/2011 06:49 AM, Peter Bigot wrote: > I'm inclined to follow sparc's lead, but is one or another of the choices > more likely to help combine/reload/etc do a better job? I don't know. In the case of RX, we don't model CC_REG until after reload, so combine really doesn't get a shot at it. Be careful here. If you explicitly model the carry flag before reload, you need to have an ADD instruction that can avoid any flags modification. Reload needs to generate such instructions in some cases, and needs to be able to insert them between any two arbitrary insns. If you're like sparc (separate add, addcc insns), or i386 (separate add, lea insns), then you're fine. If you're like m68k or RX and have only an add that clobbers the flags, then you'll have to delay splitting flags-using patterns until after reload is complete. r~
gcc-4.6-20111028 is now available
Snapshot gcc-4.6-20111028 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20111028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 180634 You'll find: gcc-4.6-20111028.tar.bz2 Complete GCC MD5=38ccc5e0396851c5540b68c30fa25cc5 SHA1=ce59049cb3aa82594ee8f3f860e7230774d3a5a7 Diffs from 4.6-20111021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
