RFR (tedious) 8216022: Use #pragma once

[Andrew Haley]

On 1/5/19 3:03 PM, Erik Österlund wrote:

> I have asked this before, but does anyone actually know of a 
> compiler/os/filesystem combo that has a #pragma once implementation that 
> gets confused about symbolic links or different include paths, or is 
> this all a hypothetical problem, for a hypothetical 
> compiler+os+filesystem combo that can probably never support e.g. C++17? 

When we were discussing the possibility of using compiler intrinsics
for atomic operations you used the following hypothetical reason to
oppose the idea:

> 2) Even if you could and the compiler happens to generate that - we
> can not rely on it because there is no contract to the compiler what
> fence instructions it elects to use. The only contract the compiler
> needs to abide to is how atomic C++ operations interact with other
> C++ operations. And we do not want the underlying fencing to
> silently change when performing compiler upgrades.

I could surely have replied to this with a question along the lines of
"Does anyone know of a compiler/processor combo that actually changed
its atomic operations in a semantically incompatible way?", i.e. used
exactly the same reasoning as you're using above.

It's not practically possible for a compiler silently to change
atomics in the way that you suggested here because it would break
binary compatibility, but you insisted that because it's
*hypothetically* possible we shouldn't use such atomic intrinsics.

Perhaps we should beware of relying on compiler properties that aren't
standardized and so might silently change when performing compiler
upgrades, even when such changes are extremely unlikely. I don't think
so, but I admit it is at least an argument.

I suggest to you that these two cases are very similar: they're both
about relying on compiler behaviour that is not standardized.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671