--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-01 08:07
---
There is a bug in the gcc compiler for the C code that changes the behavior of
a simple program with -O2 optimizations, but not with -O1 or -O0.
-O2 enables -fstrict-aliasing so the code must be written in ISO
--- Comment #6 from irar at il dot ibm dot com 2009-03-01 10:34 ---
Reduced it a bit more:
subroutine adw_trajsp (F_u,i0,in,j0,jn)
implicit none
real F_u(*)
integer i0,in,j0,jn
integer n,i,j
real*8 xsin(i0:in,j0:jn)
!$omp parallel do private(xsin)
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-03-01 10:53
---
Subject: Bug 39264
Author: ebotcazou
Date: Sun Mar 1 10:53:17 2009
New Revision: 144514
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144514
Log:
PR ada/39264
* gcc-interface/decl.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-01 10:56
---
The test should pass everywhere now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenther at suse dot de 2009-03-01 10:58 ---
Subject: Re: internal compiler error: verify_stmts
failed
On Sun, 1 Mar 2009, irar at il dot ibm dot com wrote:
--- Comment #6 from irar at il dot ibm dot com 2009-03-01 10:34 ---
Reduced it a bit more:
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-03-01 11:02 ---
Subject: Bug 39267
Author: hubicka
Date: Sun Mar 1 11:02:30 2009
New Revision: 144515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144515
Log:
PR debug/39267
* tree-inline.c
--- Comment #9 from rguenther at suse dot de 2009-03-01 11:32 ---
Subject: Re: internal compiler error: verify_stmts
failed
On Sun, 1 Mar 2009, irar at il dot ibm dot com wrote:
--- Comment #8 from irar at il dot ibm dot com 2009-03-01 11:15 ---
(In reply to comment #7)
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-03-01 11:39
---
The small testcase at -O2 is bound by PRE time
PRE : 27.08 (55%) usr 0.02 ( 4%) sys 27.09 (55%) wall
1551 kB ( 2%) ggc
nothing interesting at -O1 and it still nicely fits into my
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-01 11:07 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from irar at il dot ibm dot com 2009-03-01 12:27 ---
(In reply to comment #9)
Ok. Then
if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
gimple_purge_dead_eh_edges (bb);
should be enough to fix this.
Richard.
Yes, it fixes the ICE. Thanks! I'll submit
--- Comment #12 from gerald at pfeifer dot com 2009-03-01 13:03 ---
(In reply to comment #8)
This looks like it happens on FreeBSD 7.1 as well:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00142.html
Any news on what is going on here?
Yes, I have updated my nightly tester to
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-01 13:20 ---
Before starting a reghunt, I have done the test again and these failures
diasppeared!-(I'll close the bug after a few more bootstraps).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39324
--- Comment #6 from rwild at gcc dot gnu dot org 2009-03-01 12:45 ---
The patch to fix this bug broke documented options:
--help=warnings,^joined,^undocumented
in order to fix an ICE with invalid options. New patch to undo breakage and
fix the ICE in a different way proposed here:
--- Comment #1 from dominiq at lps dot ens dot fr 2009-03-01 12:00 ---
The test fails because '[exec file linkage-x.o]' returns 'linkage-x.o: Mach-O
64-bit object'. The following patch fixes the problem:
--- ../_gcc_clean/gcc/testsuite/gcc.misc-tests/linkage.exp 2009-02-20
from libgomp.c++/pr27337.C at -O3 we get in 042i.inline
ret.12_15 = x.8;
.omp_data_o.11.ret ={v} ret.12_15;
__builtin_GOMP_parallel_start (_Z3barv.omp_fn.0, .omp_data_o.11, 4);
_Z3barv.omp_fn.0 (.omp_data_o.11);
__builtin_GOMP_parallel_end ();
ret.13_16 = .omp_data_o.11.ret;
x.8 =
mipsel-unknown-linux-gnu-gcc -mabi=32 vfwscanf.c -c -std=gnu99 -O2 -Wall
-Winline -Wstrict-prototypes -Wwrite-strings -finline-limit=1
-I../include -I.
-I/media/d_drive/crosstool-0.43/build/mipsel-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.6/build-glibc/stdio-common
-I.. -I../libio
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-01 17:26 ---
omp-lower introduces the store to retval which seems useless as with
a pass-by-reference retval we will never change the address itself.
ret.12 = retval;
.omp_data_o.11.ret = ret.12;
{
#pragma omp
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-01 17:41 ---
GCC 3.4.5 is no longer maintained.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.3 |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.3/work/gcc-4.3.3/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3
--- Comment #1 from galtgendo at o2 dot pl 2009-03-01 18:19 ---
Created an attachment (id=17381)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17381action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-03-01 18:47 ---
Subject: Bug 39267
Author: hubicka
Date: Sun Mar 1 18:47:08 2009
New Revision: 144529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144529
Log:
PR debug/39267
* tree.h
From James van Buskirk on clf:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/81ebe96bb6b05dc3#
C:\gfortran\clf\recursive_parametertype recursive_parameter.f90
program recursive_parameter
implicit none
integer, parameter :: dp = kind(1.0_dp)
write(*,*) dp
end
--- Comment #13 from ubizjak at gmail dot com 2009-03-01 19:16 ---
(In reply to comment #12)
If anyone has any ideas / patches to verify, I will be happy to do my best.
Is there an ABI documentation that says which prefixes are correct for certain
cases? It is easy to fix this issue
--- Comment #7 from gerald at pfeifer dot com 2009-03-01 19:26 ---
I'm seeing the same on i386-unknown-freebsd7.1.
PASS: gcc.dg/tree-ssa/vrp47.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 [xy][^ ]* != 0
FAIL: gcc.dg/tree-ssa/vrp47.c
--- Comment #14 from ubizjak at gmail dot com 2009-03-01 20:13 ---
(In reply to comment #5)
Uros, looking at this again, after manually changing
leal$_48(,%eax,4), %eax
to
leal_48(,%eax,4), %eax
things build again with the label being defined as
.type $_48,
--- Comment #15 from hjl dot tools at gmail dot com 2009-03-01 20:20
---
(In reply to comment #14)
I think that H.J. can explain the reason for this inconsistency in the
assembler.
LOCAL_LABELS_DOLLAR never really works completely for x86 assembler.
When assembler sees $foo, it
--- Comment #16 from hjl dot tools at gmail dot com 2009-03-01 20:23
---
I posted a patch at:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00049.html
It may breaks ABI for platforms where NO_DOLLAR_IN_LABEL
is undefined:
bash-3.2$ grep NO_DOLLAR_IN_LABEL *.h */*.h | grep undef
--- Comment #17 from hjl dot tools at gmail dot com 2009-03-01 20:40
---
I opened an assembler bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=9915
I believe it is a mistake to define LOCAL_LABELS_DOLLAR for any
x86 targets where '$' is used as the immediate prefix. If it worked
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-01 20:49 ---
Subject: Bug 39331
Author: rguenth
Date: Sun Mar 1 20:49:14 2009
New Revision: 144531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144531
Log:
2009-03-01 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-01 20:49 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Using SVN rev 144526, encountered this ICE:
$ host-x86_64-unknown-linux-gnu/gcc/cc1 -O1 -floop-interchange gdevdevn.pre.c
snip
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups {GC 5330k - 4348k} summary generate
inline static-var
--- Comment #1 from il dot basso dot buffo at gmail dot com 2009-03-01
21:10 ---
Created an attachment (id=17382)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17382action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
Shared libraries ought to contain the full path so that executables built
against them can find them at runtime.
eg,
$ otool -L libgcc_s.1.dylib
libgcc_s.1.dylib:
/opt/gcc-4.3.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib
--- Comment #2 from bauhaus at futureapps dot de 2009-03-01 21:52 ---
This is still present in 4.4.0
gcc -c pak2.ads
+===GNAT BUG DETECTED==+
| 4.4.0 20090301 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
einfo.adb:837
--- Comment #18 from hjl dot tools at gmail dot com 2009-03-01 21:53
---
I will check in a patch:
http://sourceware.org/ml/binutils/2009-03/msg8.html
to undefine LOCAL_LABELS_DOLLAR for x86 assembler. I suggest that
gcc should define NO_DOLLAR_IN_LABEL for all x86 targets.
--
--- Comment #9 from hpa at zytor dot com 2009-03-01 22:34 ---
Though __builtin_not_reached () can be used to implement __builtin_assume (),
so it may be more generally useful. if (i 0) __builtin_not_reached (); will
make GCC assume that i = 0 on the other edge (of course we'd have
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-03-01 22:41
---
Oh, patches welcome!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2009-03-02 01:20 ---
My patch for 39310 also fixes this bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-02 01:22 ---
*** Bug 39321 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2009-03-02 01:22 ---
Yep, duplicate.
*** This bug has been marked as a duplicate of 37806 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from cnstar9988 at gmail dot com 2009-03-02 01:28 ---
ping 4.3.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
--- Comment #3 from jason at gcc dot gnu dot org 2009-03-02 01:47 ---
The discussion of Core issue 547
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#547) suggests that
we ought to be able to write partial specializations of is_function that can
deal with function
Using gcc 4.4.0 20090226 with -Os on:
int f(int a)
{
if (!a) {
return 0;
} else {
volatile int vla[a];
vla[0] = 0;
return vla[0];
}
}
gives:
_f:
pushl %ebp
xorl%eax, %eax
movl
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-03-02 02:32 ---
This is correct, vla and alloca always uses a frame pointer because there is no
way to get back to the original offsets so the compiler needs a frame pointer.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-02 02:33 ---
One more thing, inlining of functions that contain a VLA is disabled anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39337
--- Comment #3 from astrange at ithinksw dot com 2009-03-02 02:39 ---
This is correct, vla and alloca always uses a frame pointer because there is
no way to get back to the original offsets so the compiler needs a frame
pointer.
It's not restoring from the frame pointer here, it's
--- Comment #7 from rob1weld at aol dot com 2009-03-02 03:19 ---
(In reply to comment #6)
Broken: x86_64-pc-linux-gnu
Works: i686-pc-linux-gnu
Rob
Here is someone who had much better luck on 64-Bit (ia64-suse-linux-gnu):
Results for 4.4.0 20090218 (experimental) [lto revision
--- Comment #19 from hjl dot tools at gmail dot com 2009-03-02 03:20
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00061.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Is this a known bug?
It looks like gcc treats +0x1 as a floating suffix.
I confirmed this on cygwin at winXP.
###
$ cat test.c
int main(int argc, char* argv[])
{
return 0xe+0x1 ;
}
$ gcc test.c
test.c:4:9: invalid suffix
--- Comment #1 from pault at gcc dot gnu dot org 2009-03-02 05:07 ---
It is, of course confirmed and a fix posted yesterday.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
I believe what is happening is that a loop like
for (int i = 1; i; ++i) { int64_t m = i * CONST_LL ...}
is being optimized to roughly:
int64_t m = 0;
for (...) { m += CONST_LL ...}
My code was intentionally allowing i to become negative (it was testing the
equivalence of two expressions for
--- Comment #8 from bonzini at gnu dot org 2009-03-02 06:11 ---
Subject: Re: gcc.dg/tree-ssa/vrp47.c fails on powerpc
Is this the same issue, or should I open a different report?
I think it is the same, I will verify.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
54 matches
Mail list logo
