[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #7 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andreas Krebbel from comment #5)
> > In:
> >
> > _1 = src_6(D)->a;
> > dst$val_9 = _1;
> > _2 = BIT_FIELD_REF ;
> > _3 = _2 & 64;
> > if (_3 != 0)
>
> There is only 2 accesses going on in the above IR because SRA removed the
> 3rd when it replaced the access of dst.val with dst$val but didn't update
> BIT_FIELD_REF to remove the byteswap ...
Ok, got it. It isn't the removal of the assignment. As you say it happens in
early SRA when changing dst.val to dst$val and with that going from the union
with the storage order marker to a long int without it. The marker on the
BIT_FIELD_REF needs to be in sync with the marker on its inner reference.
Dropping one without adjusting the other is the problem here. Thanks for the
pointer!
The following change helps with that testcase:
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 8dfc923ed7e..6b1ce6e8b4a 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -3815,8 +3815,13 @@ sra_modify_expr (tree *expr, gimple_stmt_iterator *gsi,
bool write)
}
}
else
- *expr = repl;
- sra_stats.exprs++;
+ {
+ if (bfr && TYPE_REVERSE_STORAGE_ORDER (TREE_TYPE (*expr)))
+ REF_REVERSE_STORAGE_ORDER (bfr) = 0;
+
+ *expr = repl;
+ sra_stats.exprs++;
+ }
}
else if (write && access->grp_to_be_debug_replaced)
{
[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 --- Comment #16 from Alexander Monakov --- Draft patch for the sched1 issue: https://inbox.sourceware.org/gcc-patches/cf62c3ec-0a9e-275e-5efa-2689ff1f0...@ispras.ru/T/#m95238afa0f92daa0ba7f8651741089e7cfc03481
[Bug c++/108206] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 --- Comment #1 from Arseny Solokha --- > % g++-13 -c vph5xonf.cc > vph5xonf.cc:1:11: error: 'WrongType' has not been declared > 1 | template void foo (T1); > | ^ > vph5xonf.cc:2:11: error: 'WrongType' has not been declared > 2 | template void bar (T2); > | ^ > zsh: exit 1 g++-13 -c vph5xonf.cc Please ignore that part.
[Bug c++/108206] New: ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 Bug ID: 108206 Summary: ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc 13.0.0 20221218 snapshot (g:fd69977febf399d1992bbf8d66ae9170e0a4dc9f) ICEs when compiling the following testcase: template void foo (T1); template void foo (T2); % g++-13 -c vph5xonf.cc vph5xonf.cc:1:11: error: 'WrongType' has not been declared 1 | template void foo (T1); | ^ vph5xonf.cc:2:11: error: 'WrongType' has not been declared 2 | template void bar (T2); | ^ zsh: exit 1 g++-13 -c vph5xonf.cc asolokha@czc101b91d ~/t1 % g++-13 -c vph5xonf.cc vph5xonf.cc:1:11: error: 'WrongType' has not been declared 1 | template void foo (T1); | ^ vph5xonf.cc:2:11: error: 'WrongType' has not been declared 2 | template void foo (T2); | ^ vph5xonf.cc:2:55: error: redefinition of default argument for '' 2 | template void foo (T2); | ^ vph5xonf.cc:2:55: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 0x88468e tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/tree.cc:8996 0x6d185d contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/tree.h:3642 0x6d185d merge_default_template_args(tree_node*, tree_node*, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/decl.cc:1563 0x9ff720 duplicate_decls(tree_node*, tree_node*, bool, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/decl.cc:2371 0xabdd4c pushdecl(tree_node*, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/name-lookup.cc:3686 0xabf011 do_pushdecl_with_scope /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/name-lookup.cc:4769 0xabf23b pushdecl_namespace_level(tree_node*, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/name-lookup.cc:6125 0xb70268 push_template_decl(tree_node*, bool) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/pt.cc:6128 0xa0d399 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/decl.cc:5908 0xb10835 cp_parser_init_declarator /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:22854 0xb18d5e cp_parser_single_declaration /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:32459 0xb18f4c cp_parser_template_declaration_after_parameters /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:32012 0xb19860 cp_parser_explicit_template_declaration /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:32285 0xb1c504 cp_parser_declaration /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:14959 0xb1d051 cp_parser_toplevel_declaration /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:15051 0xb1d051 cp_parser_translation_unit /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:5090 0xb1d051 c_parse_file() /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/cp/parser.cc:49389 0xc5d681 c_common_parse_file() /var/tmp/portage/sys-devel/gcc-13.0.0_p20221218/work/gcc-13-20221218/gcc/c-family/c-opts.cc:1248
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #10 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd Author: Steve Kargl Date: Thu Dec 22 20:38:57 2022 -0800 Remove not needed assert macro which fails. PR fortran/106731 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_auto_array_allocation): Remove gcc_assert (!TREE_STATIC()). gcc/testsuite/ChangeLog: * gfortran.dg/pr106731.f90: New test.
[Bug c++/108205] New: ICE following "unused parameter" in precondition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108205
Bug ID: 108205
Summary: ICE following "unused parameter" in precondition
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Using (Homebrew GCC HEAD-37c2d99) 13.0.0 20221213 (experimental)
and compiling via:
g++-HEAD -std=c++23 -fmodules-ts -fcontracts -pedantic-errors \
-O0 -Wall -Wextra -Werror -Wpedantic \
-fno-builtin -fconcepts-diagnostics-depth=2
on an x86 MacBook Pro.
This code compiles:
[[nodiscard]] constexpr int
quotient( double x, double y ) noexcept
{
[[assume (y != 0.0)]];
return int(x / y);
}
The same code also compiles as a module:
export module test;
export [[nodiscard]] constexpr int
quotient( double x, double y ) noexcept
{
[[assume (y != 0.0)]];
return int(x / y);
}
But reformulating the assumption as a precondition causes issues.
First, this code is diagnosed with "unused parameter 'x'", which
seems misleading:
[[nodiscard]] constexpr int
quotient( double x, double y ) noexcept
[[ pre: y != 0.0 ]]
{
return int(x / y);
}
Second, when the above is compiled as a module, the compiler
additionally segfaults:
export module test;
export [[nodiscard]] constexpr int
quotient( double x, double y ) noexcept
[[ pre: y != 0.0 ]]
{
return int(x / y);
}
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #8) > The simple patch does indeed fix the ICE at compile time. It also > regression tests cleanly. > > I am studying the results of running this test case to be sure it makes > sense. The DTIO procedure in the example is not getting invoked from my > first look. Indeed it was not being invoked since the line: print *, 'n=',n,automatic(n)%x Completely resolves the value of x. If instead one uses: print *, 'n=',n,automatic The DTIO procedure is invoked as expected. I will commit this one under simple and obvious rule shortly with a test case.
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- The simple patch does indeed fix the ICE at compile time. It also regression tests cleanly. I am studying the results of running this test case to be sure it makes sense. The DTIO procedure in the example is not getting invoked from my first look.
[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 --- Comment #10 from W E Brown --- > On Dec 22, 2022, at 6:51 PM, cvs-commit at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 > > --- Comment #9 from CVS Commits --- > The master branch has been updated by Jason Merrill : > > https://gcc.gnu.org/g:8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 > > commit r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 > Author: Arsen ArsenoviÄ > Date: Thu Dec 22 12:03:06 2022 +0100 > >libstdc++: Improve output of default contract violation handler [PR107792] > >Make the output more readable. Don't output anything unless verbose >termination is enabled at configure-time. > >The testsuite change was almost entirely mechanical. Save for two files >which had very short matches, these changes were produced by two seds and a >Perl script, for the more involved cases. The latter will be added in a >subsequent commit. The former are as follows: > >sed -E -i "/dg-output/s/default std::handle_contract_violation called: > \ >(\S+) (\S+) (\S+(<[A-Za-z0-9, ]*)?>?)\ >/contract violation in function \3 at \1:\2: /" *.C >sed -i '/dg-output/s/ */ /g' > >Whichever files remained failing after the above changes were checked-out, >re-ran, with output extracted, and ran through dg-out-generator.pl. > >Co-Authored-By: Jonathan Wakely > >libstdc++-v3/ChangeLog: > >PR libstdc++/107792 >PR libstdc++/107778 >* src/experimental/contract.cc (handle_contract_violation): Make >output more readable. > >gcc/testsuite/ChangeLog: > >* g++.dg/contracts/contracts-access1.C: Convert to new default >violation handler. >* g++.dg/contracts/contracts-assume2.C: Ditto. >* g++.dg/contracts/contracts-config1.C: Ditto. >* g++.dg/contracts/contracts-constexpr1.C: Ditto. >* g++.dg/contracts/contracts-ctor-dtor1.C: Ditto. >* g++.dg/contracts/contracts-deduced2.C: Ditto. >* g++.dg/contracts/contracts-friend1.C: Ditto. >* g++.dg/contracts/contracts-multiline1.C: Ditto. >* g++.dg/contracts/contracts-post3.C: Ditto. >* g++.dg/contracts/contracts-pre10.C: Ditto. >* g++.dg/contracts/contracts-pre2.C: Ditto. >* g++.dg/contracts/contracts-pre2a2.C: Ditto. >* g++.dg/contracts/contracts-pre3.C: Ditto. >* g++.dg/contracts/contracts-pre4.C: Ditto. >* g++.dg/contracts/contracts-pre5.C: Ditto. >* g++.dg/contracts/contracts-pre7.C: Ditto. >* g++.dg/contracts/contracts-pre9.C: Ditto. >* g++.dg/contracts/contracts-redecl3.C: Ditto. >* g++.dg/contracts/contracts-redecl4.C: Ditto. >* g++.dg/contracts/contracts-redecl6.C: Ditto. >* g++.dg/contracts/contracts-redecl7.C: Ditto. >* g++.dg/contracts/contracts-tmpl-spec1.C: Ditto. >* g++.dg/contracts/contracts-tmpl-spec2.C: Ditto. >* g++.dg/contracts/contracts-tmpl-spec3.C: Ditto. >* g++.dg/contracts/contracts10.C: Ditto. >* g++.dg/contracts/contracts14.C: Ditto. >* g++.dg/contracts/contracts15.C: Ditto. >* g++.dg/contracts/contracts16.C: Ditto. >* g++.dg/contracts/contracts17.C: Ditto. >* g++.dg/contracts/contracts19.C: Ditto. >* g++.dg/contracts/contracts25.C: Ditto. >* g++.dg/contracts/contracts3.C: Ditto. >* g++.dg/contracts/contracts35.C: Ditto. >* g++.dg/contracts/contracts5.C: Ditto. >* g++.dg/contracts/contracts7.C: Ditto. >* g++.dg/contracts/contracts9.C: Ditto. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug libstdc++/107792] Output of default contract violation handler could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107792 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 commit r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 Author: Arsen ArsenoviÄ Date: Thu Dec 22 12:03:06 2022 +0100 libstdc++: Improve output of default contract violation handler [PR107792] Make the output more readable. Don't output anything unless verbose termination is enabled at configure-time. The testsuite change was almost entirely mechanical. Save for two files which had very short matches, these changes were produced by two seds and a Perl script, for the more involved cases. The latter will be added in a subsequent commit. The former are as follows: sed -E -i "/dg-output/s/default std::handle_contract_violation called: \ (\S+) (\S+) (\S+(<[A-Za-z0-9, ]*)?>?)\ /contract violation in function \3 at \1:\2: /" *.C sed -i '/dg-output/s/ */ /g' Whichever files remained failing after the above changes were checked-out, re-ran, with output extracted, and ran through dg-out-generator.pl. Co-Authored-By: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/107792 PR libstdc++/107778 * src/experimental/contract.cc (handle_contract_violation): Make output more readable. gcc/testsuite/ChangeLog: * g++.dg/contracts/contracts-access1.C: Convert to new default violation handler. * g++.dg/contracts/contracts-assume2.C: Ditto. * g++.dg/contracts/contracts-config1.C: Ditto. * g++.dg/contracts/contracts-constexpr1.C: Ditto. * g++.dg/contracts/contracts-ctor-dtor1.C: Ditto. * g++.dg/contracts/contracts-deduced2.C: Ditto. * g++.dg/contracts/contracts-friend1.C: Ditto. * g++.dg/contracts/contracts-multiline1.C: Ditto. * g++.dg/contracts/contracts-post3.C: Ditto. * g++.dg/contracts/contracts-pre10.C: Ditto. * g++.dg/contracts/contracts-pre2.C: Ditto. * g++.dg/contracts/contracts-pre2a2.C: Ditto. * g++.dg/contracts/contracts-pre3.C: Ditto. * g++.dg/contracts/contracts-pre4.C: Ditto. * g++.dg/contracts/contracts-pre5.C: Ditto. * g++.dg/contracts/contracts-pre7.C: Ditto. * g++.dg/contracts/contracts-pre9.C: Ditto. * g++.dg/contracts/contracts-redecl3.C: Ditto. * g++.dg/contracts/contracts-redecl4.C: Ditto. * g++.dg/contracts/contracts-redecl6.C: Ditto. * g++.dg/contracts/contracts-redecl7.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec1.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec2.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec3.C: Ditto. * g++.dg/contracts/contracts10.C: Ditto. * g++.dg/contracts/contracts14.C: Ditto. * g++.dg/contracts/contracts15.C: Ditto. * g++.dg/contracts/contracts16.C: Ditto. * g++.dg/contracts/contracts17.C: Ditto. * g++.dg/contracts/contracts19.C: Ditto. * g++.dg/contracts/contracts25.C: Ditto. * g++.dg/contracts/contracts3.C: Ditto. * g++.dg/contracts/contracts35.C: Ditto. * g++.dg/contracts/contracts5.C: Ditto. * g++.dg/contracts/contracts7.C: Ditto. * g++.dg/contracts/contracts9.C: Ditto.
[Bug libstdc++/107778] handle_contract_violation should reflect _GLIBCXX_VERBOSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107778 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 commit r13-4861-g8ec5fcb6fc79e5bcca23c3fecbaf09d4566cb1d5 Author: Arsen ArsenoviÄ Date: Thu Dec 22 12:03:06 2022 +0100 libstdc++: Improve output of default contract violation handler [PR107792] Make the output more readable. Don't output anything unless verbose termination is enabled at configure-time. The testsuite change was almost entirely mechanical. Save for two files which had very short matches, these changes were produced by two seds and a Perl script, for the more involved cases. The latter will be added in a subsequent commit. The former are as follows: sed -E -i "/dg-output/s/default std::handle_contract_violation called: \ (\S+) (\S+) (\S+(<[A-Za-z0-9, ]*)?>?)\ /contract violation in function \3 at \1:\2: /" *.C sed -i '/dg-output/s/ */ /g' Whichever files remained failing after the above changes were checked-out, re-ran, with output extracted, and ran through dg-out-generator.pl. Co-Authored-By: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/107792 PR libstdc++/107778 * src/experimental/contract.cc (handle_contract_violation): Make output more readable. gcc/testsuite/ChangeLog: * g++.dg/contracts/contracts-access1.C: Convert to new default violation handler. * g++.dg/contracts/contracts-assume2.C: Ditto. * g++.dg/contracts/contracts-config1.C: Ditto. * g++.dg/contracts/contracts-constexpr1.C: Ditto. * g++.dg/contracts/contracts-ctor-dtor1.C: Ditto. * g++.dg/contracts/contracts-deduced2.C: Ditto. * g++.dg/contracts/contracts-friend1.C: Ditto. * g++.dg/contracts/contracts-multiline1.C: Ditto. * g++.dg/contracts/contracts-post3.C: Ditto. * g++.dg/contracts/contracts-pre10.C: Ditto. * g++.dg/contracts/contracts-pre2.C: Ditto. * g++.dg/contracts/contracts-pre2a2.C: Ditto. * g++.dg/contracts/contracts-pre3.C: Ditto. * g++.dg/contracts/contracts-pre4.C: Ditto. * g++.dg/contracts/contracts-pre5.C: Ditto. * g++.dg/contracts/contracts-pre7.C: Ditto. * g++.dg/contracts/contracts-pre9.C: Ditto. * g++.dg/contracts/contracts-redecl3.C: Ditto. * g++.dg/contracts/contracts-redecl4.C: Ditto. * g++.dg/contracts/contracts-redecl6.C: Ditto. * g++.dg/contracts/contracts-redecl7.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec1.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec2.C: Ditto. * g++.dg/contracts/contracts-tmpl-spec3.C: Ditto. * g++.dg/contracts/contracts10.C: Ditto. * g++.dg/contracts/contracts14.C: Ditto. * g++.dg/contracts/contracts15.C: Ditto. * g++.dg/contracts/contracts16.C: Ditto. * g++.dg/contracts/contracts17.C: Ditto. * g++.dg/contracts/contracts19.C: Ditto. * g++.dg/contracts/contracts25.C: Ditto. * g++.dg/contracts/contracts3.C: Ditto. * g++.dg/contracts/contracts35.C: Ditto. * g++.dg/contracts/contracts5.C: Ditto. * g++.dg/contracts/contracts7.C: Ditto. * g++.dg/contracts/contracts9.C: Ditto.
[Bug c++/108204] pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204 --- Comment #2 from nightstrike --- (In reply to Andrew Pinski from comment #1) > Try with -fno-ms-extensions or try -fms-extension on Linux. Hey, we have a winner! -fms-extension on Linux results in the bad error, and -fno-ms-extensions on mingw results in the good one!
[Bug c++/108204] pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204 --- Comment #1 from Andrew Pinski --- Try with -fno-ms-extensions or try -fms-extension on Linux.
[Bug c++/108204] New: pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204
Bug ID: 108204
Summary: pr84973-2.C fails with wrong error on mingw
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
All of the pr84973-2.C tests fail on mingw. They give the output:
g++.dg/template/pr84973-2.C: In instantiation of 'void a()::c::b() [with int
= 0]':
g++.dg/template/pr84973-2.C:7:3: required from 'void a() [with int
= 0]'
g++.dg/template/pr84973-2.C:12:7: required from here
g++.dg/template/pr84973-2.C:5:20: error: statement cannot resolve address of
overloaded function
or outside the testsuite for slightly different formatting:
$ x86_64-w64-mingw32-g++ -c a.cc
a.cc: In instantiation of 'void a()::c::b() [with int = 0]':
a.cc:5:11: required from 'void a() [with int = 0]'
a.cc:10:8: required from here
a.cc:3:38: error: statement cannot resolve address of overloaded function
3 | void b() try { b; } catch (short) { // { dg-error
"invalid use" }
| ^
On linux, however, the output is different:
a.cc: In instantiation of 'void a()::c::b() [with int = 0]':
a.cc:5:11: required from 'void a() [with int = 0]'
a.cc:10:8: required from here
a.cc:3:38: error: invalid use of non-static member function 'void a()::c::b()
[with int = 0]'
3 | void b() try { b; } catch (short) { // { dg-error
"invalid use" }
| ^
a.cc:3:28: note: declared here
3 | void b() try { b; } catch (short) { // { dg-error
"invalid use" }
|^
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 104166, which changed state. Bug 104166 Summary: Implement C++20 std::format https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/104166] Implement C++20 std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Done for GCC 13.
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #3 from Jonathan Wakely --- Time zones committed as r13-4853-g9fc61d45fa15fd Formatting committed as r13-4856-gf99b94865fa629 Still missing std::chrono::parse.
[Bug libstdc++/108200] std::format fails on AIX due to __float128 not being supported by std::to_chars for -maix64 -mlong-double-128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108200 --- Comment #3 from Jonathan Wakely --- And I've just added a few more at r13-4856-gf99b94865fa629 FAIL: 20_util/duration/io.cc (test for excess errors) UNRESOLVED: 20_util/duration/io.cc compilation failed to produce executable FAIL: std/time/clock/file/io.cc (test for excess errors) UNRESOLVED: std/time/clock/file/io.cc compilation failed to produce executable FAIL: std/time/clock/gps/io.cc (test for excess errors) UNRESOLVED: std/time/clock/gps/io.cc compilation failed to produce executable FAIL: std/time/clock/system/io.cc (test for excess errors) UNRESOLVED: std/time/clock/system/io.cc compilation failed to produce executable FAIL: std/time/clock/tai/io.cc (test for excess errors) UNRESOLVED: std/time/clock/tai/io.cc compilation failed to produce executable FAIL: std/time/clock/utc/io.cc (test for excess errors) UNRESOLVED: std/time/clock/utc/io.cc compilation failed to produce executable FAIL: std/time/format.cc (test for excess errors) UNRESOLVED: std/time/format.cc compilation failed to produce executable FAIL: std/time/hh_mm_ss/io.cc (test for excess errors) UNRESOLVED: std/time/hh_mm_ss/io.cc compilation failed to produce executable
[Bug c++/108203] Format string checking with __USE_MINGW_ANSI_STDIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95130 --- Comment #1 from Andrew Pinski --- I suspect this is a dup of bug 95130
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 --- Comment #11 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ee4af2ed0b7322884ec4ff537564683c3749b813 commit r13-4857-gee4af2ed0b7322884ec4ff537564683c3749b813 Author: Jonathan Wakely Date: Thu Dec 22 09:56:47 2022 + libstdc++: Avoid recursion in __nothrow_wait_cv::wait [PR105730] The commit r12-5877-g9e18a25331fa25 removed the incorrect noexcept-specifier from std::condition_variable::wait and gave the new symbol version @@GLIBCXX_3.4.30. It also redefined the original symbol std::condition_variable::wait(unique_lock&)@GLIBCXX_3.4.11 as an alias for a new symbol, __gnu_cxx::__nothrow_wait_cv::wait, which still has the incorrect noexcept guarantee. That __nothrow_wait_cv::wait is just a wrapper around the real condition_variable::wait which adds noexcept and so terminates on a __forced_unwind exception. This doesn't work on uclibc, possibly due to a dynamic linker bug. When __nothrow_wait_cv::wait calls the condition_variable::wait function it binds to the alias symbol, which means it just calls itself recursively until the stack overflows. This change avoids the possibility of a recursive call by changing the __nothrow_wait_cv::wait function so that instead of calling condition_variable::wait it re-implements it. This requires accessing the private _M_cond member of condition_variable, so we need to use the trick of instantiating a template with the member-pointer of the private member. libstdc++-v3/ChangeLog: PR libstdc++/105730 * src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait): Access private data member of base class and call its wait member.
[Bug c++/108203] New: Format string checking with __USE_MINGW_ANSI_STDIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203 Bug ID: 108203 Summary: Format string checking with __USE_MINGW_ANSI_STDIO Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Circa v4.5, some mingw-w64 users discovered an issue with printf functions and g++. Addressing this resulted in a kludge on the mingw-w64 headers side, but this should have been documented here so that we can remove the kludge and have a better coordination between projects. Original mail thread describing the problem: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4F05E61C.6010506%40t-online.de/#msg28632591 Bug report that came from it: https://sourceforge.net/p/mingw-w64/bugs/292/ Header change from fixing the bug report: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/280b5f973e/ This commit might potentially be related: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/1ed6dcc2a19c1aeac5dd4e6530af899fd8d95dbb/ +/* Override __builtin_printf-routines ... Kludge for libstdc++ ...*/ +#define __builtin_vsnprintf __mingw_vsnprintf +#define __builtin_vsprintf __mingw_vsprintf I hope with this PR, we can better coordinate and make both sides better :)
[Bug libstdc++/108200] std::format fails on AIX due to __float128 not being supported by std::to_chars for -maix64 -mlong-double-128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108200 Jonathan Wakely changed: What|Removed |Added Summary|std::format fails on AIX|std::format fails on AIX |due to __float128 not being |due to __float128 not being |supported by std::to_chars |supported by std::to_chars ||for -maix64 ||-mlong-double-128 --- Comment #2 from Jonathan Wakely --- This is only for the -maix64 -mlong-double-128 multilib.
[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #16 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:794af0d00b7086c9f0493f3a1aaac644e1fd50f6 commit r13-4851-g794af0d00b7086c9f0493f3a1aaac644e1fd50f6 Author: Harald Anlauf Date: Thu Dec 22 22:03:31 2022 +0100 Fortran: check for invalid uses of statement functions arguments [PR69604] gcc/fortran/ChangeLog: PR fortran/69604 * match.cc (chk_stmt_fcn_body): New function. Check for invalid uses of statement functions arguments. (gfc_match_st_function): Use above. gcc/testsuite/ChangeLog: PR fortran/69604 * gfortran.dg/statement_function_4.f90: New test.
[Bug libstdc++/108200] std::format fails on AIX due to __float128 not being supported by std::to_chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108200 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-22 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- FAIL: std/format/formatter/requirements.cc (test for excess errors) UNRESOLVED: std/format/formatter/requirements.cc compilation failed to produce executable FAIL: std/format/functions/format.cc (test for excess errors) UNRESOLVED: std/format/functions/format.cc compilation failed to produce executable FAIL: std/format/functions/format_to_n.cc (test for excess errors) UNRESOLVED: std/format/functions/format_to_n.cc compilation failed to produce executable FAIL: std/format/functions/size.cc (test for excess errors) UNRESOLVED: std/format/functions/size.cc compilation failed to produce executable FAIL: std/format/functions/vformat_to.cc (test for excess errors) UNRESOLVED: std/format/functions/vformat_to.cc compilation failed to produce executable FAIL: std/format/string.cc (test for excess errors) UNRESOLVED: std/format/string.cc compilation failed to produce executable
[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code CC||anlauf at gcc dot gnu.org --- Comment #15 from anlauf at gcc dot gnu.org --- Patch to catch the invalid uses of statement function arguments: https://gcc.gnu.org/pipermail/fortran/2022-December/058680.html
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #11 from James Hilliard --- (In reply to Andrew Pinski from comment #1) > The error is correct at least for C before C23. Can you clarify where exactly in the C23 specification that this will be allowed?
[Bug c/108201] Warning about conversion from unsigned int to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108201
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I see the warning already in r0-88996 (haven't bisected exactly, r0-88387
didn't warn),
but before r10-6125-g731dbfc3f3b586e78f2ccdca24561ea3369c6338 the warning
looked like:
pr108201.c: In function ‘decode’:
pr108201.c:4:34: warning: conversion to ‘m_string_unicode_t’ {aka ‘unsigned
int’} from ‘char’ may change the sign of the result [-Wsign-conversion]
4 | *unicode = ((*unicode << 6)) | ((m_string_unicode_t) c);
| ^
and since then till latest trunk like:
pr108201.c: In function ‘decode’:
pr108201.c:4:34: warning: conversion to ‘m_string_unicode_t’ {aka ‘unsigned
int’} from ‘unsigned int’ may change the sign of the result [-Wsign-conversion]
4 | *unicode = ((*unicode << 6)) | ((m_string_unicode_t) c);
| ^
[Bug ada/108202] New: [13 Regression] Many new acats fails on 32bit Darwin hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202 Bug ID: 108202 Summary: [13 Regression] Many new acats fails on 32bit Darwin hosts. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- LAST_UPDATED: Thu Dec 22 09:45:44 UTC 2022 (revision r13-4840-g02fc8100298e) === acats tests === FAIL: a49027b FAIL: a54b02a FAIL: a55b12a FAIL: c250002 FAIL: c34001a FAIL: c34001c FAIL: c37306a FAIL: c35102a FAIL: c354002 FAIL: c354003 FAIL: c35502a FAIL: c35502b FAIL: c35502c FAIL: c35502e FAIL: c390a01 FAIL: c35003a FAIL: c35003b FAIL: c37103a FAIL: c35502g FAIL: c35502h FAIL: c35502i FAIL: c35502j FAIL: c35502k FAIL: c35502l FAIL: c35502m FAIL: c35502n FAIL: c35502p FAIL: c38102e FAIL: c35505c FAIL: c393008 FAIL: c393009 FAIL: c393011 FAIL: c393012 FAIL: c393a05 FAIL: c390001 FAIL: c390004 FAIL: c390005 FAIL: c390006 FAIL: c390a02 FAIL: c390a03 FAIL: c392003 FAIL: c392005 FAIL: c392a01 FAIL: c392d01 FAIL: c392d02 FAIL: c392d03 FAIL: c432001 FAIL: c432004 FAIL: c49023a FAIL: c49026a FAIL: c41107a FAIL: c42006a FAIL: c460a01 FAIL: c460a02 FAIL: c431001 FAIL: c46051b FAIL: c41320a FAIL: c45202b FAIL: c45211a FAIL: c49020a FAIL: c433001 FAIL: c44003f FAIL: c55b10a FAIL: c54a13d FAIL: c55b11a FAIL: c55b11b FAIL: c55b15a FAIL: c56002a FAIL: c64103b FAIL: c761006 FAIL: c74407b FAIL: c730001 FAIL: c730003 FAIL: c74203a FAIL: c85018b FAIL: c85019a FAIL: c87b04c FAIL: c87b31a FAIL: c87b32a FAIL: c87b34c FAIL: c83025c FAIL: c87b19a FAIL: c87b23a FAIL: c87b27a FAIL: c87b41a FAIL: c974003 FAIL: c974004 FAIL: c974005 FAIL: c974006 FAIL: c974007 FAIL: c974008 FAIL: c974009 FAIL: c974010 FAIL: c974011 FAIL: c980003 FAIL: ca13001 FAIL: ca13002 FAIL: ca11b01 FAIL: ca11b02 FAIL: cc1220a FAIL: cc3220a FAIL: cc30002 FAIL: cc3125b FAIL: cc51002 FAIL: cc3230a FAIL: cc3235a FAIL: cc3305a FAIL: cc1308a FAIL: cd2a21c FAIL: cd90001 FAIL: cda201a FAIL: cd30001 FAIL: cdd2a01 FAIL: cdd2a02 FAIL: cdd2a03 FAIL: cd1c03g FAIL: cd1c04d FAIL: cd40001 FAIL: cd30004 FAIL: cd30011 FAIL: cd10002 FAIL: cd5013a FAIL: cd5003b FAIL: ce3908a FAIL: ce3905b FAIL: ce3905l FAIL: ce3906a FAIL: ce3906c FAIL: ce3906e FAIL: ce3901a FAIL: ce3904a FAIL: cxa5013 FAIL: cxac004 === acats Summary === # of expected passes2195 # of unexpected failures133 Native configuration is i686-apple-darwin9 (aime on powerpc-darwin9) the fails are of the form: /scratch/10-5-leo/gcc-master/gcc/gnatmake --GNATBIND=/scratch/10-5-leo/gcc-master/gcc/gnatbind --GNATLINK=/scratch/10-5-leo/gcc-master/gcc/gnatlink --GCC=/scratch/10-5-leo/gcc-master/gcc/xgcc -B/scratch/10-5-leo/gcc-master/gcc/ -gnatws -O2 -gnat95 -I/scratch/10-5-leo/gcc-mas ter/gcc/testsuite/ada/acats1/../acats/support a49027b.adb -largs --GCC=/scratch/10-5-leo/gcc-master/gcc/xgcc -B/scratch/10-5-leo/gcc-master/gcc/ /scratch/10-5-leo/gcc-master/gcc/xgcc -c -B/scratch/10-5-leo/gcc-master/gcc/ -gnatws -O2 -gnat95 -I/scratch/10-5-leo/gcc-master/gcc/testsuite/ada/acats1/../acats/support a49027b.adb raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693 gnatmake: "a49027b.adb" compilation error FAIL: a49027b sometime after r13-4542 ( I do not have many recent samples, since i686 and powerpc are bootstrap broken by rust and gm2).
[Bug c/108201] New: Warning about conversion from unsigned int to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108201
Bug ID: 108201
Summary: Warning about conversion from unsigned int to unsigned
int
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
On a Linux x86_64 system, with GCC 12.2.0, when I build the following program
with -Wsign-conversion ,
typedef unsigned int m_string_unicode_t;
void decode(char c, m_string_unicode_t *unicode) {
*unicode = ((*unicode << 6)) | ((m_string_unicode_t) c);
}
void decode2(char c, unsigned int *unicode) {
*unicode = ((*unicode << 6)) | ((unsigned int) c);
}
I get the following wanning:
tst.c: In function 'decode':
tst.c:6:32: warning: conversion to 'm_string_unicode_t' {aka 'unsigned int'}
from 'unsigned int' may change the sign of the result [-Wsign-conversion]
There is a warning for the function decode, but not for the function decode2.
I don't understand the warning as there is no conversion from unsigned int to
unsigned int as both are the same type. I was expecting no warning for both
functions.
The warning only appears with GCC 12 (no issue with GCC 11).
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 --- Comment #6 from Andrew Pinski --- (In reply to Andreas Krebbel from comment #5) > In: > > _1 = src_6(D)->a; > dst$val_9 = _1; > _2 = BIT_FIELD_REF ; > _3 = _2 & 64; > if (_3 != 0) There is only 2 accesses going on in the above IR because SRA removed the 3rd when it replaced the access of dst.val with dst$val but didn't update BIT_FIELD_REF to remove the byteswap ...
[Bug libstdc++/108200] New: std::format fails on AIX due to __float128 not being supported by std::to_chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108200 Bug ID: 108200 Summary: std::format fails on AIX due to __float128 not being supported by std::to_chars Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* FAIL: std/format/formatter/requirements.cc (test for excess errors) Excess errors: ld: 0711-317 ERROR: Undefined symbol: ._ZSt8to_charsPcS_g ld: 0711-317 ERROR: Undefined symbol: ._ZSt8to_charsPcS_gSt12chars_formati ld: 0711-317 ERROR: Undefined symbol: ._ZSt8to_charsPcS_gSt12chars_format ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status UNRESOLVED: std/format/formatter/requirements.cc compilation failed to produce executable The __float128 format support should be disabled on AIX.
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 --- Comment #6 from Petr Skocik --- (In reply to Petr Skocik from comment #5) > (In reply to Andrew Pinski from comment #4) > > Invalid as mentioned in r13-3135-gfa258f6894801a . > > I believe it's still a bug for pre-c2x __typeof. > While it is GCC's prerogative to include _Noreturn/__attribute((noreturn)) > into the type for its own __typeof (which, BTW, I think is better design > than the standardized semantics), I think two otherwise compatible function > types should still remain compatible if they both either have or don't have > _Noreturn/__attribute((noreturn)). But treating `_Noreturn void > NR_FN_A(void);` > as INcompatible with `_Noreturn void NR_FN_B(void);` that's just wonky, IMO. OK, the bug was MINE after all. For bug report archeologists: I was doing what was meant to be a full (qualifers-including) type comparison wrong. While something like _Generic((__typeof(type0)*)0, __typeof(type1)*:1, default:0) suffices to get around _Generic dropping qualifs (const/volatile/_Atomic) in its controlling expression, for function pointer types at single pointer layer of indirection, the _Noreturn attribute will still get dropped in the controlling expression of _Generic (I guess that makes sense because they're much more closely related to functions that how another pointer type would be related to its target type) and another pointer layer of indirection if required as in `_Generic((__typeof(type0)**)0, __typeof(type1)**:1, default:0)`. Thanks you all very much, especially jos...@codesourcery.com, who pointed me (pun intended) to the right solution over email. :)
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 --- Comment #5 from Andreas Krebbel --- In: _1 = src_6(D)->a; dst$val_9 = _1; _2 = BIT_FIELD_REF ; _3 = _2 & 64; if (_3 != 0) src, dst and the BIT_FIELD_REF carry storage order flags which result in either bswaps being emitted or, in case of the bitfield, the constant for the compare to be adjusted. So from reading "src" to evaluating "_2" 3 "bswaps" will be applied. After dropping the assignment to dst only two remain which cancel each other out. So in the end we access the value without any adjustments. Just to check I did: diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc index b36dd97802b..b858194a432 100644 --- a/gcc/c-family/c-attribs.cc +++ b/gcc/c-family/c-attribs.cc @@ -1820,6 +1820,7 @@ handle_scalar_storage_order_attribute (tree *node, tree name, tree args, } TYPE_REVERSE_STORAGE_ORDER (type) = reverse; + TYPE_VOLATILE (type) = reverse; return NULL_TREE; } As expected this "fixes" the problem but is probably too big of a hammer here since it basically voids many of the advantages of the attribute which is folding away many of the bswaps.
[Bug middle-end/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #9 from Filip Rak --- Hello, I have no idea if this is important, but marking cplx_t constructors as constexpr causes that code can be successfully compiled. Best regards!
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-22 Summary|Bitfields and |Bitfields, unions and SRA |storage_order_attribute |and storage_order_attribute Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- (In reply to Andreas Krebbel from comment #2) > The problem appears to get introduced when dead store elimination removes > the assignment to the target struct in FRE. There is no DSE in FRE going on Rather SRA did messed up. > > Before FRE we have the following: > > _1 = src_6(D)->a; bswap > dst$val_9 = _1; bswap > _2 = BIT_FIELD_REF ; bswap > _3 = _2 & 64; > if (_3 != 0) dst$val_9/_1 are both SSA names and not a store/load. so there is no swapping going on. It is definitely SRA going wrong. Turning off SRA (-fno-sra) and we get the correct thing at the end.
[Bug middle-end/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #8 from Andrew Pinski --- verify_gimple_in_seq_2 could get the same worklist handling too.
[Bug tree-optimization/108199] Bitfields and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 --- Comment #3 from Andreas Krebbel --- Moving the local definition of dst out of the function to global scope prevents the store from getting eliminated. union DST dst; As expected the store is still in the FRE dump: _1 = src_6(D)->a; dst.val = _1;<--- _2 = BIT_FIELD_REF ; _3 = _2 & 64; if (_3 != 0) ... and the first by is accessed: bar: movq(%rdi), %rax movq%rax, dst(%rip) testb $64, %al jne .L11
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #7 from Andrew Pinski --- Created attachment 54151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54151=edit patch which should fix/improve -fno-checking case Note the formating on the code needs to be fixed but this should improve the situtation for -fno-checking case. Instead of being recusive, we have a worklist. Should reduce the stack usage.
[Bug tree-optimization/108199] Bitfields and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 Andreas Krebbel changed: What|Removed |Added Target||x86_64 Build||x86_64 Keywords||wrong-code Host||x86_64 --- Comment #2 from Andreas Krebbel --- The testcase does an assigned between two struct with endianess differing from host endianess (assumed to be little). Here the required byteswaps are supposed to cancel each other out. After that a bitfield comparison on the target struct is done. This comparison uses the wrong byte offset into the bitfield: testb $64, 7(%rdi) jne .L11 On a big endian target the first bits in the bitfield are supposed to reside in the first bytes in memory. The problem appears to get introduced when dead store elimination removes the assignment to the target struct in FRE. Before FRE we have the following: _1 = src_6(D)->a; bswap dst$val_9 = _1; bswap _2 = BIT_FIELD_REF ; bswap _3 = _2 & 64; if (_3 != 0) ... This would result in 3 bswaps chained to each other. However, after FRE we have only two because the dead store to dst$val is removed. _1 = src_6(D)->a; _2 = BIT_FIELD_REF <_1, 8, 0>; _3 = _2 & 64; if (_3 != 0) Now we have only which cancel each other out. Looks like we have to prevent depending stores/loads with different endianess from getting removed - perhaps by making them also volatile? I think we have to keep the number of memory accesses with foreign endianess constant over the optimizations.
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Andrew Pinski --- For -fchecking: #2513 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af3b40) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 #2514 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af3a50) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 #2515 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af39b0) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 #2516 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af38c0) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 #2517 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af3820) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 #2518 0x019eba7a in verify_gimple_in_seq_2 (stmts=0x72af3730) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:5226 For -fno-checking: #26 0x019f8f7f in do_warn_unused_result (seq=0x72882190) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 #27 0x019f8f7f in do_warn_unused_result (seq=0x728820a0) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 #28 0x019f8f7f in do_warn_unused_result (seq=0x72882000) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 #29 0x019f8f7f in do_warn_unused_result (seq=0x72881f00) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 #30 0x019f8f7f in do_warn_unused_result (seq=0x72881e60) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 #31 0x019f8f7f in do_warn_unused_result (seq=0x72881d70) at /home/apinski/src/upstream-gcc/gcc/gcc/tree-cfg.cc:9734 This is for ulimit -s 4096.
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog --- Comment #5 from Andrew Pinski --- Windows has a fixed stack limit and it is usually smallish.
[Bug tree-optimization/108199] Bitfields and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 --- Comment #1 from Andreas Krebbel --- Created attachment 54150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54150=edit Testcase
[Bug tree-optimization/108199] New: Bitfields and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 Bug ID: 108199 Summary: Bitfields and storage_order_attribute Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: ---
[Bug testsuite/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046 --- Comment #10 from Jeffrey A. Law --- Yes. I should have changed the state on this BZ a few weeks back.
[Bug target/107609] ice in extract_insn, at recog.cc:2791 with _mm_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107609 Andrew Pinski changed: What|Removed |Added Summary|ice in extract_insn, at |ice in extract_insn, at |recog.cc:2791 |recog.cc:2791 with ||_mm_prefetch Target Milestone|--- |13.0
[Bug target/107609] ice in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107609 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug testsuite/106515] [13 regression] gcc.dg/debug/btf/btf-int-1.c fails after r13-1937-g5df04a7aa837a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515 --- Comment #6 from Jose E. Marchesi --- (In reply to Richard Biener from comment #5) > Fixed I assume. Yes indeed. Sorry about leaving all these bugs in the "open" state. Only recently I managed to get my bugzilla accounts consolidated in a @gcc.gnu.org one, so I can have editbugs.
[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Martin Liška from comment #3) > > This got fixed since r8-6656-g6d3aa24cd6535dcf. > > This does not make sense since it only started at r13-1204-gd68d366425369649 > ... Oh that is when the original ICE was fixed not the current one.
[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) > This got fixed since r8-6656-g6d3aa24cd6535dcf. This does not make sense since it only started at r13-1204-gd68d366425369649 ...
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #4 from Filip Rak --- This is Windows system, not Linux :(
[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- documentation amended for trunk and branch.
[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:6e09c1d71d23d4c17f035577b318b873960db1d8 commit r12-9009-g6e09c1d71d23d4c17f035577b318b873960db1d8 Author: Richard Biener Date: Thu Dec 22 15:51:46 2022 +0100 bootstrap/106482 - document minimal GCC version There's no explicit mention of what GCC compiler supports C++11 and the cross compiler build requirement mentions GCC 4.8 but not GCC 4.8.3 which is the earliest known version to not run into C++11 implementation bugs. The following adds explicit wording. PR bootstrap/106482 * doc/install.texi (ISO C++11 Compiler): Document GCC version known to work. (cherry picked from commit b97c33fbd28e74a206c81c96a9b0b9fa3c8545d6)
[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b97c33fbd28e74a206c81c96a9b0b9fa3c8545d6 commit r13-4847-gb97c33fbd28e74a206c81c96a9b0b9fa3c8545d6 Author: Richard Biener Date: Thu Dec 22 15:51:46 2022 +0100 bootstrap/106482 - document minimal GCC version There's no explicit mention of what GCC compiler supports C++11 and the cross compiler build requirement mentions GCC 4.8 but not GCC 4.8.3 which is the earliest known version to not run into C++11 implementation bugs. The following adds explicit wording. PR bootstrap/106482 * doc/install.texi (ISO C++11 Compiler): Document GCC version known to work.
[Bug testsuite/106227] [13 regression] g++.dg/modules/loc-prune-4.C fails after r13-1506-g069f46c71e9432
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106227 --- Comment #1 from Richard Biener --- *** Bug 106262 has been marked as a duplicate of this bug. ***
[Bug testsuite/106262] [13 regression] test case g++.dg/modules/loc-prune-4.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106262 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- looks like a dup. *** This bug has been marked as a duplicate of bug 106227 ***
[Bug c++/106363] [13 Regression] [modules] ICE using-declaration of imported name in the same namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-22 Keywords||ice-checking Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed. We run into ... #if CHECKING_P gcc_assert (!import || importedness >= 0); #endif likely also an issue on the branch, but I didn't check.
[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Priority|P3 |P2
Ever confirmed|0 |1
Last reconfirmed||2022-12-22
--- Comment #4 from Richard Biener ---
(In reply to Daniel Richard G. from comment #2)
> It would be good to have a specific minimum version of GCC in the documented
> prerequisites, as the current text ("an existing GCC binary (version 4.8 or
> later)", albeit referring to non-bootstrap builds) misses edge cases like
> this.
Note the documented requirement for bootstrapping is a "ISO C++11 compiler".
We fail to specifically say which GCC version fulfills this, the GCC 4.8
requirement for non-bootstrap is technically unrelated but it will run into
the same issues I think.
Generally when we refer to a major GCC version picking the latest bugfix
release is always recommended.
I'm posting a proposal to amend the documentation.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek --- Looks fixed.
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #3 from Martin Liška --- what's your ulimit -s ?
[Bug target/107609] ice in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107609 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Should have been fixed by r13-3886.
[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 --- Comment #7 from Martin Liška --- With --param=max-jump-thread-duplication-stmts=17 -O3 the call to 'foo' is gone since r8-910-g10bc8017a3028c29.
[Bug testsuite/106515] [13 regression] gcc.dg/debug/btf/btf-int-1.c fails after r13-1937-g5df04a7aa837a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106515 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed I assume.
[Bug tree-optimization/106717] [13 Regression] ICE: tree check: expected integer_cst, have poly_int_cst in get_len, at tree.h:6247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106717 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- So fixed.
[Bug middle-end/106982] [10/11 Regression][OpenACC] ICE incorrect sharing of tree nodes with nested reduction / .GOACC_REDUCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106982 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/106982] [10/11 Regression][OpenACC] ICE incorrect sharing of tree nodes with nested reduction / .GOACC_REDUCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106982 Richard Biener changed: What|Removed |Added Known to fail|12.2.1 |12.2.0 Known to work||12.2.1, 13.0 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-22 Ever confirmed|0 |1 Summary|[10/11/12/13|[10/11 Regression][OpenACC] |Regression][OpenACC] ICE|ICE incorrect sharing of |incorrect sharing of tree |tree nodes with nested |nodes with nested reduction |reduction / |/ .GOACC_REDUCTION |.GOACC_REDUCTION Priority|P3 |P2
[Bug sanitizer/106998] [10/11/12/13 Regression] libsanitizer PATH_MAX not defined for linux new targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998 --- Comment #2 from Richard Biener --- Is this meanwhile resolved or upstream reported?
[Bug libgomp/107041] [13 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041 --- Comment #1 from Richard Biener --- Using a specific builtin enum type in builtins is indeed difficult.
[Bug testsuite/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Richard Biener --- Fixed I assume.
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-12-22
--- Comment #6 from Richard Biener ---
Confirmed for the diagnostics. But note the loop in question is basically
for (a = 1; a != 0; a++)
so it iterates until we wrap to zero (a is 'short', the increment is in
'int' due to promotion so short wrap doesn't invoke undefined overflow).
That means the loop iterates >65000 times which means the repeated add
of 264487869 overflows.
At the point we emit this diagnostic this will always happen so the
diagnostic is correct?
We do fail to optimize if ((c += 264487869) == 9) though, but likely
because VRP no longer iterates. c starts from 1 and we only add positive
numbers the range for it should be [1, +INF]. The entry to the line:
tail loop has this optimized and the add removed as dead code. That's
what possibly happened before - we optimized this branch and thus DCEd
the add?
Anyhow, on x86_64 we mangle the whole thing a bit more than on arc-elf.
Huh, it looks like arc-elf disables GIMPLE loop optimizers. I can reproduce
the diagnostic on x86_64 with -fno-tree-loop-optimize.
gcc/common/config/arc/arc-common.cc has
{ OPT_LEVELS_SIZE, OPT_ftree_loop_optimize, NULL, 0},
for whatever reason. -ftree-loop-optimize "fixes" the diagnostic.
But as said, I think the diagnostic is correct.
[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed||2022-12-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Priority|P3 |P2
--- Comment #11 from Richard Biener ---
Confirmed. We're diagnosing the read
# VUSE <.MEM_106>
_60 = MEM[(const struct basic_string *)]._M_string_length;
which happens conditional after the lifetime of D.48280 starts:
MEM[(struct __as_base &)] ={v} {CLOBBER};
MEM[(union _Variadic_union *)] ={v} {CLOBBER};
MEM[(union _Variadic_union *)] ={v} {CLOBBER};
MEM[(struct _Uninitialized *)] ={v} {CLOBBER};
_128 = (void *) ivtmp.494_2;
_19 = MEM[(const type &)_128];
MEM[(struct _Uninitialized *)]._M_storage = _19;
MEM[(struct _Variant_storage *)]._M_index = 2;
...
the condition chains is
[local count: 668941184]:
MEM[(struct _Variant_storage *)_35]._M_index = 255;
_45 = D.48280.D.48091.D.47570.D.47488.D.47356.D.47242.D.47146._M_index;
_46 = (signed char) _45;
_47 = (long unsigned int) _46;
if (_47 > 4)
goto ; [16.67%]
else
goto ; [83.33%]
[local count: 557450988]:
switch (_45) [20.00%], case 1: [20.00%], case 2:
[20.00%], case 3: [20.00%], case 4: [20.00%]>
[local count: 111490196]:
:
_57 = [(struct basic_string *)_35].D.36033._M_local_buf;
MEM[(struct _Alloc_hider *)_35]._M_p = _57;
_58 = MEM[(const struct basic_string *)]._M_dataplus._M_p;
if ([(const struct basic_string *)].D.36033._M_local_buf == _58)
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 33447058]:
_60 = MEM[(const struct basic_string *)]._M_string_length;
in this case we have other stores possibly clobbering the _M_index store
so we fail to statically optimize these branches (from the = 2 initializer
which should be still there?).
[Bug testsuite/107220] [13 regression] gcc.dg/tree-ssa/forwprop-19.c fails after r13-3212-gb88adba751da63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107220 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Richard Biener --- .
[Bug testsuite/107809] gcc.dg/vect/vect-recurr-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107809 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Should be fixed now.
[Bug testsuite/107809] gcc.dg/vect/vect-recurr-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107809 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d4a320f1ee4c76f09f95bdc583b90a9b049bbba0 commit r13-4846-gd4a320f1ee4c76f09f95bdc583b90a9b049bbba0 Author: Richard Biener Date: Thu Dec 22 14:20:40 2022 +0100 testsuite/107809 - fix vect-recurr testcases This adds a missing effective target check for the permute recurrence vectorization requires. PR testsuite/107809 * gcc.dg/vect/vect-recurr-1.c: Require vect_perm. * gcc.dg/vect/vect-recurr-2.c: Likewise. * gcc.dg/vect/vect-recurr-3.c: Likewise. * gcc.dg/vect/vect-recurr-4.c: Likewise. * gcc.dg/vect/vect-recurr-5.c: Likewise. * gcc.dg/vect/vect-recurr-6.c: Likewise.
[Bug testsuite/107809] gcc.dg/vect/vect-recurr-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107809
--- Comment #3 from Richard Biener ---
It looks like SPARC should support vec_perm with VIS2, but it's not clear
whether that's enabled. The testcases definitely lack an effective target
check for the required permute which is a whole vector shift by 1 element
plus the insert of the topmost lane into the first or a two-vector shift
by 1 element.
I've checked and
/* { dg-require-effective-target vect_perm } */
should disable the test for sparc but it's not exactly spot-on I think
(and as said, it looks like -mvis2 should suppport the test)
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 --- Comment #2 from Filip Rak --- Hi :) Don't think so, it's 40GB RAM machine. Besides that - please look here: https://godbolt.org/z/W7cdvfqvY Best regards!
[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
--- Comment #6 from Richard Biener ---
(In reply to Martin Liška from comment #5)
> With r13-3897-gbe2c74fdcd0e8d66 get:
> gcc pr105832.c -c -O3 -fdump-tree-optimized=/dev/stdout --param
> max-jump-thread-duplication-stmts=17
>
>
> ;; Function main (main, funcdef_no=0, decl_uid=2741, cgraph_uid=1,
> symbol_order=2) (executed once)
>
> int main ()
> {
>[local count: 178992760]:
> c.a = 0;
> return 0;
>
> }
>
> before the revision I was:
>
> ;; Function main (main, funcdef_no=0, decl_uid=2741, cgraph_uid=1,
> symbol_order=2) (executed once)
>
> Removing basic block 5
> int main ()
> {
> char _1;
> unsigned char _2;
> char iftmp.0_11;
>
>[local count: 178992758]:
> _1 = c.b;
> _2 = (unsigned char) _1;
> if (_2 > 4)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 89496379]:
> iftmp.0_11 = _1 << 2;
>
>[local count: 178992760]:
> c.a = 0;
> return 0;
>
> }
That's still without a call to foo ()?
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #6 from Gaius Mulley --- Created attachment 54149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54149=edit m2 remove empty directories from top build (using mkinstalldirs) The same patch as before but now using mkinstalldirs instead of mkdir -p.
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-12-22 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug tree-optimization/108197] [12/13 Regression] -Wstringop-overread emitted on simple boost small_vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Component|c++ |tree-optimization Known to work||11.3.1 Status|UNCONFIRMED |NEW Summary|-Wstringop-overread emitted |[12/13 Regression] |on simple boost |-Wstringop-overread emitted |small_vector code |on simple boost ||small_vector code Keywords||diagnostic Blocks||97048 Last reconfirmed||2022-12-22 Target Milestone|--- |12.3 --- Comment #1 from Richard Biener --- Confirmed. We have [local count: 321929297]: _58 = _43 * 4; _40 = (signed long) _58; _67 = _40 /[ex] 4; sz_68 = (const size_type) _67; if (_58 > 40) goto ; [51.12%] else goto ; [48.88%] [local count: 164570258]: if (_58 > 9223372036854775804) goto ; [0.00%] else goto ; [100.00%] ... [local count: 133301908]: __builtin_memcpy (_82, [(const struct small_vector_base *)].m_storage_start.data, _58); so we get a constraint on _58, the lower bound causes us to warn. The .data field is only 4 bytes in size, so the access is clearly out of bounds. Maybe it is unreachable, the initialization seems to happen in a function not inlined: boost::container::expand_forward_and_insert_alloc.isra ([(struct small_vector_base *)].m_storage_start.data, [(struct small_vector_base *)].m_storage_start.data, 1); _42 = MEM[(struct vector_alloc_holder *)].m_size; it looks like boost already uses always_inline a lot but it doesn't forcefully expose the setting of m_size, so there's not much we can do about this diagnostic. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 [Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
[Bug c/108060] [10/11/12/13 Regression] UBsan missed an out-of-bound bug at -O0 since r7-1900-g8a1b7b7fd75a3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060 Martin Liška changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Martin Liška --- @Marek, can you please take a look?
[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #5 from Martin Liška ---
With r13-3897-gbe2c74fdcd0e8d66 get:
gcc pr105832.c -c -O3 -fdump-tree-optimized=/dev/stdout --param
max-jump-thread-duplication-stmts=17
;; Function main (main, funcdef_no=0, decl_uid=2741, cgraph_uid=1,
symbol_order=2) (executed once)
int main ()
{
[local count: 178992760]:
c.a = 0;
return 0;
}
before the revision I was:
;; Function main (main, funcdef_no=0, decl_uid=2741, cgraph_uid=1,
symbol_order=2) (executed once)
Removing basic block 5
int main ()
{
char _1;
unsigned char _2;
char iftmp.0_11;
[local count: 178992758]:
_1 = c.b;
_2 = (unsigned char) _1;
if (_2 > 4)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 89496379]:
iftmp.0_11 = _1 << 2;
[local count: 178992760]:
c.a = 0;
return 0;
}
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #5 from Gaius Mulley --- Ah thanks, I'll change all uses of mkdir -p to $(mkinstalldirs).
[Bug ipa/80899] [10/11/12/13 Regression] Devirtualization causes incorrect code generation with placement new in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | --- Comment #18 from Martin Liška --- Fixed with r8-2885-ge910a9b11a04d37e.
[Bug c++/108198] G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198 Richard Biener changed: What|Removed |Added Host||x86_64-w64-mingw32 Target||x86_64-w64-mingw32 --- Comment #1 from Richard Biener --- Works fine for me on x86_64-linux > /usr/bin/time ~/install/gcc-12/usr/local/bin/g++ -S t.C 3.12user 0.13system 0:03.25elapsed 99%CPU (0avgtext+0avgdata 518408maxresident)k 0inputs+0outputs (0major+133817minor)pagefaults 0swaps are you running out of memory?
[Bug tree-optimization/108166] [12 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] Wrong|[12 Regression] Wrong code |code with -O2 since |with -O2 since |r12-8078-ga42aa68bf1ad745a |r12-8078-ga42aa68bf1ad745a --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #3 from Martin Liška ---
(In reply to Andrew Pinski from comment #2)
> Testcase just for easier access:
> ```
> void* a;
>
> void foo() {
> if ((a = &))
> return;
>
> l:;
> }
>
> int main() {
> foo();
> goto *a;
>
> return 0;
> }
> ```
> I can no longer reproduce this ICE.
This got fixed since r8-6656-g6d3aa24cd6535dcf.
[Bug rtl-optimization/108193] [13 Regression] ICE in do_SUBST, at combine.cc:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108193 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed on the trunk. Latent on release branches, so I'll likely backport there too.
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5c17adfb5d08e34da7a7f234dfc2ed1f0aaadaa9 commit r13-4845-g5c17adfb5d08e34da7a7f234dfc2ed1f0aaadaa9 Author: Jakub Jelinek Date: Thu Dec 22 12:52:48 2022 +0100 phiopt: Drop SSA_NAME_RANGE_INFO in maybe equal case [PR108166] The following place in value_replacement is after proving that x == cst1 ? cst2 : x phi result is only used in a comparison with constant which doesn't care if it compares cst1 or cst2 and replaces it with x. The testcase is miscompiled because we have after the replacement incorrect range info for the phi result, we would need to effectively union the phi result range with cst1 (oarg in the code) because previously that constant might be missing in the range, but newly it can appear (we've just verified that the single use stmt of the phi result doesn't care about that value in particular). The following patch just resets the info, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Aldy/Andrew, how would one instead union the SSA_NAME_RANGE_INFO with some INTEGER_CST and store it back into SSA_NAME_RANGE_INFO (including adjusting non-zero bits and the like)? 2022-12-22 Jakub Jelinek PR tree-optimization/108166 * tree-ssa-phiopt.cc (value_replacement): For the maybe_equal_p case turned into equal_p reset SSA_NAME_RANGE_INFO of phi result. * g++.dg/torture/pr108166.C: New test.
[Bug rtl-optimization/108193] [13 Regression] ICE in do_SUBST, at combine.cc:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108193 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0cb5d7cdbab8e5f8359764ef5f62d93c2bc88552 commit r13-4844-g0cb5d7cdbab8e5f8359764ef5f62d93c2bc88552 Author: Jakub Jelinek Date: Thu Dec 22 12:44:13 2022 +0100 cse: Fix up CSE const_anchor handling [PR108193] The following testcase ICEs on aarch64, because insert_const_anchor inserts invalid CONST_INT into the CSE tables - 0x8000 for SImode. The second hunk of the patch fixes that, the first one is to avoid triggering undefined behavior at compile time during compute_const_anchors computations - performing those additions and subtractions in HOST_WIDE_INT means it can overflow for certain constants. 2022-12-22 Jakub Jelinek PR rtl-optimization/108193 * cse.cc (compute_const_anchors): Change n type to unsigned HOST_WIDE_INT, adjust comparison against it to avoid warnings. Formatting fix. (insert_const_anchor): Use gen_int_mode instead of GEN_INT. * gfortran.dg/pr108193.f90: New test.
[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104731 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d176d5b3e734cac0ab1e613c3f1bbe48c0bab81a commit r11-10434-gd176d5b3e734cac0ab1e613c3f1bbe48c0bab81a Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it. (cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)
[Bug libstdc++/107814] [10/11 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d176d5b3e734cac0ab1e613c3f1bbe48c0bab81a commit r11-10434-gd176d5b3e734cac0ab1e613c3f1bbe48c0bab81a Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it. (cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #10 from rguenther at suse dot de --- On Thu, 22 Dec 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 > > --- Comment #9 from Jakub Jelinek --- > Created attachment 54147 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54147=edit > gcc13-pr108068.patch > > So like this instead? Untested so far. LGTM.
[Bug c++/108198] New: G++ fails to compile large 2D array initializer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108198
Bug ID: 108198
Summary: G++ fails to compile large 2D array initializer.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.rak81 at gmail dot com
Target Milestone: ---
Created attachment 54148
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54148=edit
Preprocessed output.
The following code (containing 2048x10 array initialization):
#define ROW { { 0.0, 0.0 }, { 1.0, 1.0 }, { 2.0, 2.0 }, { 3.0, 3.0 },
{ 4.0, 4.0 }, \
{ 5.0, 5.0 }, { 6.0, 6.0 }, { 7.0, 7.0 }, { 8.0, 8.0 }, { 9.0,
9.0 } }
#define ROW8 ROW, ROW, ROW, ROW, ROW, ROW, ROW, ROW
#define ROW64 ROW8, ROW8, ROW8, ROW8, ROW8, ROW8, ROW8, ROW8
#define ROW512 ROW64, ROW64, ROW64, ROW64, ROW64, ROW64, ROW64, ROW64
#define ROW4096 ROW512, ROW512, ROW512, ROW512, ROW512, ROW512, ROW512,
ROW512
template
class cplx_t {
public:
T m_re;
T m_im;
cplx_t() : m_re(), m_im() {
}
cplx_t(const T& re, const T& im) : m_re(re), m_im(im) {
}
};
cplx_t test_arr[2048][10] = {
ROW512, ROW512, ROW512, ROW512
};
int main() {
}
causes compiler to abort compilation without any error message.
GCC used:
g++.exe (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders) 12.2.0
Copyright (C) 2022 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.
System:
Windows 11.
Compilation command line:
- g++ -v -save-temps ./test_large_init.cpp
Compiler output:
Using built-in specs.
COLLECT_GCC=C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/r/winlibs64-11.3.0ucrt/2604.gcc/inst_gcc-12.2.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-ucrt-posix-seh, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap
--enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath
--disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs
--disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit
--disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry
--disable-multilib --enable-ld --enable-libquadmath --enable-libada
--enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string
--enable-libgomp --enable-graphite --enable-mingw-wildcard
--enable-libstdcxx-time --disable-libstdcxx-pch
--with-mpc=/e/Prog/winlibs64-11.3.0ucrt/custombuilt
--with-mpfr=/e/Prog/winlibs64-11.3.0ucrt/custombuilt
--with-gmp=/e/Prog/winlibs64-11.3.0ucrt/custombuilt
--with-isl=/e/Prog/winlibs64-11.3.0ucrt/custombuilt
--enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit
--without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/r/winlibs64-11.3.0ucrt/2604.gcc/gcc-12.2.0/build_mingw/mingw-w64
CFLAGS='-I/e/Prog/winlibs64-11.3.0ucrt/custombuilt/include/libdl-win32
-D__USE_MINGW_ACCESS' CXXFLAGS=-D__USE_MINGW_ACCESS
LDFLAGS='-Wl,--disable-nxcompat -Wl,--disable-high-entropy-va
-Wl,--disable-dynamicbase'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/cc1plus.exe
-E -quiet -v -iprefix
c:\programdata\chocolatey\lib\mingw\tools\install\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/12.2.0/
-D_REENTRANT ./test_large_init.cpp -mtune=generic -march=x86-64
-fpch-preprocess -o a-test_large_init.ii
ignoring duplicate directory
"c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0"
ignoring duplicate directory
"c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/programdata/chocolatey/lib/mingw/tools/install/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/backward"
ignoring duplicate directory
[Bug tree-optimization/107451] [11/12 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451 Richard Biener changed: What|Removed |Added Known to work||13.0 Summary|[11/12/13 Regression] |[11/12 Regression] |Segmentation fault with |Segmentation fault with |vectorized code since |vectorized code since |r11-6434|r11-6434 Priority|P3 |P2 --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7b2cf5041460859ca4f58e5da1308b7ef9129d8b commit r13-4843-g7b2cf5041460859ca4f58e5da1308b7ef9129d8b Author: Richard Biener Date: Thu Dec 22 09:36:17 2022 +0100 tree-optimization/107451 - SLP load vectorization issue When vectorizing SLP loads with permutations we can access excess elements when the load vector type is bigger than the group size and the vectorization factor covers less groups than necessary to fill it. Since we know the code will only access up to group_size * VF elements in the unpermuted vector we can simply fill the rest of the vector with whatever we want. For simplicity this patch chooses to repeat the last group. PR tree-optimization/107451 * tree-vect-stmts.cc (vectorizable_load): Avoid loading SLP group members from group numbers in excess of the vectorization factor. * gcc.dg/torture/pr107451.c: New testcase.
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #9 from Jakub Jelinek --- Created attachment 54147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54147=edit gcc13-pr108068.patch So like this instead? Untested so far.
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #8 from Jakub Jelinek --- Created attachment 54146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54146=edit gcc13-pr108068.patch Overnight I've successfully bootstrapped/regtested this, but given your comment that might not be good enough.
[Bug c++/108197] New: -Wstringop-overread emitted on simple boost small_vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
Bug ID: 108197
Summary: -Wstringop-overread emitted on simple boost
small_vector code
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steveire at gmail dot com
Target Milestone: ---
```
#include
struct MyThing
{
int d0 = {};
};
void modify(boost::container::small_vector )
{
pp.resize(1);
pp[0].d0 = 3;
}
void foo()
{
boost::container::small_vector pp2;
boost::container::small_vector pp;
pp.resize(1);
pp[0].d0 = 2;
pp2 = std::move(pp);
}
```
gives
```
/opt/compiler-explorer/libs/boost_1_80_0/boost/container/detail/copy_move_algo.hpp:184:19:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
reading between 41 and 9223372036854775804 bytes from a region of size 40
[-Wstringop-overread]
184 | std::memmove(dest_raw, beg_raw, sizeof(value_type)*n);
```
https://godbolt.org/z/rs3oj3YoE
Even though modify is never called, it must be in the code to reproduce the
bug.
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #4 from Jakub Jelinek --- I think pretty much nothing but m2 uses mkdir -p directly, other makefiles use $(mkinstalldirs) (unless only a single directory needs to be created, for that mkdir dir is fine).
