FreeBSD_HEAD_amd64_gcc - Build #1677 - Fixed

From: <jenkins-admin_at_FreeBSD.org>
Date: Sat, 12 Nov 2016 01:16:25 +0000 (GMT)
FreeBSD_HEAD_amd64_gcc - Build #1677 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1677/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1677/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1677/console

Change summaries:

308563 by emaste:
libcc_{s,eh}: build without SSP

As in the gnu/lib/libgcc Makefile:
    libgcc is linked in last and thus cannot depend on ssp
    symbols coming from earlier libraries. Disable stack protection
    for this library.

Reviewed by:	dim
Sponsored by:	The FreeBSD Foundation

308562 by rstone:
Fix git tools when run against a worktree

In a git worktree, the gitdir is in an entirely different location.
In arcgit, use git rev-parse --git-dir to get the correct path to it
always.

When running git from outside of the work tree, as in importgit,
the path provided by git rev-parse --git-dir can be either a
relative or absolute path depending on the work tree.  Rather
than trying to deal with that, just use git -C.

Differential Revision:	https://reviews.freebsd.org/D8501
Reviewed by: markj

308561 by gavin:
Correct spelling in syslog: getttimeofday -> gettimeofday

308560 by jhibbits:
Replace another fdt_is_compatible() call.

308559 by dim:
Pull in r263169 from upstream llvm trunk (by Tim Northover):

  AArch64: only try to use scaled fcvt ops on legal vector types.

  Before we ended up calling getSimpleVectorType on a <3 x float>, which
  asserted.

This fixes an assertion when building the print/ghostscript9-agpl-base
port for AArch64.

PR:		213865
MFC after:	3 days

308558 by cem:
queue.3: Document existing QMD_* macros

Feedback from:	bapt, bdrewery, emaste
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D3983

308553 by cem:
ioat(4): Fix race between process_events and reset_hw

In the case where a hardware error is detected during
ioat_process_events, hardware may advance (by one descriptor, probably)
and a subsequent ioat_process_events may race the intended ioat_reset_hw
followup.  In that case, the second process_events would observe a
completion update that does not match the software "last_seen" status,
and attempt to successfully complete already-failed descriptors.

Guard against this race with the resetting_cleanup flag.

Reviewed by:	bdrewery, markj
Sponsored by:	Dell EMC Isilon
Received on Sat Nov 12 2016 - 00:18:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC