Float literal exceeding type exponent produces error in C backend

[demoitem]

Declaring a REAL variable
r := 1.23E123; (the exponent's legal range is -37..38 from memory)

produces error Infinity not declared in this scope in the C backend.
Similarly for LONGREAL and EXTENDED (although they are the same)
for exponents exceeding 308.

[RodneyBates]

So do we want the front end to object?  I would expect the limits to be more nuanced than just limiting the exponent, i.e, would the validity of a maximal exponent depend on the mantissa value? Particularly if the mantissa is not normalized?

…

On 10/31/22 23:17, peter mckinna wrote: Declaring a REAL variable r := 1.23E123; (the exponent's legal range is -37..38 from memory) produces error Infinity not declared in this scope in the C backend. Similarly for LONGREAL and EXTENDED (although they are the same) for exponents exceeding 308. — Reply to this email directly, view it on GitHub <#1111>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNENG4QCB4FZIQW6QYTWGCKVPANCNFSM6AAAAAARTWH5LI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[demoitem]

It was a bit hasty of me posting that issue. It's obviously the value not just the exponent which is being evaluated as infinite. The front end is blameless I think. The C backend just has to include math.h and typedef Infinite to INFINITE I would have thought. I should explain how I got here. I've got a branch with EXTENDED changed to 128 bit floats __float128 in C terms The GCC backend is working and I was testing the C backend which should be easy enough to change. I was hoping to kludge the Windows backend to keep EXTENDED as LONGREAL somehow, as the work involved in generating all the calls to the quadmath library seem daunting (even if I could find a windows version of quadmath). Is this a legitimate quest? The result would be loss of portability at least - not to mention any pickle problems. But only for that backend. You could always use the llvm backend on windows and get 128 bit floats. Thoughts? On Wed, 2 Nov 2022 at 03:09, Rodney M. Bates ***@***.***> wrote:

…

So do we want the front end to object? I would expect the limits to be more nuanced than just limiting the exponent, i.e, would the validity of a maximal exponent depend on the mantissa value? Particularly if the mantissa is not normalized? On 10/31/22 23:17, peter mckinna wrote: > > Declaring a REAL variable > r := 1.23E123; (the exponent's legal range is -37..38 from memory) > > produces error Infinity not declared in this scope in the C backend. > Similarly for LONGREAL and EXTENDED (although they are the same) > for exponents exceeding 308. > > — > Reply to this email directly, view it on GitHub < #1111>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABSVZNENG4QCB4FZIQW6QYTWGCKVPANCNFSM6AAAAAARTWH5LI >. > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#1111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABALZXZ6ZSQI7SUAYLZ7KJ3WGE6CHANCNFSM6AAAAAARTWH5LI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[VictorMiasnikov]

Thoughts?

"EXTENDED changed to 128 bit floats __float128" is good idea.

the Windows backend

Are You about AMD64_NT or AMD64_MINGW?

P.S.

if I could find a windows version of quadmath

It looks like we can try 1 .. 3 variants:

3)

https://www.boost.org/doc/libs/master/libs/math/doc/html/math_toolkit/float128.html
= =
( . . .) or the _Quad type provided by the Intel compiler.
= =

2)

https://www.codeproject.com/Articles/1206126/Quadruple-precision-floating-point-calculations-in
= =
Creation a numeric library that calculates with quadruple floating-point precision and used from MSVC C/C++ code
= =

1)
https://github.com/coder0xff/QPFloat/
= = =

# QPFloat (GPL 3.0) #

For high-precision mathematics, the Quadruple-Precision Floating Point library (QPFloat) emulates the IEEE 754 2008 binary128 on x86, and x64

  . . .

### Microsoft Visual C++ ###
* This code base can be compiled  ( . . .)

= = =

P.P.S.

use the llvm backend on windows

It is good variant too

[VictorMiasnikov]

