[Patch, Fortran] PRs 60283/60543: Fix two wrong-code bugs related for implicit pure

[Paul Richard Thomas]

Dear Tobias,

The patch looks OK to me.  If nothing else, it offers a
rationalisation of all the lines of code that unset the attribute!

I am somewhat puzzled by "Note: I failed to create a test case",
wheras I find one at the end of the patch.  Can you explain what you
mean?

Cheers

Paul

On 19 March 2014 21:21, Tobias Burnus <burnus@net-b.de> wrote:
> Early *ping*  - I think this wrong-code GCC 4.7/4.8/4.9 issue is pretty
> severe.
>
>
> Tobias Burnus wrote:
>>
>> This patch fixes two issues, where gfortran claims that a function is
>> implicit pure, but it is not. That will cause a wrong-code optimization in
>> the middle end.
>>
>> First problem, cf. PR60543, is that implicit pure was not set to 0 for
>> calls to impure intrinsic subroutines. (BTW: There are no impure intrinsic
>> functions.) Example:
>>
>>   module m
>>   contains
>>     REAL(8) FUNCTION random()
>>       CALL RANDOM_NUMBER(random)
>>     END FUNCTION random
>>   end module m
>>
>>
>> The second problem pops up if one adds a BLOCK ... END BLOCK around the
>> random_number call after applying the patch of the PR, which just does:
>> gfc_current_ns->proc_name->attr.implicit_pure = 0.
>>
>> The problem is that one sets only the implicit_pure of the block to 0 and
>> not of the function. That's the reason that the patch became much longer and
>> that I added gfc_unset_implicit_pure as new function.
>>
>> Thus, the suspicion I had when reviewing the OpenACC patches turned out to
>> be founded. Cf. PR60283.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk and for the 4.7 and 4.8 branches?
>>
>> Note: I failed to create a test case.
>>
>> Tobias
>
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy