gcc/11: apply upstream fix 103910 so openjdk builds

Adam Joseph · Adam Joseph · commit b83f032ffcbc · 2023-02-12T07:40:05.000-08:00
Our openjdk derivations fail to build with `-march=opteron` (via either `NIX_CFLAGS_COMPILE` or `hostPlatform.gcc.arch`). This was fixed upstream in gcc12 but not carried back to gcc11: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d243f4009d8071b734df16cd70f4c5d09a373769 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910 Since gcc11 is still nixpkgs' primary compiler, this PR cherry-picks the fix out of gcc12. Unfortunately since `-march=` can be added after the `gcc11` derivation is built we can't apply this patch conditionally (which we don't usually do anyways).
diff --git a/pkgs/development/compilers/gcc/11/default.nix b/pkgs/development/compilers/gcc/11/default.nix
@@ -82,7 +82,10 @@ let majorVersion = "11";
       ++ optional (stdenv.isDarwin && targetPlatform.isAvr) ./avr-gcc-11.3-darwin.patch
 
       # Obtain latest patch with ../update-mcfgthread-patches.sh
-      ++ optional (!crossStageStatic && targetPlatform.isMinGW && threadsCross.model == "mcf") ./Added-mcf-thread-model-support-from-mcfgthread.patch;
+      ++ optional (!crossStageStatic && targetPlatform.isMinGW && threadsCross.model == "mcf") ./Added-mcf-thread-model-support-from-mcfgthread.patch
+
+      # openjdk build fails without this on -march=opteron; is upstream in gcc12
+      ++ [ ./gcc-issue-103910.patch ];
 
     /* Cross-gcc settings (build == host != target) */
     crossMingw = targetPlatform != hostPlatform && targetPlatform.libc == "msvcrt";
diff --git a/pkgs/development/compilers/gcc/11/gcc-issue-103910.patch b/pkgs/development/compilers/gcc/11/gcc-issue-103910.patch
@@ -0,0 +1,41 @@
+From d243f4009d8071b734df16cd70f4c5d09a373769 Mon Sep 17 00:00:00 2001
+From: Andrew Pinski <apinski@marvell.com>
+Date: Wed, 5 Jan 2022 22:00:07 +0000
+Subject: [PATCH] Fix target/103910: missing GTY on x86_mfence causing PCH
+ usage to ICE
+
+With -O3 -march=opteron, a mfence builtin is added after the loop
+to say the nontemporal stores are no longer needed. This all good
+without precompiled headers as the function decl that is referneced
+by x86_mfence is referenced in another variable but with precompiled
+headers, x86_mfence is all messed up and the decl was GC'ed away.
+This fixes the problem by marking x86_mfence as GTY to save/restore
+during precompiled headers just like most other variables in
+the header file.
+
+Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
+
+gcc/ChangeLog:
+
+	PR target/103910
+	* config/i386/i386.h (x86_mfence): Mark with GTY.
+---
+ gcc/config/i386/i386.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
+index f027608eefa..3ac0f698ae2 100644
+--- a/gcc/config/i386/i386.h
++++ b/gcc/config/i386/i386.h
+@@ -486,7 +486,7 @@ extern unsigned char ix86_prefetch_sse;
+ 
+ /* Fence to use after loop using storent.  */
+ 
+-extern tree x86_mfence;
++extern GTY(()) tree x86_mfence;
+ #define FENCE_FOLLOWING_MOVNT x86_mfence
+ 
+ /* Once GDB has been enhanced to deal with functions without frame
+-- 
+2.31.1
+
