commit: 9f776b2cbc66523f9c3ca137661dfad4ea68a6c6 Author: Sam James <sam <AT> gentoo <DOT> org> AuthorDate: Mon Mar 9 11:51:00 2026 +0000 Commit: Sam James <sam <AT> gentoo <DOT> org> CommitDate: Mon Mar 9 11:51:00 2026 +0000 URL: https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=9f776b2c
16.0.0: drop upstream patch Signed-off-by: Sam James <sam <AT> gentoo.org> 16.0.0/gentoo/88_all_PR124291-firefox.patch | 103 ---------------------------- 16.0.0/gentoo/README.history | 4 ++ 2 files changed, 4 insertions(+), 103 deletions(-) diff --git a/16.0.0/gentoo/88_all_PR124291-firefox.patch b/16.0.0/gentoo/88_all_PR124291-firefox.patch deleted file mode 100644 index f4a7c8c..0000000 --- a/16.0.0/gentoo/88_all_PR124291-firefox.patch +++ /dev/null @@ -1,103 +0,0 @@ -From 82ef5f5e7d240747cad2eb697f97b95323f76c74 Mon Sep 17 00:00:00 2001 -Message-ID: <82ef5f5e7d240747cad2eb697f97b95323f76c74.1772799281.git....@gentoo.org> -From: Martin Jambor <[email protected]> -Date: Fri, 6 Mar 2026 13:09:01 +0100 -Subject: [PATCH] ipa-cp: Allow more precise contexts in the verifier - (PR124291) - -Hi, - -similarly to PR123629, the issue again stems from that when propagating -polymorphic contexts, when there are no known "values" in the corresponding -lattice of the caller we use just the information on the edge and when -there are some we combine them with the information, and from the fact that -we iterate the propagation in strongly connected components of the call -graph (SCCs). - -In the first iteration over such SCC, we process the edge from -unmark/1097720 to onChild/1097719 before we determined the lattices of the -caller. In the second iteration, we already know what context there will -be in the first unmarks's parameter and so can add a more precise value to -the corresponding lattice of onChild. Because we always add values to the -lattices and never "improve" them, we get two values for the call. - -In PR123629, that actually described reality well because the caller's -lattice had the variable flag set, without cloning the caller we could not -assume we could use the caller's lattice value and so both values were -possible (and in fact both cases happened, the problem was that their meet -failed). - -In this case however, one could argue that the lattices contain wrong info -or at least information that is misleading because the caller's lattice -contains just that single "constant" and the variable flag is not set. We -know that regardless of cloning decisions for the caller the more precise -derived value will be the case. And indeed since I changed the cloning -code to re-gather all constants for the given set of callers, that code -arrives at the more precise context. For the record they only differ in -the fact that the more precise one has the dynamic flag cleared. - -I have thought about how to fix up the lattices in one way or another but -so far it has always turned ugly. Therefore this patch simply changes the -verification to simply allow this situation because even though the final -result is just a bit more precise than what was expected, it is however -correct. There will not be any attempt to clone for the more precise -context because all the call graph edges will have been redirected away. -The only "issue" is that the less precise contexts take up place in the -lattice, which has a limited length. That should not be a problem in -practice. - -I do not have a simple testcase, the issue was discovered by Sam when -building Firefox with both LTO and PGO. However Sam has reported in -Bugzilla that with this patch the build succeeds. Needless to say, I -have bootstrapped, tested and LTOprofieldbootstrapped the patch. - -OK for master? - -Thanks, - -Martin - -gcc/ChangeLog: - -2026-03-06 Martin Jambor <[email protected]> - -PR ipa/124291 - * ipa-cp.cc (ipcp_val_replacement_ok_p): Allow more precise - contexts that what the clone was originally intended for. ---- - gcc/ipa-cp.cc | 16 ++++++++++++---- - 1 file changed, 12 insertions(+), 4 deletions(-) - -diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc -index b4e01a92344e..4765ef972b9d 100644 ---- a/gcc/ipa-cp.cc -+++ b/gcc/ipa-cp.cc -@@ -5920,11 +5920,19 @@ ipcp_val_replacement_ok_p (vec<tree> &, - int index, HOST_WIDE_INT offset, - ipa_polymorphic_call_context value) - { -- if (offset != -1) -+ if (offset != -1 -+ || known_contexts.length () <= (unsigned) index -+ || known_contexts[index].useless_p ()) - return false; -- return (known_contexts.length () > (unsigned) index -- && !known_contexts[index].useless_p () -- && known_contexts[index].equal_to (value)); -+ -+ if (known_contexts[index].equal_to (value)) -+ return true; -+ -+ /* In some corner cases, the final gathering of contexts can figure out that -+ the available context is actually more precise than what we wanted to -+ clone for. Allow it. */ -+ value.combine_with (known_contexts[index]); -+ return known_contexts[index].equal_to (value); - } - - /* Decide whether to create a special version of NODE for value VAL of - -base-commit: e1077ad5753148892871fa146f3948b55c46f7e3 --- -2.53.0 - diff --git a/16.0.0/gentoo/README.history b/16.0.0/gentoo/README.history index 2c6d173..bb35105 100644 --- a/16.0.0/gentoo/README.history +++ b/16.0.0/gentoo/README.history @@ -1,3 +1,7 @@ +40 ???? + + - 88_all_PR124291-firefox.patch + 39 9 March 2026 - 85_all_PR120987-ipa-modref-typo.patch
