[Bug target/33437] potentially valid construct rejected

[Bug target/33437] potentially valid construct rejected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED
      Known to fail|                            |

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is not a valid C.  That is (int)(long)x where
sizeof(long)!=sizeof(int)!=sizeof(void*) the linker might not know the value at
link time and therefor will need a runtime relocation and then it might not
load at load time as the value would have gotten truncated.

[Bug target/33437] potentially valid construct rejected

[jbeulich at suse dot com]

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

jbeulich at suse dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|INVALID                     |---

--- Comment #3 from jbeulich at suse dot com ---
(In reply to Andrew Pinski from comment #2)
> This is not a valid C.

As per "All the expressions in an initializer for an object that has static or
thread storage duration shall be constant expressions or string literals."

long l = (long)x;

then either similarly isn't (yet the compiler accepts it), or both are (which
is my reading of the sentence, albeit further restrictions make this invalid).
Plus if it was strictly invalid, then why would a PPC compiler accept it (as
you've said yourself many years ago)?

It was for a reason that I did say  "potentially" in the title. Without knowing
what "x" is and what relocation types a target has, the compiler has no
justification to say "initializer element is not computable at load time". It
might use "may", but then it would still be overly limiting. As said in the
original description, "x" may simply stand for a small constant value, which C
does not allow to access any (meaningfully) other way than by expressing
through either an array (as in the example) or by using the address operator in
the initialization.

>  That is (int)(long)x where
> sizeof(long)!=sizeof(int)!=sizeof(void*) the linker might not know the value
> at link time and therefor will need a runtime relocation and then it might
> not load at load time as the value would have gotten truncated.

Hence it should be the assembler's job to determine whether a suitable
relocation type is available and the (static and/or dynamic) linker's job to
detect and report truncation / overflow. This is not the least because later
the standard also says "An implementation may accept other forms of constant
expressions."

[Bug target/33437] potentially valid construct rejected

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-11-15 00:43 -------
This works for me with PPC both 32bit and 64bit but fails with 64bit i686 and
works with 32bit x86.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c                           |target
     Ever Confirmed|0                           |1
  GCC build triplet|x86_64-linux-gnu            |
   GCC host triplet|x86_64-linux-gnu            |
 GCC target triplet|x86_64-linux-gnu            |x86_64-*-*
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-15 00:43:49
               date|                            |


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