[Bug driver/108328] New: gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[Bug driver/108328] New: gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

            Bug ID: 108328
           Summary: gcc --help -v doesn't work correctly in some
                    circumstances in gcc>=10
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sagimor6 at gmail dot com
  Target Milestone: ---

Created attachment 54210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54210&action=edit
patch to fix the bug

works:
gcc --help -v 2>/dev/null | grep ffunction-sections

(prints the ffunction-section description)

doesn't work:
gcc -Wl,--some-flag --help -v 2>/dev/null | grep ffunction-sections

(nothing is printed)
I am sure that this behavior is incorrect.

also (but maybe less important):
gcc a.c a.c a.c a.c --help -v 2>/dev/null | grep ffunction-sections

this prints the help 4 times (as many times as there are input files).
I am also sure that this behavior is incorrect. 

Some programs depend on --help -v to work, for example python. python checks if
fwrapv is supported with the mechanism. buildroot uses something called
toolchain-wrapper to add default flags to gcc when you call it, if you would
check the bootlin compilers in aarch64 they add -Wl,-z,relro by default. So, if
you were to compile python with a bootlin compiler with gcc>=10 it will not
compile with all the correct flags (no fwrapv).
This is just one example (this is where I noticed the bug).


The bug was introduced in the following commit:
https://github.com/gcc-mirror/gcc/commit/2dcfc8722b6146e479039a2f8994050c772b25e6
(commit 2dcfc8722b6146e479039a2f8994050c772b25e6)

So the bug only exists in gcc>=10, and doesn't in gcc<=9.

I created a patch to revert a small part of this commit (will send to the gcc
patches mailing list as well). I tested the patch.

One of the reasons I am sure this is a bug is because of the comment above the
if statement: "Ensure we only invoke each subprocess once.", so the help should
be printed once and only once.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Considering -fwrapv has been there since GCC 3.4.0, I think python should just
change how their configuring.
-fwrapv was added in r0-50210-g4fa26a60791ec3 .

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this behavior is correctly documented too:
If the -v option is also specified then --help is also passed on to the various
processes invoked by gcc, so that they can display the command-line options
they accept. 

With -Wl,x you only invoke collect2(ld).

That is how it has been documented too.

I think just python configure is broken.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #3 from Sagi Mor <sagimor6 at gmail dot com> ---
I agree that the python check is broken, but I do think that the current
behavior is incorrect. it doesn't make sense that for N input file, the help
will be displayed N times. and that linker options suppress the help message.

The comment in the code above the if statement ("Ensure we only invoke each
subprocess once.") shows this was the intention, and the commit I talked about
broke it without noticing.

The fact that this worked till gcc 9.x.x, and stopped working from gcc 10.x.x,
also says that this is not the intended behavior, in my opinion.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #4 from Sagi Mor <sagimor6 at gmail dot com> ---
created a bug report on buildroot as a workaround for the time being:

https://bugs.busybox.net/show_bug.cgi?id=15231

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So basically from what I understand is buildroot is doing this so they can
hardcode supporting only 4k pages. THIS IS BROKEN. Someone could build a kernel
and try to use a buildroot built sysroot and it will break ...

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #6 from Sagi Mor <sagimor6 at gmail dot com> ---
Well, this is only for aarch64 and arc, and they do compile the kernel in
buildroot, so it seems to work? (never checked myself)
By the way, they solve the -Wl,z,relro for kernel/uboot compilation by checking
if -D__KERNEL__ or -D__UBOOT__ was specified and then not adding the link flag,
which is an eye-opener for me.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328

--- Comment #7 from Sagi Mor <sagimor6 at gmail dot com> ---
Ok, now I understand what you said about the kernel and sysroot.
Yes, it is weird. (non buildroot kernel compiled with 64k pages, buildroot
sysroot with 4k max).