fix: use a bigger real transfering mask_val

[inaki-amatria]

This change ensures the type of mask_val is big enough to satisfy the transfer; otherwise, we risk transfering a 4-byte value to 2-element arrays of 4-byte elements (i.e., i4tmp(2) and r4tmp(2))

I encountered this issue compiling the project with Flang; see https://godbolt.org/z/91EfY154n

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules
• New check tests, if applicable, are included
• make distcheck passes

[inaki-amatria]

Bump! (I am sorry if this is not standard procedure. I just want to make sure this PR does not go unnoticed)

[bensonr]

Can you open an issue and explain what's happening and why this is needed with example code that demonstrates the problem. Also, as you add code, we require contributors to create new or modify an existing unit test to demonstrate proper behavior of the update for our CI/CD system and manual testing. If there is an expected failure condition, the unit test should also exercise it to ensure proper handling of the failure.

[inaki-amatria]

After careful consideration of the issue, I believe this is an error in the latest LLVM Flang compiler. Indeed, according to https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gfortran/TRANSFER.html: "If the bitwise representation of the result is longer than that of SOURCE, then the leading bits of the result correspond to those of SOURCE and any trailing bits are filled arbitrarily.". So this seems like a Flang bug (llvm/llvm-project#108832). I am sorry about the confusion and thank you very much for your valuable time!