[Bug tree-optimization/67196] Another false positive from -Wmaybe-uninitialized

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-12
                 CC|                            |manu at gcc dot gnu.org
             Blocks|                            |24639
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
For some reason, the uninit pass does not even analyze the predicates and
thinks all uses are unguarded (or it doesn't dump it).

A shorter testcase:

int some_test(int);

int test (int n)
{
  int num_captions_in_row = 0;
  int first_caption = 0; /* set to zero here */
  int first_caption_idx;
  int i;
  for (i = 0; i < n; i++)
    {
      if (some_test (i))
        {
          num_captions_in_row++;
          first_caption = 1; /* only ever set here */
          first_caption_idx = i; /* set here */
        }
    }

  /* The guard on "first_caption" here requires we entered the block
     above that sets "first_caption_idx". */
  if (first_caption && num_captions_in_row == 1)
    return first_caption_idx; /* get bogus warning here at -O1 and above */
  return 0;
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
>From gcc-bugs-return-494688-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 12 21:00:20 2015
Return-Path: <gcc-bugs-return-494688-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 57861 invoked by alias); 12 Aug 2015 21:00:20 -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 57820 invoked by uid 55); 12 Aug 2015 21:00:16 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
Date: Wed, 12 Aug 2015 21:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joseph at codesourcery dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67172-4-HLt4a4FBt5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67172-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: 2015-08/txt/msg00830.txt.bz2
Content-length: 831

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 11 Aug 2015, breedlove.matt at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?idg172
>
> --- Comment #3 from Matt Breedlove <breedlove.matt at gmail dot com> ---
> In gcc/defaults.h, it gets defined via:

So why does not exactly the same sequence of conditional macro definitions
apply when libgcc is being built and so cause your patch to be
ineffective, given that libgcc does still include the host-side tm.h until
the transition away from host-side target macros in target-side code is
complete?  (In any case, my point still applies: stop
__LIBGCC_EH_FRAME_SECTION_NAME__ being defined if it's incorrect, which
means some sort of host-side change.)