https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812
kargls at comcast dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargls at comcast dot net
--- Comment #2 from kargls at comcast dot net ---
(In reply to anlauf from comment #1)
> Works as expected on Linux.
>
> What happens if you replace C_NEW_LINE by something different,
> like c_carriage_return, or c_null_char, and pipe the output
> through "cat -v"?
Harald, there's a bug (at least it fails on FreeBSD). Here's
a testcase based on the original code. On FreeBSD, I see
% gfcx -o z a.f90 && ./z
STOP 2
In sub2, the line 'str(11:11) = c_new_line' places the new line
character in str(1:1).
! { dg-do run }
program main
use iso_c_binding
implicit none
character(len=*), parameter :: const = '0123456789'
call sub1 ! OK. No pointer initialization.
call suba ! OK. Allocatable attribute instead of pointer
call sub2 ! Not OK. Pointer initialized to null()/
contains
subroutine sub1
character(len=:), pointer :: str
allocate(character(len=11) :: str)
str = const // 'x'
str(11:11) = c_new_line
if (str(1:10) /= const) stop 1
end subroutine sub1
subroutine sub2
character(len=:), pointer :: str => null()
allocate(character(len=11) :: str)
str = const // 'x'
str(11:11) = c_new_line
if (str(1:10) /= const) stop 2
end subroutine sub2
subroutine suba
character(len=:), allocatable :: str
str = const // 'x'
str(11:11) = c_new_line
if (str(1:10) /= const) stop 3
end subroutine suba
end
