Re: *PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar
This one looks OK. Sorry I missed it earlier. Thanks again for the patch! Jerry On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote: *Ping* Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran: Dear Fortranners, when initializing parameter arrays from scalars, we did handle only the case init->expr_type == EXPR_CONSTANT, which misses the case of derived types. As a consequence the constructor for the r.h.s. was not set up, which later led to different ICEs. To solve this I looked at gfc_simplify_spread. I was contemplating whether to also copy the logic to make this initialization dependent on -fmax-array-constructor. I chose not to, because there is no sensible and simple fallback available to handle that case while allowing the access to array elements. We could instead make that a warning. Comments / opinions? Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is an ICE on valid, potentially useful code, I'd like to backport this to 11-branch. Thanks, Harald
Re: [Patch] [v2] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)
Re-sent with gzipped attachment as gcc-patches@ did reject it as being too
large.
Alternatively, you can find it at
https://gcc.gnu.org/pipermail/fortran/attachments/20211009/dc26f92d/attachment-0001.bin
as fortran@ contrary to gcc-patches@ did accept the patch ...
Tobias
On 09.10.21 23:48, Tobias Burnus wrote:
Hi all,
attached is the updated version. Changes:
* Handle noncontiguous arrays – with BIND(C), (g)Fortran needs to make it
contiguous in the caller but also handle noncontiguous in the callee.
* Fixes/handle 'character(len=*)' with BIND(C); those always use an
array descriptor - also with explicit-size and assumed-size arrays
* Fixed a bunch of bugs, found when writing extensive testcases.
* Fixed type(*) handling - those now pass properly type and elem_len
on when calling a new function (bind(C) or not).
Besides adding the type itself (which is rather straight forward),
this patch only had minor modifications – and then the two big
conversion functions.
While it looks intimidating, it should be comparably simple to
review as everything is on one place and hopefully sufficiently
well documented.
OK – for mainline? Other comments? More PRs which are fixed?
Issues not yet fixed (which are inside the scope of this patch)?
(If this patch is too long, I also have a nine-day old pending patch
at https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580624.html )
Tobias
PS: The following still applies.
On 06.09.21 12:52, Tobias Burnus wrote:
gfortran's internal array descriptor (xgfc descriptor) and
the descriptor used with BIND(C) (CFI descriptor, ISO_Fortran_binding.h
of TS29113 / Fortran 2018) are different. Thus, when calling a BIND(C)
procedure the gfc descriptor has to be converted to cfi – and when a
BIND(C) procedure is implemented in Fortran, the argument has to be
converted back from CFI to gfc.
The current implementation handles part in the FE and part in
libgfortran,
but there were several issues, e.g. PR101635 failed due to alias issues,
debugging wasn't working well, uninitialized memory was used in some
cases
etc.
This patch now moves descriptor conversion handling to the FE – which
also
can make use of compile-time knowledge, useful both for diagnostic
and to
optimize the code.
Additionally:
- Some cases where TS29113 mandates that the array descriptor should be
used now use the array descriptor, in particular character scalars
with
'len=*' and allocatable/pointer scalars.
- While debugging the alias issue, I simplified 'select rank'. While
some
special case is needed for assumed-shape arrays, those cannot
appear when
the argument has the pointer or allocatable attribute. That's not
only a
missed optimization, pointer/allocatable arrays can also be NULL -
such
that accessing desc->dim.ubound[rank-1] can be uninitialized memory
...
OK? Comments? Suggestions?
* * *
For some more dumps, see the discussion about the alias issue at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578364.html
("[RFH] ME optimizes variable assignment away / Fortran bind(C)
descriptor conversion")
plus the original emails:
- https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578271.html
- and (correct dump)
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578274.html
Debugging - not ideal but not too bad either. For
subroutine f(x) bind(C)
integer :: x(:)
with an uninitialized size-4 array as argument:
m::f (_x=...) at foo4.f90:3
3 subroutine f(x) bind(C)
(gdb) p x
Cannot access memory at address 0x38
(gdb) p _x
$6 = ( base_addr = 0x7fffe2c0, elem_len = 4, version = 1, rank =
1 '\001', attribute = 2 '\002', type = 1025, dim = (( lower_bound =
0, extent = 5, sm = 4 )) )
(gdb) s
5 x(1) = 5
(gdb) p x
$7 = (0, 0, 0, -670762413, 0)
Tobias
PS: This patch fixes but not necessarily fully the following PRs:
PR fortran/102086 - [F2008][TS29113] Accepts invalid scalar TYPE(*)
as actual argument to assumed-rank
PR fortran/92189 - Fortran-written bind(C) function with allocatable
argument does not update C descriptor on exit
PR fortran/92621 - Problems with memory handling with allocatable
intent(out) arrays with bind(c)
PR fortran/101308 - Bind(C): gfortran does not create C descriptors
for scalar pointer/allocatable arguments
PR fortran/101635 - FAIL: gfortran.dg/PR93963.f90 – alias-handling
issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
PR fortran/92482 - BIND(C) with array-descriptor mishandled for type
character
and possibly some more.
PPS: I should add some additional testcases – I try to do this as
Part 2 of this patch.
PPPS: Once the patch is in, some audit needs to be done which parts
of those PRs remain
as follow-up work. I think some still existing issues are covered by
José's pending
patches + for those which are now fixed, the testcase might still be
added.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße
201, 80634 München; Gesellschaft mit beschränkter Haftung;
Geschäftsf
*PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar
*Ping* Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran: Dear Fortranners, when initializing parameter arrays from scalars, we did handle only the case init->expr_type == EXPR_CONSTANT, which misses the case of derived types. As a consequence the constructor for the r.h.s. was not set up, which later led to different ICEs. To solve this I looked at gfc_simplify_spread. I was contemplating whether to also copy the logic to make this initialization dependent on -fmax-array-constructor. I chose not to, because there is no sensible and simple fallback available to handle that case while allowing the access to array elements. We could instead make that a warning. Comments / opinions? Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is an ICE on valid, potentially useful code, I'd like to backport this to 11-branch. Thanks, Harald
Re: [PATCH] PR fortran/65454 - accept both old and new-style relational operators
Hi Jerry, > Gesendet: Samstag, 09. Oktober 2021 um 00:28 Uhr > Looks all good Harald, OK and thanks for the support! Thanks for the quick review! Harald
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote: > > > On 09.10.21 01:18, Iain Sandoe wrote: >>> I meant the case where the user writes, with an old, KIND=16 is double >>> double compiler, >>> >>> subroutine foo(a) >>>real(kind=16) :: a >>>a = a + 1._16 >>> end subroutine foo >>> >>> and puts it in a library or an old object file, and in new code with an >>> IEEE QP compiler calls that with >>> >>> real(kind=16) :: a >>> a = 2._16 >>> call foo(a) >>> print *,a >>> >>> this will result in silent generation of garbage values, since Fortran >>> does not mangle the function name based on it types. For both cases, the >>> subroutine will be called foo_ (or MOD..._foo). >> hmm, well I thought about that case, but … isn’t this “pilot error”? >> if one compiles different parts of a project with incompatible command line >> options… >> … or, say, compile with -mavx512 and then try to run code on hardware without >> such a vector unit? >> Getting wrong answers silently can likely be done with other command line >> option mismatches. > > Again, it depends. > > What I was thinking about what a scenario where we do not change the > SONAME on POWER and rely on name mangling to get to the correct version > of a libgfortran library function. That could work, but it would not > work for user procedures. What I’m missing is why it has to. IF the user wants to use old (or not-owned) code compiled for double-double, then she must select a command-line option to use that on Power(New). Else The user recompiles all the code in her project to use the new shiny QP. I doubt there’s a way for this to proceed in a way that a user of Power (New) can avoid having to think it through - a new library SO name won’t help them with the interop with thier own (or not owned) code. > I have thought of mangling the name of all user Fortran procedures > which contain a reference to an IEEE QP in their argument list, like > _foo%QP, but that would fall down for C interop. So, no luck there. agreed, I did the same thought exercise. > So, a new SONAME at least on POWER is mandatory, I think. > > The question is still if we can avoid a new SONAME for >99% of our users > for no gain at all for them. Is there a possibility of aliasing the > SONAME somehow (grasping at straws here)? > > Best regards > > Thomas
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote: > The question is still if we can avoid a new SONAME for >99% of our users > for no gain at all for them. Is there a possibility of aliasing the > SONAME somehow (grasping at straws here)? I'd hope Debian can just ln -sf libgfortran.so.5 libgfortran.so.6 as their libgfortran6 package for non-ppc64le and make it depend on libgfortran5 if they really want to do something and GCC itself doesn't need to care, except for libgfortran/Makefile.in which would need to adjust `grep -v '^\#' $(srcdir)/libtool-version` to conditionally (for ppc64le only) sed 's/^5:/6:/' in it). Jakub
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 09.10.21 01:18, Iain Sandoe wrote: I meant the case where the user writes, with an old, KIND=16 is double double compiler, subroutine foo(a) real(kind=16) :: a a = a + 1._16 end subroutine foo and puts it in a library or an old object file, and in new code with an IEEE QP compiler calls that with real(kind=16) :: a a = 2._16 call foo(a) print *,a this will result in silent generation of garbage values, since Fortran does not mangle the function name based on it types. For both cases, the subroutine will be called foo_ (or MOD..._foo). hmm, well I thought about that case, but … isn’t this “pilot error”? if one compiles different parts of a project with incompatible command line options… … or, say, compile with -mavx512 and then try to run code on hardware without such a vector unit? Getting wrong answers silently can likely be done with other command line option mismatches. Again, it depends. What I was thinking about what a scenario where we do not change the SONAME on POWER and rely on name mangling to get to the correct version of a libgfortran library function. That could work, but it would not work for user procedures. I have thought of mangling the name of all user Fortran procedures which contain a reference to an IEEE QP in their argument list, like _foo%QP, but that would fall down for C interop. So, no luck there. So, a new SONAME at least on POWER is mandatory, I think. The question is still if we can avoid a new SONAME for >99% of our users for no gain at all for them. Is there a possibility of aliasing the SONAME somehow (grasping at straws here)? Best regards Thomas
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On Okt 09 2021, Thomas Koenig via Fortran wrote: > There is no choice - we need to make object code compiled by the user > incompatible between the old and the new format on the systems where > we make the switch. If you link, but not recompile, object files compiled against different versions of glibc, you are in for surprises, too. This isn't something new. There is no guarantee of API stability. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
