[llvm-bugs] [Bug 35358] New: GlobalISel: Assertion `SizeInBits != 0 && "invalid zero-sized type"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35358
Bug ID: 35358
Summary: GlobalISel: Assertion `SizeInBits != 0 && "invalid
zero-sized type"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: kristof.be...@arm.com
CC: llvm-bugs@lists.llvm.org
$ cat small.ll
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64--linux-gnu"
%struct.T1 = type { float, %struct.T3 }
%struct.T3 = type {}
define %struct.T1 @fn1() {
entry:
%retval = alloca %struct.T1, align 4
%agg.tmp = alloca %struct.T1, align 4
%call = call %struct.T1 @fn1()
%0 = getelementptr inbounds %struct.T1, %struct.T1* %agg.tmp, i32 0, i32 0
%1 = extractvalue %struct.T1 %call, 0
store float %1, float* %0, align 4
%2 = getelementptr inbounds %struct.T1, %struct.T1* %agg.tmp, i32 0, i32 1
%3 = extractvalue %struct.T1 %call, 1
store %struct.T3 %3, %struct.T3* %2, align 4
%4 = load %struct.T1, %struct.T1* %retval, align 4
ret %struct.T1 %4
}
$ llc -global-isel small.ll
llc: /home/kribey01/dev/llvm.org/llvm/lib/CodeGen/LowLevelType.cpp:34:
llvm::LLT llvm::getLLTForType(llvm::Type &, const llvm::DataLayout &):
Assertion `SizeInBits != 0 && "invalid zero-sized type"' failed.
#0 0x02db5d54 PrintStackTraceSignalHandler(void*)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2db5d54)
#1 0x02db6076 SignalHandler(int)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2db6076)
#2 0x7f531a23b340 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10340)
#3 0x7f5318e1ecc9 gsignal
/build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x7f5318e220d8 abort
/build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0
#5 0x7f5318e17b86 __assert_fail_base
/build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0
#6 0x7f5318e17c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32)
#7 0x0246e6f5 llvm::getLLTForType(llvm::Type&, llvm::DataLayout const&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x246e6f5)
#8 0x02fea6b2 llvm::IRTranslator::getOrCreateVReg(llvm::Value const&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2fea6b2)
#9 0x02fed33d llvm::IRTranslator::translateExtractValue(llvm::User
const&, llvm::MachineIRBuilder&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2fed33d)
#10 0x02ff1de9 llvm::IRTranslator::translate(llvm::Instruction const&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2ff1de9)
#11 0x02ff2878
llvm::IRTranslator::runOnMachineFunction(llvm::MachineFunction&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x2ff2878)
#12 0x024c4174
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x24c4174)
#13 0x027c25bf llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x27c25bf)
#14 0x027c2813 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x27c2813)
#15 0x027c2d06 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x27c2d06)
#16 0x016aab62 compileModule(char**, llvm::LLVMContext&)
(/home/kribey01/dev/llvm.org/build/bin/llc+0x16aab62)
#17 0x016a817b main
(/home/kribey01/dev/llvm.org/build/bin/llc+0x16a817b)
#18 0x7f5318e09ec5 __libc_start_main
/build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:321:0
#19 0x016a7029 _start
(/home/kribey01/dev/llvm.org/build/bin/llc+0x16a7029)
Stack dump:
0. Program arguments: /home/kribey01/dev/llvm.org/build/bin/llc
-global-isel small.ll
1. Running pass 'Function Pass Manager' on module 'small.ll'.
2. Running pass 'IRTranslator' on function '@fn1'
Aborted (core dumped)
The C input that produced the above LLVM-IR is:
$ cat small.c
typedef struct {
} T3;
typedef struct {
float field0;
T3 field1
} T1;
T1 fn1() { fn1(); }
with clang command line:
clang --target=aarch64-linux-gnu -S small.c -emit-llvm -o small.ll
This was found by running the ABITest testing framework in clang's util
directory:
// ../ABITestGen.py --no-unsigned --no-vector --no-complex --no-bool --max-args
0 -o inputs/test.4874.a.c -T inputs/test.4874.b.c -D inputs/test.4874.driver.c
--min=4874 --count=1
// Generated: 2017-11-17 14:52
// Cardinality of function generator: inf
// Cardinality of type generator: inf
#include
#include
#include
typedef union T3 { } T3;
typedef struct T1 { float field0; T3 field1; } T1;
extern T1 T1_retval;
T1 fn4874(void);
static T1 T1_values[] = {
{ 0.0f, { } },
{ -1.0f, { } },
{ 1.0f, { } },
{ -1.0f, { } },
};
void test_fn4874(void) {
printf("fn4874: testing return.\n");
for (int i=0; i<4; ++i) {
T1 RV;
T1_retva
[llvm-bugs] [Bug 35359] New: [GlobalISel][AArch64] Calling convention for HFAs incorrect on big-endian targets
https://bugs.llvm.org/show_bug.cgi?id=35359
Bug ID: 35359
Summary: [GlobalISel][AArch64] Calling convention for HFAs
incorrect on big-endian targets
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: oliver.stann...@arm.com
CC: llvm-bugs@lists.llvm.org
Global-isel generates incorrect code when targeting big-endian AArch64 for this
code:
struct foo {
float first;
float second;
};
float get_first(foo p) {
return p.first;
}
This is the code that global-isel currently generates:
// /work/llvm/build/bin/clang --target=aarch64--none-eabi -march=armv8-a -c
callees.cpp -O0 -mllvm -global-isel=true -mllvm -global-isel-abort=0
-mbig-endian -o - -S
_Z9get_first3foo: // @_Z9get_first3foo
// BB#0:// %entry
sub sp, sp, #16 // =16
// implicit-def: %X8
fmovw9, s0
mov w10, w9
bfxil x8, x10, #0, #32
fmovw9, s1
mov w10, w9
bfi x8, x10, #32, #32
add x10, sp, #8 // =8
str x8, [sp, #8]
ldr w9, [x10]
fmovs0, w9
add sp, sp, #16 // =16
ret
When run on a big-endian target, this incorrectly returns the second member of
the struct, instead of the first.
--
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 35360] New: [GlobalISel][AArch64] Calling convention for vectors incorrect on big-endian targets
https://bugs.llvm.org/show_bug.cgi?id=35360
Bug ID: 35360
Summary: [GlobalISel][AArch64] Calling convention for vectors
incorrect on big-endian targets
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: oliver.stann...@arm.com
CC: llvm-bugs@lists.llvm.org
Global-isel generates incorrect code when targeting big-endian AArch64 for this
code:
#include
int32x2_t load_vector(int32x2_t *p) {
return *p;
}
Global-isel generates this:
// armclang --target=aarch64-arm-none-eabi -march=armv8-a -c callees.cpp -O0
-Wall -std=c++11 -mllvm -global-isel=true -mllvm -global-isel-abort=0
-mbig-endian -o - -S
_Z11load_vectorP11__Int32x2_t: // @_Z11load_vectorP11__Int32x2_t
// BB#0:// %entry
sub sp, sp, #16 // =16
str x0, [sp, #8]
ldr x0, [sp, #8]
ld1 { v0.2s }, [x0]
add sp, sp, #16 // =16
ret
With global-isel off, there is a rev64 instruction between the ld1 and the add,
which fixes up the endianness of the vector.
--
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 35361] New: [GlobalISel][AArch64] Calling convention for small arguments passed on stack incorrect on big-endian targets
https://bugs.llvm.org/show_bug.cgi?id=35361
Bug ID: 35361
Summary: [GlobalISel][AArch64] Calling convention for small
arguments passed on stack incorrect on big-endian
targets
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: GlobalISel
Assignee: unassignedb...@nondot.org
Reporter: oliver.stann...@arm.com
CC: llvm-bugs@lists.llvm.org
Global-isel generates incorrect code when targeting big-endian AArch64 for this
code:
int foo(int x0, int x1, int x2, int x3, int x4, int x5, int x6, int x7,
int stack1) {
return stack1;
}
int main() {
int ret = foo(0,1,2,3,4,5,6,7,8);
printf("%d\n", ret);
}
Global isel thinks that the incoming value of stack1 is stored in bytes [0,4)
above SP, but for big-endian targets this should be in bytes [4,8):
// /work/llvm/build/bin/clang --target=aarch64-arm-none-eabi -march=armv8-a -c
callees.cpp -O0 -Wall -std=c++11 -mllvm -global-isel=true -mllvm
-global-isel-abort=0 -mbig-endian -o - -S
_Z3fooi:// @_Z3fooi
// BB#0:// %entry
sub sp, sp, #48 // =48
ldr w8, [sp, #48] // <= Should be [sp, #52]
str w0, [sp, #44]
str w1, [sp, #40]
str w2, [sp, #36]
str w3, [sp, #32]
str w4, [sp, #28]
str w5, [sp, #24]
str w6, [sp, #20]
str w7, [sp, #16]
str w8, [sp, #12]
ldr w0, [sp, #12]
add sp, sp, #48 // =48
ret
--
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 35362] New: clang crashes at -O3 and above with polly: cannot handle void expression
https://bugs.llvm.org/show_bug.cgi?id=35362 Bug ID: 35362 Summary: clang crashes at -O3 and above with polly: cannot handle void expression Product: Polly Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org The hashtag for polly is c702e3805f3. Clang compiles. $ clang-trunk -v clang version 6.0.0 (trunk 318641) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -O3 abc.c abc.c:14:9: warning: expression result unused [-Wunused-value] *g ?: (d = b); ^ 1 warning generated. $ clang-trunk -O3 -mllvm -polly abc.c abc.c:14:9: warning: expression result unused [-Wunused-value] *g ?: (d = b); ^ /home/absozero/trunk/llvm/tools/polly/lib/External/isl/isl_ast_build_expr.c:1653: cannot handle void expression #0 0x02109b8a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2109b8a) #1 0x02107a2e llvm::sys::RunSignalHandlers() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2107a2e) #2 0x02107b82 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2107b82) #3 0x7f8543efe330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f8542a7bc37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f8542a7f028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x03d24f96 isl_handle_error (/home/absozero/trunk/root-clang/bin/clang-6.0+0x3d24f96) #7 0x03cfae6e isl_ast_build_expr_from_pw_aff_internal (/home/absozero/trunk/root-clang/bin/clang-6.0+0x3cfae6e) #8 0x03cfb040 isl_ast_build_from_multi_pw_aff_internal (/home/absozero/trunk/root-clang/bin/clang-6.0+0x3cfb040) #9 0x02810d68 IslNodeBuilder::createNewAccesses(polly::ScopStmt*, isl_ast_node*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2810d68) #10 0x02814060 IslNodeBuilder::createUser(isl_ast_node*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2814060) #11 0x02812cb8 IslNodeBuilder::createIf(isl_ast_node*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2812cb8) #12 0x028111b8 IslNodeBuilder::createBlock(isl_ast_node*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x28111b8) #13 0x027b2dc6 CodeGen(polly::Scop&, polly::IslAstInfo&, llvm::LoopInfo&, llvm::DominatorTree&, llvm::ScalarEvolution&, llvm::RegionInfo&) [clone .constprop.277] (/home/absozero/trunk/root-clang/bin/clang-6.0+0x27b2dc6) #14 0x0176b323 llvm::RGPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x176b323) #15 0x01c28903 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c28903) #16 0x01c289cc llvm::FPPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c289cc) #17 0x01c2849d llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c2849d) #18 0x022bff36 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x22bff36) #19 0x02aeb0c7 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2aeb0c7) #20 0x02ccbc18 clang::ParseAST(clang::Sema&, bool, bool) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2ccbc18) #21 0x02aea47c clang::CodeGenAction::ExecuteAction() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2aea47c) #22 0x0267681e clang::FrontendAction::Execute() (/home/absozero/trunk/root-clang/bin/clang-6.0+0x267681e) #23 0x02645b66 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x2645b66) #24 0x027097a3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0x27097a3) #25 0x00a593e8 cc1_main(llvm::ArrayRef, char const*, void*) (/home/absozero/trunk/root-clang/bin/clang-6.0+0xa593e8) #26 0x009d4d15 main (/home/absozero/trunk/root-clang/bin/clang-6.0+0x9d4d15) #27 0x7f8542a66f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0 #28 0x00a558f9 _start (/home/absozero/trunk/root-clang/bin/clang-6.0+0xa558f9) Stack dump: 0. Program arguments: /home/absozero/trunk/root-clang/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -
[llvm-bugs] Issue 3169 in oss-fuzz: llvm: ASSERT: RHS.U.VAL != 0 && "Divide by zero?"
Updates: Labels: Deadline-Approaching Comment #7 on issue 3169 by sheriff...@chromium.org: llvm: ASSERT: RHS.U.VAL != 0 && "Divide by zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3169#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3171 in oss-fuzz: llvm: ASSERT: RHS.U.VAL != 0 && "Divide by zero?"
Updates: Labels: Deadline-Approaching Comment #7 on issue 3171 by sheriff...@chromium.org: llvm: ASSERT: RHS.U.VAL != 0 && "Divide by zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3171#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3178 in oss-fuzz: llvm: ASSERT: !CodeSynthesisContexts.empty()
Updates: Labels: Deadline-Approaching Comment #7 on issue 3178 by sheriff...@chromium.org: llvm: ASSERT: !CodeSynthesisContexts.empty() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3178#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3168 in oss-fuzz: llvm: ASSERT: Access == AS_private || Access == AS_protected
Updates: Labels: Deadline-Approaching Comment #7 on issue 3168 by sheriff...@chromium.org: llvm: ASSERT: Access == AS_private || Access == AS_protected https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3168#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3194 in oss-fuzz: llvm: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #7 on issue 3194 by sheriff...@chromium.org: llvm: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3194#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3192 in oss-fuzz: llvm: ASSERT: Result.isInvalid() && "C++ binary operator overloading is missing candidates!"
Updates: Labels: Deadline-Approaching Comment #7 on issue 3192 by sheriff...@chromium.org: llvm: ASSERT: Result.isInvalid() && "C++ binary operator overloading is missing candidates!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3192#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3211 in oss-fuzz: llvm: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: Deadline-Approaching Comment #7 on issue 3211 by sheriff...@chromium.org: llvm: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3211#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3213 in oss-fuzz: llvm: ASSERT: !Prev.isAmbiguous() && "Cannot have an ambiguity in previous-declaration lookup"
Updates: Labels: Deadline-Approaching Comment #7 on issue 3213 by sheriff...@chromium.org: llvm: ASSERT: !Prev.isAmbiguous() && "Cannot have an ambiguity in previous-declaration lookup" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3213#c7 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 3195 in oss-fuzz: llvm: Direct-leak in clang::Parser::ParseParameterDeclarationClause
Updates: Labels: Deadline-Approaching Comment #8 on issue 3195 by sheriff...@chromium.org: llvm: Direct-leak in clang::Parser::ParseParameterDeclarationClause https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3195#c8 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35363] New: Incorrect order of evaluation for || somehow involving ! of _Bool
https://bugs.llvm.org/show_bug.cgi?id=35363
Bug ID: 35363
Summary: Incorrect order of evaluation for || somehow involving
! of _Bool
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: jsew...@acm.org
CC: llvm-bugs@lists.llvm.org
Incorrect order of evaluation for || somehow involving ! of _Bool
For the following input (in C)
void ff(void);
void gg(void);
_Bool hh(int*);
void test()
{
int a;
_Bool q = hh(&a);
if (!q || (a == 42))
ff();
else
gg();
}
"clang version 5.0.0 (tags/RELEASE_500/final) (llvm/tags/RELEASE_500/final
312553)" on x86_64-Linux, at -O and above, produces code that firsts tests
|a == 42| and only then |!q|:
test: # @test
.cfi_startproc
# BB#0:
pushq %rax
.Lcfi0:
.cfi_def_cfa_offset 16
leaq4(%rsp), %rdi
callq hh
cmpl$42, 4(%rsp)
je .LBB0_2
# BB#1:
testb %al, %al
je .LBB0_2
# BB#3:
callq gg
popq%rax
retq
.LBB0_2:
callq ff
popq%rax
retq
I don't see how it can justify comparing |a==42| before looking at the
return value from hh.
I notice also that it produces the "expected" order of tests (testb, then
cmpl) for either of the following changes:
* using |unsigned char| or |int| or |long| instead of |_Bool|
* changing the first term from |!q| to simply |q|
It's as if the compiler believes that ! of _Bool is undefined behavior in
C, so it can do what it likes. But I can't imagine why it would believe
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34519] No easy way to assemble a .s file as thumb (no .arm or .thumb directives in file)
https://bugs.llvm.org/show_bug.cgi?id=34519 Peter Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Peter Smith --- Committed in r318647 and r318648 -- 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 35365] New: ASAN on Windows dies on exception re-throw
https://bugs.llvm.org/show_bug.cgi?id=35365
Bug ID: 35365
Summary: ASAN on Windows dies on exception re-throw
Product: compiler-rt
Version: 5.0
Hardware: PC
OS: Windows XP
Status: NEW
Severity: enhancement
Priority: P
Component: compiler-rt
Assignee: unassignedb...@nondot.org
Reporter: steinar+l...@gunderson.no
CC: llvm-bugs@lists.llvm.org
Hi,
ASAN on Clang 5.0.0 on Windows seems not to handle exception rethrow properly;
it dies with a NULL pointer exception. A simple example (that uses a separate
helper function to do the rethrow, but it dies even without it, although in a
different and less helpful way):
#include
#include
void func()
{
throw std::runtime_error("hello, world");
}
void handle_rethrow()
{
try {
throw;
} catch (std::exception &e) {
std::cout << e.what() << std::endl;
}
}
int main(void)
{
try {
func();
} catch (...) {
handle_rethrow();
}
}
C:\Users\sgunders\source>cl /c /EHsc -fsanitize=address test.cpp
C:\Users\sgunders\source>"c:\Program Files\LLVM\bin\lld-link.exe" /out:test.exe
test.obj "c:\Program
Files\LLVM\lib\clang\5.0.0\lib\windows\clang_rt.asan_cxx-x86_64.lib"
"c:\Program Files\LLVM\lib\clang\5.0.0\lib\windows\clang_rt.asan-x86_64.lib"
C:\Users\sgunders\source>.\test.exe
=
==33004==ERROR: AddressSanitizer: access-violation on unknown address
0x (pc 0x7ff7413fb2d4 bp 0x002c886fd390 sp 0x002c886fad00 T0)
==33004==The signal is caused by a READ memory access.
==33004==Hint: address points to the zero page.
#0 0x7ff7413fb2d3 in _asan_test_only_reported_buggy_pointer+0xc982a3
(C:\Users\sgunders\source\test.exe+0x140cbb2d3)
#1 0x7ff74145258f in _asan_after_dynamic_init+0x243bf
(C:\Users\sgunders\source\test.exe+0x140d1258f)
#2 0x7ff741448327 in _asan_after_dynamic_init+0x1a157
(C:\Users\sgunders\source\test.exe+0x140d08327)
#3 0x7ffe6600a162 in RtlCaptureContext+0x3c2
(C:\Windows\SYSTEM32\ntdll.dll+0x1800aa162)
#4 0x7ff7413fb20a in _asan_test_only_reported_buggy_pointer+0xc981da
(C:\Users\sgunders\source\test.exe+0x140cbb20a)
#5 0x7ff7413fb3a2 in _asan_test_only_reported_buggy_pointer+0xc98372
(C:\Users\sgunders\source\test.exe+0x140cbb3a2)
#6 0x7ff74145258f in _asan_after_dynamic_init+0x243bf
(C:\Users\sgunders\source\test.exe+0x140d1258f)
#7 0x7ff741448327 in _asan_after_dynamic_init+0x1a157
(C:\Users\sgunders\source\test.exe+0x140d08327)
#8 0x7ffe6600a162 in RtlCaptureContext+0x3c2
(C:\Windows\SYSTEM32\ntdll.dll+0x1800aa162)
#9 0x7ff7413fb36d in _asan_test_only_reported_buggy_pointer+0xc9833d
(C:\Users\sgunders\source\test.exe+0x140cbb36d)
#10 0x7ff74143c6c4 in _asan_after_dynamic_init+0xe4f4
(C:\Users\sgunders\source\test.exe+0x140cfc6c4)
#11 0x7ffe636f8363 in BaseThreadInitThunk+0x13
(C:\Windows\System32\KERNEL32.DLL+0x180008363)
#12 0x7ffe65fc7090 in RtlUserThreadStart+0x20
(C:\Windows\SYSTEM32\ntdll.dll+0x180067090)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: access-violation
(C:\Users\sgunders\source\test.exe+0x140cbb2d3) in
_asan_test_only_reported_buggy_pointer+0xc982a3
==33004==ABORTING
The same code works without fault with ASAN on Linux, and without ASAN on
Windows.
--
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 35364] New: clang crashes with both "-mllvm -enable-newgvn" and "-mllvm -polly": Assertion `(TrackSubRegLiveness || V.RedefVNI) && "Instruction is reading nonexistent value"' failed.
https://bugs.llvm.org/show_bug.cgi?id=35364
Bug ID: 35364
Summary: clang crashes with both "-mllvm -enable-newgvn" and
"-mllvm -polly": Assertion `(TrackSubRegLiveness ||
V.RedefVNI) && "Instruction is reading nonexistent
value"' failed.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: helloqi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Either "clang-trunk -mllvm -enable-newgvn" or "clang-trunk -mllvm -polly" is
fine.
The hashtag for polly is c702e3805f3.
$ clang-trunk -v
clang version 6.0.0 (trunk 318641)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ clang-trunk -mllvm -polly -m32 -O3 abc.c
4 warnings generated.
$ clang-trunk -mllvm -enable-newgvn -m32 -O3 abc.c
4 warnings generated.
$ clang-trunk -mllvm -enable-newgvn -mllvm -polly -m32 -O3 abc.c
abc.c:18:11: warning: incompatible pointer types assigning to 'char *' from
'int *' [-Wincompatible-pointer-types]
k = &p1;
^ ~~~
abc.c:24:9: warning: incompatible pointer types assigning to 'char *' from
'short *' [-Wincompatible-pointer-types]
k = &l;
^ ~~
abc.c:27:11: warning: incompatible pointer types assigning to 'char *' from
'void (int)' [-Wincompatible-pointer-types]
j = fn1;
^ ~~~
abc.c:38:7: warning: incompatible pointer types assigning to 'int *' from 'long
long *' [-Wincompatible-pointer-types]
m = &f;
^ ~~
clang-6.0: /home/absozero/trunk/llvm/lib/CodeGen/RegisterCoalescer.cpp:2302:
{anonymous}::JoinVals::ConflictResolution
{anonymous}::JoinVals::analyzeValue(unsigned int, {anonymous}::JoinVals&):
Assertion `(TrackSubRegLiveness || V.RedefVNI) && "Instruction is reading
nonexistent value"' failed.
#0 0x02109b8a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x2109b8a)
#1 0x02107a2e llvm::sys::RunSignalHandlers()
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x2107a2e)
#2 0x02107b82 SignalHandler(int)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x2107b82)
#3 0x7fd866318330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x7fd864e95c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7fd864e99028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7fd864e8ebf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#7 0x7fd864e8eca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#8 0x019b271a (anonymous
namespace)::JoinVals::computeAssignment(unsigned int, (anonymous
namespace)::JoinVals&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x19b271a)
#9 0x019b27cb (anonymous namespace)::JoinVals::mapValues((anonymous
namespace)::JoinVals&) [clone .constprop.331]
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x19b27cb)
#10 0x019b3999 (anonymous
namespace)::RegisterCoalescer::joinVirtRegs(llvm::CoalescerPair&) [clone
.constprop.329] (/home/absozero/trunk/root-clang/bin/clang-6.0+0x19b3999)
#11 0x019b9132 (anonymous
namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&) [clone
.constprop.326] (/home/absozero/trunk/root-clang/bin/clang-6.0+0x19b9132)
#12 0x019bb54f (anonymous
namespace)::RegisterCoalescer::copyCoalesceWorkList(llvm::MutableArrayRef)
[clone .constprop.322]
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x19bb54f)
#13 0x019bb6eb (anonymous
namespace)::RegisterCoalescer::coalesceLocals() [clone .constprop.318]
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x19bb6eb)
#14 0x019bc322 (anonymous
namespace)::RegisterCoalescer::runOnMachineFunction(llvm::MachineFunction&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x19bc322)
#15 0x018e87bd
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x18e87bd)
#16 0x01c28903 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c28903)
#17 0x01c289cc llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c289cc)
#18 0x01c2849d llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x1c2849d)
#19 0x022bff75 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/home/absozero/trunk/root-clang/bin/clang-6.0+0x22bff75)
#20 0x02aeb0c7
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/h
[llvm-bugs] [Bug 35366] New: DAGCombiner: memory aliasing bug
https://bugs.llvm.org/show_bug.cgi?id=35366
Bug ID: 35366
Summary: DAGCombiner: memory aliasing bug
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19446
--> https://bugs.llvm.org/attachment.cgi?id=19446&action=edit
reduced testcase (llc input)
It seems that Csmith has hit some kind of bug relating to memory aliasing
during DAGCombining. The reduced c-function looks like:
/* --- GLOBAL VARIABLES --- */
static int32_t g_2 = 2;
static int32_t g_5 = -1;
static int32_t g_717 = 0;
static int64_t func_1(void)
{
g_5 = (g_5 & g_2);
if (g_5 != 1)
for (g_2 = 1; (g_2 > 0); --g_2)
return 0;
g_717 = 2;
return (g_5 + g_2 + g_717);
}
/* */
int main (int argc, char* argv[])
{
int print_hash_value = 0;
if (argc == 2 && strcmp(argv[1], "1") == 0) print_hash_value = 1;
platform_main_begin();
crc32_gentab();
func_1();
transparent_crc(g_2, "g_2", print_hash_value);
transparent_crc(g_717, "g_717", print_hash_value);
platform_main_end(crc32_context ^ 0xUL, print_hash_value);
return 0;
}
func_1() gets inlined into main(). Even though the static global variables are
32 bit signed integers, optimizations have turned g_2 and g_717 into i1
accesses. This is a bit hard for me to follow, but I have trusted sofar that
opt is doing something clever with the constants.
This is the compilers voting on the correct checksum (which also holds with the
reduced test case):
689C3C99: gcc -O0 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O1 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O0 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O1 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O0 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O0 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
D2A6FFDC: bin/clang -O3 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O3 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
-mllvm -disable-basicaa
The test case fails with clang at -O3 (from z10 and up), unless
-disable-basicaa is given.
The interesting block looks like this just before isel:
crc32_gentab.exit:
%44 = load i32, i32* @g_5, align 4, !tbaa !7
%.b1.i = load i1, i1* @g_2, align 4
%45 = select i1 %.b1.i, i32 1, i32 2
%and.i21 = and i32 %45, %44
store i32 %and.i21, i32* @g_5, align 4, !tbaa !7
%cmp.i = icmp eq i32 %and.i21, 1
# select of address for store.
%g_717.sink.i = select i1 %cmp.i, i1* @g_717, i1* @g_2
# store to either @g_717 or @g_2.
store i1 true, i1* %g_717.sink.i, align 4
# load @g_2
%.b = load i1, i1* @g_2, align 4
%conv44 = select i1 %.b, i64 1, i64 2
tail call fastcc void @transparent_crc ...
...
The diff of the .s files in the interesting block look like:
< disable-basicaa (good)
> (bad)
# BB#6: # BB#6:
# LoadAddress: @g_2 into %r2
larl%r2, g_2larl%r2, g_2
llc %r3, 0(%r2) llc %r3, 0(%r2)
lhi %r4, 2 lhi %r4, 2
chi %r3, 0 chi %r3, 0
larl%r1, g_5larl%r1, g_5
lochilh %r4, 1 lochilh %r4, 1
n %r4, 0(%r1) n %r4, 0(%r1)
# Load-Address: @g_717 into %r12
larl%r12, g_717 larl%r12, g_717
chi %r4, 1 chi %r4, 1
# Load-On-Condition of @g_717 into address (select implementation)
larl%r1, g_2 | locgre %r2, %r12
locgre %r1, %r12 | mvi 0(%r2), 1
# Move Immediate into @g_717 or @g_2
mvi 0(%r1), 1 <
# Load again @g_2 since MVI may store into it.
# - Missing in bad version with basicaa!
llc %r1, 0(%r2) <
lghi%r2, 2 lghi%r2, 2
chi %r1, 0| chi %r3, 0
llgfr %r13, %r0 llgfr %r13, %r0
strl%r4, g_5strl%r4, g_5
locghilh%r2, 1 locghilh%r2, 1
larl%r3, .L.str.1 larl%r3, .L.str.1
lgr %r4, %r13 lgr %r4, %r13
brasl %r14, transparent_crc brasl %r14, transparent_crc
...
The second llc of @g_2 is correctly chain
[llvm-bugs] [Bug 35367] New: Merge r318658 into the 5.0 branch: Fixed OMP doacross implementation on 32-bit platforms.
https://bugs.llvm.org/show_bug.cgi?id=35367 Bug ID: 35367 Summary: Merge r318658 into the 5.0 branch: Fixed OMP doacross implementation on 32-bit platforms. Product: OpenMP Version: unspecified Hardware: PC OS: All Status: ASSIGNED Severity: enhancement Priority: P Component: Runtime Library Assignee: andrey.churba...@intel.com Reporter: hah...@hahnjo.de CC: llvm-bugs@lists.llvm.org, mgo...@gentoo.org, tstel...@redhat.com Fixed OMP doacross implementation on 32-bit platforms. (This has been reported on 32bit Gentoo for 5.0.0 already.) https://reviews.llvm.org/rL318658 -- 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 34858] clang-cl crash with constexpr ctor
https://bugs.llvm.org/show_bug.cgi?id=34858 Nicolas Lesser changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Nicolas Lesser --- Actually, while it doesn't crash on Windows, it does so on Linux for some reason. Reopening. -- 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 35368] New: Clang-Format script for vim fails if a line range is given
https://bugs.llvm.org/show_bug.cgi?id=35368 Bug ID: 35368 Summary: Clang-Format script for vim fails if a line range is given Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: eyen...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Basically the following is executed from "/clang-format.py" if you define l:lines=59:72 before calling: ['clang-format', '-style', 'file', '-cursor', '1658', '6', '9', ':', '7', '2', '-assume-filename', '/tmp/foo.cpp'] but the correct command would be ['clang-format', '-style', 'file', '-cursor', '1658', '-lines', '68:72', '-assume-filename', '/tmp/foo.cpp'] Line 96 with "command += lines" is the culprit and has to be "command.extend(["-lines", lines])" It would be nice if someone can make a commit from this - I have had a look at the "Getting involved" pages but have no experience with svn / svn patch generation and am not willing to invest a lot of time for this one liner. For the next time - would it be better to send a message like this to one of the mailing lists or did I do the 'right' thing in opening a bug? Thank you for your hard work! :) -- 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 34664] variant uses "unsigned int" to store index, making it bigger than necessary
https://bugs.llvm.org/show_bug.cgi?id=34664 Eric Fiselier changed: What|Removed |Added Resolution|--- |FIXED CC||e...@efcs.ca Status|NEW |RESOLVED --- Comment #2 from Eric Fiselier --- Fixed in r318621. However, as @mclow noted: The change is ABI breaking, and therefore cannot and is not enabled by default. Only when ABI v2 is enabled, via _LIBCPP_UNSTABLE_ABI or otherwise, will the change come into effect. -- 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 35272] [AVX512] Assertion "Invalid sext node, dst < src!" in llvm::SelectionDAG::getNode()
https://bugs.llvm.org/show_bug.cgi?id=35272 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Craig Topper --- Should be fixed with r318706 -- 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 35369] New: LLD wasm: alignment assert + a segfault
https://bugs.llvm.org/show_bug.cgi?id=35369 Bug ID: 35369 Summary: LLD wasm: alignment assert + a segfault Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: llvm-bugs@lists.llvm.org Created attachment 19448 --> https://bugs.llvm.org/attachment.cgi?id=19448&action=edit test object file that fails I've experimented trying to integrate LLD into Rust's support for WebAssembly but unfortunately the "hello world" was generating a few asserts and segfaults in LLD. For reduction I've extracted just one object file on the linker line which reproduces the issue. If I execute: $ wasm-ld test.o -o test --allow-undefined it'll fail with: wasm-ld: /home/alex/code/llvm/include/llvm/Support/MathExtras.h:678: uint64_t llvm::alignTo(uint64_t, uint64_t, uint64_t): Assertion `Align != 0u && "Align can't be 0."' failed. I tried tracing in gdb and it looks like this is a case where the data section has an alignment of 0 (unsure why). I then attempted to apply a small patch [1] but then lld segfaulted right afterwards. Then I gave up and decided to open a bug! To be clear the object file here doesn't actually do anything useful. This was part of a much larger link line and this is just one object file reduced. If it's helpful I can provide all the various inputs as well! [1]: https://gist.github.com/alexcrichton/8f5ddc7778586011eabe58aa2e11baeb -- 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 35370] New: Cannot use object files with OrcJIT on MacOS
https://bugs.llvm.org/show_bug.cgi?id=35370 Bug ID: 35370 Summary: Cannot use object files with OrcJIT on MacOS Product: libraries Version: 5.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: 1101.deb...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19449 --> https://bugs.llvm.org/attachment.cgi?id=19449&action=edit JIT runner source code I made a simple JIT runner and now I am trying to feed it with an object file. When I attempt to run 'main' then it crashes. Even though it works just fine on Linux (tested on Ubuntu 16.04 32bit). I attach my simple JIT runner as a main.cpp. I built it using LLVM 5.0 official prebuilt binaries. I used the following command: clang++ `llvm-config --cxxflags` `llvm-config --libs` -lz -lncurses main.cpp -o jitter The I just built 'hello world' program: clang++ -c main.cpp And fed it to the jitter: ./jitter main.o This is the trace I obtained from lldb: * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x000100bd81a9 jitter`llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject, std::__1::shared_ptr, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr >, std::__1::shared_ptr)::'lambda'(std::__1::__list_iterator >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr > const&, std::__1::function)>::buildInitialSymbolTable(std::__1::shared_ptr > const&) + 41 frame #1: 0x000100bd8102 jitter`llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr >, std::__1::shared_ptr) + 226 frame #2: 0x000100bd7b43 jitter`main + 963 frame #3: 0x7fff8ad77235 libdyld.dylib`start + 1 -- 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 35371] New: [OrcJIT] Incorrect symbol resolution of libc function addresses on MacOS
https://bugs.llvm.org/show_bug.cgi?id=35371 Bug ID: 35371 Summary: [OrcJIT] Incorrect symbol resolution of libc function addresses on MacOS Product: libraries Version: 3.9 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: 1101.deb...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19450 --> https://bugs.llvm.org/attachment.cgi?id=19450&action=edit JIT runner source code (Related to https://bugs.llvm.org/show_bug.cgi?id=35370). I feed an object file to the ObjectLinkingLayer and the run the 'main' function that is defined in the object file. It works on Linux but does not on MacOS. On MacOS it simply crashes saying: error: memory read failed for 0x8af86200 After debugging, I discovered what leads to this behavior. The crash happens around this code: /// Disasm from LLDB 0x1035a9287: cmpl $0x1, -0x8(%rbp) 0x1035a928b: movl %eax, -0x24(%rbp) 0x1035a928e: jne0x1035a92b1 0x1035a9294: leaq -0x1190(%rip), %rdi 0x1035a929b: movb $0x0, %al 0x1035a929d: callq 0x8adf0180 This assembly corresponds to the following code extracted from the object file using otool (otool -tV main.o): /// Original code 0032 callq _printf 0037 cmpl $0x1, -0x8(%rbp) 003b movl %eax, -0x24(%rbp) 003e jne0x61 0044 leaq 0x160(%rip), %rdi ## literal pool for: "no test specified\n" 004b movb $0x0, %al 004d callq _printf After few iterations, I discovered that the instruction in the original code preceding the first instruction in the disassembled code from LLDB is always has something to do with a libc function. In fact, if I remove any such calls then everything works just fine. Also, it works correctly on Linux. Note: the code is working if I compile jit runner with address sanitizer enabled. Another note: I am not sure if it is the actual bug in the Orc itself or I am doing something wrong. I attach the JIT runner (main.cpp). I compiled it using the following command: clang++ `llvm-config --cxxflags` `llvm-config --libs` -lz -lncurses main.cpp -o jitter The I built simple 'hello world' program: clang++ -c main.cpp And fed it to the runner: ./jitter main.o P.S. I tried to reproduce it using LLVM 5.0 but hit another problem: https://bugs.llvm.org/show_bug.cgi?id=35370 -- 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 24204] integrated clang assembler reports "undefined temporary" with usage of undefined label
https://bugs.llvm.org/show_bug.cgi?id=24204 Konstantin Belochapka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Konstantin Belochapka --- Fixed in r265984 after fix, produces the following message: source1.s:3:9: error: directional label undefined jmp 1f ^ -- 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 35372] New: Crash in ARM backend for fmaxnum/fminnum
https://bugs.llvm.org/show_bug.cgi?id=35372 Bug ID: 35372 Summary: Crash in ARM backend for fmaxnum/fminnum Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: srhi...@google.com CC: kristof.be...@arm.com, llvm-bugs@lists.llvm.org, pir...@google.com Created attachment 19451 --> https://bugs.llvm.org/attachment.cgi?id=19451&action=edit reduced ll file The attached test case breaks for fmaxnum. We also tested a few variations in this source file. Changing the call to fminnum also will crash similarly. If we remove the fp-armv8 flag, then the bug goes away (but the new instructions aren't used either). There are also slightly different crashes if you change a constant value from -3.276800e+04 to -3.376800e+04, but it isn't obvious if this is just a different manifestation of the same bug. $ llc bugpoint-reduced-simplified.ll LLVM ERROR: Cannot select: t12: v4f32 = fmaxnum t22, undef:v4f32 t22: v4f32 = bitcast t21 t21: v4i32 = ARMISD::VMOVIMM TargetConstant:i32<1735> t20: i32 = TargetConstant<1735> t11: v4f32 = undef In function: _ZN7android11volumeMultiILi4ELi8EsffisEEvPT1_jPKT2_PT4_PKT3_T5_ -- 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
