[llvm-bugs] [Bug 47929] New: Missed vectorization for loop in which array elements with different offset are read after write
https://bugs.llvm.org/show_bug.cgi?id=47929
Bug ID: 47929
Summary: Missed vectorization for loop in which array elements
with different offset are read after write
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: hujiangp...@cn.fujitsu.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
For the following codes, main.c can't be vectorized, while main5.c can but a
little complicated. Form the C code level, there is no meaningful difference
between them, so why main.c can't be vectorized?
```main.c
#define LEN 100
float a[LEN], b[LEN], c[LEN], d[LEN];
int foo(void)
{
int ntimes = LEN;
for (int nl = 0; nl < ntimes; nl++) {
for (int i = 0; i < LEN-1; i++) {
a[i] *= c[i];
b[i] += a[i + 1] * d[i];
}
}
}
```
```main5.c
#define LEN 100
float a[LEN], b[LEN], c[LEN], d[LEN];
int foo(void)
{
int ntimes = LEN;
for (int nl = 0; nl < ntimes; nl++) {
for (int i = 0; i < LEN-1; i++) {
b[i] += a[i + 1] * d[i];
a[i] *= c[i];
}
}
}
```
```shell
# /home/build_llvm/LLVM1100rc1/llvm/build/bin/clang -Ofast -march=armv8.2-a
-Rpass-analysis=loop-vectorize -S -c ../main.c
../main.c:16:1: warning: non-void function does not return a value
[-Wreturn-type]
}
^
../main.c:11:24: remark: loop not vectorized: value that could not be
identified as reduction is used outside the loop
[-Rpass-analysis=loop-vectorize]
a[i] *= c[i];
^
../main.c:10:11: remark: loop not vectorized: unsafe dependent memory
operations in loop. Use #pragma loop distribute(enable) to allow loop
distribution to attempt to isolate the offending operations into a separate
loop [-Rpass-analysis=loop-vectorize]
for (int i = 0; i < LEN-1; i++) {
^
1 warning generated.
# /home/build_llvm/LLVM1100rc1/llvm/build/bin/clang -Ofast -march=armv8.2-a
-Rpass-analysis=loop-vectorize -S -c ../main5.c
../main5.c:16:1: warning: non-void function does not return a value
[-Wreturn-type]
}
^
../main5.c:10:11: remark: the cost-model indicates that interleaving is not
beneficial [-Rpass-analysis=loop-vectorize]
for (int i = 0; i < LEN-1; i++) {
^
1 warning generated.
```
Because that a[i+1] does not depend on a[i] *= c[i], I think it can be load in
a different vector register at the begin, then main.c will be vectorized too
and main5.c will be vectorized more efficiently. Why can't we do like that?
--
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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 47837, which changed state. Bug 47837 Summary: Clang rGc78da037783b segfaults when building an arm64 Linux kernel https://bugs.llvm.org/show_bug.cgi?id=47837 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 47837] Clang rGc78da037783b segfaults when building an arm64 Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=47837 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #9 from Jonas Paulsson --- 42a8286 -- 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 47863] ImmutableMapRef::Profile not compiling
https://bugs.llvm.org/show_bug.cgi?id=47863 Ádám Balogh changed: What|Removed |Added OS|Windows NT |All Severity|enhancement |release blocker Hardware|PC |All Status|NEW |RESOLVED Version|11.0|trunk Resolution|--- |FIXED Blocks|47800 | Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=47800 [Bug 47800] [meta] 11.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 47930] New: Merge a6336eab0c507b665dda63fa9db1292a2cdee409 into 11.0.1
https://bugs.llvm.org/show_bug.cgi?id=47930 Bug ID: 47930 Summary: Merge a6336eab0c507b665dda63fa9db1292a2cdee409 into 11.0.1 Product: libraries Version: 11.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: adam.bal...@ericsson.com CC: llvm-bugs@lists.llvm.org Please merge https://github.com/llvm/llvm-project/commit/a6336eab0c507b665dda63fa9db1292a2cdee409. [ADT] Fix for ImmutableMapRef -- 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 47931] New: initializer list {} fails for template instantiation + map + tuple +vector
https://bugs.llvm.org/show_bug.cgi?id=47931
Bug ID: 47931
Summary: initializer list {} fails for template instantiation +
map + tuple +vector
Product: clang
Version: 11.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: juanlucas...@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 24085
--> https://bugs.llvm.org/attachment.cgi?id=24085&action=edit
fail exemple
this is a pretty specific bug, probably due to the explicit instantiation:
when having an initialisation list for a std::map>> inside an explicitly
instantiated function, there is a failure of type:
Undefined symbols for architecture x86_64: std::__1::allocator >
>::~tuple()"
there is no reason why the attached code should fail to compile, and it
actually works on gcc.
note:
-remove the explicit instantiation and it works
-replace the vector by a simple type like int and it works
-remove the map and it works
I used "clang++ -std=c++17 ./clangbug.cpp"
sorry I'm new here let me know if anything else is needed
--
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 47932] New: Compilation error LLVM 11.0 with Windows 64-bit compiler
https://bugs.llvm.org/show_bug.cgi?id=47932 Bug ID: 47932 Summary: Compilation error LLVM 11.0 with Windows 64-bit compiler Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: albert.te...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I try to compile LLVM version 11.0 with 64-bit Windows compiler and I get: [ 72%] Building CXX object tools/clang/lib/ARCMigrate/CMakeFiles/obj.clangARCMigrate.dir/Transforms.cpp.obj Transforms.cpp E:\Programs\LLVM\11.0\llvm-project\clang\lib\ARCMigrate\Transforms.cpp : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj How to overcome this problem (or is it a bug)? Mote important information (as far as I can see) from cmake stage: cmake -G "NMake Makefiles" -DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra ..\llvm -- The C compiler identification is MSVC 19.16.27034.0 -- The CXX compiler identification is MSVC 19.16.27034.0 -- The ASM compiler identification is MSVC -- Found assembler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- Check for working C compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- Check for working C compiler: D:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works -- 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 47933] New: Assertion failure in WebAssemblyFastISel
https://bugs.llvm.org/show_bug.cgi?id=47933
Bug ID: 47933
Summary: Assertion failure in WebAssemblyFastISel
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: jjo...@quarkslab.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 24086
--> https://bugs.llvm.org/attachment.cgi?id=24086&action=edit
Output of the crash
When compiling the reduced test case below for the wasm32 target with
clang -target wasm32 -c test.ll -o /dev/null
Where test.ll is
target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
define private void @failing(i32 %0) {
entry:
%1 = alloca i8, i32 4
%2 = ptrtoint i8* %1 to i32
%3 = and i32 %2, 2
%4 = add i32 %2, %3
%5 = inttoptr i32 %4 to i32*
store i32 %0, i32* %5
ret void
}
```
Clang fails with the following message:
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp:76: void (anonymous
namespace)::WebAssemblyFastISel::Address::setReg(unsigned int): Assertion
`isRegBase() && "Invalid base register access!"' failed.
See the attached log for details.
--
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 47801] [RegisterScavenger] Spills dead register.
https://bugs.llvm.org/show_bug.cgi?id=47801 Jonas Paulsson changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonas Paulsson --- 1606755 -- 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 47934] New: Add debuginfo-tests to the list of projects that auto-subscribe llvm-commits
https://bugs.llvm.org/show_bug.cgi?id=47934 Bug ID: 47934 Summary: Add debuginfo-tests to the list of projects that auto-subscribe llvm-commits Product: Phabricator Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: paul_robin...@playstation.sony.com CC: llvm-bugs@lists.llvm.org A Phabricator review for a new debuginfo-tests tests (https://reviews.llvm.org/D89873) didn't automatically subscribe any of the -commits mailing lists. I suspect llvm-commits is the most reasonable one here. -- 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 47935] New: BPF: backport commit 31611721686760fe59c91a84b025e4dee94d1662
https://bugs.llvm.org/show_bug.cgi?id=47935 Bug ID: 47935 Summary: BPF: backport commit 31611721686760fe59c91a84b025e4dee94d1662 Product: new-bugs Version: 11.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ys114...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I would like to backport the following commit to llvm 11.0.1. commit 31611721686760fe59c91a84b025e4dee94d1662 (isel) Author: Yonghong Song Date: Wed Oct 7 16:24:33 2020 -0700 BPF: fix incorrect DAG2DAG load optimization Currently, bpf backend Instruction section DAG2DAG phase has an optimization to replace loading constant struct memeber or array element with direct values. The reason is that these locally defined struct or array variables may have their initial values stored in a readonly section and early bpf ecosystem is not able to handle such cases. ... This fixed a bug where wrong code could be generated. -- 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 22260 in oss-fuzz: llvm: Coverage build failure
Comment #21 on issue 22260 by ClusterFuzz-External: llvm: Coverage build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22260#c21 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-77ea7df1-3b42-45ef-9101-7a96e59f7f8c.txt -- 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 47936] New: AfterControlStatement: MultiLine breaks AllowShortFunctionsOnASingleLine
https://bugs.llvm.org/show_bug.cgi?id=47936
Bug ID: 47936
Summary: AfterControlStatement: MultiLine breaks
AllowShortFunctionsOnASingleLine
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: edas...@att.net
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Using the MultiLine setting for BraceWrapping.AfterControlStatement appears to
disable AllowShortFunctionsOnASingleLine, even in cases without any control
statements. For the input:
void bar() {}
class Foo {
void shortfunction() { bar(); }
};
The command:
clang-format --style="{BasedOnStyle: llvm, AllowShortFunctionsOnASingleLine:
Inline, BreakBeforeBraces: Custom, BraceWrapping: {AfterFunction: true,
AfterControlStatement: MultiLine}}"
produces:
void bar() {}
class Foo {
void shortfunction()
{
bar();
}
};
If MultiLine is replaced with Always or Never, or is left out entirely, we get:
void bar() {}
class Foo {
void shortfunction() { bar(); }
};
which is the expected result, as no control statements are present.
--
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 47277] Do not throw an error for calling a __host__ function from a __device__ function during host compilation
https://bugs.llvm.org/show_bug.cgi?id=47277 Artem Belevich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 47841] Template argument deduction not allowed in template parameter
https://bugs.llvm.org/show_bug.cgi?id=47841 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||e97e9851b227e98e39c27c4c8f5 ||558e331cde8b4 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] Issue 26569 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::sema::CapturingScopeInfo::addCapture
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-10-22 Type: Bug New issue 26569 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::sema::CapturingScopeInfo::addCapture https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26569 Detailed Report: https://oss-fuzz.com/testcase?key=5176092044034048 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fffa3f87cc8 Crash State: clang::sema::CapturingScopeInfo::addCapture clang::Sema::tryCaptureVariable MarkVarDeclODRUsed Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010190618:202010200603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5176092044034048 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 47757] getSizeInBits called on extended MVT
https://bugs.llvm.org/show_bug.cgi?id=47757 Tyler Mandry changed: What|Removed |Added Fixed By Commit(s)||184a13d362e041b1fcd14a5e782 ||ba0b17d13dc3c Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Tyler Mandry --- Took another look at this today. It does not reproduce on the latest 11.x branch. I was able to bisect the change down to the fix for https://bugs.llvm.org/show_bug.cgi?id=47619 which is the same bug. Thanks for your help. -- 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 47939] New: bug when setting the bss segment name in a Windows build, causes it to use executable space...
https://bugs.llvm.org/show_bug.cgi?id=47939
Bug ID: 47939
Summary: bug when setting the bss segment name in a Windows
build, causes it to use executable space...
Product: libraries
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: je...@radgametools.com
CC: llvm-bugs@lists.llvm.org
LLVM for Windows (just like visual studio), allows you to name the segments for
compilation with the following pragmas:
#pragma code_seg("mycodename")
#pragma data_seg("mydataname")
#pragma const_seg("myconstname")
#pragma bss_seg("mybssname")
This is convenient for middleware so that our customers can track what space
our products are using. We used this for around 20 years with the MS compiler.
LLVM handles this properly for the most part, however, if you set the BSS
segment name, if forgets that this is a BSS type segment, and then, when
linking, the executable will actually contain huge runs of zeros (rather than
just setting the segment type as zero initialized).
To test this, you should just be able to do #pragma bss_seg("test") followed by
a static char buf[1024*1024]; and see that the linked EXE is now 1 megabyte
larger.
I assume that in naming the segment, the segment type gets been lost, or that
somewhere LLVM is looking at the segment name, rather than the segment type to
decide how to create the final binary properly.
--
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 47941] New: "this requires expression will only be checked for syntactic validity" suggests bad fixit, is not emitted on equally dangerous code
https://bugs.llvm.org/show_bug.cgi?id=47941
Bug ID: 47941
Summary: "this requires expression will only be checked for
syntactic validity" suggests bad fixit, is not emitted
on equally dangerous code
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
// https://godbolt.org/z/hhWdzd
template
concept Foo = requires {
{ requires { sizeof(T)==0; } };
};
static_assert(Foo);
template
concept Bar = requires {
sizeof(T)==0;
};
static_assert(Bar);
template
concept Baz = requires {
requires requires { sizeof(T)==0; };
};
static_assert(Baz);
===
These are all correct C++20 behavior, but it's surprising that the
user-programmer can end up here by the usual "add/remove braces until the
compiler stops complaining" approach. Start with
template
concept Foo = requires {
requires { sizeof(T)==0 };
};
Clang complains:
:3:28: error: expected ';' at end of requirement
requires { sizeof(T)==0 };
^
;
:3:5: warning: this requires expression will only be checked for
syntactic validity; did you intend to place it in a nested requirement? (add
another 'requires' before the expression) [-Wrequires-expression]
requires { sizeof(T)==0 };
^
requires
That is, Clang is suggesting:
template
concept Foo = requires {
requires requires { sizeof(T)==0; };
};
(which, to be clear, ALSO does not do what the user intended!)
Or, we can throw braces around the whole thing instead, and Clang will be
equally satisfied:
template
concept Foo = requires {
{ requires { sizeof(T)==0; } };
};
Or, we can "cancel out" the two `requires requires` Clang suggested, and Clang
will be equally satisfied:
template
concept Foo = requires {
sizeof(T)==0;
};
Basically, I think Clang should continue to complain about all of these. The
only way to shut it up should be the universal signal, "redundant parentheses
around the condition."
template
concept Foo = requires {
((sizeof(T)==0)); // OK, I guess
(requires { sizeof(T)==0; }); // OK, I guess
};
The current diagnostics seem to be in a sour spot of moral hazard, where Clang
seems to be TRYING to help the user-programmer, but actually ignores a lot of
equally dangerous alternatives.
Is Clang clever enough to detect when the condition is guaranteed to be a
constant-expression for any T? e.g. sizeof(T)==0 is a constant-expression
regardless of T, because sizeof(T) is integral. When it's a constant
expression, I think the likelihood is high that the programmer intended to test
truthiness, not well-formedness.
Also notice that sizeof(T)==0 doesn't depend on any
requires-expression-parameters; that's an obvious difference between it and
e.g. `requires(T t) { sizeof(T)==t; }` (which arguably is clear enough in its
intent to test well-formedness instead of truthiness).
--
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 47940] New: -ffunction_sections not working on LLVM windows...
https://bugs.llvm.org/show_bug.cgi?id=47940
Bug ID: 47940
Summary: -ffunction_sections not working on LLVM windows...
Product: libraries
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: je...@radgametools.com
CC: llvm-bugs@lists.llvm.org
Even with -ffunction-sections on the command line, llvm on windows doesn't
split functions so that they can be independently stripped by the MS linker.
This is out at the OBJ level, after compiling, you can dissemble the obj, and
the functions aren't split into separate sections.
Easy to test, just add a:
void test()
{
__asm
{
nop
... 16K times or whatever
nop
}
}
And then build an exe - the exe will grow by 16K...
--
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
