[Bug tree-optimization/60165] New: "may be used uninitialized" warning with -O3 but not with -O2

[Bug tree-optimization/60165] New: "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

            Bug ID: 60165
           Summary: "may be used uninitialized" warning with -O3 but not
                    with -O2
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net

With:

gcc (Debian 20140111-1) 4.9.0 20140111 (experimental) [trunk revision 206552]

I get the following inconsistency in the warnings:

ypig% cat out.i
int a, b;
int fn2 (int, int);
int fn1 (int *p1)
{
    if (fn2 (a, 0))
        *p1 = b;
    int c;
    fn1 (&c);
    return c;
}
ypig% gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O2 out.i
ypig% gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O3 out.i
out.i: In function 'fn1':
out.i:9:5: error: 'c' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
     return c;
     ^
cc1: some warnings being treated as errors
ypig% 

I don't know whether this is regarded as normal, but this looks strange.

Note: I got this problem when compiling round_prec.c from the GNU MPFR trunk. I
generated the preprocessed file with -E, then used creduce on the following
script:

#!/bin/sh
{
  gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O2 out.i && \
  ! gcc-snapshot -c -Wall -Werror=maybe-uninitialized -O3 out.i
} >/dev/null 2>&1

to generate the simple testcase (and fixed the declarations to avoid additional
warnings -- I think I should have used -Werror in the script to avoid them in
the first place).

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Well, the code paths in question do not necessarily exist (you could say the
same thing with -O2, where the function is not inlined: there may be some code
paths for which fn1() doesn't initialize c).

Actually the number of "maybe-uninitialized" warnings should decrease when the
optimization level increases, because of additional knowledge, not the
opposite.
>From gcc-bugs-return-443438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 08:47:27 2014
Return-Path: <gcc-bugs-return-443438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8363 invoked by alias); 13 Feb 2014 08:47:26 -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 8280 invoked by uid 48); 13 Feb 2014 08:47:23 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 08:47: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: bug_status resolution
Message-ID: <bug-60165-4-aRKPy0Zwbi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01195.txt.bz2
Content-length: 1588

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #2)
> Well, the code paths in question do not necessarily exist (you could say the
> same thing with -O2, where the function is not inlined: there may be some
> code paths for which fn1() doesn't initialize c).

The code path exists in the code, the fact that perhaps in your program such
code path is never taken doesn't mean it is undesirable to warn about it.
GCC has two kinds of warnings, the is uninitialized one where particular code,
if executed, will always use uninitialized value, and maybe uninitialized,
where it will use uninitialized value only conditionally.  That is the case
here.
> 
> Actually the number of "maybe-uninitialized" warnings should decrease when
> the optimization level increases, because of additional knowledge, not the
> opposite.

No, usually with more inlining it increases and should.  When fn1 is not
inlined, GCC intentionally does not warn that c might be uninitialized because
maybe the function call could use the value or not set it unconditionally, that
would lead to so huge amount of false positives for the warning that nobody
would be willing to use the warning.
>From gcc-bugs-return-443439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 08:56:18 2014
Return-Path: <gcc-bugs-return-443439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11413 invoked by alias); 13 Feb 2014 08:56:18 -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 11371 invoked by uid 48); 13 Feb 2014 08:56:13 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60167] [4.8/4.9 regression] Bogus error: conflicting declaration
Date: Thu, 13 Feb 2014 08:56: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority bug_status cf_reconfirmed_on cc target_milestone short_desc everconfirmed
Message-ID: <bug-60167-4-3pUcSZtbKW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60167-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60167-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-02/txt/msg01196.txt.bz2
Content-length: 1009

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`167

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-13
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org
   Target Milestone|---                         |4.8.3
            Summary|[4.9 regression] Bogus      |[4.8/4.9 regression] Bogus
                   |error: conflicting          |error: conflicting
                   |declaration                 |declaration
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r207167 and in r207189 has been introduced on the 4.8 branch as
well.

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Vincent Lefèvre from comment #2)
> > Well, the code paths in question do not necessarily exist (you could say the
> > same thing with -O2, where the function is not inlined: there may be some
> > code paths for which fn1() doesn't initialize c).
> 
> The code path exists in the code, the fact that perhaps in your program such
> code path is never taken doesn't mean it is undesirable to warn about it.
> GCC has two kinds of warnings, the is uninitialized one where particular
> code, if executed, will always use uninitialized value, and maybe
> uninitialized, where it will use uninitialized value only conditionally. 
> That is the case here.

Where it of course still only assumes that the function is entered at all.
>From gcc-bugs-return-443443-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 09:21:40 2014
Return-Path: <gcc-bugs-return-443443-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26489 invoked by alias); 13 Feb 2014 09:21: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 26330 invoked by uid 48); 13 Feb 2014 09:21:37 -0000
From: "joey.ye at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/60166] ARM default NAN encoding violates EABI
Date: Thu, 13 Feb 2014 09:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joey.ye at arm dot com
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60166-4-LZKpg9bWj8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60166-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60166-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-02/txt/msg01200.txt.bz2
Content-length: 233

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`166

