This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
- From: "ajmay81 at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 22 Apr 2016 11:00:33 +0000
- Subject: [Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
- Auto-submitted: auto-generated
- References: <bug-70684-4 at http dot gcc dot gnu dot org/bugzilla/>
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.