[Patch, Fortran] PR32359 OpenMP threadprivate: SAVE is implied by explicit initialization

[Tobias Burnus]

Daniel Franke wrote:
> any specific reason why you high-jacked that PR? I had it already assigned to me :)
>   
I somehow missed that :-(

> Comments to your patch: it fixes only the one issue with threadprivate,
>   
> Instead of fixes them one by one, I'd suggest to change the save-attribute in 
> in 'symbol_attribute' from a boolean to a tri-state, say: SAVE_NONE = 0, 
> SAVE_EXPLICIT, SAVE_IMPLICIT.

Granted, but attr.save is used only very rarely in the code and the use
seems to be ok. (I have to admit, I got lost in trans-array.c and
trans-common.c; I don't see whether attr.save or attr.save ==
SAVE_EXPLICIT is needed there. I think the change is ok with regards to
trans-*.c.)

However, your patch missed the following use of the "SAVE" statement:
   integer :: y
   save

How about something like the attached patch?

The testsuites libgomp & gfortran have no failures but:
gfortran.dg/module_md5_1.f90; after glancing at module.c I still don't
quite understand why, but I get the MD5 sum:
MD5:2acedc3d584fad6aae6248078b02aa38 instead of
MD5:18a257e13c90e3872b7b9400c2fc6e4b. As the distinction between
SAVE_IMPLICIT and SAVE_EXPLICIT is lost, when reading/writing a mod file
(the distinction should not be needed for use-associated symbols), I
don't see how the MD5 sum could possibly change.

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save-gomp.diff
Type: text/x-patch
Size: 4629 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070616/17b70a8b/attachment.bin>