tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] NAN and INFINITY break in different ways


From: avih
Subject: Re: [Tinycc-devel] NAN and INFINITY break in different ways
Date: Sun, 24 Dec 2017 14:49:05 +0000 (UTC)

> I think we could make an exception for 0.0/0.0 and always fold this into
> NaN (normally division by zero is indeed not allowable in constant
> expressions in c99).  That would handle the musl case at least.

It wasn't abundantly clear to me from the spec that it's disallowed, but
I trust your understanding/interpretation, and therefore I think it's not
worth compromising the spec to hack a solution, especially when
a similar issue exists also with glibc which I _think_ this won't solve.

The spec says NAN and INFINITY should be defined in math.h, but these
values clearly have to relate somehow to the compiler implementation. tcc
currently doesn't do something useful about this part of the spec, so
better solution IMHO is my suggestion - exactly the missing link between
math.h and tcc.

Thanks for making them floats. I'll check how to integrate my suggested
solution cleanly such that it works on various linux systems and windows,
maybe with some tests to.



On Sunday, December 24, 2017 2:18 PM, Michael Matz <address@hidden> wrote:


Hi,

On Sat, 23 Dec 2017, avih wrote:

> Alpine:
> $ tcc test.c
> testinfs.c:2: error: division by zero in constant
>
> $ tcc test.c -E
> ...
> static const double infs[] = { (0.0f/0.0f), 1e5000f };
> ...
>
> So clearly tcc doesn't like musl's fallback definition (if not gcc) for NAN
> in a constant, but tcc is fine with musl's INFINITY definition.

I think we could make an exception for 0.0/0.0 and always fold this into
NaN (normally division by zero is indeed not allowable in constant
expressions in c99).  That would handle the musl case at least.

> Ubuntu:
> $ tcc test.c
> test.c:2: error: initializer element is not constant
>
> $ tcc test.c -E
> ...
> static const double infs[] = { (__qnan_union.__d), (__huge_valf.__f) };
> ...
>
> Here it's less clear to me how come tcc doesn't complain about undefined
> symbols,

__qnan_union and __huge_valf are static variables defined in the
respective headers, so it's no undefined symbols.  Nevertheless it
wouldn't normally be acceptable in initializers, and with GCC it works
only because there the headers use __builtin_nan and __builtin_inff.


> But the following does seem to solve it relatively correctly I think. Is
> there an objection to install this as <prefix>/lib/tcc/include/math.h ?
>
> /* override NAN and INFINITY with tcc tokens */
>
> #include_next <math.h>
>
> #ifdef NAN
> #  undef NAN
> #endif
> #define NAN __nan__
>
> #ifdef INFINITY
> #  undef INFINITY
> #endif
> #define INFINITY __inf__


I'd be fine with this.  I notice that the c99 NAN and INFINITY are
supposed to be float constants and currently TCCs __nan__ and __inf__ are
doubles.  As those tokens are currently not exposed in any headers (as you
noticed) they're probably unused in the wild and hence can be made floats
without many problems.  I've done this in mob.  I leave the header thingy
to you.


Ciao,
Michael.



reply via email to

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