https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #15 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #14) > Created attachment 61006 [details] > Fix for this PR > > I believe that this fixes most, if not all, of the problems with the reduce > intrinsic. I will be packaging it up for submission over the next 24 hours. This looks almost very good. I have only minor suggestion for improvement. > I have only been able to test on x86_64. The key to the fix appears in > reduce_3.f90, which failed even with -m64. Although it was not apparent from > the tree dump, the scalar result was going on the stack. Once it became > larger than the word size, it pushed the arguments out of alignment with the > library prototype. Yes, that seems to explain the findings. > I took the opportunity to add character length checking to the library. I > think that it might be redundant and so might not appear in the submitted > version. I don't have clear opinion on this, but as the length check is used only once per REDUCE call, there is no real overhead. > I would appreciate feedback as soon as you can, please. I found the following places in iresolve.c::generate_reduce_op_wrapper that are possibly copy&paste issues: - the buffer for the symbol name of the wrapper can be too short if the names of the procedure and the operation are both 63 characters - the INTENT of the arguments a,b could also be IN instead of INOUT I will attach this minor change, as well as a corresponding update of testcase reduce_4.f90 that I leave up to you. (I could sometimes produce an ICE here, but not reliably without the buffer size fix.) > Paul Cheers, Harald
