[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 --- Comment #18 from rguenther at suse dot de --- On Mon, 6 Jun 2016, shiva0217 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 > > --- Comment #17 from Shiva Chen --- > Hi, Richard > > Thanks for the explanation :) > > So the transformation (short)abs((int)short_var) -> abs (short_var) > > should guard by TYPE_OVERFLOW_WRAPS > > because when TYPE_OVERFLOW_WRAPS is true, signed operation could wrap > around.(ABS_EXPR in gimple could wrap around and rtl abs already modulo) it _does_, not _could_ wrap around. > > Therefore, the transformation is valid when TYPE_OVERFLOW_WRAPS is true. Yes. > It seems the last update of Matthew's patch in > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00433.html > still make sense. > > Why would it be dropped, or there're still something we should consider ? I don't see any "update" of the patch and the patch directly linked is wrong. > If we implement ABSU_EXPR, when should transfer > ABS_EXPR (x) -> (type of x) ABSU_EXPR (x) ? When it makes sense to us to avoid introducing undefinedness into our IL without losing the advantage of the undefinedness of ABS on INT_MIN. > Could we define like if (!TYPE_OVERFLOW_WRAPS) then transfer ABS_EXPR (x) -> > (type of x) ABSU_EXPR (x) in match.pd ? If we do that unconditionally then we can as well simply say we always treat ABS_EXPR as having defined behavior on overflow. I think it's useful to value-range analysis that we can assert that abs(x) >= 0 and thus disregard the special-case of x == INT_MIN which means we do not want to lose that information in exchange for nothing. > How to expand (type of x) ABSU_EXPR (x) to rtl ? > > Do we have to add a new naming pattern absu ? As on RTL 'abs' has well-defined behavior on wrapping we can just use that.
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 Richard Biener changed: What|Removed |Added CC||alan.hayward at arm dot com Target Milestone|--- |7.0 Summary|ICE at -O3 in 32-bit and|[7 Regression] ICE at -O3 |64-bit modes on |in 32-bit and 64-bit modes |x86_64-linux-gnu|on x86_64-linux-gnu |(vectorizable_live_operatio |(vectorizable_live_operatio |n) |n)
[Bug other/71414] 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 --- Comment #1 from Richard Biener --- The core loop is .L8: addq$1, %rdx vaddps (%r8), %ymm1, %ymm1 addq$32, %r8 cmpq%rdx, %rcx ja .L8 which compared to LLVM is not unrolled. You can use -funroll-loops to force that which probably fixes the performance compared to LLVM. For the short loop above I also guess this is not the optimal IV choice.
[Bug tree-optimization/71410] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71410 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- Fixed by fix for PR71398 *** This bug has been marked as a duplicate of bug 71398 ***
[Bug tree-optimization/71398] [7 Regression] ICE at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu (Segmentation fault, find_edge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71398 Richard Biener changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #5 from Richard Biener --- *** Bug 71410 has been marked as a duplicate of this bug. ***
[Bug bootstrap/70473] genautomata memory footprint for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70473 Benda Xu changed: What|Removed |Added CC||heroxbd at sohu dot com --- Comment #4 from Benda Xu --- I can reproduce this bug on armv7a (TI OMAP 4430) with 1GB of memory, build/genautomata took 900MB of ram and the system freezed. To ktkachov, but gcc-4.9 has a moderate memory footprint. This should be considered a regression of gcc-5. But thanks for working on this issue. I'd vote for it.
[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71400 Richard Biener changed: What|Removed |Added CC||nathan at gcc dot gnu.org Target Milestone|--- |7.0
[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71428 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Mine likely, confirmed.
[Bug c/71422] Total size of static objects is not limited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71422 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- IMNSHO gcc shouldn't, after all, if you just put each into a separate CU, gcc won't even see them together. It should be linker's responsibility to complain.
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413 --- Comment #3 from Bernd Schmidt --- Also, to help narrow it down, can you try it with this patch? Index: tree-ssa-strlen.c === --- tree-ssa-strlen.c (revision 237069) +++ tree-ssa-strlen.c (working copy) @@ -1860,7 +1860,7 @@ handle_builtin_memcmp (gimple_stmt_itera use_operand_p use_p; imm_use_iterator iter; - if (!res) + if (1 || !res) return true; FOR_EACH_IMM_USE_FAST (use_p, iter, res)
[Bug tree-optimization/71423] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71423
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |5.5
Summary|[6/7 Regression] wrong code |[5/6/7 Regression] wrong
|at -Os and above on |code at -Os and above on
|x86_64-linux-gnu|x86_64-linux-gnu
--- Comment #3 from Richard Biener ---
Those transforms were carried over from tree-ssa-forwprop.c IIRC. On the
gcc-4_9-branch this was done in simplify_bitwise_binary thus the issue is
latent on the gcc-5-branch as well. In its transform phase it did the
proper comparison swapping:
static bool
simplify_bitwise_binary_boolean (gimple_stmt_iterator *gsi,
enum tree_code code,
tree op0, tree op1)
{
...
if (code == BIT_AND_EXPR)
newcode = TYPE_UNSIGNED (TREE_TYPE (x)) ? LT_EXPR : GT_EXPR;
else
newcode = TYPE_UNSIGNED (TREE_TYPE (x)) ? LE_EXPR : GE_EXPR;
The following fixes it.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 237117)
+++ gcc/match.pd(working copy)
@@ -900,12 +900,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(ne (bit_and:c (bit_not @0) @1) integer_zerop)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_PRECISION (TREE_TYPE (@1)) == 1)
- (lt @0 @1)))
+ (if (TYPE_UNSIGNED (TREE_TYPE (@1)))
+(lt @0 @1)
+(gt @0 @1
(simplify
(ne (bit_ior:c (bit_not @0) @1) integer_zerop)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_PRECISION (TREE_TYPE (@1)) == 1)
- (le @0 @1)))
+ (if (TYPE_UNSIGNED (TREE_TYPE (@1)))
+(le @0 @1)
+(ge @0 @1
/* ~~x -> x */
(simplify
[Bug other/71414] 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 --- Comment #2 from Marc Glisse --- (In reply to Richard Biener from comment #1) > The core loop is > > .L8: > addq$1, %rdx > vaddps (%r8), %ymm1, %ymm1 > addq$32, %r8 > cmpq%rdx, %rcx > ja .L8 > > which compared to LLVM is not unrolled. You can use -funroll-loops to > force that which probably fixes the performance compared to LLVM. For > the short loop above I also guess this is not the optimal IV choice. -funroll-loops only gains 10% or so, nowhere near the factor of 2 with clang. Except for the slightly better induction choice in llvm, the 2 unrolled loops look quite similar, I have a hard time seeing how one can be so much faster than the other. Maybe the alignment somehow ends up better in one case? Or the loop being one instruction shorter lets it fit better in cache?
[Bug bootstrap/71421] trunk bootstrap is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71421 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Fixed.
[Bug target/71419] [6/7 Regression] cortex-a9 IRQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71419 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|c++ |target Target Milestone|--- |6.2 Summary|cortex-a9 IRQ |[6/7 Regression] cortex-a9 ||IRQ
[Bug c/71418] [7 Regression] gcc ICE on x86_64-linux-gnu in min_align_of_type, at stor-layout.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71418 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |7.0 Summary|gcc ICE on x86_64-linux-gnu |[7 Regression] gcc ICE on |in min_align_of_type, at|x86_64-linux-gnu in |stor-layout.c:2402 |min_align_of_type, at ||stor-layout.c:2402
[Bug tree-optimization/71417] [7 Regression] wrong code (SIGFPE) at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71417 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 Target Milestone|--- |7.0 Summary|wrong code (SIGFPE) at -O3 |[7 Regression] wrong code |on x86_64-linux-gnu |(SIGFPE) at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c/71426] gcc ICE on x86_64-linux-gnu in get_parm_info, at c/c-decl.c:7059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71426 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This ICEs for me even with 5/6. Likely mine anyway.
[Bug tree-optimization/71428] [7 Regression] wrong code with -Os -fno-tree-forwprop (breaks in the .bswap dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71428 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r236204.
[Bug c/71418] [7 Regression] gcc ICE on x86_64-linux-gnu in min_align_of_type, at stor-layout.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71418 Marek Polacek changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- This ICEs since 4.7.
[Bug c/71426] gcc ICE on x86_64-linux-gnu in get_parm_info, at c/c-decl.c:7059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71426 --- Comment #2 from Jakub Jelinek --- This is just weird, I certainly do get ICE with 6.x, and while I don't with 5.x, I get the ICE at the 5.x branch point. So this really doesn't look like a regression to me.
[Bug c/71418] [4.9/5/6/7 Regression] gcc ICE on x86_64-linux-gnu in min_align_of_type, at stor-layout.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71418 Jakub Jelinek changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Summary|[7 Regression] gcc ICE on |[4.9/5/6/7 Regression] gcc |x86_64-linux-gnu in |ICE on x86_64-linux-gnu in |min_align_of_type, at |min_align_of_type, at |stor-layout.c:2402 |stor-layout.c:2402 --- Comment #2 from Jakub Jelinek --- Most likely ICEs starting with r181048.
[Bug fortran/44265] Link error with reference to parameter array in specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265 --- Comment #8 from Dominique d'Humieres --- While trying to package the patch in comment 5, I stumbled on the following problem in 32 mode: the following code MODULE Fruits IMPLICIT NONE PRIVATE PUBLIC :: Get CONTAINS FUNCTION Get(i) RESULT(s) CHARACTER(len=7), PARAMETER :: names(3) = [ & 'Apple ', & 'Orange ', & 'Mango ' ]; INTEGER, INTENT(IN) :: i CHARACTER(LEN_TRIM(names(i))) :: s ! s = names(i) print *, len(s) END FUNCTION Get END MODULE Fruits PROGRAM WheresThatbLinkingConstantGone USE Fruits IMPLICIT NONE integer :: i i = len(Get(1)) print *, i END PROGRAM WheresThatbLinkingConstantGone outputs at run time 5 5 when compiled with -m64, but 5 7 when compiled with -m32 (x86_64-apple-darwin15). The function Get(i) works as expected when used as a contained proc or through an interface.
[Bug tree-optimization/71417] [7 Regression] wrong code (SIGFPE) at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71417 --- Comment #2 from Jakub Jelinek --- Started with r236831.
[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 --- Comment #4 from Ludovic Courtès --- Created attachment 38650 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38650&action=edit Diff of one of the RTL phases between stage 2 and 3, gcc/real.c, GCC 5.4.0
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r237065.
[Bug ipa/71190] [7 Regression] ICE in assemble_variable_contents, at varasm.c:2054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71190 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- I hit this ICE on aarch64. The testcase I have is quite large, waiting for creduce to chomp on it.
[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 --- Comment #5 from Ludovic Courtès --- I tried this time with GCC 5.4.0, and with BOOT_CFLAGS='-O2 -g0 -da'. I'm also getting the failure: make[3]: Leaving directory '/tmp/guix-build-gcc-5.4.0.drv-0/build' Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/c/c-parser.o differs gcc/c/c-typeck.o differs gcc/cp/semantics.o differs gcc/cp/optimize.o differs gcc/c-family/cilk.o differs gcc/coverage.o differs gcc/df-scan.o differs gcc/double-int.o differs gcc/dwarf2cfi.o differs gcc/fold-const.o differs gcc/ipa-inline.o differs gcc/omp-low.o differs gcc/real.o differs gcc/simplify-rtx.o differs gcc/tree-dfa.o differs gcc/tree-nested.o differs gcc/tree-inline.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-math-opts.o differs gcc/tree-ssa-sccvn.o differs gcc/gcov-dump.o differs gcc/libgcov-driver-tool.o differs libiberty/simple-object-xcoff.o differs libiberty/fibheap.o differs libiberty/sort.o differs libiberty/pic/simple-object-xcoff.o differs libiberty/pic/fibheap.o differs libiberty/pic/sort.o differs Makefile:21400: recipe for target 'compare' failed make[2]: *** [compare] Error 1 make[2]: Leaving directory '/tmp/guix-build-gcc-5.4.0.drv-0/build' I have attached the diff of stage[23]-gcc/real.c.192r.expand in the hope it would provide useful info. I have hundreds of GiBs of RTL dumps to share, so let me know what you'd like to see! :-)
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 Jonathan Wakely changed: What|Removed |Added CC||yanp.bugz at gmail dot com --- Comment #13 from Jonathan Wakely --- *** Bug 71329 has been marked as a duplicate of this bug. ***
[Bug libstdc++/71329] Remove typedefs from iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71329 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- (In reply to Yan from comment #0) > iostream comes with typedefs like uint8_t , int32_t etc. The most confusing That's not a bug. > is > "typedef unsigned int uint;", which is non-stadart. This is caused by G++ automatically defining _GNU_SOURCE, which is Bug 11196 *** This bug has been marked as a duplicate of bug 11196 ***
[Bug c/71418] [4.9/5/6/7 Regression] gcc ICE on x86_64-linux-gnu in min_align_of_type, at stor-layout.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71418 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c/71426] gcc ICE on x86_64-linux-gnu in get_parm_info, at c/c-decl.c:7059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71426 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug libstdc++/71329] Remove typedefs from iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71329 --- Comment #2 from Jonathan Wakely --- Also Bug 51749
[Bug other/71414] 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- (In reply to Marc Glisse from comment #2) > (In reply to Richard Biener from comment #1) > > The core loop is > > > > .L8: > > addq$1, %rdx > > vaddps (%r8), %ymm1, %ymm1 > > addq$32, %r8 > > cmpq%rdx, %rcx > > ja .L8 > > > > which compared to LLVM is not unrolled. You can use -funroll-loops to > > force that which probably fixes the performance compared to LLVM. For > > the short loop above I also guess this is not the optimal IV choice. > > -funroll-loops only gains 10% or so, nowhere near the factor of 2 with > clang. Except for the slightly better induction choice in llvm, the 2 > unrolled loops look quite similar, I have a hard time seeing how one can be > so much faster than the other. Maybe the alignment somehow ends up better in > one case? Or the loop being one instruction shorter lets it fit better in > cache? Can you post a full example? The LLVM bug and this copy lacks information on what actual 'a' and 'n' is used. Note that unless a fits in L2 I hardly doubt one can exceeed memory bandwidth (and thus code-gen should not matter unless it affects the HW prefetcher).
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 Ever confirmed|0 |1
[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 --- Comment #6 from Ludovic Courtès --- FWIW, we're bootstrapping from an ARM->ARM pseudo cross-compiler (same version, that is 5.3.0 in the initial report, 5.4.0 in the latest report), along the lines of: http://linuxfromscratch.org/lfs/view/stable/chapter05/toolchaintechnotes.html http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html The stragegy works fine on x86_64, i686, and mips64el. It also worked well on armhf with GCC 4.9. Ludo'.
[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 Jonathan Wakely changed: What|Removed |Added CC||ralphengels at gmail dot com --- Comment #9 from Jonathan Wakely --- *** Bug 71298 has been marked as a duplicate of this bug. ***
[Bug libstdc++/71298] changes to libstdc++ breaks windows builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71298 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- In the absence of any useful info whatsoever I'm going to assume it's a duplicate. *** This bug has been marked as a duplicate of bug 70936 ***
[Bug target/71419] interrupt attribute silently dropped for Thumb code on armv7-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71419 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code |documentation Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||ktkachov at gcc dot gnu.org Known to work|5.3.0 | Summary|[6/7 Regression] cortex-a9 |interrupt attribute |IRQ |silently dropped for Thumb ||code on armv7-a Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- The interrupt attribute only works for arm mode i.e. compile with -marm. That is because the LDM with exception return instruction is only available in ARM mode. For Thumb mode the attribute is silently ignored. That being said, we could handle it better. Currently for -mthumb the attribute still blocks tailcall optimisation, which it shouldn't do if it was properly ignored. So we could perhaps issue a warning or error in this situation, document the behaviour and properly discard the attribute when this occurs
[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 alahay01 at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #3 from alahay01 at gcc dot gnu.org --- I've reproduced this on x86. Issue is not present on aarch64.
[Bug libstdc++/71430] New: Consider having different global std::locale object per thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71430 Bug ID: 71430 Summary: Consider having different global std::locale object per thread Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Contention on the ref-counts of the global std::locale object could be avoided by having per-thread global locale objects. This is encouraged since C++11 by [locale] p9.
[Bug c/71426] gcc ICE on x86_64-linux-gnu in get_parm_info, at c/c-decl.c:7059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71426 --- Comment #3 from Marek Polacek --- "Reduced": int f (int x[x - x ()]);
[Bug libstdc++/71431] New: ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431
Bug ID: 71431
Summary: ifstream::rdbuf directory
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimaqq at gmail dot com
Target Milestone: ---
Pardon my primitive code:
```
auto utf8 = std::locale(std::locale(), new std::codecvt_utf8);
std::wifstream expression(argv[1]);
if (!expression) { /* ... */ return 99; }
expression.imbue(utf8);
std::wstringstream buf;
buf << expression.rdbuf();
```
This works fine for files; fails correctly for files that won't open (doesn't
exist, wrong permissions, etc).
It doesn't fail for directories though (result is same as empty file).
None of the error bits are set either.
strace shows a failed read call:
```
open(".", O_RDONLY) = 4
read(4, 0x10b0250, 8191)= -1 EISDIR (Is a directory)
```
But no error is reported. That can't be right, can it?
gcc version 6.1.1 20160501 (GCC); x86_64-pc-linux-gnu
[Bug libstdc++/71298] changes to libstdc++ breaks windows builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71298 --- Comment #3 from ralphengels at gmail dot com --- Sorry for the delay, yes its a duplicate of the same bug you linked to. The msys2 devs have found a way to get around it which does not include patching, but i thought it best to report it anyway in case it breaks other archs.
[Bug debug/71432] New: [7 Regression] -fcompare-debug failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71432 Bug ID: 71432 Summary: [7 Regression] -fcompare-debug failure (length) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Created attachment 38651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38651&action=edit test.ii, compile with: g++ -c -fcompare-debug -O2 This must be a very recent regression as it was working last week on Thursday (Jun 2). $ g++ -c -fcompare-debug -O2 test18.ii g++: error: test18.ii: -fcompare-debug failure (length)
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely ---
The semantics of exists(const path&, error_code&) are precisely specified, and
I think this behaviour is correct according to the specification. This is also
consistent with Boost.Filesystem.
(In reply to Martin Ejdestig from comment #0)
> Which means it is not possible to discern between an error and when the file
> does not exist without examining error_code.value(), which is platform
> dependent.
Just compare to the platform independent enumerator:
#include
#include
int main()
{
std::error_code error_code;
bool exists = std::experimental::filesystem::exists("does_not_exist",
error_code);
std::cout << "exists: " << exists << '\n';
std::cout << "an error happened: "
<< (error_code != std::errc::no_such_file_or_directory) << '\n';
}
I'll discuss with the C++ committee whether this behaviour is really desirable,
but it seems to be what the spec requires, and not a bug in GCC.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-06-06
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This demonstrates the same problem without the irrelevant clutter:
#include
int main()
{
std::ifstream f("/");
if (!f)
throw 1;
}
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413 --- Comment #4 from Andreas Schwab --- This fixes the comparison failure on ia64.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely ---
On second thoughts, I think this is correct. Calling fopen(".", "r") succeeds,
but calling fread on the resulting stream fails, and fstreams do the same.
[Bug tree-optimization/71433] New: [7 Regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433 Bug ID: 71433 Summary: [7 Regression] -Warray-bounds false positive with -O2 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Target Milestone: --- When compiling GNU MPFR 3.1.4 with CFLAGS="-O2 -Werror=array-bounds" and gcc (Debian 20160603-1) 7.0.0 20160603 (experimental) [trunk revision 237077] I get: get_d.c: In function 'mpfr_get_d': get_d.c:115:24: error: array subscript is above array bounds [-Werror=array-bounds] d = (d + tp[i]) / MP_BASE_AS_DOUBLE; ~~^~~ There was no such problem with gcc (Debian 20160508-1) 7.0.0 20160508 (experimental) [trunk revision 236009] so that's a recent regression.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431
Dima Tisnek changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID |---
--- Comment #3 from Dima Tisnek ---
@Jonathan, arguably, `std::ifstream f("/");` should not through, as underlying
`open()` succeeds. No read call is made at that point. That was the nature of
bug 36564 They site ""current standard" at the time.
(Personally I'd prefer ifstream creation to fail, but I can live with that).
Successive read operations really ought to set some error bit.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Jonathan Wakely ---
Could you clarify exactly what you think is a bug then?
This example shows that failbit is set on the output stream, as required:
#include
#include
#include
int main()
{
std::ifstream f(".");
std::ostringstream ss;
ss << f.rdbuf();
std::cout << (bool)f.fail() << '\n';
std::cout << (bool)ss << '\n';
}
The standard doesn't say anything about operator<<(basic_streambuf*)
setting any error bits on the input streambuf if reading characters from it
fails.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431 --- Comment #5 from Jonathan Wakely --- Oops, sorry, that was meant to be: std::cout << f.fail() << f.bad() << '\n'; std::cout << ss.fail() << ss.bad() << '\n'; Which prints: 00 10 and I think that's correct.
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431 --- Comment #6 from Dima Tisnek --- Perhaps in my case, it's a combination of directory, `imbue` and `rdbuf` ?
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431 --- Comment #7 from Dima Tisnek --- Ugh, it never occurred to me to check error on target of buffer copy. `buf.rdstate()` does report an error for me. A bit unexpected and seems like black magic, but the error is there :)
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431 --- Comment #8 from Dima Tisnek --- Looks like I cannot distinguish between a directory and an empty file: ``` buf << expression.rdbuf(); /* check buf.rdstate() */ ``` underlying file name was a directory -- rdstate() == 4 underlying file name is empty file -- rdstate() == 4 It's good enough for me (file shouldn't be empty), but may be a gotcha for someone else. Personally I find it weird that nothing is set on `expression`, but hey, I didn't read the standard, did I?
[Bug other/71414] 2x slower than clang summing small float array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #4 from Yichao Yu ---
The C code is in the gist linked `a` is a cacheline aligned pointer and `n` is
1024 so `a` should even fits in L1d, which is 32kB on both processors I
benchmarked.
More precise timing (ns per loop)
6700K
```
% ./benchmark-gcc
80.553456
% ./benchmark-clang37
28.81
% ./benchmark-clang38
41.782532
```
4702HQ
```
% ./benchmark-gcc
140.744893
% ./benchmark-clang37
50.835441
% ./benchmark-clang38
70.220946
```
Pasting the whole program over for completeness.
The alignment line gives some weird timing on clang without `-mcore-avx2` but
doesn't change anything too much with `-Ofast -mcore-avx2`
```
//
#include
#include
#include
#include
#include
uint64_t gettime_ns()
{
struct timespec t;
clock_gettime(CLOCK_MONOTONIC, &t);
return t.tv_sec * (uint64_t) 1e9 + t.tv_nsec;
}
__attribute__((noinline)) float sum32(float *a, size_t n)
{
/* a = (float*)__builtin_assume_aligned(a, 64); */
float s = 0;
for (size_t i = 0;i < n;i++)
s += a[i];
__asm__ volatile ("" ::: "memory");
return s;
}
int main()
{
float *p = aligned_alloc(64, sizeof(float) * 1024);
memset(p, 0, sizeof(float) * 1024);
uint64_t start = gettime_ns();
for (int i = 0;i < 1024 * 1024;i++)
sum32(p, 1024);
free(p);
uint64_t end = gettime_ns();
printf("%f\n", (end - start) / (1024.0 * 1024.0));
return 0;
}
```
[Bug libstdc++/71434] New: binomial_distribution operator(): using uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71434 Bug ID: 71434 Summary: binomial_distribution operator(): using uninitialized variable Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: barannikov88 at gmail dot com Target Milestone: --- The variable __x declared at line 1699 of file libstdc++-v3/include/bits/random.tcc may be used uninitialized. This happens when the following conditions are met: __u <= __a1 (line 1724) __y >= __param._M_d1 (line 1728) When both conditions are TRUE, the variable __x is used uninitialized at line 1782: __reject |= __x + __np >= __thr; Seems that it is assumed that __x has a meaningful value only when __reject == FALSE (other uses of __x are under this condition). If __reject is TRUE, then the value of the variable __x doesn't matter: __reject will remain TRUE. But __x is used unconditionally it this context, that leads to execution error on a machine with tagged architecture (this is how I found it). This line should be rewritten as: __reject = __reject || __x + __np >= __thr; (note that if __reject is TRUE, the variable __x is not used.) This applies to all versions of libstdc++. Line numbers provided are for gcc-5.1.
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #3 from Martin Ejdestig --- > The semantics of exists(const path&, error_code&) are precisely specified, > and > I think this behaviour is correct according to the specification. This > is also > consistent with Boost.Filesystem. Oh, OK. It seems odd to me that an error is signaled for something that should be considered "normal operations" though. > I'll discuss with the C++ committee whether this behaviour is really > desirable, > but it seems to be what the spec requires, and not a bug in GCC. OK, thanks. Is there some way for me to track the discussion? The isocpp.org Google group? Or is there e.g. some other mailing list where std::filesystem is discussed? I am just curious. :)
[Bug libstdc++/71431] ifstream::rdbuf directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71431 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Jonathan Wakely --- Not a bug then.
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #4 from Jonathan Wakely --- (In reply to Martin Ejdestig from comment #3) > Oh, OK. It seems odd to me that an error is signaled for something that > should be considered "normal operations" though. I agree. > Is there some way for me to track the discussion? The isocpp.org Google > group? Or is there e.g. some other mailing list where std::filesystem is > discussed? I am just curious. :) A new issue should get added to http://cplusplus.github.io/LWG/lwg-active.html
[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71400 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-06 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Nathan Sidwell --- Testing patch. Aaron's isn't quite right.
[Bug c/24414] Old-style asms don't clobber memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24414 --- Comment #20 from Bernd Edlinger --- Author: edlinger Date: Mon Jun 6 12:31:59 2016 New Revision: 237133 URL: https://gcc.gnu.org/viewcvs?rev=237133&root=gcc&view=rev Log: gcc/ 2016-06-06 Bernd Edlinger PR c/24414 * cfgexpand.c (expand_asm_loc): Remove handling for ADDR_EXPR. Implicitly clobber memory for basic asm with non-empty assembler string. Use targetm.md_asm_adjust also here. * compare-elim.c (arithmetic_flags_clobber_p): Use asm_noperands here. * final.c (final_scan_insn): Handle basic asm in PARALLEL block. * gimple.c (gimple_asm_clobbers_memory_p): Handle basic asm with non-empty assembler string. * ira.c (compute_regs_asm_clobbered): Use asm_noperands here. * recog.c (asm_noperands): Handle basic asm in PARALLEL block. (decode_asm_operands): Handle basic asm in PARALLEL block. (extract_insn): Handle basic asm in PARALLEL block. * doc/extend.texi: Mention new behavior of basic asm. * config/ia64/ia64 (rtx_needs_barrier): Handle ASM_INPUT here. * config/pa/pa.c (branch_to_delay_slot_p, branch_needs_nop_p, branch_needs_nop_p): Use asm_noperands. gcc/testsuite/ 2016-06-06 Bernd Edlinger PR c/24414 * gcc.target/i386/pr24414.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr24414.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/compare-elim.c trunk/gcc/config/ia64/ia64.c trunk/gcc/config/pa/pa.c trunk/gcc/doc/extend.texi trunk/gcc/final.c trunk/gcc/gimple.c trunk/gcc/ira.c trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/71415] std::filesystem::exists that does not throw sets error code if file does not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71415 --- Comment #5 from Martin Ejdestig --- (In reply to Jonathan Wakely from comment #4) > A new issue should get added to > http://cplusplus.github.io/LWG/lwg-active.html Thank you.
[Bug bootstrap/71435] New: [7 regression] sparc bootstrap failure since r235625
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435 Bug ID: 71435 Summary: [7 regression] sparc bootstrap failure since r235625 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Target Milestone: --- Attempting to bootstrap gcc-7-20160605 on sparc-linux fails with: Comparing stages 2 and 3 Bootstrap comparison failure! gcc/ira.o differs gcc/double-int.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/mnt/scratch/objdir7' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir7' make: *** [bootstrap] Error 2 Last successful bootstrap was with gcc-7-20160424. A bisection showed that the failure started with the reload1 patch in r235625. Configured on sparc64-linux-gnu with: /mnt/scratch/gcc-7-20160605/configure --prefix=/mnt/scratch/install7 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-6.1.0 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.4 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.3 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++ --build=sparc-unknown-linux --target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all
[Bug target/71436] New: [7 Regression] Segmentation fault in arm_output_multireg_pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436
Bug ID: 71436
Summary: [7 Regression] Segmentation fault in
arm_output_multireg_pop
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: arm
The testcase:
#pragma pack(1)
struct S0
{
volatile int f0;
short f2;
};
void foo (struct S0 *);
int a, d;
static struct S0 b[5];
static struct S0 c;
void fn1 ();
void
main ()
{
{
struct S0 e;
for (; d; fn1 ())
{
{
a = 3;
for (; a >= 0; a -= 1)
{
{
e = c;
}
b[a] = e;
}
}
}
}
foo (b);
}
ICEs on arm with -O3 -marm -march=armv7-a -mfloat-abi=hard -mfpu=neon
arm-crash.c: In function 'main':
arm-crash.c:33:1: internal compiler error: Segmentation fault
}
^
0xb152fe crash_signal
$SRC/gcc/toplev.c:333
0xe3e921 arm_output_multireg_pop(rtx_def**, bool, rtx_def*, bool, bool)
$SRC/gcc/config/arm/arm.c:17809
0x101fe24 output_390
$SRC/gcc/config/arm/arm.md:11344
0x8284a5 get_insn_template(int, rtx_def*)
$SRC/gcc/final.c:2077
0x82b3eb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
$SRC/gcc/final.c:2948
0x82bbba final(rtx_insn*, _IO_FILE*, int)
$SRC/gcc/final.c:2045
0x82c053 rest_of_handle_final
$SRC/gcc/final.c:4441
0x82c053 execute
$SRC/gcc/final.c:4516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
The rtx that's causing the segfault is:
(parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 5 r5 [147]) [2 c+0 S4 A32]))
(set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [4 %sfp+-12 S4 A32])
(mem/u/c:SI (plus:SI (reg/f:SI 5 r5 [147])
(const_int 4 [0x4])) [2 c+4 S4 A32]))
])
where the code is trying to extract:
REGNO (XEXP (XVECEXP (operands[0], 0, i), 0))
That second set mem-mem looks dodgy.
Bisection shows it started with r235765 but I'm not sure it's the root cause
[Bug debug/71432] [7 Regression] -fcompare-debug failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71432 Tobias Burnus changed: What|Removed |Added CC||bernds at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #1 from Tobias Burnus --- Bisecting points at r237069: 2016-06-03 Bernd Schmidt PR tree-optimization/52171 [...] Disclaimer: As I was partially doing incremental builds, the bisection might have gone wrong.
[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||6.1.0 Target Milestone|--- |7.0 Known to fail||7.0
[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
--- Comment #1 from Vincent Lefèvre ---
Here's a simple test case:
int t[1];
int fct (long e)
{
int d = 0, i, n = 52;
if (e < 0)
n += e;
for (i = 1 ; i < n / 64 + 1 ; i++)
d = t[i];
return d;
}
If I replace "long" by "int" in the second line, I no longer get any warning.
[Bug target/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436
--- Comment #1 from ktkachov at gcc dot gnu.org ---
The invalid mem-mem set rtx appears during reload. It transforms:
(insn 55 67 151 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32]))
(set (reg:SI 158 [ c+4 ])
(mem/u/c:SI (plus:SI (reg/f:SI 147)
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) arm-crash.c:25 393 {*load_multiple}
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
into:
(insn 55 67 70 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 5 r5 [147]) [2 c+0 S4 A32]))
(set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [4 %sfp+-12 S4
A32])
(mem/u/c:SI (plus:SI (reg/f:SI 5 r5 [147])
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) arm-crash.c:25 393 {*load_multiple}
(nil))
I wonder why this gets recognised?
ldm_stm_operation_p that's supposed to act as a predicate for that insn doesn't
accept it (from what I can see in gdb)
[Bug rtl-optimization/71436] [7 Regression] Segmentation fault in arm_output_multireg_pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71436 ktkachov at gcc dot gnu.org changed: What|Removed |Added Component|target |rtl-optimization --- Comment #2 from ktkachov at gcc dot gnu.org --- Hmm, looks like an rtl-optimization failure to me.
[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 --- Comment #7 from Ludovic Courtès --- > I have attached the diff of stage[23]-gcc/real.c.192r.expand in the hope it > would provide useful info. The diffs are too noisy: due to '-gtoggle', we not only get "# DEBUG" comments in stage2 dumps and not in stage3 dumps, but we also get 'debug_insn's in stage2 that offset all the insn UIDs compared to stage3. (Indeed, I believe the 'real.c.192r.expand' dumps are in fact equivalent modulo "# DEBUG" comments and 'debug_insn' forms.) I narrowed this dump to the 'round_for_format' function since that's where the assembly diverged. Right from the beginning of the function, we see different variable decls: --- real.c.s2.narrowed 2016-06-06 16:10:01.482909061 +0200 +++ real.c.s3.narrowed 2016-06-06 16:09:46.321718424 +0200 @@ -99,10 +99,8 @@ void round_for_format(const real_format* int _119; bool _122; void * _126; - long unsigned int _128; struct real_value * _129; long unsigned int _130; - long unsigned int _131; sizetype _133; long unsigned int _135; unsigned int _136; @@ -110,33 +108,32 @@ void round_for_format(const real_format* long unsigned int _138; long unsigned int _139; sizetype _141; + unsigned int _154; unsigned int _155; - unsigned int _156; - int _157; - void * _158; - bool _159; - unsigned int _161; - struct real_value * _162; - unsigned int _163; + int _156; + void * _157; + bool _158; + unsigned int _160; + struct real_value * _161; + unsigned int _162; + unsigned int _165; unsigned int _166; - unsigned int _167; - struct real_value * _168; + struct real_value * _167; + void * _169; void * _170; - void * _171; - bool _173; - pretmp_194; - int pretmp_196; - int prephitmp_197; - pretmp_204; - int pretmp_207; - int prephitmp_209; - pretmp_210; - int pretmp_212; - int prephitmp_213; + bool _172; + pretmp_193; + int pretmp_195; + int prephitmp_196; + pretmp_203; + int pretmp_206; + int prephitmp_208; + pretmp_209; + int pretmp_211; + int prephitmp_212; ;; basic block 2, loop depth 0 ;;pred: ENTRY - # DEBUG round_up => 0 _14 = BIT_FIELD_REF <*r_13(D), 8, 0>; _15 = _14 & 4; if (_15 != 0) Does that help at all? Any idea on how to get more exploitable debugging data? Alternately, I can give instructions on how to reproduce with GNU Guix, which shouldn't take long.
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413 --- Comment #5 from Andreas Schwab --- I see sem_ch13__new_stream_subprogram__build_spec.9906 in stage3 calling memcmp whereas it is inlined in stage2. That appears to be the only difference.
[Bug c++/61564] #pragma GCC optimize ("-fno-lto") causes the compiler to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61564
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Note current trunk doesn't ICE, but emits quite weird diagnostics on this:
#pragma GCC optimize ("-fno-lto")
int main(int argc, char *argv[]) {return 0;}
./xgcc -B ./ -o 1 1.c -flto
/usr/bin/ld: /tmp/ccJ3LJfv.o: plugin needed to handle lto object
[Bug target/70830] [6/7 Regression] ARM interrupt attribute: push/pop do not support {reglist}^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830
--- Comment #9 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Jun 6 14:39:21 2016
New Revision: 237134
URL: https://gcc.gnu.org/viewcvs?rev=237134&root=gcc&view=rev
Log:
Fix fallout from: [ARM] PR target/70830: Avoid POP-{reglist}^ when returning
from interrupt handlers
Backport from trunk
2016-06-02 Kyrylo Tkachov
PR target/70830
* config/arm/arm.c (arm_output_multireg_pop): Guard "pop" on update.
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm.c
[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
--- Comment #2 from Vincent Lefèvre ---
Well, this test case also yields a warning with 20160508-1 (trunk r236009).
Here's a new test case that yields no warnings with 20160508-1, but yields one
with 20160603-1 (r237077).
int t[1];
int a (void);
int fct (int r, long e, int neg)
{
int d = 0;
if (r == 4)
r = neg ? 3 : 2;
if (e < -52)
d = r == 0 && a () ? 1 : 2;
else
{
int i, n = 53;
if (e < 0)
n += e;
for (i = 1 ; i < n / 64 + 1 ; i++)
d = t[i];
}
return d;
}
[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71404 --- Comment #10 from Bill Seurer --- I checked on both powerpc64 BE and LE and indeed it runs now. Thanks!
[Bug c++/58987] [c++11] ICE with template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58987 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 Ever confirmed|0 |1
[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71400 --- Comment #2 from Nathan Sidwell --- Author: nathan Date: Mon Jun 6 15:24:24 2016 New Revision: 237135 URL: https://gcc.gnu.org/viewcvs?rev=237135&root=gcc&view=rev Log: PR libgcc/71400 * libgcov-driver-system.c (__gcov_error_file): Disable if IN_GCOV_TOOL. (get_gcov_error_file): Check __gcov_error_file before trying to initialize it. (gcov_error): Always use get_gcov_error_file. Modified: trunk/libgcc/ChangeLog trunk/libgcc/libgcov-driver-system.c
[Bug bootstrap/71400] [7 Regression] profiledbootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71400 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- Fixed r237135.
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413
--- Comment #6 from Bernd Schmidt ---
Does this fix it (on both machines)?
Index: tree-ssa-strlen.c
===
--- tree-ssa-strlen.c (revision 237069)
+++ tree-ssa-strlen.c (working copy)
@@ -1867,6 +1867,8 @@ handle_builtin_memcmp (gimple_stmt_itera
{
gimple *ustmt = USE_STMT (use_p);
+ if (is_gimple_debug (ustmt))
+ continue;
if (gimple_code (ustmt) == GIMPLE_ASSIGN)
{
gassign *asgn = as_a (ustmt);
[Bug libstdc++/71320] filesystem::permissions does not respect add_perms/remove_perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71320 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Mon Jun 6 15:50:01 2016 New Revision: 237136 URL: https://gcc.gnu.org/viewcvs?rev=237136&root=gcc&view=rev Log: libstdc++/71320 Add or remove file permissions correctly PR libstdc++/71320 * src/filesystem/ops.cc (permissions(const path&, perms, error_code&)): Add or remove permissions according to perms argument. * testsuite/experimental/filesystem/operations/permissions.cc: New test. Added: trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/permissions.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Eric Botcazou --- I can reproduce on IA-64.
[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37780 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jun 6 15:59:48 2016 New Revision: 237138 URL: https://gcc.gnu.org/viewcvs?rev=237138&root=gcc&view=rev Log: [1/3][ARM] Keep ctz expressions together until after reload PR middle-end/37780 * config/arm/arm.md (ctzsi2): Convert to define_insn_and_split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md
[Bug libstdc++/71322] [DR 2720] std::filesystem::permissions always follows symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71322 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2016-06-06 Summary|std::filesystem::permission |[DR 2720] |s always follows symlinks |std::filesystem::permission ||s always follows symlinks Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- http://cplusplus.github.io/LWG/lwg-active.html#2720
[Bug libstdc++/71313] [Filesystem TS] remove_all fails to remove directory contents recursively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71313 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-06 CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Ville Voutilainen --- Mine.
[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37780 --- Comment #5 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jun 6 16:01:47 2016 New Revision: 237139 URL: https://gcc.gnu.org/viewcvs?rev=237139&root=gcc&view=rev Log: [2/3][AArch64] Keep CTZ components together until after reload PR middle-end/37780 * config/aarch64/aarch64.md (ctz2): Convert to define_insn_and_split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md
[Bug libstdc++/71320] filesystem::permissions does not respect add_perms/remove_perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71320 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-06 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37780 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jun 6 16:06:05 2016 New Revision: 237141 URL: https://gcc.gnu.org/viewcvs?rev=237141&root=gcc&view=rev Log: [3/3][RTL ifcvt] PR middle-end/37780: Conditional expression with __builtin_clz() should be optimized out PR middle-end/37780 * ifcvt.c (noce_try_ifelse_collapse): New function. Declare prototype. (noce_process_if_block): Call noce_try_ifelse_collapse. * simplify-rtx.c (simplify_cond_clz_ctz): New function. (simplify_ternary_operation): Use the above to simplify conditional CLZ/CTZ expressions. * gcc.c-torture/execute/pr37780.c: New test. * gcc.target/aarch64/pr37780_1.c: Likewise. * gcc.target/arm/pr37780_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr37780.c trunk/gcc/testsuite/gcc.target/aarch64/pr37780_1.c trunk/gcc/testsuite/gcc.target/arm/pr37780_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/71437] New: [7 regression' Performance regression after r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 Bug ID: 71437 Summary: [7 regression' Performance regression after r235817 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com Target Milestone: --- We noticed ~10% slowdown on one important benchmark used for Silvermont testing. I can reproduced this performance gap using attached test-case on SandyBridge: before r235817 time ./good.exe W[100]=10 real0m0.761s r235817 W[100]=10 real0m0.863s THere exist another optimization opportunnty, which can be illustrated by the following test fragment: if( i == ( I - 1 ) ) L = pL[i] ; LD = (float)( L - pL[i] ) / (float)( pL[i + 1] - pL[i] ) ; It is clear that LD value is 0 if L == pL[i], i.e. we can move the second statement inside the hammock and perform simplification.
[Bug tree-optimization/71437] [7 regression' Performance regression after r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 --- Comment #1 from Yuri Rumyantsev --- Created attachment 38652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38652&action=edit test-case to reproduce Need to be compiled with -O3 -m32 -ffast-math on x86-64.
[Bug tree-optimization/71438] New: wrong code at -O3 on x86_64-linux-gnu (by tree vectorizer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71438
Bug ID: 71438
Summary: wrong code at -O3 on x86_64-linux-gnu (by tree
vectorizer)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following testcase on x86_64-linux at -O3
in both 32-bit and 64-bit modes.
This appears to be a tree vectorizer bug as it goes away with
-fno-tree-vectorize.
This is a regression from 6.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160606 (experimental) [trunk revision 237117] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-6.1 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c; ./a.out
Aborted (core dumped)
$
$ gcc-trunk -O3 -fno-tree-vectorize small.c; ./a.out
$
---
int a, b, c, d;
int
main ()
{
int e = d = 3;
for (; d >= 0; d--)
{
c = e;
e = a ^ (a && b) && 1;
}
if (c != 0)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/71259] [6/7 Regression] GCC trunk emits wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71259 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Jun 6 18:35:03 2016 New Revision: 237147 URL: https://gcc.gnu.org/viewcvs?rev=237147&root=gcc&view=rev Log: PR tree-optimization/71259 * tree-vect-slp.c (vect_get_constant_vectors): For VECTOR_BOOLEAN_TYPE_P, return all ones constant instead of one for constant op, and use COND_EXPR for non-constant. * gcc.dg/vect/pr71259.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr71259.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug ada/71413] [7 Regression] bootstrap (gnat) broken on arm-linux-gnueabi*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71413 --- Comment #8 from Andreas Schwab --- That fixes the comparison failure on ia64.
[Bug tree-optimization/71259] [6/7 Regression] GCC trunk emits wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71259 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Jun 6 18:47:33 2016 New Revision: 237148 URL: https://gcc.gnu.org/viewcvs?rev=237148&root=gcc&view=rev Log: PR tree-optimization/71259 * tree-vect-slp.c (vect_get_constant_vectors): For VECTOR_BOOLEAN_TYPE_P, return all ones constant instead of one for constant op, and use COND_EXPR for non-constant. * gcc.dg/vect/pr71259.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/vect/pr71259.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-vect-slp.c
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #7 from relliott at umn dot edu --- Hello, I just want to make one think certain. You quoted section 6.3.3.1 of the J3/04-007 document to show that a NAMED local allocatable variable would be deallocated at the end of a routine. However, it is unclear to me that this applies to a POINTER variable (as I have in my skeleton code). In Section 6.3.1.2 is says: Allocation of a pointer creates an object that implicitly has the TARGET attribute. Following successful execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may be used to reference or define the target This seems to say that an UNNAMED allocatable target object is created when the allocate statement for a pointer variable is executed. In which case, section 6.3.3.1 is not applicable. Can you help me to understand why this is not the case? Many thanks, Ryan
[Bug tree-optimization/71259] [6/7 Regression] GCC trunk emits wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71259 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412
--- Comment #8 from Steve Kargl ---
On Mon, Jun 06, 2016 at 06:51:16PM +, relliott at umn dot edu wrote:
>
> I just want to make one think certain. You quoted section 6.3.3.1 of the
> J3/04-007 document to show that a NAMED local allocatable variable would be
> deallocated at the end of a routine.
>
> However, it is unclear to me that this applies to a POINTER variable
> (as I have in my skeleton code).
>
> In Section 6.3.1.2 is says:
>
> Allocation of a pointer creates an object that implicitly has the TARGET
> attribute. Following successful execution of an ALLOCATE statement for a
> pointer, the pointer is associated with the target and may be used to
> reference or define the target
Finishing reading that paragraph:
It is not an error to allocate a pointer that is already
associated with a target. In this case, a new pointer
target is created as required by the attributes of the
pointer and any array bounds, type, and type parameters
specified by the ALLOCATE statement. The pointer is then
associated with this new target. Any previous association
of the pointer with a target is broken. If the previous
target had been created by allocation, it becomes inaccessible
unless other pointers are associated with it.
integer(c_int), pointer, save :: val ! Retain pointer associate with SAVE
allocate(val) ! Allocate a new target object
call store_ptr(index, c_loc(val)) ! Cache pointer for C code.
See more below.
> This seems to say that an UNNAMED allocatable target object is created
> when the allocate statement for a pointer variable is executed. In
> which case, section 6.3.3.1 is not applicable.
>
> Can you help me to understand why this is not the case?
>
6.3.3.1 still applies (see the highlighted phrase).
When the execution of a procedure is terminated by execution of
a RETURN or END statement, an allocatable variable that is a named
local variable of the procedure retains its allocation
and definition status
if it has the SAVE attribute or is a function result variable or
a subobject thereof; otherwise, it is deallocated.
You now need to chase down the meaning of definition status.
16.4.2.1.3
The association status of a pointer becomes undefined when
...
(4) Execution of a RETURN or END statement causes the pointer's
target to become undefined (item (3) of 16.5.6),
(5) A procedure is terminated by execution of a RETURN or END
statement and the pointer is declared or accessed in the
subprogram that defines the procedure unless the pointer
(a) Has the SAVE attribute,
16.5.6
Variables become undefined as follows:
...
(3) When execution of an instance of a subprogram completes,
(a) its unsaved local variables become undefined,
[Bug c++/71330] [6/7 Regression] Compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71330 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Mon Jun 6 19:48:22 2016 New Revision: 237151 URL: https://gcc.gnu.org/viewcvs?rev=237151&root=gcc&view=rev Log: PR c++/70847 PR c++/71330 PR c++/71393 * cp-gimplify.c (cp_fold_r): Set *walk_subtrees = 0 and return NULL right after cp_fold call if cp_fold has returned the same stmt already in some earlier cp_fold_r call. (cp_fold_function): Add pset automatic variable, pass its address to cp_walk_tree. * g++.dg/opt/pr70847.C: New test. * g++.dg/ubsan/pr70847.C: New test. * g++.dg/ubsan/pr71393.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr71393.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Mon Jun 6 19:48:22 2016 New Revision: 237151 URL: https://gcc.gnu.org/viewcvs?rev=237151&root=gcc&view=rev Log: PR c++/70847 PR c++/71330 PR c++/71393 * cp-gimplify.c (cp_fold_r): Set *walk_subtrees = 0 and return NULL right after cp_fold call if cp_fold has returned the same stmt already in some earlier cp_fold_r call. (cp_fold_function): Add pset automatic variable, pass its address to cp_walk_tree. * g++.dg/opt/pr70847.C: New test. * g++.dg/ubsan/pr70847.C: New test. * g++.dg/ubsan/pr71393.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr71393.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/71393] [6/7 Regression] Compilation hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71393 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Jun 6 19:48:22 2016 New Revision: 237151 URL: https://gcc.gnu.org/viewcvs?rev=237151&root=gcc&view=rev Log: PR c++/70847 PR c++/71330 PR c++/71393 * cp-gimplify.c (cp_fold_r): Set *walk_subtrees = 0 and return NULL right after cp_fold call if cp_fold has returned the same stmt already in some earlier cp_fold_r call. (cp_fold_function): Add pset automatic variable, pass its address to cp_walk_tree. * g++.dg/opt/pr70847.C: New test. * g++.dg/ubsan/pr70847.C: New test. * g++.dg/ubsan/pr71393.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr70847.C trunk/gcc/testsuite/g++.dg/ubsan/pr71393.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
