[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #1 from Kewen Lin ---
The related insns requires TARGET_POWERPC64, they are still available on 32bit
if the option -O2 -mpowerpc64 comes after -m32.
I think it suffers the issue as its comments:
/* On some versions of dejagnu this test will fail when biarch testing
with RUNTESTFLAGS="--target_board=unix'{-m64,-m32}'" due to -m32
being added on the command line after the dg-options -mpowerpc64.
common/config/rs6000/rs6000-common.c:rs6000_handle_option disables
-mpowerpc64 for -m32. */
Hi Mike,
Could you share which test box you used for testing? Or dejagnu version?
[Bug tree-optimization/105651] [12/13 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651 --- Comment #18 from Jason Merrill --- (In reply to Jason Merrill from comment #17) > There's probably a way to help the optimizer out without the > __builtin_unreachable hammer, as for 98465; suggestions are welcome. ..like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336#c1
[Bug tree-optimization/105651] [12/13 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #17 from Jason Merrill --- Created attachment 53474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53474=edit patch to work around the issue in the library This patch tells the optimizer that the copy can't overlap, since it is having trouble figuring that out on its own. This fixes the false positive. It theoretically could deduce this from the previous two conditions: the first establishes that the end of the source is after the end of the destination; the second establishes that the beginning of the source is before the end of the destination. So the source crosses the end of the destination, and so the length of the overlap is less than the length of the source. There's probably a way to help the optimizer out without the __builtin_unreachable hammer, as for 98465; suggestions are welcome. Turning off -Wrestrict just around the call to _M_copy also works, but this patch should also improve optimization.
[Bug testsuite/106516] New test case gcc.dg/pr104992.c fails on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516 Kewen Lin changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #3 from Kewen Lin --- *** Bug 106681 has been marked as a duplicate of this bug. ***
[Bug testsuite/106681] Powerpc test gcc.dg/pr104992.c fails on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106681 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Kewen Lin --- Dup. *** This bug has been marked as a duplicate of bug 106516 ***
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 --- Comment #9 from Kewen Lin --- (In reply to Michael Meissner from comment #8) > Note, the gcc.target/powerpc/pr92398.p9-.c test fails when the compiler is > configured for either --with-cpu=power9 or --with-cpu=power10. No > --with-tune= was used in configuring either compiler. Yeah, as comment #1, it's a different issue from the --with-tune issue, it's due to empty TU in effective target checks. The patch was posted at: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html
[Bug analyzer/106181] [13 Regression] ICE in capacity_compatible_with_type, at analyzer/region-model.cc:2909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106181 Tim Lange changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Tim Lange --- (In reply to David Malcolm from comment #4) > Tim: is this fixed by the above commit? Yes, marking as fixed.
[Bug analyzer/106181] [13 Regression] ICE in capacity_compatible_with_type, at analyzer/region-model.cc:2909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106181 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Tim: is this fixed by the above commit?
[Bug c++/106646] [C++23] P2437R1 - Support for #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646 --- Comment #1 from Joseph S. Myers --- Enabled for C2x (i.e. stopped -pedantic diagnosing it) with commit d7c3000147c1d8090f66a2baf4623d2c0dfe8eb6 - C++ will presumably want to adjust the diagnostics as well as enabling for relevant C++ versions and adding associated tests.
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #8 from Michael Meissner --- Note, the gcc.target/powerpc/pr92398.p9-.c test fails when the compiler is configured for either --with-cpu=power9 or --with-cpu=power10. No --with-tune= was used in configuring either compiler.
[Bug target/106682] New: Powerpc test gcc.target/powerpc/pr86731-fwrapv-longlong.c fails on power8, passes on power9/power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682 Bug ID: 106682 Summary: Powerpc test gcc.target/powerpc/pr86731-fwrapv-longlong.c fails on power8, passes on power9/power10 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I was doing builds on a power10 for patch submission, and I noticed the test pr86731-fwrapv-longlong.c fails when the target is power8, but it passes when the target is power9 or power10. Here is the log file from power8: Executing on host: /home/meissner/fsf-build-ppc64le/work098-power8/gcc/xgcc -B/home/meissner/fsf-build-ppc64le/work098-power8/gcc/ /home/meissner/fsf-src/work098/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c -fdiagnostics-plain-output -maltivec -O3 -fwrapv -mpower8-vector -ffat-lto-objects -fno-ident -S -o pr86731-fwrapv-longlong.s(timeout = 300) spawn -ignore SIGHUP /home/meissner/fsf-build-ppc64le/work098-power8/gcc/xgcc -B/home/meissner/fsf-build-ppc64le/work098-power8/gcc/ /home/meissner/fsf-src/work098/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c -fdiagnostics-plain-output -maltivec -O3 -fwrapv -mpower8-vector -ffat-lto-objects -fno-ident -S -o pr86731-fwrapv-longlong.s PASS: gcc.target/powerpc/pr86731-fwrapv-longlong.c (test for excess errors) PASS: gcc.target/powerpc/pr86731-fwrapv-longlong.c scan-assembler-times \\mvspltis[bhw]\\M 0 PASS: gcc.target/powerpc/pr86731-fwrapv-longlong.c scan-assembler-times \\mvsl[bhwd]\\M 0 gcc.target/powerpc/pr86731-fwrapv-longlong.c: \\mp?lxv\\M|\\mlxv\\M|\\mlxvd2x\\M|\\mxxspltidp\\M found 0 times
[Bug testsuite/106681] New: Powerpc test gcc.dg/pr104992.c fails on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106681 Bug ID: 106681 Summary: Powerpc test gcc.dg/pr104992.c fails on power10 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I was doing builds on a power10 system for patch submission, and I noticed the following test fails when the test is compiled for power10, but it does not fail when the test is compiled for power8 or power9: gcc.dg/pr104992.c: Executing on host: /home/meissner/fsf-build-ppc64le/work098-if/gcc/xgcc -B/home/meissner/fsf-build-ppc64le/work098-if/gcc/ /home/meissner/fsf-src/work098/gcc/testsuite/gcc.dg/pr104992.c -fdiagnostics-plain-output -O2 -Wno-psabi -fdump-tree-optimized -S -o pr104992.s(timeout = 300) spawn -ignore SIGHUP /home/meissner/fsf-build-ppc64le/work098-if/gcc/xgcc -B/home/meissner/fsf-build-ppc64le/work098-if/gcc/ /home/meissner/fsf-src/work098/gcc/testsuite/gcc.dg/pr104992.c -fdiagnostics-plain-output -O2 -Wno-psabi -fdump-tree-optimized -S -o pr104992.s PASS: gcc.dg/pr104992.c (test for excess errors) gcc.dg/pr104992.c: pattern found 6 times FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9
[Bug testsuite/106680] New: Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680 Bug ID: 106680 Summary: Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- I was doing some builds for submitting patches, and I did runs on BE systems as well as LE systems. I noticed the test gcc.target/powerpc/bswap64-4.c fails in 32-bit, because it does not generate ldbrx or stdbrx instructions. These instructions are not supported on 32-bit. So the test has to be adjusted to either only be run on a 64-bit system, or adjust the insns generated when the test is run on a 32-bit target.
[Bug testsuite/101169] [10 regression] test case gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r10-9880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169 Michael Meissner changed: What|Removed |Added Ever confirmed|0 |1 CC||meissner at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-18 --- Comment #3 from Michael Meissner --- The fold-vec-extract tests work fine on the development version of GCC 13 for 64-bit, but they are still failing if I run them on a BE system that supports 32-bit code generation. It looks like the insn count may need to be adjusted for 32-bit: FAIL: gcc.target/powerpc/fold-vec-extract-int.p8.c scan-assembler-times \\maddi\\M 9 FAIL: gcc.target/powerpc/fold-vec-extract-short.p7.c scan-assembler-times \\maddi\\M|\\madd\\M 12 FAIL: gcc.target/powerpc/fold-vec-extract-short.p8.c scan-assembler-times \\maddi\\M 9 FAIL: gcc.target/powerpc/fold-vec-extract-char.p7.c scan-assembler-times \\maddi\\M 9 FAIL: gcc.target/powerpc/fold-vec-extract-double.p7.c scan-assembler-times \\maddi\\M|\\madd\\M 3 FAIL: gcc.target/powerpc/fold-vec-extract-float.p7.c scan-assembler-times \\maddi\\M|\\madd\\M 3 FAIL: gcc.target/powerpc/fold-vec-extract-float.p8.c scan-assembler-times \\maddi\\M 2 FAIL: gcc.target/powerpc/fold-vec-extract-int.p7.c scan-assembler-times \\maddi\\M|\\madd\\M 12
[Bug c++/103876] Parameter pack not expanded in lambda within static_assert in a fold-expression of a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103876
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment #2 from S. Davis Herring ---
Probably the same bug from a simpler (and C++17-compatible) case:
template
void f(const TT &...tt) {
[tt...]() {
([tt] {},...);
}();
}
:4:13: error: parameter packs not expanded with '...':
4 | ([tt] {},...);
| ^
:4:13: note: 'tt'
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 Andrew Pinski changed: What|Removed |Added Target|powerpc64-linux-gnu,| |powerpc64le-linux-gnu | Host|powerpc64-linux-gnu,| |powerpc64le-linux-gnu | Last reconfirmed||2022-08-18 Build|powerpc64-linux-gnu,| |powerpc64le-linux-gnu | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Looks like it also fails on x86_64-linux-gnu: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599920.html
[Bug tree-optimization/106679] [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug other/106679] New: [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679 Bug ID: 106679 Summary: [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after r13-2098-g5adfb6540db95d Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:5adfb6540db95da5faf1f77fbe9ec38b4cf8eb1f, r13-2098-g5adfb6540db95d make -k check-gcc RUNTESTFLAGS="tree-prof.exp=gcc.dg/tree-prof/cmpsf-1.c" FAIL: gcc.dg/tree-prof/cmpsf-1.c scan-tree-dump-not dom2 "Invalid sum" # of expected passes4 # of unexpected failures1 # of unsupported tests 1 commit 5adfb6540db95da5faf1f77fbe9ec38b4cf8eb1f (HEAD, refs/bisect/bad) Author: Aldy Hernandez Date: Wed Aug 17 17:47:21 2022 +0200 Reset root oracle from path_oracle::reset_path.
[Bug rtl-optimization/81501] mulitple calls to __tls_get_addr() with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 --- Comment #8 from H.J. Lu --- Created attachment 53473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53473=edit A patch This patch uses a single UNSPEC_TLS_LD_BASE in the whole function.
[Bug target/106609] [12/13 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 Andrew Pinski changed: What|Removed |Added Summary|sh3eb-elf cross compiler is |[12/13 Regression] |being miscompiled |sh3eb-elf cross compiler is ||being miscompiled since ||r12-1525-g3155d51bfd1de8b6c ||4645 Target Milestone|--- |12.2 Component|middle-end |target Severity|normal |blocker See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=46235
[Bug middle-end/106609] sh3eb-elf cross compiler is being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #9 from Mikael Pettersson --- # first bad commit: [3155d51bfd1de8b6c4645dcb2292248a8d7cc3c9] [PATCH] PR rtl-optimization/46235: Improved use of bt for bit tests on x86_64. Starting with this commit, the host compiler (on x86_64-linux) miscompiles the gcc-13 based cross-compiler to sh3eb-elf.
[Bug target/106678] Inefficiency in long integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106678 --- Comment #1 from Andrew Pinski --- The inner loop for aarch64 on the trunk is: .L5: ldr x7, [x20, x5, lsl 3] ldr x10, [x21, x12, lsl 3] ldr x6, [x11, x5, lsl 3] mul x2, x7, x10 umulh x7, x7, x10 addsx2, x2, x8 cincx8, x7, cs addsx2, x2, x6 csetx7, cs addsx2, x2, x9 add x6, x6, x2 str x6, [x11, x5, lsl 3] add x5, x5, 1 cincx9, x7, cs cmp x19, x5 bne .L5 So I suspect this is still a target issue.
[Bug rtl-optimization/106678] New: Inefficiency in long integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106678
Bug ID: 106678
Summary: Inefficiency in long integer multiplication
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code from PR 103109
#include
void Long_multiplication( uint64_t multiplicand[],
uint64_t multiplier[],
uint64_t sum[],
uint64_t ilength, uint64_t jlength )
{
uint64_t acarry, mcarry, product;
for( uint64_t i = 0;
i < (ilength + jlength);
i++ )
sum[i] = 0;
acarry = 0;
for( uint64_t j = 0; j < jlength; j++ )
{
mcarry = 0;
for( uint64_t i = 0; i < ilength; i++ )
{
__uint128_t mcarry_prod;
__uint128_t acarry_sum;
mcarry_prod = ((__uint128_t) multiplicand[i]) * ((__uint128_t)
multiplier[j])
+ (__uint128_t) mcarry;
mcarry = mcarry_prod >> 64;
product = mcarry_prod;
acarry_sum = ((__uint128_t) sum[i+j]) + ((__uint128_t) acarry) +
product;
sum[i+j] += acarry_sum;
acarry = acarry_sum >> 64;
// {mcarry, product} = multiplicand[i]*multiplier[j]
//+ mcarry;
// {acarry,sum[i+j]} = {sum[i+j]+acarry} + product;
}
}
}
still shows some inefficiency after r13-2107.
Compiling the function with gcc 13.0.0 20220818, with
$ gcc -mcpu=power9 -O3 -c loop.c
and disassembling the output (for easier reading) gives (looking only
at the main part)
7c: 00 00 80 38 li r4,0
80: 00 00 80 3b li r28,0
84: 00 00 60 38 li r3,0
88: 00 00 00 38 li r0,0
8c: ff ff c0 38 li r6,-1
90: 00 00 e0 38 li r7,0
94: 20 00 c1 fa std r22,32(r1)
98: 28 00 e1 fa std r23,40(r1)
9c: 60 00 c1 fb std r30,96(r1)
a0: 68 00 e1 fb std r31,104(r1)
a4: 00 00 00 60 nop
a8: 00 00 00 60 nop
ac: 00 00 42 60 ori r2,r2,0
b0: a6 03 49 7f mtctr r26
b4: 78 c3 0c 7f mr r12,r24
b8: 14 22 b9 7c add r5,r25,r4
bc: 00 00 00 39 li r8,0
c0: 09 00 6c e9 ldu r11,8(r12)
c4: 2a 20 5d 7d ldx r10,r29,r4
c8: 09 00 25 e9 ldu r9,8(r5)
cc: 33 52 cb 13 maddld r30,r11,r10,r8
d0: 31 52 eb 13 maddhdu r31,r11,r10,r8
d4: 38 30 d6 7f and r22,r30,r6
d8: 38 38 f7 7f and r23,r31,r7
dc: 78 fb e8 7f mr r8,r31
e0: 14 48 56 7d addcr10,r22,r9
e4: 14 01 77 7d adder11,r23,r0
e8: 14 18 4a 7d addcr10,r10,r3
ec: 14 52 29 7d add r9,r9,r10
f0: 94 01 6b 7c addze r3,r11
f4: 00 00 25 f9 std r9,0(r5)
f8: c8 ff 00 42 bdnzc0
fc: 01 00 9c 3b addir28,r28,1
100: 08 00 84 38 addir4,r4,8
104: 40 e0 3b 7c cmpld r27,r28
108: a8 ff 82 40 bne b0
In these two nested loops, r6 is not changed, so it is always -1.
d4: 38 30 d6 7f and r22,r30,r6
just assigns r30 to r22, so r30 could have been used instead of
r22.
Similarly,
d8: 38 38 f7 7f and r23,r31,r7
just sets r23 to zero because r7 is always zero.
[Bug fortran/106557] nesting intrinsics ibset and transfer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106557
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-08-18
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
The underlying issue also affects ibclr, and possibly other intrinsics that
are simplified at compile time.
Reduced testcase:
print *, ibset (transfer (0, 0), 0) ! bad
print *, ibset (transfer (0, 0) + 0, 0) ! OK
print *, ibset (transfer (0, 0), 0) + 0 ! OK
print *, transfer (ibset (transfer (0, 0), 0), 0) == 1 ! bad
print *, transfer (ibclr (transfer (1, 0), 0), 0) == 0 ! bad
end
The problem arises from the dual representation of the result of the
simplification of TRANSFER in gfc_simplify_transfer(), once as
result->value.integer, and as result->representation.string.
The latter is used e.g. for ensuring safe round-trip for nested
TRANSFER(TRANSFER(...),...).
It happens in gfc_simplify_ibset that value.integer is updated, but not
representation.string, and under the given circumstances either one or the
other is used later.
Possible solutions:
1) conservative hack:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index fb725994653..6c5ffcdaf86 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3380,6 +3380,11 @@ gfc_simplify_ibclr (gfc_expr *x, gfc_expr *y)
k = gfc_validate_kind (x->ts.type, x->ts.kind, false);
result = gfc_copy_expr (x);
+ if (result->representation.string)
+{
+ free (result->representation.string);
+ result->representation.string = NULL;
+}
convert_mpz_to_unsigned (result->value.integer,
gfc_integer_kinds[k].bit_size);
and a similar change to gfc_simplify_ibset. This fixes the issue just for
those two intrinsics. This may miss other cases, although I could not find
them so far.
2) more aggressive hack:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index fb725994653..3e895e12f8c 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -8157,6 +8158,16 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold,
gfc_expr *size)
/* And read the buffer back into the new expression. */
gfc_target_interpret_expr (buffer, buffer_size, result, false);
+ /* Integer is capable to hold all bits needed for complete round-trip
+with TRANSFER-in-TRANSFER. Drop separate memory representation so that
+subsequent simplification of bit manipulation intrinsics of the result
+of gfc_simplify_transfer does not lead to inconsistencies. */
+ if (result->ts.type == BT_INTEGER)
+{
+ free (result->representation.string);
+ result->representation.string = NULL;
+}
+
return result;
}
Both patches regtest cleanly on x86_64-pc-linux-gnu.
[Bug tree-optimization/106677] Abstraction overhead with std::views::join
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677 --- Comment #1 from Andrew Pinski --- (In reply to Marc Glisse from comment #0) > sum_vec gets relatively nice, short code. sum_array gets something uglier. > > _18 = _5(D)->m_array; > _6 = foo_5(D) + 24; > if (_6 != _18) That is related to PR 89317.
[Bug tree-optimization/106677] Abstraction overhead with std::views::join
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- As the inquiry to SC22WG5 resulted in a comment that different ranks should not be allowed, I've reverted the commit as r13-2118: commit ca170ed9f8a086ca7e1eec841882b6bed9ec1a3a Author: Harald Anlauf Date: Thu Aug 18 21:24:29 2022 +0200 Revert "Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]" This reverts commit 0110cfd5449bae3a772f45ea2e4c5dab5b7a8ccd. See https://gcc.gnu.org/pipermail/fortran/2022-August/058049.html for details. Will close this PR therefore as invalid (at least for <= Fortran 2018).
[Bug tree-optimization/106677] New: Abstraction overhead with std::views::join
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106677
Bug ID: 106677
Summary: Abstraction overhead with std::views::join
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from https://stackoverflow.com/q/73407636/1918193 )
#include
#include
#include
struct Foo {
auto join() const { return m_array | std::views::join; }
auto direct() const { return std::views::all(m_array[0]); }
std::array, 1> m_array;
};
__attribute__((noinline)) int sum_array(const Foo& foo)
{
int result = 0;
for (int* val : foo.join())
result += *val;
return result;
}
__attribute__((noinline)) int sum_vec(const Foo& foo)
{
int result = 0;
for (int* val : foo.direct())
result += *val;
return result;
}
I am using a snapshot from 20220719 with -std=gnu++2b -O3 and looking at
.optimized dumps.
sum_vec gets relatively nice, short code. sum_array gets something uglier.
_18 = _5(D)->m_array;
_6 = foo_5(D) + 24;
if (_6 != _18)
Err, x != x+24 should be folded to false? Let's add
if(foo.m_array.begin()==foo.m_array.end())__builtin_unreachable();
to move forward.
_16 = MEM[(int * const * const &)foo_4(D)];
_17 = MEM[(int * const * const &)foo_4(D) + 8];
if (_16 != _17)
goto ; [5.50%]
else
goto ; [94.50%]
why are we guessing that the vector is probably empty? Let's look at more code
[local count: 853673669]:
_10 = [(const struct array *)foo_4(D)]._M_elems;
_7 = foo_4(D) + 24;
_16 = MEM[(int * const * const &)foo_4(D)];
_17 = MEM[(int * const * const &)foo_4(D) + 8];
if (_16 != _17)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 806721618]:
_18 = foo_4(D) + 24;
[local count: 96636762]:
# SR.89_28 = PHI <_10(2), _18(3)>
# SR.90_41 = PHI <_16(2), 0B(3)>
goto ; [100.00%]
[local count: 923031551]:
# result_2 = PHI <0(4), result_12(8)>
# SR.89_13 = PHI
# SR.90_30 = PHI
if (_7 == SR.89_13)
goto ; [30.00%]
else
goto ; [70.00%]
[local count: 276909463]:
if (SR.90_30 == 0B)
goto ; [16.34%]
else
goto ; [83.66%]
[local count: 96636764]:
# result_31 = PHI
return result_31;
(why not _18 = _7 towards the beginning?)
It would be nice if threading could isolate the case of an empty vector: 2 -> 3
-> 4 -> 9 -> 10 -> 11: just return 0, and the rest of the code may become
easier to optimize.
Let me add
if(foo.m_array[0].begin()==foo.m_array[0].end())__builtin_unreachable();
to avoid the empty vector case as well. This looks better, at least the inner
loop looks normal, but we are still iterating on the elements of m_array, when
we should be able to tell that it has exactly 1 element.
[Bug libstdc++/106676] New: [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676
Bug ID: 106676
Summary: [C++20] Automatic iterator_category detection
misbehaves when `::reference` is an rvalue reference,
refuses to accept a forward iterator
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Since C++20, `std::iterator_traits` can auto-detect `::iterator_category`, if
the iterator doesn't set it.
Forward iterators require `::reference` (aka the return type of `operator*`) to
be a reference (any reference), but libstdc++ only accepts lvalue references
here.
Example:
#include
#include
template
struct A
{
using value_type = std::remove_cvref_t;
using difference_type = int;
T operator*() const;
A ++();
A operator++(int);
bool operator==(const A &) const;
};
// Ok.
static_assert(std::is_same_v>::iterator_category, std::forward_iterator_tag>);
// Should pass but fails, the category is `std::input_iterator_tag`.
static_assert(std::is_same_v>::iterator_category, std::forward_iterator_tag>);
I blame this on cppreference, which used to incorrectly say that only lvalue
references are allowed there. It was fixed since then.
See https://eel.is/c++draft/iterators#forward.iterators-1.3. Also see
https://cplusplus.github.io/LWG/issue1211 (from 2009), which was resolved by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3066.html (in 2010).
This was discussed on SO: https://stackoverflow.com/q/73353152
libc++ and MSVC's standard library share the exact same bug.
This was tested on GCC 12.1 and on trunk (13.0.0).
[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86521 --- Comment #2 from Andrew Pinski --- I suspect the patch for PR 86521 which was aiming on fixing the rejection was not fully correct and introduced an ICE in some cases ...
[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-08-18 Summary|g++ crashes on funky|[10/11/12/13 Regression] |operators |g++ crashes on funky ||operators Known to fail||12.1.0, 8.4.0, 8.5.0, 9.1.0 Target Milestone|--- |10.5 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- (In reply to Isabella from comment #0) > g++ from v11 onward crashes on it: https://godbolt.org/z/nYqo1zj31 That is because the language default changed to gnu++17 from gnu++14. Confirmed. It might be considered a regression even though it was rejected before GCC 8.4.0. The ICE is in joust_maybe_elide_copy.
[Bug c++/106675] New: g++ crashes on funky operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106675 Bug ID: 106675 Summary: g++ crashes on funky operators Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: izaberina at gmail dot com Target Milestone: --- Created attachment 53472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53472=edit short repro Attached is a small reproducer of something that originally came from boost::system::error_code. g++ from v11 onward crashes on it: https://godbolt.org/z/nYqo1zj31
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Maarten L. Hekkelman changed: What|Removed |Added CC||maarten at hekkelman dot com --- Comment #13 from Maarten L. Hekkelman --- Too bad this bug has still not been dealt with. And it is even worse that simply running out of stack space seems to be acceptable. And no, I'm not using inputs in the form of 27kB, more like just a few hundred characters at most with quite complex expressions. Fortunately, it is now very easy to use the boost::regex as a standalone library as a replacement. But alas, that's still a dependency.
[Bug c++/106648] [C++23] P2071 - Named universal character escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106648 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 53471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53471=edit makeuname2c.cc I've so far written a generator of a space optimized radix tree for the Unicode name to codepoint mapping (this would be libcpp/makeuname2c.cc), but will need to write a consumer of those arrays to actually implement the Unicode name to codepoint mapping.
[Bug tree-optimization/106457] array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457 qinzhao at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #10 from qinzhao at gcc dot gnu.org --- after discussing with Richard, and agreed on the several bugs mentioned in comment #7,#8 and #9 are actually not bugs. we just need to add more comments for array_at_struct_end_p and change the name of it later. close this bug as fixed.
[Bug analyzer/106181] [13 Regression] ICE in capacity_compatible_with_type, at analyzer/region-model.cc:2909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106181 --- Comment #3 from CVS Commits --- The master branch has been updated by Tim Lange : https://gcc.gnu.org/g:c83e97317efb87fd5639a9ee9ec55aa1caa5423e commit r13-2115-gc83e97317efb87fd5639a9ee9ec55aa1caa5423e Author: Tim Lange Date: Thu Aug 18 11:36:08 2022 +0200 analyzer: warn on the use of floating-points operands in the size argument [PR106181] This patch fixes the ICE reported in PR106181 and adds a new warning to the analyzer complaining about the use of floating-point operands. Regrtested on Linux x86_64. 2022-08-17 Tim Lange gcc/analyzer/ChangeLog: PR analyzer/106181 * analyzer.opt: Add Wanalyzer-imprecise-floating-point-arithmetic. * region-model.cc (is_any_cast_p): Formatting. (region_model::check_region_size): Ensure precondition. (class imprecise_floating_point_arithmetic): New abstract diagnostic class for all floating-point related warnings. (class float_as_size_arg): Concrete diagnostic class to complain about floating-point operands inside the size argument. (class contains_floating_point_visitor): New visitor to find floating-point operands inside svalues. (region_model::check_dynamic_size_for_floats): New function. (region_model::set_dynamic_extents): Call to check_dynamic_size_for_floats. * region-model.h (class region_model): Add region_model::check_dynamic_size_for_floats. gcc/ChangeLog: PR analyzer/106181 * doc/invoke.texi: Add Wanalyzer-imprecise-fp-arithmetic. gcc/testsuite/ChangeLog: PR analyzer/106181 * gcc.dg/analyzer/allocation-size-1.c: New test. * gcc.dg/analyzer/imprecise-floating-point-1.c: New test. * gcc.dg/analyzer/pr106181.c: New test.
[Bug tree-optimization/80635] [10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #68 from Alec Edgington --- This (or at least a very similar) bug still exists in gcc 11.2.0.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Segher Boessenkool --- Okay, closing then. Thanks!
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #28 from Arseny Solokha --- Yes, I think so.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #27 from Segher Boessenkool --- So this particular bug is no longer there, and this PR can be closed?
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Richard Biener --- Should be fixed now.
[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106642 Bug 106642 depends on bug 106617, which changed state. Bug 106617 Summary: [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ac68f904fe31baf80fa53218f1d8ee033bd8c79b commit r13-2113-gac68f904fe31baf80fa53218f1d8ee033bd8c79b Author: Richard Biener Date: Thu Aug 18 11:10:30 2022 +0200 middle-end/106617 - fix fold_binary_op_with_conditional_arg pattern issue Now that we have parts of fold_binary_op_with_conditional_arg duplicated in match.pd and are using ! to take or throw away the result we have to be careful to not have both implementations play games which each other, causing quadratic behavior. In particular the match.pd implementation requires both arms to simplify while the fold-const.cc is happy with just one arm simplifying (something we cannot express in match.pd). The fix is to simply not enable the match.pd pattern for GENERIC. PR middle-end/106617 * match.pd ((a ? b : c) > d -> a ? (b > d) : (c > d)): Fix guard, disable on GENERIC to not cause quadratic behavior with the fold-const.cc implementation and the use of ! * gcc.dg/pr106617.c: New testcase.
[Bug gcov-profile/106659] [13 Regression] error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106659 Martin Liška changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Martin Liška --- Fixed.
[Bug gcov-profile/106659] [13 Regression] error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106659 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:03119249b9cfedb48e910b8df6a832b206cced2b commit r13-2112-g03119249b9cfedb48e910b8df6a832b206cced2b Author: Andrew Pinski Date: Thu Aug 18 14:36:28 2022 +0200 gcov-dump: properly use INCLUDE_VECTOR PR gcov-profile/106659 gcc/ChangeLog: * gcov-dump.cc (INCLUDE_VECTOR): Include vector.h with INCLUDE_VECTOR.
[Bug libstdc++/106669] incorrect definition of viewable_range ("more madness with move-only views")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669 --- Comment #1 from Hannes Hauswedell --- This affects GCC 10.4 and GCC 11.3 since move-only views were backported. The following part of the draft standard also needs changing: https://eel.is/c++draft/range.all#general-2.1 ---> decay-copy(E) if that expression is well-formed and the decayed type of E models view. This will make references to move-only views pick the second option (ref_view).
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #6 from Richard Earnshaw --- (In reply to Richard Earnshaw from comment #5) > (In reply to D Scott Phillips from comment #2) > > th(In reply to Andrew Pinski from comment #1) > > > Shouldn't the linker add the BTI inside the ___veneer instead? > > > > The bti instruction has to be placed at the target of the indirect branch > > (at the top of `func` in this case) so I don't think it would be possible to > > work around this just within the veneer. > > The veneer has to be placed 'near' the target and then end with a direct > branch instruction. The linker should be able to work this out. This might, of course, mean that two veneers are needed in this case, one that can be reached from the initial branch, and one that can reach the final target. A direct branch will jump to the first and the second one will be reached by an indirect jump (needing a BTI at the start).
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #5 from Richard Earnshaw --- (In reply to D Scott Phillips from comment #2) > th(In reply to Andrew Pinski from comment #1) > > Shouldn't the linker add the BTI inside the ___veneer instead? > > The bti instruction has to be placed at the target of the indirect branch > (at the top of `func` in this case) so I don't think it would be possible to > work around this just within the veneer. The veneer has to be placed 'near' the target and then end with a direct branch instruction. The linker should be able to work this out.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #26 from Arseny Solokha --- Now testcases from comment 8 and the one in the gcc tree from which comment 6 has been reduced both fail the same way as reported in PR96762.
[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617
--- Comment #12 from Richard Biener ---
Btw, just for reference the original looks like
fc_cpu_order = ( __builtin_constant_p(( __builtin_constant_p(nr_cpu_ids) ? (
((nr_cpu_ids) == 1) ? 1 : (1UL << (( __builtin_constant_p((nr_cpu_ids) - 1) ? (
__builtin_constant_p((nr_cpu_ids) - 1) ? ( ((nr_cpu_ids) - 1) < 2 ? 0 :
((nr_cpu_ids) - 1) & (1ULL << 63) ? 63 : ((nr_cpu_ids) - 1) & (1ULL << 62) ? 62
: ((nr_cpu_ids) - 1) & (1ULL << 61) ? 61 : ((nr_cpu_ids) - 1) & (1ULL << 60) ?
60 : ((nr_cpu_ids) - 1) & (1ULL << 59) ? 59 : ((nr_cpu_ids) - 1) & (1ULL << 58)
? 58 : ((nr_cpu_ids) - 1) & (1ULL << 57) ? ...
so some fancy ceil_log2.
If you take a simplified
unsigned long fc_setup_exch_mgr(int nr_cpu_ids_m1)
{
return nr_cpu_ids_m1)) & (1<<21) ? 21
: ((nr_cpu_ids_m1)) & (1<<20) ? 20
: ((nr_cpu_ids_m1)) & (1<<19) ? 19
: ((nr_cpu_ids_m1)) & (1<<18) ? 18
: ((nr_cpu_ids_m1)) & (1<<17) ? 17
: ((nr_cpu_ids_m1)) & (1<<16) ? 16
: ((nr_cpu_ids_m1)) & (1<<15) ? 15
: ((nr_cpu_ids_m1)) & (1<<14) ? 14
: ((nr_cpu_ids_m1)) & (1<<13) ? 13
: ((nr_cpu_ids_m1)) & (1<<12) ? 12
: ((nr_cpu_ids_m1)) & (1<<11) ? 11 /* THIS */
: ((nr_cpu_ids_m1)) & (1<<9) ? 9
: ((nr_cpu_ids_m1)) & (1<<8) ? 8
: ((nr_cpu_ids_m1)) & (1<<7) ? 7
: ((nr_cpu_ids_m1)) & (1<<6) ? 6
: ((nr_cpu_ids_m1)) & (1<<5) ? 5
: ((nr_cpu_ids_m1)) & (1<<4) ? 4
: ((nr_cpu_ids_m1)) & (1<<3) ? 3
: 0)) != 11;
}
I see
./cc1 -quiet t2.c -fdump-tree-original-folding; grep 'Applying'
t2.c.005t.original | sort -u ; grep 'Applying' t2.c.005t.original | wc -l
Applying pattern match.pd:4778, generic-match.cc:95676
Applying pattern match.pd:5809, generic-match.cc:24025
16383
but when I just remove the marked line it becomes
./cc1 -quiet t2.c -fdump-tree-original-folding; grep 'Applying'
t2.c.005t.original | sort -u ; grep 'Applying' t2.c.005t.original | wc -l
Applying pattern match.pd:4778, generic-match.cc:95676
Applying pattern match.pd:5809, generic-match.cc:24025
34
hmm, and the issue is probably that we have this pattern both in
fold-const.cc and match.pd and thus when the pattern applies recursively,
like for
(a ? (b ? d : e) : f) > g
and the original fold implementation would simplify because one of the
braches simplifes:
/* Check that we have simplified at least one of the branches. */
if (!TREE_CONSTANT (arg) && !TREE_CONSTANT (lhs) && !TREE_CONSTANT (rhs))
return NULL_TREE;
so it goes all the way, recursively to "simple". But then the match.pd
variant rejects the result because it is EXPR_P for the lhs (but not
for the rhs). We always first try the match.pd path but then will
try fold_binary_op_with_conditional_arg anyway which makes this effectively
at least quadratic.
This was all done to avoid regressing the COND_EXPR gimple IL refactoring.
One possibility to avoid the recursion with fold-const is to disable the
match.pd pattern for GENERIC.
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273
--- Comment #9 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:9d2d38a4686cb0f4cc0a7ce252503dd8090ab322
commit r13-2109-g9d2d38a4686cb0f4cc0a7ce252503dd8090ab322
Author: Sergei Trofimovich
Date: Thu Aug 18 07:46:03 2022 +0100
Makefile.def: drop remnants of unused libelf
Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR
lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0.
This change removes unused references to libelf from top-level configure
and Makefile.
/
* Makefile.def: Drop libelf module and gcc-configure dependency
on it.
* Makefile.in: Regenerate with 'autogen Makefile.def'.
* Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and
LIBELFINC.
* configure: Regenrate.
* configure.ac (host_libs): Drop unused libelf.
[Bug bootstrap/67102] Parallel build fails in libffi/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102
--- Comment #7 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:5dbc94bf13c5ef2f2b777d76d7880fe2153aa37b
commit r13-2108-g5dbc94bf13c5ef2f2b777d76d7880fe2153aa37b
Author: Sergei Trofimovich
Date: Thu Aug 18 07:55:15 2022 +0100
Add libgo dependency on libbacktrace.
Noticed missing dependency when regenerated Makefile.in for unrelated
change with 'autogen Makefile.def'.
The change was lost in r12-6861-gaeac414923aa1e ("Revert "Fix PR 67102:
Add libstdc++ dependancy to libffi" [PR67102]").
/
* Makefile.in: Regenerate.
[Bug target/103109] madd not used for multiply add on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109 HaoChen Gui changed: What|Removed |Added Resolution|--- |FIXED CC||guihaoc at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from HaoChen Gui --- Fixed by r13-2107.
[Bug target/103109] madd not used for multiply add on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103109 --- Comment #1 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:defa08a33672d200edbdd7f87ed7afa442249261 commit r13-2107-gdefa08a33672d200edbdd7f87ed7afa442249261 Author: Haochen Gui Date: Thu Aug 18 16:23:11 2022 +0800 rs6000: Add expand pattern for multiply-add (PR103109) gcc/ PR target/103109 * config/rs6000/rs6000.md (maddditi4): New pattern for multiply-add. (madddi4_highpart): New. (madddi4_highpart_le): New. gcc/testsuite/ PR target/103109 * gcc.target/powerpc/pr103109.h: New. * gcc.target/powerpc/pr103109-1.c: New. * gcc.target/powerpc/pr103109-2.c: New.
[Bug ada/106031] ICE on container map empty aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106031 David SAUVAGE - AdaLabs changed: What|Removed |Added CC||david.sauvage at adalabs dot com --- Comment #2 from David SAUVAGE - AdaLabs --- reproducer available on https://gitlab.com/adalabs/reproducers/-/tree/main/106031
[Bug ada/106037] ICE with Aggregate aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037 David SAUVAGE - AdaLabs changed: What|Removed |Added CC||david.sauvage at adalabs dot com --- Comment #3 from David SAUVAGE - AdaLabs --- reproducer available on https://gitlab.com/adalabs/reproducers/-/tree/main/106037
[Bug ada/106168] Errors with empty array aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168 David SAUVAGE - AdaLabs changed: What|Removed |Added CC||david.sauvage at adalabs dot com --- Comment #1 from David SAUVAGE - AdaLabs --- https://gitlab.com/adalabs/reproducers/-/tree/main/106168
[Bug ada/106169] Error with iterated element association in aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106169 David SAUVAGE - AdaLabs changed: What|Removed |Added CC||david.sauvage at adalabs dot com --- Comment #1 from David SAUVAGE - AdaLabs --- reproducer available on https://gitlab.com/adalabs/reproducers/-/tree/main/106169
[Bug go/85037] SIGSEGV in gotools testsuite affects several tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85037 Uroš Bizjak changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Uroš Bizjak --- Obsolete PR.
[Bug d/90261] FAIL: libphobos.phobos/std/file.d on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90261 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Uroš Bizjak --- Centos 5.11 is just too old nowadays.
[Bug target/101346] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |12.2 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/103861] [i386] vectorize v2qi vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Uroš Bizjak --- Let's say this is done now.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 95201, which changed state. Bug 95201 Summary: Some x86 vector-extend patterns are not exercised. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/95201] Some x86 vector-extend patterns are not exercised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Uroš Bizjak --- This is now fixed.
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658 Bug 92658 depends on bug 95201, which changed state. Bug 95201 Summary: Some x86 vector-extend patterns are not exercised. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95201 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug ada/106318] ICE when using 'Range in Ada22 Iterated Component Association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106318 David SAUVAGE - AdaLabs changed: What|Removed |Added CC||david.sauvage at adalabs dot com --- Comment #1 from David SAUVAGE - AdaLabs --- bug also present on gcc 12.1.0 x86_64 GNU/Linux reproducer available on https://gitlab.com/adalabs/reproducers/-/tree/main/106318
[Bug libgcc/106674] New: Potential for symbol conflicts between libgcc_s and libunwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106674 Bug ID: 106674 Summary: Potential for symbol conflicts between libgcc_s and libunwind Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: yshuiv7 at gmail dot com Target Milestone: --- libunwind and ligcc_s provides the same set of symbols, if an application depends on both, then in very specific scenarios, conflicts can happen. I hit the problem when running C++ code built by wineg++. When an exception is thrown, libgcc_s' _Unwind_RaiseException somehow calls into libunwind's _Unwind_GetCFA, and got garbage. I don't know exactly how this happens. Arch Linux does this to libunwind: https://github.com/archlinux/svntogit-packages/blob/bd8ecd47e91dbb2cf77f82ca3a5a94ef1263eb31/trunk/PKGBUILD#L26 I don't know if that is to fix this problem in specific, but it does make the problem go away.
[Bug ada/106673] compilation bug on abstract primitive pre'class aspect using for all construct on a string parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673 --- Comment #1 from David SAUVAGE - AdaLabs --- Created attachment 53470 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53470=edit reproducer
[Bug ada/106673] New: compilation bug on abstract primitive pre'class aspect using for all construct on a string parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106673 Bug ID: 106673 Summary: compilation bug on abstract primitive pre'class aspect using for all construct on a string parameter Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: david.sauvage at adalabs dot com Target Milestone: --- gcc version 12.1.0 [1] bug reproduction: use make command on reproducer pre-class-aspect-for-all-on-string-compiler-bug.tar.gz attached, or using git at https://gitlab.com/adalabs/reproducers/-/tree/main/pre-class-aspect-for-all-on-string-compiler-bug +===GNAT BUG DETECTED==+ | 12.1.0 (x86_64-pc-linux-gnu) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:472 | | Error detected at reproducer.ads:9:38| reproducer.ads 1 2 package Reproducer is 3 4 type Node_Type is abstract tagged private; 5 6 not overriding 7 procedure Add_Child (Self : in out Node_Type; 8 Name : in String) is abstract 9 with Pre'Class => (for all C of Name => C /= '.'); 10 11 private 12 type Node_Type is abstract tagged null record; 13 end Reproducer; [1] Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=[..]/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../src/configure --prefix=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gcc/install --with-build-time-tools=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/binutils/install/bin --enable-languages=c,ada,c++ --enable-libstdcxx --enable-libstdcxx-threads --enable-libada --disable-nls --without-libiconv-prefix --disable-libstdcxx-pch --enable-lto --disable-multilib --enable-threads=posix --with-gnu-ld --with-gnu-as --with-mpfr=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpfr/install --with-gmp=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gmp/install --with-mpc=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpc/install --with-isl=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/isl/install --build=x86_64-pc-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib
