[Bug tree-optimization/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|WAITING |ASSIGNED Component|fortran |tree-optimization --- Comment #8 from Richard Biener --- So it's "easy" to explain. The initialization gets optimized away because appearantly points-to analysis concludes that the allocated storage does not escape: a_3 = &HEAP(10) CALLUSED(12) = &STRING _4 = a_3 D.3422 = a_3 callarg(19) = &D.3422 callarg(19) = *callarg(19) + UNKNOWN CALLUSED(17) = callarg(19) derefaddrtmp(20) = &NONLOCAL *a_3 = derefaddrtmp(20) -> ESCAPED, points-to non-local, points-to vars: { } but this should have included HEAP(10). Let me investigate. It might be still a FE issue.
[Bug ada/71674] missing overflow detection in Ada.Strings.Search
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71674 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 CC||ebotcazou at gcc dot gnu.org Summary|An exception is thrown on a |missing overflow detection |valid code |in Ada.Strings.Search Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Compiling a-strsea.adb with overflow checking enabled yields: raised CONSTRAINT_ERROR : a-strsea.adb:102 overflow check failed if Mapping'Address = Maps.Identity'Address then while Ind <= Source'Last - PL1 loop if Pattern = Source (Ind .. Ind + PL1) then Num := Num + 1; Ind := Ind + Pattern'Length; else Ind := Ind + 1; <=== 102 end if; end loop;
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Component|tree-optimization |fortran --- Comment #9 from Richard Biener --- Confirmed as fortran FE bug. The FE manages to set ".r" as fn spec attribute on save_cptr which specifies that its first argument does not escape. It's trans-types.c:create_fn_spec that does this by doing for (f = gfc_sym_get_dummy_args (sym); f; f = f->next) if (spec_len < sizeof (spec)) { if (!f->sym || f->sym->attr.pointer || f->sym->attr.target || f->sym->attr.external || f->sym->attr.cray_pointer || (f->sym->ts.type == BT_DERIVED && (f->sym->ts.u.derived->attr.proc_pointer_comp || f->sym->ts.u.derived->attr.pointer_comp)) || (f->sym->ts.type == BT_CLASS && (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))) spec[spec_len++] = '.'; else if (f->sym->attr.intent == INTENT_IN) spec[spec_len++] = 'r'; else if (f->sym) spec[spec_len++] = 'w'; } and it looks like the side-effect of marking arguments as not escaping as soon as you specify anything else than . was overlooked. Or Fortran really doesn't allow args to be stored away but has an exception for C binding types which needs handling above.
[Bug target/71680] New: [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 Bug ID: 71680 Summary: [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ra Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-e500v2-linux-gnuspe gcc-7.0.0-alpha20160626 snapshot fails to compile the following testcase w/ -Os -mlra: int om, iz, te; long long int wm, j6; short int nd; void o1 (void) { short int *m9 = &nd; int ty, kc = 2; long long int gi = 0; while (gi != 0) { long long int *dk; int rl = 0; yn: if (j6 / kc != 0) { *m9 = 2; while (*m9 != 0) { m9 = &rl; *m9 = 1; } goto yn; } m9 = &nd; dk = (om != 0) ? &ty : &gi; while (rl != 0) while (te < 1) { while (wm != 0) { ty /= (kc & 1); if (((j6 != 0) + ty) != 0) { nd = rl; if (nd != 0) gi = om = (wm != gi); } while (j6 != 0) { if (wm != 0 && *dk != 0) *dk = kc = 0; wm |= (rl != 0) ? ty : (ty || 0); ++j6; } iz = 2; } rl /= gi; ++te; } } } % powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20160626 -w -c -Os -mlra en3q71xb.c en3q71xb.c: In function 'o1': en3q71xb.c:55:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
[Bug middle-end/66313] Unsafe factorization of a*b+a*c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313 Richard Biener changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2015-10/msg02907.ht ||ml --- Comment #12 from Richard Biener --- See patch at https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02907.html, yes I think even the latest variant regressed at least the tail-recursion testcase and I didn't have time to review Josephs last comment and change the exceptions accordingly. That said, I believe the transform would be best done in the reassoc pass but that has to be enhanced to handle types with non-wrapping overflow characteristics first.
[Bug c++/71658] User-defined conversion operator from a wrapper class to the wrapped type does not compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658 --- Comment #2 from Ulrich Mutze --- Created attachment 38780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38780&action=edit This is a shortened version of the first attachment. It avoids a superfluous complication.
[Bug tree-optimization/70032] tree-ssa-tail-merge engine replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70032 --- Comment #4 from Richard Biener --- Yes, tail-merging needs to utilize a "value-numbering" like IPA ICF (in fact, just re-use its implementation - I think this is what Martins patch set does). My cleanup comment was supposed to be the first cleanup _after_ that patch-set is merged.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #7 from Richard Biener --- ISTR a similar bug in C++ lambda support related how we map them to nested functions. PR69756.
[Bug preprocessor/71681] New: header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 Bug ID: 71681 Summary: header.gcc file lookup is broken for -remap Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: andris.pavenis at iki dot fi Target Milestone: --- Looking up header.gcc files in sub-directories (for example in case of '#include ') is broken as directory separator is missing in generated file names. Added simple debugging output to static method remap_filename() in libcpp/files.c. Some examples illustrating missing directory separator from debug output are given below. remap_filename() finds header file in top directories of include search path but not in subdirectories in part of cases (one is getting new_dir='/usr/includesys/' where name should have been './usr/include/sys/') Test example foo.c: #include "foo/bar/baz.h" #include Used gcc version 7.0.0-20160628. Problem present also in several earlier GCC versions. Problem actually detected for DJGPP, but can easily be reproduced under Linux as done in this case) [andris@localhost test]$ ../xgcc -B ../ -c -remap foo.c remap_filename: fname='foo.c' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='stdc-predef.h' remap_filename: fname='foo/bar/baz.h' remap_filename: new_dir='foo/' remap_filename: new_dir='foo/bar/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='../includesys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='../include-fixedsys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='/usr/local/includesys/' remap_filename: fname='sys/stat.h' remap_filename: new_dir='/usr/includesys/' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='features.h' remap_filename: fname='sys/cdefs.h' remap_filename: new_dir='../includesys/' remap_filename: fname='sys/cdefs.h' remap_filename: new_dir='../include-fixedsys/' remap_filename: fname='sys/cdefs.h'
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Tue Jun 28 08:27:18 2016 New Revision: 237814 URL: https://gcc.gnu.org/viewcvs?rev=237814&root=gcc&view=rev Log: PR middle-end/66867 * builtins.c (expand_ifn_atomic_compare_exchange_into_call, expand_ifn_atomic_compare_exchange): New functions. * internal-fn.c (expand_ATOMIC_COMPARE_EXCHANGE): New function. * tree.h (build_call_expr_internal_loc): Rename to ... (build_call_expr_internal_loc_array): ... this. Fix up type of last argument. * internal-fn.def (ATOMIC_COMPARE_EXCHANGE): New internal fn. * predict.c (expr_expected_value_1): Handle IMAGPART_EXPR of ATOMIC_COMPARE_EXCHANGE result. * builtins.h (expand_ifn_atomic_compare_exchange): New prototype. * gimple-fold.h (optimize_atomic_compare_exchange_p, fold_builtin_atomic_compare_exchange): New prototypes. * gimple-fold.c (optimize_atomic_compare_exchange_p, fold_builtin_atomic_compare_exchange): New functions.. * tree-ssa.c (execute_update_addresses_taken): If optimize_atomic_compare_exchange_p, ignore &var in 2nd argument of call when finding addressable vars, and if such var becomes non-addressable, call fold_builtin_atomic_compare_exchange. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/internal-fn.c trunk/gcc/internal-fn.def trunk/gcc/predict.c trunk/gcc/tree-ssa.c trunk/gcc/tree.h
[Bug c++/71658] User-defined conversion operator from a wrapper class to the wrapped type does not compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71658 --- Comment #3 from Ulrich Mutze --- (In reply to Martin Sebor from comment #1) > I believe the test case is invalid. > > In a call to an operator, operator overload resolution in [over.match.oper] > considers three sets of candidate functions: > 1) member candidates (operators defined as members one of the operands) > 2) non-member candidates (only non-member functions are considered) > 3) built-in candidates (operators that take types to which the operands can > be converted) > > In the test case, sets (1) and (2) are obviously empty. Set (3) is also > empty because there is no well-formed implicit conversion sequence > ([over.best.ics]) from Z1 to int (the conversion exists but would require > two user-defined conversions, one from Z1 to Z and another from Z to int; > such conversions are not well-formed). > > Like GCC, both Clang 3.8 and EDG eccp 3.11 also reject the program. > > The expression "Z(x0)+Z(x1)" is valid because the types of the operands are > Z and thus do not require the second implicit user-defined conversion that > makes set (3) above empty. I believe that (3) is not empty since Z + Z is defined by a member function in Z and the arguments of Z1 + Z1 can be implicitly converted to Z in a single step. The type int is not in the game when Z sum=x0+x1; is under consideration. The implicit conversion Z --> int was enabled simply to allow my function main to return a reasonable value (which is required to be of type int). Sorry for this misleading and superfluous complication in my code.
[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71673 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Jun 28 08:29:11 2016 New Revision: 237815 URL: https://gcc.gnu.org/viewcvs?rev=237815&root=gcc&view=rev Log: PR rtl-optimization/71673 * internal-fn.c (expand_arith_overflow_result_store): Use OPTAB_LIB_WIDEN instead of OPTAB_DIRECT as last argument to expand_simple_binop. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c
[Bug preprocessor/71681] header.gcc file lookup is broken for -remap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71681 --- Comment #1 from Andris Pavenis --- Created attachment 38781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38781&action=edit Fix for problem
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #10 from Dominique d'Humieres --- > Thank you for the suggested workaround. This can certainly be helpful in the > short term. However, we would not want to rely on tuning compiler > optimization switches in the future to ensure correct code operation. ... You can do the inlining in your code, e.g., --- pr71544.f90 2016-06-15 18:54:59.0 +0200 +++ pr71544_db.f90 2016-06-28 10:06:17.0 +0200 @@ -7,10 +7,12 @@ end module store_cptr subroutine init() use, intrinsic :: iso_c_binding +use store_cptr implicit none integer(c_int), pointer :: a allocate(a) -call save_cptr(c_loc(a)) +!call save_cptr(c_loc(a)) +cptr = c_loc(a) a = 100 end subroutine init
[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #7 from Dominik Vogt --- This commit triggers an ICE with s390x. See https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01810.html for details.
[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71673 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Hopefully fixed now.
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |7.0
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Hopefully fixed for 7+.
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 Anton Blanchard changed: What|Removed |Added CC||anton at samba dot org --- Comment #1 from Anton Blanchard --- I'm hitting this on powerpc64le with the following test case: #pragma pack(1) struct { float f0; } a; void foo(int); int main(void) { for (;;) foo((int)a.f0); }
[Bug middle-end/71682] New: [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71682 Bug ID: 71682 Summary: [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15 Target: x86_64-apple-darwin15 Build: x86_64-apple-darwin15 Revision r237556 causes the following failures on x86_64-apple-darwin15 with -m32 FAIL: InvokeReturn execution - source compiled test FAIL: InvokeReturn -findirect-dispatch execution - source compiled test FAIL: InvokeReturn -O3 output - source compiled test FAIL: InvokeReturn -O3 -findirect-dispatch execution - source compiled test FAIL: PR3096 execution - source compiled test FAIL: PR3096 -findirect-dispatch execution - source compiled test FAIL: PR3096 -O3 execution - source compiled test FAIL: PR3096 -O3 -findirect-dispatch execution - source compiled test FAIL: Serialization execution - source compiled test FAIL: Serialization -findirect-dispatch execution - source compiled test FAIL: Serialization -O3 execution - source compiled test FAIL: Serialization -O3 -findirect-dispatch execution - source compiled test FAIL: md5test execution - source compiled test FAIL: md5test -findirect-dispatch execution - source compiled test FAIL: md5test -O3 execution - source compiled test FAIL: md5test -O3 -findirect-dispatch execution - source compiled test FAIL: negzero output - source compiled test FAIL: negzero -findirect-dispatch output - source compiled test FAIL: negzero -O3 output - source compiled test FAIL: negzero -O3 -findirect-dispatch output - source compiled test FAIL: pr21785 execution - source compiled test FAIL: pr21785 -findirect-dispatch execution - source compiled test FAIL: pr21785 -O3 execution - source compiled test FAIL: pr21785 -O3 -findirect-dispatch execution - source compiled test FAIL: pr25676 output - source compiled test FAIL: pr25676 -findirect-dispatch output - source compiled test FAIL: pr25676 -O3 output - source compiled test FAIL: pr25676 -O3 -findirect-dispatch output - source compiled test FAIL: shatest execution - source compiled test FAIL: shatest -findirect-dispatch execution - source compiled test FAIL: shatest -O3 execution - source compiled test FAIL: shatest -O3 -findirect-dispatch execution - source compiled test
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 Jiong Wang changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #2 from Jiong Wang --- Does a revert of r237277 fix this issue?
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 --- Comment #3 from Segher Boessenkool --- anton: What flags for your test case? I fail to reproduce it.
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- Oh never mind, I forgot -mlra, duh. Confirmed, also on BE, -O2 -mlra fails already.
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 --- Comment #5 from Arseny Solokha --- (In reply to Segher Boessenkool from comment #4) > Oh never mind, I forgot -mlra, duh. > > Confirmed, also on BE, -O2 -mlra fails already. I can't make it fail on 32-bit BE, though. Segher, is your machine powerpc64?
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 --- Comment #6 from Segher Boessenkool --- Yes, but it fails with -m32 too.
[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675 --- Comment #2 from Julian Stecklina --- Return bool actually makes sense, because that is the result from the "compare" part of compare/exchange. I am not sure what the meaning of 'type' as a result would be.
[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71680 --- Comment #7 from Segher Boessenkool --- We have an insn: (insn 32 33 34 3 (set (reg:DI 165) (unspec:DI [ (fix:SI (subreg:SF (reg:SI 160 [ a ]) 0)) ] UNSPEC_FCTIWZ)) 71680.c:11 334 {fctiwz_sf} (expr_list:REG_DEAD (reg:SI 160 [ a ]) (nil))) 160 is allocated memory by IRA. LRA does: Changing pseudo 160 in operand 1 of insn 32 on equiv [r162:SI] Creating newreg=167, assigning class ALL_REGS to subreg reg r167 32: r165:DI=unspec[fix(r167:SI#0)] 7 REG_DEAD r160:SI Inserting subreg reload before: 37: r167:SI=[r162:SI] and from then on it keeps loading 167 into another (new) SImode reg, which never magically becomes a float reg ;-)
[Bug tree-optimization/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 Jakub Jelinek changed: What|Removed |Added Component|middle-end |tree-optimization Version|tree-ssa|7.0 Target Milestone|--- |7.0
[Bug target/60882] [ARM] Execution fail on spec2K/197.parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60882 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Earnshaw --- No feedback in over 18 months
[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Earnshaw --- No feedback in over a year
[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 #27 from Richard Earnshaw --- (In reply to David Malcolm from comment #26) > (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...) Is there anything further to be done on this?
[Bug c++/71679] gcc silently accepts parameter number mismatch in template redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71679 --- Comment #1 from Markus Trippelsdorf --- The testcase can be further reduced: template struct A; struct B { template friend struct ::A; }; When using A instead of ::A it works fine and gcc errors out: llvm.ii:3:37: error: redeclared with 2 template parameters template friend struct A; ^ llvm.ii:1:23: note: previous declaration ‘template > struct A’ used 1 template parameter template struct A; ^
[Bug tree-optimization/66917] [4.9 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917 --- Comment #23 from Richard Earnshaw --- Any plans to backport to 4.9, or should this be closed?
[Bug rtl-optimization/67037] [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037 --- Comment #9 from Richard Earnshaw --- Any plans to backport to 4.9, or should this be closed?
[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71639 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Jonathan Wakely --- Right. Debug mode identifies a problem: /home/jwakely/gcc/7/include/c++/7.0.0/debug/safe_iterator.h:297: Error: attempt to increment a singular iterator. Objects involved in the operation: iterator "this" @ 0x0x7ffca3d04820 { type = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector > > (mutable iterator); state = singular; references sequence with type 'std::__debug::vector >' @ 0x0x7ffca3d047a0 } Aborted (core dumped)
[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69187 --- Comment #15 from Richard Earnshaw --- Any plans to backport this further?
[Bug rtl-optimization/69886] ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69886 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.1.0 Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed for GCC 6.1. Not planning backports as it's not a regression
[Bug tree-optimization/71683] New: [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683 Bug ID: 71683 Summary: [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above) Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-7.0.0-alpha20160626 ICEs when compiling the following reduced testcase w/ -ftree-vectorize -O2 (-O3, -Ofast): short unsigned int ve; void u1 (void) { int oq = 0; while (ve != 0) { int j4, w7 = oq; oq = 0 / oq; ve %= oq; j4 = ve ^ 1; ve ^= oq; if (j4 != 0 ? j4 : ve) oq = ve; else if (w7 != 0) oq = ve; } } % gcc-7.0.0-alpha20160626 -c -O2 -ftree-vectorize h0j2boji.c h0j2boji.c: In function 'u1': h0j2boji.c:4:1: internal compiler error: in gen_phi_arg_condition, at tree-if-conv.c:1705
[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675 Martin Sebor changed: What|Removed |Added Keywords|documentation |rejects-valid --- Comment #3 from Martin Sebor --- You're right. I was mistaken in comment #1 about the return value: the function does return a true/false result, but it appears to be of the wrong type. So the documentation is correct (it matches C11 atomic_compare_exchange) and the bug is in the compiler. The root cause seems to be the resolve_overloaded_builtin function in builtins.c calling sync_resolve_return to convert the bool result to the enum, which the C++ front end then rejects.
[Bug middle-end/71682] [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71682 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/71350] [4.9/5/6/7 regression] ICE on trailing return type declaration with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71350 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4 Summary|[4.8/4.9/5/6/7 regression] |[4.9/5/6/7 regression] ICE |ICE on trailing return type |on trailing return type |declaration with|declaration with |initializer list|initializer list
[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Testing a fix.
[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030 --- Comment #8 from Renlin Li --- (In reply to Vladimir Makarov from comment #6) > Created attachment 38033 [details] > A patch > > Here is the patch which might solve the problem. Hi Vladimir, Do you have plan to check this patch in? Thanks!
[Bug libstdc++/71684] New: Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 Bug ID: 71684 Summary: Memory leak with std::mutex and std::lock_guard on freebsd Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: plongstaff at sandvine dot com Target Milestone: --- On freebsd, pthread_mutex_t is a pointer to 'struct pthread_mutex'. PTHREAD_MUTEX_INITIALIZER is defined as NULL. On freebsd, the code: { std::mutex m; std::lock_guard lg(m); } will leak. 'm' will have _M_mutex initialized to NULL. When the std::lock_guard constructor calls gthread_mutex_lock() which calls pthread_mutex_lock(), a 'struct pthread_mutex' will be created using calloc() and then locked. The std::lock_guard destructor will unlock the mutex. However, since std::mutex_base has: // Common base class for std::mutex and std::timed_mutex class __mutex_base { protected: typedef __gthread_mutex_t __native_type; #ifdef __GTHREAD_MUTEX_INIT __native_type _M_mutex = __GTHREAD_MUTEX_INIT; constexpr __mutex_base() noexcept = default; #else __native_type _M_mutex; __mutex_base() noexcept { // XXX EAGAIN, ENOMEM, EPERM, EBUSY(may), EINVAL(may) __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex); } ~__mutex_base() noexcept { __gthread_mutex_destroy(&_M_mutex); } #endif __mutex_base(const __mutex_base&) = delete; __mutex_base& operator=(const __mutex_base&) = delete; }; and __GTHREAD_MUTEX_INIT is defined as NULL, there is no destructor to destroy the mutex. Therefore, that memory is leaked.
[Bug rtl-optimization/67037] [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037 --- Comment #10 from Bernd Edlinger --- (In reply to Richard Earnshaw from comment #9) > Any plans to backport to 4.9, or should this be closed? I won't have time/resources for the necessary regression testing. However the patch is quite simple, and will certainly work as-is.
[Bug c/71685] New: Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Bug ID: 71685 Summary: Segmentation fault in gcc when compiling the attached file. Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vtselfa at gmail dot com Target Milestone: --- Created attachment 38782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38782&action=edit Reduced file that triggers the segfault
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #3 from Richard Earnshaw --- Atomic loads and stores have to use the same policy for a single object, you can't have loads using one model and stores another. Atomic loads have to work even if the object is marked const. C/C++ permit a non-const object pointer to be cast to a const object pointer. That means that any mechanism used for atomic loads has to work with const objects, in particular with objects that are immutable (would trap if modification were attempted). The v8 ARM ARM says that the way to perform a 128-bit atomic read using ldxp is to read the value and then attempt to store it back using a stxp; if the store succeeds, then the read was atomic, otherwise it was not and must be retried. This model doesn't work if the object was immutable, since the store will fault. The consequence of this is that ldxp cannot be used for atomic 128-bit reads. And the consequence of that is that stxp cannot be used for 128-bit stores. Ergo, the only way to perform 128-bit atomic accesses is by using locks. So I think the existing code is correct. I'll leave this open for the moment for further discussion, but I'm minded to reject as INVALID.
[Bug c/71685] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Reduced testcase: extern struct S v, s; struct S { int t; int p[]; } v = { 4, 0 };
[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Jakub Jelinek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||wilson at gcc dot gnu.org Target Milestone|--- |6.2 Summary|Segmentation fault in gcc |[6/7 Regression] |when compiling the attached |Segmentation fault in gcc |file. |when compiling the attached ||file. --- Comment #2 from Jakub Jelinek --- Started with r229505.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- on a posix platform pthread_mutex_destroy should be called for a mutex if its life time ends, so the ifdef logic seems wrong (the initializer does not make a difference).
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Phil Longstaff from comment #0) > std::lock_guard constructor calls gthread_mutex_lock() which calls > pthread_mutex_lock(), a 'struct pthread_mutex' will be created using > calloc() and then locked. I was made aware of this behaviour of FreeBSD recently, but I'm not sure that it's conforming. pthread_mutex_lock() isn't allowed to fail with ENOMEM (and EAGAIN is supposed to mean too many locks are held, not that memory couldn't be allocated). Conforming or not, we need to deal with it.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #3 from Jonathan Wakely --- (In reply to nsz from comment #1) > on a posix platform pthread_mutex_destroy should be called for a mutex if > its life time ends, so the ifdef logic seems wrong (the initializer does not > make a difference). I don't think that's clear from the POSIX spec. In previous versions PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically allocated objects, which live for the lifetime of the program and so there's typically no need (or sensible time) to destroy them. http://austingroupbugs.net/view.php?id=70#c127 changed the rules so now you can use the initializer for automatic objects, and structure members, but it's unclear whether you do need to use pthread_mutex_destroy on them. Maybe POSIX should clarify. On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then pthread_mutex_destroy would segfault, see http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html So it's not clear to me that using that combination is a good idea.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then > pthread_mutex_destroy would segfault, see > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html I misremembered, it aborts. Still not good though.
[Bug c++/71679] gcc silently accepts parameter number mismatch in template redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71679 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 Ever confirmed|0 |1
[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71656 --- Comment #5 from Peter Bergner --- Author: bergner Date: Tue Jun 28 15:49:10 2016 New Revision: 237823 URL: https://gcc.gnu.org/viewcvs?rev=237823&root=gcc&view=rev Log: PR target/71656 * gcc.target/powerpc/pr71656-2.c: Fix syntax errors. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr71656-2.c
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #4 from Yichao Yu --- Thanks for the explanation. I didn't realize that the load is the problem. Just curious (since I somehow can't find documentation about it), would `ldaxp` provide the right semantics without the corresponding store?
[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71675 --- Comment #5 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01896.html
[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Jakub Jelinek changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 38783 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38783&action=edit gcc7-pr71685.patch Untested fix.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #5 from Richard Earnshaw --- I don't think so. It's to do with whether the CPU is permitted to 'crack' the operation into multiple micro-ops that proceed independently down the pipeline. LDAXP could still be cracked in this way provided that from that CPU's perspective other memory operations from that core were not re-ordered with respect to that operation in an incompatible manner. However, external memory operations could still cause the separate micro-ops to see different values.
[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-28 CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started wutg r235808.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- Closing as invalid. Though for v8.4 or so it would be nice if there was 128bit atomic loads.
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #3) > (In reply to nsz from comment #1) > > on a posix platform pthread_mutex_destroy should be called for a mutex if > > its life time ends, so the ifdef logic seems wrong (the initializer does not > > make a difference). > > I don't think that's clear from the POSIX spec. In previous versions > PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically > allocated objects, which live for the lifetime of the program and so there's > typically no need (or sensible time) to destroy them. > > http://austingroupbugs.net/view.php?id=70#c127 changed the rules > so now you can use the initializer for automatic objects, and structure > members, but it's unclear whether you do need to use pthread_mutex_destroy > on them. > Maybe POSIX should clarify. > i see. > On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then > pthread_mutex_destroy would segfault, see > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html > > So it's not clear to me that using that combination is a good idea. in the current spec PTHREAD_MUTEX_INITIALIZER must have the same effect as pthread_mutex_init(&m,0) without error checks, which means pthread_mutex_destroy should work accordingly (and indeed pthread_mutex_lock should not fail with ENOMEM either). so this may need platform specific workarounds.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #6 from Andrew Pinski --- (In reply to Richard Earnshaw from comment #5) > I don't think so. It's to do with whether the CPU is permitted to 'crack' > the operation into multiple micro-ops that proceed independently down the > pipeline. LDAXP could still be cracked in this way provided that from that > CPU's perspective other memory operations from that core were not re-ordered > with respect to that operation in an incompatible manner. However, external > memory operations could still cause the separate micro-ops to see different > values. Makes sense (and I Know of one micro arch which will doing that for casp). So closing as invalid. Note the locks used in libatomic are no where near fair and can cause sometimes not progressing on one thread (but that is a separate bug and is recorded as bug 59305).
[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 --- Comment #4 from Jim Wilson --- The problem here is that I assumed that c_build_qualified_type would only be called when we want to create a variant type. However, there are a number of places that call it without checking to see if we have any type qualifiers first. These places can call it with no qualifiers, in which case it returns the original type, which may be a main variant type. So we need to avoid clearing C_TYPE_INCOMPLETE_TYPE in that case. Perhaps with an early exit at the top if type_quals is 0. Or alternatively, at the bottom, we can clear C_TYPE_INCOMPLETE_TYPE only if var_type != type.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #8 from Richard Earnshaw --- (In reply to Andrew Pinski from comment #7) > Closing as invalid. Though for v8.4 or so it would be nice if there was > 128bit atomic loads. That probably wouldn't help. It would require a new ABI before you could use them, since all code has to swap to that mechanism. Iff you could guarantee that an application had exactly one instance of __atomic_{load,store}_16 (ie that it isn't a private function in each DSO component), then you *might* be able to re-implement those routines using the new instructions, but otherwise you're stuck with the requirement to retain backwards compatibility.
[Bug target/70814] atomic store of __int128 is not lock free on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814 --- Comment #9 from Andrew Pinski --- (In reply to Richard Earnshaw from comment #8) > (In reply to Andrew Pinski from comment #7) > > Closing as invalid. Though for v8.4 or so it would be nice if there was > > 128bit atomic loads. > > That probably wouldn't help. It would require a new ABI before you could > use them, since all code has to swap to that mechanism. Iff you could > guarantee that an application had exactly one instance of > __atomic_{load,store}_16 (ie that it isn't a private function in each DSO > component), then you *might* be able to re-implement those routines using > the new instructions, but otherwise you're stuck with the requirement to > retain backwards compatibility. On x86, they use ifuncs for this purpose inside libatomic. Basically the requirement is only one libatomic can be used at a time.
[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71683 --- Comment #2 from Arseny Solokha --- (In reply to Jakub Jelinek from comment #1) > Started wutg r235808. Must be a duplicate of PR71503, then.
[Bug target/58655] [avr] -mfract-convert-truncate not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655 --- Comment #1 from denisc at gcc dot gnu.org --- Author: denisc Date: Tue Jun 28 17:56:37 2016 New Revision: 237825 URL: https://gcc.gnu.org/viewcvs?rev=237825&root=gcc&view=rev Log: PR target/58655 * config/avr/avr.opt (-mfract-convert-truncate): Update description. * doc/invoke.texi (AVR Options): Document it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.opt trunk/gcc/doc/invoke.texi
[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70524 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #5 from Gerhard Steinmetz --- There is a different ICE for a subset of the above group. A selection of affected files from gfortran testsuite : character_array_constructor_1.f90 char_pack_2.f90 missing_optional_dummy_6.f90 optional_absent_1.f90 pr43793.f90 pr48636.f90 whole_file_9.f90 For example : $ gfortran-7-20160626 -frepack-arrays -Warray-temporaries -c pr43793.f90 pr43793.f90:11:31: rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos) 1 Warning: Creating array temporary at (1) [-Warray-temporaries] pr43793.f90:5:0: subroutine sparse_alltoall (rs, rq, rcount) in linemap_position_for_loc_and_offset, at libcpp/line-map.c:897 0x138c523 linemap_position_for_loc_and_offset(line_maps*, unsigned int, unsigned int) ../../libcpp/line-map.c:897 0x6822fc gfc_format_decoder ../../gcc/fortran/error.c:943 0x13771f8 pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:643 0x13720f0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:827 0x68205f gfc_warning ../../gcc/fortran/error.c:792 0x682ce6 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.c:823 0x72a291 gfc_trans_dummy_array_bias(gfc_symbol*, tree_node*, gfc_wrapped_block*) ../../gcc/fortran/trans-array.c:6177 0x7466ec gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4268 0x749223 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6275 0x71ea79 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2056 0x6d4bfd translate_all_program_units ../../gcc/fortran/parse.c:5830 0x6d4bfd gfc_parse_file() ../../gcc/fortran/parse.c:6049 0x717142 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:201
[Bug middle-end/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71626 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Jun 28 18:31:42 2016 New Revision: 237826 URL: https://gcc.gnu.org/viewcvs?rev=237826&root=gcc&view=rev Log: PR middle-end/71626 * config/i386/i386.c (ix86_expand_vector_move): For SUBREG of a constant, force its SUBREG_REG into memory or register instead of whole op1. * gcc.c-torture/execute/pr71626-1.c: New test. * gcc.c-torture/execute/pr71626-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr71626-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr71626-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/71686] New: ICE on broken character continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686 Bug ID: 71686 Summary: ICE on broken character continuation Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- With a broken character continuation : $ cat z1.f90 program p character(8) :: z z = 'abc& !end $ cat z2.f90 program p character(8) :: z = 'abc& !end $ gfortran-6 z1.f90 f951: internal compiler error: Segmentation fault $ gfortran-6 z2.f90 f951: internal compiler error: Segmentation fault --- Whereas : $ cat z3.f90 program p character(8) :: z = 'abc& $ gfortran-6 z3.f90 z3.f90:2:24: character(8) :: z = 'abc& 1 Error: Unterminated character constant beginning at (1)
[Bug fortran/71687] New: ICE in omp_add_variable, at gimplify.c:5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71687 Bug ID: 71687 Summary: ICE in omp_add_variable, at gimplify.c:5821 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Using -fopenmp together with -fstack-arrays or -Ofast for a test similar to pr49792 (also related to pr69281) : $ cat z1.f90 subroutine s (n, x) integer :: n real :: x(n) !$omp parallel x(1:n) = x(n:1:-1) !$omp end parallel end $ gfortran-6 -fopenmp -fstack-arrays -c z1.f90 z1.f90:5:0: x(1:n) = x(n:1:-1) internal compiler error: in omp_add_variable, at gimplify.c:5821
[Bug fortran/71687] ICE in omp_add_variable, at gimplify.c:5821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71687 --- Comment #1 from Gerhard Steinmetz --- As known, case above works with "workshare" : $ cat z2.f90 subroutine s (n, x) integer :: n real :: x(n) !$omp parallel workshare x(1:n) = x(n:1:-1) !$omp end parallel workshare end
[Bug fortran/71688] New: ICE in analyze, at cgraphunit.c:632
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71688 Bug ID: 71688 Summary: ICE in analyze, at cgraphunit.c:632 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Aborting with gfortran-7-20160626, 6.1, 5.4, 4.9 : $ cat z1.f90 program p call s contains subroutine s real, save :: x[*] x = 2 block end block end end $ gfortran-6 -fcoarray=single z1.f90 $ gfortran-6 -fcoarray=lib z1.f90 z1.f90:1:0: program p internal compiler error: in analyze, at cgraphunit.c:632
[Bug fortran/71688] ICE in analyze, at cgraphunit.c:632
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71688 --- Comment #1 from Gerhard Steinmetz --- Modified a bit : $ cat z2.f90 program p call s contains subroutine s real :: x[*] = 1 block end block x = 2 end end $ gfortran-6 -fcoarray=lib z2.f90 z2.f90:1:0: program p internal compiler error: in analyze, at cgraphunit.c:632
[Bug middle-end/71626] [4.9/5/6 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71626 Jakub Jelinek changed: What|Removed |Added Summary|[4.9/5/6/7 regression] ICE |[4.9/5/6 regression] ICE at |at -O1 and above on |-O1 and above on |x86_64-linux-gnu (in|x86_64-linux-gnu (in |output_constant_pool_2, at |output_constant_pool_2, at |varasm.c:3837) |varasm.c:3837) --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/58655] [avr] -mfract-convert-truncate not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #2 from Georg-Johann Lay --- Done.
[Bug c/71689] New: Missing dwarf info when using nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71689 Bug ID: 71689 Summary: Missing dwarf info when using nested function Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: asnast at gmail dot com Target Milestone: --- Hello, The following piece of code will fail to correctly generate dwarf function signature information: void outer(int *x) { *x *= 2; void inner(void) { *x += 1; } } int main() { return 0; } When compiling with "gcc -g " a DW_TAG_formal_parameter DIE is not generated for 'x' parameter for outer function above: dwarfdump -a ./a.out: LOCAL_SYMBOLS: < 1><0x002d>DW_TAG_subprogram DW_AT_external yes(1) DW_AT_name "outter" DW_AT_decl_file 0x0001 /home/alexsn/tst.c DW_AT_decl_line 0x0001 DW_AT_prototypedyes(1) DW_AT_low_pc0x00400566 DW_AT_high_pc 68 DW_AT_frame_baselen 0x0001: 9c: DW_OP_call_frame_cfa DW_AT_GNU_all_tail_call_sitesyes(1) DW_AT_sibling <0x005e> < 2><0x004a> DW_TAG_subprogram ... Note that this only occurs if 'x' parameter if used from both outer and inner function and removing either will correctly generate the missing DIE: void outer(int *x) { void inner(void) { *x += 1; } } or void outer(int *x) { *x *= 2; void inner(void) { } } Will generate: LOCAL_SYMBOLS: < 1><0x002d>DW_TAG_subprogram DW_AT_external yes(1) DW_AT_name "outter" DW_AT_decl_file 0x0001 /home/alexsn/tst.c DW_AT_decl_line 0x0001 DW_AT_prototypedyes(1) DW_AT_low_pc0x00400566 DW_AT_high_pc 58 DW_AT_frame_baselen 0x0001: 9c: DW_OP_call_frame_cfa DW_AT_GNU_all_tail_call_sitesyes(1) DW_AT_sibling <0x005e> < 2><0x004a> DW_TAG_formal_parameter DW_AT_name "x" DW_AT_decl_file 0x0001 /home/alexsn/tst.c DW_AT_decl_line 0x0001 DW_AT_type <0x005e> I've tested this on gcc 4.8.4 and gcc 5.3.1 both of which havethis issue. Thanks, Alex.
[Bug c/71552] Confusing error for incorrect struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71552 --- Comment #6 from Martin Sebor --- Author: msebor Date: Tue Jun 28 20:09:36 2016 New Revision: 237829 URL: https://gcc.gnu.org/viewcvs?rev=237829&root=gcc&view=rev Log: PR c/71552 - Confusing error for incorrect struct initialization gcc/c/ChangeLog: PR c/71552 * c-typeck.c (output_init_element): Diagnose incompatible types before non-constant initializers. gcc/testsuite/ChangeLog: PR c/71552 * gcc.dg/init-bad-9.c: New test. Added: trunk/gcc/testsuite/gcc.dg/init-bad-9.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/71552] Confusing error for incorrect struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71552 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed in r237829.
[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 Tiago de Paula Peixoto changed: What|Removed |Added CC||tiago at skewed dot de --- Comment #10 from Tiago de Paula Peixoto --- Just chiming in here: This code makes heavy use of templates, and indeed takes many gigs of RAM to compile. Although it would be nice if GCC were able to compile it using less memory, I do not believe this is really a bug at all.
[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71671 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Markus Trippelsdorf --- Yeah. And we still have no testcase. Closing.
[Bug middle-end/71690] New: integer conversion defeats memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 Bug ID: 71690 Summary: integer conversion defeats memcpy optimizaton Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Both functions in the following program are expected to result in comparably efficient code. In expand_builtin_memcpy, GCC decides whether an invocation of __builtin_memcpy will be expanded inline or result in a library call. Among the factors it uses to make that decision is the range of sizes of the copy. The range is obtained from the result of the Value Range Propagation optimization for the size argument, provided the argument is constrained to a subrange of its type. When the argument's type is other than size_t, VRP makes the range available, and the call to memcpy may be expanded inline (this is the case with the function g below). But when the argument's type is size_t, VRP does not make its range available, and the expansion results in a library call, thus defeating the optimization. This seems to be a general problem with VRP, not one limited to memcpy (I just used memcpy as an example). Any built-in whose expansion depends on the result of VRP of one of its arguments may be affected. char d [10]; char s [10]; void f (int); void g (unsigned n) { if (n >= sizeof d) return; __builtin_memcpy (d, s, n); } void h (unsigned long n) { if (n >= sizeof d) return; __builtin_memcpy (d, s, n); } The problem can be seen in the generated assembly and also in the vrp dump for the program (see the <<< annotations): Value ranges after VRP: ... _1: [0, 9] .MEM_2: VARYING n_3(D): VARYING n_6: [0, 9] EQUIVALENCES: { n_3(D) } (1 elements) g (unsigned int n) { long unsigned int _1; : if (n_3(D) > 9) goto ; else goto ; : _1 = (long unsigned int) n_3(D); <<< constrained to [0, 9] __builtin_memcpy (&d, &s, _1); : return; } ... Value ranges after VRP: .MEM_1: VARYING n_2(D): VARYING n_5: [0, 9] EQUIVALENCES: { n_2(D) } (1 elements) h (long unsigned int n) { : if (n_2(D) > 9) goto ; else goto ; : __builtin_memcpy (&d, &s, n_2(D)); <<< n_2(D) is VARYING : return; }
[Bug middle-end/71690] integer conversion defeats memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 --- Comment #1 from Martin Sebor --- See also C++ bug 71654 for the "inverse" of the problem where VRP successfully provides range information in the absence of a conversion but fails with it.
[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70524 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Gerhard Steinmetz from comment #5) > There is a different ICE for a subset of the above group. It is probably a similar issue: gfortran is passing a wrong location. You need to figure out using gdb what loc and offset is being passed to linemap_position_for_loc_and_offset, where do they come from and what should be passed instead. The ICEs should only happen with --enabled-checking. Released compilers do not ICE but give a wrong location.
[Bug middle-end/71654] [6/7 Regression] missing VRP optimization on c++ unsigned char and short expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71654 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Don't have the time to thoroughly test at the moment but this seems to fix it on the VRP side: diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index c2115f4..1a0aa42 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -5298,7 +5298,7 @@ register_edge_assert_for_1 (tree name, edge e, gimple_stmt_iterator bsi, if (CONVERT_EXPR_CODE_P (rhs_code) && INTEGRAL_TYPE_P (TREE_TYPE (name2)) && TYPE_UNSIGNED (TREE_TYPE (name2)) - && prec == TYPE_PRECISION (TREE_TYPE (name2)) + && prec >= TYPE_PRECISION (TREE_TYPE (name2)) && (comp_code == LE_EXPR || comp_code == GT_EXPR || !tree_int_cst_equal (val, TYPE_MIN_VALUE (TREE_TYPE (val
[Bug middle-end/71690] absence of integer conversion defeats memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 --- Comment #2 from Andrew Pinski --- (In reply to Martin Sebor from comment #1) > See also C++ bug 71654 for the "inverse" of the problem where VRP > successfully provides range information in the absence of a conversion but > fails with it. That is a totally different issue. The issue here is that range information has to be correct for all places where the name is used. Without a cast the name is used in both the comparison and in the memcpy so the range needs to be empty so the comparison is not removed.
[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Jun 28 22:30:04 2016 New Revision: 237830 URL: https://gcc.gnu.org/viewcvs?rev=237830&root=gcc&view=rev Log: PR c/71685 * c-typeck.c (c_build_qualified_type): Don't clear C_TYPE_INCOMPLETE_VARS for the main variant. * gcc.dg/pr71685.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr71685.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/71690] absence of integer conversion defeats memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 --- Comment #3 from Andrew Pinski --- To fix this, would mean we keep around copies and PHInodes longer. I don't know if we want to do that because it causes code generation to be very bad really.
[Bug c/71685] [6 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression]|[6 Regression] Segmentation |Segmentation fault in gcc |fault in gcc when compiling |when compiling the attached |the attached file. |file. | --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/71685] [6 Regression] Segmentation fault in gcc when compiling the attached file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71685 --- Comment #7 from Jim Wilson --- An early exit if type_quals is 0 does not work, as there is at least one place that deliberately calls c_build_qualified_type with no type qualifiers to create an unqualified type from a qualified type. Likewise, my earlier suggestion of a check for var_type != type can't work as it fails in this case too. I can see another possible fix, checking for type_quals non-zero before clearing the C_TYPE_INCOMPLETE_VARS, but given how complicated this code is turning out to be, the check for a type main variant is the safest fix. And I see that Jakub has just checked in a patch for that solution, so I'm assuming I don't need to do anymore work on this.
[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 Martin Sebor changed: What|Removed |Added Summary|absence of integer |some integer conversions |conversion defeats memcpy |defeat memcpy optimizaton |optimizaton | --- Comment #4 from Martin Sebor --- While debugging this I noticed other cases where VRP either doesn't make the range information available at all, or makes a "super-range" of the actual range available. I used the script below to see what types defeat the optimization in what languages (C in the second column and C++ in the third). Based on the results a more accurate description of the problem might be that some integer conversions (including the identity conversion if there were such a thing) defeat VRP. An interesting case is unsigned short in C++ where VRP misses the value range altogether but exposes the range of the type instead. $ cat vrp.c && for t in signed unsigned; do for u in char short int long 'long long'; do printf "%-20s " "$t $u"; for l in c c++; do m=$(/build/gcc-6-branch/gcc/xgcc -B/build/gcc-6-branch/gcc -DT="$t $u" -O2 -S -Wall -Wextra -Wpedantic -o/dev/stdout -x$l vrp.c 2>/dev/null | grep memcpy); if [ "$m" ]; then printf "%-8s" call; else printf "%-8s" inline; fi; done; echo; done; done char d [10]; char s [10]; void f (T n) { if (n < 0 || n >= 10) return; __builtin_memcpy (d, s, n); } signed char inline inline signed short inline inline signed int inline inline signed long callcall signed long long callcall unsigned charinline inline unsigned short inline call unsigned int inline inline unsigned longcallcall unsigned long long callcall
[Bug fortran/71686] ICE on broken character continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- With this patch: diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c index 6a7a5b68..be9c5091 100644 --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -1416,7 +1416,8 @@ restart: { if (in_string) { - gfc_current_locus.nextc--; + if (gfc_current_locus.nextc) + gfc_current_locus.nextc--; if (warn_ampersand && in_string == INSTRING_WARN) gfc_warning (OPT_Wampersand, "Missing %<&%> in continued character " @@ -1427,7 +1428,10 @@ restart: /* Both !$omp and !$ -fopenmp continuation lines have & on the continuation line only optionally. */ else if (openmp_flag || openacc_flag || openmp_cond_flag) - gfc_current_locus.nextc--; + { + if (gfc_current_locus.nextc) + gfc_current_locus.nextc--; + } else { c = ' '; I get: $ gfc bug1.f90 bug1.f90:3:8: z = 'abc& 1 Error: Unterminated character constant beginning at (1) f951: Error: Unexpected end of file in ‘bug1.f90’ $ gfc bug2.f90 bug2.f90:2:24: character(8) :: z = 'abc& 1 Error: Unterminated character constant beginning at (1) f951: Error: Unexpected end of file in ‘bug2.f90’
[Bug fortran/71686] ICE on broken character continuation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71686 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-29 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jerry DeLisle --- I will take this one.
[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 --- Comment #5 from Martin Sebor --- In addition to the data in comment #4, the script below extracts VRP ranges for an argument passed via the ellipsis to __builtin_snprintf. The script output shows that despite the same bounds on a variable, VRP exposes different ranges for different types of the variable, and the ranges sometimes differ between C and C++. Unfortunately, the ranges only correspond to the actual bounds in the relatively rare cases of char and short in C, and only in the signed forms of those types in C++. Cells with anything but [0, 9] in them indicate a suboptimal result. That the correct range be made available is important to me because of a patch for bug 49905 I'm testing because it would help reduce false positives. $ (cat vrp.c && for t in signed unsigned; do for u in char short int long 'long long'; do printf "%-20s " "$t $u"; for l in c c++; do /build/gcc-6-branch/gcc/xgcc -B/build/gcc-6-branch/gcc -DT="$t $u" -O2 -S -Wall -Wextra -Wpedantic -fdump-tree-vrp=vrp.out -x$l vrp.c 2>/dev/null; v=$(sed -n "s/ *__builtin_snprintf.*, *\([^ ,]*\));/\1/p" vrp.out); r=$(sed -n "s/^$v: *\(.*\)/\1/p" vrp.out | tail -n1); printf "%-20s" "$r"; done; echo; done; done) char d [10]; char s [10]; void f (T n) { if (n < 0 || n >= 10) return; __builtin_snprintf (d, 10, "%i", n); } signed char [0, 9] [0, 9] signed short [0, 9] [0, 9] signed int VARYING VARYING signed long VARYING VARYING signed long long VARYING VARYING unsigned char[0, 9] [0, 255] unsigned short [0, 9] [0, 65535] unsigned int VARYING VARYING unsigned longVARYING VARYING unsigned long long VARYING VARYING
[Bug tree-optimization/71691] New: wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 Bug ID: 71691 Summary: wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com Target Milestone: --- $ 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 20160628 (experimental) [trunk revision 237830] (GCC) $ $ gcc-trunk -O3 -m32 small.c ; ./a.out Floating point exception (core dumped) $ $ gcc-trunk -O3 -m64 small.c ; ./a.out Floating point exception (core dumped) $ $ gcc-trunk -O2 -m64 small.c ; ./a.out $ $ cat small.c char b; short f; unsigned e; int g = 20; void fn1() { int l = 0; for (; l <= 7; l++) { int h, j = 38; if (g) h = 0; for (; h <= 7; h++) { int i, k = b % (j % 4); g = f; for (;;) { j = 6 || b; if (e) { for (; j; --j) if (k) __builtin_printf("%d", 9); if (i) __builtin_printf("%d", j); } if (l) continue; break; } i = f || b; } } } int main() { fn1(); return 0; } $