[llvm-bugs] [Bug 123512] clang thread safety analysis does not take into account assert_exclusive_lock attribute
Issue
123512
Summary
clang thread safety analysis does not take into account assert_exclusive_lock attribute
Labels
Assignees
Reporter
krinkinmu
It seems like clang version 18 (specifically I tested it on 18.1.8) fails to take into account `assert_exclusive_lock`/`assert_capability` annotations.
Here is a minimal example I came up with that reproduces the issue for me:
```c++
#define GUARDED_BY(x) __attribute__((guarded_by(x)))
#define EXCLUSIVE_LOCKS_REQUIRED(...) __attribute__((exclusive_locks_required(__VA_ARGS__)))
#define LOCKABLE __attribute__((lockable))
#define EXCLUSIVE_LOCK_FUNCTION(...) __attribute__((exclusive_lock_function(__VA_ARGS__)))
#define UNLOCK_FUNCTION(...) __attribute__((unlock_function(__VA_ARGS__)))
#define ASSERT_EXCLUSIVE_LOCK(...) __attribute__((assert_exclusive_lock(__VA_ARGS__)))
struct LOCKABLE Lock {
void lock() EXCLUSIVE_LOCK_FUNCTION() {}
void unlock() UNLOCK_FUNCTION() {}
void assert() ASSERT_EXCLUSIVE_LOCK(this) {}
};
struct ComplexValue {
};
struct Parent {
Lock lock;
};
struct Child {
Child(Parent& p) : p(p) {}
const ComplexValue& value() ASSERT_EXCLUSIVE_LOCK(p.lock) {
p.lock.assert();
return data;
}
Parent &p;
ComplexValue data GUARDED_BY(p.lock);
};
```
When compiling this code with the following command:
```shell
clang++-18 -c -Wthread-safety -Wthread-safety-reference-return -Werror -std=c++20 test.cc
```
I get an error:
```
test.cc:25:12: error: returning variable 'data' by reference requires holding mutex 'p.lock' [-Werror,-Wthread-safety-reference-return]
25 | return data;
|^
1 error generated.
```
I understand that returning a reference to a protected variable in general might be incorrect, but in this case before returning the reference I call a function with `assert_exclusive_lock` annotation, so by the time we get to the return statement, clang should be able to figure out that the lock is being held.
Naturally, replacing `assert_exclusive_lock` with `exclusive_locks_required` attribute eliminates the warning. However, in more complex cases it might be hard for clang to figure out what locks are held in what contexts, so I want to help clang with putting asserts like this to let clang know that the lock is actually held, but it does not seem that clang takes those into account or derives anything from `exclusive_locks_required`, which seems wrong.
Is my understanding of the purpose of `exclusive_locks_required` annotation somehow incorrect?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123509] [BUG] LLVM ERROR: out of memory on WSL
Issue 123509 Summary [BUG] LLVM ERROR: out of memory on WSL Labels new issue Assignees Reporter kraudy Hi, i'm trying to implement a simple autograd in mojo, but i get this LLVM error. ```bash LLVM ERROR: out of memory Allocation failed [187884:187884:20250118,172648.512482:ERROR file_io_posix.cc:144] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2) [187884:187884:20250118,172648.512585:ERROR file_io_posix.cc:144] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2) Please submit a bug report to https://github.com/modularml/mojo/issues and include the crash backtrace along with all the relevant source codes. Stack dump: 0. Program arguments: mojo engine.mojo --debug-level = full #0 0x55add47e26bb llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) Signals.cpp:0:0 #1 0x55add47e0619 llvm::sys::RunSignalHandlers() Signals.cpp:0:0 #2 0x55add47e2d3d SignalHandler(int) Signals.cpp:0:0 #3 0x7f961c717520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7f961c76b9fc __pthread_kill_implementation ./nptl/./nptl/pthread_kill.c:44:76 #5 0x7f961c76b9fc __pthread_kill_internal ./nptl/./nptl/pthread_kill.c:78:10 #6 0x7f961c76b9fc pthread_kill ./nptl/./nptl/pthread_kill.c:89:10 #7 0x7f961c717476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #8 0x7f961c6fd7f3 abort ./stdlib/./stdlib/abort.c:81:7 #9 0x55add47b2da9 llvm::report_bad_alloc_error(char const*, bool) ErrorHandling.cpp:0:0 #10 0x55add47b2df5 (/home/kraudy/Mojo/mojo-grad/.magic/envs/default/bin/mojo+0x5715df5) #11 0x7f961cbff3e3 (anonymous namespace)::handle_oom(void* (*)(void*), void*, bool, bool) tcmalloc.cc:0:0 #12 0x7f961cc0e1a4 tcmalloc::allocate_full_cpp_throw_oom(unsigned long) tcmalloc.cc:0:0 #13 0x7f95a80063b5 mojo crashed! The system ```bash Linux Ubuntu 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux mojo version ``` More specific error ```bash terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted ``` This is the mojo issue: https://github.com/modular/mojo/issues/3958 Thanks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123534] [Flang] Compilation abnormally terminates when interface declaration of function in module is inconsistent with definition of function outside the module
Issue 123534 Summary [Flang] Compilation abnormally terminates when interface declaration of function in module is inconsistent with definition of function outside the module Labels flang Assignees Reporter ohno-fj ``` Version of flang : 20.0.0(f5a35a31bfe6cbc16bec0c130f2bb3632dbf1fbf)/AArch64 ``` The attached program is incorrect. `interface` declaration of `function (px6)` in `module` is inconsistent with definition of `function (px6)` outside the `module`. - The former: `result-name` is defined as a procedure pointer with an `interface-name` of x2. - The latter: `result-name` is defined as a procedure pointer with an `interface-name` of x2. and it is associated with the function x2. In the above case, a compilation terminates abnormally. This should be detected as an error during compilation. The following are the test program, Flang, Gfortran and ifx compilation/execution result. sngg520i_2.f90: ```fortran module mod interface function px6() result(r) interface function x2(i) result(r) character(i),pointer::r end function x2 end interface procedure (x2),pointer :: r end function px6 end interface procedure (x1),pointer :: p contains function x1(i) result(r) character(i),pointer::r allocate(r) r='12' end function x1 end module mod subroutine s1 use mod p=>px6() if (p(2)/='12')print *,3 end subroutine s1 program main call s1 print *,'pass' end program main function x2(i) result(r) character(i),pointer::r allocate(r) r='12' end function x2 function px6() result(r) interface function x2(i) result(r) character(i),pointer::r end function x2 end interface procedure (x2),pointer :: r r=>x2 end function px6 ``` ``` $ flang sngg520i_2.f90 fatal internal error: CHECK(symbol.has()) failed at /work/groups/ssoft/compiler/llvm/src/llvm-main/flang/lib/Semantics/mod-file.cpp(1783) PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +outline-atomics -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -resource-dir /work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/lib/clang/20 -mframe-pointer=non-leaf -o /tmp/sngg520i_2-e3167b.o -x f95-cpp-input sngg520i_2.f90 #0 0x40003ef271a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/groups/ssoft/compiler/llvm/aarch64/main-latest/lib/libLLVM.so.20.0git+0x59e71a0) #1 0x40003ef25228 llvm::sys::RunSignalHandlers() (/work/groups/ssoft/compiler/llvm/aarch64/main-latest/lib/libLLVM.so.20.0git+0x59e5228) #2 0x40003ef25380 SignalHandler(int) Signals.cpp:0:0 #3 0x4000345607a0 (linux-vdso.so.1+0x7a0) #4 0x400043da6274 raise (/lib64/libc.so.6+0x36274) #5 0x400043d90a2c abort (/lib64/libc.so.6+0x20a2c) #6 0x06d9de34 (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x6d9de34) #7 0x05fc41e4 (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc41e4) #8 0x05fc456c Fortran::semantics::SubprogramSymbolCollector::DoSymbol(Fortran::parser::CharBlock const&, Fortran::semantics::Symbol const&) (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc456c) #9 0x05fc4760 Fortran::semantics::SubprogramSymbolCollector::DoParamValue(Fortran::semantics::ParamValue const&) (.part.5305) mod-file.cpp:0:0 #10 0x05fc4630 Fortran::semantics::SubprogramSymbolCollector::DoSymbol(Fortran::parser::CharBlock const&, Fortran::semantics::Symbol const&) (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc4630) #11 0x05fc45dc Fortran::semantics::SubprogramSymbolCollector::DoSymbol(Fortran::parser::CharBlock const&, Fortran::semantics::Symbol const&) (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc45dc) #12 0x05fc4c04 Fortran::semantics::SubprogramSymbolCollector::Collect() (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc4c04) #13 0x05fc537c Fortran::semantics::ModFileWriter::PutSubprogram(Fortran::semantics::Symbol const&) (.part.5310) mod-file.cpp:0:0 #14 0x05fc2d80 Fortran::semantics::ModFileWriter::PutSymbol(llvm::raw_ostream&, Fortran::semantics::Symbol const&) (/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang+0x5fc2d80) #15 0x05fcc980 Fortran::semantics::ModFileWriter::PutSymbols(Fortran::semantics:
[llvm-bugs] [Bug 123536] [Flang] Compilation abnormally terminates when the array extent is set to a large value
Issue 123536 Summary [Flang] Compilation abnormally terminates when the array extent is set to a large value Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 20.0.0(f5a35a31bfe6cbc16bec0c130f2bb3632dbf1fbf)/AArch64 ``` When the array extent is set to a large value, a compilation terminates abnormally. Gfortran and ifx detect errors during compilation. The following are the test program, Flang, Gfortran and ifx compilation/execution result. e8643a_.f: ```fortran recursive subroutine sub parameter (i=15) real a(i,i),b(i,i) a=1.0 b=1.0 print *,a,b end ``` ``` $ flang -c e8643a_.f flang-20: error: unable to execute command: Killed flang-20: error: flang frontend command failed due to signal (use -v to see invocation) flang version 20.0.0git (https://github.com/llvm/llvm-project.git f5a35a31bfe6cbc16bec0c130f2bb3632dbf1fbf) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin Build config: +assertions flang-20: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: flang-20: note: diagnostic msg: /tmp/e8643a_-f0d1aa flang-20: note: diagnostic msg: /tmp/e8643a_-f0d1aa.sh flang-20: note: diagnostic msg: $ ``` ``` $ cat /tmp/e8643a_-f0d1aa #line "./e8643a_.f" 1 recursive subroutine sub parameter (i=15) real a(i,i),b(i,i) a=1.0 b=1.0 print *,a,b end $ ``` ``` $ cat /tmp/e8643a_-f0d1aa.sh # Crash reproducer for clang version 20.0.0git (https://github.com/llvm/llvm-project.git f5a35a31bfe6cbc16bec0c130f2bb3632dbf1fbf) # Driver args: "-c" "e8643a_.f" # Original command: "/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang" "-fc1" "-triple" "aarch64-unknown-linux-gnu" "-emit-obj" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-target-cpu" "generic" "-target-feature" "+outline-atomics" "-target-feature" "+v8a" "-target-featur e" "+fp-armv8" "-target-feature" "+neon" "-resource-dir" "/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/lib/clang/20" "-mframe-pointer=non-leaf" "-o" "e8643a_.o" "-x" "f95-cpp-input" "e8643a_.f" "/work/groups/ssoft/compiler/llvm/aarch64/main-20250113-f5a35a31bfe6/bin/flang" "-fc1" "-triple" "aarch64-unknown-linux-gnu" "-emit-obj" "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie" "-target-cpu" "generic" "-target-feature" "+outline-atomics" "-target-feature" "+v8a" "-target-feature" "+fp-armv8" "-tar get-feature" "+neon" "-mframe-pointer=non-leaf" "-x" "f95-cpp-input" "e8643a_-f0d1aa" $ ``` ``` $ gfortran -c e8643a_.f e8643a_.f:1:30: 1 | recursive subroutine sub | ^ Error: total size of local objects 1800 exceeds maximum 9223372036854775296 $ ``` ``` $ ifx -c e8643a_.f warning: :0:0: stack frame size (4164941944717836440) exceeds limit (4294967295) in function 'sub_' $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123524] [clang++] if-contexpr expression aren't parsed in an immediate function context
Issue 123524 Summary [clang++] if-contexpr _expression_ aren't parsed in an immediate function context Labels clang Assignees Reporter katzdm Sorry for all of these similar bugs! Just filing for now to document; I may have time to help with some PRs in a few weeks. https://godbolt.org/z/5ejE5f1vK The "condition of a constexpr if statement" is one of the forms that constitute a manifestly constant-evaluated _expression_. Since subexpressions of manifestly constant-evaluated expressions are considered to be within an _immediate function context_, the immediate-escalating _expression_ `&fn` should be valid and allowed. We might consider pushing an `ExpressionEvaluationContext` [here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseExprCXX.cpp#L2207) when `CK == ConditionKind::ConstexprIf`, just prior to calling `ParseExpression()`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123560] Are the codes in UnicodeCharSets.h accurate, and what version of Unicode standard are they for?
Issue
123560
Summary
Are the codes in UnicodeCharSets.h accurate, and what version of Unicode standard are they for?
Labels
new issue
Assignees
Reporter
mrolle45
The ranges in `XIDStartRanges[]` and `XIDContinueRanges[]` don't seem to correspond exactly to the codepoints shown as XID_START and XID_CONTINUE in the official Unicode documents. I'm reading https://www.unicode.org/Public/15.1.0/ucd/DerivedCoreProperties.txt for version 15.1, which the last commit says it was updated for.
As an example, the standard document has
```
00F8..01BA; XID_Start # L& [195] LATIN SMALL LETTER O WITH STROKE..LATIN SMALL LETTER EZH WITH TAIL
01BB ; XID_Start # Lo LATIN LETTER TWO WITH STROKE
01BC..01BF; XID_Start # L& [4] LATIN CAPITAL LETTER TONE FIVE..LATIN LETTER WYNN
01C0..01C3; XID_Start # Lo [4] LATIN LETTER DENTAL CLICK..LATIN LETTER RETROFLEX CLICK
01C4..0293; XID_Start # L& [208] LATIN CAPITAL LETTER DZ WITH CARON..LATIN SMALL LETTER EZH WITH CURL
0294 ; XID_Start # Lo LATIN LETTER GLOTTAL STOP
0295..02AF; XID_Start # L& [27] LATIN LETTER PHARYNGEAL VOICED FRICATIVE..LATIN SMALL LETTER TURNED H WITH FISHHOOK AND TAIL
02B0..02C1; XID_Start # Lm [18] MODIFIER LETTER SMALL H..MODIFIER LETTER REVERSED GLOTTAL STOP
```
but your file has
```c
{0x00F8, 0x02C1}
```
Thus there are several codepoints in this range which clang considers to be identifier start characters, but are not such in the Unicode standard.
By the way, the standard file also contains the same codes as ID_START:
```
00F8..01BA; ID_Start # L& [195] LATIN SMALL LETTER O WITH STROKE..LATIN SMALL LETTER EZH WITH TAIL
01BB ; ID_Start # Lo LATIN LETTER TWO WITH STROKE
01BC..01BF; ID_Start # L& [4] LATIN CAPITAL LETTER TONE FIVE..LATIN LETTER WYNN
01C0..01C3; ID_Start # Lo [4] LATIN LETTER DENTAL CLICK..LATIN LETTER RETROFLEX CLICK
01C4..0293; ID_Start # L& [208] LATIN CAPITAL LETTER DZ WITH CARON..LATIN SMALL LETTER EZH WITH CURL
0294 ; ID_Start # Lo LATIN LETTER GLOTTAL STOP
0295..02AF; ID_Start # L& [27] LATIN LETTER PHARYNGEAL VOICED FRICATIVE..LATIN SMALL LETTER TURNED H WITH FISHHOOK AND TAIL
02B0..02C1; ID_Start # Lm [18] MODIFIER LETTER SMALL H..MODIFIER LETTER REVERSED GLOTTAL STOP
```
This is important to me personally because I am working on a C preprocessor which has an option to emulate clang version 20 (with `-E` switch), and to test it I am giving it various identifiers with unicode characters.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123544] [Bug][ARM] Using -mno-unaligned-access still generates unaligned access
Issue 123544 Summary [Bug][ARM] Using -mno-unaligned-access still generates unaligned access Labels new issue Assignees Reporter Zhenhang1213 When a value is assigned to bootp_ptr, unaligned str still exists. I expect that the value should be assigned to one byte. demo:https://godbolt.org/z/T5688E51Y ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123545] __builtin_launder complains about type completeness
Issue
123545
Summary
__builtin_launder complains about type completeness
Labels
c++17,
clang:frontend,
diverges-from:gcc,
diverges-from:msvc,
diverges-from:edg
Assignees
Reporter
hubert-reinterpretcast
`std::launder` does not require that the type pointed to is complete. See https://wg21.link/ptr.launder.
Clang refuses to compile the following:
```cpp
#include
struct A;
A *h(A *p) { return std::launder(p); }
```
which becomes (with multiple C++ standard libraries):
```cpp
struct A;
A *h(A *p) { return __builtin_launder(p); }
```
Online compiler link: https://godbolt.org/z/8KG98zaxW
### SOURCE (``):
```cpp
struct A;
A *h(A *p) { return __builtin_launder(p); }
```
### COMPILER INVOCATION:
```
clang++ -fsyntax-only -std=c++17 -xc++ -
```
### ACTUAL COMPILER OUTPUT:
```
:2:21: error: incomplete type 'A' where a complete type is required
2 | A *h(A *p) { return __builtin_launder(p); }
| ^
:1:8: note: forward declaration of 'A'
1 | struct A;
|^
1 error generated.
```
### EXPECTED COMPILER OUTPUT:
(clean compile)
### COMPILER VERSION INFO (`clang++ -v`):
```
clang version 20.0.0git (https://github.com/llvm/llvm-project.git dd42651295d0e1566b34104b007ad19865c57fcc)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/wandbox/clang-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Candidate multilib: .;@m64
Selected multilib: .;@m64
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123549] HeuristicResolver::getPointeeType discards qualifiers
Issue
123549
Summary
HeuristicResolver::getPointeeType discards qualifiers
Labels
clangd,
clang:frontend
Assignees
HighCommander4
Reporter
HighCommander4
`HeuristicResolver::getPointeeType()` returns a `Type *` rather than a `QualType`, which means it necessarily discards any qualifiers on the returned pointee type.
This can be important, as seen e.g. in clangd in the following code:
```c++
template
struct Waldo {
void find();
void find() const;
};
template
struct smart_ptr {
T* operator->();
};
template
void foo(smart_ptr> s) {
s->find();
}
```
Go-to-definition on the `find` token in `s->find()` offers both overloads of `Waldo::find()` as results, when it should only offer the `const` overload.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123550] [Indvars] Miscompile: SSA value incorrectly simplified
Issue
123550
Summary
[Indvars] Miscompile: SSA value incorrectly simplified
Labels
new issue
Assignees
Reporter
Nirhar
One can find the incorrect transformation here: https://godbolt.org/z/T9qMhT7rb
And the proof of incorrect transformation here: https://alive2.llvm.org/ce/z/PXjb5J
For the record, I describe the problem here. Given the IR:
```
define i32 @widget() {
bb:
br label %bb1
bb1: ; preds = %bb4, %bb
%phi = phi i32 [ -173, %bb ], [ %sub, %bb4 ]
%phi2 = phi i32 [ 1, %bb ], [ %add, %bb4 ]
%srem = srem i32 729259140, %phi
%trunc = trunc i32 %phi2 to i8
%urem = urem i8 -83, %trunc
%zext = zext i8 %urem to i32
%sub = sub nsw i32 0, %zext
br label %bb4
bb4: ; preds = %bb1
%add = add nuw nsw i32 %phi2, 1
%icmp = icmp eq i32 %sub, 0
br i1 %icmp, label %bb5, label %bb1
bb5: ; preds = %bb4
%phi6 = phi i32 [ %srem, %bb4 ]
ret i32 %phi6
}
```
which returns `srem i32 729259140, -173` which is `130`. The above IR under the `indvars` pass transforms to:
```
define i32 @widget() {
br label %bb1
bb1: ; preds = %bb4, %bb
br label %bb4
bb4: ; preds = %bb1
br i1 true, label %bb5, label %bb1
bb5: ; preds = %bb4
ret i32 729259140
}
```
which returns `729259140` which is the wrong answer.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
