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=&#
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 functi
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
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?
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 th
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 t
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 ar
: 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
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.
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 :-)
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 Obj
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.
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.)
D
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/bug
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 +6
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
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
17 matches
Mail list logo
