[llvm-bugs] [Bug 48246] New: Clang can crash (or freeze) after static_assert() has failed
https://bugs.llvm.org/show_bug.cgi?id=48246
Bug ID: 48246
Summary: Clang can crash (or freeze) after static_assert() has
failed
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: rippe...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 24190
--> https://bugs.llvm.org/attachment.cgi?id=24190&action=edit
Contains autogenerated reproduction-7c6556.sh and reproduction-7c6556.cpp files
During my work on side-project, I've reproduced clang crashes which were
preceded by freeze of my PC machine (up to the point where I couldn't even move
my cursor). I've managed to find a minimal reproduction scenario by compiling
this code:
#include
#include
#include
int main() {
constexpr size_t x = 1;
constexpr size_t y = 2;
static_assert(x >= y, "|x| must not be smaller than |y|");
using type = std::void_t>;
return 0;
}
with a command like this:
clang++ -std=c++17 reproduction.cpp
which gives me this error:
reproduction.cpp:9:3: error: static_assert failed due to requirement 'x >= y'
"|x| must not be smaller than |y|"
static_assert(x >= y, "|x| must not be smaller than |y|");
^ ~~
clang: error: unable to execute command: Killed
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/reproduction-7c6556.cpp
clang: note: diagnostic msg: /tmp/reproduction-7c6556.sh
clang: note: diagnostic msg:
I've tested this on multiple clang versions and they all fail, on the other
hand GCC and ICC just report error and don't crash/freeze machine.
For the context in which I've found it - I was writing my own std::bind()-like
implementation which deduced number of function arguments and number of bounded
arguments and computed how many (and which ones) are left. In this case, the
bug reproduced if I provided more arguments for binding than the function took,
even though there were 2 static_asserts for this along the way.
As for the severity, I think that due to how it can freeze the machine and the
fact that some IDEs (e.g. QtCretor) use clang as a backend for understanding
code ("Clang Code Model") which constantly respawns after a crash leading to
complete machine freeze (nothing but to reboot, just by opening a file with
such code), the severity should be high.
Best regards,
Damian Dyńdo.
--
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 48247] New: vla var with typedef'd type has incomplete debug info
https://bugs.llvm.org/show_bug.cgi?id=48247
Bug ID: 48247
Summary: vla var with typedef'd type has incomplete debug info
Product: new-bugs
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vr...@gcc.gnu.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider test.c:
...
int n = 5;
int a = 1;
int
main (void)
{
#if V == 1
int vla[n];
#elif V == 2
typedef int vla_t[n];
vla_t vla;
#endif
for (int i = 0; i < n; i++)
vla[i] = i;
return vla[a];
}
...
With gcc, we print the correct type of vla in both V=1 and V=2 cases:
...
$ gcc test.c -g -DV=1
$ gdb -batch a.out -ex "b 17" -ex run -ex "ptype vla"
Breakpoint 1 at 0x400533: file test.c, line 17.
Breakpoint 1, main () at test.c:17
17return vla[a];
type = int [5]
$ gcc test.c -g -DV=2
$ gdb -batch a.out -ex "b 17" -ex run -ex "ptype vla"
Breakpoint 1 at 0x400533: file test.c, line 17.
Breakpoint 1, main () at test.c:17
17return vla[a];
type = int [5]
...
With clang-10, that's only for V=1:
...
$ clang test.c -g -DV=1
$ gdb -batch a.out -ex "b 17" -ex run -ex "ptype vla"
Breakpoint 1 at 0x40050e: file test.c, line 17.
Breakpoint 1, main () at test.c:17
17return vla[a];
type = int [5]
$ clang test.c -g -DV=2
$ gdb -batch a.out -ex "b 17" -ex run -ex "ptype vla"
Breakpoint 1 at 0x40050e: file test.c, line 17.
Breakpoint 1, main () at test.c:17
17return vla[a];
type = int []
...
With clang and V=2, the variable vla:
...
<2><147>: Abbrev Number: 6 (DW_TAG_variable)
<14c> DW_AT_name: (indirect string, offset: 0x21d): vla
<152> DW_AT_type: <0x172>
...
has type:
...
<2><172>: Abbrev Number: 9 (DW_TAG_typedef)
<173> DW_AT_type: <0x185>
<177> DW_AT_name: (indirect string, offset: 0x235): vla_t
...
which refers to type:
...
<1><185>: Abbrev Number: 10 (DW_TAG_array_type)
<186> DW_AT_type: <0x106>
<2><18a>: Abbrev Number: 11 (DW_TAG_subrange_type)
<18b> DW_AT_type: <0x190>
...
There's no DW_AT_count for the DW_TAG_subrange_type.
--
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 27715 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_vectorize
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 Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-21 Type: Bug New issue 27715 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_vectorize https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27715 Detailed Report: https://oss-fuzz.com/testcase?key=5724148105740288 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2560 MB) Crash Address: Crash State: llvm-opt-fuzzer--x86_64-loop_vectorize Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202005010248:202005020247 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5724148105740288 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27721 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->isRValue() && E->getType()->hasPointerRepresentation()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible OS-Linux Proj-llvm Engine-honggfuzz Reported-2020-11-21 Type: Bug New issue 27721 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: E->isRValue() && E->getType()->hasPointerRepresentation() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27721 Detailed Report: https://oss-fuzz.com/testcase?key=5083886962606080 Project: llvm Fuzzing Engine: honggfuzz Fuzz Target: clang-fuzzer Job Type: honggfuzz_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: E->isRValue() && E->getType()->hasPointerRepresentation() clang::StmtVisitorBase::Visit LValueExprEvaluator::VisitCompoundAssignOperator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=honggfuzz_asan_llvm&range=202006110252:202006121812 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5083886962606080 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 27722 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !VD->mightBeUsableInConstantExpressions(Info.Ctx)
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-2020-11-21 Type: Bug New issue 27722 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !VD->mightBeUsableInConstantExpressions(Info.Ctx) https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27722 Detailed Report: https://oss-fuzz.com/testcase?key=5516417939800064 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !VD->mightBeUsableInConstantExpressions(Info.Ctx) evaluateVarDeclInit LValueExprEvaluator::VisitVarDecl Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202007080155:202007092056 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5516417939800064 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 48248] New: Crash on win64 vectorcall with large
https://bugs.llvm.org/show_bug.cgi?id=48248
Bug ID: 48248
Summary: Crash on win64 vectorcall with large
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: christoffer.le...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
I found a possible bug in TargetInfo.cpp, WinX86_64ABIInfo::classify
On rows 4215-4216 we have the following:
} else if (IsReturnType) {
return ABIArgInfo::getExpand();
This would suggest that we use "Expand" as strategy for a return value on a
vector call. However, "Expand" is not a valid strategy for return values, as it
is only for parameters. Hoping to expose this bug, I created large vectors
embedded in structs, which would then hit the "homogenous aggregate" path in
said function.
I finally struck gold with the following:
typedef double foo __attribute__ ((vector_size (64)));
struct Test {
foo a[2];
};
struct Test __vectorcall bar(struct Test a) {
return (struct Test) {};
}
However I am not sure that I'm actually triggering the bug, or if there are
multiple bugs, as this only crashes when "struct Test a" is there, which makes
me suspect that maybe we're hitting some other bug here.
Godbolt link: https://www.godbolt.org/z/EWWaor
--
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 48249] New: LLVMCreateTypeAttribute is missing from LLVM-C API
https://bugs.llvm.org/show_bug.cgi?id=48249 Bug ID: 48249 Summary: LLVMCreateTypeAttribute is missing from LLVM-C API Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: christoffer.le...@gmail.com CC: llvm-bugs@lists.llvm.org >From the LLVM-C API it is possible to create string and enum attributes, however it still lacks support for type attributes, which makes it impossible to use byval attributes properly. This problem is also clearly documented: In LLVMCreateEnumAttribute it says: // After r362128, byval attributes need to have a type attribute. Provide a // NULL one until a proper API is added for this. This affects sret and byval. -- 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 45533] CUDA and OpenMP math functions conflicts (using both -xcuda and -fopenmp)
https://bugs.llvm.org/show_bug.cgi?id=45533 Anonymous User changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #7 from Anonymous User --- Thank you for this change! I have to report that it's partially working. It seems that __clang_cuda_complex_builtins.h is not updated with the rest of stuff in D78155. I.e. _OPENMP is not replaced by __OPENMP_NVPTX__ in that file. To validate, when I hardcodedly change it, then everything works... May I mark this as reopened? -- 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 48250] New: ICE in explicit instantiation of generic lambda operator()
https://bugs.llvm.org/show_bug.cgi?id=48250
Bug ID: 48250
Summary: ICE in explicit instantiation of generic lambda
operator()
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: ldalessan...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The index sequence seemed necessary to trigger the ICE.
> #include
>
> int main() {
> auto inner = []() { return 0; };
> auto outer = [&](std::index_sequence) {
> return inner.template operator()();
> };
> return outer(std::make_index_sequence<5>());
> }
https://godbolt.org/z/njK79P
--
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 25272 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 25272 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25272#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] Issue 25279 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: End.isValid() && "Macro expansion wasn't captured?"
Updates: Labels: Deadline-Approaching Comment #1 on issue 25279 by sheriffbot: llvm:clangd-fuzzer: ASSERT: End.isValid() && "Macro expansion wasn't captured?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25279#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] Issue 25289 in oss-fuzz: llvm:clang-fuzzer: ASSERT: (data().DefaultedCopyAssignmentIsDeleted || needsOverloadResolutionForCopyAssign
Updates: Labels: Deadline-Approaching Comment #1 on issue 25289 by sheriffbot: llvm:clang-fuzzer: ASSERT: (data().DefaultedCopyAssignmentIsDeleted || needsOverloadResolutionForCopyAssign https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25289#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 48251] New: clang-format -dump-config should dump all settings alphabetically
https://bugs.llvm.org/show_bug.cgi?id=48251 Bug ID: 48251 Summary: clang-format -dump-config should dump all settings alphabetically Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: legal...@xmission.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org The main use case for dumping the configuration is because you want to match all the settings to your existing in-house style and that isn't one of the existing canned styles. The reasonable way to do this is to run -dump-config in order to get all the settings and go through them one-by-one with the documentation open. The documentation lists all the settings in sorted order, but the settings aren't necessarily dumped out in sorted order when you run -dump-config. A small example: IndentCaseLabels: false IndentCaseBlocks: false IndentGotoLabels: true Now this isn't *wildly* out of sorted order, but some of the config settings have lengthy descriptions making you scroll back and forth and lose your place of which setting you were updating. It would be easier if clang-format emitted all settings in alphabetical order. Due to the nature of the YAML settings dump, it isn't feasible to just pipe the output into sort. -- 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 48252] New: Adding an operator== breaks implicit operator== generation from defaulted <=>
https://bugs.llvm.org/show_bug.cgi?id=48252
Bug ID: 48252
Summary: Adding an operator== breaks implicit operator==
generation from defaulted <=>
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Reduced example:
#include
struct X
{
auto operator<=>(X const&) const = default;
auto operator==(int i) const;
};
bool f(X x) {
return x == x;
}
clang trunk rejects this saying no matching candidate. The presence of the
unrelated operator== seems to prevent the generation of X::operator==(X const&)
const from the defaulted <=>.
--
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 45533] CUDA and OpenMP math functions conflicts (using both -xcuda and -fopenmp)
https://bugs.llvm.org/show_bug.cgi?id=45533 Johannes Doerfert changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #8 from Johannes Doerfert --- (In reply to Anonymous User from comment #7) > Thank you for this change! > > I have to report that it's partially working. > > It seems that __clang_cuda_complex_builtins.h is not updated with the rest > of stuff in D78155. I.e. _OPENMP is not replaced by __OPENMP_NVPTX__ in that > file. > > To validate, when I hardcodedly change it, then everything works... > > May I mark this as reopened? Closed it, PR48014 was taking care of the complex headers. Feel free to reopen if that was not the case. Though PR48014 is not cherry picked into the release branch yet. -- 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 48253] New: clang-format doesn't respect BreakConstructorInitializers setting
https://bugs.llvm.org/show_bug.cgi?id=48253
Bug ID: 48253
Summary: clang-format doesn't respect
BreakConstructorInitializers setting
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: legal...@xmission.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Created attachment 24193
--> https://bugs.llvm.org/attachment.cgi?id=24193&action=edit
.clang-format
The "BeforeColon" setting of BreakConstructorInitializers is described in 11.0
documentation as inserting a line break before the colon of an
initializer list, but this isn't working. Example transcript below.
Source code used in this test is on github at
https://github.com/legalizeadulthood/refactor-test-suite
commit 1cf5c07c500907817caf769a612a67b744f76e5b
D:\legalize\refactor-test-suite\src\RefactorTest
> clang-format --version
clang-format version 11.0.0
D:\legalize\refactor-test-suite\src\RefactorTest
> clang-format -i AddOverride.cpp
D:\legalize\refactor-test-suite\src\RefactorTest
> git diff AddOverride.cpp
diff --git a/RefactorTest/AddOverride.cpp b/RefactorTest/AddOverride.cpp
index 998ac2c..8fb96e7 100644
--- a/RefactorTest/AddOverride.cpp
+++ b/RefactorTest/AddOverride.cpp
@@ -8,7 +8,9 @@
class Interface
{
public:
-virtual ~Interface() { }
+virtual ~Interface()
+{
+}
virtual void Method() = 0;
@@ -20,11 +22,13 @@ public:
class Implementation : public Interface
{
public:
-Implementation()
-: value_(0)
-{ }
+Implementation() : value_(0)
+{
+}
-virtual ~Implementation() { }
+virtual ~Implementation()
+{
+}
// #TEST#: AO1 Add override
virtual void Method()
@@ -56,13 +60,13 @@ private:
class AbstractImplementation : public Interface
{
public:
-AbstractImplementation()
-: value_(0)
+AbstractImplementation() : value_(0)
{
}
virtual ~AbstractImplementation()
-{}
+{
+}
virtual int Getter() const override
{
@@ -81,12 +85,13 @@ private:
class DerivedImplementation : public AbstractImplementation
{
public:
-DerivedImplementation()
-: AbstractImplementation()
-{}
+DerivedImplementation() : AbstractImplementation()
+{
D:\legalize\refactor-test-suite\src\RefactorTest
> find "BreakConstructorInitializers" ..\.clang-format
-- ..\.CLANG-FORMAT
BreakConstructorInitializers: BeforeColon
D:\legalize\refactor-test-suite\src\RefactorTest
>
--
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 27748 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::PushBlockScope
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-11-22 Type: Bug New issue 27748 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::PushBlockScope https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27748 Detailed Report: https://oss-fuzz.com/testcase?key=5634876472295424 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe87dc2ff8 Crash State: clang::Sema::PushBlockScope clang::Sema::ActOnBlockStart clang::Parser::ParseBlockLiteralExpression Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011190626:202011200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5634876472295424 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 48254] New: Various programs fail in ~SmallVectorImpl with Visual Studio
https://bugs.llvm.org/show_bug.cgi?id=48254 Bug ID: 48254 Summary: Various programs fail in ~SmallVectorImpl with Visual Studio Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: p...@windfall.com CC: llvm-bugs@lists.llvm.org Created attachment 24194 --> https://bugs.llvm.org/attachment.cgi?id=24194&action=edit First half of traceback I apologize for submitting this bug again, but I cannot find my original submission and do not know its status. Various programs compiled and linked with Visual Studio 2019 16.8.1 on Windows 7 fail in ~SmallVectorImpl. One example is TableGenTests.exe, the unit tests for TableGen. I have attached two screen captures showing the traceback for a different program. -- 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 48255] New: [AArch64] Using ".byte" from asm in a switch statement causes bad jump table
https://bugs.llvm.org/show_bug.cgi?id=48255 Bug ID: 48255 Summary: [AArch64] Using ".byte" from asm in a switch statement causes bad jump table Product: clang Version: trunk Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: myriac...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 24196 --> https://bugs.llvm.org/attachment.cgi?id=24196&action=edit Compile me with -O2 on ARM64 If you use .byte from within an ARM64 "asm" block to exceed 4 bytes per line, a "switch" statement could generate a bad jump table, causing unpredictable behavior. This happens with -O1 and higher, but is more likely with -O2 and higher. https://gcc.godbolt.org/z/bGdqb3 The correct output is 1 (i.e. 15 - 14), but instead it prints 29 on ARM64 with -O2 because the CPU ends up riding the NOP sled. What happens is that LLVM with -O2 or higher will use a byte-sized table to store a count of instructions to skip for that entry of the jump table. When LLVM inlines Meow, this exceeds the values that can be stored in this jump table, truncating the jump distance to a byte. -- 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 48256] New: clang-format Allman brace style joins } with while keyword in do/while loop
https://bugs.llvm.org/show_bug.cgi?id=48256
Bug ID: 48256
Summary: clang-format Allman brace style joins } with while
keyword in do/while loop
Product: clang
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: legal...@xmission.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Created attachment 24197
--> https://bugs.llvm.org/attachment.cgi?id=24197&action=edit
.clang-format
A do/while loop in Allman brace style should be written like this:
do
{
loopBody();
}
while (cond);
clang-format joins the brace and the while line, giving this:
} while (cond);
This isn't Allman brace style, which has every opening and closing brace
on it's own line at the same indent level as the enclosing scope of the
control statement.
--
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 48257] New: vget_lane_p64 triggers -Wvector-conversion diagnostic
https://bugs.llvm.org/show_bug.cgi?id=48257
Bug ID: 48257
Summary: vget_lane_p64 triggers -Wvector-conversion diagnostic
Product: new-bugs
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: cl...@evan.coeusgroup.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
vget_lane_p64 is defined in arm_neon.h as:
#define vget_lane_p64(__p0, __p1) __extension__ ({ \
poly64x1_t __s0 = __p0; \
poly64_t __ret; \
__ret = (poly64_t) __builtin_neon_vget_lane_i64((poly64x1_t)__s0, __p1); \
__ret; \
})
Note the cast on the first argument to __builtin_neon_vget_lane_i64;
vget_lane_i64 takes an int64x1_t, not a poly64x1_t, so code which calls this
macro ends up emitting a -Wvector-conversion diagnostic:
error: incompatible vector types passing 'poly64x1_t' (vector of 1 'poly64_t'
value) to parameter of type '__attribute__((__vector_size__(1 * sizeof(long
long' (vector of 1 'long' value) [-Werror,-Wvector-conversion]
For an example, you can use:
#include
poly64_t foo (poly64x1_t v);
poly64_t
foo (poly64x1_t v) {
return vget_lane_p64(v, 0);
}
Or, on Compiler Explorer: https://godbolt.org/z/GWf6fq
It looks like this is a problem on all the vget*_lane_p64 functions.
--
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
