Janus Weil wrote:
As the comment says which the patch is removing, the gfc_match_varspec
should be relevant for cases like this:
print *,char_func()(1:3)
print *,array_func()(2)
print *,derived_type_func()%comp
Are we sure that all of these are actually invalid? (At least they are
rejected by g
Hi Mikael,
>> And then, the call to gfc_match_varspec shouldn't be there in the first
>> place. I'll test the following later.
>
> It seems like the parts you're removing have essentially been there
> since day zero. Would be interesting to know if (and where) your patch
> fails.
actually I just
>> Indeed, that's invalid:
>>
> And then, the call to gfc_match_varspec shouldn't be there in the first
> place. I'll test the following later.
It seems like the parts you're removing have essentially been there
since day zero. Would be interesting to know if (and where) your patch
fails.
Cheers
Le 13/04/2013 17:44, Mikael Morin a écrit :
> Indeed, that's invalid:
>
And then, the call to gfc_match_varspec shouldn't be there in the first
place. I'll test the following later.
Index: primary.c
===
--- primary.c (révision
Le 13/04/2013 16:02, Janus Weil a écrit :
> Hi Mikael,
>
>> So, it seems that EXPR_FUNCTION is acceptable in gfc_match_varspec.
>> And then, there is nothing preventing 'c(i)' in 'c(i)%encM()' from being
>> parsed as a function. Is this supported?
>
> I think this is forbidden by the Fortran st
Hi Mikael,
>> Unless someone has a better idea how to treat this, I will commit the
>> attached patch as obvious.
>>
> Not really a better idea, but it seems to me that function calls can
> have trailing sub-references, so that gfc_match_varspec could be called
> on them.
>
> gfc_match_rvalue has:
Hello,
Le 12/04/2013 20:38, Janus Weil a écrit :
> Unless someone has a better idea how to treat this, I will commit the
> attached patch as obvious.
>
Not really a better idea, but it seems to me that function calls can
have trailing sub-references, so that gfc_match_varspec could be called
on t
Hi all,
here is a small patch which fixes an ICE-on-invalid problem by simply
turning a "gcc_assert" into a MATCH_ERROR. I am aware that the
resulting error message ("Unclassifiable statement") is not the most
helpful one, but I couldn't come up with something better.
The problem is that "c(i)" i
