--- Comment #16 from rakdver at kam dot mff dot cuni dot cz 2007-07-29
06:33 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
rakdver at kam dot mff dot cuni dot cz writes:
rakdver Probably the problem is that -maltivec does not
rakdver imply
--- Comment #17 from rakdver at kam dot mff dot cuni dot cz 2007-07-29
07:16 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
rakdver Probably the problem is that -maltivec does not
rakdver imply -mabi=altivec, or some similar omission.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-29 08:10
---
(In reply to comment #5)
I have had a quick look and the cause of failures are quite different.
Could you please attach the files
/opt/gcc/darwin_buildl/gcc/testsuite/gfortran/gfortran.sum and
--- Comment #5 from dominiq at lps dot ens dot fr 2007-07-29 08:01 ---
If you were expecting to be kept buzzy, you'll be glad! The summary is:
=== gfortran Summary for unix/-fdefault-integer-8//-m32 ===
# of expected passes18575
# of unexpected failures750
# of
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-29 08:59 ---
Created an attachment (id=13996)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13996action=view)
log and sum files for the tests with -fdefault-integer-8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-07-29 08:39 ---
I think I understand what's wrong with my patch now: The
stream initialized with init_error_stream was never flushed.
I think I'll go with a naked write() call, which is
a) simpler
b) more robust.
--
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-29 09:24 ---
Considering the number of failures to analyse, I think there is need to avoid
duplicate efforts. What is the best way to proceed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-07-29 09:47
---
(In reply to comment #8)
Considering the number of failures to analyse, I think there is need to avoid
duplicate efforts. What is the best way to proceed?
I've started a x86_64-linux testsuite with
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 10:01 ---
Subject: Bug 32879
Author: dfranke
Date: Sun Jul 29 10:01:27 2007
New Revision: 127037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127037
Log:
2007-07-29 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #4 from doko at gcc dot gnu dot org 2007-07-29 10:10 ---
Subject: Bug 32929
Author: doko
Date: Sun Jul 29 10:09:54 2007
New Revision: 127038
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127038
Log:
2007-07-29 H.J. Lu [EMAIL PROTECTED]
PR libgcj/32929
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-29 10:49 ---
Subject: Bug 32879
Author: dfranke
Date: Sun Jul 29 10:49:11 2007
New Revision: 127042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127042
Log:
2007-07-29 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-29 10:50 ---
Documented in 4.2 and trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-29 11:09 ---
The following test cases fail only with -m64, but not, or differently, with
-m32.
FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test
FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution
--- Comment #12 from dominiq at lps dot ens dot fr 2007-07-29 11:11 ---
Created an attachment (id=13998)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13998action=view)
test case failing with -m32, but not, or differently, with -m64
--
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-29 11:21 ---
(In reply to comment #7)
(In reply to comment #3)
This is OK to commit.
FX,
In developing the testcase, I found out that this version of the patch is wrong
- change 'f=0' to 'f=42' to see what I mean (look at
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-29 11:08 ---
Created an attachment (id=13997)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13997action=view)
Failures on PPC Darwin8 common to -m32 and -m64
I attached the reduced list of the test cases failing with -m32
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-07-29 11:19
---
From your testresults, Dominique, I see the following testcases ICE:
gfortran.dg/altreturn_5.f90
gfortran.dg/associated_2.f90
gfortran.dg/bounds_check_5.f90
gfortran.dg/char_associated_1.f90
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-29 11:44 ---
I have already started to investigate gfortran.dg/forall_4.f90. With -m32 it
does not ICE but abort due to the line
forall (i=1:n, .not. s(i)) a(i) = i
the '.not.' seems to be the problem (the corresonding
--- Comment #18 from dje at watson dot ibm dot com 2007-07-29 11:57 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
rakdver at kam dot mff dot cuni dot cz writes:
it's on ppc-linux.
rakdver I mean, I did the testing on ppc-linux; it is possible that
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-29 12:21 ---
gfortran.dg/associated_2.f90
gfortran.fortran-torture/execute/intrinsic_associated.f90
gfortran.fortran-torture/execute/intrinsic_associated_2.f90
ICE with the same kind of error (cannot get any backtrace):
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|rakdver at kam dot mff dot |
|cuni dot cz |
--- Comment #16 from dominiq at lps dot ens dot fr 2007-07-29 12:33 ---
gfortran.dg/bounds_check_5.f90
gfortran.dg/char_associated_1.f90
gfortran.dg/der_array_1.f90
gfortran.dg/ret_pointer_1.f90
ICE as associated_2_db:
bounds_check_5_db.f90:16: internal compiler error: in
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-07-29 12:44
---
(In reply to comment #14)
Program exited with code 04.
(gdb) backtrace
No stack.
You need to backtrace f951 (which is the compiler proper) instead of gfortran
(which is only the driver). Use gfortran -v
--- Comment #18 from dominiq at lps dot ens dot fr 2007-07-29 12:59 ---
You need to backtrace f951
Yes indeed: I did
gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951
I have also noticed that I don't have any entry for today
in~/Library/Logs/CrashReporter/, while I
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 13:01 ---
This is accepted:
$ cat pr32881.f90
program foo
integer :: i = 42
print *, bar()
contains
pure integer function bar ()
bar = i
end function
end program
--
dfranke at gcc dot gnu dot org changed:
--- Comment #20 from dominiq at lps dot ens dot fr 2007-07-29 13:26 ---
And did you set a breakpoint on fancy_abort?
If it has to be done explicitely, the answer is no. Doing it I get:
(gdb) break fancy_abort
Breakpoint 1 at 0xbf4ec: file ../../gcc-4.3-20070727/gcc/diagnostic.c, line
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2007-07-29 13:11
---
(In reply to comment #18)
gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951
And did you set a breakpoint on fancy_abort? ICE can be due either to GCC
catching a segfault signal (in which case,
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-29 14:18 ---
Subject: Bug 32906
Author: dfranke
Date: Sun Jul 29 14:17:59 2007
New Revision: 127043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127043
Log:
gcc/fortran:
2007-07-29 Daniel Franke [EMAIL PROTECTED]
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 ---
Thanks for the report!
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-29 14:19 ---
Closing, take II.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:45 ---
Fixed on trunk with correction to be unity rather than zero based.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from tkoenig at gcc dot gnu dot org 2007-07-29 14:57
---
As a side question, this PR has open some kind of Pandora box in which some
failures are directly related to this PR, but probably many others are not.
Would not it be wise to open a meta bug for
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 ---
Subject: Bug 31211
Author: pault
Date: Sun Jul 29 14:44:03 2007
New Revision: 127044
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044
Log:
2007-07-29 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-29 14:44 ---
Subject: Bug 32682
Author: pault
Date: Sun Jul 29 14:44:03 2007
New Revision: 127044
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127044
Log:
2007-07-29 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-29 14:47 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-29 15:14 ---
I would be curious to hear from
Zdenek: is there something that could be done in the loop optimizer dealing
generally with this common patterns?
Not at the moment. It would be possible to implement this
--- Comment #3 from pcarlini at suse dot de 2007-07-29 15:21 ---
Ok, Zdenek, thanks a lot anyway...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
--- Comment #8 from jb at gcc dot gnu dot org 2007-07-29 15:58 ---
I had a look at your patch, and one thing which looks worrying is the use of
sprintf all over the place. That's just a recipe for buffer overflows,
especially when combined with %s formatting.
I think Tobi's suggestion
--- Comment #1 from info at umfragen-service dot de 2007-07-29 16:12
---
Konsole:
=
[EMAIL PROTECTED]:/mnt/sda1_removable/avr/gcc_schlecht# make
begin
* Individual makefile for AvrLiveCD
*
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-07-29 16:33 ---
Created an attachment (id=13999)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13999action=view)
Patch (current status)
This patch is currently bootstrapping on my machine.
Let's see how it works.
--
I think the following is different enough from PR32770 to justify a new PR. As
reported,
gfortran.dg/forall_4.f90 and gfortran.dg/where_operator_assign_2.f90 give an
ICE
when compiled on darwin8 with both -fdefault-integer-8 and -m64 (see
PR32770#20) fo a backtrace.
The following reduced codes
--- Comment #2 from ammonton at cc dot helsinki dot fi 2007-07-29 17:53
---
The INSTALL directory only has a README saying the instructions are generated
from gcc/doc/install.texi and the install.texi2html script in that directory
complains about a missing file gcc-vers.texi which I
/usr/local/gcc43/lib/gcc/i686-pc-cygwin/4.3.0/../../../libssp.a(ssp.o):ssp.c:(.t
ext+0x190): multiple definition of `___stack_chk_fail'^M
/cygdrive/c/Temp/ccrBTHWE.o:ssp-2.c:(.text+0x0): first defined here^M
collect2: ld returned 1 exit status^M
function declaration in testsuite conflicts with
--- Comment #27 from tprince at computer dot org 2007-07-29 18:00 ---
same failure for gcc-4.3 mainline on i686-pc-cygwin
--
tprince at computer dot org changed:
What|Removed |Added
--- Comment #10 from patchapp at dberlin dot org 2007-07-29 18:55 ---
Subject: Bug number PR 32858
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-07/msg02070.html
--
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-29 19:35 ---
Note that the ICEs with -m64 diasppear with -O3, but then both tests fail to
execute.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01
---
Subject: Bug 32858
Author: tkoenig
Date: Sun Jul 29 20:01:45 2007
New Revision: 127049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049
Log:
2007-07-29 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-29 20:01 ---
Subject: Bug 30814
Author: tkoenig
Date: Sun Jul 29 20:01:45 2007
New Revision: 127049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127049
Log:
2007-07-29 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #1 from tprince at computer dot org 2007-07-29 20:15 ---
This test is reported failing also by anonymous testers of
powerpc-apple-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
--- Comment #5 from tprince at computer dot org 2007-07-29 20:57 ---
No longer relevant, due to changes in gfortran.
--
tprince at computer dot org changed:
What|Removed |Added
--- Comment #2 from tprince at computer dot org 2007-07-29 20:54 ---
The suggested function name change is in mainline, and this resolves the bug.
--
tprince at computer dot org changed:
What|Removed |Added
--- Comment #8 from tprince at computer dot org 2007-07-29 21:02 ---
The patch discussed here was incorporated in mainline, and the failure was last
reported 20070420.
--
tprince at computer dot org changed:
What|Removed |Added
--- Comment #6 from andreast at gcc dot gnu dot org 2007-07-29 21:24
---
install-binPROGRAMS: install-toolexeclibLTLIBRARIES 'overwrites' the
install-binPROGRAMS generated by automake. So this is a no go.
I helped myself with this one:
Index: Makefile.am
--- Comment #3 from drow at gcc dot gnu dot org 2007-07-29 21:34 ---
Damn, I couldn't find this bug when I searched for it Saturday morning, so I
spent all day reducing the testcase...
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-07-29 23:23
---
The patch applied in Comment #11 fixes the original test case.
The modified test case in Comment #8 is still broken.
pr31609-2.f90: In function master.0.j:
pr31609-2.f90:10: internal compiler error: in
Simplification of the ICE with nan_1.f90:
$ !cat
cat nan_6.f90
program test
real :: a
if (min(a, 3.0, 2.0) /= 2.0) call abort
end program test
$ gfortran -fdefault-integer-8 nan_6.f90
nan_6.f90: In function 'MAIN__':
nan_6.f90:3: internal compiler error: in simplify_subreg, at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
Maybe this isn't a bug, but I can't see why this shouldn't at least be a
warning since it changes the output of the program...
==C++ Source with B.print not const
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-30 02:19 ---
Well it is valid as B::print hides A::print.
Try doing:
#include iostream
class A {
public:
virtual char * print() const { return A\n;}
virtual ~A(){};
};
class B : public A {
public:
virtual char *
59 matches
Mail list logo
