Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread Jerry D
rtran 15.1? Regards, Christopher Zapart National Astronomical Observatory in Japan Greetings to Japan folks. Can you post a sample a short sample program on our bugzilla so we can track this? It really helps to do this. See https://gcc.gnu.org/bugzilla/ I am testing here on gcc version 15.0.1 20250416

Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread Steve Kargl
On Wed, Apr 16, 2025 at 04:44:23AM +, ZAPART CHRISTOPHER ANDREW wrote: > > After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14 > to 15.0.1: > > [chris@fedora FITSWEBQLSE]$ gfortran --version > GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0) > > The new version

Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread Jerry D
On 4/16/25 6:48 PM, ZAPART CHRISTOPHER ANDREW wrote: Sorry don’t have a bugzilla account yet. For completeness here is a full test code that also calls a pure subroutine from within a “block” located inside a “do concurrent” loop. Regards, Chris gfortran -march=native -g -Ofast -fPIC -fno-fin

Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread Jerry D
testing here on gcc version 15.0.1 20250416 (experimental) (GCC) so this is listed as experimental. Looking here: https://gcc.gnu.org/develop.html#timeline 15 is not quite released but its pretty close. I did not catch a notification on it. Best regards, Jerry This is likely now PR119836

Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread ZAPART CHRISTOPHER ANDREW
Sorry don’t have a bugzilla account yet. For completeness here is a full test code that also calls a pure subroutine from within a “block” located inside a “do concurrent” loop. Regards, Chris gfortran -march=native -g -Ofast -fPIC -fno-finite-math-only -funroll-loops -ftree-vectorize -fopenmp

Re: Fortran 15.0.1 treats "shiftl" as impure

2025-04-16 Thread ZAPART CHRISTOPHER ANDREW
Hi guys, Thank you everyone for looking so promptly into it. Since you already have created a test program on GCC Bugzilla there is no point in duplicating the efforts. The “offending” intrinsics “shift” and “min” are indeed used from within a “block”, as per your “wrongly rejected” test code.