llvm dev - Dec 2015 - Bootstrapping clang/LLVM with ELLCC

(Fixed the cfe email address)

On 12/18/2015 09:34 PM, Tim Northover wrote:
> On 18 December 2015 at 19:15, Richard Pennington via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> It turns out that it can with some simple patches.
> This sounds really cool. I think we should seriously consider putting
> these patches into LLVM mainline.
>
>> Information on building clang/LLVM with ELLCC is here:
>> http://ellcc.org/blog/?p=26397
>
> Here are some of my thoughts on the patch there, with a view to
upstreaming:
>
>    * Large sections of the patch seem to be Makefile changes. Given
> that we're deprecating autoconf, a CMake equivalent will be needed.
I know. I'm scared to death of cmake, but I plan on moving there
soon.
>    * Unconditionally #defining _BSD_SOURCE doesn't feel right.
I agree. I'll find a better way.
>    * #undefining libc symbols based on __ELCC__. This looks like a musl
> issue rather than just elcc. I'm actually rarther suspicious of musl
> here too: neither C99 nor C++11 reserve (e.g.) fopen64. That said,
> we've put in worse hacks to support broken platforms (see
> -fms-compatibility).
I'll talk to the musl guys about this. I don't think they like the idea 
of being referred to as a "broken platform".
>    * sys/time.h: not sure this exists on all systems. What are we using
> that depends on it and what guards does that source have?
I'll verify why this was added. It was a while ago.
>    * "and" as an operator? I know C allows it, but it's
highly
> unidiomatic. </tiniest nit in the world>
I just copied what was already there. </tiniest rationalization in the 
world>

-Rich
>
> Cheers.
>
> Tim.
>

On 18 December 2015 at 19:50, Richard Pennington <rich at pennware.com>
wrote:
>>    * #undefining libc symbols based on __ELCC__. This looks like a musl
>> issue rather than just elcc. I'm actually rarther suspicious of
musl
>> here too: neither C99 nor C++11 reserve (e.g.) fopen64. That said,
>> we've put in worse hacks to support broken platforms (see
>> -fms-compatibility).
>
> I'll talk to the musl guys about this. I don't think they like the
idea of
> being referred to as a "broken platform".
Yeah, that was probably excessively harsh. But people could have
legitimate reasons for #including <stdio.h> (presumably) but making
use of "fopen64". You should see the hoops libc++ jumps through to
avoid such mishaps.

Cheers.

Tim.

> Yeah, that was probably excessively harsh. But people could have
> legitimate reasons for #including <stdio.h> (presumably) but making
> use of "fopen64". You should see the hoops libc++ jumps through
to
> avoid such mishaps.
Looks like Musl's own definitions are protected by
"_LARGEFILE64_SOURCE || _GNU_SOURCE". My guess is that we end up
defining _GNU_SOURCE for whatever reason, which would make the #undefs
entirely logical in that regime. (Completely unchecked, of course).

Cheers.

Tim.

On Fri, Dec 18, 2015 at 09:50:55PM -0600, Richard Pennington via cfe-dev
wrote:
> I'll talk to the musl guys about this. I don't think they like the
idea of
> being referred to as a "broken platform".
What are they trying to do -- provide header compatibility for broken
Linux sources that want to use the silly fopen64 and co? For that just
define a second prototype and use __asm__("fopen") or so to rename it.
No need for a macro.

Joerg

On Dec 18, 2015 9:51 PM, "Richard Pennington via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
>
> (Fixed the cfe email address)
>
>
> On 12/18/2015 09:34 PM, Tim Northover wrote:
>>
>> On 18 December 2015 at 19:15, Richard Pennington via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>> It turns out that it can with some simple patches.
>>
>> This sounds really cool. I think we should seriously consider putting
>> these patches into LLVM mainline.
>>
Thanks for bringing this up, Rich!

If these patches or something like them are accepted, maybe it makes sense
to update docs/GettingStarted "getting a modern host c++ toolchain" to
include ecc?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/84176f83/attachment.html>