Redirected from PR48835: Attempting to build an Ada-enabled gcc-4.7 cross to m68k-linux fails with: /tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/bin/ -B/home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/lib/ -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/include -isystem /home/mikpe/pkgs/linux-x86/cross-m68k/m68k-unknown-linux/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc a-assert.adb -o a-assert.o +===========================GNAT BUG DETECTED==============================+ | 4.7.0 20111203 (experimental) (m68k-unknown-linux) GCC error: | | in fp_size_to_prec, at ada/gcc-interface/misc.c:781 | (you don't need the m68k-linux Ada support patch for this, vanilla upstream gcc sources suffice) This worked up to r177136, but broke due to r177137+177141. Eric Botcazou commented: > No, but the new code (cstand.adb:Register_Float_Type) makes an invalid > assumption about the size of a FP mode given its precision and alignment, > instead of using the proper interface. enumerate_modes should probably pass > GET_MODE_BITSIZE to its callback. I'd suggest opening a new regression PR for > this problem.
This doesn't show up on i386 because XFmode is overaligned for this arch.
Created attachment 26285 [details] Patch
> Created attachment 26285 [details] > Patch I don't think it's correct. Like the middle-end, the Ada front-end has a notion of precision (RM_Size) and a notion of size (Esize), so we need to pass both to the front-end. But I'll let Geert comment here.
The front-end has never made that distinction for floating point types.
If I understand correctly, you're changing the interface to pass the object size (Esize) instead of the precision (RM_Size). That is not correct. Right now, we have the assumption that we can derive the Esize from the RM_Size rounded up to the alignment. What I don't quite understand right now is what the properties of the M68K type are. What is the precision, size and alignment? If necessary, we can pass both Esize and RM_Size, but the current change seems like it would break other targets. -Geert
> If I understand correctly, you're changing the interface to pass the object > size (Esize) instead of the precision (RM_Size). That is not correct. I'm just restoring previous behaviour. > Right now, we have the assumption that we can derive the Esize from the RM_Size > rounded up to the alignment. That completely ignores padding. > If necessary, we can pass both Esize and RM_Size, but the current change seems > like it would break other targets. Those targets would have been broken before. Since nobody appeared to complain so far, those targets don't exit.
Any chance this could be resolved before the 4.7.0 release? It would be a shame if Ada support for m68k would be impossible due to something as lame as FP format confusion/disagreement.
Created attachment 26524 [details] pass both precision and storage size to Register_Float_Type Patch I'm testing. Works on i686-linux. Unfortunately all post-20110730 snapshots seem to suffer from additional build failures (for m68k at least) so I haven't been able to build a cross yet. The first one I need to figure out is: /tmp/gcc-4.7-20110820/gcc/ada -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- /tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb scng.adb:1799:47: "SPARK" is undefined gnatmake: "/tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb" compilation error
(In reply to comment #8) > /tmp/gcc-4.7-20110820/gcc/ada -g -O2 -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -gnatpg -gnata -I- > /tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb > scng.adb:1799:47: "SPARK" is undefined > gnatmake: "/tmp/gcc-4.7-20110820/gcc/ada/ali-util.adb" compilation error This is a generic problem affecting all cross-builds, caused by r177183. For instance, a gcc-4.6.2 host gcc fails to build gcc-4.7-20120128 as a cross to sparc64-linux with the above error, even though native builds on sparc64-linux have no problems building the same gcc-4.7-20120128 with an even older gcc-4.4.6 host compiler. However, in the brief period between r177141 and r177183, applying my tentative patch did allow a successful build of a gcc-4.7 cross to m68k w/ ada, so I'll try a native bootstrap with it soonish.
(In reply to comment #9) > applying my tentative > patch did allow a successful build of a gcc-4.7 cross to m68k w/ ada, so I'll > try a native bootstrap with it soonish. Native bootstrap of 4.7-20120225 plus my proposed fix for this PR, the base m68k-linux Ada support patch from PR48835, and the proposed fix for the cc0 bug in PR49847, with Ada enabled, did succeed.
GCC 4.7.0 is being released, adjusting target milestone.
GCC 4.7.1 is being released, adjusting target milestone.
GCC 4.7.2 has been released.
Can't build Ada/gnat-4.7 on Ubuntu 12.10 because of SPARK issue, although there are long and complicated directions for how to build Ada/gnat-4.7 on Ubuntu, some work and some don't. Per GNU standards, the build system should be changed so that it's possible to build gnat-4.7 with gnat-4.6. Also, if a native compiler of the same version number must be built to build gnat, then the build system should (but fails to) automatically build the native version first, then use that to build the cross compiler.
> Can't build Ada/gnat-4.7 on Ubuntu 12.10 because of SPARK issue, although there > are long and complicated directions for how to build Ada/gnat-4.7 on Ubuntu, > some work and some don't. Per GNU standards, the build system should be > changed so that it's possible to build gnat-4.7 with gnat-4.6. Also, if a > native compiler of the same version number must be built to build gnat, then > the build system should (but fails to) automatically build the native version > first, then use that to build the cross compiler. This PR has nothing to do with the build system though.
GCC 4.7.3 is being released, adjusting target milestone.
Eric, there's an updated patch in c#8 which reportedly fixes the problem by passing both the precision and storage size of Register_Float_Type. I'm nowhere near versed enough in Ada to know if Mikael's on the right track with that patch. It's been sitting there for ~2 years now ;( The SPARK issues in c#14 is separate and we should probably create a distinct BZ for that since I believe it completely stands in the way bootstrapping Ada on platforms without a functional Ada compiler. If you could help move along these issues, it'd be appreciated. Thanks, Jeff
> Eric, there's an updated patch in c#8 which reportedly fixes the problem by > passing both the precision and storage size of Register_Float_Type. Right, this is the way to go. > I'm nowhere near versed enough in Ada to know if Mikael's on the right track > with that patch. It's been sitting there for ~2 years now ;( > > The SPARK issues in c#14 is separate and we should probably create a > distinct BZ for that since I believe it completely stands in the way > bootstrapping Ada on platforms without a functional Ada compiler. > > If you could help move along these issues, it'd be appreciated. Geert, could you have a look at the patch?
Taking care of it.
On Mar 10, 2014, at 16:11, ebotcazou at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote: > --- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > Taking care of it. > Thank you! -Geert
Author: ebotcazou Date: Thu Mar 13 15:42:21 2014 New Revision: 208546 URL: http://gcc.gnu.org/viewcvs?rev=208546&root=gcc&view=rev Log: PR ada/51483 * cstand.adb (Register_Float_Type): Add 'precision' parameter and use it to set the RM size. Use directly 'size' for the Esize. (Create_Back_End_Float_Types): Adjust call to above. * get_targ.ads (Register_Type_Proc): Add 'precision' parameter. * set_targ.ads (FPT_Mode_Entry): Add 'precision' component. (Write_Target_Dependent_Values): Adjust comment. * set_targ.adb (Register_Float_Type): Add 'precision' parameter and deal with it. (Write_Target_Dependent_Values): Write the precision in lieu of size. (Initialization): Read the precision in lieu of size and compute the size from the precision and the alignment. * gcc-interface/gigi.h (enumerate_modes): Add integer parameter. * gcc-interface/misc.c (enumerate_modes): Likewise. Do not register types for vector modes, pass the size in addition to the precision. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/cstand.adb trunk/gcc/ada/gcc-interface/gigi.h trunk/gcc/ada/gcc-interface/misc.c trunk/gcc/ada/get_targ.ads trunk/gcc/ada/set_targ.adb trunk/gcc/ada/set_targ.ads
Author: ebotcazou Date: Thu Mar 13 15:42:42 2014 New Revision: 208547 URL: http://gcc.gnu.org/viewcvs?rev=208547&root=gcc&view=rev Log: PR ada/51483 * back_end.ads (Register_Type_Proc): Add 'precision' parameter. * cstand.adb (Register_Float_Type): Add 'precision' parameter and use it to set the RM size. Use directly 'size' for the Esize. * gcc-interface/gigi.h (enumerate_modes): Add integer parameter. * gcc-interface/misc.c (enumerate_modes): Likewise. Do not register types for vector modes, pass the size in addition to the precision. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/back_end.ads branches/gcc-4_8-branch/gcc/ada/cstand.adb branches/gcc-4_8-branch/gcc/ada/gcc-interface/gigi.h branches/gcc-4_8-branch/gcc/ada/gcc-interface/misc.c
Author: ebotcazou Date: Thu Mar 13 15:43:01 2014 New Revision: 208548 URL: http://gcc.gnu.org/viewcvs?rev=208548&root=gcc&view=rev Log: PR ada/51483 * back_end.ads (Register_Type_Proc): Add 'precision' parameter. * cstand.adb (Register_Float_Type): Add 'precision' parameter and use it to set the RM size. Use directly 'size' for the Esize. * gcc-interface/gigi.h (enumerate_modes): Add integer parameter. * gcc-interface/misc.c (enumerate_modes): Likewise. Do not register types for vector modes, pass the size in addition to the precision. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/back_end.ads branches/gcc-4_7-branch/gcc/ada/cstand.adb branches/gcc-4_7-branch/gcc/ada/gcc-interface/gigi.h branches/gcc-4_7-branch/gcc/ada/gcc-interface/misc.c
Patch applied everywhere.
Thanks!