public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/67129] New: x86: erratic parsing of "#pragma GCC target ("...")" Date: Thu, 06 Aug 2015 06:37:00 -0000 [thread overview] Message-ID: <bug-67129-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67129 Bug ID: 67129 Summary: x86: erratic parsing of "#pragma GCC target ("...")" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com Target Milestone: --- There's a bug in the way the "GCC target" pragma is translated into the "target" attribute on x86, and probably also on (all?) other platforms that base their implementation of the "GCC target" pragma and the "target" attribute on the code in i386.c and i386-c.c: According to the documentation, the last occurence of "#pragma GCC target ("...")" should always replace all previous occurences, and this is indeed what happens. On a machine with sse support, this code compiles just fine: -- snip -- #pragma GCC target ("fpmath=sse") #pragma GCC target ("no-sse") void t1(void) { } -- snip -- $ gcc -S t1.c (ok) The "no-sse" option wins, "fpmath=sse" is not used at all. However, *sometimes* during processing of the #pragma, the value of the old #pragma is used for checking validity of the new #pragma: -- snip -- #pragma GCC target ("fpmath=sse") #pragma GCC target ("no-sse") void t2(void) { } -- snip -- $ gcc -S t2.c /t2.c:2:9: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] t2.c:3:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] t2.c:3:1: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] Since this is only a warning, compilation continues, and eventually the old value gets discarded without causing any harm. However, if there is a combination of options that causes an error, gcc will fail to compile valid code. -- There is a bug in the implementation of i386-c.c:ix86_pragma_target_parse(). As far as I understand, when a "#pragma GCC target ("...")" is processed: 1. Use global_options as the target options structure. 2. Add the options defined in the string. 3. Check if the resulting options are valid. The last step fails when the secons #pragma is parsed. Then, when a function definition begins: 4. Look up the most recent target pragma definition and the function's target attribute and, if present, parse their strings in order. So, for functions everything is fine, but any definitions between the last #pragma and the next function definition is affected by the union of all #pragmas (after the last reset). Now, don't ask me why the warning in the example above is affected by the order of the two pragmas. I think to fix this, the function in i386-c.c should: 1. Make a working copy of the original global_options and global_options_set (the values that were affected only by command line options). No idea how to get the original values at that point in the code. 2. Call ix86_valid_target_attribute_tree() with that copy. 3. If the result is calid, overwrite global_options with the modified values in the copy.
next reply other threads:[~2015-08-06 6:37 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-08-06 6:37 vogt at linux dot vnet.ibm.com [this message] 2015-08-06 6:38 ` [Bug target/67129] " vogt at linux dot vnet.ibm.com 2015-08-06 6:39 ` vogt at linux dot vnet.ibm.com 2015-08-06 6:41 ` vogt at linux dot vnet.ibm.com 2015-08-06 7:57 ` vogt at linux dot vnet.ibm.com 2015-08-06 11:06 ` vogt at linux dot vnet.ibm.com 2021-09-02 8:29 ` pinskia at gcc dot gnu.org 2021-09-02 8:34 ` pinskia at gcc dot gnu.org 2021-09-02 8:35 ` pinskia at gcc dot gnu.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-67129-4@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).