https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83235
--- Comment #5 from Paul Romano ---
Got it; thanks for the clarification, and sorry for the noise! Guess I'll just
have to stop relying on this "feature" of previous versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83235
--- Comment #3 from Paul Romano ---
Thank you both for your quick responses. I understand that the bit model for
negative numbers is undefined and that x*x overflows and is thus also
undefined. However, the second argument to IAND is well-defined
ormal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.k.romano at gmail dot com
Target Milestone: ---
Created attachment 42760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42760&action=edit
Minimal example of IAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
--- Comment #2 from Paul Romano ---
Thanks for clarifying!
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.k.romano at gmail dot com
Target Milestone: ---
The following program results in a race condition on x:
program main
integer :: i, x = 0
!$omp parallel do reduction(+:x)
do i = 1, 10
call accumulate
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.k.romano at gmail dot com
It appears that performing !$omp atomic update on an automatic array does not
protect access to the array. As an example, consider the following program