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 <bur...@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
