[llvm-bugs] [Bug 44318] New: Missed Store forwarding optimization as the Alias analysis failed to establish "noalias" information.
https://bugs.llvm.org/show_bug.cgi?id=44318
Bug ID: 44318
Summary: Missed Store forwarding optimization as the Alias
analysis failed to establish "noalias" information.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: venkataramanan.kumar.l...@gmail.com
CC: llvm-bugs@lists.llvm.org
Please consider the following test case.
---Snip--
struct B {
int b1;
int b2;
};
struct C {
int b1;
};
struct A {
int a1;
struct C SC;
int a2;
};
int foo1(struct A * Aptr, struct B* Bptr)
{
int *a = &Aptr->SC.b1;
*a=10;
Bptr->b1 = 11;
return *a;
}
int foo2(struct A * Aptr, struct B* Bptr)
{
Aptr->SC.b1=10;
Bptr->b1 = 11;
return Aptr->SC.b1;
}
---Snip--
For the function "foo1" return value is 10 and can be forwarded directly.
The alias analysis is not able establish the fact that memory accessed by "*a"
and "Bptr->b1" donot alias each other.
Hence the optimization is missed. There is no TBAA information formed for
"&Aptr->SC.b1" and we are not able to prove "noalias" using TBAA.
But for the function "foo2", the Alias analysis proved that "Aptr->SC.b1" and
"Bptr->b1" donot alias each other. TBAA has proper metadata for both the memory
accesses in this case. Here the return value is forwarded.
--
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 44319] New: warnings promoted to error via pragma can not be demoted to warning via pragma
https://bugs.llvm.org/show_bug.cgi?id=44319
Bug ID: 44319
Summary: warnings promoted to error via pragma can not be
demoted to warning via pragma
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: oliverh...@gmx.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Hello,
In the following piece of code Clang throws an error for the unused variable
even though it should only be a warning.
void func()
{
#pragma clang diagnostic error "-Wunused-variable"
#pragma clang diagnostic warning "-Wunused-variable"
int a = 0;
}
The above example of course does not make much sense, but the warning option
could have been set to error in an included file or in the same file somewhere
earlier.
According to a test within godbolt.org this broke with Clang 3.1 (it is a
warning on Clang 3.0).
A workaround is to demote the warning flag to ignored and then promote to
warning again.
void func()
{
#pragma clang diagnostic error "-Wunused-variable"
#pragma clang diagnostic ignored "-Wunused-variable"
#pragma clang diagnostic warning "-Wunused-variable"
int a = 0;
}
Compiling the following code with -Wunused-variable -Werror as command line
options works:
void func()
{
#pragma clang diagnostic warning "-Wunused-variable"
int a = 0;
}
In GCC it works without the ignore as expected.
void func()
{
#pragma GCC diagnostic error "-Wunused-variable"
#pragma GCC diagnostic warning "-Wunused-variable"
int a = 0;
}
Kind regards,
Oliver
--
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 42387] [C++] constexpr constructors for data types from -finclude-default-header
https://bugs.llvm.org/show_bug.cgi?id=42387 Sven van Haastregt changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Sven van Haastregt --- Committed rGdf5a905aa8a8: [OpenCL] Add ExtVectorElementExpr constant evaluation (PR42387). -- 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 44320] New: SSAUpdater corrupts SCEV
https://bugs.llvm.org/show_bug.cgi?id=44320
Bug ID: 44320
Summary: SSAUpdater corrupts SCEV
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: suc-dan...@yandex.ru
CC: llvm-bugs@lists.llvm.org
Created attachment 22940
--> https://bugs.llvm.org/attachment.cgi?id=22940&action=edit
CFG after loop unswitch
Consider following IR:
define void @foo(i32* %arg, i32* %arg1, i1 %cond1, i1 %cond2, i1 %cond3, i1
%cond4, i1 %cond5) {
bb:
br label %bb3
bb2: ; preds = %bb20
br label %bb3
bb3: ; preds = %bb2, %bb
br i1 %cond1, label %bb4, label %bb24
bb4: ; preds = %bb3
%tmp = load i32, i32* %arg
%tmp5 = load i32, i32* %arg1
%tmp6 = add i32 %tmp5, %tmp
%tmp7 = icmp sgt i32 %tmp6, %tmp
br i1 %tmp7, label %bb8, label %bb17
bb8: ; preds = %bb4
%tmp9 = and i1 %cond2, %cond3
br label %bb10
bb10: ; preds = %bb15, %bb8
%tmp11 = phi i32 [ %tmp12, %bb15 ], [ %tmp, %bb8 ]
%tmp12 = add nsw i32 %tmp11, 1
br i1 %tmp9, label %bb15, label %bb13
bb13: ; preds = %bb10
%tmp14 = phi i32 [ %tmp12, %bb10 ]
ret void
bb15: ; preds = %bb10
br i1 %cond4, label %bb10, label %bb16
bb16: ; preds = %bb15
br label %bb17
bb17: ; preds = %bb16, %bb4
%tmp18 = phi i32 [ 0, %bb4 ], [ %tmp5, %bb16 ]
br i1 %cond5, label %bb25, label %bb19
bb19: ; preds = %bb17
br label %bb20
bb20: ; preds = %bb20, %bb19
%tmp21 = phi i32 [ %tmp22, %bb20 ], [ 0, %bb19 ]
%tmp22 = add nuw nsw i32 %tmp21, 1
%tmp23 = icmp slt i32 %tmp22, %tmp18
br i1 %tmp23, label %bb20, label %bb2
bb24: ; preds = %bb3
ret void
bb25: ; preds = %bb17
ret void
}
Following command:
opt
-passes="verify,loop(unswitch),verify"
-S -o /dev/null -verify-scev-strict input.ll
completes with following error message:
Trip Count for Loop at depth 2 containing: %bb20
Changed!
Old: (-1 + (1 smax ((-1 * %.us-phi) + ((%tmp5 + %.us-phi) smax
%.us-phi
New: (-1 + (1 smax ((-1 * %tmp) + ((%tmp + %tmp5) smax %tmp
Delta: ((-1 * (1 smax ((-1 * %tmp) + ((%tmp + %tmp5) smax %tmp + (1
smax ((-1 * %.us-phi) + ((%tmp5 + %.us-phi) smax %.us-phi
(comment: %.us-phi is an alias of %tmp that doesn't dominate %bb20, %bb20 isn't
even reachable from the point where %.us-phi is defined; if that's unclear see
attached .svg CFG of the final IR)
Here's why:
To preserve LCSSA SimpleLoopUnswitch calls formLCSSA, which in some cases uses
SSAUpdater::RewriteUse. Even though SSAUpdater::RewriteUse rewrites only one
use, it calls ValueHandleBase::ValueIsRAUWd which in turn calls
CallbackVH::allUsesReplacedWith. SCEVUnknown::allUsesReplacedWith acts the way
that is correct if and only if all uses of the value are replaced (and given
the name of the method it makes complete sense), so it looks like
ValueHandleBase::ValueIsRAUWd shouldn't be called by SSAUpdater::RewriteUse at
all. Actually if I just remove the call to ValueHandleBase::ValueIsRAUWd the
bug goes away and `make check` completes successfully. Here's the catch: that
call was added by the following commit:
commit 8d804520766b6772277fcc1d9b31da02f320bc12
Author: Nadav Rotem
Date: Mon Aug 13 23:06:54 2012 +
LICM uses AliasSet information to hoist and sink instructions. However,
other passes, such as LoopRotate
may invalidate its AliasSet because SSAUpdater does not update the
AliasSet properly.
This patch teaches SSAUpdater to notify AliasSet that it made changes.
The testcase in PR12901 is too big to be useful and I could not reduce
it to a normal size.
rdar://11872059 PR12901
llvm-svn: 161803
I.e. AliasSetTracker relies on SSAUpdater to (incorrectly) call
ValueHandleBase::ValueIsRAUWd for every new instruction it adds, so we can't
simply remove that call since it will (probably) cause new bugs.
One way to fix it is to remove that call and invalidate AliasSet everywhere
where SSAUpdater is used, either directly or indirectly, but it goes against
what many efforts were aimed for (compile time improvements).
Another way is to introduce a new method, say CallbackVH::UseIsReplacedWith,
and its counterpart ValueHandleBase::UsesOfValueReplaced and call it in such
cases instead of ValueHandl
[llvm-bugs] [Bug 44321] New: InstCombine incorrectly folds 'gep(bitcast ptr), idx' into 'gep ptr, idx'
https://bugs.llvm.org/show_bug.cgi?id=44321
Bug ID: 44321
Summary: InstCombine incorrectly folds 'gep(bitcast ptr), idx'
into 'gep ptr, idx'
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
```
$ cat gep-vector.ll
define i32* @bitcast_vec_to_array_gep(<7 x i32>* %x, i64 %y, i64 %z) {
%arr_ptr = bitcast <7 x i32>* %x to [7 x i32]*
%gep = getelementptr [7 x i32], [7 x i32]* %arr_ptr, i64 %y, i64 %z
ret i32* %gep
}
$ opt -instcombine gep-vector.ll -S -o -
define i32* @bitcast_vec_to_array_gep(<7 x i32>* %x, i64 %y, i64 %z) {
%gep = getelementptr <7 x i32>, <7 x i32>* %x, i64 %y, i64 %z
ret i32* %gep
}
```
This is incorrect because DataLayout::getTypeAllocSize(< 7 x i32 >) and
getTypeAllocSize([ 7 x i32 ]) may differ.
This can be double-checked by emitting assembly code before/after optimization.
https://godbolt.org/z/xB-p5u
Before optimization, rax = rdi + 28 * rsi + 4 * rdx
After instcombine, rax = rdi + 32 * rsi + 4 * rdx.
--
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 17661 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: Timeout in llvm-isel-fuzzer--aarch64-gisel
Updates: Labels: Deadline-Approaching Comment #2 on issue 17661 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--aarch64-gisel: Timeout in llvm-isel-fuzzer--aarch64-gisel https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17661#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17663 in oss-fuzz: llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere
Updates: Labels: Deadline-Approaching Comment #2 on issue 17663 by sheriff...@chromium.org: llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17663#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17606 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in EvaluateValue
Updates: Labels: Deadline-Approaching Comment #2 on issue 17606 by sheriff...@chromium.org: llvm:clang-fuzzer: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17606#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17653 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: !isa(TI) && "Cannot split critical edge from IndirectBrInst"
Updates: Labels: Deadline-Approaching Comment #2 on issue 17653 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-gvn: ASSERT: !isa(TI) && "Cannot split critical edge from IndirectBrInst" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17653#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17667 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Timeout in llvm-isel-fuzzer--aarch64-O2
Updates: Labels: Deadline-Approaching Comment #2 on issue 17667 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--aarch64-O2: Timeout in llvm-isel-fuzzer--aarch64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17667#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17671 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: RC && "This value type is not natively supported!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 17671 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: RC && "This value type is not natively supported!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17671#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 17708 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: Deadline-Approaching Comment #2 on issue 17708 by sheriff...@chromium.org: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBaseSequenceChecker, void>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17708#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 40253] combined target teams implements shared clause as firstprivate
https://bugs.llvm.org/show_bug.cgi?id=40253 Joel E. Denny changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #2 from Joel E. Denny --- The reproducer I reported here still reproduces the bug for me at fbaf835c5c51. -- 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 44316] wasm32: Same symbol erroneously imported from the same module
https://bugs.llvm.org/show_bug.cgi?id=44316 Alex Crichton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Alex Crichton --- Ah ok, that makes sense! I was using stock LLVM 9 but looks like this was fixed after that. Thanks for the info! -- 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 44324] New: Difference with gcc's -Wmisleading-indentation
https://bugs.llvm.org/show_bug.cgi?id=44324 Bug ID: 44324 Summary: Difference with gcc's -Wmisleading-indentation Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: simon.mar...@polymtl.ca CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk clang++ 10 reports a misleading indentation warning with the attached code, whereas g++ does not. test.cpp:14:7: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] j = j; ^ test.cpp:11:4: note: previous statement is here if (k) ^ 1 warning generated. The warning is due to the presence of a spurious space at the beginning of line 12, before the tab. I don't really know if this should warn or not (or if there's even a right answer to this), but I thought I would report it so you can judge for yourself. I've been told [1]that gcc respects tab stops to compute the indentation. My understanding is that for gcc, "" and "" will both amount to 8 columns (using the default of -ftabstop=8), so it won't make a difference. [1] https://sourceware.org/ml/gdb-patches/2019-12/msg00751.html -- 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 44325] New: Wzero-as-null-pointer-constant warns when using `operator<=>`
https://bugs.llvm.org/show_bug.cgi?id=44325 Bug ID: 44325 Summary: Wzero-as-null-pointer-constant warns when using `operator<=>` Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: da...@doublewise.net CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk ``` #include auto b = 1 <=> 2 < 0; ``` Outputs: ``` :3:20: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] auto b = 1 <=> 2 < 0; ^ nullptr 1 warning generated. Compiler returned: 0 ``` See it live: https://godbolt.org/z/9a8cnD Technically, the warning is accurate. User code has a literal `0` that is being passed to a function accepting a `nullptr`. However, this is an implementation detail of the standard library and the intended interface for use (users should not use `nullptr` there), so we should not warn users for doing so (and definitely should not direct them to change their code). -- 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 44327] New: @sdiv3 and @sdiv5 tests in test/Transforms/InstCombine/exact.ll are miscompiles for undef
https://bugs.llvm.org/show_bug.cgi?id=44327
Bug ID: 44327
Summary: @sdiv3 and @sdiv5 tests in
test/Transforms/InstCombine/exact.ll are miscompiles
for undef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Noticed accidentally when looking at https://reviews.llvm.org/D71568 and trying
to ensure that the baseline udiv-by-select tests aren't miscompiles also.
define i32 @sdiv3(i32 %x) {
%0:
%y = sdiv i32 %x, 3
%z = mul i32 %y, 3
ret i32 %z
}
=>
define i32 @sdiv3(i32 %x) {
%0:
%1 = srem i32 %x, 3
%z = sub i32 %x, %1
ret i32 %z
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
i32 %x = undef
Source:
i32 %y = #x (0) [based on undef value]
i32 %z = #x (0)
Target:
i32 %1 = #x (0)
i32 %z = #x0001 (65536)
Source value: #x (0)
Target value: #x0001 (65536)
define i32 @sdiv5(i32 %x) {
%0:
%y = sdiv i32 %x, 3
%z = mul i32 %y, 4294967293
ret i32 %z
}
=>
define i32 @sdiv5(i32 %x) {
%0:
%1 = srem i32 %x, 3
%z = sub i32 %1, %x
ret i32 %z
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
i32 %x = undef
Source:
i32 %y = #x (0) [based on undef value]
i32 %z = #x (0)
Target:
i32 %1 = #x (0)
i32 %z = #x1000 (268435456)
Source value: #x (0)
Target value: #x1000 (268435456)
--
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 44328] New: clang and gcc disagree on output constraint
https://bugs.llvm.org/show_bug.cgi?id=44328
Bug ID: 44328
Summary: clang and gcc disagree on output constraint
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: ndesaulni...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Consider the following code:
void baz(void) {
register int y asm("rdx") = 0;
asm volatile ("mov 42, %0" : "=c"(y));
}
at -O2, GCC produces:
baz():
mov 42, %ecx
ret
while Clang produces
baz():# @baz()
movl42, %edx
retq
It's not clear to me that the input is even well formed, and I haven't found
code that relies on it yet (knock on wood), but it might be nice to match or
better yet error or warn the user that their code isn't really semantically
correct.
--
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 34717] LiveDebugValues won`t extend range across empty MachineBasicBlock
https://bugs.llvm.org/show_bug.cgi?id=34717 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED CC||v...@apple.com Status|NEW |RESOLVED --- Comment #3 from Vedant Kumar --- I think this was fixed in r343890 / https://reviews.llvm.org/D52921. -- 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 43981] arm64 global isel: LLVM ERROR: unable to legalize instruction: %2:_(s16), %3:_(s1) = G_UADDO %1:_, %4:_ (in function: slice)
https://bugs.llvm.org/show_bug.cgi?id=43981 Xiaoqing Wu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Xiaoqing Wu --- Fixed in a17619e0b097 (https://reviews.llvm.org/rGa17619e0b097) -- 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 44329] New: SimplifyCFG of empty WinEH cleanup pads doesn't handle lifetime.end correctly
https://bugs.llvm.org/show_bug.cgi?id=44329 Bug ID: 44329 Summary: SimplifyCFG of empty WinEH cleanup pads doesn't handle lifetime.end correctly Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: andrew.kay...@intel.com CC: llvm-bugs@lists.llvm.org Created attachment 22942 --> https://bugs.llvm.org/attachment.cgi?id=22942&action=edit Reproducer for SSA problem The SimplifyCFG utility doesn't correctly handle lifetime.end intrinsics when deleting empty WinEH cleanup pads. There are at least two issues. 1. The lifetime.end intrinsic is simply deleted with the empty cleanup pad. This leaves a path through the control graph in which a pointer appears to be alive longer than it should. 2. If the lifetime.end is the only user of a PHI node in the cleanup pad we will attempt to sink the PHI node into the cleanup pad's successor, which might not be dominated by the cleanup pad. If the PHI node had non-PHI users outside the cleanup pad this would be safe, but when the only user of the PHI node is a lifetime.end marker inside the cleanup pad it causes an SSA violation. The attached IR file reproduces the second problem. The first problem can be seen in the existing (as of 12/17/2019) SimplifyCFG/empty-cleanuppad.ll test (in f9). -- 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
