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."
next prev 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: linkBe 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).