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:
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
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
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++;
}
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113424
Krister Walfridsson changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from
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:
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
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
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
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 =
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
Krister Walfridsson changed:
What|Removed |Added
CC||kristerw at gcc dot gnu.org
---
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:
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
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:
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,
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
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:
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:
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:
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:
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:
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
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
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:
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
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
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,
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
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
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/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:
47 matches
Mail list logo
