On Sat, Sep 28, 2019 at 02:27:40AM +0100, Ramsay Jones wrote: > > > On 28/09/2019 00:00, Luc Van Oostenryck wrote: > > On Fri, Sep 27, 2019 at 09:24:05PM +0100, Ramsay Jones wrote: > >> > >> > >> On 26/09/2019 21:33, Luc Van Oostenryck wrote: > >>> On Thu, Sep 26, 2019 at 07:50:27PM +0100, Ramsay Jones wrote: > >> [snip] > >>> Randy had the problem on llvm-3.8.0. > >>> > >>>> I haven't looked into the errors/warnings yet, but they seem to > >>>> relate to 'unknown/misused' pseudo-ops used for debug info. > >>> > >>> I really don't think it could be related to the last patch. > >>> I don't use or have access to cygwin but I've tested on Debian > >>> (bullseye/sid) with gcc-7 & gcc-9 and there wasn't any problem with > >>> llvm-8 (on Ubuntu I can only test with llvm-7). So, I'm curious to > >>> know more about this error you're seeing. > >> > >> I forgot to mention, in my previous email, that I was pretty > >> sure this was a platform specific issue, so I am not surprised > >> that you see no problem on Linux. > >> > >> So, tonight, I had a very quick look at the problem. If I use > >> gcc or clang to generate the assembler version of one of the > >> failing tests (backend/pointer-sub.c), then the pseudo-ops used > >> are appropriate for use with a 'coff-type' object file (ie a PE > >> file). However, the assembler produced by sparsec (saved from the > >> output of llc), would typically used in ELF object files ... > >> > >> After studying the output of 'clang -###', I noticed that clang > >> was passing (among other things) a 'triple' parameter to cc1. > >> However, the triple displayed by clang and llc were different: > >> > >> $ llc --version | head -5 > >> LLVM (http://llvm.org/): > >> LLVM version 8.0.1 > >> Optimized build. > >> Default target: x86_64-unknown-cygwin > >> Host CPU: haswell > >> $ clang --version > >> clang version 8.0.1 (tags/RELEASE_801/final) > >> Target: x86_64-unknown-windows-cygnus > >> Thread model: posix > >> InstalledDir: /usr/bin > >> $ > >> > >> I noticed that you could override the target triple used by llc, so > >> decided to give it a try: > >> > >> > >> $ git diff > >> diff --git a/sparsec b/sparsec > >> index bafe2da..8a056e7 100755 > >> --- a/sparsec > >> +++ b/sparsec > >> @@ -39,6 +39,7 @@ case "$(uname -s)" in > >> *CYGWIN*) > >> # cygwin uses the sjlj (setjmp-longjmp) exception model > >> LLC_ARCH_OPTS="-exception-model=sjlj" > >> + LLC_ARCH_OPTS="$LLC_ARCH_OPTS -mtriple=x86_64-unknown-windows-cygnus" > >> ;; > >> *) > >> ;; > >> $ > >> > >> This fixes the testsuite on cygwin! :-D > > > > Great! > > > > > > The defaut target triple is supposed to be determinated from the host triple > > but from what I've seen LLVM's config system seems to know only about > > x86_64-unknown-cygwin and nothing about *-*-windows-cygnus (config.guess). > > OTOH, the part related to code generation seems to only know about > > x86_64-unknown-windows-cygnus ... > > > > I suppose that `llvm-config --host-target` returns x86_64-unknown-cygwin ? > > Ah no, I had meant to mention this: > > $ llvm-config --host-target > x86_64-unknown-windows-cygnus > $ > > ... which agrees with clang, but not llc. Then the patch could simply be something like: + LLC_ARCH_OPTS="$LLC_ARCH_OPTS -mtriple=$(llvm-config --host-target)" but I'm not sure how this would behave with cygwin32 or when using -m32. Best regards, -- Luc"
