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 conver
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 are
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
I've just tried to build libgfortran on an old glibc system
(gcc112.fsffrance.org) an
On Fri, Jan 07, 2022 at 12:29:25PM +0100, Jakub Jelinek wrote:
> we don't do it consistently:
> readelf -Wr
> /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0
> | grep ieee128
> 00250310 01280015 R_PPC64_JMP_SLOT
>
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261, which introduced this new form of
gfc_conv_gfc_desc_to_cfi_desc.
The patch
Hi Jakub,
00251038 06ad0015 R_PPC64_JMP_SLOT
__cabsieee128 + 0
All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
So, seems all these come from f951 compiled sources.
For user code, I think the agreement was if you want to use successfull
On Fri, Jan 07, 2022 at 03:25:57PM +0100, Thomas Koenig wrote:
> > > 00251038 06ad0015 R_PPC64_JMP_SLOT
> > > __cabsieee128 + 0
> > > All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
> >
> > So, seems all these come from f951 compiled sources
On Thu, 2022-01-06 at 17:20 +0100, Martin Jambor wrote:
> Hello,
>
> another year is upon us and Google has announced there will be again
> Google Summer of Code 2022 (though AFAIK there is no specific timeline
> yet). I'd like to volunteer to be the main Org Admin for GCC again so
> let me know
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 th
Hi Paul,
Am 07.01.22 um 14:42 schrieb Paul Richard Thomas via Fortran:
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261, w
Hi Jakub,
So, the following patch adds -fbuilding-libgfortran option and uses
it together with TARGET_GLIBC_M* checks to decide whether to use
libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran
and not glibc or glibc is older than 2.32) or glibc 2.32 APIs
(otherwise). This
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 native/swap
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
13 matches
Mail list logo
