[Bug c++/61382] New: parameter pack expansion unexpected order

[Bug c++/61382] New: parameter pack expansion unexpected order

[pengujohn at xvlc dot de]

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

            Bug ID: 61382
           Summary: parameter pack expansion  unexpected order
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pengujohn at xvlc dot de

Created attachment 32882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32882&action=edit
small example that expands like 3,2,1,0 ... should be 0,1,2,3

C++11 variadic templated parameter pack expansion happens for {}-initialiser in
reversed oder. As far as I understand this, they should be expanded in order. I
am not sure if its expansion or evaluation thats out of order.... clang++ does
the correct(?) ordering.

[Bug c++/61382] parameter pack expansion unexpected order

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's definitely a bug ... I think there's an existing PR about it.

[Bug c++/61382] parameter pack expansion unexpected order

[thibaut.lutz at googlemail dot com]

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

Thibaut LUTZ <thibaut.lutz at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thibaut.lutz at googlemail dot com

--- Comment #2 from Thibaut LUTZ <thibaut.lutz at googlemail dot com> ---
@Jonathan: you might be referring to 56774. 59716 was a similar issue.

However I think this case is definitely NOT a bug. Here is why:

- let's decompose the line:
std::tuple<ARGS...> r { get_single<ARGS>(posfoo++)... };

* std::tuple<ARGS...> r{ ... }: this is a constructor call: std::tuple(args...)
* get_single<ARGS>(posfoo++)... expands to get_single<int>(posfoo++),
get_single<float>(posfoo++), get_single<float>(posfoo++),
get_single<int>(posfoo++)

Putting the two together, with the previous line:
int posfoo = 0;
std::tuple<ARGS...> r ( get_single<int>(posfoo++),
                        get_single<float>(posfoo++),
                        get_single<float>(posfoo++),
                        get_single<int>(posfoo++));

This is the root of your problem: 
N3797 §8.3.6.9: The order of evaluation of function arguments is unspecified.

The pack expansion is working fine, but the increments to posfoo are not being
sequenced. Clang does evaluate arguments in the opposite order as GCC does,
which makes it look correct in this case, but it is still undefined behavior. 

You can re-write your get_single function to do a pack traversal instead.
>From gcc-bugs-return-453145-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 01:06:19 2014
Return-Path: <gcc-bugs-return-453145-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9251 invoked by alias); 4 Jun 2014 01:06: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 9208 invoked by uid 48); 4 Jun 2014 01:06:15 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61382] parameter pack expansion  unexpected order
Date: Wed, 04 Jun 2014 01:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
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-61382-4-z9LGwYv9kd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61382-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61382-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-06/txt/msg00227.txt.bz2
Content-length: 653

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Thibaut LUTZ from comment #2)
> @Jonathan: you might be referring to 56774. 59716 was a similar issue.

They don't look related. I meant PR 51253

> However I think this case is definitely NOT a bug. Here is why:
>
> - let's decompose the line:
> std::tuple<ARGS...> r { get_single<ARGS>(posfoo++)... };
>
> * std::tuple<ARGS...> r{ ... }: this is a constructor call:
> std::tuple(args...)

No, this is not a valid transformation, the semantics of T r{args...} are not
the same as T r(args...), see [dcl.init.list] p4.

[Bug c++/61382] parameter pack expansion unexpected order

[thibaut.lutz at googlemail dot com]

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

--- Comment #4 from Thibaut LUTZ <thibaut.lutz at googlemail dot com> ---
You're right, my bad. Thanks for correcting me.

The exact quote is 
> Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions, are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.

So the increments *should* be sequenced.

Sorry about the noise.

[Bug c++/61382] parameter pack expansion unexpected order

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed Jun  4 15:51:01 2014
New Revision: 211235

URL: http://gcc.gnu.org/viewcvs?rev=211235&root=gcc&view=rev
Log:
    PR c++/51253
    PR c++/61382
gcc/
    * gimplify.c (gimplify_arg): Non-static.
    * gimplify.h: Declare it.
