[llvm-bugs] [Bug 39707] Wrong condition evaluation

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39707

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #5 from Richard Smith <richard-llvm at metafoo.co.uk> ---
(In reply to Roger from comment #4)
> opt_bootscrub lives in the .init section, and whether the virtual address is
> valid or not depends on the value of system_state (mappings for .init data
> are removed if system_state >= SYS_STATE_active).

I see, thanks for explaining.

LLVM assumes that regular global variables don't behave this way (and in
particular, that loads and stores of them have no side-effects beyond the
memory being stored). This is not really specific to LLVM, though; other
optimizing compilers make similar assumptions. As far as I'm aware, we don't
have any flag or setting to turn this off when optimizing.

Because a load or store of this variable *does* have an additional side-effect
beyond the normal semantics (in particular, it can trap if the section
containing it has been unmapped), the variable should be marked 'volatile' to
prevent accesses of it being speculated or reordered.

I'm going to mark this as working as intended on the above basis, but please do
reopen if you still see this load being speculated when the variable is marked
as volatile, or if there's something in the code that you think should already
be sufficient to imply that the load of the variable can't be hoisted. (Also,
if GCC has a flag to turn off this assumption or similar, we'd probably be
interested in a compatibility feature for that.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181120/20ecd016/attachment.html>