--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 19:50
---
Reduced testcase follows:
$ cat a.f90
integer :: i
select case(i)
case (transfer(1,1))
end select
end
$ gfortran -c a.f90
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-16 20:12 ---
Confirmed. (Yes, this means I'm finally able to reproduce it!)
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot
|dot org
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:24
---
Yet another transfer bug :(
Reduced testcase:
real :: NaN = transfer(0,0)
print *, NaN
end
Backtrace of the ICE:
Breakpoint 1, gfc_conv_constant (se=0xbf8f8fbc, expr=0x888dad8)
at
The following problem can cause bootstrap comparison failures in some
circumstances (and was originally observed when bootstrapping with CFLAGS=-g
BOOT_CFLAGS=-g).
Consider the code from tree.c:
/* See if the data pointed to by the type hash table is marked. We consider
it marked if the type
--- Comment #1 from jsm28 at gcc dot gnu dot org 2007-03-16 20:26 ---
Created an attachment (id=13215)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13215action=view)
Testcase cut down from dbxout.i in original bootstrap failure.
--
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:29
---
Unit numbers are passed and stored internally as GFC_INTEGER_4, but we don't
error out on too large numbers (like the one that don't fit inside a
GFC_INTEGER_4).
--
fxcoudert at gcc dot gnu dot org changed:
Hello,
there seems to be a gcc problem with the target 'xtensa-elf':
/home/mstein/sim/xtensa-elf/build/./gcc/xgcc
-B/home/mstein/sim/xtensa-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/xtensa-elf/build/xtensa-elf/newlib/ -isystem
/home/mstein/sim/xtensa-elf/build/xtensa-elf/newlib/targ-include
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:42
---
Confirmed on x86_64-linux, but somehow it doesn't happen on i386.
The reason why it fails and the way to fix it are given in the ML link given by
the reporter.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-16 20:46
---
Created an attachment (id=13216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13216action=view)
from SVN revision: 122962
Commandline used to create libgcc2.i:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:48
---
Confirmed. Changing -3 into -2**18 can also make it ICE.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:53
---
Confirmed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:55
---
*** This bug has been marked as a duplicate of 31202 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:55
---
*** Bug 31208 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31202
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:56
---
Wrong bug number.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:56
---
*** This bug has been marked as a duplicate of 31203 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:56
---
*** Bug 31208 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-16 20:57
---
Another testcase, from the duplicate 31208:
$ cat a.f90
SUBROUTINE S1(I,J)
character(len=I-J) :: a
IF (LEN(a)0) CALL ABORT()
END SUBROUTINE
CALL S1(1,2)
END
$ gfortran -static a.f90 ./a.out
Aborted
--
Hello,
there seems to be a gcc problem with the target 'xstormy16-elf':
/home/mstein/sim/xstormy16-elf/build/./gcc/xgcc
-B/home/mstein/sim/xstormy16-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/xstormy16-elf/build/xstormy16-elf/newlib/ -isystem
in obstack.h in the \include dir of the GCC 4.1.2 release, the macro
definition for the obstack_int_grow_fast function is as follows:
# define obstack_int_grow_fast(h,aint) \
(((int *) ((h)-next_free += sizeof (int)))[-1] = (aptr))
shouldn't the right side of
--- Comment #1 from eweddington at cso dot atmel dot com 2007-03-16 21:34
---
Created an attachment (id=13217)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13217action=view)
Patch to add in the missing break statements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-16 21:45 ---
# cnt_67 = PHI 27(13)
L22:;
D.1796_118 = time_14(D)-mon[27];
ivtmp.56_8 = (unsigned int) D.1796_118;
D.1797_117 = iov[27];
ivtmp.59_7 = (unsigned int) D.1797_117;
# ivtmp.59_76 = PHI ivtmp.59_112(17),
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|--- |4.3.0
--- Comment #1 from george at houseofellery dot com 2007-03-16 21:50
---
the above is the SECOND definition of the macro function in the
#else /* not __GNUC__ or not __STDC__ */ branch of the enclosing conditional.
--
george at houseofellery dot com changed:
What
As noted in this message:
http://gcc.gnu.org/ml/fortran/2007-03/msg00339.html
This should probably be documented in the manual.
--
Summary: Thread-safety of random_number should be documented.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-16 22:39 ---
This is probably related to Bug #31229.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-16 22:40 ---
This is probably related to Bug #31154
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
Configured and built with:
../gcc-4.2-20070221/configure --enable-languages=c --enable-bootstrap
--disable-nls make BOOT_CFLAGS=-gstabs
The result is:
[...]
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./dbxout.o differs
./insn-emit.o differs
--- Comment #1 from joseph at codesourcery dot com 2007-03-16 22:50 ---
Subject: Re: New: Bootstrap comparison failure with
-gstabs
On Fri, 16 Mar 2007, feri1024 at t-email dot hu wrote:
Configured and built with:
../gcc-4.2-20070221/configure --enable-languages=c
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-16 22:57
---
I will work this one. I want to review the standard. I think we are
truncating and I am not so sure this has to do with the t1 format specifier.
We'll see.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-16 23:01
---
I will fix this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-03-16 23:05 ---
Thnaks for verifying. Thanks also for your testresults
for many embedded processors!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
/*
when using an external function pointer cast as an interrupt in a if (function
== 0) statement the compiler assume the pointer is non-null and optimize out
the if right away even tho the symbol could indeed be null and optimizations
are disabled.
this is a big problem when values are set as
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-16 23:08 ---
You need to mark the function as weak not to assume the function is non-null.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sh-list at ssc-studios dot com 2007-03-17 00:07 ---
I don't think this behavior is part of the C or C++ standard.
nor is __attribute__ (( weak ))
this behavior of gcc seems to be undocumented.
I don't see how usefull it is to have gcc assume pointers to functions to
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-17 00:19 ---
Still invalid, the C standard talks about NULL as being at the location 0 so it
is basically it is invalid for a function to be located at 0/NULL.
Again if you want a function to be possibly located at NULL/0, use
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-17 00:22 ---
As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks
Richard for your
patience.
I have just noticed the following oddity with the code:
#include math.h
#include stdio.h
int main()
{
--- Comment #14 from dominiq at lps dot ens dot fr 2007-03-17 00:26 ---
Thanks to Richard Guenther, the bug seems to be fixed (hopefully in the
20070316 snapshot):
see PR31161 for details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-17 00:27 ---
Thanks to Richard Guenther, the bug seems to be fixed (hopefully in the
20070316 snapshot):
see PR31161 for details.
I'll comment in another PR about the corresponding optimization (too late to
do it tonight
--- Comment #10 from aoliva at gcc dot gnu dot org 2007-03-17 03:48 ---
Does anyone feel like testing the patch in 4.0?
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from aoliva at gcc dot gnu dot org 2007-03-17 04:52 ---
Subject: Bug 29906
Author: aoliva
Date: Sat Mar 17 04:52:44 2007
New Revision: 123011
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123011
Log:
gcc/ChangeLog:
PR debug/29906
* dwarf2out.c (force_type_die):
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-17 06:28
---
The front end is converting the integer8 to integer4 and not checking the range
of the number first. The integer value gets wrapped around and the library
sees unit=10 for this test case.
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-17 06:48
---
Fixed.
Does anyone feel like testing the patch in 4.0?
The 4.0 branch has been retired.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
101 - 143 of 143 matches
Mail list logo
