https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to be a FE bug.
Already in *.gimple bug with -fdump-tree-all-uid one can see:
__attribute__((fn spec (". ")))
void p ()
{
  static voidD.27 sD.4214 (void);
  struct array01_character(kind=1) yD.4238;
  static integer(kind=8)D.9 .yD.4216;
  static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
  bitsizetype D.4278;
  sizetype D.4279;

  try
    {
...
__attribute__((fn spec (". ")))
void s ()
{
  bitsizetype D.4285;
  sizetype .y.10D.4286;
  integer(kind=8)D.9 iftmp.14D.4287;

  {
    static integer(kind=8)D.9 .yD.4216;
    static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
    bitsizetype D.4278;
    sizetype D.4279;

That means that BLOCK_VARS of a BLOCK inside of p function contain
s var with DECL_UID 4214, its DECL_CHAIN is y with DECL_UID 4238 and
its DECL_CHAIN is .y with DECL_UID 4216.
But the same .y var with DECL_UID 4216 is also in BLOCK_VARS of another BLOCK
inside of s.  Vars in BLOCK_VARS are chained through DECL_CHAIN, aren't in some
vec or TREE_VEC etc., so can't be part of multiple chains.

Reply via email to