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

[sagimor6 at gmail dot com via Gcc-bugs]

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

[sagimor6 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sagi Mor  ---
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 via Gcc-bugs]

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

--- Comment #4 from Sagi Mor  ---
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

[sagimor6 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Sagi Mor  ---
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 via Gcc-bugs]

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

--- Comment #7 from Sagi Mor  ---
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).