[PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

Dear all, we need to check the arguments of the elemental MASKL and MASKR intrinsics also before simplifying. Testcase by Gerhard. The fix is almost obvious, but I'm happy to get feedback in case there is something I overlooked. (There is already a check on scalar arguments to MASKL/MASKR, whic

[PATCH] PR fortran/103778 - [10/11/12 Regression] ICE: Invalid expression in gfc_element_size

Dear all, again found by Gerhard: using a BOZ literal constant in situations where an interoperable object is expected can lead to an ICE. But obviously a BOZ in not interoperable. Obvious patch, regtested on x86_64-pc-linux-gnu. Will commit within 48h unless there are objections or better sugge

[PATCH] PR fortran/103776 - ICE in gfc_compare_string, at fortran/arith.c:1118

Dear all, we need to check that expressions in CASE selectors are scalar, and reject them early if they aren't. Testcase by Gerhard. The fix is obvious and sort of a follow-up to the fix for PR103591. Regtested on x86_64-pc-linux-gnu. Will commit as obvious within 48h unless there are objectio

[PATCH] OpenMP front-end: allow requires dynamic_allocators

Hi all, This patch removes the "sorry" message for the OpenMP "requires dynamic_allocators" feature in C, C++ and Fortran. The clause is supposed to state that the user code will not work without the omp_alloc/omp_free and omp_init_allocator/omp_destroy_allocator and these things *are* prese

Re: [patch, Fortran] Make REAL(KIND=16) detection more robust

Hi FX, I’m not opposed, but I’d really like to get this into the current branch. It is a much less invasive change than the power-ieee128 work. The only case I changed is the case where there is a kind 16, and there is a long double, but the long double is neither kind 10 neither kind 16. I