[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #5 from Martin Liška --- (In reply to Andrew Pinski from comment #2) > (In reply to Martin Liška from comment #1) > > Created attachment 47974 [details] > > Reduced test-case > I doubt this is a reduced testcase. It is a reduced testcase for the ICE > but not the wrong code causing the ICE, see your comment below ... Yes. > > > (In reply to Martin Liška from comment #0) > > I can't reproduce that with a cross compiler and I noticed that one needs > > to bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy > > machine where I could reproduce that right now.. > > So if you use --disable-bootstrap, did you run the testsuite? That > sometimes will find which testcase is producing wrong code now. > The other way to find what is being miscompiled is bisect the commit which > introduced the problem and then compare the .o files for the stage which is > being compiled. > I would normally do that, but right now I only have a open build service worker output. That's why I'm asking for help somebody how can run the bootstrap locally. I hope IBM guys will help us.
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Martin Liška changed: What|Removed |Added Attachment #47973|0 |1 is obsolete|| --- Comment #4 from Martin Liška --- Created attachment 47975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47975=edit Build log Sorry, this is the proper build log.
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #3 from Andrew Pinski --- One question I have is which stage fails? Is it stage 2 or stage 3? Because if it is stage 3, then stage 2 is miscompiled which is causing a different miscompile in stage 3.
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code Status|NEW |WAITING --- Comment #2 from Andrew Pinski --- (In reply to Martin Liška from comment #1) > Created attachment 47974 [details] > Reduced test-case I doubt this is a reduced testcase. It is a reduced testcase for the ICE but not the wrong code causing the ICE, see your comment below ... (In reply to Martin Liška from comment #0) > I can't reproduce that with a cross compiler and I noticed that one needs > to bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy > machine where I could reproduce that right now.. So if you use --disable-bootstrap, did you run the testsuite? That sometimes will find which testcase is producing wrong code now. The other way to find what is being miscompiled is bisect the commit which introduced the problem and then compare the .o files for the stage which is being compiled. Note you also attached the incorrect log file. it is a log for building hfst-ospell
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Martin Liška changed: What|Removed |Added Target||ppc-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-05 CC||rguenth at gcc dot gnu.org Known to work||9.2.0 Host||ppc-linux-gnu Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 Build||ppc-linux-gnu
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #1 from Martin Liška --- Created attachment 47974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47974=edit Reduced test-case
[Bug bootstrap/94042] New: [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Bug ID: 94042
Summary: [10 Regression] Bootstrap fails on ppc-linux-gnu
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 47973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47973=edit
Build log
Doing bootstrap on ppc-linux-gnu I see many ICEs when building libsupc+:
[ 3338s] libtool: compile:
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/./gcc/xgcc
-shared-libgcc
-B/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/./gcc
-nostdinc++
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/src
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/src/.libs
-L/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem
/usr/powerpc64-suse-linux/include -isystem
/usr/powerpc64-suse-linux/sys-include -fno-checking
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/libstdc++-v3/../libgcc
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/powerpc64-suse-linux
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include
-I/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=bad_alloc.lo -O2 -D_FORTIFY_SOURCE=2
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -g -U_FORTIFY_SOURCE -D_GNU_SOURCE -c
../../../../libstdc++-v3/libsupc++/bad_alloc.cc -fPIC -DPIC -D_GLIBCXX_SHARED
-o bad_alloc.o
...
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:
In instantiation of 'struct std::integral_constant':
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:106:14:
required from here
[ 3338s]
/home/abuild/rpmbuild/BUILD/gcc-10.0.1+git175037/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/type_traits:62:17:
internal compiler error: in iterative_hash_template_arg, at cp/pt.c:1915
[ 3338s]62 | constexpr operator value_type() const noexcept { return
value; }
[ 3338s] | ^~~~
[ 3338s] make[5]: *** [Makefile:762: bad_alloc.lo] Error 1
I can't reproduce that with a cross compiler and I noticed that one needs to
bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy
machine where I could reproduce that right now..
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #40 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fe19699ae2883b252d30f98481d32dabff00744b commit r10-7035-gfe19699ae2883b252d30f98481d32dabff00744b Author: Jakub Jelinek Date: Thu Mar 5 08:00:04 2020 +0100 sccvn: Fix handling of POINTER_PLUS_EXPR in memset offset [PR93582] > > where POINTER_PLUS_EXPR last operand has sizetype type, thus unsigned, > > and in the testcase gimple_assign_rhs2 (def) is thus 0xf001ULL > > which multiplied by 8 doesn't fit into signed HWI. If it would be treated > > as signed offset instead, it would fit (-0xfffLL, multiplied > > by 8 is -0x7ff8LL). Unfortunately with the poly_int obfuscation > > I'm not sure how to convert it from unsigned to signed poly_int. > > mem_ref_offset provides a boiler-plate for this: > > poly_offset_int::from (wi::to_poly_wide (TREE_OPERAND (t, 1)), SIGNED); Thanks, that seems to work. The test now works on both big-endian and little-endian. 2020-03-05 Richard Biener Jakub Jelinek PR tree-optimization/93582 * tree-ssa-sccvn.c (vn_reference_lookup_3): Treat POINTER_PLUS_EXPR last operand as signed when looking for memset offset. Formatting fix. * gcc.dg/tree-ssa/pr93582-11.c: New test. Co-authored-by: Richard Biener
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #43 from Thomas Henlich --- (In reply to Steve Kargl from comment #42) > gfortran currently does not implement IEEE_FMA along > with a few additional IEEE_ARITHMETIC features added > in F2018. > > Note, gcc/builtins.def has fma, fmaf, and fmal covered. > We'll need a mapping in libquadmath if it has a __float128 > fma. It has: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46402
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e19f06538c51fed54240a4e98277e62daa00d9b3 commit r9-8339-ge19f06538c51fed54240a4e98277e62daa00d9b3 Author: Jason Merrill Date: Wed Mar 4 23:07:13 2020 -0500 c++: Fix constexpr ICE from const mismatch [PR91607] gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/91607 * constexpr.c (constexpr_call_hasher::equal): Use same_type_ignoring_top_level_qualifiers_p.
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 --- Comment #20 from Kito Cheng --- Created attachment 47972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47972=edit PR90811-ipa-increase-alignment.patch Hi Jeff: Updated patch attached, tested on riscv32/riscv64, this version take the suggestion from Andrew, implement that in ipa_increase_alignment pass, I saw the dump file number is 67, but ompdevlow is 92, I am not sure it's late enough or not, since I failed to reproduce the original issue on x86_64 + nvptx + cuda 10.0, I just get some error message seems like unrelated to this alignment issue even with r272181. as /tmp/ccuQhrDr.s, line 26; error : Arguments mismatch for instruction 'mov' as /tmp/ccuQhrDr.s, line 91; error : Arguments mismatch for instruction 'mov' as /tmp/ccuQhrDr.s, line 98; error : Label expected for argument 0 of instruction 'call' as /tmp/ccuQhrDr.s, line 98; fatal : Call target not recognized * Note, as has replaced to ptxas manually, it was https://github.com/MentorEmbedded/nvptx-tools Did you mind tell me how to build the environment to reproduce? My current configure option and version: GCC version g:6b3302da9ef26aa11940f8c0dc92bec19e15c09b CUDA: 10.0 (8.0 install failed on Ubuntu 18.04) x86_64: --disable-bootstrap --disable-multilib --enable-languages=c,c++,lto,fortran --enable-offload-targets=nvptx-none --enable-multiarch --with-cuda-driver=/usr/local/cuda nvptx-none nvptx: --disable-bootstrap --disable-sjlj-exceptions --enable-newlib-io-long-long --target=nvptx-none --enable-as-accelerator-for=x86_64-linux-gnu --enable-languages=c,c++,fortran,lto --program-prefix=nvptx-none- Thanks
[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91607 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++/94041] New: temporary object destructor called before the end of the full-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94041
Bug ID: 94041
Summary: temporary object destructor called before the end of
the full-expression
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mawww at kakoune dot org
Target Milestone: ---
Hello on current trunk, with no special options given, compiling the following
code:
struct Temp{ ~Temp(); };
struct A{ A(const Temp&) noexcept; };
struct B{ ~B(); };
struct Pair{ A a; B b; };
Temp make_temp() noexcept;
void foo(const Pair&) noexcept;
void bar(const Pair& p) noexcept
{
foo({A(make_temp()), p.b});
}
generates the following assembly for the bar function:
bar(Pair const&):
pushrbp
mov rbp, rsp
sub rsp, 32
mov QWORD PTR [rbp-24], rdi
lea rax, [rbp-1]
mov rdi, rax
callmake_temp()
lea rdx, [rbp-1]
lea rax, [rbp-3]
mov rsi, rdx
mov rdi, rax
callA::A(Temp const&)
lea rax, [rbp-1]
mov rdi, rax
callTemp::~Temp() [complete object destructor]
lea rax, [rbp-3]
mov rdi, rax
callfoo(Pair const&)
lea rax, [rbp-3]
mov rdi, rax
callPair::~Pair() [complete object destructor]
nop
leave
ret
Note the call to Temp::~Temp *before* the call to foo, which can lead to the A
object referring to a dangling Temp object when accessed in foo.
I believe that destructor call should only take place *after* calling foo, when
the full-expression actually ends.
This does not happen on gcc 9 and previous version, only on current trunk and
gcc-10 as provided in fedora rawhide.
[Bug c/94040] New: [10 Regression] ICE in get_constant, at c-family/c-format.c:325 (error: 'format' attribute argument 2 value '3' refers to parameter type 'int *')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94040
Bug ID: 94040
Summary: [10 Regression] ICE in get_constant, at
c-family/c-format.c:325 (error: 'format' attribute
argument 2 value '3' refers to parameter type 'int *')
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.1-alpha20200301 snapshot (g:151bf47e78f5d919f6cc591d11cc1f6aff61078f)
ICEs when compiling the following testcase w/ -m32 -Wformat:
int
strftime (char *, int, int *, void *);
int
li (void)
{
return strftime (0, 0, 0, 0);
}
% gcc-10.0.1 -m32 -Wformat -w -c yjslsqig.c
yjslsqig.c: In function 'li':
yjslsqig.c:7:3: error: 'format' attribute argument 2 value '3' refers to
parameter type 'int *'
7 | return strftime (0, 0, 0, 0);
| ^~
yjslsqig.c:7:3: internal compiler error: in get_constant, at
c-family/c-format.c:325
0x5de063 get_constant
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c-family/c-format.c:325
0x5de063 get_constant
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c-family/c-format.c:313
0x8652f0 decode_format_attr
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c-family/c-format.c:377
0x8680d8 check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c-family/c-format.c:1183
0x856b48 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c-family/c-common.c:5726
0x7e3dc7 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-typeck.c:3116
0x803f36 c_parser_postfix_expression_after_primary
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:10494
0x7fb409 c_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:10169
0x7ff89a c_parser_unary_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:8266
0x8011a7 c_parser_cast_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:8108
0x801477 c_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:7911
0x8025c8 c_parser_conditional_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:7645
0x802cb2 c_parser_expr_no_commas
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:7562
0x802f55 c_parser_expression
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:10630
0x8037cb c_parser_expression_conv
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:10663
0x7f96a4 c_parser_statement_after_labels
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:6205
0x7fabd0 c_parser_compound_statement_nostart
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:5800
0x818ac8 c_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:5616
0x81a71e c_parser_declaration_or_fndef
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:2504
0x822e73 c_parser_external_declaration
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/c/c-parser.c:1746
[Bug tree-optimization/82689] merging writes of different types to the same location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82689 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-10-24 00:00:00 |2020-3-4 CC||msebor at gcc dot gnu.org Known to fail||10.0, 7.3.0, 8.2.0, 9.1.0 --- Comment #2 from Martin Sebor --- Reconfirmed for GCC 10.
[Bug c++/90938] [9 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|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Sebor --- Fixed in GCC 10 and 9.
[Bug c++/90938] [9 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
--- Comment #14 from CVS Commits ---
The releases/gcc-9 branch has been updated by Martin Sebor
:
https://gcc.gnu.org/g:1665d97d37559ea7403d5b3e0efd5c5ae416e1ae
commit r9-8338-g1665d97d37559ea7403d5b3e0efd5c5ae416e1ae
Author: Martin Sebor
Date: Wed Mar 4 18:32:40 2020 -0700
PR c++/90938 - Initializing array with {1} works, but not {0}
gcc/cp/ChangeLog:
PR c++/90938
* tree.c (type_initializer_zero_p): Fail for structs initialized
with non-structs.
gcc/testsuite/ChangeLog:
PR c++/90938
* g++.dg/init/array55.C: New test.
* g++.dg/init/array56.C: New test.
* g++.dg/cpp2a/nontype-class33.C: New test.
[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 #13 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:cb2409c60aeff498064346f85165531a3bbead14
commit r10-7034-gcb2409c60aeff498064346f85165531a3bbead14
Author: Martin Sebor
Date: Wed Mar 4 18:19:31 2020 -0700
PR c++/90938 - Initializing array with {1} works but not {0}
gcc/cp/ChangeLog:
PR c++/90938
* tree.c (type_initializer_zero_p): Fail for structs initialized
with non-structs.
gcc/testsuite/ChangeLog:
PR c++/90938
* g++.dg/init/array55.C: New test.
* g++.dg/init/array56.C: New test.
* g++.dg/cpp2a/nontype-class33.C: New test.
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 --- Comment #12 from Marek Polacek --- It depends on r10-3735-gcb57504a550158913258e5be8ddb991376475efb :/ So, we'd have to play some games with unwrapping the NON_LVALUE_EXPR.
[Bug c++/93299] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug c++/93299] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2b5d109ba3af320f65cb0707e8733eeea3c96262 commit r9-8336-g2b5d109ba3af320f65cb0707e8733eeea3c96262 Author: Marek Polacek Date: Wed Mar 4 19:04:31 2020 -0500 c++: Fix ICE in tsubst_copy with parenthesized expression [PR93299] PR c++/93299 - ICE in tsubst_copy with parenthesized expression. * pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR. * g++.dg/cpp1y/paren5.C: New test.
[Bug sanitizer/93436] [9 Regression] ICE during GIMPLE pass: sanopt with -fsanitize=address -fdump-tree-sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug sanitizer/93436] [9 Regression] ICE during GIMPLE pass: sanopt with -fsanitize=address -fdump-tree-sanopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93436 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d8b65123ea2e7f169c3e3972d3942d73f9bc commit r9-8335-gd8b65123ea2e7f169c3e3972d3942d73f9bc Author: Marek Polacek Date: Wed Mar 4 19:02:22 2020 -0500 sanopt: Avoid crash on anonymous parameter [PR93436] PR sanitizer/93436 * sanopt.c (sanitize_rewrite_addressable_params): Avoid crash on null DECL_NAME.
[Bug c++/93676] [8/9 Regression] crash in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93676 --- Comment #10 from CVS Commits --- The releases/gcc-9 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b38d6242be6aeaf83cdf1f990ff3297a697e4488 commit r9-8334-gb38d6242be6aeaf83cdf1f990ff3297a697e4488 Author: Marek Polacek Date: Wed Mar 4 18:57:08 2020 -0500 c++: Fix value-init crash in template [PR93676] PR c++/93676 - value-init crash in template. * init.c (build_new_1): Don't call build_vec_init in a template. * g++.dg/cpp0x/nsdmi-template19.C: New test.
[Bug c++/90505] [9 Regression] g++ rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90505 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Marek Polacek --- Fixed.
[Bug c++/90505] [9 Regression] g++ rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90505 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:581825efc30ce79d86dfb0ebf378913fdec44adf commit r9-8333-g581825efc30ce79d86dfb0ebf378913fdec44adf Author: Marek Polacek Date: Wed Mar 4 18:49:37 2020 -0500 c++: Fix mismatch in template argument deduction [PR90505] 2020-03-03 Jason Merrill Marek Polacek PR c++/90505 - mismatch in template argument deduction. * pt.c (tsubst): Don't reduce the template level of template parameters when tf_partial. * g++.dg/template/deduce4.C: New test. * g++.dg/template/deduce5.C: New test. * g++.dg/template/deduce6.C: New test. * g++.dg/template/deduce7.C: New test.
[Bug gcov-profile/94029] [9/10 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at redhat dot com
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 --- Comment #7 from Marek Polacek --- *** Bug 93898 has been marked as a duplicate of this bug. ***
[Bug c++/93898] [9/10 Regression] internal compiler error: in output_constructor_regular_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93898 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Which has been fixed. *** This bug has been marked as a duplicate of bug 90432 ***
[Bug tree-optimization/94015] [10 Regression] Another assignment incorrectly omitted by -foptimize-strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015
--- Comment #6 from Martin Sebor ---
(In reply to Nate Eldredge from comment #4)
A compile-time only test that doesn't depend on the target or endianness would
be much better than a runtime test that fails only on a subset of targets. The
way to do that is to verify that the pass doesn't misinterpret the size of the
pointer stored in the array as the length of the string by checking to make
sure that the result of a strlen call with the buffer as an argument isn't
folded into a constant:
/* PR tree-optimization/94015 - assignment incorrectly omitted by
-foptimize-strlen
{ dg-do compile }
{ dg-options "-O2 -Wall -fdump-tree-optimized" } */
int f (int n)
{
char *s = __builtin_malloc (n);
*(char **)s = "0123456";
return __builtin_strlen (s);
}
/* { dg-final { scan-tree-dump-times "strlen" 1 "optimized" } } */
The buggy count_nonzero_bytes function is tricky because it tries to recover
string length information obscured by earlier optimizations like store merging
that turn multiple character stores into one. The merged stores can have
different forms, be of a variety of different types, and result in ranges of
lengths (i.e., minimum and maximum). For instance this:
char a[8];
void f (void)
{
char s[] = "1234567";
__builtin_memcpy (a, s, sizeof s);
}
is transformed into this:
f (char * p)
{
[local count: 1073741824]:
MEM [(char * {ref-all})] = 15540725856023089;
return;
}
count_nonzero_bytes then goes and figures out the length of the string the
number corresponds to. To detect buffer overflows, it also computes the size
of the store, and when the store is one of a pointer type, it gets the size and
length computations mixed up.
[Bug bootstrap/93962] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 Jeffrey A. Law changed: What|Removed |Added Summary|[10 regression] bootstrap |bootstrap fails with |fails with |gcc/value-prof.c:268:28 : |gcc/value-prof.c:268:28 : |error: format '%lld' |error: format '%lld'|expects argument of type |expects argument of type|'long long int', but |'long long int', but|argument 3 hastype 'int' |argument 3 hastype 'int'| --- Comment #9 from Jeffrey A. Law --- Fixed on the trunk, but kept open so that Gerald can attach the .ii file for further analysis if Jakub is interested.
[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 --- Comment #8 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:20a235a8b443a81ea0ec6a10f260b119f2193a69 commit r10-7032-g20a235a8b443a81ea0ec6a10f260b119f2193a69 Author: Jeff Law Date: Wed Mar 4 16:25:11 2020 -0700 Fix format warning which showed up on FreeBSD 11.3. PR bootstrap/93962 * value-prof.c (dump_histogram_value): Use std::abs.
[Bug middle-end/94035] Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035 --- Comment #2 from joseph at codesourcery dot com --- I think pseudo-denormals should be considered trap representations.
[Bug c++/90691] [9 regression] -Wsign-compare false-positive with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90691 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.3 |10.0 --- Comment #10 from Jason Merrill --- The fix isn't suitable for backporting.
[Bug c++/90997] [9 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90997 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- And 9.3.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 --- Comment #11 from Jason Merrill --- (In reply to Marek Polacek from comment #10) > Don't know if I should pursue this backport. Seems like it depends on other fixes, not sure how hard they will be to find. Your call.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9af9e004831f8efdfb68c2affea07b17fadd3279 commit r9-8332-g9af9e004831f8efdfb68c2affea07b17fadd3279 Author: Jason Merrill Date: Wed Mar 4 17:30:58 2020 -0500 c++: Fix [[no_unique_address]] and default mem-init [PR90432] output_constructor doesn't like two consecutive entries with fields at the same position; let's avoid adding the one for the empty field. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90432 * init.c (perform_member_init): Don't do aggregate initialization of empty field. * constexpr.c (cx_check_missing_mem_inits): Don't enforce initialization of empty field.
[Bug c++/90997] [9 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90997 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:831d4a690053599d2d0aa9713642b8513fdf8f5b commit r9-8331-g831d4a690053599d2d0aa9713642b8513fdf8f5b Author: Jason Merrill Date: Wed Mar 4 17:30:58 2020 -0500 c++: avoid ICE with __builtin_memset (PR90997). warn_for_memset calls fold_for_warn, which calls fold_non_dependent_expr, so also calling instantiate_non_dependent_expr here is undesirable. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90997 * semantics.c (finish_call_expr): Don't call instantiate_non_dependent_expr before warn_for_memset.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6876b269bc7fe6465fedfed87c31e6175992129f commit r10-7031-g6876b269bc7fe6465fedfed87c31e6175992129f Author: Jason Merrill Date: Wed Mar 4 12:08:42 2020 -0500 c++: Fix [[no_unique_address]] and default mem-init [PR90432] output_constructor doesn't like two consecutive entries with fields at the same position; let's avoid adding the one for the empty field. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90432 * init.c (perform_member_init): Don't do aggregate initialization of empty field. * constexpr.c (cx_check_missing_mem_inits): Don't enforce initialization of empty field.
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:10591cfe6cac200e926a73f3b8065147ce84 commit r10-7030-g10591cfe6cac200e926a73f3b8065147ce84 Author: Martin Sebor Date: Wed Mar 4 15:14:49 2020 -0700 PR tree-optimization/93986 - ICE on mixed-precision wide_int arguments gcc/testsuite/ChangeLog: PR tree-optimization/93986 * gcc.dg/pr93986.c: New test. gcc/ChangeLog: PR tree-optimization/93986 * tree-ssa-strlen.c (maybe_warn_overflow): Convert all wide_int operands to the same precision widest_int to avoid ICEs.
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed.
[Bug target/49854] Clean up SPE/e500 option handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/84302] ICE: Segmentation fault (in extract_insn) on SPE target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84302 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/85170] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85170 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/87083] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87083 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Fixed (see comment 2); regression test added (see comment 3); marking as resolved. Thanks for filing this.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #41 from joseph at codesourcery dot com --- On Wed, 4 Mar 2020, rguenther at suse dot de wrote: > We're actually careful about the sign of zero here when recording > requivalences for propagation. I don't see anything preventing > equivalence based propagation for decimal floats though. > Also not sure if actual FP formats are required to be always > normalized ... All finite DFP values that can be represented with fewer decimal digits than the maximum for the format, and where the least significant nonzero decimal digit has an exponent greater than the smallest possible for the format, have representations with more than one possible quantum exponent, which are not equivalent even though they compare equal, and thus comparing equal should not result in an equivalence being recorded. E.g. _Decimal32 has 7-digit precision. 1.0DF and 1.00DF are different members of the same cohort, with quantum exponents -1 and -2, and compare equal but are not equivalent. 1.01DF uses all 7 digits so is the unique member of its cohort, so it is valid to use 1.01DF in place of anything that compared equal to 1.01DF. 1E-101DF is the least positive subnormal value; as -101 is the lowest quantum exponent, anything with a nonzero digit in the 10^-101 place is the unique member of its cohort and so 1E-101DF can be used in place of anything that compared equal to 1E-101DF. This is a separate matter from noncanonical encodings of DFP values. A noncanonical encoding is a valid representation that *is* fully equivalent to some canonical encoding - but most operations are supposed to produce only canonically encoded results. If a cohort has only one member but there are noncanonical encodings of that member, a canonical encoding can replace a noncanonical one (in general it's not required to propagate noncanonical encodings, even when permitted), but not vice versa.
[Bug target/71012] ICE: in expand_expr_real_2, at expr.c:9348 when compiling stress-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/81628] Backport r250637 and r250638 to the powerpcspe* target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/85121] Assembler messages: Error: operand out of range (264 is not between 0 and 248)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85121 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/86133] powerpc (-mcpu=8548) internal compiler error for double variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 Author: David Malcolm Date: Wed Mar 4 12:10:34 2020 -0500 analyzer: add regression test for fixed ICE [PR94028] The C++ reproducer for PR analyzer/94028 generates a similar ICE to that of the Fortran reproducer for PR analyzer/93993 and, like it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. This patch adds the C++ reproducer as a regression test. gcc/testsuite/ChangeLog: PR analyzer/94028 * g++.dg/analyzer/pr94028.C: New test.
[Bug c++/94039] New: conditional operator fails to use proper overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Bug ID: 94039
Summary: conditional operator fails to use proper overload
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: monstrefou at gmail dot com
Target Milestone: ---
I believe the following program should compile but I get the error
"operands to ?: have different types 'INT_WRAPPER' and 'std::nullptr_t'"
class INT_WRAPPER
{
public:
operator int*() { return m_int = nullptr; }
private:
int* m_int;
};
int main()
{
true ? INT_WRAPPER() : nullptr;
}
>From my understanding neither type can't be implicitly converted to the other
type "target" as described in 7.6.16 paragraph 4
So it should do use overload resolution as per 7.6.16 paragraph 4
and operator?:(int*, int*) should be an available overload as per 12.7
paragraph 28
So in conclusion I think it this code should compile and the result type of the
conditional operator should be in* in this case
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 Author: David Malcolm Date: Wed Mar 4 12:10:34 2020 -0500 analyzer: add regression test for fixed ICE [PR94028] The C++ reproducer for PR analyzer/94028 generates a similar ICE to that of the Fortran reproducer for PR analyzer/93993 and, like it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. This patch adds the C++ reproducer as a regression test. gcc/testsuite/ChangeLog: PR analyzer/94028 * g++.dg/analyzer/pr94028.C: New test.
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 --- Comment #2 from Patrick Palka --- (In reply to Marek Polacek from comment #1) > > This seems to be a regression from GCC 9. > > Are you sure? I see the same thing with GCC 6. Oops, you're right, it's not a regression.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Summary|Broken diagnostic: |[10 Regression] Broken |'result_decl' not supported |diagnostic: 'result_decl' |by dump_expr|not supported by dump_expr Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r10-5821-g10d2f801f472931137deae1714d5b690c1862037
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86801, which changed state. Bug 86801 Summary: Powerpcspe port (may) need updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug target/86801] Powerpcspe port (may) need updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Segher Boessenkool --- GCC 9 does not support powerpcspe.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
--- Comment #13 from Rene Rahn ---
(In reply to Eric Gallager from comment #12)
> (In reply to Rene Rahn from comment #10)
> > I know this is quite old now. But can someone explain me why using `#pragma
> > pack(push, 1)` does work then? I couldn't find enough resources on that. The
> > only thing I found is, that it does literally the same. But wouldn't then
> > the references/pointers still not be valid?
> >
> > So if I change the code to:
> >
> > ```
> > #pragma pack(push, 1)
> > struct Squeeze
> > {
> > short s;
> > };
> > #pragma pack(pop)
> > ```
> >
> > Then it works on godbolt with gcc-trunk.
>
> There are several bugs open about inconsistencies between
> __attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
> 92900, bug 68160, and bug 60972
Ah great. Thanks for pointing to this.
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678
--- Comment #10 from Marek Polacek ---
With this patch GCC 9 ICEs on:
$ ./cc1plus -quiet pr87768.C -std=gnu++2a -fconcepts
pr87768.C: In instantiation of ‘constexpr const bool c::f’:
pr87768.C:14:29: required from here
pr87768.C:9:29: internal compiler error: in tsubst_copy, at cp/pt.c:15833
9 | requires requires(d e) { e[0]; }
|~^
0xaaad12 tsubst_copy
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15833
0xac0b50 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19709
0xaba51d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:18434
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0x8c892b satisfy_expression_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2070
0x8c92ff satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2242
0x8c90c9 satisfy_parameterized_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2185
0x8c9388 satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2257
0x8c944d satisfy_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2294
0x8c9511 satisfy_associated_constraints
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2318
0x8c97ed constraints_satisfied_p(tree_node*)
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2393
0x8454e3 add_function_candidate
/home/mpolacek/src/gcc9/gcc/cp/call.c:
0x851d96 add_candidates
/home/mpolacek/src/gcc9/gcc/cp/call.c:5754
0x84d828 build_op_call_1
/home/mpolacek/src/gcc9/gcc/cp/call.c:4712
0x84e172 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc9/gcc/cp/call.c:4808
0xb0e895 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc9/gcc/cp/semantics.c:2602
0xabdd43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19195
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0xaa9801 tsubst_init
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15527
0xad2f31 regenerate_decl_from_template
/home/mpolacek/src/gcc9/gcc/cp/pt.c:24262
because tsubst_copy/NON_LVALUE_EXPR gets
NON_LVALUE_EXPR (e)>
Don't know if I should pursue this backport.
[Bug middle-end/92478] [8 Regression] ICE on strcpy referencing an element of a static local constant array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92478 Martin Sebor changed: What|Removed |Added Summary|[8 Regression] ICE: |[8 Regression] ICE on |Segmentation fault |strcpy referencing an ||element of a static local ||constant array --- Comment #5 from Martin Sebor --- (In reply to John X from comment #3) > Would the ICE in gcc-8 be fixed? The fix looks simple enough to me to backport to GCC 8.5.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00251.html
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- > This seems to be a regression from GCC 9. Are you sure? I see the same thing with GCC 6.
[Bug libstdc++/93978] A snippet using views::join fails to compile with -O1, but succeeds with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93978 Patrick Palka changed: What|Removed |Added Depends on||94038 --- Comment #1 from Patrick Palka --- I think the underlying cause of this issue is PR c++/94038 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 [Bug 94038] Compiling with -Wall causes function template body to get needlessly instantiated
[Bug c++/94038] New: Compiling with -Wall causes function template to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
Bug ID: 94038
Summary: Compiling with -Wall causes function template to get
needlessly instantiated
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
With GCC trunk:
$ cat sa.cc
template
constexpr int
foo()
{
static_assert(T(1) == 0);
return 0;
}
constexpr int
bar(int a)
{
return a;
}
static_assert(decltype(bar(foo())){} == 0);
$ g++ -fsyntax-only -O sa.cc
$ g++ -fsyntax-only -O -Wall sa.cc
sa.cc: In instantiation of ‘constexpr int foo() [with T = int]’:
sa.cc:15:36: required from here
sa.cc:5:22: error: static assertion failed
5 | static_assert(T(1) == 0);
| ~^~~~
This seems to be a regression from GCC 9.
[Bug rtl-optimization/94037] New: Runtime varies 2x just by order of two int assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94037
Bug ID: 94037
Summary: Runtime varies 2x just by order of two int assignments
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
(This report re-uses some code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165 but identifies an entirely
different problem.)
Given:
```
bool swap_if(bool c, int& a, int& b) {
int v[2] = { a, b };
#ifdef FAST /* 4.6s */
b = v[1-c], a = v[c];
#else /* SLOW, 9.8s */
a = v[c], b = v[!c];
#endif
return c;
}
int* partition(int* begin, int* end) {
int pivot = end[-1];
int* left = begin;
for (int* right = begin; right < end - 1; ++right) {
left += swap_if(*right <= pivot, *left, *right);
}
int tmp = *left; *left = end[-1], end[-1] = tmp;
return left;
}
void quicksort(int* begin, int* end) {
while (end - begin > 1) {
int* mid = partition(begin, end);
quicksort(begin, mid);
begin = mid + 1;
} }
static const int size = 100'000'000;
#include
#include
#include
int main(int, char**) {
int fd = ::open("1e8ints", O_RDONLY);
int perms = PROT_READ|PROT_WRITE;
int flags = MAP_PRIVATE|MAP_POPULATE|MAP_NORESERVE;
auto* a = (int*) ::mmap(nullptr, size * sizeof(int), perms, flags, fd, 0);
quicksort(a, a + size);
return a[0] == a[size - 1];
}
```
after
```
$ dd if=/dev/urandom of=1e8ints bs=100 count=400
```
The run time of the the program above, built "-O3 -march=skylake"
vs. "-DFAST -O3 -march=skylake", varies by 2x on Skylake, similarly
on Haswell. Both cases are almost equally fast on Clang, matching
G++'s fast version. The difference between "!c" and "1-c" in the
array index exacerbates the disparity.
Godbolt `` says, slow:
```
movl(%rax), %edx
movl(%rbx), %esi
movl%esi, 8(%rsp)
movl%edx, 12(%rsp)
cmpl%edx, %ecx
setge %sil
movzbl %sil, %esi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rbx)
setl%sil
movzbl %sil, %esi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rax)
```
and 2x as fast:
```
movl(%rax), %ecx
cmpl%ecx, %r8d
setge %dl
movzbl %dl, %edx
movl(%rbx), %esi
movl%esi, 8(%rsp)
movl%ecx, 12(%rsp)
movl%r9d, %esi
subl%edx, %esi
movslq %esi, %rsi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rax)
movslq %edx, %rdx
movl8(%rsp,%rdx,4), %edx
movl%edx, (%rbx)
cmpl%ecx, %r8d
```
Clang 9.0.0, -DFAST, for reference:
```
movl(%rcx), %r11d
xorl%edx, %edx
xorl%esi, %esi
cmpl%r8d, %r11d
setle %dl
setg%sil
movl(%rbx), %eax
movl%eax, (%rsp)
movl%r11d, 4(%rsp)
movl(%rsp,%rsi,4), %eax
movl%eax, (%rcx)
movl(%rsp,%rdx,4), %eax
movl%eax, (%rbx)
```
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |8.5 Summary|ICE equivalence of an |[8/9/10 Regression] ICE |integer and an element of |equivalence of an integer |an array of size n |and an element of an array ||of size n --- Comment #2 from Thomas Koenig --- This should be rejected.
[Bug target/80700] [8 Regression] ICE: Bus error (on SPE target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700 Segher Boessenkool changed: What|Removed |Added Known to work||9.0 Summary|[8/9/10 Regression] ICE:|[8 Regression] ICE: Bus |Bus error (on SPE target) |error (on SPE target) --- Comment #11 from Segher Boessenkool --- The target has been removed in GCC 9.
[Bug target/81288] [8/9/10 Regression] ICE on 32-bit BE powerpcspe w/ -misel -O2 (-O3, -Ofast, -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288 --- Comment #10 from Segher Boessenkool --- Works in GCC 9, as in, the target does not exist any more in GCC 9.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #40 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #35)
> > You seem to say that either Annex F is fully there or not at all but why?
> > -fno-signed-zeros breaks Annex F but only parts of it. Isn't it possible to
> > retain the other parts of it? Maybe it's impossible or maybe it's impossible
> > to retain division by zero, I don't know. What is your logic here?
>
> This issue is that the nice property x == y implies f(x) == f(y), in
> particular, x == y implies 1 / x == 1 / y is no longer valid with signed
> zeros. Thus one intent of -fno-signed-zeros could be to enable optimizations
> based on this property. But this means that division by zero becomes
> undefined behavior (like in C without Annex F). Major parts of Annex F would
> still remain valid.
I agree that the intent is to enable optimization based on the property "x == y
implies f(x) == f(y)". But I'm not sure what follows from this.
Sure, one possibility is make undefined any program that uses f(x) where x
could be a zero and f(x) differs for two zeros. But this approach make printf
and memory-accesss undefined too. Sorry, I don't how you could undefine
division by zero while not undefining printing of zero.
Another approach is to say that we don't care which of possible two values f(x)
returns x is zero. That is, we don't care whether 1/0. is +inf or -inf and we
don't care whether printf("%g", 0.) outputs 0 or -0.
> > This means that you cannot implement you own printf: if you analyze sign bit
> > of your value to decide whether you need to print '-', the sign of zero is
> > significant in your code.
>
> If you want to implement a printf that takes care of the sign of 0, you must
> not use -fno-signed-zeros.
So if I use ordinary printf from a libc with -fno-signed-zeros it's fine but if
I copy its implementation into my own program it's not fine?
> > IOW why do you think that printf is fine while "1 / x == 1 / 0." is not?
>
> printf is not supposed to trigger undefined behavior. Part of its output is
> unspecified, but that's all.
Why the same couldn't be said about division? Division by zero is not supposed
to trigger undefined behavior. Part of its result (the sign of infinit) is
unspecified, but that's all.
> > > * Memory analysis. Again, the sign does not matter, but for instance,
> > > reading an object twice as a byte sequence while the object has not been
> > > changed by the code must give the same result. I doubt that this is
> > > affected
> > > by optimization.
> >
> > Working with objects on byte level is often optimized too:
>
> Indeed, there could be invalid optimization... But I would have thought that
> in such a case, the same kind of issue could also occur without
> -fno-signed-zeros. Indeed, if x == y, then this does not mean that x and y
> have the same memory representation. Where does -fno-signed-zeros introduce
> a difference?
Right. But it's well known that x == y doesn't imply that x and y have the same
value. And the only such case is zeros of different signs (right?). So
compilers deal with this case in a special way. (E.g., the optimization `if (x
== C) use(x)` -> `if (x == C) use(C)` is normally done only for non-zero FP
constant `C`. -fno-signed-zeros changes this.)
The idea that one value could have different representations is not widely
distributed. I didn't manage to construct a testcase for this yesterday but I
succeeded today -- see pr94035 (affects clang too).
The next level -- the same value, the same representation, different meaning.
E.g., pointers of different provenance. But that's another story:-)
> Note: There's also the case of IEEE 754 decimal floating-point formats (such
> as _Decimal64), for instance, due to the "cohorts", where two identical
> values can have different memory representations. Is GCC always correct here?
I have used pseudo-denormals in long double (x86_fp80) for this so far. Are
decimal floating-point formats more interesting?
[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993 --- Comment #4 from Jakub Jelinek --- Created attachment 47971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47971=edit gcc10-pr91993-wip.patch As implemented in this completely untested (so far) patch, which makes the -Wconversion warning go away both in the case of comma operator with user side-effects as well as -fsanitize=undefined.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #15 from jwjagersma at gmail dot com --- Created attachment 47970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47970=edit alternative patch v3 Alternative to last patch. Inserts the debug stmt across the fallthrough edge. Let me know which patch would be preferable, and I'll submit it.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=93910,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=92900,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=68160,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=60972
--- Comment #12 from Eric Gallager ---
(In reply to Rene Rahn from comment #10)
> I know this is quite old now. But can someone explain me why using `#pragma
> pack(push, 1)` does work then? I couldn't find enough resources on that. The
> only thing I found is, that it does literally the same. But wouldn't then
> the references/pointers still not be valid?
>
> So if I change the code to:
>
> ```
> #pragma pack(push, 1)
> struct Squeeze
> {
> short s;
> };
> #pragma pack(pop)
> ```
>
> Then it works on godbolt with gcc-trunk.
There are several bugs open about inconsistencies between
__attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
92900, bug 68160, and bug 60972
[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
The sanitization boils down to adding COMPOUND_EXPRs with the checking in the
first operand and whatever it would normally have in the second operand.
using uc = unsigned char;
auto
foo (const uc , const uc , const uc )
{
return static_cast(static_cast(a << 1U) | b) | c;
}
auto
bar (const uc , const uc , const uc , int )
{
return static_cast(static_cast((d++, a) << 1U) | b) | c;
}
warns in bar the same even with just -Wconversion and doesn't warn in foo.
Now, I wonder if a way out of this wouldn't be in cp_build_binary_op to look
through COMPOUND_EXPRs (say set some temporary to (not sure if op0 or
orig_op0),
and then while (TREE_CODE (op0) == COMPOUND_EXPR) op0 = TREE_OPERAND (op0, 1);
and similarly for op1 (or orig_op1?) and then at the end readd the lhs's from
the COMPOUND_EXPRs to the result (guess for doing_shift case and
flag_strong_eval_order == 2 we'd need to either not do that or be extra
careful, because in that case op0 is ordered before op1).
Thoughts on this?
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #2 from David Malcolm --- Yes, the ICE was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. It's a similar issue to the reproducer for PR analyzer/93993. I'll add your reproducer as a further regression test; thanks.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-04 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/92601] [9 Regression] error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed for 9.3.
[Bug testsuite/94036] New: [9 regression] gcc.target/powerpc/pr72804.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94036 Bug ID: 94036 Summary: [9 regression] gcc.target/powerpc/pr72804.c fails Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This was fixed in trunk, see pr92398, and the same fix should work for gcc 9. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 power 7: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not lxvd2x FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x power 8: works fine power 9: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std 2
[Bug middle-end/94035] Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035 --- Comment #1 from Alexander Cherepanov --- clang bug -- https://bugs.llvm.org/show_bug.cgi?id=45101
[Bug middle-end/94035] New: Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
Bug ID: 94035
Summary: Wrong optimization: conditional equivalence vs. values
with several representations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The problem happens when:
- conditional equivalence propagation replaces an expression with a variable or
a constant that has the same value but a different representation, and
- this happens in a computation where representation is accessed.
Example with a pseudo-denormal in long double:
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
int main()
{
long double x, y;
unsigned char *px = (unsigned char *)
unsigned char *py = (unsigned char *)
// make x pseudo-denormal
x = 0;
px[7] = 0x80;
opaque(); // hide it from the optimizer
y = x;
if (y == 0x1p-16382l)
printf("py[8] = %d\n", py[8]);
printf("py[8] = %d\n", py[8]);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
py[8] = 1
py[8] = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200304 (experimental)
--
The value 0x1p-16382l admits two representations:
00 00 80 00 00 00 00 00 00 00 pseudo-denormal
00 01 80 00 00 00 00 00 00 00 normalized value
So both 0 and 1 for py[8] are fine but the testcase should print the same value
both times, i.e. the representation of y should be stable.
DR 260 Q1 allows for unstable representation but IMO this is wrong.
[Bug tree-optimization/80776] -Wformat-overflow false positive for %d on integer bounded by __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80776
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-05-16 00:00:00 |2020-3-4
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94021
Known to fail|6.3.0, 7.1.0|10.0, 6.4.0, 7.5.0, 8.4.0,
||9.2.0
--- Comment #7 from Martin Sebor ---
Reconfirming that test case in comment #2 still triggers the warning in GCC 10.
The dump shows that the warning thinks the fifth directive (%02d) generates
between 2 and 10 bytes of output. The symptoms feel similar to pr94021 but I
haven't looked into whether they underlying root causes are related.
Result: 2, 10, 10, 10 (12, 20, 20, 20)
$ gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout pr80776-c2.c
;; Function f (f, funcdef_no=0, decl_uid=1936, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
pr80776-c2.c:14: __builtin_sprintf: objsize = 15, fmtstr =
"%04d%02d%02d%02d%02d%02d"
Directive 1 at offset 0: "%04d"
Result: 4, 4, 4, 4 (4, 4, 4, 4)
Directive 2 at offset 4: "%02d"
Result: 2, 2, 2, 2 (6, 6, 6, 6)
Directive 3 at offset 8: "%02d"
Result: 2, 2, 2, 2 (8, 8, 8, 8)
Directive 4 at offset 12: "%02d"
Result: 2, 2, 2, 2 (10, 10, 10, 10)
Directive 5 at offset 16: "%02d"
pr80776-c2.c: In function ‘f’:
pr80776-c2.c:14:44: warning: ‘%02d’ directive writing between 2 and 10 bytes
into a region of size 5 [-Wformat-overflow=]
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
|^~~~
pr80776-c2.c:14:27: note: directive argument in the range [0, 2147483647]
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
| ^~
Result: 2, 10, 10, 10 (12, 20, 20, 20)
Directive 6 at offset 20: "%02d"
pr80776-c2.c:14:27: note: directive argument in the range [0, 60]
Result: 2, 2, 2, 2 (14, 22, 22, 22)
Directive 7 at offset 24: "", length = 1
pr80776-c2.c:14:3: note: ‘__builtin_sprintf’ output between 15 and 23 bytes
into a destination of size 15
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
| ^
f (int a, int b, int c, int d, int e, int f)
{
[local count: 1073741824]:
__builtin_sprintf (, "%04d%02d%02d%02d%02d%02d", a_14(D), b_15(D),
c_16(D), d_17(D), e_18(D), f_19(D));
return;
}
[Bug c++/91953] [8 Regression] G++ rejects lambda with constexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953 Jason Merrill changed: What|Removed |Added Summary|[8/9 Regression] G++|[8 Regression] G++ rejects |rejects lambda with |lambda with constexpr |constexpr variable |variable --- Comment #10 from Jason Merrill --- Fixed for 9.3 as well.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #1 from Zdenek Sojka --- I can no longer reproduce this with r10-7026 , seems to be fixed by r10-7023
[Bug c++/94034] New: Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Bug ID: 94034
Summary: Broken diagnostic: 'result_decl' not supported by
dump_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The following produces substitution text in an error message that is indicative
of missing format-for-message handling.
### SOURCE ():
struct A { A *ap = this; };
constexpr A foo() {
return {};
}
void g() {
constexpr A a = foo();
}
### COMPILER INVOCATION:
g++ -fsyntax-only -xc++ -
### COMPILER OUTPUT:
: In function 'void g()':
:6:23: error: 'A{(&'result_decl' not supported by dump_expr)}' is not a constant expression
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200302 (experimental) (GCC)
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:3ca63e1c76b7693b5d3f5ba2567421defc764249 commit r10-7027-g3ca63e1c76b7693b5d3f5ba2567421defc764249 Author: Martin Sebor Date: Wed Mar 4 10:23:49 2020 -0700 PR middle-end/81401 - false positive -Wformat-overflow in a loop gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/builtin-sprintf-warn-24.c: New test.
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Neither test case triggers the warning in GCC 10. Bisection points to r269115 as the fix.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 81401, which changed state. Bug 81401 Summary: False positive sprintf warning at O2 (-Wformat-overflow) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93800 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Sure, let me take a look.
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #2 from Avi Kivity --- It does not look similar to 93923. There, there is an incomplete type. In my reproducer the type is complete but the default constructor is private. Note that for simple cases is_trivially_constructible works (and evaluates to false), both in gcc 9 and gcc 10. It is only in a few cases that it starts to fail. The errors are also very different from 93983.
[Bug libstdc++/94003] is_constructible seems to have sideeffects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94003 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 Ever confirmed|0 |1
[Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 Ever confirmed|0 |1
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #1 from Jonathan Wakely --- Probably another instance of PR 93983 and PR PR 93923.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94021
Known to fail||10.0, 7.3.0, 8.2.0, 9.1.0
--- Comment #4 from Martin Sebor ---
GCC 10 issues the same warning. The partial dump below shows that the range
info the directive uses doesn't correspond to the range set in the code. This
is similar to pr94021.
$ gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout pr83733.c
;; Function g (g, funcdef_no=1, decl_uid=1939, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7
;; 2 succs { 7 3 }
;; 3 succs { 4 6 }
;; 4 succs { 7 5 }
;; 5 succs { 6 }
;; 6 succs { 7 }
;; 7 succs { 1 }
Computing maximum subobject size for _10:
Computing maximum object size for p_8(D):
_10: maximum subobject size 9
pr83733.c:8: __builtin_sprintf: objsize = 9, fmtstr = "CMPRT%02d"
Directive 1 at offset 0: "CMPRT", length = 5
Result: 5, 5, 5, 5 (5, 5, 5, 5)
Directive 2 at offset 5: "%02d"
pr83733.c: In function ‘g’:
pr83733.c:8:34: warning: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Wformat-overflow=]
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
| ^~~~
pr83733.c:8:28: note: directive argument in the range [-32768, 31]
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
|^~~
Result: 2, 6, 6, 6 (7, 11, 11, 11)
Directive 3 at offset 9: "", length = 1
pr83733.c:8:3: note: ‘__builtin_sprintf’ output between 8 and 12 bytes into a
destination of size 9
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
| ^~~~
[Bug libstdc++/94032] Please provide std::string::__resize_default_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94032 --- Comment #1 from Jonathan Wakely --- We'll add it when it's in the draft standard. Adding it before then would either mean only making it available for C++20 mode, or adding it to the shared library exports as a stable ABI artefact. Neither seems very good to me.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #42 from Steve Kargl --- On Wed, Mar 04, 2020 at 04:35:02PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #41 from Thomas Henlich --- > One would assume that fast FMA > (https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to > the modern Fortran enthusiast, in the year 202x. > It already is. F2018, 17.11.3 IEEE_FMA. gfortran currently does not implement IEEE_FMA along with a few additional IEEE_ARITHMETIC features added in F2018. Note, gcc/builtins.def has fma, fmaf, and fmal covered. We'll need a mapping in libquadmath if it has a __float128 fma.
[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 --- Comment #7 from Jakub Jelinek --- So do you think you could attach preprocessed sources from both the working and failing builds so that we can look up at the differences?
