https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830
--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 27, 2019 at 02:55:56PM +0000, dominiq at lps dot ens.fr wrote:
>
> AFAIU this PR reports two issues with no or little connection with REPEAT.
>
Yes, and we have already agreed to close this one because (1)
was a pilot error and create a new PR for (2).
> (2) The reference to the source in run time errors:
>
> subroutine foo(s,n)
> implicit none
> character(len=1), intent(in) :: s
> integer, intent(in) :: n
> write(*,*) repeat(s,n)
> end subroutine
>
> call foo('a', -1)
> end
>
> which gives
>
> % gfc pr89830_2_db.f90
> % ./a.out
> At line 5 of file pr89830_2_db.f90
> Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its
> value is -1)
> % gfc ../bug/pr89830_2_db.f90
> % ./a.out
> At line 5 of file ../bug/pr89830_2_db.f90
> Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its
> value is -1)
> i.e., the path to the file given to the compiler. AFAICT this is
> generic to all run time error pointing to a source file (mostly I/O errors).
>
>>From comment 5, the reporter's expectation is not clear for me.
>> IMO this should be solved at the build script level rather that
>> with yet another option.
The issue is quite clear. Zaak wants to allow users to build OpenCoarrays
in whatever directory hierarchy the user can imagine, and end up with a
final OC library that is repeatable. He wants to strip the path from the
filename. This may be useful for invariant SHA256 or MD5 checksums if
one distributes a compiled project.
I think that stripping the path would be a lose of information for
someone that may need to debug a problem. If one has multiple files
with the same name, but of course in different directories, then
one needs to guess which file is the root of the problem.
