[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 09:19:09 UTC ---
(In reply to comment #16)
> (In reply to comment #3)
> > A way to tell gcc a variable is not uninitialized is to perform
> > self-initialization like
> > 
> >  int i = i;
> > 
> > this will cause no code generation but inhibits the warning.  Other compilers
> > may warn about this construct of course.

> The only good solution would be to fix the bug. I've checked that it is still
> there in the trunk revision 197260 (current Debian's gcc-snapshot).

If you mean to fix the false warning, then you are likely to wait a long long
time (in order of years) because it doesn't seem a trivial thing to fix and
there are very very few people with enough GCC knowledge to fix it (and they
are busy with other things).

What would be trivial to fix (but require persistence, patience and time) is to
implement this idea:

http://gcc.gnu.org/ml/gcc/2010-08/msg00297.html

that is, either  __attribute__ ((initialized))

or _Pragma("GCC diagnostic ignored \"-Wuninitialized\"").

(Personally, I prefer the latter, since it reuses existing code).

Add as a follow-up, get rid of the non-portable valgrind-unfriendly i=i idiom
that has caused so much grief over the years.

However, we still need someone with the persistence, patience and time to
implement this and get it past the powers that be.
>From gcc-bugs-return-420450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 09:29:28 2013
Return-Path: <gcc-bugs-return-420450-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19699 invoked by alias); 17 Apr 2013 09:29:28 -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 19485 invoked by uid 48); 17 Apr 2013 09:28:56 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
Date: Wed, 17 Apr 2013 09:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56982-4-BpwOZ4WBe8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56982-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01595.txt.bz2
Content-length: 1123


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV982

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-17 09:28:55 UTC ---
#include <stdio.h>
#include <setjmp.h>

static sigjmp_buf env;
static inline int g (int x)
{
  if (x)
    {
      fprintf (stderr, "Returning 0\n");
      return 0;
    }
  else
    {
      fprintf (stderr, "Returning 1\n");
      return 1;
    }
}
__attribute__ ((noinline))
void bar (int n)
{
  if (n == 0)
    exit (0);
  static int x;
  if (x++) abort ();
  longjmp (env, 42);
}
int
f (int *e)
{
  int n = *e;
  if (n)
    return 1;
  int x = setjmp (env);
  n = g (x);
  fprintf (stderr, "x = %i, n = %i\n", x, n);
  bar (n);
}
int
main ()
{
  int v = 0;
  return f (&v);
}

Adjusted testcase that fails even with GCC 4.7.2 at -O2, works with -O2
-fno-dominator-opts (which disables uncprop).  Again, I don't see how
this could be declared invalid, while n is declared before the setjmp, it is
not live across the setjmp call.  This adjusted testcase regressed in April
2005 (i.e. 4.1+ regression).