Bug 239266 - clang poisons namespace on powerpc by defining vec_step without any trigger (GCC fails to build: tree-vect-loop.c:4979:12: error: expected unqualified-id)
Summary: clang poisons namespace on powerpc by defining vec_step without any trigger (...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Some People
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords:
: 245483 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-17 15:52 UTC by Leandro Lupori
Modified: 2024-03-17 20:15 UTC (History)
10 users (show)

See Also:


Attachments
gcc8 vec_step fix (5.31 KB, patch)
2019-07-18 16:12 UTC, Leandro Lupori
no flags Details | Diff
Proposed hack to work around clang issue (2.43 KB, patch)
2019-07-28 13:17 UTC, Gerald Pfeifer
no flags Details | Diff
Fixed hack to work around clang issue (not including in-flight changes to other ports) (1.19 KB, patch)
2019-07-28 13:19 UTC, Gerald Pfeifer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Leandro Lupori 2019-07-17 15:52:17 UTC
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
Comment 1 Gerald Pfeifer freebsd_committer freebsd_triage 2019-07-17 16:50:18 UTC
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).
Comment 2 Mark Millard 2019-07-17 17:10:08 UTC
(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.
Comment 3 Mark Millard 2019-07-17 17:18:49 UTC
(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.
Comment 4 Leandro Lupori 2019-07-17 20:20:53 UTC
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.
Comment 5 Leandro Lupori 2019-07-18 16:12:14 UTC
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.
Comment 6 Mikael Urankar freebsd_committer freebsd_triage 2019-07-18 16:17:45 UTC
(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)
Comment 7 Leandro Lupori 2019-07-18 16:53:36 UTC
(In reply to mikael.urankar from comment #6)

Thanks, gcc8 built fine with your patch!
Comment 8 Brandon Bergren freebsd_committer freebsd_triage 2019-07-18 22:01:54 UTC
I just hit this too. I will be trying the patch as well.
Comment 9 Brandon Bergren freebsd_committer freebsd_triage 2019-07-18 22:06:17 UTC
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.
Comment 10 Gerald Pfeifer freebsd_committer freebsd_triage 2019-07-20 06:29:52 UTC
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?
Comment 11 Gerald Pfeifer freebsd_committer freebsd_triage 2019-07-20 17:31:18 UTC
(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!
Comment 12 Mark Millard 2019-07-20 21:28:41 UTC
(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?
Comment 13 Mark Millard 2019-07-20 21:57:28 UTC
(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
Comment 14 Mark Millard 2019-07-20 22:01:58 UTC
(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?)
Comment 15 Andreas Tobler freebsd_committer freebsd_triage 2019-07-24 21:03:18 UTC
(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.
Comment 16 Piotr Kubaj freebsd_committer freebsd_triage 2019-07-24 22:05:04 UTC
(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.
Comment 17 Gerald Pfeifer freebsd_committer freebsd_triage 2019-07-28 13:17:57 UTC
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?
Comment 18 Gerald Pfeifer freebsd_committer freebsd_triage 2019-07-28 13:19:44 UTC
Created attachment 206116 [details]
Fixed hack to work around clang issue (not including in-flight changes to other ports)
Comment 19 Gerald Pfeifer freebsd_committer freebsd_triage 2019-08-13 12:41:28 UTC
Folks, could someone with a powerpc* machine please provide feedback
on my proposed patch here?
Comment 20 Mark Millard 2019-08-13 19:56:59 UTC
(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
Comment 21 Mark Millard 2019-08-14 00:08:28 UTC
(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
Comment 22 commit-hook freebsd_committer freebsd_triage 2019-08-22 16:25:45 UTC
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
Comment 23 Mark Millard 2019-08-22 21:09:02 UTC
(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.)
Comment 24 commit-hook freebsd_committer freebsd_triage 2019-08-24 11:05:26 UTC
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
Comment 25 Gerald Pfeifer freebsd_committer freebsd_triage 2019-08-24 11:12:16 UTC
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.
Comment 26 Andreas Tobler freebsd_committer freebsd_triage 2019-08-27 19:18:52 UTC
(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
Comment 27 Piotr Kubaj freebsd_committer freebsd_triage 2019-08-28 10:05:27 UTC
(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.
Comment 28 Gerald Pfeifer freebsd_committer freebsd_triage 2019-08-29 12:34:53 UTC
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 ?
Comment 29 commit-hook freebsd_committer freebsd_triage 2019-11-17 22:55:21 UTC
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
Comment 30 commit-hook freebsd_committer freebsd_triage 2019-11-22 00:55:05 UTC
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
Comment 31 Piotr Kubaj freebsd_committer freebsd_triage 2019-12-15 12:06:37 UTC
Already fixed.
Comment 32 Kubilay Kocak freebsd_committer freebsd_triage 2019-12-16 14:12:17 UTC
^Triage: Assign to committer that resolved
Comment 33 Gerald Pfeifer freebsd_committer freebsd_triage 2019-12-27 04:47:39 UTC
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).
Comment 34 Gerald Pfeifer freebsd_committer freebsd_triage 2020-04-09 20:31:23 UTC
*** Bug 245483 has been marked as a duplicate of this bug. ***
Comment 35 commit-hook freebsd_committer freebsd_triage 2020-05-03 09:12:06 UTC
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
Comment 36 Mark Millard 2021-10-29 20:52:21 UTC
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".)
Comment 37 Gerald Pfeifer freebsd_committer freebsd_triage 2024-03-17 19:55:10 UTC
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
Comment 38 Mark Millard 2024-03-17 20:15:02 UTC
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.)