[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #3 from Bill Seurer --- All the compilation failures disappear if the two casts /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int' /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int' are fixed.
[Bug fortran/84276] Invalid error for valid statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 --- Comment #2 from Steve Kargl --- On Thu, Feb 08, 2018 at 02:26:50AM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 > > --- Comment #1 from Steve Kargl --- > Reduced testcase. > > subroutine stepns(hh,h,s,w) > real, intent(inout) :: h,hh,s > real, intent(out) :: w > real :: qofs > qofs(s)=s > w=qofs(hh+h) > end subroutine stepns > > Problem occurs with interface.c:3219. > So, the problem appears to boil down to gfortran acquiring not only the type and type parameters from the declaration statements, but also the attributes. Statement functions should not inherit the attributes.
[Bug c++/82930] [C++17] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82930 sandthorn changed: What|Removed |Added CC||hotguest1 at hotmail dot com --- Comment #3 from sandthorn --- I also confirm this on GCC 8.0.1 20180206, but GCC 7.3 seems okey with code below. https://godbolt.org/g/kwDaVE auto lam = [](auto structured_bindable){ // also error with auto& auto [first,second] = structured_bindable; // also error with auto& auto test_access = first; }; g++ (GCC-Explorer-Build) 8.0.1 20180206 (experimental) : In lambda function: :3:35: internal compiler error: in is_normal_capture_proxy, at cp/lambda.c:288 auto test_access = first; ^ mmap: Invalid argument
[Bug fortran/84276] Invalid error for valid statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 --- Comment #1 from Steve Kargl --- Reduced testcase. subroutine stepns(hh,h,s,w) real, intent(inout) :: h,hh,s real, intent(out) :: w real :: qofs qofs(s)=s w=qofs(hh+h) end subroutine stepns Problem occurs with interface.c:3219.
[Bug c/84258] Bogus -Wformat warning "wide character string" for const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84258 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00380.html
[Bug fortran/84276] Invalid error for valid statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Known to fail||6.4.1, 7.3.1, 8.0
[Bug fortran/84276] New: Invalid error for valid statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 Bug ID: 84276 Summary: Invalid error for valid statement function Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Found in c.l.f, but significantly reduced by me https://groups.google.com/forum/#!topic/comp.lang.fortran/MtbUxdhz_6k subroutine stepns(hh,h,s,y,yp,y1,y2,w) real, intent(inout):: h,hh,s,y,y1,yp,y2 real, intent(out) :: w real :: z2,z4,z1,z3,d,a,b,c,e,qofs z1(a,b,d)=(b-a)/d z2(a,c,b,d)=(z1(a,b,d)-c)/d z3(a,b,e,d)=(e-z1(a,b,d))/d z4(a,c,b,e,d)=(z3(a,b,e,d)-z2(a,c,b,d))/d qofs(a,c,b,e,d,s)=((z4(a,c,b,e,d)*(s-d)+z2(a,c,b,d))*s+c)*s+a w=qofs(y1,y2,y,yp,hh,hh+h) end subroutine stepns % gfcx -c HOMPACK90.f HOMPACK90.f:14:27: w=qofs(y1,y2,y,yp,hh,hh+h) 1 Error: Non-variable expression in variable definition context (actual argument to INTENT = OUT/INOUT) at (1) Code compiles if the INTENT is removed.
[Bug middle-end/84275] New: missing warning on conflicting attributes on different declara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84275 Bug ID: 84275 Summary: missing warning on conflicting attributes on different declara Product: gcc Version: 8.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: --- GCC silently accepts function declarations with attributes whose parameters contradict or conflict with one another, both on distinct declarations of the same function and even on the same declaration. The test case below shows that if two declarations specify such conflicting attributes GCC honors the first one (at least the object size pass does). Since the other attribute is ignored GCC should point that out (e.g., by -Wattributes or by -Wignored-attributes). Similar bugs were reported in pr32960 and pr81544. $ cat t.C && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -xc t.C #include #define ATTR(list) __attribute__ (list) void* ATTR ((alloc_align (1), alloc_size (2),// this conflicts... alloc_align (2), alloc_size (1))) // ...with this foo (int, int); void* ATTR ((alloc_size (1), alloc_align (2))) // this conflicts... bar (int, int); void* ATTR ((alloc_size (2), alloc_align (1))) // ...with this bar (int, int); void* foobar (void) { void *p = bar (3, 5); memset (p, 0, 7); return p; } In file included from /usr/include/string.h:635, from t.C:1: In function ‘memset’, inlined from ‘foobar’ at t.C:19:3: /usr/include/bits/string3.h:90:10: warning: ‘__builtin___memset_chk’ writing 7 bytes into a region of size 3 overflows the destination [-Wstringop-overflow=] return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); ^
[Bug c/84274] New: [feature request] mbind attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84274 Bug ID: 84274 Summary: [feature request] mbind attribute Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- https://sourceware.org/ml/binutils/2017-03/msg00261.html describes as-of-yet-unimplemented attributes to control the placement of data into new variants of bss, data, etc. > The goal is to place data in special memory sections via > attribute. To place an uninitialized variable, foo, in a > mbind bss section with memory type 1: > > int foo __attribute__ ((mbind(0x1))); > > To place a variable, foo, in a mbind data section with > memory type 2: > > int foo __attribute__ ((mbind(0x2))) = 1; > > To place a read-only variable, foo, in a mbind rodata > section with memory type 3: > > const int foo __attribute__ ((mbind(0x3))) = 1; This is a feature request to support these in GCC, since the underlying functionality is supported (https://fossies.org/diffs/binutils/2.28_vs_2.29/include/ChangeLog-diff.html). # Additional references https://sourceware.org/ml/gnu-gabi/2017-q1/msg0.html
[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84154 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Meissner --- Fixed in subversion id 257570.
[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84154 --- Comment #3 from Michael Meissner --- Author: meissner Date: Wed Feb 7 22:54:59 2018 New Revision: 257470 URL: https://gcc.gnu.org/viewcvs?rev=257470&root=gcc&view=rev Log: [gcc] 2018-02-07 Michael Meissner PR target/84154 * config/rs6000/rs6000.md (fix_trunc2): Convert from define_expand to be define_insn_and_split. Rework float/double/_Float128 conversions to QI/HI/SImode to work with both ISA 2.07 (power8) or ISA 3.0 (power9). Fix regression where conversions to QI/HImode types did a store and then a load to truncate the value. For conversions to VSX registers, don't split the insn, instead emit the code directly. Use the code iterator any_fix to combine signed and unsigned conversions. (fix_truncsi2_p8): Likewise. (fixuns_trunc2): Likewise. (fix_trunc2): Likewise. (fix_trunc2): Likewise. (fix_di2_hw): Likewise. (fixuns_di2_hw): Likewise. (fix_si2_hw): Likewise. (fixuns_si2_hw): Likewise. (fix_2_hw): Likewise. (fix_trunc2): Likewise. (fctiwz__smallint): Rename fctiwz__smallint to fix_truncsi2_p8. (fix_trunc2_internal): Delete, no longer used. (fixuns_trunc2_internal): Likewise. (fix__mem): Likewise. (fctiwz__mem): Likewise. (fix__mem): Likewise. (fix_trunc2_mem): On ISA 3.0, prevent the register allocator from doing a direct move to the GPRs to do a store, and instead use the ISA 3.0 store byte/half-word from vector register instruction. For IEEE 128-bit floating point, also optimize stores of 32-bit ints. (fix_trunc2_mem): Likewise. [gcc/testsuite] 2018-02-07 Michael Meissner PR target/84154 * gcc.target/powerpc/pr84154-1.c: New tests. * gcc.target/powerpc/pr84154-2.c: Likewise. * gcc.target/powerpc/pr84154-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr84154-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr84154-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr84154-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 22:41:59 2018 New Revision: 257468 URL: https://gcc.gnu.org/viewcvs?rev=257468&root=gcc&view=rev Log: 2018-02-07 Steven G. Kargl PR fortran/82994 * match.c (gfc_match_deallocate): Check for NULL pointer. 2018-02-07 Steven G. Kargl PR fortran/82994 * gfortran.dg/deallocate_error_3.f90: New test. * gfortran.dg/deallocate_error_4.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deallocate_error_3.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deallocate_error_4.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/match.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.5 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on 6-branch, 7-branch, and trunk. Thanks for the bug report.
[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707 --- Comment #3 from Will Schmidt --- Created attachment 43360 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43360&action=edit .expand dump from a build with -O1. the .expand dump from a build with -O1.
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 22:36:24 2018 New Revision: 257467 URL: https://gcc.gnu.org/viewcvs?rev=257467&root=gcc&view=rev Log: 2018-02-07 Steven G. Kargl PR fortran/82994 * match.c (gfc_match_deallocate): Check for NULL pointer. 2018-02-07 Steven G. Kargl PR fortran/82994 * gfortran.dg/deallocate_error_3.f90: New test. * gfortran.dg/deallocate_error_4.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deallocate_error_3.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deallocate_error_4.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/83707] g++.dg/eh/simd-3.C fails on power7 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707 Will Schmidt changed: What|Removed |Added CC||willschm at gcc dot gnu.org --- Comment #2 from Will Schmidt --- The troublesome snippet of code reads as so ( from gcc/testsuite/g++.dg/eh/simd-3.C ) " int main(void) { v v1 = vt; try { thrower(); } catch (int x) { } v2 = v1; if (memcmp(&v2,&vt,...)) abort(); " where thrower() is a function meant to scramble contents of the VSRs. And the problem (that we abort during the test run) occurs when any non-zero optimization level is specified, due to vt != v2. high-level debug suggests that we are not storing the v1=vt result to memory, (only to a reg), so the call to thrower clobbers the contents, and we ultimately fail. When built with -O0, on the "v1 = vt" statement, i can see (.expand dump) ;; Generating RTL for gimple basic block 2 ;; v1_5 ={v} vt; (insn # # # (set (reg:SI 129) (high:SI (symbol_ref:SI ("vt") [flags 0x2] ))) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (nil)) (insn # # # (set (reg/f:SI 128) (lo_sum:SI (reg:SI 129) (symbol_ref:SI ("vt") [flags 0x2] ))) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (expr_list:REG_EQUAL (symbol_ref:SI ("vt") [flags 0x2] ) (nil))) (insn # # # (set (reg:V4SI 130) (mem/v/c:V4SI (reg/f:SI 128) [1 vt+0 S16 A128])) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (nil)) (insn # # 0 (set (mem/c:V4SI (plus:SI (reg/f:SI 116 virtual-stack-vars) (const_int 8 [0x8])) [1 v1+0 S16 A128]) (reg:V4SI 130)) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (nil)) ;; thrower (); Noting the "set (mem/c..." statement. This code works, in that the v1 value survives the call to thrower. When built with -O1, that chunk of the dump now reads: ;; v1_4 ={v} vt; (insn # # # (set (reg:SI 128) (high:SI (symbol_ref:SI ("*.LANCHOR1") [flags 0x182]))) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (nil)) (insn # # # (set (reg/f:SI 127) (lo_sum:SI (reg:SI 128) (symbol_ref:SI ("*.LANCHOR1") [flags 0x182]))) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR1") [flags 0x182]) (nil))) (insn # # 0 (set (reg/v:V4SI 123 [ v1 ]) (mem/v/c:V4SI (reg/f:SI 127) [1 vt+0 S16 A128])) "/home/willschm/gcc/gcc-mainline-regtest_patches/gcc/testsuite/g++.dg/eh/simd-3.C":56# (nil)) ;; thrower (); And here, note that this is a "set (reg". There is no "set (mem" until after the "v2 = v1" statement, after the call to thrower(). This seems to fit with what I see via objdump : (working code) xx : xx: 94 21 ff c0 stwur1,-64(r1) xx: 7c 08 02 a6 mflrr0 xx: 90 01 00 44 stw r0,68(r1) xx: 93 e1 00 3c stw r31,60(r1) xx: 7c 3f 0b 78 mr r31,r1 xx: 3d 20 10 02 lis r9,4098 xx: 39 29 00 40 addir9,r9,64 xx: 7c 00 4e 18 lxvw4x vs0,0,r9 <- load. xx: 39 20 00 10 li r9,16 xx: 7c 1f 4f 18 stxvw4x vs0,r31,r9 <- store. xx: 4b ff ff 61 bl 174c <_Z7throwerv> versus (failing code): xx : xx: 94 21 ff d0 stwur1,-48(r1) xx: 7c 08 02 a6 mflrr0 xx: 90 01 00 34 stw r0,52(r1) xx: 38 00 00 10 li r0,16 xx: 7f e1 01 ce stvxv31,r1,r0 xx: 3d 20 10 02 lis r9,4098 xx: 39 29 00 40 addir9,r9,64 xx: 7f e0 4e 19 lxvw4x vs63,0,r9<- load, no store. xx: 4b ff ff 89 bl 16f0 <_Z7throwerv> most previous tree dump before expand (232t.optimized) shows bb2 having: : v1_5 ={v} vt; thrower (); versus [local count: 1073741825]: v1_4 ={v} vt; thrower ();
[Bug c++/84082] [7/8 Regression] ICE with broken template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Feb 7 22:30:51 2018 New Revision: 257466 URL: https://gcc.gnu.org/viewcvs?rev=257466&root=gcc&view=rev Log: PR c++/84082 * parser.c (cp_parser_dot_deref_incomplete): New function. (cp_parser_postfix_dot_deref_expression): Use it. * g++.dg/template/incomplete11.C: New test. * g++.dg/parse/crash67.C: Expect an incomplete type diagnostics too. Added: trunk/gcc/testsuite/g++.dg/template/incomplete11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash67.C
[Bug fortran/82994] ICE in gfc_match_deallocate, at fortran/match.c:4478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82994 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 22:29:22 2018 New Revision: 257465 URL: https://gcc.gnu.org/viewcvs?rev=257465&root=gcc&view=rev Log: 2018-02-07 Steven G. Kargl PR fortran/82994 * match.c (gfc_match_deallocate): Check for NULL pointer. 2018-02-07 Steven G. Kargl PR fortran/82994 * gfortran.dg/deallocate_error_3.f90: New test. * gfortran.dg/deallocate_error_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deallocate_error_3.f90 trunk/gcc/testsuite/gfortran.dg/deallocate_error_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug c++/82478] Rejects valid access to private member type that should be allowed by friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82478 Alexander Zaitsev changed: What|Removed |Added CC||zamazan4ik at tut dot by --- Comment #6 from Alexander Zaitsev --- One more problematic case: #include class A { int a; friend class B; }; class B { public: template struct trait: std::false_type {}; template struct trait().a)>>: std::true_type {}; }; int main() { static_assert(B::trait{}); return 0; } On clang(trunk) this code works well. On gcc(trunk) we have: prog.cc: In function 'int main()': prog.cc:15:61: error: 'int A::a' is private within this context struct trait().a)>>: std::true_type {}; ~~~^ prog.cc:4:9: note: declared private here int a;
[Bug fortran/84273] New: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84273 Bug ID: 84273 Summary: Reject allocatable passed-object dummy argument (proc_ptr_47.f90) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- implementing C453 (F03), C456 (F08), C461(F15) see https://github.com/nncarlson/gfortran.dg/issues/4
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #8 from Vladimir Makarov --- (In reply to David Binderman from comment #0) > A build of today's gcc trunk with valgrind produces this: > > ==8995== Conditional jump or move depends on uninitialised value(s) > ==8995==at 0xA39BBE: lra_eliminate_regs_1 (lra-eliminations.c:403) > ==8995==by 0xA39BBE: eliminate_regs_in_insn(rtx_insn*, bool, bool, long) > (lra-eliminations.c:1114) > ==8995==by 0xA3A147: process_insn_for_elimination > (lra-eliminations.c:1396) > ==8995==by 0xA3A147: lra_eliminate(bool, bool) (lra-eliminations.c:1459) > > svn blame gives us > > 23 vmakarov if (CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, > 1)) == -offset) > > I suspect local variable offset isn't correct. > > Configure lines are > > ../trunk/configure --prefix=/home/dcb/gcc/results.255572.valgrind \ > --disable-bootstrap \ > --disable-multilib \ > --disable-werror \ > --enable-checking=valgrind \ > --enable-languages=c,c++,fortran > > sed 's/-O2/-O3 -funroll-loops -Wtautological-compare/' < Makefile > > Makefile.tmp > mv Makefile.tmp Makefile > > svn info tells us current revision number is 255572. Sorry, I tried to reproduce it according to these instructions (without and with editing the Makefile) but I've failed. Could you confirm that it is still the problem in your environment.
[Bug fortran/84218] ICE in free_expr0, at fortran/expr.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84218 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com --- Comment #2 from Neil Carlson --- Note that the DATA statement data (x(j:i), i=1,2,2) /'a'/ is not valid Fortran. Implied do objects, here x(j:i), are restricted by R538 (F08) to array elements, scalar structure component, or an implied-do. x(j:i) is an array section not an array element. But this may be a language extension that gfortran supports.
[Bug fortran/84270] optimization bug with assumed size array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84270 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- The bug disappears with -fno-frontend-optimize.
[Bug target/84272] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84272 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2018-2-7 Target Milestone|--- |8.0
[Bug target/84272] New: AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84272 Bug ID: 84272 Summary: AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity() Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: amker at gcc dot gnu.org, kyrylo.tkachov at arm dot com, ramana at gcc dot gnu.org Target Milestone: --- Host: aarch64-linux-gnu Target: aarch64-linux-gnu Seen both on a native machine and cross compiler (on x86_64): $ cat model.ii class a { public: float b, c; a (); a (float, float, float); float operator* (a) { float d = b * b + c * c; return d; } } typedef e; void f () { e g[1]; e h (0, 0, h * g[2]); } $ ./xg++ -B. model.ii -c -march=armv8-a -mtune=cortex-a57 -O2 = ==20120==ERROR: AddressSanitizer: heap-use-after-free on address 0x60423ca8 at pc 0x02e669b2 bp 0x7fffd1b0 sp 0x7fffd1a8 READ of size 8 at 0x60423ca8 thread T0 #0 0x2e669b1 in fma_node::get_parity() ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 #1 0x2e669b1 in fma_node::rename(fma_forest*) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:600 #2 0x2e67b0a in func_fma_steering::dfs(void (*)(fma_forest*), void (*)(fma_forest*, fma_root_node*), void (*)(fma_forest*, fma_node*), bool) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:882 #3 0x2e686b9 in func_fma_steering::rename_fma_trees() ../../gcc/config/aarch64/cortex-a57-fma-steering.c:1006 #4 0x2e6aac2 in func_fma_steering::execute_fma_steering() ../../gcc/config/aarch64/cortex-a57-fma-steering.c:1036 #5 0x2e6c7ad in pass_fma_steering::execute(function*) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:1071 #6 0x1dadc09 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497 #7 0x1daf5e2 in execute_pass_list_1 ../../gcc/passes.c:2586 #8 0x1daf60c in execute_pass_list_1 ../../gcc/passes.c:2587 #9 0x1daf60c in execute_pass_list_1 ../../gcc/passes.c:2587 #10 0x1daf68f in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2597 #11 0x11619a9 in cgraph_node::expand() ../../gcc/cgraphunit.c:2139 #12 0x116454c in expand_all_functions ../../gcc/cgraphunit.c:2275 #13 0x116454c in symbol_table::compile() ../../gcc/cgraphunit.c:2624 #14 0x116dc76 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2717 #15 0x2132fe4 in compile_file ../../gcc/toplev.c:480 #16 0x690921 in do_compile ../../gcc/toplev.c:2081 #17 0x690921 in toplev::main(int, char**) ../../gcc/toplev.c:2216 #18 0x69b444 in main ../../gcc/main.c:39 #19 0x75a65f49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #20 0x69dba9 in _start (/home/marxin/Programming/gcc2/objdir2/gcc/cc1plus+0x69dba9) 0x60423ca8 is located 24 bytes inside of 48-byte region [0x60423c90,0x60423cc0) freed by thread T0 here: #0 0x76f02ff8 in operator delete(void*, unsigned long) (/usr/lib64/libasan.so.4+0xdeff8) #1 0x2e682e5 in func_fma_steering::dfs(void (*)(fma_forest*), void (*)(fma_forest*, fma_root_node*), void (*)(fma_forest*, fma_node*), bool) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:896 #2 0x60423bcf () previously allocated by thread T0 here: #0 0x76f01c70 in operator new(unsigned long) (/usr/lib64/libasan.so.4+0xddc70) #1 0x2e69e52 in func_fma_steering::analyze_fma_fmul_insn(fma_forest*, du_chain*, du_head*) ../../gcc/config/aarch64/cortex-a57-fma-steering.c:774 SUMMARY: AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity() Shadow bytes around the buggy address: 0x0c087fffc740: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 00 0x0c087fffc750: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fa 0x0c087fffc760: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00 0x0c087fffc770: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 fa 0x0c087fffc780: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fa =>0x0c087fffc790: fa fa fd fd fd[fd]fd fd fa fa 00 00 00 00 00 fa 0x0c087fffc7a0: fa fa 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 0x0c087fffc7b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fffc7c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fffc7d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fffc7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f
[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 --- Comment #28 from Thomas Koenig --- Author: tkoenig Date: Wed Feb 7 21:08:51 2018 New Revision: 257462 URL: https://gcc.gnu.org/viewcvs?rev=257462&root=gcc&view=rev Log: 2018-02-07 Thomas Koenig PR fortran/68560 * trans-intrinsic.c (gfc_conv_intrinsic_shape): New function. (gfc_conv_intrinsic_function): Call it. 2018-02-07 Thomas Koenig PR fortran/68560 * gfortran.dg/shape_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/shape_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82049 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on 6-branch, 7-branch, and trunk. Thanks for the bug report.
[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82049 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 21:01:00 2018 New Revision: 257461 URL: https://gcc.gnu.org/viewcvs?rev=257461&root=gcc&view=rev Log: 2018-02-07 Steven G. Kargl PR fortran/82049 * match.c (gfc_match_type_spec): If the charlen is non-NULL, then try to resolve it. While here return early if possible. 2018-02-07 Steven G. Kargl PR fortran/82049 * gfortran.dg/assumed_charlen_parameter.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/match.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78303 --- Comment #4 from Segher Boessenkool --- If -maltivec=be is not used, I support removing it. Deprecating it with a warning on use will show if anyone care enough to tell us they do use it ;-)
[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #22 from David Malcolm --- Assigning this to me in the hope that I'll get to it in gcc 9 stage 1.
[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82049 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 20:45:40 2018 New Revision: 257460 URL: https://gcc.gnu.org/viewcvs?rev=257460&root=gcc&view=rev Log: 2018-02-07 Steven G. Kargl PR fortran/82049 * match.c (gfc_match_type_spec): If the charlen is non-NULL, then try to resolve it. While here return early if possible. 2018-02-07 Steven G. Kargl PR fortran/82049 * gfortran.dg/assumed_charlen_parameter.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82049 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Feb 7 20:43:33 2018 New Revision: 257459 URL: https://gcc.gnu.org/viewcvs?rev=257459&root=gcc&view=rev Log: 2018-02-06 Steven G. Kargl PR fortran/82049 * match.c (gfc_match_type_spec): If the charlen is non-NULL, then try to resolve it. While here return early if possible. 2018-02-06 Steven G. Kargl PR fortran/82049 * gfortran.dg/assumed_charlen_parameter.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/assumed_charlen_parameter.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83204 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #2 from Bill Schmidt --- I wonder how many failures are left if that invalid cast is removed from the code? It is just wrong and unnecessary.
[Bug lto/84212] -Wno-* does not disable warnings from -flto link stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84212 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00350.html
[Bug target/84220] rs6000 builtin __builtin_vec_sld() ICEs on invalid 3rd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84220 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-02/msg00325.ht ||ml Last reconfirmed||2018-02-07 Assignee|unassigned at gcc dot gnu.org |willschm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Will has a patch submitted.
[Bug fortran/84270] New: optimization bug with assumed size array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84270 Bug ID: 84270 Summary: optimization bug with assumed size array argument Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: weinert at cmth dot phys.uwm.edu Target Milestone: --- Created attachment 43359 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43359&action=edit simple test case Optimization bug at -O2, -O3 with message vr = matmul( orth(:,:,n), v ) 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array ‘orth’ at (1) lhcal.f90:33:25: Attached test case is taken from larger program, and only appears to be a problem if orth is an assumed size arrays with the * in the last dimension. (If assumed shape, also fine.) Obviously easy to work around, so minor.
[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org
[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789 --- Comment #4 from Segher Boessenkool --- Kaushik: is this fixed with r256762?
[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80567 David Malcolm changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84269 --- Comment #9 from David Malcolm --- I've filed PR c++/84269 to track improving the "memset" handling (for next stage 1).
[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 David Malcolm changed: What|Removed |Added Priority|P3 |P5
[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-07 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug c++/84269] New: C++ FE does not suggest which #include to use for "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 Bug ID: 84269 Summary: C++ FE does not suggest which #include to use for "memset" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- As noted in the fix for PR c++/81610 and PR c++/80567 here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02200.html > The C++ FE is missing a suggestion about which #include to use for > "memset", but I'd prefer to treat that as a follow-up patch (and > probably for next stage 1). I've filing this PR to capture that (for gcc 9 stage 1). See those PRs for more info.
[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80567 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed by r257456.
[Bug c++/81610] [8 Regression] bogus fix-it hint for a call to an undeclared function: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81610 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Should be fixed by r257456.
[Bug c++/80567] [8 Regression] bogus fixit hint for undeclared memset: else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80567 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Wed Feb 7 17:55:54 2018 New Revision: 257456 URL: https://gcc.gnu.org/viewcvs?rev=257456&root=gcc&view=rev Log: C++: avoid most reserved words as misspelling suggestions (PR c++/81610 and PR c++/80567) lookup_name_fuzzy can offer some reserved words as suggestions for misspelled words, helping with "singed"/"signed" typos. PR c++/81610 and PR c++/80567 report problems where the C++ frontend suggested "if", "for" and "else" as corrections for misspelled variable names. The root cause is that in r247233 ("Fix spelling suggestions for reserved words (PR c++/80177)") I loosened the conditions on these reserved words, adding this condition: if (kind == FUZZY_LOOKUP_TYPENAME) to the logic for rejecting words that don't start decl-specifiers, to allow for "static_assert" to be offered. This is too loose a condition: we don't want to suggest *any* reserved word when we're in a context where we don't know we expect a typename. For the kinds of error-recover situations where we're suggesting spelling corrections we don't have much contextual information, so it seems prudent to be stricter about which reserved words we offer as spelling suggestions; I don't think it makes sense for us to suggest e.g. "for". This patch implements that by effectively reinstating the old logic, but special-casing RID_STATIC_ASSERT, moving the logic to a new subroutine (in case we want to allow for other special-cases). I attempted to add suggestions for the various RID_*CAST, to cope with e.g. "reinterptet_cast" (I can never type that correctly on the first try), but the following '<' token confuses the error-recovery enough that the suggestion code isn't triggered. gcc/cp/ChangeLog: PR c++/81610 PR c++/80567 * name-lookup.c (suggest_rid_p): New function. (lookup_name_fuzzy): Replace enum-rid-filtering logic with call to suggest_rid_p. gcc/testsuite/ChangeLog: PR c++/81610 PR c++/80567 * g++.dg/spellcheck-reswords.C: New test case. * g++.dg/spellcheck-stdlib.C: Remove xfail from dg-bogus suggestion of "if". Added: trunk/gcc/testsuite/g++.dg/spellcheck-reswords.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
[Bug c++/81610] [8 Regression] bogus fix-it hint for a call to an undeclared function: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81610 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Wed Feb 7 17:55:54 2018 New Revision: 257456 URL: https://gcc.gnu.org/viewcvs?rev=257456&root=gcc&view=rev Log: C++: avoid most reserved words as misspelling suggestions (PR c++/81610 and PR c++/80567) lookup_name_fuzzy can offer some reserved words as suggestions for misspelled words, helping with "singed"/"signed" typos. PR c++/81610 and PR c++/80567 report problems where the C++ frontend suggested "if", "for" and "else" as corrections for misspelled variable names. The root cause is that in r247233 ("Fix spelling suggestions for reserved words (PR c++/80177)") I loosened the conditions on these reserved words, adding this condition: if (kind == FUZZY_LOOKUP_TYPENAME) to the logic for rejecting words that don't start decl-specifiers, to allow for "static_assert" to be offered. This is too loose a condition: we don't want to suggest *any* reserved word when we're in a context where we don't know we expect a typename. For the kinds of error-recover situations where we're suggesting spelling corrections we don't have much contextual information, so it seems prudent to be stricter about which reserved words we offer as spelling suggestions; I don't think it makes sense for us to suggest e.g. "for". This patch implements that by effectively reinstating the old logic, but special-casing RID_STATIC_ASSERT, moving the logic to a new subroutine (in case we want to allow for other special-cases). I attempted to add suggestions for the various RID_*CAST, to cope with e.g. "reinterptet_cast" (I can never type that correctly on the first try), but the following '<' token confuses the error-recovery enough that the suggestion code isn't triggered. gcc/cp/ChangeLog: PR c++/81610 PR c++/80567 * name-lookup.c (suggest_rid_p): New function. (lookup_name_fuzzy): Replace enum-rid-filtering logic with call to suggest_rid_p. gcc/testsuite/ChangeLog: PR c++/81610 PR c++/80567 * g++.dg/spellcheck-reswords.C: New test case. * g++.dg/spellcheck-stdlib.C: Remove xfail from dg-bogus suggestion of "if". Added: trunk/gcc/testsuite/g++.dg/spellcheck-reswords.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/spellcheck-stdlib.C
[Bug rtl-optimization/83530] [7/8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 Pat Haugen changed: What|Removed |Added Summary|[8 Regression] ICE in |[7/8 Regression] ICE in |reset_sched_cycles_in_curre |reset_sched_cycles_in_curre |nt_ebb, at sel-sched.c:7150 |nt_ebb, at sel-sched.c:7150 --- Comment #10 from Pat Haugen --- Marking as 7 regression also as that is when the change to use -fsched-pressure --param sched-pressure-algorithm=2 as the default for PowerPC happened. But as I mentioned in Comment 7, the failure can be reproduced on prior versions by adding those two options.
[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530 --- Comment #9 from Pat Haugen --- (In reply to Andrey Belevantsev from comment #8) > I will take a look. The ICE is within the code that models the scheduling > loop in order to get the proper insn ticks and everything for later MD > processing (it is equivalent to always scheduling the next insn). Either > there is an issue in that loop that wasn't uncovered anywhere but powerpc or > there is some subtlety in the powerpc cpu model that is triggered there. It > is not very pleasant to find out and fix usually so it will take time. Thanks, appreciate that. I did find out the isssue is not very pleasant to track down as you state.
[Bug lto/84212] -Wno-* does not disable warnings from -flto link stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84212 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- You're right. I fixed it for bug 78768 in r244326 (-Walloca-larger-than and -Wformat-overflow et al.) but missed -Wstringop-overflow. Let me take care of this. I wonder if LTO should be implied for all warnings to avoid these mistakes. Alternatively, have a script check to make sure that middle-end warnings are enabled for in the .opt file(s), run it for each build and fail if not.
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Additional testcases now fixed as well.
[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed
[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84181 --- Comment #7 from Jason Merrill --- Author: jason Date: Wed Feb 7 16:02:50 2018 New Revision: 257454 URL: https://gcc.gnu.org/viewcvs?rev=257454&root=gcc&view=rev Log: PR c++/84182 - ICE with captured lambda PR c++/84181 * pt.c (extract_locals_r, extract_local_specs): New. (tsubst_pack_expansion): Use them. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-targ2.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84182 --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Feb 7 16:02:50 2018 New Revision: 257454 URL: https://gcc.gnu.org/viewcvs?rev=257454&root=gcc&view=rev Log: PR c++/84182 - ICE with captured lambda PR c++/84181 * pt.c (extract_locals_r, extract_local_specs): New. (tsubst_pack_expansion): Use them. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-targ2.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 Bill Seurer changed: What|Removed |Added CC||munroesj at gcc dot gnu.org --- Comment #1 from Bill Seurer --- Most of the failures (well, the first couple dozen or so anyway) appear to be like this: Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o ./bmi-andn-1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o ./bmi-andn-1.exe In file included from /home/seurer/gcc/build/gcc-trunk/gcc/include/x86intrin.h:39, from /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/bmi-andn-1.c:7: /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h: In function '_mm_cmpeq_pi32': /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:3: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int' /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h: In function '_mm_cmpgt_pi32': /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int' compiler exited with status 1 FAIL: gcc.target/powerpc/bmi-andn-1.c (test for excess errors) Excess errors: /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:857:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int' /home/seurer/gcc/build/gcc-trunk/gcc/include/mmintrin.h:886:5: error: incompatible types when assigning to type '__vector signed int' {aka '__vector(4) int'} from type '__vector(8) short int'
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #23 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #21) > So after r257453 we improve the situation pre-IVOPTs to just > 6 IVs (duplicated but trivially equivalent) plus one counting IV. But then > when SLP is enabled IVOPTs comes along and adds another 4 IVs which makes us > spill... (for AVX256, so you need -march=core-avx2 for example). > > Bin, any chance you can take a look? In the IVO dump I see > > target_avail_regs 15 > target_clobbered_regs 9 > target_reg_cost 4 > target_spill_cost 8 > regs_used 3 > ^^^ > > and regs_used looks awfully low to me. The loop has even more IVs initially > plus variable steps for that IVs which means we need two regs per IV. > > There doesn't seem to be a way to force IVOPTs to use the minimal set of IVs? > Or just use the original set, removing the obvious redundancies? There is > a microarchitectural issue left with the vectorization but the spilling > obscures the look quite a bit :/ Sure, I will have a look based on your commit. Thanks
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #22 from Richard Biener --- Author: rguenth Date: Wed Feb 7 15:46:17 2018 New Revision: 257453 URL: https://gcc.gnu.org/viewcvs?rev=257453&root=gcc&view=rev Log: 2018-02-07 Richard Biener PR tree-optimization/84037 * tree-vectorizer.h (struct _loop_vec_info): Add ivexpr_map member. (cse_and_gimplify_to_preheader): Declare. (vect_get_place_in_interleaving_chain): Likewise. * tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize ivexpr_map. (_loop_vec_info::~_loop_vec_info): Delete it. (cse_and_gimplify_to_preheader): New function. * tree-vect-slp.c (vect_get_place_in_interleaving_chain): Export. * tree-vect-stmts.c (vectorizable_store): CSE base and steps. (vectorizable_load): Likewise. For grouped stores always base the IV on the first element. * tree-vect-loop-manip.c (vect_loop_versioning): Unshare versioning condition before gimplifying. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #21 from Richard Biener --- So after r257453 we improve the situation pre-IVOPTs to just 6 IVs (duplicated but trivially equivalent) plus one counting IV. But then when SLP is enabled IVOPTs comes along and adds another 4 IVs which makes us spill... (for AVX256, so you need -march=core-avx2 for example). Bin, any chance you can take a look? In the IVO dump I see target_avail_regs 15 target_clobbered_regs 9 target_reg_cost 4 target_spill_cost 8 regs_used 3 ^^^ and regs_used looks awfully low to me. The loop has even more IVs initially plus variable steps for that IVs which means we need two regs per IV. There doesn't seem to be a way to force IVOPTs to use the minimal set of IVs? Or just use the original set, removing the obvious redundancies? There is a microarchitectural issue left with the vectorization but the spilling obscures the look quite a bit :/
[Bug target/84266] New: mmintrin.h intrinsic headers for PowerPC code fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 Bug ID: 84266 Summary: mmintrin.h intrinsic headers for PowerPC code fails on power9 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- (more details coming) This is the complete list of failures: FAIL: gcc.target/powerpc/bmi-andn-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-andn-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-bextr-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-bextr-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-bextr-4.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-bextr-5.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsi-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsi-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsmsk-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsmsk-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsr-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-blsr-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-tzcnt-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi-tzcnt-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi2-bzhi32-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi2-bzhi64-1.c (test for excess errors) FAIL: gcc.target/powerpc/bmi2-bzhi64-1a.c (test for excess errors) FAIL: gcc.target/powerpc/bmi2-mulx32-2.c (test for excess errors) FAIL: gcc.target/powerpc/bmi2-mulx64-2.c (test for excess errors) times) FAIL: gcc.target/powerpc/mmx-packs.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-packssdw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-packsswb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-packuswb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddd-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddsb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddsw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddusb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddusw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-paddw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpeqb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpeqd-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpeqw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpgtb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpgtd-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pcmpgtw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pmaddwd-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pmulhw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pmullw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-pslld-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psllw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psrad-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psraw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psrld-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psrlw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubb-2.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubd-2.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubsb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubsw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubusb-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubusw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-psubw-2.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpckhbw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpckhdq-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpckhwd-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpcklbw-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpckldq-1.c (test for excess errors) FAIL: gcc.target/powerpc/mmx-punpcklwd-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-addps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-addss-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-andnps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-andps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cmpss-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cvtpi16ps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cvtpi32ps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cvtpi32x2ps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cvtpi8ps-1.c (test for excess errors) FAIL: gcc.target/powerpc/sse-cvtpspi16-1.c (test for excess errors) FAIL: gcc.target/power
[Bug c/84258] Bogus -Wformat warning "wide character string" for const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84258 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-07 CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- Confirmed. The wording seems to date back to r36586 (18 years ago). I'll have a look at fixing it.
[Bug c/84240] Error in extract_constrain_insn, at recog.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84240 --- Comment #2 from xvl5190 at psu dot edu --- Please try this example with optimization level -O1/-O2/-O3: /* Executable testcase for 'output flags.' */ /* { dg-do rund *nbum; } */ char TestC() { char r; __asm__("stc": "=@ccc" (r)); if (r) { __asm__("clc": "=@ccnc" (r)); if (r) return 1; } return 0; } char TestE() { char r; /* 1 equals 1. */ __asm__("cmp $1, %1": "=@cce" (r): "r" (1)); if (r) { /* 1 not equals 2. */ __asm__("cmp $2, %1": "=@ccne" (r): "r" (1)); if (r) return 1; } return 0; } char TestZ() { char r; /* 1 equals 1. */ __asm__("cmp $1, %1": "=@ccz" (r): "r" (1)); if (r) { /* 1 not equals 2. */ __asm__("cmp $2, %1": "=@ccnz" (r): "r" (1)); if (r) return 1; } return 0; } char TestA() { char r; /* 1 a 0. */ __asm__("cmp $0, %1": "=@cca" (r): "r" (1)); if (r) { /* 1 na 2. */ __asm__("cmp $2, %1": "=@ccna" (r): "r" (1)); if (r) { /* 1 na 1. */ __asm__("cmp $1, %1": "=@ccna" (r): "r" (1)); if (r) return 1; } } return 0; } char TestAE() { char r; /* 1 ae 0. */ __asm__("cmp $0, %1": "=@ccae" (r): "r" (1)); if (r) { /* 1 nae 2. */ __asm__("cmp $2, %1": "=@ccnae" (r): "r" (1)); if (r) { /* 1 ae 1. */ __asm__("cmp $1, %1": "=@ccae" (r): "r" (1)); if (r) return 1; } } return 0; } char TestB() { char r; /* 1 b 2. */ __asm__("cmp $2, %1": "=@ccb" (r): "r" (1)); if (r) { /* 1 nb 0. */ __asm__("cmp $0, %1": "=@ccnb" (r): "r" (1)); if (r) { /* 1 nb 1. */ __asm__("cmp $1, %1": "=@ccnb" (r): "r" (1)); if (r) return 1; } } return 0; } char TestBE() { char r; /* 1 be 2. */ __asm__("cmp $2, %1": "=@ccbe" (r): "r" (1)); if (r) { /* 1 nbe 0. */ __asm__("cmp $0, %1": "=@ccnbe" (r): "r" (1)); if (r) { /* 1 be 1. */ __asm__("cmp $1, %1": "=@ccbe" (r): "r" (1)); if (r) return 1; } } return 0; } char TestG() { char r; /* 1 g 0. */ __asm__("cmp $0, %1": "=@ccg" (r): "r" (1)); if (r) { /* 1 ng 2. */ __asm__("cmp $2, %1": "=@ccng" (r): "r" (1)); if (r) { /* 1 ng 1. */ __asm__("cmp $1, %1": "=@ccng" (r): "r" (1)); if (r) return 1; } } return 0; } char TestGE() { char r; /* 1 ge 0. */ __asm__("cmp $0, %1": "=@ccge" (r): "r" (1)); if (r) { /* 1 nge 2. */ __asm__("cmp $2, %1": "=@ccnge" (r): "r" (1)); if (r) { /* 1 ge 1. */ __asm__("cmp $1, %1": "=@ccge" (r): "r" (1)); if (r) return 1; } } return 0; } char TestL() { char r; /* 1 l 2. */ __asm__("cmp $2, %1": "=@ccl" (r): "r" (1)); if (r) { /* 1 nl 0. */ __asm__("cmp $0, %1": "=@ccnl" (r): "r" (1)); if (r) { /* 1 nl 1. */ __asm__("cmp $1, %1": "=@ccnl" (r): "r" (1)); if (r) return 1; } } return 0; } char TestLE() { char r; /* 1 le 2. */ __asm__("cmp $2, %1": "=@ccle" (r): "r" (1)); if (r) { /* 1 nle 0. */ __asm__("cmp $0, %1": "=@ccnle" (r): "r" (1)); if (r) { /* 1 le 1. */ __asm__("cmp $1, %1": "=@ccle" (r): "r" (1)); if (r) return 1; } } return 0; } char TestO() { char r; unsigned char res = 128; /* overflow. */ __asm__("addb $128, %1": "=@cco" (r), "+r" (res)); if (r) { /* not overflow. */ __asm__("addb $1, %1": "=@ccno" (r), "+r" (res)); if (r) return 1; } return 0; } char TestP() { char r, res = 1; /* even # bits. */ __asm__("addb $2, %1": "=@ccp" (r), "+r" (res)); if (r) { /* odd # bits. */ __asm__("addb $1, %1": "=@ccnp" (r), "+r" (res)); if (r) return 1; } return 0; } char TestS() { char r, res = 1; /* sign bit set. */ __asm__("addb $128, %1": "=@ccs" (r), "+r" (res)); if (r) { /* sign bit not set. */ __asm__("subb $128, %1": "=@ccns" (r), "+r" (res)); if (r) return 1; } return 0; } /* dg-do treats exit code of 0 as success. */ int main() { if (TestC() && TestE() && TestZ() && TestA() && TestAE() && TestB() && TestBE() && TestG() && TestGE() && TestL() && TestLE() && TestO() && TestP() && TestS()) return 0; __builtin_abort(); }
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #11 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #10) > On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 > > > > --- Comment #9 from Jakub Jelinek --- > > I think the bug is in the ARRAY_REF design, because at least in C one can > > have > > arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND > > (, > > 3) > > is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make > > sense, > > because what you really get from array_ref_element_size in cases where the > > size > > of element is not a multiple of the TYPE_ALIGN_UNIT is something that > > doesn't > > have anything to do with the element size. > > Is that some Ada specific stuff? > > Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN, > > supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but > > something smaller. > > It is an optimization so that for variable-sized stuff it's easier to > get at an alignment value. We've experimented with removing this > but it regressed some cases (even in C). Eric may know more and I > think there was a bug tracking this ... or some ml posts. > > So arrays of over-aligned types in C do not contain padding? Thus > the elements are not aligned but only the first element? Wasn't I believe so. > this to be implemented as aligning the array type but not its element > type? Not sure how it would be possible. There is the debug info question (perhaps not a show stopper with early debug), another one is that for aggregates the alignment is an essential part, we don't have for the same aggregate differently aligned variants. And we can have arrays of arrays, or arrays of VLA structures etc. Anyway, seems with the _Alignas(16) or __attribute__((aligned (16))) before the struct keyword we actually don't have array of over-aligned fields, that is what you get when using struct __attribute__((aligned (16))) { short aa; } a[size]; That is somewhat simpler case, it is only the array field itself that is aligned, array_ref_element_size is not involved at all in that case, but we still compute an incorrect rli->offset_align somewhere for the b field. While the previous field is 16 bytes aligned, the element is only 2 bytes aligned and variable size, so b is only guaranteed to be 4 bytes aligned (2 bytes if it was say char b[size];).
[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241 --- Comment #8 from Jan Hubicka --- I am testing fix for the missing resolution info. It turns out to be related to rather early LTO hack to not put into symbol table symbols used only by external definitions. Concerning multiversioning this is different bug (it produces cgraph node with wrong visibility flags) I will fix next.
[Bug target/84264] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 --- Comment #2 from Segher Boessenkool --- It ICEs on gcc_assert (!lra_in_progress && !reload_completed); but this is called from the movv4si expander, and that is something LRA is allowed to use.
[Bug other/80589] Typing mistakes in two messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589 Martin Liška changed: What|Removed |Added Status|REOPENED|ASSIGNED
[Bug other/80589] Typing mistakes in two messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80589 Martin Liška changed: What|Removed |Added Known to work|8.0 | Known to fail||8.0 --- Comment #9 from Martin Liška --- (In reply to Göran Uddeborg from comment #8) > This doesn't seem completely fixed. I don't see the second mistake any > more. But the first mistake still remains in param.def, while the same > string in doc/invoke.texi is fixed. Confirmed, let me fix that.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #10 from rguenther at suse dot de --- On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 > > --- Comment #9 from Jakub Jelinek --- > I think the bug is in the ARRAY_REF design, because at least in C one can have > arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (, > 3) > is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make > sense, > because what you really get from array_ref_element_size in cases where the > size > of element is not a multiple of the TYPE_ALIGN_UNIT is something that doesn't > have anything to do with the element size. > Is that some Ada specific stuff? > Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN, > supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but > something smaller. It is an optimization so that for variable-sized stuff it's easier to get at an alignment value. We've experimented with removing this but it regressed some cases (even in C). Eric may know more and I think there was a bug tracking this ... or some ml posts. So arrays of over-aligned types in C do not contain padding? Thus the elements are not aligned but only the first element? Wasn't this to be implemented as aligning the array type but not its element type?
[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Created attachment 43358 [details] > gcc8-pr84252.patch > > Full untested fix. Thanks. Bootstrapped & regression-tested on aarch64-linux-gnu, no new failures.
[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241 H.J. Lu changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu | |, aarch64-none-linux-gnu, | |arm | CC||hjl.tools at gmail dot com --- Comment #7 from H.J. Lu --- I also saw it on x86-64 and spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc9.c -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/ -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/ -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/ -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt/.libs -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/ -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -lm -o ./mvc9.exe^M lto1: fatal error: missing resolution data for foo.default.3^M compilation terminated.^M lto-wrapper: fatal error: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc returned 1 exit status^M compilation terminated.^M /usr/local/bin/ld: error: lto-wrapper failed^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 FAIL: gcc.target/i386/mvc9.c (test for excess errors)
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #9 from Jakub Jelinek --- I think the bug is in the ARRAY_REF design, because at least in C one can have arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (, 3) is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make sense, because what you really get from array_ref_element_size in cases where the size of element is not a multiple of the TYPE_ALIGN_UNIT is something that doesn't have anything to do with the element size. Is that some Ada specific stuff? Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN, supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but something smaller.
[Bug c++/83204] [6/7/8 Regression] c++ -std=c++14 ICE in maybe_undo_parenthesized_ref, at cp/semantics.c:1694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83204 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- I'm looking a bit into this. First blush I'm also wondering if we don't want something like the below - which passes testing on x86_64-linux: Index: pt.c === --- pt.c(revision 257438) +++ pt.c(working copy) @@ -17210,8 +17210,8 @@ tsubst_copy_and_build (tree t, r = build_x_indirect_ref (input_location, r, RO_UNARY_STAR, complain|decltype_flag); - if (TREE_CODE (r) == INDIRECT_REF) - REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t); + if (REF_PARENTHESIZED_P (t)) + r = force_paren_expr (r); RETURN (r); }
[Bug target/84264] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-07 Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. Needs -mlittle, -fstack-protector=strong, any -On with n > 0.
[Bug target/84265] ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. In case you're having trouble reproducing it on trunk, adding -mcpu=cortex-a53 helps (some vector costs are probably involved)
[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #4 from Richard Biener --- MODULE MODULE_RA_GFDLETA REAL , SAVE :: EM1(28,180) REAL ,SAVE, DIMENSION(5040):: EM1V EQUIVALENCE (EM1V(1),EM1(1,1)) END MODULE module_RA_GFDLETA
[Bug lto/84213] [8 Regression] 521.wrf_r from SPEC 2017 fails to build (link) with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84213 --- Comment #3 from Richard Biener --- So the issue here is that the early debug generated for module_ra_gfdleta.F90 contains relocations to text symbols. That's a no-no. So this is reproducible with just compiling this file with -flto -g, the resulting object file has Relocation section '.rela.gnu.debuglto_.debug_info' at offset 0xd6610 contains 4636 entries: Offset Info Type Sym. ValueSym. Name + Addend ... 04d9 00860001 R_X86_64_64 module_ra_gfdleta.eq.1 + 0 04ed 00860001 R_X86_64_64 module_ra_gfdleta.eq.1 + 0 ... etc. So reducing a testcase should be possible by grepping readelf -r (it's the only relocation section) for module_ra_gfdleta.eq ... Tryign to reduce.
[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84059 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Feb 7 13:16:04 2018 New Revision: 257451 URL: https://gcc.gnu.org/viewcvs?rev=257451&root=gcc&view=rev Log: Revert behavior to r251316. 2018-02-07 Martin Liska PR c++/84059. * class.c (add_method): Append argument value. * cp-tree.h (maybe_version_functions): Add new argument. * decl.c (decls_match): Call it if a declaration does not have DECL_FUNCTION_VERSIONED. (maybe_version_functions): record argument is added. 2018-02-07 Martin Liska PR c++/84059. * g++.dg/ext/mv26.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/mv26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/84257] Extremely slow compilation from gcc source code under macOS 10.13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257 --- Comment #3 from 191919 <191919 at gmail dot com> --- In macOS 10.12.6 with SIP disabled, the value of DYLD_LIBRARY_PATH was modified to the same as in macOS 10.13.3, but the compilation speed was not affected. I guess this is a regression of macOS code to handle DYLD_LIBRARY_PATH in an SIP-disabled environment. Long since OS X El Capitan which introduced SIP (aka rootless), DYLD_LIBRARY_PATH was practically screened and no one complained about it, I think it is safe to say that the line #3 of the following code taken from configure.ac of gcc is not necessary and can be removed. 1 | case "${host}" in 2 | *-*-hpux*) RPATH_ENVVAR=SHLIB_PATH ;; 3 | *-*-darwin*) RPATH_ENVVAR=DYLD_LIBRARY_PATH ;; 4 | *-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;; 5 | *) RPATH_ENVVAR=LD_LIBRARY_PATH ;; 6 | esac
[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252 --- Comment #5 from Jakub Jelinek --- Created attachment 43358 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43358&action=edit gcc8-pr84252.patch Full untested fix.
[Bug target/84265] ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Priority|P3 |P1 Last reconfirmed||2018-2-7 Target Milestone|--- |8.0
[Bug target/84265] New: ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84265 Bug ID: 84265 Summary: ICE in vect_permute_load_chain, at tree-vect-data-refs.c:5933 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: amker at gcc dot gnu.org, rdsandiford at googlemail dot com Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: aarch64-linux-gnu Both seen on native machine and cross compiler: $ cat ice.i struct a { unsigned long b; unsigned long c; int d; int *e; char f; }; struct { int g; struct a h[]; } i; int j, k; void l () { for (; k; k++) j += (int) (i.h[k].c - i.h[k].b); } $ ./xgcc -B. -O3 ice.i -c during GIMPLE pass: vect ice.i: In function ‘l’: ice.i:17:6: internal compiler error: in vect_permute_load_chain, at tree-vect-data-refs.c:5933 void l () ^ 0x134b950 vect_permute_load_chain ../../gcc/tree-vect-data-refs.c:5933 0x134c46f vect_transform_grouped_load(gimple*, vec, int, gimple_stmt_iterator*) ../../gcc/tree-vect-data-refs.c:6355 0xe31758 vectorizable_load ../../gcc/tree-vect-stmts.c:8366 0xe3c1df vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:9453 0xe4b522 vect_transform_loop(_loop_vec_info*) ../../gcc/tree-vect-loop.c:8872 0xe6b173 vectorize_loops() ../../gcc/tree-vectorizer.c:740
[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263 --- Comment #2 from Nathan Sidwell --- Martin has confirmed i686 host & target. (not just target)
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #39 from Christophe Lyon --- Maybe we can demote this from P1? I'm sure armeb is getting a lot of attention, given other bug reports.
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #38 from Christophe Lyon --- (In reply to Aldy Hernandez from comment #37) > (In reply to Christophe Lyon from comment #31) > > Created attachment 43352 [details] > > Reduced testcase > > > > I commented out most calls, since abort() is called from csub4. > > Can you also remove the csub8, isub4, and isub8 unused functions as well? > > I see you've commented out this in csub4: > > !! if (any(bb /= b)) call abort > > I assume this is irrelevant to the failure? > > Can you also verify that after these changes you have a revision of GCC for > which this reduced testcase succeeds (regardless of the vect cost model > rabbit hole), and a revision of GCC for which this fails? > > I'm trying to make sure all this removing of stuff didn't cause an > inconditional abort. I don't speak fortran, but I thought the program did: main-> call csub4-> call abort if some condition In my testing, removing all calls but csub4 from main is sufficient to make the program fail, and then it seems the first call to abort in csub4 is taken too. What would it change to remove csub8/isub4/isub8? (except not generating dead code, which is irrelevant to the current problem) > > Also, is this only reproducible with -g? I don't know, it's added by the torture harness. I wouldn't expect this to change code generation, though. > > BTW, no need to include the assembly. I should be able to generate it with > a cross ./cc1.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #8 from Jakub Jelinek --- Though, in e.g. *.ehcleanup2 dump we still have: pretmp.25_64 = D.1613_19 /[ex] 16; D.2749_73 = &s.2_61->b{off: pretmp.25_64 * 16}[0]; ivtmp.35_86 = (long unsigned int) D.2749_73; both before and after that revision, which matches what we emit now, but somehow in the *.optimized dump it gets optimized away into: ivtmp.35 = (long unsigned int) &s.2->b{off: D.1613}[0]; where the exact division and multiplication are cancelled. Though, /[ex] is a guarantee that it is an exact division and thus we are invoking UB if at runtime that isn't the case. The *.original dump still doesn't have this: s.b{off: (long unsigned int) SAVE_EXPR * 2}[i] = 0; but *.gimple does: D.1634 = D.1613 /[ex] 16; s.2->b{off: D.1634 * 16}[i] = 0;
[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Nathan Sidwell --- Well, that's exciting
[Bug target/84264] New: ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 Bug ID: 84264 Summary: ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org Target Milestone: --- Following code snippet ICEs: $ cat ice.ii void _setjmp (); void a (unsigned long *); void b () { for (;;) { _setjmp (); unsigned long args[9]{}; a (args); } } $ ./xgcc -B. ice.ii -O1 -fstack-protector-strong -c during RTL pass: reload ice.ii: In function ‘void b()’: ice.ii:12:1: internal compiler error: in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 } ^ 0x10e2dd6 rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode) ../../gcc/config/rs6000/rs6000.c:10367 0x12b5e68 gen_movv4si(rtx_def*, rtx_def*) ../../gcc/config/rs6000/vector.md:142 0xa1e514 insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../gcc/recog.h:301 0xa1e514 emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/expr.c:3661 0xa1e8ce emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3757 0xbe3422 lra_emit_move(rtx_def*, rtx_def*) ../../gcc/lra.c:497 0xbfb8c4 curr_insn_transform ../../gcc/lra-constraints.c:4297 0xbfd137 lra_constraints(bool) ../../gcc/lra-constraints.c:4883 0xbe6864 lra(_IO_FILE*) ../../gcc/lra.c:2410 0xb9a821 do_reload ../../gcc/ira.c:5465 0xb9a821 execute ../../gcc/ira.c:5649 Happens both on native and x86 cross compiler.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #7 from Jakub Jelinek --- The difference with that revision is: addq$2, %rax cmpq%rcx, %rax jne .L3 - leaq(%r12,%rdx), %rdx + andq$-16, %rdx xorl%eax, %eax + leaq(%r12,%rdx), %rdx
[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2018-2-7 Target Milestone|--- |8.0
[Bug c++/84263] New: [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263 Bug ID: 84263 Summary: [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Host: i686-linux-gnu Starting from r248826 we ICE on: $ cat /tmp/ice.ii namespace std { template struct b { int c; a d; }; template class g; template class initializer_list { int *e; unsigned f; }; class h; class j { typedef b i; public: j(); j(initializer_list); }; template struct m; template struct m {}; class h { public: template h(l &); }; class G { G(); j n; }; G::G() { n = decltype(n){{0, ""}, {1, ".unoLineArrowEnd"}}; } } $ ./gcc/xg++ -Bgcc /tmp/ice.ii --param ggc-min-expand=0 --param ggc-min-heapsize=0 -c /tmp/ice.ii:29:61: internal compiler error: Segmentation fault G::G() { n = decltype(n){{0, ""}, {1, ".unoLineArrowEnd"}}; } ^ 0x8c82124 crash_signal ../../gcc/toplev.c:338 0x870f9d6 lookup_page_table_entry ../../gcc/ggc-page.c:646 0x87106f6 ggc_set_mark(void const*) ../../gcc/ggc-page.c:1536 0x864b7de gt_ggc_mx_lang_tree_node(void*) ./gt-cp-tree.h:138 0x857f789 gt_ggc_mx(deferred_access_check&) ./gt-cp-parser.h:45 0x8581ab4 void gt_ggc_mx(vec*) ../../gcc/vec.h:1107 0x857f760 gt_ggc_mx_vec_deferred_access_check_va_gc_(void*) ./gt-cp-parser.h:37 0x857f838 gt_ggc_mx_tree_check(void*) ./gt-cp-parser.h:57 0x857f907 gt_ggc_mx(cp_token&) ./gt-cp-parser.h:79 0x8581aff void gt_ggc_mx(vec*) ../../gcc/vec.h:1107 0x857f8a4 gt_ggc_mx_vec_cp_token_va_gc_(void*) ./gt-cp-parser.h:68 0x857f986 gt_ggc_mx_cp_lexer(void*) ./gt-cp-parser.h:95 0x857fbdc gt_ggc_mx_cp_parser(void*) ./gt-cp-parser.h:155 0x892e005 ggc_mark_root_tab ../../gcc/ggc-common.c:77 0x892e082 ggc_mark_roots() ../../gcc/ggc-common.c:94 0x871167b ggc_collect() ../../gcc/ggc-page.c:2206 0x87b0a77 cgraph_node::finalize_function(tree_node*, bool) ../../gcc/cgraphunit.c:488 0x861b497 expand_or_defer_fn(tree_node*) ../../gcc/cp/semantics.c:4299 0x852f409 maybe_clone_body(tree_node*) ../../gcc/cp/optimize.c:670 0x861b378 expand_or_defer_fn_1(tree_node*) ../../gcc/cp/semantics.c:4272 I can repeat that only on i686 target.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #6 from Jakub Jelinek --- This changed with r146817, so I'd look at a problem in expansion rather than much earlier. DECL_SIZE_UNIT should match what sizeof is, so you can't just change it at will, it is part of the ABI. Arrays of overaligned structures are just weird, but I believe they don't grow the size of the elements, so only the first array element is aligned and the remaining ones are not.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 --- Comment #5 from rguenther at suse dot de --- On Wed, 7 Feb 2018, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 > > Aldy Hernandez changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org, >||rguenth at gcc dot gnu.org > > --- Comment #4 from Aldy Hernandez --- > [Looping in the experts: Hi Jakub. Hi Richard.] > > Imagine this: > > struct big_container { > __attribute__((aligned(16))) > struct aa_container { > short aa; > } a[size]; > int b[size]; > } s; > > While laying out the type of big_container, and looking at field "a" in > place_field() we get a DECL_SIZE_UNIT(a) of SAVE_EXPR * 2 (courtesy of > update_alignment_for_field). > > This size*2 is used in calculating the size of the record thus far: > > /* Now add size of this field to the size of the record. If the size is > not constant, treat the field as being a multiple of bytes and just > adjust the offset, resetting the bit position. > ... > else if (TREE_CODE (DECL_SIZE (field)) != INTEGER_CST >|| TREE_OVERFLOW (DECL_SIZE (field))) > { > rli->offset > = size_binop (PLUS_EXPR, rli->offset, > fold_convert (sizetype, > size_binop (CEIL_DIV_EXPR, rli->bitpos, > bitsize_unit_node))); > rli->offset > = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field)); > rli->bitpos = bitsize_zero_node; > rli->offset_align = MIN (rli->offset_align, desired_align); > } > > (gdb) p debug_generic_stmt(rli.offset) > (sizetype) SAVE_EXPR * 2; > > Which means that when we call place_field(b), we think we have to start at > size*2. Surely the start of field b should take into consideration the > alignment of aa_container, no? > > Question: > > 1. Should DECL_SIZE_UNIT(a) include the size of the alignment padding? I'm not sure whether the attribute aligns the array elements or the array. If it aligns the array then no. > 2. Or, should the snippet above add the padding? This is for b, so why? There should be no padding needed. > Or, am I missing something? > > Thanks. > >
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210 Aldy Hernandez changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #4 from Aldy Hernandez --- [Looping in the experts: Hi Jakub. Hi Richard.] Imagine this: struct big_container { __attribute__((aligned(16))) struct aa_container { short aa; } a[size]; int b[size]; } s; While laying out the type of big_container, and looking at field "a" in place_field() we get a DECL_SIZE_UNIT(a) of SAVE_EXPR * 2 (courtesy of update_alignment_for_field). This size*2 is used in calculating the size of the record thus far: /* Now add size of this field to the size of the record. If the size is not constant, treat the field as being a multiple of bytes and just adjust the offset, resetting the bit position. ... else if (TREE_CODE (DECL_SIZE (field)) != INTEGER_CST || TREE_OVERFLOW (DECL_SIZE (field))) { rli->offset = size_binop (PLUS_EXPR, rli->offset, fold_convert (sizetype, size_binop (CEIL_DIV_EXPR, rli->bitpos, bitsize_unit_node))); rli->offset = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field)); rli->bitpos = bitsize_zero_node; rli->offset_align = MIN (rli->offset_align, desired_align); } (gdb) p debug_generic_stmt(rli.offset) (sizetype) SAVE_EXPR * 2; Which means that when we call place_field(b), we think we have to start at size*2. Surely the start of field b should take into consideration the alignment of aa_container, no? Question: 1. Should DECL_SIZE_UNIT(a) include the size of the alignment padding? 2. Or, should the snippet above add the padding? Or, am I missing something? Thanks.
[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234 --- Comment #6 from Florian Lemaitre --- I want auto-vectorization, not guided vectorization. Basically, I try to write a fast RSQRT that will not break auto vectorization, and this will be integrated in a large scale project where it is easy to tell people "use this function" than to make them writing guided vectorization. As far as I'm concerned, I'm completely fine with telling the compiler my function doesn't have any side effect. But this should be written somewhere for other people.
[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262 --- Comment #4 from Jonathan Wakely --- (In reply to Serguei Kolos from comment #2) > If you read my original message through the end you should have noticed that > I have admitted that already. My question was different: > > Is it normal that the same code (seemingly bogus) compiles fine with > optimize tags and gives errors without them? That question might have been more appropriate on the gcc-help mailing list, not as a bug report. Anyway, as I said, the answer is yes. It's expected.
[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262 --- Comment #3 from Jonathan Wakely --- (In reply to Serguei Kolos from comment #0) > According to the article 9.4.2/4 of the C++ standard the code is probably > missing definitions of the c1, c2 and c3 constants: > > "If a static data member is of const integral or const enumeration type, its > declaration in the class definition can specify a constant initializer which > shall be an integral constant expression (5.19). In that case, the member > can appear in integral constant expressions within its scope. The member > shall still be defined in a namespace scope if it is used in the program and > the namespace scope definition shall not contain an initializer." Right. https://isocpp.org/wiki/faq/ctors#link-errs-static-data-mems > But what bothers me is the fact that the same (seemingly bogus) code > compiles fine with -OX flag. Is that normal? Yes, see https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234 --- Comment #5 from Jakub Jelinek --- #pragma omp declare simd or simd attribute say that on the definition compiler should create alternate entry point(s) for the vectorized variants, and on declarations that on the definition they were created, and that the compiler can use them on vectorized loops. That is true also on your testcase, just the compiler decided not to use them because it couldn't prove it doesn't have a side-effect that would prevent it. What I don't understand is when you are using #pragma omp declare simd why aren't you also using #pragma omp simd on the loops you want to vectorize.
[Bug c/84261] gcc fails to vectorize a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84261 --- Comment #3 from Marcin Krotkiewski --- (In reply to Richard Biener from comment #1) > Also vectorization of loops with using vectors isn't supported. Not sure what you mean. If instead of a function call I do some floating point computations in test1, e.g., #pragma omp declare simd simdlen(4) double test1(double v1) { for(int i=0; i<4; i++){ v1 = v1*1.1; } return v1; } then the loop is 'vectorized' as expected, i.e., executed for short vector arguments, and not for scalars.
[Bug c++/84262] Header file initialization of a static constant causes linker error if code is compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84262 --- Comment #2 from Serguei Kolos --- If you read my original message through the end you should have noticed that I have admitted that already. My question was different: Is it normal that the same code (seemingly bogus) compiles fine with optimize tags and gives errors without them?
[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84252 Jakub Jelinek changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That patch changed behavior rather than just change representation from hwis to poly_int*. --- gcc/var-tracking.c.jj 2018-01-04 00:43:15.007702432 +0100 +++ gcc/var-tracking.c 2018-02-07 11:13:59.388135311 +0100 @@ -1853,8 +1853,7 @@ static bool track_offset_p (poly_int64 offset, HOST_WIDE_INT *offset_out) { HOST_WIDE_INT const_offset; - if (!offset.is_constant (&const_offset) - || !IN_RANGE (const_offset, 0, MAX_VAR_PARTS - 1)) + if (!offset.is_constant (&const_offset)) return false; *offset_out = const_offset; return true; @@ -5355,7 +5354,8 @@ track_loc_p (rtx loc, tree expr, poly_in } HOST_WIDE_INT const_offset; - if (!track_offset_p (offset, &const_offset)) + if (!track_offset_p (offset, &const_offset) + || !IN_RANGE (const_offset, 0, MAX_VAR_PARTS - 1)) return false; if (mode_out) would restore previous behavior. The primary point of MAX_VAR_PARTS is to make sure that no value is tracked in more than 16 parts, which in many cases is enforced just by giving up if we need more than 16 bytes of memory or offsets above that, but other parts of the code just care that not more than 16 unique offsets are tracked for the var. The patch added: /* vt_get_decl_and_offset has already checked that the offset is a valid variable part. */ comment which just isn't correct, because vt_get_decl_and_offset could have failed and we'd still get here. So, another possible fix is to: --- gcc/var-tracking.c.jj 2018-01-04 00:43:15.007702432 +0100 +++ gcc/var-tracking.c 2018-02-07 12:47:09.735980882 +0100 @@ -9653,6 +9653,7 @@ vt_add_function_parameter (tree parm) poly_int64 offset; dataflow_set *out; decl_or_value dv; + bool incoming_ok = true; if (TREE_CODE (parm) != PARM_DECL) return; @@ -9743,6 +9744,7 @@ vt_add_function_parameter (tree parm) if (!vt_get_decl_and_offset (incoming, &decl, &offset)) { + incoming_ok = false; if (MEM_P (incoming)) { /* This means argument is passed by invisible reference. */ @@ -9861,6 +9863,10 @@ vt_add_function_parameter (tree parm) { int i; + /* The following code relies on vt_get_decl_and_offset returning true for +incoming, which might not be always the case. */ + if (!incoming_ok) + return; for (i = 0; i < XVECLEN (incoming, 0); i++) { rtx reg = XEXP (XVECEXP (incoming, 0, i), 0);
[Bug middle-end/84234] #pragma omp declare simd is ignored on forward declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84234 --- Comment #4 from Florian Lemaitre --- Ah... ok. I understand. Indeed, declaring the function const works as expected. So, I guess we can say it is not a bug, and close the bug report? However, I really think this should be documented somewhere. Currently, there is no mention of side effects within GCC existing documentation either here: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes or here (referenced by previous page): https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt