--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-07-30 06:11
---
Fixed on trunk. Closing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
--- 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
class A {
public:
virtual char * print() const { return "A\n";}
virtual ~A(){};
};
class B : public A {
public:
virtual char * print() { r
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
class A {
public:
virtual char * print() const { return "A\n";}
virtual ~A(){};
};
--
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
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
simplify-rtx.c
--- 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 gfc_co
--- 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 #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 #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 #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 #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 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=gcc&view=rev&rev=127049
Log:
2007-07-29 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- 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=gcc&view=rev&rev=127049
Log:
2007-07-29 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- 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 #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
--
http://gcc.gnu.org/bugzilla/
--- 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
--
/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 fun
--- 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 gat
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 yi
--- 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=13999&action=view)
Patch (current status)
This patch is currently bootstrapping on my machine.
Let's see how it works.
--
tkoe
--- 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
* Avr-Gcc
--- 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 t
--- 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 #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 optim
--- 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 -fdefault
--- 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
Stat
--- 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 #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=gcc&view=rev&rev=127044
Log:
2007-07-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=127044
Log:
2007-07-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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
Statu
--- 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 #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=gcc&view=rev&rev=127043
Log:
gcc/fortran:
2007-07-29 Daniel Franke <[EMAIL PROTECTED]>
--- 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 #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 #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 h
--- 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 #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 simplify_subr
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|rakdver at kam dot mff dot |
|cuni dot cz |
AssignedTo|unassi
--- 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):
associa
--- 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
--- 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 output
--- 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 #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
gfortran.dg/der_arr
--- 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=13998&action=view)
test case failing with -m32, but not, or differently, with -m64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- 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 te
--- 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=13997&action=view)
Failures on PPC Darwin8 common to -m32 and -m64
I attached the reduced list of the test cases failing with -m32
--- 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 #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=gcc&view=rev&rev=127042
Log:
2007-07-29 Daniel Franke <[EMAIL PROTECTED]>
Backp
--- 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=gcc&view=rev&rev=127038
Log:
2007-07-29 H.J. Lu <[EMAIL PROTECTED]>
PR libgcj/32929
--- 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=gcc&view=rev&rev=127037
Log:
2007-07-29 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- 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 -fdefault
--- 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 #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=13996&action=view)
log and sum files for the tests with -fdefault-integer-8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3277
--- 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.
--
http://g
--- 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
/opt/gcc/darwin_b
--- 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 expe
--- 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.
> >
> >
59 matches
Mail list logo
