[llvm-bugs] [Bug 46901] New: Buildbot - error during "clean stage" on Windows
https://bugs.llvm.org/show_bug.cgi?id=46901 Bug ID: 46901 Summary: Buildbot - error during "clean stage" on Windows Product: new-bugs Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kuh...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Dear Commmunity, I repeatedly see errors during the "clean step" on my new buildbot worker on Windows: http://lab.llvm.org:8014/builders/clang-x86-ninja-win10/builds/680 Does anyone have an idea what is causing this? I guess this is Windows related. The error message says: --- rm: reading directory `stage1/test/tools/dsymutil/X86/Output/reproducer.test.tmp.repro/volumes/buildbot/windows10-vs2019/clang-x86-ninja-win10/stage1/test/tools/dsymutil/X86/Output/reproducer.test.tmp/Inputs': No such file or directory rm: cannot remove directory `stage1/test/tools/dsymutil/X86/Output/reproducer.test.tmp.repro/volumes/buildbot/windows10-vs2019/clang-x86-ninja-win10/stage1/test/tools/dsymutil/X86/Output/reproducer.test.tmp': Directory not empty rm: reading directory `stage1/tools/clang/test/Modules/Output/dependency-dump-dependent-module.m.tmp/vfs/volumes/buildbot/windows10-vs2019/clang-x86-ninja-win10/llvm/clang/test/Modules/Inputs/AlsoDependsOnModule.framework': No such file or directory rm: cannot chdir from `stage1/tools/clang/test/Modules/Output/dependency-dump-dependent-module.m.tmp/vfs/volumes/buildbot/windows10-vs2019/clang-x86-ninja-win10/llvm/clang/test/Modules/Inputs' to ..: No such file or directory --- -- 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 46902] New: Accessing element of struct prevents vectorization
https://bugs.llvm.org/show_bug.cgi?id=46902
Bug ID: 46902
Summary: Accessing element of struct prevents vectorization
Product: tools
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: joel.hut...@arm.com
CC: llvm-bugs@lists.llvm.org
The following snippet:
include $
struct foo;$
typedef struct foo {$
int x;$
} foo;$
$
void bar(unsigned char dst, unsigned char src,$
foo *f, int i_max) {$
for (int i = 0; i < i_max; i++)$
dst[i] = (src[i] + f->x);$
}$
cannot be vectorized by LLVM trunk. However, if f->x is replaced by an integer
passed as a parameter, it can be vectorized. This can be vectorized by GCC
trunk.
Tested on aarch64-linux
--
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 46903] New: Go binding leaks CreateGlobalVariable() function.
https://bugs.llvm.org/show_bug.cgi?id=46903
Bug ID: 46903
Summary: Go binding leaks CreateGlobalVariable() function.
Product: libraries
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: m...@wud.me
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Go binding leaks CreateGlobalVariable().
And I have tried to write this manually, but I am wondering why don't go
binding implement this API?:
package llvm
/*
#include "IRBindings.h"
#include
*/
import "C"
import (
"unsafe"
)
type DIGlobalVariable struct {
Namestring
Linkage string
FileMetadata
Lineint
TypeMetadata
LocalToUnit bool
ExprMetadata
DeclMetadata
AlignInBits uint32
}
func (d *DIBuilder) CreateGlobalVariable(scope Metadata, v DIGlobalVariable)
Metadata {
name := C.CString(v.Name)
linkage := C.CString(v.Linkage)
defer C.free(unsafe.Pointer(name))
result := C.LLVMDIBuilderCreateGlobalVariableExpression(
d.ref,
scope.C,
name, C.size_t(len(v.Name)),
linkage, C.size_t(len(v.Linkage)),
v.File.C,
C.unsigned(v.Line),
v.Type.C,
C.LLVMBool(boolToCInt(v.LocalToUnit)),
v.Expr.C,
v.Decl.C,
C.uint32_t(v.AlignInBits))
return Metadata{C: result}
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46904] New: Cherry pick ed7bde0e4b40 into 11.0 branch (LLD test fix)
https://bugs.llvm.org/show_bug.cgi?id=46904 Bug ID: 46904 Summary: Cherry pick ed7bde0e4b40 into 11.0 branch (LLD test fix) Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: russell_gal...@sn.scee.net CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com As described here: https://reviews.llvm.org/D84885 the test lld/ELF/ppc64-reloc-pcrel34-overflow.s is causing intermittent problems for other tests in our infrastructure, including on release/11.x. This has been addressed in commit ed7bde0e4b40cbf8a7c833fd8240c957fcda176e Author: Fangrui Song Date: Wed Jul 29 13:01:31 2020 -0700 [ELF][test] Fix ppc64-reloc-pcrel34-overflow.s Please could this be cherry-picked to 11.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 46905] New: findNearbyTokens traverses whole file in redundant cases
https://bugs.llvm.org/show_bug.cgi?id=46905 Bug ID: 46905 Summary: findNearbyTokens traverses whole file in redundant cases Product: clang-tools-extra Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: clangd Assignee: unassignedclangb...@nondot.org Reporter: kadircetinkaya.06...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 46725 Binary search predicate was wrong, resulting in an incorrect search but rest of the logic was compensating for the failure by doing an exhaustive linear search (with a sub-optimal outcome). https://reviews.llvm.org/D84912 fixes the issue. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46725 [Bug 46725] [meta] 11.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46906] New: cmake config failure with Ninja
https://bugs.llvm.org/show_bug.cgi?id=46906 Bug ID: 46906 Summary: cmake config failure with Ninja Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: u...@polymagelabs.com CC: llvm-bugs@lists.llvm.org With the configuration below, I get: ... -- Performing Test HAVE_STEADY_CLOCK -- success -- Configuring done -- Generating done CMake Error: Running '/usr/local/bin/ninja' '-C' '/home/uday/llvm-project/build' '-t' 'cleandead' failed with: ninja: error: remove(include/llvm/Support): Directory not empty == cmake -G Ninja ../llvm -DLLVM_ENABLE_PROJECTS="mlir" -DLLVM_TARGETS_TO_BUILD="X86"-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_ENABLE_LLD=ON -DLLVM_CCACHE_BUILD=ON -DBUILD_SHARED_LIBS=ON cmake version 3.17.3 ninja --version 1.10.0 Trunk: a4a0844248d4a68a866b9c4e18ae89fa49a83ec0 (from a few hours 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 46907] New: [AMDGPU][MC] Assembler produces multiple error messages for a single error
https://bugs.llvm.org/show_bug.cgi?id=46907 Bug ID: 46907 Summary: [AMDGPU][MC] Assembler produces multiple error messages for a single error Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org There are many cases when assembler produces 2 or even 3 error messages when an error occurs. For example, the code shown below s_waitcnt vmcnt(0) & expcnt(0) x(0) result in the following plethora of messages: _test.s:1:32: error: invalid counter name x s_waitcnt vmcnt(0) & expcnt(0) x(0) ^ _test.s:1:35: error: unknown token in expression s_waitcnt vmcnt(0) & expcnt(0) x(0) ^ _test.s:1:35: error: failed parsing operand. s_waitcnt vmcnt(0) & expcnt(0) x(0) ^ The first message is the most specific while second and third messages are rather generic and do not help in understanding of error reason. Moreover, having several error messages per instruction may lead to subtle issues in lit tests where errors generated for one instruction interfere with testing of subsequent instructions and may result in some failures being hidden. In summary, cases with multiple error messages should be analyzed and corrected to produce just one most specific message. -- 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 46908] New: Access type node must be a valid scalar type (std::destroying_delete_t)
https://bugs.llvm.org/show_bug.cgi?id=46908
Bug ID: 46908
Summary: Access type node must be a valid scalar type
(std::destroying_delete_t)
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: mikhail.strelni...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 23791
--> https://bugs.llvm.org/attachment.cgi?id=23791&action=edit
s-eb6fec.sh
Z:\b>type s.cpp
namespace std {
struct destroying_delete_t { explicit destroying_delete_t() = default; };
}
class t {
public:
void operator delete(t *, std::destroying_delete_t) {}
};
int main() {
delete new t;
}
Z:\b>"C:\Program Files\LLVM\bin\clang++.exe" -std=c++2a -O1 -g s.cpp
Access type node must be a valid scalar type
store %"struct.std::destroying_delete_t" undef,
%"struct.std::destroying_delete_t"* %coerce, align 1, !dbg !12, !tbaa !26
!26 = !{!27, !27, i64 0}
!27 = !{!"?AUdestroying_delete_t@std@@"}
in function main
fatal error: error in backend: Broken function found, compilation aborted!
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: C:\Program Files\LLVM\bin\clang++.exe -cc1 -triple
x86_64-pc-windows-msvc19.27.29109 -emit-obj -mincremental-linker-compatible
-disable-free -main-file-name s.cpp -mrelocation-model pic -pic-level 2
-mframe-pointer=none -fmath-errno -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -gno-column-info -gcodeview
-debug-info-kind=limited -resource-dir C:\Program Files\LLVM\lib\clang\12.0.0
-internal-isystem C:\Program Files\LLVM\lib\clang\12.0.0\include
-internal-isystem C:\Program Files (x86)\Microsoft Visual
Studio\2019\Preview\VC\Tools\MSVC\14.27.29109\include -internal-isystem
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Preview\VC\Tools\MSVC\14.27.29109\atlmfc\include -internal-isystem
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt
-internal-isystem C:\Program Files (x86)\Windows
Kits\10\include\10.0.19041.0\shared -internal-isystem C:\Program Files
(x86)\Windows Kits\10\include\10.0.19041.0\um -internal-isystem C:\Program
Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt -O1 -std=c++2a
-fdeprecated-macro -fdebug-compilation-dir Z:\b -ferror-limit 19
-fno-use-cxa-atexit -fms-extensions -fms-compatibility
-fms-compatibility-version=19.27.29109 -fdelayed-template-parsing
-fno-implicit-modules -fcxx-exceptions -fexceptions -faddrsig -o
C:\Users\sms\AppData\Local\Temp\s-56fc7b.o -x c++ s.cpp
1. parser at end of file
2. Per-function optimization
3. Running pass 'Module Verifier' on function '@main'
clang++: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 12.0.0 (https://github.com/llvm/llvm-project
7d0b32c268ab4cfbc0630b2836890f2aef128d8b)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
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: C:\Users\sms\AppData\Local\Temp\s-eb6fec.cpp
clang++: note: diagnostic msg: C:\Users\sms\AppData\Local\Temp\s-eb6fec.sh
clang++: note: diagnostic msg:
--
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 46909] New: cbrt(2.0) computed differently by llvm and gcc
https://bugs.llvm.org/show_bug.cgi?id=46909
Bug ID: 46909
Summary: cbrt(2.0) computed differently by llvm and gcc
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: balarishi.bhog...@amd.com
CC: llvm-bugs@lists.llvm.org
$ cat foo.c
#include
#include
#include
#include
int main()
{
double d;
d = 2.0;
printf("pow((2.0), 1.0/3.0) = % .16e\n", pow((2.0), 1.0/3.0));
printf("cbrt(2.0) = % .16e\n", cbrt(2.0));
}
$ gcc foo.c -o foo -lm
$ ./foo
pow((2.0), 1.0/3.0) = 1.2599210498948732e+00
cbrt(2.0) = 1.2599210498948732e+00
$ clang foo.c -o foo -lm
$ ./foo
pow((2.0), 1.0/3.0) = 1.2599210498948732e+00
cbrt(2.0) = 1.2599210498948734e+00// <
--
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 46910] New: Deferred Diagnostics still fire if call is constexpr
https://bugs.llvm.org/show_bug.cgi?id=46910
Bug ID: 46910
Summary: Deferred Diagnostics still fire if call is constexpr
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: erich.ke...@intel.com
CC: llvm-bugs@lists.llvm.org
See this example:
https://godbolt.org/z/znj5Pv
constexpr float bar(long double f) { return f;}
void foo() {
#pragma omp target
{
float error = 0.0;
#pragma omp parallel for reduction(max:error)
for (int i = 0; i < 20; ++i) {
constexpr auto x = bar(1.1);
}
}
}
Diagnostic is:
:10:28: error: 'bar' requires 128 bit size 'long double' type support,
but device 'nvptx64-nvidia-cuda' does not support it
constexpr auto x = bar(1.1);
^
:2:17: note: 'bar' defined here
constexpr float bar(long double f) { return f;}
However, the invocation of 'bar' never makes it to the device, since it is
evaluated at compile time. Delayed diagnostics for uses should likely be
relaxed if it is evaluated during constant evaluation.
--
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 46824] Global declare target pointer cannot be accessed in target region
https://bugs.llvm.org/show_bug.cgi?id=46824 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||a.bat...@hotmail.com Fixed By Commit(s)||142d0d3ed8e07aca2476bc4ecc1 ||a12d15577a84a --- Comment #2 from Alexey Bataev --- Fixed in 142d0d3ed8e07aca2476bc4ecc1a12d15577a84a -- 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 46012] declare target pointer cannot be accessed in target region
https://bugs.llvm.org/show_bug.cgi?id=46012 Alexey Bataev changed: What|Removed |Added Status|REOPENED|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 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 46012, which changed state. Bug 46012 Summary: declare target pointer cannot be accessed in target region https://bugs.llvm.org/show_bug.cgi?id=46012 What|Removed |Added Status|REOPENED|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 46911] New: Wrong alignment on conditional store
https://bugs.llvm.org/show_bug.cgi?id=46911 Bug ID: 46911 Summary: Wrong alignment on conditional store Product: libraries Version: 11.0 Hardware: Other OS: All Status: NEW Severity: release blocker Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: kparz...@quicinc.com CC: llvm-bugs@lists.llvm.org Blocks: 46725 The original commit introducing part-word LL/SC expansion omitted alignment update on the conditional store by accident. This lead to incorrect code generated for sub-32-bit atomic operations. This mainly affects Hexagon. This is fixed in master in 7b114446c320de542c50c4c02f566e5d18adee33. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=46725 [Bug 46725] [meta] 11.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46912] New: Request merge of various AArch64 SVE fixes onto the LLVM 11 Release branch
https://bugs.llvm.org/show_bug.cgi?id=46912
Bug ID: 46912
Summary: Request merge of various AArch64 SVE fixes onto the
LLVM 11 Release branch
Product: libraries
Version: 11.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: sander.desma...@arm.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
Hello, would it be possible to have the following patches cherry-picked onto
the LLVM 11 release branch?
These are various fixes related to CodeGen for AArch64 SVE and/or scalable
vectors (for which SVE is the only target that supports it atm). Practically
all of the fixes are isolated to SVE and scalable vectors, so behavioural
changes are only exhibited when compiling for +sve. Any changes that are *not*
in lib/Target/AArch64 are of the kind: if(VT.isScalableVector) { /* bail out,
or do something else */ }
Fixes for various SVE bugs:
- 23ad660b5d34930b2b5362f1bba63daee78f6aa4 [SVE][CodeGen] At -O0 fallback to
DAG ISel when translating alloca with scalable types
- 9ad7c980bb47edd7db8f8db828b487cc7dfc9921 [SVE] Don't consider scalable vector
types in SLPVectorizerPass::vectorizeChainsInBlock
- 207877175944656bd9b52d36f391a092854572be [SVE][CodeGen] Add simple integer
add tests for SVE tuple types
- f43b5c7a76ab83dcc80e6769d41d5c4b761312b1 [SVE] Add checks for no warnings in
CodeGen/AArch64/sve-sext-zext.ll
- 5d84eafc6b86a42e261af8d753c3a823e0e7c67e [CodeGen] Remove calls to
getVectorNumElements in DAGTypeLegalizer::SplitVecOp_EXTRACT_SUBVECTOR
- 14bc85e0ebb6c00c1672158ab6a692bfbb11e1cc [SVE] Don't use LocalStackAllocation
for SVE objects
- cda2eb3ad2bbe923e74d6eb083af196a0622d800 [AArch64][SVE] Fix epilogue for SVE
when the stack is realigned.
- 26b4ef3694973ea2fa656d3d3a7f67f16f135654 [AArch64][SVE] Don't align the last
SVE callee save.
- 54492a5843a34684ce21ae201dd8ca3e509288fd [AArch64][SVE] Don't support
fixedStack for SVE objects.
- 993c1a3219a8ae69f1d700183bf174d75f3815d4 [AArch64][SVE] Teach copyPhysReg to
copy ZPR2/3/4.
- bef56f7fe2382ed1476aa67a55626b364635b44e [AArch64][SVE] Correctly allocate
scavenging slot in presence of SVE.
- 9bacf1588583014538a0217add18f370acb95788 [AArch64][SVE] Fix PCS for functions
taking/returning scalable types.
- b8f765a1e17f8d212ab1cd8f630d35adc7495556 [AArch64][SVE] Add support for trunc
to .
To apply (the first patch has merely a superficial conflict):
$ git cherry-pick --strategy=recursive -X theirs
b8f765a1e17f8d212ab1cd8f630d35adc7495556
$ git cherry-pick 9bacf1588583014538a0217add18f370acb95788
bef56f7fe2382ed1476aa67a55626b364635b44e
993c1a3219a8ae69f1d700183bf174d75f3815d4
54492a5843a34684ce21ae201dd8ca3e509288fd
26b4ef3694973ea2fa656d3d3a7f67f16f135654
cda2eb3ad2bbe923e74d6eb083af196a0622d800
14bc85e0ebb6c00c1672158ab6a692bfbb11e1cc
5d84eafc6b86a42e261af8d753c3a823e0e7c67e
f43b5c7a76ab83dcc80e6769d41d5c4b761312b1
207877175944656bd9b52d36f391a092854572be
9ad7c980bb47edd7db8f8db828b487cc7dfc9921
23ad660b5d34930b2b5362f1bba63daee78f6aa4
The following patches are addressing mode improvements, so more optional, but
are a really like-to-have:
- adb28e0fb2b0e97ea9dce422c09b36979cf7cd2f [llvm][CodeGen] Addressing modes for
SVE ldN.
- dbeb184b7f54db2d3ef20ac153b1c77f81cf0b99 [NFC][AArch64] Replace some template
methods/invocations...
- 809600d6642773f71245f76995dab355effc73af [llvm][sve] Reg + Imm addressing
mode for ld1ro.
To apply:
$ git cherry-pick 809600d6642773f71245f76995dab355effc73af
dbeb184b7f54db2d3ef20ac153b1c77f81cf0b99
adb28e0fb2b0e97ea9dce422c09b36979cf7cd2f
Please let me know if you have any questions and/or concerns!
Thanks,
Sander
--
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 46913] New: -Wuninitialized inside lambda
https://bugs.llvm.org/show_bug.cgi?id=46913
Bug ID: 46913
Summary: -Wuninitialized inside lambda
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: federico.kirch...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I've a bug that GCC was able to avoid thanks to "-Wuninitialized -O1", but that
clang fails to diagnose.
The reduced test-case is
int main() {
int i = [&](){return i;}();
return i;
}
I've tried compiling with "-Weverything -Wno-c++98-compat -O2" and other
optimizations level, without any luck.
Notice that
int main() {
int i = i;
return i;
}
gets diagnosed correctly with "warning: variable 'i' is uninitialized when used
within its own initialization [-Wuninitialized]".
Another example where clang does not emit any diagnostic but GCC does:
int main() {
int i;
[&](){i++;}();
return i;
}
--
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 46914] New: Inconsistency between
https://bugs.llvm.org/show_bug.cgi?id=46914
Bug ID: 46914
Summary: Inconsistency between
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: federico.kirch...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
There is an inconsistency between "-Wshadow-all" and
"-Wshadow-uncaptured-local".
int main() {
int i = [](int i){ return i;}(1);
return i;
}
when compiling with "-Wshadow-all" it emits following diagnostic: "warning:
declaration shadows a local variable [-Wshadow-uncaptured-local]"
but when compiling with "-Wshadow-uncaptured-local", it does not emit any
diagnostic.
As reference:
https://godbolt.org/z/vxWdc4
--
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 46915] New: analysis for min/max/abs intrinsics
https://bugs.llvm.org/show_bug.cgi?id=46915 Bug ID: 46915 Summary: analysis for min/max/abs intrinsics Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: spatel+l...@rotateright.com CC: llvm-bugs@lists.llvm.org We recently added IR intrinsics for min/max/abs, and there are several areas that need to be updated to support and optimize these. Please comment here if you are or are planning to work on any part of this, so we do not duplicate effort. Partial list: * ConstantFolding * ValueTracking * InstSimplify * InstCombine * PatternMatch * DemandedBits * Vectorization * Cost Modeling * LVI, CVP, SCCP * SCEV * IndVars -- 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 46228] [LV] Loop vectorizer crashes trying to version for unit stride at -Os/-Oz
https://bugs.llvm.org/show_bug.cgi?id=46228 ayal.z...@intel.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46916] New: [Statepoint-VRegs] Dropped tied operand when folding unrelated memop
https://bugs.llvm.org/show_bug.cgi?id=46916
Bug ID: 46916
Summary: [Statepoint-VRegs] Dropped tied operand when folding
unrelated memop
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
Found while working on something else, full test case copied below. Note that
after peephole-opt the def/use tied pairs have been broken. This is a
miscompile.
>From some quick digging, it appears to be a problem in foldPatchpoint in
lib/CodeGen/TargetInstInfo.cpp. What appears to be happening is we're folding
a load into a deopt operand and not preserving the tied operand information
when building the new instruction. Note that this *isn't* related to folding
gc operands themselves.
; RUN: llc -max-registers-for-gc-values=5
-stop-after=fixup-statepoint-caller-saved < %s
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
declare void @foo()
declare void @consume(i8 addrspace(1)*)
define void @test(i8 addrspace(1)* %a, i8 addrspace(1)* %b, i8 addrspace(1)*
%c, i8 addrspace(1)* %d, i8 addrspace(1)* %e, i8 addrspace(1)* %f, i8
addrspace(1)* %g, i8 addrspace(1)* %h) gc "statepoint-example" {
entry:
%safepoint_token = tail call token (i64, i32, void ()*, i32, i32, ...)
@llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32
0, i32 0, i32 0, i32 0) ["gc-live" (i8 addrspace(1)* %a, i8 addrspace(1)* %b,
i8 addrspace(1)* %c, i8 addrspace(1)* %d, i8 addrspace(1)* %e, i8 addrspace(1)*
%f, i8 addrspace(1)* %g, i8 addrspace(1)* %h)]
%a1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 0, i32 0)
call void @consume(i8 addrspace(1)* %a1)
%b1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 1, i32 1)
call void @consume(i8 addrspace(1)* %b1)
%c1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 2, i32 2)
call void @consume(i8 addrspace(1)* %c1)
%d1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 3, i32 3)
call void @consume(i8 addrspace(1)* %c1)
%e1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 4, i32 4)
call void @consume(i8 addrspace(1)* %e1)
%f1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 5, i32 5)
call void @consume(i8 addrspace(1)* %f1)
%g1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 6, i32 6)
call void @consume(i8 addrspace(1)* %g1)
%h1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 7, i32 7)
call void @consume(i8 addrspace(1)* %h1)
ret void
}
declare token @llvm.experimental.gc.statepoint.p0f_i1f(i64, i32, i1 ()*, i32,
i32, ...)
declare token @llvm.experimental.gc.statepoint.p0f_isVoidf(i64, i32, void ()*,
i32, i32, ...)
declare i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token, i32, i32)
--
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 46917] New: [Statepoint-VReg] Cornercase bug with multiple uses of a single value
https://bugs.llvm.org/show_bug.cgi?id=46917
Bug ID: 46917
Summary: [Statepoint-VReg] Cornercase bug with multiple uses of
a single value
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
There is a hard to handle cornercase in our experimental vreg statepoint
lowering. I had briefly described the problem in
https://reviews.llvm.org/D81648?vs=on&id=277132#2146051 as such:
"Second, there appears to be a semantic problem around the handling of base vs
derived slots unless we *always* spill the base. We can't tie both uses to a
single def. This may warrant some offline discussion."
(I decided to land that patch with the issue unresolved to unblock progress
since review discussion was fragmented and hard to follow.)
Let me expand a bit on the issue. Say we have an example like the following:
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
declare void @foo()
declare void @consume(i8 addrspace(1)*)
define void @test(i8 addrspace(1)* %a) gc "statepoint-example" {
entry:
%a_gep = getelementptr i8, i8 addrspace(1)* %a, i64 8
%safepoint_token = tail call token (i64, i32, void ()*, i32, i32, ...)
@llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32
0, i32 0, i32 0, i32 0) ["gc-live" (i8 addrspace(1)* %a, i8 addrspace(1)*
%a_gep)]
%a1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 0, i32 1)
call void @consume(i8 addrspace(1)* %a1)
ret void
}
declare token @llvm.experimental.gc.statepoint.p0f_i1f(i64, i32, i1 ()*, i32,
i32, ...)
declare token @llvm.experimental.gc.statepoint.p0f_isVoidf(i64, i32, void ()*,
i32, i32, ...)
declare i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token, i32, i32)
In this example, we generate a statepoint MI node which looks like this:
%6:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, 1, 8, %stack.0, 0, killed
%7(tied-def 0), csr_64, implicit-def $rsp, implicit-def $ssp :: (volatile load
store 8 on %stack.0)
(Where %7 is the GEP, and %stack.0 is the spill for the base)
Imagine we had instead generated:
%6:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, 1, 0, %7, 0, killed
%7(tied-def 0), csr_64, implicit-def $rsp, implicit-def $ssp :: (volatile load
store 8 on %stack.0)
(That is, replaced stack with another usage of %7.)
This would be incorrect. Why? Because the second use of %7 can not be tied to
the %6 def. As a result, the fact that the GC may need to update the base -
remember objects may move many times during a call - is lost. The register
allocator is free to assign different locations to the the two uses of %0, and
then *assume one of them is read only*. That would be a miscompile.
To say all that different, we tie *operands*, not registers.
Unfortunately, the very slightly tweaked example produces exactly this effect:
define void @test(i8 addrspace(1)* %a) gc "statepoint-example" {
entry:
%a_gep = getelementptr i8, i8 addrspace(1)* %a, i64 8
%safepoint_token = tail call token (i64, i32, void ()*, i32, i32, ...)
@llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @foo, i32
0, i32 0, i32 0, i32 0) ["gc-live" (i8 addrspace(1)* %a, i8 addrspace(1)*
%a_gep)]
%a1 = call i8 addrspace(1)* @llvm.experimental.gc.relocate.p1i8(token
%safepoint_token, i32 0, i32 0)
call void @consume(i8 addrspace(1)* %a1)
ret void
}
This produces:
%1:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, %0, %0(tied-def 0),
csr_64, implicit-def $rsp, implicit-def $ssp
Which is WRONG.
One possible correct alternative would be:
%1:gr64, %2:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, %0(tied-def 0),
%0(tied-def 1), csr_64, implicit-def $rsp, implicit-def $ssp
Note that while I've given the example in terms of a single base/derived pair,
you can also construct the same problematic pattern by relocating a single
object twice (or otherwise having multiple gc operand uses of the same value).
The two major families of fixes I see are:
1) Produce a separate tied def for each use copy.
2) Produce at most one use of each value - thus, eagerly spilling further uses.
The second seems like a hard invariant to preserve during optimization, so I'd
tend towards the first.
The first does result in slightly poor codegen since we can end up spilling the
same value twice. I don't have a simple fix for that. We could potentially
change the statepoint MI format to remove the dual use, but that's a bit
involved.
--
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:
[llvm-bugs] Issue 22113 in oss-fuzz: llvm:llvm-special-case-list-fuzzer: Timeout in llvm-special-case-list-fuzzer
Updates: Labels: Deadline-Approaching Comment #1 on issue 22113 by sheriffbot: llvm:llvm-special-case-list-fuzzer: Timeout in llvm-special-case-list-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22113#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46879] Integrated assembler errors on ljmp %cs:*(realdest - entry16_debug) : error: unknown token in expression
https://bugs.llvm.org/show_bug.cgi?id=46879 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fangrui Song --- Thanks! Marked as fix. -- 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 46918] New: MIR fails verifier when regalloc produces error: inline assembly requires more registers than available
https://bugs.llvm.org/show_bug.cgi?id=46918 Bug ID: 46918 Summary: MIR fails verifier when regalloc produces error: inline assembly requires more registers than available Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com Created attachment 23793 --> https://bugs.llvm.org/attachment.cgi?id=23793&action=edit Testcase The register allocator currently produces MIR that fails the verifier when it can't handle inline assembly. It produces the user error in the context, and then has to produce something and keep going. The MIR should pass the verifier so the compilation can reach the end successfully. I'm not sure whether it would be better to hack up the code to avoid failing the verifier, or to change the verifier check for the error and disable the liveness checks. llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 -verify-machineinstrs -- 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 46919] New: Integrated assembler errors on #(label-.-8): error: constant expression expected
https://bugs.llvm.org/show_bug.cgi?id=46919 Bug ID: 46919 Summary: Integrated assembler errors on #(label-.-8): error: constant expression expected Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: i...@maskray.me CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com, ties.st...@arm.com cat > a.s <___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46920] New: FAIL: Clang :: Driver/crash-report-modules.m
https://bugs.llvm.org/show_bug.cgi?id=46920
Bug ID: 46920
Summary: FAIL: Clang :: Driver/crash-report-modules.m
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mgo...@gentoo.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Blocks: 46725
The following new test fails in 11.0.0 when building standalone. Apparently
the bug is much older, just we haven't been tested for it. BUG_REPORT_URL is
not set in standalone builds.
FAIL: Clang :: Driver/crash-report-modules.m (6177 of 21387)
TEST 'Clang :: Driver/crash-report-modules.m' FAILED
Script:
--
: 'RUN: at line 4'; rm -rf
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
: 'RUN: at line 5'; mkdir -p
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/i
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/m
: 'RUN: at line 7'; env FORCE_CLANG_DIAGNOSTICS_CRASH=
TMPDIR=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
TEMP=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
TMP=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
not
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang
-fsyntax-only
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
-I
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/Inputs/module
-isysroot
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crash-report-modules.m.tmp/i/
-fmodules
-fmodules-cache-path=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/m/
-DFOO=BAR 2>&1 | /usr/lib/llvm/11/bin/FileCheck
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
: 'RUN: at line 11'; /usr/lib/llvm/11/bin/FileCheck --check-prefix=CHECKSRC
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
-input-file
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/crash-report-*.m
: 'RUN: at line 12'; /usr/lib/llvm/11/bin/FileCheck --check-prefix=CHECKSH
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
-input-file
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/crash-report-*.sh
--
Exit Code: 1
Command Output (stderr):
--
+ : 'RUN: at line 4'
+ rm -rf
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
+ : 'RUN: at line 5'
+ mkdir -p
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/i
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/m
+ : 'RUN: at line 7'
+ env FORCE_CLANG_DIAGNOSTICS_CRASH=
TMPDIR=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
TEMP=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
TMP=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir
not
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/bin/clang
-fsyntax-only
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
-I
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/Inputs/module
-isysroot
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crash-report-modules.m.tmp/i/
-fmodules
-fmodules-cache-path=/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/x/y/clang-abi_x86_32.x86/test/Driver/Output/crmdir/m/
-DFOO=BAR
+ /usr/lib/llvm/11/bin/FileCheck
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m
/var/tmp/portage/sys-devel/clang-11.0.0_rc1/work/clang/test/Driver/crash-report-modules.m:22:11:
error: CHECK: expected string not found in input
// CHECK: PLEASE submit a bug report to {{.*}} and include the crash backtrace,
preprocessed source, and associated run script.
^
:1:1: note: scanning from here
clang-11: error: failing because environment variable
'FORCE_CLANG_DIAGNOSTICS_CRASH' is set
^
:2:1: note: possible intended match here
PLEASE submit a bug report to and include the crash backtrace, preprocessed
source, and associated run s
[llvm-bugs] [Bug 46921] New: Apply "AMDGPU: Put inexpensive ops first in AMDGPUAnnotateUniformValues::visitLoadInst" to 11.0 release branch
https://bugs.llvm.org/show_bug.cgi?id=46921 Bug ID: 46921 Summary: Apply "AMDGPU: Put inexpensive ops first in AMDGPUAnnotateUniformValues::visitLoadInst" to 11.0 release branch Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: matthew.arsena...@amd.com CC: llvm-bugs@lists.llvm.org Apply 243376cdc7b719d443f42c8c4667e5d96af53dcc to the release branch. Since 85117e286db0bfa6c7cecadd2c0c348e3358f450 no longer skips this pass for graphics shaders, I'm concerned about the potential compile time impact on shaders -- 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 46908] Access type node must be a valid scalar type (std::destroying_delete_t)
https://bugs.llvm.org/show_bug.cgi?id=46908 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||llvmorg-12-init-1641-g1e7f0 ||26c3b5 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 46922] New: Wrongsided function picked for overload when valid template function exists.
https://bugs.llvm.org/show_bug.cgi?id=46922
Bug ID: 46922
Summary: Wrongsided function picked for overload when valid
template function exists.
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Keywords: compile-fail, regression
Severity: normal
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: canl...@sandia.gov
CC: llvm-bugs@lists.llvm.org
The following code doesn’t compile with newer versions of clang:
template
__device__ __host__ int foo(T *x) {
return 1;
}
__device__ int foo(int *x) {
return 2;
}
__host__ int foo(long *x) {
return 3;
}
__device__ __host__ int bar() {
auto long_val = 1l;
return foo(&long_val);
}
clang++ -O2 -g -x cuda --cuda-gpu-arch=sm_61 -std=c++14 -o main -c main.cpp
give me:
error: reference to __host__ function 'foo' in __host__ __device__ function
return foo(&long_val);
^
main.cpp:10:14: note: 'foo' declared here
__host__ int foo(long *x) {
I believe that the issue is at
https://github.com/llvm/llvm-project/blob/8224c5047e9cef2db4b0e31427cdf90a2568a341/clang/lib/Sema/SemaOverload.cpp#L9860
It’s possible that IdentifyCUDAPreference will return CFP_HostDevice for valid
overloads, but this code doesn’t erase the wrong side candidates in that case.
Then best overload selection picks the wrong side candidate.
If I rewrite those lines as:
bool ContainsSameSideCandidate =
llvm::any_of(Candidates, [&](OverloadCandidate *Cand) {
// Check viable function only.
if (Cand->Viable && Cand->Function) {
auto MatchType = S.IdentifyCUDAPreference(Caller, Cand->Function);
return MatchType == Sema::CFP_HostDevice ||
MatchType == Sema::CFP_SameSide;
}
return false;
});
My code compiles again.
--
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 46923] New: Assertion failure in PPCBoolRetToInt pass in rust when compiling firefox 79
https://bugs.llvm.org/show_bug.cgi?id=46923 Bug ID: 46923 Summary: Assertion failure in PPCBoolRetToInt pass in rust when compiling firefox 79 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Created attachment 23794 --> https://bugs.llvm.org/attachment.cgi?id=23794&action=edit Reduced test case. Rust on ppc64le crashes in the PPCBoolRetToInt pass when trying to compile firefox 79. I've attached a reduce test case. To reproduce run: llc < ff79-rust-reduced.ll -- 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 46924] New: A loop is not unrolled with a decreasing counter and -fno-vectorize
https://bugs.llvm.org/show_bug.cgi?id=46924
Bug ID: 46924
Summary: A loop is not unrolled with a decreasing counter and
-fno-vectorize
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: fj876...@aa.jp.fujitsu.com
CC: llvm-bugs@lists.llvm.org
If the following program is compiled with -fno-vectorize, unrolling does not
work.
It seems to be stopped by "High cost for expanding trip count scale!".
I have a feeling that unrolling can be applied. What do you think?
The loop was unrolled in llvm 9. Starting with llvm 10, it seems that loops are
no longer unrolled.
It seems to be affected by the following commit.
commit 0f22e783a038b6983f0fe161eef6cf2add3a4156
[InstCombine] Revert rL341831: relax one-use check in foldICmpAddConstant()
(PR44100)
For AArch64, this problem does not occur unless the -mcpu option is specified,
for example, thunderx2t99.
- minus.c
void foo(double * restrict a,
double * restrict b,
double * restrict c,
int n) {
for (int i=n;i>0;--i)
c[i] = a[i] + b[i];
return;
}
$ clang -target x86_64-unkown-linux-gnu -O3 minus.c
-Rpass=loop-vectorize\|unroll -fno-vectorize -S
$
- information on --debug-only=loop-unroll
$ clang -target x86_64-unkown-linux-gnu -O3 minus.c
-Rpass=loop-vectorize\|unroll -fno-vectorize -S -mllvm --debug-only=loop-unroll
Loop Unroll: F[foo] Loop %for.body
Loop Size = 8
will not try to unroll loop with runtime trip count -unroll-runtime not given
Loop Unroll: F[foo] Loop %for.body
Loop Size = 8
runtime unrolling with count: 4
Exiting Block = for.body
Trying runtime unrolling on Loop:
Loop at depth 1 containing: %for.body Using prolog
remainder.
High cost for expanding trip count scev!
Won't unroll; remainder loop could not be generated when assuming runtime trip
count
On the other hand, in the case of a loop with increasing counter, unrolling
works.
- plus.c
void foo(double * restrict a,
double * restrict b,
double * restrict c,
int n) {
for (int i=0;i0;--i)
c[i] = a[i] + b[i];
return;
}
$ clang -target x86_64-unkown-linux-gnu -O3 minusUnsigned.c
-Rpass=loop-vectorize\|unroll -fno-vectorize -S
minusUnsigned.c:6:3: remark: unrolled loop by a factor of 4 with run-time trip
count [-Rpass=loop-unroll]
for (unsigned i=n;i>0;--i)
^
$
--
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 46925] New: Clang crashed in clang/lib/AST/ASTContext.cpp:3115 Assertion `TypeLoc::getFullDataSizeForType(Updated) == TypeLoc::getFullDataSizeForType(TSInfo->getType()) && "TypeLoc si
https://bugs.llvm.org/show_bug.cgi?id=46925
Bug ID: 46925
Summary: Clang crashed in clang/lib/AST/ASTContext.cpp:3115
Assertion `TypeLoc::getFullDataSizeForType(Updated) ==
TypeLoc::getFullDataSizeForType(TSInfo->getType()) &&
"TypeLoc size mismatch from updating exception
specification"' failed
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: crash-on-invalid
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hi, all.
So weirdly, the definition of different identifier name makes Clang-trunk
crashed. This behavior only occurs in trunk version, and other released
versions compile this well.
$cat s1.cc
unsigned g_volatile_a;
class A {
int foo() noexcept(g_volatile_b);
};
$cat s2.cc
unsigned a;
class A {
int foo() noexcept(b);
};
$clang++ s1.cc
s1.cc:3:24: error: use of undeclared identifier 'g_volatile_b'; did you mean
'g_volatile_a'?
int foo() noexcept(g_volatile_b);
^~~~
g_volatile_a
s1.cc:1:10: note: 'g_volatile_a' declared here
unsigned g_volatile_a;
^
s1.cc:3:24: error: argument to noexcept specifier must be a constant expression
int foo() noexcept(g_volatile_b);
^~~~
s1.cc:3:24: note: read of non-const variable 'g_volatile_a' is not allowed in a
constant expression
s1.cc:1:10: note: declared here
unsigned g_volatile_a;
^
clang-12:
/home/tuhaoxin/compilers/llvm-project-0730/clang/lib/AST/ASTContext.cpp:3115:
void clang::ASTContext::adjustExceptionSpec(clang::FunctionDecl *, const
FunctionProtoType::ExceptionSpecInfo &, bool): Assertion
`TypeLoc::getFullDataSizeForType(Updated) ==
TypeLoc::getFullDataSizeForType(TSInfo->getType()) && "TypeLoc size mismatch
from updating exception specification"' 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:
/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
s1.cc -mrelocation-model static -mframe-pointer=all -fmath-errno
-fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64
-fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir
/home/tuhaoxin/compilers/llvm-project-0730/build/lib/clang/12.0.0 -c-isystem
/usr/local/include/csmith-2.3.0 -cxx-isystem /usr/local/include/csmith-2.3.0
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/x86_64-linux-gnu/c++/10
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/x86_64-linux-gnu/c++/10
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/backward
-internal-isystem /usr/local/include -internal-isystem
/home/tuhaoxin/compilers/llvm-project-0730/build/lib/clang/12.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdeprecated-macro -fdebug-compilation-dir
/home/tuhaoxin/gitee/run-new-scg/comparison/scg/ice-test/creduce -ferror-limit
19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics
-faddrsig -o /tmp/s1-07201d.o -x c++ s1.cc
1. parser at end of file
2. s1.cc:2:1: parsing struct/union/class body 'A'
#0 0x0275f234 PrintStackTraceSignalHandler(void*)
(/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12+0x275f234)
#1 0x0275ce2e llvm::sys::RunSignalHandlers()
(/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12+0x275ce2e)
#2 0x0275f555 SignalHandler(int)
(/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12+0x275f555)
#3 0x7f11b16f48a0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0)
#4 0x7f11b0152f47 raise
/build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f11b01548b1 abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f11b014442a __assert_fail_base
/build/glibc-2ORdQG/glibc-2.27/assert/assert.c:89:0
#7 0x7f11b01444a2 (/lib/x86_64-linux-gnu/libc.so.6+0x304a2)
#8 0x04a23c7a
(/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12+0x4a23c7a)
#9 0x04319805
clang::Sema::actOnDelayedExceptionSpecification(clang::Decl*,
clang::ExceptionSpecificationType, clang::SourceRange,
llvm::ArrayRef >,
llvm::ArrayRef, clang::Expr*)
(/home/tuhaoxin/compilers/llvm-project-0730/build/bin/clang-12+0x4319805)
#10 0x03ffd948
cl
[llvm-bugs] [Bug 46926] New: Assertion: "Initializer for struct element doesn't match!"
https://bugs.llvm.org/show_bug.cgi?id=46926 Bug ID: 46926 Summary: Assertion: "Initializer for struct element doesn't match!" Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: thrimbor.git...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 23797 --> https://bugs.llvm.org/attachment.cgi?id=23797&action=edit Files requested by the error output I discovered this on a release build of clang 10.0.1, but reproduced it on a debug build of 10.0.1 and the current master (ec1445c5afda7f145a414f11c9103c87a4c1823f). In the release build, the error message was "fatal error: error in backend: Type mismatch in constant table!". Somehow the inclusion of the type_info constructor seems to trigger this issue. but I can work around it by moving the whole struct and the function definitions into a different file. clang-10: /SSDATA/llvm-project/llvm/lib/IR/Constants.cpp:1147: llvm::ConstantAggregate::ConstantAggregate(llvm::Type*, llvm::Value::ValueTy, llvm::ArrayRef): Assertion `V[I]->getType() == ST->getTypeAtIndex(I) && "Initializer for struct element doesn't match!"' 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: /SSDATA/llvm-project/build/bin/clang-10 -cc1 -triple i386-pc-windows-msvc19.11.0 -emit-llvm-bc -emit-llvm-uselists -save-temps=cwd -disable-free -main-file-name main.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -ffreestanding -target-cpu pentium3 -resource-dir /SSDATA/llvm-project/build/lib/clang/12.0.0 -Wno-ignored-attributes -fdeprecated-macro -fdebug-compilation-dir /home/venom/Sync/xbox_dev/nxdk-txmltest/samples/hello++ -ferror-limit 19 -fno-builtin -fno-rtti -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.11 -std=c++14 -fdelayed-template-parsing -fcxx-exceptions -fexceptions -fcolor-diagnostics -disable-llvm-passes -faddrsig -o main.bc -x c++-cpp-output main.ii 1. parser at end of file 2. /home/venom/Sync/xbox_dev/nxdk-txmltest/samples/hello++/main.cpp:35:5: LLVM IR generation of declaration 'main' 3. /home/venom/Sync/xbox_dev/nxdk-txmltest/samples/hello++/main.cpp:35:5: Generating code for declaration 'main' #0 0x5626c66e9711 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /SSDATA/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:22 #1 0x5626c66e97a4 PrintStackTraceSignalHandler(void*) /SSDATA/llvm-project/llvm/lib/Support/Unix/Signals.inc:625:1 #2 0x5626c66e756f llvm::sys::RunSignalHandlers() /SSDATA/llvm-project/llvm/lib/Support/Signals.cpp:68:20 #3 0x5626c66e90a0 SignalHandler(int) /SSDATA/llvm-project/llvm/lib/Support/Unix/Signals.inc:406:1 #4 0x7f45d7162960 __restore_rt (/usr/lib/libpthread.so.0+0x14960) #5 0x7f45d6be9355 raise (/usr/lib/libc.so.6+0x3c355) #6 0x7f45d6bd2853 abort (/usr/lib/libc.so.6+0x25853) #7 0x7f45d6bd2727 _nl_load_domain.cold (/usr/lib/libc.so.6+0x25727) #8 0x7f45d6be1936 (/usr/lib/libc.so.6+0x34936) #9 0x5626c5c25457 llvm::ConstantAggregate::ConstantAggregate(llvm::Type*, llvm::Value::ValueTy, llvm::ArrayRef) /SSDATA/llvm-project/llvm/lib/IR/Constants.cpp:1147:7 #10 0x5626c5c259c4 llvm::ConstantStruct::ConstantStruct(llvm::StructType*, llvm::ArrayRef) /SSDATA/llvm-project/llvm/lib/IR/Constants.cpp:1214:3 #11 0x5626c5c3ccda llvm::ConstantAggrKeyType::create(llvm::StructType*) const /SSDATA/llvm-project/llvm/lib/IR/ConstantsContext.h:455:60 #12 0x5626c5c394ec llvm::ConstantUniqueMap::create(llvm::StructType*, llvm::ConstantAggrKeyType, std::pair > >&) /SSDATA/llvm-project/llvm/lib/IR/ConstantsContext.h:715:20 #13 0x5626c5c356f4 llvm::ConstantUniqueMap::getOrCreate(llvm::StructType*, llvm::ConstantAggrKeyType) /SSDATA/llvm-project/llvm/lib/IR/ConstantsContext.h:734:22 #14 0x5626c5c25be3 llvm::ConstantStruct::get(llvm::StructType*, llvm::ArrayRef) /SSDATA/llvm-project/llvm/lib/IR/Constants.cpp:1244:67 #15 0x5626c7072708 (anonymous namespace)::MicrosoftCXXABI::getAddrOfRTTIDescriptor(clang::QualType) /SSDATA/llvm-project/clang/lib/CodeGen/MicrosoftCXXABI.cpp:3887:32 #16 0x5626c707242d (anonymous namespace)::MicrosoftCXXABI::getAddrOfCXXCatchHandlerType(clang::QualType, clang::QualType) /SSDATA/llvm-project/clang/lib/CodeGen/MicrosoftCXXABI.cpp:3848:72 #17 0x5626c6bfa117 clang::CodeGen::CodeGenFunction::EnterCXXTryStmt(clang::CXXTryStmt const&, bool) /SSDATA/llvm-project/clang/lib/CodeGen/CGException.cpp:604:43 #18 0x5626c6bf9f05 clang::CodeGen::CodeGenFunction::EmitCXXTryStm