gcc/cp/
    * cp-gimplify.c (cp_gimplify_expr): Handle CALL_EXPR_LIST_INIT_P here.
    * semantics.c (simplify_aggr_init_expr): Not here, just copy it.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/initlist86.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-gimplify.c
    trunk/gcc/cp/semantics.c
    trunk/gcc/gimplify.c
    trunk/gcc/gimplify.h

[Bug c++/61382] parameter pack expansion unexpected order

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-06-04
                 CC|                            |jason at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
   Target Milestone|---                         |4.10.0
     Ever confirmed|0                           |1

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed on trunk for now.

[Bug c++/61382] parameter pack expansion unexpected order

[pengujohn at xvlc dot de]

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

--- Comment #7 from Johannes Steinmetz <pengujohn at xvlc dot de> ---
(In reply to Jason Merrill from comment #6)
> Fixed on trunk for now.

Ohh great. Thank You!

[Bug c++/61382] parameter pack expansion unexpected order

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Mon Jun 30 14:25:21 2014
New Revision: 212150

URL: https://gcc.gnu.org/viewcvs?rev=212150&root=gcc&view=rev
Log:
    DR 1030
    PR c++/51253
    PR c++/61382
    * cp-tree.h (CALL_EXPR_LIST_INIT_P): New.
    * call.c (struct z_candidate): Add flags field.
    (add_candidate): Add flags parm.
    (add_function_candidate, add_conv_candidate, build_builtin_candidate)
    (add_template_candidate_real): Pass it.
    (build_over_call): Set CALL_EXPR_LIST_INIT_P.
    * tree.c (build_aggr_init_expr): Copy it.
    * semantics.c (simplify_aggr_init_expr): Copy it.
    * cp-gimplify.c (cp_gimplify_expr): Handle it.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/initlist86.C
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/cp/ChangeLog
    branches/gcc-4_9-branch/gcc/cp/call.c
    branches/gcc-4_9-branch/gcc/cp/cp-gimplify.c
    branches/gcc-4_9-branch/gcc/cp/cp-tree.h
    branches/gcc-4_9-branch/gcc/cp/semantics.c
    branches/gcc-4_9-branch/gcc/cp/tree.c
    branches/gcc-4_9-branch/gcc/gimplify.c
    branches/gcc-4_9-branch/gcc/gimplify.h

[Bug c++/61382] parameter pack expansion unexpected order

[brooks at gcc dot gnu.org]

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

Brooks Moses <brooks at gcc dot gnu.org> changed:

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

--- Comment #9 from Brooks Moses <brooks at gcc dot gnu.org> ---
FWIW, the new initlist86.C test that this adds is failing on the google/gcc-4_9
branch on powerpc64le and aarch64, though it passes on x86_64.  I haven't yet
checked on the upstream 4.9 branch, but I figured a heads-up might be useful.

[Bug c++/61382] parameter pack expansion unexpected order

[brooks at gcc dot gnu.org]

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

--- Comment #11 from Brooks Moses <brooks at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> Thanks.  Does removing "PUSH_ARGS_REVERSED &&" from the cp_gimplify_expr
> change fix it?

Nope -- I just gave it a try, and it doesn't seem to change things.  Still
passes on x86_64 and fails on aarch64.

[Bug c++/61382] parameter pack expansion unexpected order

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm seeing:
FAIL: g++.dg/cpp0x/initlist86.C -std=c++11 execution test
FAIL: g++.dg/cpp0x/initlist86.C -std=c++1y execution test
on 4.9 branch (but not on trunk) on x86_64-linux -m32.
make check-g++ \
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=initlist86.C'

[Bug c++/61382] parameter pack expansion unexpected order

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> I'm seeing:
> FAIL: g++.dg/cpp0x/initlist86.C -std=c++11 execution test
> FAIL: g++.dg/cpp0x/initlist86.C -std=c++1y execution test
> on 4.9 branch (but not on trunk) on x86_64-linux -m32.

Hmm, I can't reproduce that compiling it by hand with my 4.9 branch build.

[Bug c++/61382] parameter pack expansion unexpected order

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Jul  4 08:23:28 2014
New Revision: 212289

URL: https://gcc.gnu.org/viewcvs?rev=212289&root=gcc&view=rev
Log:
    PR c++/61382
    Backport from mainline
    2014-06-05  Andreas Schwab  <schwab@suse.de>

    * g++.dg/cpp0x/initlist86.C (main): Initialize i.

Modified:
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/initlist86.C

[Bug c++/61382] parameter pack expansion unexpected order

[brooks at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5006 bytes --]

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

--- Comment #15 from Brooks Moses <brooks at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
[...]
> 	* g++.dg/cpp0x/initlist86.C (main): Initialize i.
[...]

Aha ... yes, that would do it.  And, indeed, I can confirm that this fixes the
failures I was seeing.  Thanks!

Jason, should this be marked as "resolved"?
>From gcc-bugs-return-455834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 08 03:28:28 2014
Return-Path: <gcc-bugs-return-455834-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18081 invoked by alias); 8 Jul 2014 03:28:27 -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 17774 invoked by uid 48); 8 Jul 2014 03:28:15 -0000
From: "gccbugzilla at limegreensocks dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/61740] New: Fixes for minor problems in asm_fprintf and output_asm_insn
Date: Tue, 08 Jul 2014 03:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gccbugzilla at limegreensocks dot com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-61740-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-07/txt/msg00425.txt.bz2
Content-length: 2732

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

            Bug ID: 61740
           Summary: Fixes for minor problems in asm_fprintf and
                    output_asm_insn
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gccbugzilla at limegreensocks dot com

