[llvm-bugs] [Bug 44185] New: Can't remove shufflevector if input might be poison
https://bugs.llvm.org/show_bug.cgi?id=44185
Bug ID: 44185
Summary: Can't remove shufflevector if input might be poison
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Keywords: miscompilation
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nunoplo...@sapo.pt
CC: efrie...@quicinc.com, llvm-bugs@lists.llvm.org,
reg...@cs.utah.edu, spatel+l...@rotateright.com,
zhengy...@kuf.io
Test case from Transforms/InstCombine/insert-extract-shuffle.ll:
define <4 x float> @insert_not_undef_shuffle_translate_commute(float %x, <4 x
float> %y, <4 x float> %q) {
%xv = insertelement <4 x float> %q, float %x, i32 2
%r = shufflevector <4 x float> %y, <4 x float> %xv, <4 x i32> { 0, 6, 2,
undef }
ret <4 x float> %r
}
=>
define <4 x float> @insert_not_undef_shuffle_translate_commute(float %x, <4 x
float> %y, <4 x float> %q) {
%r = insertelement <4 x float> %y, float %x, i32 1
ret <4 x float> %r
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
float %x = poison
<4 x float> %y = < poison, poison, poison, poison >
<4 x float> %q = < poison, poison, poison, poison >
Source:
<4 x float> %xv = < poison, poison, poison, poison >
<4 x float> %r = < poison, poison, poison, undef >
Target:
<4 x float> %r = < poison, poison, poison, poison >
Source value: < poison, poison, poison, undef >
Target value: < poison, poison, poison, poison >
This is with the semantics of LangRef, where an undef mask stops propagation of
poison. This implies this kind of shufflevectors can't be removed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44186] New: Incorrect instcombine transform urem -> icmp+zext with vectors
https://bugs.llvm.org/show_bug.cgi?id=44186
Bug ID: 44186
Summary: Incorrect instcombine transform urem -> icmp+zext with
vectors
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Keywords: miscompilation
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nunoplo...@sapo.pt
CC: lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
reg...@cs.utah.edu, spatel+l...@rotateright.com
Testcase from Transforms/InstCombine/vector-urem.ll:
define <4 x i32> @test_v4i32_one_undef(<4 x i32> %a0) {
%1 = urem <4 x i32> { 1, 1, 1, undef }, %a0
ret <4 x i32> %1
}
=>
define <4 x i32> @test_v4i32_one_undef(<4 x i32> %a0) {
%1 = icmp ne <4 x i32> %a0, { 1, 1, 1, undef }
%2 = zext <4 x i1> %1 to <4 x i32>
ret <4 x i32> %2
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
<4 x i32> %a0 = < #x0010 (16), #x0001 (1), #x0400 (1024),
#x0001 (1) >
Source:
<4 x i32> %1 = < #x0001 (1), #x (0), #x0001 (1), #x (0)
>
Target:
<4 x i1> %1 = < #x1 (1), #x0 (0), #x1 (1), #x1 (1) >
<4 x i32> %2 = < #x0001 (1), #x (0), #x0001 (1), #x0001 (1)
>
Source value: < #x0001 (1), #x (0), #x0001 (1), #x (0)
>
Target value: < #x0001 (1), #x (0), #x0001 (1), #x0001 (1)
>
Essentially, "x urem 1" is 0 for any 'x'. However, the optimized code can
produce 0 or 1.
I guess the easiest fix is to change undef to 1 in the icmp.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 17461 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: Timeout in llvm-isel-fuzzer--wasm32-O2
Updates: Status: WontFix Comment #3 on issue 17461 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--wasm32-O2: Timeout in llvm-isel-fuzzer--wasm32-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17461#c3 ClusterFuzz testcase 5645320205107200 is flaky and no longer crashes, so closing issue. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44188] New: Wrong optimization of byte-by-byte copying of long doubles
https://bugs.llvm.org/show_bug.cgi?id=44188
Bug ID: 44188
Summary: Wrong optimization of byte-by-byte copying of long
doubles
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ch3r...@openwall.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Source code:
--
#include
int main()
{
long double x = 1, y = 0;
unsigned char *px = (unsigned char *)&x;
unsigned char *py = (unsigned char *)&y;
py[9] = px[9];
py[8] = px[8];
py[7] = px[7];
py[6] = px[6];
py[5] = px[5];
py[4] = px[4];
py[3] = px[3];
py[2] = px[2];
py[1] = px[1];
py[0] = px[0];
printf("y = %Lf\n", y);
}
--
Results:
--
$ clang -std=c11 -Weverything test.c && ./a.out
y = 1.00
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
y = inf
--
clang x86-64 version: clang version 10.0.0
(https://github.com/llvm/llvm-project.git
3f4b70c79e686117c2754d2c0a5a44c8b6829e79)
As I understand it, optimizer tracks the progress of assignments as actual long
double values and trips on intermediate results:
- initial x is 0xK3FFF8000;
- initial y is 0xK;
- after copying one byte (py[9] = px[9];) y should be 0xK3F00.
This is an unnormal (zero) and it's somehow changed to 0xK7FFF
(pseudo-infinity);
- final y is 0xK7FFF8000 (+infinity).
The problem is not that normalization of y went wrong. The problem is that,
during copying, the representation of y has changed outside of control of the
program.
And now the funny part -- DR 260[1] kinda blessed this behavior:
"
Committee Response
Question 1:
Values may have any bit-pattern that validly represents them and the
implementation is free to move between alternate representations (for example,
it may normalize pointers, floating-point representations etc.). In the case of
an indeterminate value all bit-patterns are valid representations and the
actual bit-pattern may change without direct action of the program.
"
[1] http://open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
But IMO this shows that DR 260 Q1 is wrong, not that clang is right.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43748] Cannot link to Open MPI with ld.lld
https://bugs.llvm.org/show_bug.cgi?id=43748 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Fangrui Song --- A minimal reproduce: % touch a.f90 % mpifort -fuse-ld=lld a.f90 ld.lld: error: corrupt input file: version definition index 0 for symbol mpi_fortran_argv_null_ is out of bounds >>> defined in /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_usempif08.so ... I believe lld's rigorous behavior regarding VER_NDX_LOCAL is correct. Both openmpi and GNU ld have bugs. See https://sourceware.org/bugzilla/show_bug.cgi?id=25236 (common symbol: don't consider definitions in shared objects) and https://github.com/open-mpi/ompi/issues/7209 (mpi_fortran_argv_null_ has incorrect st_size in ompi/mpi/fortran/base/gen-mpi-mangling.pl) Fixing either bug can make the lld linking problem go away. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
