Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
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:eli...@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...@nongnu.org] On Behalf Of Michael Matz Sent: Saturday, January 02, 2021 00:09 To: jull...@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 ( 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 . 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 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 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 : 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 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 be conditional
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...@nongnu.org] On Behalf Of Michael Matz Sent: Saturday, January 02, 2021 00:09 To: jull...@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 ( 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 . 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 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 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 : 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 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 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 d) b + leave it to the C library to provide The nicest solution would be (c) as that goes towards providing a free-standing implementation. But the provided 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@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
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Hello, On Fri, 1 Jan 2021, Joshua Scholar wrote: I noticed that in the win32 directory there are 46 include files in the main include directory, 9 in include/sys, there's a secure api directory with 12 files, an a libtcc directory with an include file and a def file.. but the include directory for the non-windows build only has 9 files, so I guess it's relying on the system to have another C compiler installed whose .h files it can use. No, it means you have to have a C library installed (there are multiple). The compiler doesn't provide one. If you come from Windows that might seem unusual, but the C standard explicitely has provisions for this, and it's the usual way of delivery on non-windows system. You might have multiple compilers, all using the same C library, the latter being more tied to the system facilities than a compiler. It does require some cooperation between C library and C compiler at the overlap, but it provides much better separation of concerns. I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. How could it be any different? We don't provide a graphical GUI library, so we provide no headers for it. We don't provide a C library either, so we don't provide those headers either. The headers you see for Windows and its msvcrt library are a mere nicety: there's only one de-facto C library on Windows so providing headers for that one is fairly easy. In addition there're also well-known other libraries provided on every windows system, so some headers (and .def) files for them are provided as well. But that's more catering to expectations of Windows users than the usual way. Does that mean you have to have GCC installed? No. It's awfully confident of them to be sure that every GCC include tree will work. Not every GCC include tree, no. But every C library include tree: yes, that is an expectation. Within limits, but generally so: the C lib include headers are expected to make use of only standard C features (or use non-standard features only after checking for availability from the compiler at hand), and TCC is expected to conform to the standard. Again, that's the ideal, not 100% reached, but it's the general direction. Does Clang work? With what? With GCC include trees: no, with C lib includes: yes. Clang is not different from TCC in this respect, or from GCC for that matter. It's just another compiler. (Well, in fact clang implements most GCC extensions, so it is even fine with most GCC-specific headers; but that's a detail). Is it a license issue? If so, that's passing the license issue on to you. No, it's not a license issue, it's a separation of concern issue. Ciao, Michael. On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: First, happy new year all. 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. i.e. From C11: B.18 Common definitions ptrdiff_t size_t max_align_t wchar_t NULL offsetof(type, member-designator) _ _STDC_WANT_LIB_EXT1_ _ rsize_t Howerver it also contain many [u]intN_t type definitions which duplicate what is found on stdint.h The issues come when a valid program frist includes then It first finds [u]intN_t definitions in system [/usr/include/]stdint.h file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. When definitions differ, tcc stops as some with *BSD systems and [u]int64_t definitions. Questions: Why tcc needs its own stddef.h instead of system one? Why tcc does not need stdint.h? 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. Clarifications/fixes are welcome. C. ___ 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
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 ( 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 . 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 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 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 : 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 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 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 d) b + leave it to the C library to provide The nicest solution would be (c) as that goes towards providing a free-standing implementation. But the provided 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@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
I responded too soon. There are only the nine files from the build directory's /include in /usr/local/lib/tcc That STILL doesn't tell us where it's getting stddef.h from, except that it has to be getting them from the standard GCC installed. On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien wrote: > The Windows case is more clear to me, as windows does not have compiler > hence no standard includes, the win32/include part contains all the stuff > to let tcc find its includes (most of its includes). It contains std C > headers and the most common windows headers. > > > > My concern is with includes that are installed with “make install” and go > to /usr/local/lib/tcc by default. > > > > C. > > > > *From:* Joshua Scholar [mailto:joshuascho...@gmail.com] > *Sent:* Friday, January 01, 2021 17:24 > *To:* jull...@eligis.com; tinycc-devel@nongnu.org > *Subject:* Re: [Tinycc-devel] issues/questions with stddef.h which comes > with tcc > > > > I noticed that in the win32 directory there are 46 include files in the > main include directory, 9 in include/sys, there's a secure api directory > with 12 files, an a libtcc directory with an include file and a def file.. > but the include directory for the non-windows build only has 9 files, so I > guess it's relying on the system to have another C compiler installed whose > .h files it can use. I haven't been here long, but it does sound like a > bad idea to not include your own include files for every platform. > > > > Does that mean you have to have GCC installed? It's awfully confident of > them to be sure that every GCC include tree will work. Does Clang work? Is > it a license issue? If so, that's passing the license issue on to you. > > > > On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > > First, happy new year all. > > > > 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. > > i.e. From C11: > > > > *B.18 Common definitions * > > ptrdiff_t > > size_t > > max_align_t > > wchar_t > > NULL > > offsetof(type, member-designator) > > _ _STDC_WANT_LIB_EXT1_ _ > > rsize_t > > > > Howerver it also contain many [u]int*N*_t type definitions which > duplicate what is found on stdint.h > > > > The issues come when a valid program frist includes then > > > It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h > file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. > > When definitions differ, tcc stops as some with *BSD systems and > [u]int64_t definitions. > > > > Questions: > > > > Why tcc needs its own stddef.h instead of system one? > > Why tcc does not need stdint.h? > > > > 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. > > > > Clarifications/fixes are welcome. > > > > C. > > ___ > 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 > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Oh, nevermind. I never tried "sudo make install." On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien wrote: > The Windows case is more clear to me, as windows does not have compiler > hence no standard includes, the win32/include part contains all the stuff > to let tcc find its includes (most of its includes). It contains std C > headers and the most common windows headers. > > > > My concern is with includes that are installed with “make install” and go > to /usr/local/lib/tcc by default. > > > > C. > > > > *From:* Joshua Scholar [mailto:joshuascho...@gmail.com] > *Sent:* Friday, January 01, 2021 17:24 > *To:* jull...@eligis.com; tinycc-devel@nongnu.org > *Subject:* Re: [Tinycc-devel] issues/questions with stddef.h which comes > with tcc > > > > I noticed that in the win32 directory there are 46 include files in the > main include directory, 9 in include/sys, there's a secure api directory > with 12 files, an a libtcc directory with an include file and a def file.. > but the include directory for the non-windows build only has 9 files, so I > guess it's relying on the system to have another C compiler installed whose > .h files it can use. I haven't been here long, but it does sound like a > bad idea to not include your own include files for every platform. > > > > Does that mean you have to have GCC installed? It's awfully confident of > them to be sure that every GCC include tree will work. Does Clang work? Is > it a license issue? If so, that's passing the license issue on to you. > > > > On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > > First, happy new year all. > > > > 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. > > i.e. From C11: > > > > *B.18 Common definitions * > > ptrdiff_t > > size_t > > max_align_t > > wchar_t > > NULL > > offsetof(type, member-designator) > > _ _STDC_WANT_LIB_EXT1_ _ > > rsize_t > > > > Howerver it also contain many [u]int*N*_t type definitions which > duplicate what is found on stdint.h > > > > The issues come when a valid program frist includes then > > > It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h > file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. > > When definitions differ, tcc stops as some with *BSD systems and > [u]int64_t definitions. > > > > Questions: > > > > Why tcc needs its own stddef.h instead of system one? > > Why tcc does not need stdint.h? > > > > 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. > > > > Clarifications/fixes are welcome. > > > > C. > > ___ > 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 > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
I compiled it under linux. There is no /usr/local/lib/tcc. I can't find anything like that. I can't find any environment variables that refer to tcc. And nothing was copied back to include in the build directory. On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien wrote: > The Windows case is more clear to me, as windows does not have compiler > hence no standard includes, the win32/include part contains all the stuff > to let tcc find its includes (most of its includes). It contains std C > headers and the most common windows headers. > > > > My concern is with includes that are installed with “make install” and go > to /usr/local/lib/tcc by default. > > > > C. > > > > *From:* Joshua Scholar [mailto:joshuascho...@gmail.com] > *Sent:* Friday, January 01, 2021 17:24 > *To:* jull...@eligis.com; tinycc-devel@nongnu.org > *Subject:* Re: [Tinycc-devel] issues/questions with stddef.h which comes > with tcc > > > > I noticed that in the win32 directory there are 46 include files in the > main include directory, 9 in include/sys, there's a secure api directory > with 12 files, an a libtcc directory with an include file and a def file.. > but the include directory for the non-windows build only has 9 files, so I > guess it's relying on the system to have another C compiler installed whose > .h files it can use. I haven't been here long, but it does sound like a > bad idea to not include your own include files for every platform. > > > > Does that mean you have to have GCC installed? It's awfully confident of > them to be sure that every GCC include tree will work. Does Clang work? Is > it a license issue? If so, that's passing the license issue on to you. > > > > On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > > First, happy new year all. > > > > 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. > > i.e. From C11: > > > > *B.18 Common definitions * > > ptrdiff_t > > size_t > > max_align_t > > wchar_t > > NULL > > offsetof(type, member-designator) > > _ _STDC_WANT_LIB_EXT1_ _ > > rsize_t > > > > Howerver it also contain many [u]int*N*_t type definitions which > duplicate what is found on stdint.h > > > > The issues come when a valid program frist includes then > > > It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h > file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. > > When definitions differ, tcc stops as some with *BSD systems and > [u]int64_t definitions. > > > > Questions: > > > > Why tcc needs its own stddef.h instead of system one? > > Why tcc does not need stdint.h? > > > > 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. > > > > Clarifications/fixes are welcome. > > > > C. > > ___ > 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 > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
But one thing that's interesting about his project is that it compiles very fast AND it has some optimization. He added only two optimization passes but says that on a SpecInt test, it's 80% as fast as GCC -O2 He says that most optimizations give you very little in return, but a couple of well chosen ones are worth it. On Fri, Jan 1, 2021 at 8:50 AM Ivo van Poorten wrote: > On Fri, 1 Jan 2021 08:27:10 -0800 Joshua Scholar > wrote: > > I had this experience the other day. > > Someone on Github is building a (not yet finished) jit compiler that > > has a C compiler as a test case. > > Do you have a link? Always interested in this kind of projects. > > Regards, > Ivo > > ___ > 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
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
The Windows case is more clear to me, as windows does not have compiler hence no standard includes, the win32/include part contains all the stuff to let tcc find its includes (most of its includes). It contains std C headers and the most common windows headers. My concern is with includes that are installed with “make install” and go to /usr/local/lib/tcc by default. C. From: Joshua Scholar [mailto:joshuascho...@gmail.com] Sent: Friday, January 01, 2021 17:24 To: jull...@eligis.com; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc I noticed that in the win32 directory there are 46 include files in the main include directory, 9 in include/sys, there's a secure api directory with 12 files, an a libtcc directory with an include file and a def file.. but the include directory for the non-windows build only has 9 files, so I guess it's relying on the system to have another C compiler installed whose .h files it can use. I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. Does that mean you have to have GCC installed? It's awfully confident of them to be sure that every GCC include tree will work. Does Clang work? Is it a license issue? If so, that's passing the license issue on to you. On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: First, happy new year all. 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. i.e. From C11: B.18 Common definitions ptrdiff_t size_t max_align_t wchar_t NULL offsetof(type, member-designator) _ _STDC_WANT_LIB_EXT1_ _ rsize_t Howerver it also contain many [u]intN_t type definitions which duplicate what is found on stdint.h The issues come when a valid program frist includes then It first finds [u]intN_t definitions in system [/usr/include/]stdint.h file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. When definitions differ, tcc stops as some with *BSD systems and [u]int64_t definitions. Questions: Why tcc needs its own stddef.h instead of system one? Why tcc does not need stdint.h? 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. Clarifications/fixes are welcome. C. ___ 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
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
https://github.com/vnmakarov/mir I mentioned all the sorts of things I wanted in a jit (along with saying that I could help) to the author of this jit and he said he wasn't interested. He doesn't particularly want to generate parallel friendly code, nor is he interested in a garbage collector, nor in making the state of a system open to snapshotting. On Fri, Jan 1, 2021 at 8:27 AM Joshua Scholar wrote: > I had this experience the other day. > Someone on Github is building a (not yet finished) jit compiler that has a > C compiler as a test case. It will be a competitor to TCC one day, I guess. > Anyway, it's being developed on Linux but some early parts were tested on > Windows. > Not the C compiler though, it doesn't come with ANY include files. > I tried MingW's include files - nothing but errors. > I tried TCC's include files - nothing but errors. > > So that's an example of this sort of thing going wrong. > > On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > >> First, happy new year all. >> >> >> >> 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. >> >> i.e. From C11: >> >> >> >> *B.18 Common definitions * >> >> ptrdiff_t >> >> size_t >> >> max_align_t >> >> wchar_t >> >> NULL >> >> offsetof(type, member-designator) >> >> _ _STDC_WANT_LIB_EXT1_ _ >> >> rsize_t >> >> >> >> Howerver it also contain many [u]int*N*_t type definitions which >> duplicate what is found on stdint.h >> >> >> >> The issues come when a valid program frist includes then >> >> >> It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h >> file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. >> >> When definitions differ, tcc stops as some with *BSD systems and >> [u]int64_t definitions. >> >> >> >> Questions: >> >> >> >> Why tcc needs its own stddef.h instead of system one? >> >> Why tcc does not need stdint.h? >> >> >> >> 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. >> >> >> >> Clarifications/fixes are welcome. >> >> >> >> C. >> ___ >> 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
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
On Fri, 1 Jan 2021 08:27:10 -0800 Joshua Scholar wrote: > I had this experience the other day. > Someone on Github is building a (not yet finished) jit compiler that > has a C compiler as a test case. Do you have a link? Always interested in this kind of projects. Regards, Ivo ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
I had this experience the other day. Someone on Github is building a (not yet finished) jit compiler that has a C compiler as a test case. It will be a competitor to TCC one day, I guess. Anyway, it's being developed on Linux but some early parts were tested on Windows. Not the C compiler though, it doesn't come with ANY include files. I tried MingW's include files - nothing but errors. I tried TCC's include files - nothing but errors. So that's an example of this sort of thing going wrong. On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > First, happy new year all. > > > > 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. > > i.e. From C11: > > > > *B.18 Common definitions * > > ptrdiff_t > > size_t > > max_align_t > > wchar_t > > NULL > > offsetof(type, member-designator) > > _ _STDC_WANT_LIB_EXT1_ _ > > rsize_t > > > > Howerver it also contain many [u]int*N*_t type definitions which > duplicate what is found on stdint.h > > > > The issues come when a valid program frist includes then > > > It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h > file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. > > When definitions differ, tcc stops as some with *BSD systems and > [u]int64_t definitions. > > > > Questions: > > > > Why tcc needs its own stddef.h instead of system one? > > Why tcc does not need stdint.h? > > > > 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. > > > > Clarifications/fixes are welcome. > > > > C. > ___ > 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
Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
I noticed that in the win32 directory there are 46 include files in the main include directory, 9 in include/sys, there's a secure api directory with 12 files, an a libtcc directory with an include file and a def file.. but the include directory for the non-windows build only has 9 files, so I guess it's relying on the system to have another C compiler installed whose .h files it can use. I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. Does that mean you have to have GCC installed? It's awfully confident of them to be sure that every GCC include tree will work. Does Clang work? Is it a license issue? If so, that's passing the license issue on to you. On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote: > First, happy new year all. > > > > 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. > > i.e. From C11: > > > > *B.18 Common definitions * > > ptrdiff_t > > size_t > > max_align_t > > wchar_t > > NULL > > offsetof(type, member-designator) > > _ _STDC_WANT_LIB_EXT1_ _ > > rsize_t > > > > Howerver it also contain many [u]int*N*_t type definitions which > duplicate what is found on stdint.h > > > > The issues come when a valid program frist includes then > > > It first finds [u]int*N*_t definitions in system [/usr/include/]stdint.h > file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. > > When definitions differ, tcc stops as some with *BSD systems and > [u]int64_t definitions. > > > > Questions: > > > > Why tcc needs its own stddef.h instead of system one? > > Why tcc does not need stdint.h? > > > > 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. > > > > Clarifications/fixes are welcome. > > > > C. > ___ > 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
[Tinycc-devel] issues/questions with stddef.h which comes with tcc
First, happy new year all. 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. i.e. From C11: B.18 Common definitions ptrdiff_t size_t max_align_t wchar_t NULL offsetof(type, member-designator) _ _STDC_WANT_LIB_EXT1_ _ rsize_t Howerver it also contain many [u]intN_t type definitions which duplicate what is found on stdint.h The issues come when a valid program frist includes then It first finds [u]intN_t definitions in system [/usr/include/]stdint.h file which are duplicated/redefined in [tcc/include/]stddef.h from tcc. When definitions differ, tcc stops as some with *BSD systems and [u]int64_t definitions. Questions: Why tcc needs its own stddef.h instead of system one? Why tcc does not need stdint.h? 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. Clarifications/fixes are welcome. C. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] [PATCH 1/1] arm-asm: Add movt
---
arm-asm.c | 15 ++-
arm-tok.h | 1 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arm-asm.c b/arm-asm.c
index 6eb680a..1aeb28c 100644
--- a/arm-asm.c
+++ b/arm-asm.c
@@ -226,7 +226,19 @@ static void asm_binary_opcode(TCCState *s1, int token)
tcc_warning("Using 'sp' as operand with '%s' is deprecated by ARM",
get_tok_str(token, NULL));
if (ops[1].type != OP_REG32) {
-expect("(source operand) register");
+switch (ARM_INSTRUCTION_GROUP(token)) {
+case TOK_ASM_movteq:
+if (ops[1].type == OP_IM8 || ops[1].type == OP_IM8N || ops[1].type
== OP_IM32) {
+if (ops[1].e.v >= 0 && ops[1].e.v <= 0x)
+asm_emit_opcode(token, 0x340 | (ops[0].reg << 12) |
ops[1].e.v);
+else
+expect("(source operand) immediate 16 bit value");
+} else
+expect("(source operand) immediate");
+break;
+default:
+expect("(source operand) register");
+}
return;
}
@@ -1120,6 +1132,7 @@ ST_FUNC void asm_opcode(TCCState *s1, int token)
case TOK_ASM_sxtheq:
case TOK_ASM_uxtbeq:
case TOK_ASM_uxtheq:
+case TOK_ASM_movteq:
return asm_binary_opcode(s1, token);
case TOK_ASM_ldreq:
diff --git a/arm-tok.h b/arm-tok.h
index 6d2483b..626e20e 100644
--- a/arm-tok.h
+++ b/arm-tok.h
@@ -69,6 +69,7 @@
DEF_ASM_CONDED(sxth)
DEF_ASM_CONDED(uxtb)
DEF_ASM_CONDED(uxth)
+ DEF_ASM_CONDED(movt)
/* multiplication */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
