[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 --- Comment #9 from Hale Wang --- Hi Tim, Your testcase is caused by the combine. It's not the same with Siarhei's test case. So I think we should divide your test case to another bug. And my patch is only used to fix the bug with your test case. So I will submit a new bug to record your comments. Thanks, Hale
[Bug middle-end/64766] [4.8/4.9/5 Regression] internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64766 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Jan 27 08:13:45 2015 New Revision: 220152 URL: https://gcc.gnu.org/viewcvs?rev=220152&root=gcc&view=rev Log: PR c/64766 * c-typeck.c (store_init_value): Don't overwrite DECL_INITIAL of FUNCTION_DECLs with error_mark_node. * gcc.dg/pr64766.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64766.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug libffi/64779] [5 Regression] libffi/src/x86/sysv.S:864: Error: junk at end of line, first unrecognized character is `@'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779 --- Comment #7 from Jakub Jelinek --- I guess the question is why the freebsd specific code (freebsd.S etc.) has been removed, if it is really not needed anymore, or if it got due to a mistake.
[Bug tree-optimization/64807] [5 Regression] Wrong-code because of wide-int division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64807 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Jan 27 08:26:13 2015 New Revision: 220153 URL: https://gcc.gnu.org/viewcvs?rev=220153&root=gcc&view=rev Log: PR tree-optimization/64807 * wide-int.cc (wi::divmod_internal): Clear b_dividend[dividend_blocks_needed]. * gcc.dg/pr64807.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64807.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/wide-int.cc
[Bug middle-end/64818] New: User specified register don't work correctly in inline-asm operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818
Bug ID: 64818
Summary: User specified register don't work correctly in
inline-asm operands.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Hale.Wang at arm dot com
Created attachment 34588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34588&action=edit
arm-none-eabi-gcc -O1 -S -o testcase.s testcase.c
The testcase is submitted by Tim Pambor in bug #46164. But it's actually not
the same bug with #46164. So I resubmitted the comments here.
Command: arm-none-eabi-gcc -O1 -S -o testcase.s testcase.c
The expected assembler code should be:
mov r4, .L_temp
mov r1, r4
...
mov r0, r0@ r0
mov r1, r1@ r1
mov r2, r2@ r2
But GCC combined the insns, and the code is generated as:
mov r4, .L_temp
...
mov r0, r0@ r0
mov r4, r4@ r1
mov r2, r2@ r2
Just "-O1" could reproduce this problem.
The combine pass combined the user specified registers into inline-asm
operation which caused this bug.
There are three insns which are related to the user specified register "r1":
(insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ]))
(insn 41 40 43 3 (set (reg/f:SI 148)(reg/v:SI 1 r1 [ b ]))
(insn 43 41 45 3 (parallel [
(set (reg/v:SI 0 r0 [ ret ])
(asm_operands/v:SI ("mov %2, %2 mov %3, %3 mov %4,
%4")
("=r") 0 [
(reg/v:SI 0 r0 [ a ])
(reg/v:SI 1 r1 [ b ])
(reg/v:SI 2 r2 [ c ])
(mem/c:QI (reg/f:SI 148) [0 MEM[(char *)&temp]+0 S1
A8])
The combine pass combine these insns as:
(note 98 97 40 3 NOTE_INSN_DELETED)
(note 41 40 43 3 NOTE_INSN_DELETED)
(insn 43 41 45 3 (parallel [
(set (reg/v:SI 0 r0 [ ret ])
(asm_operands/v:SI ("mov %2, %2 mov %3, %3 mov %4,
%4")
("=r") 0 [
(reg/v:SI 0 r0 [ a ])
(reg:SI 154 [ b ])
(reg/v:SI 2 r2 [ c ])
(mem/c:QI (reg:SI 154 [ b ]) [0 MEM[(char *)&temp]+0
S1 A8])
But actually 41+43 can be combined but 98+43 can not. Because if combining the
98+43, the user specified register will be replaced with a normal virtual
register reg 154. It's not the user expected behavior.
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #65 from Mikael Pettersson --- (In reply to Bernd Edlinger from comment #64) > (In reply to Mikael Pettersson from comment #63) > > The backport request has been posted: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02192.html > > OK, fine. > > If you want I can commit that for you now. Thanks, yes please do.
[Bug tree-optimization/64807] [5 Regression] Wrong-code because of wide-int division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64807 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug libstdc++/64819] New: [5 Regression] undefined symbol in libstdc++.so.6.0.21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64819 Bug ID: 64819 Summary: [5 Regression] undefined symbol in libstdc++.so.6.0.21 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: redi at gcc dot gnu.org Since r220143: nm /home/trippels/gcc_test/usr/local/lib64/libstdc++.so.6.0.21 | grep _ZNSt13__facet_shims21__numpunct_fill_cacheIcEEvSt17integral_constantIbLb1EEPKNSt6locale5facetEPSt16__numpunct_cacheIT_ERPKcRm U _ZNSt13__facet_shims21__numpunct_fill_cacheIcEEvSt17integral_constantIbLb1EEPKNSt6locale5facetEPSt16__numpunct_cacheIT_ERPKcRm
[Bug middle-end/64766] [4.8/4.9 Regression] internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64766 Jakub Jelinek changed: What|Removed |Added Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] |internal compiler error:|internal compiler error: |tree check: expected block, |tree check: expected block, |have error_mark in |have error_mark in |lower_function_body, at |lower_function_body, at |gimple-low.c:122|gimple-low.c:122 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/64805] Specific use of __attribute ((always_inline)) breaks MPX functionality with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805 Ilya Enkovich changed: What|Removed |Added CC||enkovich.gnu at gmail dot com --- Comment #2 from Ilya Enkovich --- This might be introduced by the recent changes in always_inline functions instrumentation. Now we keep them alive longer and therefore have inline of the original functionA into the original functionB. It causes error in a verifier because inliner clears all references and then calls cgraph node verification which expects IPA_REF_CHKP reference to instrumented functionB. I would like to keep IPA_REF_CHKP check in the verifier because this ref is important for reachability analysis. Thus we probably should rebuild IPA_REF_CHKP reference in inliner. Will tests this patch: diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c index c0ff329..d341619 100644 --- a/gcc/ipa-inline.c +++ b/gcc/ipa-inline.c @@ -2464,6 +2464,13 @@ early_inliner (function *fun) #endif node->remove_all_references (); + /* Rebuild this reference because it dosn't depend on + function's body and it's required to pass cgraph_node + verification. */ + if (node->instrumented_version + && !node->instrumentation_clone) +node->create_reference (node->instrumented_version, IPA_REF_CHKP, NULL); + /* Even when not optimizing or not inlining inline always-inline functions. */ inlined = inline_always_inline_functions (node);
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-27 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|compilation hangs at -O3|[5 Regression] compilation |with -g enabled on |hangs at -O3 with -g |x86_64-linux-gnu|enabled on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Startred with r211725, but seems to be yet another case of too costly simplify-rtx.c or too large RTL expression created, not sure which one it is yet.
[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #28 from rguenther at suse dot de --- On Tue, 27 Jan 2015, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 > > --- Comment #26 from amker at gcc dot gnu.org --- > (In reply to Richard Biener from comment #17) > > I really wonder why IVOPTs calls convert_affine_scev with > > !use_overflow_semantics. > I don't understand below code in convert_affine_scev: > > enforce_overflow_semantics = (use_overflow_semantics > && nowrap_type_p (type)); > According to comments, > >"USE_OVERFLOW_SEMANTICS is true if this function should assume that >the rules for overflow of the given language apply (e.g., that signed >arithmetics in C does not overflow) -- i.e., to use them to avoid > unnecessary >tests, but also to enforce that the result follows them." > > Seems to me we need to enforce overflow check for result if we take > advantage of USE_OVERFLOW_SEMANTICS to prove there is no overflow for > src. So shouldn't we set enforce_overflow_semantics according to > "nowrap_type_p (TREE_TYPE (*base))", rather than the result type. Yes, I also wondered about this... > Also it is noted at the end of function, that we can't use the fact > "signed variables do not overflow" when we are checking for result. > > But the function is used widespread in scev, there shouldn't be anything so > wrong. Heh - I wouldn't count on that. > > Note that for the original testcase 'i' may be negative or zero and thus 'd' > > may be zero. We do a bad analysis here because IVOPTs follows complete > > peeling immediately... but at least we have range information that looks > > useful: > > The case also holds for O2, at this level gcc won't completely unroll > the first loop. > > An irrelevant question. Isn't cunroll too aggressive in GCC? For cases > like this one, the code size is bloated and may hurt Icache performance, > while only saving several increment instruction. Yeah - it was Honza enabling this aggressive peeling. It makes sense for a limited amount of code growth (like peeling two iterations) but indeed using the same limit as for unrolling (where we know intermediate exits are not taken) doesn't make too much sense... I wonder if the size estimates are correctly handling that fact...
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org Summary|ICE at -O3 with -g enabled |[5 Regression] ICE at -O3 |on x86_64-linux-gnu (in |with -g enabled on |32-bit mode)|x86_64-linux-gnu (in 32-bit ||mode) --- Comment #3 from Jakub Jelinek --- I can't seem to reproduce this, even with valgrind. Line 5031 is: lattice[i] += lattice[gimple_uid (def_stmt)]; But adding a gcc_assert (gimple_bb (def_stmt) == bb); ICEs on this testcase, so the assumptions that we only TER inside bbs is apparently false, either due to some bug or intentionally so. In that case, either we need to fix that bug or change reorder_operands back to check gimple_bb (def_stmt) == bb in all 3 spots where reorder_operands calls get_gimple_for_ssa_name.
[Bug rtl-optimization/61058] [4.8/4.9/5 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Tue Jan 27 09:19:30 2015 New Revision: 220155 URL: https://gcc.gnu.org/viewcvs?rev=220155&root=gcc&view=rev Log: PR rtl-optimization/61058 * jump.c (cleanup_barriers): Update basic block boundaries if BLOCK_FOR_INSN is non-NULL on PREV. * gcc.dg/pr61058.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61058.c Modified: trunk/gcc/ChangeLog trunk/gcc/jump.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/64776] [5 Regression] FAIL: gcc.dg/ipa/pr64307.c (internal compiler error) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64776 --- Comment #16 from Jakub Jelinek --- Author: jakub Date: Tue Jan 27 09:21:26 2015 New Revision: 220156 URL: https://gcc.gnu.org/viewcvs?rev=220156&root=gcc&view=rev Log: PR ipa/64776 * cgraphunit.c (cgraph_node::expand_thunk): If not this_adjusting, handle the first argument in the same loop as all the other arguments. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug middle-end/64764] [5 Regression] internal compiler error: in is_value_included_in, at tree-ssa-uninit.c:942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64764 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/61058] [4.8/4.9 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058 Jakub Jelinek changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] ICE: |[4.8/4.9 Regression] ICE: |RTL check: expected elt 3 |RTL check: expected elt 3 |type 'B', have '0' (rtx |type 'B', have '0' (rtx |barrier) in |barrier) in |distance_agu_use_in_bb, at |distance_agu_use_in_bb, at |config/i386/i386.c:16740|config/i386/i386.c:16740 |with|with |__builtin_unreachable() |__builtin_unreachable() Known to fail|4.10.0 | --- Comment #11 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug sanitizer/64820] New: Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Bug ID: 64820 Summary: Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org 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, ygribov at gcc dot gnu.org Host: x86_64-pc-linux-gnu Target: i386-linux-gnu, arm-linux-gnueabi Created attachment 34589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34589&action=edit Simple reprocase If compile with both -fsanitize=address and -fstack-protector for 32-bit architectures and run with ASAN_OPTIONS=detect_stack_use_after_return=1, libsanitizer fails with: $ ~/install/master/bin/gcc -m32 -fsanitize=address -fstack-protector test.c $ ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out ==7299==AddressSanitizer CHECK failed: /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_poisoning.cc:25 "((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) #0 0xf72d8afc in AsanCheckFailed /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_rtl.cc:68 #1 0xf72dda89 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:72 #2 0xf72d39b1 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned char) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_poisoning.cc:25 #3 0xf7261e29 in __asan::SetShadow(unsigned long, unsigned long, unsigned long, unsigned long long) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:32 #4 0xf7261e29 in __asan::OnMalloc(unsigned long, unsigned long, unsigned long) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:198 #5 0xf7261e29 in __asan_stack_malloc_7 /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:230 #6 0x8048655 in foo (/tmp/a.out+0x8048655) #7 0x8048707 in main (/tmp/a.out+0x8048707) Simple reprocase is attached. This happens because size parameter is not aligned by 8 bytes (Granularity) here: $~/install/master/bin/gcc -m32 -fsanitize=address-fstack-protector test.c -o- -S ... cmpl$0, __asan_option_detect_stack_use_after_return je .L1 subl$8, %esp pushl %eax pushl $4188 // Aligned by 4 bytes. call__asan_stack_malloc_7 addl$16, %esp Perhaps we should emit some warning (error) in compile time to prevent the issue? $ ~/install/master/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/max/install/master/bin/gcc COLLECT_LTO_WRAPPER=/home/max/install/master/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap --enable-languages=c,c++ Thread model: posix gcc version 5.0.0 20150127 (experimental) (GCC)
[Bug ipa/64776] [5 Regression] FAIL: gcc.dg/ipa/pr64307.c (internal compiler error) on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64776 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jakub Jelinek --- Fixed.
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 --- Comment #4 from Markus Trippelsdorf --- Please note that the testcase is nondeterministic. That is also the reason why it is hard to reduce. You may need to run gcc several times to hit the bug.
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov --- > Perhaps we should emit some warning (error) in compile time > to prevent the issue? Or fix SSP to respect ASan stack requirements.
[Bug target/64821] New: [AArch64] Improve target folding for vsqrt_f64 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64821 Bug ID: 64821 Summary: [AArch64] Improve target folding for vsqrt_f64 intrinsic Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Following the implementation of vsqrt_f64 with a target builtin: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00699.html it was suggested to add some target folding code into a sqrt when -fno-math-errno is given: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00710.html This issue tracks that work that should be done for GCC 6
[Bug tree-optimization/56273] [4.8/4.9 regression] Bogus -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 Richard Biener changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 regression] |[4.8/4.9 regression] Bogus |Bogus -Warray-bounds|-Warray-bounds warning |warning | --- Comment #20 from Richard Biener --- Fixed in GCC 5. --- Comment #21 from Richard Biener --- Author: rguenth Date: Tue Jan 27 09:49:29 2015 New Revision: 220157 URL: https://gcc.gnu.org/viewcvs?rev=220157&root=gcc&view=rev Log: 2015-01-27 Richard Biener PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-12.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/56273] [4.8/4.9 regression] Bogus -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 Richard Biener changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 regression] |[4.8/4.9 regression] Bogus |Bogus -Warray-bounds|-Warray-bounds warning |warning | --- Comment #20 from Richard Biener --- Fixed in GCC 5. --- Comment #21 from Richard Biener --- Author: rguenth Date: Tue Jan 27 09:49:29 2015 New Revision: 220157 URL: https://gcc.gnu.org/viewcvs?rev=220157&root=gcc&view=rev Log: 2015-01-27 Richard Biener PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-12.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/59124] [4.8/4.9/5 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Jan 27 09:49:29 2015 New Revision: 220157 URL: https://gcc.gnu.org/viewcvs?rev=220157&root=gcc&view=rev Log: 2015-01-27 Richard Biener PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-12.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/64277] [4.9/5 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 --- Comment #14 from Richard Biener --- Author: rguenth Date: Tue Jan 27 09:49:29 2015 New Revision: 220157 URL: https://gcc.gnu.org/viewcvs?rev=220157&root=gcc&view=rev Log: 2015-01-27 Richard Biener PR tree-optimization/56273 PR tree-optimization/59124 PR tree-optimization/64277 * tree-vrp.c (vrp_finalize): Emit array-bound warnings only from the first VRP pass. * g++.dg/warn/Warray-bounds-6.C: New testcase. * gcc.dg/Warray-bounds-12.c: Likewise. * gcc.dg/Warray-bounds-13.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-6.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-12.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/64277] [4.9 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 Richard Biener changed: What|Removed |Added Known to work||5.0 Summary|[4.9/5 Regression] |[4.9 Regression] Incorrect |Incorrect warning "array|warning "array subscript is |subscript is above array|above array bounds" |bounds" | --- Comment #15 from Richard Biener --- Fixed in GCC 5.
[Bug libstdc++/64819] [5 Regression] undefined symbol in libstdc++.so.6.0.21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64819 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Markus Trippelsdorf --- Must have been local problem. I normally just "git update" gcc daily and then run "make" in my existing build dir (configured with --disable-bootstrap). This normally works fine. But apparently not for this libstdc++ change.
[Bug sanitizer/64741] Incorrect size of UBSan type descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 --- Comment #3 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Tue Jan 27 09:58:00 2015 New Revision: 220159 URL: https://gcc.gnu.org/viewcvs?rev=220159&root=gcc&view=rev Log: 2015-01-27 Jakub Jelinek Yury Gribov PR ubsan/64741 * ubsan.c (ubsan_source_location): Refactor code. (ubsan_type_descriptor): Update type size. Refactor code. Modified: trunk/gcc/ChangeLog trunk/gcc/ubsan.c
[Bug tree-optimization/64277] [4.9 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #16 from Richard Biener ---
(In reply to Ilya Enkovich from comment #13)
> Ranges have to be used for maxiter computations to have consistent analysis
> in complete unroll and vrp. Following patch allows to refine maxiter
> estimation using ranges and avoid warnings.
Looks good to me with...
> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
> index 919f5c0..14cce2a 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -2754,6 +2754,7 @@ record_nonwrapping_iv (struct loop *loop, tree base,
> tree step, gimple stmt,
> {
>tree niter_bound, extreme, delta;
>tree type = TREE_TYPE (base), unsigned_type;
> + tree orig_base = base;
>
>if (TREE_CODE (step) != INTEGER_CST || integer_zerop (step))
> return;
> @@ -2777,7 +2778,14 @@ record_nonwrapping_iv (struct loop *loop, tree base,
> tree step, gimple stmt,
>
>if (tree_int_cst_sign_bit (step))
> {
> + wide_int min, max, highwi = high;
>extreme = fold_convert (unsigned_type, low);
> + if (TREE_CODE (orig_base) == SSA_NAME
> + && !POINTER_TYPE_P (TREE_TYPE (orig_base))
test
INTEGRAL_TYPE_P (TREE_TYPE (orig_base))
instead
> + && SSA_NAME_RANGE_INFO (orig_base)
You can drop this check, get_range_info will return VR_VARYING.
> + && get_range_info (orig_base, &min, &max) == VR_RANGE
> + && wi::gts_p (highwi, max))
I think you can write
&& wi::gts_p (high.to_widest (), max))
and avoid the highwi temporary.
Similar changes below.
> + base = wide_int_to_tree (unsigned_type, max);
>if (TREE_CODE (base) != INTEGER_CST)
> base = fold_convert (unsigned_type, high);
>delta = fold_build2 (MINUS_EXPR, unsigned_type, base, extreme);
> @@ -2785,8 +2793,15 @@ record_nonwrapping_iv (struct loop *loop, tree base,
> tree step, gimple stmt,
> }
>else
> {
> + wide_int min, max, lowwi = low;
>extreme = fold_convert (unsigned_type, high);
> - if (TREE_CODE (base) != INTEGER_CST)
> + if (TREE_CODE (orig_base) == SSA_NAME
> + && !POINTER_TYPE_P (TREE_TYPE (orig_base))
> + && SSA_NAME_RANGE_INFO (orig_base)
> + && get_range_info (orig_base, &min, &max) == VR_RANGE
> + && wi::gts_p (min, lowwi))
> + base = wide_int_to_tree (unsigned_type, min);
> + else if (TREE_CODE (base) != INTEGER_CST)
> base = fold_convert (unsigned_type, low);
>delta = fold_build2 (MINUS_EXPR, unsigned_type, extreme, base);
> }
> diff --git a/gcc/testsuite/gcc.dg/pr64277.c b/gcc/testsuite/gcc.dg/pr64277.c
> new file mode 100644
> index 000..0d5ef11
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr64277.c
> @@ -0,0 +1,21 @@
> +/* PR tree-optimization/64277 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -Wall -Werror" } */
> +
> +
> +int f1[10];
> +void test1 (short a[], short m, unsigned short l)
> +{
> + int i = l;
> + for (i = i + 5; i < m; i++)
> +f1[i] = a[i]++;
> +}
> +
> +void test2 (short a[], short m, short l)
> +{
> + int i;
> + if (m > 5)
> +m = 5;
> + for (i = m; i > l; i--)
> +f1[i] = a[i]++;
> +}
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 --- Comment #5 from Jakub Jelinek --- Created attachment 34590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34590&action=edit gcc5-pr64809.patch IMHO in any case we should apply something like the attached patch, there is no point to even look at the debug stmts and TER really shouldn't make any guarantees for uses in debug stmts, those must be by definition ignored for TER purposes. Whether that is sufficient is another question.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #5 from Richard Biener --- Created attachment 34591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34591&action=edit patch Ok, so it was bogus to assume size_t would cover the largest alignment needed. Can test check the attached patch please?
[Bug libstdc++/64813] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #2 from Jonathan Wakely --- It's not a libstdc++ bug if it's an ICE.
[Bug tree-optimization/59124] [4.8/4.9/5 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #7 from Richard Biener --- The testcase in comment #2 is fixed for GCC 5 but the original testcase still warns.
[Bug tree-optimization/56273] [4.8/4.9 regression] Bogus -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #22 from Richard Biener --- Mine for backporting.
[Bug tree-optimization/64277] [4.9 Regression] Incorrect warning "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #17 from Richard Biener --- Mine for backporting.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #21 from Dominique d'Humieres --- > On x86_64-apple-darwin14, the failures are now reduced to... > FAIL: 22_locale/conversions/string/2.cc execution test > FAIL: 23_containers/unordered_map/requirements/explicit_instantiation/2.cc > (test for excess errors) > FAIL: 23_containers/unordered_map/requirements/explicit_instantiation/4.cc > (test for excess errors) > FAIL: 30_threads/shared_lock/cons/1.cc (test for excess errors) > ... Confirmed, thanks for the fix. The first failure is covered by pr64797, the 23_containers/* failures are covered by pr64813, and I'll open a new PR for the remaining ones ASAP. I am waiting for feedback from the other platforms before closing the PR as FIXED.
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812 Richard Biener changed: What|Removed |Added Target||i?86-*-* Known to work||4.8.2 Target Milestone|--- |4.9.3 Known to fail||4.9.0, 4.9.2
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #22 from Jonathan Wakely --- (In reply to howarth from comment #20) > On x86_64-apple-darwin14, the failures are now reduced to... > > FAIL: 22_locale/conversions/string/2.cc execution test PR 64797 > FAIL: 23_containers/unordered_map/requirements/explicit_instantiation/2.cc > (test for excess errors) > FAIL: 23_containers/unordered_map/requirements/explicit_instantiation/4.cc > (test for excess errors) PR 64813 > FAIL: 30_threads/shared_lock/cons/1.cc (test for excess errors) > FAIL: 30_threads/shared_lock/cons/2.cc (test for excess errors) > FAIL: 30_threads/shared_lock/cons/3.cc (test for excess errors) > FAIL: 30_threads/shared_lock/cons/4.cc (test for excess errors) > FAIL: 30_threads/shared_lock/locking/1.cc (test for excess errors) > FAIL: 30_threads/shared_lock/locking/2.cc (test for excess errors) > FAIL: 30_threads/shared_lock/modifiers/1.cc (test for excess errors) > FAIL: 30_threads/shared_lock/modifiers/2.cc (test for excess errors) > FAIL: 30_threads/shared_lock/requirements/explicit_instantiation.cc (test > for excess errors) > FAIL: 30_threads/shared_lock/requirements/typedefs.cc (test for excess > errors) > FAIL: 30_threads/shared_timed_mutex/cons/1.cc (test for excess errors) > FAIL: 30_threads/shared_timed_mutex/requirements/standard_layout.cc (test > for excess errors) > FAIL: 30_threads/shared_timed_mutex/try_lock/1.cc (test for excess errors) > FAIL: 30_threads/shared_timed_mutex/try_lock/2.cc (test for excess errors) Fixed by r220161 > FAIL: experimental/feat-cxx14.cc (test for excess errors) Maybe also fixed by r220161 --- Comment #23 from Jonathan Wakely --- Author: redi Date: Tue Jan 27 11:12:04 2015 New Revision: 220161 URL: https://gcc.gnu.org/viewcvs?rev=220161&root=gcc&view=rev Log: PR libstdc++/64368 * include/std/shared_mutex (shared_timed_mutex::try_lock_for, shared_timed_mutex::try_lock_until): Only define when POSIX thread timeouts option is supported. (shared_timed_mutex::try_shared_lock_for, shared_timed_mutex::try_shared_lock_until): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/shared_mutex
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > Created attachment 34590 [details] > gcc5-pr64809.patch > > IMHO in any case we should apply something like the attached patch, there is > no point to even look at the debug stmts and TER really shouldn't make any > guarantees for uses in debug stmts, those must be by definition ignored for > TER purposes. Whether that is sufficient is another question. Agreed.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #16 from Richard Biener ---
(In reply to Jonathan Wakely from comment #15)
> I think we need to get a suppression into valgrind:
>
> ==21268== Memcheck, a memory error detector
> ==21268== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==21268== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==21268== Command: ./a.out
> ==21268==
> ==21268==
> ==21268== HEAP SUMMARY:
> ==21268== in use at exit: 72,704 bytes in 1 blocks
> ==21268== total heap usage: 5,747 allocs, 5,746 frees, 822,784 bytes
> allocated
> ==21268==
> ==21268== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==21268==at 0x4A0645D: malloc (vg_replace_malloc.c:291)
> ==21268==by 0x4C990FF: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:117)
> ==21268==by 0x394940F2D9: call_init.part.0 (dl-init.c:82)
> ==21268==by 0x394940F3C2: _dl_init (dl-init.c:34)
> ==21268==by 0x3949401229: ??? (in /usr/lib64/ld-2.18.so)
> ==21268==
> ==21268== LEAK SUMMARY:
> ==21268==definitely lost: 0 bytes in 0 blocks
> ==21268==indirectly lost: 0 bytes in 0 blocks
> ==21268== possibly lost: 0 bytes in 0 blocks
> ==21268==still reachable: 72,704 bytes in 1 blocks
> ==21268== suppressed: 0 bytes in 0 blocks
> ==21268==
> ==21268== For counts of detected and suppressed errors, rerun with: -v
> ==21268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Or add a destructor.
Index: libstdc++-v3/libsupc++/eh_alloc.cc
===
--- libstdc++-v3/libsupc++/eh_alloc.cc (revision 220160)
+++ libstdc++-v3/libsupc++/eh_alloc.cc (working copy)
@@ -81,6 +81,7 @@ namespace
{
public:
pool();
+ ~pool();
void *allocate (std::size_t);
void free (void *);
@@ -240,6 +242,11 @@ namespace
&& p < arena + arena_size);
}
+ pool::~pool ()
+{
+ free (arena);
+}
+
pool emergency_pool;
}
[Bug libstdc++/64813] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-27 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Revision r219696 is OK, r219776 gives the ICE, likely r219737.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #17 from Jonathan Wakely --- Ah, I assumed the lack of destructor was intentional, so we can still deal with exceptions while destroying globals. Otherwise an exception could try to allocate from the pool after the destructor has run.
[Bug libstdc++/64781] regex out-of-range submatches should represent an unmatched sub-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64781 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-27 Ever confirmed|0 |1
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug libstdc++/64813] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64813 --- Comment #4 from Jonathan Wakely --- (In reply to Dominique d'Humieres from comment #3) > Revision r219696 is OK, r219776 gives the ICE, likely r219737. Unlikely, the only file changed by r219737 isn't even included in the failing tests, and even if it was would not define anything without -std=c++14. This is a compiler bug, not a library bug. The bug is the ICE, which is in the compiler.
[Bug libffi/64779] [5 Regression] libffi/src/x86/sysv.S:864: Error: junk at end of line, first unrecognized character is `@'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- (In reply to Jakub Jelinek from comment #7) > I guess the question is why the freebsd specific code (freebsd.S etc.) has > been removed, if it is really not needed anymore, or if it got due to a > mistake. Richard should be able to answer this: commit b21ec1ce783f09335c0e6c6f96ccc7e89da5a1b4 Author: Richard Henderson Date: Wed Nov 5 10:15:25 2014 +0100 x86: Rewrite closures Move everything into sysv.S, removing win32.S and freebsd.S. Handle all abis with a single ffi_closure_inner function. Move complexity of the raw THISCALL trampoline into assembly instead of the trampoline itself. Only push the context for the REGISTER abi; let the rest
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #18 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #17 from Jonathan Wakely --- Ah, I
> assumed the lack of destructor was intentional, so we can still deal
> with exceptions while destroying globals. Otherwise an exception could
> try to allocate from the pool after the destructor has run.
Well - technically accessing emergency_pool after its default destructor
ran is undefined (though we don't seem to run any destructor on it...
I wonder if we do for __scoped_lock and if that works).
I hope that initialization/destruction order imposed by some means
allows EH to be thrown during initialization or destruction (though
what would catch that?)
We can make the patch safer by using
pool::~pool ()
{
__gnu_cxx::__scoped_lock sentry(emergency_mutex);
free (arena);
arena = NULL;
}
and/or by attaching a init_priority to the class.
But again - where can you catch exceptions thrown from global
initializers / destructors? If I throw from a __thread global
constructor will the parent process be able to catch that exception
somehow?
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Jakub Jelinek --- > Created attachment 34573 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34573&action=edit > gcc5-pr64612.patch > > Lightly tested patch to do that (tested just on x86_64-linux). Worked for me. Tested on * Solaris 10/x86 (as/ld and gas/ld; no comdat in ld) * Solaris 10/x86 (gas/gld, comdat) * Solaris 11/x86 (as/ld and gas/ld; comdat in ld) The new comdat_group keyword needs documenting in sourcebuild.texi, though. Thanks. Rainer
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 Jakub Jelinek changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #19 from Jakub Jelinek --- I think a destructor is too risky here. Can't you just register with valgrind a pointer known not to be freed at exit? Would be nice to have something like __libc_freeres for libstdc++ too, that valgrind/mtrace/LeakSanitizer could invoke. I'm afraid tons of programs just do busy work in various threads until some thread exits the whole app, and your change could break it.
[Bug testsuite/64796] effective target bswap64 globally caches target-specific use of lp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64796
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #3 from H.J. Lu ---
(In reply to vries from comment #0)
> proc check_effective_target_bswap64 { } {
> global et_bswap64_saved
>
> if [info exists et_bswap64_saved] {
> verbose "check_effective_target_bswap64: using cached result" 2
> } else {
> set et_bswap64_saved 0
> if { [is-effective-target bswap]
> && [is-effective-target lp64] } {
>set et_bswap64_saved 1
> }
> }
>
> verbose "check_effective_target_bswap64: returning $et_bswap64_saved" 2
> return $et_bswap64_saved
> }
That is wrong for x32. X32 is ILP32 and should support bswap64.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
__BIGGEST_ALIGNMENT__ is unnecessarily large, e.g. on i?86-linux, it is 16,
while you only need to guarantee 8-byte alignment.
Isn't the bug just in the badalloc1.C testcase, if it provides its own malloc,
it should IMHO guarantee the system malloc alignments (generally, something
like alignment of
union U
{
long long ll;
double d;
long double ld;
void *p;
};
.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #20 from rguenther at suse dot de --- On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||mark at gcc dot gnu.org > > --- Comment #19 from Jakub Jelinek --- > I think a destructor is too risky here. > Can't you just register with valgrind a pointer known not to be freed at exit? > Would be nice to have something like __libc_freeres for libstdc++ too, that > valgrind/mtrace/LeakSanitizer could invoke. > I'm afraid tons of programs just do busy work in various threads until some > thread exits the whole app, and your change could break it. It indeed would free memory of in-flight exceptions. Which means that process termination in OOM situations might become interesting? OTOH we now leak with dlopen/dlclose of libstdc++.so (just consider doing that multiple times).
[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64817
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The problem is that expand_debug_expr follows all TER definitions for
SSA_NAMEs, and in this testcase it just creates really huge expression that we
then try to simplify, and nonzero_bits have bad time complexity for such large
expressions.
pretmp_33 = a;
a.1_6 = pretmp_33 & 231;
a.2_21 = a.1_6 ^ 14;
a.1_22 = a.2_21 & 231;
a.2_17 = a.1_22 ^ 14;
a.1_19 = a.2_17 & 231;
a.2_37 = a.1_19 ^ 14;
a.1_28 = a.2_37 & 231;
a.2_29 = a.1_28 ^ 14;
a.1_42 = a.2_29 & 231;
a.5_41 = a.1_42 ^ 15;
# DEBUG D#1 => a.5_41 < 0
# DEBUG e => (int) D#1
a.1_14 = a.5_41 & 231;
a.2_25 = a.1_14 ^ 14;
a.1_13 = a.2_25 & 231;
a.2_44 = a.1_13 ^ 14;
a.1_45 = a.2_44 & 231;
a.2_46 = a.1_45 ^ 14;
a.1_47 = a.2_46 & 231;
a.2_48 = a.1_47 ^ 14;
a.1_49 = a.2_48 & 231;
a.5_51 = a.1_49 ^ 15;
# DEBUG D#1 => a.5_51 < 0
# DEBUG e => (int) D#1
a.1_56 = a.5_51 & 231;
a.2_57 = a.1_56 ^ 14;
a.1_58 = a.2_57 & 231;
a.2_59 = a.1_58 ^ 14;
a.1_60 = a.2_59 & 231;
a.2_61 = a.1_60 ^ 14;
a.1_62 = a.2_61 & 231;
a.2_63 = a.1_62 ^ 14;
a.1_64 = a.2_63 & 231;
a.5_66 = a.1_64 ^ 15;
# DEBUG D#1 => a.5_66 < 0
# DEBUG e => (int) D#1
...
Best would be to limit somehow the number of nested:
case SSA_NAME:
{
gimple g = get_gimple_for_ssa_name (exp);
if (g)
{
op0 = expand_debug_expr (gimple_assign_rhs_to_tree (g));
if (!op0)
return NULL;
}
levels, perhaps by adding DEBUG_EXPR_DECLs to break too deep chains.
Supposedly it would need to be done at the end of TER or so,
simply for all debug stmts, look at the nesting depth of
get_gimple_for_ssa_name links from their expressions, and if it goes over say 5
or 10,
add some DEBUG_EXPR_DECLs and debug stmts for them right after the
corresponding SSA_NAME definitions and replace all debug uses of the SSA_NAME
with that DEBUG_EXPR_DECL.
Alex, what do you think about that?
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan --- My first line of attack would be checking that while building up the jit, the jit configury and build system is not using the --with-float=hard and --with-fpu=vfpv3-d16 configure time option in some manner.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Richard Biener --- > Created attachment 34591 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34591&action=edit > patch > > Ok, so it was bogus to assume size_t would cover the largest alignment > needed. > Can test check the attached patch please? Initial testing (just rebuilding libstdc++ and re-running the test) looked good. I'll fire off a full bootstrap for good measure, but that will take a bit. Thanks. Rainer
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #21 from Richard Biener ---
We can make it extra-safe but still deallocate in most common cases:
pool::~pool ()
{
__gnu_cxx::__scoped_lock sentry(emergency_mutex);
if (arena
&& arena == reinterpret_cast (first_free_entry)
&& arena_size == first_free_entry->size)
{
free (arena);
arena = NULL;
first_free_entry = NULL;
}
}
this ensures threads won't continue allocating from the pool. Well,
they may in case some other thread frees some exception... So indeed
running a destructor makes the whole stuff undefined (object lifetime
of the pool ended) :/
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #24 from Dominique d'Humieres --- > > ... > > FAIL: 30_threads/shared_timed_mutex/try_lock/2.cc (test for excess errors) > > Fixed by r220161 Confirmed. PR fixed before being opened!-) > > FAIL: experimental/feat-cxx14.cc (test for excess errors) > > Maybe also fixed by r220161 Yes. Remaining after r220161 PR 64797 and PR 64813.
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Both the compiler and libgccjit were configured with: --with-tune=cortex-a8 --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux on the configure command line. Perhaps some of these options are set for driver only (libgccjit presumably doesn't use any driver) and need to be passed explicitly to the compiler?
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #8 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #6 from Jakub Jelinek ---
> __BIGGEST_ALIGNMENT__ is unnecessarily large, e.g. on i?86-linux, it is 16,
> while you only need to guarantee 8-byte alignment.
> Isn't the bug just in the badalloc1.C testcase, if it provides its own malloc,
> it should IMHO guarantee the system malloc alignments (generally, something
> like alignment of
> union U
> {
> long long ll;
> double d;
> long double ld;
> void *p;
> };
> .
no, badalloc1.C provides __BIGGEST_ALIGNMENT__ aligned memory. The bug
is in the EH allocator which allocates the extra size_t entry aligned
but the EH object itself only size_t aligned. It's documented
that __attribute__((aligned)) aligns to the biggest type so using
__BIGGEST_ALIGNMENT__ looks correct here - this is also what malloc ()
guarantees for alignment, no? Do we have any other means of getting
the same alignment as malloc () provides?
Btw, it still wastes a lot less space than the previous allocator.
Bug in the patch anyway and the following hunk is also needed:
@@ -185,7 +186,7 @@ namespace
{
__gnu_cxx::__scoped_lock sentry(emergency_mutex);
allocated_entry *e = reinterpret_cast
- (reinterpret_cast (data) - sizeof (std::size_t));
+ (reinterpret_cast (data) - offsetof (allocated_entry,
data));
std::size_t sz = e->size;
if (!first_free_entry)
{
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #22 from Jakub Jelinek --- Can't you use a .bss object for the initial case, so you don't malloc anything in the ctor unless user requests something larger than that? That way "freeing" that would be handled in most cases. And I assume you really can't dlclose libstdc++ while other threads are handling exceptions, because then those libraries should use libstdc++ entry points and either would need to be dlclosed too, or libstdc++ wouldn't be really unmapped.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 Richard Biener changed: What|Removed |Added Attachment #34591|0 |1 is obsolete|| --- Comment #9 from Richard Biener --- Created attachment 34592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34592&action=edit updated patch Patch with missing hunk
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #10 from Jakub Jelinek --- __BIGGEST_ALIGNMENT__ has nothing to do with alignment of malloc returned memory. The union I've mentioned is a reasonable guess (something actually mandated by the standard), glibc right now guarantees 2 * sizeof (void *) (which is wrong for ppc32). For malloc alignment, we've added an attribute for that, but glibc maintainers haven't added it to their headers :( and obviously other libcs neither.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #23 from rguenther at suse dot de --- On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 > > --- Comment #22 from Jakub Jelinek --- > Can't you use a .bss object for the initial case, so you don't malloc anything > in the ctor unless user requests something larger than that? Is there a non-zeroed .bss section? I think using dynamically allocated memory might be cheaper. But sure - it was a .bss object previously (four actually). > That way "freeing" that would be handled in most cases. And I assume you > really can't dlclose libstdc++ while other threads are handling exceptions, > because then those libraries should use libstdc++ entry points and either > would > need to be dlclosed too, or libstdc++ wouldn't be really unmapped. Ok, so what's the real issue then with the destructor? Don't we destroy the global IO and locale stuff as well?
[Bug libffi/64799] [5 regression] libffi.special/unwindtest.cc FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64799 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Henderson --- > Created attachment 34583 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34583&action=edit > proposed patch > > That does seem likely. I tested this on linux; hopefully > I got all of the macroization right for solaris. Looks good so far: I've applied the patch, rebuilt libffi and run the libffi testsuite (both multilibs). I'll run a full bootstrap (both as and gas configurations) for good measure and check if the libjava failures are gone, too. Thanks. Rainer
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #11 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
>
> --- Comment #10 from Jakub Jelinek ---
> __BIGGEST_ALIGNMENT__ has nothing to do with alignment of malloc returned
> memory.
> The union I've mentioned is a reasonable guess (something actually mandated by
> the standard), glibc right now guarantees 2 * sizeof (void *) (which is wrong
> for ppc32). For malloc alignment, we've added an attribute for that, but
> glibc
> maintainers haven't added it to their headers :( and obviously other libcs
> neither.
I can drop __BIGGEST_ALIGNMENT__ and use alignof (allocated_entry::data)
which is aligned via __attribute__((aligned)) by the patch (same trick
that badalloc1.C uses). That attribute trick is documented as
"Alternatively, you can leave out the alignment factor
and just ask the compiler to align a variable or field to the
default alignment for the target architecture you are compiling for.
The default alignment is sufficient for all scalar types, but may not be
enough for all vector types on a target that supports vector operations.
The default alignment is fixed for a particular target ABI."
but then
"GCC also provides a target specific macro @code{__BIGGEST_ALIGNMENT__},
which is the largest alignment ever used for any data type on the
target machine you are compiling for."
and the following example suggests that the first doesn't necessarily
matches the second. Though testing on x86_64 reveals that
__attribute__((aligned)) aligns to 16 bytes as well.
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535 --- Comment #24 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #23) > Is there a non-zeroed .bss section? No. > I think using dynamically allocated > memory might be cheaper. I very much doubt it. > > That way "freeing" that would be handled in most cases. And I assume you > > really can't dlclose libstdc++ while other threads are handling exceptions, > > because then those libraries should use libstdc++ entry points and either > > would > > need to be dlclosed too, or libstdc++ wouldn't be really unmapped. > > Ok, so what's the real issue then with the destructor? Don't we destroy > the global IO and locale stuff as well? IO destruction is a huge can of worms, just look at some of the interesting glibc bugs. It is an area which is essentially unsolvable. Most other stuff isn't destructed by glibc at all, there is __libc_freeres exactly to make valgrind/mtrace etc. happy, but still not free otherwise.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #12 from Richard Biener --- Created attachment 34593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34593&action=edit further updated patch Ceases use of __BIGGEST_ALIGNMENT__.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #13 from Jakub Jelinek --- I think aligned attribute is similarly useless for this, I'd really go for testing alignments you need, rather than expecting some magic value. I'm not aware of any target that would have bigger alignment for say char/short/int/long than long long, ditto with float/double, so I'd just check maximum of long long, long double, void * alignment.
[Bug c++/64816] gcc claims that constructor is private when it should be accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816 Ville Voutilainen changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-27 CC||ville.voutilainen at gmail dot com Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.1, 5.0
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #25 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #18)
> But again - where can you catch exceptions thrown from global
> initializers / destructors?
Within those global constructors/destructors themselves:
struct Global {
~Global() {
try {
throw 1;
} catch (...) {
}
}
} global;
Anyway, we should probably use an init_priority for the pool, because as well
as an order of destruction problem it's possible for a global constructor to
try to use the pool, and that must not happen before it has been initialized by
the constructor.
[Bug libstdc++/64658] std::atomic_init() undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64658 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Jonathan Wakely --- fixed - probably not worth backporting since noone has noticed it's missing (and these functions only really exist because of the original plan for C compatibility, in C++ you can just use the constructor)
[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791 Ville Voutilainen changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-27 CC||paolo.carlini at oracle dot com, ||ville.voutilainen at gmail dot com Known to work||5.0 Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.1 --- Comment #3 from Ville Voutilainen --- Trunk accepts the code and prints 2, 3 like clang does. So unless there's a need for an additional testcase or a backport, this looks like a candidate for closing.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #14 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
>
> --- Comment #13 from Jakub Jelinek --- I
> think aligned attribute is similarly useless for this, I'd really go for
> testing alignments you need, rather than expecting some magic value.
> I'm not aware of any target that would have bigger alignment for say
> char/short/int/long than long long, ditto with float/double, so I'd just
> check maximum of long long, long double, void * alignment.
For the actual bug I can use __alignof__ (__cxa_refcounted_exception),
but that again ends up using __attribute__((__aligned__)) via the
_Unwind_Exception member:
struct _Unwind_Exception
{
_Unwind_Exception_Class exception_class;
_Unwind_Exception_Cleanup_Fn exception_cleanup;
#if !defined (__USING_SJLJ_EXCEPTIONS__) && defined (__SEH__)
_Unwind_Word private_[6];
#else
_Unwind_Word private_1;
_Unwind_Word private_2;
#endif
/* @@@ The IA-64 ABI says that this structure must be double-word
aligned.
Taking that literally does not make much sense generically. Instead
we
provide the maximum alignment required by any type for the machine.
*/
} __attribute__((__aligned__));
so I think that using __attribute__((__aligned__)) is very much the
correct and easiest thing to use.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 --- Comment #15 from Jakub Jelinek --- If _Unwind_Exception already uses it, sure. Sorry, didn't know that.
[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791 --- Comment #4 from Ville Voutilainen --- Oh, wait a minute, with trunk, I see an incorrect warning: prog.cc: In function 'int main()': prog.cc:7:15: warning: variable 'a' set but not used [-Wunused-but-set-variable] const int a = 2; ^
[Bug libstdc++/64535] Emergency buffer for exception allocation too small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #26 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #25 from Jonathan Wakely ---
> (In reply to rguent...@suse.de from comment #18)
> > But again - where can you catch exceptions thrown from global
> > initializers / destructors?
>
> Within those global constructors/destructors themselves:
>
> struct Global {
> ~Global() {
> try {
> throw 1;
> } catch (...) {
> }
> }
> } global;
>
> Anyway, we should probably use an init_priority for the pool, because as well
> as an order of destruction problem it's possible for a global constructor to
> try to use the pool, and that must not happen before it has been initialized
> by
> the constructor.
Of course that's broken in older releases as well because of the
emergency_mutex being dynamically constructed.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #25 from Jonathan Wakely --- Great, thanks for confirming it. As you say, let's leave this open for now in case HP or Rainer still sees some of these failures.
[Bug tree-optimization/64822] New: tree-ssa-sccvn miscompile union containing bitfield for big-endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64822
Bug ID: 64822
Summary: tree-ssa-sccvn miscompile union containing bitfield
for big-endian targets
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiwang at gcc dot gnu.org
given the following simple testcase,
union {
unsigned f0;
unsigned f1 : 24;
} const g_3983 = {1};
int main() {
printf("checksum = %08x\n", g_3983.f1);
}
on aarch64, or other target support big-endian, then
./cc1 -O2 -mbig-endian test.c
during tree-ssa-sccvn pass g_3983.f1 is evaluated into constant 1 while I think
it should be zero for big-endian.
[Bug tree-optimization/64822] tree-ssa-sccvn miscompile union containing bitfield for big-endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64822 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||thomas.preudhomme at arm dot com --- Comment #1 from Richard Biener --- This is fold_ctor_reference at work. I remember that somebody was working on fixing bugs in that or its caller related to bigendian bitfields...? Thomas? (refering to PR62103) The bug is exposed by my changes to more aggressively fold from constructors during value-numbering.
[Bug tree-optimization/64822] tree-ssa-sccvn miscompile union containing bitfield for big-endian targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64822 --- Comment #2 from Jiong Wang --- And I verified, the problem is here at least since 4.8
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #3 from David Malcolm --- (In reply to Jakub Jelinek from comment #2) > Both the compiler and libgccjit were configured with: > --with-tune=cortex-a8 --with-arch=armv7-a --with-float=hard > --with-fpu=vfpv3-d16 --with-abi=aapcs-linux > on the configure command line. Perhaps some of these options are set for > driver only (libgccjit presumably doesn't use any driver) and need to be > passed explicitly to the compiler? libgccjit *does* use the driver; the library runs toplev.c to generate a .s file, then invokes the driver to turn it into a .so file. It looks like there's some kind of mismatch between these two things. It looks like I'm going to need to get onto armvhl hw (or qemu) to investigate further. Jakub: BTW, the jit testsuite does extra-verbose logging, beyond jit.log; in particular the arguments for both of the invocations above are logged to: gcc/testsuite/jit/*.log.txt so if it's easy to hack up the specfile to stick these in the uuencoded logs, that might be beneficial.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #26 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #25) > Great, thanks for confirming it. As you say, let's leave this open for now > in case HP or Rainer still sees some of these failures. JFTR, for cris-elf at r220153, my autotester is now down to the following regressions since the start of the epoch (11 years ago): gcc.sum gcc.dg/tls/alias-1.c libstdc++.sum 28_regex/traits/char/isctype.cc libstdc++.sum 28_regex/traits/wchar_t/isctype.cc (all covered by other PR:s, the last two may be on your short list :-) Thanks!
[Bug middle-end/64421] Incorrect vector function name generated for log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64421 Andrew Senkevich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Senkevich --- Thank you!
[Bug jit/64780] toplevel configure should reject jit as a language if --enable-host-shared is not supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64780 --- Comment #1 from David Malcolm --- We seem to have two choices here: (A) default to --enable-host-shared when jit is an enabled language (B) have the toplevel configure reject jit as language if --enable-host-shared is not supplied. FWIW apparently Darwin defaults to position-independent code, so it's not explicitly needed there. That said, I think I prefer (B), since there is a performance cost: my thinking here is that there are people who perform benchmarking of GCC (and publish their results on prominent websites). If they turn on the jit and use the same configuration to do their benchmarking of the rest of GCC, they'll see GCC 5 be apparently slower than earlier releases. You're a gcc expert, and you ran into this issue, so it's clearly unreasonable to expect a 3rd-party reviewer to notice this detail on their own. So I'm thinking of implementing (B), and putting in a note in the error message recommending that people configure and build GCC twice to avoid the performance hit, so that it can be self-documenting.
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #4 from ramana.radhakrishnan at arm dot com --- On 27/01/15 12:27, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 > > Jakub Jelinek changed: > > What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek --- > Both the compiler and libgccjit were configured with: > --with-tune=cortex-a8 --with-arch=armv7-a --with-float=hard > --with-fpu=vfpv3-d16 --with-abi=aapcs-linux The --with-abi=aapcs-linux in addition to the --with-float=hard argument is just wrong. In fact it allows for a case where if the order of command line arguments passed to the compiler if in some way is wrong, the code generated will force the compiler into passing floating point parameters through the integer registers rather than fp registers which is what the --with-float=hard configure time option is doing. Really Fedora should remove this from the configure line as it only confuses people. For the compiler built can you please post back the output is for a simple function that adds 2 float values and pushes it back up. Ramana
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #1 from Jonathan Wakely --- I think the behaviour you're seeing is correct (and Clang gives the same result). The problem is that increments to the input iterator happen inside the copy_n call, to a copy of the iterator not to readIter itself. This means it is not equivalent to your for (int j = 0; j < 4; ++j) loop which operates directly on readIter. Each time through the outer loop the readIter variable has not been incremented, so has not cached the next element from the input stream.
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #2 from Anquietas --- (In reply to Jonathan Wakely from comment #1) > The problem is that increments to the input iterator happen inside > the copy_n call, to a copy of the iterator not to readIter itself. The copy_n implementation I provided produces the same behaviour as the for loop, even with copying the iterator.
[Bug testsuite/64796] effective target bswap64 globally caches target-specific use of lp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64796 --- Comment #4 from Andrew Pinski --- (In reply to H.J. Lu from comment #3) > That is wrong for x32. X32 is ILP32 and should support bswap64. And wrong for MIPS N32 and even AARCH64 ILP32. We need to special case those three targets. Even wrong for PowerPC with -mpowerpc64 enabled too.
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #3 from Jonathan Wakely --- Actually it's nothing to do with operating on a copy of the iterator, it's due to this in the implementation of copy_n: if (--__n > 0) ++__first; So as you observe we don't increment the input iterator on the last step. However, I don't see any requirement in the standard that says we're supposed to do so. All that is required is n assignments, there is no guarantee that the input range is also incremented past the last element written to. So I think you are assuming something that isn't actually guaranteed by the standard.
[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63889 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libffi/64779] [5 Regression] libffi/src/x86/sysv.S:864: Error: junk at end of line, first unrecognized character is `@'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779 --- Comment #9 from Richard Henderson --- (In reply to Jakub Jelinek from comment #7) > I guess the question is why the freebsd specific code (freebsd.S etc.) has > been removed, if it is really not needed anymore, or if it got due to a > mistake. freebsd.S and win32.S were merged with sysv.S. There were very few differences between them.
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #4 from Jonathan Wakely --- The current behaviour is decades old, coming from the copy_n in the SGI STL, and like the standard https://www.sgi.com/tech/stl/copy_n.html says nothing about postconditions for the input iterator. Note http://cplusplus.github.io/LWG/lwg-active.html#2242 though.
[Bug libffi/64779] [5 Regression] libffi/src/x86/sysv.S:864: Error: junk at end of line, first unrecognized character is `@'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64779 --- Comment #10 from Richard Henderson --- (In reply to H.J. Lu from comment #6) That will probably break small structure return. See case FFI_TYPE_STRUCT: #ifndef X86 /* ??? This should be a different ABI rather than an ifdef. */ if (cif->rtype->size == 1) flags = X86_RET_STRUCT_1B; else if (cif->rtype->size == 2) flags = X86_RET_STRUCT_2B; else if (cif->rtype->size == 4) flags = X86_RET_INT32; else if (cif->rtype->size == 8) flags = X86_RET_INT64; else #endif
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #5 from Anquietas --- (In reply to Jonathan Wakely from comment #3) > However, I don't see any requirement in the standard that says we're > supposed to do so. All that is required is n assignments, there is no > guarantee that the input range is also incremented past the last element > written to. The closest thing I could find to an up to date copy of the C++11 standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf copy_n is on page 851 "Effects: For each non-negative integer i < n, performs *(result + i) = *(first + i)." Since it's talking about input iterators where (first + n) isn't valid I think we can interpret this as n applications each of ++first and *first. I don't know whether the most recent version changed the description though; perhaps if you could provide a link?
[Bug middle-end/64809] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64809 Yuri Rumyantsev changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #7 from Yuri Rumyantsev --- I sent the patch with regression test for review.
[Bug libstdc++/64814] std::copy_n advances InputIterator one *less* time than necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64814 --- Comment #6 from Anquietas --- (In reply to Anquietas from comment #5) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf The working copy for C++14, page 902 has the same specification as the other PDF.
[Bug libobjc/63863] New warnings in libobjc due to the move over to GNU11 by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63863 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220175
[Bug ipa/64282] [5 Regression] ICE in gimple_get_virt_method_for_vtable, at gimple-fold.c:5635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64282 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Tue Jan 27 16:59:31 2015 New Revision: 220177 URL: https://gcc.gnu.org/viewcvs?rev=220177&root=gcc&view=rev Log: PR ipa/64282 * gimple-fold.c (gimple_get_virt_method_for_vtable): Remove assert on vtable being vtable. * g++.dg/torture/pr64282.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr64282.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
