[Bug fortran/83235] IAND sometimes doesn't take bitwise-and of sign bit with -O2

2017-12-01 Thread paul.k.romano at gmail dot com
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.

[Bug fortran/83235] IAND sometimes doesn't take bitwise-and of sign bit with -O2

2017-12-01 Thread paul.k.romano at gmail dot com
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

[Bug fortran/83235] New: IAND sometimes doesn't take bitwise-and of sign bit with -O2

2017-11-30 Thread paul.k.romano at gmail dot com
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

[Bug fortran/79247] Race condition on OpenMP reduction variable

2017-01-26 Thread paul.k.romano at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247 --- Comment #2 from Paul Romano --- Thanks for clarifying!

[Bug fortran/79247] New: Race condition on OpenMP reduction variable

2017-01-26 Thread paul.k.romano at gmail dot com
: 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

[Bug fortran/63938] New: OpenMP atomic update does not protect access to automatic array

2014-11-18 Thread paul.k.romano at gmail dot com
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