[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #27 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 08:09:59 UTC --- Compilation finished after ~3 hours and consuming at least 3GB (from top - I forgot to use memmax2...). Winners in the geez, I'm slow for this test case list: PRE: 6241.75 (57%) usr tree loop invariant motion : 4194.83 (38%) usr TOTAL : 11021.46 Time is mostly spent in the alias oracle. For LIM I'm going to test using triangle instead of square dep/indep matrix, as a first step. Richi, PRE is yours so... ;-)
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07 08:14:17 UTC --- I don't like the patch too much. Why are you removing the cfun-optabs stuff? set_cfun is called pretty often, e.g. during IPA switching to various functions and back, when you remove cfun-optabs, it will constantly need to recompute the optabs (quite expensive operation) if switching between mips16 vs. non-mips16 functions with different optimization attributes. The base_optabs stuff is fine, but I'd just remove the ggc_free and in invoke_set_current_function_hook restore the saving of the computed optabs into cfun-optabs and using it if already set.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2013-03-07 08:33:10 UTC --- On Wed, 6 Mar 2013, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-06 15:06:41 UTC --- Created attachment 29598 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29598 assign.c With -O3 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math the different in *.optimized dump from r196262 to r196263 is just: @@ -176,7 +176,6 @@ Assignment (long int[101] * x) short int[101][101] * pretmp_418; long int _429; long int _431; - unsigned long _432; long unsigned int patt_438; unsigned int _440; long unsigned int patt_441; @@ -293,8 +292,7 @@ Assignment (long int[101] * x) _108 = _130 3; _89 = -_108; _72 = (short unsigned int) _89; - _432 = _89 1; - prolog_loop_niters.59_193 = (short unsigned int) _432; + prolog_loop_niters.59_193 = _72 1; if (prolog_loop_niters.59_193 == 0) goto bb 19; else @@ -307,7 +305,7 @@ Assignment (long int[101] * x) bb 19: # j_288 = PHI 1(18), 0(17) # c_287 = PHI c_141(18), 9223372036854775807(17) - prolog_loop_adjusted_niters.60_357 = _89 1; + prolog_loop_adjusted_niters.60_357 = (sizetype) prolog_loop_niters.59_193; niters.61_359 = 101 - prolog_loop_niters.59_193; base_off.68_53 = prolog_loop_adjusted_niters.60_357 * 8; vect_p.69_48 = pretmp_386 + base_off.68_53; From the bugreport, it isn't clear if you were measuring -m32 or -m64 performance, but I guess the *.optimized dump change could just increase register pressure and pessimize the loop RA or something. Yeah, I don't see anything wrong with the change otherwise. Note that forwprop's tree combiner doesn't seem to restrict itself to single-use defs in all cases.
[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #21 from rguenther at suse dot de rguenther at suse dot de 2013-03-07 08:36:43 UTC --- On Wed, 6 Mar 2013, aldyh at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #20 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-03-06 16:28:12 UTC --- Oh, no worries Ian. I totally agree. I just wanted to put all this out there, since I'm unfortunately about to drop it. We should probably close this as a WONTFIX, or perhaps just drop this in priority. A false positive is not the end of the world, so I don't see how this merits a P2 for the release. Thoughts? I'd say we just give up here due to the fact that propagation in SSA / CFG cycles is imprecise and that it is thus not possible to avoid either false positives or false negatives. A P2 regression isn't so bad, we have tons of those.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #28 from rguenther at suse dot de rguenther at suse dot de 2013-03-07 08:44:28 UTC --- On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #24 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 23:39:27 UTC --- (In reply to comment #22) 4.8.0 -O2 (terminated after 9 minutes waiting, LIM being the offender, I suspect domwalk ...) 2.5GB applying domwalk fix ... It is LIM, for sure. I've been watching in GDB for a while at some back traces, and it's spent minutes already in this DOM walk: #5 0x00b841e1 in walk_dominator_tree (walk_data=0x7fffdd60, bb=0x7fffef033958) at ../../trunk/gcc/domwalk.c:187 #6 0x00c02d73 in determine_invariantness () at ../../trunk/gcc/tree-ssa-loop-im.c:1189 #7 tree_ssa_lim () at ../../trunk/gcc/tree-ssa-loop-im.c:2632 #8 0x0075bcd7 in execute_one_pass (pass=0x12323e0 pass_lim) at ../../trunk/gcc/passes.c:2330 #9 0x0075c0f5 in execute_pass_list (pass=0x12323e0 pass_lim) at ../../trunk/gcc/passes.c:2378 This is supposed to be cheap. Is this a known bottle-neck? Pathetic... Yes, it's known - and there are several known (to me ...) ways to make constant factor compile-time and memory-usage improvements... (I _think_ we have a bug for LIMs slowness, if you can't find it quickly you can create one and assign me - I have some TLC patches locally queued for 4.9, but they don't help the slowness very much)
[Bug c++/56558] Address of operator with template base class member (C++ source compile error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56558 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-07 08:47:18 UTC --- Indeed. *** This bug has been marked as a duplicate of bug 48593 ***
[Bug c++/48593] Wrong return type when applying address operator to inherited, template dependend member, using a typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48593 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||thierry.moreau at connotech ||dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-07 08:47:18 UTC --- *** Bug 56558 has been marked as a duplicate of this bug. ***
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de
2013-03-07 08:47:35 UTC ---
On Thu, 7 Mar 2013, steven at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #25 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07
00:08:26 UTC ---
(In reply to comment #24)
(In reply to comment #22)
4.8.0 -O2 (terminated after 9 minutes waiting, LIM being the offender, I
suspect domwalk ...) 2.5GB
applying domwalk fix ...
It is LIM, for sure. I've been watching in GDB for a while at some
back traces, and it's spent minutes already in this DOM walk:
After this, it's spending even more time in refs_independent_p, doing
bitmap tests (ah! a test case for my splay tree bitmaps!).
Is the refs_independent_p relation symmetric? It certainly looks that
way. If so, one way to halve the work done here is to build only half
the independence graph. Currently it builds a full square:
if (mem_refs_may_alias_p (ref1-mem, ref2-mem,
memory_accesses.ttae_cache))
{
bitmap_set_bit (ref1-dep_ref, ref2-id);
bitmap_set_bit (ref2-dep_ref, ref1-id);
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, dependent.\n);
return false;
}
else
{
bitmap_set_bit (ref1-indep_ref, ref2-id);
bitmap_set_bit (ref2-indep_ref, ref1-id);
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, independent.\n);
return true;
}
It's hard to say how much memory is wasted here (obstack_memory_used
is still broken and overflows), but it's probably x*100MB if not more.
Yeah, one of my minor TLC patches. Most of the excessive memory
usage for regular testcases can be fixed by doing LIM on
all siblings of the loop tree independently, instead of keeping
data on all loops in the function live at the same time
(I've not finished _that_ TLC patch - and it won't help for
insanely deep nests, of course)
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #30 from rguenther at suse dot de rguenther at suse dot de 2013-03-07 08:52:52 UTC --- On Thu, 7 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #27 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 08:09:59 UTC --- Compilation finished after ~3 hours and consuming at least 3GB (from top - I forgot to use memmax2...). Winners in the geez, I'm slow for this test case list: PRE: 6241.75 (57%) usr tree loop invariant motion : 4194.83 (38%) usr TOTAL : 11021.46 Time is mostly spent in the alias oracle. For LIM I'm going to test using triangle instead of square dep/indep matrix, as a first step. Richi, PRE is yours so... ;-) Actually PRE is yours - it's the RTL PRE ;) Richard.
[Bug target/56511] memcpy misses chance to use AVX instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56511 --- Comment #4 from Igor Zamyatin izamyatin at gmail dot com 2013-03-07 08:52:53 UTC --- Doesn't first argument of memcpy which is called from memcpy_vec have unknown (1byte) alignment? If yes, how PPC managed to produce vector instructions?
[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Target Milestone|--- |4.8.0 Summary|Link error about|[4.8 Regression] Link error |`std::fstream' or |about `std::fstream' or |`std::stringstream' with|`std::stringstream' with |`-flto' and `-rdynamic' |`-flto' and `-rdynamic' |options |options Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-07 09:07:46 UTC --- Confirmed.
[Bug middle-end/56559] [4.8 Regression] ICE in propagate_op_to_single_use, at tree-ssa-reassoc.c:1057
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56559 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07 09:17:20 UTC --- Created attachment 29608 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29608 gcc48-pr56559.patch In my limited understanding, it is fine to assume the chain has just single uses if you walk through rhs1s, but when looking at rhs2, it can be arbitrary, so we need to guard it. You can't change __builtin_pow that has multiple uses just because of one of the uses. The patch fixes this and doesn't introduce any dg.exp=reassoc* tree-ssa.exp=reassoc* dg-torture.exp=reassoc* regressions.
[Bug target/56560] New: [4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560
Bug #: 56560
Summary: [4.7 regression] vzeroupper clobbers argument with AVX
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org
Target: x86_64-*-*
The vzeroupper optimization pass can go awry on the 4.7 branch and clobbers
arguments passed to functions:
eric@polaris:~ cat t.c
/* { dg-do compile } */
/* { dg-options -O2 -mavx } */
extern void abort (void);
typedef double vec_t __attribute__((vector_size(32)));
struct S { int i1; int i2; int i3; };
extern int bar (vec_t, int, int, int, int, int, struct S);
void foo (vec_t v, struct S s)
{
int i = bar (v, 1, 2, 3, 4, 5, s);
if (i == 0)
abort ();
}
/* { dg-final { scan-assembler-not vzeroupper } } */
eric@polaris:~ ~/install/gcc-4_7-branch/bin/gcc -S -O2 -mavx t.c
eric@polaris:~ cat t.s
.file t.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl$5, %r8d
movl$4, %ecx
movl$3, %edx
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
subq$64, %rsp
movq%rdi, (%rsp)
movl%esi, 8(%rsp)
movl$1, %edi
movl$2, %esi
vzeroupper
callbar
testl %eax, %eax
je .L5
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
.L5:
.cfi_restore_state
.p2align 4,,9
callabort
.cfi_endproc
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #31 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 09:58:03 UTC --- (In reply to comment #30) Hmm, RTL PRE isn't really mine either, but I probably know it as well as anyone else, so I will have a look. It's probably a similar issue as for gimple LIM: alias checks. Can you attach your TLC patches for gimple LIM to this PR, please?
[Bug lto/56495] ICE in lto_output_tree with -g -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56495 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07 10:05:14 UTC --- Thanks for verifying.
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07 10:05:50 UTC --- Confirmed. known-zero-bits and friends should figure this out I think.
[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Known to work||4.5.3 Target Milestone|--- |4.6.4 Summary|[4.7 regression] vzeroupper |[4.6/4.7 regression] |clobbers argument with AVX |vzeroupper clobbers ||argument with AVX Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07 10:09:43 UTC --- Confirmed, same code generated on the 4.6 branch. Works on the 4.5 branch where no vzeroupper is inserted. Likewise no vzeroupper on trunk.
[Bug middle-end/56559] [4.8 Regression] ICE in propagate_op_to_single_use, at tree-ssa-reassoc.c:1057
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56559 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07 10:11:13 UTC --- Honza?
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #32 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 10:13:40 UTC --- (In reply to comment #26) (In reply to comment #23) FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 ) can be compiled with 'clang', albeit slowly: ... Memory consumption is about 186M. How have you measured this? From time to time I was looking at output of 'top'. The compiler pretty quickly reaches the 186M +/- mark and stays at it.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #33 from rguenther at suse dot de rguenther at suse dot de 2013-03-07 10:14:53 UTC --- On Thu, 7 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #31 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 09:58:03 UTC --- (In reply to comment #30) Hmm, RTL PRE isn't really mine either, but I probably know it as well as anyone else, so I will have a look. It's probably a similar issue as for gimple LIM: alias checks. Can you attach your TLC patches for gimple LIM to this PR, please? Bah, I seem to have them in some local tree only but cannot find it. Maybe I accidentially reverted :/ ISTR moving stuff to obstacks as well (LIM has the heaviest load on malloc/free). Oh well.
[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-07 10:17:56 UTC --- Confirmed, same code generated on the 4.6 branch. Works on the 4.5 branch where no vzeroupper is inserted. Likewise no vzeroupper on trunk. Thanks for confirming. The vzeroupper pass didn't exist on the 4.5 branch and has been rewritten to use the mode-switching machinery on mainline.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Blocks||47344 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #73 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07 10:31:53 UTC --- On trunk with the reduced testcase I now see PTA taking 90% of compile-time ... Argh.
[Bug rtl-optimization/54016] loop optimizer: no branch on count on s390 anymore since revision 185913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-03-07 11:24:14 UTC --- Fixed with the patch for BZ56181.
[Bug rtl-optimization/54016] loop optimizer: no branch on count on s390 anymore since revision 185913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-03-07 11:26:26 UTC --- Closed per comment above.
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug target/56561] New: Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Bug #: 56561 Summary: Miscompilation with -Os -arm Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mh+...@glandium.org Created attachment 29609 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29609 Testcase (originally posted on http://gcc.gnu.org/ml/gcc/2013-03/msg00051.html) At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 build of Firefox for Android. We'd like to evaluate whether this bug is hitting us in more places than the one we spotted. To that end, we'd need to know what particular bug in GCC leads to this miscompilation. The attached file is the preprocessed source, slightly simplified, and with enough additions to allow it to be self-contained and with a main() that is able to act on the miscompilation being there or not. I was able to reproduce the miscompilation with both the GCC 4.6 from the Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens for any -march, with -marm, but not -mthumb. It happens at -Os but not -O2. The problematic assembly looks like the following. It corresponds to the C code after the second call to DER_SetUInteger in sftk_mkPrivKey:: bl DER_SetUInteger(PLT) mov r3, #0 cmp sl, r3 movne r0, #2 moveq r0, r3 sl/r10 is never set anywhere in the function, so we're getting random behaviour. This doesn't happen with GCC 4.7, which suggests it may be a known bug. Any ideas? (On an ARM host:) $ gcc -o pkcs11 pkcs11.i -marm -Os -fno-inline ./pkcs11 $ ./pkcs11 FAIL $ gcc -o pkcs11 pkcs11.i -marm -O2 -fno-inline ./pkcs11 $ ./pkcs11 PASS
[Bug c++/56562] New: [AVR GCC] segmentation fault when '__attribute__((packed))' placed at front of enum declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56562
Bug #: 56562
Summary: [AVR GCC] segmentation fault when
'__attribute__((packed))' placed at front of enum
declaration
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pawel...@gmail.com
Created attachment 29610
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29610
Preprocessed testcase 1
when compiling file containig enum declaration like this, there is SIGSEGV.
__attribute__(( packed )) enum FooEnum
{
e1,
e2,
};
Console output is:
avr-g++ -v -save-temps -c test1.cpp
Using built-in specs.
COLLECT_GCC=avr-g++
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib
--enable-long-long --enable-nls --without-included-gettext --disable-libssp
--build=i686-linux-gnu --host=i686-linux-gnu --target=avr
Thread model: single
gcc version 4.7.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c'
/usr/lib/gcc/avr/4.7.0/cc1plus -E -quiet -v test1.cpp -fpch-preprocess
-fno-rtti -fno-enforce-eh-specs -fno-exceptions -o test1.ii
ignoring nonexistent directory
/usr/lib/gcc/avr/4.7.0/../../../avr/include/c++/4.7.0
ignoring nonexistent directory
/usr/lib/gcc/avr/4.7.0/../../../avr/include/c++/4.7.0/avr
ignoring nonexistent directory
/usr/lib/gcc/avr/4.7.0/../../../avr/include/c++/4.7.0/backward
ignoring nonexistent directory
/usr/lib/gcc/avr/4.7.0/../../../avr/sys-include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/avr/4.7.0/include
/usr/lib/gcc/avr/4.7.0/include-fixed
/usr/lib/gcc/avr/4.7.0/../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c'
/usr/lib/gcc/avr/4.7.0/cc1plus -fpreprocessed test1.ii -quiet -dumpbase
test1.cpp -auxbase test1 -version -fno-rtti -fno-enforce-eh-specs
-fno-exceptions -o test1.s
GNU C++ (GCC) version 4.7.0 (avr)
compiled by GNU C version 4.7.0, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.0 (avr)
compiled by GNU C version 4.7.0, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f29438497e2f70243bbaac722728a03e
test1.cpp:5:1: internal compiler error: Naruszenie ochrony pamięci
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/56562] [AVR GCC] segmentation fault when '__attribute__((packed))' placed at front of enum declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56562 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c++ |target --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-07 13:11:57 UTC --- Must be a target issue; - target.
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07
13:32:30 UTC ---
I had to use -O3 -march=loongson2f to trigger it.
During combine, it seems the combiner figures everything out, but mips.md lacks
needed conditional move patterns:
(insn 36 35 37 2 (set (reg:SI 298)
(if_then_else:SI (eq:SI (reg:SI 299)
(const_int 0 [0]))
(reg/v:SI 194 [ a2+-2 ])
(reg/v:SI 213 [ a2+-2 ]))) 602 {*movsi_on_si}
(expr_list:REG_DEAD (reg:SI 299)
(expr_list:REG_DEAD (reg/v:SI 213 [ a2+-2 ])
(expr_list:REG_DEAD (reg/v:SI 194 [ a2+-2 ])
(nil)
(insn 37 36 40 2 (set (reg/v:SI 214 [ a2+-2 ])
(zero_extend:SI (subreg:HI (reg:SI 298) 2))) 188 {*zero_extendhisi2}
(expr_list:REG_DEAD (reg:SI 298)
(nil)))
and combiner has:
Trying 36 - 37:
Failed to match this instruction:
(set (reg/v:SI 214 [ a2+-2 ])
(if_then_else:SI (reg:SI 299)
(reg/v:SI 213 [ a2+-2 ])
(reg/v:SI 194 [ a2+-2 ])))
I.e. it figures that the masking isn't needed, but during
simplification/canonicalization transforms that (ne:SI (reg:SI 299) (const_int
0)) in first argument of IF_THEN_ELSE into (reg:SI 299).
If mips.md had patterns that accepted for movcc the first argument of
IF_THEN_ELSE being a register_operand of GPR mode as if it was (ne:GPR (that
register) (const_int 0)), the testcase would be fixed.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-07 13:37:51 UTC --- I can reproduce the runtime failure on armv5tel-linux-gnueabi with vanilla gcc-4.6.3. Trunk works, as does my heavily patched 4.6-based system compiler. I'll investigate some more later today.
[Bug middle-end/56559] [4.8 Regression] ICE in propagate_op_to_single_use, at tree-ssa-reassoc.c:1057
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56559 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07 14:34:23 UTC --- Author: jakub Date: Thu Mar 7 14:34:15 2013 New Revision: 196520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196520 Log: PR tree-optimization/56559 * tree-ssa-reassoc.c (zero_one_operation): When looking at rhs2, check that it has only a single use. * gcc.dg/tree-ssa/reassoc-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug middle-end/56559] [4.8 Regression] ICE in propagate_op_to_single_use, at tree-ssa-reassoc.c:1057
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56559 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07 14:35:37 UTC --- Fixed.
[Bug c++/56558] Address of operator with template base class member (C++ source compile error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56558 --- Comment #5 from Thierry Moreau thierry.moreau at connotech dot com 2013-03-07 14:45:20 UTC --- paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56558 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-07 08:47:18 UTC --- Indeed. *** This bug has been marked as a duplicate of bug 48593 *** Indeed, and thanks. I reported this bug (against 4.6 -- still supported by volunteers) because it *might* prevent the C++-converted gcc from being build with gcc in the range 3.x to 4.6. Working around bugs 48593 or 56558 is easy: get the pointer value through a reference declaration. The workaround may become a recommended coding style, with rationale being lost in the meantime. I don't know the terminology for gcc developers for applying a bug correction to an earlier version. So, I'm leaving it to you to determine if these bugs are relevant to 4.6 (and prior?) in view of the C++ conversion. Thanks and best regards,
[Bug middle-end/56552] conditional move can generate unnecessary conversion code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56552 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-07 14:53:07 UTC --- (In reply to comment #2) I had to use -O3 -march=loongson2f to trigger it. and combiner has: Trying 36 - 37: Failed to match this instruction: (set (reg/v:SI 214 [ a2+-2 ]) (if_then_else:SI (reg:SI 299) (reg/v:SI 213 [ a2+-2 ]) (reg/v:SI 194 [ a2+-2 ]))) Then this is mine. I think Richard S. already approved this patch too.
[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #74 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07
14:55:27 UTC ---
(In reply to comment #73)
On trunk with the reduced testcase I now see PTA taking 90% of compile-time
...
Argh.
I can speed it up by
@@ -1631,7 +1619,20 @@ do_sd_constraint (constraint_graph_t gra
flag |= bitmap_set_bit (sol, escaped_id);
else if (v-may_have_pointers
add_graph_edge (graph, lhs, t))
- flag |= bitmap_ior_into (sol, get_varinfo (t)-solution);
+ {
+ /* For transitive closures, x = *(x + UNKNOWN), delay
+propagation of the solution across the added edges
+by marking sources as changed. */
+ if (lhs == c-rhs.var)
+ {
+ bitmap_set_bit (changed, t);
+ flag |= true;
+ }
+ /* Else speedup solving by doing that here to save
+iterations. */
+ else
+ flag |= bitmap_ior_into (sol, get_varinfo (t)-solution);
+ }
/* If the variable is not exactly at the requested offset
we have to include the next one. */
as repeatedly walking all of 'sol' for 'sol = *(sol + UNKNOWN)' when
adding the solution of one of delta(sol)'s member is slow. Using
a temporary bitmap to collect all changes doesn't speed it up though,
so the only effect of the above is that the forwarding is delayed until
the next solver iteration (where eventually we discover and eliminate
more indirect cycles).
[Bug c++/56558] Address of operator with template base class member (C++ source compile error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56558 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-07 15:36:02 UTC --- (In reply to comment #5) So, I'm leaving it to you to determine if these bugs are relevant to 4.6 (and prior?) in view of the C++ conversion. They're not relevant. We can't go back and fix existing versions now, so even if we fixed 4.6.4 it wouldn't help people with 4.6.1 or 4.5.3 GCC can be built with much older compilers. If it can't be built, then the source will be changed to use a workaround instead of expecting everyone to update to a patched compiler that can build it. There's no point worrying that every little bug in old versions of GCC will cause a future problem.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #7 from Steve Ellcey sje at gcc dot gnu.org 2013-03-07 15:56:19 UTC --- I included the patch in my nightly build and test and encountered no problems with GCC or GLIBC. I was able to completely build GLIBC in mips16 mode.
[Bug debug/56563] New: no debuginfo for explicit operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563
Bug #: 56563
Summary: no debuginfo for explicit operator
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
Consider this:
struct q {
explicit operator int();
};
q::operator int() { return 23; }
compile with -g and examine the debuginfo with readelf.
There is no mention of the explicit:
237: Abbrev Number: 3 (DW_TAG_subprogram)
38 DW_AT_external: 1
38 DW_AT_name: (indirect string, offset: 0x0): operator int
3c DW_AT_decl_file : 1
3d DW_AT_decl_line : 2
3e DW_AT_linkage_name: (indirect string, offset: 0x12): _ZN1qcviEv
42 DW_AT_type: 0x51
46 DW_AT_declaration : 1
46 DW_AT_object_pointer: 0x4a
[...]
15e: Abbrev Number: 7 (DW_TAG_subprogram)
5f DW_AT_specification: 0x37
63 DW_AT_decl_line : 5
64 DW_AT_low_pc : 0x0
6c DW_AT_high_pc : 0xf 0x0
74 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
76 DW_AT_object_pointer: 0x7e
7a DW_AT_GNU_all_call_sites: 1
7a DW_AT_sibling : 0x8b
This prevents gdb from properly implementing this part of
c++ expressions.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #180 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07
16:08:29 UTC ---
Try
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 196520)
+++ gcc/tree-inline.c (working copy)
@@ -3929,7 +3929,7 @@ expand_call_inline (basic_block bb, gimp
{
id-block = make_node (BLOCK);
BLOCK_ABSTRACT_ORIGIN (id-block) = fn;
- BLOCK_SOURCE_LOCATION (id-block) = input_location;
+ BLOCK_SOURCE_LOCATION (id-block) = LOCATION_LOCUS (input_location);
prepend_lexical_block (gimple_block (stmt), id-block);
}
[Bug c++/56564] New: [4.7 Regression] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
Bug #: 56564
Summary: [4.7 Regression] movdqa on possibly-8-byte-aligned
struct with -O3
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lukeocam...@gmail.com
#include boost/exception_ptr.hpp
struct foo { };
int main()
{
boost::copy_exception(foo());
}
Compiling the above with -O3 results in the following instruction being
emitted:
movdqa %xmm0,
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep(%rip)
But that symbol need not be 16-byte aligned (it's a boost::exception_ptr, which
contains a boost::shared_ptr, which is just a pair of pointers).
This crashes if
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep
comes from another object file where it is declared with 8-byte alignment.
Possible duplicate of 54167? Works fine with 4.6.2
Preprocessed source is attached.
[Bug c++/56564] [4.7 Regression] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #1 from lukeocamden at gmail dot com 2013-03-07 16:26:39 UTC --- Created attachment 29611 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29611 Preprocessed source file
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #34 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 17:13:42 UTC --- Somehow, with -O3 LLVM clang works a little bit faster than with -O2 - 54 minutes instead of 58 minutes, though this might be a random variation: sergei@amdam2:~/gcc_bug time ~/AFSWD/install/LLVM-3.2/binsh/clang -v gap_TlnLv4.c -O3 -c clang version 3.2 (tags/RELEASE_32/final) Target: i386-pc-linux-gnu Thread model: posix /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path /tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length 182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory /include #include ... search starts here: #include ... search starts here: /usr/local/include /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include /usr/include End of search list. real54m18.212s user52m56.062s sys 0m8.085s sergei@amdam2:~/gcc_bug . Memory consumption appears to be the same as with -O2.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #35 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 17:30:58 UTC --- (In reply to comment #34) Memory consumption appears to be the same as with -O2. Can you measure the peak memory with time? /usr/bin/time -f 'real=%e user=%U system=%S share=%P%% maxrss=%M ins=%I outs=%O mfaults=%R waits=%w'
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #36 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 17:33:28 UTC --- (In reply to comment #29) Yeah, one of my minor TLC patches. Most of the excessive memory usage for regular testcases can be fixed by doing LIM on all siblings of the loop tree independently, instead of keeping data on all loops in the function live at the same time (I've not finished _that_ TLC patch - and it won't help for insanely deep nests, of course) It would be very helpful if you can try to recover this one at least, or explain a bit more what you had done. I don't see right away in the code what you mean.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-07 18:14:17 UTC --- The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 fix.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #4 from wbrana wbrana at gmail dot com 2013-03-07 18:35:10 UTC --- compiled 196260 again using same way and nbench is now slow, which is strange. When I compile nbench using gcc compiled from snapshot ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130224/ there is different result from nbench compiled using gcc from GIT using revision 196245 http://gcc.gnu.org/ml/gcc/2013-02/msg00273.html nbench compiled using gcc snapshot is fast nbench compiled using gcc revision is slow file nbench1.c.164t.optimized is same with both gcc builds, but executable has different size despite of using same CFLAGS nbench compiled using gcc revision has 1366219 bytes nbench compiled using gcc snapshot has 1205879 bytes
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2013-03-07 18:40:59 UTC --- (In reply to comment #6) I don't like the patch too much. Why are you removing the cfun-optabs stuff? Because Aldy says, it's getting confusing having all these optabs flying around. set_cfun is called pretty often, e.g. during IPA switching to various functions and back, when you remove cfun-optabs, it will constantly need to recompute the optabs (quite expensive operation) if switching between mips16 vs. non-mips16 functions with different optimization attributes. I don't think that's true, is it? It would only recompute the flags if switching between mips16 and nomips16 functions that have the _same non-default_ optimisation flags. TBH I think that's so rare that it's not worth worrying about for 4.8. I think this optabs stuff is only a stopgap. As I said in the thread on list, and as you said in the original PR, I think we should seriously consider switching the full target_globals structure instead. We can see how things look then as to whether it's worth caching in both cfun and the optimisation node. Richard
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-07 19:02:14 UTC --- It didn't seem to be too confusing and would require only a few extra lines of code (that have been written already). Anyway, I guess I don't care much, so if this works, go ahead and check it in. If you want, you might want to get rid of that ggc_free followed (almost) immediately by ggc_atomic_cleared.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #10 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2013-03-07 19:13:07 UTC --- (In reply to comment #9) It didn't seem to be too confusing and would require only a few extra lines of code (that have been written already). Anyway, I guess I don't care much, so if this works, go ahead and check it in. If you want, you might want to get rid of that ggc_free followed (almost) immediately by ggc_atomic_cleared. Yeah, I'll fix that before submitting, thanks.
[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-07 19:59:57 UTC --- mine..
[Bug c++/56565] New: lambda function in NSMI fails to capture non-static data member.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56565
Bug #: 56565
Summary: lambda function in NSMI fails to capture non-static
data member.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ogoff...@kde.org
This code is accepted by clang.
struct bug { int a; int *b = []{ return a; }(); };
But GCC (4.7 and trunk) report a compilation error:
error: invalid use of non-static data member ‘bug::a’
struct bug { int a; int *b = []{ return a; }(); };
^
error: from this location
struct bug { int a; int *b = []{ return a; }(); };
^
calling this-a works.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #37 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 21:47:52 UTC --- (In reply to comment #35) (In reply to comment #34) Memory consumption appears to be the same as with -O2. Can you measure the peak memory with time? /usr/bin/time -f 'real=%e user=%U system=%S share=%P%% maxrss=%M ins=%I outs=%O mfaults=%R waits=%w' + /usr/bin/time -f 'real=%e user=%U system=%S share=%P%% maxrss=%M ins=%Iouts=%O mfaults=%R waits=%w' /mnt/sdb8/sergei/AFSWD_debug/20121021/LLVM-3.2/bin/clang -v gap_TlnLv4.c -O3 -c clang version 3.2 (tags/RELEASE_32/final) Target: i386-pc-linux-gnu Thread model: posix /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path /tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length 182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory /include #include ... search starts here: #include ... search starts here: /usr/local/include /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include /usr/include End of search list. real=3323.86 user=3224.22 system=8.70 share=97%% maxrss=0 ins=82598outs=8720 mfaults=193511 waits=669 - I am not sure 'maxrss=0' makes sense. Anyway, several minutes before completion 'top' showed 224m (or 228m - I do not remember exactly) in VIRT column. When 'gcc' wokrs, the machine becomes very slowly responsive due to memory usage growth; with 'clang' I do not notice slow down. My machine is dual core with 2G of physical memory.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #38 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 22:15:39 UTC --- Created attachment 29612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29612 Punt on loops with more memory references than LIM can handle For the LIM problem, I'm thinking of a patch like this one (not tested yet). Basically, this means giving up on really large loops with many loads and/or stores. That's not an unreasonable thing to do anyway. Code motion from really big loops usually isn't an improvement. Richi, could you have a look at this, and see if I've got it all right, more-or-less? LIM is quite complicated and I'm not sure if I should look at, or update, the set of optimizable loops somewhere. With the patch, and with -O2 -fgcse, I now have: gap_TlnLv4.c: In function 'RDFT_49152_1': gap_TlnLv4.c:37502:18: warning: -ftree-loop-im: number of memory references in loop exceeds the --param loops-max-datarefs-for-datadeps threshold [-Wdisabled-optimization] t12308[500] = t12304[6144*i0+1000]; ^ dead store elim1: 57.70 ( 8%) dead store elim2: 76.82 (10%) combiner: 360.07 (48%) reload CSE regs : 55.44 ( 7%) TOTAL : 743.77
[Bug target/56546] Using the divide operator on unsigned int produces incorrect code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56546
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target||avr
Priority|P3 |P4
Status|UNCONFIRMED |WAITING
Last reconfirmed||2013-03-07
CC||gjl at gcc dot gnu.org
Ever Confirmed|0 |1
Severity|critical|normal
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-07
22:20:48 UTC ---
(In reply to comment #0)
Created attachment 29592 [details]
Sample code to reproduce the issue
Using the divide integer on unsigned int variables on an AVR target leads to
wrong code being generated. The generated code uses the __umulhisi3 routine
from libgcc which is a multiplication routine and the result is always zero.
Can't confirm this using the following, slightly extended test case:
$ avr-gcc-4.7.2 -O0 -mmcu=atmega8 foo.c -o foo.elf
#include stdlib.h
int main (void)
{
volatile unsigned int toto = 140;
toto /= 60;
if (toto != 2)
abort();
return 0;
}
The objdump shows that __umulhisi3 is actually called: It computes the high
part of 140 * 0x8889 which is 0x004a. This value is then unsigned-shifted by 5
to the right which is 2. This, in turn, is the expectet result of 140 / 60.
Runing a simulator hits exit (by returning from main).
[snip unrelated text]workings of gcc, I
I've come up with a very simple source file that allows to reproduce
the issue.
By the way I couldn't think of any case where transforming a udiv into a mult
operating on integers would make sense and would be glad if someone could give
me some hints on this.
AVR has no divide instruction and / 60 is performed by a multiplication and
some adjustment.
Here's the command line I used:
avr-gcc -O0 -g -Wall -Wextra -save-temps -mmcu=atmega8 -o main.elf main.c
And the version of the toolchain components:
binutils: efb7cff2df30eb792d30e8afc384aa88c193932b
gcc: ef11013858b41453c4953ca8d4c25e3b1668e536
avr-libc: 2ac01d285e23894ef3bcc65c75b39da8157b9fd9
These are no versions.
Please show the output of avr-gcc -v.
gcc-4.7.2, binutils 2.23.1 and avr-libc 1.8.0 give the same result.
Is this an unpatched avr-gcc?
[Bug target/56562] [AVR GCC] segmentation fault when '__attribute__((packed))' placed at front of enum declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56562 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Known to work||4.7.2 Keywords||ice-on-valid-code CC||gjl at gcc dot gnu.org Resolution||WORKSFORME Target Milestone|--- |4.7.2 Severity|major |normal --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-07 22:42:08 UTC --- I can confirm this whith 4.7.1 20120322 (prerelease). It works fine with 4.7.2 and 4.8.0 (experimental): stdin:1:32: warning: attribute ignored in declaration of 'enum FooEnum' [-Wattributes] __attribute__(( packed )) enum FooEnum ^ stdin:1:32: note: attribute for 'enum FooEnum' must follow the 'enum' keyword It works also with the packed attribute in the right place. Whatever the issue was, it's fixed in latest 4.7, thus closing this as WORKSFORME.
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #15 from Cesar Strauss cestrauss at gmail dot com 2013-03-07 23:03:52 UTC --- (In reply to comment #14) I just tried out to bootstrap r196092 on mingw32. There is still one more cast patch missing to make it work for that target. diff -uart gcc-4.8.0-r196092/gcc/ada/seh_init.c gcc-4.8.0/gcc/ada/seh_init.c --- gcc-4.8.0-r196092/gcc/ada/seh_init.c2013-02-16 08:26:53 + +++ gcc-4.8.0/gcc/ada/seh_init.c2013-02-06 12:01:20 + @@ -198,7 +198,7 @@ #endif Raise_From_Signal_Handler (exception, msg); - return 0; /* This is never reached, avoid compiler warning */ + return (EXCEPTION_DISPOSITION)0; /* This is never reached, avoid compiler warning */ } #endif /* !(defined (_WIN64) defined (__SEH__)) */ That's ugly, please use ATTRIBUTE_NORETURN instead. How about this (tested on i686-pc-mingw32): Index: seh_init.c === --- seh_init.c(revision 196484) +++ seh_init.c(working copy) @@ -60,7 +60,8 @@ extern struct Exception_Data _abort_sign #define Raise_From_Signal_Handler \ ada__exceptions__raise_from_signal_handler -extern void Raise_From_Signal_Handler (struct Exception_Data *, const char *); +extern void Raise_From_Signal_Handler (struct Exception_Data *, const char *) + ATTRIBUTE_NORETURN; #if defined (_WIN32) @@ -72,7 +73,8 @@ extern void Raise_From_Signal_Handler (s extern void _global_unwind2 (void *); EXCEPTION_DISPOSITION __gnat_SEH_error_handler -(struct _EXCEPTION_RECORD*, void*, struct _CONTEXT*, void*); +(struct _EXCEPTION_RECORD*, void*, struct _CONTEXT*, void*) + ATTRIBUTE_NORETURN; struct Exception_Data * __gnat_map_SEH (EXCEPTION_RECORD* ExceptionRecord, const char **msg); @@ -198,7 +200,6 @@ __gnat_SEH_error_handler (struct _EXCEPT #endif Raise_From_Signal_Handler (exception, msg); - return 0; /* This is never reached, avoid compiler warning */ } #endif /* !(defined (_WIN64) defined (__SEH__)) */
[Bug c++/56565] lambda function in NSMI fails to capture non-static data member.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56565 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Blocks||54367 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-07 23:18:27 UTC --- Confirmed.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #39 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 23:18:48 UTC --- Memory usage is still pathetic. Some stats: mem stats from /proc/self/statm on *entry* of pass: pass (#) sizeresident *warn_unused_result ( -1)177106944 140742656 ... *init_datastructures ( -1) 209670144 169570304 ssa ( 20)209670144 169582592 *rebuild_cgraph_edges ( -1) 302575616 259780608 ... expand (169) 390647808 349757440 vregs (170) 477892608 425406464 ... dfinit (174) 477892608 425627648 cse1 (175) 615616512 565694464 ... dse1 (195) 727654400 634572800 fwprop2 (196)791678976 723767296 ... combine (200)823115776 752177152 ce2 (201) 6589759488 6512082944 ... csa (222) 6938136576 1057169408 This means that combine explodes the memory foot print by ~5.4 GB. On entry to combine, the memory foot print is ~750MB. I don't think that is unreasonable. But after combine, the memory footprint jumps to ~7GB max, and 350GB resident (after a ggc_collect before csa). I'm guessing most of that 350GB is combine leaving memory scattered so that pages can't be released. dfinit is also a major contributor to the huge memory foot print. I have seen that in other test cases also, but so far I can't figure out how it can consume this much memory. Interestingly, the initial memory footprint, out of the front end, is ~180 MB. From there, the memory foot print gradually goes up, but that is probably in part because ggc_collect is just never called (this is on a box with 16GB RAM), with GGC params: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 With both parameters halved, the combine problem obviously remains, and the dfinit problem becomes more pronounced: expand (169) 328032256 287195136 vregs (170) 474415104 424263680 ... dfinit (174) 474415104 424484864 cse1 (175) 613801984 564596736 ... combine (200)823496704 752828416 ce2 (201) 6590169088 6512717824 The good news: There clearly is a lot of room for improvement for this test case. :-)
[Bug c/56566] New: bogus is narrower than values of its type warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56566
Bug #: 56566
Summary: bogus is narrower than values of its type warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
struct S {
enum E {
N = -1,
Z = 0
} e : 1;
};
int main() { return 0; }
Using current trunk (r196526):
gcc -c tt.c
tt.c:5:3: warning: ‘e’ is narrower than values of its type [enabled by default]
} e : 1;
^
g++ -c tt.c
tt.c:5:9: warning: ‘S::e’ is too small to hold all values of ‘enum S::E’
[enabled by default]
} e : 1;
^
7.2/7 of the C++ standard says
for an enumeration where emin is the smallest enumerator and emax is the
largest, the values of the enumeration are the values in the range bmin to
bmax, defined as follows: Let K be 1 for a two’s complement representation
and 0 for a one’s complement or sign-magnitude representation. bmax is the
smallest value greater than or equal to max(|emin| − K, |emax|) and equal to
2^M − 1, where M is a non-negative integer. bmin is zero if emin is non-
negative and −(bmax + K) otherwise. The size of the smallest bit-field large
enough to hold all the values of the enumeration type is max(M, 1) if bmin
is
zero and M + 1 otherwise.
given emin = -1, emax = 0, K = 1
then max(|emin|-K,|emax|) = max(0,0) = 0
therefore bmax = 0, M = 0, bmin = -(bmax+K) = -1, size = M+1 = 1
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-03-07 23:26:01 UTC --- (In reply to comment #3) (In reply to comment #2) Any specific sections you can point me to? I'd be interested to hear a justification for this behavior. Simple answer, an interrupt can happen any time after the access/assignment of the global register variable so it needs to be set to the value and treated as a volatile variable. Is this really the case? There is not even a means to tag a REG as volatile. The /v flag is set but for REGs it means user variable, see rtl.h and the docs for volatil. http://gcc.gnu.org/viewcvs/trunk/gcc/rtl.h?view=markup#l286 And qualifying foo as volatile diagnoses as expected: stdin:1:1: warning: optimization may eliminate reads and/or writes to register variables [-Wvolatile-register-var] This issue looks rather like a fallout of reload that for some reasons spills for the shift insn. See also PR49491 Or are global registers spacial for reload? I still don't see why a spilling is needed for the shift insn...
[Bug target/56439] [avr] unnecessary spill for global and local register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, ra Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Known to work||3.4.6 Blocks||56183 Summary|global and local register |[avr] unnecessary spill for |variables don't work in a |global and local register |useful way -- AVR |variables Ever Confirmed|0 |1
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
--- Comment #8 from Joey Ye joey.ye at arm dot com 2013-03-08 03:56:38 UTC ---
// A none loop case shows how minor changes impacts current jump thread
behavior
int foo(int state, int check)
{
switch (state) {
case 0:
state = 1;
zoo_0();
break;
case 1:
default:
state = 0;
zoo_1();
break;
}
if (!check) return 0;
//check++; // Uncomment it results will disable jump thread
//check=foo(); // Uncomment it results will disable jump thread
switch (state) {
case 0:
bar_0();
break;
case 1:
default:
bar_1();
break;
}
return check;
}
[Bug c++/49122] [C++0x] initializer_list is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49122 David Krauss potswa at mac dot com changed: What|Removed |Added CC||potswa at mac dot com --- Comment #7 from David Krauss potswa at mac dot com 2013-03-08 06:56:00 UTC --- I think this should be reopened. The return value object, which exists in the calling scope, is initialized from the braced-init-list. No copying occurs beyond what is demonstrated in the example in [dcl.init.list]/6. For more detail, see http://stackoverflow.com/q/15286450/153285 .
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 --- Comment #5 from jye2 at gcc dot gnu.org 2013-03-08 07:25:17 UTC --- Author: jye2 Date: Fri Mar 8 07:25:09 2013 New Revision: 196534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196534 Log: 013-03-08 Joey Ye joey...@arm.com Backport from mainline 2013-03-06 Joey Ye joey...@arm.com PR lto/50293 * gcc.c (convert_white_space): New function. (main): Handles white space in function name. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gcc.c
