--- Comment #18 from jakub at gcc dot gnu dot org 2009-09-04 06:48 ---
For each target built after r151388, can you please attach one stage2 object
that differs and corresponding stage3 object?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--- Comment #7 from sezeroz at gmail dot com 2009-09-04 06:26 ---
fixed on the trunk now.
--
sezeroz at gmail dot com changed:
What|Removed |Added
Status|NEW
Testcase:
$ cat x.cc
struct desc {
const char *Desc;
desc(const char *Str) : Desc(Str) {}
};
struct opt {
explicit opt(const desc &d) {}
};
opt o(desc("Do something!"));
int main(void) {}
Reproduce:
$ g++-4.4 x.cc -fmudflap -lmudflap -o x
$ ./x
***
mudfla
--- Comment #17 from kargl at gcc dot gnu dot org 2009-09-04 03:13 ---
Same problem on i686-*-*freebsd at Revision: 151401
gmake[3]: Entering directory `/usr/home/kargl/gcc/obj4x'
rm -f stage_current
gmake[3]: Leaving directory `/usr/home/kargl/gcc/obj4x'
Comparing stages 2 and 3
warnin
--- Comment #30 from mrs at apple dot com 2009-09-04 01:49 ---
I admit that having gcc automagically add -m32 isn't strictly needed, the user
can do that. The problem is when they don't do that. What behavior do we
want? We can pick:
1) Just work.
2) Fail immediately, telling t
--- Comment #2 from dgutson at codesourcery dot com 2009-09-04 01:10
---
I'm working on this now, and will post a fix tomorrow.
Please assign this bug to me, since seems I don't have permissions enough to do
that myself.
Thanks,
Daniel.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last rec
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-09-03
23:16 ---
The bootstrap completes normally now on x86_64-apple-darwin10 with r151394.
Regression testing now and will post to gcc-testresults. A quick and dirty test
with himenoBMTxpa.c compiled with -O3 -g indicates
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.1
Known to work||4.3.5 4.4.2
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-03 22:00 ---
Created an attachment (id=18484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18484&action=view)
Testcase for ICE
Testcase from newlib build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41252
The commit at r151362 broke the default build for arm-none-eabi in newlib with
the following ICE for the hard-float variant of the ABI.
/home/ramana/cos/combined-git-master-cloned/newlib/libm/common/s_nextafter.c:
In function ‘nextafter’:
/home/ramana/cos/combined-git-master-cloned/newlib/libm/co
--- Comment #4 from vmakarov at redhat dot com 2009-09-03 21:40 ---
Oh well, another haifa-scheduler integration issue after so many years to
integrate it into GCC. It looks like the original haifa-scheduler treated
calls as always returning.
I think you should use last_function_ca
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-09-03 21:32 ---
Richard Sandiford has already fixed this, and he has indeed excluded debug
insns from USEFUL_INSN_P.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from ubizjak at gmail dot com 2009-09-03 21:30 ---
Alpha fails bootstrap too, r151391:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree-vect-slp.o differs
gcc/c-common.o differs
gc
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-09-03 21:28 ---
Just started looking into the proposed patch and, without actually looking at
the code, I wonder: should USEFUL_INSN_P really hold for debug insns? I mean,
they're useful for something, but maybe not in the sense of
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last rec
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-09-03 20:55
---
The problem is not fixed at revision 151391:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cfgloopmanip.o differs
gcc/ada/
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Component|middle-end |debug
Ev
--- Comment #2 from xenofears at gmail dot com 2009-09-03 20:28 ---
This is a binutils issue, and appears resolved.
--
xenofears at gmail dot com changed:
What|Removed |Added
-
--- Comment #8 from xenofears at gmail dot com 2009-09-03 20:25 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Works for me with a crosscompiler from linux to mingw:
> >
> > Target: x86_64-pc-mingw32
> > Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32
--- Comment #1 from ojab at ojab dot ru 2009-09-03 20:24 ---
Created an attachment (id=18483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18483&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41251
4.5.0 20090903 (experimental) (GCC)
make[1]: Entering directory `/sources/mplayer/libavcodec'
/usr/local/bin/gcc -DHAVE_AV_CONFIG_H -I.. -I.. -Wundef -Wdisabled-optimization
-Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch
-Wpointer-arith -Wredundant-decls -O4 -
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 20:11 ---
Looking at sched-deps.c, it might be easiest for may_trap_p insns to be queued
onto deps->sched_before_next_call chain, but I'm not sure whether we want to do
that for all, or if it should ignore trapping memory as tha
--- Comment #2 from xenofears at gmail dot com 2009-09-03 20:02 ---
(In reply to comment #1)
> You didn't say how you configured it.
> As with bug 40950, you might need --enable-stage1-languages=c,c++
Sorry, it was configured with
--enable-languages=c,c++,objc,obj-c++,fortran,java
It i
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-09-03 20:00
---
> Oh, just curious - if you disable address space randomization, does the build
> succeed? (echo 0 > /proc/sys/kernel/randomize-va-space)
Disabling it is the first thing I do when I get a new box. :-)
--
h
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-09-03 19:09
---
As Richard Henderson pointed out, declarations with DECL_VALUE_EXPR
should not appear in the function body at all. I have filed bug 41250
about this.
--
jamborm at gcc dot gnu dot org changed:
What
When investigating PR 40464 I have come across a declaration with
DECL_HAS_VALUE_EXPR_P and DECL_VALUE_EXPR set (which indeed turned out
to be the root of the problem). However, according to a comment in
tree.h: "once this field has been set, the decl itself may not
legitimately appear in the func
--- Comment #15 from mikpe at it dot uu dot se 2009-09-03 18:58 ---
(In reply to comment #14)
> I compile gcc 4.4.2 20090825 and test.
>
> problem is still in.
>
> Is this fix in gcc4.4.2 too ?.
No, so far these fixes have only been applied to trunk aka gcc-4.5. They are
easily backpo
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-03 18:48
---
Yes, this is a known issue, still in *New* status:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133
We'll implement the updated C++1x specifications in due course.
--
paolo dot carlini a
--- Comment #13 from vmakarov at gcc dot gnu dot org 2009-09-03 18:33
---
Subject: Bug 41241
Author: vmakarov
Date: Thu Sep 3 18:33:25 2009
New Revision: 151388
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151388
Log:
2009-09-03 Vladimir Makarov
PR bootstrap/4124
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Component|middle-end |debug
Ev
This bug is proably a followup to #40486: [c++0x] rvalue-references no longer
bind to lvalues
std::list<>::splice() no longer works in trunk in c++0x mode:
=== 8< ==
#include "list"
int main()
{
std::list l;
l.insert(l.end(), 1);
l.insert(l.end(), 2);
--- Comment #5 from michael dot a dot richmond at nasa dot gov 2009-09-03
18:12 ---
(In reply to comment #4)
> It's probably some bad counting of position on platforms with HAVE_CRLF. To
> investigate, it should be possible to build such a faulty linux compiler by
> forcing HAVE_CRLF to
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-09-03 18:05
---
(In reply to comment #11)
> Subject: Re: should "sorry" when regparm=3 and nested functions are
> encountered
>
> All,
>
> nested functions get passed a hidden argumment akin to static link/display
> so that nes
--- Comment #23 from lucier at math dot purdue dot edu 2009-09-03 18:04
---
The gprof output on the _num.i example, with and without -fschedule-insns is at
http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.out-fschedule-insns.gz
http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.o
--- Comment #11 from graham dot stott at btinternet dot com 2009-09-03
18:01 ---
Subject: Re: should "sorry" when regparm=3 and nested functions are
encountered
All,
nested functions get passed a hidden argumment akin to static link/display
so that nested function can access the loca
All,
nested functions get passed a hidden argumment akin to static link/display
so that nested function can access the locals of its enclosing function.
Passing a nested function as parameter to another function isn't going
to work correctly when the function is eventually called the
hidden argu
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-09-03 17:30
---
Or similar just using -mregparm=2 for that nested function. I doubt we specify
the ABI for them somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-03 17:28 ---
We could implement it by not using %ecx for nested function support, so it's
not implemented vs. an error (IMHO). AFAIK that we use %ecx is completely
internal as the nested function cannot be exported.
--
http
--- Comment #2 from sje at cup dot hp dot com 2009-09-03 17:25 ---
The original file was libgcov.c, I used delta to cut it down into an example
that will fail to compile with '-g -O2'.
Testcase:
struct __gcov_var {
unsigned int offset;
unsigned int buffer[(1 << 10) + 1];
} __gco
--- Comment #10 from rguenther at suse dot de 2009-09-03 17:23 ---
Subject: Re: [4.5 Regression] miscompilation at -O2
On Thu, 3 Sep 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #9 from matz at gcc dot gnu dot org 2009-09-03 17:13 ---
> Indeed. For fixing fwprop t
--- Comment #8 from ubizjak at gmail dot com 2009-09-03 17:21 ---
(In reply to comment #3)
> Yes, I think we should sorry() here.
Why sorry? It is an error.
Using sorry, the compiler will say: "sorry, unimplemented: " which
is just confusing.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-03 17:19 ---
The comment needs adjusting...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
--- Comment #6 from bonzini at gnu dot org 2009-09-03 17:15 ---
Created an attachment (id=18482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18482&action=view)
patch erroring out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
--- Comment #9 from matz at gcc dot gnu dot org 2009-09-03 17:13 ---
Indeed. For fixing fwprop this:
--- tree-ssa-forwprop.c (Revision 151348)
+++ tree-ssa-forwprop.c (Arbeitskopie)
@@ -958,7 +958,7 @@ forward_propagate_addr_expr (tree name,
/* If the use is in a deeper loop nest
--- Comment #5 from bonzini at gnu dot org 2009-09-03 17:11 ---
Yes, if you use nested functions you can just use -mregparm=2 globally, that's
a much better solution.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-03 17:11 ---
Maybe related to PR41241. Please re-check once that is solved.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-03 17:10 ---
Please attach preprocessed source so the issue can be reproduced with a cross.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-03
17:08 ---
This breakage is likely the same issue as PR41241 which apparently is a latent
bug exposed by IRA. Watch for the fix to PR41241 and test again with that fix
applied.
--
http://gcc.gnu.org/bugzilla/show
On ia64-hp-hpux11.23, which supports a 32 and 64 bit mode, I get an assertion
failure during bootstrap. This is with version 151382.
insn is:
(debug_insn 52 51 53 9
/proj/opensrc/nightly/src/trunk/libgcc/../gcc/gcov-io.c:238 (var_location:SI
result (high (nil))) -1 (nil))
val is:
(plus:DI (con
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-09-03 16:58 ---
I don't have access to powerpc-apple-darwin9 so I cannot investigate
this. Moreover, I doubt my commit (r151345) is the one that has caused
this. Therefore I'll remove myself from the CC.
However, if you find out t
--- Comment #8 from rguenther at suse dot de 2009-09-03 16:50 ---
Subject: Re: [4.5 Regression] miscompilation at -O2
On Thu, 3 Sep 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #7 from matz at gcc dot gnu dot org 2009-09-03 16:39 ---
> Hmm, in a sense what forward
--- Comment #11 from ro at techfak dot uni-bielefeld dot de 2009-09-03
16:48 ---
Subject: Re: [4.5 Regression] VTA: bootstrap failure, ICE in loc_cmp, at
var-tracking.c:2456
> --- Comment #9 from jakub at gcc dot gnu dot org 2009-09-03 16:35 ---
> Fixed. For the sparc compar
--- Comment #4 from rmh at gcc dot gnu dot org 2009-09-03 16:47 ---
(In reply to comment #2)
> So, perhaps we should just
> error out whenever we see in -m32 mode on i?86/x86_64 a nested function in
> -mregparm=3 mode.
Error out is much nicer. I can recall nasty memory corruption bugs
--- Comment #6 from hjl at gcc dot gnu dot org 2009-09-03 16:46 ---
Subject: Bug 39065
Author: hjl
Date: Thu Sep 3 16:46:00 2009
New Revision: 151386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151386
Log:
2009-09-03 Ozkan Sezer
PR target/39065
* configur
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-03 16:40 ---
Yes, I think we should sorry() here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
As already reported in PR debug/41238, Comment #7, even after applying Jakubs
patch there are still two comparison failures that break bootstrap. See the
attachements there for details.
--
Summary: [4.5 regression] Comparison failure on Solaris 11/SPARC
after VTA
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-03 16:39 ---
Hmm, in a sense what forward prop is doing is at least fishy. It forwards
the casted ADDR_EXPR into some references of y_13, but not into all of them.
As y_13 is a restrict pointer this is always going to be a problem,
--- Comment #10 from ubizjak at gmail dot com 2009-09-03 16:36 ---
The patch works for alpha too, up to the point where bootstrap hits:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree-vect-slp.o
--- Comment #2 from pleexed at gmail dot com 2009-09-03 16:36 ---
Created an attachment (id=18481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18481&action=view)
Workaround
By declaring a typedef in a templated proxy class and using that in the friend
declaration, the desired ef
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-03 16:36 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jakub at gcc dot gnu dot org 2009-09-03 16:35 ---
Fixed. For the sparc comparison failures please open a new bug.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 16:33 ---
Subject: Bug 41236
Author: jakub
Date: Thu Sep 3 16:33:27 2009
New Revision: 151385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151385
Log:
PR debug/41236
* dwarf2out.c (loc_descriptor): Do
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-03 16:32 ---
Subject: Bug 41238
Author: jakub
Date: Thu Sep 3 16:32:07 2009
New Revision: 151384
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151384
Log:
PR debug/41238
* function.c (assign_parm_find_sta
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-09-03
16:32 ---
My mistake. I believe dwarfdump is showing the debug symbols and not the
sections. The stage2 build apparently doesn't generate any debug symbols.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 16:29 ---
Created an attachment (id=18480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18480&action=view)
gcc45-pr41246.patch
I'm afraid there is nothing that can make that unmodified testcase work for
-mregparm=3.
It i
--- Comment #17 from dominiq at lps dot ens dot fr 2009-09-03 16:15 ---
If I am not mistaken, strip on darwin does not strip the DWARF stuff by default
nor with the options I have tried (including -S file.o -o out_file).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #16 from dominiq at lps dot ens dot fr 2009-09-03 16:07 ---
> Is there actual differences or is the stage2 binary empty like
> on x86_64-apple-darwin10?
The file I looked at (was stage2-gcc/intl.o) was empty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #7 from ro at gcc dot gnu dot org 2009-09-03 15:59 ---
With your patch, the ICE on sparc-sun-solaris2.11 is gone, but the bootstrap
still
aborts with a comparison failure:
Bootstrap comparison failure!
gcc/objc/objc-act.o differs
gcc/c-common.o differs
I'm attaching the sta
--- Comment #6 from ro at gcc dot gnu dot org 2009-09-03 15:57 ---
Created an attachment (id=18479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18479&action=view)
stage3 c-common.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
--- Comment #5 from ro at gcc dot gnu dot org 2009-09-03 15:56 ---
Created an attachment (id=18478)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18478&action=view)
stage2 c-common.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41238
--- Comment #1 from rmh at gcc dot gnu dot org 2009-09-03 15:34 ---
Created an attachment (id=18477)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18477&action=view)
test case
$ gcc -m32 regparm_nested.c && ./a.out
10 31 31
$ gcc -m32 -mregparm=3 regparm_nested.c && ./a.out
10 31
On i386, combining -regparm=3 with nested functions results in %ecx (holding
the third function parameter because of -regparm=3) being overwritten with a
temporary pointer used by GCC to implement the nested function call.
GNU GRUB has had a workaround (disabling -regparm in a case-by-case basis)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-03 15:32 ---
stage2 objects shouldn't contain any debug info, they are compiled with -g0.
What is being checked is that after stripping debug info, both -g0 and -g
objects should be the same (i.e. the code itself, data, ...).
--
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-03
15:26 ---
Dominique,
Can you run dwarfdump on a stage2 and stage3 binary that differ from this
failed build on powerpc-apple-darwin9? Is there actual differences or is the
stage2 binary empty like on x86_64-apple
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-03
15:24 ---
Can you try a x86_64-apple-darwin9 bootstrap as well? It is puzzling that on
x86_64-apple-darwin10, the corresponding dwarfdump for the stage2 binaries is
empty.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:15
---
Works for me with current mainline:
$ i586-pc-mingw32-gcc -print-file-name=libgcc_s.a
/Users/fx/devel/mingw/cross/lib/gcc/i586-pc-mingw32/4.5.0/../../../../i586-pc-mingw32/lib/libgcc_s.a
$ i586-pc-mingw32-gcc -pr
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:10
---
Will have to be tested again once PR 39886 is done with; hopefully, should then
be gone.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-09-03 15:10
---
Also happens on i586-pc-mingw32 and with -m64 on i386-apple-darwin9. This P1
regression is more than 4 months old, and has a proposed patch; could someone
post the patch for review?
--
fxcoudert at gcc dot gnu
--- Comment #12 from vmakarov at redhat dot com 2009-09-03 15:01 ---
It looks as an old IRA rare hidden bug which was triggered by the new patches.
I check IRA on valgrind on a lot of tests but never saw it.
Update_equiv_reg imported from the old RA uses pseudo class but it was never
s
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-03 14:51
---
Created an attachment (id=18476)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18476&action=view)
testcase
testcase, _umoddi_s.i from libgcc2.c
> valgrind ./cc1 -quiet -O2 -m32 t.i
==1232== Invalid read of
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:40
---
It's because of this in gcc/config/i386/mingw-w64.h:
#define ASM_SPEC "%{v:-V} %{n} %{T} %{Ym,*} %{Yd,*} \
%{Wa,*:%*} %{m32:--32} %{m64:--64}"
The "%{v:-V}" part is what's triggering what you see. Now, the que
--- Comment #10 from hjl dot tools at gmail dot com 2009-09-03 14:25
---
I got my first compare failure at revision 151353.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|VTA: bootstrap failure, ICE |[4.5 Regression] VTA:
|in loc_cmp, at var-
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-09-03 14:19
---
I can confirm I can reproduce this bug with an darwin-to-mingw cross-compiler,
and running the executable under wine.
I can also confirm that it's about the REWIND statement: if you have already
run the test prog
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-03 14:13 ---
-g is not needed after all. It's just very random.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41241
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-03 14:12 ---
Because the index arithmetic is done unsigned.
return (int) ((unsigned int) i * 212) /[ex] 212;
We lost the information that i * 212 cannot overflow.
Simpler testcase:
extern int data[];
int find(int i)
{
re
Subject says it all; i386-apple-darwin is a primary platform.
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/tree.o differs
The output of "../trunk/contrib/compare-debug --preserve stage[23]-gcc/tree.o"
is long, so I'll attach it, but the end of it
--- Comment #8 from hjl dot tools at gmail dot com 2009-09-03 13:56 ---
It may be caused by VTA merge. I also got random compare failures.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-03 13:54 ---
*** This bug has been marked as a duplicate of 41241 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-03 13:54 ---
*** Bug 41243 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:53 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
> --- Comment #5 from ubizjak at gmail dot com 2009-09-03 13:08 ---
> (In reply to comment
--- Comment #1 from zsojka at seznam dot cz 2009-09-03 13:50 ---
Created an attachment (id=18475)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18475&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
In attached code:
in find(), generated code computes offset using multiplication/division.
in set(), generated code computes &data[10] and compares &data[i] with that (to
verify find() fails to be optimised because of overflow rules)
tested gcc: 4.3.4, 4.4.1, 4.5.0-alpha20090827
command line:
gcc
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-03 13:35 ---
That still assumes that inside of SIGN_EXTEND/ZERO_EXTEND is a REG, which isn't
always the case. Testing with loc_descriptor call there instead now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41236
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-03 13:30 ---
First differing dump is 183r.ira.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/ia32 and Linux/x86-64, I got random
compare failures during bootstrap:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libgcc/_umoddi3.o di
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-03 13:19 ---
I get different code with two invocations of stage2 gcc. -g is needed, and
you have to be lucky with address space randomization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-09-03
13:09 ---
Subject: Re: [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455
building stage1 N64 libgcc
> --- Comment #4 from jakub at gcc dot gnu dot org 2009-09-03 13:03 ---
> Just try latest
1 - 100 of 155 matches
Mail list logo
