Compiling the following program with g++ -std=c++0x results in an ICE:
#include vector
int main()
{
return (std::vectorint{}.size());
}
--
Summary: ICE on empty initializer lists
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
I got this error when trying to compile GRUB (latest bzr) on amd64 with -flto:
lto1: internal compiler error: compressed stream: buffer error
The culprit was an acinclude check, which can be reduced to the following test
case:
asm (.globl start; start: nop);
int
main ()
{
}
I'm not sure this
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-16 08:38 ---
top level asm is valid GNU C code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from dominiq at lps dot ens dot fr 2009-12-16 09:22 ---
Created an attachment (id=19320)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19320action=view)
assembly and dump files for r149941 and r149942
Compressed archive with the assembly (with -m64 -O3) and the
--- Comment #20 from dominiq at lps dot ens dot fr 2009-12-16 09:27 ---
The regression reported in comment #0 is due to revision 149942:
Author: matz
Date: Wed Jul 22 15:30:50 2009 UTC (4 months, 3 weeks ago)
Changed paths: 4
Log Message:
PR tree-optimization/35229
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Target Milestone|---
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-16 09:51
---
By invalid I meant that I had the time to go through Comment #3 again and found
after all safe enough what we have now. Let's delay any tweaks, which can cause
unexpected regressions on exotic targets, to
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-16 09:55
---
Already fixed in 4_4-branch and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from tschwinge at gcc dot gnu dot org 2009-12-16 09:58
---
As a tiny, years-old pointer: in
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01006.html, Daniel J. suggested
that ``appropriate dwarf2 frame gunk'' should be added.
--
tschwinge at gcc dot gnu dot org
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-16 10:10 ---
Caused by PR28879 fix:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=144988
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42387
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-16 10:14
---
(In reply to comment #10)
Results on x86_64/linux or x86_64/darwin10.2
Status:
FAIL: 23_containers/array/requirements/exception/generation_prohibited.cc
execution test
.ident GCC: (GNU) 4.4.2
---
.ident GCC: (GNU) 4.5.0 20091216 (experimental)
--
nbenoit at tuxfamily dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-16 10:44 ---
This exact spot of ICE can be fixed with e.g.:
--- init.c.jj 2009-12-02 09:37:36.0 +0100
+++ init.c 2009-12-16 11:32:52.0 +0100
@@ -2386,7 +2386,16 @@ build_new (VEC(tree,gc) **placement, tre
/* The
--- Comment #5 from kraemer at informatik dot uni-kl dot de 2009-12-16
10:50 ---
thanks a lot.
in our scenario it showed 8 buckets to be the best. but this may vary by usage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42381
/ --enable-gold --enable-lto
--enable-plugins
Thread model: posix
gcc version 4.5.0 20091216 (experimental) [trunk revision 155286] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-fgraphite-identity' '-O2' '-mtune=generic'
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
bug.f90
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Target Milestone|---
--- Comment #9 from nbenoit at tuxfamily dot org 2009-12-16 11:06 ---
Here is a unified diff which focuses on the inner-loop exit conditions.
--- 442/convol.s
+++ r155286/convol.s
.L3:
movl(%edx), %ebx
- imull (%esi,%eax,4), %ebx
+ imull H(,%eax,4), %ebx
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-16 11:11 ---
(In reply to comment #3)
Comment #3 has a couple of incorrect statements about this being a problem with
the system compiler - It's actually a 4.5 problem because the object files used
in build/genmddeps are
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-12-16 11:11
---
Regrename seems to be starting the scan of bb3 (from the reduced testcase) from
somewhere in the middle of the block rather than at the beginning (it's missing
at least 2 insns in the reg chain information:
Basic
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-12-16 11:14
---
(In reply to comment #12)
Some are really puzzling... Hard to believe something is wrong in array, for
example.
I haven't looked into it, but the problem in array could be bug 41449
--
--- Comment #21 from irar at il dot ibm dot com 2009-12-16 12:01 ---
Thanks.
I'll be able to look at this only on Sunday due to holidays.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42384
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.2
Summary|ICE in move_bb_info with|[4.5
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-16 12:22 ---
Confirmed.
# 1 CodingSystem.h 1
#pragma interface
# 1 types.h 1
# 15 CodingSystem.h 1
class Decoder { unsigned minBytesPerChar() const; };
class Encoder { class Handler { }; };
class InputCodingSystem { virtual
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-12-16 12:24
---
Which is the good version, the one with less or the one with more branches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
--- Comment #11 from nbenoit at tuxfamily dot org 2009-12-16 12:53 ---
The fastest is the variant with more jumps (442/convol.s in the diff) generated
by GCC-4.4.2.
In the one jump variant (r155286/convol.s in the diff), I guess it is the
computing of both conditions before jumping
--- Comment #12 from nbenoit at tuxfamily dot org 2009-12-16 12:55 ---
Created an attachment (id=19321)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19321action=view)
Diff of the RTL expand dump between revisions 151079 and 151080
--
--- Comment #3 from drow at gcc dot gnu dot org 2009-12-16 13:15 ---
The CFA also needs to be adjusted after __gnu_mcount_nc returns;
__gnu_mcount_nc is a pop instruction from the point-of-view of the caller.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
--- Comment #100 from jakub at gcc dot gnu dot org 2009-12-16 13:27 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-16 13:43 ---
The issue here is that the asm doesn't switch sections properly and we emit
LTO sections before the actual assembly. So we end up with
...
.section.gnu.lto_.opts,,@progbits
.string
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-16 13:52 ---
But the actual OOM comes while optimizing xml_setchildren, from an obstack
allocation in bitmap_element_allocate during compute_may_aliases after running
the alias pass. dump_memory_report says 1452M allocated from
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-16
13:58 ---
Any suggestions on how we can debug this issue further on darwin? Would this
bug indicate that we are missing some section of a previous patch addressing
mangling for the darwin target?
--
--- Comment #6 from jason at gcc dot gnu dot org 2009-12-16 14:11 ---
It seems like you're getting the right warning message, just on a different
line than expected. I guess Rafael's checkin changed when the warning is
emitted on targets that support COMDAT groups, but not on other
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-12-16 14:14
---
It's indeed expand that makes the difference when expanding
;; if (k = 511 k = j != 0)
probably due to the way TER works now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-16
14:32 ---
Shouldn't darwin have support for comdat? This patch, which went into FSF gcc
ages ago, suggests so...
http://gcc.gnu.org/ml/gcc/2004-01/msg02186.html
--
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-16 14:43 ---
It is caused by revision 155143:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00287.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-16 16:01
---
For now I would suggest we do something like this and deal with better
solutions as enhancements. What do you think Jon?
Index: thread.cc
===
--- Comment #22 from paolo dot carlini at oracle dot com 2009-12-16 16:15
---
Jon, what's your opinion about this one, now that concepts are gone? Frankly, I
don't think we can do much to avoid this type of problem.
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-16 16:17
---
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-16 16:40 ---
Both the base and deleting dtor in this case are !DECL_COMDAT,
DECL_COMDAT_GROUP != NULL, DECL_EXTERNAL. But they are emitted anyway, despite
the DECL_EXTERNAL, as the base dtor is needed.
--
--- Comment #5 from jakub at gcc dot gnu dot org 2009-12-16 17:04 ---
Actually they aren't emitted, they are really just external.
And they are supposed to be external.
I guess we shouldn't optimize known external ctors or dtors.
The question then is whether for the DECL_DEFER_OUTPUT
--- Comment #3 from rodrigorivascosta at gmail dot com 2009-12-16 17:05
---
If the lambda line is changed from:
[] { return 0; };
into any of the following:
[=] { return 0; };
[] { return 0; };
int foo = 0;
[foo] { return 0; };
The warnings disappear.
--
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-16 17:20 ---
Created an attachment (id=19322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19322action=view)
gcc45-pr42386.patch
Fix for this testcase. If we already at maybe_clone_body time know that
the ctor or dtor will
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-12-16 17:27 ---
A test case is still required.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2009-12-16 17:30 ---
Well, the solution could be disable PCH by default. :-) Is anybody using
it?...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-16 17:30 ---
(In reply to comment #6)
Created an attachment (id=19322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19322action=view) [edit]
gcc45-pr42386.patch
Fix for this testcase. If we already at
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-16 17:31 ---
Created an attachment (id=19323)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19323action=view)
gcc45-pr42386.patch
Another alternative - don't mark nodes as reachable because of
same_comdat_group links if they
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-16 17:33 ---
Re: #c7, those 2 lines aren't needed, the other two # lines are needed as is
#pragma interface.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42386
--- Comment #6 from jason at gcc dot gnu dot org 2009-12-16 17:36 ---
Subject: Bug 42387
Author: jason
Date: Wed Dec 16 17:36:05 2009
New Revision: 155292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155292
Log:
PR c++/42387
* decl.c (compute_array_index_type):
--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-12-16 17:41 ---
If they are serious, we should confirm this bug :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2009-12-16 18:02 ---
Subject: Bug 42387
Author: jason
Date: Wed Dec 16 18:02:38 2009
New Revision: 155293
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155293
Log:
PR c++/42387
* decl.c (compute_array_index_type):
--- Comment #8 from jason at gcc dot gnu dot org 2009-12-16 18:03 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from kargl at gcc dot gnu dot org 2009-12-16 18:31 ---
(In reply to comment #5)
FreeBSD upstream now switched to GCC 4.2.1 to rebuild the whole system,
so this problem was solved there.
Since GCC 3.4.x is no longer maintained by the GCC developers (GCC 4.0.x
being
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-16 18:38 ---
gerald added the #define to gcc/config/freebsd.h in revision 140650.
troutmask:sgk[208] svn log -r 140650 freebsd.h |more
r140650 | gerald |
--- Comment #4 from kargl at gcc dot gnu dot org 2009-12-16 18:53 ---
I followed the discussion pointed to by the URL in comment #3,
but I could not find if the final version of the patch has
been accepted or rejected. Is this PR still relevant or should
it be closed?
--
--- Comment #10 from kargl at gcc dot gnu dot org 2009-12-16 19:00 ---
(In reply to comment #9)
Created an attachment (id=17302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17302action=view) [edit]
Proprocessed source of the error
Yes, should have thought to do that before.
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-16 19:15
---
Well, for sure the testsuite runs much faster. Anyway, if we can't really
figure out a proper fix, maybe we can disable PCHs when we are building
cross-compilers.
--
--- Comment #10 from jason at gcc dot gnu dot org 2009-12-16 19:32 ---
The second patch seems better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42386
The attached test case should produce no output when executed. However, when
compiled with the following command-line arguments...
g++ pure_virtual_function_test.cpp -fno-strict-aliasing -O -o fail_test
the test case produces the following output...
pure virtual method called
terminate called
--- Comment #1 from Troy dot Runkel at mathworks dot com 2009-12-16 19:52
---
Created an attachment (id=19324)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19324action=view)
Original test case code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42394
--- Comment #2 from Troy dot Runkel at mathworks dot com 2009-12-16 19:53
---
Created an attachment (id=19325)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19325action=view)
Pre-processed test case code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42394
--- Comment #3 from Troy dot Runkel at mathworks dot com 2009-12-16 19:54
---
Created an attachment (id=19326)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19326action=view)
Makefile for building passing/failing versions of test case.
--
--- Comment #6 from bernds_cb1 at t-online dot de 2009-12-16 19:57 ---
I'm having a hard time reproducing this. How do you folks configure your
compilers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
--- Comment #4 from Troy dot Runkel at mathworks dot com 2009-12-16 19:59
---
Created an attachment (id=19327)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19327action=view)
Assembly fragment with comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42394
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-16 20:02
---
Interesting. I can't reproduce it in mainline, only with 4.4.x and 4.3.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42394
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-16 20:16 ---
I think there's a dup somewhere.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-16 20:18 ---
PR39509.
*** This bug has been marked as a duplicate of 39509 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-12-16 20:18
---
*** Bug 42394 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-12-16 20:19
---
PR42394 has a smaller testcase (but it doesn't fail with trunk). It works
with -fno-tree-sink.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39509
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-16
20:29 ---
What's up with the instantiation portions of the warning messages in darwin? On
Fedora 10, gcc trunk shows...
~/dist/bin/g++ mangle11.C -nostdinc++ -fmessage-length=0 -Wabi -fabi-version=1
-S -o
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-12-16 20:53
---
In a discussion we decided that introducing a __builtin_undefined () that
we can assign to variables at the point they die would be the proper way
to fix this.
--
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-12-16 20:58 ---
I'm now officially on vacation so I did not double check but...
(In reply to comment #8)
I think
/* Put the integral type with the bigger precision first. */
else if (INTEGRAL_TYPE_P (f1-type)
Command line:
gcc -O3 -g testcase.c
Tested revisions:
trunk r155256 - crash
trunk r154886 - crash (OK without checking)
trunk r154830 - crash
trunk r153685 - OK
4.4 r154975 - OK (with checking)
Output:
$ /mnt/svn/gcc-trunk/binary-155256-lto/bin/gcc -O3 -g testcase.c
testcase.c: In function
--- Comment #1 from zsojka at seznam dot cz 2009-12-16 21:03 ---
Created an attachment (id=19328)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19328action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42395
--- Comment #5 from anlauf at gmx dot de 2009-12-16 21:16 ---
(In reply to comment #3)
One can get rid of this by making the vtypes private:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
--- Comment #7 from mikpe at it dot uu dot se 2009-12-16 21:27 ---
I've done a binary search which identified 154688 as the revision which caused
the problem to appear.
To answer Bernd's question, I used an arm cross configured with:
--target=armv5tel-unknown-linux-gnueabi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 regression] Regrename |[4.5 Regression] Regrename
|reuses non-dead
--- Comment #4 from zsojka at seznam dot cz 2009-12-16 21:41 ---
Created an attachment (id=19329)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19329action=view)
different testcase, in C, reduced
Crashes in trunk r155248 and 4.4 r154975 with the following command line:
gcc -O2
--- Comment #17 from rwild at gcc dot gnu dot org 2009-12-16 21:51 ---
Armand, to expand on comment #13, could you post the exact command and error
message you're getting, as the original poster did?
Both of you, could you cd to the directory where the failure occurs, remove the
-o ARG
--- Comment #4 from zsojka at seznam dot cz 2009-12-16 22:01 ---
Created an attachment (id=19330)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19330action=view)
simplified testcase
(testcase from comment#3 turned out to be a dup of pr39453)
--
zsojka at seznam dot cz changed:
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-16
22:19 ---
So I assume darwin is the only target that uses 'a poor man's comdat group'
rather than a real one? I don't see any other targets failing these tests.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-12-16 22:48
---
Seems to be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
] ./exception
Caught an exception String
troutmask:sgk[227] ~/work/44/bin/g++ -fexceptions -Wall -o exception a.cc
troutmask:sgk[228] ./exception
Caught an exception String
The versions I tested are
gcc version 4.4.3 20091216 (prerelease) (GCC)
gcc version 4.3.5 20091216 (prerelease) (GCC)
on x86_64
Command line:
gcc -m32 -O2 -g -ftracer -fsched2-use-superblocks testcase.c
(x86 binary doesn't need -m32, crashes as well)
Tested versions:
trunk r155256 - crash
trunk r155121 - crash (x86)
trunk r154886 - crash (both with and without checking)
trunk r153685 - crash
4.4 r154975 - OK (with
--- Comment #1 from zsojka at seznam dot cz 2009-12-16 23:01 ---
Created an attachment (id=19331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19331action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42396
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-16 23:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
lto/42392
* langhooks.c (lhd_begin_section): Make sure to switch back
to the text section, not some random one.
* gcc.dg/lto/20091216-1_0.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/lto/20091216-1_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/langhooks.c
--- Comment #8 from bernds_cb1 at t-online dot de 2009-12-16 23:17 ---
This seems to be a bug in arm.md. Operand 0 in tls_load_dot_plus_eight is
marked in-out, but there's no matching match_dup to show the input. Adding
that to the unspec seems to make the problem go away. Richard
--- Comment #22 from matz at gcc dot gnu dot org 2009-12-16 23:36 ---
My patch only enables more vectorization. This seems to uncover a problem
in the vectorizer (which I haven't yet looked at).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #14 from matz at gcc dot gnu dot org 2009-12-16 23:43 ---
That's exactly what I fixed with my last patch. If this still results in a
difference it's caused by difference in cheapness of branches. I'll poke at
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
Executing on host:
/home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gfortran/../../gfortran
-B/home/dave/gnu/gcc-4.5/objdir/gcc/testsuite/gfortran/../../
f_lto_20091028-2_0.o f_lto_20091028-2_1.o -O2 -fwhopr -r -nostdlib
-finline-functions
--- Comment #15 from matz at gcc dot gnu dot org 2009-12-17 00:27 ---
Hmm, no, it's still my fault. Something must have gone wrong with my brain
when I thought the bug was fixed, no idea how that happened. The patch wasn't
complete.
--
matz at gcc dot gnu dot org changed:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 00:45 ---
Can you provide a backtrace?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
--- Comment #2 from danglin at gcc dot gnu dot org 2009-12-17 01:14 ---
#0 $$divoI () at ../../../gcc/libgcc/../gcc/config/pa/milli64.S:435
#1 0x00596158 in gen_movmemsi (operand0=0x4007d480, operand1=0x4007d490,
operand2=0x40013220, operand3=0x40013200)
at
--- Comment #16 from matz at gcc dot gnu dot org 2009-12-17 01:42 ---
Created an attachment (id=19332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332action=view)
Real fix
Now, before I blow it again, would you be so kind to test this patch (on top
of some recent trunk,
--- Comment #3 from danglin at gcc dot gnu dot org 2009-12-17 01:57 ---
The problem is here:
0x00163a80 in emit_block_move_via_movmem (x=value optimized out,
y=value optimized out, size=0x40013220, method=BLOCK_OP_NORMAL,
expected_align=value optimized out,
--- Comment #4 from danglin at gcc dot gnu dot org 2009-12-17 02:12 ---
(gdb) p debug_rtx (x)
(mem/c/i:BLK (reg/f:SI 109) [0 C.1197+0])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
1 - 100 of 104 matches
Mail list logo
