https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #14 from Andy May <ajmay81 at googlemail dot com> --- (In reply to Jerry DeLisle from comment #13) > (In reply to Andy May from comment #12) > > I don't know that it's necessary or desired to support both '\n' and '\r' as > > eol, but instead the native eol just needs to be used consistently > > everywhere, for example something like the following pseudo code: > > > > #ifdef __MINGW32__ > > #define EOL '\r' > > #else > > #define EOL '\n' > > #endif > > ... > > dtp->u.p.at_eol = (c == EOL || c == EOF); > > > > Each compiler may choose to do this a little differently. In our case we > see /r and look for the /n to eat it. If one is interested in reading a /r > as data one should use access="stream" which allows you to do what ever you > want. > > I could do something like the above, but it would touch quite a few places > in the code which opens it up for mistakes and regressions (admittedly > probably not any more than we get now and we could improve maintainability). > Our personal time is a factor too. I have bigger bugs to fry and I don't > get paid to do this. I do it in my spare time for the greater good of all. > Regardless I do appreciate all input in this process of "open" software. (I > should further audit the code when I get a chance) Of course, I really appreciate the work that goes into this. I've already made a local patch file with your fix so that the mxe.cc gcc builds with it and now our program runs correctly. I look after a project with ~2.5 million lines of Fortran, some which were written 40 years ago on punch cards. Gfortran is the only compiler where I don't have to play games deoptimizing some files etc. during compilation (beyond using -fno-aggressive-loop-optimizations), and if I see a problem with Gfortran compiled code my first instinct is always to look for a bug in our code rather than the compiler. Thanks once again for your efforts, and please just let me know if there is anything I can do to help out.
