[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the trunk and the 4.9 branch.
[Bug debug/63623] New: Lots of functions get -fvar-tracking silently turned off unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63623
Bug ID: 63623
Summary: Lots of functions get -fvar-tracking silently turned
off unnecessarily
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
I have got a report that when glibc is compiled with gcc 4.8.x, the debug info
for the bytes parameter to __libc_malloc is wrong in the prologue (and
epilogue).
Here is a reduced testcase for x86_64-linux:
-std=gnu99 -fgnu89-inline -O2 -fmerge-all-constants -frounding-math -g -dA
-fPIC:
void *a;
extern void *(*d) (__SIZE_TYPE__, const void *);
void *foo (void *, __SIZE_TYPE__);
void *bar (void *, __SIZE_TYPE__);
void *
__libc_malloc (__SIZE_TYPE__ bytes)
{
void *b, *c;
if (__builtin_expect (d != 0, 0))
return d (bytes, 0);
b = a;
if (!b)
return 0;
c = foo (b, bytes);
if (!c)
b = bar (b, bytes);
return b;
}
r203167 on the trunk fixed this by slightly changing the CFG (because of the
__builtin_expect), so the bug went latent on this testcase.
I've investigated this and found that this is because the function doesn't have
frame pointer and vt_stack_adjustments failed on the function, which precludes
not just -fvar-tracking-assignments, but also -fvar-tracking altogether.
And the reason for that is that it doesn't handle i?86/x86_64 pop instructions,
like:
(insn/f:TI 76 81 77 8 (set (reg:DI 3 bx)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8])) rh1151226.i:19 75
{*popdi1}
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
where it doesn't account for any stack adjustment in such functions. Thus,
stack_adjust values may be either wrong in the VTA info, leading to wrong
debug, or, if because of that there is some disagreement on the edges between
what the stack_adjust value should be, it gives up on -fvar-tracking
altogether.
[Bug debug/63623] Lots of functions get -fvar-tracking silently turned off unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63623 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33789 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33789action=edit gcc5-pr63623.patch Patch (successfully tested).
[Bug debug/63623] Lots of functions get -fvar-tracking silently turned off unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63623 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- dwlocstat --tabulate=0.0:10,99 results on cc1plus bootstrapped --enable-checking=yes,rtl binaries before/after the patch (in the tree without the patch I've applied the patch afterwards and did make cc1plus in the gcc directory, so var-tracking.o in stage3 got rebuilt again and thus the compared binaries contain exactly the same code, just different debug info): x86_64-linux cc1plus built without the patch: cov%samplescumul 0.0506230/38%506230/38% 0..1010327/0%516557/39% 11..2012390/0%528947/39% 21..3031265/2%560212/42% 31..4018775/1%578987/43% 41..5020631/1%599618/45% 51..6024921/1%624539/47% 61..7040959/3%665498/50% 71..8023771/1%689269/52% 81..9041771/3%731040/55% 91..9981667/6%812707/61% 100510564/38%1323271/100% x86_64-linux cc1plus built with the patch: cov%samplescumul 0.0382214/28%382214/28% 0..1013100/0%395314/29% 11..2014568/1%409882/30% 21..3033708/2%443590/33% 31..4021927/1%465517/35% 41..5023924/1%489441/36% 51..6028736/2%518177/39% 61..7045847/3%564024/42% 71..8029284/2%593308/44% 81..9052085/3%645393/48% 91..9999971/7%745364/56% 100577907/43%1323271/100% i686-linux cc1plus built without the patch: cov%samplescumul 0.0631348/48%631348/48% 0..107764/0%639112/48% 11..209690/0%648802/49% 21..3025036/1%673838/51% 31..4016113/1%689951/52% 41..5019753/1%709704/54% 51..6014563/1%724267/55% 61..7034093/2%758360/58% 71..8017450/1%775810/59% 81..9031339/2%807149/61% 91..9960368/4%867517/66% 100437548/33%1305065/100% i686-linux cc1plus built with the patch: cov%samplescumul 0.0377352/28%377352/28% 0..1016077/1%393429/30% 11..2015390/1%408819/31% 21..3031790/2%440609/33% 31..4023889/1%464498/35% 41..5029267/2%493765/37% 51..6022902/1%516667/39% 61..7045629/3%562296/43% 71..8029511/2%591807/45% 81..9050536/3%642343/49% 91..9993584/7%735927/56% 100569138/43%1305065/100% .debug_info/.debug_loc sizes in bytes: x86_64-linux cc1plus without patch .debug_info 75411710, .debug_loc 75421077 x86_64-linux cc1plus withpatch .debug_info 78498790, .debug_loc 90530117 i686-linux cc1plus without patch .debug_info 59921183, .debug_loc 37823166 i686-linux cc1plus withpatch .debug_info 63009554, .debug_loc 59535100
[Bug bootstrap/63574] [5 Regression] ICE building libjava (segfault) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63574 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- caused by one bug in IPA-ICF-gimple pass, reported to gcc-patch list. https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02307.html
[Bug c++/63619] warning: deleting ‘void*’ is undefined has no -W flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63619 --- Comment #4 from Teodor Petrov fuscated at gmail dot com --- FYI: clang fixed the same issue by adding it to -Wdelete-incomplete
[Bug bootstrap/63624] New: [5.0 regression] internal compiler error: in unify_one_argument, at cp/pt.c:16638 breaks m68k-linux bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63624 Bug ID: 63624 Summary: [5.0 regression] internal compiler error: in unify_one_argument, at cp/pt.c:16638 breaks m68k-linux bootstrap Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Attempting to bootstrap gcc-5-20141019 (r216444) on m68k-linux fails with: mkdir -p ./m68k-unknown-linux-gnu/bits/stdc++.h.gch /mnt/scratch/objdir50/./gcc/xgcc -shared-libgcc -B/mnt/scratch/objdir50/./gcc -nostdinc++ -L/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/src -L/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/mnt/scratch/install50/m68k-unknown-linux-gnu/bin/ -B/mnt/scratch/install50/m68k-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install50/m68k-unknown-linux-gnu/include -isystem /mnt/scratch/install50/m68k-unknown-linux-gnu/sys-include-x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu -I/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-5-20141019/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /mnt/scratch/gcc-5-20141019/libstdc++-v3/include/precompiled/stdc++.h \ -o m68k-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include/map:60:0, from /mnt/scratch/gcc-5-20141019/libstdc++-v3/include/precompiled/stdc++.h:80: /mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include/bits/stl_tree.h: In member function 'void std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::_M_move_data(std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc, std::false_type)': /mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include/bits/stl_tree.h:1244:6: internal compiler error: in unify_one_argument, at cp/pt.c:16638 }; ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [m68k-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 make[5]: Leaving directory `/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3/include' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/mnt/scratch/objdir50/m68k-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all-stage2-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir50' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir50' make: *** [bootstrap] Error 2 This gcc version bootstrapped fine on x86_64, sparc64, powerpc64, and armv5tel. The 2nd previous weekly snapshot, gcc-5-20141005, bootstrapped fine on m68k. Configuration options: /mnt/scratch/gcc-5-20141019/configure --prefix=/mnt/scratch/install50 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++ --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --disable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto --disable-multilib --disable-libgomp
[Bug c/63625] New: -flto breaks optimization during link phase on arm-none-eabi without -O on linker (!) command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63625 Bug ID: 63625 Summary: -flto breaks optimization during link phase on arm-none-eabi without -O on linker (!) command line Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: anpaza at mail dot ru Created attachment 33790 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33790action=edit A test source file build shell script demonstrating the bug I use arm-none-eabi-gcc (Fedora 2013.11.24-2.fc19) 4.8.1. When compiling and linking as usual with the -flto switch the resulting executable is not optimized. It looks like the code gets recompiled again somehow if -flto was specified on linker command line (I'm not sure how exactly -flto works but I suppose it relinks the whole code again somewhat like -fwhole-program but from GIMPLE opcodes). Since it recompiles everything again, the optimization options have effect on the result. If you don't specify -O on linker command line (which is useless in the traditional usage mode), you'll get an absolutely unoptimized executable. I think the optimization options should be either stored into the object files, or maybe at least WRITE A BIG RED WARNING in the manual about it. I'm doing embedded code and was shocked of the quality of the code... then I objdump'ed the object file and have seen a totally different code - clean and optimized. I almost pulled all my hair off till I realized it was the -flto switch that I monkey-copied from someone else's makefile and after reading the description in the manual I decided it is a good thing. The attached scripts demonstrate the bug. Comment out the -flto LDFLAGS switch and the .s output gets optimized, uncomment and it gets unoptimized.
[Bug c/63626] New: Warning inline function declared but never defined output twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63626 Bug ID: 63626 Summary: Warning inline function declared but never defined output twice Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org On this TU: inline int foo (void); we warn twice: ff.c:1:12: warning: inline function ‘foo’ declared but never defined inline int foo (void); ^ ff.c:1:12: warning: inline function ‘foo’ declared but never defined
[Bug c/63626] Warning inline function declared but never defined output twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63626 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-23 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #20 from ramana.radhakrishnan at arm dot com ramana.radhakrishnan at arm dot com --- On 23/10/14 00:28, e.menezes at samsung dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #16 from Evandro e.menezes at samsung dot com --- (In reply to Wilco from comment #15) Using -Ofast is not any different from -O3 -ffast-math when compiling non-Fortran code. As comment 10 shows, both loops are vectorized, however LLVM unrolls twice and uses multiple accumulators while GCC doesn't. You're right. LLVM produces: .LBB0_1:// %vector.body // =This Inner Loop Header: Depth=1 add x11, x9, x8 add x12, x10, x8 ldp q2, q3, [x11] ldp q4, q5, [x12] add x8, x8, #32 // =32 fmla v0.2d, v2.2d, v4.2d fmla v1.2d, v3.2d, v5.2d cmp x8, #128, lsl #12 // =524288 b.ne.LBB0_1 And GCC: .L3: ldr q2, [x2, x0] add w1, w1, 1 ldr q1, [x3, x0] cmp w1, w4 add x0, x0, 16 fmlav0.2d, v2.2d, v1.2d bcc .L3 I still don't see what this has to do with A57. You should open a generic bug about GCC not applying basic loop optimizations with -O3 (in fact limited unrolling is useful even for -O2). Indeed, but I think that there's still a code-generation opportunity for A57 here. What you mention is a general code generation improvement for AArch64. There's nothing Cortex-A57 specific about it. In the AArch64 backend, we think architecture and then micro-architecture. Note above that the registers are loaded in pairs by LLVM, while GCC, when it unrolls the loop, more aggressively BTW, each vector is loaded individually: .L3: ldr q28, [x15, x16] add x17, x16, 16 ldr q29, [x14, x16] add x0, x16, 32 ldr q30, [x15, x17] add x18, x16, 48 ldr q31, [x14, x17] add x1, x16, 64 ... fmlav27.2d, v28.2d, v29.2d ... fmlav27.2d, v30.2d, v31.2d ... # Rest of 8x unroll bcc .L3 It also goes without saying that this code could also benefit from the post-increment addressing mode. What's the kind of performance delta you see if you managed to unroll the loop just a wee bit ? Probably not much looking at the code produced here. Ramana
[Bug rtl-optimization/63448] [4.9/5 Regression] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug sanitizer/63627] New: thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63627 Bug ID: 63627 Summary: thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rogero at howzatt dot demon.co.uk CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 33791 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33791action=edit EXample using __atomic_test_and_set that causes tsan positives When compiling code using atomic instrinsics with -fsanitize=thread some of the functions - in particular __atomic_test_and_set and __atomic_clear are not instrumented. Hence tsan reports false positives when spin-locking with __atomic_test_and_set/__atomic_clear but not when using __atomic_exchange_n/__atomic_store_n. (This also affects std:atomic_flag as it uses the problematic operations in its implementation.)
[Bug sanitizer/63627] thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63627 --- Comment #1 from Roger Orr rogero at howzatt dot demon.co.uk --- Created attachment 33792 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33792action=edit Example using __atomic_exchange_n that does not generate tsan warnings
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #21 from Richard PALO richard at netbsd dot org --- The problem has been isolated in illumos with a preliminary patch available. This test now passes with the fix applied, therefore I believe the issue can be closed as an OS issue and not a bug. cheers
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |INVALID --- Comment #22 from Rainer Orth ro at gcc dot gnu.org --- Ok, thanks for the update. Rainer
[Bug bootstrap/63624] [5.0 regression] internal compiler error: in unify_one_argument, at cp/pt.c:16638 breaks m68k-linux bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63624 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c/63625] -flto breaks optimization during link phase on arm-none-eabi without -O on linker (!) command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63625 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This is implemented for GCC 4.9 and I believe the manual correctly states what happens for GCC 4.8.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63600 --- Comment #5 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Created attachment 33793 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33793action=edit Updated patch + regtest Will check in after testing is over
[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63600 --- Comment #6 from Kirill Yukhin kyukhin at gcc dot gnu.org --- (In reply to Kirill Yukhin from comment #5) Created attachment 33793 [details] Updated patch + regtest Will check in after testing is over Checked into main trunk (forgot to put PR into ChangeLogs). https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg00853.html
[Bug target/63600] [5 Regression] ice in ix86_expand_sse2_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63600 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: kyukhin Date: Thu Oct 23 11:50:19 2014 New Revision: 216591 URL: https://gcc.gnu.org/viewcvs?rev=216591root=gccview=rev Log: AVX. Fix block absq emit for non AVX-512 targets. gcc/ * config/i386/sse.md (define_mode_iterator VI1248_AVX512VL_AVX512BW): New. (define_insn *absmode2): Use VI1248_AVX512VL_AVX512BW mode iterator. (define_expand absmode2): Ditto. gcc/testsuite/ * gcc.target/i386/pr63600.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr63600.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug c++/61814] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Alexander Dubov oakad at yahoo dot com changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment #1 from Alexander Dubov oakad at yahoo dot com ---
This problem still happens on 4.9.1.
For example, this example works:
int main(int argc, char **argv)
{
int a{5};
float z(0.5);
[a](float z_) - void {
decltype(a) b = a;
}(z);
return 0;
}
But this basic modification fails to compile (g++-4.9.1 -std=gnu++14):
int main(int argc, char **argv)
{
int a{5};
float z(0.5);
[a](auto z_) - void {
decltype(a) b = a;
}(z);
return 0;
}
[Bug c++/61814] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Alexander Dubov from comment #1)
But this basic modification fails to compile (g++-4.9.1 -std=gnu++14):
int main(int argc, char **argv)
{
int a{5};
float z(0.5);
[a](auto z_) - void {
decltype(a) b = a;
}(z);
return 0;
}
That seems to be a different issue, and is fixed on trunk.
[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607 --- Comment #2 from Fei Yang fei.yang0953 at gmail dot com --- (In reply to Richard Biener from comment #1) Is -mfloat-abi=softfp properly used at LTO stage? It seems that -mfloat-abi=softfp is here for lto1: /home/lxr/install/bin/../lib/gcc/../../libexec/gcc/armeb-linux-gnueabi/4.7.1/lto1 -quiet -dumpdir ./ -dumpbase 1.wpa -mfloat-abi=softfp -march=armv7-a -mtls-dialect=gnu -mfloat-abi=softfp -march=armv7-a -mtls-dialect=gnu -auxbase cc9cih7t -O2 -version -fltrans-output-list=/tmp/ccZqlDqA.ltrans.out -fwpa -fresolution=/tmp/ccUnDlh3.res @/tmp/ccSi9hcz
[Bug c++/61814] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-23
CC||jason at gcc dot gnu.org
Known to work||5.0
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Actually the original problem is fixed on trunk too (but gives a different
error now), so maybe it is the same and can be reduced to:
int main()
{
int a{5};
[a](auto z) - void {
decltype(a) b = a;
}(1);
}
l.cc: In instantiation of ‘main()::lambda(auto:1) [with auto:1 = int]’:
l.cc:6:6: required from here
l.cc:5:17: error: ‘a’ was not declared in this scope
decltype(a) b = a;
^
The error goes away if the lambda doesn't have a trailing-return-type, or if
it's not a generic lambda.
Jason, is it worth fixing this on the branch? It only affects C++14 mode.
[Bug c++/63628] New: [c++1y] cannot use decltype on captured variable in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628
Bug ID: 63628
Summary: [c++1y] cannot use decltype on captured variable in
generic lambda
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, jason at gcc dot
gnu.org,
oakad at yahoo dot com, tongari95 at gmail dot com
Blocks: 54367
+++ This bug was initially created as a clone of Bug #61814 +++
The code below has a lambda that captures the outer params t, for forwarding
matter, decltype on t has to be used.
```
auto const pack = [](auto... t)
{
return [](auto f)-decltype(auto)
{
return f(static_castdecltype(t)(t)...);
};
};
int main(int argc, char** argv) {
pack(1)([](int){});
return 0;
}
```
It works with clang 3.5, but g++ 4.9.0 complains:
error: 't' was not declared in this scope
The same also applies to `sizeof` or that kind of compile-time thing.
[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-23
Summary|[c++1y] cannot use decltype |[c++1y] cannot use decltype
|on captured variable in |on captured arg-pack
|generic lambda |
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
This still fails on trunk, reduced from the original code in PR 61814
auto const pack = [](auto... t)
{
[]
{
int a[] = { static_castdecltype(t)(t)... };
};
};
int main() {
pack(1);
}
ll.cc: In instantiation of ‘lambda(auto:1 ...)::lambda() [with auto:1 =
{int}]’:
ll.cc:5:49: required from ‘structlambda(auto:1 ...) [with auto:1 =
{int}]::lambda()’
ll.cc:3:9: required from ‘lambda(auto:1 ...) [with auto:1 = {int}]’
ll.cc:10:15: required from here
ll.cc:5:55: error: cannot convert ‘decltype (t)’ to ‘int’ in initialization
int a[] = { static_castdecltype(t)(t)... };
^
ll.cc:5:55: error: storage size of ‘a’ isn’t known
[Bug c++/63628] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
And this variation gives an ICE:
void sink(...) { }
auto const pack = [](auto... t)
{
[]
{
sink( static_castdecltype(t)(t)... );
};
};
int main() {
pack(1);
}
ll.cc: In instantiation of ‘lambda(auto:1 ...)::lambda() [with auto:1 =
{int}]’:
ll.cc:7:43: required from ‘structlambda(auto:1 ...) [with auto:1 =
{int}]::lambda()’
ll.cc:5:9: required from ‘lambda(auto:1 ...) [with auto:1 = {int}]’
ll.cc:12:15: required from here
ll.cc:7:16: internal compiler error: in cxx_incomplete_type_diagnostic, at
cp/typeck2.c:572
sink( static_castdecltype(t)(t)... );
^
0x615fb9 cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*,
diagnostic_t)
/home/jwakely/src/gcc/gcc/cp/typeck2.c:572
0x6ba1c4 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/cp/typeck.c:153
0x6ba279 require_complete_type_sfinae(tree_node*, int)
/home/jwakely/src/gcc/gcc/cp/typeck.c:90
0x552061 convert_arg_to_ellipsis(tree_node*, int)
/home/jwakely/src/gcc/gcc/cp/call.c:6565
0x557e37 build_over_call
/home/jwakely/src/gcc/gcc/cp/call.c:7265
0x56dfcb build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
/home/jwakely/src/gcc/gcc/cp/call.c:4072
0x71c5cc finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
/home/jwakely/src/gcc/gcc/cp/semantics.c:2361
0x6b9b86 complete_type(tree_node*)
/home/jwakely/src/gcc/gcc/cp/typeck.c:134
0x6506a5 mark_used(tree_node*, int)
/home/jwakely/src/gcc/gcc/cp/decl2.c:4936
0x55870b build_over_call
/home/jwakely/src/gcc/gcc/cp/call.c:7411
0x56bf2b build_op_call_1
/home/jwakely/src/gcc/gcc/cp/call.c:4303
0x56bf2b build_op_call(tree_node*, vectree_node*, va_gc, vl_embed**, int)
/home/jwakely/src/gcc/gcc/cp/call.c:4326
0x71c513 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
/home/jwakely/src/gcc/gcc/cp/semantics.c:2378
0x7e4e82 c_common_parse_file()
/home/jwakely/src/gcc/gcc/c-family/c-opts.c:1050
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-23 Ever confirmed|0 |1 Severity|normal |blocker --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- If I configure gcc r216305 with the patch in pr63534 comment 33 with ../p_work/configure --prefix=/opt/gcc/gcc4.10p-216305p1 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 and use make BOOT_CFLAGS=-O2 -g -fno-ipa-icf CFLAGS_FOR_TARGET=-O2 -g -fno-ipa-icf CXXFLAGS_FOR_TARGET=-O2 -g -fno-ipa-icf a clean bootstrap fails with rm -f rts/libgnat.dylib rts/libgnarl.dylib cd rts; `echo /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/bin/ -B/opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/include -isystem /opt/gcc/gcc4.10p-216305p1/x86_64-apple-darwin14.0.0/sys-include\ | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` -dynamiclib -fno-common \ -o libgnat-4.10.dylib \ a-assert.o a-btgbso.o a-calari.o a-calcon.o a-caldel.o a-calend.o a-calfor.o a-catizo.o a-cbdlli.o a-cbhama.o a-cbhase.o a-cbmutr.o a-cborma.o a-cborse.o a-cbprqu.o a-cbsyqu.o a-cdlili.o a-cfdlli.o a-cfhama.o a-cfhase.o a-cforma.o a-cforse.o a-cgaaso.o a-cgarso.o a-cgcaso.o a-chacon.o a-chahan.o a-charac.o a-chlat1.o a-chlat9.o a-chtgbk.o a-chtgbo.o a-chtgke.o a-chtgop.o a-chzla1.o a-chzla9.o a-cidlli.o a-cihama.o a-cihase.o a-cimutr.o a-ciorma.o a-ciormu.o a-ciorse.o a-clrefi.o a-cobove.o a-cofove.o a-cogeso.o a-cohama.o a-cohase.o a-cohata.o a-coinho.o a-coinve.o a-colien.o a-colire.o a-comlin.o a-comutr.o a-contai.o a-convec.o a-coorma.o a-coormu.o a-coorse.o a-coprnu.o a-coteio.o a-crbltr.o a-crbtgk.o a-crbtgo.o a-crdlli.o a-csquin.o a-cuprqu.o a-cusyqu.o a-cwila1.o a-cwila9.o a-decima.o a-diocst.o a-direct.o a-direio.o a-dirval.o a-einuoc.o a-elchha.o a-envvar.o a-except.o a-exctra.o a-finali.o a-flteio.o a-fwteio.o a-fzteio.o a-inteio.o a-ioexce.o a-iteint.o a-iwteio.o a-izteio.o a-lcteio.o a-lfteio.o a-lfwtio.o a-lfztio.o a-liteio.o a-liwtio.o a-liztio.o a-llctio.o a-llftio.o a-llfwti.o a-llfzti.o a-llitio.o a-lliwti.o a-llizti.o a-locale.o a-ncelfu.o a-ngcefu.o a-ngcoar.o a-ngcoty.o a-ngelfu.o a-ngrear.o a-nlcefu.o a-nlcoar.o a-nlcoty.o a-nlelfu.o a-nllcar.o a-nllcef.o a-nllcty.o a-nllefu.o a-nllrar.o a-nlrear.o a-nscefu.o a-nscoty.o a-nselfu.o a-nucoar.o a-nucoty.o a-nudira.o a-nuelfu.o a-nuflra.o a-numaux.o a-numeri.o a-nurear.o a-rbtgbk.o a-rbtgbo.o a-rbtgso.o a-sbecin.o a-sbhcin.o a-sblcin.o a-scteio.o a-secain.o a-sequio.o a-sfecin.o a-sfhcin.o a-sflcin.o a-sfteio.o a-sfwtio.o a-sfztio.o a-shcain.o a-siocst.o a-siteio.o a-siwtio.o a-siztio.o a-slcain.o a-ssicst.o a-ssitio.o a-ssiwti.o a-ssizti.o a-stboha.o a-stfiha.o a-stmaco.o a-storio.o a-strbou.o a-stream.o a-strfix.o a-strhas.o a-string.o a-strmap.o a-strsea.o a-strsup.o a-strunb.o a-ststio.o a-stunau.o a-stunha.o a-stuten.o a-stwibo.o a-stwifi.o a-stwiha.o a-stwima.o a-stwise.o a-stwisu.o a-stwiun.o a-stzbou.o a-stzfix.o a-stzhas.o a-stzmap.o a-stzsea.o a-stzsup.o a-stzunb.o a-suecin.o a-suenco.o a-suenst.o a-suewst.o a-suezst.o a-suhcin.o a-sulcin.o a-suteio.o a-swbwha.o a-swfwha.o a-swmwco.o a-swunau.o a-swuwha.o a-swuwti.o a-szbzha.o a-szfzha.o a-szmzco.o a-szunau.o a-szuzha.o a-szuzti.o a-tags.o a-teioed.o a-textio.o a-tgdico.o a-tiboio.o a-ticoau.o a-ticoio.o a-tideau.o a-tideio.o a-tienau.o a-tienio.o a-tifiio.o a-tiflau.o a-tiflio.o a-tigeau.o a-tiinau.o a-tiinio.o a-timoau.o a-timoio.o a-tiocst.o a-tirsfi.o a-titest.o a-tiunio.o a-unccon.o a-uncdea.o a-undesu.o a-wichha.o a-wichun.o a-widcha.o a-witeio.o a-wrstfi.o a-wtcoau.o a-wtcoio.o a-wtcstr.o a-wtdeau.o a-wtdeio.o a-wtedit.o a-wtenau.o a-wtenio.o a-wtfiio.o a-wtflau.o a-wtflio.o a-wtgeau.o a-wtinau.o a-wtinio.o a-wtmoau.o a-wtmoio.o a-wttest.o a-wwboio.o a-wwunio.o a-zchara.o a-zchhan.o a-zchuni.o a-zrstfi.o a-ztcoau.o a-ztcoio.o a-ztcstr.o a-ztdeau.o a-ztdeio.o a-ztedit.o a-ztenau.o a-ztenio.o a-ztexio.o a-ztfiio.o a-ztflau.o a-ztflio.o a-ztgeau.o a-ztinau.o a-ztinio.o a-ztmoau.o a-ztmoio.o a-zttest.o a-zzboio.o a-zzunio.o ada.o calendar.o directio.o g-arrspl.o g-awk.o g-bubsor.o g-busora.o g-busorg.o g-byorma.o g-bytswa.o g-calend.o g-casuti.o g-catiio.o g-cgi.o g-cgicoo.o g-cgideb.o g-comlin.o g-comver.o g-crc32.o g-ctrl_c.o g-curexc.o g-debpoo.o g-debuti.o g-decstr.o g-deutst.o g-diopit.o g-dirope.o g-dynhta.o g-dyntab.o g-encstr.o g-enutst.o g-excact.o g-except.o
[Bug c++/50986] weak static data members with constant initializers emitted in .rodata, leading to segfault on startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986 --- Comment #3 from Rafael Avila de Espindola rafael.espindola at gmail dot com --- In clang this was fixed by putting a .init_array section in the same comdat as the variable it is initializing. That way if the variable is dropped, so is the initialization code.
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #5 from marxin at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #4)
On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #2 from Martin Liška mliska at suse dot cz ---
Following two functions are merged:
static boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actorint,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor
right)
static boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor
right)
with following body:
{
struct type D.3826;
struct to_log_fun D.3825;
struct attribute_name D.3824;
int SR.9;
struct actor left;
bb 2:
left = left;
SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
MEM[(struct attribute_name *)D.3824] = SR.9_4;
boost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun::attribute_output_terminalint (D.3826, left,
D.3824,
D.3825, 0);
D.3826 ={v} {CLOBBER};
return;
}
As I was debugging ao_ref_alias_sets, there's MEM_REF where we have
different
template arguments: attribute_actorint,... vs.
attribute_actor{anonymous}::my_class,
What do you think Richard about these record_types from alias set
perspective:
(gdb) p debug_tree(t1)
mem_ref 0x76ab4000
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690
precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst
0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76aae678
type reference_type 0x76e20d20 type record_type 0x76de7dc8
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20d20
visited var parm_decl 0x76e1eb00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e3d8
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
$1 = void
(gdb) p debug_tree(t2)
mem_ref 0x76aa1ac8
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690
precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst
0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76a77dc8
type reference_type 0x76e20540 type record_type 0x76ddd888
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20540
visited var parm_decl 0x76e1ea00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e300
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
these types are called for alias_set comparison, with following
record_types:
(gdb) p debug_tree((tree_node*)0x76de7dc8)
record_type 0x76de7dc8 attribute_actor needs-constructing type_5
type_6
SI
size integer_cst 0x76c51048 type integer_type 0x76c33150
bitsizetype constant 32
unit size integer_cst 0x76c51060 type integer_type 0x76c330a8
sizetype constant 4
align 32 symtab 0 alias set 17 canonical type 0x76de7dc8
fields field_decl 0x76de4ed8 D.2798
type record_type 0x76dddb28 actor needs-constructing type_5
type_6
SI size integer_cst 0x76c51048 32 unit size integer_cst
0x76c51060
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587 --- Comment #6 from marxin at gcc dot gnu.org --- Created attachment 33794 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33794action=edit PR63587.patch
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #5 from marxin at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #4)
On Sun, 19 Oct 2014, mliska at suse dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #2 from Martin Liška mliska at suse dot cz ---
Following two functions are merged:
static boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actorint,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor
right)
static boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT =
boost::log::attribute_actor{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor
right)
with following body:
{
struct type D.3826;
struct to_log_fun D.3825;
struct attribute_name D.3824;
int SR.9;
struct actor left;
bb 2:
left = left;
SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
MEM[(struct attribute_name *)D.3824] = SR.9_4;
boost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun::attribute_output_terminalint (D.3826, left,
D.3824,
D.3825, 0);
D.3826 ={v} {CLOBBER};
return;
}
As I was debugging ao_ref_alias_sets, there's MEM_REF where we have
different
template arguments: attribute_actorint,... vs.
attribute_actor{anonymous}::my_class,
What do you think Richard about these record_types from alias set
perspective:
(gdb) p debug_tree(t1)
mem_ref 0x76ab4000
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690
precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst
0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76aae678
type reference_type 0x76e20d20 type record_type
0x76de7dc8
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20d20
visited var parm_decl 0x76e1eb00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e3d8
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
$1 = void
(gdb) p debug_tree(t2)
mem_ref 0x76aa1ac8
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690
precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst
0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738
arg 0 ssa_name 0x76a77dc8
type reference_type 0x76e20540 type record_type
0x76ddd888
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20540
visited var parm_decl 0x76e1ea00 rightdef_stmt GIMPLE_NOP
version 2
ptr-info 0x76a7e300
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
these types are called for alias_set comparison, with following
record_types:
(gdb) p debug_tree((tree_node*)0x76de7dc8)
record_type 0x76de7dc8 attribute_actor needs-constructing type_5
type_6
SI
size integer_cst 0x76c51048 type integer_type 0x76c33150
bitsizetype constant 32
unit size integer_cst 0x76c51060 type
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #4 from Volker Braun vbraun.name at gmail dot com ---
I got my hands on a gcc 4.9.1 binary build made on OSX 10.9 and this one works.
Diffing the log shows that this is due to different linker flags, my binary
build calls
libtool: link: gcc -std=gnu99 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libmpir.11.dylib [...]
whereas the Yosemite-bootstrapped gcc calls
libtool: link: gcc -std=gnu99 -dynamiclib -Wl,-flat_namespace -Wl,-undefined
-Wl,suppress -o .libs/libmpir.11.dylib [...]
Relinking with the previous linker flags fixes the segfault. This is most
likely due to incorrect aclocal.m4 case check
case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
_lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
10.[[012]]*)
_lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
${wl}suppress' ;;
not taking 10.10 properly into account.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- This has been fixed a long time ago.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #6 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #7 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #8 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #9 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #10 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #11 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #12 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #13 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #14 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #15 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #16 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #17 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #18 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #19 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #20 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #21 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #22 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #23 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #24 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #26 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #25 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #27 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #28 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #29 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #30 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #31 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #32 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #33 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #34 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #35 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #36 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #37 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #38 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #39 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #40 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #41 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #42 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #43 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #44 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #45 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #47 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #46 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug ipa/63580] [5 Regression] ICE : error: invalid argument to gimple call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580 --- Comment #2 from marxin at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) You miss to mark p1 addressable in the alias decl (that is, copy TREE_ADDRESSABLE). As I can see, ICF creates thunk to a localalias of foo. At which please I should preserve addressable attribute? Thanks, Martin
[Bug c++/63629] New: ICE in fix_loop_structure, at loop-init.c:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63629 Bug ID: 63629 Summary: ICE in fix_loop_structure, at loop-init.c:251 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.sm...@alcatel-lucent.com Created attachment 33795 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33795action=edit ice in fix_loop_structure, at loop-init.c:251 /tmp/gcc50-new/x86_64-wrs-vxworks/x86_64-unknown-linux-gnu/bin/gcc -B/tmp/gcc50-new/x86_64-wrs-vxworks/x86_64-unknown-linux-gnu/bin -xc++ -c bug.i -o /dev/null -m32 -w bug.i: In member function 'virtual void UnitTest::TestfltrLogTest_fltrLogIndicateTruncatedData_Normal::RunImpl() const': bug.i:231:4: internal compiler error: in fix_loop_structure, at loop-init.c:251 } reduced testcase generated by delta is attached.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #48 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #50 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #5 from Volker Braun vbraun.name at gmail dot com --- Libtool upstream patch: http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg2.html
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #49 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #51 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #52 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #53 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #54 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #55 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #56 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #57 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #58 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #59 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #60 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug other/62284] [4.8 Regression] AVR unable to find register to spill in the class POINTER_REGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62284 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Status|UNCONFIRMED |NEW Known to work||4.9.2 Keywords||ice-on-valid-code, ra Last reconfirmed||2014-10-23 Component|target |other CC||gjl at gcc dot gnu.org Blocks||56183 Ever confirmed|0 |1 Summary|AVR unable to find register |[4.8 Regression] AVR unable |to spill in the class |to find register to spill |POINTER_REGS|in the class POINTER_REGS --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- confirmed for 4.8
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #61 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #62 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #63 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #64 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/12742] Type alignment is lost if const is added to typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12742 --- Comment #65 from StaffLeavers at arm dot com --- william.munns no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
