head -r324071 system clang 5 based powerpc64 building ports: x11-toolkit/qt5-gui gets "clang++: error: unknown argument: '-mminimal-toc'"

2017-09-29 Thread Mark Millard 
I attempted a poudriere based build of some
ports and the qt5-gui build involved failed
with the following sorts of notices. But
the context is using the same sources as
I've been testing various proposed armv6
related build fixes with (fixes taken from
bugzilla activity, not my own). I doubt
that they matter to the powerpc64 issue.


DEFAULT_LIBDIRS="/lib
/usr/lib
/usr/local/lib"
Running configuration tests...
Determining architecture... ()
clang++ -c -pipe -O2 -pipe -B/usr/local/bin/ -g -fno-strict-aliasing 
-mminimal-toc -B/usr/local/bin/ -g -Wall -W -fPIC  -I. -I/usr/local/include 
-I/usr/local/lib/qt5/mkspecs/freebsd-clang -o arch.o arch.cpp
clang++: error: unknown argument: '-mminimal-toc'
*** Error code 1

Stop.
make[1]: stopped in 
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/config.tests/arch
Unable to determine architecture!

Could not determine the target architecture!
Turn on verbose messaging (-v) to see the final report.
System architecture: 'unknown'
Host architecture: 'unknown'
clang++ -c -fvisibility=hidden fvisibility.c
clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
Symbol visibility control enabled.
clang++ -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC 
bsymbolic_functions.c
clang++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior 
is deprecated [-Wdeprecated]
bsymbolic_functions.c:2:2: error: "Symbolic function binding on this 
architecture may be broken, disabling it (see QTBUG-36129)."
#error "Symbolic function binding on this architecture may be broken, disabling 
it (see QTBUG-36129)."
 ^
1 error generated.
Symbolic function binding disabled.
checking for objcopy... 
clang++ -c -pipe -O2 -B/usr/local/bin/ -g -fno-strict-aliasing -mminimal-toc 
-O2 -Wall -W -fPIC  -I. -I/usr/local/include 
-I/usr/local/lib/qt5/mkspecs/freebsd-clang -o objcopy.o objcopy.cpp
clang++: error: unknown argument: '-mminimal-toc'
*** Error code 1

Stop.
make[1]: stopped in 
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/config.tests/unix/objcopy
objcopy disabled.
ERROR: -separate-debug-info was requested but this binutils does not support it.
Re-run configure with -v for more information
===>  Script "configure" failed unexpectedly.
Please report the problem to k...@freebsd.org [maintainer] and attach the
"/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-opensource-src-5.7.1/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/x11-toolkits/qt5-gui
=>> Cleaning up wrkdir
===>  Cleaning for qt5-gui-5.7.1_1
build of x11-toolkits/qt5-gui | qt5-gui-5.7.1_1 ended at Fri Sep 29 11:24:04 
PDT 2017
build time: 00:13:38
!!! build failure encountered !!!


Context:

# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT  r324071M  powerpc powerpc64 
1200047 1200047

Built via amd64 -> powerpc64 cross build, using clang
for buildworld:

[Note: The kernel was built with gcc 4.2.1 .]

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDpowerpc64 12.0-CURRENT powerpc.powerpc64 null   2017-09-28 20:55:01 
/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils-poud

(It is using /usr/src .)

# poudriere ports -l
PORTSTREE METHOD TIMESTAMP   PATH
default   null   2017-09-28 17:04:57 /usr/ports


# more ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host 
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITHOUT_LLD_BOOTSTRAP=
WITH_LLD=
WITHOUT_LLD_IS_LD=
WITH_LLDB=
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
MALLOC_PRODUCTION=
#
# Avoid converts between pointers to integer types with different sign 
[-Werror,-Wpointer-sign]
# and such from blocking the build.
WERROR=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
#
# Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX
#   binding automatically.
#
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Marco Beishuizen 

On Fri, 29 Sep 2017, the wise Thomas Mueller wrote:


What is the current status of portupgrade and portmaster?

I haven't used portupgrade in some time, but what about portmaster?


Using portupgrade every day and still works great. Tried portmaster once 
but liked portupgrade more. I use poudriere just for testing ports.


