https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #9 from Andrew Pinski ---
I am not 100% sure we should not transform this code. The way signals are
defined that only volatile/atomic variables can be done via signals.
This works:
```
static _Atomic int i;
static _Atomic int b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #8 from Alexander Monakov ---
Honza: ping :). ipa-pure-const might be a better place to mark functions with
compiler memory barriers, as it already computes and propagates "nonfreeing"
property (thus computing "nonbarrier" in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #7 from rguenther at suse dot de ---
On May 15, 2017 4:43:04 PM GMT+02:00, "amonakov at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
>
>--- Comment #6 from Alexander Monakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #6 from Alexander Monakov ---
I think a possible approach is to add a new cgraph_node flag (or a multi-bit
field, if we want to track presence of acquire/release/seq-cst compiler
barriers separately), handle asms and atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #5 from rguenther at suse dot de ---
On Mon, 15 May 2017, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
>
> --- Comment #4 from Alexander Monakov ---
> ipa-reference.c has:
>
> /* Set of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #4 from Alexander Monakov ---
ipa-reference.c has:
/* Set of all interesting module statics. A bit is set for every module
static we are considering. This is added to the local info when asm
code is found that clobbers all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #3 from rguenther at suse dot de ---
On Mon, 15 May 2017, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
>
> --- Comment #2 from Alexander Monakov ---
> Nowadays C has atomics and fences in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #2 from Alexander Monakov ---
Nowadays C has atomics and fences in the language standard, so it doesn't
matter if x() had
asm volatile("":::"memory");
or
__atomic_{signal,thread}_fence(__ATOMIC_ACQ_REL);
or
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,