[Bug middle-end/55874] New: Incorrect warning location for uninitialized variable

[Bug middle-end/55874] New: Incorrect warning location for uninitialized variable

[steven at gcc dot gnu.org]

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

             Bug #: 55874
           Summary: Incorrect warning location for uninitialized variable
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: steven@gcc.gnu.org


$ cat t.c
void bar (void);
int foo (int b, int c, int d)
{
  int res, r = 0;
  if (b)
    res = b * 2 + 4;
  if (c)
    {
      if (d)
        r = res;
      else
        __builtin_unreachable ();
    }
  return r;
}
$ ./xgcc -B. -O2 -W -Wall -Wextra t.c
t.c: In function 'foo':
t.c:14:3: warning: 'res' may be used uninitialized in this function 
[-Wmaybe-uninitialized]
   return r;
   ^
$ 

The warning is correct, but I'd expect the caret to point to res, not to
the return statement.

[Bug middle-end/55874] Incorrect warning location for uninitialized variable

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-04
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-04 12:14:51 UTC ---
It figures the location from

  <bb 7>:
  # res_2 = PHI <[t.c : 4:12] 0(4), [t.c : 10:4] res_1(5)>
  [t.c : 14:3] return res_2;

where we ended up copy-/const-propagating 0 and r.  Note that the
PHI argument has the correct location.

Confirmed.

We do:

  uninit_op = gimple_phi_arg_def (phi, MASK_FIRST_SET_BIT (uninit_opnds));
  if (SSA_NAME_VAR (uninit_op) == NULL_TREE)
    return;
  warn_uninit (OPT_Wmaybe_uninitialized, uninit_op, SSA_NAME_VAR (uninit_op),
               SSA_NAME_VAR (uninit_op),
               "%qD may be used uninitialized in this function",
               uninit_use_stmt);

that ends up warning at uninit_use_stmt.

Not sure if we want to warn about the other location (or how well that
would play out).

[Bug middle-end/55874] Incorrect warning location for uninitialized variable

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-04 12:46:17 UTC ---

> Not sure if we want to warn about the other location (or how well that
> would play out).

I think we definitely want to warn about the location of the operator that
triggers the warning, not about the statement at all. If that location is
available, we should *always* use it. Would it be also available if there is no
PHI node here (that is if r was completely replaced by res)?

Like in:

{
  int res, r = 0;
  r = res;
  return r;
}

[Bug middle-end/55874] Incorrect warning location for uninitialized variable

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Sorry, changed keyword on the wrong bug!
>From gcc-bugs-return-445891-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 10 10:58:27 2014
Return-Path: <gcc-bugs-return-445891-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6618 invoked by alias); 10 Mar 2014 10:58: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 6588 invoked by uid 48); 10 Mar 2014 10:58:22 -0000
From: "antony at cosmologist dot info" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
Date: Mon, 10 Mar 2014 10:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: antony at cosmologist dot info
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-60458-4-QKYtDeZQVo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60458-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60458-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-03/txt/msg00760.txt.bz2
Content-length: 722

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

--- Comment #2 from Antony Lewis <antony at cosmologist dot info> ---
Here's a related example:

    module A
    implicit none
    Type T
     integer :: val = 2
    contains
    final :: testfree
    end type
    contains

    subroutine testfree(this)
    Type(T) this

    print *,'freed'
    end subroutine

    subroutine Testf()

    associate(X => T())
        print *, X%val
    end associate
    print *,'after scope'
    end subroutine Testf

    end module


which gives

  print *, X%val
             1
Error: Symbol 'x' at (1) has no IMPLICIT type

(I was checking if finalization is called correctly, but didn't get that far)
This code compiles in ifort.