--- Comment #2 from Joey Ye <joey.ye at arm dot com> ---
(In reply to Ramana Radhakrishnan from comment #1)
> Isn't this a dup of PR59833.

It isn't. This one is only impacts QNAN.

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #3)
> The code path exists in the code,

It exists *only* if fn2() can return 0. But the fact is that in the reality,
this can never happen (with the original non-reduced code, this can even be
proved).

> the fact that perhaps in your program such
> code path is never taken doesn't mean it is undesirable to warn about it.
> GCC has two kinds of warnings, the is uninitialized one where particular
> code, if executed, will always use uninitialized value, and maybe
> uninitialized, where it will use uninitialized value only conditionally. 
> That is the case here.

But in this case, the warning is missing with -O2.

> No, usually with more inlining it increases and should.  When fn1 is not
> inlined, GCC intentionally does not warn that c might be uninitialized
> because maybe the function call could use the value or not set it
> unconditionally, that would lead to so huge amount of false positives for
> the warning that nobody would be willing to use the warning.

This is the same problem with -O3: there is a false positive here. So, you have
to choose whether you want to avoid false positives or not.
>From gcc-bugs-return-443447-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 10:13:38 2014
Return-Path: <gcc-bugs-return-443447-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28295 invoked by alias); 13 Feb 2014 10:13:38 -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 28264 invoked by uid 48); 13 Feb 2014 10:13:32 -0000
From: "lomato at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/60171] SEGFAULT when compiling with --coverage on travis-ci
Date: Thu, 13 Feb 2014 10:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 4.6.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: lomato at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60171-4-739mNNrdgC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60171-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60171-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-02/txt/msg01204.txt.bz2
Content-length: 216

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`171

--- Comment #1 from Dario Lombardo <lomato at gmail dot com> ---
On my local platform (ubuntu 12.04, with same version of gcc as travis), I
don't have the problem.

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
How can the compiler know that fn2 never returns 0, without inlining (not in
this case), some attribute (not provided, gcc right now has returns_nonnull
attribute but that is only for pointers) or some interprocedural analysis)?
Of course, if you want zero false positives, the uninitialized warnings could
not exist, even if you do:
int
foo (void)
{
  int c;
  return c;
}
you could say that warning here is a false positive, because you might actually
never call that function.

For -O2 we don't warn, because then the compiler does see an opaque call that
might be initializing what the arguments points to, might not, but warning in
that case would just mean too many false positives as I've said before.
While for -O3, when it is inlined a few times, the compiler clearly sees code
paths where the value is uninitialized, and has nothing that would hint such
code paths are impossible.
Of course, if fn2 is guaranteed to return non-NULL, why do you even write if
(fn2 (a, 0)) *p1 = b; rather than just
fn2 (a, 0); *p1 = b; ?

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Jakub Jelinek from comment #6)
> How can the compiler know that fn2 never returns 0, without inlining (not in
> this case), some attribute (not provided, gcc right now has returns_nonnull
> attribute but that is only for pointers) or some interprocedural analysis)?

It doesn't know with -O3, but it doesn't know either with -O2 as well. That's
my point (see below).

> For -O2 we don't warn, because then the compiler does see an opaque call
> that might be initializing what the arguments points to, might not, but
> warning in that case would just mean too many false positives as I've said
> before.

I think it should. Or you should avoid the false positives with -O3 too.

> Of course, if fn2 is guaranteed to return non-NULL, why do you even write if
> (fn2 (a, 0)) *p1 = b; rather than just
> fn2 (a, 0); *p1 = b; ?

That's because of creduce. But it seems that I've managed to make the warning
disappear with both -O2 and -O3 even when it is clear that the value is not
initialized. More later...
>From gcc-bugs-return-443452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 11:29:32 2014
Return-Path: <gcc-bugs-return-443452-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10979 invoked by alias); 13 Feb 2014 11:29:31 -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 10933 invoked by uid 48); 13 Feb 2014 11:29:26 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60172] ARM performance regression from trunk@207239
Date: Thu, 13 Feb 2014 11: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-60172-4-LFkvLTpim5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60172-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-02/txt/msg01209.txt.bz2
Content-length: 1063

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`172

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-02-13
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please check the rev. after

