[Bug c/102939] New: Ridiculously long compilation times on (admittedly ridiculous) pointer declaration

[Bug c/102939] New: Ridiculously long compilation times on (admittedly ridiculous) pointer declaration

[gabravier at gmail dot com]

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

            Bug ID: 102939
           Summary: Ridiculously long compilation times on (admittedly
                    ridiculous) pointer declaration
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

#define PTR1 * * * * * * * * * *
#define PTR2 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1 PTR1
#define PTR3 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2 PTR2
#define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
#define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
#define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5

int PTR4 q3_var = 0;

This takes an entire second to compile for GCC, and which is absolutely
ridiculous compared to, for example, tcc and ack, which both compile this code
in under .01 seconds.

I've investigated a bit into what's going on myself and it looks like while
parsing, there's some `variably_modified_type_p` algorithm that's going haywire
and taking forever on this declaration. Is it some kind of O(n²) recursive
algorithm or something ? It seems rather quite odd, to be honest...

For comparison, compiling this as C++ takes just .04 seconds.

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So if you place the variable inside a function, then both the C and C++
front-end take a long time to compile ....

Maybe we should cache variably_modified_type_p somewhere.

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-26
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess the code in question could be invoked when the full declaration is
parsed and not for each level of indirection.

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

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

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Gabriel Ravier from comment #0)
...
> #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
> #define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
> #define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5
> 
> int PTR4 q3_var = 0;
...

Is the use of PTR4 instead of PTR6 or PTR5, intended to provoke comments such
as this one, or are there untold additional related observations?

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[gabravier at gmail dot com]

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

--- Comment #4 from Gabriel Ravier <gabravier at gmail dot com> ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Gabriel Ravier from comment #0)
> ...
> > #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
> > #define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
> > #define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5
> > 
> > int PTR4 q3_var = 0;
> ...
> 
> Is the use of PTR4 instead of PTR6 or PTR5, intended to provoke comments
> such as this one, or are there untold additional related observations?

It's just a leftover I forgot to remove from when I was first testing this
(with the bigger macros, which just had worse results).

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[muecker at gwdg dot de]

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

Martin Uecker <muecker at gwdg dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |muecker at gwdg dot de

--- Comment #5 from Martin Uecker <muecker at gwdg dot de> ---

The fix for PR108375 also addresses this issue:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=47821ba07a19b672d3cba351a03af2b122e02213

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[uecker at gcc dot gnu.org]

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

uecker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
                 CC|                            |uecker at gcc dot gnu.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from uecker at gcc dot gnu.org ---
Fixed on trunk.