similar to: [LLVMdev] Reporting errors in inline assembly

On Jul 1, 2011, at 4:08 PM, Jakob Stoklund Olesen wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal error: error in backend: Inline

I want to report a problem with an inline assembly instruction from a code generator pass? How can I do that with the proper diagnostic format and source location? Right now we only get: clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c fatal error: error in backend: Inline asm output regs must be last on the x87 stack But gcc-4-2 can: $ gcc-4.2 -c

On Fri, Jul 1, 2011 at 4:09 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal

On Jan 18, 2012, at 8:56 PM, Joe Groff wrote: > 2012/1/18 Jakob Stoklund Olesen <stoklund at 2pi.dk>: >> This should work: >> %1 = call i64 asm "call __ftol2", "=A,{st},~{dirflag},~{fpsr},~{flags},~{st}" (double %x) nounwind > > Forgive me for being slow, but what would be the best way to implement > the equivalent of that inline asm as a custom

2012/1/19 Jakob Stoklund Olesen <stoklund at 2pi.dk>: > How many of these libcalls do you need to implement? What exactly is the calling convention? Which registers are clobbered etc. There is only one (that I know about so far). The MSVCRT `_ftol2` function implements floating-point-to-unsigned conversion for i386 targets, and LLVM 3.0 calls it with the cdecl calling convention for

Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT routine _ftol2 for floating-point to unsigned conversions, but this function has a nonstandard calling convention LLVM doesn't understand. It takes its input operand on the x87 stack as ST0, which it pops off of the stack before returning. The return value is given in EDX:EAX. In effect, I need to call it like this: %1 = call

On Sun, 03 Jun 2012 12:12:06 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > If I may add my two cents: > > > > I am planning to use LLVM as the backend for a compiler I am > > working on. And I wholeheartedly agree with Justin that it is a > > problem, if LLVM is allowed to freely

On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> On Sun, 03 Jun 2012 12:12:06 -0700 >> Chris Lattner <clattner at apple.com> wrote: >> >> > >> > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: >> >

You may find it helpful to reference http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html. In particular, the information regarding clobbers and constraints. Generally speaking, it's best not to use inline assembly at all. What are you trying to do that you find it necessary? On Mar 16, 2010, at 12:30 AM, Fred / Kettch wrote: > Hi, > > I recently switched to LLVM-GCC

Hi, I recently switched to LLVM-GCC 4.2 on OS X, to go around a bug caused by gcc with optimized code. Unfortunately, I ran into another weird problem on LLVM-GCC. In my code, there's a file with a bunch of inline assembly blocks, that worked fine with GCC 4.2. Now, when compiling with LLVM-GCC 4.2, weird things happen. Here's an example: (the blocks are larger than that, but a single

On Jan 19, 2012, at 10:12 AM, Joe Groff wrote: > 2012/1/19 Jakob Stoklund Olesen <stoklund at 2pi.dk>: >> How many of these libcalls do you need to implement? What exactly is the calling convention? Which registers are clobbered etc. > > There is only one (that I know about so far). The MSVCRT `_ftol2` > function implements floating-point-to-unsigned conversion for i386

On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Sun, 03 Jun 2012 12:12:06 -0700 > Chris Lattner <clattner at apple.com> wrote: > > > > > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote: > > > > > If I may add my two cents: > > > > > > I am planning to use LLVM as the backend for a compiler I am >

On Jan 24, 2012, at 2:30 PM, Joe Groff wrote: > On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> X86FloatingPoint.cpp with comments is all you get. > > Thanks for your help, Jakob. Attached is a first-pass attempt at a > patch. I don't want to post to -commits yet because I have no idea if > this is fully correct, but it seems

On Mon, Jun 4, 2012 at 11:46 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Sun, Jun 3, 2012 at 7:12 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >> On Sun, 03 Jun 2012 12:12:06 -0700 > >> Chris Lattner <clattner at apple.com>

I've run the tests from clang-tests/trunk/gcc-4_2-testsuite on a Ubuntu x86-64 Linux box with the following results: === gcc Summary === # of expected passes 29946 # of unexpected failures 9938 # of unexpected successes 29 # of expected failures 28 # of unresolved testcases 1451 # of untested testcases 273 # of unsupported tests 811 pid is 4456

I'm not entirely sure what caused this, but the following code, which used to behave as expected, is now broken: ---- lolwut.c ---------------------------- void lolwut(void) { __asm __volatile ( "ldr r1, =1f \n" ".ltorg \n" "1: \n\t" : : : "r0", "r1" ); } ------------------------------------------- ~/clang

Hi John, On Wed, Sep 22, 2010 at 11:32 AM, John Thompson <john.thompson.jtsoftware at gmail.com> wrote: > I've run the tests from clang-tests/trunk/gcc-4_2-testsuite on a Ubuntu > x86-64 Linux box with the following results: > >         === gcc Summary === > > # of expected passes        29946 > # of unexpected failures    9938 > # of unexpected successes    29

Hi, I'm looking for some feedback on the changes represented in the attached patches, which I'll describe below. I'm sending this to both the LLVM and Clang list because it affects both, though the main focus here is LLVM. Basically, I've partially implemented some changes for choosing multiple alternative constraints largely on the LLVM side. The Clang change is to output the

I encountered an issue with ThinLTO handling of inline assembly, where the inline assembly referenced a constant that was a local variable. The local var was renamed because it was promoted in ThinLTO mode, but the inline assembly copy was not renamed and we ended up with an undef at link time. It looks like this is a general problem with inline assembly and LTO. Wondering if it is a known issue.

On Aug 25, 2010, at 12:45 PM, John Thompson wrote: > Hi, > > I'm looking for some feedback on the changes represented in the > attached patches, which I'll describe below. > > I'm sending this to both the LLVM and Clang list because it affects > both, though the main focus here is LLVM. > Basically, I've partially implemented some changes for choosing