GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
Dear GCC Developers,
I encountered an issue where GCC fails to compile when the total
command-line argument
size exceeds 128KB.
In contrast, Clang can handle the same compilation scenario without issues.
Is this a known limitation in GCC, and are there any workarounds or plans
to address this?
Would response files (e.g., @file) be recommended for cases like this?
I'm looking forward to hearing your thoughts.
Reproduction Steps:
1) echo 'int main() { return 0; }' > test.c
2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
3) gcc test.c $ARGS -o test
gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
execv: Argument list too long
compilation terminated.
However, clang can able to produce output.
Best Regards,
Geeta D
Re: GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
On Sun, Feb 2, 2025 at 8:31 PM Geeta Dora via Gcc-bugs
wrote:
>
> Dear GCC Developers,
>
> I encountered an issue where GCC fails to compile when the total
> command-line argument
> size exceeds 128KB.
>
> In contrast, Clang can handle the same compilation scenario without issues.
>
> Is this a known limitation in GCC, and are there any workarounds or plans
> to address this?
> Would response files (e.g., @file) be recommended for cases like this?
Yes a response file will solve this issue. The limit for command lines
is much smaller under windows and that is why they were done in the
first place to workaround the limitations there.
>
> I'm looking forward to hearing your thoughts.
>
> Reproduction Steps: (Applicable to all versions of gcc)
>
> 1) echo 'int main() { return 0; }' > test.c
> 2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
> 3) gcc test.c $ARGS -o test
>
> gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
> execv: Argument list too long
> compilation terminated.
>
> However, clang can able to produce output.
Well clang is not exactly a driver and links directly against the
front-ends so it does not need to call out to other programs*.
*) The exception is the linker so you will run into issues there if
you have a lot of files to link against.
Thanks,
Andrew Pinski
>
> Best Regards,
> Geeta D
Re: GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
Thank you. I wanted to mention that on Linux, even when using a response
file, we still encounter the same issue if the response file exceeds 128KB
in size.
Does this imply that GCC enforces a limit on individual command-line
arguments (including those in response files) such that no argument should
exceed 128KB?
Best Regards,
Geeta D
On Mon, Feb 3, 2025 at 10:08 AM Andrew Pinski wrote:
> On Sun, Feb 2, 2025 at 8:31 PM Geeta Dora via Gcc-bugs
> wrote:
> >
> > Dear GCC Developers,
> >
> > I encountered an issue where GCC fails to compile when the total
> > command-line argument
> > size exceeds 128KB.
> >
> > In contrast, Clang can handle the same compilation scenario without
> issues.
> >
> > Is this a known limitation in GCC, and are there any workarounds or plans
> > to address this?
> > Would response files (e.g., @file) be recommended for cases like this?
>
> Yes a response file will solve this issue. The limit for command lines
> is much smaller under windows and that is why they were done in the
> first place to workaround the limitations there.
>
> >
> > I'm looking forward to hearing your thoughts.
> >
> > Reproduction Steps: (Applicable to all versions of gcc)
> >
> > 1) echo 'int main() { return 0; }' > test.c
> > 2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
> > 3) gcc test.c $ARGS -o test
> >
> > gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
> > execv: Argument list too long
> > compilation terminated.
> >
> > However, clang can able to produce output.
>
> Well clang is not exactly a driver and links directly against the
> front-ends so it does not need to call out to other programs*.
>
> *) The exception is the linker so you will run into issues there if
> you have a lot of files to link against.
>
> Thanks,
> Andrew Pinski
>
> >
> > Best Regards,
> > Geeta D
>
Re: GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
Thank you so much. It helps. I apologize for adding other email lists.
I will make sure to handle this more effectively in future communications.
On Mon, Feb 3, 2025 at 10:36 AM Andrew Pinski wrote:
> On Sun, Feb 2, 2025 at 8:57 PM Geeta Dora
> wrote:
> >
> > Thank you. I wanted to mention that on Linux, even when using a
> response file, we still encounter the same issue if the response file
> exceeds 128KB in size.
> >
> > Does this imply that GCC enforces a limit on individual command-line
> arguments (including those in response files) such that no argument should
> exceed 128KB?
>
> There are some known issue with GCC not using response files in some
> cases where it should be.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 (COLLECT_GCC_OPTIONS).
>
> The problem is GCC sometimes unwraps the response file and then passes
> those options either via the command line or via an environment
> variable and there is a combined limit. GCC should be using response
> files instead of passing directly via command line/env variables but
> nobody has implemented that yet. There is a patch floating around
> trying to fix COLLECT_GCC_OPTIONS but it has not been approved and
> from what I remember reading the patch it was causing some testsuite
> regressions (which should be fixed, IIRC the testcase needs to be
> updated but I could be wrong).
>
> Thanks,
> Andrew Pinski
>
> PS cross posting between these 3 lists is not a good idea and
> gcc-bugs@ is for automated emails from bugzilla and not exactly looked
> at.
>
>
> >
> > Best Regards,
> > Geeta D
> >
> > On Mon, Feb 3, 2025 at 10:08 AM Andrew Pinski wrote:
> >>
> >> On Sun, Feb 2, 2025 at 8:31 PM Geeta Dora via Gcc-bugs
> >> wrote:
> >> >
> >> > Dear GCC Developers,
> >> >
> >> > I encountered an issue where GCC fails to compile when the total
> >> > command-line argument
> >> > size exceeds 128KB.
> >> >
> >> > In contrast, Clang can handle the same compilation scenario without
> issues.
> >> >
> >> > Is this a known limitation in GCC, and are there any workarounds or
> plans
> >> > to address this?
> >> > Would response files (e.g., @file) be recommended for cases like this?
> >>
> >> Yes a response file will solve this issue. The limit for command lines
> >> is much smaller under windows and that is why they were done in the
> >> first place to workaround the limitations there.
> >>
> >> >
> >> > I'm looking forward to hearing your thoughts.
> >> >
> >> > Reproduction Steps: (Applicable to all versions of gcc)
> >> >
> >> > 1) echo 'int main() { return 0; }' > test.c
> >> > 2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
> >> > 3) gcc test.c $ARGS -o test
> >> >
> >> > gcc: fatal error: cannot execute
> ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
> >> > execv: Argument list too long
> >> > compilation terminated.
> >> >
> >> > However, clang can able to produce output.
> >>
> >> Well clang is not exactly a driver and links directly against the
> >> front-ends so it does not need to call out to other programs*.
> >>
> >> *) The exception is the linker so you will run into issues there if
> >> you have a lot of files to link against.
> >>
> >> Thanks,
> >> Andrew Pinski
> >>
> >> >
> >> > Best Regards,
> >> > Geeta D
>
Patch held up in gcc-patches due to size
Hi, I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html to gcc-patches also, as normal, but got back an e-mail that it was too large. and that a moderator would look at it. Maybe the limits can be increased a bit, sometimes patches can be quite large, especially if they contain large test cases or a large number of generated files. (Does anybody actually look at the messages, as promised in the e-mail?= Best regards Thomas
gcc-15-20250202 is now available
Snapshot gcc-15-20250202 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20250202/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 969c30885558d092ad07c9c71dd54ea14f6096c6 You'll find: gcc-15-20250202.tar.xz Complete GCC SHA256=9b44115b98f04c1c69a219fae89d05dbb5819010e30c9000b7302aa06672c954 SHA1=4721883bfb6b37eb1f0b4dbfc29fbd4ee7997086 Diffs from 15-20250126 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
Dear GCC Developers,
I encountered an issue where GCC fails to compile when the total
command-line argument
size exceeds 128KB.
In contrast, Clang can handle the same compilation scenario without issues.
Is this a known limitation in GCC, and are there any workarounds or plans
to address this?
Would response files (e.g., @file) be recommended for cases like this?
I'm looking forward to hearing your thoughts.
Reproduction Steps: (Applicable to all versions of gcc)
1) echo 'int main() { return 0; }' > test.c
2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
3) gcc test.c $ARGS -o test
gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
execv: Argument list too long
compilation terminated.
However, clang can able to produce output.
Best Regards,
Geeta D
Re: GCC Fails to Compile When Command Line Argument Size Exceeds 128KB
On Sun, Feb 2, 2025 at 8:57 PM Geeta Dora
wrote:
>
> Thank you. I wanted to mention that on Linux, even when using a response
> file, we still encounter the same issue if the response file exceeds 128KB in
> size.
>
> Does this imply that GCC enforces a limit on individual command-line
> arguments (including those in response files) such that no argument should
> exceed 128KB?
There are some known issue with GCC not using response files in some
cases where it should be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 (COLLECT_GCC_OPTIONS).
The problem is GCC sometimes unwraps the response file and then passes
those options either via the command line or via an environment
variable and there is a combined limit. GCC should be using response
files instead of passing directly via command line/env variables but
nobody has implemented that yet. There is a patch floating around
trying to fix COLLECT_GCC_OPTIONS but it has not been approved and
from what I remember reading the patch it was causing some testsuite
regressions (which should be fixed, IIRC the testcase needs to be
updated but I could be wrong).
Thanks,
Andrew Pinski
PS cross posting between these 3 lists is not a good idea and
gcc-bugs@ is for automated emails from bugzilla and not exactly looked
at.
>
> Best Regards,
> Geeta D
>
> On Mon, Feb 3, 2025 at 10:08 AM Andrew Pinski wrote:
>>
>> On Sun, Feb 2, 2025 at 8:31 PM Geeta Dora via Gcc-bugs
>> wrote:
>> >
>> > Dear GCC Developers,
>> >
>> > I encountered an issue where GCC fails to compile when the total
>> > command-line argument
>> > size exceeds 128KB.
>> >
>> > In contrast, Clang can handle the same compilation scenario without issues.
>> >
>> > Is this a known limitation in GCC, and are there any workarounds or plans
>> > to address this?
>> > Would response files (e.g., @file) be recommended for cases like this?
>>
>> Yes a response file will solve this issue. The limit for command lines
>> is much smaller under windows and that is why they were done in the
>> first place to workaround the limitations there.
>>
>> >
>> > I'm looking forward to hearing your thoughts.
>> >
>> > Reproduction Steps: (Applicable to all versions of gcc)
>> >
>> > 1) echo 'int main() { return 0; }' > test.c
>> > 2) ARGS=$(perl -e 'print "-I/tmp " x 16384')
>> > 3) gcc test.c $ARGS -o test
>> >
>> > gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’:
>> > execv: Argument list too long
>> > compilation terminated.
>> >
>> > However, clang can able to produce output.
>>
>> Well clang is not exactly a driver and links directly against the
>> front-ends so it does not need to call out to other programs*.
>>
>> *) The exception is the linker so you will run into issues there if
>> you have a lot of files to link against.
>>
>> Thanks,
>> Andrew Pinski
>>
>> >
>> > Best Regards,
>> > Geeta D
