|
From: | Joshua Scholar |
Subject: | Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc |
Date: | Mon, 4 Jan 2021 10:12:05 -0800 |
_______________________________________________Yup! I test them all for nearly every commits, or at least when I think a commit may break something.
I have access to much more than 12 setups, most of them are mine others are from gnu farm.
My OpenLisp compiler has been compiled on over 160 gnu triplets. The most uncommon are: zLinux, z/OS390, QNX, vms, HP pa risk, Alpha OS, SGI…
C.
From: Joshua Scholar [mailto:joshuascholar@gmail.com]
Sent: Monday, January 04, 2021 18:22
To: jullien@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Does this mean that TCC works with CLang includes and libraries on Linux-arm, Linux-arm64, Linux x64, Linux-riscv, FreeBSD-x64, FreeBSD-arm64, NetBSD-x64, and NetBSD-arm64?
That would be very useful. I mentioned wondering before but didn't get a useful answer.
It's amazing that you have access to 12 setups including a RiscV one!
On Fri, Jan 1, 2021 at 10:57 PM Christian Jullien <eligis@orange.fr> wrote:
Here is the result of my study when stddef.h no longer contains [u]intN_t definitions.
i.e. b) solution
OS | cpu | Compilers | result (including compiling OpenLisp with installed tcc)
--------+-------+---------------+---------------------------------------------------------
Linux | arm | gcc/clang/tcc | Ok
Linux | arm64 | gcc/clang/tcc | Ok
Linux | x64 | gcc/clang/tcc | Ok
Linux | riscv | gcc/clang/tcc | Ok
FreeBSD | x64 | gcc/clang/tcc | Ok
FreeBSD | arm64 | gcc/clang/tcc | Ok
NetBSD | x64 | gcc/clang/tcc | Ok
NetBSD | arm64 | gcc/clang/tcc | Ok
OpenBSD | x64 | gcc/clang | Ok
macOS | x64 | clang | Ok
Windows | x64 | gcc/tcc | Ok obvious as it uses its own stddef.
Windows | x86 | gcc/tcc | Ok obvious as it uses its own stddef.
* Linux x86 build is missing but I doubt it will change things
* Some OpenBSD and macOS don’t fully support tcc boostrapped by tcc.
Do you allow me to remove [u]intN_t definitions for stddef.h and see how it goes? It at least seem to solve the issue of incompatible [u]intN_t redefinitions.
I’m not in favor to add stdint.h which looks to not be needed.
Christian.
-----Original Message-----
From: Christian Jullien [mailto:eligis@orange.fr]
Sent: Saturday, January 02, 2021 06:36
To: 'tinycc-devel@nongnu.org'
Subject: RE: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Thank you for your long reply which confirms what I thought.
So I really think now that stddef.h should only contain what C11 officially defines and let tcc rely on [/usr/include/]stdint.h definitions.
I made a quick test without [u]intN_t definition and tcc after installed in /usr/local/lib/tcc is quite happy at least on linux/arm.
It can be used to bootstrap tcc and its test suite, it also compiles my OpenLisp test suite w.o. a single warning.
I suspect it is not the case with all supported platforms (Apple, *BSD).
I'll check all of them and return to you with a complete feedback.
C.
-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] On Behalf Of Michael Matz
Sent: Saturday, January 02, 2021 00:09
To: jullien@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Hello,
On Fri, 1 Jan 2021, Christian Jullien wrote:
> First, happy new year all.
To you as well.
> Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc
> distrib.
>
> First, it contains a mix of definitions coming from both stddef.h and
> stdint.h IMHO it should only contain what stddef.h is supposed to contain.
First some background. TLDR: patches welcome :)
Standard headers are a bit complicated when considering the C library and
the C compiler in isolation (which we need to do with TCC, as we provide
only a compiler). Both are part of a standard describing the whole
implementation, of library and compiler. But some header facilities can
be usefully provided only with compiler knowledge. There's the concept of
free-standing implementations, that need to provide only a few headers
(<stddef.h> being one), and it's such that in those headers are the most
compiler specifics. So it's sensible to provide them with the compiler,
not with the C library (and if only for the reason that if you don't even
have a C library that you can use the free-standing part of the C
standard).
You will notice that also GCC provides it's own <stddef.h>.
<stdint.h> is a mixed bag; most of it's facilities can be nicely defined
without many compiler specifics except very few crucial macros/builtins.
So, many C libraries do in fact provide that header themself, but still in
a way that there are compilers that don't work correctly with them. E.g.
GCC provides a <stdint.h> that uses the library one with a hosted
implementation (the opposite of a free-standing one).
There's also an advantage for the C library providing these headers: they
can in addition to the standard facilities also provide means that are
specific to the library implementation (e.g. the whole _GNU_SOURCE
business in the GNU C library).
So, for some headers there's a grey zone for decisions: should the
compiler or the library provide a header. For <stddef.h> it's easy: also
other system compilers provide it, e.g. also because of the offsetof()
macro that needs compiler support when you want to avoid non-portable
implementations, so TCC should provide it. For <stdint.h>: here it's less
clear: TCC doesn't claim to provide a free-standing implementation, so it
doesn't _have_ to provide it, but could rely on the C library, which we do
right now.
But of course you are right in that the TCC <stddef.h> should not provide
anything that it isn't supposed to provide, as that can cause conflicts
like you are seeing.
Several solutions:
a) make the non-standard extensions of TCC <stddef.h> be conditional on a
macro (or a non-existence of a macro, like e.g. it could continue to
provide them outside C89/C99/C11 conformance).
b) remove those additions completely
c) b + provide own <stdint.h>
d) b + leave it to the C library to provide <stdint.h>
The nicest solution would be (c) as that goes towards providing a
free-standing implementation. But the provided <stdint.h> needs to be
compatible with anything the C libraries provide or rely on. GCC has to
jump through hoops with that (using include_next), that might be historic
cruft, or it might still be for a reason, I don't know. So without trying
on a range of platforms I can't say if (c) is realistic or not.
> Why tcc needs its own stddef.h instead of system one?
See above, the system one also is compiler specific.
> Why tcc does not need stdint.h?
Because we got away with it :) Patches welcome.
> I suppose it is because tcc does not support all gcc syntaxes found on
> stddef.h (is it still true?) in that case, it would be better to split
> definitions in stddef.h and stdint.h following the ISO C11 standard.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Prev in Thread] | Current Thread | [Next in Thread] |