[Bug tree-optimization/62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #38 from amker at gcc dot gnu.org --- The first patch actually helping this case is at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00836.html But the real problem lies in scev/ivopt about how type conversion and scev overflow are handled. I am working on this. According to Richard, both the patch and the real fix are stage1 stuff. That's why it has been quite recently.
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Richard Biener changed: What|Removed |Added Component|tree-optimization |ipa Known to fail||5.0 --- Comment #30 from Richard Biener --- With all the patches I have for now we end up with a pure IPA issue: phase opt and generate : 193.97 (99%) usr 13.82 (93%) sys 207.75 (99%) wall 3311016 kB (94%) ggc ipa inlining heuristics : 140.48 (72%) usr 0.44 ( 3%) sys 141.13 (67%) wall 396289 kB (11%) ggc dominance computation : 2.99 ( 2%) usr 1.00 ( 7%) sys 3.89 ( 2%) wall 0 kB ( 0%) ggc integrated RA : 4.05 ( 2%) usr 0.85 ( 6%) sys 5.26 ( 3%) wall 1577496 kB (45%) ggc rest of compilation : 6.53 ( 3%) usr 1.67 (11%) sys 7.91 ( 4%) wall 155664 kB ( 4%) ggc unaccounted todo: 3.82 ( 2%) usr 1.07 ( 7%) sys 4.98 ( 2%) wall 0 kB ( 0%) ggc TOTAL : 195.4614.79 210.23 3514948 kB everything <= 1% dropped. I wonder what that unaccounted todo is ;)
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #31 from Richard Biener --- Author: rguenth Date: Fri Mar 13 08:47:14 2015 New Revision: 221409 URL: https://gcc.gnu.org/viewcvs?rev=221409&root=gcc&view=rev Log: 2015-03-10 Richard Biener PR middle-end/44563 * tree-cfgcleanup.c (split_bb_on_noreturn_calls): Remove. (cleanup_tree_cfg_1): Do not call it. (execute_cleanup_cfg_post_optimizing): Fixup the CFG here. (fixup_noreturn_call): Mark the stmt as control altering. * tree-cfg.c (execute_fixup_cfg): Do not dump the function here. (pass_data_fixup_cfg): Produce a dump file. * tree-ssa-dom.c: Include tree-cfgcleanup.h. (need_noreturn_fixup): New global. (pass_dominator::execute): Fixup queued noreturn calls. (optimize_stmt): Queue calls that became noreturn for fixup. * tree-ssa-forwprop.c (pass_forwprop::execute): Likewise. * tree-ssa-pre.c: Include tree-cfgcleanup.h. (el_to_fixup): New global. (eliminate_dom_walker::before_dom_childre): Queue calls that became noreturn for fixup. (eliminate): Fixup queued noreturn calls. * tree-ssa-propagate.c: Include tree-cfgcleanup.h. (substitute_and_fold_dom_walker): New member stmts_to_fixup. (substitute_and_fold_dom_walker::before_dom_children): Queue alls that became noreturn for fixup. (substitute_and_fold): Fixup queued noreturn calls. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfgcleanup.c trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-propagate.c
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #32 from Richard Biener --- Author: rguenth Date: Fri Mar 13 08:52:51 2015 New Revision: 221410 URL: https://gcc.gnu.org/viewcvs?rev=221410&root=gcc&view=rev Log: 2015-03-12 Richard Biener PR middle-end/44563 * tree-inline.c (gimple_expand_calls_inline): Walk BB backwards to avoid quadratic behavior with inline expansion splitting blocks. * tree-cfgcleanup.c (cleanup_tree_cfg_bb): Do not merge block with the successor if the predecessor will be merged with it. * tree-cfg.c (gimple_can_merge_blocks_p): We can't merge the entry block with its successor. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfgcleanup.c trunk/gcc/tree-inline.c
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #33 from Richard Biener --- Assigning to Honza - I wonder if there is any low-hanging fruit to improve things for GCC 5 still.
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #25 from Ramana Radhakrishnan --- Fixed presumably ?
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/65412] missing control flow optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65412 --- Comment #1 from Richard Biener --- I think there exist patches for if-to-switch conversion.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 CC||ebotcazou at gcc dot gnu.org Component|c++ |middle-end
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 --- Comment #3 from Richard Biener --- ISTR there is an even older bug for this - PR36043.
[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Thus confirmed at least. IIRC this is a tricky area ;) (but the issue is surely latent since quite some time)
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #30 from Richard Biener --- (In reply to Alan Modra from comment #28) > Created attachment 35024 [details] > modified testcase without bswap optimization > > This modified testcase avoids triggering the bswap optimization but still > shows a failure at -O3. So definitely not a problem caused by Thomas' patch. > > -O3 -fno-tree-slp-vectorize is OK > > -O3 slp dump shows weird offset of +12 between vector loads rather than +16 > as is usual Well, that's the realign-load sequence. Load ptr & ~15 and then load (ptr + 12) & ~15. If ptr is already aligned both loads should load from the same location. SLP happens in md4_update only (but it's quite trivial).
[Bug rtl-optimization/65371] arm loop with volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
--- Comment #2 from Stuart ---
I compiled it for x86_64 and thought it was fine, however, after your comment I
tried compiling it with clang/llvm and can see the difference (I'm not
particularly familiar with the full instruction set)...
I've found another case which could also be improved:
func.c:
#include
#define PERIPH_BASE0x4000
#define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE)
typedef struct
{
volatile uint32_t REG1;
} PERIPH_TypeDef;
void func(uint16_t a)
{
uint32_t t = PERIPH->REG1;
while ((uint16_t) (PERIPH->REG1 - t) < a) { }
}
gives:
:
0: f04f 4380 mov.w r3, #1073741824 ; 0x4000
4: 461amov r2, r3
6: 6819ldr r1, [r3, #0]
8: 6813ldr r3, [r2, #0]
a: 1a5bsubsr3, r3, r1
c: b29buxthr3, r3
e: 4283cmp r3, r0
10: d3fabcc.n 8
12: 4770bx lr
For some reason r3 is moved in to r2 and then value at the address in r2 is
loaded in to r3 for the loop!
I would expect the following:
:
0: f04f 4180 mov.w r1, #1073741824 ; 0x4000
4: 680aldr r2, [r1, #0]
6: 680bldr r3, [r1, #0]
8: 1a9bsubsr3, r3, r2
a: b29buxthr3, r3
c: 4283cmp r3, r0
e: d3fabcc.n 6
10: 4770bx lr
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|[C++11] GCC rejects |[5 Regression] [C++11] GCC |constexpr variable |rejects constexpr variable |definitions with valid |definitions with valid |initialization |initialization Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, started with r214941, which did away with try_move_mult_to_index that tried to replace &a[idx] p+ s * delta with &a[idx + delta]. I think the fix is to teach cxx_fold_indirect_ref to do similar transformation.
[Bug target/63347] [4.9 regression] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Richard Biener changed: What|Removed |Added Known to work||5.0 Target Milestone|--- |4.9.3
[Bug c++/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 Ever confirmed|0 |1
[Bug c++/65415] using, base class static member function template, and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65415 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. EDG and Clang both accept it.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Fixing.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409
--- Comment #4 from Jakub Jelinek ---
I've so far came up with:
--- gcc/expr.c.jj2015-01-19 09:31:15.0 +0100
+++ gcc/expr.c2015-03-13 11:30:25.699805379 +0100
@@ -6656,14 +6656,18 @@ store_field (rtx target, HOST_WIDE_INT b
&& (bitpos % BITS_PER_UNIT) == 0
&& (bitsize % BITS_PER_UNIT) == 0)))
{
- gcc_assert (MEM_P (target) && MEM_P (temp)
+ gcc_assert (MEM_P (target)
+ && (MEM_P (temp) || GET_CODE (temp) == PARALLEL)
&& (bitpos % BITS_PER_UNIT) == 0);
target = adjust_address (target, VOIDmode, bitpos / BITS_PER_UNIT);
- emit_block_move (target, temp,
- GEN_INT ((bitsize + BITS_PER_UNIT - 1)
-/ BITS_PER_UNIT),
- BLOCK_OP_NORMAL);
+ HOST_WIDE_INT bytesize
+= (bitsize + BITS_PER_UNIT - 1) / BITS_PER_UNIT;
+ if (GET_CODE (temp) == PARALLEL)
+emit_group_store (target, temp, TREE_TYPE (exp), bytesize);
+ else
+emit_block_move (target, temp, GEN_INT (bytesize),
+ BLOCK_OP_NORMAL);
return const0_rtx;
}
which seems to DTRT in this case.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #5 from Eric Botcazou --- This looks redundant to me, the following is sufficient: Index: expr.c === --- expr.c (revision 221407) +++ expr.c (working copy) @@ -6645,11 +6645,12 @@ store_field (rtx target, HOST_WIDE_INT b && mode != TYPE_MODE (TREE_TYPE (exp))) temp = convert_modes (mode, TYPE_MODE (TREE_TYPE (exp)), temp, 1); - /* If the modes of TEMP and TARGET are both BLKmode, both -must be in memory and BITPOS must be aligned on a byte -boundary. If so, we simply do a block copy. Likewise -for a BLKmode-like TARGET. */ - if (GET_MODE (temp) == BLKmode + /* If TEMP is not a PARALLEL (see below) and its mode and that of TARGET +are both BLKmode, both must be in memory and BITPOS must be aligned +on a byte boundary. If so, we simply do a block copy. Likewise for +a BLKmode-like TARGET. */ + if (GET_CODE (temp) != PARALLEL + && GET_MODE (temp) == BLKmode && (GET_MODE (target) == BLKmode || (MEM_P (target) && GET_MODE_CLASS (GET_MODE (target)) == MODE_INT
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- So let me try that out.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #6 from Jakub Jelinek --- Doesn't it generate worse code though? I mean, for BLKmode PARALLEL, forcing it into some very wide pseudo (TImode in this case, perhaps OImode for even larger ones?) and then storing might be more expensive than what my patch does.
[Bug target/64600] [5 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #14 from ktkachov at gcc dot gnu.org --- Should be fixed on trunk. Joel, can you please confirm for you and close if appropriate?
[Bug target/64600] [5 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 --- Comment #13 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Mar 13 10:48:44 2015 New Revision: 221413 URL: https://gcc.gnu.org/viewcvs?rev=221413&root=gcc&view=rev Log: [ARM] PR target/64600 Fix another ICE with -mtune=xscale: properly sign-extend mask during constant splitting PR target/64600 * config/arm/arm.c (arm_gen_constant, AND case): Use ARM_SIGN_EXTEND when constructing AND mask. PR target/64600 * gcc.target/arm/pr64600_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr64600_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #7 from Jakub Jelinek --- Ok, the pessimization (your patch vs. my patch) is only at -O0: +movl%edx, %ecx +movl%ecx, %esi +movq%rdx, %rdi +movabsq$-4294967296, %rcx +andq%rdi, %rcx +orq%rsi, %rcx +movq%rcx, %rdx is added, for -O1+ the optimizers manage to fix it up.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #8 from Eric Botcazou --- The difference is that we go through a pseudo with my version, but the code is optimal at -O1: call_Z8copy_foo3Foo movq%rax, a(%rip) movb%dl, a+8(%rip) and the change looks safe enough for all the branches.
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #9 from Jakub Jelinek --- I agree for 4.8/4.9 that your version is safer. Anyway, you're the RTL maintainer, so I'll let you decide.
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Matthias Klose changed: What|Removed |Added Target|aarch64-linux-gnu |aarch64-linux-gnu, ||arm-linux-gnuebihf CC||ramana at gcc dot gnu.org --- Comment #1 from Matthias Klose --- same on arm-linux-gnuebihf
[Bug libgcc/57221] [4.8/4.9/5 regression] libgcc symbol visibility changes break Android blobs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57221 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 CC||mkuvyrkov at gcc dot gnu.org, ||ramana at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.0, 4.8.1, 4.8.2, 4.9.0, ||4.9.1, 5.0 --- Comment #8 from Ramana Radhakrishnan --- (In reply to Bernhard Rosenkränzer from comment #3) > Created attachment 30068 [details] > Another patch > > This patch is needed as well to make sure Bionic can re-export __aeabi_lmul > and friends. > > Unlike the other patch, this one should be fixed before being applied: There > should be a #ifdef around the added attribute (not sure if there's already a > define for whether or not the target system is Android?) Uggh, As you say this should be just for Android foo - please work out how to deal with this to handle Android and not affect all standard Linux targets. Maxim - can you handle this please ? regards Ramana
[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #15 from Ramana Radhakrishnan --- I'm going to remove the regression marker on this as this is now just purely further code size improvements. Please submit patches on gcc-patc...@gcc.gnu.org for further discussion. Patches attached to bug reports aren't reviewed.
[Bug target/65416] New: xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 Bug ID: 65416 Summary: xtensa: memory allocated by alloca is used before the stack pointer is updated Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Created attachment 35025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35025&action=edit preprocessed source with a single function that demonstrates the issue Hi, I'm building gcc for xtensa linux. The function 'fork_inferior' has the following fragment: argv = (char **) alloca (4 * sizeof (char *)); argv[0] = shell_file; argv[1] = "-c"; argv[2] = shell_command; argv[3] = (char *) 0; that gcc compiles into this: addia3, sp, -32 l32ra4, .LC23 s32i.n a2, a3, 8 movi.n a2, 0 s32i.n a2, a3, 12 l32ra2, .LC26 s32i.n a3, a4, 0 l32i.n a4, a7, 0 l32i.n a2, a2, 0 s32i.n a4, a3, 0 l32ra4, .LC25 s32i.n a2, a7, 20 l32i.n a10, a7, 24 l32ra2, .LC27 movsp sp, a3 Here argv is a3. The space below the stack pointer is used before the stack pointer is updated. This is reproducible with gcc-4.8.3 and the current 5.0 mainline. Command line: xtensa-buildroot-linux-uclibc-gcc -mlongcalls -mtext-section-literals -pipe -Os -S -o fork-child.s fork-child.i Compilers: Using built-in specs. COLLECT_GCC=/home/jcmvbkbc/tmp/br/build-xea3/host/usr/bin/xtensa-buildroot-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/home/jcmvbkbc/tmp/br/build-xea3/host/usr/libexec/gcc/xtensa-buildroot-linux-uclibc/4.8.3/lto-wrapper Target: xtensa-buildroot-linux-uclibc Configured with: ./configure --prefix=/home/jcmvbkbc/tmp/br/build-xea3/host/usr --sysconfdir=/home/jcmvbkbc/tmp/br/build-xea3/host/etc --enable-static --target=xtensa-buildroot-linux-uclibc --with-sysroot=/home/jcmvbkbc/tmp/br/build-xea3/host/usr/xtensa-buildroot-linux-uclibc/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/home/jcmvbkbc/tmp/br/build-xea3/host/usr --with-mpfr=/home/jcmvbkbc/tmp/br/build-xea3/host/usr --enable-target-optspace --disable-libsanitizer --disable-tls --disable-libmudflap --enable-threads --with-mpc=/home/jcmvbkbc/tmp/br/build-xea3/host/usr --without-isl --without-cloog --disable-decimal-float --with-pkgversion='Buildroot 2014.08-4-ge3e7af8' --with-bugurl=http://bugs.buildroot.net/ --enable-languages=c,c++ --with-build-time-tools=/home/jcmvbkbc/tmp/br/build-xea3/host/usr/xtensa-buildroot-linux-uclibc/bin --enable-shared --disable-libgomp Thread model: posix gcc version 4.8.3 (Buildroot 2014.08-4-ge3e7af8) and Using built-in specs. COLLECT_GCC=/home/jcmvbkbc/ws/tensilica/projects/201409-call0/build-5.0.0-windowed-check/root/bin/xtensa-buildroot-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/home/jcmvbkbc/ws/tensilica/projects/201409-call0/build-5.0.0-windowed-check/root/libexec/gcc/xtensa-buildroot-linux-uclibc/5.0.0/lto-wrapper Target: xtensa-buildroot-linux-uclibc Configured with: ../gcc/configure --prefix=/home/jcmvbkbc/ws/tensilica/projects/201409-call0/build-5.0.0-windowed-check/root --target=xtensa-buildroot-linux-uclibc --disable-shared --disable-libssp --disable-libisl --enable-languages=c,c++ --with-sysroot=/home/jcmvbkbc/tmp/br/build-dejagnu-windowed/host/usr/xtensa-buildroot-linux-uclibc/sysroot --disable-threads --disable-tls Thread model: single gcc version 5.0.0 20150303 (experimental) (GCC)
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #3 from Bernd Edlinger ---
Hmm,
I tried this:
--- gcc/ipa-split.c.jj2015-02-08 21:13:01.0 +0100
+++ gcc/ipa-split.c2015-03-13 11:29:08.878923384 +0100
@@ -1509,6 +1509,16 @@ split_function (struct split_point *spli
|| DECL_BY_REFERENCE (DECL_RESULT (current_function_decl
gimple_call_set_return_slot_opt (call, true);
+ /* Re-insert a TSAN_FUNC_EXIT immediately _before_ the actual call,
+ because we are actually calling ourselves, so the call stack
+ should look correct this way, and it does not prevent the
+ possible tail-call optimization. */
+ if ((flag_sanitize & SANITIZE_THREAD) != 0
+ && !lookup_attribute ("no_sanitize_thread",
+DECL_ATTRIBUTES (current_function_decl)))
+gsi_insert_after (&gsi, gimple_build_call_internal (IFN_TSAN_FUNC_EXIT,
0),
+ GSI_NEW_STMT);
+
/* Update return value. This is bit tricky. When we do not return,
do nothing. When we return we might need to update return_bb
or produce a new return statement. */
BUT there are more problems (in another C file):
opcua_p_binary.c.103t.sink-OpcUa_Int32_P_NativeToWire (OpcUa_Int32_Wire * wire,
OpcUa_Int32 * native)
opcua_p_binary.c.103t.sink-{
opcua_p_binary.c.103t.sink- OpcUa_StatusCode retval.25;
opcua_p_binary.c.103t.sink-
opcua_p_binary.c.103t.sink- :
opcua_p_binary.c.103t.sink: retval.25_5 = OpcUa_Float_P_NativeToWire
(wire_2(D), native_3(D)); [tail call]
opcua_p_binary.c.103t.sink: return retval.25_5;
opcua_p_binary.c.103t.sink-
opcua_p_binary.c.103t.sink-}
--
opcua_p_binary.c.105t.tsan1-OpcUa_Int32_P_NativeToWire (OpcUa_Int32_Wire *
wire, OpcUa_Int32 * native)
opcua_p_binary.c.105t.tsan1-{
opcua_p_binary.c.105t.tsan1- OpcUa_StatusCode retval.25;
opcua_p_binary.c.105t.tsan1- void * _6;
opcua_p_binary.c.105t.tsan1-
opcua_p_binary.c.105t.tsan1- :
opcua_p_binary.c.105t.tsan1- _6 = __builtin_return_address (0);
opcua_p_binary.c.105t.tsan1- __builtin___tsan_func_entry (_6);
opcua_p_binary.c.105t.tsan1: retval.25_5 = OpcUa_Float_P_NativeToWire
(wire_2(D), native_3(D)); [tail call]
opcua_p_binary.c.105t.tsan1- __builtin___tsan_func_exit ();
opcua_p_binary.c.105t.tsan1: return retval.25_5;
opcua_p_binary.c.105t.tsan1-
opcua_p_binary.c.105t.tsan1-}
objdump -d shows this!
021755a0 :
21755a0: 55 push %rbp
21755a1: 53 push %rbx
21755a2: 48 89 fbmov%rdi,%rbx
21755a5: 48 89 f5mov%rsi,%rbp
21755a8: 48 83 ec 08 sub$0x8,%rsp
21755ac: 48 8b 7c 24 18 mov0x18(%rsp),%rdi
21755b1: e8 6a 72 29 fe callq 40c820 <__tsan_func_entry@plt>
21755b6: 48 83 c4 08 add$0x8,%rsp
21755ba: 48 89 eemov%rbp,%rsi
21755bd: 48 89 dfmov%rbx,%rdi
21755c0: 5b pop%rbx
21755c1: 5d pop%rbp
21755c2: e9 19 ff ff ff jmpq 21754e0
21755c7: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
21755ce: 00 00
[Bug go/65417] New: debug/elf: lacks support for PPC relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65417 Bug ID: 65417 Summary: debug/elf: lacks support for PPC relocations Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com tracking this here, because golang doesn't support ppc32 (yet). https://github.com/golang/go/issues/10118 debug/elf supports 64-bit powerpc, 32-bit and 64-bit arm, 386 and amd64 relocations, but not 32bit powerpc.
[Bug target/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65414 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 CC||avelenko at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- Alex Velenko was looking into something similar today.
[Bug libstdc++/64847] [5 Regression] FAIL: 30_threads/shared_lock/requirements/explicit_instantiation.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64847 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00701.html should fix this Actually no it won't, because it looks like HPUX supports pthread_wrlocK_t but not the timed-lock functions. In which case, it should have been fixed by r220161 as part of PR64368 And indeed I don't see a current failure at https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg01405.html https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg03251.html
[Bug tree-optimization/65418] New: [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418
Bug ID: 65418
Summary: [5 Regression] vim miscompilation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: jakub at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
__attribute__((noinline, noclone)) int
foo (int x)
{
if (x == '(' - 256 || x == '|' - 256 || x == '&' - 256 || x == 'n' - 256)
return 1;
return 0;
}
int
main ()
{
if (foo ('n' - 256) != 1
|| foo ('(' - 256) != 1
|| foo ('|' - 256) != 1
|| foo ('&' - 256) != 1
|| foo ('q' - 256) != 0)
__builtin_abort ();
return 0;
}
is miscompiled at -O2 starting with r216393.
[Bug tree-optimization/65418] [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-13 Ever confirmed|0 |1
[Bug tree-optimization/65418] [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Alan Modra changed: What|Removed |Added Attachment #35016|0 |1 is obsolete|| Attachment #35019|0 |1 is obsolete|| Attachment #35024|0 |1 is obsolete|| --- Comment #31 from Alan Modra --- Created attachment 35027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35027&action=edit reduced testcase
[Bug fortran/65359] [OOP] undefined output with array and inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65359 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.8.4, 4.9.2, and trunk (5.0). Note that the test compiled with 4.8.4 fails with a.out(3185,0x7fff7d157300) malloc: *** error for object 0x7fd4a9405aa0: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug
[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810 --- Comment #26 from David Malcolm --- (In reply to Ramana Radhakrishnan from comment #25) > Fixed presumably ? Mostly. The remaining issue with configure-time options reaching the jit is when gcc is configured with: --with-arch=native I attempted to fix that, but it appeared to be non-trivial, so I think I'll open that as a separate (non-arm) bug (sorry, have been on vacation in the meantime, and need to page it all back in to my brain...)
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #32 from Alan Modra --- Richi, ptr+12 is nonsense. Suppose ptr is 16k+1, then first vector loads from 16k and second from the same address since (16k+1+12) & ~15 == 16k. But we want to end up with 15 bytes from the first 16-byte aligned block and one byte from the *next* 16-byte aligned block, which means we must use ptr+16.
[Bug fortran/65397] [Coarrays][OOP] ICE in resolve_ordinary_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65397 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-13 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed on trunk (5.0 r221188) with -fcoarray=lib. The test compiles with -fcoarray=single and with 4.9.2 with -fcoarray=lib: is it a regression?
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #33 from Markus Trippelsdorf --- FWIW Alan's new testcase started to fail with r212452.
[Bug target/65416] xtensa: memory allocated by alloca is used before the stack pointer is updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416
--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
It's ok up to sched2 pass, but sched2 does the following to it:
;; ==
;; -- basic block 62 from 252 to 295 -- after reload
;; ==
;;0--> b 0: i 253 a3=[`*.LC13'] :nothing
;;1--> b 0: i 252 a10=a2 :nothing
;;2--> b 0: i 254 a10=call [a3] :nothing
;;3--> b 0: i 257 a11=[`*.LC22'] :nothing
;;4--> b 0: i 259 a3=[`*.LC13'] :nothing
;;5--> b 0: i 258 a10=a2 :nothing
;;6--> b 0: i 260 a10=call [a3] :nothing
;;7--> b 0: i 261 a11=[a7+0x4]:nothing
;;8--> b 0: i 262 a10=a2 :nothing
;;9--> b 0: i 264 a10=call [a3] :nothing
;; 10--> b 0: i 265 a3=sp-0x20 :nothing
;; 11--> b 0: i 271 a4=[`*.LC23'] :nothing
;; 12--> b 0: i 276 [a3+0x8]=a2 :nothing
;; 13--> b 0: i 277 a2=0:nothing
;; 14--> b 0: i 278 [a3+0xc]=a2 :nothing
;; 15--> b 0: i 279 a2=[`*.LC26'] :nothing
;; 16--> b 0: i 272 [a4]=a3 :nothing
;; 17--> b 0: i 626 a4=[a7] :nothing
;; 18--> b 0: i 280 a2=[a2] :nothing
;; 19--> b 0: i 273 [a3]=a4 :nothing
;; 20--> b 0: i 274 a4=[`*.LC25'] :nothing
;; 21--> b 0: i 627 [a7+0x14]=a2:nothing
;; 22--> b 0: i 281 a10=[a7+0x18] :nothing
;; 23--> b 0: i 282 a2=[`*.LC27'] :nothing
;; 24--> b 0: i 625 sp=a3 :nothing
;; 25--> b 0: i 275 [a3+0x4]=a4 :nothing
;; 26--> b 0: i 283 call [a2] :nothing
;; 27--> b 0: i 285 a2=[`*.LC28'] :nothing
;; 29--> b 0: i 286 a10=[a2]:nothing
;; 30--> b 0: i 287 a2=[`*.LC29'] :nothing
;; 32--> b 0: i 288 call [a2] :nothing
;; 33--> b 0: i 290 a3=[`*.LC30'] :nothing
;; 35--> b 0: i 291 a10=[a3]:nothing
;; 37--> b 0: i 293 call [a2] :nothing
;; 38--> b 0: i 628 a2=[a7+0x10]:nothing
;; 39--> b 0: i 302 a10=[`*.LC31'] :nothing
;; 40--> b 0: i 295 pc={(a2==0)?L657:pc}:nothing
;; Ready list (final):
;; total time = 40
;; new head = 253
;; new tail = 295
[Bug tree-optimization/60172] [4.9/5 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #26 from Joey Ye --- Regression disappeared from 4.9 branch since Aug 2014, though the problem discussed here is not yet confirmed solved.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #34 from Bill Schmidt --- (In reply to Markus Trippelsdorf from comment #29) > CCing Bill because this might be a bug in rs6000_analyze_swaps(). Adding -mno-optimize-swaps to Alan's example does not fix the problem, so no...
[Bug tree-optimization/65418] [5 Regression] vim miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65418 --- Comment #1 from Jakub Jelinek --- Created attachment 35028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35028&action=edit gcc5-pr65418.patch Untested fix.
[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143 --- Comment #2 from Balakrishnan B --- Can someone please confirm the bug?
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #35 from Jakub Jelinek --- Note to self. This is the case dr_explicit_realign: case of vectorizable_load. (ptr + 12) & -16L - i.e. vs_minus_1 * TYPE_ALIGN_UNIT (element) is reasonable for the case where the original stmt data ref is naturally aligned, but in this case it is an unaligned load and thus we can't use + 12 but should use + 15 instead. This is quite related to PR63341, but that was the dr_explicit_realign_optimized case, not dr_explicit_realign.
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400
--- Comment #4 from Bernd Edlinger ---
ok,
this should fix the second regression:
Index: tsan.c
===
--- tsan.c(revision 221355)
+++ tsan.c(working copy)
@@ -682,6 +682,7 @@
{
if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
instrument_builtin_call (gsi);
+ gimple_call_set_tail (as_a (stmt), false);
return true;
}
else if (is_gimple_assign (stmt)
--
opcua_p_binary.c.103t.sink-{
opcua_p_binary.c.103t.sink- OpcUa_StatusCode retval.25;
opcua_p_binary.c.103t.sink-
opcua_p_binary.c.103t.sink- :
opcua_p_binary.c.103t.sink: retval.25_5 = OpcUa_Float_P_NativeToWire
(wire_2(D), native_3(D)); [tail call]
opcua_p_binary.c.103t.sink: return retval.25_5;
opcua_p_binary.c.103t.sink-
opcua_p_binary.c.103t.sink-}
--
opcua_p_binary.c.105t.tsan1- :
opcua_p_binary.c.105t.tsan1- _6 = __builtin_return_address (0);
opcua_p_binary.c.105t.tsan1- __builtin___tsan_func_entry (_6);
opcua_p_binary.c.105t.tsan1: retval.25_5 = OpcUa_Float_P_NativeToWire
(wire_2(D), native_3(D));
opcua_p_binary.c.105t.tsan1- __builtin___tsan_func_exit ();
opcua_p_binary.c.105t.tsan1: return retval.25_5;
opcua_p_binary.c.105t.tsan1-
opcua_p_binary.c.105t.tsan1-}
see the "[tail call]" is removed,
and the generated code is now OK.
trying to use -O3 next.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #36 from Jakub Jelinek --- Created attachment 35029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35029&action=edit gcc5-pr65369.patch Untested fix.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65404
--- Comment #7 from Stéphane Graber ---
So with the cherry-picked fix, I get:
(vivid-powerpc-sbuild)root@winton-06:~# cat test.go
package main
/*
#include
now
void hello() {
printf("Hello world!\n");
}
*/
import "C"
func main() {
C.hello()
}
(vivid-powerpc-sbuild)root@winton-06:~# go build -v -x test.go
WORK=/tmp/go-build320378268
command-line-arguments
mkdir -p $WORK/command-line-arguments/_obj/
cd /root
CGO_LDFLAGS="-g" "-O2" /usr/lib/gcc/powerpc-linux-gnu/5/cgo -objdir
$WORK/command-line-arguments/_obj/ -gccgo -- -I
$WORK/command-line-arguments/_obj/ test.go
# command-line-arguments
./test.go:13:5: call of non-function C.hello
So cgo is now supported and I don't have to force it with CGO_ENABLED=1 but I
still can't use my cgo function.
[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65404 --- Comment #8 from Stéphane Graber --- Mathias suggested this may be #65417 but I'm not familiar enough with gccgo and cgo to know whether that's the case or not.
[Bug go/65404] cgo tool on powerpc-linux-gnu maybe incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65404 --- Comment #9 from Ian Lance Taylor --- It could be due to PR 65417, yes.
[Bug jit/64780] toplevel configure should reject jit as a language if --enable-host-shared is not supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64780 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- I've also added some docs on how to package the jit: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00759.html Closing this bug out
[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65409 --- Comment #10 from Eric Botcazou --- > I agree for 4.8/4.9 that your version is safer. > Anyway, you're the RTL maintainer, so I'll let you decide. OK, testing went fine, so I'll go for this version on all branches.
[Bug fortran/65419] New: incorrect sibcalls to libgomp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419 Bug ID: 65419 Summary: incorrect sibcalls to libgomp functions Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at gcc dot gnu.org CC: jakub at gcc dot gnu.org I'm not sure if this problem is fortran specific, but I noticed that gfortran is identifying calls to libgomp, specifically GOACC_data_end, as a sibcall if a acc data region is the last statement inside the main function. That's a problem because GOACC_data_end transfers data from the accelerator to the host at the end of an acc data region. In the attached test case, the data in question happens to be allocated on the stack. If you look at the epilogue of the stack frame callGOACC_data_start movq%rbx, %rsi movq%rsp, %rdi call__field_summary_kernel_module_MOD_field_summary_kernel addq$1296, %rsp .cfi_def_cfa_offset 16 popq%rbx .cfi_def_cfa_offset 8 # SUCC: EXIT [100.0%] (ABNORMAL,SIBCALL) jmpGOACC_data_end .cfi_endproc .LFE1: you'll see that %rsp is restored before GOACC_data_end is called. You should be able to reproduce this bug with "-fopenacc -O2". Did we specify the built-in declaration for GOACC_data_end wrong, or is this a fortran specific quirk? I don't mind fixing it, but I'm not even sure what a sibling call is. I think it has something to do with recursion. Cesar
[Bug libstdc++/65420] New: Enumerators in std::regex_constants should be constexpr variables instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65420 Bug ID: 65420 Summary: Enumerators in std::regex_constants should be constexpr variables instead Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org 28.5 [re.const] says the members of namespace std::regex_constants should be variables, not enumerators. The difference is observable, as perverse users could try to take their addresses.
[Bug target/64623] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64623 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Edelsohn --- Fixed with revised version of patch for PR target/59828.
[Bug target/59371] [4.8/4.9/5 Regression] Performance regression in GCC 4.8 and later versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
--- Comment #15 from Steve Ellcey ---
I am not sure yet where and how to improve this automatically but I have found
an interesting hand optimization that could point to a way to fix this. If I
change the original function:
int foo(int *p, unsigned short c)
{
signed short i;
int x = 0;
for (i = 0; i < c; i++) {
x = x + *p; p++;
}
return x;
}
To:
int foo(int *p, unsigned short c)
{
signed short i;
unsigned short new_i;
int x = 0;
if (c > 32767)
for (i = 0; i < c; i++) {
x = x + *p; p++;
}
else
for (new_i = 0; new_i < c; new_i++) {
x = x + *p; p++;
}
return x;
}
Then GCC 5.0 generates an empty infinite loop for the first for loop and
a compact 4 instruction loop (better even then 4.7) for the second for loop.
I am not sure where or if we can do this optimization in GCC but I am going
to investigate some more.
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #16 from Sebastian Pop --- Created attachment 35030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35030&action=edit IR before and after for failing FSM jump thread After updating the sources of GCC, I now see the fail as Jakub has reported at dbgctr=199. The difference between 198 and 199 is this jump thread path: FSM jump thread: (13, 53) incoming edge; (53, 55) (55, 64) (64, 66) (66, 67) (67, 68) (68, 69) (69, 95) (95, 94) (94, 5) nocopy; (94, 5) The attached file is a dump of the IR just before and after SEME code generation of this path.
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #17 from Sebastian Pop --- Trying to figure out why we FSM jump thread this path: (13, 53) (53, 55) (55, 64) (64, 66) (66, 67) (67, 68) (68, 69) (69, 95) (95, 94) (94, 5) (94, 5) In BB_94 we have this code: switch (sprv_49) , case 1: , case 2: , case 3: , case 5: , case 6: , case 7: , case 8: , case 10: > at this point FSM infers that sprv_49 == 1 and we jump to bb_5. Why? Following the FSM jump thread path backward from 94 to 13, we have these SSA definitions: # sprv_49 = PHI <8(4), sprv_737(95)> # sprv_737 = PHI # sprv_736 = PHI # sprv_768 = PHI # sprv_764 = PHI <1(13), 7(52)> So if we are coming from bb_13, we are guaranteed to have a value of 1.
[Bug target/65421] New: inefficient code returning float aggregates on powepc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65421
Bug ID: 65421
Summary: inefficient code returning float aggregates on
powepc64le
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
When returning homogeneous floating-point aggregates, gcc first loads the
aggregate into GPRs, then saves it to the save area, and then copies the
aggregate from the GPRs to the floating registers used to return it to the
caller. Clang emits much more efficient code (see below).
$ cat x.c && ./gcc/xgcc -B./gcc -O3 -o/dev/tty -S x.c
typedef struct { double a[4]; } A;
A foo (const A *a) { return *a; }
.file"x.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl foo
.typefoo, @function
foo:
ld 7,0(3)
ld 8,8(3)
ld 10,16(3)
ld 9,24(3)
std 7,-64(1)
std 8,-56(1)
std 10,-48(1)
std 9,-40(1)
lfd 2,-56(1)
lfd 1,-64(1)
ori 2,2,0
lfd 3,-48(1)
lfd 4,-40(1)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.sizefoo,.-foo
.ident"GCC: (GNU) 5.0.0 20150310 (experimental)"
.section.note.GNU-stack,"",@progbits
Clang emits:
.text
.abiversion 2
.file"-"
.globlfoo
.align2
.typefoo,@function
foo:
lfd 1, 0(3)
lfd 2, 8(3)
lfd 3, 16(3)
lfd 4, 24(3)
blr
.long0
.quad0
.Ltmp0:
.sizefoo, .Ltmp0-foo
.ident"clang version 3.6.0 (trunk 215935)"
[Bug c++/65422] New: [C++11] Rejected valid double expansion packs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65422 Bug ID: 65422 Summary: [C++11] Rejected valid double expansion packs. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugs at qult dot net Created attachment 35031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35031&action=edit Failing code with double parameter pack expansion. The attached code fails to compile with pretty much any version of GCC (up to the head of the Git repository), with -std=c++11, complaining about the double parameter pack expansion. When using the brace-initialization syntax instead (commented-out in the attached code), the code compiles fine. Clang 3.5 compiles both versions fine.
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-14 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1 --- Comment #4 from Alan Modra --- Created attachment 35032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35032&action=edit prototype patch Patch I'm about to test
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 --- Comment #5 from Bernd Edlinger --- Created attachment 35033 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35033&action=edit stripped down second test case For completeness, here is the stripped down test case for the tail call flag. It reproduces with current trunk and: [-O2|-Os] -fsanitize=treand[,undefined] not with -O1 and not with -O3, and not in january either :)
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug tree-optimization/46038] Vectorizer generates misaligned address for vld1 qn, [rn:alignment]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46038 mshawcroft at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mshawcroft at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from mshawcroft at gcc dot gnu.org --- Issue can't be reproduced in trunk or 4.9
[Bug c++/62116] Allowing redeclaration of global variable x using ::x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #5 from TC ---
Somewhat related: http://stackoverflow.com/questions/28955859
struct Foo {
enum { bar };
explicit Foo(int){}
};
struct Baz { explicit Baz(Foo){} };
Baz b(Foo(Foo::bar)); // 1
Line #1 should be ill-formed because it fits the grammar for a function
declaration and is disambiguated as such. GCC considers it a variable
declaration instead. Clang rejects it - see
https://llvm.org/bugs/show_bug.cgi?id=4594.
