[Bug debug/90946] New: gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90946
Bug ID: 90946
Summary: gcc generates wrong debug information at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It affects the trunk at "-O3". The expected output is "105487". However, at
-O3, it prints "40369".
Bisect points to r270902.
$ gcc-trunk -v
gcc version 10.0.0 20190619 (experimental) [trunk revision 272472] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Correct output#
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40052d: file abc.c, line 30.
Breakpoint 1, g (j=1) at abc.c:30
30 optimize_me_not();
$1 = 105487
#Wrong output#
$ gcc-trunk -g abc.c outer.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400396: file abc.c, line 30.
Breakpoint 1, g (j=1) at abc.c:30
30 optimize_me_not();
$1 = 40369
$ cat abc.c
static short a = 8;
int b, f, h;
int *c;
volatile int d;
int e(j) {}
static char g(j) {
unsigned short k;
int l_756 = 40369, i = 0;
int *l = _756;
for (; i < 4; i++)
f = 4071609;
if (f) {
int m[1];
if (j)
;
else {
int **n =
*n = e(_756);
**n = h;
**n |= 0;
}
} else {
k = b;
*c = k;
h &= 8;
}
d;
if (a) {
*l = 105487;
optimize_me_not();
return 8;
}
int o =
}
int main() { g(1); }
$ cat outer.c
void optimize_me_not() {}
$ cat cmds
b 30
r
p l_756
kill
q
[Bug tree-optimization/90917] Propagate constants into loads if dominated by str(n)cmp/memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90917
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-06-20
CC||msebor at gcc dot gnu.org
Blocks||83819
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
My hope is to ultimately fold the following (and the snprintf equivalents), as
part of the solution for pr83431.
void f (const char *s)
{
int n = __builtin_strlen (s);
if (n == __builtin_strlen ("123"))
if (3 != __builtin_strlen (s))
__builtin_abort ();
}
Propagating the strings themselves is more challenging, but might be doable at
least in the simple cases. So confirmed.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 --- Comment #3 from Andrew Pinski --- (In reply to zhonghao from comment #2) > A related code sample: > gcc also accepts it, although x->value is private. No that is not related at all. In fact it is only rejected when D::verify is instantiated. Unlike the original code x is dependent in this example. In the original code/example the type of c() is non-dependent. >BTW, I constructed a related code sample: No and that is not related at all either.
[Bug c++/57868] misleading location for invalid variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57868 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925
--- Comment #2 from zhonghao at pku dot org.cn ---
A related code sample:
class A
{
virtual int String ();
};
class F: public A { };
template < typename V > class G
{
private: V value;
};
class D
{
template < int N > void Verify() {
G* x = 0;
F& name = x->value;
name.String();
}
};
gcc also accepts it, although x->value is private.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943
--- Comment #2 from Barry Revzin ---
What if we did something like (using pretty names for a sec):
template
struct _Extra_visit_slot_needed
{
template
static bool_constant<__never_valueless<_Types...>()>
__impl(const variant<_Types...>&);
static false_type __impl(...);
using _Variant_never_valueless = decltype(__impl(declval<_Variant>()));
static constexpr bool value =
(is_same_v<_Maybe_variant_cookie, __variant_cookie>
|| is_same_v<_Maybe_variant_cookie, __variant_idx_cookie>)
&& !_Variant_never_valueless::value;
};
This should (modulo typos) work for real variant instantiations and also
anything that inherits from some variant instantiation?
[Bug c++/64235] Internal compiler error (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64235 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01185.html
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943
Jonathan Wakely changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Jonathan Wakely ---
This is all it takes to compile your example:
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -795,7 +795,7 @@ namespace __variant
template
struct _Extra_visit_slot_needed
{
- template struct _Variant_never_valueless;
+ template struct _Variant_never_valueless : false_type { };
template
struct _Variant_never_valueless>
This just assumes that unrecognized types are not never-valueless variants,
which means some extra code gets generated to handle the valueless case even if
your variant base class will never be valueless.
I haven't considered if anything else would break by doing that.
[Bug fortran/77632] [F08] Pointer initialisation does not quite work with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77632 kargl at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Ugh. Looked at this briefly. AFAIK, the following is legal code: program foo implicit none real, target :: a real, pointer :: b => a if (associated(b, a) .eqv. .false.) stop 2 end program foo This produces the wonderfully bad result: troutmask:sgk[296] gfcx -c a.f90 f951: internal compiler error: in get, at cgraph.h:424 0x714635 symtab_node::get(tree_node const*) ../../gccx/gcc/cgraph.h:424 0x714635 varpool_node::get(tree_node const*) ../../gccx/gcc/cgraph.h:2617 0x714635 varpool_node::get_create(tree_node*) ../../gccx/gcc/varpool.c:146 0x9c4667 record_reference ../../gccx/gcc/cgraphbuild.c:82 0x9c4667 record_reference ../../gccx/gcc/cgraphbuild.c:48 0x10bebd5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gccx/gcc/tree.c:12151 0x9c4e95 record_references_in_initializer(tree_node*, bool) ../../gccx/gcc/cgraphbuild.c:386 0x10fda2f varpool_node::analyze() ../../gccx/gcc/varpool.c:528 0x9cabff analyze_functions ../../gccx/gcc/cgraphunit.c:1180 0x9cbc63 symbol_table::finalize_compilation_unit() ../../gccx/gcc/cgraphunit.c:2833 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug libstdc++/90920] [9/10 Regression] ABI incompatibility in std::rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90920 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed Jun 19 22:57:02 2019 New Revision: 272489 URL: https://gcc.gnu.org/viewcvs?rev=272489=gcc=rev Log: PR libstdc++/90920 restore previous checks for empty ranges The change in r263433 broke the contract of the __rotate functions, by no longer accepting empty ranges. That means that callers which inlined the old version of std::rotate (without checks) that end up linking to a new definition of std::__rotate (also without checks) could perform a divide by zero and crash. This restores the old contract of the __rotate overloads. PR libstdc++/90920 partially revert r263433 * include/bits/stl_algo.h (__rotate): Restore checks for empty ranges. (rotate): Remove checks. * testsuite/25_algorithms/rotate/90920.cc: New test. Added: trunk/libstdc++-v3/testsuite/25_algorithms/rotate/90920.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/90945] Enhancement: Have pretty printer for std::vector return bool values for elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90945 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed Jun 19 22:57:06 2019 New Revision: 272490 URL: https://gcc.gnu.org/viewcvs?rev=272490=gcc=rev Log: Have std::vector printer's iterator return bool for vector Have the pretty-printer for 'std::vector' return a value of type 'bool' rather than an 'int'. This way, the type is clear and that can be used for better display and a 'gdb.Value' constructed from the returned value will have type 'bool' again, not e.g. 'long long' as happened previously (at least with GDB 8.2.1 on amd64). 2019-06-19 Michael Weghorn Jonathan Wakely PR libstdc++/90945 * python/libstdcxx/v6/printers.py (StdVectorPrinter._iterator): Use values of type bool for vector elements. * testsuite/libstdc++-prettyprinters/simple.cc: Test vector. * testsuite/libstdc++-prettyprinters/simple11.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc
[Bug tree-optimization/90626] fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Jun 19 21:46:09 2019 New Revision: 272487 URL: https://gcc.gnu.org/viewcvs?rev=272487=gcc=rev Log: PR tree-optimization/90626 gcc/ChangeLog: * tree-ssa-strlen.c (strxcmp_unequal): Fix typos. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug c++/64235] Internal compiler error (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64235 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Wed Jun 19 21:27:45 2019 New Revision: 272486 URL: https://gcc.gnu.org/viewcvs?rev=272486=gcc=rev Log: PR c++/60364 - noreturn after first decl not diagnosed. * attribs.c (get_attribute_namespace): No longer static. (decl_attributes): Avoid shadowing. Preserve the C++11 form for C++11 attributes. (attr_noreturn_exclusions): Make it extern. * attribs.h (get_attribute_namespace): Declare. * tree-inline.c (function_attribute_inlinable_p): Use get_attribute_name. * c-attribs.c (handle_noreturn_attribute): No longer static. * c-common.h (handle_noreturn_attribute, attr_noreturn_exclusions): Declare. * c-format.c (check_function_format): Use get_attribute_name. * decl.c (duplicate_decls): Give an error when a function is declared [[noreturn]] after its first declaration. * parser.c (cp_parser_std_attribute): Don't treat C++11 noreturn attribute as equivalent to GNU's. * tree.c (std_attribute_table): Add noreturn. * g++.dg/warn/noreturn-8.C: New test. * g++.dg/warn/noreturn-9.C: New test. * g++.dg/warn/noreturn-10.C: New test. * g++.dg/warn/noreturn-11.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/noreturn-10.C trunk/gcc/testsuite/g++.dg/warn/noreturn-11.C trunk/gcc/testsuite/g++.dg/warn/noreturn-8.C trunk/gcc/testsuite/g++.dg/warn/noreturn-9.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/attribs.h trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-format.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 90626, which changed state. Bug 90626 Summary: fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90626] fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Martin Sebor --- Patch committed in r272485.
[Bug tree-optimization/90626] fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626 --- Comment #1 from Martin Sebor --- Author: msebor Date: Wed Jun 19 20:37:41 2019 New Revision: 272485 URL: https://gcc.gnu.org/viewcvs?rev=272485=gcc=rev Log: PR tree-optimization/90626 - fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal gcc/ChangeLog: PR tree-optimization/90626 * tree-ssa-strlen.c (strxcmp_unequal): New function. (handle_builtin_string_cmp): Call it. gcc/testsuite/ChangeLog: PR tree-optimization/90626 * gcc.dg/strlenopt-65.c: New test. * gcc.dg/strlenopt-66.c: New test. * gcc.dg/strlenopt.h (strcmp, strncmp): Declare. Added: trunk/gcc/testsuite/gcc.dg/strlenopt-65.c trunk/gcc/testsuite/gcc.dg/strlenopt-66.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt.h trunk/gcc/tree-ssa-strlen.c
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #4 from Martin Sebor ---
Yes, the problem is that triviality isn't sufficient to decide whether the
transformation can be enabled. I think we need to check whether the type has a
trivial default ctor. Maybe like this:
--- gcc/cp/decl.c (revision 272482)
+++ gcc/cp/decl.c (working copy)
@@ -5853,7 +5853,7 @@ reshape_init_array_1 (tree elt_type, tree max_inde
break;
}
- if (sized_array_p && trivial_type_p (elt_type))
+ if (sized_array_p && type_has_nontrivial_default_init (elt_type))
{
/* Strip trailing zero-initializers from an array of a trivial
type of known size. They are redundant and get in the way
[Bug middle-end/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 --- Comment #4 from Christophe Lyon --- Created attachment 46505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46505=edit open62541.i.xz preprocessed
[Bug translation/90157] aarch64: unnecessary abbreviation in diagnostic: arg instead of argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90157 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Martin Sebor --- Fixed in r271338.
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #15 from Martin Sebor --- Fixed in r271971.
[Bug translation/90152] untranslated strings in print_z_candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90152 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Martin Sebor --- Fixed in r271338.
[Bug translation/90156] add linter check suggesting to replace %<%s%> with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90156 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 Severity|normal |enhancement --- Comment #4 from Martin Sebor --- GCC 10 adds a new internal warning, -Wformat-diag, to detect this and a number of other issues in the formatting and spelling of diagnostic messages.
[Bug translation/90156] add linter check suggesting to replace %<%s%> with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90156 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Jun 19 19:08:24 2019 New Revision: 272483 URL: https://gcc.gnu.org/viewcvs?rev=272483=gcc=rev Log: PR translation/90156 - add linter check suggesting to replace %<%s%> with %qs gcc/c-family/ChangeLog: PR translation/90156 * c-format.c (function_format_info::format_type): Adjust type. (function_format_info::is_raw): New member. (decode_format_type): Adjust signature. Handle "raw" diag attributes. (decode_format_attr): Adjust call to decode_format_type. Avoid a redundant call to convert_format_name_to_system_name. Avoid abbreviating the word "arguments" in a diagnostic. (format_warning_substr): New function. (avoid_dollar_number): Quote dollar sign in a diagnostic. (finish_dollar_format_checking): Same. (check_format_info): Same. (struct baltoks_t): New. (c_opers, c_keywords, cxx_keywords, badwords, contrs): New arrays. (maybe_diag_unbalanced_tokens, check_tokens, check_plain): New functions. (check_format_info_main): Call check_plain. Use baltoks_t. Call maybe_diag_unbalanced_tokens. (handle_format_attribute): Spell out the word "arguments" in a diagnostic. gcc/testsuite/ChangeLog: PR translation/90156 * gcc.dg/format/gcc_diag-11.c: Enable. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/format/gcc_diag-11.c
[Bug libstdc++/90945] Enhancement: Have pretty printer for std::vector return bool values for elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90945 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Jonathan Wakely --- Patches should be sent to the mailing lists (which you've already done) not bugzilla, so I'll close this and respond on the list.
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #13) > Author: kargl > Date: Wed Jun 19 18:18:40 2019 > New Revision: 272482 > > URL: https://gcc.gnu.org/viewcvs?rev=272482=gcc=rev > Log: > 2019-06-19 Steven G. Kargl > > PR fortran/69499 > * match.c (gfc_match_select_type): SELECT TYPE is an executable > statement, and cannot appear in MODULE or SUBMODULE scope. > > 2019-06-19 Steven G. Kargl > > PR fortran/69499 > * gfortran.dg/pr69499.f90: New test. > * gfortran.dg/module_error_1.f90: Update dg-error string. > > Added: > trunk/gcc/testsuite/gfortran.dg/pr69499.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/match.c > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gfortran.dg/module_error_1.f90 This fixes the code in comment #3. I have not decided yet whether to back port the patch.
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #13 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 19 18:18:40 2019 New Revision: 272482 URL: https://gcc.gnu.org/viewcvs?rev=272482=gcc=rev Log: 2019-06-19 Steven G. Kargl PR fortran/69499 * match.c (gfc_match_select_type): SELECT TYPE is an executable statement, and cannot appear in MODULE or SUBMODULE scope. 2019-06-19 Steven G. Kargl PR fortran/69499 * gfortran.dg/pr69499.f90: New test. * gfortran.dg/module_error_1.f90: Update dg-error string. Added: trunk/gcc/testsuite/gfortran.dg/pr69499.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/module_error_1.f90
[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69398 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 19 18:04:46 2019 New Revision: 272481 URL: https://gcc.gnu.org/viewcvs?rev=272481=gcc=rev Log: 2019-06-19 Steven G. Kargl PR fortran/69398 * decl.c (attr_decl): Check for duplicate DIMENSION attribute for a CLASS entity. 2019-06-19 Steven G. Kargl PR fortran/69398 * gfortran.dg/pr69398.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr69398.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/90941] [rfe] attribute to specify write-once static variable for early-initialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81009 --- Comment #2 from Martin Sebor --- Bug 81009 tracks the enhancement of making the alias-analysis const-aware.
[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87907 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Jun 19 17:58:54 2019 New Revision: 272480 URL: https://gcc.gnu.org/viewcvs?rev=272480=gcc=rev Log: 2019-06-19 Steven G. Kargl PR fortran/87907 * resolve.c (resolve_contained_fntype): Do not dereference a NULL pointer. 2019-06-19 Steven G. Kargl PR fortran/87907 * gfortran.dg/pr87907.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr87907.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/90941] [rfe] attribute to specify write-once static variable for early-initialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941
Martin Sebor changed:
What|Removed |Added
Keywords||alias
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
I think at least in theory, the restrict keyword should make it possible to
express this constraint. Here's somewhat convoluted code showing how:
static int priv_offset;
struct offset_t { const int* const restrict p; };
static inline offset_t
read_offset (void)
{
static struct offset_t x { _offset };
return x;
}
#define pub_offset (*read_offset ())
These declarations make it possible to modify priv_offset only until the first
time pub_offset has been used to call read_offset(). After that, modifying
priv_offset is undefined because a const qualified restricted pointer to it
exists.
The code doesn't do anything useful in GCC. It optimizes calls to
read_offset() into multiple reads of priv_offset, defeating the guarantee.
[Bug c++/80667] [c++1z] ice segfault on partial specialization with non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80667 --- Comment #3 from Ed Catmur --- Agreed, gcc is OK since 7.2, selecting the latter partial specialization (as with -std=c++14). OK to mark as fixed.
[Bug libstdc++/90945] New: Enhancement: Have pretty printer for std::vector return bool values for elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90945
Bug ID: 90945
Summary: Enhancement: Have pretty printer for std::vector
return bool values for elements
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.weghorn at posteo dot de
Target Milestone: ---
= Summary =
Currently, the iterator of the python pretty-printer for a std::vector
returns integers rather than bool values. Returning bool values (True/False)
could improve the display of values and in particular make sure that a
gdb.Value created from the value returned by the pretty-printer will have
'bool' type again.
= Current behaviour =
Small sample program:
#include
int main() {
std::vector v;
v.push_back(true);
v.push_back(false);
return 0; // set breakpoint here
}
Printing the value of the vector at the given breakpoint in GDB 8.2.1 currently
results in:
(gdb) p v
$1 = std::vector of length 2, capacity 64 = {1, 0}
GDB's documentation on pretty-printing API [1] mentions:
> Function: pretty_printer.children (self)
>
> GDB will call this method on a pretty-printer to compute the children of
> the pretty-printer’s value.
>
> This method must return an object conforming to the Python iterator
> protocol. Each item returned by the iterator must be a tuple holding two
> elements. The first element is the “name” of the child; the second element
> is the child’s value. The value can be any Python object which is
> convertible to a GDB value.
> [...]
Currently, when constructing a GDB value from the value returned by the pretty
printer, the resulting gdb.Value has an integer type, e.g. 'long long' in my
case on Debian testing (amd64) with GDB 8.2.1.
IDEs may use this to display e.g. the type of local variables, resulting in a
wrong type being shown.
= Suggestion =
In my opinion, it would be desirable for the iterator to return a bool value
('True'/'False') instead, in which case a gdb.Value constructed from that
returned value also shows type 'bool' again.
The above example in a GDB session would then look like this:
(gdb) p v
$1 = std::vector of length 2, capacity 64 = {true, false}
I'll send a patch with the suggested change to the mailing list and would be
happy for any feedback.
[1] https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
[Bug debug/90944] combine debug file created when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90944 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed.
[Bug fortran/90921] Fortran OpenACC 'declare' directive's module handling causes duplicate data clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 Ever confirmed|0 |1
[Bug fortran/90937] [7/8/9/10 Regression] ICE: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 CC||tkoenig at gcc dot gnu.org Target Milestone|--- |7.5 Summary|internal compiler error: in |[7/8/9/10 Regression] ICE: |gfc_get_symbol_decl, at |in gfc_get_symbol_decl, at |fortran/trans-decl.c:1538 |fortran/trans-decl.c:1538 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- The change occurred between revisions r268729 (2019-02-09, OK) and r269160 (2019-02-23, ICE) and has been back ported to the GCC7 and GCC8 branches.
[Bug debug/90944] New: combine debug file created when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90944 Bug ID: 90944 Summary: combine debug file created when it shouldn't be Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- If we have a test case that dies very early before expand, we still end up with a stub combine debug file, even though we never called combine(). For example: bergner@pike:~/$ echo "error stuff" > bug.i bergner@pike:~/$ /path/to/gcc/xgcc -B/path/to/gcc -S -O1 -da bug.i bug.i:1:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ at end of input 1 | stuff | ^ bergner@pike:~/$ cat bug.i.264r.combine ;; Combiner totals: 0 attempts, 0 substitutions (0 requiring new space), ;; 0 successes.
[Bug middle-end/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-19 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Can you attach the preprocessed source as requested instead of the .c and .h files?
[Bug middle-end/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 --- Comment #2 from Andrew Pinski --- >The file also compiles well if –O2 is removed and all optimization flags >described in >https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html#Optimize-Options You did not read that fully: Most optimizations are only enabled if an -O level is set on the command line. So obviously not including -O will cause -O0 to be done and most of those options also to be ignored.
[Bug c/90941] [rfe] attribute to specify write-once static variable for early-initialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/90943] New: Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943
Bug ID: 90943
Summary: Visiting inherited variants no longer works in 9.1
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Here's a short repro:
#include
struct V : std::variant {
using std::variant::variant;
};
namespace std {
template <>
struct variant_size
: integral_constant
{ };
template <>
struct variant_alternative<0, V>
{
using type = int;
};
}
V v = 42;
int i = std::visit([](int){ return 17;}, v);
This worked fine in gcc 8, but breaks in gcc 9 with:
In file included from :1:
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant: In instantiation of
'constexpr const bool std::__detail::__variant::_Extra_visit_slot_needed::value':
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:809:50: required
from 'constexpr const int std::__detail::__variant::_Multi_array&&, V&), 1>::__do_cookie'
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:821:53: required
from 'struct std::__detail::__variant::_Multi_array&&,
V&), 1>'
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:1016:36: required
from 'struct std::__detail::__variant::__gen_vtable&&,
V&>'
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:1637:23: required
from 'constexpr decltype(auto) std::__do_visit(_Visitor&&, _Variants&& ...)
[with bool __use_index = false; bool __same_return_types = true; _Visitor =
; _Variants = {V&}]'
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:1653:24: required
from 'constexpr decltype(auto) std::visit(_Visitor&&, _Variants&& ...) [with
_Visitor = ; _Variants = {V&}]'
:21:43: required from here
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:778:5: error:
incomplete type 'std::__detail::__variant::_Extra_visit_slot_needed::_Variant_never_valueless' used in nested name specifier
778 | && !_Variant_never_valueless<__remove_cvref_t<_Variant>>::value;
| ^~~~
I realize that this kind of stuff isn't technically or officially sanctioned --
but doing this makes it very convenient to write an easy-to-use recursive
variant without having to implement our own variant.
Tim says you should call this NAD, but I'm being pretty optimistic :-)
[Bug c++/90942] New: Attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90942
Bug ID: 90942
Summary: Attributes
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at 3v1n0 dot net
Target Milestone: ---
Use something like this:
// Test case, wrongexport.cpp
// g++ -shared -fPIC -o /tmp/libwrong.so wrongexport.cpp -fvisibility=hidden
// nm -DC /tmp/libwrong.so | grep Astruct # misses AStruct in gcc!!!
#define EXPORT __attribute__ ((visibility ("default")))
template
struct AStruct {
AStruct(T) {}
};
template struct EXPORT AStruct;
void ImplicitSpecializationDefinition(AStruct) {}
// Ignored in g++, clang++ will export it
template struct EXPORT AStruct;
---
When compiled with clang++:
- No error
- Exported symbols are (as expected):
1110 W AStruct::AStruct(bool)
1110 W AStruct::AStruct(bool)
1130 W AStruct::AStruct(int)
1130 W AStruct::AStruct(int)
When compiled with g++:
- Warns:
/tmp/wrongexport.cpp:17:24: warning: type attributes ignored after type is
already defined [-Wattributes]
template struct EXPORT AStruct;
^~~~
- Exported symbols are:
059c W AStruct::AStruct(bool)
059c W AStruct::AStruct(bool)
So, it's missing the symbols for AStruct::AStruct(int) because the fact
that is used as parameter, cause an implicit definition with default
attributes.
I think that in such case g++ should instead allow to define attributes at
later point when those are not explicitly set.
This affects mozjs https://bugzilla.mozilla.org/show_bug.cgi?id=1560064
[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
--- Comment #8 from Martin Sebor ---
Right. The warning pass sees this:
[local count: 1073612976]:
__dnew ={v} {CLOBBER};
D.29156 ={v} {CLOBBER};
D.29152 ={v} {CLOBBER};
if (_M_local_buf != _23)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 574060859]:
_5 = str.D.19306._M_allocated_capacity;
_3 = _5 + 1;
operator delete (_23, _3);
[local count: 1073612977]:
str ={v} {CLOBBER};
return _23;
Maybe the alias oracle could be put to use here after all to improve things.
[Bug fortran/90937] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > Reduced testcase with whitespace and easy on the eyes lowercase font. > > subroutine lfidiff > >implicit none > >contains > > subroutine grlfi(cdnom) > > character(len=*) cdnom(:) > character(len=len(cdnom)) clnoma > > call lficas(clnoma) > > end subroutine grlfi > > end subroutine lfidiff Note, if the subroutine grlfi() is not a contained subprogram (ie, just a regular old subroutine), the code compiles.
[Bug fortran/90937] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- Reduced testcase with whitespace and easy on the eyes lowercase font. subroutine lfidiff implicit none contains subroutine grlfi(cdnom) character(len=*) cdnom(:) character(len=len(cdnom)) clnoma call lficas(clnoma) end subroutine grlfi end subroutine lfidiff
[Bug fortran/90937] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 --- Comment #1 from Toon Moene --- It compiles with gfortran 7.3
[Bug target/90932] [nvptx] internal compiler error: in tree_to_shwi, at tree.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90932 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- This sounds familiar. I wonder if the nvptx target needs something similar to r270447 committed for aarch64.
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
CC||jason at gcc dot gnu.org
Known to work||8.3.0
Known to fail||10.0, 9.1.0
--- Comment #5 from Jonathan Wakely ---
This is a wrong code bug too:
extern "C" void* malloc(decltype(sizeof(0)));
extern "C" void free(void*);
struct string {
string(int) : s(malloc(1)) { }
~string() { free(s); }
string(const string& str) : s(str.s ? malloc(1) : nullptr) { }
void* s;
bool empty() const { return s == nullptr; }
};
string foo()
{
string s(42);
return s.empty() ? throw "empty" : s;
}
int main()
{
foo();
}
free(): double free detected in tcache 2
Aborted (core dumped)
[Bug c++/90940] [9/10 Regression] Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jonathan Wakely --- Agreed, thanks. *** This bug has been marked as a duplicate of bug 90393 ***
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 Jonathan Wakely changed: What|Removed |Added CC||moritz.klammler at cetitec dot com --- Comment #4 from Jonathan Wakely --- *** Bug 90940 has been marked as a duplicate of this bug. ***
[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 #76 from Jonathan Wakely --- And our best guess is still that Apple's new filesystem has a bug. Does it work if you use this? make LN_S="cp -pR" If that works, we can change the makefiles to copy files on darwin, instead of using symlinks.
[Bug c/90941] New: [rfe] attribute to specify write-once static variable for early-initialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941
Bug ID: 90941
Summary: [rfe] attribute to specify write-once static variable
for early-initialized values
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: allison.karlitskaya at redhat dot com
Target Milestone: ---
The GObject type system contains support for private variables, which works
like this: you create a MyObjectPrivate structure and tell GObject about its
size, and GObject will allocate this extra space every time it creates an
instance of MyObject. this space is always stored at a constant offset
relative to the pointer to the object in question, but his offset is determined
at runtime (during the one-time class initialization procedure).
The code looks something like this (this part is emitted by macros):
static int priv_offset;
static void one_time_initialize_my_object_class() {
...
priv_offset = calculate_offset();
...
}
static inline MyObjectPrivate *get_priv_struct(MyObject *self) {
return (MyObjectPrivate *) (((char *) self) + priv_offset);
}
and then the user uses it like this:
void my_object_get_field (MyObject *self) {
return get_priv_struct(self)->field;
}
It's often the case that the private structure is used very many times from
within a single function.
Because the compiler doesn't know that one_time_initialize_my_object() will
never be called again (and that the one call to it happens before any object is
allocated, and therefore definitely before any function operating on an object
is called), it has to assume that the 'priv_offset' variable could change at
any time. This leads to the variable being read and re-read (and the addition
performed again).
It would be really nice if there were an attribute to declare that a variable
will be written to exactly once (before it is ever read from) and then never
again.
I've tried some tricks with the alias attribute and using externs with the
wrong type, but none of these approaches are very clean.
Thanks!
[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 #75 from Damien Merenne --- Indeed in my previous comment the bug seemed to be something else, but I just reproduced the original bug: In file included from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/new:40, from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/bad_array_new.cc:24: /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/exception:144:10: fatal error: bits/nested_exception.h: No such file or directory 144 | #include | ^ compilation terminated. make[8]: *** [bad_array_new.lo] Error 1 make[8]: *** Waiting for unfinished jobs make[7]: *** [all-recursive] Error 1 make[6]: *** [all] Error 2 make[5]: *** [multi-do] Error 1 make[4]: *** [all-multi] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 It's in libstdc++ and the header is from gcc.
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
--- Comment #3 from Jonathan Wakely ---
Not a dup, because turning {0, 0} into {} is still wrong even for trivial
classes:
struct X {
X() = default;
X(int n) : n(n+1) { }
int n;
};
static_assert(__is_trivial(X), "");
int main()
{
X x[1] { 1 }; // OK
if (x->n != 2)
__builtin_abort();
X y[1] { 0 };
if (y->n != 1)
__builtin_abort();
}
Aborted (core dumped)
The array element has a non-empty initializer, so must call the X(int)
constructor, which has very different semantics from the default constructor.
An {0} initializer could be a null pointer constant too:
struct X {
X() = default;
X(int* p) : p(p ? p : new int(1)) { }
int* p;
};
static_assert(__is_trivial(X), "");
int main()
{
X x[1] { nullptr }; // OK
if (*x->p != 1)
__builtin_abort();
X y[1] { 0 };
if (*y->p != 1)
__builtin_abort();
}
Segmentation fault (core dumped)
[Bug c++/90940] [9/10 Regression] Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I think it's a dup of 90393.
[Bug c++/90940] [9/10 Regression] Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940
--- Comment #3 from Jonathan Wakely ---
Oh, and for completeness, the ICE case reduced:
extern "C" void* malloc(decltype(sizeof(0)));
extern "C" void free(void*);
struct string {
string(int) : s(malloc(1)) { }
~string() { free(s); }
string(const string& str) : s(str.s ? malloc(1) : nullptr) { }
void* s;
bool empty() const { return s == nullptr; }
};
string foo()
{
const string s(42);
return s.empty() ? throw "empty" : s;
}
90940.cc: In function 'string foo()':
90940.cc:15:38: internal compiler error: in ocp_convert, at cp/cvt.c:765
15 | return s.empty() ? throw "empty" : s;
| ^
0x5ce07b ocp_convert(tree_node*, tree_node*, int, int, int)
/home/jwakely/src/gcc/gcc/gcc/cp/cvt.c:765
0xa195c9 check_return_expr(tree_node*, bool*)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:9796
0x9d0a4e finish_return_stmt(tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/semantics.c:894
0x9486db cp_parser_jump_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:12903
0x9486db cp_parser_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11180
0x949500 cp_parser_statement_seq_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11646
0x9495d7 cp_parser_compound_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11600
0x962500 cp_parser_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22624
0x962500 cp_parser_ctor_initializer_opt_and_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22675
0x962d86 cp_parser_function_definition_after_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:27776
0x963b1e cp_parser_function_definition_from_specifiers_and_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:27692
0x963b1e cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20261
0x945c6f cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13525
0x96a402 cp_parser_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13222
0x96abaf cp_parser_translation_unit
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:4690
0x96abaf c_parse_file()
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:41243
0xa78820 c_common_parse_file()
/home/jwakely/src/gcc/gcc/gcc/c-family/c-opts.c:1156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/90940] [9/10 Regression] Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940
--- Comment #2 from Jonathan Wakely ---
Reduced example showing double free, which started with the same revision as
the ICE:
extern "C" void* malloc(decltype(sizeof(0)));
extern "C" void free(void*);
struct string {
string(int) : s(malloc(1)) { }
~string() { free(s); }
string(const string& str) : s(str.s ? malloc(1) : nullptr) { }
void* s;
bool empty() const { return s == nullptr; }
};
string foo()
{
string s(42);
return s.empty() ? throw "empty" : s;
}
int main()
{
foo();
}
[Bug c++/90940] [9/10 Regression] Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords||ice-on-valid-code, ||wrong-code Last reconfirmed||2019-06-19 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Summary|Miscompilation of ternary |[9/10 Regression] |operator with throw |Miscompilation of ternary |expression in return|operator with throw |statement |expression in return ||statement Target Milestone|--- |9.2 Known to fail||10.0, 9.1.0 --- Comment #1 from Jonathan Wakely --- Confirmed, thanks for the minimal example. The ICE started with r260272: PR c++/64372 - CWG 1560, gratuitous lvalue-rvalue conversion in ?: * call.c (build_conditional_expr_1): Don't force_rvalue when one arm is a throw-expression.
[Bug c++/90940] New: Miscompilation of ternary operator with throw expression in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90940
Bug ID: 90940
Summary: Miscompilation of ternary operator with throw
expression in return statement
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: moritz.klammler at cetitec dot com
Target Milestone: ---
After upgrading from GCC 8.3 to GCC 9.1 today, our code started to break. We
were able to eventually condense it down to the following presumably minimal
example.
#include
std::string foo()
{
/*const*/ auto s = std::string(42, '*');
return s.empty() ? throw "empty" : s;
}
When written as shown, the destructor of `s` will be called and cause a
double-free on the string's buffer. If the variable `s` is declared `const`,
GCC encounters an ICE.
test.cxx: In function ‘std::string foo()’:
test.cxx:7:40: internal compiler error: in ocp_convert, at cp/cvt.c:766
7 | return s.empty() ? throw "empty" : s;
|^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 Jonathan Wakely changed: What|Removed |Added Depends on||85723 --- Comment #2 from Jonathan Wakely --- The class X should not be trivial, see https://wg21.link/cwg1496 So maybe this is a dup of Bug 85723 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85723 [Bug 85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor
[Bug ipa/90939] ICE in meet_with, at ipa-cp.c:1073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90939 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 Version|10.0|9.1.0 Ever confirmed|0 |1 Known to fail||9.1.0
[Bug ipa/90939] New: ICE in meet_with, at ipa-cp.c:1073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90939
Bug ID: 90939
Summary: ICE in meet_with, at ipa-cp.c:1073
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
I see the ICE in chromium package with gcc9 package.
It won't be so easy to reduce a test-case, I ended up with 15 object files.
I can reproduce that with 72fa547fbac7c8dc58c5caf53e35d4b68432c08c revision and
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 4367928a515..d5908cd609b 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1829,7 +1829,7 @@ lto_read_decls (struct lto_file_decl_data *decl_data,
const void *data,
{
/* Pickle stray references. */
t = lto_input_tree_1 (_main, data_in, tag, 0);
- gcc_assert (t && data_in->reader_cache->nodes.length () == from);
+// gcc_assert (t && data_in->reader_cache->nodes.length () == from);
}
}
data_in->location_cache.apply_location_cache ();
Files:
https://drive.google.com/file/d/1gvsG3VUsJTYBoSJP0ZMhurpukHoxUocv/view?usp=sharing
$ g++ *.o
during IPA pass: cp
lto1: internal compiler error: in meet_with, at ipa-cp.c:1073
0x1b27f6a ipcp_bits_lattice::meet_with(ipcp_bits_lattice&, unsigned int,
signop, tree_code, tree_node*)
../../gcc/ipa-cp.c:1073
0x1b29cfa propagate_bits_across_jump_function(cgraph_edge*, int,
ipa_jump_func*, ipcp_bits_lattice*)
../../gcc/ipa-cp.c:1862
0x1b2ac99 propagate_constants_across_call
../../gcc/ipa-cp.c:2287
0x1b2d292 propagate_constants_topo
../../gcc/ipa-cp.c:3183
0x1b2d61b ipcp_propagate_stage
../../gcc/ipa-cp.c:3296
0x1b316cb ipcp_driver
../../gcc/ipa-cp.c:5080
0x1b318b0 execute
../../gcc/ipa-cp.c:5173
$ (gdb) bt
#0 ipcp_bits_lattice::meet_with (this=0x32794e8, other=..., precision=64,
sgn=UNSIGNED, code=MAX_EXPR, operand=0x73d4d4f8) at ../../gcc/ipa-cp.c:1073
#1 0x01b29cfb in propagate_bits_across_jump_function
(cs=0x745062d8, idx=0, jfunc=0x73d34778, dest_lattice=0x32794e8) at
../../gcc/ipa-cp.c:1862
#2 0x01b2ac9a in propagate_constants_across_call (cs=0x745062d8)
at ../../gcc/ipa-cp.c:2287
#3 0x01b2d293 in propagate_constants_topo (topo=0x7fffd850) at
../../gcc/ipa-cp.c:3183
#4 0x01b2d61c in ipcp_propagate_stage (topo=0x7fffd850) at
../../gcc/ipa-cp.c:3296
#5 0x01b316cc in ipcp_driver () at ../../gcc/ipa-cp.c:5080
#6 0x01b318b1 in (anonymous namespace)::pass_ipa_cp::execute
(this=0x28e9100) at ../../gcc/ipa-cp.c:5173
#7 0x00d8fd71 in execute_one_pass (pass=0x28e9100) at
../../gcc/passes.c:2487
#8 0x00d90cbb in execute_ipa_pass_list (pass=0x28e9100) at
../../gcc/passes.c:2927
#9 0x0084a52d in do_whole_program_analysis () at
../../gcc/lto/lto.c:3174
#10 0x0084a9aa in lto_main () at ../../gcc/lto/lto.c:3399
#11 0x00edc5a6 in compile_file () at ../../gcc/toplev.c:456
#12 0x00edf1c5 in do_compile () at ../../gcc/toplev.c:2205
#13 0x00edf4aa in toplev::main (this=0x7fffda8e, argc=34,
argv=0x28bfe40) at ../../gcc/toplev.c:2340
#14 0x01c12f6c in main (argc=20, argv=0x7fffdb88) at
../../gcc/main.c:39
$ (gdb) p debug_tree(operand)
constant 0>
$1 = void
So it's a MAX_EXPR with a pointer_type:
(gdb) p debug_tree((tree)0x768bce70)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76c47540
fields
ignored TI
../../third_party/blink/renderer/core/layout/ng/inline/ng_inline_node.h:28:19
size
unit-size
align:64 warn_if_not_align:0 offset_align 128
offset
bit-offset context
> context
pointer_to_this >
public unsigned DI
size constant 64>
unit-size constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality>
$2 = void
Can you Martin please take a look?
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #4 from Nick Krempel --- Thanks, accepted.
[Bug c++/90936] [9 Regression] Ambiguous call with ref-qualified conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90936 --- Comment #2 from m.cencora at gmail dot com --- Hmm, if it is expected, shouldn't gcc also report ambiguous call for f1 construction and assignment as well?
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> (write_expression): Trim trailing zero-initializers from arrays
> of trivial type.
I assume this is the problem. {} will default construct, but {0} does not, and
should not be turned into default construction.
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 Known to work||8.3.0 Target Milestone|--- |9.2 Ever confirmed|0 |1 Known to fail||10.0, 9.1.0
[Bug c++/90938] New: [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
Bug ID: 90938
Summary: [9/10 Regression] Initializing array with {1} works,
but not {0}
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
struct X {
X() = delete;
X(int) { }
};
X x[1] { 1 }; // OK
X y[1] { 0 };
arr.cc:7:12: error: use of deleted function 'X::X()'
7 | X y[1] { 0 };
|^
arr.cc:2:3: note: declared here
2 | X() = delete;
| ^
This started to be rejected by r270155:
PR c++/89974 - ICE on a definition of a non-type specialization on a struct
object with pointer to member function
PR c++/89878 - same specializations on a zero-initialized struct object as
a non-type parameter treated as distinct
PR c++/89833 - sorry, unimplemented: string literal in function template
signature
PR c++/47488 - sorry, unimplemented: string literal in function template
signature
gcc/cp/ChangeLog:
PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* decl.c (reshape_init_array_1): Strip trailing zero-initializers
from arrays of trivial type and known size.
* mangle.c (write_expression): Convert braced initializer lists
to STRING_CSTs.
(write_expression): Trim trailing zero-initializers from arrays
of trivial type.
(write_template_arg_literal): Mangle strings the same as braced
initializer lists.
gcc/testsuite/ChangeLog:
PR c++/89974
PR c++/89878
PR c++/89833
PR c++/47488
* gcc/testsuite/g++.dg/abi/mangle69.C: New test.
* gcc/testsuite/g++.dg/abi/mangle70.C: New test.
* gcc/testsuite/g++.dg/abi/mangle71.C: New test.
* gcc/testsuite/g++.dg/abi/mangle72.C: New test.
* gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test.
* gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test.
* gcc/testsuite/g++.dg/init/array51.C: New test.
[Bug fortran/90937] New: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 Bug ID: 90937 Summary: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Compiling he following code leads to the ICE in the summary: SUBROUTINE LFIDIFF IMPLICIT NONE INTEGER, PARAMETER :: JPIM = SELECTED_INT_KIND(9) CONTAINS SUBROUTINE FRLFI (KLUN, KLON, CDNOM, CDF) INTEGER (KIND=JPIM), INTENT (IN) :: KLUN INTEGER (KIND=JPIM), POINTER :: KLON (:) CHARACTER (LEN=*), POINTER :: CDNOM (:) CHARACTER (LEN=*), INTENT (IN) :: CDF INTEGER (KIND=JPIM) :: IREP CALL LFIFER(IREP,KLUN,'KEEP') END SUBROUTINE FRLFI SUBROUTINE GRLFI (KLUN, KLON, CDNOM, CDF) INTEGER (KIND=JPIM), INTENT (IN) :: KLUN INTEGER (KIND=JPIM), POINTER :: KLON (:) CHARACTER (LEN=*), POINTER :: CDNOM (:) CHARACTER (LEN=*), INTENT (IN) :: CDF INTEGER(KIND=JPIM) :: IREP INTEGER(KIND=JPIM) :: ILONG, IPOSEX CHARACTER(LEN=LEN(CDNOM)) :: CLNOMA CALL LFICAS(IREP,KLUN,CLNOMA,ILONG,IPOSEX,.TRUE.) END SUBROUTINE GRLFI END SUBROUTINE LFIDIFF It fails in the same way using 8.3.0.
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- This is undefined behaviour. [res.on.arguments] p1(1.3) says "If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument." You have created an rvalue reference to an object which is already referenced by the vector itself, so the rvalue reference is not a unique reference.
[Bug c++/90936] [9 Regression] Ambiguous call with ref-qualified conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90936 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think the error is expected. Changed in r269602.
[Bug c++/90936] New: [9 Regression] Ambiguous call with ref-qualified conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90936
Bug ID: 90936
Summary: [9 Regression] Ambiguous call with ref-qualified
conversion operators
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
gcc 9 and trunk complains about ambiguous call when constructing or assigning
to f2.
This works fine with gcc 8 or earlier.
struct Foo
{};
struct ConvertibleToFoo
{
operator const Foo&() const &;
operator Foo&&() &&;
};
void bar()
{
Foo f1(static_cast(ConvertibleToFoo{}));
Foo f2(static_cast(ConvertibleToFoo{}));
f1 = static_cast(ConvertibleToFoo{});
f2 = static_cast(ConvertibleToFoo{});
}
[Bug target/84521] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521 --- Comment #29 from Wilco --- Author: wilco Date: Wed Jun 19 12:52:43 2019 New Revision: 272473 URL: https://gcc.gnu.org/viewcvs?rev=272473=gcc=rev Log: Simplify setjmp and non-local goto implementation (PR84521) This fixes and simplifies the setjmp and non-local goto implementation. Currently the virtual frame pointer is saved when using __builtin_setjmp or a non-local goto. Depending on whether a frame pointer is used, this may either save SP or FP with an immediate offset. However the goto or longjmp always updates the hard frame pointer. A receiver veneer in the original function then assigns the hard frame pointer to the virtual frame pointer, which should, if it works correctly, again assign SP or FP. However the special elimination code in eliminate_regs_in_insn doesn't do this correctly unless the frame pointer is used, and even if it worked by writing SP, the frame pointer would still be corrupted. A much simpler implementation is to always save and restore the hard frame pointer. This avoids 2 redundant instructions which add/subtract the virtual frame offset. A large amount of code can be removed as a result, including all implementations of TARGET_BUILTIN_SETJMP_FRAME_VALUE (all of which already use the hard frame pointer). The expansion of nonlocal_goto on PA can be simplied to just restore the hard frame pointer. This fixes the most obvious issues, however there are still issues on targets which define HARD_FRAME_POINTER_IS_FRAME_POINTER (arm, mips). Each function could have a different hard frame pointer, so a non-local goto may restore the wrong frame pointer (TARGET_BUILTIN_SETJMP_FRAME_VALUE could be useful for this). The i386 TARGET_BUILTIN_SETJMP_FRAME_VALUE was incorrect: if stack_realign_fp is true, it would save the hard frame pointer value but restore the virtual frame pointer which according to ix86_initial_elimination_offset can have a non-zero offset from the hard frame pointer. The ia64 implementation of nonlocal_goto seems incorrect since the helper function moves the the frame pointer value into the static chain register (so this patch does nothing to make it better or worse). AArch64 + x86-64 bootstrap OK, new test passes on AArch64, x86-64 and Arm. gcc/ PR middle-end/84521 * builtins.c (expand_builtin_setjmp_setup): Save hard_frame_pointer_rtx. (expand_builtin_setjmp_receiver): Do not emit sfp = fp move since we restore fp. * function.c (expand_function_start): Save hard_frame_pointer_rtx for non-local goto. * lra-eliminations.c (eliminate_regs_in_insn): Remove sfp = fp elimination code. (remove_reg_equal_offset_note): Remove unused function. * reload1.c (eliminate_regs_in_insn): Remove sfp = hfp elimination code. * config/arc/arc.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. (arc_builtin_setjmp_frame_value): Remove function. * config/avr/avr.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. (avr_builtin_setjmp_frame_value): Remove function. * config/i386/i386.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. (ix86_builtin_setjmp_frame_value): Remove function. * config/pa/pa.md (nonlocal_goto): Remove FP adjustment. * config/sparc/sparc.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. (sparc_builtin_setjmp_frame_value): Remove function. * config/vax/vax.c (TARGET_BUILTIN_SETJMP_FRAME_VALUE): Remove. (vax_builtin_setjmp_frame_value): Remove function. * config/xtensa/xtensa.c (xtensa_frame_pointer_required): Force frame pointer if has_nonlocal_label. testsuite/ PR middle-end/84521 * gcc.c-torture/execute/pr84521.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr84521.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/arc/arc.c trunk/gcc/config/avr/avr.c trunk/gcc/config/i386/i386.c trunk/gcc/config/pa/pa.md trunk/gcc/config/sparc/sparc.c trunk/gcc/config/vax/vax.c trunk/gcc/config/xtensa/xtensa.c trunk/gcc/function.c trunk/gcc/lra-eliminations.c trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #2 from Nick Krempel --- I believe the same issue afflicts libc++, but not MSVC's implementation.
[Bug target/90935] New: [nvptx] internal compiler error: in get_personality_function, at expr.c:12497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90935 Bug ID: 90935 Summary: [nvptx] internal compiler error: in get_personality_function, at expr.c:12497 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.sum: ... FAIL: gcc.dg/pr88071.c (internal compiler error) ... gcc.log: ... during RTL pass: final^M In file included from /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/pr88071.c:5:^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/gomp/openmp-simd-2.c: In function 'foo':^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/gomp/openmp-simd-2.c:28:1: internal compiler error: in get_personality_function, at expr.c:12497^M 0x86f88d get_personality_function(tree_node*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/expr.c:12497^M 0x84b59d output_function_exception_table(int)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/except.c:3193^M 0x89ba61 rest_of_handle_final^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/final.c:4672^M 0x89ba61 execute^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/final.c:4737^M ... The testcase is missing dg-require-effective-target exceptions, but we'd better not ICE.
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #1 from Nick Krempel --- (The same buggy behavior is seen with "emplace" instead of "insert".)
[Bug libstdc++/90934] New: std::vector self-move-insert bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934
Bug ID: 90934
Summary: std::vector self-move-insert bug
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
Inserting into a vector with an rvalue reference to an item already in the
vector produces incorrect results (specifically when inserting prior to the
existing location and when a resize is *not* required):
#include
#include
#include
int main() {
std::vector v{1, 2};
v.reserve(3);
v.insert(v.begin(), std::move(v.back()));
for (auto x : v) {
std::cout << x << std::endl;
}
}
This outputs "1 1 2" instead of "2 1 2". Removing either the "reserve" or the
"std::move" gives the correct result.
(https://wandbox.org/permlink/qeBMggNmvISHlPIx)
[Bug target/90933] New: [nvptx] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90933 Bug ID: 90933 Summary: [nvptx] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2367 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.sum: ... FAIL: gcc.dg/memcmp-1.c (internal compiler error) ... gcc.log: ... during RTL pass: expand^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c: In function 'test_strncmp_49_1':^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c:190:13: internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2367^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/memcmp-1.c:487:1: note: in expansion of macro 'DEF_TEST'^M 0x573b79 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/rtl.c:890^M 0x73b346 rtx_to_poly_int64(rtx_def const*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/rtl.h:2367^M 0x73b346 expand_stack_vars^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/cfgexpand.c:1223^M 0x73bc9b expand_used_vars^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/cfgexpand.c:2297^M 0x73fe92 execute^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/cfgexpand.c:6394^M ...
[Bug target/90932] New: [nvptx] internal compiler error: in tree_to_shwi, at tree.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90932 Bug ID: 90932 Summary: [nvptx] internal compiler error: in tree_to_shwi, at tree.c Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.sum: ... FAIL: gcc.dg/attr-vector_size.c (internal compiler error) ... gcc.log: ... /home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/attr-vector_size.c:29:1: internal compiler error: in tree_to_shwi, at tree.c:7283^M 0xf13b3a tree_to_shwi(tree_node const*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/tree.c:7283^M 0xfb3699 nvptx_vector_alignment^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/config/nvptx/nvptx.c:5123^M 0xc189b9 layout_type(tree_node*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/stor-layout.c:2396^M 0xf371c7 make_vector_type^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/tree.c:10154^M 0x6c41be handle_vector_size_attribute^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c-family/c-attribs.c:3598^M 0x5b1f0b decl_attributes(tree_node**, tree_node*, int, tree_node*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/attribs.c:719^M 0x5d23d6 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c/c-decl.c:4977^M 0x63bfb8 c_parser_declaration_or_fndef^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c/c-parser.c:2156^M 0x645723 c_parser_external_declaration^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c/c-parser.c:1654^M 0x646051 c_parser_translation_unit^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c/c-parser.c:1534^M 0x646051 c_parse_file()^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c/c-parser.c:19959^M 0x6a930a c_common_parse_file()^M /home/vries/nvptx/mainkernel-2/source-gcc/gcc/c-family/c-opts.c:1156^M ...
[Bug target/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 --- Comment #1 from Christophe Lyon --- Created attachment 46504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46504=edit testcase open62541.c and open62541.h
[Bug target/90931] New: [nvptx] FAIL: gcc.c-torture/execute/pr78675.c -O1 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90931 Bug ID: 90931 Summary: [nvptx] FAIL: gcc.c-torture/execute/pr78675.c -O1 execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.sum: ... WARNING: program timed out. FAIL: gcc.c-torture/execute/pr78675.c -O1 execution test ... gcc.log: ... PASS: gcc.c-torture/execute/pr78675.c -O1 (test for excess errors) spawn nvptx-none-run ./pr78675.exe^M WARNING: program timed out. FAIL: gcc.c-torture/execute/pr78675.c -O1 execution test ...
[Bug target/90930] New: Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 Bug ID: 90930 Summary: Excessive memory consumption Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, aarch64-linux-gnu-gcc consumes a lot of memory and takes a lot of time to compile the attached code, or it fails with "cc1: out of memory allocating.." depending on the host machine. aarch64-linux-gnu-gcc -c -O2 -Wno-unused-parameter -Wall -W open62541.c On the (x86_64) machine I used, it took 15 minutes and 12GB of memory, which compiling with arm-linux-gnueabihf-gcc took about 6 minutes and 1GB of memory, which is more reasonable. Using -O0 avoids the problem. The file also compiles well if –O2 is removed and all optimization flags described in https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html#Optimize-Options for O1 and O2 are added (-ffinite-loops is replaced by fsplit-loops; fdelayed-branch is removed due to missing support on target) Command: aarch64-linux-gnu-gcc -c -fsplit-loops -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fshrink-wrap-separate -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -falign-functions -falign-jumps -falign-labels -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively -fexpensive-optimizations -fgcse -fgcse-lm -fhoist-adjacent-loads -finline-small-functions -findirect-inlining -fipa-bit-cp -fipa-cp -fipa-icf -fipa-ra -fipa-sra -fipa-vrp -fisolate-erroneous-paths-dereference -flra-remat -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks-algorithm=stc -freorder-blocks-and-partition -freorder-functions -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fstore-merging -fstrict-aliasing -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion -ftree-tail-merge -ftree-vrp -Wno-unused-parameter -Wall -W open62541.c The problem was also noticed with gcc-7 and gcc-8.
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- (In reply to Ren Kimura from comment #0) > Created attachment 46501 [details] > Proof of Concept ELF binary for nm command Hello. Is the file created with a fuzzer? I can confirm the crash, but the ELF container looks broken to me: $ readelf -S memcorrupt_nm-2.30_gcc-9.1.0_gold readelf: Warning: possibly corrupt ELF file header - it has a non-zero section header offset, but no section headers readelf: Error: Too many program headers - 0xdeff - the file is not that big Can you provide steps how to create such a file? Thanks > > On several major linux distributions like ubuntu, debian... binutils uses > ELF parser from gold linker plugin, > /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so instead of libbfd. > I found a memory corruption bug (Heap OOB read) of gold ELF parser linked > from latest nm command(2.30). > If input binary file has a zero value string section offset (i.e e_shstrndx > == 0.), gold ELF parser try to find string section by > simple_object_find_sections() without enough sanitization. > > https://github.com/gcc-mirror/gcc/blob/ > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/lto-plugin/lto-plugin.c#L1059 > > As a result if e_shstrndx is equal to 0, "(eor->shstrndx - 1)" at this line > cause integer overflow (a result becomes negative value (unsigned int)-1 ) > https://github.com/gcc-mirror/gcc/blob/ > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/libiberty/simple-object-elf.c#L600 > > and try to do out of bound access against heap memory, cause memory > corruption. > > On Ubuntu 18.10 with GCC 9.1.0. > > PoC file is attached to this email. > Execute PoC: > nm ./memcorrupt_nm-2.30_gcc-9.1.0_gold > Segmentation fault (core dumped) > > CrashDump: > nm --plugin ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0 > ./memcorrupt_nm-2.30_gcc-9.1.0_gold > Core was generated by `nm --plugin > ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0 ./researc'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 simple_object_fetch_little_64 (buf=0x5678b4bc3640 memory at address 0x5678b4bc3640>) > at ../../libiberty/simple-object-common.h:262 > > 262 return (((ulong_type) buf[7] << 56) > > (gdb) bt > > #0 simple_object_fetch_little_64 (buf=0x5678b4bc3640 memory at address 0x5678b4bc3640>) > at ../../libiberty/simple-object-common.h:262 > > #1 0x7feb2c5b7268 in simple_object_elf_find_sections > (sobj=0x5638b4bc3630, pfn=0x7feb2c5b0930 , > data=0x7ffd5884ca00, err=0x7ffd5884c9f4) at > ../../libiberty/simple-object-elf.c:601 > #2 0x7feb2c5b0dd5 in claim_file_handler (file=0x7ffd5884cac0, > claimed=0x7ffd5884cabc) > at ../../lto-plugin/lto-plugin.c:1025 > > #3 0x7feb2c49796b in ?? () from > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so > > #4 0x7feb2c497bef in ?? () from > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so > > #5 0x7feb2c30880a in bfd_check_format_matches () from > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so > #6 0x5638b4012cb0 in ?? () > #7 0x5638b40109e6 in ?? () > #8 0x7feb2c07f09b in __libc_start_main (main=0x5638b4010590, argc=4, > argv=0x7ffd5884ceb8, init=, > fini=, rtld_fini=, > stack_end=0x7ffd5884cea8) at ../csu/libc-start.c:308 > #9 0x5638b4010a5a in ?? () > ``` > > Thanks > Ren
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 --- Comment #5 from Dominique d'Humieres --- I also see the ICE with '-cpp -M'.
[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929 coypu changed: What|Removed |Added Target|mips64-linux-gnuabi64 |mips64-linux-gnuabi64, --- Comment #1 from coypu --- To clarify, the correct behaviour is implemented, it just doesn't get expanded in libgcc for header reasons.
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 --- Comment #4 from Antony Lewis --- Not sure why that rather than other dependency options, been like that for ages (guessing: maybe because of mpif.h?).
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 --- Comment #3 from Dominique d'Humieres --- Question: why do you use -MMD?
[Bug libgcc/90929] New: libgcc MIPS __clear_cache shouldn't be a no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90929 Bug ID: 90929 Summary: libgcc MIPS __clear_cache shouldn't be a no-op Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: coypu at sdf dot org Target Milestone: --- MIPS needs cache synchronization. libgcc's __clear_cache expands to: 000119b0 <__clear_cache>: 119b0: 03e8jr ra 119b4: nop ... (a no-op) Running compiler-rt's test[1] on real hardware running netbsd/mips64 (n32) without optimizations fails. If -O2 is used it succeeds, presumably because the call is inlined. # gcc clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep clear_cache; ./clear_cache_test; echo $? U __clear_cache@@GCC_3.0 1 # gcc -O2 clear_cache_test.c -o clear_cache_test; nm clear_cache_test |grep clear_cache; ./clear_cache_test; echo $? 0 To confirm this isn't caused by local changes or build oddities, I built with trunk for "mips64-linux-gnuabi64" on linux, and it still shows the no-op function. The correct behaviour is to emit a call to libc (it's a privileged instruction on older MIPS, so the kernel must do it). [1] https://github.com/llvm-mirror/compiler-rt/blob/master/test/builtins/Unit/clear_cache_test.c
[Bug target/90928] New: [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928 Bug ID: 90928 Summary: [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- ... FAIL: gcc.c-torture/compile/opout.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/opout.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/opout.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/opout.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/opout.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/opout.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/opout.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/opout.c -Os (test for excess errors) ... In more detail: ... during RTL pass: vregs^M gcc/testsuite/gcc.c-torture/compile/opout.c: In function 'z':^M gcc/testsuite/gcc.c-torture/compile/opout.c:10:1: internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737^M 0x8e036d instantiate_virtual_regs_in_insn^M gcc/function.c:1737^M 0x8e036d instantiate_virtual_regs^M gcc/function.c:1975^M 0x8e036d execute^M gcc/function.c:2024^M Please submit a full bug report,^M ...
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 --- Comment #2 from Dominique d'Humieres --- Created attachment 46503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46503=edit Compile the test with -cpp -MMD to get the ICE
[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-19 CC||nathan at gcc dot gnu.org Component|fortran |preprocessor Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This is caused by the options '-cpp -MMD' and likely due to the assert gcc_assert (d->quote_lwm == d->targets.size ()); introduced at revision r270943.
[Bug debug/90914] [10 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:27153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90914 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Known to work||9.1.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r271803.
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-19 Blocks||59002 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. (In reply to zhonghao from comment #0) > The error message of gcc contains some internal messages, which can be > removed: I don't know what you mean, and it doesn't seem to be related to this bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 [Bug 59002] [meta-bug] Access checking in templates
[Bug c++/90926] [7/8/910 Regression] member char array with string literal initializer causes = {} to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90926
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||5.1.0
Keywords||rejects-valid
Last reconfirmed||2019-06-19
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
Summary|member char array with |[7/8/910 Regression] member
|string literal initializer |char array with string
|causes = {} to fail |literal initializer causes
||= {} to fail
Known to fail||10.0, 5.4.0, 6.1.0, 6.5.0,
||7.4.0, 8.3.0, 9.1.0
--- Comment #1 from Jonathan Wakely ---
This started to be rejected with r233947:
* call.c (build_aggr_conv): Use get_nsdmi.
I'm going to call it a regression, because it used to compile with GCC 5.3
(with any -std option).
[Bug fortran/90927] New: [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927 Bug ID: 90927 Summary: [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- ICE with version GNU Fortran (GCC) 10.0.0 20190618 compiling https://github.com/cmbant/forutils.git For full output see https://travis-ci.org/cmbant/forutils/jobs/523880280
[Bug c++/90926] New: member char array with string literal initializer causes = {} to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90926
Bug ID: 90926
Summary: member char array with string literal initializer
causes = {} to fail
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomgree at cisco dot com
Target Milestone: ---
minimal example program:
int main()
{
struct thing
{
char str[100] = "foo";
//char str[100] = {'f', 'o', 'o', '\0'}; // this is fine though
};
thing foo;
foo = {}; // clang will compile this, but gcc won't
}
gcc ./test.cpp -Wall -Wextra -Wpedantic
./test.cpp: In function ‘int main()’:
./test.cpp:11:10: error: no match for ‘operator=’ (operand types are
‘main()::thing’ and ‘’)
foo = {}; // clang will compile this, but gcc won't
^
./test.cpp:4:10: note: candidate: constexpr main()::thing&
main()::thing::operator=(const main()::thing&)
struct thing
^
./test.cpp:4:10: note: no known conversion for argument 1 from
‘’ to ‘const main()::thing&’
./test.cpp:4:10: note: candidate: constexpr main()::thing&
main()::thing::operator=(main()::thing&&)
./test.cpp:4:10: note: no known conversion for argument 1 from
‘’ to ‘main()::thing&&’
According to https://godbolt.org/ this happens on all versions of GCC when
-std=c++14 is used (but not -std=c++11).
[Bug c++/90925] New: gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925
Bug ID: 90925
Summary: gcc allows calling private overridden operators
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and my code is:
class a {
private: template a <<(b);
};
a c();
template a fn2() {
int d;
return c() << d;
}
gcc accepts the code, but clang rejects it:
error: 'operator<<' is a private member of 'a'
return c() << d;
~~~ ^ ~
note: implicitly declared private here
template a <<(b);
^
1 error generated.
BTW, I constructed a related code sample:
#include
using namespace std;
class A
{
public:
A():value(0){cout<<"i am gouzao"< ++(int)
{
cout<<"A++"< std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)
operator<<(basic_ostream<_CharT, _Traits>& __os,
^~~~
/usr/include/c++/7/bits/basic_string.h:6284:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream<_CharT,
_Traits>’
a<<1;
^
In file included from /usr/include/c++/7/bits/ios_base.h:46:0,
from /usr/include/c++/7/ios:42,
from /usr/include/c++/7/ostream:38,
from /usr/include/c++/7/iostream:39,
from test.cpp:1:
/usr/include/c++/7/system_error:217:5: note: candidate: template std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::error_code&)
operator<<(basic_ostream<_CharT, _Traits>& __os, const error_code& __e)
^~~~
/usr/include/c++/7/system_error:217:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream<_CharT,
_Traits>’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:497:5: note: candidate: template std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, _CharT)
operator<<(basic_ostream<_CharT, _Traits>& __out, _CharT __c)
^~~~
/usr/include/c++/7/ostream:497:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream<_CharT,
_Traits>’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:502:5: note: candidate: template std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, char)
operator<<(basic_ostream<_CharT, _Traits>& __out, char __c)
^~~~
/usr/include/c++/7/ostream:502:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream<_CharT,
_Traits>’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:508:5: note: candidate: template
std::basic_ostream& std::operator<<(std::basic_ostream&, char)
operator<<(basic_ostream& __out, char __c)
^~~~
/usr/include/c++/7/ostream:508:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:514:5: note: candidate: template
std::basic_ostream& std::operator<<(std::basic_ostream&, signed char)
operator<<(basic_ostream& __out, signed char __c)
^~~~
/usr/include/c++/7/ostream:514:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:519:5: note: candidate: template
std::basic_ostream& std::operator<<(std::basic_ostream&, unsigned char)
operator<<(basic_ostream& __out, unsigned char __c)
^~~~
/usr/include/c++/7/ostream:519:5: note: template argument
deduction/substitution failed:
test.cpp:33:8: note: ‘A’ is not derived from ‘std::basic_ostream’
a<<1;
^
In file included from /usr/include/c++/7/iostream:39:0,
from test.cpp:1:
/usr/include/c++/7/ostream:539:5: note: candidate: template std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const _CharT*)
operator<<(basic_ostream<_CharT, _Traits>& __out, const _CharT* __s)
^~~~
/usr/include/c++/7/ostream:539:5: note: template argument
deduction/substitution failed:
[Bug c++/90909] [10 Regression] call devirtualized to pure virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90909 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug target/88529] G++ clears the return register on x86_64 when returning an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529 --- Comment #5 from Antony Polukhin --- (In reply to Jason Merrill from comment #1) > Created attachment 45899 [details] > Fix Is it enough to test only for `scan-assembler-not mov`? Probably a `scan-assembler-not xor` should be also added?