Declaring a REAL variable r := 1.23E123; (the exponent's legal range is -37..38 from memory)

produces error Infinity not declared in this scope in the C backend. Similarly for LONGREAL and EXTENDED (although they are the same) for exponents exceeding 308.

Can You try this variant?
r := 1.23x923

[demoitem]

They are not assignable if r is REAL. Type mismatch. Does not get to the backend.

…

On Wed, 2 Nov 2022 at 19:57, VictorMiasnikov ***@***.***> wrote: Declaring a REAL variable r := 1.23E123; (the exponent's legal range is -37..38 from memory) produces error Infinity not declared in this scope in the C backend. Similarly for LONGREAL and EXTENDED (although they are the same) for exponents exceeding 308. Can You try this variant? r := 1.23x123 — Reply to this email directly, view it on GitHub <#1111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABALZX7ORX43NUOHENAC5UTWGIUGTANCNFSM6AAAAAARTWH5LI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[VictorMiasnikov]

They are not assignable if r is REAL. Type mismatch. Does not get to the backend.

Ok . . .

P.S.

LLVM13 has been built on Linux:
= = =
(Debian 11.3.0-1) 11.3.0 versions- cm3: d5.11.9 llvm: 13.0.1
= = =
and can re-build other cm3 packets

[jaykrell]

Can we have the frontend output, like integers to initialize floats?
Like knowing deeply the format?
Or, alternatively, output pieces in a portable idealistic form, like 32 bit sign, 64bit exponent (not biased), 64bit mantissa (possibly with leading 1), and then leave the C backend to know the bitfield sizes, order, and bias?
Probably slightly more elaborate in terms of the leading 1 on mantissa and denormals, and maybe an enum to list special cases like inf, -inf, etc.?

You know, I don't want strings.
I am not sure where I want floating point formats to be known.
I want the C backend to have a chance of outputing ifdef endian and output both orders, so the C source is portable, etc.
I don't want the frontend to know endian, ideally, or even word size, ideally, though these are known currently, and 32bit and big endian are dying, granted.

[RodneyBates]

I'm unsure about what you are asking. A change in what the IR contains for values of floating constants?  All backends would be affected. This sounds like another example of needing to raise the compile-time representation, as result of grafting a back end with higher-level output than what the front end is designed to produce.

On 12/14/22 03:36, Jay Krell wrote: Can we have the frontend output, like integers to initialize floats? Like knowing deeply the format? Or, alternatively, output pieces in a portable idealistic form, like 32 bit sign, 64bit exponent (not biased), 64bit mantissa (possibly with leading 1), and then leave the C backend to know the bitfield sizes, order, and bias? Probably slightly more elaborate in terms of the leading 1 on mantissa and denormals, and maybe an enum to list special cases like inf, -inf, etc.? You know, I don't want strings. I am not sure where I want floating point formats to be known. I want the C backend to have a chance of outputing ifdef endian and output both orders, so the C source is portable, etc. I don't want the frontend to know endian, ideally, or even word size, ideally,

In general, these things are deeply known and used by the front end.

…

though these are known currently, and 32bit and big endian are dying, granted. — Reply to this email directly, view it on GitHub <#1111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNBCV3C5BMIUFRGZEL3WNGIKZANCNFSM6AAAAAARTWH5LI>. You are receiving this because you commented.Message ID: ***@***.***>

[jaykrell]

as result of grafting a back end with higher-level
output than what the front end is designed to produce.

This is not fair. While the backend format might seem very low level, and C might seem very high level, they do actually fit together pretty well. The C we translate to is not idiomatic C, or readable, or even very portable (it embeds word size and sometimes endian), but it works quite well anyway.

I do agree it'd be nice to optionally raise the representation in some cases.
We should output names with field references though, not just offsets.
Record fields access should be by name. For the front/middle end to do layout should be optional.
sizeof(integer) should not be evaluated by the front/middle end.
So then the C output might be word size neutral.

I've seen projects that raise binaries to C, which is a far larger raise than M3 IR to C.