From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) by sourceware.org (Postfix) with ESMTPS id 9D8E73858D39 for ; Sun, 28 Apr 2024 18:38:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D8E73858D39 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=lorenzosalvadore.it Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lorenzosalvadore.it ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9D8E73858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714329495; cv=none; b=kZVnzU9oGzTD9SUqGS13hlwsaYBTflKH1ZZkV9ee1Lg9Z4W5dqTtktLVqKYLR7jT6KJvQZA4R9WWopHaKZScXyqMevvLe5mjb5YA0bZFWJHgAfybcq/xwUyFamjoLSfgI3Zr9l3Gnsmtt1v/Un0Y+c8O+I1VonMQq7DAnAe67i4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714329495; c=relaxed/simple; bh=oMcB/D2Fxerzq5cUIRqvt3y0Avt5ZAjlbbVCA/Dj96M=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=lSvlxsdwnvKoTJXAzFhoWj+mL+0FdSzhRdVT8gjwD1T1/+MN1zLI7vE+ZQbzR/ecUUmQa37sSG+7xdHF9vEpUjwEJiEk8Q08bp7edYMP6nDkW6VgRIsAKBT7e6qqAhhmrPByOU5BOoUK5yEtmWqAtSnDz23P8YerwU9uFSgFB5w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail; t=1714329491; x=1714588691; bh=oMcB/D2Fxerzq5cUIRqvt3y0Avt5ZAjlbbVCA/Dj96M=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=UqG2ujMdQHG5QTH9NFQIYRl5VT32wHYepME2KFo9nMcQqlUrCWHb4iAf0vdpTCaKy qtWwUBsy7Ei58NzCmJnruFMxSm2yRWxLzOSvShvvJUNNc0gQmfXc6XlODyDfvpEMvD flTJAQXKnrtA/uaBXpBPHLGX35dPD/ZPccXqANQR54n0afOur/FOrJONmvXroWAY6k /W95WmDnoAUOGzwHsynY8D2mPPknsESQ7OyqS+3T3nRccMSYQhhhuA90YsKAVjZbqC x5Ht2C+r0rnnN2ThXW0FYaHsSwVpasQwiEFVgrhVgqPiM+Qk0J9BZtWZq5OfkKbzD1 MK0pldTqlVG3g== Date: Sun, 28 Apr 2024 18:38:07 +0000 To: Rainer Orth From: Lorenzo Salvadore Cc: Lorenzo Salvadore via Gcc , Gerald Pfeifer , Jonathan Wakely , Andreas Tobler Subject: Re: GCC testing on FreeBSD Message-ID: <2NOYgLhrt383ftNn2yo8eJLmLnwYY4E64y6QdA3c_TvNghHor6dnmW7pCvWlUktDHpEvMrLsCopjv0KOhEVTDTgvQI0BX2OhSUeasjMtIPw=@lorenzosalvadore.it> In-Reply-To: References: <866dda5e-c983-ac16-de71-05b685536cd7@pfeifer.com> Feedback-ID: 53711648:user:proton X-Pm-Message-ID: b0d386a414290be83b6ccadc316faa9c44539b33 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sunday, April 28th, 2024 at 19:19, Rainer Orth wrote: >=20 >=20 > Hi Lorenzo, >=20 > > On Sunday, April 28th, 2024 at 12:24, Gerald Pfeifer gerald@pfeifer.com= wrote: > >=20 > > > On Fri, 26 Apr 2024, Jonathan Wakely wrote: > > >=20 > > > > How are you testing on FreeBSD? > > > >=20 > > > > When I build GCC trunk on FreeBSD 14.0 and try to run the libstdc++ > > > > testsuite it fails due to lots of these errors: > > > >=20 > > > > Excess errors: > > > > /usr/local/bin/ld: /tmp//ccev946q.o: relocation R_X86_64_32 against > > > > symbol `_ZTIN10__cxxabiv115__forced_unwindE@@CXXABI_1.3.2' can not = be > > > > used when making a PDE object; recompile with -fPIE > > > > /usr/local/bin/ld: failed to set dynamic section sizes: bad value > >=20 > > Hi Gerald and Jonathan! > >=20 > > I normally test every weekly GCC snapshots through the FreeBSD ports > > framework on Cirrus, so that all my tests are publicly accessible: > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc11-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc12-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc13-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc14-devel > >=20 > > And of course the cirrus configuration is public as well: > > https://github.com/lsalvadore/freebsd-ports/blob/lang/gcc11-devel/.cirr= us.yml >=20 >=20 > this isn't particularly helpful if you just try to build upstream GCC > for comparision with your own targets or to verify a patch of yours. > Having to go hunting for configs like this if you're not a regular > FreeBSD user is a no-no IMO. GCC trunk should either build out of the > box or the quirks be documented in install.texi. Otherwise, non-FreeBSD > developers will get frustrated and give up on the target, to the > detriment both of their patches and the platform. >=20 > Unfortunately, it's pretty common that targets keep necessary patches in > some ports collection of their own (usually a different one per target) > and neglect to submit them upstream. I totally agree with you: upstreaming patches is important! It is not only for the upstream project itself, but for the target as well: having patches sitting in a ports collection also requires more maintainance, they require to be kept up to date with the upstream progresses. Unfortunately, it is not always possible to upstream a patch. Sometimes, patches are too specific to a target to be suitable for upstream. For example, smaller projects might be interested in supporting only very popular platforms and would not accept (or could not accept) the complexity of supporting a less known target. Hopefully this is not the case for GCC. Other times, developers do try to upstream a patch, but fail. This happened to myself in GCC too, when I was unable to get any attention to a patch I submitted, and could not do any better than keep the patch into the FreeBSD ports collection: https://gcc.gnu.org/pipermail/jit/2023q3/001642.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101491#c5 If you are able to help with this upstreaming, I would appreciate it a lot. Thanks. Cheers, Lorenzo Salvadore