https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
> Created attachment 38225 [details]
> test.ii test case (g++ -O1 -fcompare-debug)
>
> (In reply to Jakub Jelinek from comment #1)
> > Without the testcase it is hard to guess.
>
> I now tried to compile LLVM with -fcompare-debug - and I guessed correctly,
> one of the files also fails there (lib/Support/CommandLine.cpp).
>
> I am not sure whether it is the same issue, but it is a debug miscompare.
> Contrary to my original file, it also fails when a .ii is generated with
> "-E"; additionally, it also fails already with -O1 and it reduced more
> readily (for my original example, it seemed to depend much more on the
> memory layout such that comment lines were kept).
>
> The somewhat reduced example is attached; it fails here (and hopefully
> elsewhere) using "g++ -O1 -fcompare-debug" with: "g++: error: test.ii:
> -fcompare-debug failure".
That looks like a different issue though, perhaps make_fancy_decl_name should
not add DECL_UID to the names, but just D.xxxx instead, either when
-fdump-final-insns= option is used only, or always?
E.g. if the FIELD_DECLs or VAR_DECLs etc. have no name and different DECL_UIDs,
they will then show up in -fdump-final-insns= dumps, which have means to
print xxxx instead of actual uids, but in the SSA fancy names doesn't know
there are any uids embedded in there.
That said, if the constexpr processing in case the cache has been emptied can
create new decls, then I generally don't see how the desirable same order of
uids for the same things could be ever guaranteed.
Consider constexpr handling of some function (which puts it into cache), that
creates DECL_UIDs 37, 38, 39. Then some further parsing is performed, and
DECL_UIDs 40, 41, 42 are created. Then we do constexpr handling for the same
function, if we find it in the cache, we don't generate new uids, otherwise, if
GC happens after DECL_UID 42 generation, we need to redo the constexpr handling
and create DECL_UIDs 43, 44, 45.
Now the important question is if these decls (VAR_DECLs, CONST_DECLs,
FIELD_DECLs, PARM_DECLs, RESULT_DECLs, FUNCTION_DECLs) can ever make it into
the IL or not. If they would be just temporaries during the constexpr
processing, perhaps we are fine if we fix up the tree-sra.c case, but the #c0
hints perhaps something different.
The Declarations used... list that #c0 differs on is sorted by DECL_UID.
