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

2023-12-17 Thread uecker at gcc dot gnu.org via Gcc-bugs 
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.

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

2023-02-18 Thread muecker at gwdg dot de via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #5 from Martin Uecker  ---

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

2021-11-01 Thread gabravier at gmail dot com via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

--- Comment #4 from Gabriel Ravier  ---
(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

2021-10-31 Thread hp at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  ---
(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

2021-10-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
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

2021-10-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

--- Comment #1 from Andrew Pinski  ---
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.