It is not quite the same thing as “undefined behavior” in C/C++, but the Fortran standards have always said that they describe conforming programs and conforming implementations only. But the Fortran standards are not as well known to Fortran users as the C standards are to C programmers, and what really seems to matter most is that Fortran programs not change behavior when compiled by new releases of compilers (or new compilers); existing precedents need to be respected unless there’s a good reason to the contrary. Unlike C/C++, there’s not much new development taking place in Fortran, and the primary motivation is preserving the value of existing Fortran codes, standard or otherwise.
In the case of SHIFTR with a negative shift count, every Fortran compiler I tried that supports SHIFTR – which is a Fortran 2008 feature intended to avoid the runtime sign test on the shift count of the “MIL-SPEC” bit intrinsic ISHFT – returns 0 in that case on x86-64. There may be codes out there that rely on that behavior, no matter what the standards say. And that’s the de facto standard that f18 needs to implement, absent a really compelling reason to the contrary.
(That said, the constant folding code for SHIFTR will emit a compile-time error if a shift count is a known constant that is negative or excessive, but I will not hesitate to change that to a warning if some user complains and can’t change their code.)