[Bug libstdc++/54320] New: [c++11] range access to VLA

[Bug libstdc++/54320] New: [c++11] range access to VLA

[vincenzo.innocente at cern dot ch]

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

             Bug #: 54320
           Summary: [c++11] range access to VLA
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vincenzo.innocente@cern.ch


is range access to VLA supported?

I get compilation error for

 c++ -O3 -std=gnu++11 -c vla.cpp -DVLA

with

#include<algorithm>
#ifdef VLA
int foo(int N) {
  int v[N];
  auto a = std::begin(v);
  return *a;
}
#endif

int bar() {
  int v[10];
  auto a = std::begin(v);
  return *a;
}

[Bug libstdc++/54320] [c++11] range access to VLA

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-08-19 07:17:04 UTC ---
I don't think they can ever be as std::begin is defined as a template with one
of the template arguments being the size of the array.

[Bug libstdc++/54320] [c++11] range access to VLA

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-08-19 07:18:25 UTC ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5435

[Bug libstdc++/54320] [c++11] range access to VLA

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2012-08-19 07:24:52 UTC ---
int foo2(int N) {
  int v[N];
  for ( auto a : v)
    if (a) return a;
  return 0;
}

works, though was similar to std::begin(v) std::end(v)

[Bug libstdc++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-19 11:29:15 UTC ---
Would be an extension requiring front-end support. I don't think we want it.

[Bug libstdc++/54320] [c++11] range access to VLA

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente <vincenzo.innocente at cern dot ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #5 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2012-08-19 11:34:06 UTC ---
a good candidate for c++17 then!

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
          Component|libstdc++                   |c++

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-19 11:47:25 UTC ---
In case we wanted to support this, it would essentially boil down to the C++
front-end bits introspecting the size. Let's ask Jason in CC, if it would make
sense.

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-08-19 12:05:57 UTC ---
Frankly I'm also not sure about the signature of the begin and end overloads
themselves, is it even possible to tell apart VLAs??

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-17
     Ever Confirmed|0                           |1

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-17 14:11:54 UTC ---
This is now covered (allowed) in N3497.

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-17 14:16:40 UTC ---
Sorry, the most recent paper in the series is actually N3639.

[Bug c++/54320] [c++11] range access to VLA

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Sorry, I think I misread this one when I reconsidered it in the light of N3639:
range-based for loop is fully covered (and worked already in GCC), but I don't
think there are plans to support std::begin(v) where v is a VLA. I'm adding
Daniel too (I may be overlooking the implications of ongoing work on improving
the range-based for)

[Bug c++/54320] [c++11] range access to VLA

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
No, begin/end are not supported for VLA; they would involve deducing a
non-constant value for the N template parameter, or compiler magic to recognize
the VLA case and avoid normal overload resolution.

[Bug c++/54320] [c++11] range access to VLA

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to vincenzo Innocente from comment #3)
> int foo2(int N) {
>   int v[N];
>   for ( auto a : v)
>     if (a) return a;
>   return 0;
> }
> 
> works, though was similar to std::begin(v) std::end(v)

Similar, but not the same:

"if _RangeT is an array type, begin-expr and end-expr are __range and __range +
__bound, respectively, where __bound is the array bound."

[Bug c++/54320] [c++11] range access to VLA

[daniel.kruegler at googlemail dot com]

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

--- Comment #13 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Paolo Carlini from comment #10)
FWIW, I fully agree with Jason: VLAs are very restricted and don't even allow
for forming references to them, so that the standard library won't even try to
provide begin()/end() overloads for them. You should use the new
std::dynarray<T> type instead for such support.
>From gcc-bugs-return-422066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 10 20:19:59 2013
Return-Path: <gcc-bugs-return-422066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19901 invoked by alias); 10 May 2013 20:19:59 -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 19831 invoked by uid 48); 10 May 2013 20:19:53 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA
Date: Fri, 10 May 2013 20:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-55278-4-11cMLguWHf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55278-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55278-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: 2013-05/txt/msg00739.txt.bz2
Content-length: 2526

http://gcc.gnu.org/bugzilla/show_bug.cgi?idU278

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I've looked a little bit on the #c6 testcase.
On i7-2600 CPU I get:
-O3 -mavx
1mo old gcc trunk        0m6.347s
1mo old gcc trunk reload 0m6.517s
curr trunk               0m6.049s
trunk unroll             0m5.800s
trunk unroll p1          0m5.671s
trunk unroll p1+p2       0m5.691s
clang 3.2                0m6.007s
clang 3.3 svn            0m6.003s
icc                      0m5.364s

where unroll is -funroll-loops --param max-completely-peeled-insnsP0 (to
match what icc does, which aggressively unrolls the huge inner loop that
iterates exactly 4 times), p1 is experimental hack:
+(define_insn "*<code>hi_1"
+  [(set (match_operand:HI 0 "nonimmediate_operand" "=r,rm")
+(any_or:HI
+ (match_operand:HI 1 "nonimmediate_operand" "%0,0")
+ (match_operand:HI 2 "general_operand" "rn,ri")))
+   (clobber (reg:CC FLAGS_REG))]
+  "ix86_binary_operator_ok (<CODE>, HImode, operands)"
+  "<logic>{l}\t{%k2, %k0|%k0, %k2}"
+  [(set_attr "type" "alu")
+   (set_attr "mode" "SI")])

(force gcc to avoid xorw memory, %hireg and instead use movzwl memory, %sireg;
... xorl %sireg, %sireg2) and p2 was something similar for *xorqi_1.

Looking at icc generated assembly, it is interesting to see that the only
HImode instructions it ever uses are rolw and movw stores, for everything else
it uses
movzwl loads and SImode arithmetics (well, I guess shift right shrw/sarw/rorw
can't be avoided either).  Similarly, icc on the testcase doesn't emit any
QImode instructions at all, while gcc emits tons of them and llvm something in
between.

So perhaps this bug is not about LRA, but about instruction selection, and when
not optimizing for size at least on some CPUs we should consider using SImode
arithmetics instead of QImode/HImode much more aggressively than we do now.
Not sure if it is better done by (Kai's?) type optimization pass, which shortly
before expansion using target hints would just try to get rid of as many QImode
and especially HImode operations as possible, guess we can often keep complete
garbage in the upper bits, or if it is better done at the *.md level.