[Bug c/84190] [7/8 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #13 from Richard Biener --- Author: rguenth Date: Fri Feb 16 07:57:56 2018 New Revision: 257722 URL: https://gcc.gnu.org/viewcvs?rev=257722&root=gcc&view=rev Log: 2018-02-16 Richard Biener PR tree-optimization/84190 * tree-ssa.c (non_rewritable_mem_ref_base): Do not touch volatile accesses if the decl isn't volatile. * g++.dg/torture/pr84190.C: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr84190.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-ssa.c
[Bug c/84190] [7/8 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #12 from Richard Biener --- Author: rguenth Date: Fri Feb 16 07:56:16 2018 New Revision: 257721 URL: https://gcc.gnu.org/viewcvs?rev=257721&root=gcc&view=rev Log: 2018-02-16 Richard Biener PR tree-optimization/84190 * tree-ssa.c (non_rewritable_mem_ref_base): Do not touch volatile accesses if the decl isn't volatile. * g++.dg/torture/pr84190.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr84190.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c
[Bug middle-end/70920] if ((intptr_t)ptr == 0) doesn't get simplified to if (ptr == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70920 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to prathamesh3492 from comment #5) > (In reply to mwahab from comment #4) > > (In reply to prathamesh3492 from comment #3) > > > Fixed on trunk. > > > > I think that this is the cause of a failure in gcc.dg/tree-ssa/pr22051-2.c > > for arm-none-linux-gnueabihf and arm-none-eabi. > > > > With the patch, the scan-tree-dump match in the test file fails because the > > conditional becomes > > > > if (q_2(D) != 0B) > > > > rather than the expected > > > > if (r_3 != 0) > > > > > > The comment in the test file suggests that the optimization might be wrong. > Sorry for the breakage. > Patch posted for this case: > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00246.html > > Thanks, > Prathamesh An updated version of this patch was approved.
[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56828 --- Comment #15 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #14) > powerpc failure of floating-point extensions to quiet signaling NaNs > (because loads implicitly extend from float to double in a way that's > defined as bit-manipulation rather than a convertFormat operation) is bug > 56828. but bug 56828 was closed as INVALID...
[Bug tree-optimization/37239] peeling last iteration of a <= loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Andrew Pinski from comment #5) > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00253.html This was approved with a minor nit fixed
[Bug c++/84415] New: Using __m128 as a template parameter causes warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84415 Bug ID: 84415 Summary: Using __m128 as a template parameter causes warnings Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: myriachan at gmail dot com Target Milestone: --- Attempting to use one of the intrinsic x86 vector types like __m128 causes a warning: :9:30: warning: ignoring attributes on template argument '__m128 {aka __vector(4) float}' [-Wignored-attributes] __m128 Purr(const Meow<__m128> &m) ^ This is really annoying in warnings-as-errors mode. This doesn't happen for uint64x2_t on ARM or ARM64. #include template struct Meow { T x; }; __m128 Purr(const Meow<__m128> &m) { return m.x; }
[Bug c++/81930] [meta-bug] Issues with -Weffc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-16 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- One less unconfirmed bug.
[Bug c++/81853] [ 6/7/8 Regression] "using namespace" is not a constant expression in a statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81853 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-16 CC||msebor at gcc dot gnu.org Known to work||4.5.4 Summary|[C++14] "using namespace" |[ 6/7/8 Regression] "using |is not a constant |namespace" is not a |expression in function-like |constant expression in a |macro |statement expression Ever confirmed|0 |1 Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4, ||5.5.0, 6.4.0, 7.2.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed with the simplified test case below. GCC 4.5 compiles the test case without a complaint so the failure is a regression introduced in r166167. $ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C namespace N { enum { i }; } int g () { constexpr int j = ({ using namespace N; i; }); return j; } t.C: In function ‘int g()’: t.C:7:21: warning: ISO C++ forbids braced-groups within expressions [-Wpedantic] constexpr int j = ({ using namespace N; i; }); ^ t.C:7:40: error: statement is not a constant expression constexpr int j = ({ using namespace N; i; }); ^
[Bug c/67999] Wrong optimization of pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 --- Comment #28 from Daniel Micay --- I got jemalloc / Bionic libc (Android) to report errors for malloc and mmap/mremap larger than PTRDIFF_MAX a while ago (along with fixing a missing case for mremap in musl), but glibc needs to be convinced to do the same. It would be a lot easier to convince them with this officially documented. I think it's perfectly reasonable if it's clearly stated that objects larger than PTRDIFF_MAX are not supported and that the libc implementation needs to deal with it.
[Bug other/81831] -Wno-psabi is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81831 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-16 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. The option is referred to by other options but it itself is not documented as it should be. $ grep -e Wpsabi -e Wno-psabi gcc/doc/invoke.texi:you use the @option{-Wno-psabi} option. gcc/doc/invoke.texi:you use the @option{-Wno-psabi} option. gcc/doc/invoke.texi.orig:you use the @option{-Wno-psabi} option. gcc/doc/invoke.texi.orig:you use the @option{-Wno-psabi} option.
[Bug c/67999] Wrong optimization of pointer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #27 from Martin Sebor --- (In reply to Alexander Cherepanov from comment #4) > Interesting. In particular, this means that the warning "Argument 'size' of > function malloc has a fishy (possibly negative) value" from valgrind is a > serious thing. Is this gcc limitation documented somewhere? Is there a > better reference than this bug? GCC 7 and later mention it in the documentation of the -Walloc-size-larger-than=n option. It should be documented more prominently. They also diagnose the program in comment #0: pr67999.c: In function ‘main’: pr67999.c:7:15: warning: argument 1 value ‘3221225472’ exceeds maximum object size 2147483647 [-Walloc-size-larger-than=] char *buf = malloc(len); ^~~ In file included from pr67999.c:2: /usr/include/stdlib.h:427:14: note: in a call to allocation function ‘malloc’ declared here extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur; ^~ > > Am I right that the C standards do not allow for such a limitation (and > hence this should not be reported to glibc as a bug) and gcc is not > standards-compliant in this regard? Or I'm missing something? I think malloc() should fail for such large requests because objects that big don't satisfy the basic requirements on pointer arithmetic.
[Bug c++/84414] miscompile due to assuming that object returned by value cannot alias its own member pointer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414 --- Comment #2 from Richard Smith --- > Where does the scope of object A inside Foo begin and end? There is formally only one object. The object constructed in the return statement of Foo is simply the same object that is named 'a' within Bar. > Maybe it is time to file a DR to the C++ language folks about this case > if there is not one already. Hmm, the [class.temporary]/3 rule already gets very close to allowing this: "When an object of class type X is passed to or returned from a function, if each copy constructor, move constructor, and destructor of X is either trivial or deleted, and X has at least one non-deleted copy or move constructor, implementations are permitted to create a temporary object to hold the function parameter or result object. The temporary object is constructed from the function argument or return value, respectively, and the function’s parameter or return object is initialized as if by using the non-deleted trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the object). [ Note: This latitude is granted to allow objects of class type to be passed to or returned from functions in registers. — end note ]" In fact, I think the *only* problem here is that the above rule does not allow the caller and the callee to observe the objects having the same address. I'll take this to the committee and see whether we can get that rule relaxed slightly. Would you be OK with this optimization only being permitted for the above class types (those that can be passed/returned in registers)?
[Bug c++/81789] CWG1687 performed too soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81789 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-16 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. This was never rejected, so it's not a regression. Looks like the issue resolution is not implemented yet.
[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83227 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Feb 16 02:47:19 2018 New Revision: 257720 URL: https://gcc.gnu.org/viewcvs?rev=257720&root=gcc&view=rev Log: PR c++/83227 - C++17 ICE with init-list derived-to-base conversion. * call.c (convert_like_real): Don't use the copy-list-initialization shortcut for ck_base. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist98.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84349 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/84349] [6/7/8 Regression] ICE with auto in function cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84349 Martin Sebor changed: What|Removed |Added Known to work||4.8.4 Known to fail||4.9.4, 5.5.0, 6.4.0, 7.2.0, ||8.0 --- Comment #2 from Martin Sebor --- A slightly simpler test case: void *p = (int(*)(auto))0; The bug seems to be that the auto isn't rejected in this context (namespace scope). The same initializer is rejected in local scope. Accepting it in an initializer expression results in incrementing the processing_template_decl counter in the test case from its initial value of zero to 1. The counter doesn't get decremented back to zero which then triggers the unpaired call to finish_lambda_scope() below: if (!member_p && processing_template_decl) start_lambda_scope (decl); initializer = cp_parser_initializer (parser, &is_direct_init, &is_non_constant_init); if (!member_p && processing_template_decl) finish_lambda_scope (); AFAICS, the problem is somewhere in cp_parser_decl_specifier_seq() that creates a decl_specifiers.type for the initializer at global scope for which type_uses_auto() returns null.
[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404 --- Comment #4 from Arseny Solokha --- (In reply to Arseny Solokha from comment #3) > I see the same issue This is x86_64-pc-linux-gnu.
[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- I see the same issue w/ the following snippet compiled w/ -O2 -ftree-parallelize-loops=2 -floop-nest-optimize -g: int te[9]; void dt (int cz) { while (cz < 1) { int xy; for (xy = 0; xy < 9; ++xy) te[xy] = 0; ++cz; } } % gcc-8.0.0-alpha20180211 -O2 -ftree-parallelize-loops=2 -floop-nest-optimize -g -c pr84404.c /tmp/ccfu80w2.s: Assembler messages: /tmp/ccfu80w2.s:700: Error: leb128 operand is an undefined symbol: .LVU12 as of r257571. GNU as 2.30 seems to be the key here.
[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 --- Comment #5 from Steve Kargl --- This patch fixes the problem, but I'm in an area of the compiler that I do not too well. It might open gfortran to other problems. Jerry, any comments? Index: io.c === --- io.c(revision 257695) +++ io.c(working copy) @@ -1012,8 +1012,7 @@ data_desc: goto between_desc; default: - error = unexpected_element; - goto syntax; + goto format_item_1; } break;
[Bug c++/84414] miscompile due to assuming that object returned by value cannot alias its own member pointer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414 --- Comment #1 from Andrew Pinski --- To me, the temp object A inside Foo ends its scope at the end function (even with guaranteed copy elision). Because this would mean the compiler will have to assume nothing about any structs that are returned which seems backwards and even counter to the language itself. Maybe it is time to file a DR to the C++ language folks about this case if there is not one already. Where does the scope of object A inside Foo begin and end?
[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83982 --- Comment #5 from Daniel Trebbien --- Ah! Thank you for letting me know.
[Bug c++/84414] New: miscompile due to assuming that object returned by value cannot alias its own member pointer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414 Bug ID: 84414 Summary: miscompile due to assuming that object returned by value cannot alias its own member pointer values Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk CC: timshen at gcc dot gnu.org Target Milestone: --- GCC (all versions) miscompiles this code: struct A { A *children; long long arr[100]; A() : children() {} A(int) : children(this) {} }; __attribute__((noinline)) A Foo() { return A(0); } A x[3] = {}; void Bar(int n) { A a = Foo(); for (int i = 0; i < n; i++) { a.children[i].children = x; } } int main() { Bar(3); return x[0].children || !x[1].children || !x[2].children; } A correct compilation must return 0 from main, but GCC at -O2 returns 1. The reason is that it fails to reload 'a.children' on each iteration of the loop in 'Bar', reasoning (incorrectly) that the store to 'a.children[i].children' cannot alias 'a.children' because 'a' has not escaped. The above code has defined behavior in C++17, where the 'guaranteed copy elision' rules mean that the 'this' pointer inside the A::A(int) constructor points to the 'a' object inside 'Bar'. But since GCC chooses to perform copy elision on this code in all language modes (and always has done so), and the fact that it performed copy-elision is observable, this is not a C++17-specific bug. (The same miscompile can also be observed via NRVO.)
[Bug c++/84355] [7/8 Regression] ICE with failing template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84355 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00944.html
[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80945 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Created attachment 43438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43438&action=edit A demo patch for the PR This does the job but sucks stylistically. I will sort out something better. It does regtest fine, though :-) It also fixes: program main implicit none integer:: i integer, parameter:: N = 10 character(len=:), dimension(:),allocatable:: ca character(len=:), dimension(:,:),allocatable:: cb allocate(character(len=N) :: ca(3)) ca(1) = "foo" ca(2) = "bar" ca(3) = "xyzzy" write (*, '(3A5)') ca(1:3) allocate(character(len=N) :: cb(3,2)) cb(1,1) = "foo" cb(2,1) = "bar" cb(3,1) = "xyzzy" write (*, '(3A5)') cb(1:3,1) ! Hence the assignment of the rank! end program Paul
[Bug c++/84355] [7/8 Regression] ICE with failing template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84355 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org, ||jason at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69517 --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Patch for bug 69517 posted for review (below) includes a fix for this bug as > well: > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html Adding "patch" keyword then
[Bug fortran/84354] Replace '%qs' with %qs in fortran/decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84354 Eric Gallager changed: What|Removed |Added Keywords||easyhack CC||egallager at gcc dot gnu.org Severity|normal |trivial
[Bug rtl-optimization/64081] [6/7/8 Regression] r217827/8 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #62 from Eric Gallager --- (In reply to Jeffrey A. Law from comment #61) > Punting to gcc-8. The patch needs additional work and Aldy is poking at > something else at this point. The Aldy's analysis of the AIX issue should > allow this to be pushed forward in the gcc-8 development cycle. Same logic to punt to gcc-9 at this point?
[Bug middle-end/49899] ICE when redeclaring a static function as weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Nick Clifton from comment #2) > I have proposed the patch on the gcc-patches list: > > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01180.html Adding "patch" keyword
[Bug c++/83227] [7/8 Regression] internal compiler error: in process_init_constructor_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83227 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/84413] -march=skylake-avx512 disables BT instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413 --- Comment #1 from Uroš Bizjak --- Besides X86_TUNE_USE_BT, there is probably a long list of flags that have to be enabled for m_SKYLAKE_AVX512 (and m_CANNONLAKE and m_ICELAKE). Somebody will have to go through all tune flags for the above mentioned targets.
[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-15 Component|testsuite |fortran Ever confirmed|0 |1 --- Comment #4 from Thomas Koenig --- Better as a fortran issue - I searched for it in the Fortran bugs, and missed it at first. Confirming.
[Bug fortran/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Thomas Koenig changed: What|Removed |Added Component|testsuite |fortran --- Comment #4 from Thomas Koenig --- Makes more sense as a Fortran issue, IMHO.
[Bug target/84363] [8 Regression] Assembler error in stage1/libgcc: Error: view number mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84363 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Should be fixed by r257631.
[Bug c++/82468] [7/8 Regression] ICE with deduction guide template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82468 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 --- Looking into it.
[Bug c++/84045] [7 Regression] ICE when is_nothrow_default_constructible is used before #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84045 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Feb 15 22:01:33 2018 New Revision: 257713 URL: https://gcc.gnu.org/viewcvs?rev=257713&root=gcc&view=rev Log: PR c++/84045 - ICE with typedef and noexcept. * except.c (build_noexcept_spec): Use strip_typedefs_expr. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept32.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c
[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611 --- Comment #23 from Jeffrey A. Law --- No, the DOM change is only a partial fix. I've largely approved the auto-inc change. I recommend the additional tests in c#19 be pulled into a distinct BZ and the gcc8 regression marker removed once the auto-inc changes are committed.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #12 from Jozef Lawrynowicz --- (In reply to rsand...@gcc.gnu.org from comment #11) > Created attachment 43437 [details] > Possible patch v2 > > This time for real. Thanks, patch looks good to me, and the original testcase does indeed pass with it applied. Trunk still doesn't build for msp430-elf, but that seems to be an unrelated bug in libstdc++.
[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #22 from Eric Gallager --- (In reply to Alexandre Oliva from comment #21) > Author: aoliva > Date: Tue Jan 30 17:40:50 2018 > New Revision: 257194 > > URL: https://gcc.gnu.org/viewcvs?rev=257194&root=gcc&view=rev > Log: > [PR81611] accept copies in simple_iv_increment_p > > If there are copies between the GIMPLE_PHI at the loop body and the > increment that reaches it (presumably through a back edge), still > regard it as a simple_iv_increment, so that we won't consider the > value in the back edge eligible for forwprop. Doing so would risk > making the phi node and the incremented conflicting value live > within the loop, and the phi node to be preserved for propagated > uses after the loop. > > for gcc/ChangeLog > > PR tree-optimization/81611 > * tree-ssa-dom.c (simple_iv_increment_p): Skip intervening > copies. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/tree-ssa-dom.c Did this fix it?
[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84405 --- Comment #6 from Jakub Jelinek --- Another testcase that could in theory affect vec_default_construct is: extern "C" void abort (); typedef __typeof (sizeof (0)) size_t; inline void *operator new (size_t, void * p) { return p; } extern "C" void *memset (void *, int, size_t); template struct A { T t; U u; }; struct B { B (); ~B (); int b; }; B::B () : b (9) {} B::~B () {} template void foo (char *p) { new (p) T (); } int main () { int a; struct S { A b; char c[sizeof (A)]; } s; A *p = (A *) &s.c; memset (s.c, 0x55, sizeof (s.c)); foo > (s.c); if (p->t) abort (); } and that was fixed in PR11309 / r138355 only in 4.4. And Jon mentions another one value initialization related - PR30111.
[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65604 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Steve Ellcey from comment #4) > Author: sje > Date: Fri Jan 29 16:29:58 2016 > New Revision: 232985 > > URL: https://gcc.gnu.org/viewcvs?rev=232985&root=gcc&view=rev > Log: > PR target/65604 > * config/mips/mips.c (mips_output_division): Check flag_delayed_branch. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/mips/mips.c (In reply to Steve Ellcey from comment #5) > Author: sje > Date: Fri Jan 29 16:31:18 2016 > New Revision: 232986 > > URL: https://gcc.gnu.org/viewcvs?rev=232986&root=gcc&view=rev > Log: > PR target/65604 > * gcc.target/mips/div-delay.c: New test. > > Added: > trunk/gcc/testsuite/gcc.target/mips/div-delay.c > Modified: > trunk/gcc/testsuite/ChangeLog Did these commits fix this bug?
[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-15 Ever confirmed|0 |1 --- Comment #4 from kargl at gcc dot gnu.org --- Confirmed.
[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 --- Comment #3 from Steve Kargl --- On Thu, Feb 15, 2018 at 09:04:24PM +, fortranfan at outlook dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 > > --- Comment #2 from Vipul Parekh --- > Thank for your response. > > Per section 1.4.1 in 10-007r1 toward Fortran 2008 on syntax rules toward the > BNF convention in the document, line 16 says [] encloses an optional item. > > R1303 format-items is format-item [ [ , ] format-item ] > > then suggests the comma in the format item is optional and the format in the > first post should work as shown. > Ah, indeed! You are correct. I simply missed the enclosing [ ] in looking through all of the ENBDF rules.
[Bug testsuite/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Bug 84094 depends on bug 84409, which changed state. Bug 84409 Summary: [F03] check DTIO arguments for character len https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84409 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/84409] [F03] check DTIO arguments for character len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84409 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #3 from janus at gcc dot gnu.org --- Fixed with r257711. Closing.
[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83982 --- Comment #4 from Jonathan Wakely --- The trunk is currently closed for non-regression changes, as we prepare for the GCC 8 release.
[Bug fortran/84409] [F03] check DTIO arguments for character len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84409 --- Comment #2 from janus at gcc dot gnu.org --- Author: janus Date: Thu Feb 15 21:16:00 2018 New Revision: 257711 URL: https://gcc.gnu.org/viewcvs?rev=257711&root=gcc&view=rev Log: 2018-02-15 Janus Weil PR fortran/84409 * interface.c (check_dtio_arg_TKR_intent): Add a check for character length. 2018-02-15 Janus Weil PR fortran/84409 * gfortran.dg/dtio_21.f03: Add an error message. * gfortran.dg/dtio_22.f90: Fix invalid test case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dtio_21.f90 trunk/gcc/testsuite/gfortran.dg/dtio_22.f90
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #59 from Jonathan Wakely --- Should be fixed on trunk, please test and confirm.
[Bug debug/68771] Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- There's been recent changes to the __cold_sect_of_*-affecting code on Darwin; can you check and see if this is still an issue?
[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 --- Comment #2 from Vipul Parekh --- Thank for your response. Per section 1.4.1 in 10-007r1 toward Fortran 2008 on syntax rules toward the BNF convention in the document, line 16 says [] encloses an optional item. R1303 format-items is format-item [ [ , ] format-item ] then suggests the comma in the format item is optional and the format in the first post should work as shown.
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #58 from Jonathan Wakely --- Author: redi Date: Thu Feb 15 20:56:41 2018 New Revision: 257710 URL: https://gcc.gnu.org/viewcvs?rev=257710&root=gcc&view=rev Log: PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin PR libstdc++/81797 * configure.ac (INCLUDE_DIR_NOTPARALLEL): Define. * configure: Regenerate. * include/Makefile.am (INCLUDE_DIR_NOTPARALLEL): Add .NOTPARALLEL when defined. * include/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in
[Bug target/84413] New: -march=skylake-avx512 disables BT instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413 Bug ID: 84413 Summary: -march=skylake-avx512 disables BT instruction 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: ubizjak at gmail dot com Target Milestone: --- Target: x86 [hjl@gnu-skx-1 gcc]$ cat x.c unsigned long long bextr64_demanded(unsigned long long x) { return x | 0x80; } [hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O2 x.c -march=skylake-avx512 [hjl@gnu-skx-1 gcc]$ cat x.s .file "x.c" .text .p2align 4,,15 .globl bextr64_demanded .type bextr64_demanded, @function bextr64_demanded: .LFB0: .cfi_startproc movabsq $549755813888, %rax orq %rdi, %rax xorl%edi, %edi ret .cfi_endproc .LFE0: .size bextr64_demanded, .-bextr64_demanded .ident "GCC: (GNU) 8.0.1 20180212 (experimental)" .section.note.GNU-stack,"",@progbits [hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -S -O2 x.c [hjl@gnu-skx-1 gcc]$ cat x.s .file "x.c" .text .p2align 4,,15 .globl bextr64_demanded .type bextr64_demanded, @function bextr64_demanded: .LFB0: .cfi_startproc movq%rdi, %rax xorl%edi, %edi btsq$39, %rax ret .cfi_endproc .LFE0: .size bextr64_demanded, .-bextr64_demanded .ident "GCC: (GNU) 8.0.1 20180212 (experimental)" .section.note.GNU-stack,"",@progbits [hjl@gnu-skx-1 gcc]$
[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 #42 from Wilco --- Cut down example: typedef struct { int x, y; } X; void f (X *p, int n) { for (int i = 0; i < n; i++) { p[i].x = i; p[i].y = i + 1; } }
[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- The actual commit was r257702 .
[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #9 from Matthijs van Duin --- I can still reproduce the same test case with: arm-linux-gnueabihf-gcc-8 (Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision 257435] -mfloat-abi=hard is implicit for arm-linux-gnueabihf, although overriding that to -mfloat-abi=softfp produces exactly the same result for me. (-mfloat-abi=soft completely disables all use of VFP/Neon hence obviously suppresses this problem.)
[Bug c++/84045] [7/8 Regression] ICE when is_nothrow_default_constructible is used before #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84045 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/84154] [7 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 #10 from Michael Meissner --- Author: meissner Date: Thu Feb 15 19:57:46 2018 New Revision: 257707 URL: https://gcc.gnu.org/viewcvs?rev=257707&root=gcc&view=rev Log: 2018-02-15 Michael Meissner Back port from trunk 2018-02-06 Michael Meissner PR target/84154 * config/rs6000/rs6000.md (su code attribute): Use "u" for unsigned_fix, not "s". Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81764 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.1.0 Keywords||diagnostic Last reconfirmed||2018-02-15 CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84318 Ever confirmed|0 |1 Summary|Visibility attributes for |[6/7/8 Regression] |explicitly instantiated |Visibility attributes for |template class get warned |explicitly instantiated |if it has been implicitly |template class get warned |instantiated|if it has been implicitly ||instantiated Known to fail||4.2.2, 4.3.2, 4.6.0, 5.4.0, ||6.3.0, 7.2.0, 8.0 --- Comment #1 from Martin Sebor --- The warning might be helpful if the explicit specialization declaration attempted to specify different visibility that the primary template (assuming the declaration of the specialization inherits the attribute from the template) but it's pointless when it simply reiterates the same visibility, and it would be wrong if the specialization didn't "inherit" its attributes from the primary. With that, I would say that it's not desirable (even though it is intended in other cases). With that I confirm it as a bug. The warning wasn't issued prior to r115086 (committed into GCC 4.2) so it's also aa regression, albeit a very old one. As the test case below shows, the warning isn't unique to the visibility attribute. It affects other type attributes as well. Here too the warning is pointless regardless of how attributes are treated. Unfortunately, specifying an attribute on the declaration of an explicit instantiation isn't specified either in C++ or in G++ and it not clear that we know or have consensus what we want it to mean (see for example bug 84318), so this bug isn't likely to get a lot attention until the confusion around attributes and templates has been cleared up. $ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C template class A; template struct alignas (32) A { static int f () { return A<>::f (); } }; extern template struct alignas (32) A<>; static_assert (alignof (A<>) == 32, ""); t.C:9:37: warning: type attributes ignored after type is already defined [-Wattributes] extern template struct alignas (32) A<>; ^~~
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #11 from rsandifo at gcc dot gnu.org --- Created attachment 43437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43437&action=edit Possible patch v2 This time for real.
[Bug jit/84288] Support jit on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288 --- Comment #4 from Rainer Orth --- (In reply to Rainer Orth from comment #0) [...] > * In the 32-bit case, two tests FAIL like this: > > PASSED: test-vector-rvalues.cc.exe iteration 1 of 5: verify_vec_code: > fn is > non-null > FAILED: test-vector-rvalues.cc.exe iteration 1 of 5: check_div: actual: > c[i] != expected: a[i] / b[i] > incorrect value [...] > FAILED: test-vector-types.cc.exe iteration 1 of 5: check_div: > actual: c[i] != expected: a[i] / b[i] > incorrect value [...] > ISTM that check_div needs to use CHECK_DOUBLE_VALUE here. I've just run an i686-pc-linux-gnu build and see exactly the same errors. So this seems to be a 32-bit (or 32-bit x86) issue.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 rsandifo at gcc dot gnu.org changed: What|Removed |Added Attachment #43435|0 |1 is obsolete|| --- Comment #10 from rsandifo at gcc dot gnu.org --- Created attachment 43436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43436&action=edit Possible patch v2 Sigh, attached wrong file last time.
[Bug c++/84376] [7/8 Regression] ICE with missing template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84376 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|7.4 |8.0 --- Comment #2 from Jason Merrill --- Fixed for GCC 8.
[Bug c++/84376] [7/8 Regression] ICE with missing template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84376 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Feb 15 19:46:13 2018 New Revision: 257706 URL: https://gcc.gnu.org/viewcvs?rev=257706&root=gcc&view=rev Log: PR c++/84376 - ICE with omitted template arguments. * pt.c (dguide_name_p): Check for IDENTIFIER_NODE. Added: trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction47.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 rsandifo at gcc dot gnu.org changed: What|Removed |Added Attachment #43434|0 |1 is obsolete|| --- Comment #9 from rsandifo at gcc dot gnu.org --- Created attachment 43435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43435&action=edit Possible patch v2 (In reply to Jakub Jelinek from comment #8) > From the above comments, from_mode can be also MODE_INT and to_mode > MODE_PARTIAL_INT, though I wonder how, because it clearly couldn't reach the > PSImode by FOR_EACH_MODE. Ah, missed that. So in those cases, the limit mode should be the containing MODE_INT rather than to_mode itself. Second try.
[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 --- Comment #4 from Steve Ellcey --- While teaching the reassociation pass about fma's seems like the right answer would it be reasonable (and simpler) to do the fma pass (pass_optimize_widening_mul) before the reassociation pass (pass_reassoc) to get the most fma's? That fixes my small test case but I haven't done a bigger performance check to see what the overall impact would be.
[Bug fortran/84412] New: Erroneous "Inquire statement identifies an internal file" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412 Bug ID: 84412 Summary: Erroneous "Inquire statement identifies an internal file" error Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- Using gfortran 8.0.1 (r257607) the following produces an erroneous error of "Inquire statement identifies an internal file": program bug implicit none integer :: i character(len=1) :: s write (s,'(i1)') 0 open(newUnit=i,file='bug.txt',status='unknown') inquire(unit=i) end program bug $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 8.0.1 20180212 (experimental) (GCC) $ gfortran bug.F90 $ a.out At line 7 of file bug.F90 Fortran runtime error: Inquire statement identifies an internal file Error termination. Backtrace: #0 0x7fd470750d44 in inquire_via_unit at ../../../gcc-trunk/libgfortran/io/inquire.c:47 #1 0x400969 in ??? #2 0x4009a0 in ??? #3 0x7fd46fb7ed0c in __libc_start_main at /data001/abenson/Galacticus/Tools/glibc-2.12.1/csu/libc-start.c:226 #4 0x4006f8 in ??? If the WRITE statement is removed the error does not occur.
[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84405 --- Comment #5 from Jakub Jelinek --- So, seems it is that hash-table.h change that really doesn't work in GCC r132088, not just 4.2.*, but any (tried even 3.2). The implicitly defined default constructor for A (hash_map<...>::hash_entry in gcc) doesn't initialize the POD t field (which is correct I assume, current trunk doesn't do that either), but the value initialization before r132088 only constructs the non-POD u field of A and doesn't initialize t at all (in GCC that is the m_key, in the stuck case with type edge_def *). extern "C" void abort (); template struct A { T t; U u; }; struct B { B (); ~B (); int b; }; B::B () : b (9) {} B::~B () {} template void foo (T *p) { *p = T (); } int main () { int a; A h; h.t = &a; foo (&h); if (h.t) abort (); } So, either we need to conditionally revert (for say #if GCC_VERSION != 0 && GCC_VERSION < 4003 && !defined(__clang__) ) the hash-table.h change and use memset.h for old GCCs, or we need some template hackery to determine if value_type is hash_map::hash_entry from hash-map.h and instead of using *entries = value_type (); do entries->m_key = value_type::compare_type (); entries->m_value = something (); Ugh.
[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83982 --- Comment #3 from Daniel Trebbien --- Friendly reminder: I have attached a patch for this issue which I would like to have reviewed and committed.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #8 from Jakub Jelinek --- Comment on attachment 43434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43434 Possible patch From the above comments, from_mode can be also MODE_INT and to_mode MODE_PARTIAL_INT, though I wonder how, because it clearly couldn't reach the PSImode by FOR_EACH_MODE.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #7 from rsandifo at gcc dot gnu.org --- Created attachment 43434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43434&action=edit Possible patch This is the kind of change I was thinking of.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 Jakub Jelinek changed: What|Removed |Added Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Well, there are two assertions, and without the first one the second one doesn't work either, modes from different classes aren't well ordered.
[Bug c++/84411] New: Missed optimization: static guard variable generated for empty virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 Bug ID: 84411 Summary: Missed optimization: static guard variable generated for empty virtual destructor Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: arthur.j.odwyer at gmail dot com Target Milestone: --- Consider the following program: struct Base { constexpr Base() = default; virtual int foo(); // virtual ~Base() = default; }; struct Derived : public Base { constexpr Derived() = default; virtual int foo() override; }; Base& get_base() { static Derived d; return d; } This is a simplified version of the current idioms around `std::error_category` and `std::pmr::memory_resource`, except that for now I have commented-out the virtual destructor. Notice that because `Derived d` is trivially destructible, no atomic guard variable is generated to register its destructor with __cxa_atexit. Now uncomment the defaulted virtual destructor of `Base`. The semantics of `Derived d` have not changed: we are still expecting to call ~Derived by non-virtual dispatch, and ~Derived is still known statically to be a no-op. But now suddenly GCC decides to generate an atomic guard variable and a call to `__cxa_atexit`! I think GCC could do better here, and if it did, it would eliminate a lot of atomic instructions in the critical path for things like `std::error_code{}` and `std::pmr::new_delete_resource()`.
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #5 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > I think Richard needs to explain why he changed the function from using > GET_MODE_WIDER_MODE to the assert + simple iteration on modes, it isn't > clear from his patch why it was changed. Does that not really work with the > variable sized modes on SVE? FOR_EACH_MODE does use GET_MODE_WIDER_MODE. I think problem is just with the assertion.
[Bug bootstrap/82939] genmatch fills up terminal with endless printing of periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939 --- Comment #16 from Eric Gallager --- (In reply to Jakub Jelinek from comment #15) > Full testcase suitable for configure: > extern "C" void abort (); > struct S { ~S () { if (x) abort (); }; int x, y, z; }; > void foo (S *p) { *p = S (); } > int main () { S s; s.x = 1; s.y = 2; s.z = 3; foo (&s); if (s.x != 0 || s.y > != 0 || s.z != 0) abort (); } > Given how many places r249234 changed, adding workarounds for the PR33916 > GCC 4.2.[0-3] bug might be too pervasive. All 4.2.* compilers from 20061017 > to 20080212 are likely broken, unless patched. I can confirm that this aborts for me when compiled with g++ 4.2.1 with -O2.
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #38 from acsawdey at gcc dot gnu.org --- Backports complete, so this can be closed.
[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 --- Comment #2 from Thomas Koenig --- Author: tkoenig Date: Thu Feb 15 18:46:22 2018 New Revision: 257703 URL: https://gcc.gnu.org/viewcvs?rev=257703&root=gcc&view=rev Log: 2018-02-15 Thomas Koenig PR fortran/84381 * gfortran.dg/stop_shouldfail.f90: New test. Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #4 from Jakub Jelinek --- I think Richard needs to explain why he changed the function from using GET_MODE_WIDER_MODE to the assert + simple iteration on modes, it isn't clear from his patch why it was changed. Does that not really work with the variable sized modes on SVE?
[Bug target/84406] [8 Regression][MSP430] ICE on valid code in find_widening_optab_handler_and_mode, at optabs-query.c:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84406 --- Comment #3 from Jozef Lawrynowicz --- Created attachment 43433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43433&action=edit define {u,}mulhipsi3 insns I applied the patch but trunk still ICEs. After defining some insns for "umulhipsi3" and "mulhipsi3" in msp430.md, the build gets a little further, but then a case is encountered where a widen from QI to PSI is attempted. QI != PARTIAL_INT_MODE, so we ICE again. The insns in attached patch are mostly just copied from the mulhisi*, so are almost definitely not correct, but they are at least there for GCC to use in the build.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #11 from Martin Liška --- (In reply to Martin Liška from comment #10) > Created attachment 43432 [details] > Parallel build of make all-host on 8 core Haswell machine This was generated with a slightly modified make (being able to run fully in parallel): https://github.com/marxin/make/tree/timestamp-v2 And output is then parsed and 'stacked' graph is generated: https://github.com/marxin/script-misc/blob/master/parse-make-log-parallel.py
[Bug libffi/84410] libffi doesn't support riscv now, but not disabled in configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84410 --- Comment #1 from Andreas Schwab --- Neither does libgo support RISC-V yet.
[Bug translation/84303] Styled quotes in error message may be inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84303 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-15 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I'll confirm this. I would suggest to consider adopting the convention used by other back ends (e.g, mips or i386) for spelling attribute target: "attribute %" (i.e., the word attribute is not quoted but the keyword target is), and/or for attributes in general used by the middle-end ("% attribute"). This convention is helpful because there are at least two ways of spelling an attribute in user code, depending on the language: __attribute__ ((target)) in both C and C++ [[gnu::target]] in C++ C hasn't adopted the C++ syntax but a proposal for including it in C2X has been submitted and favorably received. At the same time, some people on the C committee have been arguing for alternate syntax along the lines of _Attribute (target) If this were to adopted (either in favor of the C++ notation or in addition to it), there would be three different ways to spell the same thing. Unless GCC can determine and use what appears in the source code using a generic spelling is less confusing or misleading.
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #37 from acsawdey at gcc dot gnu.org --- Author: acsawdey Date: Thu Feb 15 18:36:20 2018 New Revision: 257701 URL: https://gcc.gnu.org/viewcvs?rev=257701&root=gcc&view=rev Log: 2018-02-15 Aaron Sawdey Back port from mainline 2018-01-30 Aaron Sawdey PR target/83758 * config/rs6000/rs6000.c (rs6000_internal_arg_pointer): Only return a reg rtx. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
[Bug c++/84376] [7/8 Regression] ICE with missing template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84376 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Martin Liška changed: What|Removed |Added Attachment #43428|0 |1 is obsolete|| --- Comment #10 from Martin Liška --- Created attachment 43432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43432&action=edit Parallel build of make all-host on 8 core Haswell machine
[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84368 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Feb 15 18:15:32 2018 New Revision: 257699 URL: https://gcc.gnu.org/viewcvs?rev=257699&root=gcc&view=rev Log: PR c++/84368 - wrong error with local variable in variadic lambda. * pt.c (tsubst_pack_expansion): Fix handling of non-packs in local_specializations. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84368 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/70401] [c++1z on mingw]compile variadic template failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70401 --- Comment #5 from Rainer Emrich --- For a recent trunk version 8.0.1 20180207 (experimental) [trunk revision 257437] it's the same.
[Bug c++/84330] [6/7 Regression] [concepts] ICE with broken constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84330 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8 Regression] |[6/7 Regression] [concepts] |[concepts] ICE with broken |ICE with broken constraint |constraint | --- Comment #5 from Paolo Carlini --- Fixed in trunk.
[Bug c++/84330] [6/7/8 Regression] [concepts] ICE with broken constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84330 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Feb 15 18:05:40 2018 New Revision: 257698 URL: https://gcc.gnu.org/viewcvs?rev=257698&root=gcc&view=rev Log: /cp 2018-02-15 Paolo Carlini PR c++/84330 * constraint.cc (tsubst_constraint_info): Handle an error_mark_node as first argument. /testsuite 2018-02-15 Paolo Carlini PR c++/84330 * g++.dg/concepts/pr84330.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr84330.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/testsuite/ChangeLog
[Bug c++/70401] [c++1z on mingw]compile variadic template failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70401 --- Comment #4 from Rainer Emrich --- gcc-7.3.0 on x86_64-w64-mingw32 doesn't compile this code: $ g++ -std=c++1z aa.cpp -o aa.exe aa.cpp: In instantiation of 'std::ostream& operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*}; std::ostream = std::basic_ostream]': aa.cpp:133:54: required from here aa.cpp:113:7: error: call of overloaded 'apply(const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*}; std::ostream = std::basic_ostream]::&, const std::tuple&)' is ambiguous apply(printer,toprint); ~^ aa.cpp:105:6: note: candidate: auto apply(F&&, Tuple&&) [with F = const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*}; std::ostream = std::basic_ostream]::&; Tuple = const std::tuple&] auto apply(F&& f, Tuple&& t) { ^ In file included from aa.cpp:1:0: d:\opt\devel\gnu\gcc\mingw_nt\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-7.3.0\include\c++\7.3.0\tuple:1668:5: note: candidate: constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn = const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*}; std::ostream = std::basic_ostream]::&; _Tuple = const std::tuple&] apply(_Fn&& __f, _Tuple&& __t) ^ aa.cpp: In instantiation of 'std::ostream& operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*}; std::ostream = std::basic_ostream]': aa.cpp:134:53: required from here aa.cpp:113:7: error: call of overloaded 'apply(const operator<<(std::ostream&, const std::tuple<_Tps ...>&) [with T = {long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned int, long long unsigned int, const char*, const char*, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, long long unsigned int, const char*, long long unsigned int, const char*, const char*, long long unsigned in
[Bug bootstrap/84405] [8 Regression] Fails to bootstrap with GCC 4.1.2, GCC 4.2.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84405 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-15 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- The first revision that can't be bootstrapped with GCC 3.4.6 is again r249234. While rejecting GCC 4.2.[0-3] with PR33916 unfixed might be an option, I'm afraid rejecting everything older than that is not. I'll try to see what's going on in say 4.1.*.
[Bug target/84154] [7 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 #9 from Michael Meissner --- Author: meissner Date: Thu Feb 15 17:54:41 2018 New Revision: 257697 URL: https://gcc.gnu.org/viewcvs?rev=257697&root=gcc&view=rev Log: [gcc] 2018-02-15 Michael Meissner Back port from trunk 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-15 Michael Meissner Back port from trunk 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: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-1.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-2.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr84154-3.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug jit/84288] Support jit on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-15 Depends on||84379 Ever confirmed|0 |1 --- Comment #3 from Rainer Orth --- I've now developed a patch for PR target/84379 that cures the GC-related failures described before. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84379 [Bug 84379] Problems with sol2.c GTY handling
[Bug other/84379] Problems with sol2.c GTY handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84379 --- Comment #1 from Rainer Orth --- Created attachment 43431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43431&action=edit proposed patch By closely following what darwin.c does for machopic_indirections, I arrived at the attached patch which both bootstrapped and fixed the GC related failures in the jit testsuite.
[Bug c++/84368] [8 Regression] return type of generic lambda in variadic lambda in template is not deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84368 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-15 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83063 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed.
[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83063 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Feb 15 17:43:01 2018 New Revision: 257696 URL: https://gcc.gnu.org/viewcvs?rev=257696&root=gcc&view=rev Log: PR preprocessor/83063 - __VA_OPT__ and ## PR preprocessor/83708 * macro.c (vaopt_state): Reorder m_last_was_paste before m_state. (vaopt_state::vaopt_state): Adjust. (vaopt_state::update_flags): Add BEGIN and END. (vaopt_state::update): Return them. (copy_paste_flag): Factor out of replace_args. (last_token_is): New. (replace_args): Handle BEGIN and END. Avoid padding there. (tokens_buff_last_token_ptr): Return NULL if no tokens. Added: trunk/gcc/testsuite/c-c++-common/cpp/va-opt-2.c trunk/gcc/testsuite/c-c++-common/cpp/va-opt-3.c Modified: trunk/libcpp/ChangeLog trunk/libcpp/macro.c
[Bug preprocessor/83708] Token-based policy broken by __VA_OPT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83708 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Jason Merrill --- Fixed.
[Bug preprocessor/83708] Token-based policy broken by __VA_OPT__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83708 --- Comment #1 from Jason Merrill --- Author: jason Date: Thu Feb 15 17:43:01 2018 New Revision: 257696 URL: https://gcc.gnu.org/viewcvs?rev=257696&root=gcc&view=rev Log: PR preprocessor/83063 - __VA_OPT__ and ## PR preprocessor/83708 * macro.c (vaopt_state): Reorder m_last_was_paste before m_state. (vaopt_state::vaopt_state): Adjust. (vaopt_state::update_flags): Add BEGIN and END. (vaopt_state::update): Return them. (copy_paste_flag): Factor out of replace_args. (last_token_is): New. (replace_args): Handle BEGIN and END. Avoid padding there. (tokens_buff_last_token_ptr): Return NULL if no tokens. Added: trunk/gcc/testsuite/c-c++-common/cpp/va-opt-2.c trunk/gcc/testsuite/c-c++-common/cpp/va-opt-3.c Modified: trunk/libcpp/ChangeLog trunk/libcpp/macro.c
[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #8 from Jakub Jelinek --- In both adddi3_neon and lshrdi3_neon the GPR alternatives use exactly the same number of ?s as the NEON ones with avoid_neon_for_64bits, just the neon_for_64bits alternatives don't have any. So I don't see how it is a preference of not using NEON, when TARGET_PREFER_NEON_64BITS is true, neon is clearly preferred, otherwise there is no preferencing at all. And indeed, for DImode shifts by 32 the GPR regs should be prefered. Anyway, leaving this to ARM maintainers, don't know about the arch enough to do something.