--
I can feel for her because, although I have never been an Alaskan
prostitute dancing on the bar in a spangled dress, I still get very
bored with washing and ironing and dishwashing and cooking day after
relentless day.
-- Betty MacDonald
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [vec_step macro name in gcc7's altivec.h]

2017-09-29 Thread Mark Millard 
Summary of later additions:

devel/powerpc64-gcc has the same problem as gcc7
in this clang-based powerpc64.

My note about using gcc 4.2.1 for the kernel
build was wrong. (My 32-bit powerpc builds
are that way, not the powerpc64 ones.)

On 2017-Sep-29, at 1:51 AM, Mark Millard  wrote:

> [Looks like gcc7 might be causing its own problem
> via a vec_step macro name in its altivec.h .]
> 
> On 2017-Sep-29, at 1:14 AM, Mark Millard  wrote:
> 
>> I attempted a poudriere based build of some
>> ports and the gcc7 build involved failed
>> with the following sorts of notices:

devel/powerpc64-gcc has the same problem as gcc7
in this clang-based powerpc64

>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: 
>> error: expected unqualified-id
>> tree new_vec, vec_init, vec_step, t;
>> ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: 
>> error: expected ';' at end of declaration
>> tree new_vec, vec_init, vec_step, t;
>>^
>>;
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3983:3: 
>> error: use of undeclared identifier 't'
>> t = unshare_expr (new_name);
>> ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3988:49: 
>> error: use of undeclared identifier 't'
>> new_vec = build_vector_from_val (stepvectype, t);
>>   ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3989:12: 
>> error: expected expression
>> vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>>  ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4011:75: 
>> error: expected expression
>> new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step);
>> ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4048:7: 
>> error: use of undeclared identifier 't'
>> t = unshare_expr (new_name);
>> ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4051:53: 
>> error: use of undeclared identifier 't'
>> new_vec = build_vector_from_val (stepvectype, t);
>>   ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4052:16: 
>> error: expected expression
>> vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>>  ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4060:25: 
>> error: expected expression
>> vec_def, vec_step);
>>  ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6327:9: 
>> error: expected unqualified-id
>> tree vec_step = build_vector_from_val (cr_index_vector_type, step);
>>  ^
>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6333:36: 
>> error: expected expression
>> create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi,
>> ^
>> 50 warnings and 12 errors generated.
>> gmake[3]: *** [Makefile:1099: tree-vect-loop.o] Error 1
>> gmake[3]: *** Waiting for unfinished jobs
>> 42 warnings generated.
>> 51 warnings generated.
>> 50 warnings generated.
>> rm gfortran.pod gcc.pod
>> gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build/gcc'
>> gmake[2]: *** [Makefile:4225: all-gcc] Error 2
>> gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
>> gmake[1]: *** [Makefile:893: all] Error 2
>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
>> ===> Compilation failed unexpectedly.
>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
>> the maintainer.
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports/lang/gcc7
>> =>> Cleaning up wrkdir
>> ===>  Cleaning for gcc7-7.2.0_1
>> build of lang/gcc7 | gcc7-7.2.0_1 ended at Fri Sep 29 00:22:00 PDT 2017
>> build time: 00:29:27
>> !!! build failure encountered !!!
> 
> Turns out that there is:
> 
> # grep -r "\" ~/poudriere_failure/lang_gcc7/ | more
> . . .
> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:/*
>  Given the vec_step of a type, return the corresponding bool type.  */
> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:typename
>  __altivec_bool_ret ::__ret \
> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h: 
>   to #define vec_step to __builtin_vec_step.  */
> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:#define
>  vec_step(x) __builtin_vec_step (* (__typeof__ (x) *) 0)
> . . .
> 
> ( config/s390/vecintrin.h has something similar.)
> 
> 
> 
>> FYI:
>> 
>> # grep -r "\" /usr/src/* | more
>> /usr/src/contrib/llvm/tools/clang/lib/AST/ASTDumper.cpp:OS << "

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Matt Smith 

On Sep 29 20:23, Kurt Jaeger wrote:

Hi!


What is one officially supposed to use to build and upgrade
packages from source?


I doubt that we already have a 'official' consensus, but
buildung using poudriere, while expensive from the
hardware resource point of view, looks to me as the most stable
way to do it.



I agree. Portmaster was useful for many years but these days it is being 
left behind. The expectation is that ports are built in a clean room 
environment and portmaster does not provide that. I used synth for 
several months and it is a great tool. It works fine, but my problem 
with it is that the developer was forced out of FreeBSD and it needs an 
ada compiler.


I think on FreeBSD 12 the ada compiler is broken isn’t it? Meaning synth 
will break. For this reason I switched to poudriere and that works fine 
for me. As that is the tool used by the pkg builders themselves I know 
it will work.


For example we are shortly getting flavors support in the ports tree. I 
think the author of synth has already said he is not going to support 
this whereas poudriere will straight away.


