--- 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
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 all
--- 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
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 #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
-
--- 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 14
--- 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
--- 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 #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:
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 #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 cv-quals.
--- 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: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 #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:20 ---
My patch for 39310 also fixes this bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- 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 #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 h
--- 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 #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
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 (c
--- 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=17382&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39335
Using SVN rev 144526, encountered this ICE:
$ host-x86_64-unknown-linux-gnu/gcc/cc1 -O1 -floop-interchange gdevdevn.pre.c
Analyzing compilation unit
Performing interprocedural optimizations
{GC 5330k -> 4348k}
Assembling functions:
gray_cs_to_devn_cm cmyk_cs_to_devn_cm bpc_to_depth
compres
--- 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
Status|UNCONFIRM
--- 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=gcc&view=rev&rev=144531
Log:
2009-03-01 Richard Guenther
PR tree-optimization/
--- 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
o
--- 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
freebs
--- 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 #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 $_
--- 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 scan-tree-du
--- 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
>From James van Buskirk on clf:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/81ebe96bb6b05dc3#
C:\gfortran\clf\recursive_parameter>type recursive_parameter.f90
program recursive_parameter
implicit none
integer, parameter :: dp = kind(1.0_dp)
write(*,*) dp
end pro
--- 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=gcc&view=rev&rev=144529
Log:
PR debug/39267
* tree.h (BLOCK_NONLOCALIZED_
--- 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=17381&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error:|[4.
--
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
--- 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
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-01 17:26 ---
omp-lower introduces the store to which seems useless as with
a pass-by-reference retval we will never change the address itself.
ret.12 = ;
.omp_data_o.11.ret = ret.12;
{
#pragma omp parallel num
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
-I/media/d
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
--- 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 #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
--- 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 #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 su
--- 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
19:23:
--- 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 memory.
--- 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 #1 from rguenth at gcc dot gnu dot org 2009-03-01 11:17 ---
Confirmed. It's probably difficult to expose this to combine, so a
peephole may be the only choice to catch it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from irar at il dot ibm dot com 2009-03-01 11:15 ---
(In reply to comment #7)
> > question is it OK to vectorize function that are in EH table?
> Well, we should transfer the EH region information to the vectorized
> statement in this case. Which might be tricky ... do we
--- 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
Status|UNCON
--- 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=gcc&view=rev&rev=144515
Log:
PR debug/39267
* tree-inline.c (setup_one_pa
--- 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 #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 #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=gcc&view=rev&rev=144514
Log:
PR ada/39264
* gcc-interface/decl.c (gna
--- 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 #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 IS
56 matches
Mail list logo