[Bug target/49515] [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49515 --- Comment #2 from Uros Bizjak 2011-06-24 07:42:20 UTC --- (In reply to comment #1) > Is linker relaxation messing with this code sequence, perhaps? You are correct. Adding -Wl,--no-relax produces correct binary. I will open a binutils bugreport and recycle this one as a RA problem due to extra register move.
[Bug target/49515] [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49515 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Uros Bizjak 2011-06-24 07:56:16 UTC --- (In reply to comment #2) > I will open a binutils bugreport... Binutils PR 12928 [1]. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12928
[Bug tree-optimization/49518] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49518
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.24 08:07:13
CC||jakub at gcc dot gnu.org
Component|c |tree-optimization
Target Milestone|--- |4.6.1
Summary|ICE in |[4.6/4.7 Regression] ICE in
|vect_enhance_data_refs_alig |vect_enhance_data_refs_alig
|nment, at |nment, at
|tree-vect-data-refs.c:1555 |tree-vect-data-refs.c:1555
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek 2011-06-24
08:07:13 UTC ---
Simplified testcase:
int a, b;
struct S { unsigned int s, t, u; } c, d = { 0, 1, 0 };
void
test (unsigned char z)
{
char e[] = {0, 0, 0, 0, 1};
for (c.s = 1; c.s; c.s++)
{
b = e[c.s];
if (a)
break;
b = z >= c.u;
if (d.t)
break;
}
}
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167184
[Bug tree-optimization/49518] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49518 --- Comment #2 from Jakub Jelinek 2011-06-24 08:49:15 UTC --- And with -O3 -fno-tree-copy-prop this started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166244 Perhaps that patch should have adjusted the assert too?
[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49502 --- Comment #6 from Franck Z 2011-06-24 08:53:50 UTC --- Agreed. :-)
[Bug target/48308] [4.6 regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Summary|crosscompiling to arm fails |[4.6 regression]
|with assembler: can't |crosscompiling to arm fails
|resolve '.LC4' |with assembler: can't
|{.rodata.str1.1 section} - |resolve '.LC4'
|'.LPIC4' {*UND* section}|{.rodata.str1.1 section} -
||'.LPIC4' {*UND* section}
--- Comment #8 from Ramana Radhakrishnan 2011-06-24
09:15:08 UTC ---
Not sure if this is a target or tree-optimization issue yet.
Ramana
[Bug tree-optimization/49518] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49518 --- Comment #3 from Jakub Jelinek 2011-06-24 09:21:53 UTC --- nelements is here 16, while vf is just 2 (as the loop also operates on ints). mis is 2 (one iteration has been peeled already before vectorization). So, npeel_tmp is 14 and as cost model is used, the loop with the assertion that npeel_tmp <= vf iterates at least once. Richard, can you please look at this? Perhaps we want to and with smaller of vf and nelements & (nelements - 1) & (vf - 1)?
[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484 --- Comment #2 from cobexer at gmail dot com 2011-06-24 09:33:42 UTC --- I could not reproduce the crash using gcc 4.6. So I reported this to Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=716390
[Bug c++/49520] New: [C++0x] using-declaration and operator&& confuses constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49520
Summary: [C++0x] using-declaration and operator&& confuses
constexpr
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
namespace x { void foo(); }
template
struct traits
{
static constexpr bool f() { return true; }
static constexpr bool g()
{
using x::foo;
return f() && noexcept(foo());
}
};
template struct traits;
constexpr.cc: In static member function 'static constexpr bool traits::g()
[with T = int]':
constexpr.cc:15:17: required from here
constexpr.cc:12:5: error: body of constexpr function 'static constexpr bool
traits::g() [with T = int]' not a return-statement
(I'm trying to use something of this form to make vector's move-assignment
operator noexcept when using std::allocator, an important QoI issue. 'f' is
propagate_on_container_move_assignment and 'x::foo' is 'std::swap' which needs
to be called unqualified.)
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 --- Comment #8 from Mikael Pettersson 2011-06-24 09:59:58 UTC --- I've now bootstrapped and regtested the patch in #c5 on top of gcc-4.6-20110610 on an armv5tel-linux-gnueabi machine. (I couldn't get it to apply to trunk.) There were no build problems, it solved the test case, but there were a few testsuite regressions: +FAIL: gcc.dg/vect/nodump-pr23073.c (internal compiler error) +FAIL: gcc.dg/vect/nodump-pr23073.c (test for excess errors) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c: In function 'C': /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:19:1: error: unrecognizable insn: (insn 7 6 8 3 (set (mem/s/c:BLK (reg/f:SI 134) [3 d+0 S16 A32]) (unspec:V2SI [ (reg:V2SI 135) ] 205)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:16 -1 (nil)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:19:1: internal compiler error: in extract_insn, at recog.c:2109 +FAIL: gcc.dg/vect/vect-34.c (internal compiler error) +FAIL: gcc.dg/vect/vect-34.c (test for excess errors) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c: In function 'main1': /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:31:1: error: unrecognizable insn: (insn 41 40 42 3 (set (mem/s/c:BLK (reg/f:SI 173) [3 s+0 S16 A32]) (unspec:V8QI [ (reg:V8QI 175) ] 205)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:20 -1 (nil)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:31:1: internal compiler error: in extract_insn, at recog.c:2109 +FAIL: gcc.dg/vect/bb-slp-10.c (internal compiler error) +FAIL: gcc.dg/vect/bb-slp-10.c (test for excess errors) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c: In function 'main1': /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:41:1: error: unrecognizable insn: (insn 24 23 25 3 (set (mem/s/c:BLK (reg/f:SI 168) [2 out+0 S64 A64]) (unspec:V2SI [ (reg:V2SI 174) ] 205)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:28 -1 (nil)) /mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:41:1: internal compiler error: in extract_insn, at recog.c:2109 +FAIL: gcc.target/arm/frame-pointer-1.c execution test The runtime test in foo() fails because p4 is 0xdeadbeef rather than 4.
[Bug target/49515] [4.7 Regression] gcc.dg/torture/tls/thr-init-2.c -O2 -fpic execution test failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49515 --- Comment #4 from Uros Bizjak 2011-06-24 10:01:28 UTC --- (In reply to comment #1) > The code difference you show cannot be the real problem. The register > allocator has made a poorer choice in 4.7, leading to an extra move, > but the code that you show is exactly equivalent. The move is actually a sign extension instruction, so 4.7 code looks more correct to me.
[Bug c++/49520] [C++0x] using-declaration and operator&& confuses constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49520
--- Comment #1 from Jonathan Wakely 2011-06-24
10:22:03 UTC ---
It works fine if:
* the return statement is just a noexcept-expression
* the using-declaration is moved to namespace-scope
* the using-declaration is removed and the call is qualified as 'x::foo()'
or several other variations.
I can use this workaround, but IIUC it shouldn't be necessary:
namespace x { void foo(); }
template
struct traits
{
static constexpr bool f() { return true; }
static constexpr bool g()
{
using x::foo;
return noexcept(foo());
}
static constexpr bool h()
{ return f() && g(); }
};
template struct traits;
[Bug c++/46400] g++ Segmentation Fault on heavily templated project.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46400 --- Comment #9 from Jakub Jelinek 2011-06-24 10:24:36 UTC --- Created attachment 24590 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24590 gcc47-pr46400.patch This seems to fix it for me, otherwise untested. TREE_CHAIN for types, if I understand it right, is either NULL, or contains TYPE_DECL, so IMHO it doesn't make much sense to consider it as chain_next. Even if the TYPE_DECL has a long TYPE_CHAIN itself, that long chain would be handled when handling the TYPE_DECL, so would result in at most one extra frame. But TYPE_NEXT_VARIANT is potentially long chain.
[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49507 --- Comment #6 from Philipp 2011-06-24 10:26:06 UTC --- Applying the changes on top of gcc-4.6.1 rc1 fixes the problem for me. Thanks!
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836
--- Comment #15 from th.r.klein at web dot de 2011-06-24 11:10:27 UTC ---
The commit helps suppress building of target-libiberty.
But there is still a try to build target-zlib.
Isn't it possible to add a manual switch to prevent building of such target
libraries by adding them to
'noconfigdirs' with eg. --disable-target-zlib?
For a possible implementation see
(http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00374.html)
or below.
Index: configure.ac
===
--- configure.ac(revision 175346)
+++ configure.ac(working copy)
@@ -1880,6 +1880,28 @@ case ,${enable_languages},:${enable_objc_gc} in
;;
esac
+# a user defined "--disable-target-.." was given
+# add this to the ingnore list if not already present
+for target_lib_var in $target_libraries
+do
+ var=`$as_echo "$target_lib_var" | sed 's/[[-+.]]/_/g'`
+ eval is_enabled=\$enable_$var
+ if test x$is_enabled = xno ; then
+append_var=yes
+for var in $noconfigdirs $skipdirs
+do
+ if test x$var = x$target_lib_var ; then
+append_var=no
+break
+ fi
+done
+if test x$append_var = xyes ; then
+ noconfigdirs="$noconfigdirs $target_lib_var"
+ echo "add $target_lib_var to noconfigdirs"
+fi
+ fi
+done
+
# Remove the entries in $skipdirs and $noconfigdirs from $configdirs,
# $build_configdirs and $target_configdirs.
# If we have the source for $noconfigdirs entries, add them to $notsupp.
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #8 from Michael K. Edwards 2011-06-24 11:28:53 UTC --- So I think we agree that the CLREX is needless, but the DMB should move after the branch target. Does that make this bug "confirmed"? (I don't feel the need for patch credit. :-)
[Bug tree-optimization/49518] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49518 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2011-06-24 12:04:32 UTC --- I'll have a look.
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek 2011-06-24 12:54:39 UTC --- This is a bug in lto-streamer-out.c. TYPE_MAXVAL of the ARRAY_TYPE's TYPE_DOMAIN e.g. in f1 is a VAR_DECL (DECL_NAME is NULL, DECL_ARTIFICIAL, but !DECL_IGNORED_P). It is first encountered in a GIMPLE_DEBUG's first operand, it hasn't been seen yet, so that VAR_DECL is output. But, later on write_global_stream calls lto_output_tree on the VLA ARRAY_TYPE, with ref_p set to false, and this eventually calls lto_output_tree on that VAR_DECL again. But this doesn't find it in ob->writer_cache, because the cache has been destroyed in between, from output_function -> destroy_output_block -> lto_streamer_cache_delete. I guess VLA types need to be emitted immediately in the containing function, rather than being deferred to be written much later on globally.
[Bug target/49335] [4.6/4.7 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335
--- Comment #5 from Ramana Radhakrishnan 2011-06-24
13:15:13 UTC ---
Author: ramana
Date: Fri Jun 24 13:15:08 2011
New Revision: 175375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175375
Log:
Fix PR target/49335
2011-06-24 Ramana Radhakrishnan
PR target/49335
* config/arm/predicates.md (add_operator): New.
* config/arm/arm.md ("*arith_shiftsi"): Fix for SP reg usage
in Thumb2.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/predicates.md
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #67 from Ian Lance Taylor 2011-06-24 13:21:28 UTC --- We don't need __FRAME_END__ if we use --eh-frame-hdr. We don't need __JCR_END__ if we rename the .jcr section to jcr and use __stop_jcr. These will only work with GNU ld or gold, but that is the only case the .ctors/.dtors code will work anyhow.
[Bug tree-optimization/49516] SRA generates memory references into its replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49516 --- Comment #3 from Martin Jambor 2011-06-24 13:27:47 UTC --- Author: jamborm Date: Fri Jun 24 13:27:44 2011 New Revision: 175376 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175376 Log: 2011-06-24 Martin Jambor PR tree-optimizations/49516 * tree-sra.c (sra_modify_assign): Choose the safe path for aggregate copies if we also did scalar replacements. * testsuite/g++.dg/tree-ssa/pr49516.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr49516.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #68 from Jakub Jelinek 2011-06-24 13:33:32 UTC --- You need crtend*.o to zero terminate .eh_frame section.
[Bug tree-optimization/49516] SRA generates memory references into its replacements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49516 --- Comment #4 from Martin Jambor 2011-06-24 13:36:22 UTC --- Fixed on trunk, will commit to 4.6 after it is unfrozen.
[Bug target/49521] New: [arm] Bad PIC register load in for static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521
Summary: [arm] Bad PIC register load in for static initializers
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
Host: x86_64-linux-gnu
Target: arm-unknown-linux-gnu
Build: x86_64-linux-gnu
$ ./xgcc -v
../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnu
--with-headers=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.6.1 20110518 (prerelease) [gcc-4_6-branch revision 173875] (GCC)
Yes, this only happens with the old ABI but this wrong-code seems to happens
very frequently.
$ ./xgcc -B. -fpic -O2 ~/t.ii -S
_GLOBAL__sub_I_t.ii:
@ args = 0, pretend = 0, frame = 116
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {fp, lr}
ldr r1, .L1064 <- load GOT offset
add fp, sp, #4
sub sp, sp, #116
mov r0, #0
ldr r1, [r0, r1] <- crash
.L1064:
.word __gxx_personality_sj0(GOT)
(note 2 354 264 NOTE_INSN_FUNCTION_BEG)
(insn 264 2 287 (set (reg:SI 2 r2)
(const_int 0 [0])) 168 {*arm_movsi_insn}
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(insn 287 264 288 (set (reg:SI 3 r3 [275])
(unspec:SI [
(mem:SI (label_ref 364) [0 S4 A32])
] 3)) 170 {pic_load_addr_32bit}
(expr_list:REG_EQUIV (unspec:SI [
(symbol_ref:SI ("__gxx_personality_sj0") [flags 0x41])
] 3)
(nil)))
(insn 288 287 229 (set (reg/f:SI 3 r3 [256])
(mem:SI (plus:SI (reg:SI 2 r2)
(reg:SI 3 r3 [275])) [0 S4 A32])) 168 {*arm_movsi_insn}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_EQUIV (symbol_ref:SI ("__gxx_personality_sj0") [flags
0x41])
(nil
(insn 229 288 230 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -32 [0xffe0])) [0 S4 A32])
(reg/f:SI 3 r3 [256])) 168 {*arm_movsi_insn}
(expr_list:REG_DEAD (reg/f:SI 3 r3 [256])
(nil)))
If I explicitly specify a PIC register (e.g. -mpic-register=4), the load is
sane.
e.g.
_GLOBAL__sub_I_t.ii:
@ args = 0, pretend = 0, frame = 112
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {r4, fp, lr}
ldr r4, .L1064
add fp, sp, #8
ldr r2, .L1064+4
sub sp, sp, #112
ldr r1, .L1064+8
ldr r0, .L1064+12
.LPIC227:
add r4, pc, r4
ldr r3, .L1064+16
ldr r1, [r4, r1]
.L1064:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC227+8)
.word .LLSDA1449-(.LPIC224+8)
.word __gxx_personality_sj0(GOT)
[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 --- Comment #5 from hjl at gcc dot gnu.org 2011-06-24 13:41:44 UTC --- Author: hjl Date: Fri Jun 24 13:41:40 2011 New Revision: 175377 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175377 Log: Properly handle pointer addition/subtraction. 2011-06-24 H.J. Lu PR rtl-optimization/49504 * rtlanal.c (nonzero_bits1): Properly handle addition or subtraction a pointer in Pmode if pointers extend unsigned. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug target/49521] [arm] Bad PIC register load in for static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan 2011-06-24 13:47:42 UTC --- Missing a testcase for someone to take a look. Ramana
[Bug target/49521] [arm] Bad PIC register load in for static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.24 13:48:02 Ever Confirmed|0 |1
[Bug target/49521] [arm] Bad PIC register load in for static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521 --- Comment #2 from Ryan Mansfield 2011-06-24 13:50:48 UTC --- Created attachment 24591 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24591 preprocessed source
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 Ramana Radhakrishnan changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.24 13:55:55 CC||ramana at gcc dot gnu.org Version|4.5.2 |4.6.0 Ever Confirmed|0 |1 --- Comment #9 from Ramana Radhakrishnan 2011-06-24 13:55:55 UTC --- It is confirmed - though it's valid only for 4.6.0 onwards in the FSF tools. 4.5.x FSF doesn't have inline sync primitives. cheers Ramana
[Bug target/49521] [arm] Bad PIC register load in for static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521 Ramana Radhakrishnan changed: What|Removed |Added Status|WAITING |NEW
[Bug target/49521] [arm] Bad PIC register load in static initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521 Ryan Mansfield changed: What|Removed |Added Keywords||wrong-code Summary|[arm] Bad PIC register load |[arm] Bad PIC register load |in for static initializers |in static initializers --- Comment #3 from Ryan Mansfield 2011-06-24 14:26:49 UTC --- Add keyword.
[Bug tree-optimization/39839] [4.3/4.4/4.5/4.6/4.7 regression] loop invariant motion causes stack spill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #16 from Steven Bosscher 2011-06-24 14:57:12 UTC --- So this is fixed??
[Bug inline-asm/49142] Invalid 8bit register operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49142 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from H.J. Lu 2011-06-24 15:39:25 UTC --- Fixed.
[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from H.J. Lu 2011-06-24 15:40:08 UTC --- Fixed.
[Bug target/49437] interrupt return pop sometimes corrupts sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49437 Ramana Radhakrishnan changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.24 16:18:22 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Ramana Radhakrishnan 2011-06-24 16:18:22 UTC --- Confirmed - trunk generates this code as well. It has to do with the handling of IS_STACKALIGN in arm_output_epilogue when it optimizes for size. Ramana
[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 --- Comment #2 from H.J. Lu 2011-06-24 16:37:20 UTC --- step-14.cc is miscompiled: #0 SparsityPattern::operator() (this=0xcef8, i=0, j=0) at sparsity_pattern.cc:608 #1 0x08223fc1 in add (value=0.075579727185634243, j=, i=, this=0xc76a) at include/lac/sparse_matrix.h:1709 #2 LaplaceSolver::Solver<3>::assemble_matrix (this=0x83845c8, linear_system=..., begin_cell=..., end_cell=..., mutex=...) at step-14.cc:796 #3 0x0822750e in operator() (arg4=..., arg3=..., arg2=..., arg1=..., this=0xc738) at include/base/thread_management.h:5382 #4 LaplaceSolver::Solver<3>::assemble_linear_system (this=0x83845c8, linear_system=...) at step-14.cc:716 #5 0x0822a0c2 in LaplaceSolver::Solver<3>::solve_problem (this=0x83845c8) at step-14.cc:676 #6 0x082270cd in do_call::*)(), LaplaceSolver::WeightedResidual<3>, boost::tuples::tuple<> > (obj=..., fun_ptr=) at include/fe/fe_q.h:239
[Bug middle-end/49522] New: Divide by zero in validate_subreg in emit-rtl.c:695
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49522 Summary: Divide by zero in validate_subreg in emit-rtl.c:695 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-linux-gnu Target: arm-unknown-linux-gnueabi Build: x86_64-linux-gnu Created attachment 24592 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24592 preprocessed source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnueabi Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-multilib --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared --disable-libmudflap --disable-libssp Thread model: posix gcc version 4.7.0 20110624 (experimental) [trunk revision 175378] (GCC) $ ./xgcc -B. ~/ice.i -c -O3 -g /home/ryan/ice.i: In function 'func4': /home/ryan/ice.i:38:1: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Doesn't crash without -g Program received signal SIGFPE, Arithmetic exception. validate_subreg (omode=VOIDmode, imode=SImode, reg=0x76e33a70, offset=0) at ../../gcc/emit-rtl.c:695 695 if (offset % osize != 0) (gdb) bt #0 validate_subreg (omode=VOIDmode, imode=SImode, reg=0x76e33a70, offset=0) at ../../gcc/emit-rtl.c:695 #1 0x00616849 in gen_rtx_SUBREG (mode=VOIDmode, reg=0x76e33a70, offset=0) at ../../gcc/emit-rtl.c:775 #2 0x005c82b8 in dead_debug_insert_before ( all_blocks=) at ../../gcc/df-problems.c:3197 #3 df_note_bb_compute (all_blocks=) at ../../gcc/df-problems.c:3399 #4 df_note_compute (all_blocks=) at ../../gcc/df-problems.c:3452 #5 0x005c14c9 in df_analyze_problem (dflow=0x144d220, blocks_to_consider=0x141de88, postorder=0x13fbb50, n_blocks=3) at ../../gcc/df-core.c:1152 #6 0x005c1729 in df_analyze () at ../../gcc/df-core.c:1249 #7 0x00c50dcb in sched_init () at ../../gcc/haifa-sched.c:3487 #8 0x00c575cb in haifa_sched_init () at ../../gcc/haifa-sched.c:3526 #9 0x008211f5 in schedule_insns () at ../../gcc/sched-rgn.c:3302 #10 0x008217dd in rest_of_handle_sched2 () at ../../gcc/sched-rgn.c:3532 #11 0x007c5b30 in execute_one_pass (pass=0x1252d20) at ../../gcc/passes.c:2059 ---Type to continue, or q to quit--- #12 0x007c5e55 in execute_pass_list (pass=0x1252d20) at ../../gcc/passes.c:2114 #13 0x007c5e67 in execute_pass_list (pass=0x1252300) at ../../gcc/passes.c:2115 #14 0x007c5e67 in execute_pass_list (pass=0x12522a0) at ../../gcc/passes.c:2115 #15 0x008cd728 in tree_rest_of_compilation (fndecl=0x77fa5100) at ../../gcc/tree-optimize.c:416 #16 0x005a6546 in cgraph_expand_function (node=0x77f96480) at ../../gcc/cgraphunit.c:1792 #17 0x005a82ea in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1851 #18 cgraph_optimize () at ../../gcc/cgraphunit.c:2121 #19 0x005a897a in cgraph_finalize_compilation_unit () at ../../gcc/cgraphunit.c:1292 #20 0x0049b4d8 in c_write_global_declarations () at ../../gcc/c-decl.c:9844 #21 0x0086ad66 in compile_file (argc=15, argv=0x7fffe0b8) at ../../gcc/toplev.c:571 #22 do_compile (argc=15, argv=0x7fffe0b8) at ../../gcc/toplev.c:1908 #23 toplev_main (argc=15, argv=0x7fffe0b8) at ../../gcc/toplev.c:1980 ---Type to continue, or q to quit--- #24 0x7718deff in __libc_start_main (main=0x52de00 , argc=15, ubp_av=0x7fffe0b8, init=, fini=, rtld_fini=, stack_end=0x7fffe0a8) at libc-start.c:226 #25 0x0047f669 in _start ()
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 --- Comment #5 from eraman at gcc dot gnu.org 2011-06-24 17:10:23 UTC --- Author: eraman Date: Fri Jun 24 17:10:18 2011 New Revision: 175384 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175384 Log: 2011-06-24 Easwaran Raman PR rtl-optimization/49429 PR target/49454 * expr.c (emit_block_move_hints): Mark MEM_EXPR(x) and MEM_EXPR(y) addressable if emit_block_move_via_libcall is used to copy y into x. * calls.c (initialize_argument_information): Mark an argument addressable if it is passed by invisible reference. (emit_library_call_value_1): Mark MEM_EXPR (val) addressable if it is passed by reference. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/expr.c
[Bug tree-optimization/39839] [4.3/4.4/4.5/4.6 regression] loop invariant motion causes stack spill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839 Richard Guenther changed: What|Removed |Added Known to work||4.7.0 Summary|[4.3/4.4/4.5/4.6/4.7|[4.3/4.4/4.5/4.6 |regression] loop invariant |regression] loop invariant |motion causes stack spill |motion causes stack spill --- Comment #17 from Richard Guenther 2011-06-24 17:11:01 UTC --- At least for 4.7 it seems.
[Bug rtl-optimization/49429] [4.7 Regression] dse.c change (r175063) causes execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #16 from eraman at gcc dot gnu.org 2011-06-24 17:10:23 UTC --- Author: eraman Date: Fri Jun 24 17:10:18 2011 New Revision: 175384 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175384 Log: 2011-06-24 Easwaran Raman PR rtl-optimization/49429 PR target/49454 * expr.c (emit_block_move_hints): Mark MEM_EXPR(x) and MEM_EXPR(y) addressable if emit_block_move_via_libcall is used to copy y into x. * calls.c (initialize_argument_information): Mark an argument addressable if it is passed by invisible reference. (emit_library_call_value_1): Mark MEM_EXPR (val) addressable if it is passed by reference. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/expr.c
[Bug fortran/49523] New: uninitialized warning present when compiled with O1 but not with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49523 Summary: uninitialized warning present when compiled with O1 but not with O0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pascal...@parois.net Created attachment 24593 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24593 file showing the issue There are many other similar bugs so it might be related to an existing one. Sorry about that. I have a different behaviour depending of level optimisation. A warning is issued using O1, O2, O3, Os but not with O0. Compilation with -O1 gives a warning gfortran -O1 -xf95-cpp-input -Wuninitialized -c modules/matfile.f90 -o modules/matfile.o modules/matfile.f90: In function ‘solveconstraintmatrix’: modules/matfile.f90:76:0: attention : ‘constraintsv.offset’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:76:0: attention : ‘constraintsv.dim[1].stride’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:341:0: attention : ‘constraintsv.dim[0].ubound’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:76:0: attention : ‘constraints.offset’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:405:0: attention : ‘constraints.dim[1].stride’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:405:0: attention : ‘constraints.dim[1].ubound’ may be used uninitialized in this function [-Wuninitialized] modules/matfile.f90:360:0: attention : ‘constraints.dim[0].ubound’ may be used uninitialized in this function [-Wuninitialized] whereas no warning with O0 gfortran -O0 -xf95-cpp-input -Wuninitialized -c modules/matfile.f90 -o modules/matfile.o gcc -v Utilisation des specs internes. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configuré avec: /build/src/gcc-4.6-20110603/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --disable-multilib --disable-libstdcxx-pch --enable-checking=release Modèle de thread: posix gcc version 4.6.0 20110603 (prerelease) (GCC) The source code is attached, however it is not minimal.
[Bug c++/49507] [4.6/4.7 Regression] ICE because of defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49507 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek 2011-06-24 19:55:26 UTC --- Fixed.
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC||gjl at gcc dot gnu.org
--- Comment #4 from Georg-Johann Lay 2011-06-24
20:11:20 UTC ---
I see this on 4.5.2
In 185r.asmcons we have insn 40:
(insn 40 38 41 4 foo.c:6 (parallel [
(set (reg:HI 94)
(rotate:HI (reg/v:HI 66 [ _x ])
(const_int 8 [0x8])))
(clobber (reg:QI 95))
]) 64 {*rotbhi} (expr_list:REG_DEAD (reg/v:HI 66 [ _x ])
(expr_list:REG_UNUSED (reg:QI 95)
(nil
and in 188r.ira it is:
(insn 40 38 41 4 foo.c:6 (parallel [
(set (reg:HI 20 r20 [94])
(rotate:HI (reg/v:HI 20 r20 [orig:66 _x ] [66])
(const_int 8 [0x8])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [3 %sfp+1 S1 A8]))
]) 64 {*rotbhi} (nil))
At first sight I thought it is a reload bug, but it's not.
The bug goes like that:
operand3 gets constraint verbatim from rotx iterator, witch reads for HI
(HI "X,X,X")
That was correct if reload would supply a scratch. However, these rot patterns
don't request a scratch, the respective expander already supplies a pseudo.
So the "X" does not mean "don't need a scratch", instead it means "everything
is fine" so that reload need not generate reload insns to force "r" or whatever
constraint.
So either the constrint must be "=&r" or so if a pseudo is pre-generated (this
is waste because the reg is not needed and can even force a frame/frame
pointer) or this has to be rewritten as a proper scratch.
[Bug target/46426] [avr] avr/libgcc.S in SVN r166596 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46426 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Georg-Johann Lay 2011-06-24 20:42:13 UTC --- (In reply to comment #1) > Same here. > But even if I apply this patch, gcc segfaults for any given source. Your issue appears rather to be PR48459 *** This bug has been marked as a duplicate of bug 47534 ***
[Bug bootstrap/47534] [regression] avr libgcc.S fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47534 Georg-Johann Lay changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #3 from Georg-Johann Lay 2011-06-24 20:42:13 UTC --- *** Bug 46426 has been marked as a duplicate of this bug. ***
[Bug ada/49524] New: container loop error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49524
Summary: container loop error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rein...@gmail.com
Created attachment 24594
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24594
Demo program which does not compile.
The loop below does not compile:
for Elem of field(1).NeighbourR loop
Put(" ** Here ** "); New_Line;
end loop;
Attached is a demo program.
Command to try to compile:
nn@linux-de43:~/sensor_nettverk1/diffusion2> gnatmake -gnat2012 report1.adb
gcc -c -gnat2012 report1.adb
+===GNAT BUG DETECTED==+
| 4.6.0 20110505 [gcc-4_6-branch revision 173419] (x86_64-suse-linux-gnu) |
| Assert_Failure sinfo.adb:1072|
| Error detected at report1.adb:37:40 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
[Bug c++/46400] g++ Segmentation Fault on heavily templated project.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46400 --- Comment #10 from Jakub Jelinek 2011-06-24 21:11:19 UTC --- Author: jakub Date: Fri Jun 24 21:11:16 2011 New Revision: 175389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175389 Log: PR c++/46400 * cp-tree.h (union lang_tree_node): Use TYPE_NEXT_VARIANT instead of TYPE_CHAIN for chain_next for types. * c-decl.c (union lang_tree_node): Use TYPE_NEXT_VARIANT instead of TYPE_CHAIN for chain_next for types. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h
[Bug c++/46400] g++ Segmentation Fault on heavily templated project.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46400 --- Comment #11 from Paolo Carlini 2011-06-24 21:29:33 UTC --- Thanks Jakub.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 Janis Johnson changed: What|Removed |Added CC||janis at gcc dot gnu.org --- Comment #5 from Janis Johnson 2011-06-24 22:00:07 UTC --- Starting with r175063, arm-none-linux-gnueabi using default configuration for arch/cpu/fpu/float-abi gets these failures: FAIL: gcc.c-torture/execute/920501-7.c execution, -Os FAIL: gcc.c-torture/execute/comp-goto-2.c execution, -Os FAIL: gcc.dg/torture/stackalign/comp-goto-1.c -Os execution test FAIL: gcc.dg/torture/stackalign/non-local-goto-4.c -Os execution test The failures are only for -Os, not for other optimization levels that Ramana sees for his configuration. Let me know if this needs a separate PR.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #6 from Easwaran Raman 2011-06-24 22:19:40 UTC --- Could you please test if r175384 fixes these failures? Otherwise please run one of the smaller tests with -fdump-rtl-dse1-all and -fdump-rtl-cse2 (the pass before DSE) and upload those dumps and I will take a look.
[Bug c++/49525] New: [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 Summary: [4.4] wrong code and wrong warning for bitfield related operations Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: marcin.slus...@gmail.com Created attachment 24595 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24595 testcase Compilation of attached file generates wrong warning: $ g++-4.4.5 -c -O2 -Wall all.c all.c: In function ‘void test(const st_src_reg*, ureg_dst)’: all.c:118: warning: ‘reg’ is used uninitialized in this function all.c:118: note: ‘reg’ was declared here And produces wrong code - at random after "test" function, src[i].Negate (one bit unsigned bit-field) becomes 1 when src_reg[i]->negate == 0 - something which should not happen. The bug does not manifest when compiled with gcc instead of g++ or with g++ 4.3.5 or 4.5.2.
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 --- Comment #1 from Marcin Ślusarz 2011-06-24 22:20:24 UTC --- Created attachment 24596 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24596 g++ -v -save-temps -O2 -Wall -c all.c
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 --- Comment #2 from Marcin Ślusarz 2011-06-24 22:23:56 UTC --- Created attachment 24597 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24597 standalone app testing this bug I'm attaching sources of standalone app which tests this bug. It should print: 0 0 0 0 Sometimes it prints: 1 1 1 1 a.out: main.c:14: void check_output(ureg_src*): Assertion `sum == 0' failed.
[Bug fortran/49523] uninitialized warning present when compiled with O1 but not with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49523 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Steven Bosscher 2011-06-24 22:28:31 UTC --- From http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Warning-Options.html#index-Wuninitialized-326 "Because these warnings depend on optimization, the exact variables or elements for which there are warnings will depend on the precise optimization options and version of GCC used."
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 --- Comment #3 from Marcin Ślusarz 2011-06-24 22:37:44 UTC --- Created attachment 24598 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24598 all.ii
[Bug c++/49525] [4.4] wrong code and wrong warning for bitfield related operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49525 --- Comment #4 from Marcin Ślusarz 2011-06-24 22:38:06 UTC --- Created attachment 24599 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24599 all.s
[Bug target/49526] New: ARM missed optimization: SMMUL instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526
Summary: ARM missed optimization: SMMUL instruction
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siarhei.siamas...@gmail.com
$ cat test.c
int smmul(int a, int b) { return ((long long)a * b) >> 32; }
$ arm-none-linux-gnueabi-gcc -O2 -S -mcpu=cortex-a8 test.c
$ cat test.s
.cpu cortex-a8
.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, 2
.eabi_attribute 30, 2
.eabi_attribute 18, 4
.file "test.c"
.text
.align 2
.global smmul
.type smmul, %function
smmul:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
smull r0, r1, r0, r1
mov r0, r1
bx lr
.size smmul, .-smmul
.ident "GCC: (GNU) 4.7.0 20110624 (experimental)"
.section.note.GNU-stack,"",%progbits
[Bug target/49526] ARM missed optimization: SMMUL instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526
--- Comment #1 from Siarhei Siamashka
2011-06-24 22:48:46 UTC ---
And clang 2.9 has no problems optimizing this code:
$ cat test.c
int smmul(int a, int b) { return ((long long)a * b) >> 32; }
$ clang -ccc-host-triple arm-none-linux -O2 -mcpu=cortex-a8 -S test.c
$ cat test.s
.syntax unified
.cpu cortex-a8
.eabi_attribute 6, 10
.eabi_attribute 7, 65
.eabi_attribute 8, 1
.eabi_attribute 9, 2
.fpu neon
.eabi_attribute 10, 3
.eabi_attribute 12, 1
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.file "test.c"
.text
.globl smmul
.align 2
.type smmul,%function
smmul:
smmul r0, r1, r0
bx lr
.Ltmp0:
.size smmul, .Ltmp0-smmul
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #7 from Janis Johnson 2011-06-24 23:01:40 UTC --- Created attachment 24600 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24600 rtl dump for -Os failure
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #9 from Janis Johnson 2011-06-24 23:02:58 UTC --- I still get the -Os failures (I never had the others) with r175389 and have attached the requested rtl dumps.
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #8 from Janis Johnson 2011-06-24 23:02:12 UTC --- Created attachment 24601 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24601 rtl dump for -Os failure
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #10 from Easwaran Raman 2011-06-24 23:07:58 UTC --- (In reply to comment #9) > I still get the -Os failures (I never had the others) with r175389 and have > attached the requested rtl dumps. This doesn't look like a DSE related bug to me. The RTL dump shows that no store has been deleted by DSE in any of the functions.
[Bug c++/49527] New: internal compiler error: in mangle_decl_string, at cp/mangle.c:3099
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49527 Summary: internal compiler error: in mangle_decl_string, at cp/mangle.c:3099 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: plan9assemb...@gmail.com using gcc 4.7.0 to compile PathScale EKOPath 4 Compiler Suite https://github.com/path64/compiler cmake configuration: cmake -DCMAKE_INSTALL_PREFIX=/usr/ -DPATH64_ENABLE_TARGETS=x86_64 -DPATH64_ENABLE_MATHLIBS=ON -DPSC_CRT_PATH_x86_64=/usr/lib64 -DPSC_DYNAMIC_LINKER_x86_64=/lib64/ld-linux-x86-64.so.2 -DPSC_LIBSUPCPP_PATH_x86_64=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/ -DPSC_LIBSTDCPP_PATH_x86_64=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/ -DPSC_LIBGCC_PATH_x86_64=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/ -DPSC_LIBGCC_EH_PATH_x86_64=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/ -DPSC_LIBGCC_S_PATH_x86_64=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/ .. compile: ... [ 18%] Built target be-static-x8664 [ 18%] Building CXX object src/be/cg/CMakeFiles/cg-x8664.dir/x8664/cgtarget.cxx.o In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/ext/hash_map:61:0, from /home/XXX/compiler/src/be/../common/com/strtab.h:136, from /home/XXX/compiler/src/be/../common/com/symtab.h:65, from /home/XXX/compiler/src/be/../common/com/stab.h:29, from /home/XXX/compiler/src/be/com/data_layout.h:54, from /home/XXX/compiler/src/be/cg/x8664/cgtarget.cxx:66: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] In file included from /home/XXX/compiler/src/be/com/opt_alias_mgr.h:71:0, from /home/XXX/compiler/src/be/cg/x8664/cgtarget.cxx:71: /home/XXX/compiler/src/be/com/cxx_template.h:340:52: internal compiler error: in mangle_decl_string, at cp/mangle.c:3099 Please submit a full bug report, with preprocessed source if appropriate. PS: sorry for no detail information.
[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.25 03:09:56 CC|jason at redhat dot com |jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jason Merrill 2011-06-25 03:09:56 UTC --- Compiling step-14.cc with -O -fipa-sra -foptimize-sibling-calls is enough to produce the crash. I think this is likely to be an IPA-SRA bug; the front end change in question is correct. The new code is doing the same transformation that we already do in grokparms.
[Bug c++/35255] [DR 115] gcc does not do partial ordering on overloaded address resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35255 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill 2011-06-25 03:28:48 UTC --- Fixed for 4.7.0.
[Bug c++/49528] New: g++ fails to destroy temporary object when subobject is used to initialize a reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49528
Summary: g++ fails to destroy temporary object when subobject
is used to initialize a reference
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
I believe that r should point to a temporary int and the A temporary destroyed
at the end of the declaration statement rather than have its lifetime extended
to the end of the block. In any case, never destroying it is clearly broken.
int d;
struct A
{
int i;
~A() { ++d; };
};
int main()
{
{ const int &r = A().i; }
if (d != 1)
return 1;
}
[Bug c++/49528] g++ fails to destroy temporary object when subobject is used to initialize a reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49528 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.25 03:33:06 Ever Confirmed|0 |1
[Bug c++/49528] [4.6/4.7 regression] g++ fails to destroy temporary object when subobject is used to initialize a reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49528 Jason Merrill changed: What|Removed |Added Summary|g++ fails to destroy|[4.6/4.7 regression] g++ |temporary object when |fails to destroy temporary |subobject is used to|object when subobject is |initialize a reference |used to initialize a ||reference --- Comment #1 from Jason Merrill 2011-06-25 03:34:55 UTC --- Hmm, looks like this worked in 4.5.
[BUG, 4.5.2] __attribute__((malloc)) leading to erroneous dead code elimination?
Hi, I'm not sure if this is a bug or I am just misunderstanding the attribute. First of all I noticed this behaviour on the following gcc version, but not earlier gcc (probably 4.2, I can't remember exactly): Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --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.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) My problem is that I have a library function which implements a memory allocator: 1. void *foo_alloc(size_t) __attribute__((malloc)); And a caller which does: 2. int *foo; 3. foo = foo_alloc(sizeof(int)); 4. *foo = bar; Then later on I have some code which walks the list of objects created by foo_alloc() and I find that they are uninitialised. Specifically line 4 of my example has been eliminated. >From the docs: The `malloc' attribute is used to tell the compiler that a function may be treated as if any non-`NULL' pointer it returns cannot alias any other pointer valid when the function returns. So AIUI, the optimiser has made a mistake, since "no alias *at the time* of function return" does not mean "no other alias EVER". I can produce a minimal example program if required. Thanks Gianni