2014-01-30  Richard Biener  <rguenther@suse.de>

        PR tree-optimization/59993
        * tree-ssa-forwprop.c (associate_pointerplus): Check we
        can propagate form the earlier stmt and avoid the transform
        when the intermediate result is needed.

which avoids a case where extra expresions could have been introduced.

Also ... can you attach the Dhrystone variant you are using?

Also I can double the benchmark score on my machine when using -O3
-fwhole-program.

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #5)
> It exists *only* if fn2() can return 0. But the fact is that in the reality,
> this can never happen (with the original non-reduced code, this can even be
> proved).

After an analysis of the MPFR code, it actually seems to be a bug in MPFR. So,
the problem is the missing warning with -O2.

The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):

  -Wmaybe-uninitialized
    For an automatic variable, if there exists a path from the function
    entry to a use of the variable that is initialized, but there exist
    some other paths for which the variable is not initialized, the
    compiler emits a warning if it cannot prove the uninitialized paths
    are not executed at run time. [...]

This rule does *not* depend on the optimization level, except for the "if it
cannot prove the uninitialized paths are not executed at run time" part.
Indeed, the fact that a path exists or not is not something that depends on the
optimizations.

Concerning the "if it cannot prove the uninitialized paths are not executed at
run time" part, GCC should be able to prove more things with -O3 than with -O2,
meaning that -Wmaybe-uninitialized warnings could disappear with -O3 compared
to -O2, but generally not the opposite.

In the original example, GCC cannot prove anything about run time, so that
according to the gcc man page, one should get a warning whatever the
optimization level.

I've another example (similar to the MPFR code):

int fn3 (void);
void fn2 (int *p)
{
  if (fn3 ())
    *p = 0;
}
int fn1 (void)
{
  int c;
  fn2 (&c);
  return c;
}

GCC doesn't give any "may be used uninitialized" warning (whether -O2 or -O3 is
used). This is incorrect according to the above rule. BTW, for -O3, this is
surprising because it is similar to the original example.

I'm reopening the bug because the GCC behavior doesn't match the documentation.
>From gcc-bugs-return-443456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 12:38:43 2014
Return-Path: <gcc-bugs-return-443456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6485 invoked by alias); 13 Feb 2014 12:38:43 -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 6448 invoked by uid 48); 13 Feb 2014 12:38:38 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 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: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60165-4-KjDQqqo89b@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01213.txt.bz2
Content-length: 2345

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

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #8)
> The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
> 
>   -Wmaybe-uninitialized
>     For an automatic variable, if there exists a path from the function
>     entry to a use of the variable that is initialized, but there exist
>     some other paths for which the variable is not initialized, the
>     compiler emits a warning if it cannot prove the uninitialized paths
>     are not executed at run time. [...]
> 
> This rule does *not* depend on the optimization level, except for the "if it
> cannot prove the uninitialized paths are not executed at run time" part.
> Indeed, the fact that a path exists or not is not something that depends on
> the optimizations.

The definition of a function changes with inlining ;-)

> Concerning the "if it cannot prove the uninitialized paths are not executed
> at run time" part, GCC should be able to prove more things with -O3 than
> with -O2, meaning that -Wmaybe-uninitialized warnings could disappear with
> -O3 compared to -O2, but generally not the opposite.
> 
> In the original example, GCC cannot prove anything about run time, so that
> according to the gcc man page, one should get a warning whatever the
> optimization level.

