[Bug target/115217] Register pairs can't be encoded in RISC-V inline asm blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115217 --- Comment #1 from Andrew Pinski --- Note aarch64's TImode is always allocated in starting in even number registers (starting in GCC 9: https://inbox.sourceware.org/gcc-patches/20181002161915.18843-10-richard.hender...@linaro.org/ ) .
[Bug c++/115216] operator auto() gets instantiatied too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115216 --- Comment #2 from Andrew Pinski --- MSVC and ICC (EDG in GCC compat mode) also rejects the code for the same reason as GCC. Are you sure this is not a clang issue?
[Bug c++/115216] operator auto() gets instantiatied too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115216 --- Comment #1 from Andrew Pinski --- Created attachment 58281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58281=edit testcase Next time please attach the testcase or place it inline rather than just a link to godbolt.
[Bug tree-optimization/115210] Missed optimization opportunity in redundant copies for large structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115210 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 14295 ***
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295 Andrew Pinski changed: What|Removed |Added CC||user202729 at protonmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 115210 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/115210] Missed optimization opportunity in redundant copies for large structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115210 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208 Andrew Pinski changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 115213 has been marked as a duplicate of this bug. ***
[Bug bootstrap/115213] [15 regression] Excessive memory use compiling rust with 32-bit gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115213 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- I am going to say this is a dup for now. *** This bug has been marked as a duplicate of bug 115208 ***
[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization Target Milestone|--- |15.0
[Bug sanitizer/115205] ICE when using -fsanitize=hwaddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #4 from Andrew Pinski ---
I think this will fix it:
```
diff --git a/gcc/asan.cc b/gcc/asan.cc
index 9e0f51b1477..c684ca6d366 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -4276,6 +4276,7 @@ asan_instrument (void)
{
if (hwasan_sanitize_p ())
{
+ initialize_sanitizer_builtins ();
transform_statements ();
return 0;
}
```
Let me test that.
[Bug sanitizer/115205] ICE when using -fsanitize=hwaddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205 Andrew Pinski changed: What|Removed |Added Component|fortran |sanitizer --- Comment #3 from Andrew Pinski --- Someone is missing calling initialize_sanitizer_builtins . Maybe it is in the sanitizers.
[Bug fortran/115205] ICE when using -fsanitize=hwaddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205 Andrew Pinski changed: What|Removed |Added Component|sanitizer |fortran Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-24 --- Comment #2 from Andrew Pinski --- BUILT_IN_HWASAN_STORE8 is not being built. This is a fortran front-end issue after all. gfc_init_builtin_functions should be handling the sanitizers.
[Bug tree-optimization/114273] `PHI(a, MIN(b, c)) < c` is not optimized to just `PHI(a,b) < c`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114273 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-23 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed via the dup.
[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831 Andrew Pinski changed: What|Removed |Added CC||mkretz at gcc dot gnu.org --- Comment #42 from Andrew Pinski --- *** Bug 115204 has been marked as a duplicate of this bug. ***
[Bug target/115204] unnecessary stack usage and copies (of temporaries)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115204 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 28831 ***
[Bug target/115204] unnecessary stack usage and copies (of temporaries)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115204 --- Comment #2 from Andrew Pinski --- I am 99% sure there is a dup of this bug already.
[Bug tree-optimization/115035] Missed optimization: fold min/max in phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115035 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 114273 ***
[Bug tree-optimization/114273] `PHI(a, MIN(b, c)) < c` is not optimized to just `PHI(a,b) < c`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114273 Andrew Pinski changed: What|Removed |Added CC||xxs_chy at outlook dot com --- Comment #1 from Andrew Pinski --- *** Bug 115035 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/115202] [11/12/13/14/15 Regression] Missed optimization: std::min(f ? (unsigned short)m : a, ~0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115202
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.2|11.5
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-05-23
Summary|[14/15 Regression] Missed |[11/12/13/14/15 Regression]
|optimization: std::min(f ? |Missed optimization:
|(unsigned short)m : a, ~0) |std::min(f ? (unsigned
||short)m : a, ~0)
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed.
Here is a reduced testcase:
```
unsigned short m;
template
const T min(const T a, const T b)
{
if (a < b)
return a;
return b;
}
unsigned short func(int a, int f) {
return min(f ? m : a, ~0);
}
```
The above is a regression from GCC 8 where in GCC 9 adds an early phiopt.
And here is a version which is not a regression:
```
unsigned short m;
template
inline const T min(const T a, const T b)
{
return a < b ? a : b;
}
unsigned short func(int a, int f) {
return min(f ? m : a, ~0);
}
```
The real issue is we don't optimize MIN, -1>.
>From the IR:
```
# RANGE [irange] int [0, 65535] MASK 0x VALUE 0x0
iftmp.0_6 = (intD.9) m.1_1;
;;succ: 4 [always] count:536870912 (estimated locally, freq 0.5000)
(FALLTHRU,EXECUTABLE)
;; basic block 4, loop depth 0, count 1073741824 (estimated locally, freq
1.), maybe hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred: 3 [always] count:536870912 (estimated locally, freq 0.5000)
(FALLTHRU,EXECUTABLE)
;;2 [50.0% (guessed)] count:536870912 (estimated locally, freq
0.5000) (FALSE_VALUE,EXECUTABLE)
# iftmp.0_2 = PHI
# RANGE [irange] int [-INF, -1]
_7 = MIN_EXPR ;
```
Obviously here `MIN_EXPR ` for the iftmp.0_6 part of the PHI, it will be
-1.
[Bug target/115010] m68k: invalid subl instruction generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010 --- Comment #15 from Andrew Pinski --- (In reply to Thorsten Otto from comment #14) > A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit: > > commit 512c6ba04102295fccc62a173ee0086ca733c920 > From: Richard Biener > Date: Thu, 12 Nov 2020 11:29:12 +0100 > Subject: [PATCH] Avoid PRE insert iteration when possible That just shows it is a latent bug really since that touches gimple level and not further down the pipeline of RTL.
[Bug rtl-optimization/115081] find thie PR will cause ICE: Modify cost calculation for dealingf with equivalaennces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115081 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #5 from Andrew Pinski --- dbxout_* (-gstabs) support was removed in GCC 13 by r13-2361-g7e0db0cdf01e9c so backporting a change which was not tested in something before GCC 13, will most likely also need fixes in code which has since been removed. So I am not shocked there is an ICE in code which has since been removed. It is not upstream GCC's job to handle random backporting of changes to random versions of GCC.
[Bug target/111949] combine split points are not so good with targets that have (and (not x) y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111949
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=115086
Last reconfirmed||2024-05-23
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Mine. very similar to PR 115086, at least for:
```
int f1(int a, unsigned char b)
{
int c = a & b;
return (c ^ a)&1;
}
```
[Bug tree-optimization/115201] Recursion not optimized for structs arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > /* The parameter should be a real operand, so that phi node >created for it at the start of the function has the meaning >of copying the value. This test implies is_gimple_reg_type >from the previous condition, however this one could be >relaxed by being more careful with copying the new value >of the parameter (emitting appropriate GIMPLE_ASSIGN and >updating the virtual operands). */ > > So this has been a known issue for a long time now. Actually this is the correct one: /* Make sure there are no problems with copying. The parameter have a copyable type and the two arguments must have reasonably equivalent types. The latter requirement could be relaxed if we emitted a suitable type conversion statement. */ That has been there since tree-ssa was merged in.
[Bug tree-optimization/115201] Recursion not optimized for structs arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 Andrew Pinski changed: What|Removed |Added Keywords||FIXME See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=17749 --- Comment #7 from Andrew Pinski --- /* The parameter should be a real operand, so that phi node created for it at the start of the function has the meaning of copying the value. This test implies is_gimple_reg_type from the previous condition, however this one could be relaxed by being more careful with copying the new value of the parameter (emitting appropriate GIMPLE_ASSIGN and updating the virtual operands). */ So this has been a known issue for a long time now.
[Bug tree-optimization/115201] Recursive binary search with struct iterator is not handled by tail Recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 --- Comment #6 from Andrew Pinski --- Created attachment 58274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58274=edit Slightly more reduced Slightly more reduced, foo3 should produce the same as foo4. Basically Tailr does not handle recusive calls with struct arguments really.
[Bug tree-optimization/115201] Recursive binary search with struct iterator is not handled by tail Recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2024-05-23 --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug ipa/115201] Recursive binary search is incorrectly inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 --- Comment #4 from Andrew Pinski --- Created attachment 58273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58273=edit Better (reduced testcase) The tail call happens in the foo2 case while not in foo1. This is due to struct returns are not always handled for tail call ..
[Bug ipa/115201] Recursive binary search is incorrectly inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 --- Comment #3 from Andrew Pinski --- Oh the issue is the iterator is a struct which confuses things ...
[Bug ipa/115201] Recursive binary search is incorrectly inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |ipa --- Comment #1 from Andrew Pinski --- I suspect this is way GCC recursive inlining works and it is working correctly. While LLVM does not do any recursive inlining (anywhere).
[Bug middle-end/115100] non-target specific const_scalar_int_operand predicate is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115100 --- Comment #1 from Andrew Pinski --- >This has been true since wide-int branch was merged in back in 2014. Actually older than that. I had missed understood the diff there. But still not documented.
[Bug rtl-optimization/115104] [15 Regression] RISC-V: GCC-14 can combine vsext+vadd -> vwadd but Trunk GCC (GCC 15) Failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115104 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-22 Keywords||missed-optimization, ||testsuite-fail Ever confirmed|0 |1 Summary|RISC-V: GCC-14 can combine |[15 Regression] RISC-V: |vsext+vadd -> vwadd but |GCC-14 can combine |Trunk GCC (GCC 15) Failed |vsext+vadd -> vwadd but ||Trunk GCC (GCC 15) Failed CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 --- Comment #5 from Andrew Pinski --- .
[Bug tree-optimization/115125] [-Wstringop-overflow=] with O2/O3 - false positive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115125 Andrew Pinski changed: What|Removed |Added Known to work||15.0 Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Seems to be fixed on the trunk ...
[Bug tree-optimization/115125] [-Wstringop-overflow=] with O2/O3 - false positive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115125 --- Comment #2 from Andrew Pinski --- (In reply to Nikolai Ivanenko from comment #1) > Forgot to mention that the the code commented out in main compiles without > warnings. That is just due to inlining differences. Afterwards if you rename main to f and change the return type to void, you get back the warnings. GCC is less agressive at inlining into main (unless the call is inside a loop) as GCC knows that function call is only happens once.
[Bug c++/115198] Class template argument deduction fails for copy ctor when used with an alias template if the aliased class template has explicitly defaulted copy ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115198 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Last reconfirmed||2024-05-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/115199] [15 regression] gettext (libtextstyle) testsuite miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115199
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org
Keywords||alias
Last reconfirmed||2024-05-22
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
Confirmed.
```
Deleted dead call: # .MEM_6 = VDEF <.MEM_4>
# PT = null { D.2790 }
# ALIGN = 8, MISALIGN = 0
e_7 = memcpyD.1670 (f_5, "z", 1);
```
Note the volatile makes the difference. It seems like we miss that the memory
escapes through the volatile store so we delete the memcpy as being dead.
[Bug c++/115198] Class template argument deduction fails for copy ctor when used with an alias template if the aliased class template has explicitly defaulted copy ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115198 Andrew Pinski changed: What|Removed |Added URL|https://sigcpp.godbolt.org/ | |z/jjGT8hK8d | --- Comment #1 from Andrew Pinski --- https://sigcpp.godbolt.org/z/jjGT8hK8d
[Bug other/115189] libiberty introduces UNC paths waking up binutils bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189 Andrew Pinski changed: What|Removed |Added Host||*-*-mingw --- Comment #1 from Andrew Pinski --- I am not sure if there is anything to be done on the GCC side really.
[Bug c++/115187] [14/15 Regression] ICE when deleting temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115187 Andrew Pinski changed: What|Removed |Added Keywords|accepts-invalid,| |ice-on-invalid-code | --- Comment #4 from Andrew Pinski --- I am not 100% sure this is invalid code either. It is definitely undefined code if it is semantically valid code though.
[Bug c++/115187] [14/15 Regression] ICE when deleting temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115187
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> clang complains:
>
> t.ii:3:7: error: cannot delete expression of type 'T' (aka 'int[2]')
> 3 | delete T{};
> | ^ ~~~
But that might be due to not doing `prvalue array decay`. See PR
94264 which I think introduced the ICE here.
[Bug tree-optimization/115191] [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-22 --- Comment #4 from Andrew Pinski --- Confirmed. /* After the optimization PHI result can have value which it couldn't have previously. */ int_range_max r; if (get_global_range_query ()->range_of_expr (r, phires, phi)) Yes int_range_max here is almost definitely wrong for pointer types. Note this code is originally from r13-4878-g3d6bb832022160 .
[Bug target/95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958 Bug 95958 depends on bug 102171, which changed state. Bug 102171 Summary: vget_low_*/vget_high_* intrinsics should become BIT_FIELD_REF during gimple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102171 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/102171] vget_low_*/vget_high_* intrinsics should become BIT_FIELD_REF during gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102171 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug c++/115196] Bad error message when using library functions from versions before they were introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Already fixed. Dup of bug 107800. *** This bug has been marked as a duplicate of bug 107800 ***
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Andrew Pinski changed: What|Removed |Added CC||luigighiron at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 115196 has been marked as a duplicate of this bug. ***
[Bug c++/115195] [12 Regression] Segfault when instantiating template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115195 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241#c5 is a reduced version of comment #0 here.
[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Andrew Pinski changed: What|Removed |Added CC||patrick at rivosinc dot com --- Comment #14 from Andrew Pinski --- *** Bug 115195 has been marked as a duplicate of this bug. ***
[Bug c++/115195] [12 Regression] Segfault when instantiating template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115195 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 109241. *** This bug has been marked as a duplicate of bug 109241 ***
[Bug c++/115195] [12 Regression] Segfault when instantiating template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115195 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 114303.
[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115188 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115153, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111235 Target|arm |arm-eabi --- Comment #1 from Andrew Pinski --- At first I thought it was the same failure as PR 115153 but it is different.
[Bug tree-optimization/115191] [15 regression] ICE when building stklos (in verify_range, at value-range.cc:1526)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |15.0 Version|unknown |15.0
[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #4 from Andrew Pinski ---
: In function 'main':
:8:57: warning: initializer-string for array of 'char' is too long for
C++ [-Wc++-compat]
8 | static const char description[][5] = {[hello] = "hello"};
| ^~~
There is a patch floating around to add it as a different option besides just
C++-compat too:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651664.html
[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #2 from Andrew Pinski --- It is included in -Wc++-compat .
[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185 --- Comment #1 from Andrew Pinski --- Note in c, "abc" is valid for [3] initializer . This is different from c++. There is a dup of this bug already filed asking to add the warning. I think it was added but it is not included in either -Wextra nor -Wall.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11666 --- Comment #12 from Andrew Pinski --- So GCC behavior changed in 2003 to match more of what Java requires ...
[Bug c++/115181] [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Not a regression, the ICE only happens with checking turned on.
[Bug c++/115181] [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #1 from Andrew Pinski --- gcc_checking_assert (DECL_TINFO_P (decl) || DECL_FNAME_P (decl));
[Bug c++/115179] Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576#c10 gives an example of how to use the new feature which was added for GCC 14.
[Bug target/105576] x86: Support a machine constraint to get raw symbol name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576 Andrew Pinski changed: What|Removed |Added CC||paul_robinson at playstation dot s ||ony.com --- Comment #13 from Andrew Pinski --- *** Bug 115179 has been marked as a duplicate of this bug. ***
[Bug c++/115179] Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup, already added. *** This bug has been marked as a duplicate of bug 105576 ***
[Bug c++/115178] false positive computed goto jump warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115178 --- Comment #1 from Andrew Pinski --- So for this warning GCC does not keep track of what the possible values can be done for the computed gotos. GCC thinks all labels which have their address can be taken are targets for a computed goto as a simple way to implement this warning (it is also done that way for the CFG later on too).
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- (In reply to Cristian Rodríguez from comment #6) > I found it in executable made with current GCC HEAD on x86_64.. > > It is sufficient to demonstrate with the example code here > > https://en.cppreference.com/w/c/program/atexit > > ggcc-15 -march=native -Wall -Wextra -O2 -g -fPIE (or -fPIC) -fhardened > -fno-plt example.c > > > 1172: call 1040 <__cxa_finalize@plt> > 11fd: jmp1050 <__cxa_atexit@plt> That is coming from already compiled code in crt*.o. __cxa_finalize is from __do_global_dtors_aux in crtstuff.c from libgcc. This is not from newly compiled code that you used -fno-plt with.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 --- Comment #12 from Andrew Pinski --- Also will add an internal function which will be used for vectorization.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481
--- Comment #11 from Andrew Pinski ---
The builtins I am going to implement to be similar to clang:
__builtin_bitreverse{8,16,32,64,g}
The g one is not part of clang but will be used for _BitInt types.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Keywords||missed-optimization Status|NEW |ASSIGNED --- Comment #10 from Andrew Pinski --- I am going to implement this. and add an optab too.
[Bug target/115176] rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-21 --- Comment #1 from Andrew Pinski --- that is from aarch64-simd.md: ``` (define_insn "aarch64_rbit" [(set (match_operand:VB 0 "register_operand" "=w") (unspec:VB [(match_operand:VB 1 "register_operand" "w")] UNSPEC_RBIT))] "TARGET_SIMD" "rbit\\t%0., %1." [(set_attr "type" "neon_rbit")] ) ``` >From aarch64.md: ``` (define_insn "@aarch64_rbit" [(set (match_operand:GPI 0 "register_operand" "=r") (unspec:GPI [(match_operand:GPI 1 "register_operand" "r")] UNSPEC_RBIT))] "" "rbit\\t%0, %1" [(set_attr "type" "rbit")] ) ```
[Bug target/115176] New: rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176 Bug ID: 115176 Summary: rbit pattern should use bitreverse rtl now Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While looking at some code I noticed that it uses clang's __builtin_bitreverse8 builtin and looking at the aarch64 backend, I noticed the rbit patterns don't use bitreverse but still an UNSPEC. We should be able to change the pattern to use the rtl now.
[Bug tree-optimization/115175] [15 Regression] GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking,
||ice-on-valid-code
--- Comment #1 from Andrew Pinski ---
// We sometimes get compatible types copied from operands, make sure
// the correct type is being returned.
if (name && TREE_TYPE (name) != r.type ())
{
gcc_checking_assert (range_compatible_p (r.type (), TREE_TYPE (name)));
range_cast (r, TREE_TYPE (name));
}
[Bug tree-optimization/115175] [15 Regression] GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |15.0 Summary|GCC fails to bootstrap with |[15 Regression] GCC fails |--with-build-config='bootst |to bootstrap with |rap-O3 bootstrap-lto' at|--with-build-config='bootst |r15-698-g38d1761c0c94b7 |rap-O3 bootstrap-lto' at ||r15-698-g38d1761c0c94b7
[Bug tree-optimization/115143] [11/12 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Known to fail||13.3.0 Summary|[11/12/13 Regression] tree |[11/12 Regression] tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85 Target Milestone|13.4|11.5 Known to work||13.3.1 --- Comment #16 from Andrew Pinski --- Fixed on the GCC 13 branch too. Backporting further requires removing the hunk that handles diamond bbs as that was not in 12 or 11. I will handle that tomorrow.
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Known to fail||14.1.0 Known to work||13.3.1, 14.1.1, 15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Andrew Pinski --- Fixed on all branches, sadly it barely didn't make it for the just released GCC 13.3.0.
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/92853 --- Comment #5 from Andrew Pinski --- Filed as: https://github.com/llvm/llvm-project/issues/92853
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |MOVED --- Comment #4 from Andrew Pinski --- So I looked and I see clang is using @plt though. So gcc is doing the correct thing but clang is not, please report it to them.
[Bug libstdc++/102916] cmath constexpr can lead to ODR violations/incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916 Andrew Pinski changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #14 from Andrew Pinski --- *** Bug 115171 has been marked as a duplicate of this bug. ***
[Bug c++/115171] Constant evaluation of math.h functions in C++ against constexpr.functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115171 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. we decided not to fix this issue since they become constexpr in C++23 in the end ... *** This bug has been marked as a duplicate of bug 102916 ***
[Bug c++/88602] Consider adding ext_vector_type for better clang compatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602 --- Comment #5 from Andrew Pinski --- (In reply to Jean-Michaël Celerier from comment #4) > Another vote for this. It's used in the KFR DSP library which for this > reason gets restricted to clang in some configurations... > > Compare > > https://github.com/kfrlib/kfr/blob/main/include/kfr/simd/impl/backend_clang. > hpp > > and > > https://github.com/kfrlib/kfr/blob/main/include/kfr/simd/impl/ > backend_generic.hpp Hmm, backend_clang.hpp does not use the .xyzw syntax (or anything that is not supported by GCC's normal vector, it only uses __builtin_shufflevector (since GCC 12) and __builtin_convertvector (since GCC 9) both which have been supported in GCC for a few releases already. So it could just use vector_size there instead. Something like: ``` template using simd = unwrap_bit __attribute__((vector_size(NN*sizeof(unwrap_bit; ``` And use the header for GCC >= 12.1.0
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 --- Comment #3 from Andrew Pinski --- aarch64-linux-gnu with my example I don't see a call via plt here either: PIC: ``` adrpx0, __dso_handle add x2, x0, :lo12:__dso_handle adrpx1, :got:f;ldr x1, [x1, :got_lo12:f] adrpx0, :got:_ZN1sD1Ev;ldr x0, [x0, :got_lo12:_ZN1sD1Ev] adrpx3, :got:__cxa_atexit;ldr x3, [x3, :got_lo12:__cxa_atexit] blr x3 nop ldp x29, x30, [sp], 16 ``` PIE: ``` adrpx0, __dso_handle add x2, x0, :lo12:__dso_handle adrpx0, f add x1, x0, :lo12:f adrpx0, :got:_ZN1sD1Ev;ldr x0, [x0, :got_lo12:_ZN1sD1Ev] adrpx3, :got:__cxa_atexit;ldr x3, [x3, :got_lo12:__cxa_atexit] blr x3 nop ldp x29, x30, [sp], 16 ```
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 --- Comment #2 from Andrew Pinski --- Also provide the testcase which you see this with too.
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed||2024-05-21
--- Comment #1 from Andrew Pinski ---
I tried the simple example:
```
struct s
{
~s();
};
s f;
```
With `-fPIC -fno-plt` (and `-fPIE -fno-plt`) on x86_64-linux-gnu and don't get
a call to @plt.
PIE:
```
leaq__dso_handle(%rip), %rax
movq%rax, %rdx
leaqf(%rip), %rax
movq%rax, %rsi
movq_ZN1sD1Ev@GOTPCREL(%rip), %rax
movq%rax, %rdi
call*__cxa_atexit@GOTPCREL(%rip)
nop
popq%rbp
```
PIC:
```
leaq__dso_handle(%rip), %rax
movq%rax, %rdx
movqf@GOTPCREL(%rip), %rax
movq%rax, %rsi
movq_ZN1sD1Ev@GOTPCREL(%rip), %rax
movq%rax, %rdi
call*__cxa_atexit@GOTPCREL(%rip)
nop
popq%rbp
```
can you provide what target you are targetting and what exact version of GCC?
[Bug tree-optimization/115149] [15 Regression] ICE on valid code at -O3 with "-fno-inline -fno-tree-vrp -fno-ipa-sra -fno-tree-dce -fno-tree-ch" on x86_64-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115149 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-21 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. We are sinking the load of c back into the (infinite) loop and not updating the vuse here.
[Bug target/115169] [14/15 regression] ICE in loongarch bootstrap with checking: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115169
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |14.2
Status|UNCONFIRMED |NEW
Summary|[14 regression] ICE in |[14/15 regression] ICE in
|loongarch bootstrap with|loongarch bootstrap with
|checking: RTL check:|checking: RTL check:
|expected code 'reg', have |expected code 'reg', have
|'const_int' in rhs_regno, |'const_int' in rhs_regno,
|at rtl.h:1934 |at rtl.h:1934
Last reconfirmed||2024-05-21
--- Comment #5 from Andrew Pinski ---
Confirmed via visual inspecting the code:
```
(define_expand "movcc"
[(set (match_operand:GPR 0 "register_operand")
(if_then_else:GPR (match_operator 1 "comparison_operator"
[(match_operand:GPR 2 "reg_or_0_operand")
(match_operand:GPR 3 "reg_or_0_operand")])))]
```
```
rtx op0 = XEXP (operands[1], 0);
rtx op1 = XEXP (operands[1], 1);
...
if ((REGNO (op0) == REGNO (operands[2])
|| (REGNO (op1) == REGNO (operands[3]) && (op1 != const0_rtx)))
&& (GET_MODE_SIZE (GET_MODE (op0)) < word_mode))
{
```
There is no check to make sure op0/op1/operands[2]/operands[3] are registers
before calling REGNO on them.
This code was introduced by r14-3511-gc28c579f0dd9cd .
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/652 ||209.html --- Comment #14 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652209.html
[Bug tree-optimization/115143] [11/12/13 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13/14/15 Regression] |[11/12/13 Regression] tree |tree check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85 Known to work||14.1.1, 15.0 --- Comment #13 from Andrew Pinski --- Fixed so far on the trunk and gcc-14 branches. Waiting for GCC 13.3.0 release to backport (unless approved tomorrow for the branch).
[Bug target/115166] RISC-V: flakey relocation truncated to fit: R_RISCV_GPREL_I against `.LANCHOR1' in slp_run-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115166 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=27566 --- Comment #1 from Andrew Pinski --- This seems more likely a binutils issue (like https://sourceware.org/bugzilla/show_bug.cgi?id=27566 ).
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #13 from Andrew Pinski --- Created attachment 58249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58249=edit Patch which I am testing
[Bug c++/115159] internal compiler error: in nothrow_spec_p, at cp/except.cc:1206 when using modules and QCoreApplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115159 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #12 from Andrew Pinski --- Created attachment 58247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58247=edit Easier to (reduced) understand testcase
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110165, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110166, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105835 --- Comment #11 from Andrew Pinski --- (In reply to Sam James from comment #5) > (In reply to Andrew Pinski from comment #3) > > I wonder if my r13-7434-g682bbd364708fe exposed the issue. > > And then r14-3432-gddd64a6ec3b38e "fixed" it (on accident). > > Yeah, r13-7434-g682bbd364708fe is the first bad commit on releases/gcc-13. > > I'll bisect for the "fix" now.
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Known to work|14.1.0 | Summary|[13 Regression] wrong code |[13/14/15 Regression] wrong |at optimization levels -O2, |code at optimization levels |-O3, -Os since |-O2, -O3, -Os since |r13-7434-g682bbd364708fe|r13-7434-g682bbd364708fe --- Comment #10 from Andrew Pinski --- This works and might be the best for GCC 13/14 but maybe I think we can do better. ``` diff --git a/gcc/match.pd b/gcc/match.pd index 0f9c34fa897..6bc512cabdf 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -2400,7 +2400,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (convert (mult@0 zero_one_valued_p@1 INTEGER_CST@2)) (if (INTEGRAL_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (@0)) - && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@0))) + && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@0)) + && (TYPE_UNSIGNED (type) || TYPE_PRECISION (type) > 1)) (mult (convert @1) (convert @2 /* (X << C) != 0 can be simplified to X, when C is zero_one_valued_p. ``` For bit 1 precision, look at the lower bit of the INTEGER_CST and decide if it should be @1 or `0` and that would avoid the overflow too. Note you can reproduce the failure on the trunk and GCC 14 by using -fsanitize=undefined which I missed in the original bug report and that is because r14-3432-gddd64a6ec3b38e is disable for undefined sanitizers case.
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #9 from Andrew Pinski --- Matching expression match.pd:2310, gimple-match-3.cc:90 Matching expression match.pd:2310, gimple-match-3.cc:90 Applying pattern match.pd:4890, gimple-match-2.cc:4798 Matching expression match.pd:160, gimple-match-10.cc:33 Matching expression match.pd:2243, gimple-match-5.cc:20 Matching expression match.pd:160, gimple-match-10.cc:33 Applying pattern match.pd:5024, gimple-match-7.cc:13241 Applying pattern match.pd:2404, gimple-match-2.cc:4387 gimple_simplified to _32 = () _2; _29 = -_32; The problem match pattern (r13-1162-g9991d84d2a8435) is: ``` /* Narrow integer multiplication by a zero_one_valued_p operand. Multiplication by [0,1] is guaranteed not to overflow. */ (simplify (convert (mult@0 zero_one_valued_p@1 INTEGER_CST@2)) (if (INTEGRAL_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (@0)) && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@0))) (mult (convert @1) (convert @2 ``` _36 = _27 * 5; _29 = () _36; We go from `()(_27 *5)` to `(()_27) * -1` which does overflow. The only case where is an overflow is `signed:1` so we should reject that I think.
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #8 from Andrew Pinski --- ``` Optimizing statement _5 = () _2; LKUP STMT _5 = nop_expr _2 2>>> STMT _5 = nop_expr _2 Optimizing statement _3 = -_5; LKUP STMT _3 = negate_expr _5 2>>> STMT _3 = negate_expr _5 Optimizing statement f.b = _3; Replaced '_3' with constant '0' ``` So Dom decided it was always 0 as -signed:1 is undefined otherwise. The IR is fine in .ccp: ``` _27 = (int) si1_34; _36 = _27 * 5; _29 = () _36; f.b = _29; ``` Then in forwprop it is broken: ``` _32 = () _2; _29 = -_32; f.b = _29; ```
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection |wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-19 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski --- (In reply to Sam James from comment #6) > yep, r14-3432-gddd64a6ec3b38e fixed it on trunk So that is not the correct fix really. It just works around the bad ir/bug. Tomorrow I will look into the correct fix. -a is not well defined for signed:1 and something created it which was wrong. There was a few other fixes in this area that fixed stuff like this too which was done due to detection of lowering vectors.
[Bug target/115158] pru: undefined reference to _getentropy after r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 --- Comment #1 from Andrew Pinski --- Hmm, _GLIBCXX_HAVE_GETENTROPY maybe should not defined for PRU while configuring libstdc++ ...
[Bug c++/115159] internal compiler error: in nothrow_spec_p, at cp/except.cc:1206 when using modules and QCoreApplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115159 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-05-19 --- Comment #1 from Andrew Pinski --- The preprocessed source didn't attach, maybe it was too big. Can you compress it and try again? Also I think we will need the preprocessed source for the module `photoDeltaFetchingBenchmarks` too.
[Bug sanitizer/115156] [14/15 Regression] passing zero to __builtin_clzl() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115156 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.2 Summary|[14 Regression] passing |[14/15 Regression] passing |zero to __builtin_clzl()|zero to __builtin_clzl() |check missing |check missing
[Bug sanitizer/115156] [14 Regression] passing zero to __builtin_clzl() check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115156 --- Comment #1 from Andrew Pinski --- I am not 100% sure this if this case matters as the return value of __builtin_clzl is very much unused.
[Bug sanitizer/108256] Missing integer overflow instrumentation when assignment LHS is narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256 Andrew Pinski changed: What|Removed |Added CC||bic60176 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 115155 has been marked as a duplicate of this bug. ***
[Bug sanitizer/115155] [11/12 Regression] signed integer overflow check missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115155 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. This is not a regression. it was specifically fixed for GCC 13. *** This bug has been marked as a duplicate of bug 108256 ***
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #3 from Andrew Pinski --- I wonder if my r13-7434-g682bbd364708fe exposed the issue. And then r14-3432-gddd64a6ec3b38e "fixed" it (on accident).
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Known to work||13.1.0, 14.1.0 Keywords||needs-bisection Target Milestone|--- |13.3 Known to fail||13.2.0 --- Comment #2 from Andrew Pinski --- It was caused by something that was backported to GCC 13 for GCC 13.2.0 too. It works in GCC 14.1.0 and the trunk for me.
[Bug tree-optimization/115154] [13 Regression] wrong code at optimization levels -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Summary|[13/14 Regression] wrong|[13 Regression] wrong code |code at optimization levels |at optimization levels -O2, |-O2, -O3, -Os |-O3, -Os --- Comment #1 from Andrew Pinski --- This is fixed in GCC 14. I think it was one of my match.pd patches and it might be backported already to the GCC 13 branch. Let me look.
