[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220 Jeff Hammond changed: What|Removed |Added CC||jeff.science at gmail dot com --- Comment #8 from Jeff Hammond --- For what it's worth, ISO/IEC DIS 1539-1:2022 (E) now contains the following: All standard procedures in the intrinsic module ISO_C_BINDING, other than C_F_POINTER and C_F_PROCPOINTER, are now pure.
[Bug fortran/107375] New: CFI_cdesc_t incorrectly reports non-interoperable C structure as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107375
Bug ID: 107375
Summary: CFI_cdesc_t incorrectly reports non-interoperable C
structure as such
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff.science at gmail dot com
Target Milestone: ---
Interoperable C structs are not permitted to contain allocatable members, among
other things.
The compiler should report that types containing allocatable members are
CFI_type_other, not CFI_type_struct.
I was not sure if the Fortran code was illegal or if the CFI_cdesc_t was
populated incorrectly, but another member of WG5 said it was the latter.
% gcc-12 -g -std=c11 -c foo.c -o foo.o
% gfortran-12 -g -std=f2018 class.F90 foo.o -o class.x
% ./class.x
CFI_cdesc_t.type = interoperable C structure
==> foo.c <==
#include
#include
#include "ISO_Fortran_binding.h"
char * get_type(CFI_type_t t)
{
switch(t) {
case CFI_type_cptr : return "void *";break;
case CFI_type_struct : return "interoperable C structure"; break;
case CFI_type_other : return "Not otherwise specified"; break;
default : abort();
}
}
void foo(CFI_cdesc_t * d)
{
printf("CFI_cdesc_t.type = %s\n", get_type(d->type));
}
==> class.F90 <==
module m
type :: t
integer :: i
double precision :: d
integer :: j(10)
real :: r(100)
real, allocatable :: z(:)
end type t
interface
subroutine foo(t) bind(C)
implicit none
type(*), dimension(..) :: t
end subroutine foo
end interface
end module m
program main
use m
implicit none
type(t) :: x
call foo(x)
end program main
% gfortran-12 -v
Using built-in specs.
COLLECT_GCC=gfortran-12
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin21/12/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-12
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 12.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin21
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Homebrew GCC 12.2.0)
[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #11 from Jeff Hammond --- > program foo >use f >integer i >call test(i) > end program > > which specific subroutine is called based on TKR? I understand there is an ambiguity here, but what if I never make this call? Is the module code incorrect? Anyways, there was a lot of discussion of this on a few channels and it seems to not be required to work, although it's ambiguous whether compilers need to catch it, and it seems that at least some compilers defer detection of the issue until the ambiguous overload is actually used.
[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #2 from Jeff Hammond --- Is this ever going to be fixed? I observe that a similar MCVE (below) is compiled without complaint by Intel, Cray and NAG Fortran, so it's almost certainly a lack of support for the standard in GCC. As best I can, it is impossible to overload an interface when one of the specific interfaces involves type(*), dimension(..), which makes it impossible for me to implement MPI-3 F08 support. My MCVE: module f implicit none interface test module procedure test_f08 module procedure test_f08ts end interface test contains subroutine test_f08(buf) integer :: buf end subroutine test_f08 subroutine test_f08ts(buffer) type(*), dimension(..), intent(inout) :: buffer end subroutine test_f08ts end module f
[Bug fortran/101602] New: local and local_init are not supported in DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602 Bug ID: 101602 Summary: local and local_init are not supported in DO CONCURRENT Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Fortran 2018 (https://j3-fortran.org/doc/year/18/18-007r1.pdf) has three locality specifiers: shared, local and local_init. GCC Fortran does not support any of these. This breaks user experience for Fortran programmers using DO CONCURRENT code that works with other compilers. OpenMP supports equivalent locality specifiers already so the internal capability for this surely exists in GCC. program bug implicit none integer :: i, j, k integer, dimension(100) :: x j = 20 k = 30 x = 7 do concurrent (i=1:10) shared(x) k = k + x(i) j = k end do do concurrent (i=1:10) local(j) k = k + x(i) j = k end do do concurrent (i=1:10) local_init(k) k = k + x(i) j = k end do print*,k end program bug % gfortran-11 bug.F bug.F:8:31: 8 | do concurrent (i=1:10) shared(x) | 1 Error: Syntax error in DO statement at (1) bug.F:11:11: 11 | end do | 1 Error: Expecting END PROGRAM statement at (1) bug.F:12:31: 12 | do concurrent (i=1:10) local(j) | 1 Error: Syntax error in DO statement at (1) bug.F:15:11: 15 | end do | 1 Error: Expecting END PROGRAM statement at (1) bug.F:16:31: 16 | do concurrent (i=1:10) local_init(k) | 1 Error: Syntax error in DO statement at (1) bug.F:19:11: 19 | end do | 1 Error: Expecting END PROGRAM statement at (1) % gfortran-11 --version GNU Fortran (Homebrew GCC 11.1.0_1) 11.1.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #7 from Jeff Hammond --- @Martin % gfortran -O3 -fprefetch-loop-arrays --verbose -c ctrsm.f && echo OKAY Using built-in specs. COLLECT_GCC=gfortran Target: aarch64-apple-darwin20 Configured with: ../configure --build=aarch64-apple-darwin20 --prefix=/opt/homebrew/Cellar/gcc/10.2.0_3 --libdir=/opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.1 20201220 (Homebrew GCC 10.2.0_3) COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c' '-mmacosx-version-min=11.2.0' '-asm_macosx_version_min=11.2' '-mlittle-endian' '-mabi=lp64' /opt/homebrew/Cellar/gcc/10.2.0_3/libexec/gcc/aarch64-apple-darwin20/10.2.1/f951 ctrsm.f -ffixed-form -fPIC -quiet -dumpbase ctrsm.f -mmacosx-version-min=11.2.0 -mlittle-endian -mabi=lp64 -auxbase ctrsm -O3 -version -fprefetch-loop-arrays -fintrinsic-modules-path /opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1/finclude -o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s GNU Fortran (Homebrew GCC 10.2.0_3) version 10.2.1 20201220 (aarch64-apple-darwin20) compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (Homebrew GCC 10.2.0_3) version 10.2.1 20201220 (aarch64-apple-darwin20) compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c' '-mmacosx-version-min=11.2.0' '-mlittle-endian' '-mabi=lp64' as -arch arm64 -v -mmacosx-version-min=11.2 -o ctrsm.o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s Apple clang version 12.0.0 (clang-1200.0.32.29) Target: aarch64-apple-darwin20.3.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple arm64-apple-macosx11.2.0 -filetype obj -main-file-name ccR79V1w.s -target-cpu vortex -target-feature +v8.3a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +fullfp16 -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +sha2 -target-feature +aes -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.29)" -dwarf-version=4 -mrelocation-model pic -o ctrsm.o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s:362:23: error: index must be a multiple of 8 in range [0, 32760]. prfmPLDL1KEEP, [x0, -8] ^
[Bug fortran/99092] New: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 Bug ID: 99092 Summary: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeff.science at gmail dot com Target Milestone: --- Created attachment 50179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50179=edit source code that triggers bug I am using GCC 10.2.1 installed via Homebrew on an Apple M1 system. I attempted to compile one of the functions from the BLAS and it fails as follows. The failure is triggered by the combined use of -O3 and -fprefetch-loop-arrays. Reducing to -O2 or removing the latter eliminates the issue, so there is a simple workaround. Nonetheless, I encountered it the first time I tried to build NWChem on this platform, so it will be seen by others until I can fix the NWChem build system to avoid it. I do not see this issue on x86, although I am not sure if I have tested GCC 10.2.1 specifically. % wget https://netlib.sandia.gov/blas/ctrsm.f # also attached % gfortran -O3 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccj3jW77.s:362:23: error: index must be a multiple of 8 in range [0, 32760]. prfmPLDL1KEEP, [x0, -8] ^ % gfortran -O2 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY OKAY % gfortran -O3 -c ctrsm.f && echo OKAY OKAY % gfortran --version GNU Fortran (Homebrew GCC 10.2.0_3) 10.2.1 20201220 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
