*PING* [PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

[Harald Anlauf via Fortran]

*PING*

Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:

Dear Fortranners,

when debugging the testcase, I noticed that a coarray declaration in
a COMMON statement wrongly set the dimension attribute instead of the
codimension.  As a consequence, subsequent checks that catch this
invalid situation would not trigger.

I see two possible solutions:

- in gfc_match_common, replace

  /* Deal with an optional array specification after the
 symbol name.  */
  m = gfc_match_array_spec (&as, true, true);

   by

   m = gfc_match_array_spec (&as, true, false);

   which in turn would lead to a syntax error.  Interestingly, the Intel
   compiler also takes this route and gives a syntax error.

- check the resulting as->corank and emit an error as in the attached
   patch.

The attached patch regtests fine on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

Re: [RFC] User-visible changes for powerpc64-le-linux ABI changes

[Michael Meissner via Fortran]

On Tue, Nov 02, 2021 at 07:19:10AM +0100, Thomas Koenig wrote:
> 
> 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 if it possible.
> 
> > But, if we don't bump it, we need to keep double double there backwards
> > compatible (i.e. _r16 etc. being the double double, not IEEE).
> 
> Correct.  I would actually go for 17 for the IEEE because it is
> the larger number, but that is a pure style issue and has no
> impact on something that is user visible :-)
> 
> > When in the future we bump the soname, we can swap those two and
> > make _r16 newly stand for IEEE quad and _r15 or _r16d or whatever
> > for double double.
> 
> Yep.
> 
> We do need to do something about the generated module files, though, to
> make programs compiled with one option incompatible with the other ones
> on that level.

In general, I wouldn't expect mixing and matching long double options to work.
But you do want the library to have both versions of the library functions with
different names.

And as I've found out, outside of the official libraries, you run into smaller
libraries (like gmp, mpfr, and mpc used in the compiler) that also need to be
compiled with the right options because they have random functions that have
long double elements (even if the app doesn't use the long double arguments).
For example, in the C world, we need to have 3 versions of each of the *printf
functions, since printf can be passed long double.

> Or are people expected to get that right? :-)

In terms of testing, it isn't ideal, but if you make a branch that we (IBM) can
access, we can run it on our various systems.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com