On Thu, 26 Nov 2020, Thomas Koenig wrote:
> If you want to look at something quite close to the standard, you can
> check out https://j3-fortran.org/doc/year/18/18-007r1.pdf .
Thanks!
Maciej
On Thu, 26 Nov 2020, Thomas Koenig wrote:
> > What do you need this information for anyway?
>
> It's a check if the simplification to constants of these
> floating point types is done correctly.
Well, GCC's handling of the various FP formats is in the middle end (see
gcc/real.c and the vario
Am 26.11.20 um 19:05 schrieb Maciej W. Rozycki:
What do you need this information for anyway?
It's a check if the simplification to constants of these
floating point types is done correctly.
Another interesting thing to look at would be selected_real_kind.
selected_real_kind(precision, rang
Am 26.11.20 um 18:34 schrieb Maciej W. Rozycki:
Yeah, I've seen it my Fortran reference (not an official standard though;
I don't remember where to get them from and given I don't seem to have a
copy, I suspect they are charged for).
If you want to look at something quite close to the standar
On Thu, 26 Nov 2020, Thomas Koenig wrote:
> On my (IEEE) box, this prints
>
> r = 3.402823e+38 d = 1.797693e+308 i = 4
>
> so if you have a working printf (or some other way to display
> floating-point-variables) for C, you can examine the
> values.
This prints:
r = 1.701412e+38 d = 1.701412e
On Wed, 25 Nov 2020, Tobias Burnus wrote:
> > Well, it does not link, for the somewhat unsurprising reason of a missing
> > libgfortran runtime. I have modified the program with whatever little
> > Fortran skills I gained a while ago to get something that can be parseable
> > for a human being in
On Wed, 25 Nov 2020, Tobias Burnus wrote:
> LGTM.
Applied now, thank you for your review.
Maciej
Am 25.11.20 um 23:02 schrieb Maciej W. Rozycki:
The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
would have to be handled correctly, both for simplification in
the front end and in the library.
Does the program
print *,HUGE(1.0)
print *,EPSILON(1.0)
end
print correct valu
On 25.11.20 23:02, Maciej W. Rozycki wrote:
Well, it does not link, for the somewhat unsurprising reason of a missing
libgfortran runtime. I have modified the program with whatever little
Fortran skills I gained a while ago to get something that can be parseable
for a human being in the assembl
On Wed, 25 Nov 2020, Thomas Koenig wrote:
> >xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
>
> The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
> would have to be handled correctly, both for simplification in
> the front end and in the library.
>
> Does the program
>
Hi Maciej,
Infinity is the least of a problem, because as it turns out we have
numerous FP library functions in libgfortran that require explicit porting
to each FP format supported, like these settings:
xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
The Fortran intrinsis l
On Wed, 25 Nov 2020, Tobias Burnus wrote:
> Does this solve all infinity issues? Or is there still code requiring it
> implicitly? From the previous exchange, it sounded as if there are still
> issues.
Infinity is the least of a problem, because as it turns out we have
numerous FP library funct
LGTM.
Does this solve all infinity issues? Or is there still code requiring it
implicitly? From the previous exchange, it sounded as if there are still
issues.
Tobias
On 25.11.20 19:14, Maciej W. Rozycki wrote:
The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#de
The *_HAS_* floating-point feature macros are defined as 0/1 rather than
#undef/#define settings by gcc/c-family/c-cppbuiltin.c. Consequently we
choose to use infinity and NaN features even with non-IEEE-754 targets
such as `vax-netbsdelf' that lack them, causing build warnings and
failures li
14 matches
Mail list logo
