Compiling this simple function in thumb mode:
int add_const(int x)
{
return x+400;
}
I got:
mov r1, #200
lsl r3, r1, #1
add r0, r0, r3
A better code sequence should be:
add r0, r0, 200
add r0, r0, 200
In order to apply this optimization, the constant
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-03 08:16 ---
Ramana, can you please add the exact command line you are using (so that I can
see what flags you use and what cpu you target) and the exact output you are
expecting? I have hacked things such that the store is cros
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-03 08:25 ---
s/L4/L5/
my punishment from manually typing over the assembly from my laptop screen into
bugzilla on the desktop :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
The attached Fortran source, when compiled with a recent version of the trunk,
gives the above ICE.
Compile options: -O3 -c.
--
Summary: internal compiler error: in set_ssa_val_to, at tree-
ssa-sccvn.c:1811
Product: gcc
Version: 4.5.0
--- Comment #1 from toon at moene dot org 2009-06-03 08:50 ---
Created an attachment (id=17947)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17947&action=view)
Testcase
Attached the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
--- Comment #2 from toon at moene dot org 2009-06-03 08:52 ---
The bug started to appear between revisions 147846 and 147982 of the trunk.
--
toon at moene dot org changed:
What|Removed |Added
---
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-03 09:30
---
(In reply to comment #1)
> I'm under the impression we should simply not provide operator __safe_bool()
Agreed, there is no requirement for conversion to bool, explicit or implicit.
Even if it can be done unambi
--- Comment #6 from paolo dot carlini at oracle dot com 2009-06-03 09:43
---
Ok. Thanks Sebastian and Jon for your feedback. Jon, I'll leave that additional
clean up to you then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from matz at gcc dot gnu dot org 2009-06-03 09:51 ---
I'm looking at this now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-03 10:36 ---
This code comes from the split2 (split insns after reload). So this is target
specific. It surprises me that non-legitimate constants are accepted before
reload on ARM (at least in thumb mode). It may be (and IMHO,
--- Comment #7 from paolo at gcc dot gnu dot org 2009-06-03 10:37 ---
Subject: Bug 40296
Author: paolo
Date: Wed Jun 3 10:37:20 2009
New Revision: 148122
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148122
Log:
2009-06-03 Paolo Carlini
PR libstdc++/40296
*
--- Comment #8 from paolo at gcc dot gnu dot org 2009-06-03 10:37 ---
Subject: Bug 40296
Author: paolo
Date: Wed Jun 3 10:37:32 2009
New Revision: 148123
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148123
Log:
2009-06-03 Paolo Carlini
PR libstdc++/40296
*
--- Comment #9 from paolo dot carlini at oracle dot com 2009-06-03 10:40
---
Fixed 4.4.1 and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-03 10:57 ---
FWIW it looks like the define_split at arm.c:5060 (of r147729) is triggered.
Richard E., is there a reason for lowering load-immediates so late in the
pipeline?
--
steven at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-03 11:25 ---
Mine. We fail to fold COMPLEX_EXPR <0, 0> to COMPLEX_CST.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-03 11:31 ---
I am testing the following:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 148119)
+++ gcc/fold-const.c(working copy)
@@ -2643,9 +26
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-03 11:56 ---
Subject: Bug 40323
Author: jamborm
Date: Wed Jun 3 11:56:05 2009
New Revision: 148126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148126
Log:
2009-06-03 Martin Jambor
PR tree-optimization/403
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-03 12:54 ---
I have just verified this is fixed on the current trunk.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from toon at moene dot org 2009-06-03 12:55 ---
It works for the testcase with your change (over revision 148127).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-03 13:17 ---
Also broken on arm-eabi cross. Using gdb and the exact steps as in Comment #0
shows me problem as 0x100.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-03 14:00
---
The problem seems to be the asymmetry wrt handling of NAMEs vs. SSA_NAME
operands
in NARYs and REFERENCEs. We happily translate NAMEs and do not clean them
if they are in AVAIL_OUT, but we only can translate SSA_N
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|internal compiler error: in |[4.5 Regression] internal
|set_ssa_val_to, at tree-
--- Comment #10 from ich at az2000 dot de 2009-06-03 15:00 ---
Thanks a lot, works just fine. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #13 from dberlin at gcc dot gnu dot org 2009-06-03 15:16
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Hmmm, clean should only have to check set1 and set2, not AVAIL_OUT.
I'm not sure why it looks at AVAIL_
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-03 15:31 ---
Subject: Bug 40328
Author: rguenth
Date: Wed Jun 3 15:30:52 2009
New Revision: 148134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148134
Log:
2009-06-03 Richard Guenther
PR middle-end/40328
On freebsd-6.4-stable alpha gcc-4.5 fails to build after 20090507. Until then
built ok. Tried with default system compiler gcc-3.4 or with gcc-4.4.
#gcc44 -v
Using built-in specs.
Target: alpha-portbld-freebsd6.4
Configured with: ./../gcc-4.4-20090526/configure --disable-nls
--with-system-zlib --w
right now, 4.4 branch is broken for CP2K, there seems to be some error in
libfortran that causes incorrect writes. The diff in the restarts looks like:
56,58c56,58
< &FORCEFIELD
FORCEFIELD,
> ,PARMTYPE CHM
> ,PA
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-03 15:44 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-03 15:46 ---
CCed the experts
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC|
Using either the std::tr1 or C++0x std:: random number generators, the
uniform_real distribution produces numbers that are completely wrong.
For instance, using Boost.Random the test program produces this sequence of
floating point numbers:
Random real: 0.0975404
Random real: 0.547221
Random real
--- Comment #1 from colin at gibibit dot com 2009-06-03 15:52 ---
Created an attachment (id=17948)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17948&action=view)
Test case that generates random reals using Boost, TR1, and C++0x
Uncomment exactly one of RNG_BOOST, RNG_TR1, or RNG
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-03 15:54 ---
Did you try 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #9 from matz at gcc dot gnu dot org 2009-06-03 15:57 ---
Bah, simply not expanding those variables (whose SSA partitions were already)
by clearing TREE_USED on them fixes the problem, but makes those variables
have no debug info at all, as the DECLs then have no DECL_RTL_SET
--- Comment #6 from eduardo dot m dot costa at gmail dot com 2009-06-03
16:06 ---
Are you using tree-parallelize-loops? I got the same problem, and using "-O2
-fno-tree-parallelize-loops" worked for me...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-03 16:08 ---
(In reply to comment #2)
> Did you try 4.5?
unfortunately trunk currently fails for other reasons. I'll try to look into
that afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #4 from jv244 at cam dot ac dot uk 2009-06-03 16:31 ---
OK, a good hint from valgrind. The following error is present if I use 4.4.1
but not if I link against the runtime from 4.4.0:
==30712== Invalid read of size 1
==30712==at 0x4A22DF9: strncmp (mc_replace_strmem.c:314)
--- Comment #5 from jv244 at cam dot ac dot uk 2009-06-03 16:47 ---
OK, now with easy testcase, as you'll notice from the output, the loop is
important:
IMPLICIT NONE
character(len=100) :: fmt1,str1,fmt2,str2
real*8 :: r(3)=0
integer :: i,iunit
fmt1="(T2,A2,"
str1="a"
iunit=6
DO i=1,10
--- Comment #2 from paolo dot carlini at oracle dot com 2009-06-03 16:49
---
*** This bug has been marked as a duplicate of 40263 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from jv244 at cam dot ac dot uk 2009-06-03 16:49 ---
compiled with trunk this is also buggy (with new bugs about dwarf2):
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader: unhandl
--- Comment #3 from paolo dot carlini at oracle dot com 2009-06-03 16:49
---
*** Bug 40331 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
ele/gcc_trunk/build/
--with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090603 (experimental) [trunk revision 148132] (GCC)
leads to these errors at link time:
/usr/bin/ld: error in
/data03/vondele/clean/cp2k/src/../lib/Linux-x86-64-gfortran/sdbg/libcp2k_li
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 17:09 ---
What binutils version are you using? do ld --version. This might be a bug in
binutils really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
--- Comment #2 from jv244 at cam dot ac dot uk 2009-06-03 17:14 ---
(In reply to comment #1)
> What binutils version are you using? do ld --version. This might be a bug in
> binutils really.
it is recent, I think:
> ld -v
GNU ld (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1
--
--- Comment #7 from jb at gcc dot gnu dot org 2009-06-03 17:39 ---
Confirmed on trunk.
This seems to be due to the format caching stuff?
The regression on the 4.4 branch would be explained by the I/O backport
(r147887).
--
jb at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40308
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c (cp_
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40307
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c (cp_
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40311
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c (cp_
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 18:15 ---
Fixed by:
2009-06-03 Julian Brown
* config/arm/arm.c (arm_hard_regno_mode_ok): Permit values of four
words or less (including TImode) in core registers.
--
pinskia at gcc dot gnu dot org chang
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-03 18:12 ---
Subject: Bug 40306
Author: jason
Date: Wed Jun 3 18:11:53 2009
New Revision: 148141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148141
Log:
PR c++/40308
PR c++/40311
* typeck.c (cp_
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-03 18:49 ---
Created an attachment (id=17949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17949&action=view)
Proposed patch
This patch seems to fix it, will formally submit as soon as it regtests.
--
http://gcc.gnu.org/b
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-03 18:58 ---
(In reply to comment #7)
> Fixed on trunk.
> I'll backport to 4.4. branch in a week.
* ping *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
--- Comment #9 from jb at gcc dot gnu dot org 2009-06-03 19:19 ---
Proper patch submitted.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-03 19:39 ---
Subject: Bug 40019
Author: burnus
Date: Wed Jun 3 19:39:09 2009
New Revision: 148143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148143
Log:
2009-06-03 Francois-Xavier Coudert
PR fortran/40019
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-03 19:40 ---
Now also FIXED on the 4.4 branch. -> CLOSE
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Target Milestone|--- |4.4.1
http://
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-03 21:07 ---
Subject: Bug 40330
Author: jb
Date: Wed Jun 3 21:07:19 2009
New Revision: 148149
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148149
Log:
PR libfortran/40330
Use heap memory for cached format strings.
Modi
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:12
---
No news for a year and a half. 4.2 branch is now closed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:13
---
4.2 branch is closed, works in 4.3.0
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:18
---
Here's what it gives with Apple's gcc:
_r:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movaps %xmm0, -24(%ebp)
movaps %xmm1, -40(%ebp)
movaps %xmm2, -56(%e
The following SSE2 code crashes because the non-static global variable breaks
the alignment of the static data section.
align.cpp:
#include
int nonstatic_padding;
static int static_padding[3];
static __attribute__((aligned(16))) __m128i sse_data;
int main() {
static_padding[0] = 1234;
ss
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-03 21:26 ---
*** This bug has been marked as a duplicate of 37216 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #62 from pinskia at gcc dot gnu dot org 2009-06-03 21:26
---
*** Bug 40333 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:29
---
Not target-specific, can reproduce on x86_64-linux (don't know what you expect,
though).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:35
---
Changing subject according to comment #6.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:47
---
Still fails on both ppc-darwin and i386-darwin, for 4.3.2, 4.4.0 and current
trunk:
$ cat a.c
extern int puts (const char *);
extern void abort (void);
int main ()
{
__label__ l1;
void foo ()
{
void
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:50
---
*** This bug has been marked as a duplicate of 10901 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:50
---
*** Bug 22119 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-06-03 21:58
---
(In reply to comment #3)
> So I don't know what people want to do about this bug. Over the years some
> people have worked to fix such problems as bugs; and some people want to point
> to the documentation and sa
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-03 22:00
---
Works for me on 4.3.2, 4.4.0 and 4.5.0. Suppose it's fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-06-03 22:16
---
I'm not seeing that one with 4.3.2 (nor with 4.4.0 or current trunk).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34584
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-06-03 23:31
---
Subject: Bug 10242
Author: rearnsha
Date: Wed Jun 3 23:31:12 2009
New Revision: 148156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148156
Log:
PR target/10242
* arm.md (arm_addsi3): Don
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-06-03 23:34
---
fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #4 from dalej at gcc dot gnu dot org 2009-06-04 00:06 ---
Yeah. Looking through our local changes, I think you just need this line in
i386.h:
#define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_MACHO ? 4 : (TARGET_SSE ? 3
: 0)))
However Apple employees can't currently touc
The following program (also attached) reads to eof, backspace, reads (eof
detected), backspace, and reads again. The last read gets the last line with
gfortran 4.5 (tested: r148116) but eof with gfortran <= 4.4, g95, g77 and Sun
f95.
>From reading comp.lang.fortran I know that EOF/BACKSPACE intera
--- Comment #1 from bartoldeman at users dot sourceforge dot net
2009-06-04 00:30 ---
Created an attachment (id=17950)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17950&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-04 01:13
---
Confirmed on 4.4 and 4.5. I checked with 4.3, ifort, open64, and Sun
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.5 regression: changed |4.4,4.5 regression: changed
|BACKSPACE behaviour
--- Comment #19 from bartoldeman at users dot sourceforge dot net
2009-06-04 04:03 ---
Thanks for all the work -- another text processing program which changes some
headers in big ASCII files (which is what inspired this bug) went from around
real0m2.026s
user0m1.764s
sys 0m
--- Comment #11 from jv244 at cam dot ac dot uk 2009-06-04 05:16 ---
(In reply to comment #9)
> Proper patch submitted.
Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
could be released this month, and some further testing on the branch would be
good:
http://g
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-04 05:36 ---
> Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
> could be released this month, and some further testing on the branch would be
> good:
Planned for June 21, see (better link):
http://gcc.
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-04 06:41 ---
With trunk 2009-04-05-r145558 I get
HELLO
correct
while with trunk 2009-04-06-r145580 the result is
HELLO
error2: not at eof
It is not surprising that the following patch was checked in between those
revisions:
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-04 06:43 ---
Can this PR now be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
83 matches
Mail list logo
