Re: not computable at load time

On Tue, 29 May 2018, Richard Biener wrote: > The testcase dates back to some repository creation rev. (egcs?) and > I'm not sure we may compute the difference of addresses of structure > members. So that GCC accepts this is probably not required. Joseph > may have a definitive answer here. My

Re: not computable at load time

> On May 29, 2018, at 5:49 AM, Richard Biener > wrote: > ... > It might be a "regression" with the POINTER_MINUS_EXPR introduction. > You can debug this with gdb when you break on 'pointer_diff'. For me > on x86_64 this builds a POINTER_DIFF_EXPR: (char *) - > of ptrdiff_t. That a

Re: not computable at load time

On Mon, May 28, 2018 at 8:34 PM Paul Koning wrote: > > On May 28, 2018, at 12:03 PM, Richard Biener > wrote: > > > > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote: > >> On Mai 28 2018, Richard Biener wrote: > >> > >>> It means there's no relocation that can express the result

Re: not computable at load time

> On May 28, 2018, at 12:03 PM, Richard Biener > wrote: > > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote: >> On Mai 28 2018, Richard Biener wrote: >> >>> It means there's no relocation that can express the result of 's.f - >> ' >>> and the frontend doesn't consider this a

Re: not computable at load time

On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab wrote: >On Mai 28 2018, Richard Biener wrote: > >> It means there's no relocation that can express the result of 's.f - >' >> and the frontend doesn't consider this a constant expression (likely

Re: not computable at load time

On Mai 28 2018, Richard Biener wrote: > It means there's no relocation that can express the result of 's.f - ' > and the frontend doesn't consider this a constant expression (likely because > of the conversion). Shouldn't the frontend notice that s.f - by itself is

Re: not computable at load time

"error: initializer element is not computable at load time". > I don't understand why because it seems to be a perfectly reasonable > compile time constant; "load time" doesn't enter into the picture that > I can see. It means there's no relocation that can express the result of 's

not computable at load time

One of my testsuite failures for the pdp11 back end is gcc.c-torture/compile/930326-1.c which is: struct { char a, b, f[3]; } s; long i = s.f- It fails with "error: initializer element is not computable at load time". I don't understand why because it seems to be a perfectly

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #6 from joseph at codesourcery dot com --- On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 > > --- Comment #5 from Martin Sebor --- > I"m not sure I understand what you're

Re: [Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 > > --- Comment #5 from Martin Sebor --- > I"m not sure I understand what you're saying. Your comment that "the > initializer *as > converted* must be a constant expression (and, thus,

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #5 from Martin Sebor --- I"m not sure I understand what you're saying. Your comment that "the initializer *as converted* must be a constant expression (and, thus, to be an address constant, must be of pointer type)" makes it sound

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #4 from joseph at codesourcery dot com --- On Sat, 13 May 2017, msebor at gcc dot gnu.org wrote: > I don't see what purpose rejecting > > bool b = ""; > > serves when > > bool b = !!""; > > or even > > bool b = "" ? 1 :

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #3 from Martin Sebor --- I don't see what purpose rejecting bool b = ""; serves when bool b = !!""; or even bool b = "" ? 1 : 0; are accepted. Even if it isn't 100% crystal clear, the standard encourages implementations

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #2 from joseph at codesourcery dot com --- See for my old syntactic model of constant expressions in C99. I'd consider it appropriate to handle implicit conversions in

[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 --- Comment #1 from joseph at codesourcery dot com --- I think it should be understood implicitly that it's the initializer *as converted* that must be a constant expression (and, thus, to be an address constant, must be of pointer type).

[Bug c/80730] New: bogus initializer element is not computable at load time converting a string to bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730 Bug ID: 80730 Summary: bogus initializer element is not computable at load time converting a string to bool Product: gcc Version: 7.0 Status: UNCONFIRMED

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

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

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

[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 adam at consulting dot net.nz --- 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

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

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

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

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

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

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

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

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

[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 --- Comment #5 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-10-12 11:56:06 UTC --- Author: jsm28 Date: Wed Oct 12 11:56:03 2011 New Revision: 179845 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179845 Log: PR c/50565 *

[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 --- Comment #6 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-10-12 11:57:39 UTC --- Author: jsm28 Date: Wed Oct 12 11:57:36 2011 New Revision: 179846 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179846 Log: PR c/50565 *

[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 --- Comment #7 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-10-12 11:58:52 UTC --- Author: jsm28 Date: Wed Oct 12 11:58:47 2011 New Revision: 179847 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179847 Log: PR c/50565 *

[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

is not computable at load time That's the offset1 initializer it's complaining about. Note that the offset0 initializer is accepted. If we comment out the offset1 definition we get: perl -pi -e 's,^const int offset1,//const int offset1,g' pr50565.c objdir/gcc/xgcc -Bobjdir/gcc/ -O2 -S pr50565.c

[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot

[Bug c/50565] New: [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Bug #: 50565 Summary: [4.5/4.6/4.7 Regression] initializer element is not computable at load time Classification: Unclassified Product: gcc Version: 4.6.2 Status

[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end

[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-29 17:03:28 UTC --- Anyreason Why ((int)( ((void *)(nmsgbuf.payload.part.ball.pos[0])) - ((void *)(nmsgbuf)) )) is being used instead of offsetof ?

Re: [named address] rejects-valid: error: initializer element is not computable at load time

Ulrich Weigand schrieb: Georg-Johann Lay wrote: Ulrich Weigand wrote: This is pretty much working as expected. pallo is a string literal which (always) resides in the default address space. According to the named address space specification (TR 18037) there are no string literals in

Re: [named address] rejects-valid: error: initializer element is not computable at load time

Georg-Johann Lay wrote: Ulrich Weigand wrote: This is pretty much working as expected. pallo is a string literal which (always) resides in the default address space. According to the named address space specification (TR 18037) there are no string literals in non-default address spaces

[named address] rejects-valid: error: initializer element is not computable at load time

pointer_type 0xb74db120 readonly constant arg 0 string_cst 0xb74cdf78 type array_type 0xb74db0c0 readonly constant static pallo\000 pgm.c:1:28 pgm.c:1:28 pgm.c:1:28 pgm.c:1:1: error: initializer element is not computable at load time

Re: [named address] rejects-valid: error: initializer element is not computable at load time

Georg-Johann Lay wrote: For the following 1-liner I get an error with current trunk r177267: const __pgm char * pallo = pallo; __pgm as a named address space qualifier. [snip] Moreover, if a user writes a line like const __pgm char * pallo = pallo; he wants the string literal to be

Re: [named address] rejects-valid: error: initializer element is not computable at load time

Ulrich Weigand wrote: Georg-Johann Lay wrote: For the following 1-liner I get an error with current trunk r177267: const __pgm char * pallo = pallo; __pgm as a named address space qualifier. [snip] Moreover, if a user writes a line like const __pgm char * pallo = pallo; he wants the

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

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

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

time This doesn't make any sense to me. -- Summary: Spurious error: initializer element is not computable at load time Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3

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

[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 other/26462] New: initializer element is not computable at load time

$ cat const.c #define B0 (+1.0l/5/1/6) const double c0 = B0; // initializer element is not computable at load time const double c0_tab[1] = { B0 }; // initializer element is not constant #define B1 (+1.0l/5) const double c1 = B1; // ok. const double c1_tab[1] = { B1 }; // initializer element

[Bug other/26462] initializer element is not computable at load time

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 --- This is a dup of bug 26374. The problem is that the middle-end does not fold IBM 128bit long double format currently. See PR 19405 for history on why. *** This bug has been marked as a duplicate of 26374 *** --