Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170625101704.GA2032@port70.net>
Date: Sun, 25 Jun 2017 12:17:04 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: more on missing volatile qualifications

* Jens Gustedt <jens.gustedt@...ia.fr> [2017-06-25 10:45:16 +0200]:
> 
>  - the definition of pthread_once_t
>  - the definition of pthread_spinlock_t
>  - the handler array in sigaction.c
> 
> All three could benefit for an additional volatile qualification. All
> their usages are already so, so this would just be conservative and
> not risk any incompatibilities, I think.

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.

> 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)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.