Re: Code optimization: warning for code that hangs
On Sat, Jun 23, 2012 at 5:30 PM, Ian Lance Taylor wrote:
> "Peter A. Felvegi" writes:
>
>> My question is: wouldn't it be possible to print a warning when a jmp
>> to itself or trivial infinite recursion is generated? The code
>> compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7.
>
> This question is not appropriate for the mailing list gcc@gcc.gnu.org,
> which is for discussions about the development of GCC. It would be
> appropriate for gcc-h...@gcc.gnu.org. Please take any followups to
> gcc-help. Thanks.
>
> I'm not yet convinced that a -Wall warning would be worth the effort in
> this case. You have basically come up with a complicated way to write
>
> void f() { f(); }
>
> I suppose I think it would be reasonable to issue a -Wall warning for
> code like that. The trick is detecting it. Obviously there is nothing
> wrong with a recursive call. What is different here is that the
> recursive call is unconditional. I don't see a way to detect that
> without writing a specific warning pass to look for that case. And I
> think this case is rare enough, and easy enough to discover in other
> ways, that I don't think a warning would be worth the cost in
> compilation time and compiler maintenance.
>
> If the problem can be detected cheaply in the course of an existing
> pass, I would support a warning.
I suppose you could rely on detecting the CFG form of an uncontional
goto to an empty block from that block - the above recursion should
have been eliminated by the tail-recursion pass.
The issue with this kind of warnings is always that they are issued
even when the endless loop might not be reached at runtime.
Richard.
> Ian
Re: Code optimization: warning for code that hangs
"Peter A. Felvegi" writes: >>> My question is: wouldn't it be possible to print a warning when a jmp >>> to itself or trivial infinite recursion is generated? The code >>> compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7. Note that if the target architecture is a microcontroller, an endless loop can be a legitimate way to finish / abort the program.
Re: Code optimization: warning for code that hangs
On 6/24/2012 11:22 AM, Richard Guenther wrote: I suppose I think it would be reasonable to issue a -Wall warning for code like that. The trick is detecting it. Obviously there is nothing wrong with a recursive call. What is different here is that the recursive call is unconditional. I don't see a way to detect that without writing a specific warning pass to look for that case. Ada has this warning, and it has proved useful!
Re: Code optimization: warning for code that hangs
On 6/24/2012 12:09 PM, Ángel González wrote: "Peter A. Felvegi" writes: My question is: wouldn't it be possible to print a warning when a jmp to itself or trivial infinite recursion is generated? The code compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7. Note that if the target architecture is a microcontroller, an endless loop can be a legitimate way to finish / abort the program. But not an infinite recursion! And an endless loop is such a rare case that it deserves a warning, it's a false positive in this case, so what?
Re: Code optimization: warning for code that hangs
On 24/06/12 23:54, Robert Dewar wrote: On 6/24/2012 12:09 PM, Ángel González wrote: "Peter A. Felvegi" writes: My question is: wouldn't it be possible to print a warning when a jmp to itself or trivial infinite recursion is generated? The code compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7. Note that if the target architecture is a microcontroller, an endless loop can be a legitimate way to finish / abort the program. But not an infinite recursion! And an endless loop is such a rare case that it deserves a warning, it's a false positive in this case, so what? An endless loop is not rare - as Ángel says, it is standard practice in embedded systems. Typical systems can have more than one such loop - the main loop is usually endless, and you often have some sort of "halt" or "wait for watchdog reset" endless loop. Most such loops are not simple "jump to yourself" instructions - but some are (with other actions being triggered by interrupts). In the majority of cases, however, it should be possible to mark the function in question as "noreturn". In fact, when I think about it, perhaps a "-Wsuggest-attribute=noreturn" will give people the warning they want? After all, if the compiler can work out that the best code is a "jump to yourself" instruction, it should also have noted that the function does not return.
gcc-4.8-20120624 is now available
Snapshot gcc-4.8-20120624 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120624/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 188918 You'll find: gcc-4.8-20120624.tar.bz2 Complete GCC MD5=f1adf36b8864f3e922bc7c560ae860b4 SHA1=11e69b32805250007240b9e027a4722b7fff3fbf Diffs from 4.8-20120617 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