f(&i) is considered as an initialization of i. This heuristic is necessary,
otherwise the number of false positives would make the warning useless.

> I've another example (similar to the MPFR code):
> 
> int fn3 (void);
> void fn2 (int *p)
> {
>   if (fn3 ())
>     *p = 0;
> }
> int fn1 (void)
> {
>   int c;
>   fn2 (&c);
>   return c;
> }
> 
> GCC doesn't give any "may be used uninitialized" warning (whether -O2 or -O3
> is used). This is incorrect according to the above rule. BTW, for -O3, this
> is surprising because it is similar to the original example.

A different optimization pass (CCP) seems to notice that the value returned is
either 0 or something uninitialized and thus must be 0. Maybe there is an
opportunity for a warning there (though again we need to make sure it won't
cause too many false positives).

I don't know why you think warnings should be so well defined. They have always
been a heuristic compromise.
>From gcc-bugs-return-443457-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 12:39:11 2014
Return-Path: <gcc-bugs-return-443457-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7735 invoked by alias); 13 Feb 2014 12:39:11 -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 7702 invoked by uid 48); 13 Feb 2014 12:39:07 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 12:39: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60165-4-Z1hVOxBsYQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01214.txt.bz2
Content-length: 1811

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #8)
> Concerning the "if it cannot prove the uninitialized paths are not executed
> at run time" part, GCC should be able to prove more things with -O3 than
> with -O2, meaning that -Wmaybe-uninitialized warnings could disappear with
> -O3 compared to -O2, but generally not the opposite.

Your assumption is mistaken because you don't seem to realize something that
Jakub has said repeatedly. GCC doesn't warn *on purpose* for very common code
such as

{
int c;
f(&c);
return c;
}

if GCC doesn't know what is going on within f(), because that will trigger a
lot of false positives (although it is easy to build testcases where warning
would have been warranted). At -O3, that code may be converted to

{
   int c;
   if (g())
       c = 3
    return c;
}

and then, even though g() may never return false, if GCC cannot prove that,
then GCC will warn, because not warning will case a lot of false negatives.
Such design decisions are based on experience.

Now, I agree that ideally, GCC should warn for your last testcase. But I guess
in that case inlining either doesn't happen or it happens too late, so GCC only
sees the first case. The analysis that GCC performs are predicated on the
transformations leading to better code, otherwise they are not performed. A
tool for static analysis will surely inline as much as it could, not matter if
the code is slower or larger, but this is not how GCC works because GCC is not
a tool for static analysis.

On the other hand, GCC has bugs (missed optimizations, PR24639), and it would
be nice if more people worked on those, but this PR doesn't look like one.
>From gcc-bugs-return-443458-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 12:41:23 2014
Return-Path: <gcc-bugs-return-443458-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11619 invoked by alias); 13 Feb 2014 12:41:23 -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 11408 invoked by uid 48); 13 Feb 2014 12:41:19 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 12:41: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-60165-4-9MCEyXTp1D@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01215.txt.bz2
Content-length: 791

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

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

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

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #9)
> A different optimization pass (CCP) seems to notice that the value returned
> is either 0 or something uninitialized and thus must be 0. Maybe there is an
> opportunity for a warning there (though again we need to make sure it won't
> cause too many false positives).

