[Bug rtl-optimization/40679] New: Optimizer handles loops with volatiles and post-incr. wrong
If the following code is compiled with -Os for ARM or ColdFire, the exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because the
PowerPC version does not show the problem.
Also: Using a different start-address for tbl, does not show the problem.
The problem has been reported also for 4.4.0.
typedef volatile unsigned long __vu32;
void bs()
{
int i;
__vu32 *tbl = (__vu32 *)0xff00;
for(i = 0; i < 64; ++i){
//-> tbl[i] = (__vu32)10;
*tbl++ = (__vu32)10;
}
}
Cmd-line: arm-none-eabi-gcc -S -Os t.c
Output:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file "t.c"
.text
.align 2
.global bs
.type bs, %function
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mvn r2, #255
.L2:
mov r3, #10
str r3, [r2], #4
b .L2
.size bs, .-bs
.ident "GCC: (Sourcery G++ Lite 2008q3-39) 4.3.2"
--
Summary: Optimizer handles loops with volatiles and post-incr.
wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian dot schick at sciopta dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-mingw32
GCC target triplet: i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-08 07:36 ---
I can reproduce the ICE with 4.1, 4.2 and 4.3 - but it no longer gives an ICE
with 4.4 or 4.5.
* * *
However, there is also a bug in 4.4: It simply compiles.
Expected: Either an error of the form (NAG f95)
Error: aa.f90, line 6: Implicit type for SUNSHINE
detected at SUNSHINE@
or -- better (or additionally) -- of the form
error #6423: This name has already been used as an external function name.
[SUNSHINE]
* * *
In 4.3.4 the following assert fails:
/* Procedure actual arguments. */
else if (sym->attr.flavor == FL_PROCEDURE
&& se->expr != current_function_decl)
{
gcc_assert (se->want_pointer);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||accepts-invalid, diagnostic,
||ice-on-invalid-code
Last reconfirmed|-00-00 00:00:00 |2009-07-08 07:36:28
date||
Summary|ICE on invalid code,|Using a function as
|gfc_conv_variable |variable: ICE with 4.3,
||accepts invalid with 4.4/4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40678
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-08 08:00 ---
I think one can consider supporting non-signed zeros as extension, similar to
ifort which has:
-assume nominus0The compiler uses Fortran 90/77 standard
semantics in the SIGN intrinsic to treat
-0.0 and +0.0 as 0.0, and writes a value
of 0.0 with no sign on formatted output.
(Default as of ifort 11.1 is the F77/F90 behaviour while gfortran defaults to
the F95/F2003/F2008 behaviour.)
Currently, gfortran only has such a flag for I/O and not for the sign
intrinsic:
-fsign-zero
When writing zero values, show the negative sign if the sign
bit is set. "fno-sign-zero" does not print the negative
sign of zero values for compatibility with F77. Default
behavior is to show the negative sign.
I think one can extends this to the SIGN intrinsic. One needs to modify
("if (gfc_option.flag_sign_zero)") trans-intrinsic.c's gfc_conv_intrinsic_sign.
Currently,
test = sign(x, y)
produces (-fdump-tree-original)
test = __builtin_copysignf (x, y)
that would have to be replaced by
test = (y == 0) ? abs(x) : __builtin_copysignf (x, y)
This can be further optimized by using MODE_HAS_SIGNED_ZEROS (or
HONOR_SIGNED_ZEROS?).
Actually, one also needs to modify simplify.c's gfc_simplify_sign: Either -0.0
is not correctly handled or the comment is wrong.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Last reconfirmed|-00-00 00:00:00 |2009-07-08 08:00:23
date||
Summary|sign intrinsic fails for|Support -fnosign-zero for
|value of 0.0|SIGN intrinsic for Fortran
||77 compatibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
Re: [Bug rtl-optimization/40679] New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com" > wrote:
If the following code is compiled with -Os for ARM or ColdFire, the
exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of
volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because
the
PowerPC version does not show the problem.
Also: Using a different start-address for tbl, does not show the
problem.
It looks more like a wrapping issue. 4*64 = 256. So we go from -256u
to 0 which causes wrapping of the pointer which is undefined and
therefor I think gcc is doing the correct thing (If got my numbers
correct).
The problem has been reported also for 4.4.0.
typedef volatile unsigned long __vu32;
void bs()
{
int i;
__vu32 *tbl = (__vu32 *)0xff00;
for(i = 0; i < 64; ++i){
//-> tbl[i] = (__vu32)10;
*tbl++ = (__vu32)10;
}
}
Cmd-line: arm-none-eabi-gcc -S -Os t.c
Output:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file "t.c"
.text
.align 2
.global bs
.type bs, %function
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mvn r2, #255
.L2:
mov r3, #10
str r3, [r2], #4
b .L2
.size bs, .-bs
.ident "GCC: (Sourcery G++ Lite 2008q3-39) 4.3.2"
--
Summary: Optimizer handles loops with volatiles and post-
incr.
wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian dot schick at sciopta dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-mingw32
GCC target triplet: i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #1 from pinskia at gmail dot com 2009-07-08 08:13 ---
Subject: Re: New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com"
wrote:
> If the following code is compiled with -Os for ARM or ColdFire, the
> exit
> condition for the loop is removed.
> Replacing *tbl++ with tbl[i] or using unsigned long instead of
> volatile
> unsigned long does not show the problem.
> I suspect the post-increment optimization to be the problem, because
> the
> PowerPC version does not show the problem.
> Also: Using a different start-address for tbl, does not show the
> problem.
It looks more like a wrapping issue. 4*64 = 256. So we go from -256u
to 0 which causes wrapping of the pointer which is undefined and
therefor I think gcc is doing the correct thing (If got my numbers
correct).
>
> The problem has been reported also for 4.4.0.
>
> typedef volatile unsigned long __vu32;
> void bs()
> {
>int i;
>__vu32 *tbl = (__vu32 *)0xff00;
>for(i = 0; i < 64; ++i){
> //-> tbl[i] = (__vu32)10;
> *tbl++ = (__vu32)10;
>}
> }
> Cmd-line: arm-none-eabi-gcc -S -Os t.c
> Output:
>.cpu arm7tdmi
>.fpu softvfp
>.eabi_attribute 20, 1
>.eabi_attribute 21, 1
>.eabi_attribute 23, 3
>.eabi_attribute 24, 1
>.eabi_attribute 25, 1
>.eabi_attribute 26, 1
>.eabi_attribute 30, 4
>.eabi_attribute 18, 4
>.file "t.c"
>.text
>.align 2
>.global bs
>.type bs, %function
> bs:
>@ Function supports interworking.
>@ args = 0, pretend = 0, frame = 0
>@ frame_needed = 0, uses_anonymous_args = 0
>@ link register save eliminated.
>mvn r2, #255
> .L2:
>mov r3, #10
>str r3, [r2], #4
>b .L2
>.size bs, .-bs
>.ident "GCC: (Sourcery G++ Lite 2008q3-39) 4.3.2"
>
>
> --
> Summary: Optimizer handles loops with volatiles and post-
> incr.
>wrong
> Product: gcc
> Version: 4.3.2
>Status: UNCONFIRMED
> Severity: major
> Priority: P3
> Component: rtl-optimization
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: bastian dot schick at sciopta dot com
> GCC build triplet: i686-pc-linux-gnu
> GCC host triplet: i686-mingw32
> GCC target triplet: i686-mingw32
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug target/40677] flag -mmultiple is ignored
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-08 08:21 --- patches should be sent to gcc-patc...@gcc.gnu.org with a changelog entry and a note how it was tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #2 from bastian dot schick at sciopta dot com 2009-07-08 08:24 --- (In reply to comment #1) > > Sent from my iPhone Oh, dude (which one :-) > On Jul 8, 2009, at 12:32 AM, "bastian dot schick at sciopta dot com" > > wrote: > > > If the following code is compiled with -Os for ARM or ColdFire, the > > exit > > condition for the loop is removed. > > Replacing *tbl++ with tbl[i] or using unsigned long instead of > > volatile > > unsigned long does not show the problem. > > I suspect the post-increment optimization to be the problem, because > > the > > PowerPC version does not show the problem. > > Also: Using a different start-address for tbl, does not show the > > problem. > > It looks more like a wrapping issue. 4*64 = 256. So we go from -256u > to 0 which causes wrapping of the pointer which is undefined and If so, it should not be used, but it seems to be a new optimization as 3.4.4 does not use it. > therefor I think gcc is doing the correct thing (If got my numbers > correct). Replacing *tbl++ by tbl[i] gives this ARM code: .L2: mov r3, #10 str r3, [r2], #4 cmp r2, #0 bne .L2 bx lr See, gcc knows about the wrapping but still the *tbl++ version misses the end-condition which is the bug. Addenum: x86-gcc 4.3.3 (openSUSE 10.0) has the same problem. Compiling with -O, gives correct code with *tbl++ : .L2: mov r3, #10 str r3, [r2], #4 cmp r2, #0 bne .L2 bx lr -- bastian dot schick at sciopta dot com changed: What|Removed |Added CC||bastian dot schick at ||sciopta dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 08:25 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-08 08:25:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-08 08:49 --- On trunk with -fno-tree-vrp I see the correct code being generated. bs: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mvn r3, #255 mov r2, #10 .L2: str r2, [r3], #4 cmp r3, #0 bne .L2 bx lr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #4 from bastian dot schick at sciopta dot com 2009-07-08 09:06 --- (In reply to comment #3) > On trunk with -fno-tree-vrp I see the correct code being generated. It seems to be related to Bug #30785 (test for null pointer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug lto/39003] internal compiler error: in output_parm_decl, at lto-function-out.c:2652
--- Comment #3 from rubidium at openttd dot org 2009-07-08 09:12 --- I cannot reproduce this error anymore in gcc-lto (lto merged with rev 149291) 4.5.0 20090706 (experimental) revision 149340. However... I don't have the setup I've ran the previous test on, as such I have build it with another compiler for another platform (x86_64). On the other hand I'm hitting another internal compiler error in expand_expr_real_1, at expr.c:7382. But I'm not sure whether this is trunk or lto; I'm recompiling trunk right now though that takes a while. I'll open a new bug report for lto if it's really lto only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39003
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #5 from ramana at gcc dot gnu dot org 2009-07-08 09:12 --- Richi, Can you comment on this one ? Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug target/40680] New: extra register move
Compile the attached source code with options -Os -mthumb -march=armv5te, gcc
generates:
push{r3, r4, r5, lr}
.LCFI0:
mov r4, r0
ldr r0, [r0]
bl _Z3foof
ldr r1, [r4, #4]
@ sp needed for prologue
add r5, r0, #0
bl _Z3barfi
mov r0, r5 // *
bl _Z3fffi // *
mov r4, r5 // *
mov r5, r0 // *
mov r0, r4 // *
bl _Z3fffi // *
mov r1, r0 // *
mov r0, r5 // *
bl _Z3setii
pop {r3, r4, r5, pc}
There is an obvious extra register move (mov r4, r5) in the marked section, a
better code sequence of the marked section could be:
mov r0, r5
bl _Z3fffi
mov r4, r0
mov r0, r5
bl _Z3fffi
mov r1, r0
mov r0, r4
The marked code sequence before scheduler is:
mov r4, r5
mov r0, r5
bl _Z3fffi
mov r5, r0
mov r0, r4
bl _Z3fffi
mov r1, r0
mov r0, r5
The instruction (mov r4, r5 ) is generated by register allocator. I don't know
why RA generates this instruction.
--
Summary: extra register move
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
[Bug target/40680] extra register move
--- Comment #1 from carrot at google dot com 2009-07-08 09:36 --- Created an attachment (id=18155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18155&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 09:48 --- Well. I suppose that I should accept the bug :-) I will commit the fix to 4.4 over the weekend, so please try to test it to destruction on 4.5. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-07-07 05:01:00 |2009-07-08 09:48:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #6 from mikpe at it dot uu dot se 2009-07-08 09:59 --- (In reply to comment #2) > Replacing *tbl++ by tbl[i] gives this ARM code: > .L2: > mov r3, #10 > str r3, [r2], #4 > cmp r2, #0 > bne .L2 > bx lr > > See, gcc knows about the wrapping but still the *tbl++ version misses the > end-condition which is the bug. The difference is that in the tbl[i] version there will not be a wraparound at runtime because &tbl[i] for i == 64 is never computed, while in the *tbl++ version the iteration with i == 63 will do tbl++ moving tbl from -4U to 0 before the loop termination test, which triggers undefined behaviour. And the issue is not ARM, the same infinite loop occurs for e.g. target i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug target/40680] extra register move
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-08 10:00 ---
However Confirmed with trunk for Thumb1. The extra move doesn't appear for ARM
or Thumb2 .
The code below is what is generated for Thumb2 or ARM .
.type _ZN3CCC5funcAEv, %function
_ZN3CCC5funcAEv:
.fnstart
.LFB2:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, lr}@
.save {r3, r4, r5, lr}
.cfi_def_cfa_offset 16
mov r5, r0 @ this, this
.cfi_offset 14, -4
.cfi_offset 5, -8
.cfi_offset 4, -12
.cfi_offset 3, -16
ldr r0, [r0, #0]@ float @, .fRadius
bl _Z3foof @
ldr r1, [r5, #4]@, .flag
mov r4, r0 @ radius,
bl _Z3barfi@
mov r0, r4 @, data$fSignBitInt
bl _Z3fffi @
mov r5, r0 @ D.1797,
mov r0, r4 @, data$fSignBitInt
bl _Z3fffi @
mov r1, r0 @ D.1803,
mov r0, r5 @, D.1797
bl _Z3setii@
pop {r3, r4, r5, pc}
.cfi_endproc
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-08 10:00:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
[Bug bootstrap/40651] bootstrap error on arm-linux-gnueabi: segfault in next_const_call_expr_arg
--- Comment #1 from ramana at gcc dot gnu dot org 2009-07-08 10:01 --- Can you attach a pre-processed file for someone to look at this ? This bug report seems incomplete. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40651
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-08 10:10 --- Indeed the overflow invokes undefined behavior. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #3 from Thomas dot Lange at sun dot com 2009-07-08 10:23 --- (In reply to comment #2) > why don't you add a 'virtual' > to your destructor and int f(int) functions, because they are implicitly > virtual anyway'. That is exactly the point this is about! I want a way so the compiler enforces to add 'virtual' to ~B and B::f, and thus help to write better understandable code. This is in order for large derived trees or a big source code. It is for the one looking at the declaration (and not anymore or not at all familiar with the code!) to not miss that those functions are virtual. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
--- Comment #4 from Thomas dot Lange at sun dot com 2009-07-08 10:30 --- Side note: Of course having such an option is much more useful where the declaration of class A and B are in different header files and probably even in different modules. (For example: such cases are often found in the OpenOffice.org source code... ^_-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
[Bug lto/40681] New: [ICE] expand_expr_real_1, at expr.c:7382
Bug in lto revision 149340 (gcc 4.5 revision 149291 works fine) The used command line: /usr/local/lto/bin/g++-lto -v -save-temps -O2 -fomit-frame-pointer -flto -DUNIX -Wall -Wno-multichar -Wsign-compare -Wundef -Wwrite-strings -Wpointer-arith -Wno-uninitialized -W -Wno-unused-parameter -Wformat=2 -Wredundant-decls -fno-strict-aliasing -Wcast-qual -fno-strict-overflow -DWITH_SDL -I/usr/include/SDL -D_REENTRANT -DWITH_ZLIB -D_SQ64 -I/home/rubidium/openttd/special/lto/src/3rdparty/squirrel/include -DWITH_PNG -I/usr/include/libpng12 -DWITH_FONTCONFIG-DWITH_FREETYPE -I/usr/include/freetype2 -DWITH_ICU -D_REENTRANT -I/usr/include -DENABLE_NETWORK -DWITH_PERSONAL_DIR -DPERSONAL_DIR=\".openttd\" -DGLOBAL_DATA_DIR=\"/usr/local/share/games/openttd\" -I /home/rubidium/openttd/special/lto/objs/release -I /home/rubidium/openttd/special/lto/objs/lang -c -o misc_gui.o /home/rubidium/openttd/special/lto/src/misc_gui.cpp The output of the above line: Using built-in specs. COLLECT_GCC=/usr/local/lto/bin/g++-lto COLLECT_LTO_WRAPPER=/usr/local/lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../lto/configure --program-suffix=-lto --prefix=/usr/local/lto --enable-languages=c,c++ --enable-lto --enable-threads Thread model: posix gcc version 4.5.0 20090706 (experimental) (lto merged with rev 149291) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-fomit-frame-pointer' '-flto' '-DUNIX' '-Wall' '-Wno-multichar' '-Wsign-compare' '-Wundef' '-Wwrite-strings' '-Wpointer-arith' '-Wno-uninitialized' '-W' '-Wno-unused-parameter' '-Wformat=2' '-Wredundant-decls' '-fno-strict-aliasing' '-Wcast-qual' '-fno-strict-overflow' '-DWITH_SDL' '-I/usr/include/SDL' '-D_REENTRANT' '-DWITH_ZLIB' '-D_SQ64' '-I/home/rubidium/openttd/special/lto/src/3rdparty/squirrel/include' '-DWITH_PNG' '-I/usr/include/libpng12' '-DWITH_FONTCONFIG' '-DWITH_FREETYPE' '-I/usr/include/freetype2' '-DWITH_ICU' '-D_REENTRANT' '-I/usr/include' '-DENABLE_NETWORK' '-DWITH_PERSONAL_DIR' '-DPERSONAL_DIR=".openttd"' '-DGLOBAL_DATA_DIR="/usr/local/share/games/openttd"' '-I' '/home/rubidium/openttd/special/lto/objs/release' '-I' '/home/rubidium/openttd/special/lto/objs/lang' '-c' '-o' 'misc_gui.o' '-shared-libgcc' '-mtune=generic' /usr/local/lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus -E -quiet -v -I/usr/include/SDL -I/home/rubidium/openttd/special/lto/src/3rdparty/squirrel/include -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include -I /home/rubidium/openttd/special/lto/objs/release -I /home/rubidium/openttd/special/lto/objs/lang -D_GNU_SOURCE -DUNIX -DWITH_SDL -D_REENTRANT -DWITH_ZLIB -D_SQ64 -DWITH_PNG -DWITH_FONTCONFIG -DWITH_FREETYPE -DWITH_ICU -D_REENTRANT -DENABLE_NETWORK -DWITH_PERSONAL_DIR -DPERSONAL_DIR=".openttd" -DGLOBAL_DATA_DIR="/usr/local/share/games/openttd" /home/rubidium/openttd/special/lto/src/misc_gui.cpp -mtune=generic -Wall -Wno-multichar -Wsign-compare -Wundef -Wwrite-strings -Wpointer-arith -Wno-uninitialized -W -Wno-unused-parameter -Wformat=2 -Wredundant-decls -Wcast-qual -fomit-frame-pointer -flto -fno-strict-aliasing -fno-strict-overflow -O2 -fpch-preprocess -o misc_gui.ii ignoring nonexistent directory "/usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include" ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /usr/include/SDL /home/rubidium/openttd/special/lto/src/3rdparty/squirrel/include /usr/include/libpng12 /usr/include/freetype2 /home/rubidium/openttd/special/lto/objs/release /home/rubidium/openttd/special/lto/objs/lang /usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0 /usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/x86_64-unknown-linux-gnu /usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward /usr/local/include /usr/local/lto/include /usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /usr/local/lto/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-fomit-frame-pointer' '-flto' '-DUNIX' '-Wall' '-Wno-multichar' '-Wsign-compare' '-Wundef' '-Wwrite-strings' '-Wpointer-arith' '-Wno-uninitialized' '-W' '-Wno-unused-parameter' '-Wformat=2' '-Wredundant-decls' '-fno-strict-aliasing' '-Wcast-qual' '-fno-strict-overflow' '-DWITH_SDL' '-I/usr/include/SDL' '-D_REENTRANT' '-DWITH_ZLIB' '-D_SQ64' '-I/home/rubidium/openttd/special/lto/src/3rdparty/squirrel/include' '-DWITH_PNG' '-I/usr/include/libpng12' '-DWITH_FONTCONFIG' '-DWITH_FREETYPE' '-I/usr/include/freetype2' '-DWITH_ICU' '-D_REENTRANT' '-I/usr/include' '-DENABLE_NETWORK' '-DWITH_PERSONAL_DIR' '-DPERSONAL_DIR=".openttd"' '-DGLOBAL_DATA_DIR="/usr/local/share/games/openttd"' '-I' '/home/rubidium/openttd/special/lto/objs/release' '-I
[Bug lto/40681] [ICE] expand_expr_real_1, at expr.c:7382
--- Comment #1 from rubidium at openttd dot org 2009-07-08 10:42 --- Created an attachment (id=18156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18156&action=view) The .ii file of save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40681
[Bug other/40458] gcc flavours
--- Comment #6 from hp at gcc dot gnu dot org 2009-07-08 10:47 --- (In reply to comment #0) If it's just about the version, perhaps you can make -V working again. Requires a working --enable-version-specific-runtime-libs of course. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
[Bug other/40458] gcc flavours
--- Comment #7 from hp at gcc dot gnu dot org 2009-07-08 10:49 --- (In reply to comment #6) > If it's just about the version, perhaps you can make -V working again. Oh same version. Change the above to "make -b working again". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
[Bug target/40603] unnecessary conversion from unsigned byte load to signed byte load
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-08 10:49:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40603
[Bug c++/40682] New: Require direct binding of short-lived references to rvalues
In a recent discussion on comp.std.c++
"rvalue references returned from a function",
as pointed by Niels Dekker and Micael Dark,
a defect report:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
was accepted into C++0x WP. This has a significant impact on GCC.
The current behavior also creates a problem with the following:
struct R {
R(const R &);
};
R && func();
int main() {
R const & r1 = func();
R && r2 = func();
}
Both r1 and r2 will be bound to a temporary which will be
created by copying (or if available - moving) the returned
rvalue. This is invalid according to the mentioned changes.
--
Summary: Require direct binding of short-lived references to
rvalues
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dragan at plusplus dot co dot yu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40682
[Bug lto/39003] internal compiler error: in output_parm_decl, at lto-function-out.c:2652
--- Comment #4 from bje at gcc dot gnu dot org 2009-07-08 11:15 --- Reported as fixed by the original submitter. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39003
[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)
--- Comment #9 from sezeroz at gmail dot com 2009-07-08 11:37 --- Will there be a backport of this to the branches 4.3 and 4.4? -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-08 11:41 --- Note, in general work on C++0x features doesn't really belong to Bugzilla, unless existing code crashes on new testcases, things like that. You understand that in general the situation would otherwise quickly explode. About this specific issue, I suspect we even have something already open. Maybe Jon can help... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com Summary|Require direct binding of |[C++0x] Require direct |short-lived references to |binding of short-lived |rvalues |references to rvalues http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40682
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #4 from dominiq at lps dot ens dot fr 2009-07-08 11:47 --- It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and Intel64(?), see http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00755.html http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00078.html -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug lto/39042] [LTO] LTO tests don't cleanup temporary files
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-08 11:49 --- This is fixed in lto revision 149354. I ran make check-gcc and watched /tmp. Temporary files were removed as the testsuite ran. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)
--- Comment #10 from kkojima at gcc dot gnu dot org 2009-07-08 11:54 --- I don't think this is a regression, unfortunately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-08 12:37 --- (In reply to comment #4) > It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and > Intel64(?), see I can - somewhat - reproduce it. It does not fail but valgrind shows (x86-64-linux and i686-linux): ==32231== Conditional jump or move depends on uninitialised value(s) ==32231==at 0x80485A2: test.1513 (proc_ptr_21.f90:26) ==32231==by 0x8048548: MAIN__ (proc_ptr_21.f90:8) ==32231==by 0x80485F4: main (proc_ptr_21.f90:8) That is solved by adding: i = 0 to subroutine test (while any other number causes the abortion). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues
--- Comment #2 from dragan at plusplus dot co dot yu 2009-07-08 12:38 --- Although this is a feature request in the context that the old behavior was correctly implemented and it will be different in C++0x, it still presents a bug in the current C++0x implementation. It creates copies of objects that are returned by a rvalue reference, which would be wrong. I wasn't _really_ trying to request a new functionality, although I understand your concern. However, IMHO in this particular case we are talking about one of the most fundamental features (binding a reference). This change could also expose possible bugs in the (user and library) code that relies on creation of a temporary, which even in C++03 is not considered a portable code. Don't tell me you'd rather deal with the issue after all the other C++0x stuff gets implemented... Anyway, my motive was to help the development of GCC. Personally, I didn't and will not rely on either of the two behaviors, but will try to write code that works in both situations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40682
[Bug c++/40682] [C++0x] Require direct binding of short-lived references to rvalues
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-08 12:47 --- To be clear, I'm not telling you anything specific about the development process. Actually, that's exactly the point, this is ongoing development of experimental features, no guarantees, no guarantees of perfect adherence to the last public draft, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40682
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #8 from bastian dot schick at sciopta dot com 2009-07-08 13:06 --- (In reply to comment #6) > (In reply to comment #2) > > Replacing *tbl++ by tbl[i] gives this ARM code: > > .L2: > > mov r3, #10 > > str r3, [r2], #4 > > cmp r2, #0 > > bne .L2 > > bx lr > > > > See, gcc knows about the wrapping but still the *tbl++ version misses the > > end-condition which is the bug. > > The difference is that in the tbl[i] version there will not be a wraparound at > runtime because &tbl[i] for i == 64 is never computed, while in the *tbl++ > version the iteration with i == 63 will do tbl++ moving tbl from -4U to 0 > before the loop termination test, which triggers undefined behaviour. Ok fine, but why does it generate correct code if not using volatile for the pointer ?! mvn r2, #251 .L2: mov r3, #10 str r3, [r2, #-4] add r2, r2, #4 cmp r2, #4 bne .L2 bx lr Strange, no post-increment code is generated. The 68k version still uses post-increment and voilà, endless-loop. Also see the code for the tbl[i] version, the pointer still wraps. I suspect following: The test for 0 is removed maybe because the post-increment is defined to change flags( which it isn't). Since there is no test, the next optimization changes a "jump not zero" to an "jump always". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-08 13:11 --- induction variable optimization is different w/o volatile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug fortran/40683] New: gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit
On Linux/ia32, revision 149362 gave FAIL: gfortran.dg/proc_ptr_21.f90 -O1 execution test FAIL: gfortran.dg/proc_ptr_21.f90 -O2 execution test FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -g execution test FAIL: gfortran.dg/proc_ptr_21.f90 -Os execution test I got the same result with gcc -m32 on Linux/x86-64. -- Summary: gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
[Bug fortran/40629] Host association problem
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 13:22 ---
Created an attachment (id=18157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view)
Fix for bug - not regtested yet
This handles host_assoc_function_*.f90 correctly but is not yet regtested.
The testcase will be something like:
! { dg-do run }
! Tests the fix for the bug PR40629, in which the reference to 'x'
! in 'upper' wrongly host-associated with the symbol 'x' at module
! leve rather than the function.
!
! Contributed by Philippe Marguinaud
!
MODULE m
REAL :: x = 0
CONTAINS
SUBROUTINE s
call upper
call lower
CONTAINS
SUBROUTINE upper
y = x(3,1)
if (int(y) .ne. 3) call abort
END SUBROUTINE
FUNCTION x(n, m)
x = m*n
END FUNCTION
SUBROUTINE lower
y = x(2,1)
if (int(y) .ne. 3) call abort
END SUBROUTINE
END SUBROUTINE
END MODULE
use m
call s
end
! { dg-final { cleanup-modules "m" } }
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �� does break strict-aliasing rules
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 13:25 --- (In reply to comment #3) > > Note that getInt is completely inlined and there is no location involving > that function available anymore :/ The difficulties of C++ and late > diagnostics ... Don't we keep abstract_origin somewhere? I have seen in the middle-end that sometimes we test whether something is an inline variable or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-08 13:28 --- See pr40591 comments #4 and #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-08 13:28 --- I am going to close this as FIXED, since it cannot be reproduced anymore. If anyone manages to reproduce it in GCC 4.5, please reopen. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #6 from pault at gcc dot gnu dot org 2009-07-08 13:28 --- (In reply to comment #5) > That is solved by adding: >i = 0 > to subroutine test (while any other number causes the abortion). > Indeed - that was in the test originally; I do not know what happened to it. I'll put it right tonight. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit
--- Comment #2 from pault at gcc dot gnu dot org 2009-07-08 13:29 --- (In reply to comment #1) > See pr40591 comments #4 and #5. > Indeed! I'll fix it tonight. Thanks, HJ Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-08 13:29:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
[Bug fortran/40591] Procedure(interface): Rejected if interface is indirectly hostassociated
--- Comment #7 from dominiq at lps dot ens dot fr 2009-07-08 13:31 --- pr40683 is a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
[Bug c++/40557] [4.5 Regression] ICE with template union
--- Comment #4 from hjl at gcc dot gnu dot org 2009-07-08 14:30 --- Subject: Bug 40557 Author: hjl Date: Wed Jul 8 14:30:12 2009 New Revision: 149371 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149371 Log: 2009-07-08 H.J. Lu Backport from mainline: 2009-07-06 Simon Martin PR c++/40557 * g++.dg/template/union2.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/union2.C - copied unchanged from r149370, trunk/gcc/testsuite/g++.dg/template/union2.C Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40557
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-08 14:55 --- Created an attachment (id=18158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view) Patch - lightly tested Attached patch fixes the problem [independent of "-f(no-)signed-zeros"/-ffast-math]. The crucial option is "-fno-sign-zero" (which shall not be confused with -f(no-)signed-zeros): $ gfortran -O3 -fno-sign-zero ahfj.f90 && ./a.out With val =0.000 test =0.000 pass -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/40677] flag -mmultiple is ignored
--- Comment #4 from edmar at freescale dot com 2009-07-08 15:06 --- I did not run any test suite, nor prepared any test case suitable for inclusion in dejagnu suite. I opened a bug hopping the information I gave would help resolve the issue faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug c++/40684] New: ICE in tsubst
// { dg-options "-std=c++0x" }
struct A
{
};
template
typename S::A
foo (S c, T t, U u)
{
}
struct B
{
struct C
{
template
C (U t)
{
A a;
A b = foo (this, a, t);
}
} c;
B () : c (A ())
{
}
};
int
main ()
{
B f;
}
ICEs in tsubst (seeing ADDR_EXPR there). This is likely invalid testcase,
though the ICE is the only diagnostics issued, whether the original
testcase from http://bugzilla.redhat.com/509596 is valid or not is unclear.
--
Summary: ICE in tsubst
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40684
[Bug c++/40685] New: explicit constructor is used where only implicit ctors are allowed
The following testcase fails on g++ 4.4.0 and 4.3.2:
#include
enum Enum {
Foo
};
class A
{
public:
A(int y) : x(y) {}
explicit A(Enum) : x(1) {}
int x;
};
static void fun(A a = Foo)
{
if (a.x != static_cast(Foo)) {
abort();
}
}
int main()
{
fun();
return 0;
}
If the A(int) ctor is removed the program does not compile, as is expected. If
the line "A a = Foo" appears inside the function instead of the parameter list
then g++ correctly uses the A(int) ctor.
While on that topic: The code above was meant to use the Enum ctor, it would be
nice if g++ emits a warning about the emitted code probably using the wrong
ctor.
--
Summary: explicit constructor is used where only implicit ctors
are allowed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kretz at kde dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40685
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #16 from rth at gcc dot gnu dot org 2009-07-08 16:41 --- Subject: Bug 38900 Author: rth Date: Wed Jul 8 16:41:23 2009 New Revision: 149373 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149373 Log: PR target/38900 * config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Move to i386.c. (enum reg_class): Add CLOBBERED_REGS. (REG_CLASS_NAMES, REG_CLASS_CONTENTS): Likewise. * config/i386/i386.c (ix86_conditional_register_usage): Moved from CONDITIONAL_REGISTER_USAGE; build CLOBBERED_REGS for 64-bit. (ix86_function_ok_for_sibcall): Tidy. Disallow MS->SYSV sibcalls. (ix86_expand_call): Use sibcall_insn_operand when needed. Don't force 64-bit sibcalls into R11. * config/i386/constraints.md (U): New constraint. * config/i386/i386.md (sibcall_1, sibcall_value_1): Use it. (sibcall_1_rex64, sibcall_value_1_rex64): Likewise. (sibcall_1_rex64_v, sibcall_value_1_rex64_v): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/constraints.md trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #7 from mikpe at it dot uu dot se 2009-07-08 16:43 --- 4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a working 2.6.31-rc2 Linux kernel, and built a working Erlang VM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #12 from kargl at gcc dot gnu dot org 2009-07-08 16:49 --- Created an attachment (id=18160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18160&action=view) dejagnu testr case Test that sign(x, +-0) conforms to F95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #13 from kargl at gcc dot gnu dot org 2009-07-08 16:50 --- Created an attachment (id=18161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18161&action=view) dejagnu test case Test case for sign(x,+-0) when the new -fno-sign-zero option is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #14 from kargl at gcc dot gnu dot org 2009-07-08 16:56 --- (In reply to comment #11) > Created an attachment (id=18158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158&action=view) [edit] > Patch - lightly tested > > Attached patch fixes the problem [independent of > "-f(no-)signed-zeros"/-ffast-math]. > > The crucial option is "-fno-sign-zero" (which shall not be confused with > -f(no-)signed-zeros): > > $ gfortran -O3 -fno-sign-zero ahfj.f90 && ./a.out > With val =0.000 test =0.000 > pass > I've tested the patch and the -ftree-dump-original output looks correct. I've also attached two testcase for the testsuite. I do note that this option is activated by -std=legacy. Perhaps, it should be. Patch is okay. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #17 from rth at gcc dot gnu dot org 2009-07-08 16:59 --- Subject: Bug 38900 Author: rth Date: Wed Jul 8 16:59:15 2009 New Revision: 149374 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149374 Log: PR target/38900 * config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Move to i386.c. (enum reg_class): Add CLOBBERED_REGS. (REG_CLASS_NAMES, REG_CLASS_CONTENTS): Likewise. * config/i386/i386.c (ix86_conditional_register_usage): Moved from CONDITIONAL_REGISTER_USAGE; build CLOBBERED_REGS for 64-bit. (ix86_function_ok_for_sibcall): Tidy. Disallow MS->SYSV sibcalls. (ix86_expand_call): Use sibcall_insn_operand when needed. Don't force 64-bit sibcalls into R11. * config/i386/constraints.md (U): New constraint. * config/i386/i386.md (sibcall_1, sibcall_value_1): Use it. (sibcall_1_rex64, sibcall_value_1_rex64): Likewise. (sibcall_1_rex64_v, sibcall_value_1_rex64_v): Remove. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/constraints.md branches/gcc-4_4-branch/gcc/config/i386/i386-protos.h branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/config/i386/i386.h branches/gcc-4_4-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #18 from rth at gcc dot gnu dot org 2009-07-08 17:03 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-08 17:08 ---
I can reproduce the error with plugin.exp not struct-layout-1.exp. This fixes
it for me, does it for you guys?
Index: gcc/testsuite/lib/gcc.exp
===
--- gcc/testsuite/lib/gcc.exp (revision 149287)
+++ gcc/testsuite/lib/gcc.exp (working copy)
@@ -96,6 +96,7 @@ proc gcc_init { args } {
global TOOL_EXECUTABLE
global gcc_warning_prefix
global gcc_error_prefix
+global ld_library_path
if { $gcc_initialized == 1 } { return; }
@@ -113,6 +114,7 @@ proc gcc_init { args } {
set gcc_warning_prefix "warning:"
set gcc_error_prefix "error:"
+set ld_library_path ""
gcc_maybe_build_wrapper "${tmpdir}/gcc-testglue.o"
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch
--- Comment #8 from blp at cs dot stanford dot edu 2009-07-08 17:30 --- Wow, that's amazingly fast turnaround. Thanks so much guys! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
[Bug testsuite/40625] [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp"
--- Comment #4 from tjruwase at google dot com 2009-07-08 17:59 --- Subject: Re: [4.5 Regression] Errors in "make -k check-gcc RUNTESTFLAGS=plugin.exp" Your fix works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
[Bug debug/40659] A simple struct member offset doesn't need a full dwarf location expression
--- Comment #1 from mark at gcc dot gnu dot org 2009-07-08 18:08 --- Subject: Bug 40659 Author: mark Date: Wed Jul 8 18:07:47 2009 New Revision: 149377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149377 Log: 2009-07-08 Mark Wielaard PR debug/40659 * dwarf2out.c (add_data_member_location_attribute): When we have only a constant offset don't emit a new location description using DW_OP_plus_uconst, but just add the constant with add_AT_int, when dwarf_version > 2. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40659
[Bug c/40686] New: Optimization Problem With Data Conversion
Our HDF5 software has been having some data conversion problem with GCC's optimization for a few years. One example is to convert data from short to int. You can find the program at ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/slu/tmp/ctest.c When I use "gcc -O2" or "gcc -O3" to compile it, I get wrong values after the conversion. When I use "gcc -O0" or "gcc -O1", the values are correct. I'll greatly appreciate your help if you can have a look at it. -- Summary: Optimization Problem With Data Conversion Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: songyulu at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40686
[Bug debug/40659] A simple struct member offset doesn't need a full dwarf location expression
--- Comment #2 from mark at gcc dot gnu dot org 2009-07-08 18:21 --- Patch pushed. -- mark at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40659
[Bug c/40686] Optimization Problem With Data Conversion
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 18:22 ---
You are violating C/C++ aliasing rules:
d = (uint8_t*)&aligned;
/* This line causes the trouble. */
*((int*)d) = (int)(*((short*)s));
You are writing into a long long via an int which causes undefined behavior.
There are more aliasing problems in this file too with the loop at:
printf("before conversion:\n");
And
printf("after conversion:\n");
As those are accessing an char via a short or an int.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40686
[Bug c/21920] aliasing violations
--- Comment #142 from pinskia at gcc dot gnu dot org 2009-07-08 18:22 --- *** Bug 40686 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||songyulu at hdfgroup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug fortran/40683] gfortran.dg/proc_ptr_21.f90 doesn't work for 32bit
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 19:00 --- Subject: Bug 40683 Author: pault Date: Wed Jul 8 19:00:17 2009 New Revision: 149383 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149383 Log: 2008-07-08 Paul Thomas PR fortran/40683 * gfortran.dg/proc_ptr_21.f90: Initialize 'i'. Modified: trunk/gcc/testsuite/gfortran.dg/proc_ptr_21.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
[Bug fortran/40629] Host association problem
--- Comment #4 from pault at gcc dot gnu dot org 2009-07-08 19:05 ---
(In reply to comment #3)
> Created an attachment (id=18157)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157&action=view) [edit]
> Fix for bug - not regtested yet
>
> This handles host_assoc_function_*.f90 correctly but is not yet regtested.
>
> The testcase will be something like:
>
> ! { dg-do run }
> ! Tests the fix for the bug PR40629, in which the reference to 'x'
> ! in 'upper' wrongly host-associated with the symbol 'x' at module
> ! leve rather than the function.
> !
> ! Contributed by Philippe Marguinaud
> !
> MODULE m
> REAL :: x = 0
> CONTAINS
>
>
>
>
>
>
>
>
>
>
>
> SUBROUTINE s
> call upper
> call lower
> CONTAINS
> SUBROUTINE upper
> y = x(3,1)
> if (int(y) .ne. 3) call abort
> END SUBROUTINE
> FUNCTION x(n, m)
>x = m*n
> END FUNCTION
> SUBROUTINE lower
> y = x(2,1)
> if (int(y) .ne. 3) call abort
> END SUBROUTINE
> END SUBROUTINE
> END MODULE
>
> use m
> call s
> end
> ! { dg-final { cleanup-modules "m" } }
>
>
> Paul
>
The last abort should happen on a value of 2, of course.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40629
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #15 from burnus at gcc dot gnu dot org 2009-07-08 19:35 --- Subject: Bug 40675 Author: burnus Date: Wed Jul 8 19:34:49 2009 New Revision: 149390 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149390 Log: 2009-07-08 Tobias Burnus PR fortran/40675 * simplify.c (gfc_simplify_sign): Handle signed zero correctly. * trans-intrinsic.c (gfc_conv_intrinsic_sign): Support -fno-sign-zero. * invoke.texi (-fno-sign-zero): Add text regarding SIGN * intrinsic. 2009-07-08 Tobias Burnus PR fortran/40675 * gfortran.dg/nosigned_zero_1.f90: New test. * gfortran.dg/nosigned_zero_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/nosigned_zero_1.f90 trunk/gcc/testsuite/gfortran.dg/nosigned_zero_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #3 from aapo dot rantalainen at gmail dot com 2009-07-08 19:36
---
Above code doesn't compile:
int main(int argc, char *argv[])
{
int a=1;
switch (a)
{
case 1:
int b=2;
break;
}
return 0;
}
Error "a label can only be part of a statement and a declaration is not a
statement"
Same workaround: add ; before int b=2;
gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-07-08 19:42 --- (In reply to comment #3) > Above code doesn't compile: Yes it should not be compile. The error message has been improved to tell you what the problem is (that is what Manu was saying in his comment #2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug tree-optimization/34437] several test failures for gcc.dg/vect/no-scevccp-*
--- Comment #8 from janis at gcc dot gnu dot org 2009-07-08 19:48 --- Fixed awhile ago by changing -mabi=altivec to the default for powerpc*-linux. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34437
[Bug c++/40687] New: [C++0x]: error with auto and 7.1.6.4/7 in N2914
Hi,
I think there is a bug in g++ 4.4 concerning the implementation of auto.
7.1.6.4/7 in N2914
The following program compiles, but it should be rejected by g++.
int main()
{
auto i = 10, d = 5.0; // error! shall not compile in C++0x
return 0;
}
$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)
$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4BugAutoN2914.cpp
g++4.4BugAutoN2914.cpp: In function 'int main()':
g++4.4BugAutoN2914.cpp:4: warning: unused variable 'i'
g++4.4BugAutoN2914.cpp:4: warning: unused variable 'd'
--
Summary: [C++0x]: error with auto and 7.1.6.4/7 in N2914
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40687
[Bug c++/40687] [C++0x]: error with auto and 7.1.6.4/7 in N2914
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08 20:07 --- Created an attachment (id=18162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18162&action=view) program which should not compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40687
[Bug c++/40684] ICE in tsubst
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-08 20:11 ---
I could reproduce on trunk.
I am testing the patchlet below:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b4bd465..d042f98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12949,8 +12949,9 @@ type_unification_real (tree tparms,
to explicitly check cxx_dialect here. */
if (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)))
{
- tree arg = tsubst (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)),
- targs, tf_none, NULL_TREE);
+ tree arg = tsubst_template_arg
+ (TREE_PURPOSE (TREE_VEC_ELT (tparms, i)),
+targs, tf_none, NULL_TREE);
if (arg == error_mark_node)
return 1;
else
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
CC||dodji at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-08 20:11:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40684
[Bug c++/40688] New: [C++0x]: error with auto direct and copy initalization
Hi,
I think there is another bug in g++ 4.4 concerning the implementation of auto
with direct and copy initialization 7.1.6.4/3 in N2914
The following program should compile, but is rejected by g++.
int main()
{
auto v1 = 1; // copy initialization syntax
auto v2(2); // direct initialization syntax
return 0;
}
$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)
$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4Bug2AutoN2914.cpp
g++4.4Bug2AutoN2914.cpp: In function 'int main()':
g++4.4Bug2AutoN2914.cpp:5: error: 'v2' has incomplete type
g++4.4Bug2AutoN2914.cpp:4: warning: unused variable 'v1'
g++4.4Bug2AutoN2914.cpp:5: warning: unused variable 'v2'
--
Summary: [C++0x]: error with auto direct and copy initalization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40688
[Bug c++/40688] [C++0x]: error with auto direct and copy initalization
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08 20:16 --- Created an attachment (id=18163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18163&action=view) program which should compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40688
[Bug c++/40689] New: [C++0x]: error with initializer list in N2672
Hi,
I think there is a bug in g++ 4.4 concerning the implementation of initializer
list. N2672
The following program does not compiles, but it should be accepted by g++.
// /opt/gcc-4.4/bin/g++ --std=c++0x -Wall
int main()
{
class X
{
public:
X(): data {1,2,3,4,5} {}
private:
const short data[5];
};
const float * pData = new const float[4] { 1.5, 2.5, 3.5, 4.5 };
return 0;
}
$ /opt/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.4
Thread model: single
gcc version 4.4.0 (GCC)
$ /opt/gcc-4.4/bin/g++ --std=c++0x -Wall g++4.4BugN2672.cpp
g++4.4BugN2672.cpp: In constructor 'main()::X::X()':
g++4.4BugN2672.cpp:8: error: conversion from '' to non-scalar type 'const short int [5]
' requested
g++4.4BugN2672.cpp: In function 'int main()':
g++4.4BugN2672.cpp:12: error: ISO C++ forbids initialization in array new
g++4.4BugN2672.cpp:12: warning: unused variable 'pData'
--
Summary: [C++0x]: error with initializer list in N2672
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot merkle at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
[Bug c++/40689] [C++0x]: error with initializer list in N2672
--- Comment #1 from bernhard dot merkle at googlemail dot com 2009-07-08 20:29 --- Created an attachment (id=18164) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18164&action=view) program which should compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
[Bug c++/40689] [C++0x]: error with initializer list in N2672
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 20:38 --- Before filing more bugs please verify the bugs exist on a recent version of the development trunk for GCC 4.5. C++0x is considered incomplete technology preview only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
[Bug tree-optimization/40690] New: invalid conversion in gimple call for vect tests
On powerpc*-unknown-linux-gnu several vectorization tests ICE in verify_stmts
after the error message "invalid conversion in gimple call":
gcc.dg/vect/no-scevccp-outer-7.c
gcc.dg/vect/no-scevccp-outer-13.c
gcc.dg/vect/slp-perm-1.c
gcc.dg/vect/slp-perm-2.c
gcc.dg/vect/slp-perm-3.c
gcc.dg/vect/slp-perm-8.c
gcc.dg/vect/vect-reduc-dot-u8b.c
The failures begin with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=146831
r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)
Here's a minimized testcase usable with a powerpc-linux cross compiler:
---
extern unsigned char X[64] __attribute__ ((__aligned__(32)));
extern unsigned char Y[64] __attribute__ ((__aligned__(32)));
unsigned short
foo (int len) {
int i;
unsigned short result = 0;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690
[Bug c/39959] [4.5 Regression] IMA is broken
--- Comment #4 from janis at gcc dot gnu dot org 2009-07-08 20:46 --- On powerpc*-linux this test begins failing in the same way with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=146831 r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-08 20:46 --- On powerpc*-linux the test begins to fail in the same way with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=146831 r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug tree-optimization/40690] invalid conversion in gimple call for vect tests
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 20:49 --- I think this is really PR 30210. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #16 from burnus at gcc dot gnu dot org 2009-07-08 20:55 --- Close as FIXED (on the trunk [= 4.5]). Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly builds) gfortran will offer the option -fno-sign-zero which allows your program to work. However, I still would like to suggest to change the program such that it will work also the default options. The problem will presumably also appear with other compilers - for instance if they change their default. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug c++/40689] [C++0x]: error with initializer list in N2672
--- Comment #3 from bernhard dot merkle at googlemail dot com 2009-07-08 20:56 --- makes sense, thanks for the hint. is there doc to which N papers the 4.5 trunk relates ? e.g. like http://gcc.gnu.org/projects/cxx0x.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
[Bug libstdc++/40691] New: bug in logical not operator for valarray used with slice
Use of operator! (logical not) from valarray with slice fails. For example,
--
#include
void test01()
{
const std::valarray vi(12);
std::valarray vb1(12);
std::valarray vb2(3);
std::slice s(0,3,4);
vb1 = !vi; // ok
vb2 = !(std::valarray)vi[s]; // ok
vb2 = !vi[s]; // fails
}
--
fails with:
elm3b187% /opt/gcc-nightly/trunk/bin/g++ -c valarray-bug.cc
In file included from
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/valarray:562:0,
from valarray-bug.cc:1:
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/bits/valarray_after.h:
In member function std::_Expr, bool> std::_Expr<_Clos, _Tp>::operator!() const [with _Clos =
std::_SClos, _Tp = int]:
valarray-bug.cc:12:14: instantiated from here
/opt/gcc-nightly/trunk-20090706/lib/gcc/powerpc64-linux/4.5.0/../../../../include/c++/4.5.0/bits/valarray_after.h:318:61:
error: conversion from std::_Expr >, int> to non-scalar type
std::_Expr >, bool> requested
That's std::_Expr,int>
to std::_expr,bool>
I'm about to submit a proposed patch but would like a PR to keep track of this.
--
Summary: bug in logical not operator for valarray used with slice
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40691
[Bug tree-optimization/40690] invalid conversion in gimple call for vect tests
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 21:03 --- It is. *** This bug has been marked as a duplicate of 30210 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-07-08 21:03 --- *** Bug 40690 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug fortran/40675] Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility
--- Comment #17 from gdsjaar at sandia dot gov 2009-07-08 21:03 --- Subject: Re: Support -fnosign-zero for SIGN intrinsic for Fortran 77 compatibility Thanks for the quick response. I agree that the ultimate fix is to remove that idiom from the code; however, when dealing with decades old fortran code, we don't always have the time or resources to do it right. I will try to write a better test code next time that isn't buggy... --Greg burnus at gcc dot gnu dot org wrote: > --- Comment #16 from burnus at gcc dot gnu dot org 2009-07-08 20:55 > --- > Close as FIXED (on the trunk [= 4.5]). > > Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly > builds) gfortran will offer the option -fno-sign-zero which allows your > program to work. > > However, I still would like to suggest to change the program such that it will > work also the default options. The problem will presumably also appear with > other compilers - for instance if they change their default. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40675
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-07-08 21:04 --- Mike - you said you have patches for this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||meissner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug c++/40689] [C++0x]: error with initializer list in N2672
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-08 21:05 --- I don't think so. Likely nobody bothered to update that document recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
[Bug c/39959] [4.5 Regression] IMA is broken
--- Comment #5 from janis at gcc dot gnu dot org 2009-07-08 21:28 --- The test started failing with the patch reported in comment #8 because it enabled type checking; sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-08 21:29 --- The test started failing with the patch reported in comment #2 because it enabled type checking; sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 21:34 --- (In reply to comment #4) > (In reply to comment #3) > > Above code doesn't compile: > > Yes it should not be compile. The error message has been improved to tell you > what the problem is (that is what Manu was saying in his comment #2). Indeed. Aapo, what is difficult to understand from the the current error message? I would like to improve it as much as possible. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||aapo dot rantalainen at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #20 from pthaugen at gcc dot gnu dot org 2009-07-08 21:53
---
Created an attachment (id=18165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18165&action=view)
Reduced testcase
The attatched testcase exhibits the problem with the load-hit-store. It's
resulting from choosing a bad register class (GENERAL_REGS) for a pseudo that
should get assigned to FLOAT_REGS. Since there is no FPR -> GPR move for
-mcpu=power6 the copy must go through memory. I compiled the testcase with
-m64 -O3 -mcpu=power6 using trunk revision 149376. The pseudo in question is
361.
Following are the 3 insns referencing reg 361 in the sched1 dump (before ira):
(insn 51 238 241 8 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 358 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 47 46 231 9 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 179 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 196 194 198 11 thin6d_reduced.f:169 (set (mem/c/i:DF (plus:DI (reg/f:DI
477)
(const_int 56 [0x38])) [2 crkve+0 S8 A64])
(reg:DF 361 [ prephitmp.35 ])) 351 {*movdf_hardfloat64}
(expr_list:REG_DEAD (reg:DF 361 [ prephitmp.35 ])
(nil)))
And from the ira dump:
Pass1 cost computation:
a71 (r361,l1) best GENERAL_REGS, cover GENERAL_REGS
a3 (r361,l0) best GENERAL_REGS, cover GENERAL_REGS
a3(r361,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:156,1836 CTR_REGS:156,1836 SPECIAL_REGS:156,1836 MEM:156
a71(r361,l1) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:1680,1680 CTR_REGS:1680,1680 SPECIAL_REGS:1680,1680 MEM:1120
Pass 2 cost computation:
r361: preferred GENERAL_REGS, alternative NO_REGS
a3(r361,l0) costs: BASE_REGS:0,2240 GENERAL_REGS:0,2240 FLOAT_REGS:312,2552
LINK_REGS:234,4154 CTR_REGS:234,4154 SPECIAL_REGS:234,4154 MEM:156
a71(r361,l1) costs: BASE_REGS:2240,2240 GENERAL_REGS:2240,2240
FLOAT_REGS:2240,2240 LINK_REGS:3920,3920 CTR_REGS:3920,3920
SPECIAL_REGS:3920,3920 MEM:3360
Not sure what's causing the FLOAT cost to be higher than the GENERAL cost yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c++/8045] Missing "unused variable" warning
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 22:08 --- Are there some cases where a declaration such T x = y can be considered an use of 'x' by itself? The following patch warns for this, but it also produces warnings for some testcases in the testsuite. Index: gcc/cp/init.c === --- gcc/cp/init.c (revision 149319) +++ gcc/cp/init.c (working copy) @@ -1261,11 +1261,11 @@ build_aggr_init (tree exp, tree init, in if (init) TREE_TYPE (init) = itype; return stmt_expr; } - if (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == PARM_DECL) + if (TREE_CODE (exp) == PARM_DECL) /* Just know that we've seen something for this node. */ TREE_USED (exp) = 1; is_global = begin_init_stmts (&stmt_expr, &compound_stmt); destroy_temps = stmts_are_full_exprs_p (); -- manu at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.0 Last reconfirmed|2005-12-11 23:03:44 |2009-07-08 22:08:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8045
[Bug middle-end/40692] New: [4.5 Regression] Endless recursion between fold_ternary and fold_cond_expr_with_comparison
Linux kernel, in particularly xen-blkfront.c, doesn't compile with GCC trunk.
4.5.0 20090625 was still fine, 4.5.0 20090630 is already wrong.
Simplified testcase:
#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M1 (x))
struct A { char f[1]; };
char a[M2 (4096UL - (long)&((struct A *) 16)->f)];
--
Summary: [4.5 Regression] Endless recursion between fold_ternary
and fold_cond_expr_with_comparison
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40692
[Bug libstdc++/40691] bug in logical not operator for valarray used with slice
--- Comment #1 from janis at gcc dot gnu dot org 2009-07-08 22:27 --- Subject: Bug 40691 Author: janis Date: Wed Jul 8 22:26:50 2009 New Revision: 149393 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149393 Log: PR libstdc++/40691 * include/bugs/valarray-after.h (_Expr::operator!): Fix return type. * testsuite/26_numerics/valarray/40691.cc: New test. Added: trunk/libstdc++-v3/testsuite/26_numerics/valarray/40691.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/valarray_after.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40691
[Bug middle-end/40692] [4.5 Regression] Endless recursion between fold_ternary and fold_cond_expr_with_comparison
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-08 23:09 ---
Caused by r149060. Will debug tomorrow.
Alternative testcase that doesn't warn about VLA at file scope:
#define M1(x) (((x) & 0x0002) ? 0x2 : ((x) & 0x1))
#define M2(x) (((x) & 0x000c) ? M1 ((x) >> 2) << 2 : M1 (x))
struct A { char f[1]; };
int foo (void)
{
return M2 (4096UL - (long)&((struct A *) 16UL)->f);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40692
