public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: Tobias Burnus <tobias@codesourcery.com>, fortran <fortran@gcc.gnu.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]
Date: Wed, 15 Mar 2023 20:36:41 +0100	[thread overview]
Message-ID: <89b856a2-5e90-5858-44ae-ba22c8903697@gmx.de> (raw)
In-Reply-To: <099717a7-2de0-c71a-f9fa-58095e691898@codesourcery.com>

Hi Tobias,

Am 15.03.23 um 10:10 schrieb Tobias Burnus:
> Hi Harald,
>
> On 14.03.23 20:38, Harald Anlauf wrote:
>> The testcase covers only non-coarray cases, as playing with
>> coarray variants hit pre-exisiting issues in gfortran that
>> are very likely unrelated to the interface checks.
> I concur (but would not rule out additional interface issues).

More testing seems to mostly uncover issues later on in trans*.cc,
e.g. when passing type to class.  I'll open a PR on this as a followup.

>> I consider this rather as post 13-release stuff.
> In any case, the coarray issue can be fixed separately. And I think
> post-GCC-13 makes sense.

Good.

>> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> Thanks – LGTM!
>> +  formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as
>> +                                       : formal->as;
>> +
>
> (Jakub remarks for such code that some editor (emacs?), he does not use,
> mis-<tab>-auto-indent such a code - and proposes to add a parentheses
> around the right-hand side of the assignment.)

Ah, adding parentheses helps!  I've reformatted this block accordingly.
Pushed as:

https://gcc.gnu.org/g:901edd99b44976b3c2b13a7d525d9e315540186a

> * * *
>
> I also wonder whether we need some run-time testcase. The interface
> check now works and I also tend to write dg-do-compile testcases, but
> given what can go wrong with all the array descriptor, class etc
> handling, we may want to ensure it works at run time. – Thoughts?

If you comment out the lines with dg-error, the code compiles
and seems to run fine here.  I've even found cases where passing
array sections works correctly here and with current Intel it
does not ;-)

I'd prefer to postpone more elaborate run-time tests until we have
more non-ICEing related code.

Thanks,
Harald

> (That's independent of the patch it and could be done as follow up, if
> it deemed reasonable. The included testcase is surely compile-only as it
> has dg-error checks.)
>
> Tobias
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955
>


WARNING: multiple messages have this Message-ID
From: Harald Anlauf <anlauf@gmx.de>
To: gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org
Subject: Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]
Date: Wed, 15 Mar 2023 20:36:41 +0100	[thread overview]
Message-ID: <89b856a2-5e90-5858-44ae-ba22c8903697@gmx.de> (raw)
Message-ID: <20230315193641.joxUNcXk2-FpMNKZTPmIYbVH6amd4uDqoSKDxz9nwDE@z> (raw)
In-Reply-To: <099717a7-2de0-c71a-f9fa-58095e691898@codesourcery.com>

Hi Tobias,

Am 15.03.23 um 10:10 schrieb Tobias Burnus:
> Hi Harald,
> 
> On 14.03.23 20:38, Harald Anlauf wrote:
>> The testcase covers only non-coarray cases, as playing with
>> coarray variants hit pre-exisiting issues in gfortran that
>> are very likely unrelated to the interface checks.
> I concur (but would not rule out additional interface issues).

More testing seems to mostly uncover issues later on in trans*.cc,
e.g. when passing type to class.  I'll open a PR on this as a followup.

>> I consider this rather as post 13-release stuff.
> In any case, the coarray issue can be fixed separately. And I think
> post-GCC-13 makes sense.

Good.

>> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> Thanks – LGTM!
>> +  formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as
>> +                                       : formal->as;
>> +
> 
> (Jakub remarks for such code that some editor (emacs?), he does not use,
> mis-<tab>-auto-indent such a code - and proposes to add a parentheses
> around the right-hand side of the assignment.)

Ah, adding parentheses helps!  I've reformatted this block accordingly.
Pushed as:

https://gcc.gnu.org/g:901edd99b44976b3c2b13a7d525d9e315540186a

> * * *
> 
> I also wonder whether we need some run-time testcase. The interface
> check now works and I also tend to write dg-do-compile testcases, but
> given what can go wrong with all the array descriptor, class etc
> handling, we may want to ensure it works at run time. – Thoughts?

If you comment out the lines with dg-error, the code compiles
and seems to run fine here.  I've even found cases where passing
array sections works correctly here and with current Intel it
does not ;-)

I'd prefer to postpone more elaborate run-time tests until we have
more non-ICEing related code.

Thanks,
Harald

> (That's independent of the patch it and could be done as follow up, if
> it deemed reasonable. The included testcase is surely compile-only as it
> has dg-error checks.)
> 
> Tobias
> 
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: 
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; 
> Registergericht München, HRB 106955
> 



  reply	other threads:[~2023-03-15 19:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 19:38 Harald Anlauf
2023-03-15  9:10 ` Tobias Burnus
2023-03-15 19:36   ` Harald Anlauf [this message]
2023-03-15 19:36     ` Harald Anlauf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89b856a2-5e90-5858-44ae-ba22c8903697@gmx.de \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).