[Bug libgcc/85388] config/i386/morestack.S is incompatible with CET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85388 --- Comment #1 from H.J. Lu --- I am testing this patch: diff --git a/gcc/config/i386/cet.h b/gcc/config/i386/cet.h index 9dca41bad2d..309d90ec87c 100644 --- a/gcc/config/i386/cet.h +++ b/gcc/config/i386/cet.h @@ -33,12 +33,14 @@ #ifdef __ASSEMBLER__ # ifdef __IBT__ +# define _CET_NOTRACK notrack # ifdef __x86_64__ # define _CET_ENDBR endbr64 # else # define _CET_ENDBR endbr32 # endif # else +# define _CET_NOTRACK # define _CET_ENDBR # endif diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S index 99e65eaaff4..c0cda479806 100644 --- a/libgcc/config/i386/morestack.S +++ b/libgcc/config/i386/morestack.S @@ -543,7 +543,7 @@ __morestack: movq-16(%rbp),%rax # Restore caller's %rax. - call*%r10 # Call our caller! + _CET_NOTRACK call *%r10 # Call our caller! # The caller will return here, as predicted.
[Bug libgcc/85388] New: config/i386/morestack.S is incompatible with CET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85388 Bug ID: 85388 Summary: config/i386/morestack.S is incompatible with CET Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Blocks: 81652 Target Milestone: --- Target: x86_64-*-*, i?86-*-* config/i386/morestack.S has movq-16(%rbp),%rax # Restore caller's %rax. call*%r10 # Call our caller! Missing notrack prefix. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The sanitizers insert a lot of instrumentation, and some of it interferes with GCC warnings. The usual recommendation is to use either sanitization or middle-end warnings but not both. (This is obviously suboptimal and it would be ideal to have both, but it's not always possible.) Much of the instrumentation the sanitizers insert is, of course, necessary to detect bugs and runtime, but some is not (e.g., some of those in bug 79265) and could be removed to avoid some of the false positives with no loss of efficacy (and make the code run faster). The output of the sanitizer for the first function shows a couple of these unnecessary tests (I don't know if avoiding the would prevent the warning; it's issued while running the VRP pass): t1 (char * g) { int c.1_1; char * _2; char * _3; long unsigned int _4; int _5; char[] * iftmp.0_6; char[] * iftmp.0_8; char[] * iftmp.0_9; : c.1_1 = c; if (c.1_1 != 0) goto ; [INV] else goto ; [INV] : iftmp.0_8 = &b; goto ; [INV] : iftmp.0_9 = &a; : # iftmp.0_6 = PHI UBSAN_PTR (g_10(D), 4); _2 = g_10(D) + 4; if (_2 == 0B) goto ; [0.05%] else goto ; [99.95%] : __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0); : if (iftmp.0_6 == 0B)<<< unnecessary (neither &a nor &b can be null) goto ; [0.05%] else goto ; [99.95%] : __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1); : strcpy (_2, iftmp.0_6); UBSAN_PTR (g_10(D), 4); _3 = g_10(D) + 4; if (_3 == 0B)<<< redundant (already checked in bb 5 goto ; [0.05%] else goto ; [99.95%] : __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2); : _4 = strlen (_3); _5 = (int) _4; e = _5; return; }
[Bug c++/85112] [8 Regression] ICE with invalid constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85112 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Looking into it.
[Bug middle-end/85369] no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85369 Martin Sebor changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00649.html
[Bug c++/85385] [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85385 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by r259360.
[Bug c++/85385] [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85385 --- Comment #1 from David Malcolm --- Author: dmalcolm Date: Thu Apr 12 23:44:09 2018 New Revision: 259360 URL: https://gcc.gnu.org/viewcvs?rev=259360&root=gcc&view=rev Log: Prevent erroneous "macro had not yet been defined" messages (PR c++/85385) PR c++/85385 reports an issue where we emit bogus "macro had not yet been defined" notes when a macro is mis-used: $ cat test.c #define MACRO(X,Y) void test () { MACRO(42); } $ ./xg++ -B. -c test.c test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given MACRO(42); ^ test.c: In function ‘void test()’: test.c:5:3: error: ‘MACRO’ was not declared in this scope MACRO(42); ^ test.c:5:3: note: test.c:1: note: it was later defined here #define MACRO(X,Y) The macro *had* been defined, it was merely misused. This patch fixes the issue by only issuing the note if the use location is before the definition location (using linemap_location_before_p). gcc/cp/ChangeLog: PR c++/85385 * name-lookup.c (macro_use_before_def::maybe_make): New function, checking that the use is indeed before the definition. (macro_use_before_def::macro_use_before_def): Make private. (macro_use_before_def::~macro_use_before_def): Make private. Move check for UNKNOWN_LOCATION to macro_use_before_def::maybe_make. (lookup_name_fuzzy): Call macro_use_before_def::maybe_make rather than using new directly. gcc/testsuite/ChangeLog: PR c++/85385 * g++.dg/diagnostic/macro-arg-count.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/macro-arg-count.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/85387] New: incorrect output with optimization /= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85387 Bug ID: 85387 Summary: incorrect output with optimization /= 0 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu ! incorrect output with optimization /= 0 ! on trunk 259205 real efg_pw(2,2) efg_pw(1,1)=1 efg_pw(2,1)=2 efg_pw(1,2)=3 efg_pw(2,2)=4 ! with optimization /= 0 displays nothing print *,((efg_pw(i, j), i=1, j), j=1, 2) !should display 1. 3. 4. end
[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85346 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Fixed, closing.
[Bug target/83660] ICE with vec_extract inside expression statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org
[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85346 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Thu Apr 12 21:58:54 2018 New Revision: 259359 URL: https://gcc.gnu.org/viewcvs?rev=259359&root=gcc&view=rev Log: 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind for annotation and remove dependence on -ftree-parallelize-loops. 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * gfortran.dg/do_concurrent_5.f90: Dynamically allocate main work array and move test to libgomp/testsuite/libgomp.fortran. * gfortran.dg/do_concurrent_6.f90: New test. 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * testsuite/libgomp.fortran/do_concurrent_5.f90: Move modified test from gfortran.dg to here. Added: trunk/gcc/testsuite/gfortran.dg/do_concurrent_6.f90 trunk/libgomp/testsuite/libgomp.fortran/do_concurrent_5.f90 Removed: trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog
[Bug fortran/83064] DO CONCURRENT and auto-parallelization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 --- Comment #29 from Thomas Koenig --- Author: tkoenig Date: Thu Apr 12 21:58:54 2018 New Revision: 259359 URL: https://gcc.gnu.org/viewcvs?rev=259359&root=gcc&view=rev Log: 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind for annotation and remove dependence on -ftree-parallelize-loops. 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * gfortran.dg/do_concurrent_5.f90: Dynamically allocate main work array and move test to libgomp/testsuite/libgomp.fortran. * gfortran.dg/do_concurrent_6.f90: New test. 2018-04-12 Thomas Koenig PR fortran/83064 PR testsuite/85346 * testsuite/libgomp.fortran/do_concurrent_5.f90: Move modified test from gfortran.dg to here. Added: trunk/gcc/testsuite/gfortran.dg/do_concurrent_6.f90 trunk/libgomp/testsuite/libgomp.fortran/do_concurrent_5.f90 Removed: trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog
[Bug target/83660] ICE with vec_extract inside expression statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83660 acsawdey at gcc dot gnu.org changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #11 from acsawdey at gcc dot gnu.org --- Looking at the dump of an analogous test case for vec_insert: #include typedef __vector unsigned int uvec32_t __attribute__((__aligned__(16))); uvec32_t get_word(uvec32_t v) { return({const unsigned _B1 = 32; vec_insert(10, (uvec32_t)v, 2);}); } It seems that we do get an additional cleanup_point like you are proposing to add for vec_extract, which is maybe why that does not get into trouble: ;; Function __vector(4) unsigned int get_word(__vector(4) unsigned int) (null) ;; enabled by -tree-original { < = { const unsigned int _B1 = 32; <>; <> + 8) = 10;, D.3231>>; }>>; } I've gotten as far as seeing that something is calling fold_build_cleanup_point_expr an additional time compared to the vec_extract example.
[Bug fortran/85364] -fopenmp should not put array in program on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85364 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #4 from Harald Anlauf --- (In reply to Jakub Jelinek from comment #3) > If it is about variables in MAIN__ and not say variables inside of BLOCK > inside of MAIN__, then perhaps. For BLOCK, I wonder about stuff like: > !$omp parallel > block > integer :: i > i = ... > use (i) > end block > !$omp end parallel > end > and similar, where the implicit SAVE would be undesirable. The OpenMP data sharing rules are quite clear about this, even if they do not mention Fortran BLOCK explicitly: E.g. TR6, 2.20.1.2: Local variables declared in called routines in the region and that have the save attribute, or that are data initialized, are shared unless they appear in a threadprivate directive.
[Bug fortran/85364] -fopenmp should not put array in program on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85364 --- Comment #3 from Jakub Jelinek --- If it is about variables in MAIN__ and not say variables inside of BLOCK inside of MAIN__, then perhaps. For BLOCK, I wonder about stuff like: !$omp parallel block integer :: i i = ... use (i) end block !$omp end parallel end and similar, where the implicit SAVE would be undesirable.
[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r180965.
[Bug fortran/85364] -fopenmp should not put array in program on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85364 Thomas Koenig changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Thomas Koenig --- (In reply to Jakub Jelinek from comment #1) > -fopenmp just implies -frecursive and has to, because the OpenMP semantics > requires it. > Does fortran guarantee that MAIN__ can't be invoked more than once? Yes, it is not possible (from the language) to call a main program. > If so, > perhaps MAIN__ could be special-cased for -frecursive, you'd need to update > the docs too. There would be no way to force automatic variables in MAIN__ > though if the user wants it for some reason (you can't mark MAIN__ > RECURSIVE). Since F2008, all variables in the main program have the SAVE attribute anyway (F2008, 5.3.16, para 4). Earlier versions left this unspecified; in F2003, the standard says "The SAVE attribute may appear in declarations in a main program and has no effect." which makes sense because there is no way the user can tell the difference except by using valgrind on allocatable arrays. So (methinks) we should be safe making those SAVEd as well.
[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85359 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00639.html
[Bug c++/85386] ICE when applying noexcept operator to default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85386 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed by r257713.
[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85384 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00638.html
[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365 --- Comment #2 from Marek Polacek --- We warn because we see strcpy (0B, 0B); created by jump threading (in a BB that is not reachable).
[Bug c++/85386] ICE when applying noexcept operator to default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85386 --- Comment #1 from andysem at mail dot ru --- Apparently, the is_nothrow_default_constructible workaround doesn't work reliably either, at least not in the full code base from which this testcase was reduced.
[Bug c++/85386] New: ICE when applying noexcept operator to default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85386 Bug ID: 85386 Summary: ICE when applying noexcept operator to default constructor Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andysem at mail dot ru Target Milestone: --- Created attachment 43923 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43923&action=edit A testcase that shows the problem. The following testcase causes ICE: template< typename T > class allocator { }; template< typename T > struct is_ebo_possible { static constexpr bool value = true; }; template< typename Char, typename Allocator, bool = is_ebo_possible< Allocator >::value > struct ebo { typedef Allocator allocator_type; allocator_type m_allocator; // ebo() noexcept(std::is_nothrow_default_constructible< allocator_type >::value) = default; ebo() noexcept(noexcept(allocator_type())) = default; }; template< typename Char, typename Allocator > struct ebo< Char, Allocator, true > : public Allocator { typedef Allocator allocator_type; ebo() noexcept(noexcept(allocator_type())) = default; }; int main() { ebo< char, allocator< char > > m; return 0; } $ g++ -o noexcept_def_ctor_test noexcept_def_ctor_test.cpp noexcept_def_ctor_test.cpp: In instantiation of ‘ebo::ebo() [with Char = char; Allocator = allocator]’: noexcept_def_ctor_test.cpp:24:8: required from ‘struct ebo >’ noexcept_def_ctor_test.cpp:34:36: required from here noexcept_def_ctor_test.cpp:20:29: internal compiler error: Segmentation fault ebo() noexcept(noexcept(allocator_type())) = default; ^~~~ This happens with gcc 7.2 but not 6.4. If I replace the noexcept operator with the is_nothrow_default_constructible trait as in the commented line, ICE doesn't happen. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)
[Bug c/85365] -Wrestrict false positives with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/85356] [7 Regression] ICE with operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85356 --- Comment #2 from Jason Merrill --- Author: jason Date: Thu Apr 12 20:03:33 2018 New Revision: 259356 URL: https://gcc.gnu.org/viewcvs?rev=259356&root=gcc&view=rev Log: PR c++/85356 - ICE with pointer to member function. * pt.c (maybe_instantiate_noexcept): Do instantiate in templates if flag_noexcept_type. Build the new spec within the function context. * except.c (build_noexcept_spec): Do get constant value in templates if flag_noexcept_type. * decl.c (check_redeclaration_exception_specification): Don't instantiate noexcept on a dependent declaration. Added: trunk/gcc/testsuite/g++.dg/template/mem_func_ptr2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/except.c trunk/gcc/cp/pt.c
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Apr 12 20:02:47 2018 New Revision: 259355 URL: https://gcc.gnu.org/viewcvs?rev=259355&root=gcc&view=rev Log: PR c++/85258 * constexpr.c (reduced_constant_expression_p): Return false for null trees. * g++.dg/parse/error61.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/error61.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug target/85291] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Thu Apr 12 20:01:37 2018 New Revision: 259354 URL: https://gcc.gnu.org/viewcvs?rev=259354&root=gcc&view=rev Log: rs6000: Fix an ICE with -mno-direct-move (PR85291) PR target/85291 * config/rs6000/rs6000.md (fix_truncsi2): Use legacy code if asked to not generate direct moves. (fix_truncsi2_stfiwx): Similar. (fix_truncsi2_internal): Similar. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug target/85291] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85291 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Segher Boessenkool --- Fixed.
[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381 cesar at gcc dot gnu.org changed: What|Removed |Added CC||cesar at gcc dot gnu.org --- Comment #1 from cesar at gcc dot gnu.org --- Strange. It passes for me using my GeForce 1070 running Nvidia driver 390.48.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED Target Milestone|6.5 |8.0 --- Comment #19 from Jakub Jelinek --- Fixed for 8+, not going to backport.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Thu Apr 12 19:30:00 2018 New Revision: 259353 URL: https://gcc.gnu.org/viewcvs?rev=259353&root=gcc&view=rev Log: PR debug/83157 * var-tracking.c (add_stores): Handle STRICT_LOW_PART SET_DEST. * cselib.c (cselib_record_sets): For STRICT_LOW_PART dest, lookup if dest in some wider mode is known to be const0_rtx and if so, record permanent equivalence for it to be ZERO_EXTEND of the narrower mode destination. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c trunk/gcc/var-tracking.c
[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Bug 66145 depends on bug 85222, which changed state. Bug 85222 Summary: [7 Regression] ABI breakage of __throw_ios_failure by r244498 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/85222] [7 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jonathan Wakely --- Fixed for 7.4 and 8.1
[Bug libstdc++/85222] [7 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #22 from Jonathan Wakely --- Author: redi Date: Thu Apr 12 19:06:50 2018 New Revision: 259352 URL: https://gcc.gnu.org/viewcvs?rev=259352&root=gcc&view=rev Log: PR libstdc++/85222 allow catching iostream errors as gcc4-compatible ios::failure Define a new exception type derived from std::ios::failure[abi:cxx11] which also aggregates an object of the gcc4-compatible ios::failure type. Make __throw_ios_failure throw this new type for iostream errors that raise exceptions. Provide custom type info for the new type so that it can be caught by handlers for the gcc4-compatible ios::failure type as well as handlers for ios::failure[abi:cxx11] and its bases. Backport from mainline 2018-04-10 Jonathan Wakely PR libstdc++/85222 * src/c++11/Makefile.am [ENABLE_DUAL_ABI]: Add special rules for cxx11-ios_failure.cc to rewrite type info for __ios_failure. * src/c++11/Makefile.in: Regenerate. * src/c++11/cxx11-ios_failure.cc (__ios_failure, __iosfail_type_info): New types. [_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here. * src/c++11/ios.cc (__throw_ios_failure): Remove definition. (_GLIBCXX_USE_CXX11_ABI): Don't define here. * src/c++98/ios_failure.cc (__construct_ios_failure) (__destroy_ios_failure, is_ios_failure_handler): New functions. [!_GLIBCXX_USE_DUAL_ABI] (__throw_ios_failure): Define here. * testsuite/27_io/ios_base/failure/dual_abi.cc: New. * testsuite/27_io/basic_ios/copyfmt/char/1.cc: Revert changes to handler types, to always catch std::ios_base::failure. * testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise. * testsuite/27_io/basic_istream/extractors_arithmetic/char/ exceptions_failbit.cc: Likewise. * testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/ exceptions_failbit.cc: Likewise. * testsuite/27_io/basic_istream/extractors_other/char/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_istream/extractors_other/wchar_t/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise. * testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_other/char/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_other/wchar_t/ exceptions_null.cc: Likewise. * testsuite/27_io/ios_base/storage/2.cc: Likewise. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.am branches/gcc-7-branch/libstdc++-v3/src/c++11/Makefile.in branches/gcc-7-branch/libstdc++-v3/src/c++11/cxx11-ios_failure.cc branches/gcc-7-branch/libstdc++-v3/src/c++11/ios.cc branches/gcc-7-branch/libstdc++-v3/src/c++98/ios_failure.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc
[Bug c++/85385] New: [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85385 Bug ID: 85385 Summary: [8 Regression] Bogus "macro had not yet been defined" message when macro used with wrong arg count Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- $ cat test.c #define MACRO(X,Y) void test () { MACRO(42); } $ ./xg++ -B. -c test.c test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given MACRO(42); ^ test.c: In function ‘void test()’: test.c:5:3: error: ‘MACRO’ was not declared in this scope MACRO(42); ^ test.c:5:3: note: test.c:1: note: it was later defined here #define MACRO(X,Y) We shouldn't emit the note "the macro ‘MACRO’ had not yet been defined" for cases like these: the macro *had* been defined.
[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85359 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85369 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I'm testing a fix for this. See also bug 85369 for a related problem.
[Bug middle-end/85369] no -Wstringop-overflow for a strcpy / stpcpy call with a nonstring pointer when providing movstr pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85369 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. A small standalone test case is below shwoing that an x86_64 GCC issues the expected warning but the s360-linux one doesn't. $ (set -x && cat pr85369.c && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S -Wall pr85369.c && /ssd/build/s390-linux/gcc-git/gcc/xgcc -B /ssd/build/s390-linux/gcc-git/gcc -O2 -S -Wall pr85369.c) + cat pr85369.c char* g (char *d, __attribute__ ((nonstring)) const char *s) { return __builtin_stpcpy (d, s); } + /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S -Wall pr85369.c pr85369.c: In function ‘g’: pr85369.c:3:10: warning: ‘__builtin_stpcpy’ argument 2 declared attribute ‘nonstring’ [-Wstringop-overflow=] return __builtin_stpcpy (d, s); ^~~ pr85369.c:1:59: note: argument ‘s’ declared here char* g (char *d, __attribute__ ((nonstring)) const char *s) ^ + /ssd/build/s390-linux/gcc-git/gcc/xgcc -B /ssd/build/s390-linux/gcc-git/gcc -O2 -S -Wall pr85369.c
[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84955 --- Comment #6 from cesar at gcc dot gnu.org --- I reverted that patch from trunk, and will revisit this issue during stage1. It should be noted that GCC also chokes with any empty OpenACC loop in general.
[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85383 --- Comment #3 from cesar at gcc dot gnu.org --- I ended up reverting the patch in r259351. It should be working now.
[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85383 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #2 from Steve Ellcey --- This looks like the same bug I am seeing on Aarch64 with the SPEC 2017 510.parest_r benchmark. I am compiling it with -Ofast -flto=32 -mcpu=native on a T99.
[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85384 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- gcc_get_base_ver is meant for uses in Makefiles (which is why it uses $$), so it can't be easily used in a shell script.
[Bug jit/85384] libgccjit does not work if --with-gcc-major-version is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85384 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Target Milestone|--- |7.4 Ever confirmed|0 |1
[Bug jit/85384] New: libgccjit does not work if --with-gcc-major-version is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85384 Bug ID: 85384 Summary: libgccjit does not work if --with-gcc-major-version is used Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- As noted in this downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1566178 libgccjit does not honor --with-gcc-major-version. Specifically, gcc/configure.ac does not use get_gcc_base_ver when generating gcc-driver-name.h, hence GCC_DRIVER_NAME contains the wrong value when --with-gcc-major-version is used. This leads to link errors as reported in that bug, when using the default embedded driver, and to the driver not being found when using: gcc_jit_context_set_bool_use_external_driver (ctxt, 1); Affects trunk and gcc-7-branch. I'm about to submit a candidate fix.
[Bug middle-end/85383] [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85383 --- Comment #1 from cesar at gcc dot gnu.org --- I'm building a power8 toolchain right now. If the fix isn't immediately obvious, I'll revert that patch for pr84955. After all, empty loops are uninteresting in OpenACC.
[Bug middle-end/85383] New: [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85383 Bug ID: 85383 Summary: [8 regression] many ICE failures at gcc/toplev.c:325 starting with r259346 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- See this on powerpc64 both LE and BE. One example: spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/covariant-1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -flto -fno-use-linker-plugin -flto-partition=none -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/.libs -lm -o ./covariant-1.exe during IPA pass: pure-const /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/covariant-1.C:33:1: internal compiler error: Segmentation fault 0x10c0b7cb crash_signal /home/seurer/gcc/gcc-test2/gcc/toplev.c:325 0x10a00288 loop_optimizer_init(unsigned int) /home/seurer/gcc/gcc-test2/gcc/loop-init.c:88 0x10a6408f output_function /home/seurer/gcc/gcc-test2/gcc/lto-streamer-out.c:2088 0x10a6408f lto_output() /home/seurer/gcc/gcc-test2/gcc/lto-streamer-out.c:2423 0x10aee8b3 write_lto /home/seurer/gcc/gcc-test2/gcc/passes.c:2610 0x10af4117 ipa_write_summaries_1 /home/seurer/gcc/gcc-test2/gcc/passes.c:2674 0x10af4117 ipa_write_summaries() /home/seurer/gcc/gcc-test2/gcc/passes.c:2734 0x106b785b ipa_passes /home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2468 0x106b785b symbol_table::compile() /home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2558 0x106ba78f symbol_table::compile() /home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2537 0x106ba78f symbol_table::finalize_compilation_unit() /home/seurer/gcc/gcc-test2/gcc/cgraphunit.c:2717 List of failures: > FAIL: g++.dg/ipa/pr46984.C -std=gnu++11 (internal compiler error) > FAIL: g++.dg/ipa/pr46984.C -std=gnu++11 (test for excess errors) > FAIL: g++.dg/ipa/pr46984.C -std=gnu++14 (internal compiler error) > FAIL: g++.dg/ipa/pr46984.C -std=gnu++14 (test for excess errors) > FAIL: g++.dg/ipa/pr46984.C -std=gnu++98 (internal compiler error) > FAIL: g++.dg/ipa/pr46984.C -std=gnu++98 (test for excess errors) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto > -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto > -flto-partition=none -fuse-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O0 -flto > -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto > -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto > -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects (internal > compiler error) > FAIL: g++.dg/lto/20081217-1 cp_lto_20081217-1_0.o assemble, -O2 -flto > -fuse-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto > -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto > -flto-partition=none -fuse-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O0 -flto > -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto > -flto-partition=1to1 -fno-use-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto > -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects (internal > compiler error) > FAIL: g++.dg/lto/20081217-2 cp_lto_20081217-2_0.o assemble, -O2 -flto > -fuse-linker-plugin (internal compiler error) > FAIL: g++.dg/lto/20081219 cp_lto_
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #20 from Jakub Jelinek --- Are you configuring gcc against binutils 2.30+ and then assembling stuff with older binutils? You can always use -gno-as-locview-support even in that case, but the general assumption is if you configure against some gas/ld version then you use that or newer version when using the compiler.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #19 from Dmitry Vyukov --- When I am trying to build anything with -g on a machine with binutils 2.26.1 I am getting: /tmp/ccTFsPnM.s: Assembler messages: /tmp/ccTFsPnM.s:11: Error: unknown .loc sub-directive `view' /tmp/ccTFsPnM.s:11: Error: junk at end of line, first unrecognized character is `-' /tmp/ccTFsPnM.s:13: Error: unknown .loc sub-directive `view' /tmp/ccTFsPnM.s:13: Error: unknown pseudo-op: `.lvu1' /tmp/ccTFsPnM.s:14: Error: unknown .loc sub-directive `view' /tmp/ccTFsPnM.s:14: Error: unknown pseudo-op: `.lvu2' /tmp/ccTFsPnM.s:18: Error: unknown .loc sub-directive `view' But this works on machine with binutils 2.30. The previous version of gcc 8 that I built a month ago worked on the machine with binutils 2.26.1. Am I doing something wrong? Is there a workaround?
[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85347 kelvin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from kelvin at gcc dot gnu.org --- Patch committed to trunk.
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 --- Comment #2 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > My patch doesn't fix g++.dg/eh/sighandle.C compiled with > > -O2 -fcf-protection -mcet It is because (gdb) bt #0 _Unwind_RaiseException (exc=exc@entry=0x416ed0) at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:141 #1 0x77d983db in __cxxabiv1::__cxa_throw (obj=obj@entry=0x416ef0, tinfo=0x403dd0 , dest=dest@entry=0x0) at /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90 #2 0x004010cf in sighandler (signo=, si=, uc=) #3 #4 dosegv () at x.cc:36 < This is inlined and isn't on shadow stack. #5 main () at x.cc:36 #6 0x77990433 in __libc_start_main () from /lib64/libc.so.6 #7 0x004011be in _start () at x.cc:36
[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 --- Comment #3 from Dominique d'Humieres --- gfortran 4.8.2 gives ... Error: Non-polymorphic passed-object dummy argument of 'summation' at (1)
[Bug middle-end/85382] New: code compiled with fno-builtin uses builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85382 Bug ID: 85382 Summary: code compiled with fno-builtin uses builtin Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: konstantin.vladimirov at gmail dot com Target Milestone: --- Minimized reproduction: double a, b; void f() { a = b * b * (628972 + b - 628972); } Compile with: gcc -msse4 -ffast-math -Os -S minimize.c -fno-builtin -ffreestanding Remove fast-math to kill reproduction. Assembler: f: .LFB0: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movl$3, %edi movsd b(%rip), %xmm0 call__powidf2 movsd %xmm0, a(%rip) popq%rax .cfi_def_cfa_offset 8 ret Compiler version: Target: x86_64-suse-linux Thread model: posix gcc version 7.2.0 (GCC)
[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from at least gcc 4.8.5 up to trunk (8.0).
[Bug target/84369] test case gcc.dg/sms-10.c fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 CC||bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Peter Bergner --- Confirmed. Looking at the rtl dumps, the only difference coming into SMS, is the following (due to combine): -(insn 25 23 26 4 (set (reg:DI 150 [ iD.2875+-4 ]) -(sign_extend:DI (subreg/v:SI (reg/v:DI 137 [ iD.2875+-4 ]) 4))) "/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33 38 {extendsidi2} - (nil)) +(note 25 23 26 4 NOTE_INSN_DELETED) (insn 26 25 28 4 (set (reg:DI 151) -(ashift:DI (reg:DI 150 [ iD.2875+-4 ]) -(const_int 3 [0x3]))) "/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33 270 {ashldi3} - (expr_list:REG_DEAD (reg:DI 150 [ iD.2875+-4 ]) -(nil))) +(ashift:DI (sign_extend:DI (subreg:SI (reg/v:DI 137 [ iD.2880+-4 ]) 4)) +(const_int 3 [0x3]))) "/home/bergner/gcc/gcc-fsf-mainline-mcpu-native/gcc/testsuite/gcc.dg/sms-10.c":33 276 {ashdi3_extswsli} + (nil)) ...and the ashdi3_extswsli pattern is only enabled with power9. Not sure yet why the above disables SMS, but will keep looking.
[Bug testsuite/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85190 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Should be fixed now.
[Bug rtl-optimization/79916] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916 --- Comment #9 from Vladimir Makarov --- I've reproduced one test bug on my machine by using: ./cc1 -I. ../../gcc/gcc/testsuite/gcc.dg/dfp/pr41049.c -fno-expensive-optimizations --param ira-max-conflict-table-size=0 -mpopcntd -O3 I think the fix can be probably in rs6000 machine-dependent code related to LRA and fixing it needs to know LRA very well. So I'll be working on it.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 43922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43922&action=edit gcc8-pr85376.patch The problem is that cse.c (fold_rtx) uses simplify_unary_operation and that contains stuff like: else if (! CLZ_DEFINED_VALUE_AT_ZERO (imode, int_value)) int_value = GET_MODE_PRECISION (imode); That is fine in some optimization passes, where we just want some value for the expression, but not in cse, where we want to record that some register has this constant value and then optimize other uses of the same constant, canonicalizing to that register. Of course, when the value is not defined for zero, the register contains some random value, not the constant we've computed. So, either we can do what the patch does, or punt instead of returning GET_MODE_PRECISION in simplify-rtx.c.
[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85347 --- Comment #2 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Thu Apr 12 16:16:08 2018 New Revision: 259350 URL: https://gcc.gnu.org/viewcvs?rev=259350&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-04-12 Kelvin Nilsen PR target/85347 * gcc.target/powerpc/vec-ldl-1.c: Change dejagnu directives to specify -mvsx on gcc command line. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/vec-ldl-1.c
[Bug fortran/85357] gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357 c...@mnet-mail.de changed: What|Removed |Added Summary|Regression: gfortran|gfortran versions |versions 7.2.0/8.0.1 reject |7.2.0/8.0.1 reject F03 |F03 procedure overriding|procedure overriding --- Comment #1 from c...@mnet-mail.de --- Can't actually vouch for gfortran 7.1 being able to compile this, as I no longer have access to that gfortran version, so I changed the title (might still be a regression, though). Also, when replacing the line: use base by use base, only: base_type the code compiles with both gfortran 7.2.0 and 8.0.1.
[Bug rtl-optimization/84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 Bug 84659 depends on bug 85354, which changed state. Bug 85354 Summary: [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Blocks||84659 Resolution|--- |FIXED --- Comment #5 from Alexander Monakov --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84659 [Bug 84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling
[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 --- Comment #4 from Alexander Monakov --- Author: amonakov Date: Thu Apr 12 15:40:44 2018 New Revision: 259348 URL: https://gcc.gnu.org/viewcvs?rev=259348&root=gcc&view=rev Log: sel-sched: move cleanup_cfg before calculate_dominance_info (PR 85354) PR rtl-optimization/85354 * sel-sched-ir.c (sel_init_pipelining): Move cfg_cleanup call... * sel-sched.c (sel_global_init): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/sel-sched.c
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #7 from Paolo Carlini --- For the remaining error-recovery issue, loosening a bit the assertion would be enough - see below - I don't know if we want to dig deeper... Opinions? Index: name-lookup.c === --- name-lookup.c (revision 259340) +++ name-lookup.c (working copy) @@ -2052,7 +2052,7 @@ pop_local_binding (tree id, tree decl) binding->value = NULL_TREE; else { - gcc_assert (binding->type == decl); + gcc_assert (!binding->type || binding->type == decl); binding->type = NULL_TREE; }
[Bug target/85381] New: [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85381 Bug ID: 85381 Summary: [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- When running parallel-loop-1.c with this patch, it hangs: ... diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c index 4bc71415688..5e7adcb4340 100644 --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c @@ -1,4 +1,5 @@ /* { dg-do run } */ +/* { dg-additional-options "-fopenacc-dim=::128" } */ #include ...
[Bug fortran/83064] DO CONCURRENT and auto-parallelization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #28 from Christophe Lyon --- (In reply to Thomas Koenig from comment #27) > > 2018-04-09 Thomas Koenig > > PR fortran/83064 > * gfortran.dg/do_concurrent_5.f90: New test. Hi, I think the testcase is probably missing a require-effective-target, because I see it failing on aarch64/arm with this error message: gfortran: error: libgomp.spec: No such file or directory
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|ktietz at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #26 from Eric Botcazou --- This should work now.
[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238 --- Comment #25 from Eric Botcazou --- Author: ebotcazou Date: Thu Apr 12 14:18:17 2018 New Revision: 259347 URL: https://gcc.gnu.org/viewcvs?rev=259347&root=gcc&view=rev Log: PR target/85238 * lto-wrapper.c (debug_objcopy): Open the files in binary mode. * dwarf2out.c (dwarf2out_early_finish): Do not generate assembly in LTO mode for PE-COFF targets. * config/i386/i386-protos.h (i386_pe_asm_lto_start): Declare. (i386_pe_asm_lto_end): Likewise. * config/i386/cygming.h (TARGET_ASM_LTO_START): Define. (TARGET_ASM_LTO_END): Likewise. * config/i386/winnt.c (saved_debug_info_level): New static variable. (i386_pe_asm_lto_start): New function. (i386_pe_asm_lto_end): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/dwarf2out.c trunk/gcc/lto-wrapper.c
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 Tom de Vries changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom de Vries --- Patch committed, marking resolved-fixed
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #18 from Jakub Jelinek --- I will, once I bootstrap/regtest it fully on a couple of targets.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #17 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #15) > (In reply to chefmax from comment #14) > > (In reply to Jakub Jelinek from comment #13) > > > or introduce a new virtual pseudo register that vregs pass would map > > > directly to dynamic_offset. > > > > Yeah, that's what I though about (LLVM does pretty the same thing). But > > (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an > > appropriate solution too. I'll cover the testing for both approaches. > > The above patch passed > make -j16 -k check-gcc check-g++ > RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp=alloca*' > on x86_64-linux and powerpc64-linux and without the -m32, part also on > powerpc64le-linux. Nice! Jakub, would you post the patch in ML?
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 --- Comment #11 from seurer at gcc dot gnu.org --- I dug through my logs and the last failures I saw for phi-opt-11.c and pr21643.c on powerpc64 were in mid January immediately before Eric's patch.
[Bug ada/85380] New: gnatbind fails with small executable & restricted runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85380 Bug ID: 85380 Summary: gnatbind fails with small executable & restricted runtime Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Host: x86_64-apple-darwin15 Target: arm-eabi Build: x86_64-apple-darwin15 After following the change suggested in PR ada/66205 comment 14, System.Suppress_Standard_Library set to False, I attempted to build a small program and got the error b__generate_hard_fault.adb:62:44: "Parameters" not declared in "System" gprbind: compilation of binder generated file failed This line is Default_Secondary_Stack_Size : System.Parameters.Size_Type; pragma Import (C, Default_Secondary_Stack_Size, "__gnat_default_ss_size"); and in successful builds of other programs System.Parameters is withed (in the spec; why not in the body?). On investigating, I find that none of the units in the closure required the secondary stack (the P lines didn’t contain 'SS'); this means that Opt.Sec_Stack_Used is False. The 'with System.Parameters;' line is generated at bindgen.adb:2286 if Opt.Sec_Stack_Used is True. If Suppress_Standard_Library_On_Target is False, the 'Default_Secondary_Stack_Size' line is generated unconditionally at bindgen.adb:748. Proposed solution: make generation of the 'with System.Parameters;' line conditional on (Opt.Sec_Stack_Used or not Suppress_Standard_Library_On_Target). Proposed alternative solution: make generation of the 'Default_Secondary_Stack_Size' and related lines at bindgen.adb:748 conditional on Opt.Sec_Stack_Used. I think this would need a lot more thought to make sure it was OK in all circumstances.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The bug seems to be introduced during cse_local, before that we have: (insn 28 26 31 2 (parallel [ (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 188) (const_int 0 [0]))) (set (reg:SI 93 [ _13 ]) (ctz:SI (reg:SI 188))) ]) "pr85376.c":12 735 {*bsfsi_1} (expr_list:REG_DEAD (reg:SI 188) (expr_list:REG_UNUSED (reg:SI 93 [ _13 ]) (expr_list:REG_UNUSED (reg:CCZ 17 flags) (nil) ... (insn 55 54 56 2 (set (reg:SI 194 [ o ]) (const_int 32 [0x20])) "pr85376.c":14 86 {*movsi_internal} (expr_list:REG_DEAD (reg/v:HI 91 [ o ]) (nil))) (insn 56 55 57 2 (set (reg:QI 108 [ _26+1 ]) (const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal} (nil)) (insn 57 56 58 2 (parallel [ (set (reg:CC 17 flags) (compare:CC (subreg:QI (reg:SI 194 [ o ]) 0) (subreg:QI (reg:SI 104 [ _23 ]) 0))) (set (reg:QI 195) (minus:QI (subreg:QI (reg:SI 194 [ o ]) 0) (subreg:QI (reg:SI 104 [ _23 ]) 0))) ]) "pr85376.c":14 294 {*subqi_3} (expr_list:REG_DEAD (reg:SI 194 [ o ]) (expr_list:REG_DEAD (reg:SI 104 [ _23 ]) (nil But cse_local changes that to: (insn 56 54 57 2 (set (reg:QI 108 [ _26+1 ]) (const_int 0 [0])) "pr85376.c":14 88 {*movqi_internal} (nil)) (insn 57 56 58 2 (parallel [ (set (reg:CC 17 flags) (compare:CC (subreg:QI (reg:SI 93 [ _13 ]) 0) (subreg:QI (reg:SI 104 [ _23 ]) 0))) (set (reg:QI 195) (minus:QI (subreg:QI (reg:SI 93 [ _13 ]) 0) (subreg:QI (reg:SI 104 [ _23 ]) 0))) ]) "pr85376.c":14 294 {*subqi_3} (expr_list:REG_DEAD (reg:SI 194 [ o ]) (expr_list:REG_DEAD (reg:SI 104 [ _23 ]) (nil but pseudo 93 certainly isn't known to contain (const_int 32). I don't think cse pass uses cselib though.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #5 from Jakub Jelinek --- There is nothing weird about what cprop1 does, __builtin_ffs (0) is known to be 0, with so many disabled optimizations we just don't optimize it away nor simplify earlier. So the mov eax, 0 # tmp201, bsf edx, eax# _28, tmp201 mov ecx, -16# tmp204, add eax, ecx# tmp203, tmp204 part is just fine, we replaced the edx in the addition with eax which is known to hold the same value, and because DCE is disabled nothing removes the dead bsf.
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug gcov-profile/85377] [GCOV] Wrong coverage with label and if(cond) break in while(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85377 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84955 --- Comment #5 from cesar at gcc dot gnu.org --- Author: cesar Date: Thu Apr 12 13:15:45 2018 New Revision: 259346 URL: https://gcc.gnu.org/viewcvs?rev=259346&root=gcc&view=rev Log: PR middle-end/84955 gcc/ * lto-streamer-out.c (output_function): Fix CFG loop state before streaming out. * omp-expand.c (expand_oacc_for): Handle calls to internal functions like regular functions. libgomp/ * testsuite/libgomp.oacc-c-c++-common/pr84955.c: New test. * testsuite/libgomp.oacc-fortran/pr84955.f90: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c trunk/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/omp-expand.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/85379] New: Missing ENDBR in __stack_split_initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85379 Bug ID: 85379 Summary: Missing ENDBR in __stack_split_initialize Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Blocks: 81652 Target Milestone: --- Target: x86_64-*-*, i?86-*-* Program received signal SIGSEGV, Segmentation fault. __stack_split_initialize () at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751 751 leaq-16000(%rsp),%rax # We should have at least 16K. Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.0.1-0.21.0.fc28.x86_64 (gdb) disass Dump of assembler code for function __stack_split_initialize: => 0x00402858 <+0>: lea-0x3e80(%rsp),%rax 0x00402860 <+8>: mov%rax,%fs:0x70 0x00402869 <+17>:sub$0x8,%rsp 0x0040286d <+21>:mov%rsp,%rdi 0x00402870 <+24>:mov$0x3e80,%esi 0x00402875 <+29>:callq 0x401810 <__generic_morestack_set_initial_sp> 0x0040287a <+34>:add$0x8,%rsp 0x0040287e <+38>:retq End of assembler dump. (gdb) This diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S index eca441a2867..99e65eaaff4 100644 --- a/libgcc/config/i386/morestack.S +++ b/libgcc/config/i386/morestack.S @@ -730,6 +730,7 @@ __morestack_large_model: #endif __stack_split_initialize: + _CET_ENDBR #ifndef __x86_64__ fixes it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #16 from Dmitry Vyukov --- Here is disasm of the function with the patch: https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt And the epilogue: 8305fe5f: 48 8d 75 d8 lea-0x28(%rbp),%rsi 8305fe63: 48 89 e7mov%rsp,%rdi 8305fe66: e8 35 a9 ac fe callq 81b2a7a0 <__asan_allocas_unpoison> 8305fe6b: 44 89 f0mov%r14d,%eax 8305fe6e: 48 8b 4d d0 mov-0x30(%rbp),%rcx 8305fe72: 65 48 33 0c 25 28 00xor%gs:0x28,%rcx 8305fe79: 00 00 8305fe7b: 0f 85 5f 01 00 00 jne8305ffe0 8305fe81: 48 8d 65 d8 lea-0x28(%rbp),%rsp 8305fe85: 5b pop%rbx 8305fe86: 41 5c pop%r12 8305fe88: 41 5d pop%r13 8305fe8a: 41 5e pop%r14 8305fe8c: 41 5f pop%r15 8305fe8e: 5d pop%rbp 8305fe8f: c3 retq Kernel boots. So far I don't see these alloca-related false positives. If I see something suspicious I will post here, but otherwise consider that everything is good. Thanks!
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #4 from Richard Biener --- Thus looks like a cselib issue to me.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #3 from Richard Biener --- -fdisable-rtl-cprop2 -fdisable-rtl-cprop1 fixes it, likewise -fdisable-rtl-cse_local: > diff -u t.c.245r.cprop2 t.c.247r.cse_local ... - 41: r194:SI=0x20 - REG_DEAD r91:HI 42: r108:QI=0 - 43: {flags:CC=cmp(r194:SI#0,r104:SI#0);r195:QI=r194:SI#0-r104:SI#0;} + 43: {flags:CC=cmp(r93:SI#0,r104:SI#0);r195:QI=r93:SI#0-r104:SI#0;} huh.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85378, which changed state. Bug 85378 Summary: -fsplit-stack is incompatible with -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug target/85378] -fsplit-stack is incompatible with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- -fsplit-stack doesn't require gold linker, only if you want to build parts with -fsplit-stack and other parts without it and rely on the linker to fix it up, you need gold. So, emitting an error is just incorrect.
[Bug tree-optimization/85360] FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85360 --- Comment #2 from dave.anglin at bell dot net --- On 2018-04-12 3:43 AM, rguenth at gcc dot gnu.org wrote: > Any special > configury required? No.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #5 from Tom de Vries --- Created attachment 43921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43921&action=edit 0002-nvptx-Fix-propagation-of-branch-cond-in-vw-neutered-code.patch Tentative fix.
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #4 from Tom de Vries --- Created attachment 43920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43920&action=edit 0001-nvptx-Simplifly-logic-in-nvptx_single.patch NFC patch to make fix easier
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 --- Comment #2 from Jakub Jelinek --- Started with r257852.
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Known to work||7.3.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Should be fixed now.
[Bug target/85378] New: -fsplit-stack is incompatible with -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85378 Bug ID: 85378 Summary: -fsplit-stack is incompatible with -fcf-protection -mcet Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Blocks: 81652 Target Milestone: --- -fsplit-stack requires gold linker, which doesn't support GNU property required by Intel CET: https://sourceware.org/bugzilla/show_bug.cgi?id=22914 https://sourceware.org/bugzilla/show_bug.cgi?id=22915 It should be an error to use -fsplit-stack with -fcf-protection -mcet. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > I went through a couple of cycles of minimizing the failure, seeing > something suspicious, modifying by hand or writing a tentative patch, but > every time I went back to the original non-minimized example I got the > failure again. > > Anyway, things that may be causing this fail: > 2. > > The bar.sync instruction may not be sufficiently understood. > > In the documentation for bar.sync it says: > ... > bar.sync and bar.red also guarantee memory ordering among threads identical > to > membar.cta . Thus, threads within a CTA that wish to communicate via memory > can > store to memory, execute a bar.sync or bar.red instruction, and then safely > read > values stored by other threads prior to the barrier. > ... > > The question is what happens when you specify a thread count. Does the > memory ordering still apply to the whole CTA, or only to the threads > participating in the barrier? > > So if we store something in vector id 0, worker id 0, and load it in worker > id 1, we may have to use a bar.sync 0 instead to synchronize (or keep the > same barrier but add a membar.cta). I misanalyzed why the test was failing, it was not a barrier problem. There are two situations in which there is state propagation: 1. when transitioning from single to partition mode, for either worker or vector (so, when entering a partitioned loop) 2. when propagating branch conditions. [ We implement worker-single and vector-single by branch around, but do not branch around branches, so the branch condition is calculated in either W0V0 or WAV0 code, and then used in WAVA code. To go from worker single to worker partitioned (W0V0 -> WAV0), we use a generic broadcast buffer. To go from vector single to vector partitioned (WAV0 -> WAVA), we use a worker-specific broadcast buffer. To propagate the branch condition, we use the worker-specific broadcast buffer, but that only works for WAV0 -> WAVA. For the W0V0 -> WAVA propagation, we need to use the generic broadcast buffer.
[Bug target/85328] [8 Regression] accessing ymm16 with non-avx512 instruction form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85328 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug lto/85371] [8 Regression] Compiling code with -g -flto gives an ICE on darwin after revision r259317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85371 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Apr 12 12:27:14 2018 New Revision: 259345 URL: https://gcc.gnu.org/viewcvs?rev=259345&root=gcc&view=rev Log: 2018-04-12 Richard Biener PR lto/85371 * dwarf2out.c (init_sections_and_labels): Use debug_line_section[_label] for the early LTO debug to properly generate references to it during DIE emission. Do not re-use that for the skeleton for split-dwarf. (dwarf2out_early_finish): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/85246] [og7, nvptx, openacc] gemm.f90 fails with -mlong-vector-in-workers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85246 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #1) > I went through a couple of cycles of minimizing the failure, seeing > something suspicious, modifying by hand or writing a tentative patch, but > every time I went back to the original non-minimized example I got the > failure again. > > Anyway, things that may be causing this fail: > > 1. > > The og7 fix for PR85204 introduces a unified jump (bra.uni) for a jump > conditional consisting of a test for vector id == 0 && worker id == 0. The > fact that we're going a different direction in worker id 0 for vector id 0 > and vector id 1 means the branch diverges, and is _not_ unified. It seems > prudent to fix this by reverting the og7 fix and backporting the trunk fix. Fixed here: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00525.html
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #15 from Jakub Jelinek --- (In reply to chefmax from comment #14) > (In reply to Jakub Jelinek from comment #13) > > or introduce a new virtual pseudo register that vregs pass would map > > directly to dynamic_offset. > > Yeah, that's what I though about (LLVM does pretty the same thing). But > (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an > appropriate solution too. I'll cover the testing for both approaches. The above patch passed make -j16 -k check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp=alloca*' on x86_64-linux and powerpc64-linux and without the -m32, part also on powerpc64le-linux.
[Bug tree-optimization/85375] possible missed optimisation / regression from 6.3 with while (__builtin_ffs(x) && x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85375 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-12 Blocks||85316 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- .optimized shows [local count: 114863532]: _8 = __builtin_ffs (x_4(D)); if (_8 != 0) goto ; [94.50%] else goto ; [5.50%] [local count: 108546038]: if (x_4(D) != 0) goto ; [94.50%] else goto ; [5.50%] missed jump-threading. [local count: 958878293]: # x_10 = PHI x_6 = x_10 - a.0_1; _2 = __builtin_ffs (x_6); if (_2 != 0) goto ; [94.50%] else goto ; [5.50%] [local count: 906139986]: if (x_6 != 0) goto ; [94.50%] else goto ; [5.50%] likewise. VRP needs to derive a range for x_6 from _2 != 0. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug rtl-optimization/85376] [8 Regression] wrong code with -Og -fno-dce -fgcse -fno-tree-ccp -fno-tree-copy-prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85376 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #14 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) > or introduce a new virtual pseudo register that vregs pass would map directly > to dynamic_offset. Yeah, that's what I though about (LLVM does pretty the same thing). But (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an appropriate solution too. I'll cover the testing for both approaches.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #13 from Jakub Jelinek --- Created attachment 43919 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43919&action=edit gcc8-pr85230.patch So, if you want to add STACK_DYNAMIC_OFFSET to new_sp for the second argument, then we could do either what this patch does (i.e. pass new_sp + (virtual_stack_dynamic_rtx - stack_pointer_rtx) as second argument) and rely on cse/forwprop/combine to optimize it into new_sp (if STACK_DYNAMIC_OFFSET is 0) or to just addition of some constant, or introduce a new virtual pseudo register that vregs pass would map directly to dynamic_offset.
[Bug gcov-profile/85377] New: [GCOV] Wrong coverage with label and if(cond) break in while(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85377 Bug ID: 85377 Summary: [GCOV] Wrong coverage with label and if(cond) break in while(1) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: yangyibiao at nju dot edu.cn CC: marxin at gcc dot gnu.org Target Milestone: --- $ gcc pv gcc: error: pv: No such file or directory gcc: fatal error: no input files compilation terminated. root@localhost:~/ccv# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu 8-20170923-1ubuntu2) $ cat small.c int g = 0; int main () { while (1) { int i = 2; L1: if (g < 1) break; } while (1) { int i = 2; L2: // if (g < 1) break; } return 0; } $ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov File 'small.c' Lines executed:90.00% of 10 Creating 'small.c.gcov' -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 -:1:int g = 0; -:2: 1:3:int main () -:4:{ -:5: while (1) #:6: { 1:7:int i = 2; 1:8:L1: 1:9:if (g < 1) 1: 10: break; -: 11: } -: 12: -: 13: while (1) -: 14: { 1: 15:int i = 2; 1: 16:L2: -: 17:// if (g < 1) 1: 18: break; -: 19: } 1: 20: return 0; -: 21:} Line #6 is wrongly marked as not executed with "#". For the second while statement, coverage of Line #14 is correct.