[Bug middle-end/106470] Subscribed access to __m256i casted to (uint16_t *) produces garbage or a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470 --- Comment #8 from Alexander Monakov --- But that's the point of many warnings, isn't it? To help the user understand what's wrong when the code is bad? And bogus warnings just confuse more.
[Bug analyzer/106473] New: -Wanalyzer-malloc-leak false positive regression when returning heap-allocation through nested pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106473
Bug ID: 106473
Summary: -Wanalyzer-malloc-leak false positive regression when
returning heap-allocation through nested pointers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: raimue at codingfarm dot de
Target Milestone: ---
Source:
void foo(char **args[], int *argc) {
*argc = 1;
(*args)[0] = __builtin_malloc(42);
}
Compiler output:
$ gcc-12 -Wall -fanalyzer -c -o foo.o foo.c
foo.c: In function 'foo':
foo.c:4:1: warning: leak of '' [CWE-401] [-Wanalyzer-malloc-leak]
4 | }
| ^
'foo': events 1-2
|
|3 | (*args)[0] = __builtin_malloc(42);
| | ^~~~
| | |
| | (1) allocated here
|4 | }
| | ~
| | |
| | (2) '' leaks here; was allocated at (1)
|
Notes:
This is only reported with the write to argc happening first, which should be
considered completely unrelated to args. Reordering the two statements resolves
the analyzer report.
Tested versions:
gcc 10.3: FAIL
gcc 11.2: OK
gcc 12.0: FAIL
I therefore consider this a regression as it was not reported by gcc 11.
Compiler Explorer link:
https://gcc.godbolt.org/z/zGanPa3fs
[Bug c/106465] ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-07-29
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. The ICE is the following
> ./cc1 -quiet t.c
t.c: In function 'f':
t.c:3:17: warning: anonymous struct declared inside parameter list will not be
visible outside of this definition or declaration
3 | void g(int m, struct { char p[m]; } b) { }
| ^~
t.c:1:5: internal compiler error: m from g referenced in f
1 | int f()
| ^
0x15818d9 convert_nonlocal_reference_op
/home/rguenther/src/trunk/gcc/tree-nested.cc:1164
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #5 from Richard Biener --- can't reproduce with a cross from x86_64
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 --- Comment #7 from Jakub Jelinek --- Maybe.
[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:97d32048c04e9787fccadc4bae1c042754503e34 commit r13-1887-g97d32048c04e9787fccadc4bae1c042754503e34 Author: Jakub Jelinek Date: Fri Jul 29 09:49:11 2022 +0200 openmp: Fix up handling of non-rectangular simd loops with pointer type iterators [PR106449] There were 2 issues visible on this new testcase, one that we didn't have special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer part in sizetype, for non-rectangular loop on the other side we can rely on multiplication factor 1, pointers can't be multiplied, without those changes we'd ICE. The other issue was that we put n2 expression directly into a comparison in a condition and regimplified that, for the &a[512] case that and with gimplification being destructed that unfortunately meant modification of original fd->loops[?].n2. Fixed by unsharing the expression. This was causing a runtime failure on the testcase. 2022-07-29 Jakub Jelinek PR middle-end/106449 * omp-expand.cc (expand_omp_simd): Fix up handling of pointer iterators in non-rectangular simd loops. Unshare fd->loops[i].n2 or n2 before regimplifying it inside of a condition. * testsuite/libgomp.c-c++-common/pr106449.c: New test.
[Bug target/106471] Strange code generation for __builtin_ctzl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Keywords||missed-optimization CC||sayle at gcc dot gnu.org --- Comment #7 from Richard Biener --- Roger is working on the sign-/zero-extension issue. The false dependence thing would be for adjusting generic tuning for more modern CPUs by default, I'm not sure what's the oldest families still affected here.
[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2dcceedb3c121f2498ae58d8414e7b8454b7bf55 commit r13-1888-g2dcceedb3c121f2498ae58d8414e7b8454b7bf55 Author: Jakub Jelinek Date: Fri Jul 29 09:59:19 2022 +0200 openmp: Reject invalid forms of C++ #pragma omp atomic compare [PR106448] The allowed syntaxes of atomic compare don't allow ()s around the condition of ?:, but we were accepting it in one case for C++. Fixed thusly. 2022-07-29 Jakub Jelinek PR c++/106448 * parser.cc (cp_parser_omp_atomic): For simple cast followed by CPP_QUERY token, don't try cp_parser_binary_operation if compare is true. * c-c++-common/gomp/atomic-32.c: New test.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
Richard Biener changed:
What|Removed |Added
Target||x86_64-pc-solaris2.11
Host||x86_64-pc-solaris2.11
Build||x86_64-pc-solaris2.11
--- Comment #3 from Richard Biener ---
There is dependencies = { module=all-target-libgo; on=all-target-libbacktrace;
}
in Makefile.def so there's sth fishy going on. Do you use GNU make?
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #4 from Petr Sumbera ---
(In reply to Richard Biener from comment #3)
> There is dependencies = { module=all-target-libgo;
> on=all-target-libbacktrace; }
> in Makefile.def so there's sth fishy going on. Do you use GNU make?
Yes. GNU Make 4.3.
[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed on the trunk. Not going to be backported, as it is accepts-invalid.
[Bug c/106464] [OpenMP] atomic compare – gcc wrongly accepts parenthesized expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106464 Bug 106464 depends on bug 106448, which changed state. Bug 106448 Summary: [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449 --- Comment #11 from Jakub Jelinek --- Fixed on the trunk so far. Will backport later.
[Bug tree-optimization/105679] [12/13 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-29 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Checking profitability of path (backwards): bb:5 (2 insns) bb:4 (7 insns) bb:3 Control statement insns: 2 Overall: 7 insns [1] Registering jump thread: (3, 4) incoming edge; (4, 5) normal (5, 6) nocopy; path: 3->4->5->6 SUCCESS but from the following you can see BB3 is known to probably never execute. ;; basic block 2, loop depth 0, count 1073741823 (estimated locally), maybe hot ;;prev block 9, next block 3, flags: (NEW, REACHABLE, VISITED) ;;pred: 9 [always] count:1073741823 (estimated locally) (FALLTHRU,EXECUTABLE) if (irq_1(D) > 31) goto ; [0.00%] else goto ; [100.00%] ;; basic block 3, loop depth 0, count 0 (precise), probably never executed ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [never] count:0 (precise) (TRUE_VALUE,EXECUTABLE) _2 = (unsigned long) irq_1(D); __builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, 1, _2); ;;succ: 4 [never] count:0 (precise) (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, count 1073741823 (estimated locally), maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [always] count:1073741823 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;;3 [never] count:0 (precise) (FALLTHRU,EXECUTABLE) _3 = 1 << irq_1(D); mask_4 = (u32) _3; entry = instance_5(D)->array[irq_1(D)]; capture (mask_4); if (level_6(D) != 0) goto ; [34.00%] else goto ; [66.00%] ;;succ: 7 [34.0% (guessed)] count:365072224 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;5 [66.0% (guessed)] count:708669599 (estimated locally) (FALSE_VALUE,EXECUTABLE) ;; basic block 5, loop depth 0, count 708669600 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED) ;;pred: 4 [66.0% (guessed)] count:708669599 (estimated locally) (FALSE_VALUE,EXECUTABLE) if (irq_1(D) == 1) goto ; [20.97%] else goto ; [79.03%] ;;succ: 7 [21.0% (guessed)] count:148608017 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;;6 [79.0% (guessed)] count:560061583 (estimated locally) (FALSE_VALUE,EXECUTABLE)
[Bug c/106474] New: DCE depends on how if expressions are nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
Bug ID: 106474
Summary: DCE depends on how if expressions are nested
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tmayerl at student dot ethz.ch
Target Milestone: ---
In some cases, the compiler's ability to eliminate dead code depends on how if
expressions are nested.
GCC detects that the if expressions in the following code snippet evaluate to
false and thus removes the dead code:
#include
#include
static void __attribute__ ((noinline)) DCEMarker0_() {printf("DCE2.0");}
void f(bool s, bool c) {
if (!c == !s) {
if (!c && s) {
DCEMarker0_();
}
}
}
In the following snippet the !c term is moved into the outer if expression.
However, GCC cannot eliminate the dead code anymore:
#include
#include
static void __attribute__ ((noinline)) DCEMarker0_() {printf("DCE2.0");}
void f(bool s, bool c) {
if ((!c == !s) && !c) {
if (s) {
DCEMarker0_();
}
}
}
In the following snippet, only the outer if statement is kept and all terms are
moved there. GCC is now able to eliminate the code again:
#include
#include
static void __attribute__ ((noinline)) DCEMarker0_() {printf("DCE2.0");}
void f(bool s, bool c) {
if (((!c == !s) && !c) && s) {
DCEMarker0_();
}
}
This can also be seen via the following Compiler Explorer link:
https://godbolt.org/z/9WPn5cG1W
[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399
--- Comment #5 from Eric Botcazou ---
This is an equivalent Ada testcase:
function Foo (A: Integer) return Integer is
function A2 return Integer is (A * A);
begin
return A2;
end;
with the same issue. We have been using the to-be-attached patch for years to
solve the problem, but it does not seem to work for the C compiler because the
prologue_location points to '{' instead of the function declarator.
[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399 --- Comment #6 from Eric Botcazou --- Created attachment 53380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53380&action=edit Incomplete fix
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4894ba078692a780a461d2f358b5dfaa25719859 commit r13-1889-g4894ba078692a780a461d2f358b5dfaa25719859 Author: Richard Biener Date: Fri Jul 29 08:24:52 2022 +0200 tree-optimization/106422 - verify block copying in forward threading The forward threader failed to check whether it can actually duplicate blocks. The following adds this in a similar place the backwards threader performs this check. PR tree-optimization/106422 * tree-ssa-threadupdate.cc (fwd_jt_path_registry::update_cfg): Check whether we can copy thread blocks and cancel the thread if not. * gcc.dg/torture/pr106422.c: New testcase.
[Bug tree-optimization/106422] [13 Regression] ice in duplicate_block, at cfghooks.cc:1115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener --- Fixed.
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b5f5d1b36edbcd7d923f2e2653e54e52637c715b commit r13-1890-gb5f5d1b36edbcd7d923f2e2653e54e52637c715b Author: Jonathan Wakely Date: Thu Jul 28 20:55:51 2022 +0100 libstdc++: Tweak common_iterator::operator-> return type [PR104443] This adjusts the return type to match the resolution of LWG 3672. There is no functional difference, because decltype(auto) always deduced a value anyway, but this makes it simpler and consistent with the working draft. libstdc++-v3/ChangeLog: PR libstdc++/104443 * include/bits/stl_iterator.h (common_iterator::operator->): Change return type to just auto.
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|SUSPENDED |RESOLVED Target Milestone|--- |13.0 --- Comment #5 from Jonathan Wakely --- (In reply to Jiang An from comment #3) > LWG3672 has been adopted, so no change is needed and this issue can be > closed. Although it might be more clear to use auto instead of > decltype(auto). Agreed, and done. Thanks for the report and update.
[Bug middle-end/78081] -Wmaybe-initialized false-alarm regression for Emacs regex.c (jump threading fallout)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78081 Richard Biener changed: What|Removed |Added Last reconfirmed|2018-09-16 00:00:00 |2022-7-29 --- Comment #6 from Richard Biener --- Re-confirmed (the reduced testcase no longer warns in GCC 12+).
[Bug tree-optimization/106474] DCE depends on how if expressions are nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||amacleod at redhat dot com Ever confirmed|0 |1 Component|c |tree-optimization Last reconfirmed||2022-07-29 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- For the failing case we see : if (c_5(D) == s_6(D)) goto ; [INV] else goto ; [INV] : if (c_5(D) != 0) goto ; [INV] else goto ; [INV] : if (s_6(D) != 0) goto ; [INV] else goto ; [INV] and we basically fail to thread 2->3->4->6, eliminating the if (s_6(D) != 0) branch when c_5(D) == s_6(D) and c_5(D) == 0. It looks like relations / equivalences related, but maybe not exactly. Andrew?
[Bug tree-optimization/105679] [12/13 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:49ba4fdeb648c149fa7d964ba812084262c3d06f commit r13-1891-g49ba4fdeb648c149fa7d964ba812084262c3d06f Author: Richard Biener Date: Fri Jul 29 10:40:34 2022 +0200 tree-optimization/105679 - disable backward threading of unlikely entry The following makes the backward threader reject threads whose entry edge is probably never executed according to the profile. That in particular, for the testcase, avoids threading the irq == 1 check on the path where irq > 31, thereby avoiding spurious -Warray-bounds diagnostics if (irq_1(D) > 31) goto ; [0.00%] else goto ; [100.00%] ;; basic block 3, loop depth 0, count 0 (precise), probably never executed _2 = (unsigned long) irq_1(D); __builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, 1, _2); _3 = 1 << irq_1(D); mask_4 = (u32) _3; entry = instance_5(D)->array[irq_1(D)]; capture (mask_4); if (level_6(D) != 0) goto ; [34.00%] else goto ; [66.00%] ;; basic block 5, loop depth 0, count 708669600 (estimated locally), maybe hot if (irq_1(D) == 1) goto ; [20.97%] else goto ; [79.03%] PR tree-optimization/105679 * tree-ssa-threadbackward.cc (back_threader_profitability::profitable_path_p): Avoid threading when the entry edge is probably never executed.
[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 Richard Biener changed: What|Removed |Added Known to work||13.0 Summary|[12/13 Regression] extra|[12 Regression] extra |-Warray-bounds warning |-Warray-bounds warning |added with -fsanitize=shift |added with -fsanitize=shift |due to jump threading |due to jump threading --- Comment #5 from Richard Biener --- Should be fixed on trunk. Can you check on the original unreduced testcase?
[Bug middle-end/106467] [OpenMP] Wrong code with collapse – tree sharing issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467 --- Comment #4 from Tobias Burnus --- For completeness, the testcase https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599041.html was committed as https://gcc.gnu.org/r13-1893-g85fe7e7dd1f1461b86d92a3a0c1bfd97a06efcc0
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #17 from Richard Biener ---
Seeing
Trying 21 -> 24:
21: r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
REG_DEAD r146:V4SI
REG_DEAD r141:V4SI
24: {r151:SI=vec_select(r150:V4SI,parallel);clobber scratch;}
...
Successfully matched this instruction:
(set (reg:SI 151)
(vec_select:SI (reg:V4SI 141)
(parallel [
(const_int 3 [0x3])
])))
shouldn't that be (vec_select:SI (reg:V4SI 146) ...)? Or does
(vec_concat:V8SI (xx:V4SI xx:V4SI)) magically swap the two V4SI vectors?
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> Seeing
>
> Trying 21 -> 24:
>21: r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
> REG_DEAD r146:V4SI
> REG_DEAD r141:V4SI
>24: {r151:SI=vec_select(r150:V4SI,parallel);clobber scratch;}
> ...
> Successfully matched this instruction:
> (set (reg:SI 151)
> (vec_select:SI (reg:V4SI 141)
> (parallel [
> (const_int 3 [0x3])
> ])))
>
> shouldn't that be (vec_select:SI (reg:V4SI 146) ...)? Or does
> (vec_concat:V8SI (xx:V4SI xx:V4SI)) magically swap the two V4SI vectors?
Ah, no, the combination looks correct to me. After all the select in 21
interleaves the two inputs.
[Bug tree-optimization/106475] New: Loop vectorizer prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
Bug ID: 106475
Summary: Loop vectorizer prevents vectorization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: christophm30 at gmail dot com
Target Milestone: ---
Inspired by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106352 I've tested
GCC's behaviour after adding the restrict keyword as advised there.
This results in the following code:
```
#include
void
foo (uint8_t *restrict dst, int i_dst_stride,
uint8_t *src1, int i_src1_stride,
uint8_t *src2, int i_src2_stride,
int i_height)
{
for (int y = 0; y < i_height; y++)
{
for( int x = 0; x < 8; x++ )
dst[x] = (src1[x] + src2[x] + 1);
dst += i_dst_stride;
src1 += i_src1_stride;
src2 += i_src2_stride;
}
}
```
The issue is now, that this only gets vectorized, if we pass
`-O3 -fno-tree-loop-vectorize`, i.e. disable the loop vectorizer.
Obviously, what helps for this function is not necessarily beneficial
for the rest of the program. So a solution that does not need to disable
the loop vectorization to generate faster code would be preferred.
I have not found a GCC version that can do this, so this is not a
regression, but a limitation. I also have not found a similar ticket,
but I suspect this to be somehow a known issue.
Are there any ideas to improve this?
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Giulio Benetti changed: What|Removed |Added CC||giulio.benetti@benettiengin ||eering.com --- Comment #10 from Giulio Benetti --- It still shows up on gcc 11.2.0
[Bug tree-optimization/106073] [12/13 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-3903-g0288527f47cec669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106073
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=90348
--- Comment #4 from Richard Biener ---
Options reduced to
-O2 -funroll-loops -fno-tree-vectorize -fdisable-tree-cunrolli
-fdbg-cnt=gimple_unroll:3-6:8-8
in particular reducing late unrolling more will no longer reproduce the issue.
Disabling all threading after cunroll still reproduces the issue, thus
adding
-fdisable-tree-thread2 -fdisable-tree-threadfull2 -fdisable-tree-vrp2
-fdisable-tree-dom3
disabling IVOPTs hides the issue. Making all functions but main static also
still reproduces the issue (so there's just one function left for late opts).
With that simplification
-O2 -funroll-loops -fno-tree-vectorize -fdisable-tree-cunrolli
-fdbg-cnt=gimple_unroll:3-6:8-8 -fdisable-tree-thread2
-fdisable-tree-threadfull2 -fdisable-tree-dom3 -fno-tree-vrp -fdump-tree-all
-fdbg-cnt=ivopts_loop:13-13:15-15
reproduces it, less IVOPTs does not.
So one difference triggering the issue is (good vs bad in .optimized):
@@ -328,20 +326,21 @@
[local count: 60532]:
l = 0;
+ ivtmp.151_212 = (unsigned long) &bf;
+ _507 = ivtmp.151_212 + 56;
[local count: 412224]:
- # ai_lsm.108_510 = PHI
- # ivtmp_511 = PHI <8(19), ivtmp_512(21)>
- ivtmp_512 = ivtmp_511 - 1;
- if (ivtmp_512 != 0)
+ # ivtmp.151_254 = PHI
+ if (ivtmp.151_254 != _507)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 366880]:
- bf[ai_lsm.108_510][0] = 5;
- bf[ai_lsm.108_510][1] = 5;
- _516 = ai_lsm.108_510 + 1;
+ _506 = (void *) ivtmp.151_254;
+ MEM[(int *)_506] = 5;
+ MEM[(int *)_506 + 4B] = 5;
+ ivtmp.151_380 = ivtmp.151_254 + 8;
goto ; [100.00%]
[local count: 45347]:
@@ -353,8 +352,6 @@
[local count: 40253]:
bf ={v} {CLOBBER(eol)};
- ivtmp.132_498 = (unsigned long) &bf;
- _480 = ivtmp.132_498 + 56;
goto ; [100.00%]
[local count: 325681]:
@@ -364,8 +361,8 @@
ivtmp.132_245 = ivtmp.132_383 + 8;
[local count: 365933]:
- # ivtmp.132_383 = PHI
- if (ivtmp.132_383 != _480)
+ # ivtmp.132_383 = PHI
+ if (ivtmp.151_254 != ivtmp.132_383)
goto ; [89.00%]
else
goto ; [11.00%]
that already causes quite some assembler changes :/
It's still not clear what goes wrong here.
Interestingly again, -fstack-reuse=none avoids the issue. So maybe the
above hints at 'bf' being the issue here:
Partition 3: size 56 align 16
av au bf
Partition 5: size 56 align 16
av
Partition 1: size 44 align 16
at
Partition 2: size 8 align 8
au
[Bug rtl-optimization/102446] [10/11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Richard Biener changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11 Regression] wrong |wrong code at -O3 on|code at -O3 on |x86_64-linux-gnu|x86_64-linux-gnu Keywords||needs-bisection Known to work||12.1.1, 13.0 Known to fail||11.3.1 --- Comment #15 from Richard Biener --- It no longer fails on trunk and the branch. What fixed it? Still broken on the GCC 11 branch.
[Bug ipa/101839] [10/11/12/13 Regression] Hang in C++ code with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839 --- Comment #7 from Richard Biener --- Honza?
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #11 from Giulio Benetti --- And it shows up on gcc 12.1.0 too.
[Bug tree-optimization/106475] Loop vectorizer prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475 --- Comment #1 from Richard Biener --- The loop seems to be vectorized just fine? The issue is just that we need a runtime alias check because of the variable stride and the fact that we need a VF of two to fill up to 16 byte vectors: .L5: movq(%rcx), %xmm1 movq(%rdx), %xmm0 addl$1, %esi movhps (%rcx,%r10), %xmm1 movhps (%rdx,%r9), %xmm0 addq%r14, %rcx addq%r13, %rdx paddb %xmm1, %xmm0 paddb %xmm2, %xmm0 movq%xmm0, (%rax) movhps %xmm0, (%rax,%rdi) addq%r12, %rax cmpl%esi, %r15d jne .L5 movl%ebp, %eax andl$-2, %eax andl$1, %ebp je .L1 .L4: imulq %rax, %r10 imulq %rax, %r9 imulq %rdi, %rax movq(%rbx,%r10), %xmm0 movq(%r8,%r9), %xmm1 paddb %xmm1, %xmm0 movq.LC1(%rip), %xmm1 paddb %xmm1, %xmm0 movq%xmm0, (%r11,%rax) yes, the BB vectorization result is smaller but only uses half of a vector: .L3: movq(%r8), %xmm0 movq(%rdx), %xmm1 addl$1, %ecx addq%rdi, %rdx addq%rsi, %r8 paddb %xmm1, %xmm0 paddb %xmm2, %xmm0 movq%xmm0, (%rax) addq%r10, %rax cmpl%ecx, %r11d jne .L3
[Bug rtl-optimization/102446] [10/11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | --- Comment #16 from Jakub Jelinek --- On the trunk r13-1186-ga0c30fe3b888f20215f and that has been backported in r12-8523-g9e72a522dd9f835dd15.
[Bug rtl-optimization/102446] [10/11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446 --- Comment #17 from Jakub Jelinek --- So dup or related to PR106032.
[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #5 from dave.anglin at bell dot net --- On 2022-07-28 4:12 a.m., rguenth at gcc dot gnu.org wrote: > Can you check trunk / the gcc 12 branch head? Test fails in the same way with trunk.
[Bug tree-optimization/106476] New: ICE generating FOLD_EXTRACT_LAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106476 Bug ID: 106476 Summary: ICE generating FOLD_EXTRACT_LAST Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ams at gcc dot gnu.org CC: rguenther at suse dot de Target Milestone: --- Target: amdgcn-amdhsa Commit 8f4d9c1deda "amdgcn: 64-bit not" exposed an ICE in tree-vect_stmts.cc when compiling gcc.dg/torture/pr67470.c at -O2 for amdgcn. The newly implemented op is not the problem, but it allows this optimization (and many others) to proceed, and the error is no longer hidden. amdgcn has masked vectors and fold_extract_last, which leads to a code path through tree-vect-stmts.cc that has vec_then_clause = vec_oprnds2[i]; if (reduction_type != EXTRACT_LAST_REDUCTION) vec_else_clause = vec_oprnds3[i]; and then /* Instead of doing ~x ? y : z do x ? z : y. */ vec_compare = new_temp; std::swap (vec_then_clause, vec_else_clause); and finally new_stmt = gimple_build_call_internal (IFN_FOLD_EXTRACT_LAST, 3, else_clause, vec_compare, vec_then_clause); in which vec_then_clause remains set to NULL_TREE. The dump shows e_lsm.16_32 = .FOLD_EXTRACT_LAST (e_lsm.16_8, _70, ); (note the last field is missing.) I can fix the ICE if I add "else vec_else_clause = integer_zero_node", but I'm not sure that is the correct logical solution. (CC Richi who touched this code last)
[Bug c++/106466] ICE in In function 'bool jxl_skcms_Parse(const void*, size_t, skcms_ICCProfile*)': at skcms/skcms.cc:1004:6 internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466 --- Comment #6 from tt_1 --- works with: gcc-10.3.0 gcc-10.3.1_p20211126 gcc-11.3.0 does not work with: gcc-10.4.0 the segfault is sort of spurious, its an about 1/5 to 1/7 chance for me. Is that something you can work with? and indeed these are two seperate segfaults, I got the -O1 from comment #4 now reproduced with -O2 as well
[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 --- Comment #15 from Michael_S --- (In reply to Richard Biener from comment #14) > (In reply to Michael_S from comment #12) > > On related note... > > One of the historical good features of gcc relatively to other popular > > compilers was absence of auto-vectorization at -O2. > > When did you decide to change it and why? > > Well, people requested it ... so GCC 12 is now having it (with an extra > eye on code size but this all doesn't work for scalar code vectorization > which OTOH is thought to almost always benefit code size ...). "People" is a vague term. You didn't organize voting among all gcc users, I suppose. So, count me as "people" who asks to remove it. Somehow , I suspect that the other one who will vote like me has a middle name Benedict.
[Bug analyzer/106007] RFE: analyzer should complain about exec/system/putenv of tainted args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007 Tim Lange changed: What|Removed |Added CC||tlange at gcc dot gnu.org --- Comment #3 from Tim Lange --- (In reply to David Malcolm from comment #2) > Currently the taint analysis only has handling for numeric arguments being > bounds-checked. > > How can string arguments transition to a "sanitized" state? Or are string > arguments always tainted once they've acquired taint? Many papers introduce sanitizers/taint killers/... besides sources and sinks, which are also manually-defined methods. Two prime examples in webdev are XSS and SQL query escaping methods that do replace special characters such that the user input is not interpreted. I don't think you can automatically find out that a method is a sanitizer unless you would track the interesting part of the string on a byte-level.
[Bug tree-optimization/106475] Loop vectorizer prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475 --- Comment #2 from Christoph Müllner --- Yes, you are right! I haven't noticed that the longer sequence requires only half of the loop iterations when compared to the shorter sequence.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
If we follow what other backends do in *_output_mi_thunk, it would be
--- gcc/config/i386/i386.cc.jj 2022-07-26 10:32:23.373275765 +0200
+++ gcc/config/i386/i386.cc 2022-07-29 15:25:26.02341 +0200
@@ -21396,6 +21396,7 @@ x86_output_mi_thunk (FILE *file, tree th
tmp_regno = CX_REG;
}
+ reload_completed = 1;
emit_note (NOTE_INSN_PROLOGUE_END);
/* CET is enabled, insert EB instruction. */
@@ -21561,6 +21562,9 @@ x86_output_mi_thunk (FILE *file, tree th
final (insn, file, 1);
final_end_function ();
assemble_end_function (thunk_fndecl, fnname);
+
+ /* Stop pretending to be a post-reload pass. */
+ reload_completed = 0;
}
static void
Unfortunately, that doesn't help much, the next problem is that it needs
pic_offset_table_rtx as a hard register, so we probably before
tmp = gen_rtx_REG (word_mode, tmp_regno);
if (GET_MODE (fnaddr) != word_mode)
fnaddr = gen_rtx_ZERO_EXTEND (word_mode, fnaddr);
emit_move_insn (tmp, fnaddr);
fnaddr = tmp;
in the above mentioned snippet need to do something like:
if (flag_pic && !TARGET_64BIT && !TARGET_MACHO && SYMBOLIC_CONST
(fnaddr))
{
pic_offset_table_rtx = gen_reg_RTX (Pmode, some_suitable_reg);
ix86_init_pic_reg ();
}
or something similar. But unsure about the exact conditions,
insert_insn_on_edge will likely not work either etc.
So it likely needs emit_insn (gen_set_got (reg)) etc. directly.
}
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 106475, which changed state. Bug 106475 Summary: Loop vectorizer prevents vectorization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/106475] Loop vectorizer prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475 Christoph Müllner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Christoph Müllner --- Closing as invalid.
[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 53381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53381&action=edit gcc13-pr106079.patch Untested fix.
[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 --- Comment #6 from dave.anglin at bell dot net --- On 2022-07-29 8:50 a.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 > > --- Comment #5 from dave.anglin at bell dot net --- > On 2022-07-28 4:12 a.m., rguenth at gcc dot gnu.org wrote: >> Can you check trunk / the gcc 12 branch head? > Test fails in the same way with trunk. Aside from a couple of .stringz and .ident assembler statements, there is no difference in the assembly code generated by "GCC: (GNU) 13.0.0 20220728 (experimental) [master r13-1220-g7c1c7e120cc]" and "GCC: (Debian 12.1.0-7) 12.1.0".
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #5 from H.J. Lu ---
Here is the testcase:
---
void
bar(int *indices, int max_iter, int *actual_indices,
int *iters_per_dim, int N_dims)
{
int iter = 0;
int sum_indices = 0;
int flag, k;
while (iter < max_iter) {
for (k = N_dims - 1; k > 0; k--) {
sum_indices += actual_indices[k];
}
if (sum_indices >= max_iter) {
return;
}
iter++;
for (k = 0; k < N_dims; k++) {
if (indices[k] < iters_per_dim[k] - 1) {
indices[k]++;
break;
}
}
}
}
---
The second loop is unrolled after the commit.
[Bug target/99410] Nios II Error: branch offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99410 --- Comment #9 from Giulio Benetti --- This bug shows up with gcc 11.3.0 and 12.1.0
[Bug libstdc++/106477] New: With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
Bug ID: 106477
Summary: With -fno-exception operator new(nothrow) aborts
instead of returning null
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijs at stdin dot nl
Target Milestone: ---
The nothrow version of operator new is intended to return null on allocation
failure. However, when libstdc++ is compiled with -fno-exceptions, it aborts
instead.
The cause of this failure is that the nothrow operators work by calling the
regular operators, catching any allocation failure exception and turning that
into a null return. However, with -fno-exceptions, the regular operator aborts
instead of throwing, so the nothrow operator never gets a chance to return
null.
Originally, this *did* work as expected, because the nothrow operators would
just call malloc directly. However, as reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 this violates the C++11
requirement that the nothrow versions must call the regular versions (so
applications can replace the regular version and get the nothrow for free), so
this was changed in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b66e5a95c0065fda3569a1bfd3766963a848a00d
Note this comment by Jonathan Wakely in the linked report, which actually
already warns against introducing the behavior I am describing (but the comment
was apparently not considered when applying the fix):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210#c2
In any case, we have two conflicting requirements:
1. nothrow operators should return null on failure
2. nothrow operators should call regular operators
I can see no way to satisfy both. Since -fno-exceptions is already violating
the spec, it would make sense to me to, when -fno-exceptions is specified, only
satisfy 1 and allow 2 to be violated (which is more of a fringe case anyway,
and applications can always replace the nothrow versions too to get the
behavior they need).
Essentially this would mean that with -fno-exceptions, the nothrow versions
would have to call malloc again directly like before (either duplicating code
like before, or maybe introducing a null-returning helper function?).
To reproduce, I made a small testcase. I was originally seeing this in the
Arduino environment on an Atmel samd chip, but I made a self-contained testcase
and tested that using gcc from https://developer.arm.com (using the linker
script from Atmel/Arduino), which is compiled with -fno-exceptions.
The main testcase is simple: An _sbrk() implementation that always fails to
force allocation failure (overriding the default libnosys implementation that
always succeeds), and a single call to operator new that should return null,
but aborts:
$ cat test.cpp
#include
volatile void* foo;
extern "C"
void *_sbrk(int n) {
// Just always fail allocation
return (void*)-1;
}
int main() {
// This should return nullptr, but actually aborts (with -fno-exceptions)
foo = new (std::nothrow) char[65000];
return 0;
}
In addition, I added a minimal startup.c for memory initialization and reset
vector and a linker script taken verbatim from
https://github.com/arduino/ArduinoCore-samd/raw/master/variants/arduino_zero/linker_scripts/gcc/flash_without_bootloader.ld
(I will attach both files next).
Compiled using:
$ ~/Downloads/gcc-arm-11.2-2022.02-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
-mcpu=cortex-m0plus -mthumb -g -fno-exceptions --specs=nosys.specs
--specs=nano.specs -Tflash_without_bootloader.ld -nostartfiles test.cpp
startup.c -lstdc++
Running this on the Arduino zero (using openocd and gdb to upload the code
through the EDBG port) shows it aborts:
Program received signal SIGINT, Interrupt.
_exit (rc=rc@entry=1) at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/_exit.c:16
16
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/_exit.c:
No such file or directory.
(gdb) bt
#0 _exit (rc=rc@entry=1) at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/_exit.c:16
#1 0x013a in abort () at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/stdlib/abort.c:59
#2 0x0128 in operator new (sz=65000) at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/libstdc++-v3/libsupc++/new_op.cc:54
#3 0x0106 in operator new[] (sz=) at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/libstdc++-v3/libsupc++/new_opv.cc:32
#4 0x00fe in operator new[] (sz=) at
/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/libstdc++-v3/libsupc++/new_opvnt.cc:38
#5 0x0034 in main () at test.cpp:17
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #1 from Matthijs Kooijman --- Created attachment 53382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53382&action=edit Testcase - main code
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #2 from Matthijs Kooijman --- Created attachment 53383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53383&action=edit Testcase - startup code
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #3 from Matthijs Kooijman --- Created attachment 53384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53384&action=edit Testcase - linker script for ATSAMD21G18 (Arduino zero)
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment #8 from Matthijs Kooijman --- Note that in comment:2, Jonathan Wakely pointed out a caveat: > Also we certainly don't want to conform to the new requirement when > libstdc++ is built with -fno-exceptions, because allocation failure > would abort in operator new(size_t) and so the nothrow version never > gets a chance to handle the exception and return null. But this was not taken into account when implementing the fix for this issue, meaning nothrow operators are now effectively useless with -fno-exceptions (and there is thus no way to handle allocation failure other than aborting in that case). I created a new bug report about this here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
[Bug tree-optimization/106474] DCE depends on how if expressions are nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474 --- Comment #2 from Andrew Macleod --- (In reply to Richard Biener from comment #1) > For the failing case we see > >: > if (c_5(D) == s_6(D)) > goto ; [INV] > else > goto ; [INV] > >: > if (c_5(D) != 0) > goto ; [INV] > else > goto ; [INV] > >: > if (s_6(D) != 0) > goto ; [INV] > else > goto ; [INV] > > and we basically fail to thread 2->3->4->6, eliminating the if (s_6(D) != 0) > branch when c_5(D) == s_6(D) and c_5(D) == 0. > > It looks like relations / equivalences related, but maybe not exactly. > Andrew? it is related. Due to the expense, we don't evaluate every equivalence at every use point. In this case, there was no obvious "trigger" when we see s_6 != 0 to go query all of the equivalences to see if they have ranges. However range_from_dom () is now quite efficient and has a "read-only" mode where it will make a DOM query without filling the cache. I am experimenting with having the on-entry cache fill also invoke range_from_dom on equivalences in read-only mode to see if any existing equivalence value can improve the range. The initial protoype reduces that test case in EVRP from : _1 = ~c_7(D); _2 = (int) _1; _3 = ~s_8(D); _4 = (int) _3; if (c_7(D) == s_8(D)) goto ; [INV] else goto ; [INV] : if (c_7(D) != 0) goto ; [INV] else goto ; [INV] : if (s_8(D) != 0) goto ; [INV] else goto ; [INV] : DCEMarker0_ (); : return; to : _1 = ~c_7(D); _2 = (int) _1; _3 = ~s_8(D); _4 = (int) _3; return; Let me run some performance numbers and see what the result is to see if there is any throtteling needed or not.
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-07-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68210 --- Comment #4 from Jonathan Wakely --- Yes, I've been meaning to revisit this for years. I thought there was another bug report about it already, but I can't find one now.
[Bug c++/106478] New: GCC rejects valid code involving partial specialization of variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106478
Bug ID: 106478
Summary: GCC rejects valid code involving partial
specialization of variable template
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program is incorrectly rejected by gcc. This can be verified
here: https://godbolt.org/z/f4c3d9voa
```
template
struct A
{
static constexpr std::size_t B = 1;
template
static constexpr std::size_t C = 4;
template
static constexpr std::size_t C = B; //rejected by msvc and gcc
};
int main()
{
int i = A::C;
return 0;
}
```
The error for gcc says:
:13:34: error: explicit template argument list not allowed
13 | static constexpr std::size_t C = B; //rejected by msvc and gcc
[Bug analyzer/106479] New: FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106479 Bug ID: 106479 Summary: FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-linux* Target: hppa*-*-linux* Build: hppa*-*-linux* Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c -fdia gnostics-plain-output -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summar ies -S -o pr104308.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/obj dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c -fdiagn ostics-plain-output -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o pr104308.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c: In function 'te st_memcpy_from_uninit': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c:18:11: warning: use of uninitialized value '*(unsigned char (*)[5])(&a2[0])' [CWE-457] [-Wanalyz er-use-of-uninitialized-value] /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c:17:8: note: (1) region created on stack here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr104308.c:18:11: note: (2) use of uninitialized value '*(unsigned char (*)[5])(&a2[0])' here FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 9) FAIL: gcc.dg/analyzer/pr104308.c (test for warnings, line 10) PASS: gcc.dg/analyzer/pr104308.c (test for warnings, line 17) PASS: gcc.dg/analyzer/pr104308.c (test for warnings, line 18) PASS: gcc.dg/analyzer/pr104308.c (test for excess errors) dave@atlas:~/gnu/gcc/objdir/gcc$ ./xgcc -B. -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-multiarch --enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-13 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu --enable-checking=release --enable-languages=c,c++,d,objc,fortran,obj-c++,ada,lto --without-ppl --enable-libssp --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220728 (experimental) [master r13-1220-g7c1c7e120cc] (GCC)
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 --- Comment #6 from Henry --- > This sanitizer is stupid. That is an unjust comment on great work from the LLVM team. An unsigned overflow in user code is almost always a bug due to some oversight, there is no denying that. Look at Arianne 5 for an example. The community at large (aka "the users") might have very low priority on your priorities list but as there is no way to turn off "unsigned-integer-overflow" for specific includes, they have to turn off these checks on user code as well. It has a significant impact on us. But its your project at the end of the day.
[Bug tree-optimization/106480] New: FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for warnings, line 33)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106480
Bug ID: 106480
Summary: FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for
warnings, line 33)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Target Milestone: ---
Host: hppa*-*-linux*
Target: hppa*-*-linux*
Build: hppa*-*-linux*
FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for warnings, line 33)
FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for warnings, line 133)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c
-fdiagnostics-plain-output -O2 -Wall -S -o Warray-bounds-48.s
In function 'warn_ax_local',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:63:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:22:8: warning:
array subscript 0 is outside array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:62:15: note:
defined here 'sax'
In function 'warn_ax_local',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:63:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:23:8: warning:
array subscript 1 is outside array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:62:15: note:
defined here 'sax'
In function 'warn_ax_local_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:77:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:35:8: warning:
array subscript 2 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
In function 'warn_ax_local_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:77:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:36:8: warning:
array subscript 3 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
In function 'warn_ax_local_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:77:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:37:8: warning:
array subscript 4 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
In function 'warn_ax_extern_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:85:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:44:8: warning:
array subscript 3 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
In function 'warn_ax_extern_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:85:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:45:8: warning:
array subscript 4 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:17:11: note:
while referencing 'ax'
In function 'warn_ax_extern_buf',
inlined from 'test_ax' at
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:85:5:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:46:8: warning:
array subscript 5 is above array bounds of 'int16_t[]' {aka 'short int[]'}
[-Warray-bounds]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c: In function
'test_ax':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/Warray-bounds-48.c:
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 John David Anglin changed: What|Removed |Added Build|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu ||hppa-unknown-linux-gnu Host|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu ||hppa-unknown-linux-gnu CC||danglin at gcc dot gnu.org Target|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu ||hppa-unknown-linux-gnu --- Comment #2 from John David Anglin --- Also fails on hppa: FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -Wc++-compat scan-sarif-file "text": " int u6587u5b57u5316u3051 =
[Bug libstdc++/106469] Undefined behavior triggered on Mersenne Twister engine due to unsigned integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469 --- Comment #7 from Andrew Pinski --- "An unsigned overflow" does not exist. That is the point here. And that is why this sanitizer is bogus and should never be used. And yes overflow wrapping is sometimes a bug in the code but if the code depends on the wrapping behavior then it is wrong to complain about it. C and c++ requires wrapping behavior for unsigned types. This option is bogus and should be removed even from llvm.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #4 from H.J. Lu --- We don't have available scratch registers in 32-bit mode for x86_output_mi_thunk.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #5 from Jakub Jelinek --- So, shall we temporarily disable -mforce-indirect-call during the mi thunk output?
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 --- Comment #6 from H.J. Lu --- (In reply to Jakub Jelinek from comment #5) > So, shall we temporarily disable -mforce-indirect-call during the mi thunk > output? Something like this diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index e03f86d4a23..394fcac53a2 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -21382,6 +21382,7 @@ x86_output_mi_thunk (FILE *file, tree thunk_fndecl, HOST_WIDE_INT delta, rtx this_reg, tmp, fnaddr; unsigned int tmp_regno; rtx_insn *insn; + int saved_flag_force_indirect_call = flag_force_indirect_call; if (TARGET_64BIT) tmp_regno = R10_REG; @@ -21394,6 +21395,9 @@ x86_output_mi_thunk (FILE *file, tree thunk_fndecl, HOST_WIDE_INT delta, tmp_regno = DX_REG; else tmp_regno = CX_REG; + + if (flag_pic) + flag_force_indirect_call = 0; } emit_note (NOTE_INSN_PROLOGUE_END); @@ -21561,6 +21565,8 @@ x86_output_mi_thunk (FILE *file, tree thunk_fndecl, HOST_WIDE_INT delta, final (insn, file, 1); final_end_function (); assemble_end_function (thunk_fndecl, fnname); + + flag_force_indirect_call = saved_flag_force_indirect_call; } static void
[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079 --- Comment #3 from seurer at gcc dot gnu.org --- I tried the patch on trunk and it fixed the failure. I am trying a full make check there and with gcc 12.
[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-07-29 Status|UNCONFIRMED |ASSIGNED Version|12.0|13.0 --- Comment #2 from David Malcolm --- I've been prototyping an implementation of this; marking as assigned.
[Bug other/106429] Building GCC is Inhibited on old Linux Distributions due to the use of "#!/bin/bash"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #5 from Martin Vahi --- Created attachment 53385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53385&action=edit Console Output of the Bash Version Related GCC Build Failure ... gmake[1]: Entering directory '/opt/andmekettad/magnet_465GiB_01/home/ts3b/tmp_/test/demobuild/autogenerated_tmp/ GCC_v_11_2_0/gcc/x86_64-linux-gnu/libgcc' /bin/bash: -/: invalid option Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings ...
[Bug other/106429] Building GCC is Inhibited on old Linux Distributions due to the use of "#!/bin/bash"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #6 from Martin Vahi --- Created attachment 53386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53386&action=edit List of changes that allow temporary use of an alternative Bash binary. Too old Bash version: GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu) Bash version that was tested to work after applying the changes to the GCC code: GNU bash, version 5.1.0(1)-release (x86_64-pc-linux-gnu)
[Bug other/106429] Building GCC is Inhibited on old Linux Distributions due to the use of "#!/bin/bash"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #7 from Andrew Pinski --- (In reply to Martin Vahi from comment #5) > Created attachment 53385 [details] This is a failure while "make clean". And your patch does not even touch anything related to libgcc and "make clean". So this is a different issue from what you reported.
[Bug other/106429] Building GCC is Inhibited on old Linux Distributions due to the use of "#!/bin/bash"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #8 from Martin Vahi --- Thank You for the answers/replies. As of 2022_07_30 I am not familiar with the GCC source code, nor do I know the GCC build system, but as someone, who can do configure-make-make_install, I have the following observations: observation_0) The build fails with Bash 4.3.48, as described at the console output at one of the attached text-files. observation_1) If I use Bash 5.1.0 with the GCC code changes that are described at another attachment/txt/diff file, then the build completes without any errors that I would easily notice on console. It's up to GCC developers to figure out, how things _should_ or _should_not_ be, but that's how I fixed it for myself and it would probably help others like me, if they didn't have to re-do the text changes in the files listed at the attached diff-file. Probably people smarter than me can figure out, which of the changes are actually necessary or may be the smarter people, possibly You, can come up with some different kind of code-change that just throws out the use of Bash features that are present at the 5.1.0 and missing from the 4.3.48, but there is the "risk" that at some point someone comes up with some code that still uses some features that are specific to some newer version of Bash and some people might use even older Bash versions than the 4.3.48. The GCC code and build scripts that I used has been packaged to ~1.2GiB (~8GiB after unpacking wrapped xz) 2022_07_24_created_GCC_bugreport_106429_optional_appendix_01_SHA256_68f6aa8ec04f4adbd31c89e35597b2dbbfce9718ec0b801c4a40ac2dd8ad1767.tar which MIGHT be downloadable from (Folder view.) https://1fichier.com/dir/uiRZKGsU (Direct link to tar-file.) https://1fichier.com/?qe2en1n9bh6ixl6669pi Inside the tar-file the ./demobuild/autogenerated_tmp/GCC_v_11_2_0/gcc includes all files as they were/are right after the failed build. Actually the use case that I described here for custom-building GCC is just one of the 2 use-cases that I have had. Initially I wrote the ./demobuild/try_to_compile_it.bash for building Linux kernel for the Windows Linux layer, the WSL. I know that the way I use Git at https://github.com/martinvahi/mmmv_notes/tree/master/mmmv_notes/usage_demos/WSL2_Microsoft_Kernel_installation_notes_t1/WSL1_2_WSL2_upgrade_option_02_hard_and_errorprone/src/GCC/mmmv_repackaging_GCC_v_11_2_0_WSL_AMD64_t1_v02.tar.xz.file_pieces is plain horrible and that "no decent person does that", but I like to organize projects into folders and that's how I could shove the whole GCC building related part to my Git repository while keeping the number of files at my repository relatively small. Thank You for the answers/replies and thank You for reading my comment.
[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079 --- Comment #4 from seurer at gcc dot gnu.org --- The patch causes a bunch of new failures: FAIL: gfortran.dg/c-interop/allocatable-dummy.f90 -Os execution test FAIL: gfortran.dg/c-interop/allocate-errors.f90 -O0 execution test FAIL: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O1 execution test FAIL: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90 -O2 execution test FAIL: gfortran.dg/c-interop/cf-descriptor-3.f90 -O2 execution test FAIL: gfortran.dg/c-interop/cf-descriptor-7.f90 -Os execution test FAIL: gfortran.dg/c-interop/contiguous-3.f90 -O0 execution test Though it did fix these: FAIL: gfortran.dg/c-interop/fc-descriptor-6.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O0 execution test FAIL: gfortran.dg/boz_15.f90 -O1 execution test FAIL: gfortran.dg/boz_15.f90 -O2 execution test FAIL: gfortran.dg/boz_15.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/boz_15.f90 -O3 -g execution test FAIL: gfortran.dg/boz_15.f90 -Os execution test
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED Summary|Building GCC is Inhibited |make clean in libgcc fails |on old Linux Distributions | |due to the use of | |"#!/bin/bash" | --- Comment #9 from Andrew Pinski --- As I mentioned this is unrelated to bash version. "make clean" is failing so reopening for that issue. clean in libgcc/Makefile.in is defined as: clean: -rm -f libgcc_tm.h libgcc.map -rm -f libgcc_tm.stamp stmp-ldirs -rm -f *$(objext) -rm -f *.dep -rm -f *.a -rm -f libunwind$(SHLIB_EXT) -rm -f libgcc_s* @$(MULTICLEAN) multi-clean DO=clean
[Bug other/106429] make clean in libgcc fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429 --- Comment #10 from Andrew Pinski --- It should be noted almost nobody does "make clean" really. Most just remove the build directory instead. Is there a reason why you build scripts are doing "make clean"?
[Bug target/106481] New: [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106481 Bug ID: 106481 Summary: [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 53387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53387&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop testcase.c -Wno-psabi testcase.c:13:1: internal compiler error: in native_encode_rtx, at simplify-rtx.cc:6884 13 | } | ^ 0x7857b6 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int) /repo/gcc-trunk/gcc/simplify-rtx.cc:6884 0x16f2feb optimize_constant_pool /repo/gcc-trunk/gcc/varasm.cc:4437 0x16fcbff output_shared_constant_pool() /repo/gcc-trunk/gcc/varasm.cc:4544 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1895-20220729130134-g6e0ca3fe88d-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-1895-20220729130134-g6e0ca3fe88d-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220729 (experimental) (GCC)
