public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization Date: Wed, 15 Apr 2020 07:05:17 +0000 [thread overview] Message-ID: <bug-94600-4-oceGq1Pfi7@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-94600-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- We're going through rtx store_expr (tree exp, rtx target, int call_param_p, bool nontemporal, bool reverse) { ... normal_expr: /* If we want to use a nontemporal or a reverse order store, force the value into a register first. */ tmp_target = nontemporal || reverse ? NULL_RTX : target; temp = expand_expr_real (exp, tmp_target, GET_MODE (target), (call_param_p ? EXPAND_STACK_PARM : EXPAND_NORMAL), &alt_rtl, false); which expands directly into target via else if (optimize >= 1 && modifier != EXPAND_CONST_ADDRESS && modifier != EXPAND_INITIALIZER && modifier != EXPAND_MEMORY && TREE_READONLY (array) && ! TREE_SIDE_EFFECTS (array) && TREE_CODE (index) == INTEGER_CST && (VAR_P (array) || TREE_CODE (array) == CONST_DECL) && (init = ctor_for_folding (array)) != error_mark_node) { ... /* If VALUE is a CONSTRUCTOR, this optimization is only useful if this doesn't store the CONSTRUCTOR into memory. If it does, it is more efficient to just load the data from the array directly. */ rtx ret = expand_constructor (value, target, modifier, true); and then store_constructor (exp, target, 0, int_expr_size (exp), false); store_constructor cannot anymore fail and since we're invoking expand_constructor with avoid_temp_mem == true that's the place to fixup I think, possibly by amending /* Handle calls that pass values in multiple non-contiguous locations. The Irix 6 ABI has examples of this. */ if (target == 0 || ! safe_from_p (target, exp, 1) || GET_CODE (target) == PARALLEL || modifier == EXPAND_STACK_PARM) { if (avoid_temp_mem) return NULL_RTX; with the case for volatile target. Or of course at the very toplevel by passing down a different expand modifier or by skipping ctor folding. Note that an aggregate volatile assignment is not very well specified when bitfields are involved - C says the copy is elementwise and then strict volatile bitfield semantics would suggest that N stores happen together with the required reads for RMW cycles. So I'm not sure if this is really a bug or rather wrong user expectation.
next prev parent reply other threads:[~2020-04-15 7:05 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-14 23:27 [Bug middle-end/94600] New: " hp at gcc dot gnu.org 2020-04-14 23:32 ` [Bug middle-end/94600] " hp at gcc dot gnu.org 2020-04-14 23:36 ` hp at gcc dot gnu.org 2020-04-15 6:46 ` rguenth at gcc dot gnu.org 2020-04-15 7:05 ` rguenth at gcc dot gnu.org [this message] 2020-04-15 7:06 ` rguenth at gcc dot gnu.org 2020-04-15 7:07 ` rguenth at gcc dot gnu.org 2020-04-15 22:33 ` joseph at codesourcery dot com 2020-04-15 22:45 ` hp at gcc dot gnu.org 2020-07-13 6:09 ` cvs-commit at gcc dot gnu.org 2020-07-13 6:30 ` cvs-commit at gcc dot gnu.org 2020-08-13 3:13 ` cvs-commit at gcc dot gnu.org 2020-12-04 19:29 ` cvs-commit at gcc dot gnu.org 2020-12-04 19:37 ` cvs-commit at gcc dot gnu.org 2021-12-21 2:46 ` hp 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-94600-4-oceGq1Pfi7@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).