--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-15 06:40 ---
As I said, the branch is still open for regression bugfixes, so I don't see why
this couldn't be added there provided sufficient testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39767
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-04-15 05:14 ---
NaN requires -mieee for SH target and you could avoid the ICE
with -mieee or -fno-finite-math-only. Although the test case
doesn't make much sense for this target without these options,
the ICE might show the compil
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-15
05:07 ---
Subject: Re: [4.5 Regression] Fail pr34513.c and
pr34513.C at -O1 and above
Attached .i.
Dave
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-15
05:07 ---
Created an
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-04-15 04:46 ---
I'd like to add Jakub to the CC list because it's a build
failure on 4.4.0-rc1 anyway, though I don't think this is
a blocker. sh64 targets maybe not even tertiary.
The patch below will fix the problem. Jakub, plea
=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/usr/local/google/tmp/gcc4.4_dejagnu/install
--with-mpfr=/usr/local/google/tmp/gcc4.4_dejagnu/install --enable-multilib
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090414 (prerelease
--- Comment #1 from jingyu at google dot com 2009-04-15 03:44 ---
Created an attachment (id=17640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17640&action=view)
assembly of gcc.dg/initpri1.c
This assembly was generated by this command:
$arm-eabi-gcc gcc.dg/initpri1.c -S -o init
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-04-15 02:16
---
Without trying it. Your example is not a zero length file. You have written at
least a LF or CR-LF.
I am not convinced yet. I just want to know the basis. Is this standard
conforming or is it an extension? Is
The toolchain is built with newlib C.
2 g++ failures in dejaGNU tests:
FAIL tmpdir-g++.dg-struct-layout-1/t004 cp_compat_x_tst.o compile
FAIL tmpdir-g++.dg-struct-layout-1/t004 cp_compat_y_tst.o compile
Compiler error:
"In file included from
/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-trunk
--- Comment #4 from meissner at gcc dot gnu dot org 2009-04-14 22:58
---
Subject: Bug 39769
Author: meissner
Date: Tue Apr 14 22:57:51 2009
New Revision: 146071
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146071
Log:
PR testsuite/39769
Modified:
branches/ibm/gcc-4_3-bra
--- Comment #3 from meissner at gcc dot gnu dot org 2009-04-14 22:57
---
Subject: Bug 39769
Author: meissner
Date: Tue Apr 14 22:56:52 2009
New Revision: 146070
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146070
Log:
PR testsuite/39769
Modified:
branches/ibm/power7-meis
--- Comment #2 from meissner at gcc dot gnu dot org 2009-04-14 22:56
---
Subject: Bug 39769
Author: meissner
Date: Tue Apr 14 22:55:52 2009
New Revision: 146068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146068
Log:
PR testsuite/39769
Modified:
trunk/gcc/testsuite/Chan
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-14 22:41 ---
-frtl-abstract-sequences was removed from the trunk so closing as won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
/pr11832.c: Likewise.
However, these two files are still in gcc-4.4 branch (gcc version 4.4.0
20090414 (prerelease)).
Could someone delete these two files from gcc-4.4 branch?
Thanks!
--
jingyu at google dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-14 22:08 ---
(((long)(unsigned int)&(((ABC *)0)->abcC)) is not a valid C90/C99 constant
expression. Use the offsetof macro from stdlib.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773
--- Comment #1 from marcus at jet dot franken dot de 2009-04-14 22:06
---
Created an attachment (id=17639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17639&action=view)
generated.i
gcc -c -O2 generated.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773
--- Comment #15 from dominiq at lps dot ens dot fr 2009-04-14 22:04 ---
> No, I cannot reproduce it any more.
So I close this PR as fixed. Please reopen if the failure reappears.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--
--- Comment #3 from mlybbert at users dot sourceforge dot net 2009-04-14
21:56 ---
Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
--- Comment #14 from Ralf dot Wildenhues at gmx dot de 2009-04-14 21:50
---
Subject: Re: Bootstrapping libstdc++-v3 failed
* dominiq at lps dot ens dot fr wrote on Sun, Apr 12, 2009 at 10:17:24AM CEST:
> Is comment #11 still true?
No, I cannot reproduce it any more.
--
http://gc
new with GCC TRUNK:
LANG=C /home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O2 ~/generated.i
/home/marcus/generated.i: In function 'test_pack_ABC':
/home/marcus/generated.i:12: error: object with variably modified type must
have no linkage
This built fine with previous gcc.
--
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
the following program
INTEGER*8 :: N
INTEGER, DIMENSION(:), ALLOCATABLE :: data
N=2_8**32
write(6,*) N
ALLOCATE(data(N))
write(6,*) SIZE(data,1)
END
prints
4294967296
0
It would be useful if a check for overflow of size could be added to e.g.
-fbounds-check (a rather natu
--- Comment #33 from hjl at gcc dot gnu dot org 2009-04-14 20:27 ---
Subject: Bug 39678
Author: hjl
Date: Tue Apr 14 20:27:30 2009
New Revision: 146061
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146061
Log:
gcc/
2009-04-14 H.J. Lu
Backport from mainline:
--- Comment #6 from alexandre dot nunes at gmail dot com 2009-04-14 20:11
---
(In reply to comment #5)
> See the attached pqp.c file.
>
> [cut]
>
> With gcc 4.4.0 branch, built on 20090413, it fails:
>
This seems to be caused by the register order allocation. If I replace the
source
--- Comment #7 from jv244 at cam dot ac dot uk 2009-04-14 20:08 ---
I'm reopening this report. -ftrapv is still documented, so can be expected to
work by users.
For the particular problem I have right now, a functional version of this
option would be a great thing to have.
--
jv244
--- Comment #5 from alexandre dot nunes at gmail dot com 2009-04-14 20:07
---
See the attached pqp.c file.
With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
sum:
ldr r2, .L3
ldmia r2, {r1, r3}@ phole ldm
add r3, r0, r3
--- Comment #4 from alexandre dot nunes at gmail dot com 2009-04-14 20:04
---
Created an attachment (id=17638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17638&action=view)
Testcase for gcc 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-14 19:59 ---
*** Bug 39771 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 19:59 ---
*** This bug has been marked as a duplicate of 35412 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rsion 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC)
gcc version 4.5.0 20090414 (experimental) [trunk revision 146031] (GCC)
--
Summary: ftrapv does not work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Sever
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-14 19:26
---
Yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 19:24 ---
Local classes cannot be template arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
The following code does not compile ( error: no matching function for call to
`::A::print(main()::B&) ):
#include
namespace {
struct A {
template void print(C c)
{
c.print();
}
};
}
int main()
{
A a
--- Comment #7 from jason at gcc dot gnu dot org 2009-04-14 18:54 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-04-14
17:48 ---
Created an attachment (id=17637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17637&action=view)
Patch to fix the tests not to use floating point equality.
--
http://gcc.gnu.org/bugzilla/show
3 of the vmx tests (3a-04.c, 3a-04m.c, and 3a-05.c) fail on different powerpc
machines because the test relies on the Vector 2 Raised to the Exponent
Estimate and Vector Reciprocal Estimate instructions producing the exact same
bit value for each machine. Since these instructions are estitmate fun
--- Comment #6 from jason at gcc dot gnu dot org 2009-04-14 17:14 ---
Subject: Bug 39763
Author: jason
Date: Tue Apr 14 17:14:04 2009
New Revision: 146054
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146054
Log:
PR c++/39763
* name-lookup.c (pushdecl_maybe_frie
--- Comment #5 from jason at gcc dot gnu dot org 2009-04-14 17:04 ---
Subject: Bug 39763
Author: jason
Date: Tue Apr 14 17:04:04 2009
New Revision: 146053
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146053
Log:
PR c++/39763
* name-lookup.c (pushdecl_maybe_frie
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 16:15
---
Created an attachment (id=17636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17636&action=view)
testcase, not minimised
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39768
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree .
$ bfin-uclinux-gcc -S random.i
In file included from /home/segher/src/kernel/include/linux/kernel.h:16,
from /home/segher/src/kernel/include/linux/sched.h:53,
from /home/segher/src/kernel
/src/gcc-4.4.0-RC-20090414/libgcc
-I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/.
-I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc
-I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../include -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/n/17/segher/src/gcc
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:50
---
Created an attachment (id=17635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17635&action=view)
testcase, not minimised
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that
matters.
$ h8300-elf-gcc -mh -mint32 -g -fomit-frame-pointer -S read_write.i
/home/segher/src/kernel/fs/read_write.c: In function 'sys_pwrite64':
/home/segher/src/kernel/fs/read_write.c:455: internal compiler
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:30
---
Created an attachment (id=17634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17634&action=view)
testcase, not minimised
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39765
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that
matters.
$ cris-linux-gcc -O2 -S buffer.i
/home/segher/src/kernel/fs/buffer.c: In function 'block_page_mkwrite':
/home/segher/src/kernel/fs/buffer.c:2409: error: insn does not satisfy its
constraints:
(insn 14
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-14 15:20
---
The original testcase in #0 appears to be fixed if compiled with -fwhole-file.
Andrew's comment #4 appears to be still an issue?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-04-14 15:18 ---
Closing as WONTFIX.
Workaround: use -fmax-errors=1 to get only one message at a time.
See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
--- Comment #15 from domob at gcc dot gnu dot org 2009-04-14 15:16 ---
(In reply to comment #14)
> In the case of the first, the dependency was missed. In this second, it is
> detected OK but the components of the lhs that are not assigned to by the
> module procedure are left indetermi
--- Comment #31 from dfranke at gcc dot gnu dot org 2009-04-14 15:16
---
Closing as WONTFIX.
See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from nickc at redhat dot com 2009-04-14 15:15 ---
Hi Paolo
I am going to apply the uploaded patch to fix this problem.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601
--- Comment #1 from nickc at redhat dot com 2009-04-14 15:14 ---
Created an attachment (id=17633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17633&action=view)
Do not assume that comparisons with small integers will always produce a short
branch
--
http://gcc.gnu.org/bugzil
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-04-14 15:04
---
Reopen, closed wrong PR :(
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-14 15:04 ---
Yeah, it would help to use -Wshadow...
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-14 14:57 ---
I certainly can, with e.g. fresly updated:
GNU C++ (GCC) version 4.5.0 20090414 (experimental) (x86_64-unknown-linux-gnu)
LC_ALL=C ./cc1plus -O2 -Wshadow z.C -quiet
z.C: In function 'int foo()':
z.C:1
$ cat ice.ii
class A;
class B { };
extern const double NaN;
B foo(A* exec, double d);
inline B baz(A* a) {
return foo(a, NaN);
}
B bar(A* a) {
return baz(a);
}
extern const double NaN = (__builtin_nanf(""));
$ ./xgcc -B. -m4 -ml -fvisibility=hidden -O2 -finline-functions ice.i
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-14 14:50 ---
*** This bug has been marked as a duplicate of 35652 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #28 from pinskia at gcc dot gnu dot org 2009-04-14 14:50
---
*** Bug 39748 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-14 14:49
---
Closing as WONTFIX.
See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from falk at debian dot org 2009-04-14 14:47 ---
The problem comes from some convoluted code that was apparently substituted for
strlen to special-case constant arguments. It boils down to:
int f(void) {
if (0)
return ((const char *) "")[2];
return 0;
}
(without
--- Comment #8 from dodji at gcc dot gnu dot org 2009-04-14 14:34 ---
Created an attachment (id=17632)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17632&action=view)
Fix candidate
I am fully bootstrapping/regtesting this candidate patch at the moment ...
--
http://gcc.gnu.o
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-14 14:25 ---
I can't reproduce this with 4.4 or 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #4 from jason at redhat dot com 2009-04-14 14:07 ---
Subject: Re: [4.5 Regression] ICE: tree check: accessed elt
2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
I wonder if it only works on 4.4 because tree checking is disabled on
release branches.
Jason
--
htt
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 14:02 ---
Testcase for the second case:
struct Y { int z; };
struct X { struct Y y; };
int foo()
{
int z = 1;
struct X *x = (struct X *)&z;
return x->y.z;
}
a testcase for the first case is harder.
--
http://gcc.g
--- Comment #13 from bonzini at gnu dot org 2009-04-14 14:02 ---
Subject: Re: [4.4/4.5 Regression] Reload failure
on mplayer from SVN
> That's one of the reasons why TER doesn't forward all expressions even if
> they're used only once.
Yes -- indeed in this case we'd need fo
--- Comment #12 from matz at gcc dot gnu dot org 2009-04-14 13:58 ---
That's only possible sometimes and hence can't be relied upon. The RHS
expression might not be available at the point of the use anymore (some
operands might have been clobbered meanwhile, remember we aren't in SSA
an
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:52 ---
> I don't see the connection to SSA expansion
Well, now that you posted the patch my suppositions were partly true. The
important thing is that now you have a way to get an SSA_NAME's RHS into
expansion. So, if we can do
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-14 13:52
---
I Think the PRE/FRE part of this bug is really PR 38884 (for the complex) and
PR 38885 (for the vector).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:41 ---
Yes, but programs cannot use it so it does not really count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #10 from rguenther at suse dot de 2009-04-14 13:08 ---
Subject: Re: data-flow analysis does not discover
constant real/imaginary parts
On Tue, 14 Apr 2009, bonzini at gnu dot org wrote:
> --- Comment #8 from bonzini at gnu dot org 2009-04-14 13:00 ---
> It seems
--- Comment #1 from caolanm at redhat dot com 2009-04-14 13:06 ---
Created an attachment (id=17631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17631&action=view)
trivial demo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
This is very similar to Bug 39526 except that the test-case there now (Fedora
rawhide: gcc-4.4.0-0.32.x86_64) passes, while this similar one reports...
g++ -c -Wshadow demo.cxx
demo.cxx: In function int foo():
demo.cxx:11: warning: declaration of infoo shadows a previous local
demo.cxx:10: war
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-14 13:04 ---
Created an attachment (id=17630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17630&action=view)
hack
Hack in-progress that even works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #8 from bonzini at gnu dot org 2009-04-14 13:00 ---
It seems easier to lower complex phis. Though it doesn't work with vectors, it
shouldn't matter since we do not have vector extraction yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-14 12:40 ---
Ok, doesn't work. We get lattice transitions CONSTANT -> CONSTANT with
different
values which is unexpected (or even may break sth). If you remove that sanity
check it substitutes the broken constant (huh, with zer
--- Comment #6 from rguenther at suse dot de 2009-04-14 12:24 ---
Subject: Re: data-flow analysis does not discover
constant real/imaginary parts
On Tue, 14 Apr 2009, bonzini at gnu dot org wrote:
> --- Comment #5 from bonzini at gnu dot org 2009-04-14 12:16 ---
> Right, sor
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-14 12:20 ---
At revision 145996, this error is not detected with the -fwhole-file option:
[karma] f90/bug% gfc -fwhole-file pr24878_db.f90
[karma] f90/bug% a.out
Did NOT catch this error
--
http://gcc.gnu.org/bugzilla/show
--- Comment #5 from bonzini at gnu dot org 2009-04-14 12:16 ---
Right, sorry -- it is only at -Os that we don't get it. VRP and DOM say that
the jump threading is not performed because the probability is too small, and
PRE does not run at -Os at all.
--
bonzini at gnu dot org change
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-14 12:00 ---
Huh? I see in .optimized
foo (int i)
{
:
if (i != 0)
goto ;
else
goto ;
:
Invalid sum of incoming frequencies 5000, should be 7231
bar (); [tail call]
:
Invalid sum of incoming frequencies 12231, sh
--- Comment #3 from bonzini at gnu dot org 2009-04-14 11:56 ---
No, it survives to RTL :-(
Adjusting subject.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2009-04-14 10:37 ---
Fixed also for 4.3 and 4.4.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status
--- Comment #11 from uros at gcc dot gnu dot org 2009-04-14 10:31 ---
Subject: Bug 39740
Author: uros
Date: Tue Apr 14 10:31:29 2009
New Revision: 146030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146030
Log:
Backport from mainline:
2009-04-12 Uros Bizjak
--- Comment #10 from uros at gcc dot gnu dot org 2009-04-14 10:21 ---
Subject: Bug 39740
Author: uros
Date: Tue Apr 14 10:21:41 2009
New Revision: 146028
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146028
Log:
Backport from mainline:
2009-04-12 Uros Bizjak
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 10:14 ---
I also see this repeatedly. This test should be XFAILed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39756
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-14 10:14 ---
I also see this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 10:13 ---
GCC 3.2.1 is no longer maintained, please reproduce with at least GCC 4.3.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-14 10:06 ---
It is done by DOM, VRP and/or phicprop.
CCP cannot do it because the PHI node is varying.
Complex lowering does not split PHI nodes into a real/imag part either.
For the same reason as CCP FRE won't do it either.
PR
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #1 from schwab at linux-m68k dot org 2009-04-14 09:33 ---
Signed integer overflow is undefined in C. Use -fwrapv if you want wrapping
semantics.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
-
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
/* { dg-do compile } */
/* { dg-options "-Os" } */
/* { dg-options "-Os -msoft-float" { target { { i?86-* x86_64-* } && ilp32 } }
} */
extern void bar (void);
void
foo (unsigned int x, unsigned int y, unsigned int z)
{
unsigned int a, b, d, e;
unsigned int f = (8 << 12) + 0.000122 * 4096;
b
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:57 ---
This is currently caught by RTL jump bypassing, but not on all machines.
--
bonzini at gnu dot org changed:
What|Removed |Added
>From this testcase:
void bar();
void foo(int i)
{
__complex__ int k = 0;
if (i)
k = 1;
if (k)
bar();
}
(cfr. gcc.c-torture/compile/pr35431.c) we get after cddce1:
# k_1 = PHI <__complex__ (0, 0)(2), __complex__ (1, 0)(3)>
D.1198_6 = REALPART_EXPR ;
if (D.1198_6 != 0)
got
The same alternative can produce very different instruction sequences. For
example:
if (compare_sign_p (insn))
{
if (l) *l = 1;
return AS1 (tst,%B0);
}
if (reg_unused_after (insn, op)
&& compare_eq_p (insn))
{
/* Faster than sbiw if we can clobber the opera
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:29 ---
Seems to be caused by a failure to simplify
(if_then_else (ne (zero_extract:SI (const_int 0 [0x0])
(const_int 1 [0x1])
(const_int 0 [0x0]))
(const_int 0 [0x0]))
(label
--- Comment #3 from burnus at gcc dot gnu dot org 2009-04-14 08:09 ---
> I think gfortran has this right. This is an attempt to read from an internal
> unit of length zero. Try the same operation from a zero length file.
I'm not sure whether gfortran is right, but my program from comme
gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
code a.c:
#include
main() {
int i;
for (i = 1; i > 0; i *= 2)
printf("%d\n",i);
}
1. build:
gcc -O a.c -o a
Run:
./a
1
2
4
...
4536870912
1073741824
2. build:
gcc -O2 a.c -o a
Run:
./a
1
2
4
...
4536870912
1073741824
0
0
0
1 - 100 of 104 matches
Mail list logo
