[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 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Ick - that will also paper over good warnings so I'd rather not do that.
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 --- Comment #6 from torvald at gcc dot gnu.org --- We can keep it open, but my guess is that it would need some volunteer to actively drive the backporting process. I.e., with a patch and testing. Given that TM is experimental, I think backporting fixes for TM has low priority on most people's todo list.
[Bug c++/64755] Error in optimization with std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64755 --- Comment #5 from Alejandro Rivero Pérez nubcrack at yahoo dot es --- Yes, my bad, with no-strict-aliasing the code compiles OK and generate the desire output. After read more info about strict-aliasing that definitely is the problem, thanks for the help, sorry for the trouble.
[Bug target/64761] [4.9/5 Regression] -freorder-blocks-and-partition causes some failures on SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64761 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug testsuite/64796] New: effective target bswap64 globally caches target-specific use of lp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64796
Bug ID: 64796
Summary: effective target bswap64 globally caches
target-specific use of lp64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
1. unix/: supported
$ make -k -j5 -d check-gcc 'RUNTESTFLAGS=dg.exp=optimize-bswapdi-1.c -v -v
--target_board=unix/'
...
Schedule of variations:
unix/
Running target unix/
Running /home/vries/gcc_versions/devel/master/src/gcc/testsuite/gcc.dg/dg.exp
PASS: gcc.dg/optimize-bswapdi-1.c (test for excess errors)
PASS: gcc.dg/optimize-bswapdi-1.c scan-tree-dump-times bswap 64 bit bswap
implementation found at 3
...
2. unix/-m32: unsupported
$ make -k -j5 -d check-gcc 'RUNTESTFLAGS=dg.exp=optimize-bswapdi-1.c -v -v
--target_board=unix/-m32':
...
Schedule of variations:
unix/-m32
Running target unix/-m32
Running /home/vries/gcc_versions/devel/master/src/gcc/testsuite/gcc.dg/dg.exp
UNSUPPORTED: gcc.dg/optimize-bswapdi-1.c
...
3. unix/ unix/-m32: supported
$ make -k -j5 -d check-gcc 'RUNTESTFLAGS=dg.exp=optimize-bswapdi-1.c -v -v
--target_board=unix/\ unix/-m32'
...
Schedule of variations:
unix/
unix/-m32
Running target unix/
Running /home/vries/gcc_versions/devel/master/src/gcc/testsuite/gcc.dg/dg.exp
PASS: gcc.dg/optimize-bswapdi-1.c (test for excess errors)
PASS: gcc.dg/optimize-bswapdi-1.c scan-tree-dump-times bswap 64 bit bswap
implementation found at 3
Running target unix/-m32
Running /home/vries/gcc_versions/devel/master/src/gcc/testsuite/gcc.dg/dg.exp
PASS: gcc.dg/optimize-bswapdi-1.c (test for excess errors)
PASS: gcc.dg/optimize-bswapdi-1.c scan-tree-dump-times bswap 64 bit bswap
implementation found at 3
...
The bswap64 effective target is cached globally, so it caches the
target-specific use of lp64:
...
Return 1 if the target supports 64-bit byte swap instructions.
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
}
...
Note that the test passes with -m32, so maybe the effective target bswap64 is
not needed, or the wrong one.
[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[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
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-01-26
Ever confirmed|0 |1
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed btw. I believe we have plenty of dups of this report - it is usually
the last peeled iteration we warn for.
The interesting thing is that we have
# RANGE [1, 11] NONZERO 15
i_385 = i_369 + 1;
...
bb 52:
# RANGE [1, 11] NONZERO 15
i_461 = ASSERT_EXPR i_385, i_385 prephitmp_422;
...
bb 20:
# RANGE [0, 10] NONZERO 15
# i_82 = PHI i_461(52)
still we compute
i_461: [14, 32766] EQUIVALENCES: { i_385 } (1 elements)
so sth is bogus here (the above ranges are simply copied in unrolling
but that's ok - they are conservatively correct).
We should be able to rely on the previous ranges and use them to our advantage,
like with
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 220107)
+++ gcc/tree-vrp.c (working copy)
@@ -847,6 +847,23 @@ update_value_range (const_tree var, valu
value_range_t *old_vr;
bool is_new;
+ /* If there is a value-range on the SSA name from earlier analysis
+ factor that in. */
+ if (INTEGRAL_TYPE_P (TREE_TYPE (var)))
+{
+ wide_int min, max;
+ value_range_type rtype = get_range_info (var, min, max);
+ if (rtype == VR_RANGE || rtype == VR_ANTI_RANGE)
+ {
+ value_range_d nr;
+ nr.type = rtype;
+ nr.min = wide_int_to_tree (TREE_TYPE (var), min);
+ nr.max = wide_int_to_tree (TREE_TYPE (var), max);
+ nr.equiv = NULL;
+ vrp_intersect_ranges (new_vr, nr);
+ }
+}
+
/* Update the value range, if necessary. */
old_vr = get_value_range (var);
is_new = old_vr-type != new_vr-type
which cuts down the number of warnings to
t.c: In function 'foo':
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
a[i] = f1[i];
^
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
t.c:12:14: warning: 'f1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
f1[i] = f1[i] + 1;
^
from
t.c: In function 'foo':
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
a[i] = f1[i];
^
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
t.c:18:16: warning: array subscript is above array bounds [-Warray-bounds]
t.c:12:14: warning: 'f1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
f1[i] = f1[i] + 1;
^
[Bug libstdc++/64797] New: 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 Bug ID: 64797 Summary: 22_locale/conversions/string/2.cc FAILs Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* The new 22_locale/conversions/string/2.cc test FAILs on Solaris: Assertion failed: werr == woutput, file /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/22_locale/conversions/string/2.cc, line 49, function test01 Rainer
[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 #19 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) It's probably not correct to simply transfer range info from *idx to iv-base. Instead SCEV analysis needs to track the range of CHREC_LEFT when it analyzes the SSA use-def chain. That's of course a much bigger change :/ The patch may still help in some cases - I suppose the original testcase is reduced from sth else? Not sure if this is related to comment #c2 where the reference is to a 15% regression in bzip2 compress at O3. Sebastian could probably confirm. I don't think we can ignore the regression though, can we ? regards Ramana
[Bug libffi/64799] New: [5 regression] libffi.special/unwindtest.cc FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64799 Bug ID: 64799 Summary: [5 regression] libffi.special/unwindtest.cc FAILs on Solaris/SPARC Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rth at gcc dot gnu.org Host: *-*-solaris2.1[01] Target: *-*-solaris2.1[01] Build: *-*-solaris2.1[01] Since the libffi merge, two testcases FAIL on Solaris/SPARC when using Sun as, both for 32 and 64-bit: FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test FAIL: libffi.special/unwindtest_ffi_call.cc -shared-libgcc -lstdc++ execution test I'm also seeing a couple of libjava regressions that are almost certainly related: FAIL: noclass execution - gij test FAIL: pr11951 run FAIL: throwit execution - gij test FAIL: pr29812 execution - gij test FAIL: ExtraClassLoader execution - source compiled test FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test FAIL: ExtraClassLoader -O3 execution - source compiled test FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test FAIL: invokethrow execution - source compiled test FAIL: invokethrow -findirect-dispatch execution - source compiled test FAIL: invokethrow -O3 execution - source compiled test FAIL: invokethrow -O3 -findirect-dispatch execution - source compiled test I'm pretty sure that this happens because the merge lost the handcrafted .eh_frame sections, relying on .cfi_* directives that the native Solaris/SPARC assembler does not support. Rainer
[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 #21 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 26 Jan 2015, ramana at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #19 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) It's probably not correct to simply transfer range info from *idx to iv-base. Instead SCEV analysis needs to track the range of CHREC_LEFT when it analyzes the SSA use-def chain. That's of course a much bigger change :/ The patch may still help in some cases - I suppose the original testcase is reduced from sth else? Not sure if this is related to comment #c2 where the reference is to a 15% regression in bzip2 compress at O3. Sebastian could probably confirm. I don't think we can ignore the regression though, can we ? We should try not to.
[Bug ipa/64730] [5 Regression] g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64730 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34575 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34575action=edit gcc5-pr64730.patch I don't think there was anything wrong with the patch, just there is a problem that a non-NULL edge-call_stmt necessarily doesn't mean the call has a known location.
[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 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jan 26 14:50:03 2015 New Revision: 220111 URL: https://gcc.gnu.org/viewcvs?rev=220111root=gccview=rev Log: 2015-01-26 Richard Biener rguent...@suse.de PR middle-end/64764 * tree-ssa-uninit.c (is_pred_expr_subset_of): Handle combining two BIT_AND_EXPR predicates. * gcc.dg/uninit-19.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/uninit-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #6) I think that it should be reopened as a placeholder. Alright, let's reopen for the sake of the discussion I suspect that removing the inheritance information is not the right way to go. I should have explained better. I removed code that was touching some_derived_type_symbol-f2k_derived-sym_root, which was never used. The inheritance information is still present, through the type of the first component of an extended type. I don't think it is related to the patch I committed, because 4.9 also gives the wrong result.
[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 #12 from Ilya Enkovich enkovich.gnu at gmail dot com --- (In reply to Richard Biener from comment #10) Ick - that will also paper over good warnings so I'd rather not do that. I'm also worried about possible good warnings removal. Thus I disable them only in case cunroll speculates about iterations number and never disable them for the first loop iteration. I agree warnings disabling looks like a workaround. But it doesn't seem correct to complain on code generated by compiler and probably never executed. Each time maxiter is used for complete unroll following optimizations may improve maxiter estimation and thus we get a compiler generated dead code which still may produce warnings.
[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765 --- Comment #15 from Rainer Orth ro at gcc dot gnu.org --- I've never received comments on my alternative patch. Either that one, which I prefer since it's cleaner) or the previous one (ugly and target-specific), needs to be applied to have AIX bootstrap, I believe. What should we do? Rainer
[Bug tree-optimization/64739] Spurious array subscript is above array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64739 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #2 from Igor Zamyatin izamyatin at gmail dot com --- Looks quite similar to PR64277
[Bug libstdc++/64798] New: [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 Bug ID: 64798 Summary: [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Between 20150116 (r219745) and 20150123 (r220039), g++.old-deja/g++.eh/badalloc1.C started to FAIL on 32-bit Solaris/SPARC: FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++11 execution test FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++14 execution test FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++98 execution test Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] __cxxabiv1::__cxa_throw (obj=0x2195c arena+92, tinfo=0x73908 typeinfo for int, dest=0x0) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76 76 __GXX_INIT_PRIMARY_EXCEPTION_CLASS(header-exc.unwindHeader.exception_class); 1: x/i $pc = 0xff220314 __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))+96:sttw %g2, [ %i0 + -24 ] (gdb) where #0 __cxxabiv1::__cxa_throw (obj=0x2195c arena+92, tinfo=0x73908 typeinfo for int, dest=0x0) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76 #1 0x0004 in fn_throw () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:98 #2 0x000112f8 in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:129 (gdb) p $i0-24 $3 = 137540 The SEGV happens because the sttw target needs to be 8-byte aligned, but is not. Rainer
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/64802] New: [ARM] Selecting an -mcpu or -march that supports only one of ARM/Thumb should default to the ISA that *is* supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64802 Bug ID: 64802 Summary: [ARM] Selecting an -mcpu or -march that supports only one of ARM/Thumb should default to the ISA that *is* supported Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target: arm* Currently for an arm-none-eabi-gcc configured with --with-fpu=neon-fp-armv8 --with-arch=armv8-a (or any configuration I suspect) if I try to compile something with -mcpu=cortex-m3 I get an error: pc.c:1:0: error: target CPU does not support ARM mode int main(void) ^ It only works if I add an -mthumb to the command line. I think this is unhelpful. If a given -march or -mcpu doesn't support ARM mode then the compilation should default to Thumb code generation that the architecture supports unless the user explicitly specifies -marm (in which case we should error out). This would need some reorg in the way TARGET_ARM and TARGET_THUMB are defined through arm.opt and perhaps arm_option_override
[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 #22 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 26 Jan 2015, amker at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #20 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) It's probably not correct to simply transfer range info from *idx to iv-base. Instead SCEV analysis needs to track the range of CHREC_LEFT when it analyzes the SSA use-def chain. That's of course a much bigger change :/ The patch may still help in some cases - I suppose the original testcase is reduced from sth else? I see it's a tricky problem, and I have to admit that I don't understand it very well yet. The question is, is relax of POINTER_PLUS_EXPR constraint the right way fixing this? I do remember some other PRs (other than this one or bug 52563) are caused by this constraint according to your comments. Well, it's not sure that relaxing POINTER_PLUS_EXPR will help in the end... Of course, take range information into consideration is always an improvement. Actually I have another possible example in iv elimination. Curently GCC simply rejects elimination of an iv use with a candidate if the cand is of smaller type, but as long as we can prove value of iv use can be represented by the smaller candidate, elimination is actually safe. But seems to me, fixing this issue with value information is like a side-effect? Might be - but it's a matter of fixing the observable regression ;)
[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482 --- Comment #11 from torvald at gcc dot gnu.org --- Thanks for confirming. However, that fails before libitm, for which you should file a separate bug report. Thanks.
[Bug middle-end/64592] [5 regression] tramp3d EH unwind tables are 50% bigger with mainline compared to GCC 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64592 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- What binutils version do you have out of interest?
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34573 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34573action=edit gcc5-pr64612.patch Lightly tested patch to do that (tested just on x86_64-linux).
[Bug target/64795] [5.0 regression x86_64] too many memory references for `lea'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64795 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Target||x86_64-*-* Component|lto |target Target Milestone|--- |5.0
[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 #8 from Ilya Enkovich enkovich.gnu at gmail dot com --- Created attachment 34569 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34569action=edit patch to disable warnings for array references generated by cunroll
[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 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 torvald at gcc dot gnu.org changed: What|Removed |Added Version|5.0 |4.9.1 --- Comment #7 from torvald at gcc dot gnu.org --- Changed version to 4.9.1.
[Bug fortran/64771] [4.9/5 Regression] ICE(segfault) when passing coarrays around; ICE in gfc_zero_size_array in arith.c:1637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64771 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r197922.
[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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- What errors do you get on echo '.text; foo: nop; .data; .long foo-.; .text' conftest.s gcc -c conftest.s (i.e. why HAVE_AS_X86_PCREL isn't defined for you)?
[Bug middle-end/64421] Incorrect vector function name generated for log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64421 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-26 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34570 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34570action=edit gcc5-pr64421.patch Untested fix.
[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect Alignment of access forced using peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63439 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Rainer Orth ro at gcc dot gnu.org --- Done now.
[Bug testsuite/64796] effective target bswap64 globally caches target-specific use of lp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64796 vries at gcc dot gnu.org changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #1 from vries at gcc dot gnu.org --- cc-ing author
[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-26 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment 1 marked as NEW. On x86_64-apple-darwin14, I see the segmentation fault with -m32 only and it depends on the version, optimization level, and the state of the machine (erratic fault).
[Bug bootstrap/64754] [5 Regression] bootstrap failed with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jan 26 12:47:20 2015 New Revision: 220108 URL: https://gcc.gnu.org/viewcvs?rev=220108root=gccview=rev Log: Initialize ruid in new_var_info PR bootstrap/64754 * tree-ssa-structalias.c (new_var_info): Initialize ruid. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug bootstrap/64754] [5 Regression] bootstrap failed with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug libffi/64799] [5 regression] libffi.special/unwindtest.cc FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64799 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #2 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 26 Jan 2015, Richard Biener wrote:
On Mon, 26 Jan 2015, ro at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
Bug ID: 64798
Summary: [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
Build: sparc*-sun-solaris2.*
Between 20150116 (r219745) and 20150123 (r220039),
g++.old-deja/g++.eh/badalloc1.C
started to FAIL on 32-bit Solaris/SPARC:
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++11 execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++98 execution test
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
__cxxabiv1::__cxa_throw (obj=0x2195c arena+92,
tinfo=0x73908 typeinfo for int, dest=0x0)
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76
76
__GXX_INIT_PRIMARY_EXCEPTION_CLASS(header-exc.unwindHeader.exception_class);
1: x/i $pc
= 0xff220314 __cxxabiv1::__cxa_throw(void*, std::type_info*, void
(*)(void*))+96:sttw %g2, [ %i0 + -24 ]
(gdb) where
#0 __cxxabiv1::__cxa_throw (obj=0x2195c arena+92,
tinfo=0x73908 typeinfo for int, dest=0x0)
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76
#1 0x0004 in fn_throw ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:98
#2 0x000112f8 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:129
(gdb) p $i0-24
$3 = 137540
The SEGV happens because the sttw target needs to be 8-byte aligned, but is
not.
Does malloc return 8-byte aligned memory? Is __alignof__
struct free_entry {
std::size_t size;
free_entry *next;
};
less than 8?
Ah - the issue might be that g++.old-deja/g++.eh/badalloc1.C does
extern C void *malloc (size_t size)
{
object *p = reinterpret_castobject *(arena[pos]);
if (fail)
return 0;
p-size = size;
size = (size + __alignof__(object) - 1) - __alignof__(object);
pos += size + sizeof(object);
thus it aligns to 'object' but 'object' is
struct object
{
size_t size __attribute__((aligned));
};
Richard
[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 #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 34576 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34576action=edit pr64307.c.050i.whole-program for --enable-checking=release build Can you attach preprocessed source or say -fdump-ipa-whole-program-all -fdump-ipa-icf-all dumps from the --enable-checking=release build? pr64307.c.050i.whole-program for --enable-checking=release build.
[Bug target/64795] [5 regression] too many memory references for `lea'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64795
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-01-26
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Ever confirmed|0 |1
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
The failed insn is:
#(insn 8 6 13 2 (set (mem/f/j/c:DI (symbol_ref:DI (_ZZ4mainE1a) [flags 0x2]
var_decl 0x7fe4d00f2900 a) [0 a.pf+0 S8 A64])
#(symbol_ref:DI (_ZL3fn21s) [flags 0x3] function_decl 0x7fe4d02dd0d8
fn2)) t.ii:10 89 {*movdi_internal}
# (nil))
leaq_ZL3fn21s(%rip), _ZZ4mainE1a(%rip)# 8*movdi_internal/6
[length = 8]
Patch that tightens lea constraints in testing:
Index: i386.md
===
--- i386.md (revision 220092)
+++ i386.md (working copy)
@@ -2208,7 +2208,8 @@
(const_string ssecvt)
(eq_attr alternative 21,22,23,24)
(const_string mskmov)
- (match_operand 1 pic_32bit_operand)
+ (and (match_operand 0 register_operand)
+(match_operand 1 pic_32bit_operand))
(const_string lea)
]
(const_string imov)))
@@ -2361,7 +2362,8 @@
(const_string ssemov)
(eq_attr alternative 13,14)
(const_string mskmov)
- (match_operand 1 pic_32bit_operand)
+ (and (match_operand 0 register_operand)
+(match_operand 1 pic_32bit_operand))
(const_string lea)
]
(const_string imov)))
[Bug ipa/64801] [5 Regression] kernel build failure due to ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64801
--- Comment #1 from Martin Liška marxin at gcc dot gnu.org ---
You are right, the problem is hidden in cooperation between IPA inliner and
ICF.
If I run the test w/o ICF, inliner sets NULL to the fsp_detect FUNCTION_DECL:
#0 0x0074541e in symtab_node::unregister (this=0x76c47620) at
../../gcc/symtab.c:407
#1 0x0074b0ef in cgraph_node::remove (this=0x76c47620) at
../../gcc/cgraph.c:1741
#2 0x00b891b9 in expand_call_inline (id=0x7fffd5c0,
stmt=0x76d54aa0, bb=optimized out)
at ../../gcc/tree-inline.c:4762
#3 gimple_expand_calls_inline (id=0x7fffd5c0, bb=optimized out) at
../../gcc/tree-inline.c:4787
so that cgraph_node::get(decl) == NULL here:
if (symtab-state != LTO_STREAMING)
│1784{
B+│1785 n = cgraph_node::get (decl);
│1786 if (!n
│1787 || (!n-clones !n-clone_of !n-global.inlined_to
│1788 (symtab-global_info_ready
│1789 (TREE_ASM_WRITTEN (n-decl)
│1790 || DECL_EXTERNAL (n-decl)
│1791 || !n-analyzed
│1792 || (!flag_wpa n-in_other_partition)
│1793release_body ();
│1794}
That's the reason why the body is not removed. On the contrary, with ICF,
aforementioned condition is satisfied and fsp_detect's body is removed.
I think the situation after IPA ICF is correct:
fsp_detect/2 (fsp_detect) @0x76c47620
Type: function definition analyzed
Visibility: external public
References:
Referring:
Availability: available
First run: 0
Function flags: body
Called by: elantech_detect/1 (1.00 per call) psmouse_extensions/3 (1.00 per
call)
Calls:
elantech_detect/1 (elantech_detect) @0x76c47498
Type: function definition analyzed
Visibility: externally_visible public
References:
Referring:
Availability: available
First run: 0
Function flags: body icf_merged
Called by:
Calls: fsp_detect/2 (1.00 per call)
Can you please help me Honza?
Thanks,
Martin
[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 #9 from Martin Liška marxin at gcc dot gnu.org --- May I please Dominique to put 'debug_tree(arg);' after following statement: error (invalid argument to gimple call); And send the stderr output? Thanks, Martin
[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 #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- May I please Dominique to put 'debug_tree(arg);' after following statement: error (invalid argument to gimple call); And send the stderr output? /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c: In function 'real_part': /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: error: invalid argument to gimple call } ^ parm_decl 0x14315e280 a type complex_type 0x14315cdc8 COMPLEX_FLOAT type real_type 0x1430203f0 float sizes-gimplified SF size integer_cst 0x143001ee8 constant 32 unit size integer_cst 0x143001f00 constant 4 align 32 symtab 0 alias set -1 canonical type 0x1430203f0 precision 32 pointer_to_this pointer_type 0x1430205e8 sizes-gimplified SC size integer_cst 0x143001ca8 constant 64 unit size integer_cst 0x143001cc0 constant 8 align 32 symtab 0 alias set -1 canonical type 0x143020d20 context translation_unit_decl 0x1421753c0 D.2108 pointer_to_this pointer_type 0x14315f0a8 used SC file /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c line 9 col 38 size integer_cst 0x143001ca8 64 unit size integer_cst 0x143001cc0 8 align 32 context function_decl 0x143158a20 real_part arg-type complex_type 0x14315cdc8 COMPLEX_FLOAT a # .MEM_2 = VDEF .MEM_1(D) retval.0_3 = real_part_2 (a); [tail call] /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: internal compiler error: verify_gimple failed --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c: In function 'real_part': /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: error: invalid argument to gimple call } ^ parm_decl 0x14315e280 a type complex_type 0x14315cdc8 COMPLEX_FLOAT type real_type 0x1430203f0 float sizes-gimplified SF size integer_cst 0x143001ee8 constant 32 unit size integer_cst 0x143001f00 constant 4 align 32 symtab 0 alias set -1 canonical type 0x1430203f0 precision 32 pointer_to_this pointer_type 0x1430205e8 sizes-gimplified SC size integer_cst 0x143001ca8 constant 64 unit size integer_cst 0x143001cc0 constant 8 align 32 symtab 0 alias set -1 canonical type 0x143020d20 context translation_unit_decl 0x1421753c0 D.2108 pointer_to_this pointer_type 0x14315f0a8 used SC file /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c line 9 col 38 size integer_cst 0x143001ca8 64 unit size integer_cst 0x143001cc0 8 align 32 context function_decl 0x143158a20 real_part arg-type complex_type 0x14315cdc8 COMPLEX_FLOAT a # .MEM_2 = VDEF .MEM_1(D) retval.0_3 = real_part_2 (a); [tail call] /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: internal compiler error: verify_gimple failed Le 26 janv. 2015 à 17:04, marxin at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org a écrit : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64776 --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- May I please Dominique to put 'debug_tree(arg);' after following statement: error (invalid argument to gimple call); And send the stderr output? Thanks, Martin -- You are receiving this mail because: You reported the bug.
[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 #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- May I please Dominique to put 'debug_tree(arg);' after following statement: error (invalid argument to gimple call); And send the stderr output? /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c: In function 'real_part': /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: error: invalid argument to gimple call } ^ parm_decl 0x14315e280 a type complex_type 0x14315cdc8 COMPLEX_FLOAT type real_type 0x1430203f0 float sizes-gimplified SF size integer_cst 0x143001ee8 constant 32 unit size integer_cst 0x143001f00 constant 4 align 32 symtab 0 alias set -1 canonical type 0x1430203f0 precision 32 pointer_to_this pointer_type 0x1430205e8 sizes-gimplified SC size integer_cst 0x143001ca8 constant 64 unit size integer_cst 0x143001cc0 constant 8 align 32 symtab 0 alias set -1 canonical type 0x143020d20 context translation_unit_decl 0x1421753c0 D.2108 pointer_to_this pointer_type 0x14315f0a8 used SC file /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c line 9 col 38 size integer_cst 0x143001ca8 64 unit size integer_cst 0x143001cc0 8 align 32 context function_decl 0x143158a20 real_part arg-type complex_type 0x14315cdc8 COMPLEX_FLOAT a # .MEM_2 = VDEF .MEM_1(D) retval.0_3 = real_part_2 (a); [tail call] /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: internal compiler error: verify_gimple failed --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c: In function 'real_part': /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: error: invalid argument to gimple call } ^ parm_decl 0x14315e280 a type complex_type 0x14315cdc8 COMPLEX_FLOAT type real_type 0x1430203f0 float sizes-gimplified SF size integer_cst 0x143001ee8 constant 32 unit size integer_cst 0x143001f00 constant 4 align 32 symtab 0 alias set -1 canonical type 0x1430203f0 precision 32 pointer_to_this pointer_type 0x1430205e8 sizes-gimplified SC size integer_cst 0x143001ca8 constant 64 unit size integer_cst 0x143001cc0 constant 8 align 32 symtab 0 alias set -1 canonical type 0x143020d20 context translation_unit_decl 0x1421753c0 D.2108 pointer_to_this pointer_type 0x14315f0a8 used SC file /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c line 9 col 38 size integer_cst 0x143001ca8 64 unit size integer_cst 0x143001cc0 8 align 32 context function_decl 0x143158a20 real_part arg-type complex_type 0x14315cdc8 COMPLEX_FLOAT a # .MEM_2 = VDEF .MEM_1(D) retval.0_3 = real_part_2 (a); [tail call] /opt/gcc/_clean/gcc/testsuite/gcc.dg/ipa/pr64307.c:28:1: internal compiler error: verify_gimple failed Le 26 janv. 2015 à 17:04, marxin at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org a écrit : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64776 --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- May I please Dominique to put 'debug_tree(arg);' after following statement: error (invalid argument to gimple call); And send the stderr output? Thanks, Martin -- You are receiving this mail because: You reported the bug.
[Bug ipa/64801] [5 Regression] kernel build failure due to ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64801 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[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 #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Sorry for the duplicate comments 5 and 6. Bugzilla is very slow and I got a confusing message about gateway timed out.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #1 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 26 Jan 2015, ro at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
Bug ID: 64798
Summary: [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
Build: sparc*-sun-solaris2.*
Between 20150116 (r219745) and 20150123 (r220039),
g++.old-deja/g++.eh/badalloc1.C
started to FAIL on 32-bit Solaris/SPARC:
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++11 execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C -std=c++98 execution test
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
__cxxabiv1::__cxa_throw (obj=0x2195c arena+92,
tinfo=0x73908 typeinfo for int, dest=0x0)
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76
76
__GXX_INIT_PRIMARY_EXCEPTION_CLASS(header-exc.unwindHeader.exception_class);
1: x/i $pc
= 0xff220314 __cxxabiv1::__cxa_throw(void*, std::type_info*, void
(*)(void*))+96:sttw %g2, [ %i0 + -24 ]
(gdb) where
#0 __cxxabiv1::__cxa_throw (obj=0x2195c arena+92,
tinfo=0x73908 typeinfo for int, dest=0x0)
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:76
#1 0x0004 in fn_throw ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:98
#2 0x000112f8 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.eh/badalloc1.C:129
(gdb) p $i0-24
$3 = 137540
The SEGV happens because the sttw target needs to be 8-byte aligned, but is
not.
Does malloc return 8-byte aligned memory? Is __alignof__
struct free_entry {
std::size_t size;
free_entry *next;
};
less than 8?
Thanks,
Richard.
[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 jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you attach preprocessed source or say -fdump-ipa-whole-program-all -fdump-ipa-icf-all dumps from the --enable-checking=release build?
[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 #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 34578 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34578action=edit pr64307.c.052i.icf for --enable-checking=release build Can you attach preprocessed source or say -fdump-ipa-whole-program-all -fdump-ipa-icf-all dumps from the --enable-checking=release build? pr64307.c.052i.icf for --enable-checking=release build.
[Bug libstdc++/64798] [5 regression] g++.old-deja/g++.eh/badalloc1.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #1 from rguenther at suse dot de rguenther at suse dot de ---
[...]
Does malloc return 8-byte aligned memory? Is __alignof__
It does, according to libc sources exactly for the case at hand:
* Alignment (ALIGN) changed to 8 for SPARC ldd/std.
struct free_entry {
std::size_t size;
free_entry *next;
};
less than 8?
Yup: 4 in the (failing) 32-bit case.
Rainer
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 --- Comment #4 from janus at gcc dot gnu.org --- Author: janus Date: Mon Jan 26 15:56:03 2015 New Revision: 220125 URL: https://gcc.gnu.org/viewcvs?rev=220125root=gccview=rev Log: 2015-01-26 Janus Weil ja...@gcc.gnu.org PR fortran/64230 * class.c (finalize_component): New argument 'sub_ns'. Insert code to check if 'expr' is associated. (generate_finalization_wrapper): Rename 'ptr' symbols to 'ptr1' and 'ptr2'. Pass 'sub_ns' to finalize_component. 2015-01-26 Janus Weil ja...@gcc.gnu.org PR fortran/64230 * gfortran.dg/class_allocate_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 M. Hanselmann public at hansmi dot ch changed: What|Removed |Added CC||public at hansmi dot ch --- Comment #7 from M. Hanselmann public at hansmi dot ch --- Confirmed using GCC 5.0.0 20150125 built from source (see below) and 4.7.2 (Debian 4.7.2-5; Debian Wheezy). Tested using the test case in comment 1. Output: $ g++-5-20150125 -std=c++11 -o test62258 test62258.c -Wall ./test62258 test62258: test62258.c:11: int main(): Assertion `!std::uncaught_exception()' failed. Aborted $ g++-5-20150125 -v Using built-in specs. COLLECT_GCC=g++-5-20150125 COLLECT_LTO_WRAPPER=/home/user/gcc50/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/user/gcc50build/src-gcc-5-20150125/configure --target=x86_64-unknown-linux-gnu --prefix=/home/user/gcc50build/target-x86_64-unknown-linux-gnu --program-suffix=-5-20150125 --disable-nls --enable-c99 --enable-checking=release --enable-gnu-unique-object --enable-gold --enable-languages=c,c++ --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-long-long --enable-multiarch --enable-multilib --enable-shared --enable-targets=all --enable-threads=posix --with-system-zlib --with-tune=generic Thread model: posix gcc version 5.0.0 20150125 (experimental) (GCC)
[Bug c/64803] New: __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 Bug ID: 64803 Summary: __LINE__ inside macro is not constant Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: alserkli at inbox dot ru The following code (simplified from EXPECT_DEATH(VariantValue(VariantMatcher::SingleMatcher(varDecl())) in llvm/tools/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp:149) #define C(a, b) a ## b #define L(x) C(L, x) #define M(a) goto L(__LINE__); __LINE__; L(__LINE__): M(a ); produces (gcc -E; 5.0.0 20150126) goto L5; 5; L4: In gcc-4.7 the result was (after '#' lines removal) goto L5 ; 5 ; L5 : ;
[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 rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-26 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine, but can you confirm those findings?
[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 #24 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to amker from comment #23) partially agree. at least for the single use case given by Seb, I think tree ivopt should do it. (I verified clang do ivopt correctly for the case) for the rtl re-associate, it's a little bit painful from my experiment experiences. as it's not always good to reassociate virtual_frame + offset, we can only benefit if it's in loop, because the re-associate will increase register pressure, there will be situations that more callee-saved regs used, and finally we run into unncessary push/pop in pro/epilogue... and I haven't found a good place where we can safely re-use existed rtl info and do the rtl re-association as I am afraid rebuild those rtl info will cause compile time penalty.
[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 #23 from amker at gcc dot gnu.org ---
Now I am less convinced that it's a tree ivopt issue. Tree optimizer has no
knowledge about stack frame information for local array variables. With the
original test, on 32-bits targets, tree ivopts happens to choose the IV of base
address like below:
bb 16:
# ivtmp.11_82 = PHI ivtmp.11_84(15), ivtmp.11_83(17)
_87 = (void *) ivtmp.11_82;
_13 = MEM[base: _87, offset: 0B];
ivtmp.11_83 = ivtmp.11_82 - 1;
_14 = (int) _13;
foo (_14);
if (ivtmp.11_83 != _88)
goto bb 17;
else
goto bb 3;
bb 17:
goto bb 16;
IMHO, we shouldn't depend on this. It's much clearer to consider the exactly
multiple-use example in previous comment, but this time in loop context:
void bar(int i) {
char A[10];
char B[10];
char C[10];
int d = 0;
while (i 0)
A[d++] = i--;
while (d 0)
{
foo(A[d]);
foo(B[d]);
foo(C[d]);
d--;
}
}
Tree ivopt has no knowledge that references of A/B/C in loop share common
sub-expression. Most likely (as suggested by previous comments), GCC will
generates below IR:
bb 15:
_93 = (sizetype) i_6(D);
_94 = A + _93;
ivtmp.11_92 = (unsigned int) _94;
_98 = (sizetype) i_6(D);
_99 = _98 + 1;
_100 = B + _99;
ivtmp.15_97 = (unsigned int) _100;
_104 = (sizetype) i_6(D);
_105 = _104 + 1;
_106 = C + _105;
ivtmp.20_103 = (unsigned int) _106;
_110 = (unsigned int) A;
bb 16:
# ivtmp.11_90 = PHI ivtmp.11_92(15), ivtmp.11_91(17)
# ivtmp.15_95 = PHI ivtmp.15_97(15), ivtmp.15_96(17)
# ivtmp.20_101 = PHI ivtmp.20_103(15), ivtmp.20_102(17)
_107 = (void *) ivtmp.11_90;
_13 = MEM[base: _107, offset: 0B];
ivtmp.11_91 = ivtmp.11_90 - 1;
_14 = (int) _13;
foo (_14);
ivtmp.15_96 = ivtmp.15_95 - 1;
_108 = (void *) ivtmp.15_96;
_16 = MEM[base: _108, offset: 0B];
_17 = (int) _16;
foo (_17);
ivtmp.20_102 = ivtmp.20_101 - 1;
_109 = (void *) ivtmp.20_102;
_19 = MEM[base: _109, offset: 0B];
_20 = (int) _19;
foo (_20);
if (ivtmp.11_91 != _110)
goto bb 17;
else
goto bb 3;
bb 17:
goto bb 16;
It not good at least on targets without auto-increment addressing modes. Even
on ARM/AARCH64 with auto-increment addressing modes, it's not always practical
because of bloated loop-setup, or register pressure issue caused by duplicated
inducation variables.
In this case, we should associate virtual_frame + offset1 and hoist it out of
loop, while in loop, we should choose only one inducation variable (the biv),
then refer to A/B/C using offset addressing mode like below:
bb 15
base_1 = virtual_frame + off1
bb 16:
# d_26 = PHI init, d_13
base_2 = base_1 + d_26
d_13 = d_26 - 1;
foo (MEM[base_2, off_A])
foo (MEM[base_2, off_B])
foo (MEM[base_2, off_C])
goto bb 16
So maybe this is a RTL issue, we firstly should do reassociation like
virtual_frame + reg + offset to (virtual_frame + offset) + reg. As for
missed CSE opportunities in address expressions, maybe it can be fixed by an
additional strength reduction pass on RTL, just like gimple-strength-reduction
pass. The rtl pass is necessary simply because the gimple one has no knowledge
of stack frame information, just like tree IVOPT.
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org --- The bootstrap failure should be fixed now. ASAN doesn't work at all with != 39 bits of virtual address space though.
[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63765 --- Comment #16 from David Edelsohn dje at gcc dot gnu.org --- The alternative patch works on AIX. I thought that it was going to be installed.
[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-26 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|__LINE__ inside macro is|[5 Regression] __LINE__ |not constant|inside macro is not ||constant Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r213102 aka PR61861.
[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 #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 34577 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34577action=edit pr64307.c.050i.whole-program for --enable-checking=release build Can you attach preprocessed source or say -fdump-ipa-whole-program-all -fdump-ipa-icf-all dumps from the --enable-checking=release build? pr64307.c.050i.whole-program for --enable-checking=release build.
[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Honza/Martin, any progress on this?
[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 #13 from Ilya Enkovich enkovich.gnu at gmail dot com ---
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.
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))
+ SSA_NAME_RANGE_INFO (orig_base)
+ get_range_info (orig_base, min, max) == VR_RANGE
+ wi::gts_p (highwi, max))
+ 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 fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Mon Jan 26 18:53:42 2015 New Revision: 220130 URL: https://gcc.gnu.org/viewcvs?rev=220130root=gccview=rev Log: 2015-01-26 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64230 * class.c (finalize_component): New argument 'sub_ns'. Insert code to check if 'expr' is associated. (generate_finalization_wrapper): Rename 'ptr' symbols to 'ptr1' and 'ptr2'. Pass 'sub_ns' to finalize_component. 2015-01-26 Janus Weil ja...@gcc.gnu.org Backport from mainline PR fortran/64230 * gfortran.dg/class_allocate_18.f90: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_allocate_18.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/class.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||friend1992friend1992@yandex ||.ru --- Comment #199 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 64808 has been marked as a duplicate of this bug. ***
[Bug target/15184] [4.8/4.9/5 Regression] Direct access to byte inside word not working with -march=pentiumpro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #30 from Jeffrey A. Law law at redhat dot com --- Actually better to handle this in combine rather than the backend. The problem is the to-be-inserted bits have different canonical forms depending on where we're inserting them. if it's the low bits it might be (subreg) or a zero_extend. If it's middle bits, there's an (and ..) and if its in the high bits, then there's an (ashift ...) It gets even uglier when we start looking at the 2nd pair of tests By nailing it down in combine, other targets benefit as well. For the combiner, the first two tests (and a couple of my own) are pretty easy. It's far enough along that taking ownership seems to make sense. Attacking the problem in bswap would be good, but obviously further out.
[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 #9 from Ilya Enkovich enkovich.gnu at gmail dot com --- Nice solution for this problem would be to have a better estimation of maximum loop iterations number. Currently array size and index step are used to get the maximum ignoring starting index value range. Another way to solve the problem is to disable warnings for code generated by cunroll in case it cannot compute exact number of iterations. I attach a patch which does it. This bug is hit multiple times on Android build with GCC 4.9. With this fix we have a clean Android build with GCC 4.9.
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 34571 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34571action=edit segregate derived type namespaces from regular namespaces To convince yourself that sym_root fields are never used in derived type namespaces, here is a patch that gives a type without sym_root field to f2k_derived. It passes bootstrapping.
[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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34572 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34572action=edit gcc5-pr64766.patch Untested fix.
[Bug c/64800] New: Bad opcode produced for coldfire mcf5307 processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64800 Bug ID: 64800 Summary: Bad opcode produced for coldfire mcf5307 processor Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: angelo70 at gmail dot com Dear all, i am compiling a simple bare-metal binary with https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz $ make -f makefile.release /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/boot.o src/boot.S /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/vt100.o src/vt100.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/timing.o src/timing.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/flash.o src/flash.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/memory.o src/memory.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/main.o src/main.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc -m5307 -g -O2 -fno-builtin -I include -c -o obj/serial.o src/serial.c /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-ld -T ram.ld -M -o bin/cf4k.elf obj/boot.o obj/vt100.o obj/timing.o obj/flash.o obj/memory.o obj/main.o obj/serial.o bin/cf4k.map /opt/toolchains/m68k/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-objcopy -O binary bin/cf4k.elf bin/cf4k The resulting opcodes seems not correct for mcf5307 (coldfire). Wrong code is of course not running on the target board. See this meminit func disass: Dump of assembler code for function meminit: 0x2758 +0: linkw %fp,#-12 0x275c +4: moveml %a2-%a4,%sp@ 0x2760 +8: movel #262144,%sp@- 0x2766 +14:lea 0x24fc delay,%a3 0x276c +20:moveal #268435720,%a2 0x2772 +26:moveaw #4,%a4 0x2776 +30:jsr %a3@ 0x2778 +32:movew #-32218,%d0 0x277c +36:movew %d0,0x1100 0x2782 +42:movel #16711681,%d0 0x2788 +48:movel #13060,%a2@ 0x278e +54:movel %d0,0x110c = 0x2794 +60:movel #13068,%a2@ 0x279a +66:movel #-1095901459,%a4@ 0x27a0 +72:movel #45828,%a2@ 0x27a6 +78:pea 0x68a 0x27aa +82:jsr %a3@ 0x27ac +84:movel #-1095901459,%a4@ 0x27b2 +90:movel #45828,%a2@ 0x27b8 +96:movel #262144,%sp@- 0x27be +102: jsr %a3@ 0x27c0 +104: movel #-1095901459,%d0 0x27c6 +110: lea %sp@(12),%sp 0x27ca +114: movel #45892,%a2@ 0x27d0 +120: movel %d0,0xc00 0x27d4 +124: moveq #4,%d0 0x27d6 +126: swap %d0 0x27d8 +128: .short 0x4cfe 0x27da +130: moveb %d0,%d6 0x27dc +132: .short 0xfff4 0x27de +134: unlk %fp 0x27e0 +136: movel %d0,0x1114 0x27e6 +142: clrl 0x1110 0x27ec +148: rts While, with a toolchain from CodeSourcery, /opt/toolchains/m68k/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf-gcc --version m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. i get = 0x2758 +0: linkw %fp,#-12 0x275c +4: moveml %a2-%a4,%sp@ 0x2760 +8: movel #262144,%sp@- 0x2766 +14:lea 0x24f8 delay,%a3 0x276c +20:moveal #268435720,%a2 0x2772 +26:moveaw #4,%a4 0x2776 +30:jsr %a3@ 0x2778 +32:movew #-32218,%d0 0x277c +36:movew %d0,0x1100 0x2782 +42:movel #16711681,%d0 0x2788 +48:movel #13060,%a2@ 0x278e +54:movel %d0,0x110c 0x2794 +60:movel #13068,%a2@ 0x279a +66:movel #-1095901459,%a4@ 0x27a0 +72:movel #45828,%a2@ 0x27a6 +78:pea 0x68a 0x27aa +82:jsr %a3@ 0x27ac +84:movel #-1095901459,%a4@ 0x27b2 +90:movel #45828,%a2@ 0x27b8 +96:movel #262144,%sp@- 0x27be +102: jsr %a3@ 0x27c0 +104: movel #-1095901459,%d0 0x27c6 +110: lea %sp@(12),%sp 0x27ca +114: movel #45892,%a2@ 0x27d0 +120: movel %d0,0xc00 0x27d4 +124: moveq #4,%d0 0x27d6 +126: swap %d0 0x27d8 +128: moveml %fp@(-12),%a2-%a4 0x27de +134: unlk %fp 0x27e0 +136: movel %d0,0x1114 0x27e6 +142: clrl 0x1110
[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 #20 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) It's probably not correct to simply transfer range info from *idx to iv-base. Instead SCEV analysis needs to track the range of CHREC_LEFT when it analyzes the SSA use-def chain. That's of course a much bigger change :/ The patch may still help in some cases - I suppose the original testcase is reduced from sth else? I see it's a tricky problem, and I have to admit that I don't understand it very well yet. The question is, is relax of POINTER_PLUS_EXPR constraint the right way fixing this? I do remember some other PRs (other than this one or bug 52563) are caused by this constraint according to your comments. Of course, take range information into consideration is always an improvement. Actually I have another possible example in iv elimination. Curently GCC simply rejects elimination of an iv use with a candidate if the cand is of smaller type, but as long as we can prove value of iv use can be represented by the smaller candidate, elimination is actually safe. But seems to me, fixing this issue with value information is like a side-effect?
[Bug ipa/64801] New: [5 Regression] kernel build failure due to ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64801
Bug ID: 64801
Summary: [5 Regression] kernel build failure due to ICF
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Created attachment 34574
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34574action=edit
unreduced testcase
Seen on x86_64 with kernel's defconfig.
...
CC init/version.o
LD init/built-in.o
drivers/built-in.o:psmouse-base.c:function psmouse_extensions: error: undefined
reference to 'fsp_detect'
-fno-ipa-icf fixes the issue.
markus@x4 tmp % cat psmouse-base.i
int a;
int
elantech_detect (void)
{
return -38;
}
inline int
fsp_detect (void)
{
return -38;
}
void
psmouse_extensions (void)
{
int (*b)() = fsp_detect;
a = b ();
}
markus@x4 tmp % gcc -c -O2 psmouse-base.i
markus@x4 tmp % nm psmouse-base.o| grep fsp_detect
U fsp_detect
[Bug c/64800] Bad opcode produced for coldfire mcf5307 processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64800 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Looks like this is a bug in your assembler, which generates 0x4cfe instead of 0x4cee for moveml %fp@(-12),%a2-%a4.
[Bug target/64795] [5 regression] too many memory references for `lea'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64795 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jan 26 18:49:21 2015 New Revision: 220128 URL: https://gcc.gnu.org/viewcvs?rev=220128root=gccview=rev Log: PR target/64795 * config/i386/i386.md (*movdi_internal): Also check operand 0 to determine TYPE_LEA operand. (*movsi_internal): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Allan Jensen from comment #3) I refer to this: /* Handle arch= if specified. For priority, set it to be 1 more than the best instruction set the processor can handle. For instance, if there is a version for atom and a version for ssse3 (the highest ISA priority for atom), the atom version must be checked for dispatch before the ssse3 version. */ That is correct. The issue here is nt __attribute__ ((target(arch=corei7))) foo (); vs int __attribute__ ((target(arch=corei7,popcnt))) foo (); not int __attribute__ ((target(arch=corei7))) foo (); vs int __attribute__ ((target(popcnt))) foo (); What bug does your patch try to fix?
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jan 26 19:31:55 2015 New Revision: 220131 URL: https://gcc.gnu.org/viewcvs?rev=220131root=gccview=rev Log: Revert the last P_POPCNT order change PR target/64806 * config/i386/i386 (feature_priority): Revert the last P_POPCNT order change. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Allan Jensen from comment #1) The logic is supposed to be that any arch that includes an extension is prioritized above that extension, and with POPCNT being part of SSE4a on AMD and part of SSE 4.2 for Intel, that should be the case. The feature priority array, feature_priority, is orthogonal to -march=.
[Bug ipa/64730] [5 Regression] g++.dg/ipa/pr64049-1.C ICE: SEGV when printing NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64730 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) Created attachment 34575 [details] gcc5-pr64730.patch I don't think there was anything wrong with the patch, just there is a problem that a non-NULL edge-call_stmt necessarily doesn't mean the call has a known location. Totally agree. Assigning to Jakub since he has a patch.
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #14 from Damian Rouson damian at sourceryinstitute dot org --- Correction: the backport I was discussing with Andre was for a different bug. Nonetheless, I'm reasonably certain that the fix for this bug would benefit the aforementioned project (pFUnit) so I'm still interested in this patch being back ported if that's an option.
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #13 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to David Edelsohn from comment #12) GCC on AIX. One can use gcc111 in the GCC Compiler Farm. Thanks! I've sent a request for an access to gcc111 but got no response so far...
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from janus at gcc dot gnu.org --- Fixed on trunk and 4.9. Closing. Thanks for the report!
[Bug c++/64808] static_cast double to int on linux 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64808 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- You see the effect of excess precision of a floating point value that cannot be represented exactly. *** This bug has been marked as a duplicate of bug 323 ***
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #12 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com ---
Dear All,
As I just said on #gfortran, the previous explanation is wrong. The
problem is that, for the mold= case with no default initializer, the
code-expr winds up being NULL. This fixes it and is being regtested:
Index: /svn/trunk/gcc/fortran/resolve.c
===
*** /svn/trunk/gcc/fortran/resolve.c(revision 220097)
--- /svn/trunk/gcc/fortran/resolve.c(working copy)
*** resolve_allocate_expr (gfc_expr *e, gfc_
*** 6995,7003
{
/* Default initialization via MOLD (non-polymorphic). */
gfc_expr *rhs = gfc_default_initializer (code-expr3-ts);
! gfc_resolve_expr (rhs);
! gfc_free_expr (code-expr3);
! code-expr3 = rhs;
}
if (e-ts.type == BT_CLASS !unlimited !UNLIMITED_POLY (code-expr3))
--- 6995,7006
{
/* Default initialization via MOLD (non-polymorphic). */
gfc_expr *rhs = gfc_default_initializer (code-expr3-ts);
! if (rhs != NULL)
! {
! gfc_resolve_expr (rhs);
! gfc_free_expr (code-expr3);
! code-expr3 = rhs;
! }
}
if (e-ts.type == BT_CLASS !unlimited !UNLIMITED_POLY (code-expr3))
If it regtests OK, I intend to commit right away as obvious. I guess
that for this completely stupid bug, I should backport to 4.9 at
least?
Cheers
Paul
On 26 January 2015 at 18:19, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear Dominique,
For some reason, the hash values are different in the vtable and the
TYPE IS. I had always worried that that we would have different names
giving the same hash sometime but not that the same name would give a
different hash!
The 'other brand' gives the correct result.
Thanks for the testcase!
Paul
On 26 January 2015 at 11:55, dominiq at lps dot ens.fr
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The following, which works OK with another brand, selects the wrong type
with trunk. 4.9 still segfaults. Without the use rename, 4.9 runs and gives
the wrong result.
The following test without module also selects the wrong type when compiled
with 4.8 up to 5.0
implicit none
type, abstract :: GridImageSiloTemplate
end type GridImageSiloTemplate
type, extends ( GridImageSiloTemplate ) ::
UnstructuredGridImageSiloForm
end type UnstructuredGridImageSiloForm
call foo
contains
subroutine foo
class (GridImageSiloTemplate), allocatable :: a
type (UnstructuredGridImageSiloForm) :: b
allocate (a, mold = b)
select type (a)
type is (UnstructuredGridImageSiloForm)
print *, correct type selected
class default
print *, wrong type
end select
end subroutine
end
--
You are receiving this mail because:
You are on the CC list for the bug.
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 --- Comment #3 from Allan Jensen linux at carewolf dot com --- I refer to this: /* Handle arch= if specified. For priority, set it to be 1 more than the best instruction set the processor can handle. For instance, if there is a version for atom and a version for ssse3 (the highest ISA priority for atom), the atom version must be checked for dispatch before the ssse3 version. */
[Bug target/64795] [5 regression] too many memory references for `lea'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64795 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jan 26 20:12:26 2015 New Revision: 220132 URL: https://gcc.gnu.org/viewcvs?rev=220132root=gccview=rev Log: Backport from mainline 2015-01-26 Uros Bizjak ubiz...@gmail.com PR target/64795 * config/i386/i386.md (*movdi_internal): Also check operand 0 to determine TYPE_LEA operand. (*movsi_internal): Ditto. Backport from mainline 2015-01-23 Uros Bizjak ubiz...@gmail.com * config/i386/sse.md (sse2_loadld): Set attribute isa to sse2 for alternative 1. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.md branches/gcc-4_9-branch/gcc/config/i386/sse.md
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #13 from Damian Rouson damian at sourceryinstitute dot org --- Paul, In case it matters, I reported a duplicate of this bug that I isolated from code in an open-source NASA project (http://sourceforge.net/projects/pfunit/). NASA has expressed a desire for the fix to be backported to 4.9 (and 4.8 if possible) and I just received approval to fund Andre to work on it in case that helps. Please let me know how to proceed. Damian
[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 #14 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Created attachment 34581 [details]
gcc5-pr64776.patch
Untested fix.
The patch fixes the ICE and regtest cleanly (at least with
make -k check-gcc RUNTESTFLAGS=ipa.exp --target_board=unix'{-m32,-m64}'
...
=== gcc Summary ===
# of expected passes802
# of expected failures6
# of unsupported tests6
Thanks.
[Bug jit/64708] libgccjit installed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64708 --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- [david@c64 install]$ ll $(find -name libgccjit.so*) -rwxr-xr-x. 1 david david 78637910 Jan 26 12:59 ./libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/libgccjit.so lrwxrwxrwx. 1 david david 14 Jan 26 12:59 ./lib/libgccjit.so - libgccjit.so.0 lrwxrwxrwx. 1 david david 18 Jan 26 12:59 ./lib/libgccjit.so.0 - libgccjit.so.0.0.1 -rwxr-xr-x. 1 david david 78637910 Jan 26 12:59 ./lib/libgccjit.so.0.0.1 The libdir one is from gcc/jit/Make-lang.in: jit.install-common: installdirs $(INSTALL_PROGRAM) $(LIBGCCJIT_FILENAME) \ $(DESTDIR)/$(libdir)/$(LIBGCCJIT_FILENAME) (...snip...) The libexec one is from gcc/Makefile.in: # Install the compiler executables built during cross compilation. install-common: native lang.install-common installdirs for file in $(COMPILERS); do \ if [ -f $$file ] ; then \ rm -f $(DESTDIR)$(libexecsubdir)/$$file; \ $(INSTALL_PROGRAM) $$file $(DESTDIR)$(libexecsubdir)/$$file; \ else true; \ fi; \ done (...snip...) since COMPILERS contains libgccjit.so.
[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 #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Can you look at libffi's config.log if it is clear why the test failed then?
[Bug c/64800] Bad opcode produced for coldfire mcf5307 processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64800 --- Comment #2 from angelo angelo70 at gmail dot com --- You mean the issue is into m68k-linux-as or what ? The function i disassembled is inside memory.c. So i am calling m68k-linux-gcc, wich generate object code and finally opcodes.
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #11 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Dear Dominique, For some reason, the hash values are different in the vtable and the TYPE IS. I had always worried that that we would have different names giving the same hash sometime but not that the same name would give a different hash! The 'other brand' gives the correct result. Thanks for the testcase! Paul On 26 January 2015 at 11:55, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following, which works OK with another brand, selects the wrong type with trunk. 4.9 still segfaults. Without the use rename, 4.9 runs and gives the wrong result. The following test without module also selects the wrong type when compiled with 4.8 up to 5.0 implicit none type, abstract :: GridImageSiloTemplate end type GridImageSiloTemplate type, extends ( GridImageSiloTemplate ) :: UnstructuredGridImageSiloForm end type UnstructuredGridImageSiloForm call foo contains subroutine foo class (GridImageSiloTemplate), allocatable :: a type (UnstructuredGridImageSiloForm) :: b allocate (a, mold = b) select type (a) type is (UnstructuredGridImageSiloForm) print *, correct type selected class default print *, wrong type end select end subroutine end -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tree-optimization/64807] New: [5 Regression] Wrong-code because of wide-int division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64807
Bug ID: 64807
Summary: [5 Regression] Wrong-code because of wide-int division
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: emsr at gcc dot gnu.org, jakub at gcc dot gnu.org,
nheghathivhistha at gmail dot com, segher at gcc dot
gnu.org,
trippels at gcc dot gnu.org
Depends on: 63504, 63988
/* { dg-do run { target int128 } } */
/* { dg-options -O2 } */
__uint128_t
foo (void)
{
__uint128_t a = -1;
__uint128_t b = -1;
return a / b;
}
int
main ()
{
if (foo () != 1)
__builtin_abort ();
return 0;
}
is miscompiled starting with wide-int merge r210113.
[Bug target/64806] [5 Regression] FAIL: FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |5.0
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #10 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Hi Mikael, Yes, you will see from my comment on the PR that I had come to the same conclusion. However, rather than take PR62044 as a place holder, I will open a new PR. Thanks for the information about the derived type namespaces. Originally they were added with precisely this in mind (and in fact?) but they seem to have fallen into disuse (or not!). Cheers Paul On 26 January 2015 at 13:11, mikael at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 34571 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34571action=edit segregate derived type namespaces from regular namespaces To convince yourself that sym_root fields are never used in derived type namespaces, here is a patch that gives a type without sym_root field to f2k_derived. It passes bootstrapping. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug target/64806] New: [5 Regression] FAIL: FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806
Bug ID: 64806
Summary: [5 Regression] FAIL: FAIL: g++.dg/ext/mv1.C
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
r220095 caused:
FAIL: g++.dg/ext/mv1.C -std=gnu++98 execution test
FAIL: g++.dg/ext/mv1.C -std=gnu++11 execution test
FAIL: g++.dg/ext/mv1.C -std=gnu++14 execution test
on Nehalem and Westmere machines. g++.dg/ext/mv1.C has
int __attribute__ ((target(arch=corei7,popcnt)))
foo ()
{
return 5;
}
and
int __attribute__ ((target(arch=corei7)))
foo ()
{
return 6;
}
r220095 changed the priority of P_POPCNT:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9ec40cb..441911d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree
*predica
te_list)
P_PROC_SSE4_A,
P_SSE4_1,
P_SSE4_2,
-P_PROC_SSE4_2,
P_POPCNT,
+P_PROC_SSE4_2,
On Nehalem and Westmere machines, it selected foo for corei7 instead
of corei7,popcnt since P_PROC_SSE4_2 has the higher priority than
P_POPCNT.
[Bug c++/64808] New: static_cast double to int on linux 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64808
Bug ID: 64808
Summary: static_cast double to int on linux 32
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: friend1992friend1992 at yandex dot ru
I have code :
#include iostream
void fun(double _v)
{
std::cout_v=_vstd::endl;
long long int var=static_cast long long int (_v*1000.);
std::coutvar=varstd::endl;
}
int main(int ac, char** av)
{
fun(33.33);
return 0;
}
I try to compile this code on Linux x86_64 with GCC 4.8.2 (g++ test.cpp -o
test64), I get result in console:
_v=33.33
var=0
but when I try to compile this code on Linux i686 with GCC 4.8.2 (g++ test.cpp
-o test32), I get result in console:
_v=33.33
var=33329
But if I replace long long int var=static_cast long long int (_v*1000.); to
double t = _v*1000.; long int var=static_cast long long int (t); I get the
result on Linux i686 with GCC 4.4.5:
_v=33.33
var=0
[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 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-26 CC||mpolacek at gcc dot gnu.org Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug target/64806] [5 Regression] FAIL: g++.dg/ext/mv1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806 Allan Jensen linux at carewolf dot com changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #1 from Allan Jensen linux at carewolf dot com --- The logic is supposed to be that any arch that includes an extension is prioritized above that extension, and with POPCNT being part of SSE4a on AMD and part of SSE 4.2 for Intel, that should be the case.
[Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 --- Comment #3 from Christian Otterstad christian.otterstad at gmail dot com --- Great, it seems this corrected the issue, but a new problem that didn't appear to exist before seems to have been introduced. I created a new bug issue for it. Bug 64805: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
For 2) a short testcase is:
__uint128_t
foo (void)
{
__uint128_t a = -1;
__uint128_t b = a - 0x8000ULL;
return a / b;
}
(even on x86_64 native).
