https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > I'm not sure a target specific option is the way to go here, the only > difference is that nvptx spends all the time on this (adjusted) testcase at > compile time (and eats all disk space there too), while on x86_64 it is at > assembly time. > gcc -O2 -c -o /tmp/1.o /tmp/1.c > /tmp/ccUN9rYB.s: Assembler messages: > /tmp/ccUN9rYB.s: Fatal error: can't fill 256 bytes in section .data of > /tmp/1.o: 'No space left on device' > In real-world people will only compile code that is useful for something, > and we should honor there the no hardcoded limits unless really necessary > rule, some users may need 20GB initializers some day (sure, on most PTX > decides it wouldn't likely fit, but that can be diagnosed later). > For the error recovery, it is ok to throw away the initializers if it > doesn't result in further diagnostics, but otherwise, let's let users do > what they want > if they have time and disk space for that. I guess we can set the limit to the max by default, and then run the testsuite with the limit set to something more reasonable.
