search for: forissi

...(and how clang 10.0.0 behaves). ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Sjoerd Meijer via llvm-dev <llvm-dev at lists.llvm.org> Sent: 01 June 2020 16:32 To: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Jerome Forissier <jerome at forissier.org> Cc: op-tee at lists.trustedfirmware.org <op-tee at lists.trustedfirmware.org> Subject: Re: [llvm-dev] Aarch64: unaligned access despite -mstrict-align Hi Jerome, > Note the 'ldr x9, [x0]'. At this point there is no guarantee that x0 is a multiple...

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char

...val = 1; } I would expect the main program to return 2, not 1. Last thing, if I define "val" as volatile, the programs behaves as expected. Are we in "unspecified, just don't do this" territory here? Thanks, -- Jerome > > On Thu, Jun 11, 2020 at 10:12 AM Jerome Forissier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I think that Clang erroneously discards a function annotated with >> __attribute__((constructor)) when flags -Os -fno-common are given. Test >> case below. >> >> What do you t...

> On Apr 28, 2020, at 9:03 AM, David Blaikie <dblaikie at gmail.com> wrote: > > What does llvm-dwarfdump tell you? > (particularly `--verify`) -- adrian

Hi, In a 32-bit ARM build, I am seeing the following warning (edited for simplicity, I can provide full logs if necessary): > llvm-objdump -l -d -x file.elf > llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf All object files and static libraries seem to have debug info (i.e., llvm-objdump does not complain when run on each file individually and

Hi, I think that Clang erroneously discards a function annotated with __attribute__((constructor)) when flags -Os -fno-common are given. Test case below. What do you think? Thanks. ----8<--------8<--------8<--------8<--------8<--------8<-------- $ cat ctor.c int val; static void __attribute__((constructor)) init_fn(void) { val = 1; } int main(int argc, char *argv[])