On Sat, Jan 08, 2022 at 02:15:14PM -0500, David Edelsohn wrote:
> On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner
> wrote:
> >
> > On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote:
> > > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
> > > >
> > > > On 08.01.22
On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner wrote:
>
> On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote:
> > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
> > >
> > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
> > > > Note, as for byteswapping,
On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
> >
> > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
> > > Note, as for byteswapping, apparently it wasn't ever working right fox
> > > the IBM extended
On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
>
> On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
> > Note, as for byteswapping, apparently it wasn't ever working right fox
> > the IBM extended real(kind=16) and complex(kind=16).
>
> The lack of bug reports since the
On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
Note, as for byteswapping, apparently it wasn't ever working right fox
the IBM extended real(kind=16) and complex(kind=16).
The lack of bug reports since the conversion feature was introduced in
2006, more than 15 years ago, tells us
On Sat, Jan 08, 2022 at 12:10:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> One reason for that is that neither conversion is lossless, neither format
> is a subset or superset of the other. Yes, IEEE quad has both much bigger
> exponent range (-16382..16383 vs. -1022..1023) and slightly
On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> And IMHO the default like for byte-swapping should be the native
> format, i.e. the one the program actually used.
One reason for that is that neither conversion is lossless, neither format
is a subset or superset of
On Sat, Jan 08, 2022 at 11:07:24AM +0100, Thomas Koenig wrote:
> I have tried to unravel the different cases here, I count six
> (lumping together the environment variables, the CONVERT specifier
> and -fconvert, and leaving out the byte swapping)
>
> CompilerConvert Read action Write
On 07.01.22 22:48, Jakub Jelinek wrote:
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:
One thing that one has to watch out for is a big-endian IBM long double
file, so the byte swapping will have to be done before assigning
the value.
I've tried to handle that right, i.e. on
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:
> One thing that one has to watch out for is a big-endian IBM long double
> file, so the byte swapping will have to be done before assigning
> the value.
I've tried to handle that right, i.e. on unformatted read with
byte-swapping and
On 07.01.22 20:52, Jakub Jelinek wrote:
Here is completely untested patch that implements something,
but doesn't implement the gcc option stuff, nor the CONVERT=
syntax to supply multiple conversion options nor done anything
about env var nor any testcases.
But it tries to have the
On Fri, Jan 07, 2022 at 11:26:15AM +0100, Thomas Koenig wrote:
> In
>
> https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html
>
> I made a suggestion how how the format could look like. I used
> a plus sign instead of a comma because I thought the environment
> variable should follow
On 07.01.22 10:22, Jakub Jelinek wrote:
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
On 06.01.22 06:00, Michael Meissner via Fortran wrote:
What is still missing is the conversion for unformatted I/O, both
ways. I'll start doing some stuff on it. Just one question:
What
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll start doing some stuff on it. Just one question:
> What are functions that I can use to
14 matches
Mail list logo
