https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
--- Comment #6 from Dimitri Gorokhovik <dimitri.gorokhovik at free dot fr> ---
I bisected this issue to the commit:
commit 35a952ba70028b50fbd2fd19f7dc91f2da45371e
Author: Martin Jambor <mjam...@suse.cz>
Date: Tue Jun 13 13:34:51 2017 +0200
[PR80803 1/2] Streamline SRA access enqueuing
2017-06-13 Martin Jambor <mjam...@suse.cz>
* tree-sra.c (add_access_to_work_queue): Only enqueue accesses
that have a first_link.
(sort_and_splice_var_accesses): Do not check first_link before
enquing.
(subtree_mark_written_and_enqueue): Likewise.
(propagate_all_subaccesses): Likewise and do not stop at first
parent with a first_link.
From-SVN: r249153
on the branch gcc-8 and on. (gcc-7.5.0 and clang-11 don't have the issue.
Adding 2/2 of the change doesn't help.)
So I have the following fragment of code:
template <unsigned N>
struct index : public std::array <unsigned char, N>
{
constexpr index () : std::array <unsigned char, N> {0} {};
constexpr bool can_be_incremented (tesselation_of_two_cubes const&);
};
...
struct iterator
{
tesselation_of_two_cubes const* me_;
index <number_of_dimensions> idx_;
bool reached_end_;
constexpr iterator (tesselation_of_two_cubes const& ts) noexcept
: me_ { &ts },
idx_ {},
>>>>>>>> reached_end_ { ! idx_.can_be_incremented (ts) } <<<<<<<<<<
eliminated
{};
...
If compiling as shown, SRA and subsequent passes make the line above go away
(replace by 'true' which shouldn't be). This is because the ctor for idx_ is
also eliminated, so idx_.can_be_incremented() probably considered reading from
uninitialised data by SRA.
If I change the layout of 'struct iterator', move the member 'idx_' above
'me_', or below 'reached_end_', the issue goes away.
Still struggling with producing small good code sample.
