public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jbeulich at suse dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/33437] potentially valid construct rejected
Date: Tue, 10 Aug 2021 08:04:26 +0000	[thread overview]
Message-ID: <bug-33437-4-qQmTcS7K7C@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-33437-4@http.gcc.gnu.org/bugzilla/>

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

  parent reply	other threads:[~2021-08-10  8:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-33437-4@http.gcc.gnu.org/bugzilla/>
2021-08-09  4:58 ` pinskia at gcc dot gnu.org
2021-08-10  8:04 ` jbeulich at suse dot com [this message]
2007-09-14 15:25 [Bug c/33437] New: " jbeulich at novell dot com
2008-11-15  0:45 ` [Bug target/33437] " pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-33437-4-qQmTcS7K7C@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).