[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #2 from Eric Reischer ---
I can't point to a specific standard that says, "thou shalt generate output
with these types..."; it's more of a "we probably should be doing this"-type
thing. If you are compiling Fortran and C on the same system with the same
compiler suite, this is a non-issue. However, if you are, say, creating an API
that has autogenerated files redistributed (e.g., a base Fortran package and
then autogenerated and distributed C/C++ header files), the types generated
using -fc-prototypes are not safely transportable to another compiler with the
requested variable sizes.
This is probably better demonstrated with another example:
Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
E", you get the following output:
> gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
long a;
{...}
long_long e;
} bar;
---
In the above, "long_long" is nonstandard and not recognized by most compilers
(it was apparently implemented in some locations as a workaround to a problem
on Windows with gcc compatibility).
What's worse, is if you run the above in 64-bit mode on x86 Linux, you get:
> gfortran -m64 -fc-prototypes -fsyntax-only foo.f90
long a;
{...}
long e;
} bar;
---
This is most definitely wrong -- "long" will be 64 bits on Linux, but only 32
bits on Windows, so the size type emitted is ambiguous. Additionally, the
structures will no longer be interoperable, because (again, on Windows) in
C/C++ you'll get a variable "E" that will only store 32 bits, whereas in
Fortran the corresponding variable will be 64 bits, thus offsetting every
variable that comes after it. Probably better to be safe (and definitely more
portable) to leave translation of the types to when the C/C++ files are
actually compiled (which may not be with gcc) by using the stdint.h types.
I will stipulate that, yes, int64_t is not *guaranteed* to be exactly 64 bits,
and size_t is not *guaranteed* to be 32 or 64 bits (based on what architecture
you're running). But preserving the explicitly-specified data types across the
language translation is the point here. An entirely separate argument could be
had for INTEGER*4, INTEGER*8, etc., but in this case, since you're explicitly
requesting C_INTxx_T, you're getting something else entirely out of the
prototype-generation subsystem.
[Bug fortran/109322] New: -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
Bug ID: 109322
Summary: -fc-prototypes does not correctly translate
INTEGER(KIND=C_SIZE_T), and other sizes
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: emr-gnu at hev dot psu.edu
Target Milestone: ---
When generating C-prototypes, the gfortran compiler translates stdint.h
typedefs to their destination types at invocation time, rather than leaving
that to the C/C++ compiler in the translated code. Example: C_SIZE_T is
translated to "long" rather than "size_t" in the generated prototype
structures. This holds true for function parameters and return values as well.
foo.f90:
MODULE FOO
USE, INTRINSIC :: ISO_C_BINDING
IMPLICIT NONE
PUBLIC :: BAR
TYPE, BIND(C) :: BAR
INTEGER(KIND=C_SIZE_T) :: A = -1
INTEGER(KIND=C_INT32_T) :: B = -1
INTEGER(KIND=C_INT16_T) :: C = -1
INTEGER(KIND=C_INT8_T) :: D = -1
END TYPE
END MODULE
The above produces the following output:
> gfortran -fc-prototypes -fsyntax-only foo.f90
typedef struct bar {
long a;
int b;
short c;
signed char d;
} bar;
--
Expected output:
typedef struct bar {
size_t a;
int32_t b;
int16_t c;
int8_t d;
} bar;
[Bug ada/108909] Build process does not honor discovered path to "gnatmake" and "gnatlink"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909 --- Comment #1 from Eric Reischer --- One more: --- gcc-12.2.0/gcc/ada/gcc-interface/Makefile.in2022-08-19 04:09:52.352659553 -0400 +++ gcc-12.2.0-fixed/gcc/ada/gcc-interface/Makefile.in 2023-02-23 16:27:59.604161728 -0500 @@ -616,7 +616,7 @@ -$(MKDIR) ./bldtools/oscons $(RM) $(addprefix ./bldtools/oscons/,$(notdir $^)) $(CP) $^ ./bldtools/oscons - (cd ./bldtools/oscons ; gnatmake -q xoscons) + (cd ./bldtools/oscons ; $(GNATMAKE) -q xoscons) $(RTSDIR)/s-oscons.ads: ../stamp-gnatlib1-$(RTSDIR) s-oscons-tmplt.c gsocket.h ./bldtools/oscons/xoscons $(RM) $(RTSDIR)/s-oscons-tmplt.i $(RTSDIR)/s-oscons-tmplt.s
[Bug ada/108909] New: Build process does not honor discovered path to "gnatmake" and "gnatlink"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Bug ID: 108909
Summary: Build process does not honor discovered path to
"gnatmake" and "gnatlink"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: emr-gnu at hev dot psu.edu
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54521
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54521&action=edit
Patch to resolve gnatmake build issue
When attempting to build GCC 12.2 from released source:
$ GNATBIND=gnatbind-12.1 GNATMAKE=gnatmake-12.1 ../gcc-12.2.0/configure
--enable-languages=c,c++,ada,fortran --program-suffix=-12.2 {...blah blah...}
{...}
checking for x86_64-linux-gnu-gnatbind... gnatbind-12.1
checking for x86_64-linux-gnu-gnatmake... gnatmake-12.1
checking whether compiler driver understands Ada... yes
{...much later...}
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -q -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU
-I/build/gcc-12.2.0/gcc/ada gen_il-main
/bin/sh: gnatmake: command not found
make: *** [ada/stamp-gen_il] Error 127
This seems similar to PR 30541, in that if your system-level packages don't
have the GNAT tools installed, but you have specified an alternate compiler
path to Ada tools in the environment, the build scripts ignore the
configure-guessed (or environment-specified) options, and just blindly call
"gnatmake". Thus, the build fails.
The fix is to change lines 21, 42, and 49 of gcc/ada/Make-generated.in to use
"$(GNATMAKE)" instead of "gnatmake".
[Bug ada/98754] gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754 --- Comment #3 from Eric Reischer --- (Or some other more descriptive error indicating "gprbuild" was not found on the path, rather than acting as though you have borked the command-line options.)
[Bug ada/98754] gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754 --- Comment #2 from Eric Reischer --- In that case, this is not a RESOLVED WONTFIX -- this is still open. The documentation and output of "gnatmake --help" need to be updated to reflect the fact this is no longer a valid command line option.
[Bug ada/98754] New: gnatmake no longer recognizes -P option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98754
Bug ID: 98754
Summary: gnatmake no longer recognizes -P option
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: emr-gnu at hev dot psu.edu
Target Milestone: ---
Using 10.2.0, "gnatmake -Pfoo" does not appear to be a valid command line
anymore. Contents of foo.gpr:
project foo is
for Source_Dirs use (".");
for Object_Dir use "./build";
for Exec_Dir use ".";
for Main use ("hello");
package Compiler is
for Default_Switches ("Ada")
use ("-fstack-check",
"-ffloat-store",
"-msse2",
"-mfpmath=sse",
"-O0",
"-gnatws",
"-gnatE",
"-gnato");
end Compiler;
end foo
I would expect gnat to start building the program defined by "hello", but
instead I receive:
try "gnatmake-10.2 --help" for more information.
Configured with: -v --enable-languages=c,c++,ada,fortran
--prefix=/opt/gcc-10.2.0 --program-suffix=-10.2 --enable-shared
--enable-linker-build-id --with-system-zlib --libexecdir=/opt/gcc-10.2.0/lib
--without-included-gettext --enable-threads=posix --libdir=/opt/gcc-10.2.0/lib
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-default-pie --enable-plugin --with-arch-32=i686
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-nls --wihtout-cuda-driver --enable-libada
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 --- Comment #5 from Eric Reischer --- Sorry, that meant to say, "I can confirm the attached patch resolves the crash". Thanks :-)
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 --- Comment #3 from Eric Reischer --- Confirm the attached patch resolves the crash. I have not checked, however, if the generated code is correct.
[Bug fortran/98517] New: gfortran segfault on character array initialization from parameter value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 Bug ID: 98517 Summary: gfortran segfault on character array initialization from parameter value Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: emr-gnu at hev dot psu.edu Target Milestone: --- ~/fortran_bug$ cat source.for SUBROUTINE TEST_BUG IMPLICIT NONE CHARACTER*(*) DEF_VAL PARAMETER (DEF_VAL = 'ABCDEFGH') STRUCTURE /SOME_STRUCT/ CHARACTER*64SOME_VAR /DEF_VAL/ END STRUCTURE END ~/fortran_bug$ gfortran-10.2 -fdec-structure -c source.for f951: internal compiler error: Segmentation fault 0xbfa08f crash_signal toplev.c:328 0x6fc7e0 resolve_charlen resolve.c:12369 0x709019 resolve_charlen resolve.c:12347 0x709019 resolve_types resolve.c:17183 0x70472c gfc_resolve(gfc_namespace*) resolve.c:17300 0x6ec82c resolve_all_program_units parse.c:6245 0x6ec82c gfc_parse_file() parse.c:6492 0x7388ff gfc_be_parse_file f95-lang.c:210 Note: This may be related to #82721
