[llvm-bugs] [Bug 37528] New: Miscompilation with intersegment jmp on Mac OsX
https://bugs.llvm.org/show_bug.cgi?id=37528
Bug ID: 37528
Summary: Miscompilation with intersegment jmp on Mac OsX
Product: new-bugs
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: valerakonyc...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hello. I'm making a special debugging/testing tool for my work. During this I
faced clang miscompilation bug on Mac OsX. If in source code there is a jmp
from .text section to others, the resulting executable file will be incorrect.
It's strange because the object file is correct.
I've gotten this bug with my standard Mac OsX compiler: Apple LLVM version
9.0.0 (clang-900.0.37). Also I had downloaded trunk(clang version 7.0.0 (trunk
332669)) and got this bug again.
I've checked behaviour of clang and gcc on Linux (Ubuntu 16.04) and everything
are fine: executable files are correct.
The simple way to reproduce the bug:
clang_jmp_test.c:
#include
int main () {
asm volatile(
"jmp 1f\n"
".section __TEXT,__my_sect, regular,pure_instructions\n"
"1: jmp 2f\n"
".text\n"
"2: nop\n");
printf("Hello world\n");
return 0;
}
After clang -c clang_jmp_test.c into the object file everything are fine:
clang_jmp_test.o:
_main:
55pushq %rbp
0001 48 89 e5 movq%rsp, %rbp
0004 48 83 ec 10 subq$0x10, %rsp
0008 c7 45 fc 00 00 00 00 movl$0x0, -0x4(%rbp)
000f e9 1c 00 00 00jmp 0x30 // right
0014 90nop
0015 48 8d 3d 19 00 00 00 leaq0x19(%rip), %rdi
001c b0 00 movb$0x0, %al
001e e8 00 00 00 00callq 0x23
0023 31 c9 xorl%ecx, %ecx
0025 89 45 f8 movl%eax, -0x8(%rbp)
0028 89 c8 movl%ecx, %eax
002a 48 83 c4 10 addq$0x10, %rsp
002e 5dpopq%rbp
002f c3retq
Contents of (__TEXT,__my_sect) section
0030 e9 14 00 00 00jmp 0x49 // with relocation right
Relocations in the clang_jmp_test.o are fine too:
RELOCATION RECORDS FOR [__text]:
001f X86_64_RELOC_BRANCH _printf
0018 X86_64_RELOC_SIGNED __cstring
0010 X86_64_RELOC_BRANCH __my_sect
RELOCATION RECORDS FOR [__my_sect]:
0001 X86_64_RELOC_BRANCH _main
But in the executable file jmp from .text section to __my_sect is wrong! and
there are no any relocations.
clang_jmp_test:
_main:
00010f40 55pushq %rbp
00010f41 48 89 e5 movq%rsp, %rbp
00010f44 48 83 ec 10 subq$0x10, %rsp
00010f48 c7 45 fc 00 00 00 00 movl$0x0, -0x4(%rbp)
00010f4f e9 18 00 00 00jmp 0x10f6c // wrong
00010f54 90nop
00010f55 48 8d 3d 3a 00 00 00 leaq0x3a(%rip), %rdi
00010f5c b0 00 movb$0x0, %al
00010f5e e8 13 00 00 00callq 0x10f76
00010f63 31 c9 xorl%ecx, %ecx
00010f65 89 45 f8 movl%eax, -0x8(%rbp)
00010f68 89 c8 movl%ecx, %eax
00010f6a 48 83 c4 10 addq$0x10, %rsp
00010f6e 5dpopq%rbp
00010f6f c3retq
Contents of (__TEXT,__my_sect) section
00010f70 e9 df ff ff ffjmp 0x10f54 // right
This problem is related to standard sections too. I've checked it with __data
section.
--
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 37529] New: Invalid "conflicting types for" in header
https://bugs.llvm.org/show_bug.cgi?id=37529
Bug ID: 37529
Summary: Invalid "conflicting types for" in header
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: et...@ethanhs.me
CC: llvm-bugs@lists.llvm.org
I'm working on porting CPython to work with clang-cl on Windows, so first off
thank you for clang-cl!
I've recently hit an edge case which MSC will compile, but clang will refuse to
compile.
Here is a minimal example that shows the issue:
// example.h
float difference(struct timeval *start, struct timeval *end);
// example.c
#include "example.h"
#include
float difference(struct timeval *start, struct timeval *end) {
return end->tv_sec - start->tv_sec;
}
Clang will report "conflicting types for 'difference'" which seems to be due to
the fact it assumes struct timeval in example.h references a new struct, which
is wrong.
I'd normally just move the include of Windows.h into example.h as a work
around, but this isn't always practical. In CPython, the real file is pytime.h,
which is included in Python.h, which is included in just about everthing...
I believe it isn't too uncommon for this pattern to exist, so it'd be great if
it were supported. 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37530] New: llvm-ar doesn't produce valid thin archives when combining multiple .a
https://bugs.llvm.org/show_bug.cgi?id=37530 Bug ID: 37530 Summary: llvm-ar doesn't produce valid thin archives when combining multiple .a Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: d...@golovin.in CC: llvm-bugs@lists.llvm.org Created attachment 20322 --> https://bugs.llvm.org/attachment.cgi?id=20322&action=edit resulting test2.a archive using llvm-ar The behavior of llvm-ar is not the same with GNU ar (from GNU binutils). To reproduce this: 1. create two empty objects: clang -c -x c /dev/null -o test1.o clang -c -x c /dev/null -o test2.o 2. archive the first object: llvm-ar rcSTD test1.a test1.o 3. archive the second object together with the first archive: llvm-ar rcsTD test2.a test2.o test1.a 4. check archive's contents: llvm-ar t test2.a Expected result: test2.o and test1.o are in the archive Actual result: test2.o and test1.a are in the archive If you use GNU ar instead of llvm-ar, you will get the expected result. -- 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 37531] New: Extreme compilation time degradation withof array of structs
https://bugs.llvm.org/show_bug.cgi?id=37531
Bug ID: 37531
Summary: Extreme compilation time degradation withof array of
structs
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: regression, slow-compile
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: v.reich...@netcologne.de
CC: llvm-bugs@lists.llvm.org
The following code snippet takes more than 2 minutes to compile
with just "-O" enabled:
===
struct A {};
struct S
{
void foo();
S(int, const A& = A()) { foo(); }
~S();
};
struct X
{
S s1, s2, s3, s4, s5;
};
// helper macros for one, ten and fifty initializers for X
#define ONE { 0, 0, 0, 0, 0 },
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define FIFTY TEN TEN TEN TEN TEN
static const X x[] = {
FIFTY
FIFTY
FIFTY
FIFTY
FIFTY
FIFTY
};
===
There seems to be some exponential compile time growth,
because the time almost doubles for every 50 additional
initializers:
50:1s
100:5s
150: 17s
200: 41s
250: 81s
300: 145s
350: 230s
This is a very recent regression on the trunk (appeared within
the last week or so). Previous versions (including 6.0.0)
compile the code in less than 3 seconds.
--
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 37527] MergeICmps crashes when compiling with -fno-builtin
https://bugs.llvm.org/show_bug.cgi?id=37527 Benjamin Kramer changed: What|Removed |Added CC||benny@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Benjamin Kramer --- https://reviews.llvm.org/rL332808 -- 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 37532] New: tests require FileCheck's deprecated overlapping CHECK-DAG
https://bugs.llvm.org/show_bug.cgi?id=37532
Bug ID: 37532
Summary: tests require FileCheck's deprecated overlapping
CHECK-DAG
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jdenny.o...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following patch changes FileCheck's CHECK-DAG directive not to permit
matches to overlap the matches of any preceding consecutive CHECK-DAG
directives:
https://reviews.llvm.org/D47106
However, that change breaks many existing tests, which are tracked by this
bugzilla issue.
That patch also implements the FileCheck command-line option
-allow-deprecated-dag-overlap, which reverts CHECK-DAG to the old overlapping
behavior. Before committing the above patch, we will add that option to the
broken tests. After committing, we will gradually adjust those tests for the
new behavior.
The list of unexpected test failures I'm seeing currently is below. You'll
notice I haven't yet cloned every LLVM repo, so there might be other unexpected
failures elsewhere.
Setup
-
The repos and base commits I'm testing:
$ find . -name .git -exec sh -c 'cd {}/.. && echo r`git svn find-rev @` `git
rev-parse @` {}' \;
r332809 06b38392dd60537b5d5732362f0ea8ec8dcea3d5 ./.git
r332775 2dc250081581f8dca5807819fbf4fed217f87ab5 ./tools/polly/.git
r332789 8daca416e4060dc49314744d23766e267d3dd919 ./tools/lld/.git
r332806 6b2fbf833d28a7e73f5728593cf6f9ba95cc2c24 ./tools/clang/.git
r332792 da054b1bc17dd4b6607aa9c8d7e66ff4d77d1308 ./projects/compiler-rt/.git
r332797 262632877b2d25065267b8641c3a083204636905 ./projects/libcxx/.git
r332495 abedd0661b48ab4541cd7fbbf68de130798c4b16 ./projects/openmp/.git
r332660 b9d870b66613fe18698e504ad78f3c7a98cb4a32 ./projects/test-suite/.git
r332767 e0330b61d74b898ee64922d0a3d50c3562f6ddb1 ./projects/libcxxabi/.git
llvm.git also includes the non-overlapping CHECK-DAG patch as of the
following version:
polly.git also includes the following patch to fix a break in the build:
diff --git a/lib/Support/RegisterPasses.cpp b/lib/Support/RegisterPasses.cpp
index 2ce0f63e..975ec574 100644
--- a/lib/Support/RegisterPasses.cpp
+++ b/lib/Support/RegisterPasses.cpp
@@ -706,7 +706,7 @@ void RegisterPollyPasses(PassBuilder &PB) {
} // namespace polly
// Plugin Entrypoint:
-extern "C" ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK
LLVM_PLUGIN_EXPORT
+extern "C" ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK
llvmGetPassPluginInfo() {
return {LLVM_PLUGIN_API_VERSION, "Polly", LLVM_VERSION_STRING,
polly::RegisterPollyPasses};
Results
---
ninja check-all gives the following summary of unexpected failures, of
which 101 are new. I have added asterisks in front of all failures
that are also present without the CHECK-DAG patch.
Failing Tests (110):
Clang :: CodeGen/dso-local-executable.c
Clang :: CodeGen/may-alias.c
Clang :: CodeGenCUDA/convergent.cu
Clang :: CodeGenCUDA/device-stub.cu
Clang :: CodeGenCXX/debug-info-line-if.cpp
Clang :: CodeGenCXX/dllexport.cpp
Clang :: CodeGenCXX/inline-hint.cpp
Clang :: CodeGenCXX/linetable-eh.cpp
Clang :: CodeGenCXX/mangle-ms-cxx14.cpp
Clang :: CodeGenCXX/regcall.cpp
Clang :: CodeGenCXX/runtime-dllstorage.cpp
Clang :: CodeGenObjC/dllstorage.m
Clang :: Driver/cuda-no-pgo-or-coverage.cu
Clang :: OpenMP/for_codegen.cpp
Clang :: OpenMP/for_reduction_codegen.cpp
Clang :: OpenMP/for_reduction_codegen_UDR.cpp
Clang :: OpenMP/sections_reduction_codegen.cpp
Clang :: OpenMP/target_map_codegen.cpp
Clang :: OpenMP/target_parallel_codegen.cpp
Clang :: OpenMP/target_parallel_for_codegen.cpp
Clang :: OpenMP/target_parallel_for_simd_codegen.cpp
Clang :: OpenMP/target_simd_codegen.cpp
Clang :: OpenMP/target_teams_codegen.cpp
Clang :: OpenMP/target_teams_distribute_codegen.cpp
Clang :: OpenMP/target_teams_distribute_firstprivate_codegen.cpp
Clang :: OpenMP/target_teams_distribute_parallel_for_private_codegen.cpp
Clang ::
OpenMP/target_teams_distribute_parallel_for_simd_private_codegen.cpp
Clang :: OpenMP/target_teams_distribute_private_codegen.cpp
Clang :: OpenMP/target_teams_distribute_simd_codegen.cpp
Clang :: OpenMP/target_teams_distribute_simd_firstprivate_codegen.cpp
Clang :: OpenMP/target_teams_distribute_simd_private_codegen.cpp
Clang :: OpenMP/teams_distribute_firstprivate_codegen.cpp
Clang :: OpenMP/teams_distribute_parallel_for_private_codegen.cpp
Clang :: OpenMP/teams_distribute_parallel_for_simd_private_codegen.cpp
Clang :: OpenMP/teams_distribute_private_codegen.cpp
Clang :: OpenMP/teams_distribute_simd_firstprivate_codegen.cpp
Clang :: OpenMP/teams_distribute_s
[llvm-bugs] Issue 8387 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-05-20 Type: Bug New issue 8387 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8387 Detailed report: https://oss-fuzz.com/testcase?key=5708181509505024 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::ValueHandleBase::ValueIsDeleted llvm::Value::~Value Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201805180726:201805190724 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5708181509505024 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] Issue 8388 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::ASTContext::getTypeInfo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-05-20 Type: Bug New issue 8388 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::ASTContext::getTypeInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8388 Detailed report: https://oss-fuzz.com/testcase?key=5198592229769216 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: 0x7ffc461acfd8 Crash State: clang::ASTContext::getTypeInfo clang::ASTContext::getIntWidth clang::IntegerLiteral::IntegerLiteral Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201805180726:201805190724 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5198592229769216 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] Issue 8391 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-05-20 Type: Bug New issue 8391 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8391 Detailed report: https://oss-fuzz.com/testcase?key=4660206704263168 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: 0x7ffc275c1af8 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711140614:201711141648 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4660206704263168 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