--
Matt
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Kurt Jaeger 
Hi!

> What is one officially supposed to use to build and upgrade
> packages from source?

I doubt that we already have a 'official' consensus, but
buildung using poudriere, while expensive from the
hardware resource point of view, looks to me as the most stable
way to do it.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Port Request: FreeIPA

2017-09-29 Thread Paul Pathiakis via freebsd-ports 
Hi,
It seems very useful.  I ended up in an environment using it.  (Yeah, CentOS... 
but)  It's really quite amazing.
Most of the requisite software is already ported with the exception of the 
OpenPKI system known as 'Dogtag'.
Between SSSD and FreeIPA, it seems like something truly useful has emerged to 
allow full integration into Windoze environments.  
At the end of the day, AD is pretty impressive.  The gap between it's 'ease of 
use' and LDAP is LARGE.  However, FreeIPA not so big of a gap.
Thank you,
P.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Chris H 
On Fri, 29 Sep 2017 09:38:36 + Carmel NY  wrote

> On Fri, 29 Sep 2017 09:00:02 +, Thomas Mueller stated:
> 
> >Excerpt from Jan Beich:
> >
> >> Why did portupgrade skip rebuilding print/harfbuzz-icu before building
> >> editors/libreoffice? The dependency trees of most desktop applications
> >> are so complex that the build falls apart if the upgrade tools aren't
> >> robust enough e.g., ignore MOVED or PORTREVISION bumps.  
> > 
> >> In short, this is a reminder portmaster/portupgrade are NOT supported.
> >> Users are on their own debugging such issues.  
> >
> >What is the current status of portupgrade and portmaster?
> >
> >I haven't used portupgrade in some time, but what about portmaster?
> >
> >What is one officially supposed to use to build and upgrade packages from
> >source?
> >
> >Synth, poudriere, any others?
> >
> >Tom
> 
> Years ago, I was a strong supporter of "portmanager". It just worked when
> others failed. They when its support wained, I started using "portupgrade". I
> tried "portmaster", but it just failed way to often for my tastes.
> However, after updating to FreeBSD-11, I have used "synth" exclusively. It is
> fast, through and hasn't failed me yet. It took me a while to understand all
> of its nuances, like how to use a "make.conf" file with it; however, it was
> worth it. I would highly recommend it.

FWIW I loved portmaster, but quickly found that by choosing it, I was
*instantly* at odds with a large majority of the FreeBSD crowd.
Eventually, I experimented with other choices, and finally landed on
ports-mgmt/synth, and never looked back. Like Carmel, I found some aspects 
un-intuitive. But after figuring them out. I was hooked. John Marino did
a wonderful job on this, and is very helpful.

--Chris
> 
> 
> -- 
> Carmel
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Porters Handbook section 4.4

2017-09-29 Thread Warren Block 

On Mon, 25 Sep 2017, Russell Haley wrote:


Thanks! I'll play with this on the weekend.


Please create a review at https://reviews.freebsd.org/ and add me as a 
reviewer.


Thanks!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Carmel NY 
On Fri, 29 Sep 2017 09:00:02 +, Thomas Mueller stated:

>Excerpt from Jan Beich:
>
>> Why did portupgrade skip rebuilding print/harfbuzz-icu before building
>> editors/libreoffice? The dependency trees of most desktop applications
>> are so complex that the build falls apart if the upgrade tools aren't
>> robust enough e.g., ignore MOVED or PORTREVISION bumps.  
> 
>> In short, this is a reminder portmaster/portupgrade are NOT supported.
>> Users are on their own debugging such issues.  
>
>What is the current status of portupgrade and portmaster?
>
>I haven't used portupgrade in some time, but what about portmaster?
>
>What is one officially supposed to use to build and upgrade packages from
>source?
>
>Synth, poudriere, any others?
>
>Tom

Years ago, I was a strong supporter of "portmanager". It just worked when
others failed. They when its support wained, I started using "portupgrade". I
tried "portmaster", but it just failed way to often for my tastes.
However, after updating to FreeBSD-11, I have used "synth" exclusively. It is
fast, through and hasn't failed me yet. It took me a while to understand all
of its nuances, like how to use a "make.conf" file with it; however, it was
worth it. I would highly recommend it.


-- 
Carmel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-09-29 Thread Dave Cottlehuber 
> What is the current status of portupgrade and portmaster?
> 
> I haven't used portupgrade in some time, but what about portmaster?
> 
> What is one officially supposed to use to build and upgrade packages from
> source?

