[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-19
                 CC|                            |manu at gcc dot gnu.org
             Blocks|                            |24639
            Summary|-Wmaybe-uninitialized       |wrong location for
                   |pragma mishandled in        |-Wmaybe-uninitialized in
                   |inlined function            |inlined function
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.2, 5.0

--- Comment #1 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
Confirmed also in GCC 5.0.

The problem is the location info that is available in the middle-end and how
this is transformed when inlining and renaming/propagating copies. To be able
to silence this, the warning should be given at the location of 'return *p'. 

We have the correct location in 028t.esra:
;;   basic block 4, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 3, next block 5, flags: (NEW, REACHABLE)
;;    pred:       2 (FALSE_VALUE,EXECUTABLE)
;;   starting at line 7
  [test.c:7:10] _9 = v$4_14(D);
  _13 = _9;
  [test.c:17:27] iftmp.0_10 = _9;
;;    succ:       5 (FALLTHRU,EXECUTABLE)

but the middle-end loses it after 030t.fre1:

;;   basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;    prev block 4, next block 1, flags: (NEW, REACHABLE)
;;    pred:       3 (FALLTHRU,EXECUTABLE)
;;                4 (FALLTHRU,EXECUTABLE)
;;   starting at line -1, discriminator 4
  # iftmp.0_1 = PHI <[test.c:17:27] iftmp.0_8(3), [test.c:17:27] v$4_14(D)(4)>


As a side note, I wonder if %K could be used here to get an "inline-from"
backtrace like we do in other diagnostics.