--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-07-02 06:08
---
*** This bug has been marked as a duplicate of 40347 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-07-02 06:08
---
*** Bug 40611 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tsyvarev at ispras dot ru 2009-07-02 06:16 ---
gcc --version gets:
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Yes, problem very probably target dependent - as I said, test suite was
executed on many other machines, including IA64 arhictecures with
Compile the attached source code with options -march=armv5te -mthumb -Os
-fno-exceptions, gcc generates:
push{r4, lr}
sub sp, sp, #8
add r4, sp, #4// redundant
mov r0, r4// add r0, sp, 4
bl _ZN1XC1Ev
mov r0, r4
--- Comment #1 from carrot at google dot com 2009-07-02 07:39 ---
Created an attachment (id=18120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18120action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-02 08:53 ---
This looks like one of those rematerialization problems albeit with the stack
pointer this time.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-02 09:15 ---
Is there a C test case? Can you add objdump of the gcc-generated asm and the
fixed asm to show the impact on code size? (/me is surprised that 3*add
r0,sp,4 is smaller than 1**add r0,sp,4+3*mov r0,r4... Thumb is
--- Comment #8 from paolo dot carlini at oracle dot com 2009-07-02 09:29
---
Richard, can you please have a quick look? I don't have any ia64 machine
available and the problem can't reproduce for me on x86_64 with 4_3/4_4/4_5
--
paolo dot carlini at oracle dot com changed:
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-02 09:39 ---
(In reply to comment #3)
Is there a C test case? Can you add objdump of the gcc-generated asm and the
fixed asm to show the impact on code size? (/me is surprised that 3*add
r0,sp,4 is smaller than 1**add
--- Comment #4 from hubicka at ucw dot cz 2009-07-02 10:05 ---
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
Would you mind seeing if your patch was the same?
I wanted to prevent the (set pc pc) trick, but this seems like easier fix
for the problem :)
Honza
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-02 10:07
---
Today, with 149169, I can't reproduce this problem. By the way, I suspect an
ICE or something similar was happening, definitely wrong categorization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
--- Comment #10 from paolo dot carlini at oracle dot com 2009-07-02 10:08
---
Thanks Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
--- Comment #13 from hubicka at ucw dot cz 2009-07-02 10:10 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
OK, on i386 it has some effect according to our nightly tester
it is 3524421-3510754. The size used to be as low as 3431090
so it is just small
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 10:05 ---
I can reproduce it, the abort is from the system libunwind:
(gdb) run
Starting program: /tmp/a.out
Executing test_4_10()
#0 0xa0010721 in __kernel_syscall_via_break ()
#1 0x20422940 in
There are some new 1.5 PrintStream constructors that are in GNU Classpath but
not in the local gcj version of the same file. This causes the OpenJDK7 b62
build to fail:
/mnt/builder/icedtea/bootstrap/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=1536
-J-XX:-PrintVMOptions
--- Comment #11 from tsyvarev at ispras dot ru 2009-07-02 11:26 ---
Ok, sorry for noise. I'll try with libunwind.
Only thing - what does it mean
invalid testcase because you make libunwind fail by setrlimit.
Does it mean that setrlimit shouldn't be used with new operator? or with
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-02 11:30 ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00091.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 11:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 11:37 ---
Jakub should maybe know more ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from marek dot rouchal at infineon dot com 2009-07-02 11:46
---
(In reply to comment #5)
What you want is --with-cpu=default32 for x86_64 which does not exist yet. It
does for powerpc64 though.
I'd like to ping this request once again - it seems that there was no
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-02 11:40
---
Apparently, HJ can't reproduce it either:
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00122.html
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-02 11:57 ---
For a 32-bit-default compiler that can also build 64-bit code, configure
for i686-pc-linux-gnu with --enable-targets=all. (Set CC=gcc -m32
and CC_FOR_BUILD=gcc -m32 in your environment and configure
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 ---
Subject: Bug 40585
Author: rguenth
Date: Thu Jul 2 12:15:27 2009
New Revision: 149172
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149172
Log:
2009-07-02 Richard Guenther rguent...@suse.de
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 ---
Subject: Bug 40585
Author: rguenth
Date: Thu Jul 2 12:16:39 2009
New Revision: 149173
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149173
Log:
2009-07-02 Richard Guenther rguent...@suse.de
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 12:17 ---
Fixed on the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--
rguenth 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 #5 from burnus at gcc dot gnu dot org 2009-07-02 12:36 ---
call output (p1, p2, p3, p4)
That still clobbers p1, p2, p3, and p4 as they are passed by reference so
is it really undefined code if output changes the values for the do loop?
Yes.
Revision 149170:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00046.html
breaks bootstrap on Linux/ia32:
/export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/
when flex is not installed, configure detects that flex is not installed but
doesn't emit an error.
Flex is required to build gcc-4.5 (to produce gengtype-lex.c).
So, if no flex, no gcc :-)
YC
--
Summary: when flex is not installed, gcc build stop because of a
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 13:46 ---
For 4.5 you mean?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-02 13:51 ---
(In reply to comment #1)
For 4.5 you mean?
Yes. Only on Linux/ia32. Linux/x86-64 passed that failure
point.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from marek dot rouchal at infineon dot com 2009-07-02 13:52
---
(In reply to comment #8)
For a 32-bit-default compiler that can also build 64-bit code, configure
for i686-pc-linux-gnu with --enable-targets=all. (Set CC=gcc -m32
and CC_FOR_BUILD=gcc -m32 in your
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 14:24 ---
Thus, please somebody attach genmodes.i that is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-02 14:31 ---
Ok, I see it with stage3 only :(
build/genmodes tmp-modes.c
/bin/sh: line 1: 16996 Segmentation fault build/genmodes tmp-modes.c
make[3]: *** [s-modes] Error 139
make[3]: *** Waiting for unfinished jobs
--- Comment #7 from hjl dot tools at gmail dot com 2009-07-02 14:36 ---
(In reply to comment #6)
Ok, I see it with stage3 only :(
build/genmodes tmp-modes.c
/bin/sh: line 1: 16996 Segmentation fault build/genmodes tmp-modes.c
make[3]: *** [s-modes] Error 139
make[3]: ***
templatetypename U struct X {};
templatetypename T auto f(T t) - Xdecltype(t+1) {}
templatetypename T auto g(T t) - Xdecltype(t+1) {}
Compiling with -std=c++0x gives
decltype_ice.cc:4:52: internal compiler error: Segmentation fault: 11
--
Summary: [c++0x] ICE on repeated decltype
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-02 14:16 ---
Hm, I'm into stage2 and genmodes was already built and executed fine - so,
I don't seem to be able to reproduce it right now.
How did you configure? I did
/space/rguenther/tramp3d/trunk/configure
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|4.4.0 |4.5.0
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-02 13:56 ---
Ok, I'm trying to reproduce and get genmodes.i.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--- Comment #7 from heydowns at borg dot com 2009-07-02 14:46 ---
Created an attachment (id=18121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18121action=view)
Proposed fix: Changes linking on solaris based on std=X and implements escapes
in braced specs
Attaching a fix that
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 14:55 ---
Hmm, building genmodes.o with -save-temps makes the segfault go away...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 14:59
---
Jason, can you have a look to this one? Thanks in advance!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 15:01 ---
Ok, i have an idea.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from aldot at gcc dot gnu dot org 2009-07-02 15:05 ---
Important reminder from steven from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828#c13
stevenb GCC should not hoist up further than up to the first common dominator.
i.e. ..can be Hoisted to B from #3
and _not_
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-02 15:07 ---
Restricting can be done via casting to volatile - then it is only
*(volatile int *)i
That needs then to be applies in all expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-02 14:44 ---
Michael Matz fixed that for allocatable arrays, but the patch needs to be
extended to nonallocatable arrays, cf.
http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
--
--- Comment #9 from steven at gcc dot gnu dot org 2009-07-02 15:12 ---
Note I have various working patches for GVN-based hoisting. All of them are
actually too aggressive, causing failures in the vectorizer test cases
(unrecognizable data dependency patterns). But I still intend to
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-07-02 15:17 ---
If you are building an i686-pc-linux-gnu compiler you should start by
building i686-pc-linux-gnu binutils (configured --enable-64-bit-bfd)
and installing them in the same prefix in which you are going to install
GCC
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 15:29 ---
flex is only required to build svn checkouts or snapshots. Release tarballs
contain the generated files.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at gcc dot gnu dot org 2009-07-02 15:31 ---
Subject: Bug 32131
Author: matz
Date: Thu Jul 2 15:31:28 2009
New Revision: 149178
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149178
Log:
fortran/
PR fortran/32131
* trans-array.c
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40 ---
Dan, you mentioned a pointer_no_escape attribute. What was that about? I've
never seen that mentioned before (or a patch to implement it). Sounds like a
cool attribute to have (and not just for Fortran, too).
--
--- Comment #7 from rguenther at suse dot de 2009-07-02 15:46 ---
Subject: Re: Pointer does not really escape
with write
On Thu, 2 Jul 2009, steven at gcc dot gnu dot org wrote:
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40
---
Dan, you mentioned a
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-07-02 15:50
---
Subject: Bug 40617
Author: rguenth
Date: Thu Jul 2 15:50:26 2009
New Revision: 149179
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149179
Log:
2009-07-02 Richard Guenther rguent...@suse.de
PR
--- Comment #15 from jan at codejunky dot org 2009-07-02 16:26 ---
Same problem here on powerpc-32:
powerpc-unknown-linux-gnu-gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
GCC doesn't produce the correct assembler code when I use optimizations.
[code]
#include stdio.h
#define mulscale(a,d,c) \
({ int __a=(a), __d=(d), __c=(c); \
__asm__ __volatile__ (imull %%edx; shrdl %%cl, %%edx, %%eax \
: =a (__a), =d (__d) \
: a (__a), d (__d), c
--- Comment #16 from lucier at math dot purdue dot edu 2009-07-02 16:35
---
OK, so we've had several reliable reports that this bug still exists, but I'm
not high enough in the GCC bugzilla hierarchy to reopen this bug (I just
tried), perhaps Andreas or Jakub would like to do so.
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 16:37
---
debug/40462?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40620
--- Comment #1 from hunterggl at gmail dot com 2009-07-02 16:38 ---
Created an attachment (id=18122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18122action=view)
Test file
This a small fragment of code that causes problems
--
--- Comment #2 from hunterggl at gmail dot com 2009-07-02 16:39 ---
Created an attachment (id=18123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18123action=view)
Comparison of asm
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
--- Comment #5 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
*** This bug has been marked as a duplicate of 40462 ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from joel at gcc dot gnu dot org 2009-07-02 16:44 ---
*** Bug 40622 has been marked as a duplicate of this bug. ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from bergner at gcc dot gnu dot org 2009-07-02 16:48
---
Alan, do you have any ideas?
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-02 16:51 ---
For both mulscale and divscale you have ecx as an input register but nothing
marks it as being modified so GCC does not know that. It does not read the
template string to figure out what you had meant to say.
--
--- Comment #2 from ycollet at freesurf dot fr 2009-07-02 17:39 ---
It should be relatively easy to make configure emit an error when it can't find
flex. I have lost a couple of hours before figuring out that flex was missing.
YC
--
--- Comment #4 from hunterggl at gmail dot com 2009-07-02 17:46 ---
(In reply to comment #3)
For both mulscale and divscale you have ecx as an input register but nothing
marks it as being modified so GCC does not know that. It does not read the
template string to figure out what you
I'm in doubt about exact compiler info,
cause I want to report a bug from Gentoo bugzilla,
where reporter was using 4.3.2, but I could reproduce it
with 4.4.0.
We're both on x86.
It's http://bugs.gentoo.org/show_bug.cgi?id=276146.
A rather simple code fragment gets miscompiled,
but after making a
--- Comment #1 from galtgendo at o2 dot pl 2009-07-02 18:02 ---
Created an attachment (id=18124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18124action=view)
a testcase for the bug
As I said in the Gentoo bug,
one version of the 'area' line produces correct result,
other does
--- Comment #2 from galtgendo at o2 dot pl 2009-07-02 18:05 ---
Due to that 'printf' thing, it seems vaguely similar
to bug 39333, however here neither of the switches mentioned there
has an effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-02 18:05 ---
*** This bug has been marked as a duplicate of 40462 ***
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rth at gcc dot gnu dot org 2009-07-02 18:05 ---
*** Bug 40620 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
--- Comment #3 from galtgendo at o2 dot pl 2009-07-02 18:08 ---
Created an attachment (id=18125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18125action=view)
data for the test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
This is for gcc on w32 (windows). I have downloaded the MinGW installer and
installed gcc from that.
When doing
gcc -v
the resulting prefix for me is
On w32 this should include the drive letter otherwise it is totally useless. So
it should be
--prefix=c:/mingw
I also wonder if this is the
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-07-02 18:14 ---
Make sure to re-enable the commented out tests in
gfortran.dg/integer_exponentiation_4.f90. See:
http://gcc.gnu.org/ml/fortran/2009-06/msg00288.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-02 18:15
---
Complete.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from lennart dot borgman at gmail dot com 2009-07-02 18:16
---
Hm, something went wrong when sending the bug report. It should have said
When doing
gcc -v
the resulting prefix for me is
--prefix=/mingw
On w32 ... (the rest is correct)
--
lennart dot borgman
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-02 18:26
---
Can't reproduce in any active branch, thus already fixed for 4.5.0, 4.4.1,
4.3.4 (maybe 4.3.3 too).
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-02 18:27 ---
Since the output of gcc -v depends on how GCC was configured, this is not a bug
with GCC and really a bug with the way mingw's gcc was configured.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from lennart dot borgman at gmail dot com 2009-07-02 18:29
---
pinskia, please explain why you marked this bug as invalid!
--
lennart dot borgman at gmail dot com changed:
What|Removed |Added
--- Comment #4 from lennart dot borgman at gmail dot com 2009-07-02 18:31
---
Ah, sorry, I did not see your comment. Could you advice how the MinGW team
should configure the compilation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-02 18:32 ---
Because the FSF does not supply the binaries you are using so it is not a bug
with GCC rather than the way it was configured. when configuring with
--prefix=/mingw, it have to mean C:/mingw. Also GCC binaries are
--- Comment #6 from lennart dot borgman at gmail dot com 2009-07-02 18:34
---
Thanks, I see. How can one then figure out the include path that a user has?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
On x86_64-unknown-linux-gnu, revision 149190:
make -k check-gcc RUNTESTFLAGS=plugin.exp results in
Running gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
ERROR: tcl error sourcing gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp.
ERROR: can't read ld_library_path: no such
--- Comment #1 from tjruwase at google dot com 2009-07-02 18:48 ---
Created an attachment (id=18126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18126action=view)
Proposed Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
--- Comment #5 from galtgendo at o2 dot pl 2009-07-02 20:33 ---
It definitely doesn't work in 4.3.3.
I'll attach generated assembly.
--
galtgendo at o2 dot pl changed:
What|Removed |Added
--- Comment #6 from galtgendo at o2 dot pl 2009-07-02 20:35 ---
Created an attachment (id=18127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18127action=view)
this is correct assembly
...when 'printf' and '(x0*(y0+dy) - (x0+dx)*y0)'
--
--- Comment #7 from galtgendo at o2 dot pl 2009-07-02 20:37 ---
Created an attachment (id=18128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18128action=view)
this is the incorrect one
...with 'printf' and 'x0*y1-x1*y0'
Both with '-O2' (though -0 is enough).
--
--- Comment #8 from galtgendo at o2 dot pl 2009-07-02 20:42 ---
Though perhaps I didn't need to reopen.
Just making sure: could you reproduce it with one of
the mentioned versions ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-02 20:47
---
Yes, is not fixed in 4.3.3. Is already fixed for 4.3.4, etc.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
When compiled with -frename-registers, the TBA test case produces invalid
code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h
assumes it still has the value a in it. Compiling with
-fno-rename-registers results in valid code.
--
Summary: -frename-registers causes
--- Comment #1 from dj at redhat dot com 2009-07-02 21:41 ---
Created an attachment (id=18129)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18129action=view)
test case for the above
Compile with:
./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers
--
--- Comment #2 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18130action=view)
resulting .s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #3 from dj at redhat dot com 2009-07-02 21:42 ---
Created an attachment (id=18131)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18131action=view)
dump just before rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #4 from dj at redhat dot com 2009-07-02 21:43 ---
Created an attachment (id=18132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18132action=view)
dump just after rnreg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
--- Comment #7 from rogermc at iinet dot net dot au 2009-07-02 22:58
---
Although this program compiled OK under g77 it failed under gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-02 23:17 ---
(In reply to comment #7)
Although this program compiled OK under g77 it failed under gfortran.
Please attach a tarball with all the files need to reproduce the failure,
or us to a URL where we can get the original
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:41 ---
We can add an option Wunused-result that controls the warnings.
Wno-unused-result and -Werror=unused-result will then work as expected.
Index: gcc/c-common.c
1 - 100 of 108 matches
Mail list logo
