Re: Problems with compiler explorer GDC Aarch64

[Matt Godbolt]

Hi Cecil (and CCing a list of folks)

1. As you can imagine we can only spend so long compiling people's code. Can you share a link that demonstrates this? That would help us understand, and perhaps we can increase the time allotted.

2. I'm afraid there's a number of issues with cross-compilers on Compiler Explorer, and specifically aarch64: https://github.com/compiler-explorer/compiler-explorer/issues?q=is%3Aissue+is%3Aopen+aarch64 has a few of them. We're always working on improving things, but we can always do with more help!

Sorry that's not all that satisfying an answer, but if you keep an eye on the github issues (and/or file new ones) it might help!

Cheers, Matt

On Fri, Jul 3, 2020 at 8:09 PM Cecil Ward <ce...@cecilward.com> wrote:

Hi Matt,

Couple of bad things i’ve experienced with the GDC compilers for the D language when I try  cross-compiling to ARM Aarch64 asm output.

1. when I try to compile a long-ish D source file with GDC -O2 -release to get Aarch64 asm, the compiler explorer reports something like "time exceeded 15s; killed". I can get it to work without the heavy optimisation of -O2, but then that defeats my aim as I want to see how good GDC can be at its best and I’m learning ARM64 asm too.

2. Some of the other three Aarch64 compiler options listed in the compiler explorer pull-down list under Aarch64 cause compilation to fail with various weird errors. I tried them until I picked the one that worked. It looks as if some of those GDC installations were broken - perhaps theif D runtime library is bad, or the D equivalent of header files are nasty somehow.

best,

Cecil Ward

--

Matt

[Matt Godbolt]

Hi Cecil, replies inline:

On Sat, Jul 4, 2020 at 9:58 PM Cecil Ward <ce...@cecilward.com> wrote:

Absolutely, clearly you can’t hang the server up forever agreed.

The problem of "how long do you give it" is getting worse too, with CTFE being something that D promotes as a sexy feature. Now I come to think of it, my particular D program CTFE-compiles a function that generates a small static table at compile time. Now one could even CTFE-compile an infinite loop by accident, and screw the compiler’s innards, and this kind of danger only moves the ‘halting problem’ back into the compiler instead of the program.

Understood. I'm not a D expert but I presume CTFE is some kind of compile-time thing like C++ templates or C++ constexpr. Of course that increases compile time :)

Perhaps compilers themselves need to generate some kind of intelligent watchdog-defeat events internally while they are CTFE-compiling. Not at all sure how that would work, it’s a hard problem to output ‘genuine percentage (of real work) done‘ in a way where just going round an infinite loop longer doesn’t look like more great progress towards some goal. One could extend a time limit kill duration by tickling it to extend it as proof of new work achieved comes out, so for example, each new function’s code that is generated, and each CTFE result that is successfully returned could buy you so much more time. I’m sure someone will have done some relevant work in areas that could help here.

In the end, I managed to get GDC to work outputting Aarch64 code with the desired

    -O2 -frelease

It seems there was some badness in the parameters appended to the long URL that I had bookmarked, and the web UI wouldn’t appear properly for some unknown reason. So I stripped all the junk of the end and went back up to the top of the site explore.dgnu.org again and all was then well. I uploaded the D source code into the source window with paste-copy; probably is an intelligent way to do this but I couldn’t seem to get it to work on an ipad.

This is the short URL which I got when I did a Share: https://explore.dgnu.org/z/ciqaNT

I've not seen this site before?! Cool: do you know who administrates it? I'm not responsible for whatever timeouts they have on that (we ought to have ~30s on Compiler Explorer, but it's configurable).

 

Thanks for your help and of course your continued good work. I’ve learned a lot about the spectacular capabilities of modern compilers’ backends now. Code generation is sparkling now compared to the simple efforts I used to see at work 35 years ago.

Best,

Cecil Ward

Thanks!

--matt :)