Re: more on missing volatile qualifications

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Hello Szabolcs,

On Sun, 25 Jun 2017 12:17:04 +0200 Szabolcs Nagy <nsz@port70.net> wrote:

> pthread_once_t and pthread_spinlock_t qualifiers are
> visible in the c++ name mangling if a c++ function takes
> pointer to them as arguments so the change is an abi break.

too bad, so we can't change these two

There is a reading of the C standard that says that volatile only has
implications if an object itself is such qualified, having a volatile
qualified lvalue access isn't enough. I don't think that any current
compiler does such weird things, but who knows where optimisers will
go in the future.

> > Also, I can't think of any semantics for the three, where
> > opitimizing out loads or stores makes any sense, so this also
> > should never see any kind of performance regression.  
> 
> there was a case in glibc when volatile caused problems:
> some generic atomic macro tried to create a temporary using
> 
>   __typeof(*(p)) __tmp = *(p);
> 
> but then __tmp become volatile and operations on it generated
> useless load/stores to the stack. it could be worked around as
> 
>   __typeof( (__typeof(*(p))) *(p) ) __tmp = *(p);
> 
> is not volatile because the cast expression is unqualified.
> (musl does not have such __typeof hacks, but it is an
> example where volatile caused unexpeced regression)

AFAICS for the third finding in sigaction.c this would not be an
issue. Since in addition this is something dealing with signal stuff,
I still think that volatile would be in order, here.

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]