Created attachment 206484 [details] patches to lang/gcc9 This patch (as of yet untested) brings the changes from PR 239266 and http://mikael.urankar.free.fr/FreeBSD/powerpc64/lang_gcc8_elfv2.diff to lang/gcc9.
I've bit my tongue a couple of times in the last hour and will therefore not as blunt as I would have been back then. Still... 1. I really, really, really would appreciate a bit, just a bit, of collaboration with upstream here. The last time I properly reported a powerpc64 specific issue on FreeBSD with upstream GCC it got fixed and backported to all relevant release branches within 24 hours. 2. FreeBSD has an upstream maintainer in GCC, so there should be zero reason patching files named *freebsd* locally. 3. I do appreciate getting bug reports that include fixes, but what I have seen on the powerpc* front as of lately looked a bit random. With the proposed patchset here, for example (a) two of the patches are tackling the very same issue, (b) patch-gcc_config_rs6000_freebsd64.h does something completely different than its description, and (c) disabling BOOTSTRAP is incorrect pretty much by definition. 4. Instead of opening new issues, it would be nice to get feedback on existing ones, e.g. PR 239266 (which relates to item (a) above).
I'll keep this as a local patchset on ppcdevref for now. I generated this patchset so that I could make progress on the "powerpc64 now defaults to clang" task -- so that we can minimize the regressions that users will experience during the imminent Flag Day. That task is taking all of my time right now. Given the many hundreds of changes I have been generating and/or testing, I do not have the cycles to work with every upstream -- the task would never complete, as new ports are added, and, in particular, upgrades to both llvm and gcc happen underneath me. So, I have not taken the time to investigate the Perfect Way to handle this issue. I merely modified an existing patchset that allowed me to proceed on testing gcc8-dependent ports, over to gcc9, so that I could proceed on testing the thousands of gcc9-based ports.
(In reply to Mark Linimon from comment #2) > That task is taking all of my time right now. Given the many hundreds > of changes I have been generating and/or testing, I do not have the > cycles to work with every upstream Yes, but there are also others interested in powerpc and working with upstream on the toolchain side just is the right thing. And I helped, but have not been getting feedback from anyone (until I pushed again) when proposing a patch to work around one of the clang issues. Anyway, lang/gcc8 and lang/gcc9 now carry my patch which Mark Millard kindly verified -- lang/gcc9/files/patch-clang-vec_step. That should obsolete most of the patchset in this PR (most of which was not necessary anyway). In particular gcc/tree-vect-loop.c should not see *any* further changes. Disabling the BOOTSTRAP option still looks very wrong, and does not seem to be required by other powerpc users.
I am currently going through the process of rebuilding gcc8 and gcc9, with the patches I had been given and also the latest committed patches, on both of the systems that I have been given access to (both gcc-based and clang-based), and *very carefully* writing down which result I got from which. Each run takes the better part of a day. When that is *complete* I will provide it. I was not the person that filed the initial report on gcc8, so you will have to take it up with that person. I thought by porting over that patch that I *might* help other users with gcc9. Clearly this was not the case and I apologize. I do have proof that gcc9 does not build on powerpc64 with clang in base but until I can annotate *specifically* the error messages and the patches involved I am going to wait to post it.
*** Bug 240076 has been marked as a duplicate of this bug. ***
With today's patches committed, we only need for gcc8: Index: Makefile =================================================================== --- Makefile (revision 509727) +++ Makefile (working copy) @@ -62,7 +62,11 @@ .elif ${ARCH} == powerpc64 CONFIGURE_ENV+= UNAME_m="powerpc64" +.if ${CHOSEN_COMPILER_TYPE} == gcc MAKE_ARGS+= CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" BOOT_CFLAGS="-O1" # PR235975 +.else +CONFIGURE_ARGS+= --with-abi=elfv2 +.endif .elif ${ARCH} == powerpcspe CONFIGURE_ARGS+= --with-cpu=8548 --enable-e500_double --without-fp And for gcc9: Index: Makefile =================================================================== --- Makefile (revision 509727) +++ Makefile (working copy) @@ -61,7 +61,11 @@ .elif ${ARCH} == powerpc64 CONFIGURE_ENV+= UNAME_m="powerpc64" +. if ${CHOSEN_COMPILER_TYPE} == gcc USE_GCC= 8 +. else +CONFIGURE_ARGS+= --with-abi=elfv2 +. endif .endif LANGUAGES:= c,c++,objc,fortran
Created attachment 206970 [details] replacement for earlier patch to gcc9/Makefile This is the next patch I will test on the elfv2 machine. This is pkubaj's patch but reformatted it for Bugzilla.
(In reply to Mark Linimon from comment #7) A build with these patches failed due to a stale tree: pkg-static: cannot load keyword from /usr/ports/Keywords/ldconfig.ucl: No such file or directory so I will need to SVN update and rebuild.
Mark, I do believe (more than just hope) that basic building of gcc9 and gcc8 should be fine now after the patches I applied to the ports (though I'll keep pushing for either clang to be fixed or GCC to work around this upstream as well). There is another issues which Piotr has been raising, and which his proposed patches in the PR now are about, and that is an update of the ABI to ELFv2 which is orthogonal to this question. Shall we continue to track the ABI update in this issue and the "clang breaks GCC on powerpc" issue on PR239266? (Both this issues equally affect lang/gcc8 and lang/gcc9, and any fixes/adjustments should be the same for two, so splitting by underlying issue instead of version of GCC makes things easier.) Of course if you still see regular build failures, please advise and we will jointly see how to address them with priority!
(In reply to Piotr Kubaj from comment #6) Is this intended? If you build gcc with clang you produce a gcc which produces different binaries than one built with gcc? I think the whole clang switch is not really planned, is it?
(In reply to Andreas Tobler from comment #10) If you build it with GCC, it means you run ELFv1, because GCC is used in base on ELFv1 systems. If you build with Clang, it's an ELFv2 system. So yes, both GCC's will generate different binaries. When running on ELFv1 system, it's reasonable to generate ELFv1 binaries. "I think the whole clang switch is not really planned, is it?" Since powerpc is a tier-2 platform, the developers have to do required work on their own. Of course, you are free to help, if you wish to.
(In reply to Gerald Pfeifer from comment #9) > I do believe (more than just hope) that basic building of gcc9 > and gcc8 should be fine now after the patches I applied to the ports. I have now confirmed this. > Shall we continue to track the ABI update in this issue and the "clang > breaks GCC on powerpc" issue on PR239266? I have no opinion at this point. I'll let the other folks involved decide.
(In reply to Piotr Kubaj from comment #11) What happens if you build gcc with gcc on an elfv2 system? Back to elfv1! That was the question about planning. You can do the switch from elfv1 to elfv2 on -CURRENT at a dedicated time and not before. And you have to do it on all components which affects the abi at once. Otherwise you'll might have an abi mess.
Specifically here, the existance of base clang can be used as an indication that an ELFv2 system is in use, because: a) base ld.bfd only supports ELFv1, and is missing relocations needed to link anything built by clang, ELFv1 or ELFv2. b) base ld.lld only supports ELFv2. The original ELFv1 support has long been removed from the lld code upstream. While it would theoretically be possible to have an ELFv1 system with base clang installed, you would only be able to do that by disabling LLD and using the base/binutils port to replace the system linker, and rebuilding world, as binutils from ports is the only modern linker supporting ELFv1. Once the flag day happens, we'll have an actual __FreeBSD_version value to target so that upstream can properly support the ABI switch.
The flag day patches and progress tracking are all be listed on https://wiki.freebsd.org/powerpc/llvm-elfv2 by the way. Good point re: building gcc with gcc. I don't think there's a good way to cover that case until after flag day. At which point we'll have a version number to report upstream as the cutover point and get this fixed properly.
Thanks for the background, Brandon! I was guessing something similar, yet it's good to see more background. Let me make sure I understand correctly, and propose some next steps: * The proposed patch to gcc8/Makefile and gcc9/Makefile uses the choice of system compiler as an indicator for a flag day. GCC implies ABIv1, clang implies ABIv2. * For the time being that is the most reliable (only reasonable?) indicator available, but we can later replace it once there is a __FreeBSD_version assigned. * If the above is correct, would you mind proposing a comment for those Makefile patches that describes that? Like Andreas I was surprised to see compiler and ABI mixed, and so will others probably be. Then, I guess, the question is whether these patches should be applied now, even though they would not make a difference, or wait for flag day? If the former, I can approve or take care (when, ideally, you have shared the proposed comment). (And based on the answer we probably can/should take this PR off Marks' shoulders then.)
To be clear, I have only tested: - GG-based system with only the patches in the tree (both gcc8 and gcc9 work). - clang-based system with the patches in #c6 (both gcc8 and gcc9 work). I have not tried the #c6 patches on a GCC-based system. I can do that if needed. I do *not* believe the clang-based system will build gcc8 or gcc9 without the patch in c6. I can repeat that test if necessary, but I just gave the machine a day's worth of work to do (testing lang/ruby26 as default).
(In reply to Mark Linimon from comment #17) > I have not tried the #c6 patches on a GCC-based system. I can do that if needed. Actually my home machine was idle so I gave it this task.
(In reply to Mark Linimon from comment #17) > I have not tried the #c6 patches on a GCC-based system. I can do that if needed. These ports now build on a GCC-based system: FreeBSD blackbird1.lonesome.com 13.0-CURRENT FreeBSD 13.0-CURRENT r349478 GENERIC powerpc
(In reply to Brandon Bergren from comment #14) QUOTE While it would theoretically be possible to have an ELFv1 system with base clang installed, you would only be able to do that by disabling LLD and using the base/binutils port to replace the system linker, and rebuilding world, as binutils from ports is the only modern linker supporting ELFv1. END QUOTE It is more than theoretical: I've been doing buildworld buildkernel targetting ELFv1 as an experimental environment for years, reporting oddities that I ran into. I generally used devel/powerpc64-binutils for both cross-builds and self-hosted-builds (more uniformity). These days I also sometimes use base/binutils alternative and install its builutils on the old PowerMacs that I sometimes have access to. I've also built for ELFv1 via devel/powerpc-gcc ( and devel/powerpc-xtoolchain-gcc ), both as cross-builds and as self-hosted-builds. I have also tested using base/gcc to establish system compilers on the old PowerMacs. (This is rare, however.) Most of the time I did not build/include the old gcc 4.2.1 at all. (I have patches involved to deal with PowerMac specific issues and a few FreeBSD issues as well. I genrally avoided various issues via WITHOUT_LIB32= as well.) I use ports-mgmt/poudriere-devel to build ports on old PowerMacs, at least in more recent years. Currently a PowerMac11,2 (2 sockets/2 cores each) is running a clang-built system with system-clang/clang++ as the compilers and base/binutils materials. The ports present are from ports-mgmt/poudriere-devel building them, ignoring base/binutils materials. I'm not claiming that there is any good reason to to try to support my odd environment types for the transition, even if I end up frustrated with the process of transitioning or end up starting from scratch. I might be the only one around with such odd powerpc64 environments. But it would be nice to have a very clear notice when the first changes are checked-in that would not fit with such environment types, both system check-ins and port check-ins (if there is a time frame distinction for some reason). I'd prefer -r?????? for the system and for the ports to be explicit in the notice.
Can you commit the patch so that we get both gcc8 and gcc9 working?
Do we have an actual _FreeBSD_version to key of? If not, and the check for gcc/clang is the only one we can use, mind proposing a comment as I had suggested in comment #16? Or wouldn't it be better to commit this as part of a flag day? Happy to pre-approve in that case. Gerald
(In reply to Gerald Pfeifer from comment #22) You could instead use: .if defined(PPC_ABI) && ${PPC_ABI} == ELFv2 There's no harm in committing it now, the port won't break.
(In reply to Gerald Pfeifer from comment #22) https://reviews.freebsd.org/D22039
Thank you, Piotr, for the update and pointers. That looks like an elegant way of addressing this. I'll be patching the ports in the next days.
A commit references this bug: Author: gerald Date: Fri Nov 15 20:47:37 UTC 2019 New revision: 517702 URL: https://svnweb.freebsd.org/changeset/ports/517702 Log: On versions of FreeBSD that that are new enough and made that switch already, use ELFv2 ABI on powerpc64. PR: 239813 Submitted by: pkubaj Reported by: linimon Changes: head/lang/gcc9-devel/Makefile
(In reply to Piotr Kubaj from comment #23) > You could instead use: > .if defined(PPC_ABI) && ${PPC_ABI} == ELFv2 That, plus swap the two arms of the .if statement, right? ;-) I just updated lang/gcc9-devel. Can you - Mark and/or Piotr - please confirm this addresses what you need? Once I have your confirmation, I'll push the same change to lang/gcc9, which is the most important of GCC ports in the Ports Collection.
(In reply to Gerald Pfeifer from comment #27) There is more than Mark in the comments. I'm only set up for ELFv1 and currently only get little bits of time here or there for FreeBSD activity. So it is not likely that I'd test the ELFv2 context in an appropriate time frame. But you may well have meant Mark L. anyway.
(In reply to Gerald Pfeifer from comment #27) This commit fixes ABI issue, but still doesn't fix the namespace issue: /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:4595:12: error: expected unqualified-id tree vec_step = build_vector_from_val (cr_index_vector_type, step); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:4601:39: error: expected expression create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7260:27: error: expected unqualified-id tree new_vec, vec_init, vec_step, t; ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7260:26: error: expected ';' at end of declaration tree new_vec, vec_init, vec_step, t; ^ ; /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7452:16: error: expected expression vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7491:75: error: expected expression new_stmt = gimple_build_assign (vec_def, PLUS_EXPR, induc_def, vec_step); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7522:13: error: expected expression vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7533:25: error: expected expression def, vec_step); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7653:3: error: use of undeclared identifier 't' t = unshare_expr (new_name); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7656:45: error: use of undeclared identifier 't' new_vec = build_vector_from_val (vectype, t); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7657:12: error: expected expression vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7679:74: error: expected expression new_stmt = gimple_build_assign (vec_def, PLUS_EXPR, induc_def, vec_step); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7719:7: error: use of undeclared identifier 't' t = unshare_expr (new_name); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7722:49: error: use of undeclared identifier 't' new_vec = build_vector_from_val (vectype, t); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7723:16: error: expected expression vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL); ^ /tmp/usr/ports/lang/gcc9-devel/work/gcc-9-20191109/gcc/tree-vect-loop.c:7731:25: error: expected expression vec_def, vec_step); ^ So lang/gcc9 misses ABI patch and lang/gcc9-devel misses namespace patch.
(In reply to Piotr Kubaj from comment #29) > This commit fixes ABI issue, but still doesn't fix the namespace issue: The latter is a bug in clang; I'll ping the toolchain folks whether they can get this fixed.
(In reply to Gerald Pfeifer from comment #30) It is, but you committed the workaround to lang/gcc9 anyway: r509718 | gerald | 2019-08-24 13:25:11 +0200 (Sat, 24 Aug 2019) | 3 lines Properly push down lang/gcc9/patch-clang-vec_step into the files/ subdirectory. ------------------------------------------------------------------------ r509717 | gerald | 2019-08-24 13:04:34 +0200 (Sat, 24 Aug 2019) | 8 lines clang on rs6000/powerpc* unfortunately poisons user namespace by default (without any special options or include files being required). Until that changes (or GCC changes) we need to avoid using vec_step as a variable name. PR: 239266 Can that workaround be added for other GCC ports along with the ABI patch?
IIRC, it's more of a limitation regarding how clang implements the vector bits in the parser directly, making them equivilent to reserved keywords, so it would be relatively difficult to fix on the clang side.
Does lang/gcc9-devel now build and work as desired? (I forward ported the patch that addresses clang's issue from lang/gcc9.) Next step then will be lang/gcc9. I'd just love confirmation from a powerpc64 user. Thanks!
Testing on ELFv2 -- compiles fine now w/ PPC_ABI=ELFv2 and the binaries it produces appear to be correct.
(In reply to Gerald Pfeifer from comment #33) I do not know the intent for devel/powerpc64-gcc relative to future ELFv2 ABI use. Does it need anything? (May be it is updating to gcc9 or some such first?) I do know that devel/powerpc64-gcc does not yet have the vec_step patch. (I still have and use my old, local one.) (I also force objdump:devel/binutils because of other port(s) that presume to use objdump but I tried not building the system binutils so the attempts got failed activity, one port that the build did not report the failure but something-built did not work. This was a powerpc64-gcc as master port context where a slave port had the problem. I just decided to provide objdump for all the slave ports by putting this material in devel/powerpc64-gcc .)
A commit references this bug: Author: gerald Date: Mon Nov 18 04:53:27 UTC 2019 New revision: 517855 URL: https://svnweb.freebsd.org/changeset/ports/517855 Log: Update to the 20191115 snapshot of GCC 8.3.1. This brings a fix on the Fortran side and addresses two corner cases for i386. On versions of FreeBSD that that are new enough and made that switch already, use ELFv2 ABI on powerpc64. [1] PR: 239813 [1] Submitted by: pkubaj [1] Reported by: linimon [1] Changes: head/lang/gcc8-devel/Makefile head/lang/gcc8-devel/distinfo
A commit references this bug: Author: gerald Date: Tue Nov 19 17:17:52 UTC 2019 New revision: 517973 URL: https://svnweb.freebsd.org/changeset/ports/517973 Log: Forward port r517702 | gerald | 2019-11-15 from lang/gcc9-devel: On versions of FreeBSD that that are new enough and made that switch already, use ELFv2 ABI on powerpc64. PR: 239813 Submitted by: pkubaj Reported by: linimon Changes: head/lang/gcc9/Makefile
(In reply to Mark Millard from comment #35) > I do not know the intent for devel/powerpc64-gcc relative > to future ELFv2 ABI use. Does it need anything? (May be > it is updating to gcc9 or some such first?) Updating to GCC 9 would be my recomendation, though I have no involvement with that port. lang/gcc9-devel should be fine now, both wrt. the new ABI as well as building with clang. Next I'll make the remaining equivalent changes to lang/gcc9 and lang/gcc8-devel.
A commit references this bug: Author: gerald Date: Wed Nov 20 07:52:29 UTC 2019 New revision: 517994 URL: https://svnweb.freebsd.org/changeset/ports/517994 Log: Partially forward port r517855 | gerald | 2019-11-18 from lang/gcc8-devel: On versions of FreeBSD that that are new enough and made that switch already, use ELFv2 ABI on powerpc64. PR: 239813 Submitted by: pkubaj Reported by: linimon Changes: head/lang/gcc8/Makefile
I believe everything should be in place now. (lang/gcc8-devel needs the workaround for clang poisioning namespace on powerpc which I'll take care of later, and that is tracked separately.) Thank you Piotr, and Mark and Brandon for testing and input!