https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On February 12, 2019 9:40:46 AM GMT+01:00, "tkoenig at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689 > >Thomas Koenig <tkoenig at gcc dot gnu.org> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > >--- Comment #13 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- >Thanks for the analysis (and the patch). Now for the >interesting question, what to do with it... > >On the one hand, we must avoid at all costs is to break >compatibility with pre-compiled libraries, at least while >we do not change the ABI for another reason. > >On the other hand, this is quit a serious bug, which especially >affects old Fortran codes. > >At least the problem is on the caller side, which means that >we could fix the caller without affecting the callee. > >So, what are the options? > >After checking if the patch from comment #12 does the right >thing (which I don't know), we could > >a) apply it globally, after checking that it does not break > binary compatibility on all relevant platforms (quite risky > for stage 4, I think) > >b) apply it #ifdefed for POWER > >I think both options would need an OK from a release manager due >to us being in stage 4 (plus from a POWER maintainer for option b) > >Or we could defer this to gcc 10, but I would prefer for this bug >to be fixed sooner rather than later. I haven't checked the details of the incorrectness of the function decl or its type. Given the error is on the caller side only the chances of breakage are low. Still I would suggest to fix on trunk only for now and skip the imminent 8.3 to allow for fallout to pop up. Richard.
