[Bug demangler/81682] Timeout in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81682 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- Another similar case from https://sourceware.org/bugzilla/show_bug.cgi?id=22886 c++filt Z__dn99871_en
[Bug c++/84489] [6/7/8 Regression] Non-type template parameter dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489 Jason Merrill changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |6.5
[Bug c++/84560] [6/7/8 Regression] Internal error in std::function with std::memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84560 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #6 from Jason Merrill --- ICE fixed in GCC 8.
[Bug c++/84441] [6/7/8 Regression] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84441 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520 --- Comment #4 from Jason Merrill --- Author: jason Date: Tue Feb 27 04:22:24 2018 New Revision: 258027 URL: https://gcc.gnu.org/viewcvs?rev=258027&root=gcc&view=rev Log: PR c++/84520 - ICE with generic lambda in NSDMI. * lambda.c (lambda_expr_this_capture): Don't look for fake NSDMI 'this' in a generic lambda instantiation. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/lambda.c
[Bug c++/84441] [6/7/8 Regression] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84441 --- Comment #7 from Jason Merrill --- Author: jason Date: Tue Feb 27 04:22:31 2018 New Revision: 258028 URL: https://gcc.gnu.org/viewcvs?rev=258028&root=gcc&view=rev Log: PR c++/84441 - ICE with base initialized from ?: * call.c (unsafe_copy_elision_p): Handle COND_EXPR. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/elision3.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/call.c
[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/84441] [6/7/8 Regression] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84441 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Feb 27 02:47:31 2018 New Revision: 258025 URL: https://gcc.gnu.org/viewcvs?rev=258025&root=gcc&view=rev Log: PR c++/84441 - ICE with base initialized from ?: * call.c (unsafe_copy_elision_p): Handle COND_EXPR. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/elision3.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/call.c
[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Feb 27 02:47:25 2018 New Revision: 258024 URL: https://gcc.gnu.org/viewcvs?rev=258024&root=gcc&view=rev Log: PR c++/84520 - ICE with generic lambda in NSDMI. * lambda.c (lambda_expr_this_capture): Don't look for fake NSDMI 'this' in a generic lambda instantiation. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/lambda.c
[Bug c++/84560] [6/7/8 Regression] Internal error in std::function with std::memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84560 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Feb 27 02:45:56 2018 New Revision: 258023 URL: https://gcc.gnu.org/viewcvs?rev=258023&root=gcc&view=rev Log: PR c++/84560 - ICE capturing multi-dimensional VLA. * tree.c (array_of_runtime_bound_p): False if the element is variably-modified. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/84441] [6/7/8 Regression] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84441 --- Comment #4 from Jason Merrill --- Author: jason Date: Tue Feb 27 02:45:12 2018 New Revision: 258022 URL: https://gcc.gnu.org/viewcvs?rev=258022&root=gcc&view=rev Log: PR c++/84441 - ICE with base initialized from ?: * call.c (unsafe_copy_elision_p): Handle COND_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/elision3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Feb 27 02:44:26 2018 New Revision: 258021 URL: https://gcc.gnu.org/viewcvs?rev=258021&root=gcc&view=rev Log: PR c++/84520 - ICE with generic lambda in NSDMI. * lambda.c (lambda_expr_this_capture): Don't look for fake NSDMI 'this' in a generic lambda instantiation. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nsdmi1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c
[Bug c++/84560] [6/7/8 Regression] Internal error in std::function with std::memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84560
Jason Merrill changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Status|NEW |ASSIGNED
CC||jason at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #4 from Jason Merrill ---
Reduced further. With -std=c++0x this ICEs as far back as 4.5, the first
release to support lambdas.
void f() {
int n = 1;
int m = 1;
int d[n][m];
[&]() {
return d[1];
}();
}
[Bug c++/84581] GCC expects "override" keyword in incorrect grammar position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84581
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-02-27
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=64794
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
struct Base {
virtual const char (&GetBuffer() const)[1] = 0;
};
struct Wrong : Base {
// GCC requires this incorrect syntax...
virtual const char (&GetBuffer() const override)[1];
};
struct Correct : Base {
// ...but the below is the correct syntax, which GCC rejects.
virtual const char (&GetBuffer() const)[1] override;
};
This gives:
o.cc:11:46: error: expected ‘;’ at end of member declaration
virtual const char (&GetBuffer() const)[1] override;
^
;
o.cc:11:48: error: ‘override’ does not name a type
virtual const char (&GetBuffer() const)[1] override;
^~~~
EDG behaves the same as G++ but Clang gets it right.
[Bug c++/84581] New: GCC expects "override" keyword in incorrect grammar position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84581
Bug ID: 84581
Summary: GCC expects "override" keyword in incorrect grammar
position
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: ---
GCC expects the "override" keyword in an incorrect position in the C++ grammar:
#define MEOW 256
struct Base {
virtual const char (&GetBuffer() const)[MEOW] = 0;
};
struct Derived : public Base {
// GCC requires this incorrect syntax...
virtual const char (&GetBuffer() const override)[MEOW];
// ...but the below is the correct syntax, which GCC rejects.
virtual const char (&GetBuffer() const)[MEOW] override;
};
In the C++ Standard, "override" is a virt-specifier in a virt-specifier-seq.
virt-specifier-seq optionally goes after the declarator. After the optional
virt-specifier-seq goes the optional pure-specifier.
Possibly related bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794 (I
don't know whether "-> override" is sensible; just linking this in case that
bug's reporter is correct.)
[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-27 CC||msebor at gcc dot gnu.org Known to work||4.5.4, 5.4.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed. The ICE was introduced by my r231665 in GCC 6.0.0: r231665 | msebor | 2015-12-15 16:04:08 -0500 (Tue, 15 Dec 2015) | 71 lines gcc/cp/ChangeLog: 2015-12-15 Martin Sebor c++/42121 c++/68478 c++/68613 c++/68689 c++/68710 * class.c (walk_subobject_offsets): Avoid assuming type domain is non-null or has an upper bound. (layout_class_type): Include type size in error message. (flexmems_t): New type. (field_nonempty_p, find_flexarrays, diagnose_flexarrays) (check_flexarrays): New functions. (finish_struct_1): Call check_flexarrays. * decl.c (compute_array_index_type): Distinguish flexible array members from zero-length arrays. (grokdeclarator): Reject flexible array members in unions. Avoid rejecting members of incomplete types that are flexible array members. * error.c (dump_type_suffix): Handle flexible array members with null upper bound. * init.c (perform_member_init): Same. * pt.c (instantiate_class_template_1): Allow flexible array members. (tsubst): Handle flexible array members with null upper bound. * typeck2.c (digest_init_r): Warn for initialization of flexible array members. (process_init_constructor_record): Handle flexible array members. gcc/ChangeLog: 2015-12-15 Martin Sebor c++/42121 * tree-chkp.c (chkp_find_bound_slots_1): Handle flexible array members. * tree.c (type_contains_placeholder_1): Avoid assuming type has a non-null domain or an upper bound to handle flexible array members. * varasm.c (output_constructor_regular_field): Same. (output_constructor): Set min_index to integer_zero_node rather than null when a type has no domain to avoid crashing later.
[Bug libstdc++/84580] Equality and relational ops for containers behave differently in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84580 --- Comment #1 from Jonathan Wakely --- I assume all the Debug Mode containers have the same problem.
[Bug libstdc++/84580] New: Equality and relational ops for containers behave differently in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84580
Bug ID: 84580
Summary: Equality and relational ops for containers behave
differently in Debug Mode
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This passes in normal mode but fails the second assertion when compiled with
-D_GLIBCXX_DEBUG
#include
#include
struct foo { };
typedef std::vector vect;
bool operator==(const vect&, const vect&) { return true; }
int main() {
vect v1;
vect v2;
v1.push_back(nullptr);
assert(v1 == v2);
assert(!(v1 != v2));
}
The problem is that in Debug Mode (v1 != v2) doesn't call (v1 == v2) which
would use the custom ::operator== overload.
Instead it calls (v1.base() != v2.base()) which then calls operator==, but with
arguments of type std::__cxx1998::vector, and so won't use the ::operator==
overload.
I think we need to make std::__debug::operator!= use == so that ADL can find
the same overload as would be found in normal mode, and similarly for >, <= and
>= (from Table 77, Optional container operations).
[Bug c/84563] GCC interpretation of C11 atomics (DR 459)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 --- Comment #2 from Ruslan Nikolaev --- Summary (from the mailing list): Pros of the proposed approach: 1. Ability to use guaranteed lock-free double-width atomics (when mcx16 is specified for x86-64, and always for arm64) in more or less portable manner across different supported architectures (without resorting to non-standard extensions or writing separate assembly code for each architecture). Hopefully, the behavior may also be made more or less consistent across different compilers over time. It is already the case for clang/llvm. As mentioned, double-width lock-free atomics have real practical use (ABA tags for pointers). 2. More likely to find a bug immediately if a programmer tries to do something that is not guaranteed by the standard (i.e., getting segfault on read-only memory when using double-width atomic_load). This is true even if mcx16 is not used, as most CPUs have cmpxchg16b, and libatomic will use it.On the other hand, atomic_load implemented through locks may have hard-to-find and debug issues in signal handlers, interrupt contexts, etc when a programmer erroneously assumes that atomic_load is non-blocking 3. For arm64 the corresponding instructions are always available, no need for mcx16 flag or redirection to libatomic at all (libatomic may still keep old implementation for backward compatibility). 4. Faster & easy to analyze code when mcx16 is specified. 5. Ability to tell for sure if the implementation is lock-free by checking corresponding C11 flag when mcx16 is specified. When unspecified, the flag will be false to accommodate the worst case scenario. 6. Consistent behavior everywhere on all platforms regardless of IFFUNC, mcx16 flag, etc. If cmpxchg16b is available, it is always used (platforms that do not support IFFUNC will use function pointers for redirection). The only thing the mcx16 flag changes is removing indirection to libatomic and giving guaranteed lock_free flag for corresponding types. (BTW, in practice, if you use the flag, you should know what you are doing already) 7. Ability to finally deprecate old __sync builtins, and use new and more advanced __atomic everywhere. Cons of the proposed approach: 1. Compiler may place const atomic objects to .rodata. (Avoided by making sure _Atomic objects with the size > 8 are not placed in .rodata + clarifying that casting random .rodata objects for double-width atomics is undefined and is not allowed.) 2. Backward compatibility concerns if used outside glibc/IFFUNC. Most likely, even in this case, not an issue since all calls there are already redirected to libatomic anyway, and statically-linked binaries will not interact with new binaries directly. 3. Read-only memory for atomic_load will not be supported for double-width types. But it is actually better than hiding the problem under the carpet (current behavior is actually even worse because it is inconsistent across different platforms, i.e. different for x86-64 in Linux and arm64). Anyway, it is better to use a lock-based approach explicitly if for whatever reason it is more preferable (read-only memory, performance (?), etc).
[Bug lto/84579] New: __gnu_lto_v1 should be removed when linking with -fno-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579 Bug ID: 84579 Summary: __gnu_lto_v1 should be removed when linking with -fno-lto Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi, When you want to build a project where for some reason you want to use fat LTO objects, but don't want to actually use it a link time (ie when you want to experiment with LTO but still allow to easily disable it), you might end up doing this: gcc -flto -ffat-lto-objects -fPIC -o file.o -c file.c gcc -fno-lto -fPIC -shared -o file.so file.o with gcc 8 though, this leaves the symbol __gnu_lto_v1 which is unexpected to remains in the final shared library: gcc-nm -g file.so 00201020 B __bss_start w __cxa_finalize@@GLIBC_2.2.5 00201020 D _edata 00201028 B _end 0609 T f 060c T _fini w __gmon_start__ 00201021 B __gnu_lto_v1 0508 T _init w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable Would it be possible to trim out __gnu_lto_v1 when we have fat inbound objects, but lto is explicitly deleted with -fno-lto ? Cheers, Romain
[Bug c++/84441] [6/7/8 Regression] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84441 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/84578] New: [6/7/8 Regression] ICE with flexible array member and constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578
Bug ID: 84578
Summary: [6/7/8 Regression] ICE with flexible array member and
constexpr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following (valid?) code snippet triggers an ICE since GCC 6.1.0:
==
struct A
{
constexpr A() : i(), x() {}
int i;
char x[];
};
A a;
==
bug.cc:8:3: in 'constexpr' expansion of 'a.A::A()'
bug.cc:8:3: internal compiler error: in tree_to_uhwi, at tree.c:6817
A a;
^
0x78c097 tree_to_uhwi(tree_node const*)
../../gcc/gcc/tree.c:6817
0x85630b cxx_eval_vec_init_1
../../gcc/gcc/cp/constexpr.c:2891
0x8523c5 cxx_eval_vec_init
../../gcc/gcc/cp/constexpr.c:3011
0x8523c5 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4535
0x854c7d cxx_eval_store_expression
../../gcc/gcc/cp/constexpr.c:3685
0x85232f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4248
0x8528cf cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4552
0x8513f7 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x8513f7 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x852021 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:3898
0x852021 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4643
0x85138d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4647
0x852021 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.c:3898
0x852021 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4643
0x85080f cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1689
0x8513ab cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4170
0x8569f7 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4819
0x859988 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5145
0x8cceaa expand_default_init
../../gcc/gcc/cp/init.c:1901
0x8cceaa expand_aggr_init_1
../../gcc/gcc/cp/init.c:2004
Please submit a full bug report, [etc.]
The code was accepted by GCC 4.5, 4.6, 4.7, 5.
It also triggered an ICE with GCC 4.8, 4.9.
[Bug c++/84559] [7/8 Regression] ICE with constexpr and variable-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84559 Jason Merrill changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|7.4 |8.0 --- Comment #5 from Jason Merrill --- Fixed in GCC 8.
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #4 from Carl Love --- gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p8.c during RTL pass: vregs gcc/testsuite/gcc.target/powerpc/fold-vec-neg-longlong.p9.c during RTL pass: vregs Both tests fixed with mainline commit 258006 on 2/26/2018
[Bug c++/84559] [7/8 Regression] ICE with constexpr and variable-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84559 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Feb 26 21:55:41 2018 New Revision: 258015 URL: https://gcc.gnu.org/viewcvs?rev=258015&root=gcc&view=rev Log: PR c++/84559 - ICE with constexpr VLA. * constexpr.c (ensure_literal_type_for_constexpr_object): Check for constexpr variable with VLA type. Added: trunk/gcc/testsuite/g++.dg/ext/constexpr-vla5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/84558] [6/7 Regression] ICE with invalid constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84558 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |invalid constexpr |invalid constexpr |constructor |constructor --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/84558] [6/7/8 Regression] ICE with invalid constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84558 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Feb 26 21:52:39 2018 New Revision: 258014 URL: https://gcc.gnu.org/viewcvs?rev=258014&root=gcc&view=rev Log: PR c++/84558 * constexpr.c (cxx_eval_vec_init_1): For reuse, treat NULL eltinit like a valid constant initializer. Formatting fixes. * g++.dg/cpp1y/pr84558.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr84558.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 --- Comment #4 from James Clarke --- (In reply to Jim Wilson from comment #2) > rdynamic is a linker option that the compiler ignores, except to pass on to > the linker. As far as the compiler knows, you are building a non-pic > application, and hence the symbol is local. We can't assume that -rdynamic > will be used at compile time, and hence to make this work we must assume > that any local symbol might become global at link time. Ah I see, that explains it. > We can fix this my modifying the ia64_reloc_rw_mask function to return 3 > when non-pic, same as it does when pic, to indicate that local symbols with > relocs aren't read-only. > > I don't have access to ia64 hardware, so I don't have any easy way to test > this. > The symbol ends up in .data.rel.ro.local instead of .data.rel.ro, but > presumably that is OK. That's what happens on hppa which has similar function descriptor behaviour, so that should be fine.
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 --- Comment #3 from Jim Wilson --- Created attachment 43514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43514&action=edit untested patch
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 Ever confirmed|0 |1 --- Comment #2 from Jim Wilson --- rdynamic is a linker option that the compiler ignores, except to pass on to the linker. As far as the compiler knows, you are building a non-pic application, and hence the symbol is local. We can't assume that -rdynamic will be used at compile time, and hence to make this work we must assume that any local symbol might become global at link time. We can fix this my modifying the ia64_reloc_rw_mask function to return 3 when non-pic, same as it does when pic, to indicate that local symbols with relocs aren't read-only. I don't have access to ia64 hardware, so I don't have any easy way to test this. The symbol ends up in .data.rel.ro.local instead of .data.rel.ro, but presumably that is OK.
[Bug c++/84557] ICE with invalid firstprivate variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84557 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83917 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c++/84540] [6/7 Regression] ICE with alignas in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84540 Paolo Carlini changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |alignas in variadic |alignas in variadic |template|template --- Comment #4 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/84540] [6/7/8 Regression] ICE with alignas in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84540 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Feb 26 20:06:40 2018 New Revision: 258012 URL: https://gcc.gnu.org/viewcvs?rev=258012&root=gcc&view=rev Log: /cp 2018-02-26 Paolo Carlini PR c++/84540 * pt.c (tsubst_attributes): Handle correctly tsubst_attribute returning NULL_TREE. (apply_late_template_attributes): Likewise. /testsuite 2018-02-26 Paolo Carlini PR c++/84540 * g++.dg/cpp0x/alignas14.C: New. * g++.dg/cpp0x/alignas15.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alignas14.C trunk/gcc/testsuite/g++.dg/cpp0x/alignas15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84557] ICE with invalid firstprivate variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84557 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Feb 26 19:51:05 2018 New Revision: 258011 URL: https://gcc.gnu.org/viewcvs?rev=258011&root=gcc&view=rev Log: PR c++/84557 * parser.c (cp_parser_omp_var_list_no_open): Only call cp_parser_lookup_name_simple on names satisfying identifier_p. (cp_parser_oacc_routine): Likewise. * g++.dg/gomp/pr84557.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr84557.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84541] ICE with auto in function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84541 --- Comment #2 from Volker Reichelt --- Paolo, you're right. Sorry for the noise. The "-fconcept" parameter is a left-over from the larger testcase where this snippet was derived from. The ICE can be reproduced with GCC 4.9.0 and only needs "-std=c++14" or "-std=c++1y" to be triggered.
[Bug tree-optimization/84577] New: snprintf with null buffer not eliminated when return value is in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84577
Bug ID: 84577
Summary: snprintf with null buffer not eliminated when return
value is in a known range
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The sprintf pass eliminates snprintf calls with a null buffer and zero size
when whose return value is a constant but it does not eliminate calls whose
return value is in some range. Both calls can be eliminated.
$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.c
void f (void)
{
int n = __builtin_snprintf (0, 0, "%hhx", 123); // eliminated
if (n < 0 || 2 < n)
__builtin_abort ();
}
void g (int i)
{
int n = __builtin_snprintf (0, 0, "%hhx", i); // not eliminated but could
be
if (n < 0 || 2 < n)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1957, cgraph_uid=0, symbol_order=0)
f ()
{
[local count: 1073741825]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1961, cgraph_uid=1, symbol_order=1)
g (int i)
{
[local count: 1073741825]:
__builtin_snprintf (0B, 0, "%hhx", i_3(D)); [tail call]
return;
}
[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83917 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Feb 26 19:46:34 2018 New Revision: 258010 URL: https://gcc.gnu.org/viewcvs?rev=258010&root=gcc&view=rev Log: PR debug/83917 * config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME, PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between inclusion of auto-target.h and auto-host.h. (USE_GAS_CFI_DIRECTIVES): Define if not defined already based on __GCC_HAVE_DWARF2_CFI_ASM. (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset, cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push, cfi_pop): Define. * config/i386/cygwin.S: Don't include auto-host.h here, just define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h. (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset, cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove. * config/i386/resms64fx.h: Add cfi_* directives. * config/i386/resms64x.h: Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/cygwin.S trunk/libgcc/config/i386/i386-asm.h trunk/libgcc/config/i386/resms64fx.h trunk/libgcc/config/i386/resms64x.h
[Bug c++/84576] g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84576 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/84559] [7/8 Regression] ICE with constexpr and variable-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84559 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/84551] [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 84551, which changed state. Bug 84551 Summary: [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/84551] [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Feb 26 19:04:42 2018 New Revision: 258009 URL: https://gcc.gnu.org/viewcvs?rev=258009&root=gcc&view=rev Log: PR c++/84551 - ICE with concepts and -g. * parser.c (add_debug_begin_stmt): Do nothing in a concept. Added: trunk/gcc/testsuite/g++.dg/concepts/debug1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/84576] New: g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84576
Bug ID: 84576
Summary: g++: internal compiler error: Segmentation fault
(program cc1plus)
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at gmail dot com
Target Milestone: ---
The following is obviously not a valid C++ program but crashes the compiler:
a(){[](class{
Output:
:1:3: error: ISO C++ forbids declaration of 'a' with no type
[-fpermissive]
a(){[](class{
^
: In function 'int a()':
:1:13: error: types may not be defined in parameter types
a(){[](class{
^
:1:13: error: expected '}' at end of input
:1:13: error: expected ',' or '...' at end of input
:1:13: error: expected ')' at end of input
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/84551] [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 Jason Merrill changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.0
[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84325 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84325 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Mon Feb 26 18:41:56 2018 New Revision: 258008 URL: https://gcc.gnu.org/viewcvs?rev=258008&root=gcc&view=rev Log: PR c++/84325 * tree.c (replace_placeholders_r): Only check TREE_CONSTANT on non-types. * g++.dg/cpp1z/pr84325.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/pr84325.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug target/84575] New: [8 regression] gcc.target/i386/pr84309.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84575 Bug ID: 84575 Summary: [8 regression] gcc.target/i386/pr84309.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r257617 triggers this: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/pr84309.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -mavx -ffat-lto-objects -S -o pr84309.s PASS: gcc.target/i386/pr84309.c (test for excess errors) FAIL: gcc.target/i386/pr84309.c scan-assembler _ZGVcN4v_exp Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell
[Bug libstdc++/84532] [7 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84532 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 7.4 and 8.1
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #15 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #14) > I wonder if this could be addressed with a more reasonable address > computation reassociation. > ISTM that we associating as (x + (y + c)) which seems like a mistake in this > case. > > If we associated as (x + y) + c, then the (x + y) would become a common > subexpression eliminating a bunch of unnecessary address computations. Coming out of SSA for hand_benchmark_cache_ronly(), we seem to be calculating: ((index + 1) * 8) + x ((index + 2) * 8) + x ((index + 3) * 8) + x etc After slsr we have: (index * 8) + x (((index * 8) + 8) + x) index * 8) + 8) + 8) + x) And finally after forwprop4: (index * 8) + x (((index * 8) + 8) + x) (((index * 8) + 16) + x) Are you suggesting we reassociate the above as: ((index * 8) + CONSTANT) + x Is there a preferred place to put this kind of transformation? A separate pass after forwprop4? Much earlier? Is there a pass that already does this kind of juggling? BTW, it seems like a pass like tree-ssa-reassoc, tries to precisely convert: x + (y + constant) INTO (x + CONSTANT) + y which is the opposite of what we want.
[Bug libgomp/84466] [8 regression] libgomp.graphite/force-parallel-8.c fails starting with r257723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84466 Andrey Guskov changed: What|Removed |Added CC||andrey.y.guskov at intel dot com --- Comment #3 from Andrey Guskov --- Confirmed on Intel Silvermont.
[Bug c++/84551] [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r255569.
[Bug c++/84551] [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84551 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-26 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/84574] New: Function return thunks shouldn't be aliased to indirect branch thunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84574
Bug ID: 84574
Summary: Function return thunks shouldn't be aliased to
indirect branch thunks
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
Target Milestone: ---
Target: x86-64
Function return thunks shouldn't be aliased to indirect branch thunks
since indirect branch thunks are placed in COMDAT section and a COMDAT
section with indirect branch may not have return thunk:
[hjl@gnu-skx-1 xxx]$ cat x.i
void
foo (void)
{
}
[hjl@gnu-skx-1 xxx]$ cat y.i
extern void foo (void);
int
main ()
{
foo ();
return 0;
}
[hjl@gnu-skx-1 xxx]$ cat thunk.S
.section
.text.__x86_indirect_thunk,"axG",@progbits,__x86_indirect_thunk,comdat
.globl __x86_indirect_thunk
.hidden __x86_indirect_thunk
.type __x86_indirect_thunk, @function
__x86_indirect_thunk:
.LFB1:
.cfi_startproc
call.LIND3
.LIND2:
lfence
jmp .LIND2
.LIND3:
lea 8(%rsp), %rsp
ret
.cfi_endproc
.LFE1:
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 xxx]$ make
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/-c -o thunk.o thunk.S
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2
-mindirect-branch=thunk -c y.i
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2
-mindirect-branch=thunk -mfunction-return=thunk -c x.i
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2
-mindirect-branch=thunk -o x thunk.o y.o x.o
/usr/local/bin/ld: x.o: in function `foo':
x.i:(.text+0x1): undefined reference to `__x86_return_thunk'
collect2: error: ld returned 1 exit status
make: *** [Makefile:30: x] Error 1
[hjl@gnu-skx-1 xxx]$
[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84468
--- Comment #14 from Martin Sebor ---
(In reply to Romain Geissler from comment #13)
Ah, right. It's not skipping over debug statements. That's easier to fix than
pr84561. This should do it:
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c (revision 257963)
+++ gcc/tree-ssa-strlen.c (working copy)
@@ -1856,8 +1856,21 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi
avoid the truncation warning. */
gsi_next_nondebug (&gsi);
gimple *next_stmt = gsi_stmt (gsi);
+ if (!next_stmt)
+{
+ /* When there is no statement in the same basic block check
+the immediate successor block. */
+ if (basic_block bb = gimple_bb (stmt))
+ {
+ basic_block nextbb
+ = EDGE_COUNT (bb->succs) ? EDGE_SUCC (bb, 0)->dest : NULL;
+ gimple_stmt_iterator it = gsi_start_bb (nextbb);
+ gsi_next_nondebug (&it);
+ next_stmt = gsi_stmt (it);
+ }
+}
- if (!gsi_end_p (gsi) && is_gimple_assign (next_stmt))
+ if (next_stmt && is_gimple_assign (next_stmt))
{
tree lhs = gimple_assign_lhs (next_stmt);
tree_code code = TREE_CODE (lhs);
[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422 --- Comment #3 from Carl Love --- gcc/testsuite/gcc.target/powerpc/sse2-pmuludq-1.c Test requres Power 8 as a minimum. Compiling with -mcpu=power7 generates an ICE but the test requires Power8. So the ICE shouldn't be an issue under normal testing conditions.
[Bug libstdc++/84532] [7 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84532 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon Feb 26 17:09:34 2018 New Revision: 258004 URL: https://gcc.gnu.org/viewcvs?rev=258004&root=gcc&view=rev Log: PR libstdc++/84532 prevent unwrapping of reference_wrapper arguments Backport from mainline 2018-02-23 Jonathan Wakely PR libstdc++/84532 * include/std/thread (thread::__make_invoker): Construct tuple directly instead of using make_tuple. * testsuite/30_threads/async/84532.cc: New. * testsuite/30_threads/thread/84532.cc: New. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/30_threads/async/84532.cc branches/gcc-7-branch/libstdc++-v3/testsuite/30_threads/thread/84532.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/std/thread
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. The warning suppression code sees the following statements: : _8 = &b_3(D)->_a; _9 = _8; ... _6 = &MEM[(struct String *)_1]._string; __builtin_strncpy (_6, "123", len_7); MEM[(struct String *)_1]._string[len_7] = 0; but it doesn't have the smarts to figure out that _6 is &MEM[(struct String *)_1]._string.
[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Feb 26 17:06:07 2018 New Revision: 258003 URL: https://gcc.gnu.org/viewcvs?rev=258003&root=gcc&view=rev Log: PR c++/84447 - ICE with deleted inherited ctor with default arg. * call.c (build_over_call): Handle deleted functions in one place. Added: trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor31.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/81589] Possible False-Positive with decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81589 --- Comment #7 from Jason Merrill --- Author: jason Date: Mon Feb 26 17:06:02 2018 New Revision: 258002 URL: https://gcc.gnu.org/viewcvs?rev=258002&root=gcc&view=rev Log: PR c++/81589 - error with is_trivially_constructible * g++.dg/ext/is_trivially_constructible6.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C
[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 James Clarke changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com --- Comment #1 from James Clarke --- This is a GCC bug. The function "d" here is non-static and thus exported as a dynamic symbol. On ia64, function descriptors for dynamic symbols are always allocated by the dynamic linker at runtime for canonicalisation (yes, there are other things you could do, but this is what was chosen), and therefore are not link-time constants, even though the contents of this function descriptor can be determined at link-time (since this is linking an executable). GCC should instead be placing this in a relro section like you said.
[Bug target/84039] x86 retpolines and CFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039
--- Comment #3 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Feb 26 17:00:46 2018
New Revision: 258001
URL: https://gcc.gnu.org/viewcvs?rev=258001&root=gcc&view=rev
Log:
i386: Add TARGET_INDIRECT_BRANCH_REGISTER
For
---
struct C {
virtual ~C();
virtual void f();
};
void
f (C *p)
{
p->f();
p->f();
}
---
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
_Z1fP1C:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
jmp .LIND1
.LIND0:
pushq 16(%rax)
jmp __x86_indirect_thunk
.LIND1:
call.LIND0
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc
x86-64 is supposed to have asynchronous unwind tables by default, but
there is nothing that reflects the change in the (relative) frame
address after .LIND0. That region really has to be moved outside of
the .cfi_startproc/.cfi_endproc bracket.
This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
branch via register whenever -mindirect-branch= is used. Now,
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:
_Z1fP1C:
.LFB0:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
movq16(%rax), %rax
call__x86_indirect_thunk_rax
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc
so that "-mindirect-branch=thunk-extern" is equivalent to
"-mindirect-branch=thunk-extern -mindirect-branch-register", which is
used by Linux kernel.
gcc/
PR target/84039
* config/i386/constraints.md (Bs): Replace
ix86_indirect_branch_register with
TARGET_INDIRECT_BRANCH_REGISTER.
(Bw): Likewise.
* config/i386/i386.md (indirect_jump): Likewise.
(tablejump): Likewise.
(*sibcall_memory): Likewise.
(*sibcall_value_memory): Likewise.
Peepholes of indirect call and jump via memory: Likewise.
(*sibcall_GOT_32): Disallowed for TARGET_INDIRECT_BRANCH_REGISTER.
(*sibcall_value_GOT_32): Likewise.
* config/i386/i386.opt: Likewise.
* config/i386/predicates.md (indirect_branch_operand): Likewise.
(GOT_memory_operand): Likewise.
(call_insn_operand): Likewise.
(sibcall_insn_operand): Likewise.
(GOT32_symbol_operand): Likewise.
* config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.
gcc/testsuite/
PR target/84039
* gcc.target/i386/indirect-thunk-1.c: Updated.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-5.c: Likewise.
* gcc.target/i386/indirect-thunk-6.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-1.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-2.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-3.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-5.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-6.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-5.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-6.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* gcc.target/i386/ret-thunk-9.c: Likewise.
* gcc.target/i386/ret-thunk-10.c: Likewise.
* gcc.target/i386/ret-thunk-11.c:
[Bug c++/84560] Internal error in std::function with std::memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84560 --- Comment #3 from Martin Sebor --- Created attachment 43513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43513&action=edit Reduced translation unit. Bisecting the reduced translation unit points to r231952 (gcc 6.0.0) as the revision that introduced the ICE. r231952 | jason | 2015-12-24 22:24:51 -0500 (Thu, 24 Dec 2015) | 3 lines PR c++/69005 * call.c (add_template_candidate_real): Don't try to deduce X(X). Before that, GCC errors out with: pr84560.C: In instantiation of ‘struct __result_of_impl&>’: pr84560.C:77:61: required from ‘struct __invoke_result&>’ pr84560.C:79:66: required from ‘class result_of&()>’ pr84560.C:120:102: required by substitution of ‘template function<_Res(_ArgTypes ...)>::function(_Functor) [with _Functor = function; = void; = ]’ pr84560.C:136:9: required from here pr84560.C:75:57: error: no matching function for call to ‘__result_of_impl&>::_S_test(int)’ typedef decltype(_S_test<_Functor, _ArgTypes...>(0)) type; ~~~^~~ pr84560.C:72:147: note: candidate: template static __result_of_success()((declval<_Args>)()...)), __invoke_other> __result_of_other_impl::_S_test(int) ()(declval<_Args>()...) ), __invoke_other> _S_test(int);
[Bug rtl-optimization/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
--- Comment #37 from Segher Boessenkool ---
> Propchange: trunk/gcc/testsuite/gcc.c-torture/execute/20180226-1.c
> ('svn:special' added)
This is a symlink to /home/eric/build/gcc/mips-linux/pr83496.c which
does not work on most people's machines ;-)
[Bug c++/84573] New: missing warning on an uninstantiated function template returning T with no return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84573
Bug ID: 84573
Summary: missing warning on an uninstantiated function template
returning T with no return statement
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
G++ diagnoses a return statement with a value in a function template returning
void even when the template is never instantiated, but it doesn't issue a
warning when a function template declared to return the template argument T.
Since the only valid specialization of such a template is one where T = void
it's likely that the missing return statement is a mistake that issuing a
warning for would be helpful.
$ cat z.C && gcc -Wall -Wextra -S z.C
template
void f () { return 1; } // error: return-statement with a value
template
T g () { } // missing warning
z.C: In function ‘void f()’:
z.C:2:20: error: return-statement with a value, in function returning ‘void’
[-fpermissive]
void f () { return 1; } // error: return-statement with a value
^
[Bug rtl-optimization/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #36 from Eric Botcazou --- Fixed on mainline and 7 branch.
[Bug rtl-optimization/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496 --- Comment #35 from Eric Botcazou --- Author: ebotcazou Date: Mon Feb 26 16:39:41 2018 New Revision: 258000 URL: https://gcc.gnu.org/viewcvs?rev=258000&root=gcc&view=rev Log: PR rtl-optimization/83496 * reorg.c (steal_delay_list_from_target): Change REDUNDANT array from booleans to RTXes. Call fix_reg_dead_note on every non-null element. (steal_delay_list_from_fallthrough): Call fix_reg_dead_note on a redundant insn, if any. (relax_delay_slots): Likewise. (update_reg_unused_notes): Rename REDUNDANT_INSN to OTHER_INSN. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20180226-1.c - copied unchanged from r257998, trunk/gcc/testsuite/gcc.c-torture/execute/20180226-1.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/reorg.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
--- Comment #34 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Feb 26 16:29:30 2018
New Revision: 257996
URL: https://gcc.gnu.org/viewcvs?rev=257996&root=gcc&view=rev
Log:
PR rtl-optimization/83496
* reorg.c (steal_delay_list_from_target): Change REDUNDANT array from
booleans to RTXes. Call fix_reg_dead_note on every non-null element.
(steal_delay_list_from_fallthrough): Call fix_reg_dead_note on a
redundant insn, if any.
(relax_delay_slots): Likewise.
(update_reg_unused_notes): Rename REDUNDANT_INSN to OTHER_INSN.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20180226-1.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reorg.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gcc.c-torture/execute/20180226-1.c
('svn:special' added)
[Bug target/84176] Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84176 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed for GCC 8.
[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 84176, which changed state. Bug 84176 Summary: Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84176 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/84072] [meta-bug] -mindirect-branch=thunk issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072 Bug 84072 depends on bug 84176, which changed state. Bug 84176 Summary: Need a different thunk for -mindirect-branch=thunk-extern -fcf-protection -mcet https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84176 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- Hopefully fixed for real this time.
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Mon Feb 26 16:17:00 2018 New Revision: 257995 URL: https://gcc.gnu.org/viewcvs?rev=257995&root=gcc&view=rev Log: Make fix for PR 83965 handle SLP reduction chains This patch prevents pattern-matching of fold-left SLP reduction chains, which the previous patch for 83965 didn't handle properly. It only stops the last statement in the group from being matched, but that's enough to cause the group to be dissolved later. A better fix would be to put all the information about the reduction on the the first statement in the reduction chain, so that every statement in the group can tell what the group is doing. That doesn't seem like stage 4 material though. 2018-02-26 Richard Sandiford gcc/ PR tree-optimization/83965 * tree-vect-patterns.c (vect_reassociating_reduction_p): Assume that grouped statements are part of a reduction chain. Return true if the statement is not marked as a reduction itself but is part of a group. (vect_recog_dot_prod_pattern): Don't check whether the statement is part of a group here. (vect_recog_sad_pattern): Likewise. (vect_recog_widen_sum_pattern): Likewise. gcc/testsuite/ PR tree-optimization/83965 * gcc.dg/vect/pr83965-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr83965-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug ada/84277] [8 Regression] A lot of new acats testsuite failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84277 --- Comment #11 from Eric Botcazou --- > What are the "acats tests without -fno-reorder-blocks-and-partition still at > 314 failures." failures? Runtime failures, or just failing to assemble or > failing to link? How do non-ada tests with -freorder-blocks-and-partition > look on this target? Perhaps block & partition reordering needs to be > disabled, either on the target for all compilation, or for Ada only, though > of course it would be nice to see why. Is that a regression though? -freorder-blocks-and-partition is just incompatible with SEH at the moment and, since it's now the default, the end result is obviously a regression. I have the beginning of a fix but it's still not sufficient.
[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84325 --- Comment #7 from Marek Polacek --- It might still be invalid, though, in which case it wouldn't make sense for this to be P1.
[Bug c++/84325] [8 Regression] internal compiler error, in cxx_eval_constant_expression gcc/cp/constexpr.c:4740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84325
--- Comment #6 from Marek Polacek ---
If I tweak the testcase like this:
struct seconds { int i_{0}; constexpr seconds (int) {} };
template constexpr seconds operator""_s() {
return seconds(0);
}
constexpr seconds operator""_s(long double i) {
return seconds(0);
}
template
struct Param {
constexpr static inline seconds time_to_wait{10_s};
};
struct Empty {};
Param p;
then it's accepted by clang++ and ICEs the same. And if I apply this then it's
accepted by G++, too:
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3091,7 +3091,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees,
void* data_)
replace_placeholders_t *d = static_cast(data_);
tree obj = d->obj;
- if (TREE_CONSTANT (*t))
+ if (!TYPE_P (*t) && TREE_CONSTANT (*t))
{
*walk_subtrees = false;
return NULL_TREE;
[Bug ada/84277] [8 Regression] A lot of new acats testsuite failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84277 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- What are the "acats tests without -fno-reorder-blocks-and-partition still at 314 failures." failures? Runtime failures, or just failing to assemble or failing to link? How do non-ada tests with -freorder-blocks-and-partition look on this target? Perhaps block & partition reordering needs to be disabled, either on the target for all compilation, or for Ada only, though of course it would be nice to see why. Is that a regression though? I mean, has -freorder-blocks-and-partition ever worked on this target for Ada, or just nobody tested it before?
[Bug ada/84277] [8 Regression] A lot of new acats testsuite failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84277 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4
[Bug c++/84296] [8 Regression] ICE in finish_member_declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84296 Jakub Jelinek changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #6 from Jakub Jelinek --- *** Bug 84461 has been marked as a duplicate of this bug. ***
[Bug c++/84461] [8 regression] openjdk-10 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84461 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #6 from Jakub Jelinek --- Indeed, fixed with r257538, introduced with r256866. *** This bug has been marked as a duplicate of bug 84296 ***
[Bug c++/84540] [6/7/8 Regression] ICE with alignas in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84540 Paolo Carlini changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- This is valid, and doesn't seem hard to fix.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- > Is it guaranteed that no target puts calls into delay slots? I think that reorg doesn't put instructions with delay slots into delay slots.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Mon Feb 26 15:40:18 2018 New Revision: 257993 URL: https://gcc.gnu.org/viewcvs?rev=257993&root=gcc&view=rev Log: PR debug/84545 * final.c (rest_of_clean_state): Also look for calls inside sequences. Modified: trunk/gcc/ChangeLog trunk/gcc/final.c
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 --- Comment #3 from Jakub Jelinek --- Created attachment 43512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43512&action=edit gcc8-pr84565.patch This works for me.
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 --- Comment #2 from Jakub Jelinek --- The aarch64_cmpeqdf instruction no longer matches, because the CONST0_RTX (DFmode) operand doesn't match the aarch64_simd_reg_or_zero predicate. Either aarch64_simd_reg_or_zero predicate should use aarch64_simd_or_scalar_imm_zero rather than aarch64_simd_imm_zero, or the aarch64_cmp pattern with VHSDF_HSDF needs to use some other predicate at least for the scalar modes.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545 --- Comment #6 from Jakub Jelinek --- Is it guaranteed that no target puts calls into delay slots?
[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Feb 26 15:29:30 2018 New Revision: 257992 URL: https://gcc.gnu.org/viewcvs?rev=257992&root=gcc&view=rev Log: i386: Update -mfunction-return= for return with pop When -mfunction-return= is used, simple_return_pop_internal should pop return address into ECX register, adjust stack by bytes to pop from stack and jump to the return thunk via ECX register. Tested on i686 and x86-64. PR target/84530 * config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New prototype. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.c (indirect_return_via_cx): New. (indirect_return_via_cx_bnd): Likewise. (indirect_thunk_name): Handle return va CX_REG. (output_indirect_thunk_function): Create alias for __x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd. (ix86_output_indirect_jmp): Remove the bool argument. (ix86_output_indirect_function_return): New function. (ix86_split_simple_return_pop_internal): Likewise. * config/i386/i386.md (*indirect_jump): Don't pass false to ix86_output_indirect_jmp. (*tablejump_1): Likewise. (simple_return_pop_internal): Change it to define_insn_and_split. Call ix86_split_simple_return_pop_internal to split it for -mfunction-return=. (simple_return_indirect_internal): Call ix86_output_indirect_function_return instead of ix86_output_indirect_jmp. gcc/testsuite/ PR target/84530 * gcc.target/i386/ret-thunk-22.c: New test. * gcc.target/i386/ret-thunk-23.c: Likewise. * gcc.target/i386/ret-thunk-24.c: Likewise. * gcc.target/i386/ret-thunk-25.c: Likewise. * gcc.target/i386/ret-thunk-26.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/ret-thunk-22.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-23.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-24.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-25.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/84461] [8 regression] openjdk-10 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84461 Andreas Schwab changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Schwab --- Fixed between r257516 and now.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545
--- Comment #5 from Eric Botcazou ---
> Do the:
> if (CALL_P (insn))
> {
> rtx note = find_reg_note (insn, REG_CALL_ARG_LOCATION, NULL_RTX);
> if (note)
> remove_note (insn, note);
> }
> also for insns inside a SEQUENCE?
Yes, although doing it only for the first insn therein is sufficient.
[Bug c/84563] GCC interpretation of C11 atomics (DR 459)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563 --- Comment #1 from Ruslan Nikolaev --- See also discussion in the gcc mailing list
[Bug c++/84541] ICE with auto in function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84541 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 Blocks|67491 | Summary|[8 Regression] ICE with |ICE with auto in function |auto in function parameter |parameter Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I don't think -fconcepts has anything to do with this and it doesn't look like an [8 regression], in fact I can reproduce it with -std=c++14 even in gcc-5-branch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/84533] [7 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 Paolo Carlini changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |duplicate enum value|duplicate enum value --- Comment #3 from Paolo Carlini --- Fixed in trunk.
[Bug c++/84533] [7/8 Regression] ICE with duplicate enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Feb 26 15:00:44 2018 New Revision: 257991 URL: https://gcc.gnu.org/viewcvs?rev=257991&root=gcc&view=rev Log: /cp 2018-02-26 Paolo Carlini PR c++/84533 * decl.c (redeclaration_error_message): Don't try to use DECL_DECLARED_CONSTEXPR_P on CONST_DECLs. /testsuite 2018-02-26 Paolo Carlini PR c++/84533 * g++.dg/cpp1z/pr84533.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/pr84533.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/84565] [8 Regression] ICE in extract_insn, at recog.c:2304 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84565 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-26 CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Version|unknown |8.0 Summary|ICE in extract_insn, at |[8 Regression] ICE in |recog.c:2304 on aarch64 |extract_insn, at ||recog.c:2304 on aarch64 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r256612.
[Bug c++/84461] [8 regression] openjdk-10 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
What g++ options? I can't reproduce either with -O0 -std={c++11,c++14} or
-std=c++14 -O2 -g.
[Bug debug/84545] [8 regression] FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84545
--- Comment #4 from Jakub Jelinek ---
Do the:
if (CALL_P (insn))
{
rtx note = find_reg_note (insn, REG_CALL_ARG_LOCATION, NULL_RTX);
if (note)
remove_note (insn, note);
}
also for insns inside a SEQUENCE?
[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84548 --- Comment #22 from Dmitry G. Dyachenko --- (In reply to Martin Liška from comment #20) ... > Isn't that > an old data file you forgot to remove? I'll rebuild all and 'll report
