[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #23 from Nicolas Boulenguez ---
Always with gcc-13.2.0+Debian patches on arm-linux-gnueabihf,
if s-osprim__posix.adb imports and calls
int
__gnat_gettimeofday(struct timeval *restrict tv,
struct timezone *restrict tz)
{
return gettimeofday(tv, tz);
}
defined in cal.c instead of directly importing and calling the C gettimeofday
as it does for now, the returned date is correct.
This suggests that there is a distinct issue and provides a workaround for it.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57926|0 |1 is obsolete|| --- Comment #22 from Nicolas Boulenguez --- Created attachment 58028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58028=edit merge all definitions and conversions for timeval and timespec Hello. Moving the definitions into System.CRTL was a bad idea because they are needed before the target libgnat is built. The attached version 6 creates a new System.C_Time unit. It also adds a script testing the C_Time functions against handwritten results on 32 combinations of type sizes for Duration, time_t and suseconds_t. With the first four patches applied, gcc-13.2.0 (with Debian patches) builds on x86_64-linux-gnu and arm-linux-gnueabihf. The following program then gives the correct date on x86_64-linux-gnu but random dates or Time_Error on arm-linux-gnueabihf. So the original issue remains. -- with Ada.Calendar, Ada.Text_IO; procedure Demo is Y : Ada.Calendar.Year_Number; M : Ada.Calendar.Month_Number; D : Ada.Calendar.Day_Number; S : Duration; H, Min : Integer; begin Ada.Calendar.Split (Ada.Calendar.Clock, Y, M, D, S); H := Integer ((S / 3_600) - 0.5); S := S - 3600 * Duration (H); Min := Integer ((S / 60) - 0.5); S := S - 60 * Duration (Min); Ada.Text_IO.Put_Line (Y'Img & M'Img & D'Img & H'Img & Min'Img & S'Img); end Demo; -- The commits are rebased on the trunk, with only trivial changes but untested.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57890|0 |1 is obsolete|| Attachment #57897|0 |1 is obsolete|| --- Comment #19 from Nicolas Boulenguez --- Created attachment 57926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57926=edit eight commits isolating the definition of C time types This version 5 fixes typos in commit 3 that were breaking the build with 1-3 applied only on x86_64-linux-gnu. Commit 8 is adapted so that the overall effect of 1-8 is unchanged.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #18 from Nicolas Boulenguez --- Created attachment 57897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57897=edit rewrite commit 3/8 so that Duration'Size may be 32 Would version 4 of commit 3/8 be OK? It only modifies s-crtl.ad[bs]. A bit out of the subject, but if GNAT supports Duration'Size = 32, a-reatim.adb s-ransee.adb a-calend.adb probably deserve comments about the way the conversion deals with the size difference and sign bit.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #16 from Nicolas Boulenguez --- This 3rd attempt does the requested split. It fixes all build errors on Debian/amd64. The new Ada.Calendar.Clock returns sensible results. In other words, it seems ready for review.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57866|0 |1 is obsolete|| Attachment #57867|0 |1 is obsolete|| Attachment #57868|0 |1 is obsolete|| Attachment #57869|0 |1 is obsolete|| Attachment #57876|0 |1 is obsolete|| --- Comment #15 from Nicolas Boulenguez --- Created attachment 57890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57890=edit eight commits isolating the definition of C time types
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #14 from Nicolas Boulenguez --- The new version does not change much, but I am only posting it in order to prevent duplicated work. I will try to split the timespec changes and the timeval+Sockets changes, then attempt a build.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57865|0 |1 is obsolete|| --- Comment #13 from Nicolas Boulenguez --- Created attachment 57876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57876=edit Ada: define time_t timeval timespec C types in a single place
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #11 from Nicolas Boulenguez --- Created attachment 57869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57869=edit Ada: import nanosleep from System.OS_Primitives.Timed_Delay
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #10 from Nicolas Boulenguez --- Created attachment 57868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57868=edit Ada: drop unneeded darwin, solaris, x32 variants of System.OS_Primitives
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #9 from Nicolas Boulenguez --- Created attachment 57867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57867=edit Ada: drop unneeded posix2008 variant of System.Parameters
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #8 from Nicolas Boulenguez --- Created attachment 57866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57866=edit Ada: drop unneeded x32 variant of System.Linux
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #7 from Nicolas Boulenguez ---
Hello.
The attached suggestions (based on gcc-13/13.2.0) might solve the current
issue, or at least simplify the investigation, but they are so intrusive that I
would like a quick review by experts before testing anything. For now, I have
not even tried a build.
In principle, is there a chance that you accept such changes upstream, once/if
they are tested in Debian?
The main suggestion is of course 'Define time_t ... in a single place'. Then,
```
diff -u --color=auto libgnarl/s-linux{,__x32}.ads
diff -u --color=auto libgnat/s-parame{,__posix2008}.ads
diff -u --color=auto libgnat/s-osprim__{unix,solaris}.adb
diff -u --color=auto libgnat/s-osprim__{rtems,darwin}.adb
diff -u --color=auto libgnat/s-osprim__{rtems,x32}.adb
```
should validate the removal and the last suggestion should be trivial.
Thanks in advance.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added CC||nicolas at debian dot org --- Comment #6 from Nicolas Boulenguez --- Created attachment 57865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57865=edit Ada: define time_t timeval timespec C types in a single place
[Bug ada/113195] New: gnat bug box when comparing access to subtype with access inside record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113195 Bug ID: 113195 Summary: gnat bug box when comparing access to subtype with access inside record Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Hello. If the 'p.ads' file contains this: -- package P is subtype I is Integer; A : access I := null; type Rec is record Acc : access Integer; end record; R : Rec := (Acc => null); B : Boolean := A = R.Acc; end P; -- Then 'gnatmake p' triggers this bug box. x86_64-linux-gnu-gcc-13 -c p.ads +===GNAT BUG DETECTED==+ | 13.2.0 (x86_64-linux-gnu) GCC error: | | in build_binary_op, at ada/gcc-interface/utils2.cc:1142 | | Error detected at p.ads:10:23| | Compiling p.ads | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ I have found no shorter reproducer.
[Bug bootstrap/100932] autoconf error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100932 Nicolas Boulenguez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nicolas Boulenguez --- Quite ironically, given the only answer so far, somebody has investigated the same issue, duplicated the effort, and applied almost the same fix. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=25861cf3a88a07c8dca3fb32d098c0ad756bbe38
[Bug bootstrap/100932] autoconf error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100932 --- Comment #2 from Nicolas Boulenguez --- I fail to understand how your answer helps anyone. Currently, 'autoconf' fails and 'autoconf -I../config' succeeds. With the change, both would succeed and be equivalent. What is the benefit of requiring a command-line option when the only possible value can be provided as a default? I am using # autoreconf $(computed list of subdirectories) This would be way more difficult if I had to add a different -I option for each subdirectory.
[Bug ada/79724] GNAT tools do not respect --program-suffix and --program-prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724 --- Comment #10 from Nicolas Boulenguez --- Hello. I suggest that Homebrew adopt a solution tested for years by Debian: * install the executables as TARGET-gcc-VERSION * add symbolic links if necessary (gcc, gcc-VERSION, TARGET-gcc) * apply the patch provided here over 3 years ago https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 This URL always links to latest rebase: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/ada-gcc-name.diff Until the assumptions are made explicit, the upstream code trying to guess the name of the gcc executable will probably keep changing, as it has for at least ten years. I have counted at least 6 similar bugs, and that’s only on Debian. This leads to duplicate efforts. For example, the diagnostic of this specific index error is included in the patch above.
[Bug ada/67837] Ada ATC with delay abort syscalls not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67837 Nicolas Boulenguez changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Nicolas Boulenguez --- The original author agrees to close this issue.
[Bug ada/103014] New: gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014
Bug ID: 103014
Summary: gnat1 segfaults in tree_could_trap_p when C double
parameter, -O2 -gnatn -gnatVa
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: nicolas at debian dot org
Target Milestone: ---
Hello.
The following valid Ada sources crash 'gcc-11 -O2 -gnatn -gnatVa' as shown
below.
All goes well with gcc-10, with -O1, without inlining or without validity
checks.
The tests have been performed on Debian/x86_64-linux-gnu, with gcc-11/11.2.0-10
and gcc-10/10.3.12.
cat > p.ads < p.adb < {heap 2040k} {heap 2040k}
{heap 2040k} {heap 2040k} {heap 2936k}
{heap 2936k} {heap 2936k}Streaming LTO
{heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k} {heap 2936k} {heap 2936k} {heap
2936k} {heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k}Assembling functions:
{heap 2936k} P.P3
Program received signal SIGSEGV, Segmentation fault.
0x0119a4f6 in tree_could_trap_p(tree_node*) ()
[Bug other/100933] New: install cannot stat include-fixed/limits.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100933 Bug ID: 100933 Summary: install cannot stat include-fixed/limits.h Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Hello. I have been bitten by the exact bug described at: https://gcc.gnu.org/legacy-ml/gcc/2013-04/msg00171.html The work-around described there worked for me : run 'make && make install' directly instead of via wrappers (dh_auto_build and dh_auto_install) that parse 'make -n' before normal operation. The issue seems difficult, but please at least provide a hint in the error message at install time. Without this post, I would probably never have found a work-around. Thanks.
[Bug other/100932] New: autoconf error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100932 Bug ID: 100932 Summary: autoconf error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Hello. When I attempt to autoreconf(2.69) the gcc/ subdirectory of 10.2.1 or 11.1.0, I get: configure.ac:886: error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT configure.ac:1499: error: possibly undefined macro: GCC_AC_FUNC_MMAP_BLACKLIST There is a slight possibility that the error is caused by local patches (Debian experimental), but this trivial change fixes the issue: --- a/src/gcc/configure.ac +++ b/src/gcc/configure.ac @@ -25,6 +25,7 @@ AC_INIT AC_CONFIG_SRCDIR(tree.c) +AC_CONFIG_MACRO_DIRS(../config) AC_CONFIG_HEADER(auto-host.h:config.in) gcc_version=`cat $srcdir/BASE-VER` The documentation seems to recommend AC_CONFIG_MACRO_DIRS anyway.
[Bug bootstrap/29482] libcpp/configure - no usable dependency style found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482 Nicolas Boulenguez changed: What|Removed |Added CC||nicolas at debian dot org --- Comment #9 from Nicolas Boulenguez --- Hello. I had the failure with GCC-10.2.1, only when running `autoreconf -f -i . fixincludes gcc subdirs...` before `./configure`. For each subdir in turn, autoreconf checks if the subdirectory uses libtool or automake. If so, it installs depcomp in . (../ from the subdir), else removes ./depcomp (breaking the build of other subdirectories). Changing the order of autoreconf arguments so that the last one depends on automake fixed the problem for me. I am not sure if this is a bug, or where to report it, but documenting the work-around here may be useful to other GCC users.
[Bug ada/95664] New: generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95664 Bug ID: 95664 Summary: generic instantiation fails to detect abstract equality, builds with gcc-9 and fails to link with gcc-10 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Hello. A minimal reproducer follows. With gcc-9.3.0 (Debian build 13), all goes well, but gcc-10.1.0 (Debian build 3) fails to link: # /usr/bin/ld: ./pkg.o: in function `pkg__instantiation': # pkg.ads:(.text+0x9): undefined reference to `pkg__Oeq' If the source is valid Ada code (I am not quite sure), then gcc-9 is right and gcc-10 introduces a regression, else both versions should report an error instead of their current behaviour. cat > gen_proc.ads < main.adb <
[Bug ada/87972] remove -f*-prefix-map= options from Ada Library Information files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87972 Nicolas Boulenguez changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Nicolas Boulenguez --- This patch does not fix the initial problem. Imagine a compilation driven by gnatmake with gnatmake main.adb -cargs -fdebug-prefix-map=OLD=NEW During the compilation phase: gcc -c -fdebug-prefix-map=OLD=NEW main.adb * does not write the path to .o (because of the option) * does not write the path to .ali (because of the patch) This is good. However, during the link phase, the source generated by the linker (b~main.adb) is compiled by gnatlink. The flags are taken from main.ali, they do not contain -fdebug-prefix-map anymore. So the path appears in b~main.o then the executable, which is exactly what we want to avoid. The problem is more general, see https://gcc.gnu.org/pipermail/gcc-patches/2016-November/46.html Sorry for the noise.
[Bug ada/89742] New: Ada2020 target assignment in generic renders a type invisible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89742 Bug ID: 89742 Summary: Ada2020 target assignment in generic renders a type invisible Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Hello. This issue affects the @ target assignement in Ada, which is not yet officially released, but supported with the appropriate options. This program is legal, but if the indicated Ref is replaced with @, GCC reports an error. cat > main.adb < Ref.all.I); -- ^ this Ref. end Generic_P; procedure P is new Generic_P; begin null; end Main; EOF echo 'Produces sensible warnings.' gnatgcc -c -gnat2020 main.adb sed -i 's/=> Ref/=> @/' main.adb echo 'Now says "Rec" is undefined.' gnatgcc -c -gnat2020 main.adb
[Bug ada/89609] New: bug box caused by access to function as a record component via a limited with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89609 Bug ID: 89609 Summary: bug box caused by access to function as a record component via a limited with Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- These sources should be legal. Execution would dereference a null pointer, but this is easy to fix without changing the bug box below. limited with Rs; package As is type A is access function return Rs.R; end As; with As; package Rs is type R is record F : As.A; end record; X : R; Y : R := X.F.all; end Rs; gnatmake -c rs.ads produces: +===GNAT BUG DETECTED==+ | 8.2.0 (x86_64-linux-gnu) GCC error: | | in save_gnu_tree, at ada/gcc-interface/utils.c:337 | | Error detected at rs.ads:3:4 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ This has similarities with Bug 89159, but no tagged type is implied.
[Bug ada/89178] New: equality for composed types failt when a component has a discriminant and redefines equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89178
Bug ID: 89178
Summary: equality for composed types failt when a component has
a discriminant and redefines equality
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: nicolas at debian dot org
Target Milestone: ---
'gnatmake p && ./p' outputs twice 'Should be TRUE: FALSE'.
with Ada.Text_IO;
procedure P is
type T (D : Integer := 0) is record
case D is
when others =>
null;
end case;
end record;
overriding function "=" (A, B : in T) return Boolean is (True);
T1 : constant T := (D => 1);
T2 : constant T := (D => 2);
type R is record
F : T;
end record;
R1 : constant R := (F => T1);
R2 : constant R := (F => T2);
type A is array (Positive range 1 .. 1) of T;
A1 : constant A := (1 => T1);
A2 : constant A := (1 => T2);
begin
Ada.Text_IO.Put_Line ("Should be TRUE: " & Boolean'Image (R1 = R2));
Ada.Text_IO.Put_Line ("Should be TRUE: " & Boolean'Image (A1 = A2));
end P;
[Bug ada/89159] New: limited with, tagged record and access to function confuse the linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89159 Bug ID: 89159 Summary: limited with, tagged record and access to function confuse the linker Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- The following sources demonstrate the issue with GCC 8.2.0. # gnatmake main x86_64-linux-gnu-gnatlink-8 main.ali /usr/bin/ld: ./ms.o:(.data.rel.ro.local+0x80): undefined reference to `ms__g' -- with Ms; package Ts is type T; type T is new Integer; end Ts; -- limited with Ts; package Ms is type M is tagged null record; procedure G (Container : in M; F : access function return Ts.T); end Ms; -- with Ts; package body Ms is procedure G (Container : in M; F : access function return Ts.T) is Item : Ts.T := F.all; begin null; end G; end Ms; -- with Ts; procedure Main is begin null; end Main;
[Bug ada/87972] New: remove -f*-prefix-map= options from Ada Library Information files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87972 Bug ID: 87972 Summary: remove -f*-prefix-map= options from Ada Library Information files Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- Created attachment 44984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44984=edit skip -f*-prefix-map options when writing .ali files The -f(file|debug|macro)-prefix-map=OLD=NEW options added by revision 256847 explicitly ask that OLD is never written.
[Bug ada/87777] Let gnat tools call each other with an explicit target and version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Nicolas Boulenguez changed: What|Removed |Added Attachment #44913|0 |1 is obsolete|| --- Comment #5 from Nicolas Boulenguez --- Created attachment 44954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44954=edit rewrite osint.program_name
