llvm dev - Jun 2019 - A libc in LLVM

> What do you expect to be architecture dependent? I struggled to think of
where the architecture and not the operating system was the issue.

I’m also interested in this. All I can think of is longjmp.
> On Fuchsia we critically need support for AArch64
I’d be willing to work on this side of things once work gets under way but
I’m with Jake that I’m not really sure what will be architecture dependent.

Best,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/e07b2b84/attachment.html>

fenv.h comes to mind, along with lots of routines in memory.h (eg optimized
memcpy)

On Tue, Jun 25, 2019 at 8:35 AM Alex Brachet-Mialot via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > What do you expect to be architecture dependent? I struggled to think
> of where the architecture and not the operating system was the issue.
>
> I’m also interested in this. All I can think of is longjmp.
>
> > On Fuchsia we critically need support for AArch64
>
> I’d be willing to work on this side of things once work gets under way but
> I’m with Jake that I’m not really sure what will be architecture dependent.
>
> Best,
> Alex
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/a0568607/attachment.html>

Many of the headers prescribed by the C specification itself have some degree of
architecture-dependence. I count 11 headers that rely on some architecture
details, or minimally need to have some knowledge of ABI details. These are
complex, fenv, float, inttypes, limits, math, stdarg, stdatomic, stddef, stdint,
and setjmp. About 10 headers have some degree of operating-system specific
details (ctype, errno, signal, stdio, stdlib, wchar, wctype, threads, time,
locale), although most of them have a fairly minimal abstraction base. The
remaining 8 headers are truly agnostic to any implementation details and have
their contents more or less mandated by the specification (assert, iso646,
stdalign, stdbool, stdnoreturn, string, tgmath, and uchar), although there may
be room for libraries to have accelerated implementations on particular
architectures.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex
Brachet-Mialot via llvm-dev
Sent: Tuesday, June 25, 2019 11:35
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] A libc in LLVM
> What do you expect to be architecture dependent? I struggled to think of
where the architecture and not the operating system was the issue.
I’m also interested in this. All I can think of is longjmp.
> On Fuchsia we critically need support for AArch64
I’d be willing to work on this side of things once work gets under way but I’m
with Jake that I’m not really sure what will be architecture dependent.

Best,
Alex


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/8f2b796c/attachment.html>