Bug 46028 - Regression from GCC 4.4: "storage size of 'test_array' isn't constant"
Summary: Regression from GCC 4.4: "storage size of 'test_array' isn't constant"
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.5.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-14 23:20 UTC by Marti Raudsepp
Modified: 2021-09-24 22:26 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
_configtest.i (200 bytes, text/plain)
2010-10-14 23:20 UTC, Marti Raudsepp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marti Raudsepp 2010-10-14 23:20:23 UTC
Created attachment 22046 [details]
_configtest.i

When building the Python NumPy library for Python 3.x, it does the following test compilation test:

typedef struct {float __x; float __y;} npy_check_sizeof_type;
int main ()
{
    static int test_array [1 - 2 * !(((long) (sizeof (npy_check_sizeof_type))) <= 16.0)];
    test_array [0] = 0
...

This code compiles fine with GCC 4.4.5 on Ubuntu, but fails with GCC 4.5.1 on Arch Linux x86_64:

% gcc _configtest.c
_configtest.c: In function 'main':
_configtest.c:5:16: error: storage size of 'test_array' isn't constant

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
Thread model: posix
gcc version 4.5.1 (GCC)
Comment 1 Andrew Pinski 2010-10-14 23:21:53 UTC
16.0 is a floating point number which I think is causing the issue.
Comment 2 Andrew Pinski 2010-10-14 23:23:10 UTC
Comeau C/C++ gives the following error message for the above testcase:
"ComeauTest.c", line 5: error: expression must have integral type
  <= 16.0)];
Comment 3 jsm-csl@polyomino.org.uk 2010-10-15 01:01:13 UTC
Note that you can't trivially extend the laxity in

                    /* Handle a size folded to an integer constant but
                       not an integer constant expression.  */
                    if (!size_int_const)
                      {
                        /* If this is a file scope declaration of an
                           ordinary identifier, this is invalid code;
                           diagnosing it here and not subsequently
                           treating the type as variable-length avoids
                           more confusing diagnostics later.  */
                        if ((decl_context == NORMAL || decl_context == FIELD)
                            && current_scope == file_scope)
                          pedwarn (input_location, 0,
                                   "variably modified %qE at file scope",
                                   name);
                        else
                          this_size_varies = size_varies = true;
                        warn_variable_length_array (name, size);
                      }

(that does a pedwarn rather than an error if this occurs at file scope) to 
the present case of a static array inside a function, because it's valid 
to have a block scope static *pointer* to VLA (which is however different 
from a pointer to non-VLA), so you'd need to be lax only if it's a static 
array rather than a pointer to such.
Comment 4 philipp 2011-03-14 10:37:15 UTC
This fails, too: "error: storage size of ‘sv’ isn’t constant"

int main(void)
{
    const int len = 20;
    static char sv[len];
}



Similarly, gcc 4.4 accepted 

  #define CONST_STRING "aaa"
  static char x[strlen(CONST_STRING)];

but gcc-4.5 does not.
(Of course, I could overload "strlen" ... but whether that's enough reason to reject that?)