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.
