[Bug c/38354] Spurious error: initializer element is not computable at load time

[Bug c/38354] Spurious error: initializer element is not computable at load time

[adam at consulting dot net.nz]

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

--- Comment #4 from Adam Warner <adam at consulting dot net.nz> ---
Why can a compile-time array of 32-bit function pointers (compatible with the
non-large code model) be compiled using g++ but not gcc?


$ g++ -fpermissive computable_at_load_time.c
computable_at_load_time.c:9:41: warning: invalid conversion from ‘void (*)()’
to ‘uint32_t {aka unsigned int}’ [-fpermissive]
 uint32_t computable_at_load_time_a[]={fn};
                                         ^
[No errors and line 10 compiles without warning]


$ gcc -fpermissive computable_at_load_time.c
cc1: warning: command line option ‘-fpermissive’ is valid for C++/ObjC++ but
not for C
computable_at_load_time.c:9:1: warning: initialization makes integer from
pointer without a cast
 uint32_t computable_at_load_time_a[]={fn};
 ^
computable_at_load_time.c:9:1: warning: (near initialization for
‘computable_at_load_time_a[0]’)
computable_at_load_time.c:9:1: error: initializer element is not computable at
load time
computable_at_load_time.c:9:1: error: (near initialization for
‘computable_at_load_time_a[0]’)
computable_at_load_time.c:10:1: error: initializer element is not constant
 uint32_t computable_at_load_time_b[]={(uint32_t) (ptrdiff_t) fn};
 ^
computable_at_load_time.c:10:1: error: (near initialization for
‘computable_at_load_time_b[0]’)


The claim that the initializer element is not computable at load time is
spurious.

Permitting this code to compile when the -fpermissive flag is supplied seems
reasonable: "-fpermissive: Downgrade some diagnostics about nonconformant code
from errors to warnings. Thus, using -fpermissive allows some nonconforming
code to compile."
>From gcc-bugs-return-461285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 05 10:37:46 2014
Return-Path: <gcc-bugs-return-461285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29155 invoked by alias); 5 Sep 2014 10:37:46 -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 29134 invoked by uid 48); 5 Sep 2014 10:37:42 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
Date: Fri, 05 Sep 2014 10:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-63175-4-T5G9xj1lIT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63175-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63175-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-09/txt/msg01119.txt.bz2
Content-length: 2298

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc-linux-gnu           |powerpc*-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-05
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Also seen on powerpc-apple-darwin9 from r199859 up to 214282 (last regtesting),
r198852 is OK.

The test uses -fno-common:

Executing on host: /opt/gcc/darwin_buildw/gcc/xgcc
-B/opt/gcc/darwin_buildw/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -ftree-vectorize
-fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-slp-details  -lm
-m32  -o ./costmodel-bb-slp-9a.exe    (timeout = 300)
spawn /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize
-fvect-cost-model=dynamic -fno-common -maltivec -fdump-tree-slp-details -lm
-m32 -o ./costmodel-bb-slp-9a.exe^M
PASS: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/opt/gcc/darwin_buildw/gcc::/opt/gcc/darwin_buildw/gcc
spawn [open ...]^M
PASS: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c execution test
Executing on host: /opt/gcc/darwin_buildw/gcc/xgcc
-B/opt/gcc/darwin_buildw/gcc/ arm_vect_no_misalign48217.c
-fno-diagnostics-show-caret -fdiagnostics-color=never  -S  -m32  -o
arm_vect_no_misalign48217.s    (timeout = 300)
spawn /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/gcc/
arm_vect_no_misalign48217.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -S -m32 -o arm_vect_no_misalign48217.s^M
arm_vect_no_misalign48217.c:3:3: error: #error FOO^M
compiler exited with status 1
output is:
arm_vect_no_misalign48217.c:3:3: error: #error FOO^M

FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2
"basic block vectorized using SLP" 1