Actually this missed warning is the infamous PR18501.
>From gcc-bugs-return-443459-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 12:44:23 2014
Return-Path: <gcc-bugs-return-443459-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14224 invoked by alias); 13 Feb 2014 12:44:22 -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 14179 invoked by uid 48); 13 Feb 2014 12:44:19 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 12:44: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-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60165-4-KUCK4iqMIG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01216.txt.bz2
Content-length: 831

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`165

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Only in your reading of the documentation.

You clearly don't know what you are asking for, even the very common case of
pthread_t th;
if (pthread_create (&th, NULL, tf, NULL))
  goto fail;
pthread_join (th, NULL);
case would need to be warned about, even when there is nothing wrong about it.
In your testcase, if fn1 isn't inlined, it is the same thing for GCC, a
function call as a black box which could do anything to the memory pointed to
by the escaped pointer (unless the function is say pure or const, at which
point it couldn't store to it).  If it is inlined, the compiler sees it, sees
that a variable is used and in certain path has uninitialized value and in
others initialized, and correctly warns.

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
> GCC only sees the first case.

Actually it is the reverse, inlining happens earlier in this new testcase (the
first example was recursive, which makes the inliner more conservative).

> The analysis that GCC performs are predicated
> on the transformations leading to better code, otherwise they are not
> performed. A tool for static analysis will surely inline as much as it
> could, not matter if the code is slower or larger, but this is not how GCC
> works because GCC is not a tool for static analysis.

Maybe we could have a wiki page explaining what options to tweak (inlining
parameters, etc) for a compilation where you are only interested in warnings?
(I had vaguely mentioned creating -Ow at some point, but that didn't seem such
a good idea)
>From gcc-bugs-return-443461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 13:00:03 2014
Return-Path: <gcc-bugs-return-443461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24808 invoked by alias); 13 Feb 2014 13:00:02 -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 24744 invoked by uid 48); 13 Feb 2014 12:59:54 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/60174] New: ICE on ACATS cc3305a
Date: Thu, 13 Feb 2014 13:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60174-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-02/txt/msg01218.txt.bz2
Content-length: 3158

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`174

            Bug ID: 60174
           Summary: ICE on ACATS cc3305a
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de

BUILD cc3305a.adb
gnatmake --GCC="/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/" -gnatws -O2 -gnat95
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support
cc3305a.adb -largs --GCC="/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/"
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -c
-B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ -gnatws -O2 -gnat95
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support
cc3305a.adb

Unable to coalesce ssa_names 34 and 399 which are marked as MUST COALESCE.
i_34(ab) and  i_399(ab)
+===========================GNAT BUG DETECTED==============================+
| 4.9.0 20140209 (experimental) (armv7l-unknown-linux-gnueabihf) GCC error:|
| SSA corruption                                                           |
| Error detected around cc3305a.adb:35:1                                   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/system.ads
cc3305a.adb
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support/report.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-soflin.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/ada.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/a-except.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-parame.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stalib.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/a-unccon.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-traent.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stache.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stoele.ads
/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stoele.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:432
gnatmake: "cc3305a.adb" compilation error
FAIL:   cc3305a

cat LAST_UPDATED
Obtained from SVN: trunk revision 207646

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #14 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Marc Glisse from comment #9)
> The definition of a function changes with inlining ;-)

It shouldn't: what happens at run time isn't changed by inlining.

> f(&i) is considered as an initialization of i. This heuristic is necessary,
> otherwise the number of false positives would make the warning useless.

Perhaps, but this isn't documented.

> I don't know why you think warnings should be so well defined.

According to the gcc man page, it is well-defined: the rule is given
explicitly.

(In reply to Jakub Jelinek from comment #12)
> In your testcase, if fn1 isn't inlined, it is the same thing for GCC, a
> function call as a black box which could do anything to the memory pointed
> to by the escaped pointer (unless the function is say pure or const, at
> which point it couldn't store to it).

Here you assume that the function can do anything, while Marc said that GCC
assumes that i is initialized. There's a contradiction.

Moreover in the case of MPFR, the called function is in the same preprocessed
source file, so that it is not obvious for the user that GCC will see it as a
black box (when not inlined).
>From gcc-bugs-return-443468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 13:35:46 2014
Return-Path: <gcc-bugs-return-443468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22325 invoked by alias); 13 Feb 2014 13:35:46 -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 22287 invoked by uid 55); 13 Feb 2014 13:35:43 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
Date: Thu, 13 Feb 2014 13:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59878-4-ES2orpJDkM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59878-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59878-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-02/txt/msg01225.txt.bz2
Content-length: 672

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Feb 13 13:35:10 2014
New Revision: 207758

URL: http://gcc.gnu.org/viewcvs?rev 7758&root=gcc&view=rev
Log:
2014-02-13  Richard Biener  <rguenther@suse.de>

    PR bootstrap/59878
    * doc/install.texi (ISL): Update recommended version to 0.12.2,
    mention the possibility of an in-tree build.
    (CLooG): Update recommended version to 0.18.1, mention the
    possibility of an in-tree build and clarify that the ISL
    bundled with CLooG does not work.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/install.texi

