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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #11 from Adam Warner --- Thank you Joseph for clarifying in Comment 10 why this should be considered an enhancement request. It would be non-trivial to change the model of what GNU C considers a constant expression and code relying on

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #10 from 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 (

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #9 from Jonathan Wakely --- (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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #8 from Adam Warner --- Joseph, you're correct: 4005fa: b8 c6 05 40 00 moveax,0x4005c6 4005ff: 89 05 cf 04 20 00 movDWORD PTR [rip+0x2004cf],eax # 600ad4 400605: b8 c6 05 40 00

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #7 from joseph at codesourcery dot com --- On Mon, 8 Sep 2014, adam at consulting dot net.nz wrote: > 3. To demonstrate this, a GNU extension to C++ has no problem computing the > address of the function pointer at load time and stor

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #6 from Adam Warner --- 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 initia

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #5 from Jonathan Wakely --- (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 m

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #4 from Adam Warner --- 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:

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

--- 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 #include #include void fn() { printf("Hello, World\n"); } uint32

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

--- 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

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

--- 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_