[Bug c/53871] New: Please warn about endless loops if they are obvious

[Bug c/53871] New: Please warn about endless loops if they are obvious

[tim.ruehsen at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

             Bug #: 53871
           Summary: Please warn about endless loops if they are obvious
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tim.ruehsen@gmx.de


Obvious endless loops could be reported, e.g. if the loop condition doesn't
change and the loop can't be left otherwise.

Example:
// x is declared non-volatile
while (x!=0);

while (x!=0) {
  a++;
}

An optional -Wendless-loop could detect such issues with all kind of loops.

splint 3.1.2 says about the above axamples:

Suspected infinite loop.  No value used in loop test (a) is modified by test or
loop body.
  This appears to be an infinite loop. Nothing in the body of the loop or the
  loop test modifies the value of the loop test. Perhaps the specification of a
  function called in the loop body is missing a modification. (Use -infloops to
  inhibit warning)

[Bug c/53871] Please warn about endless loops if they are obvious

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-07-07 07:11:23 UTC ---
(In reply to comment #0)
> Obvious endless loops could be reported, e.g. if the loop condition doesn't
> change and the loop can't be left otherwise.

There has been discussions about this since more than ten years ago and nothing
has happened:

http://gcc.gnu.org/ml/gcc/1999-08n/msg00720.html

My understanding is that the probability of an existing GCC dev implementing
this is very close to zero for various reasons: People are busy with other
things, not trivial to implement for non-trivial code, risk of being too noisy,
and there are other tools better at this job like splint and Clang's static
analyzer.

I can see some advantages in implementing this in GCC (sharing code, working in
any GCC FE), but those are not enough to make current developers drop what they
are doing and put time and effort on this.

So someone else will have to step up to the task. I suggest that you implement
it as a plugin and demonstrate that it works and it is not too noisy.

[Bug c/53871] Please warn about endless loops if they are obvious

[tim.ruehsen at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

--- Comment #2 from Tim Ruehsen <tim.ruehsen at gmx dot de> 2012-07-09 11:50:19 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > Obvious endless loops could be reported, e.g. if the loop condition doesn't
> > change and the loop can't be left otherwise.
> 
> There has been discussions about this since more than ten years ago and nothing
> has happened:
> 
> http://gcc.gnu.org/ml/gcc/1999-08n/msg00720.html

More than 12 years of discussions... sigh.

> My understanding is that the probability of an existing GCC dev implementing
> this is very close to zero for various reasons: People are busy with other
> things, not trivial to implement for non-trivial code, risk of being too noisy,
> and there are other tools better at this job like splint and Clang's static
> analyzer.

Neither splint nor clang understands gcc/ibm/intel nested functions, which I
use a lot (yes, I know of the stack execution issue). Clang community so far
refused to implement it, they propably never will. At least they have 'blocks'
which might be a good alternative to nested functions.
Splint isn't developed since 2007. Many years ago, I put nested functions on
splint's wishlist - same answer as yours: "go and implement it yourself !". (If
I had time to to that, I wouldn't have put it on the wishlist but created a
patch.)

Maybe it's time for a gcc static analyzer...

[Bug c/53871] Please warn about endless loops if they are obvious

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-07-09 13:59:58 UTC ---
(If
> I had time to to that, I wouldn't have put it on the wishlist but created a
> patch.)

I have thought a lot how to attract more and new developers to GCC who will be
willing to develop things that are not a priority for current developers, but I
don't have any solution to offer. It is a difficult problem: You and I see
value in your proposal, but not enough value to compensate for the required
time we would need to dedicate to it. The only solution is to have enough
developers so that the time dedicated by each of them is small enough to be
worth it. But there is not such pool of developers.

> Maybe it's time for a gcc static analyzer...

In terms of technology, never has been a better time than now: GCC internals
have never been as clean and re-usable, there is some interest in
modularization, there is now the possibility of creating powerful plugins, etc.
However, in terms of human resources, there is simply no one interested in
working on this, for the reasons given above. Hence, someone new will need to
appear: either a new company, a new group of developers, or a charismatic and
committed developer that can rally existing developers around him/her.

[Bug c/53871] Please warn about endless loops if they are obvious

[tim.ruehsen at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

--- Comment #4 from Tim Ruehsen <tim.ruehsen at gmx dot de> 2012-07-10 07:58:26 UTC ---
(In reply to comment #3)
> I have thought a lot how to attract more and new developers to GCC who will be
> willing to develop things that are not a priority for current developers, but I
> don't have any solution to offer.

There is not one solution, but a mixture of approaches may attract some
developers.
What about these "Summer of Code" things, why not writing articles for
developer magazins. There is a need for good and easy tutorials about GIMPLE
and gcc plugins.

After your last post, I read about gcc plugins - very interesting indeed.
A quick search revealed some articles/tutorials, but non of them gave me an
"instant kick" to rush into. As far as I could see, you have to be an GIMPLE
expert, before you start reading one of these articles. That might discourage
some potential plugin developers.


> However, in terms of human resources, there is simply no one interested in
> working on this, ...

I am a senior developer, and I use gcc every day. But I wasn't aware of gcc's
plugin feature. Just spread the word and you might get some interested people.

[Bug c/53871] Please warn about endless loops if they are obvious

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kuq03132 at qoika dot com

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 63388 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-462705-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 12:38:44 2014
Return-Path: <gcc-bugs-return-462705-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11871 invoked by alias); 27 Sep 2014 12:38:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11821 invoked by uid 48); 27 Sep 2014 12:38:36 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63388] cout of enum class value - segmentation fault
Date: Sat, 27 Sep 2014 12:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc resolution
Message-ID: <bug-63388-4-RgWMhv7RA2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63388-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63388-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02539.txt.bz2
Content-length: 756

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org
         Resolution|INVALID                     |DUPLICATE

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> I guess it would be possible to have an optional warning, late in the
> optimization process, when we see an empty infinite loop:

Indeed. Such warning is an old request...

*** This bug has been marked as a duplicate of bug 53871 ***
>From gcc-bugs-return-462707-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 13:18:41 2014
Return-Path: <gcc-bugs-return-462707-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23803 invoked by alias); 27 Sep 2014 13:18:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23744 invoked by uid 48); 27 Sep 2014 13:18:32 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on  x86_64-apple-darwin*
Date: Sat, 27 Sep 2014 13:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58321-4-ax4HpHW0yK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58321-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58321-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02541.txt.bz2
Content-length: 1623

