[Bug c++/65201] New: range-for range-init containing variable named like for-range-declaration iterates over uninitialized for-range-declaration

["bloerwald at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 65201
           Summary: range-for range-init containing variable named like
                    for-range-declaration iterates over uninitialized
                    for-range-declaration
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bloerwald at googlemail dot com

#include <iostream>
    #include <string>
    #include <vector>

    template<typename T>
      std::vector<T> split (T in, typename T::value_type delim);
    // … see below

    void choke (std::string foo)
    {
      for (std::string foo : split (foo, ' '))
      {
        std::cout << foo << std::endl;
      }
    }

    int main (int, char**)
    {
      choke ("foo bar baz");
      return 0;
    }

The above compiles and runs fine with clang 3.5.1:

    $ clang++ -Weverything --std=c++11 gcc_range_for_choke.cpp -o
gcc_range_for_choke
    gcc_range_for_choke.cpp:33:20: warning: declaration shadows a local
variable [-Wshadow]
      for (std::string foo : split (foo, ' '))
    [… other warnings]
    $ ./gcc_range_for_choke
    foo
    bar
    baz

but fails miserably with gcc 4.9.2,

    $ c++ --std=c++11 -Wall -Wextra gcc_range_for_choke.cpp -o
gcc_range_for_choke -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations
    gcc_range_for_choke.cpp:31:25: warning: unused parameter ‘foo’
[-Wunused-parameter]
     void choke (std::string foo)
                             ^
    $ ./gcc_range_for_choke
    Segmentation fault

(The segfault comes from directly accessing the unitialized `T in`.)

I realize what happens, but according to what I understand in the standard, it
has to be equivalent to

    {
      auto && __range = range-init;
      for ( auto __begin = begin-expr, __end = end-expr; __begin != __end;
++__begin )
      {
        for-range-declaration = *__begin;
        statement
      }
    }

The (clang reported) shadowing is real, but `range-init` most certainly can't
refer to `for-range-declaration`, as of what I understand.


Bonus: Badly implemented split for completeness:

    template<typename T>
      std::vector<T> split (T in, typename T::value_type delim)
    {
      std::vector<T> ret;
      T key;
      for (auto const& e : in)
      {
        if (e == delim)
        {
          ret.push_back (key);
          key.clear();
        }
        else
        {
          key.push_back (e);
        }
      }
      if (!key.empty())
      {
        ret.push_back (key);
      }
      return ret;
    }

Note: confirmed to exist on 4.8.2, untested on 4.9.3, 5.0.

    $ gcc -v
    Using built-in specs.
    COLLECT_GCC=gcc
   
COLLECT_LTO_WRAPPER=/p/hpc/soft/gcc/4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
    Target: x86_64-unknown-linux-gnu
    Configured with: ./configure --prefix=/p/hpc/soft/gcc/4.9.2
    Thread model: posix
    gcc version 4.9.2 (GCC)
>From gcc-bugs-return-478418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 25 09:51:51 2015
Return-Path: <gcc-bugs-return-478418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 88517 invoked by alias); 25 Feb 2015 09:51:51 -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 88048 invoked by uid 48); 25 Feb 2015 09:51:47 -0000
From: "ams at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
Date: Wed, 25 Feb 2015 10:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: ams at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64491-4-adbbqRAl79@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64491-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64491-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-02/txt/msg02750.txt.bz2
Content-length: 1027

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

--- Comment #13 from Andrew Stubbs <ams at gcc dot gnu.org> ---
I thought of that, but my testcase has 2 exits.

I thought of only warning when all the exits were being removed, but the
loop->bounds list does not include all the exits, so that can't happen either.

I thought of only warning when all the loop exits are beyond the UB, but then I
realised that that's exactly what the code already does; it just doesn't help
when the loop has been turned inside out like this.

Fundamentally, the problem is that the head of the first iteration and the
effective head of the last iteration are not necessarily one and the same. I
can't see an obvious way to start the walk from somewhere else though.

In any case, the bounds reduction code does the right thing, it's just the
warning that's broken, so it might just be best to remove it.

I'd still like to have the warning though. Perhaps the best way would be to
warn at the point where the last exit is actually removed?