This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3


Dear All,

I had some unexpected regressions, which turned out to be associated
with mulling over FX's problem with intrinsic IEEE modules.

Sending        gcc/fortran/ChangeLog
Sending        gcc/fortran/module.c
Sending        gcc/fortran/trans-decl.c
Sending        gcc/testsuite/ChangeLog
Sending        gcc/testsuite/gfortran.dg/public_private_module_2.f90
Sending        gcc/testsuite/gfortran.dg/public_private_module_6.f90
Sending        gcc/testsuite/gfortran.dg/submodule_1.f08
Adding         gcc/testsuite/gfortran.dg/submodule_10.f08
Sending        gcc/testsuite/gfortran.dg/submodule_5.f08
Sending        gcc/testsuite/gfortran.dg/submodule_9.f08
Sending        gcc/testsuite/lib/fortran-modules.exp
Transmitting file data ...........
Committed revision 226622.

The final step is documentation and wiki updates.

Cheers

Paul

On 4 August 2015 at 11:40, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Dear Mikael,
>
> Thanks for your comments. I will commit the patch tonight. If folk get
> steamed up about .smod files appearing when they compile their
> favourite non-submodule-based code, I guess that we can put in a
> compilation flag to suppress them. We have plenty of time to tweak
> this before the release of 6 branch.
>
> Once committed, I will get on with the documentation and updating of
> gfortran wiki.
>
> Cheers
>
> Paul
>
> On 3 August 2015 at 17:39, Mikael Morin <mikael.morin@sfr.fr> wrote:
>> Le 03/08/2015 14:36, Paul Richard Thomas a Ãcrit :
>>>
>>> Dear Mikael,
>>>
>>> Thanks for your green light!
>>>
>>> I have been mulling over the trans-decl part of the patch and having
>>> been wondering if it is necessary.
>>
>> You mean marking entities as public?  Or setting the hidden visibility
>> attribute?  Or both?
>> I think both are necessary.
>>
>>> Without optimization, private
>>> entities can be linked to. Given the discussion concerning the
>>> combination of submodules and private entities, I wonder if this is
>>> not sufficient? Within submodule scope, an advisory could be given for
>>> undefined references to suggest recompiling the module without
>>> optimization or making the entities public.
>>>
>> About recompiling without optimization:
>> If the module contains no code, I guess that would be OK.
>> But otherwise, it would be pretty bad.
>> And one would have to do the same for submodules of a submodule: the parent
>> submodule would be compiled without optimization. :-(
>>
>> About making the entities public:
>> I think the goal of submodules is providing a way to specify a (hopefully)
>> stable interface free of any internal implementation details that users
>> would start playing with if the opportunity was given to them.  Making all
>> entities public would go against that.
>>
>>
>> I've been reading about the hidden visibility attribute since you submitted
>> the 3/3 patch(es).  I think it's the right thing. :-)
>>
>> Mikael
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]