gfortran 4.1.2/4.2.0/4.3.0 segfaults when compiling the following program:
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 0.0d0, 0.0d0, 0.0d0 /)
real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0
end program initbug
Valgrind
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-03 07:39 ---
I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed
code gives a wrong answer:
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0,
typedef __SIZE_TYPE__ size_t;
extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...)
throw ();
extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...)
throw ();
fails to compile with:
/tmp/4.C:3: error: declaration of 'int __sprintf_chk(char*, int,
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-03 09:34 ---
I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed
code gives a wrong answer:
For me (4.3.0 20070903, r128037, x86_64-unknown-linux-gnu) both examples cause
a segmentation fault
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 09:43 ---
If I try to regtestify the code (uncomment the commented line):
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /)
real(kind=8),parameter
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:04
---
(In reply to comment #3)
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it?
I don't think we've touched anything who should affect this since
--- Comment #5 from joerg dot richter at gedas dot de 2007-09-03 10:05
---
Subject: AW: [SPAM Verdacht] - gfortran 4.3.0 doesn't
work on Windows Vista. - Bayesian Filter detected spam
Dear Sir,
I am sending You the output generated by gfortran 4.3.0 (Version
20070813)using
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-03 10:12 ---
The following does not ICE for me and produces the right result (note the extra
+0.0):
real,parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0 /) +1.0
analogously for (note extra (...)):
real,parameter ::
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:25
---
The output you posted shows that you have gfortran-4.3.0 in your path but you
also have a f951 binary coming from a G95 installation (it says: G95 Fortran
95 version 4.0.3 (g95 0.90!) Jul 27 2006). What happens
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:40
---
(In reply to comment #0)
I'm trying to run gfortran under Windows Vista.
Do you compile yourself or use pre-made binaries (and which binaries)? What
version of gfortran do you use? If you build the compiler
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:42
---
Unless this is a regression, won't be fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:44
---
The Fortran part has its PR, I saw a PR for some C problem also, so I'm closing
this. If other you experience other powerpc regressions, please open new PRs.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-03 11:01 ---
I confirm that
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /)
real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0d0 /) + 1.0d0
+++ This bug was initially created as a clone of Bug #33283 +++
[18:22] apinski
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] apinski new failure
[18:23] apinski on ppc-linux-gnu
[18:23] apinski between 127935 and 128000
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-03 11:17 ---
Closing as offtopic stuff was added again.
Maybe I should mention something about 4.2.x, gentoo also decided to use it :).
And it is not a bad release, 4.2.1 is much better. If glibc does not build
with 4.2.1,
I triggered this is the inner loop of the CPU emulation code of openMSX
(http://openmsx.sf.net/). I tried to reduce the code. Below is the smallest
code I could come with up that still shows the problem:
---
struct Clock {
void f();
void add(unsigned n) {
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 11:28 ---
# VUSE tab_56, SMT.9_58, SMT.10_60
D.2581_35 = this_2(D)-D.2503.a;
D.2582_36 = (unsigned int) D.2581_35;
D.2583_37 = D.2582_36 + 2;
D.2584_38 = (int) D.2583_37;
# tab_76 = VDEF tab_56
# SMT.9_77 = VDEF
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 11:31
---
(In reply to comment #4)
Seemingly, the array range x0(n0-1:1:-1) does not get properly simplified and
thus -value.real points to the nirvana.
Nope. I get an ICE for the following testcase:
real, parameter
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-03 12:01 ---
The problem is that forwprop doesn't propagate addr_exprs to memory reference
stmts in early optimization anymore (due to the volatile issues) and
value numbering cannot deal with the different (but same)
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-09-03 12:04
---
Created an attachment (id=14152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14152action=view)
Proposed patch
It was indeed my fault, sorry. When doing a 32x32-64 multiplication,
CONST_INTs are
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 12:04 ---
That is, rtl level DSE removes the dead store:
_ZN3CPU7executeEv:
.LFB5:
pushq %rbx
.LCFI0:
movq%rdi, %rbx
leaq8(%rdi), %rdi
call_ZN5Clock1fEv
.p2align 4,,10
--- Comment #7 from pcarlini at suse dot de 2007-09-03 12:09 ---
Fixing the second ICE.
--
pcarlini at suse dot de changed:
What|Removed |Added
the optimizer skips a function call that should not be skipped.
--
Summary: optimizer optimizes out a piece of code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
--- Comment #1 from nicolas at dyalog dot com 2007-09-03 12:26 ---
Created an attachment (id=14153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14153action=view)
preprocessed source of a repro
Sorry guys the repro is a bit complicated but i could NOT narrow it down any
further.
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-03 13:05
---
Looks ok on PowerPC Darwin. 16 passes. I tested on top of 128028.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 13:10 ---
The test case works:
[karma] gcc/darwin_buildw% ../gcc4.3w/bin/gcc -O
../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c
../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c: In function
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-09-03 13:24 ---
this report is quite old, but worth to pop :
We found similar problems with implicit memory block copying when using struct
copying by value. (frequent in C++ )
Softfloat architectures making a very extensive use of
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-03 13:43 ---
It is not bogus. -fprofile-arcs is one way of introducing .ctors stuff.
When building crtstuff, if it is supposed to work, you must avoid all options
that generate such stuff, whether it is -fprofile-arcs,
--- Comment #5 from michelin60 at gmail dot com 2007-09-03 13:49 ---
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does
--- Comment #2 from nicolas at dyalog dot com 2007-09-03 14:07 ---
after a bit more work it seems optimized out because diff64() doesn't observe
strict aliasing...
that was tricky because it was not the diff64() code that was snipped out but
TimeValToFileTime()...
I think the compiler
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:09
---
(In reply to comment #5)
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:11
---
And please stop CCing people! I'm taking care of this bug, and there really is
no need to bother other people by sending them copies of all
comments/investigation we exchange on the issue.
--
fxcoudert at gcc
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-03 14:25 ---
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND,
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-03 14:36 ---
I have a patch that makes it work apart from the tree level DSE issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #119 from rguenth at gcc dot gnu dot org 2007-09-03 15:20
---
*** Bug 33292 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 15:20 ---
The cast to (void *) disables the alias warning. This was done on purpose, so
it's unfortunate that this in some cases makes debugging harder.
*** This bug has been marked as a duplicate of 21920 ***
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.2.1
# of expected failures 169
# of untested testcases 35
# of unsupported tests 412
/opt/gcc/darwin_buildw/gcc/xgcc version 4.3.0 20070903 (experimental) (GCC)
That's the normal unexpected failures/successes on Darwin8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36
---
Subject: Bug 33290
Author: rsandifo
Date: Mon Sep 3 15:35:52 2007
New Revision: 128048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128048
Log:
gcc/
PR middle-end/33290
* optabs.c
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36
---
Thanks to Andreas and Dominique for the testing. Now applied to 4.3.
Sorry to everyone for the breakage.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mec at google dot com 2007-09-03 15:47 ---
DR 354 has been in state WP since October 2005. Is that good enough to
unsuspend this issue?
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#354
--
mec at google dot com changed:
What
--- Comment #4 from nicolas at dyalog dot com 2007-09-03 16:08 ---
That's what I feared I have lots of those in my code...
Thanks for the quick reply anyway =)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-03 16:24 ---
I see.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-09-03 16:35 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:44
---
Subject: Bug 31675
Author: fxcoudert
Date: Mon Sep 3 16:44:15 2007
New Revision: 128050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128050
Log:
PR fortran/31675
* libgfortran.h: New
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:47
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
I use std::inner_product() to do the vector multiplication when performing
matrix multiplication. This involves calling std::inner_product() within 2
nested loops (one across all rows, one across all columns). Unfortunately,
g++-4.1.2 will not, it seems, inline the call even at -O5. If I
--- Comment #2 from simon dot marshall at misys dot com 2007-09-03 16:54
---
This is also true of 4.2.1. Sorry if I have missed something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
--- Comment #1 from pcarlini at suse dot de 2007-09-03 17:20 ---
Note, in GCC any -Ox, x 3 is identical to -O3.
Anyway, I think we can safely add inline to std::accumulate and
std::inner_product.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-09-03 17:29 ---
DR 354 has been in state WP since October 2005. Is that good enough to
unsuspend this issue?
Yes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compile with -O2 -fno-strict-aliasing, fails on amd64 and alpha at least.
Doesn't fail with -fno-tree-vrp. Seems to be related to bug 32575. Breaks
linux kernel in many places (this asm is used with prefetch instruction).
struct T { void *p; } *t;
int main (void)
{
struct T *a;
a = t;
--- Comment #2 from paolo at gcc dot gnu dot org 2007-09-03 17:48 ---
Subject: Bug 33293
Author: paolo
Date: Mon Sep 3 17:48:31 2007
New Revision: 128053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128053
Log:
2007-09-03 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-09-03 17:50 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
The following code produces the error
internal compiler error: in fold_convert, at fold-const.c:2626
when compiled with GCC trunk rev. 128037:
module A
type A_type
real comp
end type
end module A
module B
contains
function initA()
use A
implicit none
type(A_type)::
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05 ---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
t.cc:12: error: 'namespace C1 { }' redeclared as different kind of symbol
t.cc:2: error: previous declaration of 'class C1'
--
--- Comment #1 from jaydub66 at gmail dot com 2007-09-03 18:05 ---
The error is also killed by
A_var = initA()
Sorry. The error is killed by *removing* this line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
--- Comment #2 from fang at csl dot cornell dot edu 2007-09-03 18:11
---
Subject: Re: namespace hides class definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05
---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-09-03
18:13 ---
This bug is invalid because asm() does NULL pointer dereference, thus
triggering undefined behavior.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed
--- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 ---
it looks we are talking about different bugs, the error I get is different:
../src/a.cpp:26: error: 'C1' does not name a type
where the line 26 is the following:
C1 c;
--
--- Comment #4 from fang at csl dot cornell dot edu 2007-09-03 18:19
---
Subject: Re: namespace hides class definition
--- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 ---
it looks we are talking about different bugs, the error I get is different:
--- Comment #4 from patchapp at dberlin dot org 2007-09-03 19:05 ---
Subject: Bug number PR33253
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-09/msg00153.html
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:27
---
Subject: Bug 33253
Author: jvdelisle
Date: Mon Sep 3 19:27:48 2007
New Revision: 128056
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128056
Log:
2007-09-03 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:29
---
Subject: Bug 33253
Author: jvdelisle
Date: Mon Sep 3 19:29:17 2007
New Revision: 128057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128057
Log:
2007-09-03 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:32
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from ubizjak at gmail dot com 2007-09-03 20:07 ---
Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() from
gfc_trans_scalar_assign():
(gdb) bt
#0 fancy_abort (file=0xb322f0 ../../gcc-svn/trunk/gcc/fold-const.c,
line=2626,
function=0xb321d2
--- Comment #2 from aesok at gcc dot gnu dot org 2007-09-03 20:35 ---
Subject: Bug 28902
Author: aesok
Date: Mon Sep 3 20:35:10 2007
New Revision: 128059
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128059
Log:
PR target/28902
* config/avr/avr.h
--- Comment #3 from aesok at gcc dot gnu dot org 2007-09-03 21:04 ---
Subject: Bug 28902
Author: aesok
Date: Mon Sep 3 21:03:50 2007
New Revision: 128060
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128060
Log:
PR target/28902
* config/avr/avr.h
--- Comment #6 from eweddington at cso dot atmel dot com 2007-09-04 03:37
---
(In reply to comment #5)
Patch to document AVR progmem attribute:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01832.html
Now committed:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00159.html
This bug
--- Comment #13 from eweddington at cso dot atmel dot com 2007-09-04 03:46
---
Seems to be fixed in 4.2.1, at least. I haven't tried earlier releases.
Changing target milestone and closing bug.
--
eweddington at cso dot atmel dot com changed:
What|Removed
--- Comment #5 from eweddington at cso dot atmel dot com 2007-09-04 04:02
---
(In reply to comment #1)
Yes and this correct.
Andrew,
Are you saying that this bug is invalid? If so, then it needs to be closed as
such.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
-__cxa_atexit --disable-jvmpi
Thread model: posix
gcc version 4.3.0 20070903 (experimental) [trunk revision 128061] (GCC)
COLLECT_GCC_OPTIONS='-B/home/ddaney/gccsvn/trunk-build/gcc/' '-v' '-S'
'-mabi=64' '-msym32' '-mno-abicalls' '-O2' '-march=sb1' '-mno-shared'
/home/ddaney/gccsvn/trunk-build/gcc
--- Comment #6 from daney at gcc dot gnu dot org 2007-09-04 04:27 ---
OK I can reproduce with my mips64-linux cross compiler. I wonder if it is
big-endian related...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:47
---
Found the problem. I will submit the update patch against this PR
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:49
---
Changed title to reflect what this is, not really a regression at this point.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from dominiq at lps dot ens dot fr 2007-09-04 04:58 ---
Did you also have a look to the other problem:
print *, nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0)
1
Error: Result of NEAREST overflows its kind at (1)
?
--
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:39
---
Yes, I also checked the huge testcase and its all clean now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #16 from patchapp at dberlin dot org 2007-09-04 05:40 ---
Subject: Bug number PR33225
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-09/msg00176.html
--
The following code:
real x
x = nearest(huge(1.0),1.0)
end
gives
x = nearest(huge(1.0),1.0)
1
Error: Result of NEAREST overflows its kind at (1)
instead of setting x to +Inf. This bug is also present in GNU F95 version
4.2.1.
--
Summary: nearest(huge(1.0),1.0) gives an
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:44
---
Dominique: The problem in comment 14 is not fixed and I do not think its
related. I will check further though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #7 from daney at gcc dot gnu dot org 2007-09-04 05:46 ---
Here is what is happening:
The value of avenrun[0] is being passed to a function that takes an 32 bit int
parameter. Since avenrun is an array of 64 bit unsigned long, the conversion
to int can be done by loading an
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-04 05:47 ---
I do not think its related.
I just realized that and I filled PR33296.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
87 matches
Mail list logo
