On 12/05/2014, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Mon, 12 May 2014, Matthias Klose wrote: > >> I didn't look close enough to the gfortran test results. PR driver/61126 >> is a >> fix for the regression introduced with the fix for the above issue. With >> this >> patch proposed by Manuel, gfortran.dg/wextra_1.f now passes, and no new >> regressions seen on the trunk and the branches. > > I think changing the order of the handlers has far too high a risk of > introducing further nonobvious regressions to consider it for the > branches. You need a clear and careful analysis of the circumstances > under which the order of the handlers can affect observable compiler > behavior in order to justify such a change as safe. But I think a better > principle is that if the order matters, there is a bug in those handlers > and they should be fixed so that the order doesn't matter (absent a clear > design showing why it is desirable for the order to matter)
(Resending because Android Gmail is defective by design, sorry Joseph and Matthias. ) The only way I can think of making the handlers robust to any ordering is to have a flag per option that says which handler has set up which option, so if a default value has been setup by the FE, then the common handler does not override it. That seems much more complex and wasteful than simply decree by design that targets can override FEs and FEs can override common defaults, but not in the other direction. It is the only order that makes sense to me. I will be very surprised if the common defaults are overriding a FE default and it is not a bug in the FE. The other alternative is to move -Wunused-parameter out of common.opt, and have each FE define the same default, except Fortran. That seems also a unnecessary duplication.
