Re: git: ce45e3c376f4 - main - lang/gcc14-devel: Fix SIGBUS depending on CPUTYPE

On Wednesday, April 16th, 2025 at 15:21, Lorenzo Salvadore <salvadore@FreeBSD.org> wrote:

> 
> 
> The branch main has been updated by salvadore:
> 
> URL: https://cgit.FreeBSD.org/ports/commit/?id=ce45e3c376f4bd72ef6e12e0a3d9964ea217987e
> 
> commit ce45e3c376f4bd72ef6e12e0a3d9964ea217987e
> Author: Lorenzo Salvadore salvadore@FreeBSD.org

Sorry, I forgot to set the Author field.
Real author is Oleg Sidorkin <osidorkin@gmail.com>.

> AuthorDate: 2025-04-13 14:45:54 +0000
> Commit: Lorenzo Salvadore salvadore@FreeBSD.org
> 
> CommitDate: 2025-04-16 13:20:39 +0000
> 
> lang/gcc14-devel: Fix SIGBUS depending on CPUTYPE
> 
> Compiling GCC with some CPUTYPE values (e.g. broadwell) result in
> breaking some applications (e.g. math/octave, cad/freecad), sending
> a SIGBUS.
> 
> The issue is due to GCC generating instructions that require
> variables
> to be aligned in memory on certain CPUs. Our libthr does not have
> the
> required alignment so these CPUs fail to execute these instructions.
> 
> The patch disables the generation of such instructions.
> 
> PR: 285711
> Reported by: cracauer
> Tested by: cracauer, jbo
> ---
> lang/gcc14-devel/Makefile | 1 +
> lang/gcc14-devel/files/patch-libgcc_unwind.inc | 28 ++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
> 
> diff --git a/lang/gcc14-devel/Makefile b/lang/gcc14-devel/Makefile
> index 9eece018e0a9..96f4085d8d61 100644
> --- a/lang/gcc14-devel/Makefile
> +++ b/lang/gcc14-devel/Makefile
> @@ -1,5 +1,6 @@
> PORTNAME= gcc
> PORTVERSION= 14.2.1.s20250412
> +PORTREVISION= 1
> PORTEPOCH= 1
> CATEGORIES= lang
> MASTER_SITES= GCC/snapshots/${DIST_VERSION}
> diff --git a/lang/gcc14-devel/files/patch-libgcc_unwind.inc b/lang/gcc14-devel/files/patch-libgcc_unwind.inc
> new file mode 100644
> index 000000000000..42155a9ba48e
> --- /dev/null
> +++ b/lang/gcc14-devel/files/patch-libgcc_unwind.inc
> @@ -0,0 +1,28 @@
> +GCC generates instructions that require variables to be aligned in memory on
> +certain CPUs. Our libthr does not have the required alignment so these CPUs fail
> +to execute these instructions. The instructions generation is driven by CPUTYPE.
> +Some CPUs are fine to execute these instructions on unaligned data.
> +
> +This patch explicitly forbids GCC to generate instructions that require
> +alignment of the data.
> +
> +If the entire program is compiled by LLVM or GCC, there is no problem (with GCC
> +everything is aligned, with LLVM vmovdqa is not used to assign both variables
> +at once).
> +
> +Linux does not have libthr, so Linux is not affected. Moreover Linux is likely
> +to build everything with GCC.
> +
> +--- libgcc/unwind.inc.orig 2025-04-12 08:18:17 UTC
> ++++ libgcc/unwind.inc
> +@@ -212,8 +212,8 @@ _Unwind_ForcedUnwind (struct _Unwind_Exception *exc,
> + uw_init_context (&this_context);
> + cur_context = this_context;
> +
> +- exc->private_1 = (_Unwind_Ptr) stop;
> 
> +- exc->private_2 = (_Unwind_Ptr) stop_argument;
> 
> ++ __builtin_memcpy(&exc->private_1, &stop, sizeof(_Unwind_Ptr));
> 
> ++ __builtin_memcpy(&exc->private_2, &stop_argument, sizeof(_Unwind_Ptr));
> 
> +
> + code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
> + if (code != _URC_INSTALL_CONTEXT)