[Bug target/83831] [RX] Unused bclr,bnot,bset insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83831 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Oleg Endo --- Fixed on GCC 8. Patches for GCC 6 and GCC 7 available here.
[Bug target/83831] [RX] Unused bclr,bnot,bset insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83831 Oleg Endo changed: What|Removed |Added Attachment #43270|0 |1 is obsolete|| --- Comment #7 from Oleg Endo --- Created attachment 44292 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44292=edit Patch for GCC 7 Updated patch for GCC 7
[Bug target/83831] [RX] Unused bclr,bnot,bset insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83831 Oleg Endo changed: What|Removed |Added Attachment #43266|0 |1 is obsolete|| --- Comment #6 from Oleg Endo --- Created attachment 44291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44291=edit Patch for GCC 6 Updated patch for GCC 6
[Bug c++/86205] [9 Regression] ICE on valid C++11 code: in type_dependent_expression_p, at cp/pt.c:25193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Summary|ICE on valid C++11 code: in |[9 Regression] ICE on valid |type_dependent_expression_p |C++11 code: in |, at cp/pt.c:25193 |type_dependent_expression_p ||, at cp/pt.c:25193 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r260272.
[Bug c++/86182] [8/9 Regression] gcc crashes when compiling the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86182 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/86200] [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/86200] [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200 --- Comment #3 from Jason Merrill --- Author: jason Date: Tue Jun 19 00:38:58 2018 New Revision: 261730 URL: https://gcc.gnu.org/viewcvs?rev=261730=gcc=rev Log: PR c++/86200 - ICE with unexpanded pack in lambda parameter. * pt.c (find_parameter_packs_r) [LAMBDA_EXPR]: Also look into the function type. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic7.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81060 --- Comment #4 from Jason Merrill --- Author: jason Date: Tue Jun 19 00:38:26 2018 New Revision: 261725 URL: https://gcc.gnu.org/viewcvs?rev=261725=gcc=rev Log: PR c++/81060 - ICE with unexpanded parameter pack. * pt.c (check_for_bare_parameter_packs): Add loc parameter. * decl.c (grokdeclarator): Call it for qualifying_scope. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/cpp0x/pr81060.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex2.C
[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81060 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Jun 19 00:38:52 2018 New Revision: 261729 URL: https://gcc.gnu.org/viewcvs?rev=261729=gcc=rev Log: PR c++/81060 - ICE with unexpanded parameter pack. * pt.c (check_for_bare_parameter_packs): Add loc parameter. * decl.c (grokdeclarator): Call it for qualifying_scope. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/cp-tree.h branches/gcc-8-branch/gcc/cp/decl.c branches/gcc-8-branch/gcc/cp/pt.c branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/pr81060.C branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/variadic-ex2.C
[Bug c++/86200] [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue Jun 19 00:38:32 2018 New Revision: 261726 URL: https://gcc.gnu.org/viewcvs?rev=261726=gcc=rev Log: PR c++/86200 - ICE with unexpanded pack in lambda parameter. * pt.c (find_parameter_packs_r) [LAMBDA_EXPR]: Also look into the function type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201
--- Comment #2 from Marek Polacek ---
The problem here is that we report the missing return value:
9224 permerror (input_location, "return-statement with no value, in "
9225"function returning %qT", valtype);
but permerror will end up calling print_instantiation_full_context, which ends
up calling dump_template_bindings and then tsubst -> tsubst_copy_and_build ->
build_functional_cast -> ... -> ocp_convert
which has (complain is tf_none)
829 if (complain & tf_warning)
830 return cp_truthvalue_conversion (e);
831 else
832 {
833 /* Prevent bogus -Wint-in-bool-context warnings coming
834 from c_common_truthvalue_conversion down the line. */
835 warning_sentinel w (warn_int_in_bool_context);
836 return cp_truthvalue_conversion (e);
837 }
So we call cp_truthvalue_conversion -> c_common_truthvalue_conversion ->
build_binary_op which only calls cp_build_binary_op but with
tf_warning_or_error. So even though the warning
4736 if ((complain & tf_warning)
4737 && (FLOAT_TYPE_P (type0) || FLOAT_TYPE_P (type1)))
4738 warning (OPT_Wfloat_equal,
4739 "comparing floating point with == or != is unsafe");
is properly guarded, we still re-enter the diagnostic routines.
[Bug middle-end/82063] issues with arguments enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063 --- Comment #10 from Martin Sebor --- Author: msebor Date: Tue Jun 19 00:02:30 2018 New Revision: 261720 URL: https://gcc.gnu.org/viewcvs?rev=261720=gcc=rev Log: PR middle-end/82063 - issues with arguments enabled by -Wall gcc/ChangeLog: PR middle-end/82063 * calls.c (alloc_max_size): Correct a logic error/typo. Treat excessive arguments as infinite. Warn for invalid arguments. * doc/invoke.texi (-Walloc-size-larger-than): Update. gcc/testsuite/ChangeLog: PR middle-end/82063 * gcc.dg/Walloc-size-larger-than-1.c: New test. * gcc.dg/Walloc-size-larger-than-10.c: New test. * gcc.dg/Walloc-size-larger-than-11.c: New test. * gcc.dg/Walloc-size-larger-than-12.c: New test. * gcc.dg/Walloc-size-larger-than-13.c: New test. * gcc.dg/Walloc-size-larger-than-14.c: New test. * gcc.dg/Walloc-size-larger-than-15.c: New test. * gcc.dg/Walloc-size-larger-than-16.c: New test. * gcc.dg/Walloc-size-larger-than-2.c: New test. * gcc.dg/Walloc-size-larger-than-3.c: New test. * gcc.dg/Walloc-size-larger-than-4.c: New test. * gcc.dg/Walloc-size-larger-than-5.c: New test. * gcc.dg/Walloc-size-larger-than-6.c: New test. * gcc.dg/Walloc-size-larger-than-7.c: New test. * gcc.dg/Walloc-size-larger-than-8.c: New test. * gcc.dg/Walloc-size-larger-than-9.c: New test. * gcc.dg/Walloc-size-larger-than.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-1.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-10.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-11.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-12.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-13.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-14.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-15.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-16.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-2.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-3.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-5.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-6.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-7.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-8.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-9.c branches/gcc-7-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/calls.c branches/gcc-7-branch/gcc/doc/invoke.texi branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/86188] Enhancement to std::merge, constexpr check of iterator types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188 --- Comment #2 from Josh Marshall --- That looks similar enough. But I think the Bidirectional iterator tag in the case of sorting is expressive enough and for std::merge, either forward iterator tags or output iterator tags would express the desired characteristics suitably. If someone can't create an iterator without those needed tags but can create an iterator with the required characteristics I would be very surprised.
[Bug c++/84918] Better handling of "std::cout >> 42;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84918
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-06-18
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #3 from Eric Gallager ---
(In reply to David Malcolm from comment #0)
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvs5hjj/
> points out:
>
> > What is the current error message for
>
> std::cout >> 42;
>
> > On older compilers this would generate roughly 100 lines of unreadable
> > error messages, so I detect and fix it in the static analyzer I wrote.
>
> Checking on godbolt.org:
>
> #include
> void test ()
> {
> std::cout >> 42;
> }
>
> we currently spew dozens of lines of diagnostics.
>
> May be worth special-casing this, and offering a fix-it hint to convert ">>"
> to "<<", if sane (and vice-versa).
Confirmed...
(In reply to Jonathan Wakely from comment #1)
> This seems pretty low priority though
...as an enhancement then. (also ASSIGNED since there's an assignee)
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-18 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- (In reply to David Malcolm from comment #0) > As reported by user "jcoffland" on Hacker News: > https://news.ycombinator.com/item?id=16598071 > > > One improvement I'd like to see is a simplified error message > > for mismatched overloaded calls. If you make an overloaded call > > for which the is no matching conversion or if the conversation is > > ambiguous the compiler will "helpfully" dump a list of possibly > > matching overloaded function signatures. The list can be hundreds > > of lines long. > > > > For example, when you try to pipe a class to std::cout that > > doesn't have an std::ostream <<(std::ostream &, const X &). > > Perhaps instead of dumping the complete function signatures it > > could show one function signature followed by a list of types > > accepted as the second parameter. Since the signatures are > > otherwise the same. Such improvements could also reduce > > template error spew. > > I hope to have a look at this in the GCC 9 timeframe, so filing this here. OK, changing status to ASSIGNED then
[Bug middle-end/82063] issues with arguments enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063 --- Comment #9 from Martin Sebor --- Author: msebor Date: Mon Jun 18 23:31:53 2018 New Revision: 261719 URL: https://gcc.gnu.org/viewcvs?rev=261719=gcc=rev Log: PR c/82063 - issues with arguments enabled by -Wall gcc/ChangeLog: PR c/82063 * calls.c (alloc_max_size): Correct a logic error/typo. Treat excessive arguments as infinite. Warn for invalid arguments. * doc/invoke.texi (-Walloc-size-larger-than): Update. gcc/testsuite/ChangeLog: PR c/82063 * gcc.dg/Walloc-size-larger-than-1.c: New test. * gcc.dg/Walloc-size-larger-than-10.c: New test. * gcc.dg/Walloc-size-larger-than-11.c: New test. * gcc.dg/Walloc-size-larger-than-12.c: New test. * gcc.dg/Walloc-size-larger-than-13.c: New test. * gcc.dg/Walloc-size-larger-than-14.c: New test. * gcc.dg/Walloc-size-larger-than-15.c: New test. * gcc.dg/Walloc-size-larger-than-16.c: New test. * gcc.dg/Walloc-size-larger-than-2.c: New test. * gcc.dg/Walloc-size-larger-than-3.c: New test. * gcc.dg/Walloc-size-larger-than-4.c: New test. * gcc.dg/Walloc-size-larger-than-5.c: New test. * gcc.dg/Walloc-size-larger-than-6.c: New test. * gcc.dg/Walloc-size-larger-than-7.c: New test. * gcc.dg/Walloc-size-larger-than-8.c: New test. * gcc.dg/Walloc-size-larger-than-9.c: New test. * gcc.dg/Walloc-size-larger-than.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-10.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-11.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-12.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-13.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-14.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-15.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-16.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-2.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-3.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-5.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-6.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-7.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-8.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than-9.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/Walloc-size-larger-than.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/calls.c branches/gcc-8-branch/gcc/doc/invoke.texi branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86205] New: ICE on valid C++11 code: in type_dependent_expression_p, at cp/pt.c:25193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205
Bug ID: 86205
Summary: ICE on valid C++11 code: in
type_dependent_expression_p, at cp/pt.c:25193
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It appears to be a recent regression.
$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180618 (experimental) [trunk revision 261707] (GCC)
$
$ g++-8.1.0 -c tmp.cpp
$
$ g++tk -c tmp.cpp
tmp.cpp:8:68: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:25193
template < class T > auto g () -> decltype (b ? f < int > : throw 0)
^
0x82c691 type_dependent_expression_p(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:25192
0x831f97 instantiation_dependent_r
../../gcc-source-trunk/gcc/cp/pt.c:25322
0x1195df4 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 >*))
../../gcc-source-trunk/gcc/tree.c:11407
0x1195870 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc-source-trunk/gcc/tree.c:11749
0x826127 instantiation_dependent_uneval_expression_p(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:25352
0x8b0533 finish_decltype_type(tree_node*, bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:8751
0x7ff66d cp_parser_decltype
../../gcc-source-trunk/gcc/cp/parser.c:14252
0x7fd95f cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:17158
0x7ee741 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16945
0x7ef6e2 cp_parser_type_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:21219
0x7fb261 cp_parser_type_id_1
../../gcc-source-trunk/gcc/cp/parser.c:21062
0x7face7 cp_parser_trailing_type_id
../../gcc-source-trunk/gcc/cp/parser.c:21153
0x7face7 cp_parser_late_return_type_opt
../../gcc-source-trunk/gcc/cp/parser.c:20978
0x7face7 cp_parser_direct_declarator
../../gcc-source-trunk/gcc/cp/parser.c:20151
0x7face7 cp_parser_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19982
0x808ff1 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19499
0x80a141 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27400
0x80a27c cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:26999
0x80ab83 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27233
0x80ab83 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:27251
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$
--
bool b;
template < class T > int f ()
{
return 0;
}
template < class T > auto g () -> decltype (b ? f < int > : throw 0)
{
return 0;
}
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #7 from Martin Sebor --- Adjusted patch committed into trunk in r261718.
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #6 from Martin Sebor --- Author: msebor Date: Mon Jun 18 22:17:57 2018 New Revision: 261718 URL: https://gcc.gnu.org/viewcvs?rev=261718=gcc=rev Log: PR middle-end/85602 - -Wsizeof-pointer-memaccess for strncat with size of source gcc/c-family/ChangeLog: PR middle-end/85602 * c-warn.c (sizeof_pointer_memaccess_warning): Check for attribute nonstring. gcc/ChangeLog: PR middle-end/85602 * calls.c (maybe_warn_nonstring_arg): Handle strncat. * tree-ssa-strlen.c (is_strlen_related_p): Make extern. Handle integer subtraction. (maybe_diag_stxncpy_trunc): Handle nonstring source arguments. * tree-ssa-strlen.h (is_strlen_related_p): Declare. gcc/testsuite/ChangeLog: PR middle-end/85602 * gcc.dg/attr-nonstring-2.c: Adjust text of expected warning. * c-c++-common/attr-nonstring-8.c: New test. Added: trunk/gcc/testsuite/c-c++-common/attr-nonstring-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/attr-nonstring-2.c trunk/gcc/tree-ssa-strlen.c trunk/gcc/tree-ssa-strlen.h
[Bug tree-optimization/86199] warn on calls to strlen with same argument as in strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86199
--- Comment #1 from Martin Sebor ---
Ditto for strdup vs strndup, although there it might be worth considering
diagnosing only calls where the strndup bound is equal the size of the source
array, as in:
char a[4], *p, *q;
void f (void)
{
p = __builtin_strdup (a); // possibly unsafe? if not then...
// ...
q = __builtin_strndup (a, sizeof a); // this could be replaced by strdup()
}
[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86114, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86125 --- Comment #2 from Martin Sebor --- Another similar bug is pr86114. The invalid memcpy declaration will be diagnosed (and possibly even discarded in favor of the correct one) once pr86125 has been fixed.
[Bug c/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86196 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86196
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||8.1.0
Keywords||diagnostic
Last reconfirmed||2018-06-18
CC||msebor at gcc dot gnu.org
Blocks||84774
Ever confirmed|0 |1
Summary|Bogus -Wrestrict on memcpy |[9 Regression] Bogus
||-Wrestrict on memcpy
||between array elements at
||unequal indices
Known to fail||9.0
--- Comment #1 from Martin Sebor ---
Confirmed with the simplified test case below. The "offset [0, 8]" notation
indicates the range the offset into an array is determined to be in. The bug
is caused by GCC incorrectly computing the offset to be between 0 and 8 bytes
(the 8 is the size of the struct).
$ cat pr86196.c && gcc -O2 -S -Wall pr86196.c
struct S { int i; void *p; };
void g (struct S *a, int i, int j)
{
if (i != j)
__builtin_memcpy ([j], [i], sizeof (struct S));
}
pr86196.c: In function ‘g’:
pr86196.c:6:5: warning: ‘__builtin_memcpy’ accessing 16 bytes at offsets [0, 8]
and [0, 8] overlaps between 8 and 16 bytes at offset [0, 8] [-Wrestrict]
__builtin_memcpy ([j], [i], sizeof (struct S));
^~
The regression was introduced in r260280:
r260280 | msebor | 2018-05-15 22:30:38 -0400 (Tue, 15 May 2018) | 15 lines
PR tree-optimization/85753 - missing -Wrestrict on memcpy into a member array
gcc/ChangeLog:
PR tree-optimization/85753
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Handle
RECORD_TYPE in addition to ARRAY_TYPE.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict
[Bug c++/86200] [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/86191] Partial ordering with an expression involving non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86191
Jason Merrill changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|[6/7/8/9 Regression] A |Partial ordering with an
|missing error message? |expression involving
||non-type template
||parameters
--- Comment #4 from Jason Merrill ---
(In reply to zhonghao from comment #0)
> The code is as follow:
>
> template struct g {};
>
> template void f(g) { }
> template void f(g) { }
>
> int main()
> {
> f<4,2>(g<4/2>());
> }
>
> When clang++ compiles the code, it produces the following messages:
> 1gcc01.cpp:8:3: error: call to 'f' is ambiguous
> 1gcc01.cpp:3:29: note: candidate function [with i = 4, j = 2]
> 1gcc01.cpp:4:29: note: candidate function [with i = 4, j = 2]
> template void f(g) { }
>
> However, when g++ compiles the code, it does not produce any error messages.
> Is the code legal or not? For me, it seems that the messages of clang++ are
> reasonable.
In partial ordering, it seems that we can deduce j#2 to i#1/j#1, but we can't
do any deduction in the other direction, so f#1 is more specialized. We don't
need to deduce a value for i#2 because it's not used in the function
parameters. I don't see why this would be ambiguous.
[Bug tree-optimization/86204] [9 Regression] wrong strlen result after prior strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86204 --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01087.html
[Bug tree-optimization/86204] [9 Regression] wrong strlen result after prior strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86204 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-18 Blocks||83819 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/86204] New: [9 Regression] wrong strlen result after prior strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86204
Bug ID: 86204
Summary: [9 Regression] wrong strlen result after prior strnlen
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: ---
A bug in the strnlen() implementation committed in r261705 lets a strnlen()
result be substituted for the result of subsequent calls to strlen() with the
same argument:
$ cat c.c && gcc -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c &&
./a.out
char a[4] = "123";
int main (void)
{
unsigned n0 = __builtin_strnlen (a, 1);
unsigned n1 = __builtin_strlen (a);
if (n0 != 1 || n1 != 3)
__builtin_abort ();
}
;; Function main (main, funcdef_no=0, decl_uid=1899, cgraph_uid=1,
symbol_order=1) (executed once)
main ()
{
[count: 0]:
__builtin_abort ();
}
Aborted (core dumped)
[Bug target/85358] PowerPC: Using -mabi=ieeelongdouble -mcpu=power9 breaks __ibm128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85358 --- Comment #1 from Michael Meissner --- Author: meissner Date: Mon Jun 18 19:10:08 2018 New Revision: 261712 URL: https://gcc.gnu.org/viewcvs?rev=261712=gcc=rev Log: [gcc] 2018-06-18 Michael Meissner PR target/85358 * config/rs6000/rs6000-modes.def (toplevel): Rework the 128-bit floating point modes, so that IFmode is numerically greater than TFmode, which is greater than KFmode using FRACTIONAL_FLOAT_MODE to declare the ordering. This prevents IFmode from being converted to TFmode when long double is IEEE 128-bit on an ISA 3.0 machine. Include rs6000-modes.h to share the fractional values between genmodes* and the rest of the compiler. (IFmode): Likewise. (KFmode): Likewise. (TFmode): Likewise. * config/rs6000/rs6000-modes.h: New file. * config/rs6000/rs6000.c (rs6000_debug_reg_global): Change the meaning of rs6000_long_double_size so that 126..128 selects an appropriate 128-bit floating point type. (rs6000_option_override_internal): Likewise. * config/rs6000/rs6000.h (toplevel): Include rs6000-modes.h. (TARGET_LONG_DOUBLE_128): Change the meaning of rs6000_long_double_size so that 126..128 selects an appropriate 128-bit floating point type. (LONG_DOUBLE_TYPE_SIZE): Update comment. * config/rs6000/rs6000.md (trunciftf2): Correct the modes of the source and destination to match the standard usage. (truncifkf2): Likewise. (copysign3, IEEE iterator): Rework copysign of float128 on ISA 2.07 to use an explicit clobber, instead of passing in a temporary. (copysign3_soft): Likewise. [libgcc] 2018-06-18 Michael Meissner * config/rs6000/t-float128 (FP128_CFLAGS_SW): Compile float128 support modules with -mno-gnu-attribute. * config/rs6000/t-float128-hw (FP128_CFLAGS_HW): Likewise. Added: trunk/gcc/config/rs6000/rs6000-modes.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-modes.def trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md trunk/libgcc/ChangeLog trunk/libgcc/config/rs6000/t-float128 trunk/libgcc/config/rs6000/t-float128-hw
[Bug c++/86193] [7/8/9 Regression] A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193
Jason Merrill changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #2 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to zhonghao from comment #0)
> > I tried the latest g++, but it does not accept the code. BTW, clang++
> > accepts the code. Is this a recurring bug?
>
> No, it's rejected for a different reason, so it's not the same bug.
>
> It started to be rejected with r243868:
>
> Check that a partial specialization is more specialized.
Indeed.
[temp.class.spec]: The specialization shall be more specialized than the
primary template (17.6.5.2).
Checking that is equivalent to resolving the partial ordering of function
templates in
template
struct identity
{
typedef T type;
};
template
struct foo {};
template
void fn(foo) = delete;
template
void fn(foo,A2>);
int main()
{
fn(foo,0>()); // error here
}
which, similarly, G++ (and EDG) rejects, and clang accepts.
I think G++ is right here: when we try to deduce values for T1 and A1 in
partial ordering, we deduce T1 to identity, but we can't deduce anything
for A1 because we don't know that the types are compatible. You can work
around that by changing your partial specialization to
template ::type A>
struct foo, A> {};
This does seem like an underspecified area in the standard.
[Bug tree-optimization/86203] duplicate non-constant call to strlen() not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86203 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79547 Blocks||83819 --- Comment #1 from Martin Sebor --- Intel ICC emits just one call to __intel_sse2_strlen. Clang emits two calls like GCC. See also bug 79547 for a similar missed optimization (the bug was fixed in GCC 7). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug c/86202] [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug tree-optimization/86203] New: duplicate non-constant call to strlen() not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86203
Bug ID: 86203
Summary: duplicate non-constant call to strlen() not folded
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: ---
In the test case below, GCC emits two calls to strlen() even though only one is
necessary: the second call can be replaced by the assignment 'n1 = n0' Cl
$ cat d.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout d.c
unsigned n0, n1;
void f (const char *s)
{
n0 = __builtin_strlen (s);
n1 = __builtin_strlen (s); // should substitute: n1 = n0;
}
;; Function f (f, funcdef_no=0, decl_uid=1958, cgraph_uid=0, symbol_order=2)
f (const char * s)
{
long unsigned int _1;
unsigned int _2;
long unsigned int _3;
unsigned int _4;
[local count: 1073741825]:
_1 = __builtin_strlen (s_6(D));
_2 = (unsigned int) _1;
n0 = _2;
_3 = __builtin_strlen (s_6(D)); // unnecessary strlen() call
_4 = (unsigned int) _3;
n1 = _4;
return;
}
[Bug c/86202] [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |8.2
[Bug c/86202] [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r251347.
[Bug c++/86201] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c/86202] New: [8/9 Regression] ICE in get_range_info, at tree-ssanames.c:407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202
Bug ID: 86202
Summary: [8/9 Regression] ICE in get_range_info, at
tree-ssanames.c:407
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20170820 and 20170910 :
$ cat z1.c
void *memcpy (void *, void *, __SIZE_TYPE__ *);
void *a, *b;
void f (void)
{
long unsigned int c;
memcpy (a, b, c);
}
$ gcc-9-20180617 -c z1.c
z1.c: In function 'f':
z1.c:6:17: warning: passing argument 3 of 'memcpy' makes pointer from integer
without a cast [-Wint-conversion]
memcpy (a, b, c);
^
z1.c:1:7: note: expected 'long unsigned int *' but argument is of type 'long
unsigned int'
void *memcpy (void *, void *, __SIZE_TYPE__ *);
^~
z1.c:6:3: internal compiler error: in get_range_info, at tree-ssanames.c:407
memcpy (a, b, c);
^~~~
0xc57d65 get_range_info(tree_node const*, generic_wide_int*,
generic_wide_int*)
../../gcc/tree-ssanames.c:407
0x85e44c size_must_be_zero_p
../../gcc/gimple-fold.c:653
0x85e44c gimple_fold_builtin_memory_op
../../gcc/gimple-fold.c:690
0x85ff9f gimple_fold_builtin
../../gcc/gimple-fold.c:3644
0x862b5b gimple_fold_call
../../gcc/gimple-fold.c:4153
0x862b5b fold_stmt_1
../../gcc/gimple-fold.c:4817
0x884fc8 gimplify_call_expr
../../gcc/gimplify.c:3424
0x87c757 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11369
0x87e776 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6618
0x87baf3 gimplify_statement_list
../../gcc/gimplify.c:1763
0x87baf3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11826
0x87e776 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6618
0x87f25f gimplify_bind_expr
../../gcc/gimplify.c:1331
0x87bda6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11598
0x87e776 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6618
0x87fac8 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12592
0x87fd95 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12736
0x73c007 cgraph_node::analyze()
../../gcc/cgraphunit.c:669
0x73eb77 analyze_functions
../../gcc/cgraphunit.c:1123
0x73f172 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2673
[Bug c++/86200] [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |8.2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r257627.
[Bug c++/86201] New: ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86201
Bug ID: 86201
Summary: ICE: Error reporting routines re-entered
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With option -std=c++11 or newer, down to at least gcc-4.8,
due to a missing return value :
$ cat z1.cc
template
auto fn1 (V&& v) -> decltype(U(v))
{
return; ///
}
void fn2 ()
{
fn1(1.0);
}
$ gcc-9-20180617 -c z1.cc
'
Internal compiler error: Error reporting routines re-entered.
0x772d1f cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/cp/typeck.c:4739
0x66d73b ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:836
0x6349c1 convert_like_real
../../gcc/cp/call.c:7118
0x63f07a perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../../gcc/cp/call.c:10797
0x775836 build_static_cast_1
../../gcc/cp/typeck.c:7039
0x776497 cp_build_c_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:7821
0x77e646 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2131
0x71bea9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17864
0x7292e1 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14899
0x69c900 dump_template_bindings
../../gcc/cp/error.c:397
0x69c900 dump_substitution
../../gcc/cp/error.c:1525
0x69d0f8 dump_substitution
../../gcc/cp/cp-tree.h:5955
0x69d0f8 dump_function_decl
../../gcc/cp/error.c:1681
0x6a2862 decl_to_string
../../gcc/cp/error.c:3056
0x6a2862 cp_printer
../../gcc/cp/error.c:4073
0x12f9eb3 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1375
0x12fad10 pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1437
0x12fade4 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:1641
0x69b816 print_instantiation_full_context
../../gcc/cp/error.c:3464
0x69b816 maybe_print_instantiation_context
../../gcc/cp/error.c:3607
[Bug c++/86200] New: [8/9 Regression] ICE in dependent_type_p, at cp/pt.c:24634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86200
Bug ID: 86200
Summary: [8/9 Regression] ICE in dependent_type_p, at
cp/pt.c:24634
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180211 and 20180218.
Derived from g++.dg/cpp0x/lambda/lambda-variadic1.C :
$ cat z1.cc
template
static void foo()
{
[](Args, int x) {
x;
};
}
int main()
{
foo();
}
$ gcc-9-20180617 -c z1.cc
z1.cc: In instantiation of 'void foo() [with Args = {}]':
z1.cc:10:7: required from here
z1.cc:4:3: internal compiler error: in dependent_type_p, at cp/pt.c:24634
[](Args, int x) {
^
0x7163e0 dependent_type_p(tree_node*)
../../gcc/cp/pt.c:24634
0x67bff8 require_complete_types_for_parms
../../gcc/cp/decl.c:12556
0x67bff8 check_function_type
../../gcc/cp/decl.c:14722
0x67bff8 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:14936
0x6b2df4 start_lambda_function(tree_node*, tree_node*)
../../gcc/cp/lambda.c:1420
0x71a577 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:17620
0x71b748 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18928
0x720357 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17396
0x71ede5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16597
0x7201ec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16583
0x72005d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16880
0x71e961 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24027
0x739e0b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24141
0x698f23 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4707
[Bug target/85905] cannot build for netbsd/alpha (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85905 coypu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from coypu --- Committed in revision 261707.
[Bug target/71659] _xgetbv intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659 --- Comment #3 from Jeffrey Walton --- (In reply to postmaster from comment #2) > Portability is one main reason to add missing intrinsics... with combination > of cpuid check and _xgetbv() we can cleanly check if AVX or MPX is available > at run-time. We can also check specific instructions during configure > process to see if we need to add workarounds for bad or missing > functions/intrinsics. +1. We were trying to use Intel's algorithm described at https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled . We should only need __get_cpuid and _xgetbv. We should not need that nasty GCC inline assembly.
[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|6.5 |9.0 --- Comment #4 from Jason Merrill --- Fixed for GCC 9, not worth backporting since it already worked in release mode.
[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Jun 18 18:16:38 2018 New Revision: 261709 URL: https://gcc.gnu.org/viewcvs?rev=261709=gcc=rev Log: PR c++/86171 - ICE with recursive alias instantiation. * pt.c (tsubst_decl): Handle recursive alias instantiation. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-65.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug tree-optimization/86199] warn on calls to strlen with same argument as in strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86199 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Severity|normal |enhancement
[Bug tree-optimization/86199] warn on calls to strlen with same argument as in strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86199 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-18 Ever confirmed|0 |1
[Bug tree-optimization/86199] New: warn on calls to strlen with same argument as in strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86199
Bug ID: 86199
Summary: warn on calls to strlen with same argument as in
strnlen
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 the call to strlen() in the test case below is most likely unsafe because
the subsequent call to strnlen() suggests that the array need not be
nul-terminated. If it is nul-terminated, then the call to strnlen() can be
replaced by strlen(). Either way, the code looks suspicious and diagnosing it
would be helpful.
$ cat c.c && gcc -O2 -S -Wall -Wextra c.c
char a[4];
unsigned n0, n1;
void f (void)
{
n0 = __builtin_strlen (a); // possibly unsafe?
// ...
n1 = __builtin_strnlen (a, sizeof a); // could be replaced by strlen()?
}
[Bug c++/86195] [9 Regression] Ref-qualified nested class member function issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86195 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW Known to work||7.3.0, 8.1.1 Summary|Ref-qualified nested class |[9 Regression] |member function issue |Ref-qualified nested class ||member function issue Known to fail||8.1.0, 9.0 --- Comment #3 from Jonathan Wakely --- It seems to be fixed in (In reply to Paolo Monteverde from comment #2) > I spotted the original error on g++ (GCC) 8.1.1 20180531 running on Arch > Linux. OK, it seems to be fixed in 8.1.1 20180615 > The simplified example above is failing on > https://wandbox.org/permlink/VMBVdHgzkcH2xLlb. The only needed option is > -std=c++14 or above. That's 8.1.0, which is even older. I'll try to find what fixed it on the branch.
[Bug other/86198] New: Libbacktrace does not properly work with ".note.gnu.build-id" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Bug ID: 86198
Summary: Libbacktrace does not properly work with
".note.gnu.build-id" section
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: d.khalikov at partner dot samsung.com
Target Milestone: ---
An error happens when libbacktrace is reading ".note.gnu.build-id" section and
effects the feature which allows to read stripped debuginfo with build-id.
Steps to reproduce:
(I will use libasan in my test case, because it's easy and libbacktrace is a
default symbolizer for libasan in GCC).
1.$cat a.cc
int main () {
int *ptr = new int[1];
return ptr[1];
}
2.$g++ -o a a.cc -fsanitize=address -g
-Wl,--build-id=0x0123456789abcdef0123456789abcdef01234567
3.$objcopy --only-keep-debug a a.debug
4.$strip a
5. In this step we need a superuser rights:
#mkdir /usr/lib/debug/.build-id/01
#ln -s `pwd`/a.debug
/usr/lib/debug/.build-id/01/23456789abcdef0123456789abcdef01234567.debug
6. ./a
output:
...
#0 0x4007cf (/path/to/exe/a+0x4007cf)
...
The problem at the libbacktrace/elf.c line 2871
2866 buildid_view_valid = 1;
2867 note = (const b_elf_note *) buildid_view.data;
2868 if (note->type == NT_GNU_BUILD_ID
2869 && note->namesz == 4
2870 && strncmp (note->name, "GNU", 4) == 0
2871 && shdr->sh_size < 12 + ((note->namesz + 3) & ~ 3) +
note->descsz)
2872 {
2873 buildid_data = >name[0] + ((note->namesz + 3) & ~ 3);
2874 buildid_size = note->descsz;
2875 }
2876 }
The size for the ".note.gnu.build-id" section by default is 36 bytes (12 + 4 +
20)
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id
So, the cmp on line 2871 should be changed from less to less or equal
2871 && shdr->sh_size <= 12 + ((note->namesz + 3) & ~ 3) +
note->descsz)
[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171
--- Comment #2 from Jason Merrill ---
A well-formed variant:
template struct A;
template using B = typename A::X;
template struct A {
typedef int X;
typedef B U;
};
B b;
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from zenith432 at users dot sourceforge.net --- Done. https://sourceware.org/bugzilla/show_bug.cgi?id=23309
[Bug tree-optimization/81384] built-in form of strnlen missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81384 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Implemented in r261705.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 81384, which changed state. Bug 81384 Summary: built-in form of strnlen missing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81384 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/81384] built-in form of strnlen missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81384 --- Comment #3 from Martin Sebor --- Author: msebor Date: Mon Jun 18 16:32:59 2018 New Revision: 261705 URL: https://gcc.gnu.org/viewcvs?rev=261705=gcc=rev Log: PR tree-optimization/81384 - built-in form of strnlen missing gcc/ChangeLog: PR tree-optimization/81384 * builtin-types.def (BT_FN_SIZE_CONST_STRING_SIZE): New. * builtins.c (expand_builtin_strnlen): New function. (expand_builtin): Call it. (fold_builtin_n): Avoid setting TREE_NO_WARNING. * builtins.def (BUILT_IN_STRNLEN): New. * calls.c (maybe_warn_nonstring_arg): Handle BUILT_IN_STRNLEN. Warn for bounds in excess of maximum object size. * tree-ssa-strlen.c (maybe_set_strlen_range): Return tree representing single-value ranges. Handle strnlen. (handle_builtin_strlen): Handle strnlen. (strlen_check_and_optimize_stmt): Same. * doc/extend.texi (Other Builtins): Document strnlen. gcc/testsuite/ChangeLog: PR tree-optimization/81384 * gcc.c-torture/execute/builtins/lib/strnlen.c: New test. * gcc.c-torture/execute/builtins/strnlen-lib.c: New test. * gcc.c-torture/execute/builtins/strnlen.c: New test. * gcc.dg/attr-nonstring-2.c: New test. * gcc.dg/attr-nonstring-3.c: New test. * gcc.dg/attr-nonstring-4.c: New test. * gcc.dg/strlenopt-45.c: New test. * gcc.dg/strlenopt.h (strnlen): Declare. Added: trunk/gcc/testsuite/gcc.c-torture/execute/builtins/lib/strnlen.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen-lib.c trunk/gcc/testsuite/gcc.c-torture/execute/builtins/strnlen.c trunk/gcc/testsuite/gcc.dg/attr-nonstring-2.c trunk/gcc/testsuite/gcc.dg/attr-nonstring-3.c trunk/gcc/testsuite/gcc.dg/attr-nonstring-4.c trunk/gcc/testsuite/gcc.dg/strlenopt-45.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtin-types.def trunk/gcc/builtins.c trunk/gcc/builtins.def trunk/gcc/calls.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c trunk/gcc/testsuite/gcc.dg/strlenopt.h trunk/gcc/tree-ssa-strlen.c
[Bug c++/86195] Ref-qualified nested class member function issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86195 --- Comment #2 from Paolo Monteverde --- (In reply to Jonathan Wakely from comment #1) > This started to fail on trunk with r251438 > > It seems to have been fixed on the gcc-8-branch though. 8.1.1 is not a > release, we need to know exactly which version you're using (as requested by > https://gcc.gnu.org/bugs/ when submitting a new bug report). I spotted the original error on g++ (GCC) 8.1.1 20180531 running on Arch Linux. The simplified example above is failing on https://wandbox.org/permlink/VMBVdHgzkcH2xLlb. The only needed option is -std=c++14 or above.
[Bug c++/86195] Ref-qualified nested class member function issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86195 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This started to fail on trunk with r251438 It seems to have been fixed on the gcc-8-branch though. 8.1.1 is not a release, we need to know exactly which version you're using (as requested by https://gcc.gnu.org/bugs/ when submitting a new bug report).
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-18 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Confirmed. Mine.
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 --- Comment #1 from Bill Schmidt --- Note, this is restricted to powerpc64le using ELFv2 ABI.
[Bug target/86197] POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197 Bill Schmidt changed: What|Removed |Added CC||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Target Milestone|--- |8.2
[Bug target/86197] New: POWERPC: float128 parameter passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86197
Bug ID: 86197
Summary: POWERPC: float128 parameter passing
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lei at ca dot ibm.com
Target Milestone: ---
Float128 should be considered qualified vector arguments and should be passed
in vector registers for homogeneous aggregates of up to 8 members.
Currently for homogeneous aggregates of 5+, they are being passed via the
stack.
$ cat a.c
struct E5 {
__float128 a[5];
};
__float128 testfp128_05(struct E5 a) {
return a.a[4];
}
Generated asm:
testfp128_05:
std 3,32(1)
std 4,40(1)
std 5,48(1)
std 6,56(1)
std 7,64(1)
std 8,72(1)
std 9,80(1)
std 10,88(1)
lxv 34,96(1)
blr
Compiler version:
gcc (GCC) 7.3.0
[Bug c/86196] New: Bogus -Wrestrict on memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86196
Bug ID: 86196
Summary: Bogus -Wrestrict on memcpy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk (on Linux x86_64), and doesn't seem to be covered by existing
bugs referenced from meta bug 84774:
> $ gcc --version
> gcc (GCC) 9.0.0 20180618 (experimental)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ cat test.c
> #include
> struct S {
> int n;
> void * p;
> };
> void f(struct S * a, size_t n) {
> size_t i = 0, j = 0;
> for (; i != n; ++i) {
> if (a[i].n == 0) {
> if (i != j) {
> memcpy([j], [i], sizeof (struct S));
> }
> ++j;
> }
> }
> }
> $ gcc -Wall -c test.c
> test.c: In function ‘f’:
> test.c:11:17: warning: ‘memcpy’ accessing 16 bytes at offsets [0, 8] and [0,
> 8] overlaps between 8 and 16 bytes at offset [0, 8] [-Wrestrict]
> memcpy([j], [i], sizeof (struct S));
> ^~~
Also, I do not understand what that "offset [0, 8]" notation is supposed to
mean.
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- > but really gets an empty blob from the LTO plugin for foo. Are you sure about this? Compiling with -save-temps shows that the symbol is present in GCC's assembly output; specifying --print-gc-sections also shows that the linker is discarding it: /usr/bin/ld.bfd: Removing unused section '.text.KeepMe' in file '/tmp/ccWbtSKK.ltrans0.ltrans.o' Gold linker does not exhibit this (try -fuse-ld=gold). Can you report it against the BFD linker at sourceware.org/bugzilla?
[Bug libstdc++/86189] not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189 --- Comment #5 from Jonathan Wakely --- [allocator.requirements]
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
With ld 2.30 it seems to work for me with a simple
void foo () {}
int main() { return 0; }
> gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections
--- Comment #2 from zenith432 at users dot sourceforge.net ---
It's the visibility that breaks it.
Try
gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections
-fvisibility=hidden
Here's a full summary of observed behavior
Without '-u foo', foo gets discarded for both LTO, non-LTO build and with any
visibility.
With '-u foo'
On non-LTO build, foo always gets forced in regardless of visibility. The
symbol's visibility is not supposed to play a role in the decision-making of
applying the '-u foo'.
On LTO build
- if foo's visibility is either default or protected, it gets forced in.
- if foo's visibility is either hidden or internal, it gets discarded.
The reason I opened this bug against GCC and not LD - is that LD does not
complain about an undefined foo even if '--require-defined=foo' is used in
place of '-u foo'. LD believes it is force-including foo, but really gets an
empty blob from the LTO plugin for foo.
[Bug c++/86195] New: Ref-qualified nested class member function issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86195
Bug ID: 86195
Summary: Ref-qualified nested class member function issue
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paolo.monteverde at gmail dot com
Target Milestone: ---
#include
template
struct A final {
struct B final {
template
void foo(Args &&... args) && {
A::foo(std::forward(args)...);
}
};
private:
template
static auto foo(Args &&...) {}
};
int main() {
A::B{}.foo();
}
This code doesn't compile under GCC 8.1.1; it works on GCC 7.3.
If you rename the private static foo() member function (and its invocation) to
a name different than foo, the code will compile on GCC 8.1.1 too.
[Bug libstdc++/86189] not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
--- Comment #4 from Rian Quinn ---
Nope, I think that is the root of the issue. Where exactly does the spec
state that as this is the first I have heard of this.
Thanks a ton,
- Rian
On Mon, Jun 18, 2018 at 6:31 AM, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
>
> Jonathan Wakely changed:
>
>What|Removed |Added
>
>
> Status|UNCONFIRMED |WAITING
>Last reconfirmed||2018-06-18
> Ever confirmed|0 |1
>
> --- Comment #1 from Jonathan Wakely ---
> (In reply to Rian Quinn from comment #0)
> > template
> > bool operator==(const myallocator4 &, const myallocator4 &)
> > { return false; }
> >
> > template
> > bool operator!=(const myallocator4 &, const myallocator4 &)
> > { return true; }
>
> Your allocators *always* compare unequal to all other instances of the same
> allocator. This is invalid, a copy-constructed allocator must compare
> equal to
> the original, and be able to deallocate its memory.
>
> I haven't analysed any further, but I assume that the containers are using
> a
> copy to deallocate, which is perfectly fine. If you think the problem lies
> elsewhere please reopen this.
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug sanitizer/80414] [UBSAN] segfault with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80414 Denis Khalikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Denis Khalikov --- Fixed.
[Bug c++/86180] Friend function definition not instantiated in certain circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86180 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- An almost exact duplicate. *** This bug has been marked as a duplicate of bug 82204 ***
[Bug c++/82204] G++ doesn't connect friend and extern declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82204 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 Ever confirmed|0 |1
[Bug c++/82204] G++ doesn't connect friend and extern declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82204 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #1 from Jonathan Wakely --- *** Bug 86180 has been marked as a duplicate of this bug. ***
[Bug c++/86074] gcc fails to compile a code sample
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86074 Jonathan Wakely changed: What|Removed |Added CC||bluescarni at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 78925 has been marked as a duplicate of this bug. ***
[Bug c++/78925] Inline friend template function not hidden during ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78925 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- This is not a bug. *** This bug has been marked as a duplicate of bug 86074 ***
[Bug c++/86191] [6/7/8/9 Regression] A missing error message?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86191 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org Known to work||4.4.7 Summary|A missing error message?|[6/7/8/9 Regression] A ||missing error message? Known to fail||4.5.0, 6.4.0, 7.3.0, 8.1.0, ||9.0 --- Comment #3 from Jonathan Wakely --- It stopped being ambiguous with r153957 PR c++/41703 * pt.c (check_undeduced_parms): New subroutine of... (more_specialized_fn): ...here. Undeduced template parms can make a template less specialized than another.
[Bug c++/86182] [8/9 Regression] gcc crashes when compiling the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86182 Jonathan Wakely changed: What|Removed |Added Keywords|accepts-invalid,|ice-on-valid-code, |ice-on-invalid-code |rejects-valid CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- I think the code is valid, so we regressed from rejects-valid to ice-on-valid-code at r253600 Various small C++ fixes. * typeck.c (condition_conversion): Assert !processing_template_decl. * semantics.c (finish_omp_clauses): Don't fold_build_cleanup_point_expr if processing_template_decl. (outer_var_p): A temporary can't be from an outer scope. * pt.c (type_dependent_expression_p): Fix dependency checking of functions without DECL_TEMPLATE_INFO. (instantiate_decl): Use lss_copy. * constexpr.c (is_valid_constexpr_fn): Fix lambdas before C++17.
[Bug c++/86191] A missing error message?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86191 --- Comment #2 from Jonathan Wakely --- This changed with GCC 4.5, it was ambiguous before then.
[Bug c++/86191] A missing error message?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86191 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- GCC seems to treat the first overload as more specialized and calls that one. I think that's a bug.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #61 from Andrew Jenner --- Sorry, once again I have been totally swamped by other work. It's now looking like I should have some time to work on this in early July.
[Bug libstdc++/86189] not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Your allocators *always* compare unequal to all other instances of the same > allocator. This is invalid, a copy-constructed allocator must compare equal > to the original, and be able to deallocate its memory. See the rows defining equality comparison and copy construction at http://en.cppreference.com/w/cpp/named_req/Allocator#Requirements Allocator propagation rules do not mean that the same specific instance of the allocator must be used for all allocations and deallocation, only one that compares equal to the original one. With your allocator that's obviously impossible, because no allocators ever compare equal (even when you compare an allocator to itself!) Stateful allocators need to be a lightweight handle for some allocation resource managed elsewhere, and two allocators compare equal if they use the same resource. That means that you should never depend on the identity (i.e. address) of allocator objects, only on their equivalence (as determined by operator==). Having looked at your code further, the test is simply completely broken. When an allocator propagates on copy assignment the allocator gets assigned, so that the "value" of the new allocator replaces the "value" of the old allocator. That doesn't change the allocator's address. The object still has the same address, it just gets a new "value". But your allocators don't have any "value" they only care about their identity (i.e. address). This report is INVALID. (In reply to Jonathan Wakely from comment #2) > You know you can just not name a parameter, instead of casting it to void? Ah yes, I see you've done that elsewhere.
[Bug libstdc++/86189] not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
--- Comment #2 from Jonathan Wakely ---
(In reply to Rian Quinn from comment #0)
> template
> myallocator4(const myallocator4 ) noexcept
> { (void) other; }
You know you can just not name a parameter, instead of casting it to void?
template
myallocator4(const myallocator4 &) noexcept
{ }
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
Yves Vandriessche changed:
What|Removed |Added
CC||yves.vandriessche at intel dot
com
--- Comment #18 from Yves Vandriessche ---
As mentioned by Sameer, thread_local now works, but the threadprivate OpenMP
directive still fails with a "declared 'threadprivate' after first use" error.
My test fragment, is as follows. It should only print a single "ctor" and twice
the same set of distinct pointers:
#include
#include
struct Foo {
Foo() {puts("ctor");}
int a;
};
int bar() {
int sum=0;
// // alternative to omp threadprivate, works with gcc
// thread_local Foo local;
#pragma omp parallel reduction(+:sum)
{
static Foo local;
#pragma omp threadprivate(local)
local.a = omp_get_thread_num();
printf("%p\n", );
sum += local.a;
}
printf("%d\n", sum);
return sum;
}
int main(int argc, char** argv) {
bar();
bar();
return 0;
}
[Bug libstdc++/86189] not equal allocators not behaving as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86189
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2018-06-18
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to Rian Quinn from comment #0)
> template
> bool operator==(const myallocator4 &, const myallocator4 &)
> { return false; }
>
> template
> bool operator!=(const myallocator4 &, const myallocator4 &)
> { return true; }
Your allocators *always* compare unequal to all other instances of the same
allocator. This is invalid, a copy-constructed allocator must compare equal to
the original, and be able to deallocate its memory.
I haven't analysed any further, but I assume that the containers are using a
copy to deallocate, which is perfectly fine. If you think the problem lies
elsewhere please reopen this.
[Bug c++/86183] Scoped enumeration instantiated even if not required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86183 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The definition of a member scoped enumaration type should not be instantiated by the implicit instantiation of the class template.
[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #5 from Jonathan Wakely --- *** Bug 86185 has been marked as a duplicate of this bug. ***
[Bug c++/86185] gcc does not reject the ill-formed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86185 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Please search for duplicates before copying every clang bug into our bugzilla, this is already known. *** This bug has been marked as a duplicate of bug 79009 ***
[Bug c++/86184] Shall gcc support this feature?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86184 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to zhonghao from comment #0) > gcc++ produces errors when compiling the following code: I don't see any errors. You didn't say which version of GCC you're using or what options you're using, as requested by https://gcc.gnu.org/bugs/
[Bug tree-optimization/86076] [7/8 Regression] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86076 --- Comment #7 from Wilco --- Author: wilco Date: Mon Jun 18 12:17:10 2018 New Revision: 261699 URL: https://gcc.gnu.org/viewcvs?rev=261699=gcc=rev Log: [testsuite] Add target pthread to pr86076.c Add missing target pthread to ensure test doesn't fail on bare-metal targets. Committed as obvious. testsuite/ PR tree-optimization/86076 * gcc.dg/pr86076.c: Add target pthread for bare-metal targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr86076.c
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- This regressed with r230365 "Merge C++ delayed folding branch."
[Bug c++/86193] [7/8/9 Regression] A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-18 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to zhonghao from comment #0) > I tried the latest g++, but it does not accept the code. BTW, clang++ > accepts the code. Is this a recurring bug? No, it's rejected for a different reason, so it's not the same bug. It started to be rejected with r243868: Check that a partial specialization is more specialized. * pt.c (process_partial_specialization): Use get_partial_spec_bindings to check that the partial specialization is more specialized than the primary template.
[Bug c++/86177] Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177 --- Comment #7 from Jonathan Wakely --- Lots of functions have such requirements and make it the caller's responsibility to meet those requirements. GCC is not a static analyser, you can't expect warnings about every possible bug in your code.
[Bug c++/86176] Wnull-dereference warning disappears with a call to std::cout on the line after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176 --- Comment #3 from Jonathan Wakely --- No, because GCC is not a static analyser.
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
--- Comment #4 from Jonathan Wakely ---
Further reduced:
typedef unsigned long size_t;
struct vector {
typedef size_t size_type;
size_type size();
};
bool func(vector vec, int var)
{
return vec.size() < static_cast(var);
}
sc.cc: In function 'bool func(vector, int)':
sc.cc:10:23: warning: conversion to 'vector::size_type {aka long unsigned int}'
from 'int' may change the sign of the result [-Wsign-conversion]
return vec.size() < static_cast(var);
^~~~
[Bug c++/86190] [6/7/8/9 Regression]-Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
Known to work||5.5.0
Summary|-Wsign-conversion ignores |[6/7/8/9
|explicit conversion in some |Regression]-Wsign-conversio
|cases |n ignores explicit
||conversion in some cases
Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0
--- Comment #3 from Jonathan Wakely ---
The manual does say that an explicit cast should silence the warning. This is a
regression since GCC 5, and only seems to happen when there's an indirection
through a typedef:
using size_t = unsigned long;
template struct vector {
using size_type = size_t;
size_type size();
};
struct A
{
int var;
vector vec;
bool func()
{
return vec.size() < static_cast(var);
}
};
int main()
{
A a;
a.func();
}
[Bug target/86194] [8/9 Regression] ICE: SIGSEGV in avoid_constant_pool_reference (simplify-rtx.c:215) with -O -g -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86194 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.2
[Bug c++/86193] [7/8/9 Regression] A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Known to work||6.4.0 Version|unknown |8.1.0 Target Milestone|--- |7.4 Summary|A recurring bug?|[7/8/9 Regression] A ||recurring bug?
[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/86194] New: [8/9 Regression] ICE: SIGSEGV in avoid_constant_pool_reference (simplify-rtx.c:215) with -O -g -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86194 Bug ID: 86194 Summary: [8/9 Regression] ICE: SIGSEGV in avoid_constant_pool_reference (simplify-rtx.c:215) with -O -g -mavx512bw Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 44290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44290=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -g -mavx512bw testcase.c -wrapper valgrind,-q,--num-callers=50 ==30755== Invalid read of size 2 ==30755==at 0xCE11AB: avoid_constant_pool_reference(rtx_def*) (simplify-rtx.c:215) ==30755==by 0xCD20BC: simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) (simplify-rtx.c:2162) ==30755==by 0xCD5559: simplify_gen_binary(rtx_code, machine_mode, rtx_def*, rtx_def*) (simplify-rtx.c:194) ==30755==by 0x1004FAB: adjust_mems(rtx_def*, rtx_def const*, void*) (var-tracking.c:1137) ==30755==by 0xCE3C17: simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def* (*)(rtx_def*, rtx_def const*, void*), void*) (simplify-rtx.c:429) ==30755==by 0xCE3413: simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def* (*)(rtx_def*, rtx_def const*, void*), void*) (simplify-rtx.c:553) ==30755==by 0xFFF255: adjust_mem_uses(rtx_def**, void*) (var-tracking.c:1160) ==30755==by 0x1001EC8: adjust_insn(basic_block_def*, rtx_insn*) [clone .isra.88] (var-tracking.c:1272) ==30755==by 0x101404A: vt_initialize() (var-tracking.c:10198) ==30755==by 0x101B1B7: variable_tracking_main_1 (var-tracking.c:10435) ==30755==by 0x101B1B7: variable_tracking_main (var-tracking.c:10488) ==30755==by 0x101B1B7: (anonymous namespace)::pass_variable_tracking::execute(function*) (var-tracking.c:10525) ==30755==by 0xBDA4A3: execute_one_pass(opt_pass*) (passes.c:2446) ==30755==by 0xBDADD7: execute_pass_list_1(opt_pass*) (passes.c:2535) ==30755==by 0xBDADE9: execute_pass_list_1(opt_pass*) (passes.c:2536) ==30755==by 0xBDADE9: execute_pass_list_1(opt_pass*) (passes.c:2536) ==30755==by 0xBDAE34: execute_pass_list(function*, opt_pass*) (passes.c:2546) ==30755==by 0x8416ED: cgraph_node::expand() (cgraphunit.c:2119) ==30755==by 0x842C3A: expand_all_functions (cgraphunit.c:2255) ==30755==by 0x842C3A: symbol_table::compile() [clone .part.55] (cgraphunit.c:2606) ==30755==by 0x845597: compile (cgraphunit.c:2665) ==30755==by 0x845597: symbol_table::finalize_compilation_unit() (cgraphunit.c:2699) ==30755==by 0xD06E6D: compile_file() (toplev.c:479) ==30755==by 0x688539: do_compile (toplev.c:2086) ==30755==by 0x688539: toplev::main(int, char**) (toplev.c:2221) ==30755==by 0x68AADA: main (main.c:39) ==30755== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==30755== during RTL pass: vartrack testcase.c: In function 'foo': testcase.c:20:1: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-261695-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-261695-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix gcc version 9.0.0 20180618 (experimental) (GCC)
[Bug c++/86193] New: A recurring bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193
Bug ID: 86193
Summary: A recurring bug?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
template
struct identity
{
typedef T type;
};
template
struct foo {};
template
struct foo, A> {};
int main()
{
foo,0> bar; // error here
}
It comes from a previous bug report
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44753).
It says that the code compiles on gcc-4.2/4.3/4.4, but does not compile on
gcc-4.5. It was fixed as Richard Biener said.
I tried the latest g++, but it does not accept the code. BTW, clang++ accepts
the code. Is this a recurring bug?
[Bug libstdc++/86188] Enhancement to std::merge, constexpr check of iterator types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188 --- Comment #1 from Jonathan Wakely --- See Bug 65861 which looks relevant, especially Bug 65861 comment 9
[Bug c++/80061] error on constexpr function with an unevaluated throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #5 from Jonathan Wakely --- *** Bug 86192 has been marked as a duplicate of this bug. ***
[Bug c++/86192] A not fully fixed bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86192 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- You didn't read Bug 70377 comment 2. *** This bug has been marked as a duplicate of bug 80061 ***