Created attachment 33087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3087&actioníit
Proposed patch

The attached patch fixes 4 inline asm issues in asm_fprintf and
output_asm_insn.  They vary in importance from minor to trivial.

1) Compiling this inline asm statement (correctly) reports "unterminated
assembly dialect alternative":

asm("{" :);

But this one does not:

asm("{stuff" :);

This patch reports all unterminated dialects (for both att & intel) in both
output_asm_insn & asm_fprintf:

  asm("{" :);
  asm("{nop" :);

  asm("{|" :);
  asm("{nop|" :);
  asm("{nop|nop" :);

  asm("{||" :);
  asm("{nop||" :);
  asm("{nop|nop|" :);
  asm("{nop||nop" :);
  asm("{nop|nop|nop" :);

2) In r198641, output_asm_insn was modified to add support for escaping the
dialect characters: {|}.  This feature was not added to asm_fprintf (which also
supports dialects).  This patch updates asm_fprintf to support escaping dialect
characters, so that it truly will "handle alternate assembler dialects here,
just like output_asm_insn."

3) There are two format strings (%@ %r) defined for asm_fprintf in c-format.c
that are only available for arm.  Any attempt to use them from other platforms
results in an ICE.  Since the entire purpose of these tables is to validate
format strings, these entries should only be defined when building arm.

While I could have simply wrapped the offending table entries in an #ifdef
__arm__, that does not appear to be consistent with the standard used by the
rest of gcc.  Following the example of the related macro
(ASM_FPRINTF_EXTENSIONS), I created a macro named ASM_FPRINTF_TABLE that can be
created on a per-platform basis to define platform-specific formats.  Like
ASM_FPRINTF_EXTENSIONS, this is (currently) only implemented on arm.

4) asm_fprintf uses a fixed size buffer (buf[10]) that it copies data into, but
it never checks to see if it is overrunning the buffer.  While 10 bytes is
almost certainly sufficient for most valid uses, not checking at all seems bad.
 There are legal (if unlikely) printf modifiers that require more than 10
bytes.  Rather than depend upon people to not violate this restriction, this
patch performs a simple check for overruns.

An 11 byte example: asm_fprintf(asm_out_file, "%-160.140x", 12);

[Bug c++/61382] parameter pack expansion unexpected order

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.10.0                      |4.9.1

--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> ---
Yes.