[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #22 from Joshua Kinard kumba at gentoo dot org --- (In reply to Andrew Pinski from comment #21) (In reply to Joshua Kinard from comment #20) Created attachment 33166 [details] Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0. This is the objdump disassembly of the '__lll_lock_wait_private()' function from the sln binary from glibc, statically compiled, by a BAD gcc-4.8.0 checkout (7882e02e) no previous commits reversed. This sln copy will hang trying to print usage instructions. Do you have the preprocessed source for this? Not currently. I'd have to intercept a glibc build and grab the compile string for sln.c and use that to crate the preprocessed source. I'll see if I can start a run tonight or tomorrow for this. That said, I have worked out that it's got something to do with gcc's built-in atomics added for 4.8. In glibc's sysdeps/mips/bits/atomic.h, there are conditional macros that pick whether to use the old __sync_* builtins if gcc-4.7 and earlier, or the new __atomic_* builtins in gcc-4.8 or later. This is why there is a difference between the output assembler between the 4.7 and 4.8 sln files. Under gcc-4.7, atomic_exchange_acq falls back to __sync_lock_test_and_set, which is an acquire memmodel operation, and this works fine on an R14000 processor. It's under gcc-4.8+, whatever atomic_exchange_acquire() maps to there, that hangs up on the processor. I checked the kernel side, and the futex is getting lost in freezable_schedule() in include/linux/freezer.h. I haven't traced beyond that point yet. The futex will exit the scheduler when you ctrl+c it. If you delete or comment out the gcc-4.8 defines for the atomic ops in sysdeps/mips/bits/atomic.h in glibc to force it back to the older __sync_* ops, it'll build with 4.8+ and the resulting sln WILL work. So it's definitely a gcc issue. I got a hold of Maxim Kuvyrkov regarding commit 39a8c5ea, but I haven't heard back from him since early September, despite sending two follow-up e-mails.
[Bug lto/63607] New: run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607
Bug ID: 63607
Summary: run fail with -flto -mfloat-abi=softfp for
armeb-linux-gnueabi-gcc
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: fei.yang0953 at gmail dot com
testsuite/gcc.dg/torture/stackalign/builtin-apply-4.c:
/* PR tree-optimization/20076 */
/* { dg-do run } */
extern void abort (void);
double
foo (int arg)
{
if (arg != 116)
abort();
return arg + 1;
}
inline double
bar (int arg)
{
foo (arg);
__builtin_return (__builtin_apply ((void (*) ()) foo,
__builtin_apply_args (), 16));
}
int
main (int argc, char **argv)
{
if (bar (116) != 117.0)
abort ();
return 0;
}
Compile option: armeb-linux-gnueabi-gcc builtin-apply-4.c -static
-mfloat-abi=softfp -flto
Disassembly:
076c main:
76c: e92d4800 push {fp, lr}
770: e28db004 addfp, sp, #4
774: e3a02113 movr2, #-1073741820; 0xc004
778: e30a3aaa movw r3, #43690 ; 0x
77c: e34a3aaa movt r3, #43690 ; 0x
780: e5823000 strr3, [r2]
784: e3a00074 movr0, #116 ; 0x74
788: ebaa bl 638 bar.4066
78c: eeb06b40vmov.f64d6, d0
790: ed9f7b0a vldr d7, [pc, #40] ; 7c0 main+0x54
794: eeb46b47 vcmp.f64 d6, d7
Analysis: Return value is not passed correctly. As we can see from line 790,
main gets the return value from d0 register, which is wrong as we use
-mfloat-abi=softfp here.
[Bug tree-optimization/63605] [4.8/4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-21 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|wrong code at -O3 on|[4.8/4.9/5 Regression] |x86_64-linux-gnu|wrong code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- r186488 turned this into ICE, r192238 fixed the ICE but it has been already miscompiled at that point.
[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Is -mfloat-abi=softfp properly used at LTO stage?
[Bug tree-optimization/63605] [4.8/4.9/5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63605 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-21 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I'm quite sure I tested that -fno-lto works. gcc-4.9 -flto -ffat-lto-objects -c t.c gcc-4.9 t.o -fno-lto -v 21 | grep lto1 nothing indeed it does. gcc-4.9 t.o -v 21 | grep lto1 /usr/lib64/gcc/x86_64-suse-linux/4.9/lto1 -quiet -dumpbase t.o -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase t -version -fno-trapv -fno-strict-overflow -fltrans-output-list=/tmp/ccRx0SND.ltrans.out -fwpa -fresolution=/tmp/ccnlyyYA.res @/tmp/ccesvcXD /usr/lib64/gcc/x86_64-suse-linux/4.9/lto1 -quiet -dumpbase ccRx0SND.ltrans0.o -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip /tmp/ccRx0SND.ltrans0.ltrans.o -version -fno-trapv -fno-strict-overflow -fltrans-output-list=/tmp/ccRx0SND.ltrans.out -fltrans @/tmp/ccq0naMZ -o /tmp/cchrU6el.s Do you use a linker plugin with LTO? That is, what's the value of HAVE_LTO_PLUGIN configure computes for you? Do you happen to run a binutils and have lto_plugin.so installed as auto-load? It seems that lto-plugin.c doesn't reject objects if COLLECT_GCC_OPTIONS contains -fno-lto (but only -fno-use-linker-plugin). Thus can you try if Index: lto-plugin/lto-plugin.c === --- lto-plugin/lto-plugin.c (revision 216464) +++ lto-plugin/lto-plugin.c (working copy) @@ -1071,7 +1071,8 @@ onload (struct ld_plugin_tv *tv) for the case where it is auto-loaded by BFD. */ char *collect_gcc_options = getenv (COLLECT_GCC_OPTIONS); if (collect_gcc_options - strstr (collect_gcc_options, '-fno-use-linker-plugin')) + (strstr (collect_gcc_options, '-fno-use-linker-plugin') + || strstr (collect_gcc_options, '-fno-lto'))) return LDPS_ERR; fixes it for you?
[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821 --- Comment #10 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Tue Oct 21 08:59:17 2014 New Revision: 216503 URL: https://gcc.gnu.org/viewcvs?rev=216503root=gccview=rev Log: PR libquadmath/55821 * Makefile.am: Unconditionally define libquadmath_TEXINFOS. * Makefile.in: Regenerate. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/Makefile.am trunk/libquadmath/Makefile.in
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #71 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #69) the code size regression for CSiBE from non LRA is reduced to 0.59%. Looking at the improved cases, the extra save/restore insns to/from stack disappear. I guess that SH has not enough numbers of the hard registers to make the equiv substitution win in the size and the speed on average working sets. It looks the pseudos produced to hold the equiv values can't get hard registers for bad cases and end up memory save/restore insns which make the code worse. I don't know the details and maybe I'm totally off here ... LRA is being used for ARM and there are almost the same amount of GP registers available on ARM than on SH. So either on ARM nobody has checked for such regressions, or there's something else going wrong or missing on SH? Or is it maybe really that SH R0-ness thing that makes everything work (or not work) totally different?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #72 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #70) I'd like to apply the revised patches below to sh-lra branch for looking at the problems easily. Oleg, is it OK for you? Sure. However, maybe it's better to do a merge from trunk first. I know there might be some conflicts w.r.t. my recent changes on trunk, in particular for PR 53513. On the other hand, I've seen some LRA changes/fixes on trunk recently.
[Bug tree-optimization/46590] long compile time with -O2 and many loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #45 from Richard Biener rguenth at gcc dot gnu.org --- Btw, now DOM and incremental SSA are the new main offenders (regression from 4.8). This is maybe the same as PR61515. Compile-time is up to 9 minutes (from two). Jeff - any progress on PR61515? This is really a major regression for -O1 compile-time. Can we at least disable the offending code at !flag_expensive_optimizations on trunk and the 4.9 branch? And fix it properly for GCC 5?
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- On x86_64-linux I still see 1GB used (watching top) on the 4.9 branch at -O1 and compilation takes about 8 minutes. Note that your compiler has checking enabled which at least makes the -ftime-report output unreliable. -O2 is not expected to deal very well with such large testcases (of course improving here is nice). LIM performs more expensive alias analysis at -O2 which may distort numbers here (to the worse, I don't expect that to improve things). I have now verified that on trunk and the 4.9 branch it is not LIM anymore that uses memory / compile-time. Thus this issue is fixed.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org --- Note that the patch was reverted in r216502.
[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Note that this bug shows up in quite a lot of regressions on the trunk, both x86_64 and i686: +FAIL: gcc.target/i386/avx-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-1.c (test for excess errors) +FAIL: gcc.target/i386/avx-2.c (internal compiler error) +FAIL: gcc.target/i386/avx-2.c (test for excess errors) +FAIL: gcc.target/i386/avx512f-vec-init.c (internal compiler error) +FAIL: gcc.target/i386/avx512f-vec-init.c (test for excess errors) +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vbroadcastsd 1 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vbroadcastss 1 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vmovdqa64[ t]+%zmm 2 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vpbroadcastb 2 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vpbroadcastd 1 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vpbroadcastq 1 +UNRESOLVED: gcc.target/i386/avx512f-vec-init.c scan-assembler-times vpbroadcastw 2 +FAIL: gcc.target/i386/sse-14.c (internal compiler error) +FAIL: gcc.target/i386/sse-14.c (test for excess errors) +FAIL: gcc.target/i386/sse-22.c (internal compiler error) +FAIL: gcc.target/i386/sse-22.c (test for excess errors) +FAIL: gcc.target/i386/sse-22a.c (internal compiler error) +FAIL: gcc.target/i386/sse-22a.c (test for excess errors) +FAIL: gcc.target/i386/sse-23.c (internal compiler error) +FAIL: gcc.target/i386/sse-23.c (test for excess errors) +FAIL: gcc.target/i386/sse-24.c (internal compiler error) +FAIL: gcc.target/i386/sse-24.c (test for excess errors) are all because of this, so IMHO this is quite urgent thing to solve. Note, supposedly in the WIP2 patch supposedly the vec_dupmode and the new define_insns should be moved after the avx512 patterns, so that those trigger earlier, and as I said, IMHO they really need to be merged so that broadcasts from gprs are in the same patterns as broadcasts from memory or vector regs, just different alternatives, but supposedly that can be done incrementally. I'm also not sure about the v vs. x constraints on the AVX2 insn, supposedly v is not an option if the mode iterator includes V*QI and V*HI modes, because then AVX512F doesn't have instructions for that, right?
[Bug target/63223] [avr] Make jumptables work with -Wl,--section-start,.text=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to Jorn Wolfgang Rennecke from comment #4) (In reply to Georg-Johann Lay from comment #1) do_global_dtors is supposed to start at the start and increment from there. I see it used to be half-way wrong and half-way correct. (Starting at the start, decrementing for __AVR_HAVE_ELPM__, incrementing otherwise.) However, you now made it all the way use an incorrect order - starting at the end and incrementing from there. Is there a rationale for this? The old code was broken as it decremented begainning at the start address. The flaw never came apparent for __dtors_start = __dtors_end or with simulators that terminated in exit. The new code uses the same traverse direction like __do_global_ctors. Is the order of .ctors, .dtors defined in any way? I.e. how do you express that constructor A must run before constructor B in the C program? Same for destructors.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #13)
On Tue, 17 Jun 2014, law at redhat dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot com
Assignee|unassigned at gcc dot gnu.org |law at redhat dot
com
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
Fundamentally we don't have a way to know what equivalences we need to
invalidate.
Invalidation is, umm, painful. The question in my mind is why are we
getting
so many invalidations to start with. That's the first thing to look at.
Well, it's easy to avoid the quadraticness - you can always create
testcases that need a lot of invalidates. But the current algorithm
really does not scale.
Honestly though, I really wonder if handling backedges is worth the effort,
even though it's important for one benchmark.
Not sure about that, but trivial improvements to the scalability are
possible here. Walking all SSA names is O(number of stmts) - if you
do that O(number of stmts) time (as you do) that's clearly the bug.
Sth like (untested)
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c (revision 216464)
+++ tree-ssa-threadedge.c (working copy)
@@ -287,20 +287,6 @@ fold_assignment_stmt (gimple stmt)
}
}
-/* A new value has been assigned to LHS. If necessary, invalidate any
- equivalences that are no longer valid. */
-static void
-invalidate_equivalences (tree lhs, vectree *stack)
-{
-
- for (unsigned int i = 1; i num_ssa_names; i++)
-if (ssa_name (i) SSA_NAME_VALUE (ssa_name (i)) == lhs)
- record_temporary_equivalence (ssa_name (i), NULL_TREE, stack);
-
- if (SSA_NAME_VALUE (lhs))
-record_temporary_equivalence (lhs, NULL_TREE, stack);
-}
-
/* Try to simplify each statement in E-dest, ultimately leading to
a simplification of the COND_EXPR at the end of E-dest.
@@ -335,6 +321,8 @@ record_temporary_equivalences_from_stmts
we discover. Note any equivalences we discover are context
sensitive (ie, are dependent on traversing E) and must be unwound
when we're finished processing E. */
+ sbitmap to_invalidate = sbitmap_alloc (num_ssa_names);
+ bitmap_clear (to_invalidate);
for (gsi = gsi_start_bb (e-dest); !gsi_end_p (gsi); gsi_next (gsi))
{
tree cached_lhs = NULL;
@@ -379,7 +367,7 @@ record_temporary_equivalences_from_stmts
if (backedge_seen)
FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_DEF)
- invalidate_equivalences (op, stack);
+ bitmap_set_bit (to_invalidate, SSA_NAME_VERSION (op));
continue;
}
@@ -419,7 +407,7 @@ record_temporary_equivalences_from_stmts
if (backedge_seen)
{
tree lhs = gimple_get_lhs (stmt);
- invalidate_equivalences (lhs, stack);
+ bitmap_set_bit (to_invalidate, SSA_NAME_VERSION (lhs));
}
continue;
}
@@ -497,8 +485,24 @@ record_temporary_equivalences_from_stmts
|| is_gimple_min_invariant (cached_lhs)))
record_temporary_equivalence (gimple_get_lhs (stmt), cached_lhs,
stack);
else if (backedge_seen)
- invalidate_equivalences (gimple_get_lhs (stmt), stack);
+ bitmap_set_bit (to_invalidate,
+ SSA_NAME_VERSION (gimple_get_lhs (stmt)));
}
+
+ /* Now invalidate all equivalencies we have to invalidate. */
+ unsigned i;
+ sbitmap_iterator bi;
+ EXECUTE_IF_SET_IN_BITMAP (to_invalidate, 0, i, bi)
+{
+ tree name = ssa_name (i);
+ record_temporary_equivalence (name, NULL_TREE, stack);
+
+ if (name)
+ record_temporary_equivalence (name, NULL_TREE, stack);
+}
+
+ sbitmap_free (to_invalidate);
+
return stmt;
}
[Bug c/63608] New: [4.8 Regression]error: type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63608 Bug ID: 63608 Summary: [4.8 Regression]error: type mismatch in binary expression Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yueming.yang at huawei dot com Created attachment 33765 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33765action=edit testcase gcc hello.c -S -O2 -w -m32 -v Using built-in specs. COLLECT_GCC=x86_install/bin/gcc Target: x86_64-unknown-linux-gnu Configured with: gcc-4.8-branch/configure --prefix=x86_install --enable-languages=c,c++ --enable-threads=posix --disable-multilib --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-checking --with-system-zlib --enable-lto --disable-bootstrap Thread model: posix gcc version 4.8.4 20140911 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-S' '-O2' '-w' '-m32' '-v' '-mtune=generic' '-march=x86-64' x86_install/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/cc1 -quiet -v -imultilib . hello.c -quiet -dumpbase hello.c -m32 -mtune=generic -march=x86-64 -auxbase hello -O2 -w -version -o hello.s GNU C (GCC) version 4.8.4 20140911 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.4, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory x86_install/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: x86_install/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/include /usr/local/include x86_install/include x86_install/lib/gcc/x86_64-unknown-linux-gnu/4.8.4/include-fixed /usr/include End of search list. GNU C (GCC) version 4.8.4 20140911 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.4, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 741d6eabab2d80d9f09742b3a0e5d8b6 hello.c: In function 'fn1': hello.c:7:5: error: type mismatch in binary expression int fn1 () ^ long int long int long unsigned int D.1709 = D.1708 | 2248593032; hello.c:7:5: internal compiler error: verify_gimple failed 0xa9362b verify_gimple_in_seq(gimple_statement_d*) gcc-4.8-branch/gcc/tree-cfg.c:4515 0x86182c gimplify_body(tree_node*, bool) gcc-4.8-branch/gcc/gimplify.c:8421 0x861aef gimplify_function_tree(tree_node*) gcc-4.8-branch/gcc/gimplify.c:8534 0x6a8903 cgraph_analyze_function gcc-4.8-branch/gcc/cgraphunit.c:665 0x6ab3f0 cgraph_analyze_functions gcc-4.8-branch/gcc/cgraphunit.c:973 0x6ab87f finalize_compilation_unit() gcc-4.8-branch/gcc/cgraphunit.c:2119 0x54e284 c_write_global_declarations() gcc-4.8-branch/gcc/c/c-decl.c:10120 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Btw, why is it recording twice a temporary equivalence? Might be simpler even with /* Now invalidate all equivalencies we have to invalidate. */ unsigned i; sbitmap_iterator bi; EXECUTE_IF_SET_IN_BITMAP (to_invalidate, 0, i, bi) record_temporary_equivalence (ssa_name (i), NULL_TREE, stack);
[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Do you use a linker plugin with LTO? That is, what's the value of HAVE_LTO_PLUGIN configure computes for you? ./gcc/auto-host.h:#define HAVE_LTO_PLUGIN 2 Do you happen to run a binutils and have lto_plugin.so installed as auto-load? No idea, whether it does for some reasons automatically. I have: * An ancient binutils-2.20.51.0.2 under /usr/bin, which doesn't support plugins * A self-built binutils-gdb trunk, configured with: --prefix=... --with-python LDFLAGS=-L.../python/lib --enable-plugins and built with the system GCC 4.4 * GCC 5 configured with --prefix=... --with-plugin-ld=/local_users/.../bin/ld --enable-languages=... It seems that lto-plugin.c doesn't reject objects if COLLECT_GCC_OPTIONS contains -fno-lto (but only -fno-use-linker-plugin). Thus can you try if [... patch for lto-plugin/lto-plugin.c ...] fixes it for you? Unfortunately, it doesn't. I tried linking with only -flto and with additionally -fno-use-linker-plugin or -fuse-linker-plugin. And with and without placing the self-compiled ld in the PATH. Plus the same with and without your patch. In all case, I get the lto1 in the output. Example: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/data/local_users/tobiasb/gcc/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper [...] COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto' '-mtune=generic' '-march=x86-64' [...]/collect2 [...] [...] COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-strict-overflow' '-mtune=generic' '-march=x86-64' '-v' '-fno-use-linker-plugin' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/cc8XPZLu.ltrans.out' '-fwpa' [...]/lto1 [...] [...]
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515
--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
Oops, that's not 100% the same. But
/* Now invalidate all equivalencies we have to invalidate. */
for (unsigned int i = 1; i num_ssa_names; ++i)
{
tree name = ssa_name (i);
if (!name)
continue;
tree val = SSA_NAME_VALUE (name);
if (TREE_CODE (val) == SSA_NAME
bitmap_bit_p (to_invalidate, SSA_NAME_VERSION (val)))
record_temporary_equivalence (name, NULL_TREE, stack);
}
unsigned i;
bitmap_iterator bi;
EXECUTE_IF_SET_IN_BITMAP (to_invalidate, 0, i, bi)
{
tree name = ssa_name (i);
if (SSA_NAME_VALUE (ssa_name (i)))
record_temporary_equivalence (name, NULL_TREE, stack);
}
would be.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Testing that.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- Btw, are you sure all temporary equivalences are to SSA names only? ISTR we have memory equivalencies as well.
[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #2) COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto' '-mtune=generic' '-march=x86-64' [...]/collect2 [...] I haven't shown it, but the collect2 arguments doesn't contain the -fno-lto, only COLLECT_GCC_OPTIONS has it. And in collect2.c's main(), there is a check for else if (!strncmp (argv[i], -fno-lto, 8)) lto_mode = LTO_MODE_NONE; but that only operates on argv and not on COLLECT_GCC_OPTIONS.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #9 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- I use 32bit Linux, perhaps, that gives the difference. Regarding checking and O2 - I will read about this. Thanks for your note.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 33766 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33766action=edit non-working patch Of course this still walks all SSA names (but only once per BB), so it isn't really removing the quadraticness. Moreover the patch (see attachment) I was testing fails to bootstrap on the 4.9 branch, seemingly miscompiling stage2 gcc (and crashing in building stage2 libgcc in swap_tree_comparison called from IVOPTs). Eventually record_temporary_equivalences_from_stmts_at_dest depends on the exact ordering of record_temporary_equivalence calls (I do the invaldiate ones late). Jeff? As this is a regression from 4.9.0 appearing in 4.9.1 it's quite bad that this is now still unfixed given we are about to release 4.9.2. I'm out of here again ;)
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #73 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #71) I don't know the details and maybe I'm totally off here ... LRA is being used for ARM and there are almost the same amount of GP registers available on ARM than on SH. So either on ARM nobody has checked for such regressions, or there's something else going wrong or missing on SH? Or is it maybe really that SH R0-ness thing that makes everything work (or not work) totally different? I'm not sure about ARM. The problematic cases I've looked at are high R0 pressure cases and IRA decided to allocate equiv value registers to memory as most profitable ones. It looks that the remained code size inflation came from R0-ness, very limited base+display addressing, only one index register and so on. I'll attach the test cases for them to this PR after merge from trunk and commit current patches.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #74 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #73) I'm not sure about ARM. The problematic cases I've looked at are high R0 pressure cases and IRA decided to allocate equiv value registers to memory as most profitable ones. It looks that the remained code size inflation came from R0-ness, very limited base+display addressing, only one index register and so on. OK, makes sense. I'll attach the test cases for them to this PR after merge from trunk and commit current patches. Thanks!
[Bug lto/63603] [4.9/5 Regression] Linking with -fno-lto still invokes LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #4 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 21 Oct 2014, burnus at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63603
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
COLLECT_GCC_OPTIONS='-v' '-fno-use-linker-plugin' '-fno-lto'
'-mtune=generic' '-march=x86-64'
[...]/collect2 [...]
I haven't shown it, but the collect2 arguments doesn't contain the -fno-lto,
only COLLECT_GCC_OPTIONS has it.
And in collect2.c's main(), there is a check for
else if (!strncmp (argv[i], -fno-lto, 8))
lto_mode = LTO_MODE_NONE;
but that only operates on argv and not on COLLECT_GCC_OPTIONS.
That means that
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2.
*/
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC \
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
LINK_PLUGIN_SPEC \
%{flto|flto=*:%fcompare-debug*} \
%{flto} %{flto=*} %l LINK_PIE_SPEC \
doesn't pass on -fno-lto as expected. Does adding %{fno-lto} after
%{flto} work?
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org --- So to recap - apart from really fixing the quadraticness - it would be nice if we can just disable threading over backedges at -O1, thus for !flag_expensive_optimizations. Especially on the 4.9 branch.
[Bug target/63542] My build log is full of non-delegitimized UNSPEC UNSPEC_GOT (0) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63542 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 #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33767 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33767action=edit gcc5-pr63542.patch Untested fix.
[Bug tree-optimization/63563] [4.9/5 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5106 with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Oct 21 12:23:11 2014 New Revision: 216507 URL: https://gcc.gnu.org/viewcvs?rev=216507root=gccview=rev Log: PR tree-optimization/63563 * tree-vect-data-refs.c (vect_analyze_data_ref_accesses): Bail out if either dra or drb stmts are not normal loads/stores. * gcc.target/i386/pr63563.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63563.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/63563] [4.9/5 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5106 with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Oct 21 12:27:25 2014 New Revision: 216508 URL: https://gcc.gnu.org/viewcvs?rev=216508root=gccview=rev Log: PR tree-optimization/63563 * tree-vect-data-refs.c (vect_analyze_data_ref_accesses): Bail out if either dra or drb stmts are not normal loads/stores. * gcc.target/i386/pr63563.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63563.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
[Bug tree-optimization/63563] [4.9/5 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5106 with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63563 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug target/63424] Octave -O3 build: internal compiler error: in prepare_cmp_insn, at optabs.c:4237
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63424 Renlin Li renlin.li at arm dot com changed: What|Removed |Added CC||renlin.li at arm dot com --- Comment #1 from Renlin Li renlin.li at arm dot com --- uminv2di is missing in this specific case.
[Bug target/63223] [avr] Make jumptables work with -Wl,--section-start,.text=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 --- Comment #9 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Georg-Johann Lay from comment #8) (In reply to Jorn Wolfgang Rennecke from comment #4) (In reply to Georg-Johann Lay from comment #1) do_global_dtors is supposed to start at the start and increment from there. I see it used to be half-way wrong and half-way correct. (Starting at the start, decrementing for __AVR_HAVE_ELPM__, incrementing otherwise.) However, you now made it all the way use an incorrect order - starting at the end and incrementing from there. Is there a rationale for this? The old code was broken as it decremented begainning at the start address. The flaw never came apparent for __dtors_start = __dtors_end or with simulators that terminated in exit. The new code uses the same traverse direction like __do_global_ctors. Is the order of .ctors, .dtors defined in any way? I.e. how do you express that constructor A must run before constructor B in the C program? Same for destructors. The C++ standard says that destructors have to run in reverse order of completion of constructors. crtstuff.c:__do_global_ctors_aux starts at the first constructor, and increments from there; crtstuff.c:__do_global_dtors_aux starts at the last destructor, and decrements from there.
[Bug target/63223] [avr] Make jumptables work with -Wl,--section-start,.text=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 --- Comment #10 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 33768 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33768action=edit patch for dtor direction I have this patch for fixing the direction of the dtor execution, but I got stuck trying to write a testcase.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #33 from Stupachenko Evgeny evstupac at gmail dot com ---
Created attachment 33769
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769action=edit
patch includes 3 patches fixing darwin bootstrap
It looks like data constant LC0 generated from pushtf not treated as GOT
dependent or treated as unchanged (assuming it depends on unchanged ebx) at
darwin reload pass.
RELOAD PASS:
(insn/f 106 8 2 2 (parallel [
(set (reg:SI 0 ax [98])
(unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT))
(clobber (reg:CC 17 flags))
]) 679 {set_got}
(expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT)
(expr_list:REG_CFA_FLUSH_QUEUE (nil)
(nil
.
For some reason on darwin AX is set here without spilling previous value.
On Linux AX is spilled and filled in appropriate place.
After that while reading LC0 on darwin we use incorrect GOT register.
(insn 115 41 116 6 (set (reg:SI 0 ax [128])
(plus:SI (reg:SI 0 ax [98])
(const:SI (unspec:SI [
(symbol_ref/u:SI (*LC0) [flags 0x2])
] UNSPEC_MACHOPIC_OFFSET frexpq.c:1319 213 {*leasi}
(expr_list:REG_EQUAL (symbol_ref/u:SI (*LC0) [flags 0x2])
(nil)))
...
Do you have any ideas where darwin can treat the LC0 symbol so?
Please try attached patch (includes all fixes) moving pushtf split earlier. The
bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of 216304).
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #25 from Yury Gribov y.gribov at samsung dot com --- Can we close this?
[Bug c++/63609] New: incompatibility with C++11 standard on 14.5.6.2 Partial ordering of function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63609
Bug ID: 63609
Summary: incompatibility with C++11 standard on 14.5.6.2
Partial ordering of function templates
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dccmmccd1 at gmail dot com
The following example is taken (with small modifications to make it compile)
from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf 14.5.6.2
(item 3) :
#include iostream
struct A {};
templateclass T
struct B {
templateclass R void operator*(R) { // #1
std::cout 1 std::endl;
}
};
templateclass T, class R
void operator*(T, R) { // #2
std::cout 2 std::endl;
}
int main() {
A a;
BA b;
b * a; //should print 1
}
Unless this was removed from the final c++11 standard I believe this has to be
legal c++ code, but g++ (4.8.3) gives the following error:
test_templates.cpp: In function ‘int main()’:
test_templates.cpp:20:5: error: ambiguous overload for ‘operator*’ (operand
types are ‘BA’ and ‘A’)
b * a; //should print 1
^
test_templates.cpp:20:5: note: candidates are:
test_templates.cpp:7:26: note: void BT::operator*(R) [with R = A; T = A]
templateclass R void operator*(R) { // #1
^
test_templates.cpp:13:6: note: void operator*(T, R) [with T = BA; R = A]
void operator*(T, R) { // #2
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #34 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bootstrap completed with the patch in comment 33 applied on top of r216304 and configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.10p-216304p1 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 Thanks for the patch.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #10 from Wilco wdijkstr at arm dot com --- The loops shown are not the correct inner loops for those options - with -ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the question is why GCC doesn't unroll vectorized loops like LLVM? GCC: .L24: ldrq3, [x13, x5] addx6, x6, 1 ldrq2, [x16, x5] cmpx6, x12 addx5, x5, 16 fmlav1.2d, v3.2d, v2.2d bcc.L24 LLVM: .LBB2_12: ldurq2, [x8, #-16] ldrq3, [x8], #32 ldurq4, [x21, #-16] ldrq5, [x21], #32 fmlav1.2d, v2.2d, v4.2d fmlav0.2d, v3.2d, v5.2d subx30, x30, #4// =4 cbnzx30, .LBB2_12
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Wilco from comment #10) The loops shown are not the correct inner loops for those options - with -ffast-math they are vectorized. LLVM unrolls 2x but GCC doesn't. So the question is why GCC doesn't unroll vectorized loops like LLVM? Because unrolling is not enabled at -O3. Try adding -funroll-loops.
[Bug target/63610] New: OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 Bug ID: 63610 Summary: OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vbraun at physics dot upenn.edu Trying to bulid gcc on OSX 10.10 with the Apple command line tools. So I first compile MPIR/MPFR/MPC with clang, then bootstrap gcc. This works so far (the patch from PR target/61407 for dealing with the version parsing is applied). But the newly-built gcc can't successfully compile MPIR, and I'm getting the testsuite failures below. The failure is only present if I both enable C++ (--enable-cxx in the MPIR configure), build a shared library, and set optimization to -O0 or -O1 (whereas -O2 works). Steps to reproduce (in the MPIR 2.6.0 source directory): $ export CFLAGS=-O0 $ ./configure --enable-cxx --disable-static $ make $ make check [...] make check-TESTS /bin/sh: line 1: 59465 Segmentation fault: 11 $tst t-bswap.log-t 21 FAIL: t-bswap PASS: t-constants PASS: t-count_zeros PASS: t-gmpmax PASS: t-hightomask PASS: t-modlinv PASS: t-parity /bin/sh: line 1: 59648 Segmentation fault: 11 $tst t-popc.log-t 21 FAIL: t-popc PASS: t-sub = 2 of 9 tests failed See tests/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = make[5]: *** [test-suite.log] Error 1 make[4]: *** [check-TESTS] Error 2 make[3]: *** [check-am] Error 2 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 Apart from the segfault, there is nothing in the log (full log attached) that indicates a failure. It seems that lower optimization leaves something in the binary that interacts badly with C++ support, but I don't have a better testcase. It is not just in MPIR, I get similar looking segfaults in other shared libraries when C++ is involved. Others have been able to reproduce the same testsuite failure on OSX. Works fine on Linux x86_64 with same versions of everything (except that gcc is used to bootstrap, of course). Stack backtrace from the t-popc test (full gdb log attached): #0 0x7fff86172432 in __block_descriptor_tmp227 () from /usr/lib/system/libdyld.dylib #1 0x7fff5fbffa80 in ?? () #2 0x0001000ca0d0 in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #3 0x011d in ?? () #4 0x0001000223c1 in __gmp_randget_mt (rstate=0x7fff5fbffb60, dest=0x7fff5fbffab0, nbits=32) at randmt.c:256 #5 0x00010006d81d in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #6 0x00010006d71c in ?? () from /Users/vbraun/Code/mpir-2.6.0/.libs/libmpir.11.dylib #7 0x00010f8c in main () at t-popc.c:60 (gdb) frame 4 #4 0x0001000223c1 in __gmp_randget_mt (rstate=0x7fff5fbffb60, dest=0x7fff5fbffab0, nbits=32) at randmt.c:256 256 NEXT_RANDOM; The NEXT_RANDOM macro is just the next step of MPIR's Mersenne twister, it only does elementary bit operations on the state variable. It also only fails after the 70th iteration of the outermost loop. Successive runs always fail in the same __block_descriptor_tmp227. The other failing testcase t-bswap also segfaults in the Mersenne twister.
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #1 from Volker Braun vbraun at physics dot upenn.edu --- Created attachment 33770 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33770action=edit Log of the MPIR compilation ending in the testsuite failure
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #3 from Volker Braun vbraun at physics dot upenn.edu --- Created attachment 33773 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33773action=edit gdb log of the failing testcase
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #2 from Volker Braun vbraun at physics dot upenn.edu --- Created attachment 33771 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33771action=edit gcc -v output
[Bug c/63611] New: Invalid optimization for == on pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611
Bug ID: 63611
Summary: Invalid optimization for == on pointers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
gcc --version says
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
uname -a says
Linux bomb20 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
(The system is Linux Mint 17, based on Ubuntu 14.04.1 LTS.)
I've created a Gist at
https://gist.github.com/Keith-S-Thompson/60dc069f4823fb1c3209
but of course I'll include the information here.
The C standard's definition of == for pointers (N1570 6.5.9 paragraph 6)
says:
Two pointers compare equal if and only if both are null pointers, both
are pointers to the same object (including a pointer to an object and a
subobject at its beginning) or function, both are pointers to one past
the last element of the same array object, or one is a pointer to one
past the end of one array object and the other is a pointer to the start
of a different array object that happens to immediately follow the first
array object in the address space.
which implies that the test program below should print (among other output)
one of the following:
- y immediately follows x followed by ok;
- x immediately follows y followed by ok; or
- x and y are not adjacent
Instead, when compiled with gcc, it prints inconsistent behavior:
It appears that gcc is assuming that a pointer just past the end of one
declared object cannot be equal to a pointer to the beginning of another
object, when the two objects are not subobjects of the same containing
object. Examining an assembly listing indicates that the code to print
ok is not even generated, implying that this is an optimization bug
(that occurs even at -O0.
I don't expect that this is a common use case, but the compiled program
does behave in a manner inconsistent with the standard's requirements.
I see the same behavior with a copy of gcc 4.9.1 built from source on the
same system. (I also see it with clang 3.5-1ubuntu1, but with the order
of x and y reversed; that's not directly relevant to this bug report,
but it's mildly interesting.)
The command line used to compile and execute the program is:
$ gcc -std=c11 -pedantic -Wall -Wextra pointer_equality_bug.c -o
pointer_equality_bug ./pointer_equality_bug
The output on my system is:
x = 0x7fff2a94a1d0
x0 = 0x7fff2a94a1d0
x1 = 0x7fff2a94a250
y = 0x7fff2a94a250
y0 = 0x7fff2a94a250
y1 = 0x7fff2a94a2d0
y immediately follows x
inconsistent behavior:
0x7fff2a94a250 !=
0x7fff2a94a250
And the program itself (73 lines, making up the remainder of this description)
is:
#include stdio.h
#include stdlib.h
int main(void) {
typedef struct {
int arr[32];
} element;
element x[1];
element y[1];
element *const x0 = x;
element *const x1 = x0 + 1;
element *const y0 = y;
element *const y1 = y0 + 1;
/*
* x and y will typically be adjacent in memory.
* x0 points to x; x1 points just past it.
* y0 points to y; y1 points just past it.
* We should have x1 == y0 if and only if y immediately follows x.
* We should have y1 == x0 if and only if x immediately follows y.
*/
printf(x = %p\nx0 = %p\nx1 = %p\ny = %p\ny0 = %p\ny1 = %p\n,
(void*)x, (void*)x0, (void*)x1,
(void*)y, (void*)y0, (void*)y1);
if (x1 == y0) {
puts(y immediately follows x);
if (x + 1 == y) {
puts(ok);
}
else if (x + 1 != y) {
printf(inconsistent behavior:\n
%p !=\n
%p\n,
(void*)(x + 1),
(void*)y);
exit(EXIT_FAILURE);
}
else {
printf(inconsistent behavior:\n
%p !=\n
%p\n,
(void*)(x + 1),
(void*)y);
exit(EXIT_FAILURE);
}
}
else if (y1 == x0) {
puts(x immediately follows y);
if (y + 1 == x) {
puts(ok);
}
else if (y + 1 != x) {
printf(inconsistent behavior:\n
%p !=\n
%p\n,
(void*)(y + 1),
(void*)x);
exit(EXIT_FAILURE);
}
else {
printf(inconsistent behavior:\n
%p !=\n
%p\n,
(void*)(y + 1),
(void*)x);
exit(EXIT_FAILURE);
}
}
else {
puts(x and y are not adjacent);
}
}
[Bug c/63611] Invalid optimization for == on pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611 --- Comment #1 from Keith Thompson Keith.S.Thompson at gmail dot com --- A bug report for a similar issue with clang is here: http://llvm.org/bugs/show_bug.cgi?id=21327
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #12 from Evandro Menezes e.menezes at samsung dot com --- Created attachment 33774 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33774action=edit Simple test-case
[Bug c/63612] New: #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612
Bug ID: 63612
Summary: #pragma breaks if...else
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: q@rsn-tech.co.uk
The following program fails to compile, giving the error else without a
previous if. Removing (or commenting out) the #pragma restores correct
behaviour.
int main (int argc, char *argv[])
{
if (argc == 1)
return 1;
#pragma message (This is a message)
else
return 0;
}
Other valid pragmas (such as #pragma pack) also exhibit this bug, but invalid
ones (like #pragma asasdadf) don't, nor do other preprocessor directives (such
as #define FOO).
It exists in at least two builds of gcc 4.8.3, in ARM cross-compilation and
native x64:
$ /opt/Xilinx/SDK/current/gnu/arm/lin/arm-xilinx-eabi/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/Xilinx/SDK/current/gnu/arm/lin/arm-xilinx-eabi/bin/gcc
Target: arm-xilinx-eabi
Configured with:
/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/src/gcc-4.8-2014.05/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-xilinx-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-arch=armv7-a --with-cpu=cortex-a9 --with-float=softfp
--with-fpu=neon-fp16 --disable-multilib --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2014
-D__CS_SOURCERYGXX_MIN__=5 -D__CS_SOURCERYGXX_REV__=22'
--enable-languages=c,c++ --disable-shared --enable-lto --with-newlib
--with-pkgversion='Sourcery CodeBench Lite 2014.05-22'
--with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-xilinx-eabi
--with-build-sysroot=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi
--with-gmp=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-isl=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--with-cloog=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/obj/pkg-2014.05-22-arm-xilinx-eabi/xilinx-2014.05-22-arm-xilinx-eabi.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --disable-libatomic --disable-libssp
--enable-poison-system-directories
--with-build-time-tools=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi/bin
--with-build-time-tools=/scratch/janisjo/build7/2014.05-xilinx-eabi-preview/install/opt/codesourcery/arm-xilinx-eabi/bin
SED=sed
Thread model: single
gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-22)
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
[Bug c/63611] Invalid optimization for == on pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63611 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org --- See bug 61502. The last comment there appears to indicate a bug, but the test given here doesn't based on my understanding that whether two objects follow each other need not be constant for all comparisons. *** This bug has been marked as a duplicate of bug 61502 ***
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||Keith.S.Thompson at gmail dot com --- Comment #5 from Joseph S. Myers jsm28 at gcc dot gnu.org --- *** Bug 63611 has been marked as a duplicate of this bug. ***
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- pragma are considered a statement.
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I should say some of the pragma's are considered statements while others are not.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #26 from Paul H. Hargrove PHHargrove at lbl dot gov --- (In reply to Yury Gribov from comment #25) Can we close this? Just tried to build the released 4.8.3 and still see the original problem (see error messages below). Same is true at the tip of the gcc-4_8-branch in svn (at r216525). However, 4.9.1 is fine. So, please don't close if 4.8.x is still open to bug fixes. If 4.8. is closed, then this bug can be closed too. -Paul libtool: compile: /home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc/xgcc -shared-libgcc -B/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc -nostdinc++ -L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src -L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../libsanitizer/sanitizer_common -I ../../../../libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/i686-pc-linux-gnu -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -g -O0 -D_GNU_SOURCE -MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc -fPIC -DPIC -o .libs/sanitizer_linux.o ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 'void __sanitizer::internal__exit(int)': ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11: error: '__NR_exit_group' was not declared in this scope syscall(__NR_exit_group, exitcode); ^ make[4]: *** [sanitizer_linux.lo] Error 1 make[4]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer/sanitizer_common' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer' make[2]: *** [all-stage1-target-libsanitizer] Error 2 make[2]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD' make: *** [all] Error 2
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #6 from Keith Thompson Keith.S.Thompson at gmail dot com --- In the test case for Bug 63611 (marked as a duplicate of this one) we have: element x[1]; element y[1]; element *const x0 = x; element *const x1 = x0 + 1; element *const y0 = y; When the test case is executed, the condition (x1 == y0) is true when it's evaluated, but the condition (x + 1 == y) (which I argue is equivalent) is false when it's evaluated 2 lines later. I don't believe that DR#260 applies, since there are no indeterminate values being used here. Which means, I think, that N1570 6.2.4p2: An object exists, has a constant address, and retains its last-stored value throughout its lifetime. does apply. Whether x follows y or y follows x in memory, or neither, is unimportant. The problem is that the == comparison is behaving inconsistently for the same two pointer values. I'm unconvinced by the argument (if I understand it correctly) that the objects x and y might be adjacent when the first comparison is evaluated, but not when the second is evaluated. I believe that would violate the requirement that objects have constant addresses and retain their last-stored values. Furthermore, even if relocating objects so they're no long adjacent is permitted by the language, I don't believe gcc (or the code that it generates) is actually doing so in this case.
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote: their last-stored values. Furthermore, even if relocating objects so they're no long adjacent is permitted by the language, I don't believe gcc (or the code that it generates) is actually doing so in this case. Really, it's a bad idea to apply concepts such as actually doing so to understanding the semantics of C, specified as a high-level language. happens to immediately follow the first array object in the address space in the high-level language need not satisfy any particular rules you might expect from thinking of C as relating to particular hardware, only the rules that can be deduced from the C standard (which as far as I can tell, do not say that follows is constant just because the addresses of the two objects in question are constant - or anything else such as that you can't have x + 1 == y and y + 1 == x, which you might expect from relating things to hardware rather than to standard requirements).
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612 --- Comment #3 from steveren q@rsn-tech.co.uk --- That seems strange and counterintuitive to say the least. FWIW, three other compilers I've got to hand - clang on Linux, Visual C++ and an old Borland compiler on Windows - all do exactly as I'd expect, printing a compile-time message without it affecting the code semantics. Open64 silently ignores the pragma but the code still compiles and runs corectly. Is there any public discussion of the rationale behind this design decision? I've not been able to find anything. Thanks.
[Bug c/63612] #pragma breaks if...else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63612 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 63326. *** This bug has been marked as a duplicate of bug 63326 ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||q@rsn-tech.co.uk --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63612 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #8 from Keith Thompson Keith.S.Thompson at gmail dot com --- I'm not (deliberately) considering anything other than the requirements of the C standard. The standard talks about an array object immediately following another array object in the address space. Since that phrase is used in normative wording in the standard, I presume it's meaningful. Since the term is not otherwise defined, I presume that the intended meaning is one that follows reasonably clearly from the wording. The test program for Bug 63611, when I execute it, prints the string y immediately follows x, followed by the string inconsistent behavior:. Are you saying it's possible that y immediately follows x in the address space when that line of output is printed, and that y *doesn't* immediately follow x in the address space when inconsistent behavior: is printed? If so, can you describe what the word follows means in this context? If it has a meaning that permits such behavior, can you cite a source that indicates that that's how the authors of the standard meant it?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #75 from Kazumoto Kojima kkojima at gcc dot gnu.org --- FYI, merge from trunk revision 216447 as r216529. I've fixed c#55, c#59, c#61 and c#66 so to match this merge and committed them on sh-lra as r216532, r216533, r216533 and r216535, respectively.
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
If I apply this change
Index: ipa-icf.c
===
--- ipa-icf.c(revision 216524)
+++ ipa-icf.c(working copy)
@@ -584,8 +584,12 @@
|| (DECL_COMDAT_GROUP (original-decl)
(DECL_COMDAT_GROUP (original-decl)
== DECL_COMDAT_GROUP (alias-decl)
-local_original
- = dyn_cast cgraph_node * (original-noninterposable_alias ());
+{
+ local_original
+= dyn_cast cgraph_node * (original-noninterposable_alias ());
+ if (!local_original)
+return false;
+}
if (redirect_callers)
{
, the following error occurs in stage1:
/usr/ccs/bin/ld: Invalid symbol type for plabel
(.libs/libstdc++.lax/libsupc++co
nvenience.a/tinfo.o, std::type_info::__is_pointer_p() const).
collect2: error: ld returned 1 exit status
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 21 Oct 2014, Keith.S.Thompson at gmail dot com wrote: Are you saying it's possible that y immediately follows x in the address space when that line of output is printed, and that y *doesn't* immediately follow x in the address space when inconsistent behavior: is printed? Yes. If so, can you describe what the word follows means in this context? follows is a binary relation with no constraints except when two objects are part of the same declared or allocated larger object. If part of the same declared or allocated larger object, it means that the bytes of the latter object immediately follow the bytes of the former object within the sequence of bytes making up the representation of the larger object (but this does *not* mean that it is necessarily valid to derive pointers to one of the smaller objects from pointers to the other, unless you are very careful about what sequences of conversions and arithmetic are involved; many cases of pointer conversions and arithmetic are less fully defined than one might naively expect, and the question of which of multiple possible objects is relevant in a particular context is one of the more poorly defined areas of C).
[Bug tree-optimization/63595] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 --- Comment #4 from Pat Haugen pthaugen at gcc dot gnu.org --- Created attachment 33775 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33775action=edit unreduced bzip2 testcase CPU2006 benchmark 447.dealII started segfaulting on PowerPC with revision 216305. Sorry for unreduced testcase, but wanted to get info out. ICF is commoning functions, but doing so incorrectly. Atached .bzip2 file can be compiled with 'g++ -S -m64 -O2 -mcpu=power7 tria.ii' to show the problem. Looking at the generated assembler, the following 3 functions: _ZNK13TriangulationILi3EE8end_faceEv _ZNK13TriangulationILi3EE7end_hexEv _ZNK13TriangulationILi3EE3endEv have all been changed to call '_ZNK13TriangulationILi3EE8end_quadEv' instead of having equivalent inline code. It appears the code for all 4 functions is the same in r216304, but with r216305 the 3 named functions are loading gpr3 with the addr of a local stack temp before calling '_ZNK13TriangulationILi3EE8end_quadEv', such that the desired values do not get stored off the original gpr3 value passed in (see '' line noted below). Following is generated asm for '_ZNK13TriangulationILi3EE8end_faceEv', the other two are similar: r216304: li 10,-1 std 4,8(3) stw 10,0(3) stw 10,4(3) blr 216305: mflr 0 std 0,16(1) stdu 1,-128(1) .cfi_def_cfa_offset 128 .cfi_offset 65, 16 addi 3,1,112 bl _ZNK13TriangulationILi3EE8end_quadEv nop addi 1,1,128 .cfi_def_cfa_offset 0 ld 0,16(1) mtlr 0 .cfi_restore 65 blr A side comment about the above ICF tranformation, it sure seems like this is going to degrade performance. We've went from a simple stackless leaf function to one that stacks a frame and makes a call.
[Bug tree-optimization/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #10 from Keith Thompson Keith.S.Thompson at gmail dot com --- I strongly disagree with your interpretation. Do you believe that the authors of the standard meant it the way you do? I suggest that the footnote: Two objects may be adjacent in memory because they are adjacent elements of a larger array or adjacent members of a structure with no padding between them, or because the implementation chose to place them so, even though they are unrelated. implies that the phrase adjacent in memory (which appears to be synonymous with immediately following in the address space) is intended to have a *consistent* meaning, even for unrelated objects. Two given objects may or may not be adjacent, and if they are adjacent they may appear in either order, entirely at the whim of the compiler. But I don't see a reasonable interpretation of the standard's wording that doesn't require == to behave consistently. Indeed, I believe that consistency (which gcc lacks) is the whole point of that wording. Any two pointer values are either equal or unequal. In the test program, the pointer values do not change, but they compare both equal and unequal at different points in the code. In my opinion, that's a clear violation of the required semantics. And I don't believe you've fullyl answered my question about what is meant by follows, at least not fully. I agree with you about the meaning for objects that are subobjects of some larger object, but for other cases you've essentially said that it's meaningless. I actually would have no problem with that, and I wouldn't complain if the standard left it unspecified -- but it doesn't.
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #27 from Daniel Richard G. skunk at iskunk dot org --- Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps fine, 4.8.3 still has the bug. (Oddly enough, the first configure run in the 4.9.1 bootstrap has the message checking for libsanitizer support... yes) Given the target milestone, I presume there's going to be a 4.8.4?
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 Matheus Izvekov mizvekov at gmail dot com changed: What|Removed |Added CC||mizvekov at gmail dot com --- Comment #18 from Matheus Izvekov mizvekov at gmail dot com --- Created attachment 33776 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33776action=edit CWG 1170 test case Compile with g++ -std=c++11 -DPUB=0 test.cc and it should print 'false' Compile with g++ -std=c++11 -DPUB=1 test.cc and it should print 'true'. Instead, GCC 4.9.1 prints true in both cases.
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 --- Comment #19 from Matheus Izvekov mizvekov at gmail dot com --- CWG 1170 is still not correctly implemented as of gcc 4.9.1 The attached test shows just this. Compile it with g++ -std=c++11 -DPUB=0 test.cc and g++ -std=c++11 -DPUB=1 test.cc. The one with PUB=0 should print 'false', while the one with PUB=1 should print 'true'. The test works as expected with clang 3.5.