In the interests of having some numbers other than email list replies I
threw up a straw poll:

https://forums.freebsd.org/threads/62633/

pick your poison and I'll report back in a week. RT/posts welcomed to
spread the word.

A+
Dave
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Status of portupgrade and portmaster?

2017-09-29 Thread Thomas Mueller 
Excerpt from Jan Beich:

> Why did portupgrade skip rebuilding print/harfbuzz-icu before building
> editors/libreoffice? The dependency trees of most desktop applications
> are so complex that the build falls apart if the upgrade tools aren't
> robust enough e.g., ignore MOVED or PORTREVISION bumps.
 
> In short, this is a reminder portmaster/portupgrade are NOT supported.
> Users are on their own debugging such issues.

What is the current status of portupgrade and portmaster?

I haven't used portupgrade in some time, but what about portmaster?

What is one officially supposed to use to build and upgrade packages from 
source?

Synth, poudriere, any others?

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

2017-09-29 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/scons | 2.5.1   | 3.0.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [vec_step macro name in gcc7's altivec.h]

2017-09-29 Thread Mark Millard 
[Looks like gcc7 might be causing its own problem
via a vec_step macro name in its altivec.h .]

On 2017-Sep-29, at 1:14 AM, Mark Millard  wrote:

> I attempted a poudriere based build of some
> ports and the gcc7 build involved failed
> with the following sorts of notices:
> 
> 
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: 
> error: expected unqualified-id
>  tree new_vec, vec_init, vec_step, t;
>  ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: 
> error: expected ';' at end of declaration
>  tree new_vec, vec_init, vec_step, t;
> ^
> ;
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3983:3: 
> error: use of undeclared identifier 't'
>  t = unshare_expr (new_name);
>  ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3988:49: 
> error: use of undeclared identifier 't'
>  new_vec = build_vector_from_val (stepvectype, t);
>^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3989:12: 
> error: expected expression
>  vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>   ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4011:75: 
> error: expected expression
>  new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step);
>  ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4048:7: 
> error: use of undeclared identifier 't'
>  t = unshare_expr (new_name);
>  ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4051:53: 
> error: use of undeclared identifier 't'
>  new_vec = build_vector_from_val (stepvectype, t);
>^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4052:16: 
> error: expected expression
>  vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>   ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4060:25: 
> error: expected expression
>  vec_def, vec_step);
>   ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6327:9: 
> error: expected unqualified-id
>  tree vec_step = build_vector_from_val (cr_index_vector_type, step);
>   ^
> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6333:36: 
> error: expected expression
>  create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi,
>  ^
> 50 warnings and 12 errors generated.
> gmake[3]: *** [Makefile:1099: tree-vect-loop.o] Error 1
> gmake[3]: *** Waiting for unfinished jobs
> 42 warnings generated.
> 51 warnings generated.
> 50 warnings generated.
> rm gfortran.pod gcc.pod
> gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build/gcc'
> gmake[2]: *** [Makefile:4225: all-gcc] Error 2
> gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
> gmake[1]: *** [Makefile:893: all] Error 2
> gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/gcc7
> =>> Cleaning up wrkdir
> ===>  Cleaning for gcc7-7.2.0_1
> build of lang/gcc7 | gcc7-7.2.0_1 ended at Fri Sep 29 00:22:00 PDT 2017
> build time: 00:29:27
> !!! build failure encountered !!!

Turns out that there is:

# grep -r "\" ~/poudriere_failure/lang_gcc7/ | more
. . .
/root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:/* 
Given the vec_step of a type, return the corresponding bool type.  */
/root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:typename
 __altivec_bool_ret ::__ret \
/root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:   
to #define vec_step to __builtin_vec_step.  */
/root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:#define
 vec_step(x) __builtin_vec_step (* (__typeof__ (x) *) 0)
. . .

( config/s390/vecintrin.h has something similar.)



> FYI:
> 
> # grep -r "\" /usr/src/* | more
> /usr/src/contrib/llvm/tools/clang/lib/AST/ASTDumper.cpp:OS << " vec_step";
> /usr/src/contrib/llvm/tools/clang/lib/AST/StmtPrinter.cpp:OS << 
> "vec_step";
> /usr/src/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp:/// 
> VisitUnaryExprOrTypeTraitExpr - Evaluate a sizeof, alignof or vec_step with
> /usr/src/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp:  // The 
> vec_step built-in functions that take a 3-component
> /usr/src/contrib/llvm/tools/clang/lib/AST/ItaniumMangle.cpp:  
>