From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 49A77385840C; Mon, 24 Oct 2022 11:29:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 49A77385840C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1666610998; bh=MTfLr0/YTbQ+hZ8NGHW97mWrholmB1s8bSZSqRg6GoE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TePxVQbldZsrihUu1h77K2vDkmCGILoCR5RgKrGgrXtc3XYEo3QMMYnbJ0mThRmuM RHsqlepdgiBfW+NktL6RrXNDMlOPlnFwnbBqoAXhJMlLQEQNqobQBcNz0OZt/jnwQ3 ak2v4dWm0IF2xlJXjbUYiX1Y1lXspbqZM06J8YBA= From: "costas.argyris at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/71850] @file should be used to cc1/cc1plus when @file is used Date: Mon, 24 Oct 2022 11:29:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: 6.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: costas.argyris at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D71850 Costas Argyris changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |costas.argyris at gmail do= t com --- Comment #6 from Costas Argyris --- A few things have changed since the last update: cc1 is no longer the problem, and it is not the subprocess that breaks for > 32k worth of command line arguments, but the bug has not gone away complete= ly because another subprocess still breaks after cc1, and that is the assembler (as) this time. At the time the bug was reported (version 6.1.0), the specs language did not have the %@{...} feature, and include paths were handled in cpp_unique_opti= ons as %{I*&F*} https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/gcc.c;h=3D7460f6af148= 969734c6cffeef870388355ef76cf;hb=3DHEAD#l1105 This was causing the include path arguments to get passed to cc1 verbatim, = i.e. without being stored in a temporary @file and that file being passed to cc1 instead (assuming a @file was given to gcc in the first place). Note that there existed ways to create temporary @files back then (as pointed out by Andrew), but they were not backed by the specs language itself through %@{.= ..}. Same for the assembler with %{I*} https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/gcc.c;h=3D7460f6af148= 969734c6cffeef870388355ef76cf;hb=3DHEAD#l1151 but it never got to that point because it was crashing earlier in cc1 when = the include paths were more than 32k bytes. The %@{...} syntax didn't exist back then because it doesn't show up neithe= r in the source code above nor in the 6.1.0 doc https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Spec-Files.html and search = for %@, no hits Some time between then and now %@{...} was added in the specs language https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Spec-Files.html %@ has a hit now and is now being used for the linker -L flags https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1162 and preprocessor include paths -I https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1238 The latter silently fixed the problem with cc1 because it now takes a tempo= rary file instead of the raw include paths (assuming a @file was given to gcc to begin with). But now we just hit the same problem with the assembler, because that one did not get updated to use %@{I*} and still uses %{I*} https://github.com/gcc-mirror/gcc/blob/releases/gcc-12/gcc/gcc.cc#L1294 So right now it is 'as' that is breaking due to the 32k limit on Windows, n= ot 'cc1'. Simply adding the @ symbol for the include args in asm_options fi= xes the issue. See the experiments below for more details. $ gcc --version gcc.exe (Rev4, Built by MSYS2 project) 12.2.0 sample response file with > 32k worth of include paths $ head -n3 rsp -I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkl= jfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKH= SDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh -I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkl= jfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKH= SDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh -I/akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkl= jfhsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKH= SDKJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh $ wc --chars rsp 37914 rsp $ gcc -v @rsp src.c ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/cc1.exe -quiet -v @C:\msys64\tmp\ccHiOua0 -D_REENTRANT src.c -quiet -dumpdir a- -dumpbase src= .c -dumpbase-ext .c -mtune=3Dgeneric -march=3Dx86-64 -version -o C:\msys64\tmp\ccsGuieQ.s ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-= mingw32/bin/as.exe -v -I /akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljf= hsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSD= KJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh -I /akjdhaskjdhfskjdfhakjsdhfkjlsahdfkjashdfasdkjfsadfasdkfjhsdakfjhds/asdkljf= hsadkjfhaskjdfhkjasdhfkjashdfkjashfsdklafhdskjfhjkfhskjfhsakdjfh/LJHFDJKHSD= KJFHASKDJdkjfghskdjfhgksdjfg/fgsdklfjghskdjfhgdksjfghdskjfgh -I -o C:\msys64\tmp\ccy7bVd1.o C:\msys64\tmp\ccsGuieQ.s gcc.exe: fatal error: cannot execute 'C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64= -mingw32/bin/as.exe': CreateProcess: No such file or directory compilation terminated. cc1.exe is OK because it takes a temporary @file, but as.exe takes the incl= ude paths so it breaks. Confirm this by observing how include args are handl= ed in the two subprocesses. $ gcc -dumpspecs | grep "{I" -C1 *asm_options: %{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*} %(asm_debug_option) %{gz|gz=3Dzlib-gnu:--compress-debug-sections} %{gz=3Dnone:--nocompress-debug-sections} %{gz=3Dzlib:%e-gz=3Dzlib is not su= pported in this configuration} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} -- *cpp_unique_options: %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %@{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{Mmodules} %{Mno-modules} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{%:debug-level-gt(2):-dD} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %= {H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}} create a custom specs_file that just adds @ for the assembler include paths $ cat specs_file *asm_options: %{-target-help:%:print-asm-header()} %{v} %{w:-W} %@{I*} %(asm_debug_option) %{gz|gz=3Dzlib-gnu:--compress-debug-sections} %{gz=3Dnone:--nocompress-debug-sections} %{gz=3Dzlib:%e-gz=3Dzlib is not su= pported in this configuration} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} use it to override the built-in asm_options and the build succeeds $ gcc -v @rsp src.c -specs=3Dspecs_file ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/cc1.exe -quiet -v @C:\msys64\tmp\cczj5Mkl -D_REENTRANT src.c -quiet -dumpdir a- -dumpbase src= .c -dumpbase-ext .c -mtune=3Dgeneric -march=3Dx86-64 -version -o C:\msys64\tmp\cckwORzw.s ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-= mingw32/bin/as.exe -v @C:\msys64\tmp\ccDFfiec -o C:\msys64\tmp\ccQzY8VR.o C:\msys64\tmp\cckwOR= zw.s ... ... ... no errors Proposed fix: In the driver gcc.cc, asm_options string, change %{I*} to %@{= I*} and then we no longer have to pass a custom specs file to avoid the error.= =20=20=20 After making the change in gcc.cc and rebuilding gcc: $ gcc -v @rsp src.c ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/cc1.exe -quiet -v @C:\msys64\tmp\ccUzV01R -D_REENTRANT src.c -quiet -dumpdir a- -dumpbase src= .c -dumpbase-ext .c -mtune=3Dgeneric -march=3Dx86-64 -version -o C:\msys64\tmp\cckn0YWz.s ... ... ... C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-= mingw32/bin/as.exe -v @C:\msys64\tmp\cce7PpKJ -o C:\msys64\tmp\ccGWfEIT.o C:\msys64\tmp\cckn0Y= Wz.s ... ... ... no errors $ gcc -dumpspecs | grep "{I" -C1 *asm_options: %{-target-help:%:print-asm-header()} %{v} %{w:-W} %@{I*} %(asm_debug_option) %{gz|gz=3Dzlib-gnu:--compress-debug-sections} %{gz=3Dnone:--nocompress-debug-sections} %{gz=3Dzlib:%e-gz=3Dzlib is not su= pported in this configuration} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} -- *cpp_unique_options: %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %@{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{Mmodules} %{Mno-modules} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{%:debug-level-gt(2):-dD} %{!iplugindir*:%{fplugin*:%:find-plugindir()}} %= {H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}} This fix doesn't prevent all cases of exceeding the 32k limit on Windows by using a @file. It only handles the include paths passed with -I.=20=20=20 Therefore, it is still possible to exceed it using other arguments than -I.= =20=20=20 However, I think -I is by far the most likely candidate to exceed the limit, and the one mentioned by the original poster.=