On 01.11.21 18:45, Jakub Jelinek wrote:
Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
-mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
ABI compatible with both, then we don't need to bump soname.
Sounds like one major pain solved. I think we should do i
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Projects): Add bullet for helping with
incomplete standards compliance.
(Proposed Extensions): Delete section.
---
gcc/fortran/gfortran.texi | 92 ---
1 file ch
2021-11-01 Sandra Loosemore
gcc/fortran/
* intrinsic.texi (Introduction to Intrinsics): Genericize
references to standard versions.
* invoke.texi (-fall-intrinsics): Likewise.
(-fmax-identifier-length=): Likewise.
---
gcc/fortran/intrinsic.texi | 15
2021-11-01 Sandra Loosemore
gcc/fortran/
* intrinsic.texi (Introduction to Intrinsics): Genericize
references to standard versions.
* invoke.texi (-fall-intrinsics): Likewise.
(-fmax-identifier-length=): Likewise.
---
gcc/fortran/intrinsic.texi | 15
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Interoperability with C): Copy-editing. Add
more index entries.
(Intrinsic Types): Likewise.
(Derived Types and struct): Likewise.
(Interoperable Global Variables): Likewise.
(Inte
Fix various bit-rot in the discussion of standards conformance, remove
material that is only of historical interest, copy-editing. Also move
discussion of preprocessing out of the introductory chapter.
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (About GNU Fortran
Discussion of conformance with various revisions of the
Fortran standard was split between two separate parts of the
manual. This patch moves it all to the introductory chapter.
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Standards): Move discussion of specific
This series of patches addresses some areas of bit-rot in the GNU
Fortran manual, mainly relating to the state of standard compliance
and the recently-completed TS29113 work. I also removed some material
that is primarily of historical interest; given that gfortran replaced
g77 almost 17 years ago
Dear Fortranners,
a recent patch uncovered a latent issue with simplification of
array-valued expressions where the resulting shape was not set
from the referenced subobject. Once found, the fix looks obvious.
Regtested on x86_64-pc-linux-gnu. OK?
Thanks,
Harald
Fortran: fix simplification of
With my documentation maintainer hat on, I've been working on updating
the standards compliance and TS29113-related material in the GNU Fortran
manual (patches will be posted soon). I also spent some time going
through the related wiki pages a few days ago to get them updated as well.
For F20
On Mon, Nov 01, 2021 at 10:54:27AM -0500, Bill Schmidt wrote:
> Hi Thomas,
>
> To me this looks excellent. If you feel that support for both forms is
> achievable,
> that's certainly superior. We had previously been concerned about whether the
> necessary name mangling support would be possible
On Mon, Nov 01, 2021 at 06:32:51PM +0100, Thomas Koenig wrote:
> f->value.function.name
> = gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
> f->ts.kind);
>
> Easy enough to add something there if ts.type is BT_REAL,
> ts.kind is 16 and the compiler
Hi Bill,
We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.
We can always add a letter to the kind number, or use a different
number in the encoding, or someting
This has to be done i
Would starting from Advance Toolchain 15 with the most recent glibc make things
easier for Thomas to test?
Thanks,
Bill
On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote:
> On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote:
>> Hi Michael,
>>
>> I tried this out on the one POWER mac
Hi Thomas,
To me this looks excellent. If you feel that support for both forms is
achievable,
that's certainly superior. We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.
I'll let Mike
15 matches
Mail list logo
