[R-pkg-devel] Assumed-size arrays in fortran and memory sanitizer

[Simon Urbanek]

Karline,

as far as I can tell, the issue (assuming we're talking about  https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-ASAN/limSolve/00check.log ) looks like a compiler optimisation issue where the compiler tries to optimise the copy (since the xDCOPY code does it one element at at a time for subsequent entries in the same column) by using memcpy() of the region (the output shows 32 bytes so 4 elements are being copied), but that is illegal for overlapping regions - which is the case here. The Fortran code is specifying the copy to be done sequentially (it is a element-wise loop) so the algorithm works fine as long as the second (target) region comes before the first region (which is it true as the code guarantees it) so the compiler should not be attempting to use memcpy() to do that, but at best should use memmove() in that case. The problem is that the resulting code will actually be wrong, so ASAN is correct, but it's not the Fortran's code fault. I'd try to reduce optimisations to see if that problem goes away. Unfortunately, I could not find anything on the optimisation in flang nor if there is a way to disable it in the code itself. Probably best would be to report it and see what the flang authors think (I could be wrong).

Cheers,
Simon


> On 26 Jun 2026, at 00:00, Karline Soetaert <karline.soetaert using nioz.nl> wrote:
> 
> Hi all,
> 
> I am the maintainer of an R-package, called limSolve, that solves least-squares problems. The package does not survive the clang-ASAN compilation, and is now scheduled to be removed from CRAN.
> 
> The error I get is (simplified):
> ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [...) and [..) overlap.
> 
> I have tried to make fixes to the exact location where this error emerges, but, even if I am successful, then a similar error emerges somewhere else.
> 
> After trying many things, my best guess now is that this is due to the use of *assumed-size arrays* in this old fortran code, which may not be compatible with the address sanitizer.
> 
> As a simple example of what I think is happening:
> in the function *DLSEI* a matrix called *W* is defined as:
>                double precision :: W(MDA, *)
> This means that W has MDA rows, and an undefined number of columns (but, as the exact size of this matrix is set in R, its memory location is known).
> Now several functions are called that operate on *rows* of W.  Let�s say, somewhere it calls a function *FUN*:
>                call FUN ( W(5,1), ...)
> which would operate on row 5 of W.
> 
> The problem, I think, is that, within FUN, W is also defined as:
>                 double precision :: W(MDA, *)
> But, as in the calling function (DLSEI), the address is passed of the 5th element in W (the first column of row 5), and not of the first element, this means that the array W in FUN extends 5 elements beyond the memory that is actually allocated to it.
> My guess is that the address sanitizer finds that this matrix overlaps with some other matrix or vector, hence the error?
> 
> I am wondering whether this *is* an error in this code, as the memory extending beyond the original memory will not be altered (although I cannot be sure of this).
> 
> This is not something that is easily fixed, also given the large number of such constructs in this fortran code, and the complexity of the code.
> My question is then: how am I supposed to deal with this? If I abandon this package, then some dependencies will also need to be abandoned or alternatives will need to be found. So if I can avoid this I would definitely prefer this.
> I realise this is not a very simple problem, but I would be grateful for any suggestions that people might have,
> 
> Thanks,
> Karline
> 
> 
> [[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel