[llvm-bugs] [Bug 47106] New: A variable should not be assigned values twice successively.(llvm-project/polly/lib/External/ppcg/gpu.c:line 5382-5383)
https://bugs.llvm.org/show_bug.cgi?id=47106 Bug ID: 47106 Summary: A variable should not be assigned values twice successively.(llvm-project/polly/lib/External/ppcg/gpu .c:line 5382-5383) Product: Polly Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: i...@ustchcs.com CC: llvm-bugs@lists.llvm.org A variable should not be assigned values twice successively. Maybe there is a typo. commit e3546c78cabfbf670391a57766872f0a8e28a423 llvm-project/polly/lib/External/ppcg/gpu.c:line 5382-5383 5377 index = pet_expr_access_get_index(expr); 5378 space = isl_multi_pw_aff_get_space(index); 5379 isl_multi_pw_aff_free(index); 5380 if (isl_space_domain_is_wrapping(space)) 5381 space = isl_space_domain_factor_domain(space); 5382 space2 = isl_space_copy(space); 5383 space2 = isl_space_from_domain(isl_space_domain(space)); 5384 id = pet_expr_access_get_ref_id(expr); 5385 space2 = isl_space_set_tuple_id(space2, isl_dim_out, id); 5386 space = isl_space_range_product(space2, space); 5387 space = isl_space_uncurry(space); 5388 5389 return isl_map_empty(space); Reported by: Ustchcs Toolsets Bugfinder (bugfinder-2.7: A variable should not be assigned values twice successively.) -- 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 20602] Clang unconditionally defines macros for SSE and SSE2
https://bugs.llvm.org/show_bug.cgi?id=20602 Brad Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||b...@comstyle.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 47107] New: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/llvm/tools/llvm-
https://bugs.llvm.org/show_bug.cgi?id=47107 Bug ID: 47107 Summary: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/llvm/tools/llvm-objcopy/M achO/MachOObjcopy.cpp:line 182 and184) Product: tools Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: llvm-objcopy/strip Assignee: unassignedb...@nondot.org Reporter: i...@ustchcs.com CC: alexander.v.shaposhni...@gmail.com, jake.h.ehrl...@gmail.com, jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org, ruppre...@google.com LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression. Config.StripSections appears twice on line 182 and 183. And Config.StripNonAlloc appears twice on line 181 and 183. commit e3546c78cabfbf670391a57766872f0a8e28a423 llvm-project/llvm/tools/llvm-objcopy/MachO/MachOObjcopy.cpp:line 181<-->183 181Config.StripAllGNU || Config.StripDWO || Config.StripNonAlloc || 182Config.StripSections || Config.Weaken || Config.DecompressDebugSections || 183Config.StripNonAlloc || Config.StripSections || Config.StripUnneeded || Reported by: Ustchcs Toolsets Bugfinder (bugfinder-2.3: LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.) -- 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 47108] New: Request merge of more AArch64 SVE fixes onto the LLVM 11 Release branch
https://bugs.llvm.org/show_bug.cgi?id=47108 Bug ID: 47108 Summary: Request merge of more AArch64 SVE fixes onto the LLVM 11 Release branch Product: libraries Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: david.sherw...@arm.com CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, smithp...@googlemail.com, ties.st...@arm.com Hi, can I ask if it's possible to get the following patches cherry-picked onto the LLVM 11 release branch? These fixes are related to CodeGen for AArch64 SVE and fixing issues with unwind information for SVE objects/registers. All of these fixes are related to SVE, therefore any behavioural differences can only be observed by compiling with +sve. There only two minor changes outside lib/Target/AArch64 where we now permit the printing of additional comments for some unwind info - these additional comments can only appear for SVE objects. The fixes are listed here: 0905d9f31ead399d054c5d2a2c353e690f5c8daa David Sherwood [SVE][CodeGen] Fix bug with store of unpacked FP scalable vectors f2916636f83dfeb4808a16045db0025783743471 Sander de Smalen [AArch64][SVE] Disable tail calls if callee does not preserve SVE regs. bb3344c7d8c2703c910dd481ada43ecaf11536a6 Sander de Smalen [AArch64][SVE] Add missing unwind info for SVE registers. fd6584a22043b254a323635c142b28ce80ae5b5b Sander de Smalen [AArch64][SVE] Fix CFA calculation in presence of SVE objects. These can be applied easily with: git cherry-pick fd6584a22043b254a323635c142b28ce80ae5b5b bb3344c7d8c2703c910dd481ada43ecaf11536a6 f2916636f83dfeb4808a16045db0025783743471 0905d9f31ead399d054c5d2a2c353e690f5c8daa If you have any problems please don't hesitate to contact me, Thanks, David. -- 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 37594] Crash during global initialization
https://bugs.llvm.org/show_bug.cgi?id=37594 Brad Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||b...@comstyle.com --- Comment #4 from Brad Smith --- Solaris 11.4 ships with LLVM/Clang 6. There are also prebuilt copies of the latest LLVM/Clang and AFAIK it should be possible to build it out of the src tree nowadays on SPARC. -- 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 39776] Crash on OpenBSD compiling ports/www/chromium
https://bugs.llvm.org/show_bug.cgi?id=39776 Brad Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||b...@comstyle.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 47109] New: UNREACHABLE executed at llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp:270!
https://bugs.llvm.org/show_bug.cgi?id=47109
Bug ID: 47109
Summary: UNREACHABLE executed at
llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.
cpp:270!
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: r...@tambre.ee
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
This occurs when compiling libunwind.cpp for AArch64. Seems to be a recent
regression introduced after the Clang 12 branch point.
clang++ unwind.cpp --target=aarch64-linux-gnu
unwind.cpp:
void a()
{
register long b __asm("x17");
asm("" : "+r"(b));
}
Stacktrace:
Register class not supported
UNREACHABLE executed at
/opt/llvm/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp:270!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/llvm/build/bin/clang-12 -cc1 -triple
aarch64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations
-disable-free -main-file-name unwind.cpp -mrelocation-model static
-mframe-pointer=non-leaf -fmath-errno -fno-rounding-math -mconstructor-aliases
-target-cpu generic -target-feature +neon -target-abi aapcs
-fallow-half-arguments-and-returns -fno-split-dwarf-inlining
-debugger-tuning=gdb -resource-dir /opt/llvm/build/lib/clang/12.0.0
-internal-isystem /usr/local/include -internal-isystem
/opt/llvm/build/lib/clang/12.0.0/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdeprecated-macro
-fdebug-compilation-dir /opt/llvm/dev -ferror-limit 19 -fno-signed-char
-fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics
-faddrsig -o /tmp/unwind-31afd1.o -x c++ unwind.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'unwind.cpp'.
4. Running pass 'RegBankSelect' on function '@_Z1av'
#0 0x05f4f3c7 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/opt/llvm/llvm/lib/Support/Unix/Signals.inc:563:11
#1 0x05f4f569 PrintStackTraceSignalHandler(void*)
/opt/llvm/llvm/lib/Support/Unix/Signals.inc:624:1
#2 0x05f4dd7b llvm::sys::RunSignalHandlers()
/opt/llvm/llvm/lib/Support/Signals.cpp:67:5
#3 0x05f4fc8d SignalHandler(int)
/opt/llvm/llvm/lib/Support/Unix/Signals.inc:405:1
#4 0x7fe2e81cb140 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
#5 0x7fe2e7ca3db1 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7fe2e7c8d537 abort ./stdlib/abort.c:81:7
#7 0x05e87524 /opt/llvm/llvm/lib/Support/ErrorHandling.cpp:210:3
#8 0x041889fb
llvm::AArch64RegisterBankInfo::getRegBankFromRegClass(llvm::TargetRegisterClass
const&, llvm::LLT) const
/opt/llvm/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp:272:1
#9 0x07702117 llvm::RegisterBankInfo::getRegBank(llvm::Register,
llvm::MachineRegisterInfo const&, llvm::TargetRegisterInfo const&) const
/opt/llvm/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:88:5
#10 0x04189bcd
llvm::AArch64RegisterBankInfo::getInstrMapping(llvm::MachineInstr const&) const
/opt/llvm/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp:582:27
#11 0x076fa7d4 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&)
/opt/llvm/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:630:25
#12 0x076fadc7
llvm::RegBankSelect::runOnMachineFunction(llvm::MachineFunction&)
/opt/llvm/llvm/lib/CodeGen/GlobalISel/RegBankSelect.cpp:705:11
#13 0x04e51d77
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/opt/llvm/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:8
#14 0x0551f542 llvm::FPPassManager::runOnFunction(llvm::Function&)
/opt/llvm/llvm/lib/IR/LegacyPassManager.cpp:1587:23
#15 0x055247a5 llvm::FPPassManager::runOnModule(llvm::Module&)
/opt/llvm/llvm/lib/IR/LegacyPassManager.cpp:1633:16
#16 0x0551fee6 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/opt/llvm/llvm/lib/IR/LegacyPassManager.cpp:1702:23
#17 0x0551fa16 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/opt/llvm/llvm/lib/IR/LegacyPassManager.cpp:614:16
#18 0x05524aa1 llvm::legacy::PassManager::run(llvm::Module&)
/opt/llvm/llvm/lib/IR/LegacyPassManager.cpp:1829:3
#19 0x0632023a (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
/opt/llvm/clang/lib/CodeGen/BackendUtil.cpp:969:3
#20 0x0631c333 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, ll
[llvm-bugs] [Bug 47110] New: Random crashes during build of Mozilla Firefox Nightly (optimized)
https://bugs.llvm.org/show_bug.cgi?id=47110 Bug ID: 47110 Summary: Random crashes during build of Mozilla Firefox Nightly (optimized) Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: hon...@firemni.cz CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Captured preprocessed files and shell scripts to reproduce: https://janbambas.cz/moz/bug1657972/stack1.tar.xz https://janbambas.cz/moz/bug1657972/stack2.tar.xz Original STR: - follow the build env [setup for mozilla firefox browser](https://firefox-source-docs.mozilla.org/setup/windows_build.html) - EXCEPTION: use MSVC2017 instead of 2019! - use a MOZCONFIG for an optimized `browser` build (I can provide one in case someone needs to really do this) - `./mach build` -- 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 47070] Bit-wise operators should not be used where logical operators should be used.( & should be &&)（llvm-project/clang-tools-extra/clangd/RIFF.cpp:line 32）
https://bugs.llvm.org/show_bug.cgi?id=47070 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||73a6a3646 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 47111] New: Failure to optimize code involving strnlen
https://bugs.llvm.org/show_bug.cgi?id=47111
Bug ID: 47111
Summary: Failure to optimize code involving strnlen
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
size_t f()
{
return strnlen("", 0);
}
This code can be transformed to `return 0;`. This transformation is done by
GCC, but not by LLVM. This is most likely caused by a lack of a builtin for
strnlen.
--
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 47112] New: Need a pedantic warning for switch statements with implicit default
https://bugs.llvm.org/show_bug.cgi?id=47112
Bug ID: 47112
Summary: Need a pedantic warning for switch statements with
implicit default
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: d...@znu.io
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
I learned recently that the C++ standard allows enums to contain values that
aren't valid, therefore a "covered" switch without a default might not handle
all values from the perspective of the standard.
It would be nice if this scenario had an opt-in pedantic warning. For example:
enum class Foo { A, B, C };
int exampleCoveredSwitch(Foo foo) {
switch (foo) {
case Foo::A: return 12;
case Foo::B: return 34;
case Foo::C: return 56;
}
// some kind of opt-in warning here about returning from a non-void
function
}
--
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 47113] New: googletest-timeout.py fails for 11.0.0-rc1 on AArch64 Linux
https://bugs.llvm.org/show_bug.cgi?id=47113 Bug ID: 47113 Summary: googletest-timeout.py fails for 11.0.0-rc1 on AArch64 Linux Product: new-bugs Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: diana.pi...@linaro.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 23839 --> https://bugs.llvm.org/attachment.cgi?id=23839&action=edit Output from running the test See attached log. -- 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 47114] New: Excessive moves when returning array from nested struct
https://bugs.llvm.org/show_bug.cgi?id=47114
Bug ID: 47114
Summary: Excessive moves when returning array from nested
struct
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: alex.gay...@gmail.com
CC: llvm-bugs@lists.llvm.org
Extracted from: https://github.com/rust-lang/rust/issues/74267
Given the following C code, the `b` and `c` functions are behaviorally
identical (https://godbolt.org/z/5eKxE5):
#include
#include
#define N 2
typedef struct {
size_t length;
size_t capacity;
uint8_t* data;
} String;
static String new_string() {
String s = {0, 0, NULL};
return s;
}
struct Arr {
String data[N];
};
struct Arr b() {
struct Arr data;
for (size_t i = 0; i < N; i++) {
data.data[i] = new_string();
}
return data;
}
struct PartialArr {
struct Arr value;
};
struct Arr c() {
struct PartialArr data;
String (*slots)[N] = &data.value.data;
for (size_t i = 0; i < N; i++) {
(*slots)[i] = new_string();
}
return data.value;
}
However, they end up optimized very differently:
b: # @b
mov rax, rdi
vxorps xmm0, xmm0, xmm0
vmovups xmmword ptr [rdi], xmm0
mov qword ptr [rdi + 16], 0
vmovups xmmword ptr [rdi + 24], xmm0
mov qword ptr [rdi + 40], 0
ret
c: # @c
vxorps xmm0, xmm0, xmm0
vmovaps xmmword ptr [rsp - 56], xmm0
mov qword ptr [rsp - 40], 0
vmovups xmmword ptr [rsp - 32], xmm0
mov rax, rdi
mov qword ptr [rsp - 16], 0
vmovups xmm0, xmmword ptr [rsp - 56]
vmovups xmmword ptr [rdi], xmm0
mov rcx, qword ptr [rsp - 40]
mov qword ptr [rdi + 16], rcx
mov rcx, qword ptr [rsp - 32]
mov qword ptr [rdi + 24], rcx
mov rcx, qword ptr [rsp - 40]
mov qword ptr [rdi + 16], rcx
vmovups xmm0, xmmword ptr [rsp - 32]
vmovups xmmword ptr [rdi + 24], xmm0
mov rcx, qword ptr [rsp - 16]
mov qword ptr [rdi + 40], rcx
ret
GCC is able to optimize this better:
b:
mov QWORD PTR [rdi], 0
mov QWORD PTR [rdi+8], 0
mov QWORD PTR [rdi+16], 0
mov QWORD PTR [rdi+24], 0
mov QWORD PTR [rdi+32], 0
mov QWORD PTR [rdi+40], 0
mov rax, rdi
ret
c:
mov QWORD PTR [rdi], 0
mov QWORD PTR [rdi+8], 0
mov QWORD PTR [rdi+16], 0
mov QWORD PTR [rdi+24], 0
mov QWORD PTR [rdi+32], 0
mov QWORD PTR [rdi+40], 0
mov rax, rdi
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 47116] New: Front end crashes when trying to export a type out of a module
https://bugs.llvm.org/show_bug.cgi?id=47116 Bug ID: 47116 Summary: Front end crashes when trying to export a type out of a module Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: vsti...@google.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk https://godbolt.org/z/6fEE3s I was trying to convert a header file to a module. The compiler complained that it could export a std:pair of a iterator class inside a template class (I was trying to emulate the behavior of a stl container.) My code is probably wrong because I don't know how modules work but it probably shouldn't crash. I found it with clang 10 on ubuntu, but it also happens on trunk (according to godbolt). -- 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 47117] New: "CommandLine Error: Option 'filter' registered more than once!" crash on startup in applications using libclang
https://bugs.llvm.org/show_bug.cgi?id=47117 Bug ID: 47117 Summary: "CommandLine Error: Option 'filter' registered more than once!" crash on startup in applications using libclang Product: clang Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: b...@lindev.ch CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Several applications that use (dynamically linked) libclang crash on startup with libclang 11-rc1, including doxygen and the Qt6 version of lupdate. $ ./bin/doxygen : CommandLine Error: Option 'filter' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Aborted (core dumped) Doxygen isn't doing anything funny like mixing shared and static libraries. The crash seems to happen in a global constructor in libclang, before even doxygen's main() is called. #0 0x73dd386f in raise () from /lib64/libc.so.6 #1 0x73db9538 in abort () from /lib64/libc.so.6 #2 0x7fffedc4cb39 in llvm::report_fatal_error(llvm::Twine const&, bool) () from /usr/lib64/libLLVMSupport.so.11.0 #3 0x7fffedc4c978 in llvm::report_fatal_error(char const*, bool) () from /usr/lib64/libLLVMSupport.so.11.0 #4 0x7fffedc32904 in ?? () from /usr/lib64/libLLVMSupport.so.11.0 #5 0x7fffedc24044 in ?? () from /usr/lib64/libLLVMSupport.so.11.0 #6 0x7fffedc2207d in llvm::cl::Option::addArgument() () from /usr/lib64/libLLVMSupport.so.11.0 #7 0x776ff910 in ?? () from /usr/lib64/libclang-cpp.so.11.0 #8 0x77702da6 in ?? () from /usr/lib64/libclang-cpp.so.11.0 #9 0x77fe1f0e in call_init () from /lib64/ld-linux-x86-64.so.2 #10 0x77fe1fec in _dl_init () from /lib64/ld-linux-x86-64.so.2 #11 0x77fd20ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #12 0x0001 in ?? () #13 0x7fffd8db in ?? () #14 0x in ?? () -- 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 37594] Crash during global initialization
https://bugs.llvm.org/show_bug.cgi?id=37594 Brian Vandenberg changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Brian Vandenberg --- Brad, As I noted in the original bug report, I'm using Solaris 10, not 11. -- 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 13022 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: i < getNumArgOperands() && "Out of bounds!"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 13022 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-guard_widening: ASSERT: i < getNumArgOperands() && "Out of bounds!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13022#c4 ClusterFuzz testcase 5177743224864768 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202008100615:202008110602 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 47118] New: Incorrect sigaction() interceptor on output param
https://bugs.llvm.org/show_bug.cgi?id=47118 Bug ID: 47118 Summary: Incorrect sigaction() interceptor on output param Product: compiler-rt Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: fuzzer Assignee: unassignedb...@nondot.org Reporter: pudd...@google.com CC: llvm-bugs@lists.llvm.org Under certain circumstances, the sigaction() interceptor will return success without taking any action: compiler-rt/lib/sanitizer_common/sanitizer_signal_interceptors.inc line 56 This is intentional, to prevent certain signals from being overwritten. However, the third parameter to sigaction() is an output parameter, used for reading the current signal state. If this 'early return zero' behavior triggers, this structure will never be written to, leaving possibly-uninitialized bytes behind. This can cause errors in a program being fuzzed that only occur during fuzzing; and if compiled with MSan, can cause incorrect crashes. One reasonable behavior: rather than directly return zero, call the real sigaction implementation with a null second parameter. This prevents it from making any changes, but still allows reading. This was discovered while doing MSan fuzzing of the Python runtime - it uses sigaction() during 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 47119] New: ICE: is_invocable_v (access via :: of non static member)
https://bugs.llvm.org/show_bug.cgi?id=47119
Bug ID: 47119
Summary: ICE: is_invocable_v (access via :: of non static
member)
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: familiebauma...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 23840
--> https://bugs.llvm.org/attachment.cgi?id=23840&action=edit
compiler output
Clang++ front-end crashes with the following code:
Compilation command: clang++ -std=c++17 sample.cpp
See here on godbolt: https://godbolt.org/z/o1xjK8
Code:
=
```
#include
struct S {
void Func() {
}
};
#include
int main()
{
auto lambda = [](const auto& cls) -> decltype(
std::remove_const_t>::Func()
) {};
auto isInv = std::is_invocable_v;
if (!isInv){
std::cout << "detected correctly";
}
return 0;
}
```
--
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 47107] LHS and RHS of a logical binary-operator (&&, ||), relational/equality binary-operator expression should not contain the same sub-expression.(llvm-project/llvm/tools/llvm-objco
https://bugs.llvm.org/show_bug.cgi?id=47107 Jordan Rupprecht changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||d2c18b598359f9b59314669ccd1 ||5070d07aeb68a Assignee|unassignedb...@nondot.org |ruppre...@google.com --- Comment #1 from Jordan Rupprecht --- Fixed by d2c18b598359f9b59314669ccd15070d07aeb68a, thanks for the report! -- 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 36641] llvm-ar should support multiple dashed arguments
https://bugs.llvm.org/show_bug.cgi?id=36641 Nico Weber changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Nico Weber --- d579c31d684678d2bf136cc8253616bb616bd5f6 fixed this long ago. -- 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 47120] New: Clang/LLVM Driver Crashes When Building for ARM32 MSVC Targets
https://bugs.llvm.org/show_bug.cgi?id=47120 Bug ID: 47120 Summary: Clang/LLVM Driver Crashes When Building for ARM32 MSVC Targets Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: falhuma...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23841 --> https://bugs.llvm.org/attachment.cgi?id=23841&action=edit Includes all the described attachments in the "Description" section above. I am using the latest Clang/LLVM 10 from Ubuntu's repositories in Ubuntu 20. I am trying to cross-compile a simple "Hello, world!" C++ application that targets the MSVC ABI from Linux for the ARM32 architecture (tested with both `armv4` and `armv7` targets). However, the driver errors out with a similar error to the following (showing `armv4-pc-windows-msvc` target output, but happens the same with `armv7-pc-windows-msvc` target): ``` fatal error: error in backend: Cannot select: 0x1c71840: ch = <> 0x1be3d48 In function: ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z clang: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 10.0.0-4ubuntu1 Target: armv4-pc-windows-msvc Thread model: posix InstalledDir: /usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/hello-76cbf3.cpp clang: note: diagnostic msg: /tmp/hello-76cbf3.sh clang: note: diagnostic msg: ``` Assuming I have mounted the `C:\Program Files (x86)` directory in my Linux machine to `/home/user/Program_Files_(x86)`, I have attached the CC and CXX scripts for C and C++ I am using, that wraps around the required arguments to build the MSVC `armv4` target in `cc_arm` and `cxx_arm` scripts, respectfully. I also attached the `hello.cpp` code I used for testing. I ran `cc_arm -o hello_arm.exe hello.cpp` command to compile the test binary and produce the above error. In addition, I attached the `hello-76cbf3.cpp` and `hello-76cbf3.sh` source code and script mentioned in the log above with the bug ticket. I have been able to reproduce the same issue with pre-built binaries for x64 targeting MSVC ABI running directly in Windows downloadable from: https://github.com/llvm/llvm-project/releases/download/llvmorg-10.0.0/LLVM-10.0.0-win64.exe. However, in both cross-compiling from Linux and compiling directly in Windows, I haven't had any issues with compiling for x64, x86, and ARM64 targets. Only ARM32 had the above 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 47122] New: target nowait segmentation fault
https://bugs.llvm.org/show_bug.cgi?id=47122
Bug ID: 47122
Summary: target nowait segmentation fault
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: xw111lu...@gmail.com
CC: llvm-bugs@lists.llvm.org
11.0.0 RC1 runs fine but current master doesn't.
int main()
{
int a = 0;
#pragma omp target map(tofrom: a) depend(out: a) nowait
{
int sum = 0;
for (int i = 0; i < 10; i++)
sum++;
a = 1;
}
#pragma omp taskwait
}
--
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 24826 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_unswitch: ASSERT: (Args.size() == FTy->getNumParams() || (FTy->isVarArg() && Args.size() > FTy->ge
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-08-11 Type: Bug New issue 24826 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_unswitch: ASSERT: (Args.size() == FTy->getNumParams() || (FTy->isVarArg() && Args.size() > FTy->ge https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24826 Detailed Report: https://oss-fuzz.com/testcase?key=5141049308348416 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_unswitch Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (Args.size() == FTy->getNumParams() || (FTy->isVarArg() && Args.size() > FTy->ge llvm::CallInst::init llvm::CallInst::Create Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202008100615:202008110602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5141049308348416 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 47123] New: lld fails to build on targets that need -latomic
https://bugs.llvm.org/show_bug.cgi?id=47123 Bug ID: 47123 Summary: lld fails to build on targets that need -latomic Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: jist...@redhat.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com In Rust CI, while trying to upgrade to LLVM 11 rc1, arm-unknown-linux-gnueabi failed to link lld due to missing symbols for Timer.cpp: https://github.com/rust-lang/rust/pull/73526#issuecomment-671549737 > [100%] Linking CXX executable ../../bin/lld > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: > ../../lib/liblldCommon.a(Timer.cpp.o): in function > `lld::ScopedTimer::stop()': > Timer.cpp:(.text._ZN3lld11ScopedTimer4stopEv+0x44): undefined reference to > `__atomic_fetch_add_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: > ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::millis() > const': > Timer.cpp:(.text._ZNK3lld5Timer6millisEv+0x8): undefined reference to > `__atomic_load_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: > ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::print(int, > double, bool) const': > Timer.cpp:(.text._ZNK3lld5Timer5printEidb+0x2c0): undefined reference to > `__atomic_load_8' > /x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/8.3.0/../../../../arm-unknown-linux-gnueabi/bin/ld: > ../../lib/liblldCommon.a(Timer.cpp.o): in function `lld::Timer::print()': > Timer.cpp:(.text._ZN3lld5Timer5printEv+0x34): undefined reference to > `__atomic_load_8' This can be solved by linking libatomic on targets that need it. I've tried to add this in https://reviews.llvm.org/D85691, but it seems that the use of atomics for Timer at all is controversial. -- 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 46940, which changed state. Bug 46940 Summary: Wrong code generated from instcombine https://bugs.llvm.org/show_bug.cgi?id=46940 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 46940] Wrong code generated from instcombine
https://bugs.llvm.org/show_bug.cgi?id=46940 Kazu Hirata changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #10 from Kazu Hirata --- I've landed https://reviews.llvm.org/D85687. -- 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 24828 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-guard_widening: Heap-use-after-free in llvm::Value::setNameImpl
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2020-08-11 Type: Bug-Security New issue 24828 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-guard_widening: Heap-use-after-free in llvm::Value::setNameImpl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24828 Detailed Report: https://oss-fuzz.com/testcase?key=5166633690333184 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-guard_widening Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-use-after-free READ 3 Crash Address: 0x6040d7f0 Crash State: llvm::Value::setNameImpl llvm::Value::setName llvm::UpgradeIntrinsicCall Sanitizer: address (ASAN) Recommended Security Severity: High Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202008100615:202008110602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5166633690333184 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 47124] New: mac/arm64 codegen puts jump tables in __TEXT, __const instead of __TEXT, __text, leading to ld64 warnings about direct access to global weak symbols
https://bugs.llvm.org/show_bug.cgi?id=47124
Bug ID: 47124
Summary: mac/arm64 codegen puts jump tables in __TEXT,__const
instead of __TEXT,__text, leading to ld64 warnings
about direct access to global weak symbols
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
thakis@Nicos-MacBook-Pro src % cat foo.cc
enum Status { kOk, kAborted, kConfigChanged, kError };
template
struct DecoderStream {
void OnBufferReady(Status status);
};
template
void DecoderStream::OnBufferReady(Status status) {
switch (status) {
case kOk:
case kConfigChanged:
break;
case kAborted:
case kError:
break;
}
}
template class DecoderStream<1>;
thakis@Nicos-MacBook-Pro src % ../bin/clang -c foo.cc -std=c++14
--target=arm64-apple-macosx
thakis@Nicos-MacBook-Pro src % ../bin/clang --target=arm64-apple-macosx -shared
-o libfoo.dylib foo.o -isysroot
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
ld: warning: direct access in function 'ltmp1' from file 'foo.o' to global weak
symbol 'DecoderStream<1>::OnBufferReady(Status)' from file 'foo.o' means the
weak symbol cannot be overridden at runtime. This was likely caused by
different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'ltmp1' from file 'foo.o' to global weak
symbol 'DecoderStream<1>::OnBufferReady(Status)' from file 'foo.o' means the
weak symbol cannot be overridden at runtime. This was likely caused by
different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'ltmp1' from file 'foo.o' to global weak
symbol 'DecoderStream<1>::OnBufferReady(Status)' from file 'foo.o' means the
weak symbol cannot be overridden at runtime. This was likely caused by
different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'ltmp1' from file 'foo.o' to global weak
symbol 'DecoderStream<1>::OnBufferReady(Status)' from file 'foo.o' means the
weak symbol cannot be overridden at runtime. This was likely caused by
different translation units being compiled with different visibility settings.
This works fine with clang in Xcode 12 beta (which buts the jump tables in
__TEXT,__text instead of __TEXT,__const), but open-source clang and the clang
at http://github.com/apple/llvm-project don't handle this right.
Encountered in a Chromium component build (https://crbug.com/1107955).
--
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 47125] New: year_month_day_last::day() has undefined behavior and should not
https://bugs.llvm.org/show_bug.cgi?id=47125
Bug ID: 47125
Summary: year_month_day_last::day() has undefined behavior and
should not
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: howard.hinn...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Convenience link: http://eel.is/c++draft/time.cal.ymdlast.members#15
Example program:
#include
int
main()
{
using namespace std::chrono;
auto constexpr ymdl = 2021y/13/last;
auto constexpr d = ymdl.day();
}
Expected result: To compile.
Actual result:
Jade-2:~/Development/cljunk> clang++ -std=c++2a test.cpp -O3
-I../libcxx/include -nostdinc++
test.cpp:8:20: error: constexpr variable 'd' must be initialized by a constant
expression
auto constexpr d = ymdl.day();
^ ~~
../libcxx/include/chrono:2457:9: note: read of dereferenced one-past-the-end
pointer is not allowed in a constant expression
__d[static_cast(month()) - 1] : chrono::day{29};
^
../libcxx/include/chrono:2457:9: note: in call to 'day(__d[12])'
test.cpp:8:29: note: in call to '&ymdl->day()'
auto constexpr d = ymdl.day();
^
1 error generated.
Cause of error: The year_month_day_last contains a month that is out of range
of the internal array that is indexed by month. This is not a user error.
This should compile and return an unspecified day.
I see two plausible directions for a fix:
1. Maximal performance: If !this->ok(), take the branch that does not index
and return day{29}.
2. Maximal debugability: If !this->ok() return a day such that !d.ok().
Maybe day{0} or day{32}.
The example implementation at https://github.com/HowardHinnant/date chose (1).
But I think either of these choices are reasonable. Field experience with the
example implementation has not provided a definitely preferred answer.
--
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 24829 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-08-12 Type: Bug New issue 24829 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24829 Detailed Report: https://oss-fuzz.com/testcase?key=4887921333895168 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcbfc56de8 Crash State: clang::DeclContext::lookup LookupDirect CppNamespaceLookup Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202008100615:202008110602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4887921333895168 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 24830 in oss-fuzz: llvm:clang-objc-fuzzer: ASSERT: Val && "isa<> used on a null pointer"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-08-12 Type: Bug New issue 24830 by ClusterFuzz-External: llvm:clang-objc-fuzzer: ASSERT: Val && "isa<> used on a null pointer" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24830 Detailed Report: https://oss-fuzz.com/testcase?key=5664329198993408 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Val && "isa<> used on a null pointer" clang::Parser::ParseClassSpecifier clang::Parser::ParseDeclarationSpecifiers Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006090257:202006100259 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5664329198993408 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 34896] Invalid vldmia/vsdmia encoding
https://bugs.llvm.org/show_bug.cgi?id=34896 Yichao Yu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Yichao Yu --- This was reported again as https://bugs.llvm.org/show_bug.cgi?id=34896 and is now fixed. *** This bug has been marked as a duplicate of bug 38389 *** -- 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
