Bug 79266 - excessive compile time for large array of STRING_CST (-O1)
Summary: excessive compile time for large array of STRING_CST (-O1)
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 6.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
Depends on:
Blocks:
 
Reported: 2017-01-28 19:50 UTC by Josh Triplett
Modified: 2025-09-18 06:41 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2025-09-18 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Triplett 2017-01-28 19:50:51 UTC 
Consider the following test case:

int main(int argc, char *argv[]) {
    char *array[] = {
#include "num_array.h"
        argv[0],
    };
    int sum = 0;
    for (int i = 0; i < sizeof(array)/sizeof(*array); i++) {
        sum += __builtin_strlen(array[i]);
    }
    return sum;
}

Where num_array.h gets generated as follows:

seq 1 250000 | sed 's/.*/"&",/' > num_array.h

When compiled without optimization, it compiles without issue:

/tmp$ time gcc test.c -o test

real	0m6.563s
user	0m6.288s
sys	0m0.264s
/tmp$ ./test

However, turning on even -O1 causes gcc to run for a long time with no signs of stopping.
Comment 1 Josh Triplett 2017-01-28 20:02:53 UTC 
Following up: it looks like gcc -O1 does eventually complete, after several minutes.  -O3 is still running.
Comment 2 Drea Pinski 2017-01-28 20:15:16 UTC 
There might be a dup of this bug just filed a few days ago and that was marked as a dup too.
Comment 3 Richard Biener 2017-01-30 11:31:47 UTC 
actually a dup would be likely PR12245 though that's for static arrays.  The dup was for C++ code btw, PR56671 which is about std::bitset<>, a more simple to solve issue.
Comment 4 Drea Pinski 2025-09-18 06:39:43 UTC 
Looks unrelated to PR 12245.

The gimplifier from:
char * array[250001] = {(char *) "1", (char *) "2", (char *) "3", (char *) "4", (char *) "5", (char *) "6", (char *) "7", (char *) "8", (char *) "9", (char *) "10", (char *) "11", (char *) "12", (char *) "13", (char *) "14", (char *) "15", (char *) "16", (char *) "17", (char *) "18", (char *) "19", (char *) "20", (char *) "21", (char *) "22", (char *) "23", (char *) "24", (char *) "25", (char *) "26", (char *) "27", (char *) "28", (char *) "29", (char *) "30", (char *) "31", (char *) "32", (char *) "33", (char *) "34", (char *) "35", (char *) "36", (char *) "37", (char *) "38", (char *) "39", (char *) "40", (char *) "41", (char *) "42", (char *) "43", (char *) "44", (char *) "45", (char *) "46", (char *) "47", (char *) "48", (char *) "49", (char *) "50", (char *) "51", (char *) "52", (char *) "53", (char *) "54", (char *) "55", (char *) "56", (char *) "57", (char *) "58", (char *) "59", (char *) "60", (char *) "61", (char *) "62", (char *) "63", (char *) "64", (char *) "65", (char *) "66", (char *) "67", (char *) "68",

produces:
    try
      {
        array[0] = "1";
        array[1] = "2";
        array[2] = "3";
        array[3] = "4";
        array[4] = "5";
...

Instead of one big array which it copies from originally.

And then aliasing analysis goes down hill.
Comment 5 Drea Pinski 2025-09-18 06:41:36 UTC 
Note changing the array to `const char *` still does not fix the issue.