[llvm-bugs] Issue 20316 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-01-24 Type: Bug New issue 20316 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20316 Detailed Report: https://oss-fuzz.com/testcase?key=5633732086333440 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd41528b28 Crash State: clang::Lexer::Lex clang::Preprocessor::Lex clang::Parser::ParseParenExpression Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202001230519 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5633732086333440 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 44246] [AArch64] strict_align not respected by GlobalISel
https://bugs.llvm.org/show_bug.cgi?id=44246 Amara Emerson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Amara Emerson --- I've committed 765b37abdfc0 as a workaround which should fall back in selection if this subtarget feature is given. -- 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 44614] Assertion failure with requires clause put after function parameters that mentions any variable
https://bugs.llvm.org/show_bug.cgi?id=44614 Saar Raz changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||4d33a8dfcf67e970ea4d150d514 ||b27de02e79aee CC||saar@raz.email 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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44556, which changed state. Bug 44556 Summary: -Wrange-loop-analysis is too strict in templates https://bugs.llvm.org/show_bug.cgi?id=44556 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44556] -Wrange-loop-analysis is too strict in templates
https://bugs.llvm.org/show_bug.cgi?id=44556 Aaron Puchert changed: What|Removed |Added Fixed By Commit(s)||41fcd17250fa0526e4b7fd2c7df ||7721b0f79b683 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Aaron Puchert --- The issue has been fixed, I'll create a new bug for my concerns from comment 3. We arguably have false negatives now, but that's better than false positives. -- 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 44641] New: GPF when passing a non-aligned struct to a __declspec(align) typedef
https://bugs.llvm.org/show_bug.cgi?id=44641
Bug ID: 44641
Summary: GPF when passing a non-aligned struct to a
__declspec(align) typedef
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: alexandre.ga...@ubisoft.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk, r...@google.com
Clang does not complain when a non-aligned instance is assigned to aligned
typedef'd type (repro below).
I think at least a warning would be nice (if not, an error).
MSVC and GCC handle this by doing a unaligned load.
https://godbolt.org/z/62HzmJ
// a.h
struct Vector4 { float v[4]; };
typedef __declspec(align(16)) Vector4 AlignVector4;
struct A {
AlignVector4 vec;
void SetVec(const AlignVector4& v) { vec = v; }
};
struct B {
bool b;
Vector4 vec;
};
// a.cpp
#include "a.h"
int f(A& a, const B& b) {
a.SetVec(b.vec);
return (int)a.vec.v[0];
}
// main.cpp
#include "a.h"
int f(A& a, const B& b);
int main() {
A a; B b;
return f(a, b);
}
// Build:
// clang-cl a.cpp /O2 /c /MT
// clang-cl main.cpp /c /MT
// lld-link a.obj main.obj /entry:main /subsystem:console
--
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 44640] New: Please backport 3c545e4b731 to 10.0.0 ([openmp] Disable archer if LIBOMP_OMPT_SUPPORT is off)
https://bugs.llvm.org/show_bug.cgi?id=44640 Bug ID: 44640 Summary: Please backport 3c545e4b731 to 10.0.0 ([openmp] Disable archer if LIBOMP_OMPT_SUPPORT is off) Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: llvm-bugs@lists.llvm.org, pro...@itc.rwth-aachen.de Blocks: 44555 This is needed to fix build failure when ompt is disabled: commit 3c545e4b7318c337bed43d5bc76aad040565f1ef Author: Michał Górny Date: 2020-01-23 06:56:01 +0100 [openmp] Disable archer if LIBOMP_OMPT_SUPPORT is off This fixed build failures due to missing ompt headers. See https://bugs.gentoo.org/700762. Differential Revision: https://reviews.llvm.org/D73249 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=44555 [Bug 44555] [meta] 10.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 44639] New: Optimization bug compiling for ARM v7a (32-bit)
https://bugs.llvm.org/show_bug.cgi?id=44639 Bug ID: 44639 Summary: Optimization bug compiling for ARM v7a (32-bit) Product: clang Version: 8.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: bri...@dashlogic.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 23048 --> https://bugs.llvm.org/attachment.cgi?id=23048&action=edit Android Studio example project My development environment is using Windows 10, Android Studio v3.5.3, Android NDK v20.0.5594570, with Clang v8.0.7. This bug appears to only happen when targeting armeabi-v7a for 32-bit Android, and not for arm64-v8a or any x86 variant. While working with the pixman graphics library compiling for Android, we've found a bug when optimizations are turned off using #pragma optimize off during a release variant build of the app. The exact error message is: [armeabi-v7a] Compile arm: myappnative <= android.c fatal error: error in backend: symbol '.LPC5_0' can not be undefined in a subtraction expression I've pulled some snippets of source out of the pixman library into an example project that reproduces this error (attached). In the attached example project, in the file android.c, the error happens on line 144 and line 174, as follows (line 144 shown): src_flags = narrow | op_flags[op].src; If replaced with src_flags = 0, the error goes away. The error also gets resolved if #pragma optimize is removed, or if compiled as a debug build. I don't understand the LLVM/Clang code well enough to know for sure, but in researching this bug I came across the following possibly related bugs: https://bugs.llvm.org/show_bug.cgi?id=7334 https://bugs.llvm.org/show_bug.cgi?id=7353 https://bugs.llvm.org/show_bug.cgi?id=10992 -- 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 18663 in oss-fuzz: llvm:clang-objc-fuzzer: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #1 on issue 18663 by sheriff...@chromium.org: llvm:clang-objc-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18663#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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44631, which changed state. Bug 44631 Summary: Backport fix for evaluating %pcrel_lo against global and weak symbols https://bugs.llvm.org/show_bug.cgi?id=44631 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 44631] Backport fix for evaluating %pcrel_lo against global and weak symbols
https://bugs.llvm.org/show_bug.cgi?id=44631 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Cherry-picked in 8634a82910eba78279a69fcba0925d3a602a0563 and a3982a59ce34039f63fff35c6c0562cf6fd5c771. 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 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44633, which changed state. Bug 44633 Summary: Integrate [Clang] Fix expansion of response files in -Wp after integrated-cc1 change 68d7f06092e5 https://bugs.llvm.org/show_bug.cgi?id=44633 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 44633] Integrate [Clang] Fix expansion of response files in -Wp after integrated-cc1 change 68d7f06092e5
https://bugs.llvm.org/show_bug.cgi?id=44633 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Cherry-picked to 10.x in 85ee70e86456e3bcb3c706c404db497c5a448602 -- 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 20281 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 20281 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20281#c1 ClusterFuzz testcase 5748440663588864 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202001220540:202001230519 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44638] New: interleaved memory access blocking loop vectorization
https://bugs.llvm.org/show_bug.cgi?id=44638 Bug ID: 44638 Summary: interleaved memory access blocking loop vectorization Product: libraries Version: 7.0 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: w...@marvell.com CC: arnaud.degrandmai...@arm.com, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, ties.st...@arm.com Created attachment 23047 --> https://bugs.llvm.org/attachment.cgi?id=23047&action=edit The attached file shows the loop cannot be vectorized because of the high cost in interleaved memory access In loop vectorizer, LV, the decision to vectorize a loop is based on the cost of the vectorized loop. The cost is calculated on the each instruction in the loop. For interleaved access instruction group, there is one cost for the whole group. The cost is based on extract/insert model to implement the interleaved memory access. Usually, this group cost will be very high, especially on AArch64 which has has a VectorInsertExtractBaseCost set to 3 in AArch64Subtarget.h. This high cost usually will fail the loop to be vectorized. On AArch64, there are multiple ways to implement interleaved memory access without using the vector extract/insert model. For example, TBL instruction can be used to rearrange and dispatch data from a vector to form a new vector and it is a single one instruction cost. Also one use zip1/2, umull1/2, smull1/2 to do this same work instead of extract/insert model. ti reproduce this problem, compile the attched file with this command clang -mcpu=thunderx2t99 -march=armv8.1-a+lse -mllvm tbl3.c -ffast-math -ffp-contract=fast -funroll-loops -finline-functions -fslp-vectorize -fvectorize -O3 -o tbl3.out The problem exists in all llvm versions. -- 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 44634] New: opt -loop-vectorizer fails with Assertion `Ingredient2Recipe[I] != nullptr && "Ingredient doesn't have a recipe"' failed.
https://bugs.llvm.org/show_bug.cgi?id=44634 Bug ID: 44634 Summary: opt -loop-vectorizer fails with Assertion `Ingredient2Recipe[I] != nullptr && "Ingredient doesn't have a recipe"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 23046 --> https://bugs.llvm.org/attachment.cgi?id=23046&action=edit bbi-37904.ll reproducer opt -loop-vectorize -S -o - bbi-37904.ll hits an assertion opt: ../lib/Transforms/Vectorize/VPRecipeBuilder.h:91: llvm::VPRecipeBase *llvm::VPRecipeBuilder::getRecipe(llvm::Instruction *): Assertion `Ingredient2Recipe[I] != nullptr && "Ingredient doesn't have a recipe"' failed. Stack dump: 0. Program arguments: build-all-builtins/bin/opt -loop-vectorize -S -o - bbi-37904.ll 1. Running pass 'Function Pass Manager' on module 'bbi-37904.ll'. 2. Running pass 'Loop Vectorization' on function '@g' #0 0x03e7dcf4 PrintStackTraceSignalHandler(void*) (build-all-builtins/bin/opt+0x3e7dcf4) #1 0x03e7b8be llvm::sys::RunSignalHandlers() (build-all-builtins/bin/opt+0x3e7b8be) #2 0x03e7e0fc SignalHandler(int) (build-all-builtins/bin/opt+0x3e7e0fc) #3 0x7fce53a1a890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x7fce524c3e97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x7fce524c5801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #6 0x7fce524b539a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #7 0x7fce524b5412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #8 0x03fcad96 llvm::VPRecipeBuilder::getRecipe(llvm::Instruction*) (build-all-builtins/bin/opt+0x3fcad96) #9 0x03fc9483 llvm::LoopVectorizationPlanner::buildVPlanWithVPRecipes(llvm::VFRange&, llvm::SmallPtrSetImpl&, llvm::SmallPtrSetImpl&) (build-all-builtins/bin/opt+0x3fc9483) #10 0x03fc36af llvm::LoopVectorizationPlanner::buildVPlansWithVPRecipes(unsigned int, unsigned int) (build-all-builtins/bin/opt+0x3fc36af) #11 0x03fc2f02 llvm::LoopVectorizationPlanner::plan(unsigned int) (build-all-builtins/bin/opt+0x3fc2f02) #12 0x03fcdb56 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (build-all-builtins/bin/opt+0x3fcdb56) #13 0x03fd0b64 llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&, std::function&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (build-all-builtins/bin/opt+0x3fd0b64) #14 0x03fd5588 (anonymous namespace)::LoopVectorize::runOnFunction(llvm::Function&) (build-all-builtins/bin/opt+0x3fd5588) #15 0x036fefd3 llvm::FPPassManager::runOnFunction(llvm::Function&) (build-all-builtins/bin/opt+0x36fefd3) #16 0x036ff2b8 llvm::FPPassManager::runOnModule(llvm::Module&) (build-all-builtins/bin/opt+0x36ff2b8) #17 0x036ff91d llvm::legacy::PassManagerImpl::run(llvm::Module&) (build-all-builtins/bin/opt+0x36ff91d) #18 0x02095a93 main (build-all-builtins/bin/opt+0x2095a93) #19 0x7fce524a6b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #20 0x0207d02a _start (build-all-builtins/bin/opt+0x207d02a) Abort (core dumped) It starts failing with commit 9d24933f: Recommit f0c2a5a "[LV] Generalize conditions for sinking instrs for first order recurrences." -- 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 44633] New: Integrate [Clang] Fix expansion of response files in -Wp after integrated-cc1 change 68d7f06092e5
https://bugs.llvm.org/show_bug.cgi?id=44633 Bug ID: 44633 Summary: Integrate [Clang] Fix expansion of response files in -Wp after integrated-cc1 change 68d7f06092e5 Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: h...@chromium.org Reporter: alexandre.ga...@ubisoft.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 44555 Please integrate 68d7f06092e56b17eb0cddf560a9d9fe8afb7dd8 into 10.0 branch. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=44555 [Bug 44555] [meta] 10.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 44632] New: clang-format BWACS_MultiLine option not working with ForEachMacros
https://bugs.llvm.org/show_bug.cgi?id=44632
Bug ID: 44632
Summary: clang-format BWACS_MultiLine option not working with
ForEachMacros
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: vthibervi...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
If the BraceWrapping AfterControlStatement rule is set to MultiLine, this rule
is not correctly handled with ForEachMacros, and acts as if it was configured
as "Always" on these macros:
Here is a short example to reproduce:
Configuration:
```
---
BreakBeforeBraces: Custom
BraceWrapping:
AfterControlStatement: MultiLine
ColumnLimit: 30
ForEachMacros: ['for_macro']
```
Input file:
```
void bar(void) {
for (aaa; bbb && ccc && ddd; eee) {
foo();
}
for (a; b; c) {
foo();
}
for_macro (a, b, c) {
foo();
}
for_macro (aaa, bbb && ccc, ddd) {
foo();
}
}
```
Result:
```
void bar(void) {
for (aaa; bbb && ccc && ddd;
eee)
{
foo();
}
for (a; b; c) {
foo();
}
for_macro (a, b, c)
{
foo();
}
for_macro (aaa, bbb && ccc,
ddd)
{
foo();
}
}
```
Expected result is to get:
```
for_macro (a, b, c) {
foo();
}
```
for the first occurrence.
This is tested with clang-format version
10.0.0-++20200115115127+cbe681bd833-1~exp1~20200115105727.528
--
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 44631] New: Backport fix for evaluating %pcrel_lo against global and weak symbols
https://bugs.llvm.org/show_bug.cgi?id=44631 Bug ID: 44631 Summary: Backport fix for evaluating %pcrel_lo against global and weak symbols Product: new-bugs Version: 10.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: a...@lowrisc.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org https://reviews.llvm.org/D73211 is an important fix to a regression that affects building FreeRTOS, FreeBSD, and possibly other software stacks using LLVM. Please apply https://reviews.llvm.org/D73211 (3f5976c97dbf) and the follow-up lld test fix ddfe8751b16a to the release branch. -- 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 44630] New: ccc-analyzer.bat does not preserve quotes in its arguments
https://bugs.llvm.org/show_bug.cgi?id=44630 Bug ID: 44630 Summary: ccc-analyzer.bat does not preserve quotes in its arguments Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: c.schrei...@ibexinnovations.co.uk CC: dcough...@apple.com, llvm-bugs@lists.llvm.org I have been trying to run scan-build on one of our project usually built with Visual Studio. To run scan-build, I converted the project to CMake, used CMake to produce MinGW-MakeFiles, which I then compiled with "scan-build mingw32-make" (running from the mintty terminal shipped with Git, also called Git Bash). After a bit of trial and error, I managed to get it to run correctly, with one exception. Our Visual Studio project was setting a pre-processor variable as a string with quotes, and these quotes are meant to be part of the macro definition. The build command generated by CMake generates the associated pre-processor command as: c++-analyzer [...] -DMACRO_NAME=\"the string\" >From inside c++-analyzer.bat, when inspecting the command line arguments, I can see that the characters \" (backslash+quote) are still there, however the backslashes are lost when passing these command line arguments over to Perl. Therefore the quotes are no longer escaped, and down the line the C++ pre-processor only sees the string without the quotes, which then fails compilation. I don't think this is a problem with my make files, because the project compiles fine if I don't use scan-build. However, I managed to fix this by replacing the content of c++-analyzer.bat to: @echo off set v_params=%* set v_params=%v_params:\"=\\\"% perl -S c++-analyzer "%v_params%" This essentially replaces \" by \\\", escaping the backslash and the quote. I'm sure the correct fix would have to be more generic than this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44629] New: Alias template name rejected in explicit destructor call
https://bugs.llvm.org/show_bug.cgi?id=44629
Bug ID: 44629
Summary: Alias template name rejected in explicit destructor
call
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: pa...@osa.pri.ee
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Clang (all versions which I could try) reports a compile error on the explicit
destructor call line:
error: no member named 'B' in 'A'
(gcc and msvc accept this code).
template
class A {};
template
using B = A;
template
void foo(B* x) {
// Fails with error: no member named 'B' in 'A'
x->~B();
// workaround:
//using BT = B;
//x->~BT();
}
// instantiate foo()
template void foo(B* x);
int 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] [Bug 44628] New: Large increase in AMDGPU tblgen build times
https://bugs.llvm.org/show_bug.cgi?id=44628 Bug ID: 44628 Summary: Large increase in AMDGPU tblgen build times Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org, matthew.arsena...@amd.com Blocks: 28222 I've noticed -gen-dag-isel in particular seems to take a lot longer, and is by far the worst culprit in *gulp* debug tblgen builds Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=28222 [Bug 28222] llvm-tblgen is still too slow in the default debug build configuration -- 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 44320] SSAUpdater corrupts SCEV
https://bugs.llvm.org/show_bug.cgi?id=44320 Daniil Suchkov changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Daniil Suchkov --- Fixed by: commit 4a8dbc617d0b28ce2ce3e6856376b3802409554e Author: Daniil Suchkov Date: Tue Jan 21 12:21:53 2020 +0700 [SSAUpdater] Don't call ValueIsRAUWd upon single use replacement It is incorrect to call ValueHandleBase::ValueIsRAUWd when only one use is replaced since it simply violates semantics of the callback and leads to bugs like PR44320. Previously this call was used specifically to keep LICM's cache of AliasSetTrackers up to date across passes (as PR36801 showed, even for that purpose it didn't work properly), but since LICM doesn't have that cache anymore, we can safely remove this incorrect call with no repercussions. This patch fixes https://bugs.llvm.org/show_bug.cgi?id=44320 Reviewers: asbirlea, fhahn, efriedma, reames Reviewed-By: asbirlea Differential Revision: https://reviews.llvm.org/D73089 -- 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
