https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> E.g. on 122 valgrind says:
> ==21905== Invalid free() / delete / delete[] / realloc()
> ==21905== at 0x484B224: operator delete(void*) (vg_replace_malloc.c:576)
> ==21905== by 0x11BB3:
> path_expression_grammar<__gnu_cxx::__normal_iterator<char const*,
> std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > > >::path_expression_grammar() (in /tmp/rh1422456.122)
> ==21905== Address 0xbd8fd048 is on thread 1's stack
>
> Looking at tree dumps from PTRS_COMPARE_UNEQUAL=10000 (works) and
> PTRS_COMPARE_UNEQUAL=122 (calls free on invalid arg), I see the first change
> in *.fre1 in path_expression_grammar<Iterator>::path_expression_grammar()
> function,
> MEM[(struct &)this_10(D) + 56] ={v} {CLOBBER};
> MEM[(struct function_base *)this_10(D) + 56B].vtable = 0B;
> _122 = MEM[(char * *)&D.552047];
> - if (&D.552047.D.20672._M_local_buf != _122)
> - goto <bb 9>;
> - else
> - goto <bb 10>;
> -
> - <bb 9>:
> operator delete (_122);
> -
> - <bb 10>:
> MEM[(struct &)&D.552047] ={v} {CLOBBER};
> D.552047 ={v} {CLOBBER};
> D.552048 ={v} {CLOBBER};
> _29 = &this_10(D)->attr;
> and
> @@ -12334,15 +12330,7 @@ path_expression_grammar<Iterator>::path_
>
> <L4>:
> _140 = MEM[(char * *)&D.552047];
> - if (&D.552047.D.20672._M_local_buf != _140)
> - goto <bb 27>;
> - else
> - goto <bb 28>;
> -
> - <bb 27>:
> operator delete (_140);
> -
> - <bb 28>:
> MEM[(struct &)&D.552047] ={v} {CLOBBER};
> D.552047 ={v} {CLOBBER};
> resx 7
>
> (all other changes are just in bb numbers, as some bbs have been removed in
> the latter case).
> No idea what to figure out from this though, it just removes some operator
> delete calls (free), but that shouldn't cause free being called on invalid,
> worst case just memory leak.
It more looks like it will now call delete on _140 where it might have not
(if equal to &..._M_local_buf). This smells like a PTA issue and the
question is why D.552047 is thought to not point to
D.552047.D.20672._M_local_buf.
I'm trying to reproduce the above with a cross.
