This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: Someone has caused regressions in gfortran


> > Because of the famous duplicated declaration problem
> 
> This sentence is reminding me that I forgot to send the following update:
> 
> As I said I was going to give it a shot over the week-end, here's an
> update on this: it won't make it into 4.3, because it's a big change
> and my current patch is triggering a very long string of
> ice-on-invalid-code bugs (all type mismatches in Fortran interfaces
> for procedures end up dying badly) as well as a few ice-on-valid-code
> that are currently hard to track (and might be preexisting front-end
> bugs exposed by the patch). I intend to work slowly on this, and
> hopefully will have put a complete patch together when 4.4 stage1
> opens.

Huh, still I would be interested in seeing the patch.
> 
> > I am not sure if
> > inlining is not completely unsafe for fortan and we would not be forced
> > to disable it completely (not just partly as before the patch).  This
> > would be rather sad.
> 
> I think the current situation is safe: we can online local functions
> (functions declared and inside other functions), which are the Fortran
> CONTAIN'ed functions. This should be safe, while all other inlining is
> currently impossible.

Can we trick fotran to set DECL_UNINLINABLE in the non CONTAIN'ed
functions?

Honza
> 
> FX


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