[llvm-bugs] [Bug 46341] New: Name resolution issue for inherited member in local class of templated function
https://bugs.llvm.org/show_bug.cgi?id=46341
Bug ID: 46341
Summary: Name resolution issue for inherited member in local
class of templated function
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: stephane.zimmerm...@trust-in-soft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 23618
--> https://bugs.llvm.org/attachment.cgi?id=23618&action=edit
Test file
With the following test.cpp file:
template
struct Bar {
int f;
};
template
int foo() {
struct Baz: Bar {
int func() { return f; }
};
return 0;
}
int
main()
{
foo();
}
The command `clang++ test.cpp` yields:
> test.cpp:11:29: error: use of undeclared identifier 'f'
>int func() { return f; }
This seems to be incorrect, since `f` in this case is declared as a field of
`Bar` and should be found during the member name lookup.
This can be seen and tested in compiler explorer here:
https://godbolt.org/z/frfoDA
--
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 46342] New: std::variant compiles with exception handling
https://bugs.llvm.org/show_bug.cgi?id=46342
Bug ID: 46342
Summary: std::variant compiles with exception handling
Product: libc++
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Standards Issues
Assignee: unassignedclangb...@nondot.org
Reporter: n...@e-nick.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
This code includes exception handling. It must not include it, since both int
and double are exception safe types:
#include
int main(){
using V = std::variant;
V a = 5;
V b = 5.6;
a.swap(b);
}
Problem might be in standard library, since this does not emit exception handle
code:
#include
template
void sw(T &a, T &b){
auto c = a;
a = b;
b = c;
}
int main(){
using V = std::variant;
V a = 5;
V b = 5.6;
sw(a, b);
}
https://stackoverflow.com/questions/62404209/why-this-stdvariant-code-includes-exception-handling
--
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 46343] New: opt -jump-threading crashing after 69bdfb075b2
https://bugs.llvm.org/show_bug.cgi?id=46343 Bug ID: 46343 Summary: opt -jump-threading crashing after 69bdfb075b2 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 23619 --> https://bugs.llvm.org/attachment.cgi?id=23619&action=edit bbi-44193.ll reproducer Reproduce with: opt -S -o - bbi-44193.ll -jump-threading Result: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all-builtins/bin/opt -S -o - bbi-44193.ll -jump-threading 1. Running pass 'Function Pass Manager' on module 'bbi-44193.ll'. 2. Running pass 'Jump Threading' on function '@func_1' build-all-builtins/bin/opt[0x44fa1a4] build-all-builtins/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x44f7cde] build-all-builtins/bin/opt[0x44fa4bc] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f5300879890] build-all-builtins/bin/opt(_ZN4llvm11Instruction15eraseFromParentEv+0x36)[0x3d291c6] build-all-builtins/bin/opt(_ZN4llvm42RecursivelyDeleteTriviallyDeadInstructionsERNS_15SmallVectorImplINS_14WeakTrackingVHEEEPKNS_17TargetLibraryInfoEPNS_16MemorySSAUpdaterE+0x377)[0x4578bc7] build-all-builtins/bin/opt(_ZN4llvm52RecursivelyDeleteTriviallyDeadInstructionsPermissiveERNS_15SmallVectorImplINS_14WeakTrackingVHEEEPKNS_17TargetLibraryInfoEPNS_16MemorySSAUpdaterE+0x117)[0x4578257] build-all-builtins/bin/opt(_ZN4llvm22ConstantFoldTerminatorEPNS_10BasicBlockEbPKNS_17TargetLibraryInfoEPNS_14DomTreeUpdaterE+0x1d5)[0x4576955] build-all-builtins/bin/opt(_ZN4llvm17JumpThreadingPass12ProcessBlockEPNS_10BasicBlockE+0xebd)[0x425866d] build-all-builtins/bin/opt(_ZN4llvm17JumpThreadingPass7runImplERNS_8FunctionEPNS_17TargetLibraryInfoEPNS_13LazyValueInfoEPNS_9AAResultsEPNS_14DomTreeUpdaterEbSt10unique_ptrINS_18BlockFrequencyInfoESt14default_deleteISC_EESB_INS_21BranchProbabilityInfoESD_ISG_EE+0x56b)[0x4256f3b] build-all-builtins/bin/opt[0x4267543] build-all-builtins/bin/opt(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x484)[0x3d5ba34] build-all-builtins/bin/opt(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x38)[0x3d5bd08] build-all-builtins/bin/opt(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x51d)[0x3d5c35d] build-all-builtins/bin/opt(main+0x2acb)[0x24df54b] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f52ff305b97] build-all-builtins/bin/opt(_start+0x2a)[0x24c902a] Segmentation fault (core dumped) This starts happening with commit 69bdfb075b2: [IR] Clean up dead instructions after simplifying a conditional branch Change BasicBlock::removePredecessor to optionally return a vector of instructions which might be dead. Use this in ConstantFoldTerminator to delete them if they are dead. Reapply with a bug fix: don't drop the "!KeepOneInputPHIs" argument when removePredecessor calls PHINode::removeIncomingValue. Differential Revision: https://reviews.llvm.org/D80206 -- 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 46345] New: accept-invalid: values in out-of-line enum definition have the wrong scope
https://bugs.llvm.org/show_bug.cgi?id=46345
Bug ID: 46345
Summary: accept-invalid: values in out-of-line enum definition
have the wrong scope
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: sammcc...@google.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Clang accepts this presumably-invalid code, which MSVC and GCC both reject
(https://godbolt.org/z/_r9y6q):
class Foo { enum PrivateEnum : char; };
enum Foo::PrivateEnum : char { A };
char Unrelated() { return A; }
Here the values of PrivateEnum are visible in the *lexical* scope of the
definition (the file) instead of the logical scope (the class Foo).
--
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 45378] [X86] recent codegen regression for vector load and reduce
https://bugs.llvm.org/show_bug.cgi?id=45378 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||057c9c7ee00b Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #6) > Candidate Patch: https://reviews.llvm.org/D81547 Fixed in rG057c9c7ee00b -- 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 34730] Efficient check that all vector elements are zero
https://bugs.llvm.org/show_bug.cgi?id=34730 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||057c9c7ee00b --- Comment #5 from Simon Pilgrim --- (In reply to Simon Pilgrim from comment #4) > https://reviews.llvm.org/D81547 should catch this (once I've dealt with the > requested refactoring to combineVectorSizedSetCCEquality first). Fixed in rG057c9c7ee00b -- 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 46346] New: Add a checker to detected bad checks of mmap() return value
https://bugs.llvm.org/show_bug.cgi?id=46346 Bug ID: 46346 Summary: Add a checker to detected bad checks of mmap() return value Product: clang Version: unspecified Hardware: PC OS: OpenBSD Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: este...@gmail.com CC: dcough...@apple.com, llvm-bugs@lists.llvm.org The mmap() POSIX function returns MAP_FAILED or -1 when an error occurs. A common mistake is to check the return value for 0 instead. https://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.html Example: ``` buflen = statbuf.st_size; buf = mmap(NULL, buflen, PROT_READ, MAP_PRIVATE|MAP_POPULATE, fd, 0); - if (!buf) + if (buf == MAP_FAILED) goto err; *data = buf; ``` -- 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 16941] LLVM has performance regression between r173893 and r173901
https://bugs.llvm.org/show_bug.cgi?id=16941 Simon Pilgrim changed: What|Removed |Added Component|Scalar Optimizations|Backend: X86 Resolution|--- |FIXED Status|NEW |RESOLVED CC||craig.top...@gmail.com, ||llvm-...@redking.me.uk, ||spatel+l...@rotateright.com --- Comment #4 from Simon Pilgrim --- Resolving old ticket - we've fixed the compare + trunc/sext issues in recent years, especially when we started expanding movmsk to bitcast to iX in many cases. -- 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 46347] New: An iteration of a loop execute more than one ordered region which throw an error
https://bugs.llvm.org/show_bug.cgi?id=46347
Bug ID: 46347
Summary: An iteration of a loop execute more than one ordered
region which throw an error
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: yangzh.f...@cn.fujitsu.com
CC: llvm-bugs@lists.llvm.org
Hi,
Follow the OpenMP's Specfications:
During execution of an iteration of a worksharing-loop or a loop nest within a
worksharing-loop, simd, or worksharing-loop SIMD region, a thread must not
execute more than one ordered region corresponding to an ordered construct
without a depend clause.
https://www.openmp.org/spec-html/5.0/openmpsu97.html#x128-5010002.17.9
The following code shoule be error. But there is no error.
Example_ordered.2.c: This code comes from
https://www.openmp.org/wp-content/uploads/openmp-examples-5.0.0.pdf
void work(int i) {}
void ordered_wrong(int n)
{
int i;
#pragma omp for ordered
for (i=0; i___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46348] New: Assertion failure during report of duplicate symbol error
https://bugs.llvm.org/show_bug.cgi?id=46348 Bug ID: 46348 Summary: Assertion failure during report of duplicate symbol error Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com Created attachment 23620 --> https://bugs.llvm.org/attachment.cgi?id=23620&action=edit Reproducer Whilst experimenting with a script to generate some objects with debug data and then linking them, I ran into an assertion produced by LLD whilst it was reporting a duplicate symbol error. The full output is: PS C:\Work\TOOLCHAIN-5886> C:\llvm\build\Debug\bin\ld.lld.exe test.o test2.o -o test.elf --reproduce=repro.tar Assertion failed: Val && "isa<> used on a null pointer", file C:\llvm\llvm-project\llvm\include\llvm/Support/Casting.h, line 104 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: C:\llvm\build\Debug\bin\ld.lld.exe test.o test2.o -o test.elf --reproduce=repro.tar #0 0x7ff639c3839c HandleAbort c:\llvm\llvm-project\llvm\lib\support\windows\signals.inc:408:0 #1 0x7ff9aac9c3e1 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x6c3e1) #2 0x7ff9aac9e039 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x6e039) #3 0x7ff9aaca3c65 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x73c65) #4 0x7ff9aaca37d7 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x737d7) #5 0x7ff9aaca1841 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x71841) #6 0x7ff9aaca41cf (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x741cf) #7 0x7ff639f8aecc llvm::isa_impl_cl::doit(class lld::elf::Symbol const *) c:\llvm\llvm-project\llvm\include\llvm\support\casting.h:104:0 #8 0x7ff639f8b5fb llvm::isa_impl_wrap::doit(class lld::elf::Symbol const *const &) c:\llvm\llvm-project\llvm\include\llvm\support\casting.h:132:0 #9 0x7ff639f8b647 llvm::isa_impl_wrap::doit(class lld::elf::Symbol *const &) c:\llvm\llvm-project\llvm\include\llvm\support\casting.h:124:0 #10 0x7ff639f5aff8 llvm::isa(class lld::elf::Symbol *const &) c:\llvm\llvm-project\llvm\include\llvm\support\casting.h:143:0 #11 0x7ff639f53168 llvm::dyn_cast(class lld::elf::Symbol *) c:\llvm\llvm-project\llvm\include\llvm\support\casting.h:339:0 #12 0x7ff63a042d6f lld::elf::InputSectionBase::getObjMsg(unsigned __int64) c:\llvm\llvm-project\lld\elf\inputsection.cpp:350:0 #13 0x7ff63a074d6a reportDuplicate c:\llvm\llvm-project\lld\elf\symbols.cpp:643:0 #14 0x7ff63a073861 lld::elf::Symbol::resolveDefined(class lld::elf::Defined const &) c:\llvm\llvm-project\lld\elf\symbols.cpp:691:0 #15 0x7ff63a0731a4 lld::elf::Symbol::resolve(class lld::elf::Symbol const &) c:\llvm\llvm-project\lld\elf\symbols.cpp:425:0 #16 0x7ff63a036ab8 lld::elf::ObjFile>::initializeSymbols(void) c:\llvm\llvm-project\lld\elf\inputfiles.cpp:1142:0 #17 0x7ff63a03b5c4 lld::elf::ObjFile>::parse(bool) c:\llvm\llvm-project\lld\elf\inputfiles.cpp:402:0 #18 0x7ff639fb2625 doParseFile > c:\llvm\llvm-project\lld\elf\inputfiles.cpp:209:0 #19 0x7ff639fafeff lld::elf::parseFile(class lld::elf::InputFile *) c:\llvm\llvm-project\lld\elf\inputfiles.cpp:222:0 #20 0x7ff639f5b90f lld::elf::LinkerDriver::link>(class llvm::opt::InputArgList &) c:\llvm\llvm-project\lld\elf\driver.cpp:1870:0 #21 0x7ff639f299b5 lld::elf::LinkerDriver::main(class llvm::ArrayRef) c:\llvm\llvm-project\lld\elf\driver.cpp:526:0 #22 0x7ff639f2b55c lld::elf::link(class llvm::ArrayRef, bool, class llvm::raw_ostream &, class llvm::raw_ostream &) c:\llvm\llvm-project\lld\elf\driver.cpp:119:0 #23 0x7ff639b50942 main c:\llvm\llvm-project\lld\tools\lld\lld.cpp:149:0 #24 0x7ff6404485c4 invoke_main d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:79:0 #25 0x7ff6404484ae __scrt_common_main_seh d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0 #26 0x7ff64044836e __scrt_common_main d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:331:0 #27 0x7ff640448659 mainCRTStartup d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp:17:0 #28 0x7ff9f4307bd4 (C:\WINDOWS\System32\KERNEL32.DLL+0x17bd4) #29 0x7ff9f488ce51 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x6ce51) I'll attach the repro.tar file too. -- 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 46349] New: Assert when running llvm-lto on bitcode module containing GlobalIFunc
https://bugs.llvm.org/show_bug.cgi?id=46349
Bug ID: 46349
Summary: Assert when running llvm-lto on bitcode module
containing GlobalIFunc
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Linker
Assignee: unassignedb...@nondot.org
Reporter: itay.bookst...@nextsilicon.com
CC: llvm-bugs@lists.llvm.org
Running llvm-lto on the following code hits an assert in LTOModule.cpp.
// try.ll
@foo2 = dso_local alias void (), void ()* @foo
@foo = dso_local ifunc void (), bitcast (i8* ()* @foo_ifunc to void ()*)
; Function Attrs: noinline nounwind optnone uwtable
define internal i8* @foo_ifunc() #0 {
entry:
ret i8* bitcast (void ()* @foo_impl to i8*)
}
; Function Attrs: noinline nounwind optnone uwtable
define internal void @foo_impl() #0 {
entry:
ret void
}
// build.sh
llvm-as try.ll -o try.bc
llvm-lto try.bc
Stack trace:
llvm-lto:
/local/users/itay/Projects/llvm-project/llvm/lib/LTO/LTOModule.cpp:610: void
llvm::LTOModule::parseSymbols(): Assertion `isa(GV)' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: ../../Projects/llvm-project/Debug/bin/llvm-lto
try.bc
#0 0x0584fb09 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/local/users/itay/Projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:11
#1 0x0584fcb9 PrintStackTraceSignalHandler(void*)
/local/users/itay/Projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1
#2 0x0584e446 llvm::sys::RunSignalHandlers()
/local/users/itay/Projects/llvm-project/llvm/lib/Support/Signals.cpp:67:5
#3 0x0585045b SignalHandler(int)
/local/users/itay/Projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1
#4 0x7f4a9f6ea730 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12730)
#5 0x7f4a9f1ee7bb raise (/lib/x86_64-linux-gnu/libc.so.6+0x377bb)
#6 0x7f4a9f1d9535 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22535)
#7 0x7f4a9f1d940f (/lib/x86_64-linux-gnu/libc.so.6+0x2240f)
#8 0x7f4a9f1e7102 (/lib/x86_64-linux-gnu/libc.so.6+0x30102)
#9 0x054cf65a llvm::LTOModule::parseSymbols()
/local/users/itay/Projects/llvm-project/llvm/lib/LTO/LTOModule.cpp:611:26
#10 0x054cea1f llvm::LTOModule::makeLTOModule(llvm::MemoryBufferRef,
llvm::TargetOptions const&, llvm::LLVMContext&, bool)
/local/users/itay/Projects/llvm-project/llvm/lib/LTO/LTOModule.cpp:234:3
#11 0x054ce4d0 llvm::LTOModule::createFromFile(llvm::LLVMContext&,
llvm::StringRef, llvm::TargetOptions const&)
/local/users/itay/Projects/llvm-project/llvm/lib/LTO/LTOModule.cpp:119:10
#12 0x030d1291 main
/local/users/itay/Projects/llvm-project/llvm/tools/llvm-lto/llvm-lto.cpp:984:42
#13 0x7f4a9f1db09b __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2409b)
#14 0x030d002a _start
(../../Projects/llvm-project/Debug/bin/llvm-lto+0x30d002a)
fish: “../../Projects/llvm-project/Deb…” terminated by signal SIGABRT (Abort)
--
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 46350] New: DeadArgElim does not generate debug info for insertval/extractval instrs
https://bugs.llvm.org/show_bug.cgi?id=46350
Bug ID: 46350
Summary: DeadArgElim does not generate debug info for
insertval/extractval instrs
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: djordje.todoro...@syrmia.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
NOTE: This is found by the LLVM DI Checker utility
(https://github.com/djolertrk/llvm-di-checker). I am preparing an RFC, so this
will be used as a reference in the proposal.
Basically, an example as:
define internal { i32 } @fn1() !dbg !4 {
entry:
unreachable
}
define void @fn2() personality i32 (i32)* undef !dbg !8 {
entry:
%tmp2 = invoke { i32 } @fn1()
to label %bb3 unwind label %bb4, !dbg !15
bb3:
%tmp3 = phi { i32 } [ %tmp2, %entry ], !dbg !15
unreachable
bb4:
%tmp4 = landingpad { i8*, i32 }
cleanup, !dbg !15
unreachable
}
will end up (after $ opt -deadargelim -S) having the 'insertvalue' with no
debug location attached after the DeadArgElim pass.
Proposed fix: https://reviews.llvm.org/D81939
--
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 46351] New: std::stringstream generates vtable
https://bugs.llvm.org/show_bug.cgi?id=46351
Bug ID: 46351
Summary: std::stringstream generates vtable
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: d...@znu.io
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following code generates vtables whereas GNU C++ does not:
#include
std::string example(void *pointer) {
std::stringstream result;
result << "example";
return result.str();
}
This is both surprising and unfortunate. Here are the exported symbols on my
Linux box:
W __clang_call_terminate
U __cxa_begin_catch
U __cxa_end_catch
r GCC_except_table0
001c r GCC_except_table13
0034 r GCC_except_table15
0078 r GCC_except_table16
U __gxx_personality_v0
U memset
U _Unwind_Resume
T _Z7examplePv
U _ZdlPv
W
_ZNKSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strEv
U
_ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv
U _ZNKSt3__16locale9use_facetERNS0_2idE
U _ZNKSt3__18ios_base6getlocEv
U
_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6resizeEmc
U
_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE9push_backEc
U _ZNSt3__113basic_istreamIcNS_11char_traitsIcEEED0Ev
U _ZNSt3__113basic_istreamIcNS_11char_traitsIcEEED1Ev
U
_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_
U _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev
U _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEED0Ev
U _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEED1Ev
U _ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEED0Ev
U _ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEED1Ev
U _ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEED2Ev
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4syncEv
U
_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5imbueERKNS_6localeE
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5uflowEv
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6setbufEPcl
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6xsgetnEPcl
U
_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6xsputnEPKcl
U
_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9showmanycEv
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEEC2Ev
U _ZNSt3__115basic_streambufIcNS_11char_traitsIcEEED2Ev
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE7seekoffExNS_8ios_base7seekdirEj
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE7seekposENS_4fposI11__mbstate_tEEj
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE8overflowEi
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE9pbackfailEi
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE9underflowEv
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev
W
_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev
W
_ZNSt3__116__pad_and_outputIcNS_11char_traitsIcNS_19ostreambuf_iteratorIT_T0_EES6_PKS4_S8_S8_RNS_8ios_baseES4_
W
_ZNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED0Ev
W
_ZNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev
W
_ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcRNS_13basic_ostreamIT_T0_EES7_PKS4_m
U _ZNSt3__15ctypeIcE2idE
U _ZNSt3__16localeD1Ev
U _ZNSt3__18ios_base33__set_badbit_and_consider_rethrowEv
U _ZNSt3__18ios_base4initEPv
U _ZNSt3__18ios_base5clearEj
U _ZNSt3__19basic_iosIcNS_11char_traitsIcEEED2Ev
U _Znwm
U _ZSt9terminatev
V
_ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIc0_NS_13basic_istreamIcS2_EE
V
_ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIc0_NS_14basic_iostreamIcS2_EE
V
_ZTCNSt3__118basic_stringstreamIcNS_11char_traitsIcEENS_9allocatorIc16_NS_13basic_ostreamIcS2_EE
U _ZThn16_NSt3__114basic_iostreamIcNS_11char_traitsIcEEED0E
[llvm-bugs] [Bug 46339] Weird error messages in different versions of clang or in a newline
https://bugs.llvm.org/show_bug.cgi?id=46339 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Smith --- This is working as intended. After the first error in Clang <= 10, we gave up, whereas in trunk we're able to recover and keep parsing, which is why more errors are now reported for the later invalid code after the first error. We intentionally use newlines as a clue to improve our diagnostics in the case where a semicolon is missing. So I think this is all working as intended. -- 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 46341] Name resolution issue for inherited member in local class of templated function
https://bugs.llvm.org/show_bug.cgi?id=46341 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- This code is invalid. See http://clang.llvm.org/compatibility.html#dep_lookup_bases or https://eli.thegreenplace.net/2012/02/06/dependent-name-lookup-for-c-templates for an explanation. Use this->f to name f as a member of a dependent base class. -- 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 46334] Equivalence statement broken for integer case
https://bugs.llvm.org/show_bug.cgi?id=46334 Nichols A. Romero changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Nichols A. Romero --- Tim and Steve, Sorry, I should of just looked up the ISO standard but I have been assuming if another compiler can handle it, f18 should too. NWChem developers have created a work around. I am going to close this issue. -- 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 46186] invalid operand in inline asm from Linux kernel's fs/readdir.c
https://bugs.llvm.org/show_bug.cgi?id=46186 Nick Desaulniers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Desaulniers --- https://github.com/llvm/llvm-project/commit/2d8e105db6bea10a6b96e4a094e73a87987ef909 -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 46186, which changed state. Bug 46186 Summary: invalid operand in inline asm from Linux kernel's fs/readdir.c https://bugs.llvm.org/show_bug.cgi?id=46186 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 46352] New: PCH header is still parsed and included leading to redefinition errors (does not happen with clang-cl/GCC style pch)
https://bugs.llvm.org/show_bug.cgi?id=46352
Bug ID: 46352
Summary: PCH header is still parsed and included leading to
redefinition errors (does not happen with clang-cl/GCC
style pch)
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nok.ra...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
// test.cpp
#include
int main() {}
// pch.hpp
#include
>clang++ -c pch.hpp -I. -Xclang -emit-pch -o pch.pch
>clang++ test.cpp -I. -Xclang -include-pch -Xclang pch.pch -o test
In file included from test.cpp:1:
.\pch.hpp:1:7: error: redefinition of 'X'
class X {};
^
test.cpp:1:1: note: '.\pch.hpp' included multiple times, additional include
site here
#include
^
test.cpp:1:10: note: '.\pch.hpp' included multiple times, additional include
site here
#include
^
.\pch.hpp:1:7: note: unguarded header; consider using #ifdef guards or #pragma
once
class X {};
^
1 error generated.
Clang with GCC style PCH, Clang-cl, GCC, and MSVC are fine:
// pch.cpp
#include
>clang++ -c -x c++-header pch.hpp -I. -o pch.hpp.gch
>clang++ test.cpp -I. -o test
>clang-cl -c pch.cpp -I. -Yc"pch.hpp" -Fo"pch.o" -Fp"pch.pch"
>clang-cl test.cpp -I. -Yu"pch.hpp" -Fp"pch.pch"
>cl -c pch.cpp -I. -Yc"pch.hpp" -Fo"pch.o" -Fp"pch.pch"
>cl -c test.cpp -I. -Yu"pch.hpp" -Fp"pch.pch" -Fo"test.o"
>g++ -c -x c++-header pch.hpp -I. -o pch.hpp.gch
>g++ test.cpp -I. -o test
--
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 46352] PCH header is still parsed and included leading to redefinition errors (does not happen with clang-cl/GCC style pch)
https://bugs.llvm.org/show_bug.cgi?id=46352 Nikita Kniazev changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Nikita Kniazev --- Ok, I was looking at the wrong manual https://clang.llvm.org/docs/PCHInternals.html, there is a note in https://clang.llvm.org/docs/UsersManual.html#precompiled-headers that says Clang does not automatically use PCH on includes inside source files, so you have to *not* include the header yourself. -- 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 46347] An iteration of a loop execute more than one ordered region which throw an error
https://bugs.llvm.org/show_bug.cgi?id=46347 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||3488e8c21cec8bac7dabd8f6b7c ||642dbace31d65 Status|NEW |RESOLVED CC||a.bat...@hotmail.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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 46220, which changed state. Bug 46220 Summary: Merge 7c9a89fed8f5d53d61fe3a61a2581a7c28b1b6d2 and 3408dcbdf054ac3cc32a97a6a82a3cf5844be609 to 10.0.1 https://bugs.llvm.org/show_bug.cgi?id=46220 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 46220] Merge 7c9a89fed8f5d53d61fe3a61a2581a7c28b1b6d2 and 3408dcbdf054ac3cc32a97a6a82a3cf5844be609 to 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=46220 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|7c9a89fed8f5d53d61fe3a61a25 |7c9a89fed8f5d53d61fe3a61a25 |81a7c28b1b6d2 |81a7c28b1b6d2 |3408dcbdf054ac3cc32a97a6a82 |3408dcbdf054ac3cc32a97a6a82 |a3cf5844be609 |a3cf5844be609 0f99a730e3b ||ea65b89665c Resolution|--- |FIXED --- Comment #1 from Tom Stellard --- Merged: ea65b89665c -- 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 46051] Please backport 88aad9b9f05 (lit googletest.py: Don't raise StopIteration in generator) to 10.x
https://bugs.llvm.org/show_bug.cgi?id=46051 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|88aad9b9f05702585eb823d0188 |88aad9b9f05702585eb823d0188 |996f4cf62070a |996f4cf62070a 756b482c69b Status|NEW |RESOLVED --- Comment #2 from Tom Stellard --- Merged: 756b482c69b -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 46051, which changed state. Bug 46051 Summary: Please backport 88aad9b9f05 (lit googletest.py: Don't raise StopIteration in generator) to 10.x https://bugs.llvm.org/show_bug.cgi?id=46051 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 46336] clang assert when using PragmaLoopHint with c++11 attribute.
https://bugs.llvm.org/show_bug.cgi?id=46336 Yuanfang Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Yuanfang Chen --- Resolved with 4676cf444ea2678660ee48279be99efde4bf60e9 8c6c606cdc72c3ddd55f382d91ef1afc3cb9f2a8 -- 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 45819] Nondeterminism of iterators causes false ThinLTO cache misses
https://bugs.llvm.org/show_bug.cgi?id=45819 Yuanfang Chen 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 46353] New: nullPointerConstant AST matcher triggers assert(!isNull()) in QualType::getCommonPtr
https://bugs.llvm.org/show_bug.cgi?id=46353
Bug ID: 46353
Summary: nullPointerConstant AST matcher triggers
assert(!isNull()) in QualType::getCommonPtr
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: luka...@chromium.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
REPRO STEPS:
1. Augment TEST(NullPointerConstants, Basic) in
clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp with the following
test code:
2612 const char kTest[] = R"(
2613 template
2614 struct MyTemplate {
2615 MyTemplate() : field_(__null) {}
2616 T* field_;
2617 };
2618 )";
2619 EXPECT_TRUE(matches(kTest, expr(nullPointerConstant(;
2. Build the unit tests:
$ cd ~/src/llvm-project/build
$ ninja tools/clang/unittests/ASTMatchers/ASTMatchersTests
3. Run the unit tests:
$ python3.7 ~/src/llvm-project/build/bin/llvm-lit -sv --param USE_Z3_SOLVER=0
~/src/llvm-project/build/tools/clang/test --filter=.*NullPointerConstants.*
EXPECTED BEHAVIOR:
1) no asserts or crashes
2) the |__null| expression is matched
ACTUAL BEHAVIOR: assert:
ASTMatchersTests:
/usr/local/google/home/lukasza/src/llvm-project/clang/include/clang/AST/Type.h:671:
const clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() const:
Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.
(I am sorry, but I don't know how to symbolize the callstack...)
NOTES:
*) The original repro used |NULL| rather than |__null|. I've used |__null|
above, to avoid having to include (which is rather difficult in unit
tests, which expect self-contained inputs).
*) It seems that recently there were some changes in the AST Matchers library
that have been highlighted in the release notes:
https://clang.llvm.org/docs/ReleaseNotes.html#ast-matchers
--
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 46354] New: Missing warning -Wthread-safety-negative when using capabilities in namespace scope
https://bugs.llvm.org/show_bug.cgi?id=46354
Bug ID: 46354
Summary: Missing warning -Wthread-safety-negative when using
capabilities in namespace scope
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: aaronpuch...@alice-dsl.net
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
With mutex.h from https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutex-h
and -Wthread-safety-negative, there is a warning on
class Foo {
Mutex mu;
public:
void foo() {
mu.Lock(); // acquiring mutex 'mu' requires negative capability '!mu'
mu.Unlock();
}
};
but not on
Mutex mu;
void foo() {
mu.Lock();
mu.Unlock();
}
That's inconsistent, and probably also unintended: "The analyzer assumes that
it holds a negative capability for any object that is not defined within the
current lexical scope. The scope of a class member is assumed to be its
enclosing class, while the scope of a global variable is the translation unit
in which it is defined." [1]
[1]
https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42958.pdf
--
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 46355] New: Crash when deserializing ASTs with certain concept constructs
https://bugs.llvm.org/show_bug.cgi?id=46355
Bug ID: 46355
Summary: Crash when deserializing ASTs with certain concept
constructs
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: aaronpuch...@alice-dsl.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Create bug.hpp with
template
concept Foo = true;
template
struct Bug
{
template T>
Bug(T&&) requires true;
template T>
Bug(T&&);
};
template
Bug(T1, T2) -> Bug;
and bug.cpp with
Bug bug(1.0, false);
Then run
clang -cc1 -std=c++2a bug.hpp -emit-pch -o bug.pch
clang -cc1 -std=c++2a -fsyntax-only -include-pch bug.pch bug.cpp
This results in a crash with stack
#5 clang::ConceptReference::getNamedConcept() const
clang/include/clang/AST/ASTConcept.h:155:12
#6 isSameTemplateParameter(clang::NamedDecl const*, clang::NamedDecl const*)
clang/lib/Serialization/ASTReaderDecl.cpp:2906:38
#7 isSameTemplateParameterList(clang::ASTContext const&,
clang::TemplateParameterList const*, clang::TemplateParameterList const*)
clang/lib/Serialization/ASTReaderDecl.cpp:2997:9
#8 isSameEntity(clang::NamedDecl*, clang::NamedDecl*)
clang/lib/Serialization/ASTReaderDecl.cpp:3199:12
#9 clang::ASTDeclReader::findExisting(clang::NamedDecl*)
clang/lib/Serialization/ASTReaderDecl.cpp:3485:13
#10 void
clang::ASTDeclReader::mergeRedeclarable(clang::Redeclarable*,
clang::ASTDeclReader::RedeclarableResult&, unsigned int)
clang/lib/Serialization/ASTReaderDecl.cpp:2493:31
#11
clang::ASTDeclReader::VisitRedeclarableTemplateDecl(clang::RedeclarableTemplateDecl*)
clang/lib/Serialization/ASTReaderDecl.cpp:2078:15
#12
clang::ASTDeclReader::VisitFunctionTemplateDecl(clang::FunctionTemplateDecl*)
clang/lib/Serialization/ASTReaderDecl.cpp::31
#13 clang::declvisitor::Base::Visit(clang::Decl*) clang/include/clang/AST/DeclNodes.inc:213:1
#14 clang::ASTDeclReader::Visit(clang::Decl*)
clang/lib/Serialization/ASTReaderDecl.cpp:519:37
#15 clang::ASTReader::ReadDeclRecord(unsigned int)
clang/lib/Serialization/ASTReaderDecl.cpp:4048:40
#16 clang::ASTReader::GetDecl(unsigned int)
clang/lib/Serialization/ASTReader.cpp:7422:5
#17 clang::ASTReader::FindExternalVisibleDeclsByName(clang::DeclContext const*,
clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp:7613:21
#18 clang::DeclContext::lookup(clang::DeclarationName) const
clang/lib/AST/DeclBase.cpp:1665:60
#19 clang::Sema::DeclareImplicitDeductionGuides(clang::TemplateDecl*,
clang::SourceLocation) clang/lib/Sema/SemaTemplate.cpp:2345:18
#20 DeclareImplicitMemberFunctionsWithName(clang::Sema&,
clang::DeclarationName, clang::SourceLocation, clang::DeclContext const*)
clang/lib/Sema/SemaLookup.cpp:1020:5
#21 LookupDirect(clang::Sema&, clang::LookupResult&, clang::DeclContext const*)
clang/lib/Sema/SemaLookup.cpp:1038:35
#22 clang::Sema::LookupQualifiedName(clang::LookupResult&, clang::DeclContext*,
bool) clang/lib/Sema/SemaLookup.cpp:2252:7
#23
clang::Sema::DeduceTemplateSpecializationFromInitializer(clang::TypeSourceInfo*,
clang::InitializedEntity const&, clang::InitializationKind const&,
llvm::MutableArrayRef) clang/lib/Sema/SemaInit.cpp:9784:10
#24 clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*,
clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*,
clang::SourceRange, bool, clang::Expr*) clang/lib/Sema/SemaDecl.cpp:11444:12
#25 clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool,
clang::Expr*) clang/lib/Sema/SemaDecl.cpp:11538:26
#26 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool)
clang/lib/Sema/SemaDecl.cpp:11889:9
#27
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
clang/lib/Parse/ParseDecl.cpp:2456:3
#28 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
clang/lib/Parse/ParseDecl.cpp:2128:9
#29
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
clang/lib/Parse/Parser.cpp:1099:10
#30
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
clang/lib/Parse/Parser.cpp:1115:12
#31
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) clang/lib/Parse/Parser.cpp:935:12
#32 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&,
bool) clang/lib/Parse/Parser.cpp:683:12
#33
clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr&)
clang/lib/Parse/Parser.cpp:555:8
#34 clang::ParseAST(clang::Sema&,
[llvm-bugs] [Bug 45323] Spurious -Wthread-safety warning in template class
https://bugs.llvm.org/show_bug.cgi?id=45323 Eli Friedman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Eli Friedman --- Yes, 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 46356] New: Wrong optimization of a division by zero
https://bugs.llvm.org/show_bug.cgi?id=46356
Bug ID: 46356
Summary: Wrong optimization of a division by zero
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: qia...@cn.fujitsu.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The expression x/x is optimised to 1 when use -O1 or -O2 or -O3 option.
If x is 0, the result is not right. So this optimisation is wrong.
test case:
-
#include
unsigned foo(unsigned x) {
return x/x;
}
int main()
{
printf("result is %d\n", foo(0));
}
test commands:
-
#clang --version
clang version 10.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
#clang -O1 div.c
#./a.out
result is 1
#clang -O1 div.c -S
#cat div.s
.text
.file "div.c"
.globl foo # -- Begin function foo
.p2align4, 0x90
.type foo,@function
foo:# @foo
.cfi_startproc
# %bb.0:# %entry
movl$1, %eax
retq
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
..
I tested this in trunk, and get the same result.
--
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 46356] Wrong optimization of a division by zero
https://bugs.llvm.org/show_bug.cgi?id=46356 Craig Topper changed: What|Removed |Added CC||craig.top...@gmail.com Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Craig Topper --- Integer division by 0 is undefined behavior. We aren't required to produce any particular result and we aren't required to trap. gcc also produces a value of 1. -- 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 46357] New: clang++ throws errors when the redefinition struct in user-defined reduction in CPP file
https://bugs.llvm.org/show_bug.cgi?id=46357
Bug ID: 46357
Summary: clang++ throws errors when the redefinition struct in
user-defined reduction in CPP file
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: yangzh.f...@cn.fujitsu.com
CC: llvm-bugs@lists.llvm.org
Hi,
This code throws errors when I use it in CPP file with clang++. In this code,
struct point which used in declare reduction has been defined. I think it
should be ok in CPP.
Example udr.1.c
This code comes from
https://www.openmp.org/wp-content/uploads/openmp-examples-5.0.0.pdf
#include
#include
struct point {
int x;
int y;
};
void minproc ( struct point *out, struct point *in )
{
if ( in->x < out->x ) out->x = in->x;
if ( in->y < out->y ) out->y = in->y;
}
void maxproc ( struct point *out, struct point *in )
{
if ( in->x > out->x ) out->x = in->x;
if ( in->y > out->y ) out->y = in->y;
}
#pragma omp declare reduction(min : struct point : \
minproc(&omp_out, &omp_in)) \
initializer( omp_priv = { INT_MAX, INT_MAX } )
#pragma omp declare reduction(max : struct point : \
maxproc(&omp_out, &omp_in)) \
initializer( omp_priv = { 0, 0 } )
void find_enclosing_rectangle ( int n, struct point points[] )
{
struct point minp = { INT_MAX, INT_MAX }, maxp = {0,0};
int i;
#pragma omp parallel for reduction(min:minp) reduction(max:maxp)
for ( i = 0; i < n; i++ ) {
minproc(&minp, &points[i]);
maxproc(&maxp, &points[i]);
}
printf("min = (%d, %d)\n", minp.x, minp.y);
printf("max = (%d, %d)\n", maxp.x, maxp.y);
}
command:
clang++ -fopenmp -S Example_udr.1.cpp
--
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 46358] New: WinException: Off-by-one building IP2state table
https://bugs.llvm.org/show_bug.cgi?id=46358
Bug ID: 46358
Summary: WinException: Off-by-one building IP2state table
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: sne...@dei.uc.pt
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Consider the following example C++ code:
#include
int main(int argc, char* argv[]) {
try {
try {
puts(new char[argc]());
} catch(...) {
return -2;
}
} catch(...) {
return -1;
}
}
It doesn't really matter what it does, all it matters is that there are a few
try..catch blocks that don't get elided. Compiling this with `clang-cl.exe -O2
-EHsc /FA /Fatest.asm test.cpp` we get in test.asm
$ip2state$main:
.long .Lfunc_begin0@IMGREL# IP
.long -1 # ToState
.long .Ltmp0@IMGREL+1 # IP
.long 1 # ToState
.long .Ltmp1@IMGREL+1 # IP
.long -1 # ToState
.long "?catch$3@?0?main@4HA"@IMGREL # IP
.long 3 # ToState
.long "?catch$4@?0?main@4HA"@IMGREL # IP
.long 2 # ToState
Now, as you can see, both beginning of the try block offsets in there are off
byte a single byte (the +1). I tracked this down to
https://github.com/llvm/llvm-project/blob/50155bcd46428eda1551efe9616f6611b0ef779a/llvm/lib/CodeGen/AsmPrinter/WinException.cpp#L885-L937
In particular, we have
// Emit an entry indicating that PCs after 'Label' have this EH state.
IPToStateTable.push_back(std::make_pair(getLabel(ChangeLabel),
StateChange.NewState));
but looking at the definition of getLabel, we see that (unless the target is
Aarch64, for whatever reason) it adds 1 to the address of its argument. The
following diff appears to fix this issue, although I do not know if it's a
proper fix:
diff --git a/llvm/lib/CodeGen/AsmPrinter/WinException.cpp
b/llvm/lib/CodeGen/AsmPrinter/WinException.cpp
index 039867557..b0d48458c 100644
--- a/llvm/lib/CodeGen/AsmPrinter/WinException.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/WinException.cpp
@@ -929,7 +929,7 @@ void WinException::computeIP2StateTable(
ChangeLabel = StateChange.PreviousEndLabel;
// Emit an entry indicating that PCs after 'Label' have this EH state.
IPToStateTable.push_back(
- std::make_pair(getLabel(ChangeLabel), StateChange.NewState));
+ std::make_pair(create32bitRef(ChangeLabel), StateChange.NewState));
// FIXME: assert that NewState is between CatchLow and CatchHigh.
}
}
With this patch, the above output becomes
$ip2state$main:
.long .Lfunc_begin0@IMGREL# IP
.long -1 # ToState
.long .Ltmp0@IMGREL # IP
.long 1 # ToState
.long .Ltmp1@IMGREL # IP
.long -1 # ToState
.long "?catch$3@?0?main@4HA"@IMGREL # IP
.long 3 # ToState
.long "?catch$4@?0?main@4HA"@IMGREL # IP
.long 2 # ToState
as expected.
--
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 46225] Backport LLD NOLOAD fix for 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=46225 Fangrui Song changed: What|Removed |Added Assignee|unassignedb...@nondot.org |i...@maskray.me Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Fangrui Song --- Done -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 46225, which changed state. Bug 46225 Summary: Backport LLD NOLOAD fix for 10.0.1 https://bugs.llvm.org/show_bug.cgi?id=46225 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 46327] Merge b8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55 into the 10.0.1
https://bugs.llvm.org/show_bug.cgi?id=46327 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|d5a186a60014dc1a8c979c978cb |d5a186a60014dc1a8c979c978cb |32aba7ecb9102 |32aba7ecb9102 |b8ae3fdfa579dbf366b1bb1cbfd |b8ae3fdfa579dbf366b1bb1cbfd |bf8c51db7fa55 |bf8c51db7fa55 aab50695971 ||bf89c5aeb89 --- Comment #7 from Tom Stellard --- Merged: bf89c5aeb89 -- 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 45309] [meta] 10.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=45309 Bug 45309 depends on bug 46327, which changed state. Bug 46327 Summary: Merge b8ae3fdfa579dbf366b1bb1cbfdbf8c51db7fa55 into the 10.0.1 https://bugs.llvm.org/show_bug.cgi?id=46327 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 46359] New: [OpenMP5.0] A worksharing region closely nested inside a worksharing region should return an error
https://bugs.llvm.org/show_bug.cgi?id=46359
Bug ID: 46359
Summary: [OpenMP5.0] A worksharing region closely nested inside
a worksharing region should return an error
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: suli...@cn.fujitsu.com
CC: llvm-bugs@lists.llvm.org
According to OpenMP5.0's Restriction：
2.20 Nesting of Regions
A worksharing region may not be closely nested inside a worksharing, loop,
task, taskloop, critical, ordered, atomic, or master region.
https://www.openmp.org/spec-html/5.0/openmpse28.html#x143-6330002.20
closely nested construct：
A construct nested inside another construct with no other construct nested
between them.
https://www.openmp.org/spec-html/5.0/openmpsu2.html#x9-80001.2.2
The following examples are non-conforming because the inner and outer loop
regions are closely nested，clang should report an error for case
nesting_restrict.2.c as nesting_restrict.1.c.
These testcases are from：
https://www.openmp.org/wp-content/uploads/openmp-examples-5.0.0.pdf
p378
nesting_restrict.1.c
---
void work(int i, int j) {}
void wrong1(int n)
{
#pragma omp parallel default(shared)
{
int i, j;
#pragma omp for
for (i=0; i___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46360] New: Merge r252892fea7088abbeff9476e0ecbacc091d135a0 into the 10.0 branch
https://bugs.llvm.org/show_bug.cgi?id=46360 Bug ID: 46360 Summary: Merge r252892fea7088abbeff9476e0ecbacc091d135a0 into the 10.0 branch Product: new-bugs Version: 10.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: yuanfang.c...@sony.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 45309 Is it OK to merge the following revision(s) to the 10.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=45309 [Bug 45309] [meta] 10.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 45610] Misoptimizations caused by "[ARM] Fix conditions for lowering to S[LR]I"
https://bugs.llvm.org/show_bug.cgi?id=45610 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Storsjö --- This was reverted in https://github.com/llvm/llvm-project/commit/52474992b1343d7c2876ed9d176cd963476af4e5, i.e. the bug was fixed/removed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44892] Regression with building with -fno-signed-zeros for AArch64
https://bugs.llvm.org/show_bug.cgi?id=44892 Martin Storsjö changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Storsjö --- There was a lot of work in this area afterwards, and I haven't run into this issue after that, so this bug can be closed. -- 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 46297] IR Linking of GlobalAliases does not preserve thread_local attribute
https://bugs.llvm.org/show_bug.cgi?id=46297 Itay Bookstein changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Itay Bookstein --- Fixed by https://reviews.llvm.org/D81605 -- 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
