This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR fortran/9972
- From: Jan Hubicka <jh at suse dot cz>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, Jan Hubicka <jh at suse dot cz>,gcc-patches at gcc dot gnu dot org, Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Tue, 13 May 2003 20:51:09 +0200
- Subject: Re: [PATCH] PR fortran/9972
- References: <email@example.com> <200305131837.OAA30140@makai.watson.ibm.com>
> >>>>> Zack Weinberg writes:
> Zack> So what I think you're saying is that the Fortran front end relies on
> Zack> dead function elimination happening whether or not optimization is
> Zack> enabled?
> Probably not intentionally, but yes. I think it "just worked"
I was looking into that testcase before I left to Barcelona (I am
leaving till sunday tomorrow again, so I won't be able to fix it before
that, so I would be happy if you manage to find proper fix).
Fortran is really intentionally relying on dead inline functions not
being emit (but does not require them to be inlined). I intended to
teach fortran frontend to simply not produce them, but didn't managed to
do that yet (it is very dificult as fortran frontend design is still in
the dark for me)
It is not exactly extern inline not even static inline, so in case we
can't fix the fortran, we would need to somehow invent new category for
> The Fortran testcase essentially is testing for Fortran behavior
> equivalent to GCC C "static inline" extension. This only works if the
> statement is deferred and then the lack of any reference prevents the
> function from being emitted. Honza's patch make f771 behave as if
> -fkeep-inline-functions were enabled, so the statement always is emitted.
> The statement explicitly references an undefined function to produce a
> link error if the statement compiled.