[Bug c/38354] Spurious error: initializer element is not computable at load time

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Adam Warner from comment #4)
> Why can a compile-time array of 32-bit function pointers (compatible with
> the non-large code model) be compiled using g++ but not gcc?

The C standard is much more restrictive about what is allowed in constant
initializers than the C++ standard.

> Permitting this code to compile when the -fpermissive flag is supplied seems
> reasonable: "-fpermissive: Downgrade some diagnostics about nonconformant
> code from errors to warnings. Thus, using -fpermissive allows some
> nonconforming code to compile."

But as the compiler tells you, that option is only valid for the C++ front-end.

[Bug c/38354] Spurious error: initializer element is not computable at load time

[adam at consulting dot net.nz]

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

--- Comment #6 from Adam Warner <adam at consulting dot net.nz> ---
Just to make sure I understand this correctly:

1. You won't confirm this bug because it violates the C standard.

2. GNU provides extensions to C when the C standard is too restrictive. In this
case the initializer element is *clearly* computable at load time because all
function pointers are *already* 32 bits under the non-large code model.

3. To demonstrate this, a GNU extension to C++ has no problem computing the
address of the function pointer at load time and storing it in a 32-bit integer
array.

4. Just because C is supposed to be a portable assembler and lower level than
C++ doesn't mean you should be able to store a 32-bit address in a 32-bit
integer at load time. Even though GNU C++ can.

5. Use GNU C++ if you want code to run fast when the L1 data cache is being
trashed by function pointer lookup tables that are twice their necessary size.
C has strict type checking which must not be violated at load time. Goto 1.

[Bug c/38354] Spurious error: initializer element is not computable at load time

[adam at consulting dot net.nz]

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

--- Comment #8 from Adam Warner <adam at consulting dot net.nz> ---
Joseph, you're correct:

  4005fa:       b8 c6 05 40 00          mov    eax,0x4005c6
  4005ff:       89 05 cf 04 20 00       mov    DWORD PTR [rip+0x2004cf],eax    
   # 600ad4 <computable_at_load_time_a>
  400605:       b8 c6 05 40 00          mov    eax,0x4005c6
  40060a:       89 05 c8 04 20 00       mov    DWORD PTR [rip+0x2004c8],eax    
   # 600ad8 <computable_at_load_time_b>

0x4005c6 is the address of the function which is loaded into the lookup table
by a static initializer function at run time.

This is identical to the workaround in C where a lookup table of 32-bit
pointers has to be populated at run time. I agree it is not significant that
the code is accepted for C++. I'm sorry about that.

What I've done in the past is use Perl to generate printf statements to output
the 32-bit addresses as an integer array. The generated array is then compiled
into the binary. A command-line option performs a check that the integer
addresses match the newly compiled function addresses. It usually takes one
additional generation/compilation before they all match up.

It is ridiculous this x86_64 workaround is required to map constants into
memory at load time when the functions occupy (under the default code model)
the same lower 31-bit address space as i386.

The original issue from six years ago is that compilation fails with the error
"initializer element is not computable at load time". These calculations are
computable at load time so the error message is spurious. But from a C language
perspective they might not be computable at load time. Thus I believe a
compiler warning is more appropriate than an error. That's the path to
finalising this bug report:

1. Can you confirm from a technical perspective that the error is spurious? If
so the bug report is CONFIRMED. If there are in fact good technical reasons why
the error is valid then please close the bug report as INVALID.

2. If the bug report is confirmed then please decide whether the project will
turn the error message into a warning. If the project will not do this then
please close the bug report as WONTFIX. This part is ultimately a political
decision. Either way it would be nice to have a resolution.

[Bug c/38354] Spurious error: initializer element is not computable at load time

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Adam Warner from comment #6)
> Just to make sure I understand this correctly:
> 
> 1. You won't confirm this bug because it violates the C standard.

