This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR52864 - fix actual/formal checks
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Tue, 24 Apr 2012 21:45:13 +0200
- Subject: Re: [Patch, Fortran] PR52864 - fix actual/formal checks
- References: <4F86F38C.email@example.com>
On 12/04/2012 17:23, Tobias Burnus wrote:
> This patch is a kind of follow up to the other one for the same PR -
> though this one is for a separate test case, it is not a regression and
> it's about actual/formal checks.
> When trying to fix the rejects-valid bug, I realized that one function
> was never accessed as a call to expr.c's gfc_check_vardef_context is
> done before. I made some cleanup and added some code to ensure pointer
> CLASS are correctly handled. I am not positive that the removed code is
> unreachable, but I failed to produce reachable code and also the test
> suit passed.
> Thus, this patch removed a rejects-valid bug, an accepts-invalid bug,
> cleans up the code a bit and adds a test case for existing checks
> (besides testing the bug fixes).
> Build and regtested on x86-64-linux.
> OK for the trunk?
Hello, is there a reason to guard the class_pointer condition with
attr.class_ok in the first conditional and with CLASS_DATA(...) != NULL
in the two other ones?
Not that it matters much, and in fact, I think the patch as is is good
enough for committal (yes, it is a OK).
I'm asking as I never know myself what is the correct, canonical way to
handle the class_* hell...