From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5235 invoked by alias); 5 Aug 2007 21:17:59 -0000 Received: (qmail 3282 invoked by uid 48); 5 Aug 2007 21:17:45 -0000 Date: Sun, 05 Aug 2007 21:17:00 -0000 Subject: [Bug other/32998] New: -frecord-gcc-switches issues X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00304.txt.bz2 ./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