February 18, 2013
On Monday, 18 February 2013 at 11:44:03 UTC, Kai Nacke wrote:
>
> I tried it with trunk.
>
> Regards
> Kai

Thanks Kai, bug added:

http://llvm.org/bugs/show_bug.cgi?id=15293

Cheers, Paolo
March 04, 2013
On Monday, 18 February 2013 at 13:03:46 UTC, Paolo Invernizzi wrote:
> Thanks Kai, bug added:
>
> http://llvm.org/bugs/show_bug.cgi?id=15293

Does using llvm::CallingConv::C by default help as a workaround (https://github.com/ldc-developers/ldc/blob/master/gen/abi.cpp#L53)?

As the official docs should say that »the extern (D) calling convention matches the C calling convention used by the supported C compiler on the host system«, this should probably be changed anyway.

David
March 05, 2013
On Monday, 4 March 2013 at 13:13:15 UTC, David Nadlinger wrote:
> On Monday, 18 February 2013 at 13:03:46 UTC, Paolo Invernizzi wrote:
>> Thanks Kai, bug added:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=15293
>
> Does using llvm::CallingConv::C by default help as a workaround (https://github.com/ldc-developers/ldc/blob/master/gen/abi.cpp#L53)?
>
> As the official docs should say that »the extern (D) calling convention matches the C calling convention used by the supported C compiler on the host system«, this should probably be changed anyway.
>
> David

Hi David,

I've tried with the latest master, changing the LINKdefault from Fast to C, but I have the same ice, on the reduced example I've posted above.

The problem is that right now I'm a little under pressure on work, so I've almost no time to dig into LLVM for trying to resolve the bug... *sigh*

/Paolo
March 23, 2013
On Monday, 18 February 2013 at 13:03:46 UTC, Paolo Invernizzi wrote:
> On Monday, 18 February 2013 at 11:44:03 UTC, Kai Nacke wrote:
>>
>> I tried it with trunk.
>>
>> Regards
>> Kai
>
> Thanks Kai, bug added:
>
> http://llvm.org/bugs/show_bug.cgi?id=15293
>
> Cheers, Paolo

Hi Paolo!

There is now a patch available in the bug report. At first look it seems that it fixes the problem.
I tried to compile druntime but (as usual) I get a lot of "error: undefined identifier va_list" messages. That was the same with PPC64....

Regards
Kai
April 07, 2013
On Saturday, 23 March 2013 at 15:12:29 UTC, Kai Nacke wrote:
> There is now a patch available in the bug report. At first look it seems that it fixes the problem.
> I tried to compile druntime but (as usual) I get a lot of "error: undefined identifier va_list" messages. That was the same with PPC64....

The patch is still being discussed on the LLVM lists, and it looks like it is a very incomplete solution.

In any case, it shouldn't really be a blocker for us, as we need to implement ABI transforms similar to x86_64 anyway to handle the ARM EABI (with and without VFP/hardfloat):

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf (see e.g. section 5.5)

The Clang source has a couple of interesting test cases, for example:

https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-arguments.c
https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-aapcs-vfp.c

David
May 06, 2013
On Sunday, 7 April 2013 at 00:05:15 UTC, David Nadlinger wrote:
> On Saturday, 23 March 2013 at 15:12:29 UTC, Kai Nacke wrote:
>> There is now a patch available in the bug report. At first look it seems that it fixes the problem.
>> I tried to compile druntime but (as usual) I get a lot of "error: undefined identifier va_list" messages. That was the same with PPC64....
>
> The patch is still being discussed on the LLVM lists, and it looks like it is a very incomplete solution.
>
> In any case, it shouldn't really be a blocker for us, as we need to implement ABI transforms similar to x86_64 anyway to handle the ARM EABI (with and without VFP/hardfloat):
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf (see e.g. section 5.5)
>
> The Clang source has a couple of interesting test cases, for example:
>
> https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-arguments.c
> https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-aapcs-vfp.c
>
> David

PR15293 should now be fixed with r181148 from yesterday.

Kai
May 06, 2013
On Monday, 6 May 2013 at 05:16:39 UTC, Kai Nacke wrote:
> On Sunday, 7 April 2013 at 00:05:15 UTC, David Nadlinger wrote:
>> On Saturday, 23 March 2013 at 15:12:29 UTC, Kai Nacke wrote:
>>> There is now a patch available in the bug report. At first look it seems that it fixes the problem.
>>> I tried to compile druntime but (as usual) I get a lot of "error: undefined identifier va_list" messages. That was the same with PPC64....
>>
>> The patch is still being discussed on the LLVM lists, and it looks like it is a very incomplete solution.
>>
>> In any case, it shouldn't really be a blocker for us, as we need to implement ABI transforms similar to x86_64 anyway to handle the ARM EABI (with and without VFP/hardfloat):
>>
>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf (see e.g. section 5.5)
>>
>> The Clang source has a couple of interesting test cases, for example:
>>
>> https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-arguments.c
>> https://github.com/llvm-mirror/clang/blob/master/test/CodeGen/arm-aapcs-vfp.c
>>
>> David
>
> PR15293 should now be fixed with r181148 from yesterday.
>
> Kai

I don't think this helps us much at all, since the ABI for (small) structs would still be wrong, no?

David

May 06, 2013
On Monday, 6 May 2013 at 08:42:44 UTC, David Nadlinger wrote:
> On Monday, 6 May 2013 at 05:16:39 UTC, Kai Nacke wrote:
>> PR15293 should now be fixed with r181148 from yesterday.
>>
>> Kai
>
> I don't think this helps us much at all, since the ABI for (small) structs would still be wrong, no?
>
> David

The commit log says:

For ARM backend, fixed "byval" attribute support.
Now even the small structures could be passed within byval (small enough
to be stored in GPRs).

I conclude that the ABI for small structs should be fine now.

Kai
May 06, 2013
On Monday, 6 May 2013 at 11:01:45 UTC, Kai Nacke wrote:
> The commit log says:
>
> For ARM backend, fixed "byval" attribute support.
> Now even the small structures could be passed within byval (small enough
> to be stored in GPRs).
>
> I conclude that the ABI for small structs should be fine now.

Doesn't LLVM suffer from the same conceptual problem as on x86_64 here, i.e. the C struct { char a, b, c, d; } being mapped to four registers instead of one if the obvious LLVM representation is chosen?

David
May 06, 2013
On Friday, 15 February 2013 at 15:51:20 UTC, Kai Nacke wrote:
> In Phobos the module which can make trouble is std.math. It is also included in many other modules and contains a fair amount of assembler code.

Naive question -- why not have D fallback versions of the assembler parts of Phobos, druntime etc.?  Even if it means very slow code for some cases, it would surely simplify getting a basic working system up and running on different platforms.
1 2
Next ›   Last »