[Bug driver/81519] New: Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

daniel.santos at pobox dot com gcc-bugzilla@gcc.gnu.org
Sat Jul 22 19:43:00 GMT 2017


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

            Bug ID: 81519
           Summary: Enhancement: Add --help=target-distcc or similar to
                    dump clean, optimal CFLAGS without using -march=native
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: daniel.santos at pobox dot com
  Target Milestone: ---

To be clear, there is a working solution and that is to run a command such as
this:

gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | perl
-pe 's/^.* - //g;'

The problem is that it is very verbose and redundant.  You can filter out the
-mno-* flags, but I'm not certain that that is always correct and still leaves
many more -m<extention> flags.  Ideally, a command such as `gcc -Q -x c
-march=native --help=target-distcc' would emit something like

CFLAGS="-march=sandybridge --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=sandybridge"

In addition to the above, the output should contain any -m<extension> and
-mno-<extension> flags for each that actually differ from the arch and not
include extensions that are already included in another extension.

Calculating this from a script would actually be possible if bug #39851 were
fixed, but there is currently no (that I am aware of) way to get an output of
extensions each arch consists of.  These extensions are listed in invoke.texi
by marketing name, but this would still be a parsing challenge and is subject
to human error since it isn't parsed from the backend code.

Alternatively, I presume that cleaning up the driver code to omit redundant
options could result in the first example being sufficient, but I don't
understand the implications of that and I suspect would likely break other
things.


More information about the Gcc-bugs mailing list