./xgcc -B ./ -frecord-gcc-switches -D_GNU_SOURCE -O2 a.c -S
gives me:
        .section        .GCC.command.line,"MS",@progbits,1
        .ascii  "-iprefix /usr/src/gcc/obj/gcc/../lib/gcc/x86_64-unknown-linu"
        .ascii  "x-gnu/4.3.0/"
        .zero   1
        .ascii  "-isystem ./include"
        .zero   1
        .ascii  "-isystem ./include-fixed"
        .zero   1
        .ascii  "-D_GNU_SOURCE a.c"
        .zero   1
        .ascii  "-mtune=generic"
        .zero   1
        .ascii  "-O2"
        .zero   1
        .ascii  "-frecord-gcc-switches"

The main issue I have with this is the separation of options into separate
strings (though, look above at "-D_GNU_SOURCE a.c" string to see it is not
done always anyway).  This means smaller .GNU.command.line section, sure, but
makes the section far less useful.  Because if you link shared library
or binary with many -frecord-gcc-switches compiled objects, all you can query
is e.g. was at least one of the input objects compiled with -O2, or whatever
other option.  On the other side, if you have one big string with all command
line options (but one that should not reference the source file name and IMNSHO
not even any of the -I/-iprefix/-isystem options, that's what .debug_line is
for and in this section where you no longer know which filename was it and
which directory was it in I can't see what it would be useful for), then you
can query whether each source was compiled with -fstack-protector or not, etc.
With the long strings you still can have the longer option strings from all
objects merged into just one string (if all sources were compiled with the same
options).
-frecord-gcc-switches among the saved options doesn't make sense either (if it
was not used, they wouldn't be recorded).  Not sure if we shouldn't try to do
any kind of sorting among unrelated non-positional options, it would certainly
be harded (but guess in *.opt we know everything we need), but perhaps would
result in better merging.  Say if you compile some sources with -O2
-fstack-protector and some with -fstack-protector -O2, if we do sorting it
could be merged, otherwise it can't.  E.g. -fstrict-aliasing
-fno-strict-aliasing can't be reordered.


-- 
           Summary: -frecord-gcc-switches issues
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998

Reply via email to