https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118540
Bug ID: 118540
Summary: RISC-V: ICE for unsupported target attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117688
--- Comment #3 from Krister Walfridsson ---
The test still fails for me when running on qemu with a compiler built from
today's source code (64d31343d4676d8ceef9232dcd33824bc2eff330).
FWIW, the function foo is generated as:
foo:
lui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118174
Bug ID: 118174
Summary: AArch64: Miscompilation at -O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117688
--- Comment #1 from Krister Walfridsson ---
Interestingly, the function is generated correctly if x is passed as a function
argument:
__attribute__ ((noipa)) void
foo2 (int8_t x)
{
int8_t minus;
_Bool overflow = __builtin_sub_overflow (x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117927
Bug ID: 117927
Summary: Invalid rotate optimization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117692
Bug ID: 117692
Summary: The VRP pass is introducing new signed integer
overflow
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117690
Bug ID: 117690
Summary: RISC-V: Constant is miscompiled by zba extension
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117688
Bug ID: 117688
Summary: RISC-V: Wrong code for .SAT_SUB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117195
Bug ID: 117195
Summary: Invalid IR after vectorization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117186
Bug ID: 117186
Summary: aarch64 wrong code for (a < b) < (b < a)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116355
Bug ID: 116355
Summary: switchconv introduces new signed overflow UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116120
Bug ID: 116120
Summary: Wrong code for (a ? x : y) != (b ? x : y)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114090
Bug ID: 114090
Summary: forwprop -fwrapv miscompilation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114056
Bug ID: 114056
Summary: ifcvt may introduce use of uninitialized variables
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Bug ID: 114032
Summary: ifcvt may introduce UB calls to __builtin_clz(0)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
--- Comment #3 from Krister Walfridsson ---
Oops. I messed up the test case... It "works", but the actual values does not
make sense...
The following is better:
int main()
{
long pgsz = sysconf (_SC_PAGESIZE);
void *p = mmap (NULL, pgsz *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
--- Comment #2 from Krister Walfridsson ---
Here is a runtime testcase:
#include
#include
#include
__attribute__((noipa))
void f1 (char *p, uintptr_t i, uintptr_t n)
{
p += i;
do
{
*p = '\0';
p += 1;
i++;
}
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
Bug ID: 113703
Summary: ivopts miscompiles loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
Bug ID: 113630
Summary: -fno-strict-aliasing introduces out-of-bounds memory
access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113590
Bug ID: 113590
Summary: The vectorizer introduces signed overflow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
Bug ID: 113588
Summary: The vectorizer is introducing out-of-bounds memory
access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113424
Krister Walfridsson changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Krister
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113424
Bug ID: 113424
Summary: lim fails to notice possible aliasing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112949
--- Comment #3 from Krister Walfridsson ---
The C program is obviously UB. But the optimization is done on GIMPLE, and it
is not obvious to me that the GIMPLE code is UB -- we have a function called
__builtin_clz that calls an internal function,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112949
Bug ID: 112949
Summary: evrp produces incorrect range for __builtin_clz
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
--- Comment #9 from Krister Walfridsson ---
I opened PR 112738 for the issue mentioned in comment 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
Bug ID: 112738
Summary: forwprop4 introduces invalid wide signed Boolean
values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Bug ID: 112736
Summary: vectorizer is introducing out of bounds memory access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
--- Comment #8 from Krister Walfridsson ---
I still see negation of a wide signed Boolean in the IR for this function. But
now it is forwprop4 that changes
_38 = (signed int) _16;
_43 = -_38;
_66 = () _43;
to
_56 = () _16;
_66 = -_5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
Bug ID: 111668
Summary: vrp2 introduces invalid wide Boolean values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
Krister Walfridsson changed:
What|Removed |Added
CC||kristerw at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111494
Bug ID: 111494
Summary: Signed overflow introduced by vectorizer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111280
Bug ID: 111280
Summary: CLZ(0) generated when CLZ_DEFINED_VALUE_AT_ZERO is
false
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111257
Bug ID: 111257
Summary: new signed overflow after vectorizer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
--- Comment #6 from Krister Walfridsson ---
One more similar case (that may be the same as comment #3):
int g;
void foo(int a, int b, int c, int d, int e)
{
if ((10 + a) * b)
{
g = (c || (g >> d)) << 1;
}
}
In this case, reass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110760
--- Comment #3 from Krister Walfridsson ---
(In reply to Andrew Pinski from comment #1)
> I thought we decided that vector types don't apply the overflow rules and
> always just wrap ...
That makes sense. But on the other hand, PR 110495 is a s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110760
Bug ID: 110760
Summary: slp introduces new wrapped arithmetic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110554
Bug ID: 110554
Summary: more invalid wide Boolean values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110541
Bug ID: 110541
Summary: Invalid VEC_PERM_EXPR mask element size
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
Bug ID: 110495
Summary: fre introduces signed wrap for vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487
Bug ID: 110487
Summary: invalid wide Boolean value
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110434
Bug ID: 110434
Summary: tree-nrv introduces incorrect CLOBBER(eol)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109626
Bug ID: 109626
Summary: forwprop introduces new signed multiplication UB
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
Bug ID: 108625
Summary: forwprop introduces new UB
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #4 from Krister Walfridsson ---
I misread the comment -- it describes a possible future improvement (that I
believe is not allowed). But the committed patch seems to be correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
--- Comment #8 from Krister Walfridsson ---
This fixed most of the rotate issues my translation validation tool found. I
assume the remaining issues are due to a different (but similar) bug, so I
opened Bug 108440 for those.
But the issue in B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #3 from Krister Walfridsson ---
Hmm. I think this is the "Y equal to B case" from bug 106523. I.e., the bugfix
is not correct...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #2 from Krister Walfridsson ---
No, bug 106523 is a different issue (I have tested with a compiler that has
that fixed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
Bug ID: 108440
Summary: rotate optimization may introduce new UB
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
--- Comment #3 from Krister Walfridsson ---
A similar case is
int r1, r2;
int foo(int a, int s1, int s2)
{
if (a & (1 << s1))
return r1;
if (a & (1 << s2))
return r1;
return r2;
}
where reassoc2 optimizes this to always shift by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106990
Bug ID: 106990
Summary: Missing TYPE_OVERFLOW_SANITIZED checks in match.pd
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
--- Comment #2 from Krister Walfridsson ---
This optimization is invalid if (int)1 << 33 is _not_ undefined behavior in
GIMPLE!
Consider an architecture where (int)1 << 33 evaluates to 0. foo(2, 1, 33)
evaluates to 0 for the original GIMPLE, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106885
Bug ID: 106885
Summary: -(a-b) is folded to b-a before the UBSAN pass is run
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
Bug ID: 106884
Summary: ifcombine may move shift so it shifts more than
bitwidth
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106883
Bug ID: 106883
Summary: SLSR may generate signed wrap
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106744
Bug ID: 106744
Summary: phiopt miscompiles min/max
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
Bug ID: 106523
Summary: forwprop miscompile
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
--- Comment #2 from Krister Walfridsson ---
(In reply to Andreas Schwab from comment #1)
> This subexpression has undefined behaviour: (((int64_t) 0xff) << 56).
I thought that was allowed in GCC as the manual says
(https://gcc.gnu.org/onlinedoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
Bug ID: 106513
Summary: bswap is incorrectly generated
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
59 matches
Mail list logo