Hi Richi,
On Wed, Sep 20 2023, Richard Biener wrote:
> The following turns MAX_NUM_CHAINS and MAX_CHAIN_LEN to params which
> allows to experiment with raising them. For the testcase in PR111489
> raising MAX_CHAIN_LEN from 5 to 8 avoids the bogus diagnostics
> at -O2, at -O3 we need a MAX_CHAIN_LEN of 6.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
> PR tree-optimization/111489
> * doc/invoke.texi (--param uninit-max-chain-len): Document.
> (--param uninit-max-num-chains): Likewise.
> * params.def (-param=uninit-max-chain-len=): New.
> (-param=uninit-max-num-chains=): Likewise.
> * gimple-predicate-analysis.cc (MAX_NUM_CHAINS): Define to
> param_uninit_max_num_chains.
> (MAX_CHAIN_LEN): Define to param_uninit_max_chain_len.
> (uninit_analysis::init_use_preds): Avoid VLA.
> (uninit_analysis::init_from_phi_def): Likewise.
> (compute_control_dep_chain): Avoid using MAX_CHAIN_LEN in
> template parameter.
our test attempting to detect that LTO_minor_version should have been
bumped but wasn't is failing and eye-balling backports to the gcc-13
branch, this looks like a likely culprit? Unless I am mistaken, params
are streamed and therefore they alter the LTO format?
If so, I'd like to propose the obvious fix, OK for gcc-13 (after some
testing)?
Thanks,
Martin
[PATCH] Bump LTO_minor_version
I believe r13-8039-g06ee3438a4fcf9 has changed LTO format and
therefore we should bump the minor version of the GCC 13 LTO format.
gcc/ChangeLog:
2023-11-20 Martin Jambor <mjam...@suse.cz>
* lto-streamer.h (LTO_minor_version): Bump.
---
gcc/lto-streamer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index fc7133d07ba..75cebcd02d3 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -122,7 +122,7 @@ along with GCC; see the file COPYING3. If not see
form followed by the data for the string. */
#define LTO_major_version GCC_major_version
-#define LTO_minor_version 0
+#define LTO_minor_version 1
typedef unsigned char lto_decl_flags_t;
--
2.42.0
