[llvm-bugs] [Bug 49985] New: Test scripts are not portable
https://bugs.llvm.org/show_bug.cgi?id=49985 Bug ID: 49985 Summary: Test scripts are not portable Product: flang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Build System Assignee: unassignedb...@nondot.org Reporter: chinoune.me...@hotmail.com CC: david.tr...@arm.com, jper...@nvidia.com, llvm-bugs@lists.llvm.org, sscalp...@nvidia.com The test scripts (*.sh files) in the test folder can't be run on Windows. Either: Port them to Windows cmd as *.bat files, That's an extra work each time someone edit these scripts. Or: Don't rely on shell scripting and find other ways. Maybe look at a more mature project like clang and see how do they write portable tests. -- 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 49987] New: Backport fixes for running tests in Windows Containers
https://bugs.llvm.org/show_bug.cgi?id=49987 Bug ID: 49987 Summary: Backport fixes for running tests in Windows Containers Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org, tstel...@redhat.com Blocks: 49317 I'd appreciate if the following two commits can be backported to the 12.x branch: commit 9de63b2e051cb3e79645cc20b83b4d33d132cba0 Author: Martin Storsjö Date: Thu Mar 18 14:08:10 2021 +0200 [lit] Pass the USERPROFILE variable through on Windows commit a88556733a4dced22416bd3f45255128b9eb4f49 Author: Martin Storsjö Date: Wed Mar 24 23:58:54 2021 +0200 [LLD] Fix probing a MSYS based 'tar' in a Windows Container These two allow running tests with MSYS based tools within Windows Containers (which are used in the current CI setup, which afaik also runs tests for the release branches). This allows exposing bash within PATH in the image used for the containers (the same image is used for testing of the main branch too). The commits apply cleanly and I can do the actual cherrypicking, if it's deemed ok. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=49317 [Bug 49317] [meta] 12.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 49988] New: Backport fixes for variadic calling conventions for Windows on AArch64
https://bugs.llvm.org/show_bug.cgi?id=49988 Bug ID: 49988 Summary: Backport fixes for variadic calling conventions for Windows on AArch64 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, maxim.kuvyr...@gmail.com, r...@google.com, smithp...@googlemail.com, ties.st...@arm.com Blocks: 49317 The following commits contain fixes for the calling convention for variadic functions on Windows on AArch64, that could be considered for backporting to 12.0.1: commit 3637c5c8ec3d4dc0b87eb4e3ee9c9ae8816cade2 Author: Martin Storsjö Date: Sun Apr 11 12:38:40 2021 +0300 [clang] [AArch64] Fix Windows va_arg handling for larger structs commit 5144f730a8a8a4c7c7984ff945187a9aa83c91ac Author: Martin Storsjö Date: Sat Apr 10 07:40:33 2021 +0300 [AArch64] Fix windows vararg functions with floats in the fixed args commit 8e0f2e89ff951c74875ed751e2215cc263b33328 Author: Martin Storsjö Date: Wed Apr 14 13:45:09 2021 +0300 [clang] [AArch64] Fix handling of HFAs passed to Windows variadic functions The second one doesn't apply cleanly to the 12.x branch right now though. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=49317 [Bug 49317] [meta] 12.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 49989] New: Off-by-one error in overwrite path of MutationDispatcher::ApplyDictionaryEntry
https://bugs.llvm.org/show_bug.cgi?id=49989 Bug ID: 49989 Summary: Off-by-one error in overwrite path of MutationDispatcher::ApplyDictionaryEntry Product: compiler-rt Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: fuzzer Assignee: unassignedb...@nondot.org Reporter: meumertzh...@code-intelligence.com CC: llvm-bugs@lists.llvm.org In the overwrite branch of MutationDispatcher::ApplyDictionaryEntry in FuzzerMutate.cpp, the index Idx at which W.size() bytes are overwritten with the word W is chosen uniformly at random in the interval [0, Size - W.size()) (see https://github.com/llvm/llvm-project/blob/1ede08a290ac70b06df6887a39c1a22ccbfcc09f/compiler-rt/lib/fuzzer/FuzzerMutate.cpp#L198). This means that Idx + W.size() will always be strictly less than Size, i.e., the last byte of the current unit will never be overwritten. If my assessment is correct, I will gladly submit the trivial patch that fixes the issue: Rand(Size - W.size()) would have to be replaced with Rand(Size + 1 - W.size()). -- 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 49990] New: LLVM 12 build fails on missing CompletionModelCodegen.py
https://bugs.llvm.org/show_bug.cgi?id=49990
Bug ID: 49990
Summary: LLVM 12 build fails on missing
CompletionModelCodegen.py
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: at...@pld-linux.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Building LLVM with subcomponents extracted in one common directory fails with:
make[2]: *** No rule to make target
'/mnt/data-fast/jan/rpm/BUILD/clang-tools-extra/clangd/quality/CompletionModelCodegen.py',
needed by 'tools/clang/tools/extra/clangd/CompletionModel.h'. Stop.
make[2]: Leaving directory
'/mnt/data-fast/jan/rpm/BUILD/llvm-12.0.0.src/build'
Notice that it tries to find CompletionModelCodegen.py in some odd location
compared to real source location. This seems to be caused by
quality/CompletionModel.cmake with path being fixed to match some specific
build environment:
set(model_compiler
${CMAKE_SOURCE_DIR}/../clang-tools-extra/clangd/quality/CompletionModelCodegen.py)
--
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 49991] New: Question on backporting DR fixes
https://bugs.llvm.org/show_bug.cgi?id=49991
Bug ID: 49991
Summary: Question on backporting DR fixes
Product: clang
Version: trunk
Hardware: Other
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: c...@daryl.haresign.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
I spent some time today investigating why Clang was rejecting the following
code in C++17 mode, but not C++20. MSVC and GCC both accept it in C++17.
#include
struct C {
C(C&) = default;
};
std::optional o;
It seems https://wg21.link/cwg1331 was addressed by https://wg21.link/p641,
which was accepted into C++20.
Clang has the following commit which applies the change only in C++20 mode:
https://github.com/llvm/llvm-project/commit/9b2c5e7c44fd28c31f4a0b088d0bf71da4fddfa5
Whereas GCC and MSVC seem to have applied it unconditionally.
Is there any policy for when defect fixes are applied in earlier standard
modes?
--
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 49992] New: Possible incorrect position hint for persistent auto dictionary entry
https://bugs.llvm.org/show_bug.cgi?id=49992 Bug ID: 49992 Summary: Possible incorrect position hint for persistent auto dictionary entry Product: compiler-rt Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: fuzzer Assignee: unassignedb...@nondot.org Reporter: meumertzh...@code-intelligence.com CC: llvm-bugs@lists.llvm.org In MutationDispatcher::RecordSuccessfulMutationSequence in FuzzerMutate.cpp, the persistent auto dictionary entries are recorded with a fixed position hint of 1 (see https://github.com/llvm/llvm-project/blob/1ede08a290ac70b06df6887a39c1a22ccbfcc09f/compiler-rt/lib/fuzzer/FuzzerMutate.cpp#L482). As a result, in 50% of the cases, Mutate_AddWordFromPersistentAutoDictionary will attempt to apply the entry right after the first byte of the input. Using a fixed position at this point is surprising and may have resulted from a confusion with a no longer implemented, separate success count hinted at by a commented out line of code above (see https://github.com/llvm/llvm-project/blob/1ede08a290ac70b06df6887a39c1a22ccbfcc09f/compiler-rt/lib/fuzzer/FuzzerMutate.cpp#L477). The fixed position 1 could be replaced with either DE->GetPositionHint() (position hint copied from the entry) or std::numeric_limits::max() (no position hint). It remains to be determined which of these would be more appropriate. If needed, I could try to get some data on this via fuzzbench. -- 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 49993] New: Clang -O3 crashes in include/llvm/Support/Casting.h:269: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X = llvm::SCEVAddRecExpr; Y = const llvm::SCEV; ty
https://bugs.llvm.org/show_bug.cgi?id=49993
Bug ID: 49993
Summary: Clang -O3 crashes in
include/llvm/Support/Casting.h:269: typename
llvm::cast_retty::ret_type llvm::cast(Y*) [with
X = llvm::SCEVAddRecExpr; Y = const llvm::SCEV;
typename llvm::cast_retty::ret_type = const
llvm::SCEVAddRecExpr*]
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi all.
$cat small.c
#include
void a() {
uint8_t *b = a;
int32_t c;
if (0)
for (; c <= 6; c += 1)
d:;
for (*b = 18; *b <= 63; *b += 1)
c %= c + 0xD0C1B2E1;
goto d;
}
$clang -w -O3 small.c
clang-13:
/home/haoxin/haoxin-data/dut-research/compilers/llvm-project/llvm/include/llvm/Support/Casting.h:269:
typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X =
llvm::SCEVAddRecExpr; Y = const llvm::SCEV; typename llvm::cast_retty::ret_type = const llvm::SCEVAddRecExpr*]: Assertion `isa(Val) &&
"cast() argument of incompatible type!"' 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:
/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/bin/clang-13
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj --mrelax-relocations
-disable-free -main-file-name small.c -mrelocation-model static
-mframe-pointer=none -fmath-errno -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb
-fcoverage-compilation-dir=/home/haoxin/haoxin-data/test -resource-dir
/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/lib/clang/13.0.0
-c-isystem /usr/local/include/csmith-2.3.0 -cxx-isystem
/usr/local/include/csmith-2.3.0 -internal-isystem
/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/lib/clang/13.0.0/include
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O3
-w -fdebug-compilation-dir=/home/haoxin/haoxin-data/test -ferror-limit 19
-fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp
-faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/small-b9bac0.o -x c small.c
1. parser at end of file
2. Optimizer
#0 0x5645a6da25cc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/bin/clang-13+0x35935cc)
#1 0x5645a6da03d4 llvm::sys::RunSignalHandlers()
(/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/bin/clang-13+0x35913d4)
#2 0x5645a6da0543 SignalHandler(int) Signals.cpp:0:0
#3 0x7f4e51044980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#4 0x7f4e4fc6cfb7 raise
/build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7f4e4fc6e921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#6 0x7f4e4fc5e48a __assert_fail_base
/build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#7 0x7f4e4fc5e502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#8 0x5645a6aec928 (anonymous
namespace)::IndVarSimplify::linearFunctionTestReplace(llvm::Loop*,
llvm::BasicBlock*, llvm::SCEV const*, llvm::PHINode*, llvm::SCEVExpander&)
IndVarSimplify.cpp:0:0
#9 0x5645a6aef054 (anonymous namespace)::IndVarSimplify::run(llvm::Loop*)
IndVarSimplify.cpp:0:0
#10 0x5645a6af12bf llvm::IndVarSimplifyPass::run(llvm::Loop&,
llvm::AnalysisManager&,
llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&)
(/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/bin/clang-13+0x32e22bf)
#11 0x5645a7d6edb1 llvm::detail::PassModel,
llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&>::run(llvm::Loop&,
llvm::AnalysisManager&,
llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&)
(/media/haoxin/SeagateData/haoxin-data/dut-research/compilers/llvm-project/build-20210416/bin/clang-13+0x455fdb1)
#12 0x5645a7ed8e86 llvm::Optional
llvm::PassManager, llvm::LoopStandardAnalysisResults&,
llvm::LPMUpdater&>::runSinglePass,
llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&>,
std::default_delete,
llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&> > > >(llvm::Loop&,
std::unique_ptr,
llvm::LoopStanda
[llvm-bugs] [Bug 49115] [OpenMP 5.0] Incorrect results for scan directive
https://bugs.llvm.org/show_bug.cgi?id=49115 Alexey Bataev changed: What|Removed |Added Resolution|--- |FIXED CC||a.bat...@hotmail.com Fixed By Commit(s)||10c7b9f64fa6c0257fe8a7f8912 ||3afb5e463ebda 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 49986] False Positive for [clang-analyzer-core.UndefinedBinaryOperatorResult] in an VLA
https://bugs.llvm.org/show_bug.cgi?id=49986 Nathan James changed: What|Removed |Added CC||dcough...@apple.com, ||llvm-bugs@lists.llvm.org, ||n.jame...@hotmail.co.uk Version|unspecified |trunk Component|clang-tidy |Static Analyzer Product|clang-tools-extra |clang Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | --- Comment #1 from Nathan James --- Moving to the static-analyzer -- 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 49994] New: Baremetal builds fail as standard C library headers are imported
https://bugs.llvm.org/show_bug.cgi?id=49994
Bug ID: 49994
Summary: Baremetal builds fail as standard C library headers
are imported
Product: compiler-rt
Version: unspecified
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: eblot...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi,
I've noticed two issues while building compiler-rt for baremetal targets with
LLVM 12.0 final [sorry, no way to specify this version in the bugzilla]
I've tried to build RISCV targets, but the issues are not tied to a peculiar
baremetal architecture.
1. clearcache.c, which requires header is built on baremetal targets.
Something weird is that compiler-rt/lib/builtins/CMakeLists.txt does not
exclude this file from the baremetal builds, while the GN alternative does
exclude it:
CMake:
if (NOT FUCHSIA)
set(GENERIC_SOURCES
${GENERIC_SOURCES}
clear_cache.c
GN:
if (current_os != "fuchsia" && !compiler_rt_baremetal_build) {
sources += [ "clear_cache.c" ]
}
A simple patch such as
diff --git a/compiler-rt/lib/builtins/CMakeLists.txt
b/compiler-rt/lib/builtins/CMakeLists.txt
index 73b6bead8424..b46a3bfa4af2 100644
--- a/compiler-rt/lib/builtins/CMakeLists.txt
+++ b/compiler-rt/lib/builtins/CMakeLists.txt
@@ -244,7 +244,7 @@ if (HAVE_UNWIND_H)
)
endif ()
-if (NOT FUCHSIA)
+if (NOT FUCHSIA AND NOT COMPILER_RT_BAREMETAL_BUILD)
set(GENERIC_SOURCES
${GENERIC_SOURCES}
clear_cache.c
seems to fix this issue, but I'm not sure it is the proper fix. Maybe
COMPILER_RT_BAREMETAL_BUILD is not longer the proper CMake definition to use?
2. Another C lib dependency appears in int_util.c, where is imported
even for baremetal builds, around line 57. I'm not sure how to work around this
one.
--
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 49995] New: clang-format 12 has multiple bugs handling lines including `NS_SWIFT_NAME`
https://bugs.llvm.org/show_bug.cgi?id=49995 Bug ID: 49995 Summary: clang-format 12 has multiple bugs handling lines including `NS_SWIFT_NAME` Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: paulbeuster...@google.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org It most notably ignores `ColumnLimit` and creates very long lines. Full example in the diff at https://github.com/firebase/firebase-ios-sdk/pull/7909 -- 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 49996] New: clang-format 11 is no longer available via brew
https://bugs.llvm.org/show_bug.cgi?id=49996 Bug ID: 49996 Summary: clang-format 11 is no longer available via brew Product: clang Version: 11.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: paulbeuster...@google.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org The missing clang-format 11 on brew is problematic for our CI because of https://bugs.llvm.org/show_bug.cgi?id=49995 in clang-format 12 -- 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 49785] [LoopUnroll] compile-time explosion with assumes at -O3
https://bugs.llvm.org/show_bug.cgi?id=49785 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||bb907b26e2bf Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Sanjay Patel --- We took a different approach in: https://reviews.llvm.org/D100573 Committed at: https://reviews.llvm.org/rGbb907b26e2bf IR test case derived from the source in this report added with: https://reviews.llvm.org/rG437fb4281787 -- 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 49997] New: Provide a focal-13 alias to focal
https://bugs.llvm.org/show_bug.cgi?id=49997
Bug ID: 49997
Summary: Provide a focal-13 alias to focal
Product: Packaging
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: deb packages
Assignee: unassignedb...@nondot.org
Reporter: gonzalo.gades...@gmail.com
CC: llvm-bugs@lists.llvm.org
For context, right now, the deb packages provided for the different Linux
distributions, e.g., for focal, are at:
deb http://apt.llvm.org/focal/ llvm-toolchain-focal main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal main
deb http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main
deb http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main
In particular, the packages of the "trunk" version are at
"llvm-toolchain-focal" while the packages of a released version are at
"llvm-toolchain-focal-{release}".
Tools that automatically install LLVM for users, like the HPC Container Maker -
a tool for building HPC containers - need to be aware of what the latest trunk
version number is:
- such that they can pick "llvm-toolchain-focal" instead of
"llvm-toolchain-focal-13" which does not exist
- such that they can properly set the toolchain as the container toolchain,
e.g., clang-13.
Right now, these tools break for the last released version and trunk every 6
months when the information about the current trunk version becomes outdated
every new release.
This requires patching these tools every six months, and while the patch lands,
users must regress 1 version, e.g., currently, to using LLVM 11 since 12 and 13
(trunk) do not work anymore.
It would be super super helpful for these tools if we could provide an alias
for trunk that contains the version number. That is, to provide:
deb http://apt.llvm.org/focal/ llvm-toolchain-focal main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal main
deb http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main
deb http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main
deb http://apt.llvm.org/focal/ llvm-toolchain-focal-13 main
deb-src http://apt.llvm.org/focal/ llvm-toolchain-focal-13 main
where "llvm-toolchain-focal-13" (13 is current trunk version) is just an alias
for "llvm-toolchain-focal".
That would allow users of these tools to pick 13 if they want to use trunk, and
once trunk gets promoted to a release, they'll continue using the release.
Users would then need to manually update to 14 in 6 months to continue using
trunk, but that's something that they could do with their current HPCCM
version.
--
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 48340] loop-vectorize assertion failure "argument of incompatible type"
https://bugs.llvm.org/show_bug.cgi?id=48340 Florian Hahn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||04790d9cfba35073d5604754450 ||2c387c5657bb1 --- Comment #4 from Florian Hahn --- This should be fixed on main: https://godbolt.org/z/z5zn1aWPc https://reviews.llvm.org/rG04790d9cfba35073d56047544502c387c5657bb1 -- 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 49998] New: templated constexpr variable fails to deduce auto type in template context
https://bugs.llvm.org/show_bug.cgi?id=49998
Bug ID: 49998
Summary: templated constexpr variable fails to deduce auto type
in template context
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: pro.guillaume@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Using clang 12.0.0
Note : Maybe in correlation with https://bugs.llvm.org/show_bug.cgi?id=43459
Looks like Clang cannot evaluate an `auto` type for a constexpr
template-variable which depends on another,
when both depends on a template context.
See live example here on godbolt : https://godbolt.org/z/ofveeGoWe
```cpp
template
struct foo
{
constexpr inline static auto value = 42;
};
template
struct bar
{
template
constexpr static inline auto foo_value = foo::value; // KO
// nb : replacing `auto` with `int` remove the error
};
static_assert(bar::foo_value == 42);
```
Which results in :
```log
:15:40: error: invalid operands to binary expression ('const auto' and
'int')
```
Stackoverflow associated post :
https://stackoverflow.com/questions/67127710/clang-invalid-operands-to-binary-expression-const-auto-and-int-with-cons
--
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 49999] New: Regression(?): ld64.lld crashes linking tsan runtime
https://bugs.llvm.org/show_bug.cgi?id=4 Bug ID: 4 Summary: Regression(?): ld64.lld crashes linking tsan runtime Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: nicolaswe...@gmx.de CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, smee...@fb.com Created attachment 24761 --> https://bugs.llvm.org/attachment.cgi?id=24761&action=edit repro I use some version of ld64.lld as my host linker. I updated my ld64.lld recently, and now it crashes linking the tsan runtime: Assertion failed: (target->hasAttr(relInfo.r_type, RelocAttrBits::UNSIGNED) && relInfo.r_extern), function parseRelocations, file ../../lld/MachO/InputFiles.cpp, line 324. (The tsan runtime is new in the GN build too though, so maybe it never worked.) Attaching repro file. % LLD_REPRODUCE=repro.tar ninja -C out/gn -j200 lib/clang/13.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib ninja: Entering directory `out/gn' [1/1] SOLINK lib/clang/13.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib FAILED: lib/clang/13.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib ./bin/clang++ -shared -lc++ -lc++abi -lobjc -Wl,-U,___sanitizer_free_hook -Wl,-U,___sanitizer_malloc_hook -Wl,-U,___sanitizer_report_error_summary -Wl,-U,___sanitizer_sandbox_on_notify -Wl,-U,___sanitizer_symbolize_code -Wl,-U,___sanitizer_symbolize_data -Wl,-U,___sanitizer_symbolize_demangle -Wl,-U,___sanitizer_symbolize_flush -Wl,-install_name,@rpath/libclang_rt.tsan_osx_dynamic.dylib -mmacosx-version-min=10.10 -Wl,--color-diagnostics -fuse-ld=lld -isysroot ../../sysroot/MacOSX.sdk -o lib/clang/13.0.0/lib/darwin/libclang_rt.tsan_osx_dynamic.dylib stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_clock.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_debugging.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_external.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_fd.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_flags.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_ignoreset.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interceptors_posix.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interface.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interface_ann.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interface_atomic.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interface_java.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_malloc_mac.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_md5.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_mman.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_mutex.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_mutexset.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_preinit.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_report.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl_mutex.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl_proc.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl_report.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl_thread.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_stack_trace.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_stat.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_suppressions.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_symbolize.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_sync.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interceptors_libdispatch.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interceptors_mac.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_interceptors_mach_vm.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_platform_mac.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_platform_posix.o stage2_unix/obj/compiler-rt/lib/tsan/rtl/tsan.tsan_rtl_amd64.o stage2_unix/obj/compiler-rt/lib/interception/sources.interception_linux.o stage2_unix/obj/compiler-rt/lib/interception/sources.interception_mac.o stage2_unix/obj/compiler-rt/lib/interception/sources.interception_type_test.o stage2_unix/obj/compiler-rt/lib/interception/sources.interception_win.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sancov_flags.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_allocator.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_allocator_checks.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_allocator_report.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_chained_origin_depot.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_common.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitizer_common_libcdep.o stage2_unix/obj/compiler-rt/lib/sanitizer_common/sources.sanitize
[llvm-bugs] Issue 33328 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in clang::Parser::SkipUntil
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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-16 Type: Bug New issue 33328 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in clang::Parser::SkipUntil https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33328 Detailed Report: https://oss-fuzz.com/testcase?key=6441486293008384 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc4ec79f48 Crash State: clang::Parser::SkipUntil Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201910210337:201910220425 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6441486293008384 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49983] Clang and LLVM IR on PowerPC, and getting: CUDA failure: ‘Invalid device function’
https://bugs.llvm.org/show_bug.cgi?id=49983 Artem Belevich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Artem Belevich --- Not a bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50000] New: Enable constraint-elimination by default
https://bugs.llvm.org/show_bug.cgi?id=5 Bug ID: 5 Summary: Enable constraint-elimination by default Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: florian_h...@apple.com CC: llvm-bugs@lists.llvm.org An umbrella bug to keep track of work towards enabling -constraint-elimination by default. -- 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 50001] New: string_view equality operator does not compile with clang-cl
https://bugs.llvm.org/show_bug.cgi?id=50001
Bug ID: 50001
Summary: string_view equality operator does not compile with
clang-cl
Product: libc++
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mho...@microsoft.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Context first:
There is a name-mangling issue/bug/limitation in clang-cl (doesn't appear to
impact clang directly) easily repro'd by attempting to compile the following
(locally named clang-cl-issue.cpp):
template
struct X {
T member;
};
template
struct ConvertibleToX {
operator X() { return {T{}}; }
};
template
struct identity {
using type = T;
};
template
bool operator==(const X lhs, const X rhs) {
return (true);
}
template
bool operator==(const X lhs, const typename identity>::type rhs) {
return (true);
}
template
bool operator==(const typename identity>::type lhs, const X rhs) {
return (true);
}
int main() {
X xVal{42};
ConvertibleToX xConvVal;
bool result = xVal == xVal;
result = xVal == xConvVal;
result = xConvVal == xVal;
return result ? 1 : 0;
}
RESULT:
clang-cl-issue.cpp(18,6): error: definition with same mangled name
'??$?8H@@YA_NU?$X@H@@0@Z' as another definition
bool operator==(const X lhs, const typename identity>::type rhs) {
^
clang-cl-issue.cpp(14,6): note: previous definition is here
bool operator==(const X lhs, const X rhs) {
^
clang-cl-issue.cpp(22,6): error: definition with same mangled name
'??$?8H@@YA_NU?$X@H@@0@Z' as another definition
bool operator==(const typename identity>::type lhs, const X rhs) {
^
clang-cl-issue.cpp(14,6): note: previous definition is here
bool operator==(const X lhs, const X rhs) {
This issue is relevant to the libc++ component because the string_view
implementation currently uses the same pattern, raising the same errors with
clang-cl with very simple usage. For example, attempting to compile:
#include
#include
#include
constexpr std::string_view kSomeView("Hello");
bool TestFunction(
const std::unordered_set& telemetry,
const std::string& s) noexcept
{
if (telemetry.find(s) != telemetry.end()) {
return s == kSomeView;
}
return false;
}
RESULT:
{MyLocalPath}\libcxx\include\string_view(614,6): error: definition with same
mangled name
'??$?8DU?$char_traits@D@__1@std@@@__1@std@@YA_NV?$basic_string_view@DU?$char_traits@D@__1@std@@@01@0@Z'
as another definition
bool operator==(basic_string_view<_CharT, _Traits> __lhs,
^
{MyLocalPath}\libcxx\include\string_view(632,6): note: previous definition is
here
bool operator==(typename common_type >::type
__lhs,
^
Though the root issue is with clang-cl, this can be worked around very easily
by adding additional qualifiers to the string_view equality operator templates
to force them to be unique. Added below ", int = 1" and ", int = 2" fixes this
problem for string_view usage.
// [string.view.comparison]
// operator ==
template
_LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
bool operator==(basic_string_view<_CharT, _Traits> __lhs,
basic_string_view<_CharT, _Traits> __rhs) _NOEXCEPT
{
if ( __lhs.size() != __rhs.size()) return false;
return __lhs.compare(__rhs) == 0;
}
template
_LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
bool operator==(basic_string_view<_CharT, _Traits> __lhs,
typename common_type >::type
__rhs) _NOEXCEPT
{
if ( __lhs.size() != __rhs.size()) return false;
return __lhs.compare(__rhs) == 0;
}
template
_LIBCPP_CONSTEXPR_AFTER_CXX11 _LIBCPP_INLINE_VISIBILITY
bool operator==(typename common_type >::type
__lhs,
basic_string_view<_CharT, _Traits> __rhs) _NOEXCEPT
{
if ( __lhs.size() != __rhs.size()) return false;
return __lhs.compare(__rhs) == 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] Issue 29852 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in llvm-opt-fuzzer--x86_64-earlycse
Updates: Labels: Deadline-Approaching Comment #1 on issue 29852 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in llvm-opt-fuzzer--x86_64-earlycse https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29852#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 50002] New: segmentation fault in libomptarget when using taskloop and target nowait
https://bugs.llvm.org/show_bug.cgi?id=50002
Bug ID: 50002
Summary: segmentation fault in libomptarget when using taskloop
and target nowait
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: xw111lu...@gmail.com
CC: llvm-bugs@lists.llvm.org
LIBOMP_USE_HIDDEN_HELPER_TASK=0 makes the reproducer to work. So there are some
correlations.
reproducer: clang++ -fopenmp -fopenmp-targets=nvptx64
taskloop_offload_nowait.cpp
#include
#include
#include
bool almost_equal(float x, float gold, float tol) {
if ( std::signbit(x) != std::signbit(gold) )
{
x = std::abs(gold) - std::abs(x);
}
return std::abs(gold) * (1-tol) <= std::abs(x) && std::abs(x) <=
std::abs(gold) * (1 + tol);
}
int main()
{
const int N0 { 2 };
const int N1 { 182 };
const float expected_value { N0*N1 };
float counter_N0{};
#pragma omp target data map(tofrom: counter_N0)
{
#pragma omp taskloop shared(counter_N0)
for (int i0 = 0 ; i0 < N0 ; i0++ )
{
#pragma omp target teams distribute parallel for map(tofrom: counter_N0)
nowait
for (int i1 = 0 ; i1 < N1 ; i1++ )
{
#pragma omp atomic update
counter_N0 = counter_N0 + 1. ;
}
}
}
if (!almost_equal(counter_N0, expected_value, 0.1)) {
std::cerr << "Expected: " << expected_value << " Got: " << counter_N0 <<
std::endl;
std::exit(112);
}
}
--
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 50003] New: Warns about lambda function based on the return type that is not what inferred return type is
https://bugs.llvm.org/show_bug.cgi?id=50003 Bug ID: 50003 Summary: Warns about lambda function based on the return type that is not what inferred return type is Product: clang Version: 10.0 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24762 --> https://bugs.llvm.org/attachment.cgi?id=24762&action=edit testcase-clang-bug-warns-about-fantom-return.cpp The lambda function is written like it returns char* but the inferred return type is std::string. clang-10 warns: > testcase-clang-bug-warns-about-fantom-return.cpp:14:11: warning: address of > stack memory associated with local variable 't' returned > [-Wreturn-stack-address] > return t; >^ > 1 warning generated. as if this function returns char*, but the actual correct inferred return type is std::string and there should be no warning. -- 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 50003] Warns about lambda function based on the return type that is not what inferred return type is
https://bugs.llvm.org/show_bug.cgi?id=50003
David Blaikie changed:
What|Removed |Added
Resolution|--- |INVALID
CC||dblai...@gmail.com
Status|NEW |RESOLVED
--- Comment #1 from David Blaikie ---
Converting the lambda to a std::function doesn't change the type of the lambda.
The return type of the lambda is inferred by the type of the return statement
only.
Essentially the lambda this code creates is this:
auto unmentionable() {
char t[10] = "abc";
return t;
}
...
std::function f = unmentionable;
which results in a std::function that does something like this:
std::string func() {
return unmentionable();
}
Because a char* is convertible to std::string, this ^ code compiles, but does
have the bug the diagnostic warns about - dangling pointer to a local variable.
--
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 50004] New: -z separate-loadable-segments doesn't work with LTO enabled
https://bugs.llvm.org/show_bug.cgi?id=50004
Bug ID: 50004
Summary: -z separate-loadable-segments doesn't work with LTO
enabled
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: rianqu...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
If I enabled LTO "using "-flto" in clang, and I include -z
separate-loadable-segments (or remove it, as it doesn't seem to make a
difference), I get the following:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
LOAD 0x001000 0x0280 0x0280 0x001f48
0x001f48 R 0x1000
LOAD 0x003000 0x02802000 0x02802000 0x020325
0x020325 R E 0x1000
LOAD 0x024328 0x02822328 0x02822328 0x006e80
0x01f2d1 RW 0x1000
GNU_STACK 0x00 0x 0x 0x00
0x00 RW 0
The RW section is not properly aligned. I am using version 11. Below is my
linker script. I am not sure if this is a bug or not, and it works fine when
LTO is disabled, but I would like to enable LTO and I am not sure what I am
doing wrong at this point.
ENTRY(mk_main_entry)
OUTPUT_FORMAT(elf64-x86-64)
SECTIONS {
. = 0x0280;
.text : ALIGN(0x1000) {
*(.text)
}
.init : ALIGN(0x1000) {
*(.init)
}
.init_array : ALIGN(0x1000) {
*(.init_array)
}
.fini : ALIGN(0x1000) {
*(.fini)
}
.fini_array : ALIGN(0x1000) {
*(.fini_array)
}
.rodata : ALIGN(0x1000) {
*(.rodata)
}
.data : ALIGN(0x1000) {
*(.data)
}
.bss : ALIGN(0x1000) {
*(.bss)
}
}
--
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 50005] New: fatal error: base class '...' has a flexible array member
https://bugs.llvm.org/show_bug.cgi?id=50005
Bug ID: 50005
Summary: fatal error: base class '...' has a flexible array
member
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: l...@behdad.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
In HarfBuzz we extensively use the Struct Hack [0]. Up until now we've used
"array[1]" for that. This upsets ubsan [1]. So I'm looking to replace it with
flexible arrays on compilers that support it.
However, trying to do that I get the "base class '...' has a flexible array
member" error. The derived class only has one base class and no members. So I
like to ask that this special-case be allowed.
Test case, based on actual code:
```
struct UnsignedArray {
unsigned count;
int array[];
};
struct SortedUnsignedArray : UnsignedArray {
};
```
I've tested this with Apple clang 12.
[0] http://c-faq.com/struct/structhack.html
[1] https://github.com/harfbuzz/harfbuzz/issues/2953
--
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 50006] New: -Wunknown-warning-option cannot be disabled via pragma
https://bugs.llvm.org/show_bug.cgi?id=50006 Bug ID: 50006 Summary: -Wunknown-warning-option cannot be disabled via pragma Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: l...@behdad.org CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk [Broadly speaking, this is similar to https://bugs.llvm.org/show_bug.cgi?id=25436] In HarfBuzz we declare what warnings we want as error, as warning, and ignored, in a C++ header file: https://github.com/harfbuzz/harfbuzz/blob/ed2ee8a8c26dc39e39172c169d8a0d434083fefe/src/hb.hh#L37-L138 clang (tested with Apple clang 12) warns about unknown warning options: warning: unknown warning option '-Wunsafe-loop-optimizations' [-Wunknown-warning-option] warning: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'? [-Wunknown-warning-option] However, we have this before adding other warning options: #pragma GCC diagnostic ignored "-Wunknown-warning-option" But clang seems to ignore it. Making that line say "clang" instead of "GCC" doesn't make any difference. If I pass -Wno-unknown-warning-option on the commandline it works. As pragma doesn't. Am I doing this wrong? Thanks. -- 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 49883] missing-braces warning for empty aggregates inhering from aggregates
https://bugs.llvm.org/show_bug.cgi?id=49883 Hana Dusíková changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hana Dusíková --- fix merged into main -- 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 33348 in oss-fuzz: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::PointerTypeNode::outputPre
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 Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-17 Type: Bug New issue 33348 by ClusterFuzz-External: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::PointerTypeNode::outputPre https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33348 Detailed Report: https://oss-fuzz.com/testcase?key=4595379527090176 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-microsoft-demangle-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd5c02be38 Crash State: llvm::ms_demangle::PointerTypeNode::outputPre Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202010020604:202010030603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4595379527090176 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50007] New: Backport 'Partially Revert "scan-view: Remove Reporter.py and associated AppleScript files"' to 12.0.1
https://bugs.llvm.org/show_bug.cgi?id=50007 Bug ID: 50007 Summary: Backport 'Partially Revert "scan-view: Remove Reporter.py and associated AppleScript files"' to 12.0.1 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 49317 Apparently scan-view is broken now: Traceback (most recent call last): File "/usr/lib/llvm/12/bin/scan-view", line 150, in main() File "/usr/lib/llvm/12/bin/scan-view", line 147, in main run(port, args, args.root) File "/usr/lib/llvm/12/bin/scan-view", line 74, in run import ScanView File "/usr/lib/llvm/12/bin/../share/scan-view/ScanView.py", line 29, in import Reporter ModuleNotFoundError: No module named 'Reporter' I'm surprised we don't cover it with regression tests. The fix's apparently in https://reviews.llvm.org/D96367 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=49317 [Bug 49317] [meta] 12.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 50008] New: Missing comparison folding optimization
https://bugs.llvm.org/show_bug.cgi?id=50008
Bug ID: 50008
Summary: Missing comparison folding optimization
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
Optimization
(cond ? ptr + 1 : ptr == ptr) --> !cond
is missing in clang.
https://godbolt.org/z/e7W5WrK5M
bool not_cond(char *x, bool cond) {
char *y = x;
if (cond)
y = x + 1;
return x == y;
}
g++ -O3 (x86-64):
mov eax, esi
xor eax, 1
ret
clang -O3 (x86-64):
lea rax, [rdi + 1]
testesi, esi
cmove rax, rdi
cmp rax, rdi
seteal
ret
Similarly for AArch64.
It seems the middle-end optimization cannot fold this:
```
%add.ptr = getelementptr inbounds i8, i8* %x, i64 1
%spec.select = select i1 %cond, i8* %add.ptr, i8* %x
%cmp = icmp eq i8* %spec.select, %x
```
--
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
