Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
On Tue, 2023-05-30 09:05:43 +0100, Maciej W. Rozycki wrote: [Ada as a cross-compiler fails to build with a slightly-older compiler.] > Alternatively you can just bootstrap GCC under test natively first and > then use the newly-built compiler for all the cross builds you want to > verify. As you need to do it only once per iteration the extra time spent > on the native build shouldn't be a big fraction of the duration of the > whole iteration. A drawback is if this native bootstrap fails for any > reason, it will make the whole run invalid, i.e. none of the cross targets > will be verified. Just implemented that: Extract the most recent GCC that got no `--target` given and try to use that. On a higher level, that GCC is built first, delaying the rest of the builds some hours. MfG, JBG -- signature.asc Description: PGP signature
Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
On Mon, 29 May 2023, Jan-Benedict Glaw wrote: > > Can you elaborate how you build GCC? > > My host compileris Debian's "gcc-snapshot", by now some two months > old. (As Eric wrote, it's probably just too old.) That compiler is > given for CC/CXX. The new build is just (as I wrote in the initial > mail) the configure/make call. So I'll just wait for the next drop for > Debian's "gcc-snapshot" package. I see that there are already a good > number of additional commits on the package source, I guess a new > package version is imminent. Alternatively you can just bootstrap GCC under test natively first and then use the newly-built compiler for all the cross builds you want to verify. As you need to do it only once per iteration the extra time spent on the native build shouldn't be a big fraction of the duration of the whole iteration. A drawback is if this native bootstrap fails for any reason, it will make the whole run invalid, i.e. none of the cross targets will be verified. Maciej
Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
On Mon, 2023-05-29 16:11:26 +0200, Marc Poulhiès wrote: > Jan-Benedict Glaw writes: > > (A full build log is at > > http://toolchain.lug-owl.de/laminar/jobs/gcc-aarch64-linux/74) > > > > Is this an issue with the patch? Or does it need a newer Ada compiler > > to for building it? > > Hello Jan, > > IIUC, your base compiler is "g++ (Debian 20230315-1) 13.0.1 20230315". > > It looks like you are doing a native build with bootstrap. If that's the > case it should work correctly. > > Can you elaborate how you build GCC? My host compileris Debian's "gcc-snapshot", by now some two months old. (As Eric wrote, it's probably just too old.) That compiler is given for CC/CXX. The new build is just (as I wrote in the initial mail) the configure/make call. So I'll just wait for the next drop for Debian's "gcc-snapshot" package. I see that there are already a good number of additional commits on the package source, I guess a new package version is imminent. MfG, JBG -- signature.asc Description: PGP signature
Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
Jan-Benedict Glaw writes: > (A full build log is at > http://toolchain.lug-owl.de/laminar/jobs/gcc-aarch64-linux/74) > > Is this an issue with the patch? Or does it need a newer Ada compiler > to for building it? Hello Jan, IIUC, your base compiler is "g++ (Debian 20230315-1) 13.0.1 20230315". It looks like you are doing a native build with bootstrap. If that's the case it should work correctly. Can you elaborate how you build GCC? Thanks, Marc
Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
> Is this an issue with the patch? Or does it need a newer Ada compiler > to for building it? Neither, it's very likely an issue with your build procedure: you need to use a matching host Ada compiler to build a cross Ada compiler, that's documented in https://gcc.gnu.org/install/prerequisites.html#GNAT-prerequisite "In order to build a cross compiler, it is strongly recommended to install the new compiler as native first, and then use it to build the cross compiler. Other native compiler versions may work but this is not guaranteed and will typically fail with hard to understand compilation errors during the build." -- Eric Botcazou
Re: [COMMITTED] ada: Remove the body of System.Storage_Elements
Hi Eric! On Tue, 2023-05-23 10:08:26 +0200, Marc Poulhiès via Gcc-patches wrote: > From: Eric Botcazou > > All the subprograms declared in the unit have convention Intrinsic and > their current implementation makes some implicit assumptions that are > not valid universally, so it is replaced by a direct expansion. > > This is mostly straightforward because Resolve_Intrinsic_Operator already > contains the required circuitry, but a few adjustements are necessary. Starting with this commit, my CI builder cannt build GCC: ../gcc/configure '--with-pkgversion=basepoints/gcc-14-1314-gff313e1c74b, built at 1685339868' --prefix=/var/lib/laminar/run/gcc-aarch64-linux/74/toolchain-install --enable-werror-always --enable-languages=all --disable-gcov --disable-shared --disable-threads --target=aarch64-linux --without-headers make V=1 all-gcc [...] mkdir -p ada/ /usr/lib/gcc-snapshot/bin/gcc -c -g -O2-gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/gcc/ada -Iada/libgnat -I../../gcc/gcc/ada/libgnat -Iada/gcc-interface -I../../gcc/gcc/ada/gcc-interface ../../gcc/gcc/ada/spark_xrefs.adb -o ada/spark_xrefs.o s-stoele.ads:84:13: error: unrecognized intrinsic subprogram make[1]: *** [../../gcc/gcc/ada/gcc-interface/Make-lang.in:165: ada/spark_xrefs.o] Error 1 make[1]: Leaving directory '/var/lib/laminar/run/gcc-aarch64-linux/74/toolchain-build/gcc' make: *** [Makefile:4637: all-gcc] Error 2 (A full build log is at http://toolchain.lug-owl.de/laminar/jobs/gcc-aarch64-linux/74) Is this an issue with the patch? Or does it need a newer Ada compiler to for building it? MfG, JBG -- signature.asc Description: PGP signature
[COMMITTED] ada: Remove the body of System.Storage_Elements
From: Eric Botcazou All the subprograms declared in the unit have convention Intrinsic and their current implementation makes some implicit assumptions that are not valid universally, so it is replaced by a direct expansion. This is mostly straightforward because Resolve_Intrinsic_Operator already contains the required circuitry, but a few adjustements are necessary. gcc/ada/ * exp_ch4.adb (Expand_N_Op_Mod): Deal with the special mod operator of System.Storage_Elements. * exp_intr.adb (Expand_To_Integer): New procedure. (Expand_Intrinsic_Call): Call Expand_To_Integer appropriately. (Expand_To_Address): Deal with an argument with modular type. * sem_ch3.adb (Derive_Subprogram): Also set convention Intrinsic on a derived intrinsic subprogram. * sem_res.adb (Resolve_Arithmetic_Op): Deal with intrinsic operators not coming from source exactly as those coming from source and also generate a reference in both cases. (Resolve_Op_Expon): Likewise. (Resolve_Intrinsic_Operator): Call Implementation_Base_Type to get a nonprivate base type. * snames.ads-tmpl (Name_To_Integer): New intrinsic name. * libgnat/s-stoele.ads: Replace pragma Convention with pragma Import throughout and remove pragma Inline_Always and Pure_Function. * libgnat/s-stoele.adb: Replace entire contents with pragma No_Body. * libgnat/s-atacco.adb: Adjust comment about pragma No_Body. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/exp_ch4.adb | 28 +- gcc/ada/exp_intr.adb | 27 ++ gcc/ada/libgnat/s-atacco.adb | 6 +-- gcc/ada/libgnat/s-stoele.adb | 101 ++- gcc/ada/libgnat/s-stoele.ads | 36 +++-- gcc/ada/sem_ch3.adb | 1 + gcc/ada/sem_res.adb | 10 ++-- gcc/ada/snames.ads-tmpl | 3 +- 8 files changed, 75 insertions(+), 137 deletions(-) diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb index 70e779d0406..c974a9e8d44 100644 --- a/gcc/ada/exp_ch4.adb +++ b/gcc/ada/exp_ch4.adb @@ -9560,6 +9560,12 @@ package body Exp_Ch4 is Typ : constant Entity_Id := Etype (N); DDC : constant Boolean:= Do_Division_Check (N); + Is_Stoele_Mod : constant Boolean := +Is_RTE (First_Subtype (Typ), RE_Storage_Offset) + and then Nkind (Left_Opnd (N)) = N_Unchecked_Type_Conversion + and then Is_RTE (Etype (Expression (Left_Opnd (N))), RE_Address); + -- True if this is the special mod operator of System.Storage_Elements + Left : Node_Id; Right : Node_Id; @@ -9593,7 +9599,10 @@ package body Exp_Ch4 is end if; end if; - if Is_Integer_Type (Typ) then + -- For the special mod operator of System.Storage_Elements, the checks + -- are subsumed into the handling of the negative case below. + + if Is_Integer_Type (Typ) and then not Is_Stoele_Mod then Apply_Divide_Checks (N); -- All done if we don't have a MOD any more, which can happen as a @@ -9663,6 +9672,23 @@ package body Exp_Ch4 is return; end if; + -- The negative case makes no sense since it is a case of a mod where + -- the left argument is unsigned and the right argument is signed. In + -- accordance with the (spirit of the) permission of RM 13.7.1(16), + -- we raise CE, and also include the zero case here. Yes, the RM says + -- PE, but this really is so obviously more like a constraint error. + + if Is_Stoele_Mod and then (not ROK or else Rlo <= 0) then +Insert_Action (N, + Make_Raise_Constraint_Error (Loc, +Condition => + Make_Op_Le (Loc, +Left_Opnd => Duplicate_Subexpr_No_Checks (Right), +Right_Opnd => Make_Integer_Literal (Loc, 0)), +Reason => CE_Overflow_Check_Failed)); +return; + end if; + -- If we still have a mod operator and we are in Modify_Tree_For_C -- mode, and we have a signed integer type, then here is where we do -- the rewrite in terms of Rem. Note this rewrite bypasses the need diff --git a/gcc/ada/exp_intr.adb b/gcc/ada/exp_intr.adb index a1e55882391..2eee892605e 100644 --- a/gcc/ada/exp_intr.adb +++ b/gcc/ada/exp_intr.adb @@ -102,6 +102,12 @@ package body Exp_Intr is -- N_Free_Statement and appropriate context. procedure Expand_To_Address (N : Node_Id); + -- Expand a call to corresponding function from System.Storage_Elements or + -- declared in an instance of System.Address_To_Access_Conversions. + + procedure Expand_To_Integer (N : Node_Id); + -- Expand a call to corresponding function from System.Storage_Elements + procedure Expand_To_Pointer (N : Node_Id); -- Expand a call to corresponding function,
