http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Joost VandeVondele from comment #10) > (In reply to Marc Glisse from comment #9) > > Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my > > current patch would handle it. It is hard for gcc to guess that > > _gfortran_os_error is safe. > > For the Fortran FE people (not me, I'm a user), but _gfortran_os_error > should have an attribute like 'abort' or 'noreturn'. abort doesn't exist, and noreturn is not sufficient, as a function that calls free on the pointer then exits is noreturn but unsafe. > However, the compiler > should also be able to figure out this can never be called (if B is > 'allocated on the stack') in this subroutine. Yes. > > Er, no, I missed the call to s2. I would also need some attribute on s2 so > > the compiler knows that s2 doesn't do anything too weird. > > Actually, in Fortran, S2 can't do anything 'weird' with B, in the sense that > your optimization should certainly apply. Not so sure about the correct > terms here, but in approximate C-speak, B 'as a pointer' is guaranteed to be > pointing to exactly the same address, nothing has happened to its target, > and no pointer can be pointing to whatever B was pointing to.... So S2 cannot call free (or realloc) on the pointer and then exit or call longjmp or do an infinite loop or anything like that in fortran? Maybe we'll need a flag set by the front-end that says whether (all) functions are safe.
