This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH/fortran] Add option to make 1st error fatal
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: V??clav Haisman <V dot Haisman at sh dot cvut dot cz>
- Cc: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sun, 30 Oct 2005 13:36:43 -0800
- Subject: Re: [PATCH/fortran] Add option to make 1st error fatal
- References: <20051030205832.GB19911@troutmask.apl.washington.edu> <436539C6.4030209@sh.cvut.cz>
On Sun, Oct 30, 2005 at 10:23:18PM +0100, V??clav Haisman wrote:
>
> > The attached patch has been bootstrapped and regression
> > tested on i386-*-freebsd.
> >
> > What does it do? Consider the source in PR fortran/23538.
> > This code will cause gfortran to go into an infinite loop,
> > which isn't too unexpected in that that code is F66. However,
> > to try to debug the codei and/or gfortran, one see 438 error
> > messages fly by the screen. Many of these errors are simply
> > cascaded from an earlier error are somewhat bogus. This
> > patch disables the output of warnings and the first encountered
> > error is fatal. For example, instead of 438 errors, I now get
> >
> > kargl[213] gfc41 -c -ffatal pr23538.f
> > In file pr23538.f:308
> >
> > 37 format(*0absolute addresses of first,nbaxo + nelpaz in elpa*3o21)
> > 1
> > Error: Unexpected element in format string at (1)
> >
> >
> > OK for mainline?
> >
> Isn't there some (probably) unwritten rule that -ffoo is reserved for
> flags that influence code generation, like optimizations and such?
>
> Vaclav Haisman
I've been in discussion with Andrew Pinski on IRC. He has
requested the option be renamed to -Wfatal-error. I'm
currently updating the patch.
PS: Don't top post.
--
steve