This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: [Patch, fortran] PR17741 - ICE in gfc_free_namespace, at fortran/symbol.c:2208


On Friday 12 May 2006 05:32, Paul Thomas wrote:
> Paul,
>
> >>This isn't user-friendly at all.
>
> At least it is better than the ICE, which does nothing other than give a
> bad impresion of gfortran.

I disagree. The compiler is broken, so it should ICE. Turning an ICE into a 
user error is not the correct solution. This ICE is no different to any other 
internal error. The check is there to make the compiler terminate instead of 
continuing with known bad state and either segfaulting or generating bad 
code.

This assert is checking for a double free of a structure. My guess would be 
it's only by pure luck that we hit the ICE instead of segfaulting.

> >I agree. The compiler has got itself confused and tried to do something
> > that should never happen. An ICE is the correct response.
>
> We have no reports of this happening with anything other than illegal
> code.  

That's irelevant. We've already issues an error message about that.
The bug is that gfortran's error recovery is broken.

> The ICEs might be fine for the maintainers but frighten potential 
> users of gfortran away.  If anybody else can be troubled to sort out how
> to exit from this low likelehood, illegal code then all strength to
> them.  

I don't see how tunring it into a user error help at all. It just means that 
instead of the user saying "gfortran fell over after I fed it illegal code" 
they say "gfortran generates bizarre error messages that have nothing to do 
with the code I fed it.". The difference is that an ICE admits it's a bug. A 
user error implicitly makes it a feature, and blames it on the user. 

Your error message complains about references to namespaces being freed. The 
obvious user reaction to this is "But my code isn't freeing anything".

It's true that the compiler should never ICE. But the compiler shouldn't have 
any bugs in it either. Turning an inconvenient ICE into a user error is not 
the solution.

This is covered in the gnu coding conventions 
http://www.gnu.org/prep/standards/html_node/Semantics.html

"In error checks that detect "impossible" conditions, just abort. There is 
usually no point in printing any message".

> As it is, the PR is just going to sit there depressing us. 

Fix the bug properly then.

Paul


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