[llvm-bugs] [Bug 48917] New: tools/llvm-elfabi/preserve-dates-stub.test fails on Windows
https://bugs.llvm.org/show_bug.cgi?id=48917 Bug ID: 48917 Summary: tools/llvm-elfabi/preserve-dates-stub.test fails on Windows Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 48902 See discussion on https://reviews.llvm.org/D92902 which introduced the problem. On my machine it fails as below. It appears 'touch' does not like the date for whatever reason. This means I'm not able to build 12.0.0-rc1. Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90 FAIL: LLVM :: tools/llvm-elfabi/preserve-dates-tbe.test (39967 of 42071) TEST 'LLVM :: tools/llvm-elfabi/preserve-dates-tbe.test' FAILED Script: -- : 'RUN: at line 3'; llvm-elfabi --elf c:\src\llvm_package_1200-rc1\llvm-project\llvm\test\tools\llvm-elfabi/Inputs/gnu_hash.so --emit-tbe=c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp : 'RUN: at line 4'; touch -m -t 19700101 c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp : 'RUN: at line 5'; llvm-elfabi --elf c:\src\llvm_package_1200-rc1\llvm-project\llvm\test\tools\llvm-elfabi/Inputs/gnu_hash.so --emit-tbe=c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp --write-if-changed : 'RUN: at line 6'; ls -l c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp | c:\src\llvm_package_1200-rc1\build32_stage0\bin\filecheck.exe --allow-unused-prefixes=false c:\src\llvm_package_1200-rc1\llvm-project\llvm\test\tools\llvm-elfabi\preserve-dates-tbe.test -- Exit Code: 1 Command Output (stdout): -- $ ":" "RUN: at line 3" $ "llvm-elfabi" "--elf" "c:\src\llvm_package_1200-rc1\llvm-project\llvm\test\tools\llvm-elfabi/Inputs/gnu_hash.so" "--emit-tbe=c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp" $ ":" "RUN: at line 4" $ "touch" "-m" "-t" "19700101" "c:\src\llvm_package_1200-rc1\build32_stage0\test\tools\llvm-elfabi\Output\preserve-dates-tbe.test.tmp" # command stderr: touch: invalid date format `19700101' error: command failed with exit status: 1 -- Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Failed Tests (2): LLVM :: tools/llvm-elfabi/preserve-dates-stub.test LLVM :: tools/llvm-elfabi/preserve-dates-tbe.test Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48918] New: check-llvm hangs with 12.0.0-rc1 while spawning llvm-exegesis
https://bugs.llvm.org/show_bug.cgi?id=48918 Bug ID: 48918 Summary: check-llvm hangs with 12.0.0-rc1 while spawning llvm-exegesis Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 48902 I'm going to try to debug it shortly. Long story short, llvm-lit spawns llvm-exegesis and nothing happens afterwards. The process doesn't utilize any CPU, so I suspect it's waiting for something. 1006397 pts/5S+ 0:01 /usr/bin/python3.9 /var/tmp/portage/sys-devel/llvm-12.0.0_rc1/work/llvm-12.0.0_rc1_build-abi_x86_64.amd64/./bin/llvm-lit -vv -j 12 /var/tmp/portage/sys-devel/llvm-12.0.0_rc1/work/llvm-12.0.0_rc1_build-abi_x86_64.amd64/utils/lit /var/tmp/portage/sys-devel/llvm-12.0.0_rc1/work/llvm-12.0.0_rc1_build-abi_x86_64.amd64/test 1006476 pts/5S+ 0:00 /var/tmp/portage/sys-devel/llvm-12.0.0_rc1/work/llvm-12.0.0_rc1_build-abi_x86_64.amd64/bin/llvm-exegesis -mode latency -x86-lbr-sample-period 123 -repetition-mode loop -snippets-file /dev/null Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48919] New: kmp_settings.cpp fails to compile on Windows with error C2131: expression did not evaluate to a constant
https://bugs.llvm.org/show_bug.cgi?id=48919 Bug ID: 48919 Summary: kmp_settings.cpp fails to compile on Windows with error C2131: expression did not evaluate to a constant Product: OpenMP Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Blocks: 48902 in a VS 2019 x86 Native Tools Command Prompt with llvmorg-12.0.0-rc1 checked out cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="clang;openmp" ..\llvm ninja omp C:\src\llvm.monorepo\openmp\runtime\src\kmp_settings.cpp(3358): error C2131: expression did not evaluate to a constant C:\src\llvm.monorepo\openmp\runtime\src\kmp_settings.cpp(3358): note: failure was caused by a read of a variable outside its lifetime C:\src\llvm.monorepo\openmp\runtime\src\kmp_settings.cpp(3358): note: see usage of 'ntraits' Bisection points to commit 927af4b3c57681e623b8449fb717a447559358d0 Author: Nawrin Sultana Date: Mon Nov 2 16:17:37 2020 -0600 [OpenMP] Modify OMP_ALLOCATOR environment variable This patch sets the def-allocator-var ICV based on the environment variables provided in OMP_ALLOCATOR. Previously, only allowed value for OMP_ALLOCATOR was a predefined memory allocator. OpenMP 5.1 specification allows predefined memory allocator, predefined mem space, or predefined mem space with traits in OMP_ALLOCATOR. If an allocator can not be created using the provided environment variables, the def-allocator-var is set to omp_default_mem_alloc. Differential Revision: https://reviews.llvm.org/D94985 openmp/runtime/src/kmp_settings.cpp | 391 -- openmp/runtime/test/env/omp51_alloc_env.c | 31 +++ 2 files changed, 353 insertions(+), 69 deletions(-) create mode 100644 openmp/runtime/test/env/omp51_alloc_env.c As of this morning the same error happens on the main branch too. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48920] New: test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp fails on 32-bit windows
https://bugs.llvm.org/show_bug.cgi?id=48920
Bug ID: 48920
Summary: test\CodeGenCXX\debug-info-gline-tables-only-codeview.
cpp fails on 32-bit windows
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: akhu...@google.com, htmldevelo...@gmail.com,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Blocks: 48902
in a VS 2019 x86 Native Tools Command Prompt
with llvmorg-12.0.0-rc1 checked out
cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_ENABLE_PROJECTS="clang;openmp" ..\llvm
ninja check-clang
-- Testing: 27111 tests, 32 workers --
Testing: 0.. 10.
FAIL: Clang :: CodeGenCXX/debug-info-gline-tables-only-codeview.cpp (4751 of
27111)
TEST 'Clang ::
CodeGenCXX/debug-info-gline-tables-only-codeview.cpp' FAILED
Script:
--
: 'RUN: at line 1'; c:\src\llvm.monorepo\build.openmp\bin\clang.exe -cc1
-internal-isystem c:\src\llvm.monorepo\build.openmp\lib\clang\12.0.0\include
-nostdsysteminc
c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp
-gcodeview -debug-info-kind=line-tables-only -S-emit-llvm -o - |
c:\src\llvm.monorepo\build.openmp\bin\filecheck.exe
c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "c:\src\llvm.monorepo\build.openmp\bin\clang.exe" "-cc1" "-internal-isystem"
"c:\src\llvm.monorepo\build.openmp\lib\clang\12.0.0\include" "-nostdsysteminc"
"c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp"
"-gcodeview" "-debug-info-kind=line-tables-only" "-S" "-emit-llvm" "-o" "-"
$ "c:\src\llvm.monorepo\build.openmp\bin\filecheck.exe"
"c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp"
# command stderr:
c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp:28:12:
error: CHECK: expected string not found in input
// CHECK: ![[MTYPE]] = !DISubroutineType(types: !{{.*}})
^
:60:123: note: scanning from here
!19 = !DICompositeType(tag: DW_TAG_structure_type, name: "C", scope: !10, file:
!9, line: 7, size: 8, flags: DIFlagFwdDecl)
^
:60:123: note: with "MTYPE" equal to "20"
!19 = !DICompositeType(tag: DW_TAG_structure_type, name: "C", scope: !10, file:
!9, line: 7, size: 8, flags: DIFlagFwdDecl)
^
:61:1: note: possible intended match here
!20 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !21)
^
Input file:
Check file:
c:\src\llvm.monorepo\clang\test\CodeGenCXX\debug-info-gline-tables-only-codeview.cpp
-dump-input=help explains the following input dump.
Input was:
<<
.
.
.
55: !14 = distinct !DISubprogram(name: "test", scope: !9, file: !9,
line: 15, type: !11, scopeLine: 15, flags: DIFlagPrototyped, spFlags:
DISPFlagDefinition, unit: !0, retainedNodes: !2)
56: !15 = !DILocation(line: 21, column: 3, scope: !14)
57: !16 = !DILocation(line: 29, column: 5, scope: !14)
58: !17 = !DILocation(line: 30, column: 1, scope: !14)
59: !18 = distinct !DISubprogram(name: "m", scope: !19, file: !9,
line: 8, type: !20, scopeLine: 8, flags: DIFlagPrototyped, spFlags:
DISPFlagDefinition, unit: !0, retainedNodes: !2)
60: !19 = !DICompositeType(tag: DW_TAG_structure_type, name: "C",
scope: !10, file: !9, line: 7, size: 8, flags: DIFlagFwdDecl)
check:28'0
X error: no match
found
check:28'1
with "MTYPE" equal
to "20"
61: !20 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !21)
check:28'0 ~~~
check:28'2 ?
possible intended match
62: !21 = !{null, !22}
check:28'0 ~~
63: !22 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !19,
size: 32, flags: DIFlagArtificial | DIFlagObjectPointer)
check:28'0
~~
64: !23 = !DILocation(lin
[llvm-bugs] [Bug 48921] New: Please merge fc8e7411218c to 11.x: [AMDGPU] Avoid an illegal operand in si-shrink-instructions
https://bugs.llvm.org/show_bug.cgi?id=48921 Bug ID: 48921 Summary: Please merge fc8e7411218c to 11.x: [AMDGPU] Avoid an illegal operand in si-shrink-instructions Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: piotr.sobc...@amd.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 47800 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 Release Blockers -- 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 48922] New: [LLVM 11 regression] Backport of [MC][ELF] Fix accepting abbreviated form with sh_flags and sh_entsize
https://bugs.llvm.org/show_bug.cgi?id=48922 Bug ID: 48922 Summary: [LLVM 11 regression] Backport of [MC][ELF] Fix accepting abbreviated form with sh_flags and sh_entsize Product: libraries Version: 11.0 Hardware: PC OS: Linux Status: NEW Keywords: compile-fail, regression Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: bur...@net-b.de CC: llvm-bugs@lists.llvm.org, tstel...@redhat.com Blocks: 47800 During the development of LLVM 11, a sensible error was added, but it triggered too often. This was fixed recently (LLVM trunk + 11 backport), cf. Bug #48201 + https://reviews.llvm.org/D92052 However, I missed a corner case, affecting-real-world code, which has now been fixed: https://reviews.llvm.org/D94072 – committed to LLVM trunk as commit 70ea15b88953e56681b997373fb11c97eeb05c4e Thus, it makes sense to also backport the follow-up fix to LLVM 11. Thanks for consideration/merging. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.0.1 Release Blockers -- 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 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
https://bugs.llvm.org/show_bug.cgi?id=38768 Bug 38768 depends on bug 39726, which changed state. Bug 39726 Summary: [DebugInfo@O2][Dexter] Pointer variable location can be dropped despite being live https://bugs.llvm.org/show_bug.cgi?id=39726 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 38754] [DebugInfo@O2][Dexter] Illegal value appears in variable when conditional blocks folded
https://bugs.llvm.org/show_bug.cgi?id=38754 Bug 38754 depends on bug 39726, which changed state. Bug 39726 Summary: [DebugInfo@O2][Dexter] Pointer variable location can be dropped despite being live https://bugs.llvm.org/show_bug.cgi?id=39726 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 39726] [DebugInfo@O2][Dexter] Pointer variable location can be dropped despite being live
https://bugs.llvm.org/show_bug.cgi?id=39726 Jeremy Morse changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeremy Morse --- Yikes, this bug description is hard to read. I must have been in too deep when writing it, As far as I understand it, my problem was that the pointer value for "qux" was available, but we couldn't find the right SDNode when building a SelectionDAG because it was on the other side of a needless BitCast. And for various reasons at the time, SelectionDAG wouldn't create DBG_VALUEs for arbitary VRegs Some time later this [0] landed, which refers to this PR. I've just given the "reproducer" a few runs and couldn't make it drop "qux", so I think it's fair to say it's fixed. Thanks for prodding! [0] https://reviews.llvm.org/D56678 -- 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 48923] New: __builtin_fabsl in stdlib.h is not guarded but not available for nvptx (among others)
https://bugs.llvm.org/show_bug.cgi?id=48923 Bug ID: 48923 Summary: __builtin_fabsl in stdlib.h is not guarded but not available for nvptx (among others) Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Standards Issues Assignee: unassignedclangb...@nondot.org Reporter: jdoerf...@anl.gov CC: a.bat...@hotmail.com, llvm-bugs@lists.llvm.org, mariya.podchishcha...@intel.com, mclow.li...@gmail.com, tianshilei1...@gmail.com When we compile the OpenMP device (=GPU) runtime, or any OpenMP device code which includes stdlib from libc++, we are presented with an error: ``` In file included from /mnt/scratch/elwasif/llvm-git/llvm-project/openmp/libomptarget/deviceRTLs/common/src/cancel.cu:15: In file included from /mnt/scratch/elwasif/llvm-git/llvm-project/openmp/libomptarget/deviceRTLs/common/debug.h:31: In file included from /mnt/scratch/elwasif/llvm-git/llvm-project/openmp/libomptarget/deviceRTLs/common/device_environment.h:16: In file included from /mnt/scratch/elwasif/llvm-git/llvm-project/openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.h:18: /mnt/scratch/elwasif/llvm-git/clang-fixed/bin/../include/c++/v1/stdlib.h:128:10: error: '__builtin_fabsl' requires 128 bit size 'long double' type support, but device 'nvptx64' does not support it return __builtin_fabsl(__lcpp_x); ``` This was probably introduced by https://reviews.llvm.org/D74387 . It is unclear to me how to handle this. One way would eb to guard the builtin use. FWIW, when we target nvptx from C/C++ code right away clang simply demotes `long double` into `double` which I find highly questionable and which can cause all sorts of havock if we talk about memory: https://clang.godbolt.org/z/eq6dPc -- 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 27016 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: !isEmpty() && "Nothing selected"
Updates: Labels: Deadline-Approaching Comment #1 on issue 27016 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: !isEmpty() && "Nothing selected" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27016#c1 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 27024 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isValidElementType(ElementType) && "Invalid type for array element!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 27024 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isValidElementType(ElementType) && "Invalid type for array element!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27024#c1 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 48924] New: Clang emits an extra entry in llvm.global_ctors when init_priority is used
https://bugs.llvm.org/show_bug.cgi?id=48924
Bug ID: 48924
Summary: Clang emits an extra entry in llvm.global_ctors when
init_priority is used
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Consider:
$ cat t.cpp
struct Foo {
Foo();
~Foo();
};
Foo init_me __attribute__((init_priority(101)));
$ clang -cc1 -emit-llvm t.cpp -o - | grep -A2 GLOBAL_
@llvm.global_ctors = appending global [2 x { i32, void ()*, i8* }] [{ i32, void
()*, i8* } { i32 101, void ()* @_GLOBAL__I_000101, i8* null }, { i32, void ()*,
i8* } { i32 65535, void ()* @_GLOBAL__sub_I_t.cpp, i8* null }]
; Function Attrs: noinline nounwind
--
define internal void @_GLOBAL__I_000101() #0 section ".text.startup" {
entry:
call void @__cxx_global_var_init()
--
define internal void @_GLOBAL__sub_I_t.cpp() #0 section ".text.startup" {
entry:
ret void
This file only needs a single entry in llvm.global_ctors and then .init_array /
.ctors / .CRT$XCU in the object file, but it has two.
We should probably fix this at the clang level. GlobalOpt could fix this, but
it runs away if it can't fold the higher priority initializer first.
This was reduced from libc++, which uses init_priority for std::cout et al
initialization.
--
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 48925] New: Always_inline / __forceinline should override dllimport inline function suppression
https://bugs.llvm.org/show_bug.cgi?id=48925
Bug ID: 48925
Summary: Always_inline / __forceinline should override
dllimport inline function suppression
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: e...@efcs.ca, h...@chromium.org,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Consider:
$ cat t.cpp
int notImported();
int __forceinline __declspec(dllimport) foo() { return notImported(); }
int bar() { return foo(); }
$ clang -S t.cpp -o - --target=x86_64-windows-msvc
...
# %bb.0:# %entry
subq$40, %rsp
.seh_stackalloc 40
.seh_endprologue
callq *"__imp_?foo@@YAHXZ"(%rip)
nop
addq$40, %rsp
retq
.seh_endproc
...
Clang doesn't honor the __forceinline attribute here because the dllimport
function refers to something that is not also imported. This logic lives here:
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenModule.cpp#L3035
if (F->hasAttr()) {
// Check whether it would be safe to inline this dllimport function.
DLLImportFunctionVisitor Visitor;
Visitor.TraverseFunctionDecl(const_cast(F));
if (!Visitor.SafeToInline)
return false;
It seems reasonable to power down this safety check when the user has an
explicit attribute. MSVC will inline when optimizations are enabled, but not at
-Od, so this should be OK:
https://gcc.godbolt.org/z/GYTKhM
This is related to https://crbug.com/1090975#c10 and the FIXME here
http://github.com/llvm/llvm-project/commit/411210838d762303027f7ac8ddc12427d774b170.
--
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 48926] New: Breaking change for non-lld Android in fae16fc0eed7
https://bugs.llvm.org/show_bug.cgi?id=48926 Bug ID: 48926 Summary: Breaking change for non-lld Android in fae16fc0eed7 Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, mh+l...@glandium.org Blocks: 48902 Please see https://reviews.llvm.org/D95166#2525131 and later comments. In short, fae16fc0eed7 breaks compilations targeting Android that don't use lld. The change landed just before the release branch point, which means downstreams don't have a whole lot of advance notice. I don't feel qualified to assess whether this is OK within the project's general expectations of compatibility, but maybe others would like to weigh in, so I'm filing this as a release blocker for visibility. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48927] New: [sanitizers] Please merge e056fc6cb676 to 12.0.0
https://bugs.llvm.org/show_bug.cgi?id=48927 Bug ID: 48927 Summary: [sanitizers] Please merge e056fc6cb676 to 12.0.0 Product: compiler-rt Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: release blocker Priority: P Component: msan Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: llvm-bugs@lists.llvm.org https://github.com/llvm/llvm-project/commit/e056fc6cb676 fixes the msan test build on FreeBSD after https://github.com/llvm/llvm-project/commit/7afdc89c2054 accidentally enabled fgetgrent_r() in the msan tests for FreeBSD, but this function is not supported. -- 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 48928] New: VE backend tests fail on 32-bit x86
https://bugs.llvm.org/show_bug.cgi?id=48928 Bug ID: 48928 Summary: VE backend tests fail on 32-bit x86 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, kaz-maruk...@xr.jp.nec.com, llvm-bugs@lists.llvm.org Blocks: 48902 Created attachment 24434 --> https://bugs.llvm.org/attachment.cgi?id=24434&action=edit sys-devel:llvm-12.0.0_rc1:20210128-230810.log.xz The following tests fail when LLVM is built with VE target enabled on 32-bit x86 (well, 32-bit multilib of an amd64 system, to be more precise). They pass on a 64-bit system, so I suspect the backend code is not 32-bit friendly somewhere. Failed Tests (13): LLVM :: CodeGen/VE/Scalar/br_cc.ll LLVM :: CodeGen/VE/Scalar/cast.ll LLVM :: CodeGen/VE/Scalar/fcopysign.ll LLVM :: CodeGen/VE/Scalar/fp_add.ll LLVM :: CodeGen/VE/Scalar/fp_fneg.ll LLVM :: CodeGen/VE/Scalar/fp_mul.ll LLVM :: CodeGen/VE/Scalar/fp_sub.ll LLVM :: CodeGen/VE/Scalar/fp_to_int.ll LLVM :: CodeGen/VE/Scalar/select.ll LLVM :: CodeGen/VE/Scalar/shl.ll LLVM :: CodeGen/VE/Scalar/shr.ll LLVM :: CodeGen/VE/VELIntrinsics/vbrd.ll LLVM :: CodeGen/VE/Vector/insert_elt.ll I'm attaching the complete build log in case it's helpful. It includes all build commands (both 32-bit and 64-bit), and the complete test suite output. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48929] New: Infinite recursion in type_info::operator== under UBSan
https://bugs.llvm.org/show_bug.cgi?id=48929
Bug ID: 48929
Summary: Infinite recursion in type_info::operator== under
UBSan
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: ubsan
Assignee: unassignedb...@nondot.org
Reporter: tliv...@google.com
CC: llvm-bugs@lists.llvm.org
Apologies if this is the wrong component to file a bug on. It is definitely a
UBSan bug, but the relevant code is spread across compiler-rt, libc++, and
libc++abi.
I just investigated an issue in which using std::type_info::operator== produced
an infinite recursion with the following cycle of function calls:
RangeError: Maximum call stack size exceeded
...
at std::type_info::operator==(std::type_info const&) const
at is_equal(std::type_info const*, std::type_info const*, bool)
at __dynamic_cast (:wasm-function[40]:0x8fb)
at __ubsan::checkDynamicType(void*, void*, unsigned long)
at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned
long, unsigned long, __ubsan::ReportOptions)
at __ubsan_handle_dynamic_type_cache_miss
at std::type_info::operator==(std::type_info const&) const
...
Here is the reproducing program:
// main.cpp
#include
int main() {
return typeid(int) == typeid(int)
}
This infinite recursion happens when libc++abi is compiled with -Oz, but not
when it compiled with -O3. In the latter configuration, enough inlining and
follow-on optimizations happen to remove the call to std::type_info::operator==
under __dynamic_cast, preventing the infinite recursion. I found that adding
__attribute__((always_inline)) to std::type_info::operator== in libc++ was
sufficient to prevent the infinite recursion in the -Oz configuration as well.
This is certainly a niche configuration required to reproduce the bug, but it
seems that UBSan depending on optimizations to prevent infinite recursions is
not great, so possibly worth fixing.
The upstream workaround in Emscripten is here:
https://github.com/emscripten-core/emscripten/pull/13367.
--
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 48930] New: CodeGen/profile-filter.c test fails on 32-bit x86
https://bugs.llvm.org/show_bug.cgi?id=48930 Bug ID: 48930 Summary: CodeGen/profile-filter.c test fails on 32-bit x86 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, pho...@chromium.org Blocks: 48902 Created attachment 24435 --> https://bugs.llvm.org/attachment.cgi?id=24435&action=edit sys-devel:clang-12.0.0_rc1:20210129-002231.log.xz (complete build log) The following test fails on 32-bit x86, apparently due to expecting 64-bit alignment: FAIL: Clang :: CodeGen/profile-filter.c (4073 of 27194) TEST 'Clang :: CodeGen/profile-filter.c' FAILED Script: -- : 'RUN: at line 1'; /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang -cc1 -internal-isystem /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/12.0.0/include -nostdsysteminc -fprofile-instrument=clang -emit-llvm /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c -o - | /usr/lib/llvm/12/bin/FileCheck --allow-unused-prefixes=false /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c : 'RUN: at line 3'; echo "fun:test1" > /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-func.list : 'RUN: at line 4'; /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang -cc1 -internal-isystem /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/12.0.0/include -nostdsysteminc -fprofile-instrument=clang -fprofile-list=/var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-func.list -emit-llvm /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c -o - | /usr/lib/llvm/12/bin/FileCheck --allow-unused-prefixes=false /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c --check-prefix=FUNC : 'RUN: at line 6'; echo "src:/var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c" | sed -e 's/\\//g' > /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-file.list : 'RUN: at line 7'; /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang -cc1 -internal-isystem /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/12.0.0/include -nostdsysteminc -fprofile-instrument=clang -fprofile-list=/var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-file.list -emit-llvm /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c -o - | /usr/lib/llvm/12/bin/FileCheck --allow-unused-prefixes=false /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c --check-prefix=FILE : 'RUN: at line 9'; echo -e "[clang]\nfun:test1\n[llvm]\nfun:test2" > /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-section.list : 'RUN: at line 10'; /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang -cc1 -internal-isystem /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/12.0.0/include -nostdsysteminc -fprofile-instrument=llvm -fprofile-list=/var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-section.list -emit-llvm /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c -o - | /usr/lib/llvm/12/bin/FileCheck --allow-unused-prefixes=false /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c --check-prefix=SECTION : 'RUN: at line 12'; echo -e "fun:test*\n!fun:test1" > /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-exclude.list : 'RUN: at line 13'; /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang -cc1 -internal-isystem /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/12.0.0/include -nostdsysteminc -fprofile-instrument=clang -fprofile-list=/var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/CodeGen/Output/profile-filter.c.tmp-exclude.list -emit-llvm /var/tmp/portage/sys-devel/clang-12.0.0_rc1/work/clang/test/CodeGen/profile-filter.c -o - | /usr/lib/llvm/12/bin/FileCheck --allow-un
[llvm-bugs] [Bug 48931] New: ClangTidyTests fail to link w/ shared libclang-cpp+libLLVM: undefined reference to `llvm::Annotations::Annotations(llvm::StringRef)'
https://bugs.llvm.org/show_bug.cgi?id=48931 Bug ID: 48931 Summary: ClangTidyTests fail to link w/ shared libclang-cpp+libLLVM: undefined reference to `llvm::Annotations::Annotations(llvm::StringRef)' Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 48902 Created attachment 24436 --> https://bugs.llvm.org/attachment.cgi?id=24436&action=edit sys-devel:clang-12.0.0_rc1:20210129-005431.log.xz Attaching the complete build log. The linker errors follow. I suspect it's missing proper linking to libLLVMTestingSupport, I am going to try patching it in a minute. /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: tools/extra/unittests/clang-tidy/CMakeFiles/ClangTidyTests.dir/ClangTidyOptionsTest.cpp.o: in function `clang::tidy::test::ParseConfiguration_CollectDiags_Test::TestBody()': ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x62): undefined reference to `llvm::Annotations::Annotations(llvm::StringRef)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x24c): undefined reference to `llvm::Annotations::range(llvm::StringRef) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x263): undefined reference to `llvm::Annotations::range(llvm::StringRef) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x39a): undefined reference to `llvm::Annotations::Annotations(llvm::StringRef)' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x88f): undefined reference to `llvm::Annotations::range(llvm::StringRef) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ClangTidyOptionsTest.cpp:(.text._ZN5clang4tidy4test36ParseConfiguration_CollectDiags_Test8TestBodyEv+0x8a6): undefined reference to `llvm::Annotations::range(llvm::StringRef) const' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: tools/extra/unittests/clang-tidy/CMakeFiles/ClangTidyTests.dir/ClangTidyOptionsTest.cpp.o: in function `clang::tidy::test::(anonymous namespace)::DiagRangeMatcherP::gmock_Impl::FormatDescription(bool) const': ClangTidyOptionsTest.cpp:(.text._ZNK5clang4tidy4test12_GLOBAL__N_117DiagRangeMatcherPIN4llvm11Annotations5RangeEE10gmock_ImplIRKNS2_13DiagCollecter4DiagEE17FormatDescriptionEb+0xe4): undefined reference to `llvm::operator<<(llvm::raw_ostream&, llvm::Annotations::Range const&)' collect2: error: ld returned 1 exit status Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=48902 [Bug 48902] [meta] 12.0.0 Release Blockers -- 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 48932] New: Possible regression with simplifycfg on 12.0.
https://bugs.llvm.org/show_bug.cgi?id=48932 Bug ID: 48932 Summary: Possible regression with simplifycfg on 12.0. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: deepak.rajendrakuma...@intel.com CC: llvm-bugs@lists.llvm.org I'm not certain this is a bug but simplifycfg does not seem to identify common load and hoist it. This was happening on 11.0 and before. See godbolt link - https://godbolt.org/z/cKdjq5 -- 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 48561] Obtained 45 lldb errors when running test-release.sh for 11.0.1 rc2
https://bugs.llvm.org/show_bug.cgi?id=48561 Neil Nelson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 48567] Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize' FAILED
https://bugs.llvm.org/show_bug.cgi?id=48567 Neil Nelson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Neil Nelson --- Did not see this bug on the 12.0.0 release. -- 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 48725] [LSR] Crash during CompareSCEVComplexity on unrolled loop
https://bugs.llvm.org/show_bug.cgi?id=48725 Max Kazantsev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 48933] New: Find and fix more unsupported type uses in device code
https://bugs.llvm.org/show_bug.cgi?id=48933
Bug ID: 48933
Summary: Find and fix more unsupported type uses in device code
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: jdoerf...@anl.gov
CC: a.bat...@hotmail.com, deepak.eachemp...@hpe.com,
jonathanchesterfi...@gmail.com,
llvm-bugs@lists.llvm.org, ravi.narayanasw...@intel.com
We diagnose a lot of expression uses of unsupported types but sme declarations
slip through. They still can cause the backend to crash. Two I found so far:
```
#pragma omp declare target
long double a() {
return 0;
}
void c(long double a) { }
#pragma omp end declare target
```
--
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 48934] New: Runtime unit-tests doesn't work with Python 3
https://bugs.llvm.org/show_bug.cgi?id=48934 Bug ID: 48934 Summary: Runtime unit-tests doesn't work with Python 3 Product: OpenMP Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: tob...@plexapp.com CC: llvm-bugs@lists.llvm.org The following test fails on my python3 only system: ``` llvm-lit: /Users/tobias/code/llvm-releases/12.0.0/rc1/llvm-project/llvm/utils/lit/lit/TestingConfig.py:99: fatal: unable to parse config file '/Users/tobias/code/llvm-releases/12.0.0/rc1/llvm-project/openmp/runtime/test/lit.cfg', traceback: Traceback (most recent call last): File "/Users/tobias/code/llvm-releases/12.0.0/rc1/Phase3/Release/llvmCore-12.0.0-rc1.obj/bin/../../../../llvm-project/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path exec(compile(data, path, 'exec'), cfg_globals, None) File "/Users/tobias/code/llvm-releases/12.0.0/rc1/llvm-project/openmp/runtime/test/lit.cfg", line 82, in config.test_flags += " -isysroot " + out TypeError: can only concatenate str (not "bytes") to str ``` The following patch fixes it: ``` diff --git a/openmp/runtime/test/lit.cfg b/openmp/runtime/test/lit.cfg index 357b18a205d0..96c0c3a1da70 100644 --- a/openmp/runtime/test/lit.cfg +++ b/openmp/runtime/test/lit.cfg @@ -76,7 +76,7 @@ if config.operating_system == 'Darwin': cmd = subprocess.Popen(['xcrun', '--show-sdk-path'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = cmd.communicate() - out = out.strip() + out = out.strip().decode() res = cmd.wait() if res == 0 and out: config.test_flags += " -isysroot " + out ``` This blocks testing of 12.0.0 on macOS -- 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
