--- Comment #9 from matz at gcc dot gnu dot org 2007-05-21 07:45 ---
Richard, the problem isn't the compare or where to store the live values
alen and blen (FYI, the store looks invalid, because reload will not
immediately stop when it sees an invalid asm insn, but instead just patch it
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 ---
I know what's going on :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 ---
Created an attachment (id=13593)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593action=view)
tentative patch?
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #97 from jv244 at cam dot ac dot uk 2007-05-21 08:30 ---
This morning's mainline gives a new ICE on the CVS version of CP2K (the file in
question is not in the tarbal of comment #0)
gfortran -c -O3 -ftree-vectorize -ffast-math -march=native
semi_empirical_int_ana.f90
--- Comment #10 from ubizjak at gmail dot com 2007-05-21 08:33 ---
Extending reload to make use of memory for some reloads, where allowed,
might be nice, but is unrealistic in its gory detail (even the secondary mem
support doesn't really help here).
Should we XFAIL this test?
--
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 ---
Micha, do you mean transforming (while expanding to RTL)
asm (: =mr (inout_2) : 0 (inout_1));
to
inout_2 = inout_1;
asm (: =mr (inout_2) : 0 (inout_2));
?
That shouldn't be too hard.
--
--- Comment #12 from matz at gcc dot gnu dot org 2007-05-21 09:03 ---
Exactly. If during expansion or at some other time before reload, doesn't
matter that much. Of course there's a remote possibility that some RTL
passes between expand and reload would do the copy propagation to
--- Comment #1 from pcarlini at suse dot de 2007-05-21 09:22 ---
Ok, thanks, but this bug is already fixed.
*** This bug has been marked as a duplicate of 25288 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2007-05-21 09:22 ---
*** Bug 32017 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-05-21 09:26 ---
Also see libstdc++/32017 for some additional details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 ---
So we'd just be replacing a weak workaround with a stronger (but not
definitive) workaround. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-05-21
09:41 ---
Subject: Re: [4.3 regression] : gcc.target/i386/pr21291.c
matz at gcc dot gnu dot org wrote:
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
Yes. The place where I
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 ---
This bug will be fixed as soon as Tom's patch goes in.
*** This bug has been marked as a duplicate of 22168 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from manu at gcc dot gnu dot org 2007-05-21 09:54 ---
*** Bug 11051 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
Yes. The place where I would think the work-around to become definitive is
exactly before regclass. Between it and reload nothing interesting happens
transformation wise.
--
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-21 10:13 ---
My patch for PR31867 fixes this in all its manifestations: see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html
The amusing thing is that I was hurting for testcases for this latter PR:)
It shows what a
--- Comment #1 from irar at il dot ibm dot com 2007-05-21 10:43 ---
On PowerPC revision 124785 from May 17 we get:
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce
--- Comment #2 from dominiq at lps dot ens dot fr 2007-05-21 10:58 ---
vect-intfloat-conversion-4b.c is four days old, but the other tests seem pretty
old so the failures are regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #3 from paolo at gcc dot gnu dot org 2007-05-21 11:26 ---
Subject: Bug 31621
Author: paolo
Date: Mon May 21 10:25:52 2007
New Revision: 124896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124896
Log:
2007-05-21 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2007-05-21 11:27 ---
Subject: Bug 31621
Author: paolo
Date: Mon May 21 10:26:49 2007
New Revision: 124897
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124897
Log:
2007-05-21 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2007-05-21 11:27 ---
Fixed for 4.2.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from uros at gcc dot gnu dot org 2007-05-21 12:31 ---
Subject: Bug 31167
Author: uros
Date: Mon May 21 11:31:14 2007
New Revision: 124900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900
Log:
PR target/31167
Backport from mainline.
*
--- Comment #6 from uros at gcc dot gnu dot org 2007-05-21 12:31 ---
Subject: Bug 30041
Author: uros
Date: Mon May 21 11:31:14 2007
New Revision: 124900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124900
Log:
PR target/31167
Backport from mainline.
*
Attached code from CP2K crashes f951 on i686-pc-linux-gnu if these flags
FCFLAGS=-c -O2 -ftree-vectorize -msse2
are specified. All of them are necessary, omitting any will avoid the segfault.
The crash seems to be related to the length of the subroutine. Further reducing
the number of
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-21 12:33 ---
Created an attachment (id=13594)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13594action=view)
Described test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32018
--- Comment #98 from dfranke at gcc dot gnu dot org 2007-05-21 12:38
---
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-21 13:04 ---
Sorry about the bad news, but I still have the very same failure with the
patch:
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-21 13:05 ---
Daniel cleared this one on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from andreast at gcc dot gnu dot org 2007-05-21 13:06
---
Nope. It clinches somehow with this one: config/mh-ppc-darwin. Here the
BOOT_CFLAGS is set to -g -O2 -mdynamic-no-pic.
In the libgcc Makefile.in I see that MULTILIB_CFLAGS is set to CFLAGS + extra
stuff. CFLAGS
--- Comment #3 from ubizjak at gmail dot com 2007-05-21 13:06 ---
(In reply to comment #1)
FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times
vectorized
1 loops 1
FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times
vectorized
1 loops 1
These
The following program should not compile (without warnings) on two counts, but
in fact only fails on one, and not for the right reason, as far as I can see.
class C
{
public:
C(const char *);
operator const char *();
};
void
foo (bool b)
{
// Prove that the implicit convertions work both
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-21 13:15 ---
Please look to PR tree-optimization/24695
Are you sure about the number? PR24695 is
[csl-arm-branch] Bootstrap failure with current csl-arm-branch
and has only three comments.
--
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #5 from ubizjak at gmail dot com 2007-05-21 14:01 ---
(In reply to comment #4)
Please look to PR tree-optimization/24695
Are you sure about the number? PR24695 is
Oops, PR24659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31867
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903
Log:
2007-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31994
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124903
Log:
2007-05-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-21 14:18 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 ---
Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has
settled on trunk and 4.2 is open again.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25
---
I won't push the subject any further, but again, if you don't adopt the tests
mentioned in the threads cited above, you will almost certainly have further
exception safety bugs lurking. Howard Hinnant can
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 14:27 ---
GCC 3.2 is no longer maintained. This works with the new C++ parser that went
in
for GCC 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following environment variables exist in gfortran (inherited from g95, cf.
http://ftp.g95.org/G95Manual.pdf). They are not documented and don't seem to
work, however they are partially implemented.
GFORTRAN_FPU_PRECISION can probably be removed (cf. -mpc32, -mpc64 and -mpc80)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-21 14:29 ---
For GFORTRAN_SIG* one could also add an option to backtrace/dump in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #7 from pcarlini at suse dot de 2007-05-21 15:00 ---
*** Bug 32017 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
--- Comment #3 from pcarlini at suse dot de 2007-05-21 15:00 ---
This specific bug is already fixed and must be marked as duplicate. Then we
have 21772, more general. We know what we are doing, thanks.
*** This bug has been marked as a duplicate of 25288 ***
--
pcarlini at suse dot
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:21
---
Created an attachment (id=13595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13595action=view)
Patch for that issue; not tested yet
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:25
---
Scanning the F2003 standard, MIN/MAX are the only intrinsics with a variable
number of arguments. They probably need special handling.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
The following program doesn't compile due to invalid lvalue in increment. The
most strange thing is that gcc somehow ignores type coercion
int main ()
{
int **a;
void **b;
*b++;/* works fine */
*((void **)a)++; / gives error */
return 0;
}
--
Summary: Invalid lvalue in
--- Comment #16 from hjl at lucon dot org 2007-05-21 15:33 ---
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:
---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit
bng_ia32_mult_sub_digit (bng a,
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 ---
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** This bug has been marked as a duplicate of 32020 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** Bug 32022 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.0
Version|unknown |3.2.3
--- Comment #3 from tru at pasteur dot fr 2007-05-21 15:43 ---
[EMAIL PROTECTED] ~]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared
--- Comment #1 from schwab at suse dot de 2007-05-21 15:45 ---
A cast is not an lvalue.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:57 ---
Dave, just to clarify, this is bug 21772. We're working on it.
;)
-benjamin
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:58 ---
This is now integrated, but the tests are still ad-hoc. We need a more
consistent application of eh-safety tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
-debug
--enable-interpreter --with-system-zlib --enable-libada --with-tls
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070521 (experimental)
The _exact_ same ./configure commands work on gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|bootstrap |middle-end
--- Comment #3 from gcc-tgc at jupiterrise dot com 2007-05-21 16:19 ---
(In reply to comment #2)
patches get sent to gcc-patches@, make sure you read
http://gcc.gnu.org/contribute.html also.
I noticed and I just did. Perhaps I should have started there ;)
I haven't signed any FSF
--- Comment #18 from patchapp at dberlin dot org 2007-05-21 16:25 ---
Subject: Bug number PR18923
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01264.html
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-21 16:25 ---
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
I think the all of the ICEs were due to:
2007-05-16 Eric Christopher [EMAIL PROTECTED]
* config/rs6000/rs6000.c (rs6000_emit_prologue): Move altivec
With gcc 4.0.x, left bitshift on 128-bit TIMode doesn't seem to be working
properly. For example, using the attached code and compiled under 4.0.4, I
initialize a 128-bit TIMode variable called mask to 1U, left-shift it by the
entered number of bits and compute 0U-mask, while printing the contents
--- Comment #1 from igor at roundbox dot com 2007-05-21 16:45 ---
Created an attachment (id=13596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13596action=view)
Simple test code to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|major |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
--- Comment #29 from pluto at agmk dot net 2007-05-21 17:01 ---
(In reply to comment #28)
Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
vi-id instead of rhs.var = id
Remove the id variable declaration.
This would have only affected fortran
thx,
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-21 17:01
---
I've asked in comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5804a24398086e50/fd2b07668628a90d
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
--- Comment #16 from eweddington at cso dot atmel dot com 2007-05-21 17:03
---
Fails with 4.1.2.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #17 from eweddington at cso dot atmel dot com 2007-05-21 17:09
---
Fails on 4.2.0.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #5 from dave at boost-consulting dot com 2007-05-21 17:16
---
Just adding a throwing allocator (especially one that throws
randomly like this one) will not test the library guarantees anywhere
nearly as effectively as the STLPort tests do. The technique is
outlined in
--- Comment #18 from eweddington at cso dot atmel dot com 2007-05-21 17:17
---
Using the target specific option -mno-tablejump fixes the bug for 4.1.2 and
4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
--- Comment #30 from dberlin at gcc dot gnu dot org 2007-05-21 17:53
---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
On 21 May 2007 16:01:29 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #29 from pluto at agmk dot net 2007-05-21 17:01
--- Comment #6 from pcarlini at suse dot de 2007-05-21 18:12 ---
(In reply to comment #5)
Use this technique. In fact, if you can, use my code.
In fact, Howard already mentioned that, at some point. To be clear, and avoid
misunderstandings, I want to clearly state that I consider
--- Comment #26 from manu at gcc dot gnu dot org 2007-05-21 18:16 ---
Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment
in-place? If so, I will commit the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Comment #20 from manu at gcc dot gnu dot org 2007-05-21 18:32 ---
(In reply to comment #19)
I think we can safely at least remove the scary [regression] from the Summary:
first, thanks c++/30500 is now fixed and the warnings are always suppressed;
second, Manuel is splitting out
--
igor at roundbox dot com changed:
What|Removed |Added
Severity|normal |major
Component|middle-end |c++
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-21 19:08 ---
What options are you using to compile the test program? If you use -O2, then
you have an C/C++ aliasing violation in your code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
,objc' which are
not enough for what I prefer - but now it builds I can add some more options
back in.
So now my xgcc says this:
#gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/downloads/gcc-4_3-trunk/configure
Thread model: posix
gcc version 4.3.0 20070521
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 19:09 ---
Also if only 4.0.x is broken, then this is fixed as 4.0.x is no longer being
maintained.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
--- Comment #4 from igor at roundbox dot com 2007-05-21 19:17 ---
Sorry, I should've mentioned that - no -O2, here is my command line:
g++ -g test_128.cpp -o test_128
And yes, this does seem to be specific to 4.0.x only - gcc 4.1 works fine.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-21 19:49 ---
So closing as fixed as 4.0.x is no longer being maintained.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-21 20:07 ---
Confirmed by majority vote.
$ ifort -warn all pr25095.f90
fortcom: Error: pr25095.f90, line 2: This expression cannot be evaluated.
[MODULO]
DATA (i(MODULO(j,5)),j=1,4) /4*0/
^
fortcom: Info: pr25095.f90,
--- Comment #11 from elizabeth dot l dot yip at boeing dot com 2007-05-21
20:10 ---
Ignore Comment #10. I resubmitted my test case as a new bug (31994) last
Friday. The bug is fixed this morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-05-21 20:16
---
The testcase of comment #7 seen through valgrind:
pr25252.f90:3.26:
module procedure X, Y,
1
Error: Syntax error in MODULE PROCEDURE statement at (1)
==12169== Invalid read of size 2
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict
-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada
-I.
./../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../../gcc/gcc/../l
ibcpp/include -I../../gcc/gcc/../libdecnumber
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-05-21 20:24
---
Can this be considered fixed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rolf dot ebert dot gcc at gmx dot de 2007-05-21 20:35
---
Created an attachment (id=13597)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13597action=view)
Bernd's patch that fixes the problem
Bernd's patch as mentioned in comment #16
--
--- Comment #2 from rob1weld at aol dot com 2007-05-21 21:05 ---
The BUG is somewhere in here:
I put back ALL my origonal (lengthy) configure options but left off the
checking. It gets past the ICE. That is not good though...
Situation A): The checker is working fine and the code
--- Comment #6 from hjl at lucon dot org 2007-05-21 21:10 ---
This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
if Linux/ia32 is also miscompiled.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #7 from hjl at lucon dot org 2007-05-21 21:19 ---
(In reply to comment #6)
This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
if Linux/ia32 is also miscompiled.
Tonto is also miscompiled on Linux/ia32.
--
--- Comment #8 from hjl at lucon dot org 2007-05-21 21:36 ---
According to the comment, before the change, we performed
[evaluate loop bounds and step]
count = (to + step - from) / step;
dovar = from;
for (;;)
{
body;
cycle_label:
dovar += step
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-21 21:41 ---
(In reply to comment #6)
This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
if Linux/ia32 is also miscompiled.
Can you file a new bug rather than reopening this one (mark it as blocking
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from hjl at lucon dot org 2007-05-21 21:54 ---
(In reply to comment #9)
(In reply to comment #6)
This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
if Linux/ia32 is also miscompiled.
Can you file a new bug rather than reopening this one
--- Comment #2 from janis at gcc dot gnu dot org 2007-05-21 22:17 ---
Subject: Bug 31924
Author: janis
Date: Mon May 21 21:17:23 2007
New Revision: 124913
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124913
Log:
libcpp/
PR c/31924
* expr.c
--- Comment #2 from bliss1940-bbs at yahoo dot com 2007-05-21 22:18 ---
(In reply to comment #1)
I don't think I said GCC was in error, but just different.
Maybe we can come to an agreement here, or maybe not. Let's see.
I certainly would expect the ARM7 would prefer that 4 byte
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 22:24 ---
(In reply to comment #2)
To beat a dead horse again, the data members are suitably aligned in
Microsoft's struct. For the GNU folk to say the extra padding is for data
alignment or is an ABI issue is misleading
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-21 22:37 ---
Related report: PR26976
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32002
1 - 100 of 128 matches
Mail list logo
