https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2019-01-16
CC| |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, like that problematic source, all gfortran options used to compile that,
any needed modules too + stubbed whatever it calls and whatever is needed in
MAIN__ or main to reproduce, ideally with minimal dependencies.
If you know the exact problematic routine, see in the debugger how many times
it is called and in which invocation of the routine it misbehaves and try to
capture on which arguments it is called. If you don't know the exact
problematic routine, one can e.g. play with assembly bisection between
-funroll-loops and no -funroll-loops, rename .L* labels in one of them so that
it can be merged by hand more easily. I think gfortran doesn't have optimize
(0) attribute yet.
