[Bug c++/56958] New: Spurious unused variable warning in empty pack expansion

[Bug c++/56958] New: Spurious unused variable warning in empty pack expansion

[lucdanton at free dot fr]

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

             Bug #: 56958
           Summary: Spurious unused variable warning in empty pack
                    expansion
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: lucdanton@free.fr


Created attachment 29872
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29872
Minimal testcase

Using:

g++-snapshot (Debian 20130330-1) 4.9.0 20130330 (experimental) [trunk revision
197260]

$ cat main.cpp 
template<typename... T>
int foo(T... t)
{
    int spurious = 0;
    return false ? foo(t + spurious...) : 0;
}

int main()
{
    return foo();
}

$ g++-snapshot -Wall -std=c++11 main.cpp 
main.cpp: In instantiation of 'int foo(T ...) [with T = {}]':
main.cpp:10:16:   required from here
main.cpp:4:9: warning: variable 'spurious' set but not used
[-Wunused-but-set-variable]
     int spurious = 0;
         ^

No such warning is produced when passing arguments to foo.

[Bug c++/56958] Spurious set but not unused variable warning in empty pack expansion

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-26
                 CC|                            |jakub at gcc dot gnu.org
            Summary|Spurious unused variable    |Spurious set but not unused
                   |warning in empty pack       |variable warning in empty
                   |expansion                   |pack expansion
     Ever Confirmed|0                           |1

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-26 14:23:27 UTC ---
Well, you aren't using spurious, are you?  Because t + spurious... expands to
nothing.

If mark_exp_read isn't called while processing_template_decl because the
expression is type dependent, and during instantiation is lost altogether, not
sure where could we call mark_rvalue_use etc.

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-26 14:30:29 UTC ---
I agree, looks like warning is fine...

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[lucdanton at free dot fr]

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

--- Comment #3 from lucdanton at free dot fr 2013-04-28 00:37:37 UTC ---
I do make use of the variable in the pack; that the pack may be empty for some
instantiations may or may not be something to look out for, but I don't think
that it should be done by the unused variable warning.

Perhaps I misunderstand the role of warning -- to me the 'used' in 'unused
variable' means that it's conceptually used, not that it's e.g. ODR-used or any
technical sense of the term. Should the following code warn? Who does that
benefit?

    int spurious = 0
    if(1) return 0;
    // never reached -- is spurious used or not?
    return spurious + 3;

Since GCC doesn't warn for this I thought it shouldn't in the case of the pack
expansion.

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[ldionne.2 at gmail dot com]

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

Louis Dionne <ldionne.2 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ldionne.2 at gmail dot com

--- Comment #4 from Louis Dionne <ldionne.2 at gmail dot com> ---
The following code triggers the same warning on GCC trunk:

------------------------------------------------------------------------------
struct Object { int method(int) const { return 0; } };

template <typename ...T> void expand(T&&...);
template <int ...> struct index_sequence { };

template <typename ...>
struct TemplateStruct {
    static constexpr Object get_object() { return {}; }

    template <int ...i>
    static void f(index_sequence<i...>) {
        constexpr auto object = get_object(); // only fires with 'auto'
        expand(object.method(i)...);
    }
};

template void TemplateStruct<>::f(index_sequence<>);
------------------------------------------------------------------------------

The warning is:

    [snip]: In instantiation of ‘
        static void TemplateStruct< <template-parameter-1-1>
            >::f(index_sequence<i ...>) [with int ...i = {};
                                              <template-parameter-1-1> = {}]’:
    [snip]:   required from here
    [snip]: warning: variable ‘object’ set but not used
[-Wunused-but-set-variable]
             constexpr auto object = get_object(); // only fires with 'auto'
                            ^


This is very annoying because that will cause perfectly fine code to emit 
warnings when used with empty parameter packs. Also surprising is that the 
warning goes away if either

    (1) A non-template struct is used instead of TemplateStruct
    (2) One uses `Object object = ...` instead of `auto object = ...`

which makes it obvious that this is a bug, not a feature. Please fix your
compiler, or metaprogrammers all around the world will hate you for forcing
them to write

    constexpr auto object = get_object();
    (void)object; // workaround GCC false positive
    expand(object.method(i)...);

in every place where a variable may be 'unused' when a parameter pack is empty.
>From gcc-bugs-return-495758-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 27 21:23:23 2015
Return-Path: <gcc-bugs-return-495758-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101316 invoked by alias); 27 Aug 2015 21:23: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 101171 invoked by uid 48); 27 Aug 2015 21:23:19 -0000
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/67367] Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error
Date: Thu, 27 Aug 2015 21:23: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.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kargl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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-67367-4-05I1DJXEfI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67367-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67367-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: 2015-08/txt/msg01900.txt.bz2
Content-length: 745

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

kargl at gcc dot gnu.org changed:

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #1)
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7ba152e in buf_read (s=0x6063b0, buf=<optimized out>, 
>     nbyte=<optimized out>) at ../../../trunk/libgfortran/io/unix.c:535
> 535	          memcpy (p, s->buffer, did_read);

There are a bunch of bugs lurking in fortran/io.c.
For example, flush(iostat=ios) causes a problem.
>From gcc-bugs-return-495759-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 27 21:48:19 2015
Return-Path: <gcc-bugs-return-495759-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 41384 invoked by alias); 27 Aug 2015 21:48:19 -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 41304 invoked by uid 48); 27 Aug 2015 21:48:15 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67351] Missed optimisation on 64-bit field compared to 32-bit
Date: Thu, 27 Aug 2015 21:48: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: 5.2.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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: cf_gcctarget cc component
Message-ID: <bug-67351-4-FAfE8X3R7S@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67351-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: 2015-08/txt/msg01901.txt.bz2
Content-length: 523

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i?86                        |x86_64
                 CC|                            |hs.naveen2u at gmail dot com
          Component|target                      |tree-optimization

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
Adding CC.
>From gcc-bugs-return-495760-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 27 22:08:22 2015
Return-Path: <gcc-bugs-return-495760-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 88457 invoked by alias); 27 Aug 2015 22:08: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 88362 invoked by uid 48); 27 Aug 2015 22:08:18 -0000
From: "gang.chen.5i5j at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63510] Wrong line number in Wstrict-overflow message
Date: Thu, 27 Aug 2015 22:08: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: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gang.chen.5i5j at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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-63510-4-5FlmtcMXu8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63510-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63510-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/msg01902.txt.bz2
Content-length: 492

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

--- Comment #9 from Chen Gang <gang.chen.5i5j at gmail dot com> ---
We need call warning_at() instead of warnings() in fold_overflow_warning() in
gcc/fold-const.c.

The related location parameter of warning_at() should be calculated, just like
another gcc files has done: e.g. gcc/c-family/*.c which use warning_at().

I shall continue to analyze how to calculate the location in gcc/fold-const.c,
reference from the other files.

Thanks.

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[foom at fuhm dot net]

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

James Y Knight <foom at fuhm dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |foom at fuhm dot net

--- Comment #6 from James Y Knight <foom at fuhm dot net> ---
I agree with the other people noting that it isn't _useful_ to warn about this
construct, and that this ought to be considered a valid bug, not working as
intended.

[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion

[serpent7776 at gmail dot com]

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

serpent7776 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |serpent7776 at gmail dot com

--- Comment #7 from serpent7776 at gmail dot com ---
I was just hit by this warning in a very similar scenario.
To me this warning in this context is not only unhelpful, but confusing.
clang doesn't issue this warning in this context.