Then, the patch is OK for trunk :-)
Thanks for putting this right - it's obviously my cock-up!
Cheers
Paul
On 15 October 2013 22:20, Tobias Burnus wrote:
> Hi Paul,
>
>
> Paul Richard Thomas wrote:
>>
>> Have you checked that:
>>
>> subroutine sub(a)
>>class(*),pointer :: a
>>a => nu
Hi Paul,
Paul Richard Thomas wrote:
Have you checked that:
subroutine sub(a)
class(*),pointer :: a
a => null()
end subroutine
does not give an error? I think that it is why the check was introduced.
I haven't checked it in particular, but was relying that some test in
the library wou
Hi Tobias,
Have you checked that:
subroutine sub(a)
class(*),pointer :: a
a => null()
end subroutine
does not give an error? I think that it is why the check was introduced.
Cheers
Paul
On 13 October 2013 09:51, Tobias Burnus wrote:
> *PING*: http://gcc.gnu.org/ml/fortran/2013-10/msg00
Le 07/10/2013 23:31, Tobias Burnus a écrit :
> The patch is rather obvious. The question is just why was the check
> there at the first place.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
OK. Thanks.
Mikael
*PING*: http://gcc.gnu.org/ml/fortran/2013-10/msg00018.html
Additionally, I'd like to early ping for the do concurrent patch:
http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html , even if the ME
review is still pending.
Tobias Burnus wrote:
The patch is rather obvious. The question is just wh
The patch is rather obvious. The question is just why was the check
there at the first place.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-10-07 Tobias Burnus
PR fortran/58658
* expr.c (gfc_check_vardef_context): Fix pointer diagnostic
for CLASS(*).
2013-10-07
