https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #8 from Claudio Kozický ---
Created attachment 51630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51630&action=edit
GCC 11.1.0 preprocessed source
executed command: gcc -v -save-temps -fsanitize=undefined -fopenmp
minimal_exa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
Claudio Kozický changed:
What|Removed |Added
Attachment #51628|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #6 from Claudio Kozický ---
Created attachment 51628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51628&action=edit
GCC version
This is the version of GCC with which I have reproduced the bug with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
Claudio Kozický changed:
What|Removed |Added
CC||claudiokozicky at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #4 from Marek Polacek ---
But these *.Lubsan_data0 are read-only I think, so I don't think there's a
problem if multiple threads read such a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
I think you should treat these artifical variables as private, not shared. If
you treated them as shared, threads would race with each other when accessing
them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
--- Comment #2 from Marek Polacek ---
Started looking into this. Seems that we should handle specially those
artificial ubsan decls such as *.Lubsan_data in omp_default_clause, i.e. treat
them as shared? But I hardly know what I'm talking about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64888
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
