This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]