[Bug ada/85007] New: -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 Bug ID: 85007 Summary: -b flag to gnatlink not recognized Product: gcc Version: 7.3.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: --- Attempting to compile a 64-bit Ada package (using a GPR file) with a gcc configured with: LDFLAGS_FOR_TARGET='-Wl,-z,relro' ~/gcc-gcc-7.3.0/configure -v --with-pkgversion='LOCAL 7.3.0' --enable-languages=c,c++,ada --prefix=/usr/local/gcc-7.3 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/local/gcc-7.3/lib --without-included-gettext --enable-threads=posix --libdir=/usr/local/gcc-7.3/lib --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-default-pie --enable-plugin --enable-objc-gc=auto --with-arch-32=prescott --with-tune=nehalem --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --disable-nls --without-cuda-driver When you get to the linker stage, the arguments used are: gnatlink-7.3 -b x86_64-linux-gnu -v -g --for-linker=-Map --for-linker=../test.map lib1.a lib2.a --GCC=gcc-7.3 -o ../test driver.ali It is expected to produce a 64-bit output file, but instead you get the error: GNATLINK 7.3.0 Copyright (C) 1995-2017, Free Software Foundation, Inc. gcc-7 -c -gnatA -gnatWb -gnatiw -b x86_64-linux-gnu -g -gnatws b~driver.adb gcc-7.3: error: x86_64-linux-gnu: No such file or directory gcc-7.3: error: unrecognized command line option '-b' I understand by default with this configuration (e.g., without the "-b" flag), it will produce a 64-bit b~driver.o file, however in this case with the output format explicitly defined, the gnatlink program should be properly converting the system configuration string to the equivalent "-m64" flag which gcc-7.3 should be accepting. The more severe error is when the same compiler attempts to generate 32-bit objects for the same package, using any valid 32-bit linux linker configuration string and the '-b' gnatlink argument; all produce an error when attempting to compile the b~driver.o object, since gcc doesn't recognize this option as valid. On MULTIARCH targets, gnatlink.adb should probably parse any '-b' argument string, and translate it to an appropriate '-m32' or '-m64' argument for the binder compilation stage.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #3 from Eric Reischer --- No, it used gnatmake -P . Is there a new recommended way to get gnatlink to generate a 32-bit bind file and link object on MULTIARCH systems (x86/x86_64 in this specific case)? It seems this would be functionality that would be needed by others, as well as needing a way to cross-compile for target hardware.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #5 from Eric Reischer --- The multilib switch (-m32 -- which is undocumented as being valid for gnatmake incidentally) already is being passed to "gnatmake" -- it properly passes this flag to gcc when compiling the spec and body files, along with the "--RTS" flag properly set. The gnatbind command generated (and output) is: gnatbind-7.3 -E -ws -v --RTS=32 -x driver.ali gnatbind-7.3 -E -ws -v --RTS=32 -F=GNAT-TEMP-04.TMP -x driver.ali GNATBIND 7.3.0 Copyright (C) 1995-2017, Free Software Foundation, Inc. Binding: driver.ali No errors - It should be noted that at the top of the b~driver.ali file generated are the following lines: V "GNAT Lib v7" A -gnatA A -gnatWb A -gnatiw A -g A -gnatws A -mtune=nehalem A -march=x86-64 P ZX As noted in the OP, my --with-tune=nehalem explains that line, but the -march line shouldn't be appearing if --RTS=32 is being passed, correct? The gnatlink command generated (and output) is: gnatlink-7.3 driver.ali -g -v --GCC=gcc-7.3 -m32 -o driver GNATLINK 7.3.0 Copyright (C) 1994-2017, Free Software Foundation, Inc. gcc-7 -c -gnatA -gnatWb -gnatiw -g -gnatws b~driver.adb gcc-7.3 b~driver.o -m32 -o driver ld: i386:x86-64 architecture of input file `b~driver.o' is incompatible with i386 output ld: b~driver.o: file class ELFCLASS64 incompatible with ELFCLASS32 ld: final link failed: File in wrong format So, the "-m32" multiarch flag is not being passed to the first tool command executed by gnatlink (gcc-7) to compile b~driver.adb, even though "-m32" is passed as an argument to gnatmake.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #7 from Eric Reischer --- To make it easier to track down, can you post your configure line?
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007
--- Comment #8 from Eric Reischer ---
N/M -- I found the trigger.
I intend to use the 7.3 tree of "gcc-7.3" to do my compilation rather than the
system-search-provided "gcc". gnatmake-7.3 doesn't seem to want to use the
"gcc-7.3" provided in the same folder as it, so I had to manually provide
"--GCC=" on the gnatmake command line. This worked as expected. However, this
argument was not passed onto the gnatlink command, so I provided it in the GPR
file:
package Linker is
for Default_Switches ("Ada")
use ("-v","--for-linker=-Map","--for-linker="driver.map",
"--GCC=/path/to/gcc-7.3/bin/gcc-7.3");
end Linker;
When you add in the "--GCC" to the linker arguments in the GPR file, it calls
"gcc-7" (I'm unable to determine if it's actually calling my gcc-7.3, or if the
"." is causing it to trip up, and it's terminating the argument there), and
doesn't pass in the "-m32" flag.
If I leave out the "--GCC" argument from the GPR file, it compiles and links
successfully, and passes in the correct arguments to gcc to compile the binder
file (and curiously enough, the ALI file doesn't have the x86-64 line), but it
uses the default system gcc, not the one passed to gnatmake.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #10 from Eric Reischer --- The gcc configure line was taken directly from the Debian distribution package build script. Distros frequently allow having multiple versions of gcc installed, and give them the appropriate extension via the "--program-suffix" argument to the configure command. They will frequently provide symlinks to the root program names (gcc -> gcc-7.3) for convenience, but one would argue the tools shouldn't depend on that (the root gcc, g++, etc., don't suffer from that issue, calling their helper programs by prepending the libexecdir config setting prior to executing the tools.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #12 from Eric Reischer --- It's in there on my target system; I just missed it when I was transcribing over into the report. It looks from gnatlink.adb:540 (of 7.3.0), if the "--GCC=" flag is specified, it short-circuits all other args that normally would have been passed to the linker, including the optimization level, "-m32", "--RTS=32", and any other flags that were passed in the compiler section of the GPR file.
[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
[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] 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 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 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] 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/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/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 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 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.
