[llvm-bugs] [Bug 39416] New: Promote loop access to scalars (LICM) blocked by unrelated volatile access
https://bugs.llvm.org/show_bug.cgi?id=39416
Bug ID: 39416
Summary: Promote loop access to scalars (LICM) blocked by
unrelated volatile access
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: bruno-l...@defraine.net
CC: llvm-bugs@lists.llvm.org
Consider the following example:
extern int x;
extern volatile int v;
int f(int) __attribute__((const));
void test() {
for (int i = 0; i < 100; ++i) {
x = f(x);
v = 1;
}
}
Godbolt URL: https://godbolt.org/z/yZo4lj
I expect that LICM optimization would move the load/store of "x" outside of
this loop, but this seems blocked by the access to volatile "v".
Note that GCC does move the load/store of "x" outside of the loop.
While only a missed optimization, this is unexpected, because the optimization
is otherwise done (if you comment out the access to "v", which you would expect
to be unrelated, LICM does promote the accesses of "x" to scalars). Also, when
you unroll such a loop, LLVM can eliminate the redundant intermediate
load/store operations. Consider:
void test_unrolled() {
x = f(x);
v = 1;
x = f(x);
v = 1;
x = f(x);
v = 1;
}
Godbolt URL: https://godbolt.org/z/0Iwsno
This has only a single load and store of "x", respectively at the beginning and
end. So the optimization in case of the loop is certainly safe (or both GCC and
LLVM outside of a loop are wrong...).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39417] New: InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot check stride when folding tail"' failed.
https://bugs.llvm.org/show_bug.cgi?id=39417 Bug ID: 39417 Summary: InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot check stride when folding tail"' failed. Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: bjorn.a.petters...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 21030 --> https://bugs.llvm.org/attachment.cgi?id=21030&action=edit reduced reproducer With opt bbi-19959.ll -S -o - --loop-vectorize I hit a new assert that was added in the commit "[llvm] r344743 - [LV] Fold tail by masking to vectorize loops of arbitrary trip count under opt for size" opt: ../lib/Transforms/Vectorize/LoopVectorize.cpp:2519: void llvm::InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot check stride when folding tail"' failed. Stack dump: 0. Program arguments: build-all/bin/opt bbi-19959.ll -S -o - --loop-vectorize 1. Running pass 'Function Pass Manager' on module 'bbi-19959.ll'. 2. Running pass 'Loop Vectorization' on function '@func_34' build-all/bin/opt[0x218e074] build-all/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0x50)[0x218c1d0] build-all/bin/opt[0x218e3d8] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f4842f2f330] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f4841b1ec37] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f4841b22028] /lib/x86_64-linux-gnu/libc.so.6(+0x2fbf6)[0x7f4841b17bf6] /lib/x86_64-linux-gnu/libc.so.6(+0x2fca2)[0x7f4841b17ca2] build-all/bin/opt(_ZN4llvm19InnerLoopVectorizer14emitSCEVChecksEPNS_4LoopEPNS_10BasicBlockE+0x375)[0x22a3635] build-all/bin/opt(_ZN4llvm19InnerLoopVectorizer28createVectorizedLoopSkeletonEv+0x276)[0x22a3b26] build-all/bin/opt(_ZN4llvm24LoopVectorizationPlanner11executePlanERNS_19InnerLoopVectorizerEPNS_13DominatorTreeE+0x121)[0x22b9f21] build-all/bin/opt(_ZN4llvm17LoopVectorizePass11processLoopEPNS_4LoopE+0x367d)[0x22c40bd] build-all/bin/opt(_ZN4llvm17LoopVectorizePass7runImplERNS_8FunctionERNS_15ScalarEvolutionERNS_8LoopInfoERNS_19TargetTransformInfoERNS_13DominatorTreeERNS_18BlockFrequencyInfoEPNS_17TargetLibraryInfoERNS_12DemandedBitsERNS_9AAResultsERNS_15AssumptionCacheERSt8functionIFRKNS_14LoopAccessInfoERNS_4LoopEEERNS_25OptimizationRemarkEmitterE+0x1d7)[0x22c5dc7] build-all/bin/opt[0x22cdccb] build-all/bin/opt(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x1bd)[0x1bc0acd] build-all/bin/opt(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x28)[0x1bc0d88] build-all/bin/opt(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x30a)[0x1bc11ea] build-all/bin/opt(main+0x2964)[0x773734] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4841b09f45] build-all/bin/opt[0x75912d] Abort -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30908] [LLD] Support --fix-cortex-a53-843419 for AArch64
https://bugs.llvm.org/show_bug.cgi?id=30908 Peter Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Peter Smith --- The --fix-cortex-a53-843419 was implemented in LLD as part of https://reviews.llvm.org/D36749 r320800. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39418] New: Do not ICF two sections with different output sections when using linker scripts
https://bugs.llvm.org/show_bug.cgi?id=39418 Bug ID: 39418 Summary: Do not ICF two sections with different output sections when using linker scripts Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: anng...@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Created attachment 21031 --> https://bugs.llvm.org/attachment.cgi?id=21031&action=edit Test to reproduce the issue. Identical sections except for their output section should not be folded by ICF. This is already the case when there is no linker script, see r333052 (http://llvm.org/viewvc/llvm-project?view=revision&revision=333052). However, with linker scripts, ICF still folds such sections. The attached test, icf-output-section.s, reproduces this issue. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39419] New: hello world example linker error
https://bugs.llvm.org/show_bug.cgi?id=39419 Bug ID: 39419 Summary: hello world example linker error Product: new-bugs Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: xunlei...@sas.com CC: llvm-bugs@lists.llvm.org Hello, First time user of LLVM here. My environment is Ubuntu18.04 64-bit in VirtualBox. Host OS is Windows 10 professional. VirtualBox:~/tmp$ uname -a Linux VirtualBox 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux VirtualBox:~/tmp$ gcc --version gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 Ubuntu18.04 has LLVM 6.0.0 pre-installed. VirtualBox:~/tmp$ /usr/bin/clang --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin I followed the hello world example https://llvm.org/docs/GettingStarted.html#an-example-using-the-llvm-tool-chain till step 7 Assemble the native assembly language file into a program: % /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native # On Solaris % gcc hello.s -o hello.native # On others The failed message is " VirtualBox:~/tmp$ gcc hello.s -o hello.native /usr/bin/ld: /tmp/ccaIxQSy.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status " I then added -fPIC to "% clang -fPIC -O3 -emit-llvm hello.c -c -o hello.bc". However, it did not help. I then installed clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz. The same issue persists. Would you please help? Thanks a lot. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39420] New: Missed loop vectorization
https://bugs.llvm.org/show_bug.cgi?id=39420
Bug ID: 39420
Summary: Missed loop vectorization
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
We are unable to vectorize:
for (size_t i = 0; i < nrpt; i++) {
for (size_t j = 0; j < nsize; j++) {
a[j] = (float)0.0f;
}
for (size_t j = 0; j < nsize; j++) {
for (size_t k = 0; k < nsize; k++) {
a[j] += b[j] * c[j][k];
}
}
}
While GCC/ICC has no issues with this code. (-march=haswell)
Code example: https://godbolt.org/z/ooyf1N
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39422] New: Variable used by task is not made firstprivate by default as suggested by the Spec (end of section 2.15.1.1)
https://bugs.llvm.org/show_bug.cgi?id=39422
Bug ID: 39422
Summary: Variable used by task is not made firstprivate by
default as suggested by the Spec (end of section
2.15.1.1)
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: simone...@gmail.com
CC: a.bat...@hotmail.com, llvm-bugs@lists.llvm.org
Created attachment 21032
--> https://bugs.llvm.org/attachment.cgi?id=21032&action=edit
segfaults for missing firstprivate
The attached test that uses task inside a parallel region fails for segfaults.
The issue seems to be that the variable P is not being made threadprivate as it
is suggested in the Specification at the end of the section 2.15.1.1.
FROM THE SPEC
- In a task generating construct, if no default clause is present, a variable
for which the data-sharing attribute is not determined by the rules above and
that in the enclosing context is determined to be shared by all implicit tasks
bound to the current team is shared.
- In a task generating construct, if no default clause is present, a variable
for which the data-sharing attribute is not determined by the rules above is
firstprivate
FROM THE SPEC
The segfaults happens with both Clang 6.0 and 7.0. Compiling the test with GCC
and Intel Compiler does not result in an issue.
The behavior is also broken for private variables that have definitely no
dynamic storage duration (just to exclude that the pointer is the
problem):
int main() {
#pragma omp parallel num_threads(NUM_THREADS)
{
int P = omp_get_thread_num();
printf("%d: %d\n", omp_get_thread_num(), P);
#pragma omp task
{
#pragma omp critical
{
printf("%d: %d\n", omp_get_thread_num(), P);
P += 10;
}
}
#pragma omp barrier
printf("%d: %d\n", omp_get_thread_num(), P);
}
}
For firstprivate, the change of P should have no effect outside of the task,
but running the tests P gets affected also outside the task.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39366] LLVM IR generation of compound statement ('{}') crash
https://bugs.llvm.org/show_bug.cgi?id=39366 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alexey Bataev --- Fixed in r345177 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39423] New: Clang should implement -Wpadding in MSVC environments
https://bugs.llvm.org/show_bug.cgi?id=39423 Bug ID: 39423 Summary: Clang should implement -Wpadding in MSVC environments Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org A chromium user wanted it, but it doesn't work on Windows: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/wPr8JKbWX1k It's only implemented in the itanium record layout builder. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39424] New: Clang fails to generate code for C11 atomics being returned
https://bugs.llvm.org/show_bug.cgi?id=39424 Bug ID: 39424 Summary: Clang fails to generate code for C11 atomics being returned Product: clang Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: hugh.a.ga...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 21033 --> https://bugs.llvm.org/attachment.cgi?id=21033&action=edit An example program with the LLVM IR generated for each function Clang fails to generate any valid instructions when compiling any function which returns an atomic_load from an atomic which has been declared and initialized in that function. My attachment here is the code which demonstrates the issue, if needed. clang trunk on godbolt.org also seems to show this issue as well, https://godbolt.org/z/o9UCO3 for the same example as the attached file. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39425] New: [Sanitizers] SanitizerOrdinal is out of bits
https://bugs.llvm.org/show_bug.cgi?id=39425
Bug ID: 39425
Summary: [Sanitizers] SanitizerOrdinal is out of bits
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
Once https://reviews.llvm.org/D50250 lands,
the "enum SanitizerOrdinal : uint64_t {" will not have *any* free bits
available.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39424] Clang fails to generate code for C11 atomics being returned
https://bugs.llvm.org/show_bug.cgi?id=39424 Eli Friedman changed: What|Removed |Added Resolution|--- |INVALID CC||efrie...@codeaurora.org Status|NEW |RESOLVED --- Comment #1 from Eli Friedman --- Your code has undefined behavior; it's reading from an uninitialized variable. (Did you mean to write "atomic_int val;" instead of "atomic_int *val;"?) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39426] New: accept ill-formed typedef with not fully defined enum
https://bugs.llvm.org/show_bug.cgi?id=39426
Bug ID: 39426
Summary: accept ill-formed typedef with not fully defined enum
Product: clang
Version: 7.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: dushis...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
clang version 7.0.0 (tags/RELEASE_700/final) compiles such code without
any error:
$ cat > test.cpp
typedef enum FooEnum : int FooEnum;
enum FooEnum : int { A = 1, B };
$ clang++ -c -pedantic -std=c++11 test.cpp
$
while gcc (8.2.1) rejects it.
according to
https://stackoverflow.com/questions/52971159/strong-enum-typedef-clang-bug-or-c11-standard-uncertainty/52973516#52973516
[dcl.typedef]/1
The typedef specifier shall not be combined in a decl-specifier-seq with
any other kind of specifier except a defining-type-specifier,[...]
[dcl.type]/1
defining-type-specifier:
type-specifier
class-specifier
enum-specifier
[dcl.enum]/1
enum-specifier:
enum-head { enumerator-listopt }
enum-head { enumerator-list , }
So the code bellow is legal c++:
typedef enum FooEnum : int { A = 1, B } FooEnum;
but this one is not legal c++:
typedef enum FooEnum : int FooEnum;
Because enum FooEnum:int is not a defining-type-specifier.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 10988] x86 MC encoder and disassembler bugs umbrella
https://bugs.llvm.org/show_bug.cgi?id=10988 Bug 10988 depends on bug 36144, which changed state. Bug 36144 Summary: Operands of the form '0b' in jump instructions in X86 Intel dialect inline assembly are not recognised as valid. https://bugs.llvm.org/show_bug.cgi?id=36144 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36144] Operands of the form '0b' in jump instructions in X86 Intel dialect inline assembly are not recognised as valid.
https://bugs.llvm.org/show_bug.cgi?id=36144 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r345189 Status|NEW |RESOLVED --- Comment #5 from Reid Kleckner --- Fixed by r345189. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32973] The assembly parser eats trailing 'h' chars from macro arguments that start with a number
https://bugs.llvm.org/show_bug.cgi?id=32973 Reid Kleckner changed: What|Removed |Added Fixed By Commit(s)||r345189 CC||r...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Reid Kleckner --- Fixed by r345189. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38190] -fdebug-types-section unusable on macos
https://bugs.llvm.org/show_bug.cgi?id=38190 Jonas Devlieghere changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Jonas Devlieghere --- We put an error in place for clang in r337717. > clang-8: error: unsupported option '-fdebug-types-section' for target > 'x86_64-apple-macosx' There's also a commit that prevents this from happening in the backend but I couldn't immediately find the revision. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39419] hello world example linker error
https://bugs.llvm.org/show_bug.cgi?id=39419 Tim Northover changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||t.p.northo...@gmail.com --- Comment #2 from Tim Northover --- Yep, looks right to me. If you're linking a PIE executable (which your GCC seems to default to and is reasonably sensible) then all your object files need to be PIC. The way you do that on llc is via -relocation-model=pic. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11126 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::LookUpIdentifierInfo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Proj-llvm Reported-2018-10-25 Type: Bug New issue 11126 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::LookUpIdentifierInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11126 Detailed report: https://oss-fuzz.com/testcase?key=5730031452553216 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcc6790fc0 Crash State: clang::Preprocessor::LookUpIdentifierInfo clang::Lexer::LexIdentifier clang::Lexer::LexUnicode Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810160226:201810170227 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5730031452553216 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32370] -Wcomma does not play well with -std=c89
https://bugs.llvm.org/show_bug.cgi?id=32370 rtr...@google.com changed: What|Removed |Added CC||rtr...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from rtr...@google.com --- Fixed in r345228. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39427] New: gcc ABI incompatibility when passing llvm::Optional
https://bugs.llvm.org/show_bug.cgi?id=39427 Bug ID: 39427 Summary: gcc ABI incompatibility when passing llvm::Optional Product: clang Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: tneum...@users.sourceforge.net CC: llvm-bugs@lists.llvm.org Created attachment 21034 --> https://bugs.llvm.org/attachment.cgi?id=21034&action=edit ABI demonstration Calling llvm::ConstantExpr::getGetElementPtr crashes when LLVM 7 is compiled with gcc 8.2 and the caller is compiled with clang 7. The reason is an ABI incompatibility: clang wants to pass the llvm::Optional parameter by value (i.e., as a single i64), while gcc expects the value to be passed by reference. I have attached a simple test program that demonstrates the problem explicitly, regardless how the underlying LLVM was compiled. (It still uses the LLVM 7 headers, but the problem is triggered purely in the example code here). To reproduce, compile and run the attached program like this: clang++-7 -c -opart1.o foo.cpp `llvm-config-7 --cxxflags` g++ -c -opart2.cpp -DPART2 foo.cpp `llvm-config-7 --cxxflags` clang++-7 -ofoo part1.o part2.o `llvm-config-7 --cxxflags` ./foo This leads to a crash. Using either g++ or clang++ for both files is fine, but mixing them leads to a crash. By inspecting the assembler code we can see that clang++ passes by value, and g++ passes by reference. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
