On 27/09/2022 23.35, Alex Bennée wrote:
It seems the depth of path we need to support can vary depending on
the order of the init constructors getting called. It seems
--enable-lto shuffles things around just enough to push you over the
limit.
Signed-off-by: Alex Bennée
Fixes:
Il mar 27 set 2022, 23:35 Alex Bennée ha scritto:
> It seems the depth of path we need to
With s/path/stack/,
Acked-by: Paolo Bonzini
Paolo
support can vary depending on
the order of the init constructors getting called. It seems
> --enable-lto shuffles things around just enough to push
Oh, wait, this is not a path! This is the stack for a graph visit, and the
limit is not the maximum length of the path, but rather the number of nodes
in the graph.
In other words, QOS_PATH_MAX_ELEMENT_SIZE is being overloaded and using it
in qos_node_stack is wrong. The solution is to use a
Paolo Bonzini writes:
> What is an example of one such huge path? This would mean that LTO is
> changing the set of tests that are run, which is
> unexpected.
It does look like the LTO build runs more tests although its hard to
diff as the order if different:
➜ grep "list" without-lto | wc
What is an example of one such huge path? This would mean that LTO is
changing the set of tests that are run, which is unexpected.
Paolo
Il mar 27 set 2022, 23:35 Alex Bennée ha scritto:
> It seems the depth of path we need to support can vary depending on
> the order of the init constructors
It seems the depth of path we need to support can vary depending on
the order of the init constructors getting called. It seems
--enable-lto shuffles things around just enough to push you over the
limit.
Signed-off-by: Alex Bennée
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1186
---
