With a not yet official PPC64 ELFv2 system, where clang8 is the system compiler, lang/gcc8 fails to build with the following errors (listed only the first 3): /usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/tree-vect-loop.c:4979:12: error: expected unqualified-id tree vec_step = build_vector_from_val (cr_index_vector_type, step); ^ /usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/tree-vect-loop.c:4985:39: error: expected expression create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, ^ /usr/ports/lang/gcc8/work/gcc-8.3.0/gcc/tree-vect-loop.c:7653:27: error: expected unqualified-id tree new_vec, vec_init, vec_step, t; The problem seems to be related with conflicting definitions of vec_step, between gcc and clang. This seems to be related with the issues reported here: https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111461.html
Is it only lang/gcc8 that is affected, or also newer versions of GCC? We are soon going to switch the default to lang/gcc9, so if that works I think we can get away declaring this a non-issue and simply marking lang/gcc8{,-devel} as broken on powerpc64. Note: this comes from GCC's altivec.h, so is powerpc64-specific. Note 2: Mark Millard has first raised this in 2017 as you found out, but since then there's not been other reports and a number of folks successfully built GCC, so probably now that clang is landing this is getting warmer (again).
(In reply to Gerald Pfeifer from comment #1) I use patches for the type of issue for: ? /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c ? /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c ? /usr/ports/lang/gcc9/files/patch-gcc_tree-vect-loop.c (I've not done anything with gcc10. I used to have such for gcc7 but quit using gcc7.) My changes long predate recent ELFv2 activity, powerpc64-gcc's patch file going back to 2017-Sep-30. What I did was rename vec_step to vec_step_renamed in order to avoid hitting clang's powerpc family specific definition of the name (tied to altivec). As I remember the source code in the area has changed over the time frame and the 3 patches are not all identical.
(In reply to Gerald Pfeifer from comment #1) Note: Any gcc version with gcc_tree-vect-loop.c using the identifier vec_step will have the problem: clang reserves the name for the powerpc family when it is configures to support altivec. So it is easy to check on the problem's existence if one has the gcc source code to search. A general search would cover if they ever have such code outside that one file.
Same issue with gcc9: /usr/ports/lang/gcc9/work/gcc-9.1.0/gcc/tree-vect-loop.c:4569:12: error: expected unqualified-id tree vec_step = build_vector_from_val (cr_index_vector_type, step); ^ /usr/ports/lang/gcc9/work/gcc-9.1.0/gcc/tree-vect-loop.c:4575:39: error: expected expression create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, ^ /usr/ports/lang/gcc9/work/gcc-9.1.0/gcc/tree-vect-loop.c:7231:27: error: expected unqualified-id tree new_vec, vec_init, vec_step, t; Actually, gcc9 is currently requiring gcc8 on powerpc64, which is probably not needed anymore. I've commented that part to force gcc9 build without gcc8. I'll try to rename vec_step, as Mark suggested, to see if it fixes the issue.
Created attachment 205872 [details] gcc8 vec_step fix Ok, with the attached patch I'm able to go further in gcc8 build. But then when xgcc starts to be used, I get errors, because xgcc is generating ELFv1 code and trying to link with ELFv2 libs. I've tried to fix this by passing -mabi=elfv2 in CFLAGS, with the following Makefile change: 65c65 < MAKE_ARGS+= CFLAGS_FOR_TARGET="-O1" CXXFLAGS_FOR_TARGET="-O1" BOOT_CFLAGS="-O1" # PR235975 --- > MAKE_ARGS+= CFLAGS_FOR_TARGET="-O1 -mabi=elfv2" CXXFLAGS_FOR_TARGET="-O1 -mabi=elfv2" BOOT_CFLAGS="-O1 -mabi=elfv2" # PR235975 The build then goes further, but fails with the following error: gmake[7]: Entering directory '/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libgomp' /bin/sh ./libtool --tag CC --mode=link /usr/ports/lang/gcc8/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc8/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd13.0/bin/ -B/usr/local/powerpc64-portbld-freebsd13.0/lib/ -isystem /usr/local/powerpc64-portbld-freebsd13.0/include -isystem /usr/local/powerpc64-portbld-freebsd13.0/sys-include -Wall -Werror -Wc,-pthread -O1 -mabi=elfv2 -lpthread -Wl,-O1 -o libgomp.la -version-info 1:0:0 -Wl,--version-script,libgomp.ver -rpath /usr/local/lib/gcc8 alloc.lo atomic.lo barrier.lo critical.lo env.lo error.lo icv.lo icv-device.lo iter.lo iter_ull.lo loop.lo loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo affinity.lo target.lo splay-tree.lo libgomp-plugin.lo oacc-parallel.lo oacc-host.lo oacc-init.lo oacc-mem.lo oacc-async.lo oacc-plugin.lo oacc-cuda.lo priority_queue.lo openacc.lo -ldl libtool: link: /usr/ports/lang/gcc8/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc8/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd13.0/bin/ -B/usr/local/powerpc64-portbld-freebsd13.0/lib/ -isystem /usr/local/powerpc64-portbld-freebsd13.0/include -isystem /usr/local/powerpc64-portbld-freebsd13.0/sys-include -shared .libs/alloc.o .libs/atomic.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/icv.o .libs/icv-device.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o .libs/target.o .libs/splay-tree.o .libs/libgomp-plugin.o .libs/oacc-parallel.o .libs/oacc-host.o .libs/oacc-init.o .libs/oacc-mem.o .libs/oacc-async.o .libs/oacc-plugin.o .libs/oacc-cuda.o .libs/priority_queue.o .libs/openacc.o -lpthread -ldl -B/usr/ports/lang/gcc8/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd13.0/bin/ -B/usr/local/powerpc64-portbld-freebsd13.0/lib/ -pthread -mabi=elfv2 -Wl,-O1 -Wl,--version-script -Wl,libgomp.ver -Wl,-soname -Wl,libgomp.so.1 -o .libs/libgomp.so.1.0.0 /usr/local/bin/ld: .libs/openacc.o: ABI version 1 is not compatible with ABI version 2 output /usr/local/bin/ld: failed to merge target specific data of file .libs/openacc.o collect2: error: ld returned 1 exit status gmake[7]: *** [Makefile:594: libgomp.la] Error 1 gmake[7]: Leaving directory '/usr/ports/lang/gcc8/work/.build/powerpc64-portbld-freebsd13.0/libgomp' gmake[6]: *** [Makefile:904: all-recursive] Error 1 So apparently some objects are still being build with ELFv1 ABI.
(In reply to Leandro Lupori from comment #5) > Created attachment 205872 [details] > gcc8 vec_step fix > > Ok, with the attached patch I'm able to go further in gcc8 build. > > But then when xgcc starts to be used, I get errors, because xgcc is > generating ELFv1 code and trying to link with ELFv2 libs. Try this patch : http://mikael.urankar.free.fr/FreeBSD/powerpc64/lang_gcc8_elfv2.diff There is still a problem: stage2 and stage3 differs (it does not happen if the BOOTSTRAP option is off)
(In reply to mikael.urankar from comment #6) Thanks, gcc8 built fine with your patch!
I just hit this too. I will be trying the patch as well.
By the way, stage2 and stage3 *always* differ for me on one file when I'm bootstrapping. I think it's a side effect of timestamping.
I'll see that I can get vec_step addressed in upstream GCC for GCC 10, and ideally backport to the GCC 9 release branch, maybe GCC 8 as well. (In reply to mikael.urankar from comment #6) > There is still a problem: stage2 and stage3 differs (it does not > happen if the BOOTSTRAP option is off) Disabling BOOTSTRAP doesn't really address this, it just sweeps issues under the carpet. The ABI change definitely is one that should go via upstream first. Andreas, what is your take?
(In reply to Gerald Pfeifer from comment #10) > I'll see that I can get vec_step addressed in upstream GCC for GCC 10, > and ideally backport to the GCC 9 release branch, maybe GCC 8 as well. Interesting feedback from one of the POWER experts: "vec_step is not defined in any of the PowerPC ABIs nor the Altivec PEM/PIM. Clang is not using a namespace reserved to the compiler by defining vec_step." So, is this something that should be rectified on the clang side, really? Can one of you in that community please help and check? Thanks!
(In reply to Gerald Pfeifer from comment #11) vec_step is from OpenCL (which did not respect compiler-specific namespace rules for C/C++): QUOTE The vec_step built-in function takes a built-in scalar or vector data type argument and returns an integer value representing the number of elements in the scalar or vector. For all scalar types, vec_step returns 1. The vec_step built-in functions that take a 3- component vector return 4. vec_step may also take a pure type as an argument, e.g. vec_step(float2) END QUOTE That is from: The OpenCL Specification Version: 1.2 which is from 2012-Nov. But I've seen references to version OpenCL V1.1 also having it --so vec_step is even olderin its originating standard. If I remember right, the clang implementation goes back to 2011. Thus: it is the classic problem when something wrong is done and stays in place for years (relative to C/C++): how much code would be invalidated and have to change if clang changed vec_step's spelling to be in a compiler namespace (or did something else incompatible to change things)? And what of OpenCL compatbility? Are GCC folks willing to avoid identifier names that OpenCL reserves and are shown to be a problem, so that compilers can reserve them, such as for OpenCL built-ins like here?
(In reply to Mark Millard from comment #12) Hmm. altivec does define vec_step as well, the AltiVec Technology Programming Interface Manual : https://www.nxp.com/docs/en/reference-manual/ALTIVECPIM.pdf lists: QUOTE 2.5.3 Value for Adjusting Pointers At compile time, the vec_step(vec_data) produces the integer value representing the amount by which a pointer to a component of an AltiVec data should increment to cause a pointer increment to increment by 16 bytes. For example, a vector unsigned short data type is considered to contain eight unsigned 2-byte values. A pointer to unsigned 2-byte values used to stream through an array of unsigned 2-byte values by a full vector at a time should increment by vec_step(vector unsigned short) = 8. Table 2-3 provides a summary of the values by data type. END QUOTE
(In reply to Mark Millard from comment #13) I just noticed: The AltiVec Technology Programming Interface Manual dates back to 1999-June, even older than the OpenCL 1.1 where vec_step was added to OpenCL. (Did AltiVec inspire OpenCL for such?)
(In reply to Gerald Pfeifer from comment #10) Untested, this might be a way to go: Index: gcc/config.gcc =================================================================== --- gcc/config.gcc (revision 273163) +++ gcc/config.gcc (working copy) @@ -2643,6 +2643,11 @@ tmake_file="${tmake_file} rs6000/t-freebsd64" extra_options="${extra_options} rs6000/linux64.opt" ;; + case ${with_abi} in + elfv2) + tm_defines="${tm_defines} LINUX64_DEFAULT_ABI_ELFv2=1" + ;; + *) tm_file="${tm_file} rs6000/freebsd.h" ;; You have to configure gcc with --with-abi=elfv2. The diff above is against gcc trunk.
(In reply to Andreas Tobler from comment #15) Your patch is slightly incorrect (missing esac), but even after correcting it, I still get the same error: /tmp/usr/ports/lang/gcc10-devel/work/gcc-10-20190714/gcc/tree-vect-loop.c:4718:12: error: expected unqualified-id tree vec_step = build_vector_from_val (cr_index_vector_type, step); ^ /tmp/usr/ports/lang/gcc10-devel/work/gcc-10-20190714/gcc/tree-vect-loop.c:4724:39: error: expected expression create_iv (series_vect, vec_step, NULL_TREE, loop, &incr_gsi, ^ /tmp/usr/ports/lang/gcc10-devel/work/gcc-10-20190714/gcc/tree-vect-loop.c:7478:27: error: expected unqualified-id tree new_vec, vec_init, vec_step, t; ^ /tmp/usr/ports/lang/gcc10-devel/work/gcc-10-20190714/gcc/tree-vect-loop.c:7478:26: error: expected ';' at end of declaration tree new_vec, vec_init, vec_step, t; ^ ; /tmp/usr/ports/lang/gcc10-devel/work/gcc-10-20190714/gcc/tree-vect-loop.c:7670:16: error: expected expression vec_step = vect_init_vector (stmt_info, new_vec, vectype, NULL); I pass --with-abi=elfv2 in CONFIGURE_ARGS and there are no other patches.
Created attachment 206115 [details] Proposed hack to work around clang issue (In reply to Piotr Kubaj from comment #16) > Your patch is slightly incorrect (missing esac), but even after > correcting it, I still get the same error: This is to be expected, since Andreas' patch aims to address the ABI issue (which was mentioned "in passing" here), not the fact that clang poisons user namespace by default. > I pass --with-abi=elfv2 in CONFIGURE_ARGS and there are no other patches. You need either the original patch attached to this PR or someone like the lighter one I am attaching thusly. Does it work then?
Created attachment 206116 [details] Fixed hack to work around clang issue (not including in-flight changes to other ports)
Folks, could someone with a powerpc* machine please provide feedback on my proposed patch here?
(In reply to Gerald Pfeifer from comment #19) I did not realize that you wanted someone to test building with your simpler, more uniform way of doing the rename. Seems fine. Details of test follow (since a clang based system is unusual) . . . A non-bootrap build is faster and historically showed the error, so that I what I used for this test. I can re-run with a full bootstrap if desired. # more /usr/local/etc/poudriere.d/options/lang_gcc8/options # This file is auto-generated by 'make config'. # Options for gcc8-8.2.0_2 _OPTIONS_READ=gcc8-8.2.0_2 _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE OPTIONS_FILE_UNSET+=BOOTSTRAP OPTIONS_FILE_UNSET+=GRAPHITE For the following on an old PowerMc G5 2-socket with 2 cores each: # uname -apKU FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r347549M: Wed May 22 15:14:43 PDT 2019 markmi@FBSDG5L:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300025 1300025 (The above pre-dates the secure-plt changes that block cross builds for buildworld buildkernel from amd64.) # cc -v FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin # c++ -v FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin # mv /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c ~/ (That removed my original patch.) # patch < patch-clang-vec_step Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lang/gcc8/files/patch-clang-vec_step |=================================================================== |--- lang/gcc8/files/patch-clang-vec_step (nonexistent) |+++ lang/gcc8/files/patch-clang-vec_step (working copy) -------------------------- (Creating file lang/gcc8/files/patch-clang-vec_step...) Patching file lang/gcc8/files/patch-clang-vec_step using Plan A... Empty context always matches. Hunk #1 succeeded at 1. done # poudriere bulk -jFBSDpowerpc64 -C -w lang/gcc8 . . . [00:00:49] [01] [00:00:00] Building lang/gcc8 | gcc8-8.3.0_2 [00:40:12] [01] [00:39:23] Finished lang/gcc8 | gcc8-8.3.0_2: Success
(In reply to Mark Millard from comment #20) The full bootstrap build worked too: # more /usr/local/etc/poudriere.d/options/lang_gcc8/options # This file is auto-generated by 'make config'. # Options for gcc8-8.2.0_2 _OPTIONS_READ=gcc8-8.2.0_2 _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE OPTIONS_FILE_SET+=BOOTSTRAP OPTIONS_FILE_UNSET+=GRAPHITE # poudriere bulk -jFBSDpowerpc64 -C -w lang/gcc8 . . . [00:00:52] [01] [00:00:00] Building lang/gcc8 | gcc8-8.3.0_2 [03:54:29] [01] [03:53:37] Finished lang/gcc8 | gcc8-8.3.0_2: Success (Full Bootstrap definitely takes longer.) For reference for the odd system-clang based context: # which ld /usr/bin/ld # ld -v GNU ld (GNU Binutils) 2.32
A commit references this bug: Author: gerald Date: Thu Aug 22 16:24:49 UTC 2019 New revision: 509607 URL: https://svnweb.freebsd.org/changeset/ports/509607 Log: 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 Changes: head/lang/gcc8/files/patch-clang-vec_step
(In reply to Gerald Pfeifer from comment #11) QUOTE "vec_step is not defined in any of the PowerPC ABIs nor the Altivec PEM/PIM. END QUOTE Were the POWER experts that indicated the above notified of the 1999: https://www.nxp.com/docs/en/reference-manual/ALTIVECPIM.pdf that does define vec_step in "2.5.3 Value for Adjusting Pointers"? (Quoted in comment #13.) At least knowing of it might prompt noticing the type of problem quicker in the future. (I have no idea which POWER experts reported the above quote.) (I'd blaim the document in ALTIVECPIM.pdf as what started this mess by not following langauge naming rules. Then other things that should likely have been done were not done to work around the issue. OpenCL later also having defined vec_step in a similar manor did not help.)
A commit references this bug: Author: gerald Date: Sat Aug 24 11:04:35 UTC 2019 New revision: 509717 URL: https://svnweb.freebsd.org/changeset/ports/509717 Log: 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 Changes: head/lang/gcc9/patch-clang-vec_step
With that, lang/gcc8 and lang/gcc9 as the two ports used by others are hacked to avoid this powerpc-specific issue caused by clang. The underlying issue in clang still should be addressed, of course.
(In reply to Piotr Kubaj from comment #16) Piotr could you try the below patch with the latest ports gcc(8/9)? Note, I added the missing 'esac' and I moved the double semicolon below the case statement. Index: config.gcc =================================================================== --- config.gcc (revision 274937) +++ config.gcc (working copy) @@ -2676,6 +2676,11 @@ tm_file="${tm_file} rs6000/default64.h rs6000/freebsd64.h" tmake_file="${tmake_file} rs6000/t-freebsd64" extra_options="${extra_options} rs6000/linux64.opt" + case ${with_abi} in + elfv2) + tm_defines="${tm_defines} LINUX64_DEFAULT_ABI_ELFv2=1" + ;; + esac ;; *) tm_file="${tm_file} rs6000/freebsd.h" --with-abi=elfv2 in CONFIGURE_ARGS is fine. How far do you come while bootstrapping gcc? TIA, Andreas
(In reply to Andreas Tobler from comment #26) This patch is not necessary, only https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813#c6 is needed.
This PR genuinely is about clang breaking other software (GCC on powerpc in this case), which should be fixed. Apologies for not focusing on separating the other issue of an ABI change on powerpc earlier on; are you fine if we track the clang breakage here and the ABI question over at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239813 ?
A commit references this bug: Author: gerald Date: Sun Nov 17 22:55:14 UTC 2019 New revision: 517843 URL: https://svnweb.freebsd.org/changeset/ports/517843 Log: Forward port r509717 | gerald | 2019-08-24 from lang/gcc9 since this issue has not been addressed upstream yet: 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 Changes: head/lang/gcc9-devel/files/patch-clang-vec_step
A commit references this bug: Author: gerald Date: Fri Nov 22 00:54:36 UTC 2019 New revision: 518121 URL: https://svnweb.freebsd.org/changeset/ports/518121 Log: Forward port r509607 | gerald | 2019-08-22 from lang/gcc8 since this has not been addressed upstream yet: 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 Changes: head/lang/gcc8-devel/files/patch-clang-vec_step
Already fixed.
^Triage: Assign to committer that resolved
Reopening, since the general issue in clang has *not* been addressed yet (which lang/gcc10-devel or anyone trying to build GCC from upstream sources directly still runs into).
*** Bug 245483 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: gerald Date: Sun May 3 09:11:13 UTC 2020 New revision: 533759 URL: https://svnweb.freebsd.org/changeset/ports/533759 Log: Update to the 20200502 snapshot of GCC 10.0.1, which has branched for the release of GCC 10.1 (and the GCC 10 release series) now. Forward port r517843 | gerald | 2019-11-17 from lang/gcc9-devel since this issue has not been addressed upstream or in our system compiler yet. [1] 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, 245483 Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo head/lang/gcc10-devel/patch-clang-vec_step
I no longer have access to powerpc* contexts but based on comments #12 and comment #13 and comment #14 I wonder if builds with both Altivec and OpenCL support disabled would still define vec_step and so get the problem (if such disabling of both is possible). If there are not both of the disables, then an alternative might be targeting powerpc variants that do not have Altivec and seeing if vec_step is still a problem. If vec_step is still defined (and so a problem) then "no trigger" would seem to be right. Otherwise the issue would seem to be specific to Altivec/OpenCL support and so more localized. (Somewhat of a "trigger".)
There is some movement now on the GCC side https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 as well as a report against LLVM https://github.com/llvm/llvm-project/issues/85579
Given the gcc/g++ based notation: #pragma GCC poison NAME(s) that is not actually involved here, the description as "clang poisons" is somewhat unfortunate. (The #pragma GCC poison use that GCC uses to enforce some code design choices in the code not required to be generically compatible with general c++11 capable toolchains is driving choices about use of bootstrap modes for lang/gcc14 and later. The two "poison" contexts should not be confused.)