[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-05-23 CC||jakub at gcc dot gnu.org Component|target |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Uh. .optimized: float sumfloat_omp(const float*) (const float * arr) { unsigned long ivtmp.22; vector(8) float D__lsm0.19; const vector(8) float vect__23.18; const vector(8) float vect__4.16; float stmp_sum_19.12; vector(8) float vect__18.10; float D.2841[8]; vector(8) float _10; void * _77; unsigned long _97; [1.00%]: arr_13 = arr_12(D); __builtin_memset (&D.2841, 0, 32); _10 = MEM[(float *)&D.2841]; ivtmp.22_78 = (unsigned long) arr_13; _97 = ivtmp.22_78 + 4096; ... [1.00%]: MEM[(float *)&D.2841] = vect__23.18_58; vect__18.10_79 = MEM[(float *)&D.2841]; stmp_sum_19.12_50 = [reduc_plus_expr] vect__18.10_79; return stmp_sum_19.12_50; well, that explains it ;) Coming from [99.00%]: # i_33 = PHI # ivtmp_35 = PHI _21 = GOMP_SIMD_LANE (simduid.0_14(D)); _1 = (long unsigned int) i_33; _2 = _1 * 4; _3 = arr_13 + _2; _4 = *_3; _22 = D.2841[_21]; _23 = _4 + _22; D.2841[_21] = _23; i_25 = i_33 + 1; ivtmp_28 = ivtmp_35 - 1; if (ivtmp_28 != 0) goto ; [98.99%] so we perform the reduction in memory, then LIM performs store-motion on it but the memset isn't inlined early enough to rewrite the decl into SSA (CCP from GOMP_SIMD_VF is missing). In DOM we have __builtin_memset (&D.2841, 0, 32); _10 = MEM[(float *)&D.2841]; so we do not fold that. If OMP SIMD always zeros the vector then it could also emit the maybe easier to optimize WITH_SIZE_EXPR<_3, D.2841> = {}; of course gimple_fold_builtin_memset should simply be improved to optimize now constant-size memset to = {}. I'll have a look.
[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW Target Milestone|--- |6.4 Summary|ipa-cp wrongly adding |[6 regression] ipa-cp |LO(symbol) twice|wrongly adding LO(symbol) ||twice --- Comment #8 from Eric Botcazou --- OK, I can reproduce now, it comes from the -fdelayed-branch option.
[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #9 from Eric Botcazou --- Investigating.
[Bug bootstrap/80860] AIX Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-23 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed. Bisection in progress.
[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844 --- Comment #2 from Jakub Jelinek --- (In reply to Richard Biener from comment #1) > If OMP SIMD always zeros the vector then it could also emit the maybe easier > to optimize > > WITH_SIZE_EXPR<_3, D.2841> = {}; It doesn't always zero, it can be pretty arbitrary. For the default reductions on integral/floating point types it does zero for +/-/|/^/|| reductions, but e.g. 1 for */&&, or ~0 for &, or maximum or minimum for min or max. For user defined reductions it can be whatever the user requests, constructor for some class type, function call, set to arbitrary value etc. For other privatization clauses it is again something different (uninitialized for private/lastprivate, some other var + some bias for linear, ...). And then after the simd loop there is again a reduction or something similar, but again can be quite complex in the general case. If it helps, we could mark the pre-simd and post-simd loops somehow in the loop structure or something, but the actual work needs to be done later, especially after inlining, including the vectorizer and other passes. E.g. for the typical reduction where the vectorizer computes the "simd array" in a vector temporary (or collection of them), it would be nice if we were able to pattern recognize simple cases and turn those into vector reduction patterns.
[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 --- Comment #2 from Peter Cordes --- (In reply to Richard Biener from comment #1) > GCC 8 generates a __atomic_load_16 call for me while GCC 6 does > > lock cmpxchg16b (%rdi) That's expected. See https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02344.html for the reason. (Apparently the plan is for gcc7 to call libatomic, to make it possible to change the implementation sooner in the future if that's deemed appropriate, even in ways that breaks compat with code that inlines lock cmpxchg16b.) The bug here is that gcc7.1.0 goes berserk after the library call, but gcc8 doesn't. I haven't tested on any other gcc7 versions.
[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844 --- Comment #3 from Peter Cordes --- (In reply to Jakub Jelinek from comment #2) > It doesn't always zero, it can be pretty arbitrary. Is if feasible have it just load the first vector of elements, instead of broadcasting the identity value? i.e. do the vector equivalent of sum = a[0] for (i=1; ...) i.e. peel the first iteration and optimize away the computation, leaving just the load. Another way to handle the actual loop body running zero times for counts between 1 and 2 full vectors is to put the loop entry point after the first load & accumulate. (BTW, for operations like min/max/AND/OR where duplicate values don't affect the result, an unaligned final vector would be much more efficient than a scalar cleanup for the last less-than-full-vector of elements, but you still need a scalar fallback if the total count can be smaller than 1 full vector...)
[Bug bootstrap/80860] AIX Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860 --- Comment #2 from Segher Boessenkool --- It is memory corruption. PR80843 may be the same. It is caused by my r248256, sws for FP. I have a patch. What a silly bug.
[Bug bootstrap/80860] AIX Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug driver/80836] final binaries missing rpath despite all attempts to use the appropriate -Wl,-rpath= statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80836 René J.V. Bertin changed: What|Removed |Added Host||linux --- Comment #4 from René J.V. Bertin --- I've been trying to get this right, but without luck. In my latest attempt I had -Wl,-rpath statements in BOOT_LDFLAGS as well as in LDFLAGS during the configure, make and "make install" steps and I also configured them using --with-stage1-ldflags . Yet my binaries didn't contain any rpath information at all. I don't think it's such an uncommon situation to build gcc for installation somewhere other than /usr. Non-privileged users may build for installation under their home directory, and what's more, a standard (64bit) build on Ubuntu will apparently put the runtime libraries into /usr/lib64 or /usr/local/lib64, which is NOT a system standard location. There should really be a reliable and easily accessible method to achieve this: --with-stdlib-rpaths : add the stdlib (libgcc_s, libstdc++, libfortran etc) paths to the RPATH of the generated executable (including the GCC executables) --with-rpaths : build the GCC executables and libraries with the paths to all dependencies stored in the RPATH. I think those are the 2 distinct aspects of the issue, but I'm not certain it's justified not to handle them with a single option. FWIW, this is all not an issue on Mac where dependencies are stored with their full path by default. A hassle sometimes, but most of the time it makes life a lot easier.
[Bug bootstrap/80860] AIX Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860 --- Comment #3 from David Edelsohn --- But I had a successful bootstrap with r248295, which is after your patch.
[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue May 23 10:16:08 2017 New Revision: 248362 URL: https://gcc.gnu.org/viewcvs?rev=248362&root=gcc&view=rev Log: PR libstdc++/67214 Avoid signed overflow in num_get::_M_extract_int 2017-05-23 Xi Ruoyao PR libstdc++/67214 * include/bits/locale_facets.tcc (num_get::_M_extract_int): Add explicit conversion to avoid signed overflow. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc
[Bug target/80862] New: [x86] Wrong rounding results for some test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80862 Bug ID: 80862 Summary: [x86] Wrong rounding results for some test cases Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.peryt at intel dot com CC: julia.koval at intel dot com, ubizjak at gmail dot com Target Milestone: --- Target: X86 Created attachment 41408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41408&action=edit Patch to reproduce described error. Recently I have found that rounding intrinsics for some particular cases produce wrong results. There have to be three specific conditions fulfilled to produce it: - test has to be compiled with O1 or O2 (doesn't appear on O0), - test case has to have only two intrinsics - regular (e.g. _mm512_cvtps_epi32) and round (e.g. _mm512_cvt_roundps_epi32), - both intrinsics must use the same input argument. As a result value from first (regular) intrinsic is copied to the second (round)intrinsic result. In asm output it can be seen that the same register is used for both assignments: vcvtps2dq %zmm0, %zmm1 vmovdqa64 %zmm1, -368(%rbp) pushq -312(%rbp) pushq -320(%rbp) pushq -328(%rbp) vcvtps2dq {rz-sae}, %zmm0, %zmm0 pushq -336(%rbp) vmovdqa64 %zmm1, -304(%rbp) >From what I gathered so far this is happening due to the use of parallel side effect for rounding md template in i386/subst.md. Because parallel is executing each side effect individually at first, on cse1 pass the part which is similar for both intrinsics get optimized. After that the same register is assigned for move operation in both assignments of the results and effectively regular and round intrinsic produces the same result. Probably some other side effect has to be used to set rounding flags to fix this issue, but I am not sure which one it should be. Eventually some modifications have to be made in cse.c to properly handle such use of parallel.
[Bug target/80863] New: [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80863 Bug ID: 80863 Summary: [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330 Product: gcc Version: 8.0 URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna pshot&arch=sh4&ver=20170520-1&stamp=1495506518&raw=0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: doko at gcc dot gnu.org, jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* Trying to build a current gcc-8 snapshot in Debian unstable on sh4 fails with: /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu -I/<>/build/prev-sh4-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o sh.o -MT sh.o -MMD -MP -MF ./.deps/sh.TPo ../../src/gcc/config/sh/sh.c ../../src/gcc/config/sh/sh.c: In function 'void output_stack_adjust(int, rtx, int, HARD_REG_ELT_TYPE (*)[5], bool)': ../../src/gcc/config/sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330 } ^ mmap: Permission denied Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc7otGNI.out file, please attach this to your bugreport. I currently don't have the preprocessed source at hand, although I'm not sure it's actually directly pasted to the build log [1]. Let me know when you need anything else. > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=sh4&ver=20170520-1&stamp=1495506518&raw=0
[Bug c/80852] Optimisation fails to recognise sum computed by loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80852 krister.walfridsson at gmail dot com changed: What|Removed |Added CC||krister.walfridsson at gmail dot c ||om --- Comment #3 from krister.walfridsson at gmail dot com --- This is related to (or a dup of) tree-optimization/46186
[Bug ipa/80581] [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80581 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka --- Fixed.
[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80743 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka --- Mine.
[Bug bootstrap/80860] AIX Bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860 David Edelsohn changed: What|Removed |Added CC|hubicka at gcc dot gnu.org | --- Comment #4 from David Edelsohn --- Note that GCC bootstraps successfully with r248317, prior to richi's change * df-scan.c (df_insn_refs_verify): Speedup when not verifying. I will try after the sws patch, but, if not, there is something wrong with richi's patch.
[Bug target/68211] Free __m128d subreg of double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211 --- Comment #6 from Marc Glisse --- (In reply to Jakub Jelinek from comment #4) > If the upper bits of the register can contain arbitrary garbage, then > keeping it there might result in e.g. floating point exceptions being raised > (it could be even a sNAN). Of course a different thing is if we can prove > what is in those upper bits and be sure it doesn't do any harm, or if the > operations on it later on are masked. For double f(double x){return __builtin_sqrt(x);} we generate vsqrtsd %xmm0, %xmm0, %xmm0 with -O -fno-math-errno. I don't see what makes the rounded version different from the non-rounded version.
[Bug target/80862] [x86] Wrong rounding results for some test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80862 --- Comment #1 from Marc Glisse --- Related to PR 73350.
[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214 --- Comment #5 from Jonathan Wakely --- Fixed on trunk, but let's keep the bug report open, as this is worth backporting.
[Bug c++/80858] When trying to copy std::unordered_map illegally, error message doesn't tell what's wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80858 --- Comment #5 from Jonathan Wakely --- Yes, that's great, thanks. As you observed, Clang doesn't indicate the location that triggers the invalid instantiation, but EDG does, correctly pointing to line 22: "um2.cc", line 9: error: no suitable constructor exists to convert from "int" to "Empty" T t(3); ^ detected during: instantiation of "A &A::operator=(const A &) [with T=Empty]" at line 22 implicit generation of "B &B::operator=(const B &)" at line 22 1 error detected in the compilation of "um2.cc".
[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80743 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Markus Trippelsdorf --- Fixed by r248366.
[Bug c++/80864] New: Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864 Bug ID: 80864 Summary: Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: oss at florianjw dot de Target Milestone: --- The following code triggers an ICE in GCC 6.3.0 and 6.3.1 under independent systems: `` struct array { char c[1]; }; template void gun() { constexpr auto c = array{{}}; } void fun() { gun(); } `` `g++ test.cpp`: `` test.cpp: In instantiation of ‘void gun() [with T = int]’: test.cpp:13:11: required from here test.cpp:8:29: internal compiler error: in reshape_init_r, at cp/decl.c:5898 constexpr auto c = array{{}}; ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. `` I didn't find a bug-report with this exact problem, but this one could possibly be related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79607
[Bug target/80861] ARM (VFPv3): Inefficient float-to-char conversion goes through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80861 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-23 CC||wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Wilco --- (In reply to Gergö Barany from comment #0) > Created attachment 41407 [details] > Input C file for triggering the bug > > Consider the attached code: > > $ cat tst.c > char fn1(float p1) { > return (char) p1; > } Confirmed. This is due to the extend patterns allowing memory, but they aren't marked as having a higher cost, so it decides the spill given register move cost is larger than memory move cost. A quick workaround would be to add ??m to the various extend patterns.
[Bug bootstrap/80865] New: broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 Bug ID: 80865 Summary: broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mojca at macports dot org Target Milestone: --- Created attachment 41409 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41409&action=edit Full build log from a broken gcc build Version 7-20170226 fails to compile on powerpc architecture on Mac. (I can check version 7.1.0 as soon as the version gets updated in MacPorts.) In file included from /path/to/gcc-7-20170226/libgcc/unwind-dw2.c:1728:0: /path/to/gcc-7-20170226/libgcc/unwind.inc: In function '_Unwind_RaiseException': /path/to/gcc-7-20170226/libgcc/unwind.inc:136:1: error: unrecognizable insn: } ^ (jump_insn/f 193 192 194 14 (parallel [ (return) (use (symbol_ref:SI ("*eh_rest_world_r10"))) (clobber (reg:SI 11 r11)) (set (reg:SI 70 cr2) (mem/c:SI (plus:SI (reg/f:SI 1 r1) (const_int 4 [0x4])) [30 S4 A8])) Full build logs are here: https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/28045 as well as in the attachment. Sorry for being unable to provide more details, but I don't know what exactly to report.
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 --- Comment #6 from Bill Schmidt --- (In reply to Ian Lance Taylor from comment #5) > To reproduce: > make GOTESTFLAGS=--keep net/check > > My apologies if I omitted the "/check" before. Thanks! That helps. > > Yes, you have identified the point in the libgo Makefile that produces this, > but the point is that the test program built by `make net/check` (and > preserved if you use `GOTESTFLAGS=--keep`) is somehow miscompiled. Right, I got that -- but was struggling along to try to figure out how to generate that program, since I couldn't get it to hang around. I'll try again with the /check...
[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #16 from Pat Haugen --- (In reply to Dmitry Babokin from comment #14) > Original test case still fails with compiler switches that I've originally > reported (-fsanitize=undefined). Is your failure fixed with r248325?
[Bug c++/80866] New: [8 Regression] segfault in is_overloaded_fn()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866 Bug ID: 80866 Summary: [8 Regression] segfault in is_overloaded_fn() Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- % cat pow_test.ii void pow(); namespace math { template void pow(T); } using namespace math; decltype(pow<>(0)) z(); % g++ -c pow_test.ii pow_test.ii:6:10: internal compiler error: Segmentation fault decltype(pow<>(0)) z(); ^ 0xd537bf crash_signal ../../gcc/gcc/toplev.c:337 0x7acc14 is_overloaded_fn(tree_node*) ../../gcc/gcc/cp/tree.c:2297 0x792535 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*, bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int) ../../gcc/gcc/cp/semantics.c:3742 0x6f25c2 cp_parser_primary_expression ../../gcc/gcc/cp/parser.c:5325 0x70576f cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6781 0x70652d cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:8117 0x707543 cp_parser_cast_expression ../../gcc/gcc/cp/parser.c:8796 0x707c67 cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:8897 0x708544 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:9184 0x70c388 cp_parser_expression ../../gcc/gcc/cp/parser.c:9353 0x70c87c cp_parser_decltype_expr ../../gcc/gcc/cp/parser.c:13756 0x70c87c cp_parser_decltype ../../gcc/gcc/cp/parser.c:13836 0x71294f cp_parser_simple_type_specifier ../../gcc/gcc/cp/parser.c:16735 0x7001bd cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:16520 0x70140a cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:13353 0x720551 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:12678 0x721455 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:12625 0x726924 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12523 0x72855b cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12399 0x72883a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4364
[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256 --- Comment #4 from Jerry DeLisle --- Author: jvdelisle Date: Tue May 23 15:54:59 2017 New Revision: 248371 URL: https://gcc.gnu.org/viewcvs?rev=248371&root=gcc&view=rev Log: 2017-05-23 Jerry DeLisle PR libgfortran/80256 * gfortran.dg/bind_c_array_params_2.f90: Modify to pass on Cygwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jerry DeLisle --- Closing
[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #1 from Nathan Sidwell --- Ok, this is also present on modules branch, but looks like it'll be obvious.
[Bug libstdc++/67578] std::random_device::entropy() always returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue May 23 16:11:57 2017 New Revision: 248374 URL: https://gcc.gnu.org/viewcvs?rev=248374&root=gcc&view=rev Log: PR libstdc++/67578 Implement non-trivial std::random_device::entropy 2017-05-23 Xi Ruoyao Jonathan Wakely PR libstdc++/67578 * acinclude.m4: Bump libtool_VERSION. * config/abi/pre/gnu.ver: Create GLIBCXX_3.4.24 with new symbol. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Add test for . * doc/xml/manual/abi.xml: Document new library version. * include/bits/random.h (random_device::entropy) [_GLIBCXX_USE_RANDOM_TR1]: Add call to new _M_getentropy member. (random_device::_M_getentropy): Declare. * src/c++11/random.cc (random_device::_M_getentropy): Define. * testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.24 to known versions, and make it the latest version. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/xml/manual/abi.xml trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/src/c++11/random.cc trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823 --- Comment #3 from Peter Bergner --- Testing a patch.
[Bug libstdc++/67578] std::random_device::entropy() always returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #5 from Jonathan Wakely --- Implemented for GCC 8.
[Bug libstdc++/67578] std::random_device::entropy() always returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578 --- Comment #6 from Jonathan Wakely --- N.B. we still return zero for the default random_device if using the RDRAND instruction. I don't know what we could do there, except maybe trust Intel and return the maximum value.
[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823 --- Comment #4 from Peter Bergner --- Stupid thinko on my part. An extra increment is causing us to skip some of the case labels in the switch statement, which only causes an ICE/problem if the skipped case happens to point to the same unreachable block as an earlier case label. In that case, the earlier case has already removed the unreachable block, but skipped case label still points to it, leading to the verify_flow ICE. I'm testing the following: Index: gcc/tree-cfg.c === --- gcc/tree-cfg.c (revision 248375) +++ gcc/tree-cfg.c (working copy) @@ -1726,7 +1726,6 @@ group_case_labels_stmt (gswitch *stmt) remove_edge_and_dominated_blocks (base_edge); gimple_switch_set_label (stmt, base_index, NULL_TREE); new_size--; - i++; } }
[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866 --- Comment #2 from Nathan Sidwell --- Author: nathan Date: Tue May 23 17:04:56 2017 New Revision: 248377 URL: https://gcc.gnu.org/viewcvs?rev=248377&root=gcc&view=rev Log: PR c++/80866 * parser.c (cp_parser_template_id): Keep the lookup when stashing the template_id. PR c++/80866 * g++.dg/parse/pr80866.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/pr80866.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- Fixed r248377.
[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242 Orlando Arias changed: What|Removed |Added CC||oarias at knights dot ucf.edu --- Comment #3 from Orlando Arias --- Greetings, I also ran into this problem when compiling newlib [snapshot 2.5.0.20170421] with a bootstrapping gcc using version 7.1.0 for the msp430-elf target. $ msp430-elf-gcc -v Using built-in specs. COLLECT_GCC=msp430-elf-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/msp430-elf/7.1.0/lto-wrapper Target: msp430-elf Configured with: ../configure --prefix=/usr --program-prefix=msp430-elf- --target=msp430-elf --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-shared --disable-nls --disable-threads --enable-languages=c --enable-multilib --without-headers --with-newlib --with-local-prefix=/usr/msp430-elf --with-sysroot=/usr/msp430-elf --with-as=/usr/bin/msp430-elf-as --with-ld=/usr/bin/msp430-elf-ld --disable-libgomp Thread model: single gcc version 7.1.0 (GCC) The particular line that fails is (expanded): if ((nmemb >= ((size_t)1 << (sizeof(size_t) * 4)) || size >= ((size_t)1 << (sizeof(size_t) * 4))) && nmemb > 0 && (0xfUL) / nmemb < size) { Failure occurs at the comparison: ../../../../../../newlib/libc/stdlib/reallocarray.c:37:36: internal compiler error: in simplify_subreg, at simplify-rtx.c:6034 nmemb > 0 && SIZE_MAX / nmemb < size) { Is there any way to disable/bypass this particular behavior? Thank you. Cheers, Orlando.
[Bug target/54168] ARM: Redundant instructions emitted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54168 Wilco changed: What|Removed |Added Status|NEW |RESOLVED CC||wilco at gcc dot gnu.org Known to work||6.3.1 Resolution|--- |FIXED Known to fail||4.8.2, 5.4.1 --- Comment #3 from Wilco --- (In reply to Mans Rullgard from comment #0) > Created attachment 27932 [details] > Test case > > Compiling the attached code for ARM results in redundant instructions even > at -O3 optimisation. Note this sequence (interleaved with other > instructions): > > ldrhr3, [r0]@ unaligned > and r3, r3, #2 > uxthr3, r3 > cmp r3, #0 > beq .L2 > > The UXTH is clearly redundant since no more than 16 bits can be set by LDRH. > Once this is removed, the CMP can be folded with the AND as ANDS. > > Interestingly, this badness only happens with -march=armv6 or higher. If > the target is v5, sane code is generated. > > This is a regression in the 4.7 and 4.8 branches. 4.6 and earlier behave > properly. GCC6.3 produces with -O3: ldrhr0, [r1] andsr0, r0, #2 it ne movne r0, #0 beq .L8 Closing as GCC4.8 isn't active.
[Bug bootstrap/80867] New: [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80867 Bug ID: 80867 Summary: [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with the gcc-7-branch r248347, last successful build was based on r248295. /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/usr/powerpc64le-linux-gnu/bin/ -B/usr/powerpc64le-linux-gnu/ lib/ -isystem /usr/powerpc64le-linux-gnu/include -isystem /usr/powerpc64le-linux-gnu/sys-include -isystem /<>/build/ sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc -gnatn -g -O3 -fdebug-prefix-map=/<>/build/powerpc64le-linux- gnu/libada=. -fstack-protector-strong a-strfix.adb -o a-strfix.o raised STORAGE_ERROR : stack overflow or erroneous memory access ../gcc-interface/Makefile:296: recipe for target 'a-strfix.o' failed make[8]: *** [a-strfix.o] Error 1 make[8]: Leaving directory '/<>/build/gcc/ada/rts' gcc-interface/Makefile:2828: recipe for target 'gnatlib' failed make[7]: *** [gnatlib] Error 2 make[7]: Leaving directory '/<>/build/gcc/ada' gcc-interface/Makefile:2920: recipe for target 'gnatlib-shared-dual' failed make[6]: *** [gnatlib-shared-dual] Error 2 make[6]: Leaving directory '/<>/build/gcc/ada' gcc-interface/Makefile:3016: recipe for target 'gnatlib-shared' failed make[5]: *** [gnatlib-shared] Error 2 make[5]: Leaving directory '/<>/build/gcc/ada' Makefile:118: recipe for target 'gnatlib-shared' failed make[4]: *** [gnatlib-shared] Error 2 make[4]: Leaving directory '/<>/build/powerpc64le-linux-gnu/libada' Makefile:20686: recipe for target 'all-target-libada' failed make[3]: *** [all-target-libada] Error 2 configured with --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu and using -O3 as the optimization flag for the build (apparently -O2 works as seen in another build).
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 --- Comment #7 from Bill Schmidt --- Thanks, Ian, I have the saved executable now.
[Bug c/80868] New: "Duplicate const" warning emitted in `const typeof(foo) bar;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868 Bug ID: 80868 Summary: "Duplicate const" warning emitted in `const typeof(foo) bar;` Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: george.burgess.iv at gmail dot com Target Milestone: --- Minimal test-case (repros with 7.1: https://godbolt.org/g/A2dTCP): $ cat tc.c const int i; const typeof(i) j; $ gcc -std=gnu89 -pedantic tc.c 2:17: warning: duplicate 'const' [-Wpedantic] const typeof(i) j; Expected behavior: no duplicate const warning when there's only one `const` on the decl for `j`. While the current behavior is understandable, I think it would be good to relax the warning in this case. typeof is often used in macros, so silencing this warning isn't always trivial. Since typeof is also a language extension, I don't believe that C89 6.5.3 (which I assume is the only reason GCC is emitting these complaints in the first place) needs to apply here. Thank you for your time :)
[Bug ada/80869] New: Ada.Directories is missing Name_Case_Equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869 Bug ID: 80869 Summary: Ada.Directories is missing Name_Case_Equivalence Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Target: x64_64-apple-darwin15 Build: x86_64-apple-darwin15 As in Summary. AARM A.16(20.2) refers. http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-A-16.html#p20.2 I guess when it was decided not to implement the optional Hierarchical_File_Names in AI05-0049 the other, non-optional, change was missed? http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0049-1.txt?rev=1.12&raw=N
[Bug c++/80396] New builtin to make std::make_integer_sequence efficient and scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80396 --- Comment #1 from Jason Merrill --- Author: jason Date: Tue May 23 20:14:01 2017 New Revision: 248384 URL: https://gcc.gnu.org/viewcvs?rev=248384&root=gcc&view=rev Log: PR c++/80396 - built-in for make_integer_sequence. * pt.c (builtin_pack_fn_p, builtin_pack_call_p) (expand_integer_pack, expand_builtin_pack_call): New. (find_parameter_packs_r): Check builtin_pack_call_p. (check_for_bare_parameter_packs): Handle it. (tsubst_pack_expansion): Call expand_builtin_pack_call. (declare_integer_pack): New. (init_template_processing): Call it. * decl2.c (mark_used): Check builtin_pack_fn_p. Added: trunk/gcc/testsuite/g++.dg/ext/integer-pack1.C trunk/gcc/testsuite/g++.dg/ext/integer-pack2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/doc/extend.texi
[Bug c++/80396] New builtin to make std::make_integer_sequence efficient and scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80396 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from Jason Merrill --- Done.
[Bug c++/80294] [5/6 Regression] ICE with constexpr and inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80294 --- Comment #19 from Jason Merrill --- Author: jason Date: Tue May 23 20:48:58 2017 New Revision: 248385 URL: https://gcc.gnu.org/viewcvs?rev=248385&root=gcc&view=rev Log: PR c++/80294 - ICE with constexpr and inheritance. * constexpr.c (reduced_constant_expression_p): A null constructor element is non-constant. (cxx_eval_indirect_ref): Don't VERIFY_CONSTANT before returning an empty base. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/constexpr.c
[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992 --- Comment #8 from Jason Merrill --- Author: jason Date: Tue May 23 20:51:33 2017 New Revision: 248386 URL: https://gcc.gnu.org/viewcvs?rev=248386&root=gcc&view=rev Log: PR c++/80267 - ICE with nested capture of reference PR c++/60992 * pt.c (tsubst_copy): Handle lookup finding a capture proxy. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/pt.c
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 --- Comment #7 from Jason Merrill --- Author: jason Date: Tue May 23 20:51:33 2017 New Revision: 248386 URL: https://gcc.gnu.org/viewcvs?rev=248386&root=gcc&view=rev Log: PR c++/80267 - ICE with nested capture of reference PR c++/60992 * pt.c (tsubst_copy): Handle lookup finding a capture proxy. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/pt.c
[Bug libgcc/80870] New: ICE building sh-elf crosscompiler on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 Bug ID: 80870 Summary: ICE building sh-elf crosscompiler on macOS Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: Anders.Montonen at iki dot fi Target Milestone: --- Host os: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64 Host compiler: Apple LLVM version 8.1.0 (clang-802.0.42) Configure string: ../gcc-7.1.0/configure --prefix=/Users/anders/local --target=sh-elf --disable-nls --enable-languages="c,c++" --with-newlib Output: /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include -isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh -L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys -L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh -B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem /Users/anders/local/sh-elf/include -isystem /Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc -I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc -I../../../../gcc-7.1.0/libgcc/../include -DHAVE_CC_TLS -o _eprintf.o -MT _eprintf.o -MD -MP -MF _eprintf.dep -DL_eprintf -c ../../../../gcc-7.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include -isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh -L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys -L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh -B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem /Users/anders/local/sh-elf/include -isystem /Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc -I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc -I../../../../gcc-7.1.0/libgcc/../include -DHAVE_CC_TLS -o __gcc_bcmp.o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c ../../../../gcc-7.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem /Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include -isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include -B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh -L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys -L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh -B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem /Users/anders/local/sh-elf/include -isystem /Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc -I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc -I../../../../gcc-7.1.0/libgcc/../include -DHAVE_CC_TLS -o _divdi3.o -MT _divdi3.o -MD -MP -MF _divdi3.dep -DL_divdi3 -c ../../../../gcc-7.1.0/libgcc/libgcc2.c \ -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc-7.1.0/libgcc/libgcc2.c: In function '__divdi3': ../../../../gcc-7.1.0/libgcc/libgcc2.c:1091:9: internal compiler error: in emit_move_insn, at expr.c:3698 d0 = 1 / d0; /* Divide intentionally by zero. */ ~~~^~~~ libbacktrace could not find
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #4 from Sergei Trofimovich --- Found similar false positive on lxc project. Original snippet of code: https://github.com/lxc/lxc/blob/5059aae90584d7d80b3494088920da4ba73e2b2a/src/lxc/cgroups/cgfsng.c#L1379-L1395 Simplified version: $ cat a.c #include void f(char * p /* NNN\0" */) { for (int idx = 0; idx < 1000; idx++) { // guaranteed to be in [0-999] range snprintf (p, 4, "%d", idx); } } $ gcc -O2 -c a.c -Wall a.c: In function 'f': a.c:6:25: warning: '__builtin___snprintf_chk' output may be truncated before the last format character [-Wformat-truncation=] snprintf (p, 4, "%d", idx); ^~~~ /usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output between 2 and 5 bytes into a destination of size 4 If I change 1000 to 999 for (int idx = 0; idx < 999; idx++) { no warning will be issued. Looks like what happens here is that gcc does not distinct between idx in the for loop itself that has range of [0-999] and idx outside for loop, which has value range of [1000-1000].
[Bug c++/80871] New: Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871 Bug ID: 80871 Summary: Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- Consider this example: #ifdef VARIADIC template constexpr int foo(Us... ) { return 1; } template constexpr int foo(Us... ) { return 2; } #else template constexpr int foo(U ) { return 1; } template constexpr int foo(U ) { return 2; } #endif int main() { static_assert(foo(1) == 1, "!"); } Without -DVARIADIC, the call to foo(1) is considered ambiguous and the program fails to compile. But with -DVARIADIC, the program compiles. The call should be ambiguous, since Ts... does not participate in partial ordering.
[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Tue May 23 21:39:41 2017 New Revision: 248388 URL: https://gcc.gnu.org/viewcvs?rev=248388&root=gcc&view=rev Log: 2017-05-23 Paul Thomas Backport from trunk PR fortran/80333 * trans-io.c (nml_get_addr_expr): If we are dealing with class type data set tmp tree to get that address. (transfer_namelist_element): Set the array spec to point to the the class data. * gfortran.dg/dtio_30.f03: New test. * list_read.c (nml_read_obj): Compute pointer into class/type arrays from the nl->dim information. Update it for each iteration of the loop for the given object. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dtio_30.f03 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-io.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/io/list_read.c
[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jerry DeLisle --- Fixed on 7 and closing.
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 --- Comment #8 from Bill Schmidt --- More headaches. I see the failure as part of "make GOTESTFLAGS=--keep net/check", as follows: $ head -c 1000 TEST.log --- FAIL: TestParseIP (20.94s) ip_test.go:47: ParseIP("127.0.1.2") = 127.0.1.2, want ip_test.go:55: IP.UnmarshalText("127.0.1.2") = 127.0.1.2, , want ?7f0001027f017f0102037f0102037f0102037f0102037f0102037f0102037f010203200148602001006820014860200100683139322e302e322e3100302e302e302e303139322e302e322e31c201302e302e302e30003a3a20010db801230012000120010db80001323030313a6462383a3a310020010db800010001000120010db8000100010001200100010001323030313a3a313a303a303a310020010db80001323030313a6462383a303a303a313a3a20010db8000100012001 But with "LD_LIBRARY_PATH=../../.libs ./a.out -test.run=TestParseIP", this particular failure mode does not occur (though the tests FAIL): $ ./a.out -test.run=TestParseIP --- FAIL: TestParseIP (0.03s) ip_test.go:47: ParseIP("127.0.1.2") = 127.0.1.2, want ip_test.go:55: IP.UnmarshalText("127.0.1.2") = 127.0.1.2, , want ip_test.go:47: ParseIP("127.0.0.1") = 127.0.0.1, want ip_test.go:55: IP.UnmarshalText("127.0.0.1") = 127.0.0.1, , want ip_test.go:47: ParseIP("127.001.002.003") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText("127.001.002.003") = 127.1.2.3, , want ip_test.go:47: ParseIP(":::127.1.2.3") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText(":::127.1.2.3") = 127.1.2.3, , want ip_test.go:47: ParseIP(":::127.001.002.003") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText(":::127.001.002.003") = 127.1.2.3, , want ip_test.go:47: ParseIP(":::7f01:0203") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText(":::7f01:0203") = 127.1.2.3, , want ip_test.go:47: ParseIP("0:0:0:0:::127.1.2.3") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText("0:0:0:0:::127.1.2.3") = 127.1.2.3, , want ip_test.go:47: ParseIP("0:0:0:0:00::127.1.2.3") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText("0:0:0:0:00::127.1.2.3") = 127.1.2.3, , want ip_test.go:47: ParseIP("0:0:0:0:::127.1.2.3") = 127.1.2.3, want ip_test.go:55: IP.UnmarshalText("0:0:0:0:::127.1.2.3") = 127.1.2.3, , want ip_test.go:47: ParseIP("2001:4860:0:2001::68") = 2001:4860:0:2001::68, want ip_test.go:55: IP.UnmarshalText("2001:4860:0:2001::68") = 2001:4860:0:2001::68, , want ip_test.go:47: ParseIP("2001:4860::2001::::0068") = 2001:4860:0:2001::68, want ip_test.go:55: IP.UnmarshalText("2001:4860::2001::::0068") = 2001:4860:0:2001::68, , want FAIL I don't have any explanation for this...
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-23 Ever confirmed|0 |1 Known to fail||7.1.0 --- Comment #5 from Martin Sebor --- (In reply to Sergei Trofimovich from comment #4) > Found similar false positive on lxc project. Thanks for the test case. The VRP pass computes the correct range information for the argument but the range made available outside it via the get_range_info() function is that of idx_6, not idx_10 below (compile with -fdump-tree-vrp=/dev/stdout to see the output). It's possible that this problem is caused by the same underlying limitation as the one in comment #0. Let me confirm this bug on that basis. Value ranges after VRP: idx_1: [1, 999] EQUIVALENCES: { idx_6 } (1 elements) idx_6: [1, 1000] idx_10: [0, 999] .MEM_11: VARYING Removing basic block 5 f (char * p) { int idx; [1.00%]: [99.00%]: # idx_10 = PHI __builtin_snprintf (p_4(D), 4, "%d", idx_10); idx_6 = idx_10 + 1; if (idx_6 != 1000) goto ; [98.99%] else goto ; [1.01%] [1.00%]: return; }
[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80741 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Tue May 23 22:05:56 2017 New Revision: 248390 URL: https://gcc.gnu.org/viewcvs?rev=248390&root=gcc&view=rev Log: 2017-05-23 Jerry DeLisle Backport from trunk PR libgfortran/80741 * transfer.c (finalize_transfer): Reset last_char to 'empty'. * file_pos.c (formatted_backspace): Likewise. (st_endfile): Likewise. (st_rewind): Likewise. (st_flush): Likewise. * trans-io.c (transfer_namelist_element): Change check from NULL_TREE to null_pointer_node. * gfortran.dg/read_4.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/read_4.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-io.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/io/file_pos.c branches/gcc-7-branch/libgfortran/io/transfer.c
[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80741 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed on 7 and closing
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 --- Comment #9 from Ian Lance Taylor --- It's possible that the long output is due to memory corruption from an earlier test. The way the test is actually run as part of the larger testsuite is LD_LIBRARY_PATH=../../.libs ./a.out -test.short
[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 --- Comment #17 from Dmitry Babokin --- Yes, it's fix with current trunk.
[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868 Nick Desaulniers changed: What|Removed |Added CC||ndesaulniers at google dot com --- Comment #1 from Nick Desaulniers --- Other discussions: LKML: https://patchwork.kernel.org/patch/9693821/ Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=723720 LLVM: https://bugs.llvm.org/show_bug.cgi?id=32985
[Bug middle-end/66313] Unsafe factorization of a*b+a*c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313 --- Comment #16 from Dmitry Babokin --- Here's another test case with a contrary example, where a variable gets pulled into the braces and it also causes false positive. Transformation is: const1 * (const2 * var1 - const3 * var2) => const1*const2*var1 - const3*var2; > cat f.cpp #include signed char var_10 = 77; long long int var_13 = 1547580415367384384LL; long foo() { long a = -6 * // 0xbf8a6c24aa342bc0 = -4644781160949077056 (long(16636733186465668563ULL * var_13 ) - // 0xd4cdd0f8c2df13cf = -3112602000603278385 long(678280911954875019ULL * var_10)); return a; } int main () { long a = foo (); std::cout << a << std::endl; return 0; } > g++ -fsanitize=undefined -O0 f.cpp; ./a.out f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 - 228867929910118694 cannot be represented in type 'long int' 9193074962074792026 If it's unrelated issue, let me know and I'll file a separate bug for it.
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #33 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #32) > Created attachment 41406 [details] > Additional files for the previous patch > > Here are the new files for the patch. Well I tried to apply the patch and test without using maintainer mode. Running my tests in the debugger, breaking and dis-assembly shows xmmm instructions and calls to matmul_vanilla so I think I need to enable maintainer mode and rebuild, or something is not quite right. Suggestions?
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 --- Comment #6 from Martin Sebor --- I also found the following discussion about what looks like the same problem: https://patchwork.ffmpeg.org/patch/3630
[Bug libgcc/80870] ICE building 7.1.0 sh-elf crosscompiler on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 Anders Montonen changed: What|Removed |Added Target||sh-elf Known to work||6.3.0 --- Comment #1 from Anders Montonen --- Building GCC 6.3.0 with the same settings works.
[Bug c++/80812] internal compiler error: in build_value_init_noctor, at cp/init.c:483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812 --- Comment #1 from James Almer --- This started with r248153
[Bug c++/80812] [8 Regression] ICE: in build_value_init_noctor, at cp/init.c:483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812 Markus Trippelsdorf changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-05-24 CC||trippels at gcc dot gnu.org, ||ville at gcc dot gnu.org Summary|internal compiler error: in |[8 Regression] ICE: in |build_value_init_noctor, at |build_value_init_noctor, at |cp/init.c:483 |cp/init.c:483 Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- trippels@gcc67 ~ % cat foo.ii struct A; template using __bool_constant = A; template struct B : __bool_constant<__is_constructible(_Tp)> {}; template struct C; template struct C<_Tp &> { typedef _Tp type; }; template struct D; struct F { F(); }; template using __alloc_rebind = F; struct G { template using rebind_alloc = __alloc_rebind; }; struct H { typedef G::rebind_alloc other; }; struct I { struct : H::other { } _M_dataplus; }; template struct list; template using _t = typename T::type; template using bool_ = A; template struct _if_; template using if_c = _t<_if_>>>; template using uncvref_t = _t>; template T *_nullptr_v(); template )> void models_(Concept *); template struct models : bool_<_t(_nullptr_v()))>::value> {}; template auto model_of() -> if_c::valueint>; struct J { template void requires_(decltype(B{})); }; struct K { template void requires_(decltype(model_of)); }; template using View = models; struct { template >())>::type> void operator()(T &&); } all; void test_iter() { using P = I; P ia[]{{}}; all(ia); } trippels@gcc67 ~ % g++ -c foo.ii foo.ii: In instantiation of ‘struct B’: foo.ii:37:30: required by substitution of ‘template void models_(Concept*) [with Ts = {I [1]}; Concept = J; = ]’ foo.ii:33:39: required from ‘struct models’ foo.ii:35:6: required by substitution of ‘template void models_(Concept*) [with Ts = {I [1]}; Concept = K; = ]’ foo.ii:33:39: required from ‘struct models’ foo.ii:44:34: required by substitution of ‘template > void::operator()(T&&) [with T = I (&)[1]; int = ]’ foo.ii:50:9: required from here foo.ii:3:32: internal compiler error: in build_value_init_noctor, at cp/init.c:485
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 Thomas Koenig changed: What|Removed |Added Attachment #41405|0 |1 is obsolete|| Attachment #41406|0 |1 is obsolete|| --- Comment #34 from Thomas Koenig --- Created attachment 41410 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41410&action=edit Patch which has all the files Well, I suspect my way of splitting the previous patch into one real patch and one *.tar.gz - file was not really the best way to go :-) Here is a patch which should include all the new files. At least it fits into the 1000 kb limit.