[Bug rtl-optimization/44374] New: Hoist same instructions in different branches
Compile the attached test case with options -march=armv7-a -mthumb -Os,
this code snippet
if (native)
dlmalloc_walk_heap(heap_chunk_callback, (void *)&ctx);
else
dvmHeapSourceWalk(heap_chunk_callback, (void *)&ctx);
is compiled to:
cbz r5, .L2
ldr r0, .L4// A
mov r1, sp // B
bl dlmalloc_walk_heap
b .L1
.L2:
ldr r0, .L4// C
mov r1, sp // D
bl dvmHeapSourceWalk
.L1:
add sp, sp, #44
pop {r4, r5, pc}
.L5:
.align 2
.L4:
.word heap_chunk_callback
Note that instructions AB are equal to instructions CD, if we move the previous
conditional branch after B, then CD can be removed.
Option -O2 and target arm have the same problem.
Which pass should do this optimization? pass_rtl_hoist?
--
Summary: Hoist same instructions in different branches
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
[Bug rtl-optimization/44374] Hoist same instructions in different branches
--- Comment #1 from carrot at google dot com 2010-06-02 08:20 --- Created an attachment (id=20805) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20805&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
[Bug rtl-optimization/44013] VTA produces wrong code
--- Comment #9 from hariharans at picochip dot com 2010-06-02 08:41 --- Thanks Alexandre. I can confirm that this patch works for this testcase. Cheers Hari -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44013
[Bug rtl-optimization/44374] Hoist same instructions in different branches
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 08:54 --- HOIST should do this. You will have to check in the RTL dumps that the code is exposed properly to this optimization. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-02 08:54:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #32 from dominiq at lps dot ens dot fr 2010-06-02 08:59 --- > 4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on > trunk yesterday, with r159979) in which several t-make fragments are included > twice on x86_64-*-darwin*. > I wonder if this could be the origin of the problem? I just had a libgomp bootstrap comparison failure with 4.6 trunk at revision 160142. So it is not fixed by r159979. Too bad!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug middle-end/44373] [4.6 regression] FAIL: gcc.dg/array-init-1.c
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 09:02 ---
Alright, this hunk is apparently necessary, although I don't see how. Oh well.
I'll put it back.
Index: gimplify.c
===
--- gimplify.c (revision 160142)
+++ gimplify.c (working copy)
@@ -7598,6 +7598,10 @@ gimplify_body (tree *body_p, tree fndecl, bool do_
timevar_push (TV_TREE_GIMPLIFY);
+ /* Initialize for optimize_insn_for_s{ize,peed}_p possibly called during
+ gimplification. */
+ default_rtl_profile ();
+
gcc_assert (gimplify_ctxp == NULL);
push_gimplify_context (&gctx);
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-06-02 09:02:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44373
[Bug middle-end/44373] [4.6 regression] FAIL: gcc.dg/array-init-1.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-06-02 09:13 --- http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00056.html -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44373
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #33 from iains at gcc dot gnu dot org 2010-06-02 09:24 ---
(In reply to comment #32)
> > 4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
> > trunk yesterday, with r159979) in which several t-make fragments are
> > included
> > twice on x86_64-*-darwin*.
> > I wonder if this could be the origin of the problem?
>
> I just had a libgomp bootstrap comparison failure with 4.6 trunk at revision
> 160142. So it is not fixed by r159979. Too bad!-(
can you do me a favor?
(a) copy the config.{log,out} files.
(b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
.. I suspect a configure race condition - and would not be surprised if the
second attempt works...
(it's essential to re-do the configure - not just to re-try the bootstrap).
(c) if it works we can compare the config files and try and figure out where
the race is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #34 from dominiq at lps dot ens dot fr 2010-06-02 09:35 ---
> can you do me a favor?
> (a) copy the config.{log,out} files.
> (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> .. I suspect a configure race condition - and would not be surprised if the
> second attempt works...
> (it's essential to re-do the configure - not just to re-try the bootstrap).
> (c) if it works we can compare the config files and try and figure out where
> the race is.
I am not sure to understand what you ask me to do in (b):
rm -r what?
should I run 'reconfigure' in the building directory?
Although I did not check that the failure is always due to the failing test
spotted in comment #13, I am pretty confident that it is the case. A quick
diagnostic is given in comment #3 of pr44304. I have seen the infamous
"gcc_cv_have_tls=no" randomly at stage 2 or 3 and in libgomp or i386/libgomp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #35 from iains at gcc dot gnu dot org 2010-06-02 09:44 ---
(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
>
> I am not sure to understand what you ask me to do in (b):
>
> rm -r what?
>
> should I run 'reconfigure' in the building directory?
>
> Although I did not check that the failure is always due to the failing test
> spotted in comment #13, I am pretty confident that it is the case. A quick
> diagnostic is given in comment #3 of pr44304. I have seen the infamous
> "gcc_cv_have_tls=no" randomly at stage 2 or 3 and in libgomp or i386/libgomp.
>
(In reply to comment #34)
> > can you do me a favor?
> > (a) copy the config.{log,out} files.
> > (b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
> > .. I suspect a configure race condition - and would not be surprised if the
> > second attempt works...
> > (it's essential to re-do the configure - not just to re-try the bootstrap).
> > (c) if it works we can compare the config files and try and figure out where
> > the race is.
>
> I am not sure to understand what you ask me to do in (b):
>
> rm -r what?
your failed build.
> should I run 'reconfigure' in the building directory?
do a clean configure & bootstrap without updating the source tree.
If it is a marginal race condition, it is likely to succeed.
I guess the other proof is a non-j bootstrap (but that takes longer to
prove).
I agree the tls variable is the likely culprit - perhaps there is a missing
dependency on building libgomp. I think that introduction of libgomp into all
stages is recent-ish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #36 from dominiq at lps dot ens dot fr 2010-06-02 09:53 --- Since I had a new comparison failure before your answer, I did the following: (1) delete the various libgomp folders, (2) resume make. Indeed the new libgomp were correctly built and I am now building libgfortran. As hinted in some of my previous post, I have the filling that the failures in detecting gcc_cv_have_tls are related to the load of my macbook, in particular what kind of web sites I am browsing at that time (java applets or flash?!-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #37 from iains at gcc dot gnu dot org 2010-06-02 10:06 --- (In reply to comment #36) > Since I had a new comparison failure before your answer, I did the following: yes, re-running bootstrap will make no difference if the race is in the configure... > (1) delete the various libgomp folders, OK. that forces libgomp config to run again... note that if the race is vs. libgcc_s (which is needed for emutls) then that is guaranteed to work. I'm guessing a libgcc_s/libgomp race is the origin since w/out the newly-built libgcc_s - the system one would be found - and that doesn't have emutls. > (2) resume make. make -jN all or make -jn bootstrap? (I guess there should be no difference - IIRC all->bootstrap if bootstrap is configured ) > Indeed the new libgomp were correctly built and I am now building libgfortran. > > As hinted in some of my previous post, I have the filling that the failures in > detecting gcc_cv_have_tls are related to the load of my macbook, in particular > what kind of web sites I am browsing at that time (java applets or flash?!-). well, I guess any load variation could cause it if there's a race .. ;) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #38 from dominiq at lps dot ens dot fr 2010-06-02 10:16 --- > make -jN all > or make -jn bootstrap? make -j2 >>& log_file & -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug tree-optimization/44372] [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44372
[Bug middle-end/44370] [4.6 Regression] Revision 160111 caused many test failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 10:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44370
[Bug debug/44375] New: goto_locus lost at -O0 during cfg cleanup
As mentioned in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html for -O0 we sometimes, e.g. for return without value or for C++ NRV optimized return don't emit any insns with the location of the return stmt, which results in worse debug experience. -- Summary: goto_locus lost at -O0 during cfg cleanup Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-02 10:36 --- Created an attachment (id=20806) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20806&action=view) gcc46-pr44375.patch One possible fix. Another is to insert GIMPLE_NOP with the location and handle it during expansion (for -O0 of course). -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug c/44376] New: optimiser destroys possibility of detecting overflow
optimiser generates SSE instructions that add 32 bit quantities when the field being referenced is actually 21 bits wide. This disables the possibility of testing the overflow of the additions. -- Summary: optimiser destroys possibility of detecting overflow Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoff at dyalog dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44376
[Bug c/44376] optimiser destroys possibility of detecting overflow
--- Comment #1 from geoff at dyalog dot com 2010-06-02 11:09 --- Created an attachment (id=20807) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20807&action=view) example code to demonstrate bug extract code using "cpio -i http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44376
[Bug tree-optimization/44376] optimiser destroys possibility of detecting overflow
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 11:17 --- Please specify the GCC version you see this bug. I think it has been fixed with GCC 4.5.0. gcc-4.4 -o t main.c slave.c -O3 > ./t overflow assigning 12524191771 total returned = 27 gcc-4.5 -o t main.c slave.c -O3 > ./t total returned = 27 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44376
[Bug tree-optimization/44377] New: ICE: gimple check: expected gimple_return(error_mark), have gimple_call() in gimple_return_retval, at gimple.h:4311 with -fipa-pta
Command line:
$ gcc -O1 -fipa-pta testcase.c
- testcase.c -
int foo ()
{
__builtin_return (foo);
}
--
Tested revisions:
r160122 - crash
r159696 - OK
Compiler output:
$ gcc -O1 -fipa-pta testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: gimple check: expected
gimple_return(error_mark), have gimple_call() in gimple_return_retval, at
gimple.h:4311
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ICE: gimple check: expected gimple_return(error_mark),
have gimple_call() in gimple_return_retval, at
gimple.h:4311 with -fipa-pta
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44377
[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-02 11:33 --- Created an attachment (id=20808) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20808&action=view) gcc46-pr44375.patch Alternative patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug tree-optimization/44376] optimiser destroys possibility of detecting overflow
--- Comment #3 from geoff at dyalog dot com 2010-06-02 11:36 --- Subject: Re: optimiser destroys possibility of detecting overflow On 02/06/10 12:17, rguenth at gcc dot gnu dot org wrote: > --- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 11:17 > --- > Please specify the GCC version you see this bug. I think it has been fixed > with GCC 4.5.0. > > gcc-4.4 -o t main.c slave.c -O3 >> ./t > overflow assigning 12524191771 > total returned = 27 > > gcc-4.5 -o t main.c slave.c -O3 >> ./t > total returned = 27 > > Yes I am using 4.4.3. Thankyou for the stunning response. Geoff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44376
[Bug tree-optimization/44377] ICE: gimple check: expected gimple_return(error_mark), have gimple_call() in gimple_return_retval, at gimple.h:4311 with -fipa-pta
--- Comment #1 from zsojka at seznam dot cz 2010-06-02 12:18 ---
The testcase was reduced from gcc.dg/torture/stackalign/builtin-return-1.c,
which is valid. It can be further reduced to:
void foo () { __builtin_return (0); }
In general, it seems any use of __builtin_return() with -fipa-pta ICEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44377
[Bug tree-optimization/44377] ICE: gimple check: expected gimple_return(error_mark), have gimple_call() in gimple_return_retval, at gimple.h:4311 with -fipa-pta
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 12:20 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-02 12:20:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44377
[Bug tree-optimization/44377] ICE: gimple check: expected gimple_return(error_mark), have gimple_call() in gimple_return_retval, at gimple.h:4311 with -fipa-pta
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-02 12:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44377
[Bug tree-optimization/44377] ICE: gimple check: expected gimple_return(error_mark), have gimple_call() in gimple_return_retval, at gimple.h:4311 with -fipa-pta
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-02 12:27 --- Subject: Bug 44377 Author: rguenth Date: Wed Jun 2 12:27:24 2010 New Revision: 160152 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160152 Log: 2010-06-02 Richard Guenther PR tree-optimization/44377 * tree-ssa-structalias.c (find_func_aliases): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44377
[Bug lto/44378] New: lto1: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1168
Trying to crosscompile Qt to arm with LTO results in a linker error while linking QtCore: armv6j-blankpage-linux-gnueabi-g++ -O2 -mcpu=arm1136jf-s -fomit-frame-pointer -fweb -frename-registers -Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu -g -fwhopr -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -fno-exceptions -Wl,--no-undefined -Wl,-O1 -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,/usr/src/ark/BUILD/qt/src/corelib/QtCore.dynlist -Wl,-soname,libQtCore.so.4 -o libQtCore.so.4.7.0 .obj/release-shared-emb-armv6/qabstractanimation.o .obj/release-shared-emb-armv6/qvariantanimation.o .obj/release-shared-emb-armv6/qpropertyanimation.o .obj/release-shared-emb-armv6/qanimationgroup.o .obj/release-shared-emb-armv6/qsequentialanimationgroup.o .obj/release-shared-emb-armv6/qparallelanimationgroup.o .obj/release-shared-emb-armv6/qpauseanimation.o .obj/release-shared-emb-armv6/qfuture.o .obj/release-shared-emb-armv6/qfutureinterface.o .obj/release-shared-emb-armv6/qfuturesynchronizer.o .obj/release-shared-emb-armv6/qfuturewatcher.o .obj/release-shared-emb-armv6/qrunnable.o .obj/release-shared-emb-armv6/qtconcurrentfilter.o .obj/release-shared-emb-armv6/qtconcurrentmap.o .obj/release-shared-emb-armv6/qtconcurrentresultstore.o .obj/release-shared-emb-armv6/qtconcurrentthreadengine.o .obj/release-shared-emb-armv6/qtconcurrentiteratekernel.o .obj/release-shared-emb-armv6/qtconcurrentexception.o .obj/release-shared-emb-armv6/qthreadpool.o .obj/release-shared-emb-armv6/qglobal.o .obj/release-shared-emb-armv6/qlibraryinfo.o .obj/release-shared-emb-armv6/qmalloc.o .obj/release-shared-emb-armv6/qnumeric.o .obj/release-shared-emb-armv6/qatomic.o .obj/release-shared-emb-armv6/qmutex.o .obj/release-shared-emb-armv6/qreadwritelock.o .obj/release-shared-emb-armv6/qmutexpool.o .obj/release-shared-emb-armv6/qsemaphore.o .obj/release-shared-emb-armv6/qthread.o .obj/release-shared-emb-armv6/qthreadstorage.o .obj/release-shared-emb-armv6/qmutex_unix.o .obj/release-shared-emb-armv6/qthread_unix.o .obj/release-shared-emb-armv6/qwaitcondition_unix.o .obj/release-shared-emb-armv6/qbitarray.o .obj/release-shared-emb-armv6/qbytearray.o .obj/release-shared-emb-armv6/qbytearraymatcher.o .obj/release-shared-emb-armv6/qcryptographichash.o .obj/release-shared-emb-armv6/qdatetime.o .obj/release-shared-emb-armv6/qeasingcurve.o .obj/release-shared-emb-armv6/qelapsedtimer.o .obj/release-shared-emb-armv6/qhash.o .obj/release-shared-emb-armv6/qline.o .obj/release-shared-emb-armv6/qlinkedlist.o .obj/release-shared-emb-armv6/qlist.o .obj/release-shared-emb-armv6/qlocale.o .obj/release-shared-emb-armv6/qpoint.o .obj/release-shared-emb-armv6/qmap.o .obj/release-shared-emb-armv6/qmargins.o .obj/release-shared-emb-armv6/qcontiguouscache.o .obj/release-shared-emb-armv6/qrect.o .obj/release-shared-emb-armv6/qregexp.o .obj/release-shared-emb-armv6/qshareddata.o .obj/release-shared-emb-armv6/qsharedpointer.o .obj/release-shared-emb-armv6/qsimd.o .obj/release-shared-emb-armv6/qsize.o .obj/release-shared-emb-armv6/qstring.o .obj/release-shared-emb-armv6/qstringbuilder.o .obj/release-shared-emb-armv6/qstringlist.o .obj/release-shared-emb-armv6/qtextboundaryfinder.o .obj/release-shared-emb-armv6/qtimeline.o .obj/release-shared-emb-armv6/qvector.o .obj/release-shared-emb-armv6/qvsnprintf.o .obj/release-shared-emb-armv6/qelapsedtimer_unix.o .obj/release-shared-emb-armv6/harfbuzz-buffer.o .obj/release-shared-emb-armv6/harfbuzz-gdef.o .obj/release-shared-emb-armv6/harfbuzz-gsub.o .obj/release-shared-emb-armv6/harfbuzz-gpos.o .obj/release-shared-emb-armv6/harfbuzz-impl.o .obj/release-shared-emb-armv6/harfbuzz-open.o .obj/release-shared-emb-armv6/harfbuzz-stream.o .obj/release-shared-emb-armv6/harfbuzz-shaper-all.o .obj/release-shared-emb-armv6/qharfbuzz.o .obj/release-shared-emb-armv6/qabstractfileengine.o .obj/release-shared-emb-armv6/qbuffer.o .obj/release-shared-emb-armv6/qdatastream.o .obj/release-shared-emb-armv6/qdataurl.o .obj/release-shared-emb-armv6/qdebug.o .obj/release-shared-emb-armv6/qdir.o .obj/release-shared-emb-armv6/qdiriterator.o .obj/release-shared-emb-armv6/qfile.o .obj/release-shared-emb-armv6/qfileinfo.o .obj/release-shared-emb-armv6/qiodevice.o .obj/release-shared-emb-armv6/qnoncontiguousbytedevice.o .obj/release-shared-emb-armv6/qprocess.o .obj/release-shared-emb-armv6/qtextstream.o .obj/release-shared-emb-armv6/qtemporaryfile.o .obj/release-shared-emb-armv6/qresource.o .obj/release-shared-emb-armv6/qresource_iterator.o .obj/release-shared-emb-armv6/qurl.o .obj/release-shared-emb-armv6/qsettings.o .obj/release-shared-emb-armv6/qfsfileengine.o .obj/release-shared-emb-armv6/qfsfileengine_iterator.o .obj/release-shared-emb-armv6/qfilesystemwatcher.o .obj/release-shared-emb-armv6/qfsfileengine_unix.o .obj/release-shared-emb-armv6/qfsfileengine_iterator_unix.o .obj/release-shared-emb-armv6/qprocess_unix.o .obj/release-shared-emb-armv6/qfilesystemwatcher_inotify.o .obj/release-shared-emb-armv6/qfilesystemwatcher_dnotify.o .obj/releas
[Bug lto/44378] lto1: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1168
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-02 12:59 --- Do not use -fwhopr with gcc 4.5, it's broken. Please try recent trunk or -flto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44378
Re: [Bug debug/44375] New: goto_locus lost at -O0 during cfg cleanup
I think this is a dup of a much older bug. Sent from my iPhone On Jun 2, 2010, at 3:30 AM, "jakub at gcc dot gnu dot org" > wrote: As mentioned in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html for -O0 we sometimes, e.g. for return without value or for C++ NRV optimized return don't emit any insns with the location of the return stmt, which results in worse debug experience. -- Summary: goto_locus lost at -O0 during cfg cleanup Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup
--- Comment #3 from pinskia at gmail dot com 2010-06-02 13:33 --- Subject: Re: New: goto_locus lost at -O0 during cfg cleanup I think this is a dup of a much older bug. Sent from my iPhone On Jun 2, 2010, at 3:30 AM, "jakub at gcc dot gnu dot org" wrote: > As mentioned in > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html > for -O0 we sometimes, e.g. for return without value or for C++ NRV > optimized > return don't emit any insns with the location of the return stmt, > which results > in worse debug experience. > > > -- > Summary: goto_locus lost at -O0 during cfg cleanup > Product: gcc > Version: 4.6.0 >Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: debug >AssignedTo: unassigned at gcc dot gnu dot org >ReportedBy: jakub at gcc dot gnu dot org > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug bootstrap/44379] New: [4.6 regression] Failed to bootstrap
On Linux/ia64, revision 160132 gave /export/gnu/import/svn/gcc-test/bld/gcc/../../src-trunk/gcc/tree-sra.c:2033: undefined reference to `MOVE_RATIO' libbackend.a(tree-inline.o): In function `estimate_move_cost': /export/gnu/import/svn/gcc-test/bld/gcc/../../src-trunk/gcc/tree-inline.c:3168: undefined reference to `MOVE_RATIO' collect2: ld returned 1 exit status make[6]: *** [cc1-dummy] Error 1 Revision 160116 is OK. -- Summary: [4.6 regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44379
[Bug bootstrap/44379] [4.6 regression] Failed to bootstrap
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-02 14:36 --- It is caused by revision 160125: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00037.html expr.h:/* If a memory-to-memory move would take MOVE_RATIO or more simple expr.h:#ifndef MOVE_RATIO expr.h:#define MOVE_RATIO(speed) 2 expr.h:#define MOVE_RATIO(speed) ((speed) ? 15 : 3) expr.h:#define SET_RATIO(speed) MOVE_RATIO(speed) [...@gnu-12 gcc]$ grep MOVE_RATIO *.c expr.c: < (unsigned int) MOVE_RATIO (optimize_insn_for_speed_p ())) expr.c: < (unsigned int) MOVE_RATIO (optimize_insn_for_speed_p ())) tree-inline.c: if (size < 0 || size > MOVE_MAX_PIECES * MOVE_RATIO (!optimize_size)) tree-sra.c:* MOVE_RATIO (optimize_function_for_speed_p (cfun)); [...@gnu-12 gcc]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44379
[Bug c++/44380] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44381] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44381
[Bug middle-end/44382] New: Slow integer multiply
For
---
extern int a, b, c, d, e, f;
void
foo ()
{
a = f * b * c * d;
}
---
on Linux/x86-64, gcc generates:
movlb(%rip), %eax
imull f(%rip), %eax
imull c(%rip), %eax
imull d(%rip), %eax
movl%eax, a(%rip)
ret
Icc generates:
movl c(%rip), %eax #6.15
movl f(%rip), %edx #6.7
imull d(%rip), %eax #6.19
imull b(%rip), %edx #6.11
imull %eax, %edx#6.15
movl %edx, a(%rip) #6.3
ret #7.1
Icc version is faster since 2 multiplications may
be issued at the same time.
--
Summary: Slow integer multiply
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c++/44383] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44383
[Bug c/44384] New: builtin_object_size_ treatment of multidimensional arrays is unexpected
Instead of treating each dimension of the array as a separate subobject, BOSC treats them all as a single subobject which results in unexpected size calculations. For example, the below code compiled with '-O2' in gcc 4.5.0 gives the following results with expect results listed after. char c[10][20]; __builtin_object_size(c, 3);/* returns 200, expected 200*/ __builtin_object_size(c[0], 3); /* returns 200, expected 20 */ __builtin_object_size(c[1], 3); /* returns 180, expected 20 */ __builtin_object_size(c[2], 3); /* returns 160, expected 20 */ __builtin_object_size(c[8], 3); /* returns 40, expected 20 */ __builtin_object_size(c[9], 3); /* returns 20, expected 20 */ -- Summary: builtin_object_size_ treatment of multidimensional arrays is unexpected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meklund at cisco dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384
[Bug lto/44385] New: ld: ../../lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed.
Trying to build Qt with -flto and -fuse-linker-plugin, using -fwhole-program for the helper apps results in g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2 -fomit-frame-pointer -fweb -frename-registers -Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu -g -flto -fuse-linker-plugin -Wl,-rpath,/usr/lib64/qt4-embedded/lib -Wl,-rpath,/usr/lib64/qt4-embedded/lib -flto -fwhole-program -fuse-linker-plugin -o ../../../bin/moc release-static/moc.o release-static/preprocessor.o release-static/generator.o release-static/parser.o release-static/token.o release-static/main.o -L/usr/src/ark/BUILD/qt/src/tools/bootstrap -lbootstrap -lz collect2: ld terminated with signal 6 [Aborted] ld: ../../lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed. Removing -fuse-linker-plugin "solves" the problem. gcc 4.5.0, gold from binutils 2.20.51.0.9 -- Summary: ld: ../../lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44385
[Bug middle-end/44382] Slow integer multiply
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-02 15:15 --- Because our tree reassoc doesn't re-associate them. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-06-02 15:15:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c/44386] New: builtin_object_size_ assumes a flexible array for a long array in a structure of known length
When the last element of a structure is an array, builtin_object_size__ always
assumes it is a flexible array no matter the length. For example, the below
code compiled with '-O2' in 4.5.0 gives an unexpected length in 'a', 'b', 'd',
and 'f'. At a minimum, it is expected that 'a' and 'd' should return 40 since
'e' is returning 40. It is debatable if 'b' and 'f' should return 40 or the
remaining size of the malloced memory.
#include
struct bar0 {
char c[40];
};
struct bar1 {
char c[40];
char d[40];
};
struct bar *bp;
int main()
{
struct bar0 *b0;
struct bar0 *b0m = malloc(200);
struct bar1 *b1;
struct bar1 *b1m = malloc(200);
printf("%ld\n", __builtin_object_size(b0->c, 3)); // a. Returned 0,
expected 40
printf("%ld\n", __builtin_object_size(b0m->c, 3)); // b. Returned 200,
expected 40 or 200
printf("%ld\n", __builtin_object_size(b1->c, 3)); // c. Returned 40,
expected 40
printf("%ld\n", __builtin_object_size(b1->d, 3)); // d. Returned 0,
expected 40
printf("%ld\n", __builtin_object_size(b1m->c, 3)); // e. Returned 40,
expected 40
printf("%ld\n", __builtin_object_size(b1m->d, 3)); // f. Returned 160,
expected 40 or 160
return 0;
}
--
Summary: builtin_object_size_ assumes a flexible array for a long
array in a structure of known length
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meklund at cisco dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44386
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-02 15:17 --- Works fine with 4_5-branch and mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.0 4.6.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug bootstrap/44379] [4.6 regression] Failed to bootstrap
--- Comment #2 from steven at gcc dot gnu dot org 2010-06-02 15:18 --- Obviously mine. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-02 15:18:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44379
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 15:18 --- *** Bug 44383 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44383] [C++0x]: result_of broken for functor references.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-02 15:18 --- *** This bug has been marked as a duplicate of 44380 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44383
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-02 15:19 --- *** Bug 44381 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44381] [C++0x]: result_of broken for functor references.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-02 15:19 --- *** This bug has been marked as a duplicate of 44380 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44381
[Bug c++/44387] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44387
[Bug lto/44385] ld: ../../lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-02 15:23 --- Subject: Bug 44385 Author: rguenth Date: Wed Jun 2 15:23:34 2010 New Revision: 160157 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160157 Log: 2010-06-02 Richard Guenther PR lto/44385 Backport from mainline 2010-05-21 Richard Guenther * lto-plugin.c (write_resolution): Do not assert syms is non-NULL. Modified: branches/gcc-4_5-branch/lto-plugin/ChangeLog branches/gcc-4_5-branch/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44385
[Bug lto/44385] ld: ../../lto-plugin/lto-plugin.c:325: write_resolution: Assertion `syms' failed.
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 15:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44385
[Bug c++/44387] [C++0x]: result_of broken for functor references.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-02 15:25 --- *** This bug has been marked as a duplicate of 44380 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44387
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-02 15:25 --- *** Bug 44387 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44388] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44388
[Bug c++/44389] New: [C++0x]: result_of broken for functor references.
The FCD (n3092) states in 20.7.6.6 (Table # 53), that result_of should work
with references to functors as well. Current implementation of result_of will
only work with functor types, not with references to functor types.
The following will produce incorrect results:
#include
struct F
{
typedef int result_type;
int operator() ();
};
std::result_of::type N1; //Will fail but shouldn't
std::result_of::type N2; //Works as expected
Build with the following compile arguments (where test.cpp is the code above):
g++ --std=c++0x -g -O2 -Wall -Wno-long-long --pedantic test.cpp
Andy.
--
Summary: [C++0x]: result_of broken for functor references.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avenikov at gmail dot com
GCC host triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
GCC target triplet: x86-64, Linux 2.6.18 (Suse 11.0), gcc 4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44389
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-02 15:29 --- *** Bug 44388 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44388] [C++0x]: result_of broken for functor references.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-02 15:29 --- *** This bug has been marked as a duplicate of 44380 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44388
[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-06-02 15:29 --- I think this is related to PR 12076. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-02 15:30 --- *** Bug 44389 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug c++/44389] [C++0x]: result_of broken for functor references.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-02 15:30 --- Hey! Stop it *** This bug has been marked as a duplicate of 44380 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44389
[Bug middle-end/44291] [4.6 regression] ICE in set_user_assembler_libfunc
--- Comment #2 from mikpe at it dot uu dot se 2010-06-02 15:33 ---
I see this error too, it's causing gcc.c-torture/execute/builtins/memops-asm.c
and gcc.dg/pr39443.c to regress on arm-linux-gnueabi due to ICEs. I didn't see
the problem in 4.6-20100515 (r159445), but do see it in 4.6-20100522 (r159746)
and current head (r160155). I'll try to bisect this.
An even simpler test case is:
extern void abort (void)
__asm__ ("foo_abort")
;
Commenting out the __asm__ bit cures the ICE.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
CC||mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #7 from avenikov at gmail dot com 2010-06-02 15:36 --- Sorry, I've just noticed that I messed up. I was clicking the "refresh" button to see the status of the bug and apparently that was creating new bug report every time. Sorry for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug middle-end/44295] [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-06-02 15:40 --- Subject: Bug 44295 Author: hubicka Date: Wed Jun 2 15:39:43 2010 New Revision: 160159 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160159 Log: PR middle-end/44295 * cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee): Do not create new cgraph node to check callee. * testsuite/g++.dg/torture/pr44295.C: Neww testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr44295.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #26 from bergner at gcc dot gnu dot org 2010-06-02 15:40 --- Subject: Bug 44199 Author: bergner Date: Wed Jun 2 15:40:09 2010 New Revision: 160160 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160160 Log: Backport from GCC 4.4: 2010-05-26 Jakub Jelinek PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): Fix up a backport glitch. Modified: branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-02 16:00 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02161.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2010- |patches/2010- |05/msg02124.html|05/msg02161.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #5 from doc0 dot delphin at voila dot fr 2010-06-02 16:07 --- Created an attachment (id=20809) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20809&action=view) Shell (bash) script to build gcc Files related to this bug : shell (bash) script, log files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug lto/44390] New: LTO strips out symbols that are actually needed
While building Qt with -flto, helper apps with an additional -fwhole-program: g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2 -fomit-frame-pointer -fweb -frename-registers -Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu -g -flto -Wl,-rpath,/usr/lib64/qt4-embedded/lib -Wl,-rpath,/usr/lib64/qt4-embedded/lib -flto -fwhole-program -o ../../../bin/uic3 .obj/release-static-emb-x86_64/customwidgetsinfo.o .obj/release-static-emb-x86_64/databaseinfo.o .obj/release-static-emb-x86_64/driver.o .obj/release-static-emb-x86_64/treewalker.o .obj/release-static-emb-x86_64/ui4.o .obj/release-static-emb-x86_64/validator.o .obj/release-static-emb-x86_64/cppextractimages.o .obj/release-static-emb-x86_64/cppwritedeclaration.o .obj/release-static-emb-x86_64/cppwriteicondata.o .obj/release-static-emb-x86_64/cppwriteicondeclaration.o .obj/release-static-emb-x86_64/cppwriteiconinitialization.o .obj/release-static-emb-x86_64/cppwriteincludes.o .obj/release-static-emb-x86_64/cppwriteinitialization.o .obj/release-static-emb-x86_64/main.o .obj/release-static-emb-x86_64/ui3reader.o .obj/release-static-emb-x86_64/parser.o .obj/release-static-emb-x86_64/domtool.o .obj/release-static-emb-x86_64/object.o .obj/release-static-emb-x86_64/subclassing.o .obj/release-static-emb-x86_64/form.o .obj/release-static-emb-x86_64/converter.o .obj/release-static-emb-x86_64/widgetinfo.o .obj/release-static-emb-x86_64/embed.o .obj/release-static-emb-x86_64/qt3to4.o .obj/release-static-emb-x86_64/deps.o .obj/release-static-emb-x86_64/uic.o -L/usr/src/ark/BUILD/qt/lib -lQt3Support -L/usr/src/ark/BUILD/qt/lib -lQtSql -lsqlite3 -lQtXml -lQtGui -lpng -lfreetype -lQtNetwork -lssl -lcrypto -lQtCore -lz -lm -ldl -lrt -lpthread /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3ReaderC2ER11QTextStreamj:ui3reader.cpp:245: error: undefined reference to '_ZN7PortingC1Ev' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader13getObjectNameERK11QDomElement:ui3reader.cpp:383: error: undefined reference to '_ZN9Ui3Reader17getObjectPropertyERK11QDomElementRK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader8generateERK7QStringS2_12QDomDocumentbbS2_S2_S2_:ui3reader.cpp:276: error: undefined reference to '_ZN9Ui3Reader13createSubDeclERK11QDomElementRK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader8generateERK7QStringS2_12QDomDocumentbbS2_S2_S2_:ui3reader.cpp:281: error: undefined reference to '_ZN9Ui3Reader14createFormDeclERK11QDomElement' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader8generateERK7QStringS2_12QDomDocumentbbS2_S2_S2_:ui3reader.cpp:273: error: undefined reference to '_ZN9Ui3Reader17createWrapperDeclERK11QDomElementRK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader8generateERK7QStringS2_12QDomDocumentbbS2_S2_S2_:ui3reader.cpp:278: error: undefined reference to '_ZN9Ui3Reader13createSubImplERK11QDomElementRK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader8generateERK7QStringS2_12QDomDocumentbbS2_S2_S2_:ui3reader.cpp:283: error: undefined reference to '_ZN9Ui3Reader14createFormImplERK11QDomElement' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN9Ui3Reader11generateUi4ERK7QStringS2_12QDomDocument:ui3reader.cpp:295: error: undefined reference to '_ZN9Ui3Reader11generateUi4ERK11QDomElement' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN3CPP19WriteInitialization15acceptActionRefEP12DomActionRef:../uic/cpp/cppwriteinitialization.cpp:1159: error: undefined reference to '_ZNK3Uic6isMenuERK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _Z7runUic3iPPc:main.cpp:300: error: undefined reference to '_ZN9Ui3Reader5embedEPKcRK11QStringList' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _Z7runUic3iPPc:main.cpp:329: error: undefined reference to '_ZN7DomTool11fixDocumentER12QDomDocument' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _Z7runUic3iPPc:main.cpp:342: error: undefined reference to '_ZN9Ui3Reader11computeDepsERK11QDomElementR11QStringListS4_b' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _Z7runUic3iPPc:main.cpp:338: error: undefined reference to '_ZN9Ui3Reader5embedEPKcRK11QStringList' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN3CPP19WriteInitialization12acceptWidgetEP9DomWidget:../uic/cpp/cppwriteinitialization.cpp:627: error: undefined reference to '_ZNK3Uic11isContainerERK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN3CPP19WriteInitialization12acceptWidgetEP9DomWidget:../uic/cpp/cppwriteinitialization.cpp:659: error: undefined reference to '_ZNK3Uic8isButtonERK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN3CPP19WriteInitialization12acceptWidgetEP9DomWidget:../uic/cpp/cppwriteinitialization.cpp:676: error: undefined reference to '_ZNK3Uic23isCustomWidgetContainerERK7QString' /usr/bin/ld: /tmp/ccegbjMZ.lto.o: in function _ZN3CPP19WriteInitialization12acceptWidgetEP9DomWidget:../uic/cpp/cppwriteinitialization.cpp:677: error: undefined reference to '_ZNK3Uic11isContainerERK7QString' collect2: l
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #6 from doc0 dot delphin at voila dot fr 2010-06-02 16:08 --- Created an attachment (id=20810) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20810&action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #7 from doc0 dot delphin at voila dot fr 2010-06-02 16:09 --- Created an attachment (id=20811) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20811&action=view) configure.log File generated by ./configure ... 2>&1 | tee configure.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #8 from doc0 dot delphin at voila dot fr 2010-06-02 16:12 --- Created an attachment (id=20812) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20812&action=view) All the files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #9 from doc0 dot delphin at voila dot fr 2010-06-02 16:15 --- (In reply to comment #1) OK Thank you very much. I have verified the prerequisites before. Please note I just send a zip files with all log files. Thanks. > first can you give the output from the failure: > i.e. which files have differences? > ...the configuration line you are using. > the output of > autoconf --version > automake --version > m4 --version > I should remind you of : > http://gcc.gnu.org/install/prerequisites.html > x86_64-apple-darwin10 will not build gcc properly with the auto* tools > installed - you must ensure that the required versions are found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #1 from bero at arklinux dot org 2010-06-02 16:20 --- uic3.tar.gz, containing the object files that should be linked and the source they're generated from, is too large to attach, so I've uploaded it to http://arklinux.org/~bero/uic3.tar.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug bootstrap/44304] Building gcc 4.5.0 under Snow Leopard : stages 2 & 3 differ
--- Comment #10 from iains at gcc dot gnu dot org 2010-06-02 16:25 --- (In reply to comment #9) > (In reply to comment #1) > OK Thank you very much. > > I have verified the prerequisites before. > Please note I just send a zip files with all log files. thanks for posting the files - see also : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170 It does look like this is the same issue. However, to confirm: Is this phenomenon deterministic - or a random occurrence depending on processor load? (as I look at your script, it would seem that you have not done a parallel build) if you remove all the libgomp directories and then re-do make - does it succeed ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44304
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-02 16:27 --- Can you try without -fwhole-program, with the tip of the 4.5 branch and with trunk? If it works on the trunk, can you identify the patch that made it work? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug middle-end/44295] [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-02 16:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug c/44386] builtin_object_size_ assumes a flexible array for a long array in a structure of known length
--- Comment #1 from meklund at cisco dot com 2010-06-02 16:33 --- I've re-run the code varying the flag from 0 to 3 (instead of hard coding to 3) with the below results. The unexpected results are still happening for 'a', 'b', 'd', and 'f'. a b c d e f 0: -1 200 -1 -1 200 160 1: -1 200 40 -1 40 160 2: 0 200 0 0 200 160 3: 0 200 40 0 40 160 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44386
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-02 16:35 --- This looks like a duplicate of pr40873. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug fortran/42900] gfortran.dg/stat_[12].f90 may fail on NFS filesystems
--- Comment #6 from ro at gcc dot gnu dot org 2010-06-02 16:35 --- Subject: Bug 42900 Author: ro Date: Wed Jun 2 16:35:15 2010 New Revision: 160161 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160161 Log: Backport from mainline: 2010-03-01 Rainer Orth PR fortran/42900 * gfortran.dg/stat_1.f90: Accept 'testfile' gid == parent dir gid. Explain this. * gfortran.dg/stat_2.f90: Likewise. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/stat_1.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/stat_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42900
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-02 16:36 --- No, this is not fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg
--- Comment #11 from spop at gcc dot gnu dot org 2010-06-02 16:39 --- Subject: Bug 44363 Author: spop Date: Wed Jun 2 16:39:26 2010 New Revision: 160163 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160163 Log: Fix PR44363: don't abort when the ifcvt analysis fails to recognize a Gimple stmt. 2010-06-02 Sebastian Pop PR middle-end/44363 * tree-if-conv.c (predicate_bbs): Do not call gcc_unreachable, return false instead. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44363
[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg
--- Comment #12 from spop at gcc dot gnu dot org 2010-06-02 16:42 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44363
[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
--- Comment #10 from ro at gcc dot gnu dot org 2010-06-02 16:50 ---
Subject: Bug 41169
Author: ro
Date: Wed Jun 2 16:49:39 2010
New Revision: 160166
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160166
Log:
Backport from mainline:
2009-09-02 Rainer Orth
PR libfortran/41169
* inclhack.def (irix_complex): New fix.
(solaris_complex): Likewise.
* fixincl.x: Regenerate.
* tests/base/complex.h [IRIX_COMPLEX_CHECK, SOLARIS_COMPLEX_CHECK]:
New tests.
2009-09-08 Ralf Wildenhues
* inclhack.def (solaris_complex): Remove superfluous backslashes from
replacement string. Replace \+ operator with \{1,\}.
Added:
branches/gcc-4_4-branch/fixincludes/tests/base/complex.h
Modified:
branches/gcc-4_4-branch/fixincludes/ChangeLog
branches/gcc-4_4-branch/fixincludes/fixincl.x
branches/gcc-4_4-branch/fixincludes/inclhack.def
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-02 16:51 --- > No, this is not fortran. I am not sure that fortran matter here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug lto/44390] LTO strips out symbols that are actually needed
--- Comment #6 from bero at arklinux dot org 2010-06-02 16:53 --- Omitting -fwhole-program doesn't change anything. Compiling 4.5 branch and trunk now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #10 from tfautre at pandora dot be 2010-06-02 16:54 ---
(In reply to comment #5)
> (In reply to comment #1)
> > I'm under the impression we should simply not provide operator __safe_bool()
>
> Agreed, there is no requirement for conversion to bool, explicit or implicit.
> Even if it can be done unambiguously, adding that non-standard conversion
> would
> encourage non-portable code. I think operator! should be removed for the same
> reason.
I disagree with that statement (the draft may have changed since your comment
was made).
In the latest C++0x draft,
Section 18.8.5: "exception_ptr shall satisfy the requirements of
NullablePointer (20.2.3)."
Section 20.2.3 (NullablePointer Requirements): "An object p of type P can be
contextually converted to bool (Clause 4). The effect shall be as if p !=
nullptr had been evaluated in place of p."
AFAIK, the following code should work but does not anymore cause of this bug
fix:
std::exception_ptr e;
if (e)
{
/* ... */
}
--
tfautre at pandora dot be changed:
What|Removed |Added
CC||tfautre at pandora dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #14 from ro at gcc dot gnu dot org 2010-06-02 16:57 --- Subject: Bug 38251 Author: ro Date: Wed Jun 2 16:57:10 2010 New Revision: 160168 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160168 Log: Backport from mainline: 2010-03-01 Rainer Orth PR libgcj/38251 * tools/Makefile.am (dist-hook): Prune .svn directories in asm and classes copies. * tools/Makefile.in: Regenerate. Revert: 2008-11-05 Andrew Haley * tools/Makefile.am (UPDATE_TOOLS_ZIP, CREATE_TOOLS_ZIP): Exclude .svn direcories. Modified: branches/gcc-4_4-branch/libjava/classpath/ChangeLog branches/gcc-4_4-branch/libjava/classpath/tools/Makefile.am branches/gcc-4_4-branch/libjava/classpath/tools/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #11 from paolo dot carlini at oracle dot com 2010-06-02 17:03 --- For sure something may have changed in the working paper, we are talking about 1 year since these changes. Jon can you have a look to this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug tree-optimization/44372] [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone
--- Comment #3 from hjl at gcc dot gnu dot org 2010-06-02 17:04 --- Subject: Bug 44372 Author: hjl Date: Wed Jun 2 17:04:13 2010 New Revision: 160169 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160169 Log: Add a testcase for PR middle-end/44372. 2010-06-02 H.J. Lu PR middle-end/44372 * g++.dg/ipa/pr44372.C: New. Added: trunk/gcc/testsuite/g++.dg/ipa/pr44372.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44372
[Bug tree-optimization/44372] [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-02 17:04 --- *** This bug has been marked as a duplicate of 44295 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44372
[Bug middle-end/44295] [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-02 17:04 --- *** Bug 44372 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #39 from rwild at gcc dot gnu dot org 2010-06-02 17:04 ---
Can you (someone with darwin) just take the configure test from comment #13,
build it, and run it under various load on your system, to see whether it
produces unstable results with a compiler from the previous stage? Thanks.
Just to be sure, this is not just about the a_in_other_thread pointer lacking a
volatile qualifier, or use of proper exclusion primitive?
Here's the source again, for reference:
#include
__thread int a;
static int *a_in_other_thread;
static void *
thread_func (void *arg)
{
a_in_other_thread = &a;
return (void *)0;
}
int
main ()
{
pthread_t thread;
void *thread_retval;
int *a_in_main_thread;
if (pthread_create (&thread, (pthread_attr_t *)0,
thread_func, (void *)0))
return 0;
a_in_main_thread = &a;
if (pthread_join (thread, &thread_retval))
return 0;
return (a_in_other_thread == a_in_main_thread);
;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug c++/44380] [C++0x]: result_of broken for functor references.
--- Comment #8 from jwakely dot gcc at gmail dot com 2010-06-02 17:09 --- gcc 4.3 was released 18 months before the FCD, at that time the specification of result_of was quite different. Also, until the gcc 4.5.0 release std::result_of was based on the tr1::result_of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44380
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #40 from dominiq at lps dot ens dot fr 2010-06-02 17:09 --- > Can you (someone with darwin) ... I have tried: [macbook] f90/bug% gcc46 pthread_create.c [macbook] f90/bug% a.out ; echo $? 0 Is it the correct way to do the test? (so far I only got zeros). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug libobjc/36610] objc_msg_sendv is broken for targets which pass argument via registers
--- Comment #17 from ro at gcc dot gnu dot org 2010-06-02 17:17 --- Subject: Bug 36610 Author: ro Date: Wed Jun 2 17:16:55 2010 New Revision: 160172 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160172 Log: Backport from mainline: 2010-02-24 Rainer Orth PR libobjc/36610 * objc/execute/forward-1.x: XFAIL on alpha*-dec-osf*, 64-bit i?86-*-solaris2*, mips-sgi-irix*, sparc*-sun-solaris2* with -fgnu-runtime. Sort entries. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/objc/execute/forward-1.x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #12 from jwakely dot gcc at gmail dot com 2010-06-02 17:17 --- The NullablePointer concept is new, so yes, it's changed. I'll deal with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #13 from paolo dot carlini at oracle dot com 2010-06-02 17:18 --- Thanks a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #14 from jwakely dot gcc at gmail dot com 2010-06-02 17:26
---
(In reply to comment #10)
> AFAIK, the following code should work but does not anymore cause of this bug
> fix:
>
> std::exception_ptr e;
>
> if (e)
> {
> /* ... */
> }
I'm fairly sure that's not valid.
That relies on an implicit conversion to bool, not a contextual conversion to
bool, and 18.8.5 also says "exception_ptr shall not be implicitly convertible
to any arithmetic, enumeration, or pointer type."
This should work though:
if (bool(e))
I'll fix that and add tests to check implicit conversions don't work (I think
that requirement is also new since exception_ptr was last worked on.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug pch/14940] PCH largefile test fails on various platforms
--- Comment #39 from ro at gcc dot gnu dot org 2010-06-02 17:28 --- Subject: Bug 14940 Author: ro Date: Wed Jun 2 17:28:24 2010 New Revision: 160176 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160176 Log: Backport from mainline: 2010-03-01 Rainer Orth PR pch/14940 * config/host-solaris.c (HOST_HOOKS_GT_PCH_GET_ADDRESS): Redefine to sol_gt_pch_get_address. (TRY_EMPTY_VM_SPACE): Define for all combinations of 32 and 64-bit, SPARC and x86. (sol_gt_pch_get_address): New function. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/host-solaris.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pch/pch.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug libstdc++/40296] [C++0x] std::exception_ptr comparisons
--- Comment #15 from jwakely dot gcc at gmail dot com 2010-06-02 17:30 --- (In reply to comment #14) > I'm fairly sure that's not valid. > That relies on an implicit conversion to bool actually that's nonsense ... that is a contextual conversion! anyway, I'll look into it properly and fix it asap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
[Bug c++/44333] Ambiguity with typedef and using namespace
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-02 17:37 --- So it's already known... *** This bug has been marked as a duplicate of 23594 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44333
[Bug c++/23594] namespace typedef and global typedef name the same type, using kills global
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-02 17:37 --- *** Bug 44333 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23594
