[llvm-bugs] [Bug 46720] New: [clang-cl] /Fe option with colon is not accepted
https://bugs.llvm.org/show_bug.cgi?id=46720 Bug ID: 46720 Summary: [clang-cl] /Fe option with colon is not accepted Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: andrey.vih...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk According to [1], `/Fe` option has two forms - it can be used with `:` as a separator. Currently `clang-cl.exe` supports only `/Fe` (without `:`) Steps to reproduce: clang-cl.exe "/Fe:out2.exe" test.cpp Does not produce `out2.exe` (produces no executable at all) Whereas clang-cl.exe "/Feout.exe" test.cpp works fine. [1] https://docs.microsoft.com/en-us/cpp/build/reference/fe-name-exe-file -- 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 46721] New: optimizer segfault on IR input
https://bugs.llvm.org/show_bug.cgi?id=46721
Bug ID: 46721
Summary: optimizer segfault on IR input
Product: tools
Version: 10.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: llvm...@dworkin.nl
CC: llvm-bugs@lists.llvm.org
Created attachment 23725
--> https://bugs.llvm.org/attachment.cgi?id=23725&action=edit
IR
# Command
clang -O test.ll
Reproduced on Ubuntu 20.04 and macOS (clang-1100.0.33.17). Without -O there is
no crash.
# test.ll (also as attachment)
target triple = "x86_64-pc-linux-gnu"
define void @func(i8* %f) #1 {
L002a:
%l1 = xor i64 0, 0
switch i64 %l1, label %L00d4 [
i64 1, label %L0045
i64 4, label %L00d4
i64 6, label %L00d4
]
L0045:
switch i64 %l1, label %L00d4 [
i64 3, label %L0061
]
L0061:
%l2 = xor i64 2, 0
br label %L00d4
L00d4:
%l3 = phi i64 [%l1, %L002a], [%l1, %L0045], [%l2, %L0061]
ret void
}
# Output
Stack dump:
0. Program arguments: /usr/lib/llvm-10/bin/clang -cc1 -triple
x86_64-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name fa0ef47025935b0946f06abdbee5ab06.ll
-mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none
-fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu znver2 -target-feature +sse2 -target-feature +cx16
-target-feature +sahf -target-feature -tbm -target-feature -avx512ifma
-target-feature +sha -target-feature -gfni -target-feature -fma4
-target-feature -vpclmulqdq -target-feature +prfchw -target-feature +bmi2
-target-feature -cldemote -target-feature +fsgsbase -target-feature -ptwrite
-target-feature +xsavec -target-feature +popcnt -target-feature +aes
-target-feature -avx512bitalg -target-feature -movdiri -target-feature +xsaves
-target-feature -avx512er -target-feature -avx512vnni -target-feature
-avx512vpopcntdq -target-feature -pconfig -target-feature +clwb -target-feature
-avx512f -target-feature +clzero -target-feature -pku -target-feature +mmx
-target-feature -lwp -target-feature +rdpid -target-feature -xop
-target-feature +rdseed -target-feature -waitpkg -target-feature -movdir64b
-target-feature +sse4a -target-feature -avx512bw -target-feature +clflushopt
-target-feature +xsave -target-feature -avx512vbmi2 -target-feature +64bit
-target-feature -avx512vl -target-feature -invpcid -target-feature -avx512cd
-target-feature +avx -target-feature -vaes -target-feature +cx8 -target-feature
+fma -target-feature -rtm -target-feature +bmi -target-feature -enqcmd
-target-feature +rdrnd -target-feature +mwaitx -target-feature +sse4.1
-target-feature +sse4.2 -target-feature +avx2 -target-feature +fxsr
-target-feature +wbnoinvd -target-feature +sse -target-feature +lzcnt
-target-feature +pclmul -target-feature -prefetchwt1 -target-feature +f16c
-target-feature +ssse3 -target-feature -sgx -target-feature -shstk
-target-feature +cmov -target-feature -avx512vbmi -target-feature -avx512bf16
-target-feature +movbe -target-feature +xsaveopt -target-feature -avx512dq
-target-feature +adx -target-feature -avx512pf -target-feature +sse3
-dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/usr/lib/llvm-10/lib/clang/10.0.0 -Os -fdebug-compilation-dir
/home/felix/d/lpc-ext/jit -ferror-limit 19 -fmessage-length 80
-fgnuc-version=4.2.1 -fobjc-runtime=gcc -fdiagnostics-show-option
-fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o
/tmp/fa0ef47025935b0946f06abdbee5ab06-005afc.o -x ir
cache/fa/fa0ef47025935b0946f06abdbee5ab06.ll
1. Per-function optimization
2. Running pass 'Simplify the CFG' on function '@func11'
#0 0x717d14ff llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x9814ff)
#1 0x717cf7b0 llvm::sys::RunSignalHandlers()
(/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x97f7b0)
#2 0x717d1ac5 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x981ac5)
#3 0x77fa13c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x718b70c6 llvm::PHINode::removeIncomingValue(unsigned int, bool)
(/lib/x86_64-linux-gnu/libLLVM-10.so.1+0xa670c6)
#5 0x7201ef3f (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x11cef3f)
#6 0x72017152 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x11c7152)
#7 0x72013a70 llvm::simplifyCFG(llvm::BasicBlock*,
llvm::TargetTransformInfo const&, llvm::SimplifyCFGOptions const&,
llvm::SmallPtrSetImpl*)
(/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x11c3a70)
#8 0x72334efd (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x14e4efd)
#9 0x72334907 (/lib/x86_64-linux-gnu/libLLVM-10.so.1+0x14e4907)
#10 0x718d6d76 llvm::FPPassManager::runOnFunction(llvm
[llvm-bugs] [Bug 41218] Clang-tidy suppression comments and the WarningsAsErrors setting are ignored
https://bugs.llvm.org/show_bug.cgi?id=41218 Sven Panne changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #8 from Sven Panne --- I'm not sure about the policy when/how to re-open bugs, but I simply try to do it... :-) If there is another way to do it, a hint/link would be helpful. -- 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 46723] New: Failure to use
https://bugs.llvm.org/show_bug.cgi?id=46723 Bug ID: 46723 Summary: Failure to use Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: gabrav...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com -- 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 46723] Failure to use
https://bugs.llvm.org/show_bug.cgi?id=46723 Gabriel Ravier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Gabriel Ravier --- Um, somehow I accidentally opened this, sorry. -- 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 46724] New: Failure to use x86 array arithmetic instead of manual add
https://bugs.llvm.org/show_bug.cgi?id=46724
Bug ID: 46724
Summary: Failure to use x86 array arithmetic instead of manual
add
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
struct as
{
as* a;
as* b;
};
struct b
{
as* a;
as* b;
};
void f(b* a, as* s)
{
if (a->a)
{
s->a = a->a;
a->a->b = s;
}
else
{
a->b = s;
}
}
With -O3, GCC outputs this :
f(b*, as*):
mov rax, QWORD PTR [rdi]
test rax, rax
je .L2
mov QWORD PTR [rsi], rax
mov QWORD PTR [rax+8], rsi
ret
.L2:
mov QWORD PTR [rdi+8], rsi
ret
LLVM outputs this :
f(b*, as*): # @f(b*, as*)
mov rax, qword ptr [rdi]
test rax, rax
je .LBB0_2
mov qword ptr [rsi], rax
add rax, 8
mov qword ptr [rax], rsi
ret
.LBB0_2:
add rdi, 8
mov qword ptr [rdi], rsi
ret
--
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 46725] New: [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug ID: 46725 Summary: [meta] 11.0.0 Release Blockers Product: new-bugs Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: h...@chromium.org Reporter: h...@chromium.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org This is the meta-bug for tracking 11.0.0 release blockers. Rather than adding comments here, please file bugs and mark them as blocking this one. The 11.0.0 release branch was created at 2e10b7a39b930ef8d9c4362509d8835b221fbc0a -- 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 46726] New: Clang rejects valid code with "anonymous types declared in an anonymous union are an extension"
https://bugs.llvm.org/show_bug.cgi?id=46726
Bug ID: 46726
Summary: Clang rejects valid code with "anonymous types
declared in an anonymous union are an extension"
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hi, all.
This code, test.cc, is a valid code I guess, but Clang rejects this under
-pedantic-errors.
$cat test.cc
namespace g_namespace {
static union { union {} u; } ;
}
$clang++ -pedantic-errors test.cc
test.cc:2:21: error: anonymous types declared in an anonymous union are an
extension [-Werror,-Wnested-anon-types]
static union { union {} u; } ;
^
1 error generated.
Apparently, "union {} u;" is not an anonymous union.
While in other mainstream compilers, gcc, icc, or msvc, they all accept this
code.
Every Clang version from 4.0 onwards behaves the same (I didn't test anything
older).
Thanks,
Haoxin
--
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 46727] New: Clang rejects valid enum definition with "reference to local variable declared in enclosing function"
https://bugs.llvm.org/show_bug.cgi?id=46727
Bug ID: 46727
Summary: Clang rejects valid enum definition with "reference to
local variable declared in enclosing function"
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hi, all.
This code, test.cc, is a valid code I guess, but Clang rejects to compile it.
$cat test.cc
int foo (){
int var = 0;
enum E { e1 = 1 ? 1 : var};
return e1;
}
$clang++ test.cc
test.cc:3:27: error: reference to local variable 'var' declared in enclosing
function 'foo'
enum E { e1 = 1 ? 1 : var};
^
test.cc:2:9: note: 'var' declared here
int var = 0;
^
1 error generated.
While in other mainstream compilers, gcc, icc, or msvc, they all accept this
code.
Every Clang version from 4.0 onwards behaves the same (I tested in Godbolt, and
I didn't test anything older).
Thanks,
Haoxin
--
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 46728] New: Clang accepts explicit specialization in class definition
https://bugs.llvm.org/show_bug.cgi?id=46728
Bug ID: 46728
Summary: Clang accepts explicit specialization in class
definition
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hi, all.
This code, test.cc, is an invalid code I guess, but Clang accepts this without
any diagnostic message.
$cat test.cc
class A {
template void F(){};
template <> void F();
};
I think explicit specialization shouldn't exist in a class definition.
While in other compilers:
Output in GCC:
test.cc:3:15: error: explicit specialization in non-namespace scope 'class A'
3 | template <> void F();
| ^
test.cc:3:22: error: template-id 'F' in declaration of primary template
3 | template <> void F();
| ^~
Output in ICC:
test.cc: error: explicit specialization is not allowed in the current scope
template <> void F();
^
Noted that this issue only happens in Clang-7 and onwards version, while other
version upwards Clang-6 rejects this with "error: explicit specialization of
'F' in class scope".
Thanks,
Haoxin
--
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 46729] New: Clang accepts template specialization in C linkage
https://bugs.llvm.org/show_bug.cgi?id=46729
Bug ID: 46729
Summary: Clang accepts template specialization in C linkage
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hi, all.
This code, test.cc, I am sure it's an invalid code but Clang compiles it well.
$cat test.cc
template void F(){};
extern "C" {
template < >
void F();
}
While in other compilers I tested:
Output in GCC:
test.cc:3:5: error: template specialization with C linkage
3 | template < >
| ^~~~
test.cc:2:1: note: 'extern "C"' linkage started here
2 | extern "C" {
| ^~
Output in ICC:
test.cc(3): error: this declaration may not have extern "C" linkage
template < >
^
Output in MSVC:
test.cc(3): error C2894: templates cannot be declared to have 'C' linkage
Interestingly, every Clang version from 5.0 onwards behaves the same, only
clang-4.0 rejects this.
Thanks,
Haoxin
--
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 17027 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: ASSERT: FullLength == length()
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 17027 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: ASSERT: FullLength == length() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17027#c3 ClusterFuzz testcase 5754702871920640 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007140158:202007150158 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 46730] New: Invalid OpenMP loop code causes crash
https://bugs.llvm.org/show_bug.cgi?id=46730
Bug ID: 46730
Summary: Invalid OpenMP loop code causes crash
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: rofir...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following invalid OpenMP code crashes clang when using `-fopenmp`
class S {
public:
operator int();
S& operator+=(int);
};
int main() {
S s1;
#pragma omp taskloop
for (S s = S(); s < s1; s += 1)
{}
}
Curiously `parallel for` does not fail so perhaps the observed crash is due to
something related to task constructs.
However both gcc and icc reject this loop (including the equivalent `[parallel
]for`) so it looks like clang should reject it too. My understanding is that
variables of class `S` are not random access iterators.
Kind regards,
--
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 46732] New: [debug-info] multiple .loc directive for single source line
https://bugs.llvm.org/show_bug.cgi?id=46732 Bug ID: 46732 Summary: [debug-info] multiple .loc directive for single source line Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: kamleshbha...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Hi devs, I could see the clang emitting multiple .loc directive for the single source line. For the testcase please see (https://godbolt.org/z/67hEcv). I am filing this because i can not see the problem in msvc/icc compiler. can someone confirm this bug? -- 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 46733] New: Debug windows build failing with big object files
https://bugs.llvm.org/show_bug.cgi?id=46733 Bug ID: 46733 Summary: Debug windows build failing with big object files Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: zahira.ammarguel...@intel.com CC: llvm-bugs@lists.llvm.org -- 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 46734] New: Failure to optimize __builtin___memcpy_chk optimally
https://bugs.llvm.org/show_bug.cgi?id=46734
Bug ID: 46734
Summary: Failure to optimize __builtin___memcpy_chk optimally
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
void *f(void *d, const void *s, size_t l)
{
return __builtin___memcpy_chk(d, s, l, __builtin_object_size(d, 0));
}
With -O3, GCC outputs this :
f(void*, void const*, unsigned long):
jmp memcpy
LLVM outputs this :
f(void*, void const*, unsigned long):
push rbx
mov rbx, rdi
call memcpy
mov rax, rbx
pop rbx
ret
The same bad code generation can be seen with the same code, but using
`__builtin___memmove_chk` instead of `__builtin___memcpy_chk`.
--
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 46735] New: __builtin___mempcpy_chk to direct call to mempcpy
https://bugs.llvm.org/show_bug.cgi?id=46735
Bug ID: 46735
Summary: __builtin___mempcpy_chk to direct call to mempcpy
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void* f(void *d, const void *s, size_t l)
{
return __builtin___mempcpy_chk(d, s, l, __builtin_object_size(d, 0));
}
This can be optimized to `return mempcpy(d, s, l);`. This optimization is done
by GCC, but not by LLVM.
--
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 46728] Clang accepts explicit specialization in class definition
https://bugs.llvm.org/show_bug.cgi?id=46728 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- This is a new C++ feature (added by DR so it applies retroactively). The other compilers presumably just haven't implemented it yet. This was added by C++ core issue 727. -- 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 46727] Clang rejects valid enum definition with "reference to local variable declared in enclosing function"
https://bugs.llvm.org/show_bug.cgi?id=46727 Richard Smith changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- Clang is implementing the language rules correctly here, but it's not clear whether this is the desired rule. *** This bug has been marked as a duplicate of bug 46374 *** -- 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 46726] imprecise diagnostic for nested unnamed type as anonymous union member
https://bugs.llvm.org/show_bug.cgi?id=46726 Richard Smith changed: What|Removed |Added Summary|Clang rejects valid code|imprecise diagnostic for |with "anonymous types |nested unnamed type as |declared in an anonymous|anonymous union member |union are an extension" | Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- Well, Clang doesn't claim that the inner union is an anonymous union, only that it's an anonymous type, which it is. But that's really irrelevant; nested types are not allowed at all in this context, and that's what we should be diagnosing. So the issue is only that the diagnostic is imprecise; it is still correct and this code is invalid. See http://eel.is/c++draft/class.union.anon#1.sentence-3 -- 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 46736] New: LTO Example in LTO Docs Does not match Description when Compiled
https://bugs.llvm.org/show_bug.cgi?id=46736 Bug ID: 46736 Summary: LTO Example in LTO Docs Does not match Description when Compiled Product: Documentation Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: General docs Assignee: unassignedb...@nondot.org Reporter: scott.d.consta...@intel.com CC: llvm-bugs@lists.llvm.org The LTO example (https://www.llvm.org/docs/LinkTimeOptimization.html) is accompanied by a description of the expected observations after LTO, which includes as the third bullet point: "And this in turn, enables linker to remove foo4()." However, foo4() will not be removed because main.c is not built with -flto. -- 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 46737] New: Inlining introduces illegal ptrtoint
https://bugs.llvm.org/show_bug.cgi?id=46737
Bug ID: 46737
Summary: Inlining introduces illegal ptrtoint
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org
Bugpoint reduced IR:
```
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "text"
target datalayout =
"e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64-ni:10:11:12:13"
target triple = "armv7l-unknown-linux-gnueabihf"
define void @julia_show_tuple_as_call_23179() local_unnamed_addr {
top:
br i1 undef, label %L16.lr.ph, label %L51
L16.lr.ph:; preds = %top
unreachable
L51: ; preds = %top
%0 = addrspacecast [2 x {} addrspace(10)*]* undef to [2 x {} addrspace(10)*]
addrspace(11)*
call fastcc void @julia_show_signature_function_32381([2 x {} addrspace(10)*]
addrspace(11)* nocapture readonly %0)
ret void
}
define dso_local fastcc void @julia_show_signature_function_32381([2 x {}
addrspace(10)*] addrspace(11)* nocapture nonnull readonly align 4
dereferenceable(8) %0) unnamed_addr {
top:
%1 = bitcast [2 x {} addrspace(10)*] addrspace(11)* %0 to i64 addrspace(11)*
ret void
}
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"Debug Info Version", i32 3}
```
reproducible with `opt bugpoint-reduced-simplified.ll -inline`.
Inlining produces
```
define void @julia_show_tuple_as_call_23179() local_unnamed_addr {
top:
br i1 undef, label %L16.lr.ph, label %L51
L16.lr.ph:; preds = %top
unreachable
L51: ; preds = %top
%0 = addrspacecast [2 x {} addrspace(10)*]* undef to [2 x {} addrspace(10)*]
addrspace(11)*
%ptrint = ptrtoint [2 x {} addrspace(10)*] addrspace(11)* %0 to i32
%maskedptr = and i32 %ptrint, 3
%maskcond = icmp eq i32 %maskedptr, 0
call void @llvm.assume(i1 %maskcond)
%1 = bitcast [2 x {} addrspace(10)*] addrspace(11)* %0 to i64 addrspace(11)*
ret void
}
```
--
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 46738] New: Crash with out of line defaulted constructor
https://bugs.llvm.org/show_bug.cgi?id=46738
Bug ID: 46738
Summary: Crash with out of line defaulted constructor
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dma...@mozilla.com
CC: froy...@gmail.com, htmldevelo...@gmail.com,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
This is present in trunk 11 as well as clang 9 and 10, maybe even earlier but I
haven't tested.
class c;
class B {
unsigned __stdcall d(c);
B();
};
B::B() = default;
clang -cc1 -triple i686-w64-windows-gnu -emit-obj -debug-info-kind=limited
-fms-extensions reduced.cpp
1. parser at end of file
2. reduced.cpp:6:4: LLVM IR generation of declaration 'B::B'
3. reduced.cpp:6:4: Generating code for declaration 'B::B'
#0 0x7ff72bd41a5e `anonymous
namespace'::ItaniumRecordLayoutBuilder::InitializeLayout
D:\src\llvm-project-11\clang\lib\AST\RecordLayoutBuilder.cpp:1257:0
#1 0x7ff72bd3b38a clang::ASTContext::getASTRecordLayout(class
clang::RecordDecl const *) const
D:\src\llvm-project-11\clang\lib\AST\RecordLayoutBuilder.cpp:3108:0
#2 0x7ff72b0ef833 clang::ASTContext::getTypeInfoImpl(class clang::Type
const *) const D:\src\llvm-project-11\clang\lib\AST\ASTContext.cpp:2234:0
#3 0x7ff72b0f0aaa clang::ASTContext::getTypeInfo(class clang::Type const
*) const D:\src\llvm-project-11\clang\lib\AST\ASTContext.cpp:1868:0
#4 0x7ff72baf7506 clang::MangleContext::mangleName(class
clang::GlobalDecl, class llvm::raw_ostream &)
D:\src\llvm-project-11\clang\lib\AST\Mangle.cpp:216:0
#5 0x7ff72b03b9ea getMangledNameImpl
D:\src\llvm-project-11\clang\lib\CodeGen\CodeGenModule.cpp:1069:0
#6 0x7ff72b036636 clang::CodeGen::CodeGenModule::getMangledName(class
clang::GlobalDecl)
D:\src\llvm-project-11\clang\lib\CodeGen\CodeGenModule.cpp:1171:0
#7 0x7ff72b07b1ed
clang::CodeGen::CGDebugInfo::CreateCXXMemberFunction(class clang::CXXMethodDecl
const *, class llvm::DIFile *, class llvm::DIType *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:1603:0
#8 0x7ff72b07bde0
clang::CodeGen::CGDebugInfo::CollectCXXMemberFunctions(class
clang::CXXRecordDecl const *, class llvm::DIFile *, class
llvm::SmallVectorImpl &, class llvm::DIType *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:1753:0
#9 0x7ff72b07ebfe clang::CodeGen::CGDebugInfo::CreateTypeDefinition(class
clang::RecordType const *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:2383:0
#10 0x7ff72b07f2ba clang::CodeGen::CGDebugInfo::CreateType(class
clang::RecordType const *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:2338:0
#11 0x7ff72b074136 clang::CodeGen::CGDebugInfo::getOrCreateType(class
clang::QualType, class llvm::DIFile *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:3130:0
#12 0x7ff72b073d72 clang::CodeGen::CGDebugInfo::getContextDescriptor(class
clang::Decl const *, class llvm::DIScope *)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:223:0
#13 0x7ff72b08410f
clang::CodeGen::CGDebugInfo::collectFunctionDeclProps(class clang::GlobalDecl,
class llvm::DIFile *, class llvm::StringRef &, class llvm::StringRef &, class
llvm::DIScope *&, class llvm::MDTupleTypedArrayWrapper &,
enum llvm::DINode::DIFlags &)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:0:0
#14 0x7ff72b086243 clang::CodeGen::CGDebugInfo::EmitFunctionStart(class
clang::GlobalDecl, class clang::SourceLocation, class clang::SourceLocation,
class clang::QualType, class llvm::Function *, bool, class
clang::CodeGen::CGBuilderTy &)
D:\src\llvm-project-11\clang\lib\CodeGen\CGDebugInfo.cpp:3782:0
#15 0x7ff72ba98049 clang::CodeGen::CodeGenFunction::StartFunction(class
clang::GlobalDecl, class clang::QualType, class llvm::Function *, class
clang::CodeGen::CGFunctionInfo const &, class clang::CodeGen::FunctionArgList
const &, class clang::SourceLocation, class clang::SourceLocation)
D:\src\llvm-project-11\clang\lib\CodeGen\CodeGenFunction.cpp:949:0
#16 0x7ff72ba9a59d clang::CodeGen::CodeGenFunction::GenerateCode(class
clang::GlobalDecl, class llvm::Function *, class clang::CodeGen::CGFunctionInfo
const &) D:\src\llvm-project-11\clang\lib\CodeGen\CodeGenFunction.cpp:1291:0
#17 0x7ff72bb3c78a clang::CodeGen::CodeGenModule::codegenCXXStructor(class
clang::GlobalDecl) D:\src\llvm-project-11\clang\lib\CodeGen\CGCXX.cpp:215:0
#18 0x7ff72b96e0b4 `anonymous namespace'::ItaniumCXXABI::emitCXXStructor
D:\src\llvm-project-11\clang\lib\CodeGen\ItaniumCXXABI.cpp:4155:0
#19 0x7ff72b042bdc
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(class clang::GlobalDecl,
class llvm::GlobalValue *)
D:\src\llvm-project-11\clang\lib\CodeGen\CodeGenModule.cpp:2876:0
#20 0x0
[llvm-bugs] [Bug 46688] omp_pteam_mem_alloc memory "Invalid constantexpr cast"
https://bugs.llvm.org/show_bug.cgi?id=46688 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||9dc327d1b74637dac6dc432fb66 ||f88711af16a55 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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46688, which changed state. Bug 46688 Summary: omp_pteam_mem_alloc memory "Invalid constantexpr cast" https://bugs.llvm.org/show_bug.cgi?id=46688 What|Removed |Added Status|RESOLVED|REOPENED 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 46688] omp_pteam_mem_alloc memory "Invalid constantexpr cast"
https://bugs.llvm.org/show_bug.cgi?id=46688 Alexey Bataev changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED -- 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 46739] New: Multi thread allocation performance issues
https://bugs.llvm.org/show_bug.cgi?id=46739
Bug ID: 46739
Summary: Multi thread allocation performance issues
Product: compiler-rt
Version: 11.0
Hardware: Other
OS: other
Status: NEW
Severity: release blocker
Priority: P
Component: scudo
Assignee: unassignedb...@nondot.org
Reporter: sy2@samsung.com
CC: llvm-bugs@lists.llvm.org
We try to apply scudo to android R os on Galaxy S20.
But scudo has allocation performance issue when we test Geekbench 5.1.1
multi-core cases.
Some cases got lower point than Jemalloc that we used previous android version.
Scudo Jemalloc
HTML51450 2886
Face Detection 3274 3749
(Higher is better)
These tests seems allocate a lot of large size of memory with 8 threads.
There are lock contention happened between threads when threads try to allocate
on secondary cache.
lockSlow, especially, is bottle-neck on these cases.
If we change HybridMutex::lock to use only "yield and trylock" as below, HTML5
score improve to 2161.
class HybridMutex {
public:
.
NOINLINE void lock() {
if (LIKELY(tryLock()))
return;
#ifdef __clang__
#pragma nounroll
#endif
while (true) {
yieldProcessor(NumberOfYields);
if (tryLock())
return;
}
}
We consider test result show lockSlow wake threads up is too slow.
This is not whole reason of multi-core test result, HybridMutex::lock has
performance problem to using android R os.
Could you invest these multi-thread allocation performance issue?
Thank you.
--
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 46740] New: Merge 00f3579aea6e3d4a4b7464c3db47294f71cef9e4 to 11.0
https://bugs.llvm.org/show_bug.cgi?id=46740 Bug ID: 46740 Summary: Merge 00f3579aea6e3d4a4b7464c3db47294f71cef9e4 to 11.0 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org This reverts most of a 5 patch series due to reports of miscompiles. The patches are 1cf6f210a2e [IR] Disable select ? C : undef -> C fold in ConstantFoldSelectInstruction unless we know C isn't poison. 469da663f2d [InstSimplify] Re-enable select ?, undef, X -> X transform when X is provably not poison 122b0640fc9 [InstSimplify] Don't fold vectors of partial undef in SimplifySelectInst if the non-undef element value might produce poison ac0af12ed2f [InstSimplify] Add test cases for opportunities to fold select ?, X, undef -> X when we can prove X isn't poison 9b1e95329af [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X transforms Some of them added new test cases which I left but change the CHECK lines. -- 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 46737] preserve-alignment-assumptions-during-inlining introduces illegal ptrtoint
https://bugs.llvm.org/show_bug.cgi?id=46737 Yichao Yu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Summary|Inlining introduces illegal |preserve-alignment-assumpti |ptrtoint|ons-during-inlining ||introduces illegal ptrtoint --- Comment #2 from Yichao Yu --- So this is indeed fixed on master. The issue is the alignment assumption and commit b74c6d2c9d8e57db96742094cc4daf98a258b412 first disables it by default and therefore hide the issue which lead to a deadend for my first bisect. The actual fix came in c95ffadb2474a4d8c4f598d94d35a9f31d9606cb which use operand bundle to encode the alignment and removes the need for the `ptrtoint`. -- 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
