http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633
--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-02-13 00:05:09 UTC --- On Sat, Feb 12, 2011 at 11:29:47PM +0000, tkoenig at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 > > Thomas Koenig <tkoenig at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tkoenig at gcc dot gnu.org > > --- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-02-12 > 23:29:25 UTC --- > (In reply to comment #4) > > The testcase is bad, because for vanilla gcc releases there is no > > (prerelease) > > etc. string at all (DEV-PHASE is empty), and because it hardcodes ASCII > > values, > > so I'm afraid it could fail on EBCDIC or other targets. > > I don't think gfortran supports EBCDIC very well right now. At least > the LLE and other functions don't take this into account. > These functions specifically assume ascii. For Fortran 2003: The intrinsic functions LGT, LGE, LLE, and LLT (13.7.63-13.7.66) provide comparisons between strings based on the ASCII collating sequence. International portability is guaranteed if the set of characters used is limited to the letters, digits, underscore, and special characters. See also Note 4.15: The intrinsic functions ACHAR (13.7.2) and IACHAR (13.7.45) provide conversion between characters and corresponding integer values according to the ASCII collating sequence.
