This is the mail archive of the gcc@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]

Re: New const function detection code and infinite loops.



> The current const detection code in the mainline sources will not
> mark f as const since it is externally visable and void type.  It
> will however mark f as const in the following example:
> 
>   static int f() {
>     while (1);
>     return 0;
>   }

(It would be nice to issue a warning for this function, as it cannot
return a value).

>   int main () {
>     f();
>     abort();
>   }
> 
> I take it that this example is also guaranteed not to call abort according
> to the ANSI C standard?

Yes.  People who have never programmed embedded systems often think
that only programs that terminate are interesting, but it common in
embedded systems to write processes that are intended to run forever.
So a compiler definitely cannot change a loop that runs forever to one
that does not!

> I can prepare a patch to fix the problem (Jan, let me know if you're
> already handling this).  BTW, is it easily provable that a loop will
> always terminate, or must we simply avoid marking the function as const
> if any type of loop construct is present?

There is no algorithm (it is proven that there is no algorithm) for
detecting, in general, that a loop terminates.  However, there are many
special cases where it is trivial to prove that the loop terminates
(e.g. simple for-loops) or that it cannot (the one in your example).

So we should avoid marking the function as const if a loop construct is
present, unless we know that the loop will always terminate.

> I guess this raises for me a more general question of how loops (any type
> of loop) should be handled.  Loops create delays (infinite loops merely
> create infinite delays :-).  At what point is a delay considered an
> observable event that is part of the program's behavior and should not
> be changed by the compiler?  Granted an infinite loop is somewhat a
> special case.

I think that only the infinite loop matters.  RMS wanted to never remove
empty loops because they might be used for timing, but there are better
ways of doing timing loops.


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