tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] minor patches + standard compliant inline functions


From: Michael Matz
Subject: Re: [Tinycc-devel] minor patches + standard compliant inline functions
Date: Mon, 17 Jun 2019 05:46:20 +0200 (CEST)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)

Hello Petr,

On Tue, 11 Jun 2019, Petr Skočík wrote:

- turn -fdollars-in-identifiers on by default   (gcc/clang do it too)
- in c11 mode, skip __STDC_ISO_10646__  (was causing a redefinition
warning in simple hello world programs compiled on linux with -std=c11)
- make -h|-hh succeed if the output is successfully written

are small and should be noncontroversial.

Nice.

The issue was that tinycc's implementation of non-static inline functions was very much nonconforming in terms of when visible symbols would or would not be created.

Well, it was conforming (roughly), just not to ISO-C99, but rather to GNU C, which had inline long before ISO C ;-)

By looking at the at the mailing list archive, it looks like it was discussed in 2013 but nothing was done about it.

The supplied patch should be fixing it.

Thanks for that, hopefully meanwhile most code in the wild will not rely on gnu-inline behaviour anymore, but rather on c99 inline behaviour. I've taken up your remark in the patch about needing two new flags in type.t and have rewritten that part.

FWIW, mingw still requires gnu-inline behaviour, which is why their use of "extern inline" in __CRT_INLINE is correct for them (they force this behaviour via an attribute), but with this TCC change 'static inline' is more correct, though in reality it's even more complicated: it should be "inline" only (without extern/static) and then some C file within mingw would declare all these inlines as 'extern' as well, to ensure an external definition exists. Of course we can't influence mingw in this way, so "static inline" is the correct equivalent to gnu-inline "extern inline".

And Christian: we shouldn't worry about changes in _mingw.h: that header explicitely does _not_ come from Mingw32 as is but is private to TCC, so differences are expected (and already exist).


Ciao,
Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]