[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #15 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
> GCC only sees the first case. The analysis that GCC performs are predicated
> on the transformations leading to better code, otherwise they are not
> performed. A tool for static analysis will surely inline as much as it
> could, not matter if the code is slower or larger, but this is not how GCC
> works because GCC is not a tool for static analysis.

Well, detecting uninitialized variables is equivalent to generating better
code. See the following functions. If you want to be able to remove the i == 0
test in the first one (making generated code better), you'll solve the warning
problem in the second one.

int f(void)
{
  int i = 0;
  /* some code that sets i to a nonzero value, but difficult to prove */
  if (i == 0)
    abort();
  return i;
}

int f(void)
{
  int i;
  /* some code that sets i to a nonzero value, but difficult to prove */
  return i;
}
>From gcc-bugs-return-443471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 13:59:25 2014
Return-Path: <gcc-bugs-return-443471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18799 invoked by alias); 13 Feb 2014 13:59:24 -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 18773 invoked by uid 48); 13 Feb 2014 13:59:21 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/60174] ICE on ACATS cc3305a
Date: Thu, 13 Feb 2014 13:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-60174-4-yzfgZ8Dft0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60174-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60174-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-02/txt/msg01228.txt.bz2
Content-length: 1821

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`174

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Richard Biener from comment #1)
> Can you check from the -fdump-tree-all dumps where i_34(ab) and i_399(ab)
> start to have overlapping life-ranges?

OK, i used grep 'i_\(34\|399\)(ab)' cc3305a.adb.*

i_399(ab) is first mentioned in cc3305a.adb.078t.dom1:

cc3305a.adb.078t.dom1:i_399(ab) -> { i_36(ab) }
cc3305a.adb.078t.dom1:  # i_34(ab) = PHI <i_168(D)(ab)(2), i_168(D)(ab)(3),
i_168(D)(ab)(4), i_398(ab)(8), i_398(ab)(9), i_398(ab)(11), i_398(ab)(12),
i_398(ab)(13), i_35(ab)(14), i_35(ab)(15), i_35(ab)(16), i_35(ab)(17),
i_208(ab)(20), i_208(ab)(21), i_208(ab)(22), i_399(ab)(25), i_399(ab)(26),
i_399(ab)(28), i_399(ab)(30), i_399(ab)(31), i_36(ab)(32), i_36(ab)(34),
i_36(ab)(36), i_36(ab)(38), i_400(ab)(39), i_37(ab)(41), i_37(ab)(42),
i_37(ab)(43), i_38(ab)(46), i_38(ab)(47), i_38(ab)(48), i_401(ab)(51),
i_401(ab)(52), i_401(ab)(54), i_401(ab)(56), i_401(ab)(57), i_39(ab)(58),
i_39(ab)(60), i_43(ab)(90), i_402(ab)(61), i_40(ab)(63), i_40(ab)(64),
i_40(ab)(65), i_41(ab)(68), i_41(ab)(69), i_41(ab)(70), i_403(ab)(73),
i_403(ab)(74), i_403(ab)(76), i_403(ab)(78), i_403(ab)(79), i_42(ab)(80),
i_42(ab)(82), i_42(ab)(84), i_42(ab)(86), i_404(ab)(87), i_43(ab)(89)>
cc3305a.adb.078t.dom1:  # i_399(ab) = PHI <i_36(ab)(24), i_333(93)>
cc3305a.adb.078t.dom1:  _188 = i_399(ab) != 0;
cc3305a.adb.078t.dom1:  _189 = i_399(ab) != 4;
cc3305a.adb.078t.dom1:  # i_400(ab) = PHI <i_399(ab)(29), i_36(ab)(37),
i_36(ab)(38), i_399(ab)(30)>
cc3305a.adb.078t.dom1:  # i_305 = PHI <i_34(ab)(5)>
cc3305a.adb.078t.dom1:  # i_333 = PHI <i_34(ab)(23)>
cc3305a.adb.078t.dom1:  # i_350 = PHI <i_34(ab)(49)>
cc3305a.adb.078t.dom1:  # i_365 = PHI <i_34(ab)(71)>

is this already overlapping?