> On 8 Oct 2021, at 23:55, Thomas Koenig via Gcc wrote:
>
>
> Hi Iain,
>
>>> Things get interesting for user code, calling a routine compiled
>>> for double double with newer IEEE QP will result in breakage.
>> That would not happen with the proposal above, since the library would
>> have di
Hi Thomas,
recognising that this is complex - the intent here is to see if there are ways
to partition the problem (where the pain falls does depend on the choices
made).
perhaps:
*A library (interface, name)
*B compiler internals
*C user-facing changes
> On 8 Oct 2021, at 17:26, Thomas K
Hi Iain,
Things get interesting for user code, calling a routine compiled
for double double with newer IEEE QP will result in breakage.
That would not happen with the proposal above, since the library would
have different entry points for the two formats.
I meant the case where the user wri
On 10/8/21 2:33 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. We internally distinguish between old and new style,
but try to map appropriately when used.
This mapping was missing when r
Dear Fortranners,
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. We internally distinguish between old and new style,
but try to map appropriately when used.
This mapping was missing when reading a module via
USE module, ONLY: OPERATOR(op)
where
On Wed, Oct 06, 2021 at 11:42:11PM -0400, Michael Meissner wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>There is also the issue of binary dat
Hi Sandra
On 08.10.21 18:58, Sandra Loosemore wrote:
I concur that that should be in a separate PR.
It's PR102641 now.
Thanks.
OK to commit v2 of the patch (attached)?
OK – thanks for the patch!
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 20
On Wed, Oct 06, 2021 at 10:03:59PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > With "not in any" I mean: not for other architectures either! All archs
> > that do not say anything about floating point in their machine
> > description get a working sofware floatin
On 10/7/21 9:25 AM, Tobias Burnus wrote:
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actu
Hi Iain,
If one wanted to prioritize library SO name stability - then, perhaps, the
approach Jonathan mentioned has been used for libstdc++ (add new
symbols for ieee128 with a different mangling to the existing r/c_16 ..)
would be preferable (the FE then has to choose the relevant symbol/
mangli
> On 8 Oct 2021, at 07:35, Thomas Koenig via Fortran
> wrote:
>
>
> On 07.10.21 17:33, Jakub Jelinek wrote:
>>> It will also be a compatibility issue if users have code compiled on a LE
>>> system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
>> libgfortran ABI changed
11 matches
Mail list logo