https://gcc.gnu.org/bugzilla/show_bug.cgi?idX321

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Would the following patch be acceptable?

--- ../_clean/gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c    2014-05-10
23:13:06.000000000 +0200
+++ gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c    2014-09-27
15:15:50.000000000 +0200
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=atom
-mmemcpy-strategy=vector_loop:2000:align,libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memcpy" 2  } } */
+/* { dg-final { scan-assembler-times "memcpy" 2 { target { ! *-*-darwin* } } }
} */
+/* { dg-final { scan-assembler-times "memcpy" 1 { target i?86-*-darwin*
x86_64-*-darwin* } } } */

 char a[2048];
 char b[2048];
--- ../_clean/gcc/testsuite/gcc.target/i386/memset-strategy-1.c    2014-05-10
23:13:02.000000000 +0200
+++ gcc/testsuite/gcc.target/i386/memset-strategy-1.c    2014-09-27
15:14:08.000000000 +0200
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=atom -mmemset-strategy=libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memset" 2  } } */
+/* { dg-final { scan-assembler-times "memset" 2 { target { ! *-*-darwin* } } }
} */
+/* { dg-final { scan-assembler-times "memset" 1 { target i?86-*-darwin*
x86_64-*-darwin* } } } */

 char a[2048];
 void t (void)

[Bug c/53871] Please warn about endless loops if they are obvious

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53871

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org,
                   |                            |egallager at gcc dot gnu.org,
                   |                            |kuq03132 at qoika dot com

--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #3)
> (In reply to Tim Ruehsen from comment #2)
> > Maybe it's time for a gcc static analyzer...
> 
> In terms of technology, never has been a better time than now: GCC internals
> have never been as clean and re-usable, there is some interest in
> modularization, there is now the possibility of creating powerful plugins,
> etc. However, in terms of human resources, there is simply no one interested
> in working on this, for the reasons given above. Hence, someone new will
> need to appear: either a new company, a new group of developers, or a
> charismatic and committed developer that can rally existing developers
> around him/her.

So, David Malcolm has contributed a static analyzer to GCC now; cc-ing him...