[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605

--- Comment #9 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #8)
> > If so, then the ICE was not caused by my diagnostic changes, it just exposes a
> > problem that has been latent or introduced later. Thus, I'm not planning to
> > investigate further.
> 
> Well, I think that is caused by your diagnostic changes, but is due to a
> conflicting definition of -Wunused-parameter in C* and gfortran which now
> share the same code (?).

It could be when we changed Fortran options to use the common options
machinery. But that sounds strange anyway, because -Wunused-parameter would
have enabled the middle-end warning in any case. I cannot find any code that
disabled the warning before my changes. In fact, this same testcase in GCC
4.5.1 (way before my changes!) had the middle-end option enabled but it didn't
give any warning.

> I am not sure if it is too late or not to change the name of the option in
> one of the front end. If it is too late, is it possible for the fortran FE
> to rename internally the option before passing it to the ME?

It could simply set:

{
 int tmp_warn_unused_parameter = warn_unused_parameter;
 warn_unused_parameter = 0
 cgraph_node::finalize_function (fndecl, true);
 warn_unused_parameter= tmp_warn_unused_parameter;
}

But it seems quite ugly to me. It would be better to understand why the
middle-end thinks it is unused (perhaps Fortran needs to mark it as used or
mark it with TREE_NO_WARNING?).

In fact, the exact same code in GCC 4.5.1 has TREE_NO_WARNING set in the
PARAM_DECL corresponding to time, but I'm not sure where it is set.

The middle-end warning also shows that the location given by Fortran to the
PARAM_DECL is very poor.

I still think this is a latent bug in the way that Fortran is generating the
PARAM_DECL for time, but if the Fortran maintainers are not interested in
investigating that, then I could prepare a patch with any of the work-arounds I
have proposed above as soon as a Fortran maintainer (someone that will approve
the patch) chooses one.