[llvm-bugs] [Bug 52510] Load address range overlap reported when ALIGN is used with LMA and VMA regions
https://bugs.llvm.org/show_bug.cgi?id=52510 Konstantin Schwarz changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||8c18719bae6f0fe6ff97adad230 ||3c447083e14be Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52530] Compiler OOM on simple code that makes large dynamic allocation
https://bugs.llvm.org/show_bug.cgi?id=52530 Kadir Cetinkaya changed: What|Removed |Added CC||kadircetinkaya.06.tr@gmail. ||com Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Kadir Cetinkaya --- *** This bug has been marked as a duplicate of bug 51712 *** -- 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 51712] Clang runs OOM when checking for constant initialization of array
https://bugs.llvm.org/show_bug.cgi?id=51712 Kadir Cetinkaya changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Kadir Cetinkaya --- reopening as the fix was reverted due to test failures on some platforms. -- 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 52534] Out of range R_X86_64_REX_GOTPCRELX relocation for __preinit_array_start/end with linker script and high image base
https://bugs.llvm.org/show_bug.cgi?id=52534 Andrew Ng changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Andrew Ng --- Fixed in commit https://github.com/llvm/llvm-project/commit/47eb3f155f9e7b2670b8e0f8a85c64f31ea39fa4. -- 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 52556] New: llvm/include/llvm/IR/ModuleSummaryIndex.h:1166:73: warning: member ‘llvm::ModuleSummaryIndex::Alloc’ is used uninitialized [-Wuninitialized]
https://bugs.llvm.org/show_bug.cgi?id=52556 Bug ID: 52556 Summary: llvm/include/llvm/IR/ModuleSummaryIndex.h:1166:73: warning: member ‘llvm::ModuleSummaryIndex::Alloc’ is used uninitialized [-Wuninitialized] Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dcb...@hotmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org In file included from /home/dcb/llvm/trunk/clang/include/clang/CodeGen/BackendUtil.h:13, from /home/dcb/llvm/trunk/clang/lib/Interpreter/IncrementalParser.cpp:16: /home/dcb/llvm/trunk/llvm/include/llvm/IR/ModuleSummaryIndex.h: In constructor ‘llvm::ModuleSummaryIndex::ModuleSummaryIndex(bool, bool)’: /home/dcb/llvm/trunk/llvm/include/llvm/IR/ModuleSummaryIndex.h:1166:73: warning: member ‘llvm::ModuleSummaryIndex::Alloc’ is used uninitialized [-Wuninitialized] 1166 | : HaveGVs(HaveGVs), EnableSplitLTOUnit(EnableSplitLTOUnit), Saver(Alloc), | ^ In C++, you can't init subobjects with other subobjects later in the declaration list. -- 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 52557] New: Clang crashes when trying to compile a simple objc program with exception catching
https://bugs.llvm.org/show_bug.cgi?id=52557
Bug ID: 52557
Summary: Clang crashes when trying to compile a simple objc
program with exception catching
Product: clang
Version: 13.0
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lilinfeng...@outlook.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25462
--> https://bugs.llvm.org/attachment.cgi?id=25462&action=edit
files_generated_by_clang
This was done on Windows 10, 21H1 with clang from chocotelatey
C:\DEV>clang --version
clang version 13.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
Minimal test case, or check the attachment:
$ cat crash.m
int main()
{
@try {
} @catch (id e) {
} @finally { };
}
$ clang -cc1 -triple x86_64-pc-windows-msvc -emit-obj
-fobjc-runtime=gnustep-2.0 -fobjc-exceptions -x objective-c crash.m
Stack dump:
0. Program arguments: "C:\\Program Files\\LLVM\\bin\\clang-cl.exe" -I
C:\\GNUstep\\x64\\Debug\\include -fobjc-runtime=gnustep-2.0 -Xclang
-fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL
-DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN
-DGSDIAGNOSE /MDd /c test.m
1. parser at end of file
2. test.m:3:5: LLVM IR generation of declaration 'main'
3. test.m:3:5: Generating code for declaration 'main'
#0 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x20c6f9a
C:\Program Files\LLVM\bin\clang-cl.exe 0x20c52c9
#1 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x20c4f8b
C:\Program Files\LLVM\bin\clang-cl.exe 0x1f4c679
#2 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1f540d7
C:\Program Files\LLVM\bin\clang-cl.exe 0x1dc0cbf
#3 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1db9fd1
C:\Program Files\LLVM\bin\clang-cl.exe 0x1dbdd6b
#4 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1dc46ca
C:\Program Files\LLVM\bin\clang-cl.exe 0x3e18c3f
#5 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x3e16909
C:\Program Files\LLVM\bin\clang-cl.exe 0x2fa80f9
#6 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x238a9c2
C:\Program Files\LLVM\bin\clang-cl.exe 0x23521bd
#7 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x23f8c26
C:\Program Files\LLVM\bin\clang-cl.exe 0x75c3
#8 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x47ff C:\Program
Files\LLVM\bin\clang-cl.exe 0x22658c6
#9 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x1b3d39f
C:\Program Files\LLVM\bin\clang-cl.exe 0x22655b7
#10 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x21a9462
C:\Program Files\LLVM\bin\clang-cl.exe 0x21a9a09
#11 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x218bf26
C:\Program Files\LLVM\bin\clang-cl.exe 0x411d
#12 0x7ff7d11e6f9a C:\Program Files\LLVM\bin\clang-cl.exe 0x3e367b8
(C:\Program Files\LLVM\bin\clang-cl.exe+0x20c6f9a)
#13 0x7ff7d11e6f9a
#14 0x7ff7d11e6f9a (C:\Program Files\LLVM\bin\clang-cl.exe+0x20c6f9a)
0x7FF7D11E6F9A (0x0270E6A49808 0x0270E6C8E001 0xE037002A1F10
0x0270E6A497E0)
0x7FF7D11E52C9 (0x0270E0AAEE50 0x7FF7D291006D 0x00C8F0B89BD0
0x00C8F0B89BE0)
0x7FF7D11E4F8B (0x 0x7FF7D291D499 0x0270E6A4BD68
0x7FF7D062E1A0)
0x7FF7D106C679 (0x0001 0x002B 0x0270E6C732F0
0xE037002A1930)
0x7FF7D10740D7 (0x0001 0x 0x00C8F0B8A250
0x00C8F0B8A1C0)
0x7FF7D0EE0CBF (0x 0x 0x
0x)
0x7FF7D0ED9FD1 (0x0003 0x0270E23C7F30 0x0270E6C736F0
0x7FF7D2168455)
0x7FF7D0EDDD6B (0x00C8F0B8BCB8 0x0003 0x
0x0270E0A84F20)
0x7FF7D0EE46CA (0x0270E23C7F40 0x00C8F0B8D2A0 0x0270E23CBE90
0x7FF7D20CD082)
0x7FF7D2F38C3F (0x0270E23C7F30 0x 0x0270E23C82D0
0x)
0x7FF7D2F36909 (0x00C8F0B8D3C8 0x00C8F0B8D3B8 0x00C8F0B8D3B8
0x7FF7D147031A)
0x7FF7D20C80F9 (0x 0xE037002A48A0 0x2D646E756F72522D
0x3163632D70697274)
0x7FF7D14AA9C2 (0x00E8 0x0270E0A883D0 0x0001
0x0270E0A75D40)
0x7FF7D14721BD (0x 0x 0x00C8F0B8DDE8
0x0270E0A0)
0x7FF7D1518C26 (0x00C8F0B8D7C0 0x00C8F0B8D658 0x00C8F0B8D5A8
0x)
0x7FF7CF1275C3 (0x0006 0x003F 0x00C8F0005080
0x00C837001126)
0x7FF7CF1247FF (0x7FF7D0C5D640 0x 0x0270E0A74EA0
0x00C8F0B8DF88)
0x7FF7D13
[llvm-bugs] [Bug 52558] New: clang-format inserts spaces in include path
https://bugs.llvm.org/show_bug.cgi?id=52558 Bug ID: 52558 Summary: clang-format inserts spaces in include path Product: clang Version: 13.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: robin.gutoehrl...@trumpf.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org If a c++ file contains the following line: #include (which compiles with the current microsoft c++ compiler), clang-format changes this path to #include if called with clang-format test.cpp > test-formatted.cpp. It seems that clang "thinks" the double slash is a comment and inserts a space before it, but a comment should never start in a include path. -- 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 52559] New: Poor fixit suggestion for an uninitialized then dereferenced pointer
https://bugs.llvm.org/show_bug.cgi?id=52559
Bug ID: 52559
Summary: Poor fixit suggestion for an uninitialized then
dereferenced pointer
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: natechancel...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Initially reported at
https://lore.kernel.org/r/yzdhyevcgqh5m...@smile.fi.intel.com/.
Reproducer: https://godbolt.org/z/EcPP7o1T9
$ cat test.c
#define NULL ((void *)0)
struct foo {
int x;
};
void bar(void) {
struct foo *a;
a->x = 1;
}
$ gcc --version
gcc (GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -Wuninitialized -c -o /dev/null test.c
test.c: In function ‘bar’:
test.c:9:14: warning: ‘a’ is used uninitialized [-Wuninitialized]
9 | a->x = 1;
| ~^~~
$ clang --version
clang version 13.0.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/sbin
$ clang -fsyntax-only -Wuninitialized test.c
test.c:9:2: warning: variable 'a' is uninitialized when used here
[-Wuninitialized]
a->x = 1;
^
test.c:8:15: note: initialize the variable 'a' to silence this warning
struct foo *a;
^
= NULL
1 warning generated.
This seems like a poor suggestion, as it is going to just result in the user's
program crashing (it probably already will but the hint does nothing to improve
that). Perhaps it should be omitted if the pointer is dereferenced (or just
altogether, since it is likely that a pointer is going to be dereferenced at
some point in its lifetime)? Having the location of the variable is helpful in
the warning but I think emitting the '= NULL' part of it is not helpful.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 41086 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex
Updates: Status: WontFix Comment #1 on issue 41086 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Preprocessor::CachingLex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41086#c1 ClusterFuzz testcase 5067340662833152 is closed as invalid, so closing issue. -- 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 52560] New: ICE in backend for sapphirerapids: Cannot select: t60: v8i16 = X86ISD::VZEXT_MOVL t55
https://bugs.llvm.org/show_bug.cgi?id=52560
Bug ID: 52560
Summary: ICE in backend for sapphirerapids: Cannot select: t60:
v8i16 = X86ISD::VZEXT_MOVL t55
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: vsevolod.livins...@frtk.ru
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Link to the Compiler Explorer: https://godbolt.org/z/zz5bdq8c6
LLVM IR Reproducer:
define void @_Z1hv(i8 %0, <2 x i16> %1, i8* %c) local_unnamed_addr {
entry:
%conv = sext i8 %0 to i16
%2 = insertelement <2 x i16> zeroinitializer, i16 %conv, i32 0
%3 = icmp sgt <2 x i16> %2, zeroinitializer
%4 = select <2 x i1> %3, <2 x i16> %1, <2 x i16> zeroinitializer
%5 = extractelement <2 x i16> %4, i32 0
%tobool.not14 = icmp eq i16 %5, 0
br i1 %tobool.not14, label %for.end, label %for.body.preheader
for.body.preheader: ; preds = %entry
store i8 0, i8* %c, align 1
br label %for.end
for.end: ; preds =
%for.body.preheader, %entry
ret void
}
Error:
>$ clang++ -c -O1 -march=sapphirerapids reduced.ll
fatal error: error in backend: Cannot select: t60: v8i16 = X86ISD::VZEXT_MOVL
t55
t55: v8i16 = scalar_to_vector t31
t31: i16 = sign_extend_inreg t29, ValueType:ch:i8
t29: i16 = truncate t2
t2: i32,ch = CopyFromReg t0, Register:i32 %0
t1: i32 = Register %0
In function: _Z1hv
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: clang++ -c -O1 -march=sapphirerapids reduced.ll
1. Code generation
2. Running pass 'Function Pass Manager' on module 'reduced.ll'.
3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z1hv'
#0 0x556a5e65f115 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x556a5e65cd64 llvm::sys::CleanupOnSignal(unsigned long)
(/testing/llvm/bin_main/bin/clang-14+0x222bd64)
#2 0x556a5e5a9293 llvm::CrashRecoveryContext::HandleExit(int)
(/testing/llvm/bin_main/bin/clang-14+0x2178293)
#3 0x556a5e654a92 llvm::sys::Process::Exit(int, bool)
(/testing/llvm/bin_main/bin/clang-14+0x2223a92)
#4 0x556a5d0cc4c8 LLVMErrorHandler(void*, char const*, bool)
cc1_main.cpp:0:0
#5 0x556a5e5b17fa llvm::report_fatal_error(llvm::Twine const&, bool)
(/testing/llvm/bin_main/bin/clang-14+0x21807fa)
#6 0x556a5f6b8f41 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*)
(/testing/llvm/bin_main/bin/clang-14+0x3287f41)
#7 0x556a5f6ba5d2 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*,
unsigned char const*, unsigned int)
(/testing/llvm/bin_main/bin/clang-14+0x32895d2)
#8 0x556a5d1c1d57 (anonymous
namespace)::X86DAGToDAGISel::Select(llvm::SDNode*) X86ISelDAGToDAG.cpp:0:0
#9 0x556a5f6b6e3a llvm::SelectionDAGISel::DoInstructionSelection()
(/testing/llvm/bin_main/bin/clang-14+0x3285e3a)
#10 0x556a5f6c1699 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/testing/llvm/bin_main/bin/clang-14+0x3290699)
#11 0x556a5f6c50ef
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/testing/llvm/bin_main/bin/clang-14+0x32940ef)
#12 0x556a5f6c6fb1
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0)
SelectionDAGISel.cpp:0:0
#13 0x556a5d1cc910 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
X86ISelDAGToDAG.cpp:0:0
#14 0x556a5d86c758
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/testing/llvm/bin_main/bin/clang-14+0x143b758)
#15 0x556a5dde9593 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/testing/llvm/bin_main/bin/clang-14+0x19b8593)
#16 0x556a5dde97c9 llvm::FPPassManager::runOnModule(llvm::Module&)
(/testing/llvm/bin_main/bin/clang-14+0x19b87c9)
#17 0x556a5ddea0e5 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/testing/llvm/bin_main/bin/clang-14+0x19b90e5)
#18 0x556a5e9a08b3 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef,
llvm::Module*, clang::BackendAction, std::unique_ptr >)
(/testing/llvm/bin_main/bin/clang-14+0x256f8b3)
#19 0x556a5f805c38 clang::CodeGenAction::ExecuteAction()
(/testing/llvm/bin_main/bin/clang-14+0x33d4c38)
#20 0x556a5f0ac389 clang::FrontendAction::Execute()
(/testing/llvm/bin_main/bin/clang-14+0x2c7b389)
#21 0x556a5f0394de
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/testing/llvm/bin_main/bin/clang-14+0x2c084de)
#22 0x556a5f1
[llvm-bugs] [Bug 52024] Instruction does not dominate all uses! Crash with -O2 in llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10474: bool llvm::LoopVectorizePass::processLoop(llvm::Loop*): Asserti
https://bugs.llvm.org/show_bug.cgi?id=52024
Vsevolod Livinskiy changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #3 from Vsevolod Livinskiy ---
Unfortunately, the error still exists in the trunk.
Link to the Compiler Explorer: https://godbolt.org/z/zbfTKEET8
LLVM IR Reproducer:
define void @_Z1fv(i32* %0, i64 %1, i32* %a, i8* %b) local_unnamed_addr {
entry:
br label %for.cond1.preheader.us
for.cond1.preheader.us: ; preds =
%for.cond1.for.cond.cleanup3_crit_edge.us, %entry
%indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next,
%for.cond1.for.cond.cleanup3_crit_edge.us ]
%2 = icmp eq i64 %indvars.iv, 0
%arrayidx7.us = getelementptr inbounds i32, i32* %0, i64 %indvars.iv
br i1 %2, label %for.cond1.for.cond.cleanup3_crit_edge.us, label
%for.body4.lr.ph.split.us21
for.body4.lr.ph.split.us21: ; preds =
%for.cond1.preheader.us
%3 = load i32, i32* %arrayidx7.us, align 4
br label %for.cond1.for.cond.cleanup3_crit_edge.us
for.cond1.for.cond.cleanup3_crit_edge.us: ; preds =
%for.body4.lr.ph.split.us21, %for.cond1.preheader.us
%storemerge = phi i32 [ %3, %for.body4.lr.ph.split.us21 ], [ 0,
%for.cond1.preheader.us ]
store i32 %storemerge, i32* %a, align 4
%indvars.iv.next = add nsw i64 %indvars.iv, %1
%cmp.us = icmp slt i64 %indvars.iv.next, 0
br i1 %cmp.us, label %for.cond1.preheader.us, label
%for.cond.cleanup.split.us.split, !llvm.loop !0
for.cond.cleanup.split.us.split: ; preds =
%for.cond1.for.cond.cleanup3_crit_edge.us
%arrayidx7.us.lcssa = phi i32* [ %arrayidx7.us,
%for.cond1.for.cond.cleanup3_crit_edge.us ]
%.us-phi.us.in.in = load i32, i32* %arrayidx7.us.lcssa, align 4
%.us-phi.us.in = icmp ne i32 %.us-phi.us.in.in, 0
%.us-phi.us = zext i1 %.us-phi.us.in to i8
store i8 %.us-phi.us, i8* %b, align 1
ret void
}
!0 = distinct !{!0, !1, !2}
!1 = !{!"llvm.loop.mustprogress"}
!2 = !{!"llvm.loop.vectorize.enable", i1 true}
Error:
>$ clang++ -c -O1 reduced.ll
Instruction does not dominate all uses!
%42 = getelementptr inbounds i32, i32* %0, i64 %41
%arrayidx7.us.lcssa = phi i32* [ %arrayidx7.us,
%for.cond1.for.cond.cleanup3_crit_edge.us ], [ %42, %middle.block ]
clang++:
/testing/llvm/llvm_src_main/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10570:
bool llvm::LoopVectorizePass::processLoop(llvm::Loop*): Assertion
`!verifyFunction(*L->getHeader()->getParent(), &dbgs())' failed.
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: clang++ -c -O1 reduced.ll
1. Optimizer
#0 0x55951e0cc115 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x55951e0c9d64 llvm::sys::CleanupOnSignal(unsigned long)
(/testing/llvm/bin_main/bin/clang-14+0x222bd64)
#2 0x55951e015fc8 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7f24091d7520 (/lib/x86_64-linux-gnu/libc.so.6+0x46520)
#4 0x7f240922b808 pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x9a808)
#5 0x7f24091d7476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x46476)
#6 0x7f24091bd7b7 abort (/lib/x86_64-linux-gnu/libc.so.6+0x2c7b7)
#7 0x7f24091bd6db (/lib/x86_64-linux-gnu/libc.so.6+0x2c6db)
#8 0x7f24091cee26 (/lib/x86_64-linux-gnu/libc.so.6+0x3de26)
#9 0x55951e3008d9 llvm::LoopVectorizePass::processLoop(llvm::Loop*)
(/testing/llvm/bin_main/bin/clang-14+0x24628d9)
#10 0x55951e300aee llvm::LoopVectorizePass::runImpl(llvm::Function&,
llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&,
llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*,
llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&,
std::function&,
llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*)
(/testing/llvm/bin_main/bin/clang-14+0x2462aee)
#11 0x55951e301332 llvm::LoopVectorizePass::run(llvm::Function&,
llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x2463332)
#12 0x55951f665046 llvm::detail::PassModel >::run(llvm::Function&,
llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x37c7046)
#13 0x55951d89e9a0 llvm::PassManager >::run(llvm::Function&,
llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x1a009a0)
#14 0x55951e3f78c6 llvm::detail::PassModel >,
llvm::PreservedAnalyses, llvm::AnalysisManager
>::run(llvm::Function&, llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x25598c6)
#15 0x55951d89d436 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&,
llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x19ff436)
#16 0x55951e3f86a6 llvm::detail::PassModel >::run(llvm::Module&,
llvm::AnalysisManager&)
(/testing/llvm/bin_main/bin/clang-14+0x255a6a6)
#17 0x55
[llvm-bugs] [Bug 52388] lld/mac should ignore invalid LC_LINKER_OPTIONS on successful links
https://bugs.llvm.org/show_bug.cgi?id=52388 Keith Smiley changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Keith Smiley --- We talked about this a bit at the roundtable and I think generally we don't think behavior like this needs to match in less folks have a good reason to want it, so I'm going to close this -- 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 52561] New: Assertion failed for sapphirerapids: `VT.getSizeInBits() == Operand.getValueSizeInBits() && "Cannot BITCAST between types of different sizes!"'.
https://bugs.llvm.org/show_bug.cgi?id=52561
Bug ID: 52561
Summary: Assertion failed for sapphirerapids:
`VT.getSizeInBits() == Operand.getValueSizeInBits() &&
"Cannot BITCAST between types of different sizes!"'.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: vsevolod.livins...@frtk.ru
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Link to the Compiler Explorer: https://godbolt.org/z/qEK4jWTcT
LLVM IR Reproducer:
@b = external local_unnamed_addr global i8, align 1
@d = external local_unnamed_addr global i32, align 4
@c = external local_unnamed_addr global [0 x [8 x i16]], align 2
define void @_Z1ev(i32 %0, i1 %1) local_unnamed_addr #0 {
entry:
%conv2 = and i32 %0, 65535
%sub = sub nsw i32 2, %conv2
br label %omp.inner.for.cond
omp.inner.for.cond: ; preds = %cond.end, %entry
%.omp.iv.0 = phi i32 [ %add19, %cond.end ], [ 0, %entry ]
%cmp8 = icmp slt i32 %.omp.iv.0, %sub
br i1 %cmp8, label %omp.inner.for.body, label %simd.if.end.loopexit
omp.inner.for.body: ; preds = %omp.inner.for.cond
%add10 = add i32 %.omp.iv.0, %0
%2 = and i32 %add10, 65535
%idxprom = zext i32 %2 to i64
br i1 %1, label %cond.end, label %cond.true
cond.true:; preds = %omp.inner.for.body
%arrayidx13 = getelementptr inbounds [0 x [8 x i16]], [0 x [8 x i16]]* @c,
i64 0, i64 1, i64 %idxprom
%3 = load i16, i16* %arrayidx13, align 2
%conv14 = trunc i16 %3 to i8
br label %cond.end
cond.end: ; preds = %cond.true,
%omp.inner.for.body
%cond = phi i8 [ %conv14, %cond.true ], [ 0, %omp.inner.for.body ]
store i8 %cond, i8* @b, align 1
%arrayidx17 = getelementptr inbounds [0 x [8 x i16]], [0 x [8 x i16]]* @c,
i64 0, i64 3, i64 %idxprom
%4 = load i16, i16* %arrayidx17, align 2
%conv18 = sext i16 %4 to i32
store i32 %conv18, i32* @d, align 4
%add19 = add nuw nsw i32 %.omp.iv.0, 1
br label %omp.inner.for.cond, !llvm.loop !0
simd.if.end.loopexit: ; preds = %omp.inner.for.cond
ret void
}
attributes #0 = { "min-legal-vector-width"="0" }
!0 = distinct !{!0, !1, !3}
!1 = !{!"llvm.loop.parallel_accesses", !2}
!2 = distinct !{}
!3 = !{!"llvm.loop.vectorize.enable", i1 true}
Error:
>$ clang++ -c -O2 -march=sapphirerapids reduced.ll
clang++:
/testing/llvm/llvm_src_main/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5074:
llvm::SDValue llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc&,
llvm::EVT, llvm::SDValue, llvm::SDNodeFlags): Assertion `VT.getSizeInBits() ==
Operand.getValueSizeInBits() && "Cannot BITCAST between types of different
sizes!"' failed.
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: clang++ -c -O2 -march=sapphirerapids reduced.ll
1. Code generation
2. Running pass 'Function Pass Manager' on module 'reduced.ll'.
3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z1ev'
#0 0x556a6053f115 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x556a6053cd64 llvm::sys::CleanupOnSignal(unsigned long)
(/testing/llvm/bin_main/bin/clang-14+0x222bd64)
#2 0x556a60488fc8 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7fbb84023520 (/lib/x86_64-linux-gnu/libc.so.6+0x46520)
#4 0x7fbb84077808 pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x9a808)
#5 0x7fbb84023476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x46476)
#6 0x7fbb840097b7 abort (/lib/x86_64-linux-gnu/libc.so.6+0x2c7b7)
#7 0x7fbb840096db (/lib/x86_64-linux-gnu/libc.so.6+0x2c6db)
#8 0x7fbb8401ae26 (/lib/x86_64-linux-gnu/libc.so.6+0x3de26)
#9 0x556a6156c22b llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc
const&, llvm::EVT, llvm::SDValue, llvm::SDNodeFlags)
(/testing/llvm/bin_main/bin/clang-14+0x325b22b)
#10 0x556a6156d341 llvm::SelectionDAG::getBitcast(llvm::EVT, llvm::SDValue)
(/testing/llvm/bin_main/bin/clang-14+0x325c341)
#11 0x556a5f185cb0 combineX86ShuffleChain(llvm::ArrayRef,
llvm::SDValue, llvm::ArrayRef, int, bool, bool, bool, llvm::SelectionDAG&,
llvm::X86Subtarget const&) X86ISelLowering.cpp:0:0
#12 0x556a5f1e28d9
combineX86ShufflesRecursively(llvm::ArrayRef, int,
llvm::SDValue, llvm::ArrayRef, llvm::ArrayRef,
unsigned int, unsigned int, bool, bool, bool, llvm::SelectionDAG&,
llvm::X86Subtarget const&) X86ISelLowering.cpp:0:0
#13 0x556a5f1e1a86
combineX86ShufflesRecursively(llvm::ArrayRef, int,
[llvm-bugs] [Bug 48678] Crash with inline asm using wrong register name
https://bugs.llvm.org/show_bug.cgi?id=48678 Fabian Wolff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Fabian Wolff --- Fixed in https://reviews.llvm.org/rGb484fa8289299a4a55708d8e4104aacfea8d7fd5. -- 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 52151] std::search violates random access iterator concept by not using the iterator's difference_type
https://bugs.llvm.org/show_bug.cgi?id=52151 Fabian Wolff changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Fabian Wolff --- Fixed in https://reviews.llvm.org/rGdc1c27149f214ff099e99930226ae312b0cf1910. -- 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 52062] Failure to optimize out strncpy immediately followed by memset
https://bugs.llvm.org/show_bug.cgi?id=52062 Fabian Wolff changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||fabian.wo...@alumni.ethz.ch --- Comment #2 from Fabian Wolff --- Fixed in https://reviews.llvm.org/rG7eec832def5717b1bddb72c3b99c3df4f7a2f6da. -- 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 52562] New: Merge 029f1a53448979365ab965572356b83edc82f755 into 13.0.1
https://bugs.llvm.org/show_bug.cgi?id=52562 Bug ID: 52562 Summary: Merge 029f1a53448979365ab965572356b83edc82f755 into 13.0.1 Product: libraries Version: 13.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: b...@comstyle.com CC: dimi...@andric.com, llvm-bugs@lists.llvm.org Blocks: 52147 Please merge https://github.com/llvm/llvm-project/commit/029f1a53448979365ab965572356b83edc82f755. [PATCH] [LazyCallGraph] Skip blockaddresses blockaddresses do not participate in the call graph since the only instructions that use them must all return to someplace within the current function. And passes cannot retrieve a function address from a blockaddress. Fixes PR50881. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=52147 [Bug 52147] [meta] 13.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 52563] New: Clang mishandles fast-math flags when pragmas are used
https://bugs.llvm.org/show_bug.cgi?id=52563
Bug ID: 52563
Summary: Clang mishandles fast-math flags when pragmas are used
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.kay...@intel.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
When pragmas are used that modify the fast-math flags, clang doesn't correctly
apply the changes to all instructions. I've seen this with phi and fneg
instructions. There may be others.
Here are some examples (compiled with -funsafe-math-optimizations, which
applies 'reassoc nsz arcp' outside pragma scopes):
```
#pragma clang fp reassociate(off)
double foo(bool flag, double x, double y) {
return flag ? x : y;
}
```
clang generates a phi instruction with the 'reassoc' flag set.
```
#pragma clang fp reassociate(off)
double bar(double x) {
return foo(x < 0, -x, x);
}
```
Here clang correctly omits the 'reassoc' flag from the fcmp but incorrectly
sets it for the fneg.
```
#pragma clang fp reassociate(off)
void fubar(double x, double *pneg, double *psub) {
*pneg = -x;
*psub = 0.0-x;
}
```
Here clang correctly omits the 'reassoc' flag from the fsub but incorrectly
sets it for the fneg.
The same problem occurs with "pragma float_control"
--
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 52564] New: Runtime crash with ` DYLD, [0x4] Symbol missing`
https://bugs.llvm.org/show_bug.cgi?id=52564 Bug ID: 52564 Summary: Runtime crash with ` DYLD, [0x4] Symbol missing` Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: v...@google.com CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com Part of crash log: `` Exception Type:EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Reason:DYLD, [0x4] Symbol missing ``` (Platform macOS 11.6) I'm working on making a small repro - but wondering if anyone has seen this ... any idea on how to narrowing this down? -- 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 33510] Clang ignores NANs with -ffast-math and -fhonor-nans (or -fno-finite-math-only)
https://bugs.llvm.org/show_bug.cgi?id=33510
Andy Kaylor changed:
What|Removed |Added
Resolution|--- |FIXED
CC||andrew.kay...@intel.com
Status|NEW |RESOLVED
--- Comment #8 from Andy Kaylor ---
I came across this while looking for something else. All the issues here seem
to be fixed.
clang -O2 -ffast-math -fhonor-nans
define dso_local i32 @testfunc(float %0) local_unnamed_addr #0 {
%2 = fcmp reassoc ninf nsz arcp contract afn ord float %0, 0.00e+00
%3 = zext i1 %2 to i32
ret i32 %3
}
attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone
uwtable willreturn "approx-func-fp-math"="true"
"denormal-fp-math"="preserve-sign,preserve-sign"
"denormal-fp-math-f32"="ieee,ieee" "frame-pointer"="none"
"min-legal-vector-width"="0" "no-infs-fp-math"="true"
"no-signed-zeros-fp-math"="true" "no-trapping-math"="true"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic"
"unsafe-fp-math"="true" }
Similarly correct for other combinations of flags.
--
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 52565] New: -fno-approx-funcs doesn't override -Ofast or -ffast-math
https://bugs.llvm.org/show_bug.cgi?id=52565
Bug ID: 52565
Summary: -fno-approx-funcs doesn't override -Ofast or
-ffast-math
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.kay...@intel.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
If I compile the following code with 'clang -O2 -ffast-math -fno-approx-funcs'
the IR generated sets the 'fast' flag (implying 'afn' on the call and issues no
diagnostic indicating that the -fno-approx-funcs option was ignored.
```
#include
float f(float x) {
return logf(x);
}
```
```
define dso_local float @f(float %0) local_unnamed_addr #0 {
%2 = tail call fast float @llvm.log.f32(float %0)
ret float %2
}
attributes #0 = { mustprogress nofree nosync nounwind readnone uwtable
willreturn "approx-func-fp-math"="true"
"denormal-fp-math"="preserve-sign,preserve-sign"
"denormal-fp-math-f32"="ieee,ieee" "frame-pointer"="none"
"min-legal-vector-width"="0" "no-infs-fp-math"="true" "no-nans-fp-math"="true"
"no-signed-zeros-fp-math"="true" "no-trapping-math"="true"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic"
"unsafe-fp-math"="true" }
```
D106191 needed many more changes to clang/lib/Driver/ToolChains/Clang.cpp to
get this option to interact correctly with the other floating point options.
--
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 52566] New: -fapprox-funcs doesn't work correctly with #pragma float_control(precise, on)
https://bugs.llvm.org/show_bug.cgi?id=52566
Bug ID: 52566
Summary: -fapprox-funcs doesn't work correctly with #pragma
float_control(precise, on)
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.kay...@intel.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
If I compile the following code with 'clang -O2 -fapprox-funcs' the
"approx-func-fp-math" attribute will be incorrectly set to 'true' and the 'afn'
flag will be set on the call to logf. The float_control pragma should disable
this.
```
#include
#pragma float_control(precise, on)
float f(float x) {
return logf(x);
}
```
```
define dso_local float @f(float %0) local_unnamed_addr #0 {
%2 = tail call afn float @logf(float %0) #2
ret float %2
}
attributes #0 = { mustprogress nofree nounwind uwtable willreturn
"approx-func-fp-math"="true" "frame-pointer"="none"
"min-legal-vector-width"="0" "no-trapping-math"="true"
"stack-protector-buffer-size"="8" "target-cpu"="x86-64"
"target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
```
--
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 52567] New: The _mm_movemask_epi8 intrinsic will sometimes call pmovmskb and will other times call movmskps
https://bugs.llvm.org/show_bug.cgi?id=52567
Bug ID: 52567
Summary: The _mm_movemask_epi8 intrinsic will sometimes call
pmovmskb and will other times call movmskps
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: chrisbu...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
I've found that calling _mm_movemask_epi8 changes its behavior depending on the
way that it is used in surrounding expressions.
This is reproducible with this code:
1 #include
2 int main()
3 {
4 const int mask = 0x00FF;
5 const auto recip = _mm_rcp_ps(_mm_set_ps(0.0f, 0.0f, 4.0f, 2.0f));
6 const auto diff = _mm_sub_ps(_mm_set_ps(0.0f, 0.0f, 0.25f, 0.5f),
recip);
7 const auto abs = _mm_and_ps(diff, _mm_set1_epi32(0x7FFF));
8 const auto compare = _mm_castps_si128(_mm_cmpgt_ps(abs,
_mm_set1_ps(0.001f)));
9 return (_mm_movemask_epi8(compare) & mask) == 0;
10 }
In plain English, this code:
1. Gets the reciprocal of the vector (0.0f, 0.0f, 4.0f, 2.0f)
2. Subtracts (0.0f, 0.0f, 0.25f, 0.5f) from the result of 1
3. Takes the absolute value of the result of 2
4. Returns 0 if the last 2 values of the result of 3 are greater than 0.001f, 1
otherwise
Intel's Intrinsics guide states that the _mm_movemask_epi8 intrinsic function
corresponds to the "pmovmskb r32, xmm" instruction. Thus, it should return
0xff00. However, because the value of mask (declared on line 4) is known at
compile time, the call to _mm_movemask_epi8 on line 9 generates a movmskps
instruction, which returns a different value. Instead of 16 1 bits per true
value 0xff00, we only get 1 true bit per value, 0b1100.
Assembly that is generated for this code is:
rcpps xmm0, xmmword ptr [rip + .LCPI0_0]
movaps xmm1, xmmword ptr [rip + .LCPI0_1] # xmm1 =
[5.0E-1,2.5E-1,0.0E+0,0.0E+0]
subps xmm1, xmm0
andps xmm1, xmmword ptr [rip + .LCPI0_2]
movaps xmm0, xmmword ptr [rip + .LCPI0_3] # xmm0 =
[1.0005E-3,1.0005E-3,1.0005E-3,1.0005E-3]
cmpltps xmm0, xmm1
movmskpsecx, xmm0 # <--- this is the instruction from
_mm_movemask_epi8
xor eax, eax
testecx, ecx
seteal
ret
If we do anything to the mask to force the compiler's hand, it will call
pmovmskb instead. The simplest thing to do is to mark the mask variable as
volatile, but moving it to a separate TU also works.
rcpps xmm0, xmmword ptr [rip + .LCPI0_0]
movaps xmm1, xmmword ptr [rip + .LCPI0_1] # xmm1 =
[5.0E-1,2.5E-1,0.0E+0,0.0E+0]
subps xmm1, xmm0
andps xmm1, xmmword ptr [rip + .LCPI0_2]
mov dword ptr [rsp - 4], 255
movaps xmm0, xmmword ptr [rip + .LCPI0_3] # xmm0 =
[1.0005E-3,1.0005E-3,1.0005E-3,1.0005E-3]
cmpltps xmm0, xmm1
pmovmskbecx, xmm0 # <--- this is the instruction from
_mm_movemask_epi8
xor eax, eax
and ecx, dword ptr [rsp - 4]
seteal
ret
The result is that the return value of _mm_movemask_epi8 is unpredictable.
The code can be seen here: https://godbolt.org/z/3Yc734rnj
The top code is the current behavior, the bottom code only differs in that mask
is volatile.
I used git bisect and found that this behavior changed in git commit
0741b75ad543d108759c0658fedb5fdfcf064487.
--
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 41189 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::SemaDiagnosticBuilder::SemaDiagnosticBuilder
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-11-20 Type: Bug New issue 41189 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::SemaDiagnosticBuilder::SemaDiagnosticBuilder https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41189 Detailed Report: https://oss-fuzz.com/testcase?key=5410501429952512 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe3023bff0 Crash State: clang::Sema::SemaDiagnosticBuilder::SemaDiagnosticBuilder clang::Sema::Diag GetFullTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202108030618:202108040600 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5410501429952512 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 41191 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::BuildCXXNestedNameSpecifier
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-11-20 Type: Bug New issue 41191 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::BuildCXXNestedNameSpecifier https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41191 Detailed Report: https://oss-fuzz.com/testcase?key=5741075734593536 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc761d2a80 Crash State: clang::Sema::BuildCXXNestedNameSpecifier clang::Sema::IsInvalidUnlessNestedName clang::Parser::ParseOptionalCXXScopeSpecifier Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202108020602:202108030618 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5741075734593536 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 40210 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::MergeFunctionDecl
Updates: Status: WontFix Comment #1 on issue 40210 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::MergeFunctionDecl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40210#c1 ClusterFuzz testcase 5948528250191872 is closed as invalid, so closing issue. -- 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 52567] The _mm_movemask_epi8 intrinsic will sometimes call pmovmskb and will other times call movmskps
https://bugs.llvm.org/show_bug.cgi?id=52567 Craig Topper changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||a4373f6753fa9aa89d39fbd4ec9 ||e273f76459a58 --- Comment #3 from Craig Topper --- I disabled this transform for this case in a4373f6753fa9aa89d39fbd4ec9e273f76459a58 -- 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
