[Bug c++/66921] failure to determine size of static constexpr array that is nested within a templated class

["billydonahue at google dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Billy Donahue <billydonahue at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |billydonahue at google dot com

--- Comment #2 from Billy Donahue <billydonahue at google dot com> ---
(In reply to Vlad Petric from comment #0)
> Created attachment 36010 [details]
> straightforward file (include-less) that fails to compile
> 
> template<typename T>
> struct Holder {
>   constexpr static const int array[] = { 1, 2, 3 };
>   enum {F = array[0]};
> };
> 
> class HI: public Holder<int> {};
> 
> gcc 4.9.3/Centos linux.
> 
> $ g++ -std=c++11 ./x.cc -o x.o -c
> ./x.cc: In instantiation of ‘constexpr const int Holder<int>::array []’:
> ./x.cc:4:18:   required from ‘struct Holder<int>’
> ./x.cc:7:18:   required from here
> ./x.cc:3:30: error: initializer fails to determine size of
> ‘Holder<int>::array’
>    constexpr static const int array[] = { 1, 2, 3 };
>                               ^
> ./x.cc:3:30: error: array must be initialized with a brace-enclosed
> initializer
> ./x.cc: In instantiation of ‘struct Holder<int>’:
> ./x.cc:7:18:   required from here
> ./x.cc:4:8: error: enumerator value for ‘F’ is not an integer constant
>    enum {F = array[0]};
> 
> 
> 
> * with gcc 4.8.3, it compiles just fine.
> 
> * if I remove the template, it also compiles just fine:
> 
> struct Holder {
>   constexpr static const int array[] = { 1, 2, 3 };
>   enum {F = array[0]};
> };
> 
> class HI: public Holder {};

I little bit of trial-and-error on gcc.godbolt.org confirms this is a problem
in gcc in the v4.9 series and beyond to the current v5.2, not a problem in the
v4.8 series.
http://goo.gl/li99SI

Clang compiles it okay, FWIW.

If I explicitly size the array[3], then all gcc's will compile it fine.

template<typename T>
struct Holder {
  // builds in modern gcc as long as the 3 is specified.
  constexpr static int array[3] = { 123, 234, 345 };
  enum {F = array[0]};
};
Holder<void> inst{};
>From gcc-bugs-return-492852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 17:00:43 2015
Return-Path: <gcc-bugs-return-492852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 99777 invoked by alias); 20 Jul 2015 17:00:43 -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 99703 invoked by uid 48); 20 Jul 2015 17:00:37 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/66929] [6 regression] ICE with iso_varying_string
Date: Mon, 20 Jul 2015 17:00: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
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-66929-4-b1qPPW928d@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66929-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66929-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-07/txt/msg01742.txt.bz2
Content-length: 2572

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

Jürgen Reuter <juergen.reuter at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Also just stumbled over this one. Happens for us with r225979:

libtool: compile:  /var/lib/jenkins/slave/opt/gcc-6.0-225979/bin/gfortran -g
-O2 -c ../../../omega/src/iso_varying_string.f90  -fPIC -o
.libs/iso_varying_string.o
../../../omega/src/iso_varying_string.f90:2467:0:

           rep_string = substring//extract(work_string,
start=i_target+length_target)//rep_string
1
internal compiler error: Segmentation fault
0xbde39f crash_signal
        ../../source/gcc/toplev.c:352
0x6aa154 expr_may_alias_variables
        ../../source/gcc/fortran/trans-expr.c:4566
0x6b0d71 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
        ../../source/gcc/fortran/trans-expr.c:5405
0x6b5a12 gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../source/gcc/fortran/trans-expr.c:7482
0x6bc4a8 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
        ../../source/gcc/fortran/trans-expr.c:7617
0x6b140f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
        ../../source/gcc/fortran/trans-expr.c:5055
0x6b5a12 gfc_conv_expr(gfc_se*, gfc_expr*)
        ../../source/gcc/fortran/trans-expr.c:7482
0x6bd840 gfc_trans_assignment_1
        ../../source/gcc/fortran/trans-expr.c:9204
0x678d35 trans_code
        ../../source/gcc/fortran/trans.c:1674
0x6eea43 gfc_trans_if_1
        ../../source/gcc/fortran/trans-stmt.c:1106
0x6f58ea gfc_trans_if(gfc_code*)
        ../../source/gcc/fortran/trans-stmt.c:1137
0x678b57 trans_code
        ../../source/gcc/fortran/trans.c:1771
0x6f78d4 gfc_trans_do_while(gfc_code*)
        ../../source/gcc/fortran/trans-stmt.c:2083
0x678b07 trans_code
        ../../source/gcc/fortran/trans.c:1791
0x6a69bf gfc_generate_function_code(gfc_namespace*)
        ../../source/gcc/fortran/trans-decl.c:5884
0x67d1d1 gfc_generate_module_code(gfc_namespace*)
        ../../source/gcc/fortran/trans.c:2045
0x63449d translate_all_program_units
        ../../source/gcc/fortran/parse.c:5506
0x63449d gfc_parse_file()
        ../../source/gcc/fortran/parse.c:5724
0x675792 gfc_be_parse_file
        ../../source/gcc/fortran/f95-lang.c:209
>From gcc-bugs-return-492853-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 17:18:53 2015
Return-Path: <gcc-bugs-return-492853-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76713 invoked by alias); 20 Jul 2015 17:18:52 -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 76649 invoked by uid 48); 20 Jul 2015 17:18:48 -0000
From: "pilot.mm at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/66932] Preprocessor includes wrong header file
Date: Mon, 20 Jul 2015 17:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pilot.mm at gmail dot com
X-Bugzilla-Status: WAITING
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-66932-4-WjL3w6m4wQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66932-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66932-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-07/txt/msg01743.txt.bz2
Content-length: 1190

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

--- Comment #5 from Michael McWilliam <pilot.mm at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> An empty : causes the current directory to be added.

Thanks for explaining that... Including the current directory with an empty :
makes sense (as it is in the documented). However that does not seem to be what
is happening considering this causes ../bfd/ to take precedent over ./. Simply
setting C_INCLUDE_PATH to any of the following will cause the error:

C_INCLUDE_PATH=":"
C_INCLUDE_PATH=":/usr/include/"
C_INCLUDE_PATH="./"
C_INCLUDE_PATH="/usr/include/:"

According to the documentation the -I directives are included first, then those
of C_INCLUDE_PATH, then the system headers. In this problem the local directory
is included first with -I. So it seems that when the compiler sees a directory
in C_INCLUDE_PATH it forgets any duplicates specified with -I and the include
precedence is being broken. Stated simply I think gcc is failing to check if an
include directory is already specified when it adds C_INCLUDE_PATH headers in
lower precedence.

So it seems it is a real bug... and a somewhat obscure bug...