Tobias,
> succeeds with your patch, but without it.
was supposed to be "succeeds with your patch, but not without it."
I also understand what happened when the test was split in two files:
If the module file is compiled with the patched compiler, then the test
succeed with ot without the patch.
Tobias,
> However, after I wrote that, I saw that there is a dg-*
> which permits to check the .mod file for a string.
Are you sure it works now the *.mod files are gzipped?
AFAICT it does not.
The following test
MODULE generalFunctions
USE, INTRINSIC :: ISO_FORTRAN_ENV
IMPLICIT NONE
INTEGER
Paul Richard Thomas wrote:
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?
What
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
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
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 impu
