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: RFC: Enabling -fwhole-file by default


Paul Richard Thomas wrote:
>> I think -fwhole-file is now stable enough to be enabled by default; one
>> can still use -fno-whole-file to disable it. (Though, I like to remove
>> that "no" option in the next release, i.e. 4.7.)
> 
> I don't think that I can agree to that, largely for legacy reasons.  I
> see no harm in leaving the option and would suggest that for
> std=legacy it is automatically set.

I am against setting -fno-whole-file for -std=legacy: Without
-fwhole-file gfortran generate wrong declarations, which cause the
middle end to do wrong alias/dependency analysis. I think problems that
pop up should be solved differently - not by falling back to generating
multiple declarations. But let's see first how many problems pop up; its
more still more one year until GCC 4.7's stage3 ends ...

>> With the two patches mentioned above and the attached patch, I only see
>> one test-suite failure:
>>  gfortran.dg/common_resize_1.f
>> where a warning about different COMMON sizes disappears with
>> -fwhole-file (cf. PR 45045 and related PR 45044). I would suggest to
>> XFAIL that check if we cannot fix it soon.
> 
> mmm!  I am not sure that I like that.  I wonder why it happens?
> Remind me in a couple of weeks, when I am back from vacation.
>
> I think that we should try and fix the failure.  It's most odd that it
> should appear with -fwhole-file.  Maybe the XFAIL is good but make
> sure that we all remember it.

I wonder whether the -fwhole-file issue and the order issue is one and
the same bug or whether those are two independent bugs. But as we have
two open PRs for the XFAIL we shouldn't forget it.

>> Jakub might want to have a look at the libgomp/testsuite/ change.

> Write the ChangeLog  and get it committed!
> OK for trunk :-)

Thanks for the review!


Steven Bosscher wrote:
> I think this should also depend on whether there are still all those
> middle-end hacks we used to have for the -fno-whole-file case. Honza?

I think there are no middle-end hacks for -fno-whole-file. But as I do
know the middle end well, nor its history, I am likely wrong. I know
that there are some hacks for wrong decls _with_ -fwhole-file for LTO.
Some of the problems of the "wrong" decls are unavoidable given how the
C/Fortran/... languages are standardized.* The other decl issues should
be solved.

Tobias

* I am thinking of unnamed commons which can be of variable length or
"void *" ("type(c_ptr)") being the only C interoperable pointer data
type in Fortran.


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