You asked why it works with C++ and I told you, I didn't say anything about
confirming it or not, because I'm not a C front-end maintainer so it's not my
place to decide what is a bug in the C front-end. (IMHO it's not a bug, but
might be a valid enhancement request.)

I stand by my statement that the C standard is more restrictive about what is
allowed in a static initializer.  C++ has a "dynamic initialization" phase
which does not exist for C.

> 2. GNU provides extensions to C when the C standard is too restrictive. In
> this case the initializer element is *clearly* computable at load time
> because all function pointers are *already* 32 bits under the non-large code
> model.
> 
> 3. To demonstrate this, a GNU extension to C++ has no problem computing the
> address of the function pointer at load time and storing it in a 32-bit
> integer array.

It's not a GNU extension, it's required by the C++ standard, and it happens at
runtime, so that fails to demonstrate your point.

> 4. Just because C is supposed to be a portable assembler and lower level
> than C++ doesn't mean you should be able to store a 32-bit address in a
> 32-bit integer at load time. Even though GNU C++ can.

Except it can't.

[Bug c/38354] Spurious error: initializer element is not computable at load time

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
This seems like an enhancement request to me.  Initializers using a 64-bit 
function address cast to 32-bit are outside the scope of my model of 
constant expressions for GNU C 
(<http://www.polyomino.org.uk/computer/c/const-exprs-gnu.txt> - fairly 
old, may be out of date).  It so happens that the x86_64 ABI does include 
a relocation for 32-bit symbol references (in fact two of them, 
R_X86_64_32 and R_X86_64_32S), but I don't believe GCC has that 
information about what relocations the target supports at present (and 
then there would be the question of which of those two relocations to use, 
though maybe that's a question for the assembler).

[Bug c/38354] Spurious error: initializer element is not computable at load time

[adam at consulting dot net dot nz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]



------- Comment #3 from adam at consulting dot net dot nz  2010-08-17 06:28 -------
AMD64 non-large code model. Functions occupy lower 2GB of the address space.
Cannot compile an array of 32-bit function addresses:

#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

void fn() {
  printf("Hello, World\n");
}

uint32_t computable_at_load_time_a[]={fn};
uint32_t computable_at_load_time_b[]={(uint32_t) (ptrdiff_t) fn};

int main() {
  return 0;
}

$ gcc -m32 computable_at_load_time.c
computable_at_load_time.c:9: warning: initialization makes integer from pointer
without a cast

$ gcc computable_at_load_time.c
computable_at_load_time.c:9: warning: initialization makes integer from pointer
without a cast
computable_at_load_time.c:9: error: initializer element is not computable at
load time
computable_at_load_time.c:9: error: (near initialization for
‘computable_at_load_time_a[0]’)
computable_at_load_time.c:10: error: initializer element is not constant
computable_at_load_time.c:10: error: (near initialization for
‘computable_at_load_time_b[0]’)

The very good reason for wanting to compile a table of 32-bit function pointers
is to halve the data cache footprint of threaded code.


-- 

adam at consulting dot net dot nz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adam at consulting dot net
                   |                            |dot nz


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

[Bug c/38354] Spurious error: initializer element is not computable at load time

[gnu at behdad dot org]

------- Comment #2 from gnu at behdad dot org  2008-12-01 23:38 -------
It's not a useful use case, agreed, but I don't see how that affects the
computability of a value at "load time", whatever that means.  It did trick me:
I was converting a vtable to use label values, and before converting the
function pointer type of the array to int, I tried a compile and got the error.
 I didn't expect the error to go away if I replace the function pointer type
with an int.  To my surprise, it did.

What I'm saying is that the statement in the error message is false.


-- 


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

[Bug c/38354] Spurious error: initializer element is not computable at load time

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2008-12-01 23:33 -------
What's the rationale for using a pointer type for something that is integral
(difference of 2 pointers)?
I don't see why we should support that as a valid constant initializer.


-- 


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