[Bug target/115659] powerpc fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
Kewen Lin changed:
What|Removed |Added
Blocks||114189
CC||bergner at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org,
||segher at gcc dot gnu.org
Target||powerpc*
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-06-26
Keywords||missed-optimization
Target Milestone|--- |15.0
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Ever confirmed|0 |1
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders
[Bug target/115659] New: powerpc fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
Bug ID: 115659
Summary: powerpc fallout from removing vcond{,u,eq} patterns
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Applying the patch dropping vcond{,u,eq}_optab support
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189#c2), there is only one
failure on both BE and LE:
FAIL: gcc.target/powerpc/pr66144-3.c scan-assembler-not mvspltiswM
Previously I blindly took it as false alarm, but after further checking, I
realized it exposed a miss-opt.
In function rs6000_emit_vector_cond_expr, there is one optimization
/* Optimize vec1 == vec2, to know the mask generates -1/0. */
if (GET_MODE_CLASS (dest_mode) == MODE_VECTOR_INT
&& (GET_CODE (op_true) == CONST_VECTOR
|| GET_CODE (op_false) == CONST_VECTOR))
...
, it's some special handling for
1) op_true -1 and op_false 0
2) op_false 0 and op_true -1
3) op_true -1
4) op_false 0
by reusing the result of vector comparison as it returns -1 or 0.
[Bug tree-optimization/31178] VRP can infer a range for b in a >> b and a << b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178 --- Comment #24 from Andrew Pinski --- Note I am talking about adding path isolation for out of ranges for the shift operand too; https://gcc.gnu.org/pipermail/gcc/2024-June/244213.html . I am not sure how it will interact with this here though.
[Bug tree-optimization/113281] [11 Regression] Latent wrong code due to vectorization of shift reduction and missing promotions since r9-1590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #34 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:54d2339c9f87f702e02e571a5460e11c19e1c02f commit r15-1639-g54d2339c9f87f702e02e571a5460e11c19e1c02f Author: Alexandre Oliva Date: Wed Jun 26 02:08:18 2024 -0300 [testsuite] [arm] [vect] adjust mve-vshr test [PR113281] The test was too optimistic, alas. We used to vectorize shifts by clamping the shift counts below the bit width of the types (e.g. at 15 for 16-bit vector elements), but (uint16_t)32768 >> (uint16_t)16 is well defined (because of promotion to 32-bit int) and must yield 0, not 1 (as before the fix). Unfortunately, in the gimple model of vector units, such large shift counts wouldn't be well-defined, so we won't vectorize such shifts any more, unless we can tell they're in range or undefined. So the test that expected the vectorization we no longer performed needs to be adjusted. Instead of nobbling the test, Richard Earnshaw suggested annotating the test with the expected ranges so as to enable the optimization, and Christophe Lyon suggested a further simplification. Co-Authored-By: Richard Earnshaw for gcc/testsuite/ChangeLog PR tree-optimization/113281 * gcc.target/arm/simd/mve-vshr.c: Add expected ranges.
[Bug c++/115656] Templated ctor use rejected in non-deduced context if class template has template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115656 --- Comment #4 from Sean Murthy --- Created attachment 58517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58517=edit g++ output This file contains the compiler output using the following cmdline on the source file containing the repro code: g++ -v -save-temps -std=c++20 -Wall -Wextra -pedantic -pedantic-errors -Werror=pedantic main.cpp
[Bug c++/115657] [12/13/14/15 Regression] ICE in tsubst_enum/tsubst_expr during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115657 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-26 Target Milestone|--- |12.5 Summary|ICE in |[12/13/14/15 Regression] |tsubst_enum/tsubst_expr |ICE in |during template |tsubst_enum/tsubst_expr |instantiation |during template ||instantiation Known to work||11.1.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- So confirmed.
[Bug c++/115657] ICE in tsubst_enum/tsubst_expr during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115657 Andrew Pinski changed: What|Removed |Added Known to fail||12.1.0, 13.1.0, 14.1.0, ||15.0 Keywords||ice-checking Summary|[15 regression] ICE in |ICE in |tsubst_enum/tsubst_expr |tsubst_enum/tsubst_expr |during template |during template |instantiation |instantiation --- Comment #1 from Andrew Pinski --- /* We shouldn't get here, but keep going if !flag_checking. */ if (flag_checking) gcc_unreachable (); And yes it ICEs with -fchecking starting with GCC 12. I have not checked if this changed to the above check in GCC 12 though.
[Bug c++/115658] char16_t and char32_t aliasing is conserative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658 --- Comment #1 from Andrew Pinski --- Though I should note https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2626r0.pdf and https://github.com/sg16-unicode/sg16-meetings/tree/master#may-22nd-2024 So maybe we really should keep on treating them the same. and maybe change char8_t back to similar as unsigned char ...
[Bug c++/115658] New: char16_t and char32_t aliasing is conserative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115658 Bug ID: 115658 Summary: char16_t and char32_t aliasing is conserative Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: alias, missed-optimization Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- when char8_t was added, a new aliasing set was done: r9-5405-g2d91f79dc990f8 But when char16_t and char32_t was added (for GCC 4.4/C++11): r0-88474-gc466b2cd136139 That was not done. Maybe it should be done now. Noticed from https://github.com/sg16-unicode/sg16/issues/67 .
[Bug c++/115656] Templated ctor use rejected in non-deduced context if class template has template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115656 --- Comment #3 from Sean Murthy --- Created attachment 58516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58516=edit preprocessed file for the source with repro This pre-processed was generated by running the following command: g++ -v -save-temps -std=c++20 -Wall -Wextra -pedantic -pedantic-errors -Werror=pedantic main.cpp
[Bug c++/115657] New: [15 regression] ICE in tsubst_enum/tsubst_expr during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115657
Bug ID: 115657
Summary: [15 regression] ICE in tsubst_enum/tsubst_expr during
template instantiation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vopl at bk dot ru
Target Milestone: ---
$ cat ./ice-15.cpp && echo EOFF
struct NonIntegral
{
constexpr operator int() { return 0; }
};
template struct TemplatedStructural
{
enum { e = NonIntegral{} };
};
template struct TemplatedStructural;
EOFF
$ g++-15 -v -c ./ice-15.cpp
Using built-in specs.
COLLECT_GCC=g++-15
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 15.0. p,
commit 772589fa2b38f09c2f62743d906e12875492d9e0' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--enable-cet --enable-systemtap --disable-valgrind-annotations
--enable-vtable-verify --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--disable-default-ssp --disable-fixincludes --with-build-config='bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240610 (experimental)
eb316013a7c841094577a57407f605b5a7ca5eee (Gentoo 15.0. p, commit
772589fa2b38f09c2f62743d906e12875492d9e0)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/15/cc1plus -quiet -v -D_GNU_SOURCE
./ice-15.cpp -quiet -dumpbase ice-15.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -version -fcf-protection -o /tmp/cchq8U8U.s
GNU C++17 (Gentoo 15.0. p, commit 772589fa2b38f09c2f62743d906e12875492d9e0)
version 15.0.0 20240610 (experimental) eb316013a7c841094577a57407f605b5a7ca5eee
(x86_64-pc-linux-gnu)
compiled by GNU C version 15.0.0 20240610 (experimental)
eb316013a7c841094577a57407f605b5a7ca5eee, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/15/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/15/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
/usr/include
End of search list.
Compiler executable checksum: c29e8810e60ad9d4d5598df79d33bb1a
./ice-15.cpp: In instantiation of 'struct TemplatedStructural':
./ice-15.cpp:11:17: required from here
11 | template struct TemplatedStructural;
| ^
./ice-15.cpp:8:10: internal compiler error: in tsubst_expr, at cp/pt.cc:21872
8 | enum { e = NonIntegral{} };
| ^
0x5605c612fdac tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/pt.cc:21872
0x5605c725d18c tsubst_enum
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/pt.cc:27727
0x5605c725d18c lookup_template_class(tree_node*, tree_node*, tree_node*,
tree_node*, int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/pt.cc:10498
0x5605c7265a9b tsubst(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/pt.cc:16267
0x5605c733badf tsubst_decl
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/pt.cc:15437
0x5605c738a042
[Bug c++/115656] Templated ctor use rejected in non-deduced context if class template has template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115656
--- Comment #2 from Sean Murthy ---
Compiler version: GCC 11.1 through GCC 14.1
Compiler options: -std=c++20 -Wall -Wextra -pedantic -pedantic-errors
-Werror=pedantic
Compiler output:
: In function 'int main()':
:39:13: error: class template argument deduction failed:
39 | A a2(45l); //Error GCC 11.1+: uncomment line above, the error
disappears
| ^
:39:13: error: no matching function for call to 'A(long int)'
:20:5: note: candidate: 'template class
requires unsigned_integral< > V, class S> requires
signed_integral A(S)-> A'
20 | A(S s) : u_( s < 0 ? -s : s) {}
| ^
:20:5: note: template argument deduction/substitution failed:
: In substitution of 'template class requires
unsigned_integral< > V, class S> requires
signed_integral A(S)-> A [with U = unsigned int; V = dv; S = long
int]':
:39:13: required from here
39 | A a2(45l); //Error GCC 11.1+: uncomment line above, the error
disappears
| ^
:20:5: error: template constraint failure for 'template class requires unsigned_integral< >
V> requires unsigned_integral struct A'
20 | A(S s) : u_( s < 0 ? -s : s) {}
| ^
:20:5: note: constraints not satisfied
:17:5: note: candidate: 'template class
requires unsigned_integral< > V> A(U)-> A'
17 | A(U u) : u_(u) {};
| ^
:17:5: note: template argument deduction/substitution failed:
:13:8: note: candidate: 'template class
requires unsigned_integral< > V> A(A)-> A'
13 | struct A
|^
:13:8: note: template argument deduction/substitution failed:
:39:13: note: mismatched types 'A' and 'long int'
39 | A a2(45l); //Error GCC 11.1+: uncomment line above, the error
disappears
| ^
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ())))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635 --- Comment #4 from Sam James --- (gdb) call get_first_event_in_a_function (_fn_event_idx) $20 = false ???
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ())))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
--- Comment #3 from Sam James ---
(gdb) p m_events
$16 = {> =
{> = {m_vec = 0x0}, }, }
(gdb)
Then
(gdb) p m_vec
$17 = (vec *) 0x0
Then
(gdb) s
1153 ASSERT_FALSE (path.interprocedural_p ());
(gdb) p path
$19 = { = {_vptr.diagnostic_path = 0x584b5cc0 },
m_threads = {> =
{> = {
m_vec = 0x58840780}, }, },
m_events = {> =
{> = {m_vec = 0x0}, }, },
m_event_pp = 0x587648f0}
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ())))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
--- Comment #2 from Sam James ---
(In reply to David Malcolm from comment #1)
> "make selftest-valgrind" is clean for me. Note that if you can reproducer
> this standalone, "make selftest-gdb" is a handy way to run the selftests
> under the debugger.
Thanks, this is helpful. I can reproduce it consistently when running gcc
manually once the PM has built it, but not yet managed to reproduce with a
manual build yet.
>
> FWIW, the output suggests that the assertion at line 1153 is failing:
>
> 1147 /* Verify that empty paths are handled gracefully. */
> 1148
> 1149 static void
> 1150 test_empty_path (pretty_printer *event_pp)
> 1151 {
> 1152test_diagnostic_path path (event_pp);
> ->1153ASSERT_FALSE (path.interprocedural_p ());
> 1154
>
> "path" is empty i.e. num_events ought to be returning 0.
>
> Hence I'd expect diagnostic_path::interprocedural_p:
>
>184 bool
>185 diagnostic_path::interprocedural_p () const
>186 {
>187/* Ignore leading events that are outside of any function. */
>188unsigned first_fn_event_idx;
>189if (!get_first_event_in_a_function (_fn_event_idx))
>190 return false;
>
> to call get_first_event_in_a_function, and for that to get 0 for "num", and
> thus bail out with num == 0 again, never entering the loop here:
>
OK, I set a breakpoint for interprocedural_p, and I hit it immediately:
(gdb) n
189 if (!get_first_event_in_a_function (_fn_event_idx))
(gdb) p first_fn_event_idx
$8 = 0
First, we don't know num:
(gdb) s
diagnostic_path::get_first_event_in_a_function (this=this@entry=0x7fffd078,
out_idx=out_idx@entry=0x7fffd014)
at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:167
167 const unsigned num = num_events ();
(gdb) p num
$9 =
Stepping a handful of times, we get to the for loop for the first time:
(gdb) s
diagnostic_path::get_first_event_in_a_function (this=this@entry=0x7fffd078,
out_idx=out_idx@entry=0x7fffd014)
at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:168
168 for (unsigned i = 0; i < num; i++)
(gdb) p num
$11 = 0
(gdb) bt
#0 diagnostic_path::get_first_event_in_a_function
(this=this@entry=0x7fffd078, out_idx=out_idx@entry=0x7fffd014)
at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:168
#1 0x56ebc723 in diagnostic_path::interprocedural_p
(this=this@entry=0x7fffd078) at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:189
#2 0x56ee1bf3 in selftest::test_empty_path
(event_pp=event_pp@entry=0x587648f0) at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:1153
#3 0x56ee2804 in selftest::diagnostic_path_cc_tests () at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/diagnostic-path.cc:2379
#4 0x56e8584c in selftest::run_tests () at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/selftest-run-tests.cc:105
#5 0x5675cb73 in toplev::run_self_tests (this=) at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/toplev.cc:2223
#6 0x577b0009 in toplev::main (this=this@entry=0x7fffd416,
argc=, argv=)
at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/toplev.cc:2327
#7 0x577ae5ee in main (argc=, argv=) at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/main.cc:39
(gdb)
(gdb) s
selftest::test_empty_path (event_pp=event_pp@entry=0x587648f0) at
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/selftest.h:38
38location (const char *file, int line, const char *function)
(gdb) s
1153 ASSERT_FALSE (path.interprocedural_p ());
(gdb)
(gdb) p path
$13 = { = {_vptr.diagnostic_path = 0x584b5cc0 },
m_threads = {> =
{> = {
m_vec = 0x58840780}, }, },
m_events = {> =
{> = {m_vec = 0x0}, }, },
m_event_pp = 0x587648f0}
[Bug tree-optimization/115636] Missing optimzation: fold ` (w << (unsigned int)((flag ? a : b) - 32768))` to ` flag ? w << (unsigned int)(a - 32768) : 0 `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115636 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Going to implement something for isolate-paths. It might not be exactly what was expecting here due it might be using a trap rather than 0. > According to the behavior of gcc Note this is statement is not exactly "correct" it is just the behavior for gcc currently for this undefined behavior. Note I have a straw poll going on which behavior we should do (maybe even by default): https://gcc.gnu.org/pipermail/gcc/2024-June/244213.html
[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189 --- Comment #6 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:aac00d09859cc5934bd0f7493d537b8430337773 commit r15-1638-gaac00d09859cc5934bd0f7493d537b8430337773 Author: liuhongt Date: Thu Jun 20 12:41:13 2024 +0800 Optimize a < 0 ? -1 : 0 to (signed)a >> 31. Try to optimize x < 0 ? -1 : 0 into (signed) x >> 31 and x < 0 ? 1 : 0 into (unsigned) x >> 31. Move the optimization did in ix86_expand_int_vcond to match.pd gcc/ChangeLog: PR target/114189 * match.pd: Simplify a < 0 ? -1 : 0 to (signed) >> 31 and a < 0 ? 1 : 0 to (unsigned) a >> 31 for vector integer type. gcc/testsuite/ChangeLog: * gcc.target/i386/avx2-pr115517.c: New test. * gcc.target/i386/avx512-pr115517.c: New test. * g++.target/i386/avx2-pr115517.C: New test. * g++.target/i386/avx512-pr115517.C: New test. * g++.dg/tree-ssa/pr88152-1.C: Adjust testcase.
[Bug c++/115656] Templated ctor use rejected in non-deduced context if class template has template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115656 --- Comment #1 from Sean Murthy --- Oops. I meant to say "GCC 11.1" in my bug description; not GCC 11.5. It looks like I can't edit the description. So, please make that a mental correction.
[Bug c++/115656] New: Templated ctor use rejected in non-deduced context if class template has template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115656
Bug ID: 115656
Summary: Templated ctor use rejected in non-deduced context if
class template has template template parameter
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s.murthy at outlook dot com
Target Milestone: ---
Using a class constructor in a non-deduced context (when no CTAD is being
attempted, saying that in case my terminology is incorrect) causes an error if
the class template has a template template parameter (lass template A in
repro). Oddly, the error disappears if CTAD is engaged before the erring code.
This is a regression: no issue in GCC 10.5, but issue since GCC 11.1.
Aside, clang accepts this code (from 11.0 to current version)
PS: I searched the bug database and found no report matching this issue, but I
apologize if this issue is known.
Repro below (online https://sigcpp.godbolt.org/z/M1eoE485x):
//stub for use in class template A
template class dv;
//class template A with template template parameter
template class V = dv
>
struct A
{
U u_;
A(U u) : u_(u) {};
template
A(S s) : u_( s < 0 ? -s : s) {}
};
//same as class A but no template template parameter
template
struct B
{
U u_;
B(U u) : u_(u) {};
template
B(S s) : u_( s < 0 ? -s : s) {}
};
int main()
{
//A a1(45ul);
A a2(45l); //Error CGCC 11.5+: uncomment line above, the error disappears
B b2(45l); //OK
}
[Bug target/115648] [15 Regression] GCN: [-PASS:-]{+FAIL:+} gcc.dg/hoist-register-pressure-{2, 3}.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115648 --- Comment #1 from HaoChen Gui --- The patch replaced rtx cost comparison with insn cost comparison. Some replacements can be done before but can't now. Or vice versa. Please check the fwprop dump log via -fdump-rtl-fwprop1-details and judge if the replacements are benefits or not.
[Bug testsuite/109360] RFE: check that generated .sarif files validate against the SARIF schema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109360 --- Comment #4 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:17967907102099806dc80c71ee7665ffb22ffa23 commit r15-1633-g17967907102099806dc80c71ee7665ffb22ffa23 Author: David Malcolm Date: Tue Jun 25 20:26:21 2024 -0400 testsuite: use check-jsonschema for validating .sarif files [PR109360] As reported here: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655434.html the schema validation I added for generated .sarif files in r15-1541-ga84fe222029ff2 used the "jsonschema" command line tool, which has been deprecated by more recent versions of the Python 3 "jsonschema" module. This patch updates the validation to use the more recent "check-jsonschema" command line tool, from the Python 3 "check-jsonschema" module, fixing the testsuite FAILs due to the deprecation message. As an added bonus, the output on validation failures is *much* nicer, e.g. if I undo r15-1540-g9f4fdc3acebcf6, the error messages begin like this: verify-sarif-file: res: Schema validation errors were encountered. diagnostic-format-sarif-file-bad-utf8-pr109098-1.c.sarif::$.runs[0].results[0].locations[0].physicalLocation.region.startColumn: 0 is less than the minimum of 1 diagnostic-format-sarif-file-bad-utf8-pr109098-1.c.sarif::$.runs[0].results[0].relatedLocations[0].physicalLocation.region.startColumn: 0 is less than the minimum of 1 diagnostic-format-sarif-file-bad-utf8-pr109098-1.c.sarif::$.runs[0].results[0].relatedLocations[1].physicalLocation.region.startColumn: 0 is less than the minimum of 1 diagnostic-format-sarif-file-bad-utf8-pr109098-1.c.sarif::$.runs[0].results[0].relatedLocations[2].physicalLocation.region.startColumn: 0 is less than the minimum of 1 child process exited abnormally FAIL: c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c -Wc++-compat (test .sarif output against SARIF schema) Tested with Python 3.8 with check_jsonschema 0.28.6 gcc/ChangeLog: PR testsuite/109360 * doc/install.texi (Python3 modules): Update SARIF validation requirement to use check-jsonschema rather than jsonschema. gcc/testsuite/ChangeLog: PR testsuite/109360 * lib/scansarif.exp (verify-sarif-file): Use check-jsonschema rather than jsonschema, updating the invocation accordingly. * lib/target-supports.exp (check_effective_target_jsonschema): Convert to... (check_effective_target_check_jsonschema): ...this. Signed-off-by: David Malcolm
[Bug c++/115504] [14/15 Regression] Wrong decltype result for a captured reference inside lambda since r14-5330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115504 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:737449e5f233feb682b5dd2cc153892ad90a79bd commit r15-1631-g737449e5f233feb682b5dd2cc153892ad90a79bd Author: Patrick Palka Date: Tue Jun 25 20:07:15 2024 -0400 c++: decltype of capture proxy of ref [PR115504] The finish_decltype_type capture proxy handling added in r14-5330 was incorrectly stripping references in the type of the captured variable. PR c++/115504 gcc/cp/ChangeLog: * semantics.cc (finish_decltype_type): Don't strip the reference type (if any) of a capture proxy's captured variable. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/decltype-auto8.C: New test. Reviewed-by: Jason Merrill
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #10 from Andrew Pinski --- Fixed. GCC 10.x is no longer supported.
[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115634 --- Comment #3 from Richard Sandiford --- Yeah, I agree that sounds like the right fix. Specifically, I assume s390_decompose_addrstyle_without_index, when doing: if (op && GET_CODE (op) != REG) return false; should check whether the register is a pseudo register or is a member of ADDR_REGS. The check should probably be limited to reload_completed, so that the RAs have a chance to reload other registers. The reason this works during register allocation is that the RAs check REGNO_OK_FOR_BASE_P and REGNO_OK_FOR_INDEX_P as part of the constraints process. But those macros are not checked automatically by address constraints themselves (perhaps somewhat surprisingly). It has to be done explicitly in target code. I disagree that the predicates & constraints are icky though. Given the way that the architecture treats shift amounts as addresses, it seems like a neat approach.
[Bug target/115622] gcc.dg/ipa/iinline-attr.c fails after r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115622 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug bootstrap/115655] [15 Regression] bootstrap failure on legitimize_dllimport_symbol: declared 'static' but never defined [-Werror=unused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115655 --- Comment #1 from Evgeny Karpov --- The patch containing the fix is under review. https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655663.html
[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115634 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > s390_valid_shift_count does not seem to check that %r0 was valid here. I should expand on that, it seems to allow any register. I think it should allow only pesudo registers or the valid registers, 1-15.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #18 from Jan Hubicka --- > different issue from the one that is raised in the PR. (Unless we think that > -O2 and -O3 should always have the same inlining heuristics henceforward, but > that seems unlikely.) Yes, I think point of -O3 is to let compiler to be more aggressive than what seems desirable for your average distro build defaults (which needs to balance speed and size). > > At the moment, -O3 is essentially -O2 + some -f options + some --param > options. > Users who want to pick & chose some of the -f options can do so, and can add > them to stable build systems. Normally, obsolete -f options are turned into > no-ops rather than removed. But users can't pick & choose the --params, and > add them to stable build systems, because we reserve the right to remove > --params without warning. Moreover those --params are slowly chaning their meaning in time. I need to retune inliner when early inlining gets smarter. > > So IMO, we should have an -f option that represents “the inlining parameters > enabled by -O3”, whatever they happen to be for a given release. It's OK if > the set is empty. > > For such a change, it doesn't really matter whether the current --params are > the right ones. It just matters that the --params are the ones that we > currently use. If the --params are changed later, the -f option and -O3 will > automatically stay in sync. I am trying to understand how useful this is. I am basically worried about two things 1) we have other optimization passes that behave differently at -O2 and -O3 (vectorizer, unrolling etc.) and I think we may want to have more. We also have -Os and -O1. So perhaps we want kind of more systmatic solution. We already have -fvect-cost-model that is kind of vectorizer version of the proposed inliner option. 2) inliner is already quite painful to tune. Especially since one really needs to benchmark packages significantly bigger than SPECs which tends to be bit hard to set up and benchmark meaningfully. I usually do at least Firefox and clang where the first is always quite some work to get working well with latest GCC. We SUSE's LNT we also run "C++ behchmarks" which were initially collected as kind of inliner tests with higher abstraction penalty (tramp3d etc.). For many years I benchmarked primarily -O3 and -O3 + profile feedbcak on x86-64 only with ocassional look at -O2 and -Os behaviour which were generally more stable. I also tested other targets (poer and aarch64) but just sporadically, which is not good. After GCC5 I doubled testing to include both lto/non-lto variant. Since GCC10 -O2 started to envolve and needed re-testing too (lto/nonlto). One metric I know I ought to tune is -O2 -flto and FDO which used to be essentially -O3 before the optimization level --params were introduced, but now -O2 + FDO inlining is more conservative which hurts, for example, profiledbootstrapped GCC. So naturally I am bit worried to introduce even more combinations that needs testing and maintenance. If we add user friendly way to tweak this, we also make a promise to keep it sane.
Re: [Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
> different issue from the one that is raised in the PR. (Unless we think that > -O2 and -O3 should always have the same inlining heuristics henceforward, but > that seems unlikely.) Yes, I think point of -O3 is to let compiler to be more aggressive than what seems desirable for your average distro build defaults (which needs to balance speed and size). > > At the moment, -O3 is essentially -O2 + some -f options + some --param > options. > Users who want to pick & chose some of the -f options can do so, and can add > them to stable build systems. Normally, obsolete -f options are turned into > no-ops rather than removed. But users can't pick & choose the --params, and > add them to stable build systems, because we reserve the right to remove > --params without warning. Moreover those --params are slowly chaning their meaning in time. I need to retune inliner when early inlining gets smarter. > > So IMO, we should have an -f option that represents “the inlining parameters > enabled by -O3”, whatever they happen to be for a given release. It's OK if > the set is empty. > > For such a change, it doesn't really matter whether the current --params are > the right ones. It just matters that the --params are the ones that we > currently use. If the --params are changed later, the -f option and -O3 will > automatically stay in sync. I am trying to understand how useful this is. I am basically worried about two things 1) we have other optimization passes that behave differently at -O2 and -O3 (vectorizer, unrolling etc.) and I think we may want to have more. We also have -Os and -O1. So perhaps we want kind of more systmatic solution. We already have -fvect-cost-model that is kind of vectorizer version of the proposed inliner option. 2) inliner is already quite painful to tune. Especially since one really needs to benchmark packages significantly bigger than SPECs which tends to be bit hard to set up and benchmark meaningfully. I usually do at least Firefox and clang where the first is always quite some work to get working well with latest GCC. We SUSE's LNT we also run "C++ behchmarks" which were initially collected as kind of inliner tests with higher abstraction penalty (tramp3d etc.). For many years I benchmarked primarily -O3 and -O3 + profile feedbcak on x86-64 only with ocassional look at -O2 and -Os behaviour which were generally more stable. I also tested other targets (poer and aarch64) but just sporadically, which is not good. After GCC5 I doubled testing to include both lto/non-lto variant. Since GCC10 -O2 started to envolve and needed re-testing too (lto/nonlto). One metric I know I ought to tune is -O2 -flto and FDO which used to be essentially -O3 before the optimization level --params were introduced, but now -O2 + FDO inlining is more conservative which hurts, for example, profiledbootstrapped GCC. So naturally I am bit worried to introduce even more combinations that needs testing and maintenance. If we add user friendly way to tweak this, we also make a promise to keep it sane.
[Bug gcov-profile/115628] undefined reference to `__gcov_merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115628 --- Comment #5 from Andrew Pinski --- (In reply to sadineniharish8446 from comment #4) > we ate trying to take coverage for libstdc++, I have tried following > configuration options but getting same error. > > ../configure --enable-languages=c,c++ - --disable-bootstrap > --disable-multilib CFLAGS="-ftest-coverage -fprofile-arcs" > CXXFLAGS="-ftest-coverage -fprofile-arcs " LDFLAGS="--coverage" > > > can you please let me know which configuration will work. Try setting CXXFLAGS_FOR_TARGET only. Note this is not the right place to get help like this. gcc@ (and libstdc++@) mailing list are better places to ask for help on getting this working and only filing a bug if there is no way in the end.
[Bug target/115638] [15 regression] libphobos.phobos/std/container/rbtree.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115638 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target Keywords||memory-hog --- Comment #1 from Andrew Pinski --- I suspect there is a problemantic md pattern which is causing this.
[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115634
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-06-25
CC||pinskia at gcc dot gnu.org
Keywords||build
Component|rtl-optimization|target
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
; 64 bit register shift with reg or imm shift count
; sll, srl, sllg, srlg, sllk, srlk
(define_insn "*3"
[(set (match_operand:GPR 0 "register_operand" "=d, d")
(SHIFT:GPR (match_operand:GPR 1 "register_operand" ", d")
(match_operand:QI 2 "shift_count_operand" "jsc,jsc")))]
""
"@
sl\t%0,<1>%Y2
sl\t%0,%1,%Y2"
[(set_attr "op_type" "RS,RSY")
(set_attr "atype""reg,reg")
(set_attr "cpu_facility" "*,z196")
(set_attr "z10prop" "z10_super_E1,*")])
;; Shift count operands are not necessarily legitimate addresses
;; but the predicate shift_count_operand will only allow
;; proper operands. If reload/lra need to change e.g. a spilled register
;; they can still do so via the special handling of address constraints.
;; To avoid further reloading (caused by a non-matching constraint) we
;; always return true here as the predicate's checks are already sufficient.
(define_address_constraint "jsc"
"Address style operand used as shift count."
(match_test "true" ))
(define_predicate "shift_count_operand"
(and (match_code "reg, subreg, and, plus, const_int")
(match_test "CONST_INT_P (op) || GET_MODE (op) == E_QImode"))
{
return s390_valid_shift_count (op, 63);
}
)
s390_valid_shift_count does not seem to check that %r0 was valid here.
This is so ick though.
[Bug bootstrap/115655] New: [15 Regression] bootstrap failure on legitimize_dllimport_symbol:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115655 Bug ID: 115655 Summary: [15 Regression] bootstrap failure on legitimize_dllimport_symbol: Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- The bootstrap build fails on x86_64-linux as: ../../source/gcc/config/i386/i386.cc:107:12: error: 'rtx_def* legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never defined [-Werror=unused-function] 107 | static rtx legitimize_dllimport_symbol (rtx, bool); |^~~ r15-1599-g63512c72df09b4 looks relevant as it leaves dangling declaration in gcc/config/i386/i386.cc: $ git grep legitimize_dllimport_symbol | cat gcc/ChangeLog-2007: (legitimize_dllimport_symbol): New. gcc/ChangeLog-2008: (legitimize_dllimport_symbol): Add prototype. gcc/config/i386/i386.cc:static rtx legitimize_dllimport_symbol (rtx, bool); gcc/config/mingw/winnt-dll.cc:legitimize_dllimport_symbol (rtx symbol, bool want_reg) gcc/config/mingw/winnt-dll.cc: return legitimize_dllimport_symbol (addr, inreg); gcc/config/mingw/winnt-dll.cc:rtx t = legitimize_dllimport_symbol (XEXP (XEXP (addr, 0), 0), inreg);
[Bug tree-optimization/115636] Missing optimzation: fold ` (w << (unsigned int)((flag ? a : b) - 32768))` to ` flag ? w << (unsigned int)(a - 32768) : 0 `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115636 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- ;; basic block 3, loop depth 0, maybe hot ;;prev block 2, next block 4, flags: (NEW, VISITED) ;;pred: 2 (TRUE_VALUE,EXECUTABLE) # VUSE <.MEM_13(D)> b.1_2 = bD.4438; # RANGE [irange] unsigned int [0, 32767][4294934528, +INF] _3 = (unsigned intD.15) b.1_2; # RANGE [irange] unsigned int [4294901760, +INF] iftmp.0_14 = _3 + 4294934528; goto ; [INV] ;;succ: 5 (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, maybe hot ;;prev block 3, next block 5, flags: (NEW, VISITED) ;;pred: 2 (FALSE_VALUE,EXECUTABLE) _4 = (unsigned intD.15) a_11(D); iftmp.0_12 = _4 + 4294934528; ;;succ: 5 (FALLTHRU,EXECUTABLE) ;; basic block 5, loop depth 0, maybe hot ;;prev block 4, next block 1, flags: (NEW, VISITED) ;;pred: 3 (FALLTHRU,EXECUTABLE) ;;4 (FALLTHRU,EXECUTABLE) # iftmp.0_8 = PHI _5 = _1 << iftmp.0_8; So we could see that bb3 is undefined due to the shift right afterwards and either change it to being __builtin_unreachable or __builtin_trap and then optimize it further. This is a job for gimple-ssa-isolate-paths to handle really.
[Bug tree-optimization/115636] Missing optimzation: fold ` (w << (unsigned int)((flag ? a : b) - 32768))` to ` flag ? w << (unsigned int)(a - 32768) : 0 `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115636 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/115652] [15 Regression] GCN: FAIL: gcc.dg/vect/pr70138-{1,2}.c (internal compiler error: verify_ssa failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115652 Andrew Pinski changed: What|Removed |Added Component|target |tree-optimization Target Milestone|--- |15.0 CC||pinskia at gcc dot gnu.org
[Bug c++/115651] CTAD: gcc accepts the code which should be rejected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115651 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/115650] [15 Regression] ARC backend bug exposed by late-combine pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115650 Andrew Pinski changed: What|Removed |Added Keywords||link-failure Target||arc CC||pinskia at gcc dot gnu.org Target Milestone|--- |15.0
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest since r14-3489-g143151ac2013c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:b383719aebe45bbe8cc3944e515ed7caa30e8744 commit r14-10346-gb383719aebe45bbe8cc3944e515ed7caa30e8744 Author: Sandra Loosemore Date: Tue Jun 25 13:54:43 2024 + Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest This function had a reference to an uninitialized variable on the error path. The problem was diagnosed by clang but not gcc. It seems the cleanest solution is to initialize all the loop-clause variables at the point of declaration rather than at different places in the code. The C++ front end didn't have this problem, but I've made similar changes there to keep the code in sync. gcc/c/ChangeLog: PR c/115587 * c-parser.cc (c_parser_omp_loop_nest): Move initializations to point of declaration. gcc/cp/ChangeLog: PR c/115587 * parser.cc (cp_parser_omp_loop_nest): Move initializations to point of declaration. (cherry picked from commit 21f1073d388af8af207183b0ed592e1cc47d20ab)
[Bug c++/115476] [13/14 Regression] __has_unique_object_representation ICE with array of uninstantiated type of unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476 Marek Polacek changed: What|Removed |Added Summary|[13/14/15 Regression] |[13/14 Regression] |__has_unique_object_represe |__has_unique_object_represe |ntation ICE with array of |ntation ICE with array of |uninstantiated type of |uninstantiated type of |unknown bound |unknown bound --- Comment #10 from Marek Polacek --- Fixed on trunk, I plan to backport it.
[Bug c++/115476] [13/14/15 Regression] __has_unique_object_representation ICE with array of uninstantiated type of unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:fc382a373e6824bb998007d1dcb0805b0cf4b8e8 commit r15-1625-gfc382a373e6824bb998007d1dcb0805b0cf4b8e8 Author: Marek Polacek Date: Mon Jun 17 17:53:12 2024 -0400 c++: ICE with __has_unique_object_representations [PR115476] Here we started to ICE with r13-25: in check_trait_type, for "X[]" we return true here: if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type)) return true; // Array of unknown bound. Don't care about completeness. and then end up crashing in record_has_unique_obj_representations: 4836 if (cur != wi::to_offset (sz)) because sz is null. https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-47-column-3-sentence-1 says that the preconditions for __has_unique_object_representations are: "T shall be a complete type, cv void, or an array of unknown bound" and that "For an array type T, the same result as has_unique_object_representations_v>" so T[] should be treated as T. So we should use kind==2 for the trait. PR c++/115476 gcc/cp/ChangeLog: * semantics.cc (finish_trait_expr) : Move below to call check_trait_type with kind==2. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/has-unique-obj-representations4.C: New test.
[Bug web/115627] Diagnostics Conventions does not mention options and keywords should be quoted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115627 --- Comment #3 from Andrew Pinski --- Oh some of it is in the internals manual too: https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Quoting
[Bug c++/115430] Cannot take address of template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115430 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- Testing a patch.
[Bug target/115654] __builtin_cpu_supports should accept specific CPU names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115654 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/115653] USE without ONLY warning when compiling submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115653 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #1 from kargls at comcast dot net --- Thanks for the bug report. Fortunately, it is only warning that clutters the terminal. This patch suppresses the warning, but may not catch a 'USE xyz' within the submodule. diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc index c565b84d61b..5a58a9dbace 100644 --- a/gcc/fortran/module.cc +++ b/gcc/fortran/module.cc @@ -7285,7 +7285,7 @@ gfc_use_module (gfc_use_list *module) only_flag = module->only_flag; current_intmod = INTMOD_NONE; - if (!only_flag) + if (!only_flag && gfc_state_stack->state != COMP_SUBMODULE) gfc_warning_now (OPT_Wuse_without_only, "USE statement at %C has no ONLY qualifier");
[Bug target/115654] New: __builtin_cpu_supports should accept specific CPU names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115654
Bug ID: 115654
Summary: __builtin_cpu_supports should accept specific CPU
names
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alexhenrie24 at gmail dot com
Target Milestone: ---
I'd like to have a specific minimum supported CPU for some particular software,
but also allow the software to run on newer CPUs that support a superset of the
minimum CPU's features. For example, I could say that the compiled binary will
run on an AMD Zen 3 processor or any other compatible processor, including any
future Intel CPUs that support all of the Zen 3's features. If the software is
run on an unsupported CPU, it needs to print a user-friendly error message. I
can see two ways to do that:
1. Check for every possible CPU: __builtin_cpu_is("znver3") ||
__builtin_cpu_is("znver4") || __builtin_cpu_is("znver5"). This is tedious
because I'd have to add to the list whenever new CPUs are added to GCC and it's
easy to miss one.
2. Check for all of the required CPU features:
__builtin_cpu_supports("x86-64-v3") && __builtin_cpu_supports("pclmul") &&
__builtin_cpu_supports("vpclmulqdq"). This is tedious because I have to look up
all of the features that are enabled by -march=znver3 and it's easy to miss
one.
For my use case, it would be very helpful if I could just write
__builtin_cpu_supports("znver3") to know, regardless of whether the CPU really
_is_ a Zen 3, whether it is fully _compatible_ with a Zen 3.
[Bug fortran/115653] New: USE without ONLY warning when compiling submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115653
Bug ID: 115653
Summary: USE without ONLY warning when compiling submodules
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gmt3141 at gmail dot com
Target Milestone: ---
When I compile a submodule with `-Wuse-without-only` option, a false positive
warning about USE without ONLY will be shown:
$ gfortran -Wuse-without-only greeting.f90
greeting.f90:13:19:
13 | submodule (greet_m) greet_implementation_sm
| 1
Warning: USE statement at (1) has no ONLY qualifier [-Wuse-without-only]
!!
!! greeting.f90
!!
module greet_m
implicit none
interface
module subroutine hello (name)
character (len=*), intent (in), optional :: name
end subroutine hello
end interface
end module greet_m
submodule (greet_m) greet_implementation_sm
contains
module subroutine hello (name)
character (len=*), intent (in), optional :: name
if (present (name)) then
print '("Hello ", a, "!")', name
else
print '("Hello World!")'
end if
end subroutine hello
end submodule greet_implementation_sm
program greeting
use greet_m, only: hello
implicit none
call hello
call hello ('John')
end program greeting
[Bug modula2/115540] "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115540 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug c++/115616] c++20: Friend-injecting a template function causes an ICE if you inject after trying to instantiate that function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115616 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-06-25 Status|UNCONFIRMED |ASSIGNED CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r9-3807-g5d9a0e3b99e31a commit 5d9a0e3b99e31a2167f6b6ab2473feb58f7c77e8 Author: Marek Polacek Date: Thu Nov 1 22:10:31 2018 + Implement P0846R0, ADL and function templates. so apparently mine.
[Bug modula2/115540] "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115540 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:d16355c72c7f7b54ecf06371d14d7ad309ea4c34 commit r15-1623-gd16355c72c7f7b54ecf06371d14d7ad309ea4c34 Author: Gaius Mulley Date: Tue Jun 25 21:37:44 2024 +0100 PR modula2/115540 gcc/m2/mc-boot-ch/Gtermios.cc error return-statement with a value This patch fixes three occurrences of cfmakeraw use in the hand built m2 support libraries which incorrectly attempt to return a void result. gcc/m2/ChangeLog: PR modula2/115540 * gm2-libs-ch/termios.c (cfmakeraw): Remove return. * mc-boot-ch/Gtermios.cc (cfmakeraw): Remove return. * pge-boot/Gtermios.cc (cfmakeraw): Remove return. Signed-off-by: Gaius Mulley
[Bug target/115652] New: [15 Regression] GCN: FAIL: gcc.dg/vect/pr70138-{1,2}.c (internal compiler error: verify_ssa failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115652
Bug ID: 115652
Summary: [15 Regression] GCN: FAIL: gcc.dg/vect/pr70138-{1,2}.c
(internal compiler error: verify_ssa failed)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code, testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Target: GCN
As of commit r15-1056-g4653b682ef161c3c2fc7bf8462b8f9206a1349e6 "Allow
single-lane SLP in-order reductions" we've got a '-fchecking' ICE regression
for GCN target (tested '-march=gfx908'):
{+FAIL: gcc.dg/vect/pr70138-1.c (internal compiler error: verify_ssa
failed)+}
[-PASS:-]{+FAIL:+} gcc.dg/vect/pr70138-1.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} gcc.dg/vect/pr70138-1.c [-execution
test-]{+compilation failed to produce executable+}
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-1.c: In function 'foo':
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-1.c:6:1: error:
definition in block 3 follows the use
for SSA_NAME: stmp_c_17.9_153 in statement:
c_17 = stmp_c_17.9_153 + stmp_c_17.9_154;
during GIMPLE pass: vect
dump file: ./pr70138-1.c.180t.vect
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-1.c:6:1: internal
compiler error: verify_ssa failed
0x142272d verify_ssa(bool, bool)
[...]/source-gcc/gcc/tree-ssa.cc:1203
{+FAIL: gcc.dg/vect/pr70138-2.c (internal compiler error: verify_ssa
failed)+}
[-PASS:-]{+FAIL:+} gcc.dg/vect/pr70138-2.c (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} gcc.dg/vect/pr70138-2.c [-execution
test-]{+compilation failed to produce executable+}
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-2.c: In function 'foo':
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-2.c:6:1: error:
definition in block 3 follows the use
for SSA_NAME: stmp_c_15.9_152 in statement:
c_15 = stmp_c_15.9_152 + stmp_c_15.9_153;
during GIMPLE pass: vect
dump file: ./pr70138-2.c.180t.vect
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/pr70138-2.c:6:1: internal
compiler error: verify_ssa failed
0x142272d verify_ssa(bool, bool)
[...]/source-gcc/gcc/tree-ssa.cc:1203
[Bug c++/115651] New: CTAD: gcc accepts the code which should be rejected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115651
Bug ID: 115651
Summary: CTAD: gcc accepts the code which should be rejected.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hokein.wu at gmail dot com
Target Milestone: ---
Consider the following code snippet:
```
template
struct Out {
template
struct Foo {
Foo(U);
};
template
requires false // always return false.
using Alias1 = Foo;
template
using Alias2 = Alias1;
};
Out::Alias2 s = 10;
```
The code should be rejected because of the always-false constraint on the
`Alias1`, but gcc accepts it, https://godbolt.org/z/czcsfezrv
If we remove remove the `Out` template class, gcc works as expected.
[Bug c/115644] [gcc][trunk] ICE if redeclare a variable with different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115644 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Confirmed.
[Bug middle-end/115641] [11/12/13/14/15 Regression] GCC crashes on function has attribute `__attribute__((const))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641
Marek Polacek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
It's the
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -4447,8 +4447,7 @@ simple_operand_p_2 (tree exp)
{
enum tree_code code;
- if (TREE_SIDE_EFFECTS (exp)
- || tree_could_trap_p (exp))
+ if (TREE_SIDE_EFFECTS (exp) || generic_expr_could_trap_p (exp))
return false;
while (CONVERT_EXPR_P (exp))
change. simple_condition_p gets
((short unsigned int) BIT_FIELD_REF [(void *) ()], 16, 0> &
65535) != 513
and generic_expr_could_trap_p recurses down to tree_could_trap_p getting
MEM [(void *) ()]
where we get the base which is "f ()" but DECL_SIZE_UNIT crashes on that.
[Bug middle-end/115641] [11/12/13/14/15 Regression] GCC crashes on function has attribute `__attribute__((const))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-06-25 Component|c |middle-end Summary|GCC crashes on function has |[11/12/13/14/15 Regression] |attribute |GCC crashes on function has |`__attribute__((const))`|attribute ||`__attribute__((const))` Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |11.5 Priority|P3 |P2 CC||mpolacek at gcc dot gnu.org Keywords||ice-on-valid-code --- Comment #1 from Marek Polacek --- Confirmed. Started with r10-3830-g853ce7c073eedf: commit 853ce7c073eedfba1adfb63530a8bd2baa767137 Author: Jakub Jelinek Date: Sat Oct 12 14:21:45 2019 +0200 re PR middle-end/92063 (ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c)
[Bug target/115643] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 --- Comment #2 from Evgeny Karpov --- Thanks for reporting the issue. The patch series has been tested, and regression tests have been executed for x86_64-w64-mingw32. Could you please provide more details on which patch triggers the regression? It looks more like binutils changes.
[Bug c++/115425] [13/14 regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Summary|[13/14/15 regression] ICE: |[13/14 regression] ICE: |tree check: expected|tree check: expected |type_pack_expansion or |type_pack_expansion or |expr_pack_expansion, have |expr_pack_expansion, have |error_mark in |error_mark in |tsubst_pack_expansion, at |tsubst_pack_expansion, at |cp/pt.cc:13778 |cp/pt.cc:13778 --- Comment #5 from Marek Polacek --- Fixed on trunk.
[Bug c++/115425] [13/14/15 regression] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115425 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:ed6ffc4e62f716d1b31d599d22594dd969da137f commit r15-1621-ged6ffc4e62f716d1b31d599d22594dd969da137f Author: Marek Polacek Date: Fri Jun 14 17:50:29 2024 -0400 c++: ICE with generic lambda and pack expansion [PR115425] In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros. That trips up here because make_pack_expansion returns error_mark_node and we access that with PACK_EXPANSION_LOCAL_P. PR c++/115425 gcc/cp/ChangeLog: * pt.cc (tsubst_pack_expansion): Return error_mark_node if make_pack_expansion doesn't work out. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-generic12.C: New test.
[Bug c++/115501] [13/14 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast since r13-3299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115501 Marek Polacek changed: What|Removed |Added Summary|[13/14/15 Regression] ICE: |[13/14 Regression] ICE: in |in build_call_a with|build_call_a with |dynamic_cast after invalid |dynamic_cast after invalid |definition of |definition of |__cxxabiv1::__dynamic_cast |__cxxabiv1::__dynamic_cast |since r13-3299 |since r13-3299 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Marek Polacek --- Fixed on trunk.
[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast since r13-3299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115501 --- Comment #10 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:71f484d02b2b3e8616cd7af27a0d4c72e4c7e977 commit r15-1620-g71f484d02b2b3e8616cd7af27a0d4c72e4c7e977 Author: Marek Polacek Date: Tue Jun 18 10:50:49 2024 -0400 c++: ICE with __dynamic_cast redecl [PR115501] Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls duplicate_decls and that in this testcase emits the "conflicting declaration" error and returns error_mark_node, so the subsequent build_cxx_call crashes on the error_mark_node. PR c++/115501 gcc/cp/ChangeLog: * rtti.cc (build_dynamic_cast_1): Return if dcast_fn is erroneous. gcc/testsuite/ChangeLog: * g++.dg/rtti/dyncast8.C: New test.
[Bug target/112363] GCN: 'FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c execution test'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112363
Thomas Schwinge changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=115382
--- Comment #4 from Thomas Schwinge ---
(In reply to Thomas Schwinge from comment #3)
> Something in the last few weeks' worth of commits made this go back to PASS:
>
> PASS: gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c (test for
> excess errors)
> [-FAIL:-]{+PASS:+} gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c
> execution test
For posterity: it was commit r15-1187-g2b438a0d2aa80f051a09b245a58f643540d4004b
"vect: Merge loop mask and cond_op mask in fold-left reduction [PR115382]" that
fixed this for GCN target, too.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #17 from Richard Sandiford --- I can see that it's useful to ask whether the current -O2 & -O3 inlining heuristics are making the right trade-off. But I think that's really a different issue from the one that is raised in the PR. (Unless we think that -O2 and -O3 should always have the same inlining heuristics henceforward, but that seems unlikely.) At the moment, -O3 is essentially -O2 + some -f options + some --param options. Users who want to pick & chose some of the -f options can do so, and can add them to stable build systems. Normally, obsolete -f options are turned into no-ops rather than removed. But users can't pick & choose the --params, and add them to stable build systems, because we reserve the right to remove --params without warning. So IMO, we should have an -f option that represents “the inlining parameters enabled by -O3”, whatever they happen to be for a given release. It's OK if the set is empty. For such a change, it doesn't really matter whether the current --params are the right ones. It just matters that the --params are the ones that we currently use. If the --params are changed later, the -f option and -O3 will automatically stay in sync.
[Bug c/115642] [11/12/13/14/15 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_expr_sizeof_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115642 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Keywords||ice-on-invalid-code Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.5 Last reconfirmed||2024-06-25 Summary|[gcc][trunk] internal |[11/12/13/14/15 Regression] |compiler error: tree check: |internal compiler error: |expected class 'type', have |tree check: expected class |'exceptional' (error_mark) |'type', have 'exceptional' |in c_expr_sizeof_expr |(error_mark) in ||c_expr_sizeof_expr CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This is a very old regression. r145256 crashes but r145245 doesn't. I have a patch.
[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98678 John David Anglin changed: What|Removed |Added Attachment #58500|0 |1 is obsolete|| --- Comment #13 from John David Anglin --- Created attachment 58515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58515=edit Really fix poll.cc on hppa-linux hppa-linux doesn't have high resolution timer support. Timer resolutions range from 1 to 10ms depending on CONFIG_HZ. The ready loop takes about 5ns per call. As a result, we need a lot of iterations to obtain reasonable accuracy in the ready loop. I reduced the number of iteration in the wait_until_sys_epoch and wait_until_steady_epoch loops to 1000 so test would run in a reasonable time. The results for these two loops are currently not checked. Here is output on 1GHz c8000 with HZ=250: dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe wait_for(0s): 4919957362ns for 1 calls, avg 49.1996ns per call wait_until(system_clock minimum): 22053828859ns for 1 calls, avg 220.538ns per call wait_until(steady_clock minimum): 22277782883ns for 1 calls, avg 222.778ns per call wait_until(system_clock epoch): 365336ns for 1000 calls, avg 3.7e+06ns per call wait_until(steady_clock epoch: 365335ns for 1000 calls, avg 3.7e+06ns per call wait_for when ready: 519995494ns for 1 calls, avg 5.19995ns per call
[Bug modula2/115540] "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115540 --- Comment #2 from Gaius Mulley --- Created attachment 58514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58514=edit Proposed fix Here is a proposed patch - which is currently being bootstrap tested.
[Bug modula2/115540] "gcc/m2/mc-boot-ch/Gtermios.cc:292:20: error: return-statement with a value, in function returning 'void' [-fpermissive]" when HAVE_CFMAKERAW is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115540 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-06-25 --- Comment #1 from Gaius Mulley --- Many thanks for the bug report - confirmed.
[Bug target/115650] [15 Regression] ARC backend bug exposed by late-combine pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115650 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/115650] New: [15 Regression] ARC backend bug exposed by late-combine pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115650
Bug ID: 115650
Summary: [15 Regression] ARC backend bug exposed by
late-combine pass
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This code generates code that can't be groked by as/ld with -O2:
/* { dg-do run } */
int a, b[2];
int
main ()
{
lbl:
for (; a; a--)
if (b[1])
goto lbl;
return 0;
}
The problem is this instruction:
ld.as r2,[gp,@b@sda+4];23 # 12[c=8 l=8]
*movsi_insn/23
That will trigger errors like this from the linker:
pr60115.c:(.text.startup+0x6): relocation truncated to fit: R_ARC_SDA16_LD2
against symbol `b' defined in .sbss section in /tmp/ccgCSiHr.o
With the right magic options this can also be triggered without the late
combine pass. The trick is to disable PRE and LICM so that these instructions
end up in the same block and are then subject to combine:
(insn 11 8 12 3 (set (reg/f:SI 157)
(const:SI (plus:SI (symbol_ref:SI ("b") [flags 0x6] )
(const_int 40960 [0xa000] "j.c":10:10 3 {*movsi_insn}
(nil))
(insn 12 11 13 3 (set (reg:SI 158 [ b[1] ])
(mem:SI (plus:SI (reg/f:SI 157)
(const_int -960 [0xfc40])) [1 b[1]+0 S4 A32]))
"j.c":10:8 3 {*movsi_insn}
(expr_list:REG_DEAD (reg/f:SI 157)
(nil)))
That will result in:
(insn 12 11 13 3 (set (reg:SI 158 [ b[1] ])
(mem:SI (const:SI (plus:SI (symbol_ref:SI ("b") [flags 0x6] )
(const_int 4 [0x9c40]))) [1 b[1]+0 S4 A32]))
"j.c":10:8 3 {*movsi_insn}
(nil))
Which triggers the subsequent linker error.
This is almost certainly a bug in the ARC backend. I'm not currently chasing
it down.
[Bug debug/115649] New: Non-ABI constructor (C4) emitted in DWARF .debug_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115649
Bug ID: 115649
Summary: Non-ABI constructor (C4) emitted in DWARF .debug_info
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: devengangwani12 at gmail dot com
Target Milestone: ---
Minimal example:
---
//test.cpp
struct A {
int p;
A(int a): p(a) {}
virtual ~A() {}
};
struct A1: public A {
int q;
A1(int b): A(b - 1), q(b) {}
~A1() {}
};
int main() {
A1 new_A1 = A1(5);
return new_A1.p;
}
---
Platform: x86_64
Compile with: g++ -g -c test.cpp
Relevant output of readelf -Ws test.o:
15: 0 NOTYPE LOCAL DEFAULT 1 _ZN1AC5Ei
17: 0 NOTYPE LOCAL DEFAULT 3 _ZN2A1C5Ei
19: 42 FUNCWEAKDEFAULT15 _ZN1AC2Ei
21: 42 FUNCWEAKDEFAULT15 _ZN1AC1Ei
26: 66 FUNCWEAKDEFAULT21 _ZN2A1C2Ei
28: 66 FUNCWEAKDEFAULT21 _ZN2A1C1Ei
Relevant output of dwarfdump -i test.o or readelf -Wwi test.o:
<41> DW_AT_linkage_name: (strp) (offset: 0x117): _ZN2A1C4ERKS_
<66> DW_AT Linkage_name: (strp) (offset: 0xff): _ZN2A1C4Ei
DW_AT_linkage_name: (strp) (offset: 0x10a): _ZNIAC4ERKS_
DW AT_linkage_name: (strp) (offset: 0xfo): _ZN1AC4Ei
<22b> DW_AT_linkage_name: (strp) (offset: 0x3): _ZN2A1C2Ei
<2f7> DW_AT_ linkage_name: (strp) (offset: 0xbe): _ZN1AC2Ei
[all are DW_TAG_subprograms]
The linkage names should conform to the ABI which doesn't include C4
constructors (at least according to this:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html).
[Bug target/115640] [15 Regression] GCN: FAIL: gfortran.dg/vect/pr115528.f -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115640 Thomas Schwinge changed: What|Removed |Added Summary|GCN: FAIL: |[15 Regression] GCN: FAIL: |gfortran.dg/vect/pr115528.f |gfortran.dg/vect/pr115528.f | -O execution test| -O execution test See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114107 --- Comment #5 from Thomas Schwinge --- Turns out, this is a regression after all: before commit r15-1238-g1fe55a1794863b5ad9eeca5062782834716016b2 "tree-optimization/114107 - avoid peeling for gaps in more cases", this test case 'gfortran.dg/vect/pr115528.f' (which, of course, wasn't in-tree back then) does PASS its execution test for GCN target (tested '-march=gfx908').
[Bug rtl-optimization/111673] assign_hard_reg() routine should scale save/restore costs of callee save registers with basic block frequency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111673 --- Comment #1 from GCC Commits --- The master branch has been updated by Surya Kumari Jangala : https://gcc.gnu.org/g:3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b commit r15-1619-g3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b Author: Surya Kumari Jangala Date: Tue Jun 25 08:37:49 2024 -0500 ira: Scale save/restore costs of callee save registers with block frequency In assign_hard_reg(), when computing the costs of the hard registers, the cost of saving/restoring a callee-save hard register in prolog/epilog is taken into consideration. However, this cost is not scaled with the entry block frequency. Without scaling, the cost of saving/restoring is quite small and this can result in a callee-save register being chosen by assign_hard_reg() even though there are free caller-save registers available. Assigning a callee save register to a pseudo that is live in the entire function and across a call will cause shrink wrap to fail. 2024-06-25 Surya Kumari Jangala gcc/ PR rtl-optimization/111673 * ira-color.cc (assign_hard_reg): Scale save/restore costs of callee save registers with block frequency. gcc/testsuite/ PR rtl-optimization/111673 * gcc.target/powerpc/pr111673.c: New test.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #16 from Rama Malladi --- I had posted a patch at the URL below for this feature: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655506.html
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #15 from Rama Malladi --- Thanks for the comments and for giving us some history/ perspective. I agree with this statement, > Pushing up -O2 limits can make sense, but needs to be done carefully - > in longer term IMO we do not want to let -O2 binaries to grow faster > than their perofrmance. Sadly this figure is not that great. and hence this option was proposed to help the user explicitly enable it and get more performance gains w inlining in addtion to LTO. The initial description I posted had perf upside for individual SPEC cpu2017 Int rate benchmarks w LTO. Note that not all benchmarks benefit and indeed `500.perlbench_r` perf went down w code size increase. But some other benchmarks such as `502.gcc_r`, `523.xalancbmk_r`, `531.deepsjeng_r` and `541.leela_r` saw better performance. Customer applications such as Envoy saw higher performance with these inline parameters.
[Bug modula2/115536] Expression is evaluated incorrectly when encountering relops and indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115536 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/115536] Expression is evaluated incorrectly when encountering relops and indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115536 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:9f168b412f44781013401492acfedf22afe7741b commit r15-1618-g9f168b412f44781013401492acfedf22afe7741b Author: Gaius Mulley Date: Tue Jun 25 18:35:22 2024 +0100 PR modula2/115536 Expression is evaluated incorrectly when encountering relops and indirection This fix ensures that we only call BuildRelOpFromBoolean if we are inside a constant expression (where no indirection can be used). The fix creates a temporary variable when a boolean is created from a relop in other cases. The previous pattern implementation would not work if the operands required dereferencing during non const expressions. Comparison of relop results in a constant expression are resolved by constant propagation, basic block analysis and dead code removal. After the quadruples have been optimized only one assignment to the boolean variable will remain for const expressions. All quadruple pattern checking for boolean expressions is removed by the patch. Thus the implementation becomes more generic. gcc/m2/ChangeLog: PR modula2/115536 * gm2-compiler/M2BasicBlock.def (GetBasicBlockScope): New procedure. (GetBasicBlockStart): Ditto. (GetBasicBlockEnd): Ditto. (IsBasicBlockFirst): New procedure function. * gm2-compiler/M2BasicBlock.mod (ConvertQuads2BasicBlock): Allow conditional boolean quads to be removed. (GetBasicBlockScope): Implement new procedure. (GetBasicBlockStart): Ditto. (GetBasicBlockEnd): Ditto. (IsBasicBlockFirst): Implement new procedure function. * gm2-compiler/M2GCCDeclare.def (FoldConstants): New parameter declaration. * gm2-compiler/M2GCCDeclare.mod (FoldConstants): New parameter declaration. (DeclareTypesConstantsProceduresInRange): Recreate basic blocks after resolving constant expressions. (CodeBecomes): Guard IsVariableSSA with IsVar. * gm2-compiler/M2GenGCC.def (ResolveConstantExpressions): New parameter declaration. * gm2-compiler/M2GenGCC.mod (FoldIfLess): Remove relop pattern detection. (FoldIfGre): Ditto. (FoldIfLessEqu): Ditto. (FoldIfGreEqu): Ditto. (FoldIfIn): Ditto. (FoldIfNotIn): Ditto. (FoldIfEqu): Ditto. (FoldIfNotEqu): Ditto. (FoldBecomes): Add BasicBlock parameter and allow conditional boolean becomes to be folded in the first basic block. (ResolveConstantExpressions): Reimplement. * gm2-compiler/M2Quads.def (IsConstQuad): New procedure function. (IsConditionalBooleanQuad): Ditto. * gm2-compiler/M2Quads.mod (IsConstQuad): Implement new procedure function. (IsConditionalBooleanQuad): Ditto. (MoveWithMode): Use GenQuadOTypetok. (IsInitialisingConst): Rewrite using OpUsesOp1. (OpUsesOp1): New procedure function. (doBuildAssignment): Mark des as a VarConditional. (ConvertBooleanToVariable): Call PutVarConditional. (DumpQuadSummary): New procedure. (BuildRelOpFromBoolean): Updated debugging and improved comments. (BuildRelOp): Only call BuildRelOpFromBoolean if we are in a const expression and both operands are boolean relops. (GenQuadOTypeUniquetok): New procedure. (BackPatch): Correct comment. * gm2-compiler/SymbolTable.def (PutVarConditional): New procedure. (IsVarConditional): New procedure function. * gm2-compiler/SymbolTable.mod (PutVarConditional): Implement new procedure. (IsVarConditional): Implement new procedure function. (SymConstVar): New field IsConditional. (SymVar): New field IsConditional. (MakeVar): Initialize IsConditional field. (MakeConstVar): Initialize IsConditional field. * gm2-compiler/M2Swig.mod (DoBasicBlock): Change parameters to use BasicBlock. * gm2-compiler/M2Code.mod (SecondDeclareAndOptimize): Use iterator to FoldConstants over basic block list. * gm2-compiler/M2SymInit.mod (AppendEntry): Replace parameters with BasicBlock. * gm2-compiler/P3Build.bnf (Relation): Call RecordOp for #, <> and =. gcc/testsuite/ChangeLog: PR modula2/115536 * gm2/iso/const/pass/constbool4.mod: New test. * gm2/iso/const/pass/constbool5.mod: New test. * gm2/iso/run/pass/condtest2.mod: New test. * gm2/iso/run/pass/condtest3.mod: New test. *
[Bug c/115644] [gcc][trunk] ICE if redeclare a variable with different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115644 --- Comment #2 from Andrew Pinski --- (In reply to wierton from comment #1) > This crash seems to be the same cause: https://gcc.godbolt.org/z/6br3xoaKG Related in the sense redeclaring the variable with a different type changes the the underlying type of the decl to error_mark_node which the rest of the compiler is not always ready to handle. (there a few other bug reports which was caused by the same thing too).
[Bug c++/115198] Class template argument deduction fails for copy ctor when used with an alias template if the aliased class template has explicitly defaulted copy ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115198 --- Comment #5 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:06ebb7c6f31fe42ffdea6f51ac1ba1f6b058c090 commit r15-1615-g06ebb7c6f31fe42ffdea6f51ac1ba1f6b058c090 Author: Patrick Palka Date: Tue Jun 25 12:59:24 2024 -0400 c++: alias CTAD and copy deduction guide [PR115198] Here we're neglecting to update DECL_NAME during the alias CTAD guide transformation, which causes copy_guide_p to return false for the transformed copy deduction guide since DECL_NAME is still __dguide_C with TREE_TYPE C but it should be __dguide_A with TREE_TYPE A (i.e. C). This ultimately results in ambiguity during overload resolution between the copy deduction guide vs copy ctor guide. This patch makes us update DECL_NAME of a transformed guide accordingly during alias/inherited CTAD. PR c++/115198 gcc/cp/ChangeLog: * pt.cc (alias_ctad_tweaks): Update DECL_NAME of the transformed guides. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias22.C: New test. Reviewed-by: Jason Merrill
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #14 from Jan Hubicka --- As for bit of history on this. I have introduced the split -O2 and -O3 limits in order to be able to enable -finline-small-functions at -O2 which we found to be really importnat for C++ codebases which no longer care about explicit use of inline keyword much. To do that it was necessary to find settings that does not grow -O2 binaries significantly (or reduce it) and yields to measurably better performance. Without LTO and SPECCPU the differences were quite small. With LTO it was more noticeable and with firefox/clang and similar with LTO they were significant (often double-digit). Pushing up -O2 limits can make sense, but needs to be done carefully - in longer term IMO we do not want to let -O2 binaries to grow faster than their perofrmance. Sadly this figure is not that great. https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branchhttps://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch loads slowly but has some data. SPEC2k17 with -O2 -flto on 2nd generation zen performs as follows: gcc-7 gcc-8 gcc-9 gcc-10 gcc-11 gcc-12 gcc-13 gcc-14 gcc-trunk SPECint 2.55% 2.90% ~ 4.55% 4.47% 11.29% 12.60% 14.13% 13.42% SPECfp ~~ ~ ~ ~ 4.15% 4.98% 5.30% 5.18% Those are scores (bigger is better) compared to gcc-6 in percents. ~ is noise. Large improvement in gcc-12 is enablement of vectorizer for specint comes primarily from x264 While text section size: gcc-7 gcc-8 gcc-9 gcc-10 gcc-11 gcc-12 gcc-13 gcc-14 gcc-trunk int ~ ~ ~ 9.77% 9.57% 8.72% 8.26% 10.68% 10.59% fp ~ 2.40% ~ 18.30% 18.24% 18.92% 18.66% 22.23% 22.27% Those are sizes (smaller is better). So we do get coniderable bloat. In GCC10 Fortran ABI changed and imporant part of FP 18% FP bloat is caused by it. Here are individual changes: runtime (only benchmarks with off-noise changes): Test Name gcc-7 gcc-8 gcc-9 gcc-10 gcc-11 gcc-12 gcc-13 gcc-14 gcc-trunk FP/538.imagick 25.01% 25.64% 27.57% 21.51% 21.75% 19.46% 19.88% 23.20% 22.91% INT/525.x264_r 7.25% 6.20% 6.58% 7.48% ~ -37.7% -40.4% -41.6% -39.90% INT/548.exchan -17.9% -17.8% -14.9% -14.1% -5.88% -13.9% -21.6% -25.0% -26.48% INT/531.deepsj -2.46% ~ ~ -15.0% -16.1% -17.9% -18.8% -19.3% -19.62% FP/503.bwaves_ -6.30% ~ -2.71% 16.95% 16.71% 16.65% 16.94% 16.94% 16.70% FP/527.cam4_r -2.99% -2.33% -10.7% -11.3% -10.9% -11.8% -11.9% -12.5% -11.37% FP/521.wrf_r~ -2.40% -5.99% -6.10% -5.66% -9.45% -9.28% -9.82% -9.95% FP/554.roms_r ~ 5.79% 2.51% ~ 5.24% 7.95% 9.35% 9.11% 9.68% INT/520.omnetp -3.26% -3.45% ~ -3.82% -6.71% -7.37% -6.57% -6.83% -5.62% FP/549.fotonik ~ ~ -5.60% -8.26% -8.61% -3.80% -4.82% -3.26% -5.48% INT/541.leela_ -2.47% -2.19% ~ -4.57% -6.32% -4.76% -5.69% -6.72% -5.88% INT/500.perlbe ~ -2.11% -2.34% -6.03% -4.51% ~ ~ -5.01% -4.52% INT/523.xalanc -2.42% -3.18% -2.26% -3.75% -2.31% -5.95% -2.02% -3.52% ~ FP/511.povray_ ~ ~ 5.21% -6.54% ~ ~ ~ ~ ~ INT/505.mcf_r ~ ~ ~ ~ ~ -2.82% -3.32% -3.71% -4.14% FP/510.parest_ ~ ~ ~ ~ -3.31% ~ -2.28% -3.03% -3.39% FP/519.lbm_r3.33% ~ ~ -4.72% ~ ~ ~ ~ ~ FP/544.nab_r~ ~ ~ ~ ~ ~ -2.43% ~ -3.15% FP/508.namd_r ~ ~ ~ ~ 4.20% ~ ~ -2.35% -2.02% Those are times (smaller is better) - Imagemagick regression since GCC 7 is store-to-load forwarding where we vectorize load in one function of value stored by pieces in another. - x264 improvement in GCC 12 is vectorization at -O2 (which may be argued to help primarily code that should be built with -Ofast/-O3 anyway) - exchange improvement in GCC 7 is special handling of self recursive functions with nested loops (quite specific to the benchmark) - forgot what caused changes in deepsjeng in GCC10 and cam4 in GCC9 size GCC 6 size gcc-7 gcc-8 gcc-9 gcc-10 gcc-11 gcc-12 gcc-13 gcc-14 gcc-trunk FP/521.wrf_rg 11.85 MB~ 5.78% 4.43% 33.11% 33.11% 34.41% 34.41% 38.42% 38.41% INT/557.xz_rg 75.53 KB~ ~ ~ 30.10% 29.47% 29.18% 30.30% 33.28% 33.57% FP/totalg 28.08 MB~ 2.40% ~ 18.30% 18.24% 18.92% 18.66% 22.23% 22.27% INT/523.xalanc 1.98 MB ~ ~ 15.05% 14.85% 14.54% 13.62% 13.80% 17.31% 17.07% FP/526.blender 6.21 MB ~ ~ -2.50% 15.93% 15.97% 15.70% 14.08% 18.47% 18.40% INT/541.leela 74.37 KB~ ~ 13.36% -8.84% -8.54% -15.7%
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #13 from Rama Malladi --- (In reply to Jan Hubicka from comment #12) > If this is without LTO, can you also try the LTO numbers? > Inliner behaves sifniciantly different with and without LTO, since LTO > introduces many (and often too many) inlining oppurtunities, which > sometimes makes things to out of hand. > > Overal SPEC2k17 without LTO is not the most representative inlining > benchmark, since most programs there are relatively old and written with > small abstraction penalty. The numbers listed above in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531#c11 are with LTO. Here are the base flags used for these runs: `O2 -march=armv8-a+crc+crypto -mtune=native -flto` + inlining params: `--param=early-inlining-insns=14 --param=inline-heuristics-hint-percent=600 --param=inline-min-speedup=15 --param=max-inline-insns-auto=30 --param=max-inline-insns-single=200`
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #12 from Jan Hubicka --- If this is without LTO, can you also try the LTO numbers? Inliner behaves sifniciantly different with and without LTO, since LTO introduces many (and often too many) inlining oppurtunities, which sometimes makes things to out of hand. Overal SPEC2k17 without LTO is not the most representative inlining benchmark, since most programs there are relatively old and written with small abstraction penalty.
[Bug target/109989] [13 Regression] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats caused by r13-2105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989 Andrew Pinski changed: What|Removed |Added Known to work||12.1.0, 14.1.0 Known to fail||13.1.0 Summary|[13 Regression] RISC-V: |[13 Regression] RISC-V: |Missing sign extension with |Missing sign extension with |int to float conversion |int to float conversion |with 64bit soft floats |with 64bit soft floats ||caused by r13-2105 --- Comment #8 from Andrew Pinski --- Was fixed for GCC 14 by r14-5060-g7560f2b4e387ef .
[Bug target/109989] [11/12/13 only] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.4 Summary|RISC-V: Missing sign|[11/12/13 only] RISC-V: |extension with int to float |Missing sign extension with |conversion with 64bit soft |int to float conversion |floats |with 64bit soft floats
[Bug target/109989] RISC-V: Missing sign extension with int to float conversion with 64bit soft floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989
--- Comment #7 from Pash Osh ---
Fix is found in gcc14:
git cherry-pick 7560f2b4e387ef43ef45ee9fb06efbad6ca0fedf
Author: Vineet Gupta
Date: Wed Nov 1 14:46:33 2023 -0700
RISC-V: fix TARGET_PROMOTE_FUNCTION_MODE hook for libcalls
Fixes: 3496ca4e6566 ("RISC-V: Add runtime invariant support")
How to commit it to all gcc-13.1,... releases/gcc-13 ?
Where manual? What about cheery-pick?
[Bug middle-end/115574] [OpenMP] Nested C function – 'declare target link(var)' leads to "referenced in offloaded code but hasn't been marked to be included in the offloaded code"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115574 --- Comment #2 from Tobias Burnus --- > #pragma declare target link(a,b) as Thomas pointed out (cf. comment 1), an 'omp' is missing. It also lacks, e.g. '#pragma omp target enter data map(a, b)' to be valid. Still, the real issue is '!is_global_var (t)' which is only valid if there is no nested function which is 'declare target', as that can access the static variable through the backdoor.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #11 from Rama Malladi --- (In reply to Wilco from comment #10) > A 1.1% overall performance gain looks good - is there a significant codesize > hit from this? If so, are there slightly less aggressive settings that still > get most of the performance gains but at a lower (acceptable) codesize cost? > It seems there may be scope to improve the default settings of -O2. Here is a code size comparison of O2 vs. O2 + inline params for SPEC cpu2017 Int Rate benchmarks. One of the concerns for not modifying the default inline parameters at -O2 is loss of some function observability due to aggressive inline optimizations. Benchmark "-O2" "-O2 + inline size params"increase 500.perlbench_r 8.5M11M 1.29 502.gcc_r 51M 56M 1.10 505.mcf_r 102K106K1.04 520.omnetpp_r 22M 23M 1.05 523.xalancbmk_r 52M 53M 1.02 525.x264_r 2.5M2.8M1.12 531.deepsjeng_r 416K441K1.06 541.leela_r 2.6M2.6M1.00 548.exchange2_r 115K115K1.00 557.xz_r818K871K1.06 999.specrand_ir 24K 24K 1.00
[Bug c++/115645] [11/12/13/14/15 Regression] new S[1][1]() requires non-explicit default ctor since r11-3092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115645 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-06-25 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/115574] [OpenMP] Nested C function – 'declare target link(var)' leads to "referenced in offloaded code but hasn't been marked to be included in the offloaded code"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115574 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #1 from Thomas Schwinge --- (Just noting that fixing the code à la '-Wunknown-pragmas' doesn't seem to make a difference re the 'error' diagnostics.)
[Bug c++/115358] [13/14/15 Regression] template argument deduction/substitution failed in generic lambda function use of static constexpr array type whos initializer defines the size since r13-2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358 --- Comment #8 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e3915c1ad56591cbd68229a64c941c38330abd69 commit r15-1614-ge3915c1ad56591cbd68229a64c941c38330abd69 Author: Patrick Palka Date: Tue Jun 25 10:42:21 2024 -0400 c++: using non-dep array var of unknown bound [PR115358] For a non-dependent array variable of unknown bound, it seems we need to try instantiating its definition upon use in a template context for sake of proper checking and typing of the overall expression, like we do for function specializations with deduced return type. PR c++/115358 gcc/cp/ChangeLog: * decl2.cc (mark_used): Call maybe_instantiate_decl for an array variable with unknown bound. * semantics.cc (finish_decltype_type): Remove now redundant handling of array variables with unknown bound. * typeck.cc (cxx_sizeof_expr): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/array37.C: New test. Reviewed-by: Jason Merrill
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest since r14-3489-g143151ac2013c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from sandra at gcc dot gnu.org --- Patch pushed to the mainline as obvious. I'll backport to the GCC 14 branch as well since this was tagged as a regression on that branch.
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest since r14-3489-g143151ac2013c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 --- Comment #3 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:21f1073d388af8af207183b0ed592e1cc47d20ab commit r15-1613-g21f1073d388af8af207183b0ed592e1cc47d20ab Author: Sandra Loosemore Date: Tue Jun 25 13:54:43 2024 + Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest This function had a reference to an uninitialized variable on the error path. The problem was diagnosed by clang but not gcc. It seems the cleanest solution is to initialize all the loop-clause variables at the point of declaration rather than at different places in the code. The C++ front end didn't have this problem, but I've made similar changes there to keep the code in sync. gcc/c/ChangeLog: PR c/115587 * c-parser.cc (c_parser_omp_loop_nest): Move initializations to point of declaration. gcc/cp/ChangeLog: PR c/115587 * parser.cc (cp_parser_omp_loop_nest): Move initializations to point of declaration.
[Bug target/115648] New: [15 Regression] GCN: [-PASS:-]{+FAIL:+} gcc.dg/hoist-register-pressure-{2, 3}.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115648
Bug ID: 115648
Summary: [15 Regression] GCN: [-PASS:-]{+FAIL:+}
gcc.dg/hoist-register-pressure-{2,3}.c scan-rtl-dump
hoist "PRE/HOIST: end of bb .* copying expression"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, guihaoc at gcc dot gnu.org
Target Milestone: ---
Yesterday's commit r15-1575-gea8061f46a301797e7ba33b52e3b4713fb8e6b48 "fwprop:
invoke change_is_worthwhile to judge if a replacement is worthwhile" regresses
GCN target (tested '-march=gfx908'):
PASS: gcc.dg/hoist-register-pressure-1.c (test for excess errors)
PASS: gcc.dg/hoist-register-pressure-2.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/hoist-register-pressure-2.c scan-rtl-dump hoist
"PRE/HOIST: end of bb .* copying expression"
PASS: gcc.dg/hoist-register-pressure-3.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/hoist-register-pressure-3.c scan-rtl-dump hoist
"PRE/HOIST: end of bb .* copying expression"
There is moderate code generation difference; I can't tell whether before vs.
after is better. Does the compiler or the test cases or the compiler flags
need to be adjusted? Re the latter, with '-fno-forward-propagate', we're back
to PASSing.
[Bug c++/115645] [11/12/13/14/15 Regression] new S[1][1]() requires non-explicit default ctor since r11-3092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115645 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.5
[Bug c/115646] [gcc][trunk] ICE in gen_conditions_for_pow_int_base, at tree-call-cdce.cc:587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115646 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-06-25 Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug target/115631] [15 Regression] GCN: [-PASS:-]{+FAIL:+} c-c++-common/torture/builtin-arith-overflow-6.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115631 --- Comment #4 from Richard Sandiford --- Created attachment 58513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58513=edit A patch for a bug seen on arm*-*-* Also, could you check whether the attached patch makes any difference? It fixes a problem seen on arm*-*-*, and I notice GCN also defines cannot_copy_insn_p.
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ())))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
--- Comment #1 from David Malcolm ---
"make selftest-valgrind" is clean for me. Note that if you can reproducer this
standalone, "make selftest-gdb" is a handy way to run the selftests under the
debugger.
FWIW, the output suggests that the assertion at line 1153 is failing:
1147 /* Verify that empty paths are handled gracefully. */
1148
1149 static void
1150 test_empty_path (pretty_printer *event_pp)
1151 {
1152test_diagnostic_path path (event_pp);
->1153ASSERT_FALSE (path.interprocedural_p ());
1154
"path" is empty i.e. num_events ought to be returning 0.
Hence I'd expect diagnostic_path::interprocedural_p:
184 bool
185 diagnostic_path::interprocedural_p () const
186 {
187/* Ignore leading events that are outside of any function. */
188unsigned first_fn_event_idx;
189if (!get_first_event_in_a_function (_fn_event_idx))
190 return false;
to call get_first_event_in_a_function, and for that to get 0 for "num", and
thus bail out with num == 0 again, never entering the loop here:
164 bool
165 diagnostic_path::get_first_event_in_a_function (unsigned *out_idx)
const
166 {
167const unsigned num = num_events ();
168for (unsigned i = 0; i < num; i++)
169 {
170const diagnostic_event = get_event (i);
171if (const logical_location *logical_loc =
event.get_logical_location ())
172 if (logical_loc->function_p ())
173{
174 *out_idx = i;
175 return true;
176}
177 }
178return false;
179 }
thus returning false to the callsite at line 189, and thus having
diagnostic_path::interprocedural_p return false at line 190:
189if (!get_first_event_in_a_function (_fn_event_idx))
190 return false;
So I'm not sure what's happening here (or maybe I'm missing something silly?)
[Bug tree-optimization/114324] [13/14/15 Regression] AVX2 vectorisation performance regression with gfortran 13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324 --- Comment #8 from mjr19 at cam dot ac.uk --- Ooops -- timings not ns/iteration as claimed, nor even comparable between the m3spf and m4spf examples, but they are consistent within each example.
[Bug analyzer/115647] No warning when a loop is infinite due to type of operand in conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115647 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #0) > In the below `for` statement, the `char` counter `i` has a smaller range > than the value of the `int` condition `n` (in this case 500) hence it will > overflow and wrap around when incremented beyond its max range value (in > this case 127) before reaching that value, resulting in an infinite loop. Note '127' assumes signed char by default, whereas on some targets the max range value is 255. But when comparing against 500 it doesn't affect the logic.
[Bug tree-optimization/114324] [13/14/15 Regression] AVX2 vectorisation performance regression with gfortran 13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324 --- Comment #7 from mjr19 at cam dot ac.uk --- The patch to GCC 15 in commit r15-1508-g59221dc587f369695d9b0c2f73aedf8458931f0f from pr 68855 has made a significant improvement to the optimisation of these examples at -O3, causing the -Ofast version now to be slower than the -O3 version for both of the attachments. For the two examples given, rough timings in ns/iteration on a 3GHz Kaby Lake are m3spf gf-12 -Ofast 26.5 gf-15 -O3 27.6 gf-14 -Ofast 34.8 gf-15 -Ofast 35.1 gf-14 -O3 43.8 gf-12 -O3 44.8 m4spf gf-12 -Ofast 23.3 gf-15 -O3 23.8 gf-14 -Ofast 29.6 gf-15 -Ofast 29.7 gf-14 -O3 37.3 gf-12 -O3 37.6 All with the flag -mavx2, and in both cases the fastest time is very similar to ifort -O3. gf-15 is gfortran 15.0-20240623 (I believe there is interest in the optimisation of these expressions. I am an electronic structure physicist, and the major simulation codes in my area, Abinit, CASTEP, QE, Siesta, VASP, are all written in Fortran, all use the complex datatype, are likely to make use of conjugation and also multiplication by +/-i, and use large amounts of time on academic supercomputers. The ability to alternate neg and nop efficiently along a vector would be very useful if it dealt with conjg and *(+/-i), and the obvious xor seems quite safe.)
[Bug analyzer/115647] No warning when a loop is infinite due to type of operand in conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115647
--- Comment #2 from David Malcolm ---
Without optimization
https://godbolt.org/z/15v7zMMo5
the analyzer "sees" this gimple IR:
int main ()
{
const int n;
char i;
int D.3184;
int _1;
unsigned char i.0_2;
unsigned char _3;
int _4;
int _10;
:
n_7 = 500;
i_8 = 0;
goto ; [INV]
:
_1 = (int) i_5;
printf ("%d\n", _1);
i.0_2 = (unsigned char) i_5;
_3 = i.0_2 + 1;
i_12 = (char) _3;
:
# i_5 = PHI
_4 = (int) i_5;
if (n_7 > _4)
goto ; [INV]
else
goto ; [INV]
:
_10 = 0;
:
:
return _10;
}
The analyzer could probably figure out from:
char i;
[...snip...]
n_7 = 500;
[...snip...]
_4 = (int) i_5;
if (n_7 > _4)
that the conditional is:
if (500 > (int)(char)X)
and thus always true.
But maybe this would be better placed elsewhere?
[Bug analyzer/115647] No warning when a loop is infinite due to type of operand in conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115647
--- Comment #1 from David Malcolm ---
There's no warning from the analyzer below -O1:
https://godbolt.org/z/34js3xT8G
but there is at -O1 and above:
https://godbolt.org/z/5z9x1vP6G
which reports:
: In function 'main':
:10:5: warning: infinite loop [CWE-835] [-Wanalyzer-infinite-loop]
10 | printf ("%d\n", i);
| ^~
'main': event 1
10 | printf ("%d\n", i);
| ^~
| |
| (1) ⚠️ infinite loop here
'main': event 2
cc1:
(2): looping back...
'main': event 3
10 | printf ("%d\n", i);
| ^~
| |
|└───>(3) ...to here
This was surprising to me, as -Wanalyzer is meant to not report on infinite
loops with side-effects, and printf ought to be a side-effect.
That said, we probably ought to warn for the conditional 'i < n' given that it
will always be true given the value of n and the type of i. Such a warning
might be better implemented in the frontends; not sure.
