Hi Michael,
> And larger :) I think the patch as-is is a good one (though maybe count from
> initial commit, not from the 0.9.27 release?), even though that macro will be
> awkwardish to use (and with the disadvantages you named).
I'm currently working on implementations of the __has_*() opera
Hello,
On Mon, 9 Aug 2021, Elijah Stone wrote:
IMO a cleaner solution would be to support clang's
__has_feature/__has_builtin/__has_extension. This:
- Is clearer: says exactly what you mean.
- Is less error-prone; if a feature goes away in a later version or in
some configuration, or if y
Thanks for the feedback!
I think implementing these operators would be much clearer and
"compatible" indeed, but I hadn't thought about it before. I haven't
really played a lot with TCC's code before, but I could try to
implement this, if there's no problem with that.
2021-08-09 22:42 GMT-03:00,
On Mon, 9 Aug 2021, Elijah Stone wrote:
- Doesn't disadvantage newer compilers
NB. to clarify--I meant completely new, never-before-heard-of compilers,
not newer versions of existing compilers.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
On Mon, 9 Aug 2021, Elijah Stone wrote:
clang's __has_feature/__has_builtin/__has_extension
Incidentally, gcc has __has_builtin and __has_attribute, but not
__has_feature nor __has_extension.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
h
IMO a cleaner solution would be to support clang's
__has_feature/__has_builtin/__has_extension. This:
- Is clearer: says exactly what you mean.
- Is less error-prone; if a feature goes away in a later version or in
some configuration, or if you typo'd the version number in the first
place,
Hello!
I'm currently using TCC for testing and experimenting because it's
blazing fast (amazing work, by the way), and some libraries depend on
GNU C features which are actually implemented in the `mob` branch, but
the libraries only check for GCC and Clang, so I would like to send a
few patches t
