It would be Really Nice if the gcc and g++ compilers, when compiling for some ELF target (at least) would stick a copy of ALL of the compilation options used during the compile into an ELF .comment or .note section within the resulting .o file. I wish I had a nickle for every time I had a .o file, left over from some build I did a long long time ago (in a galaxy not far away) and I was stuck saying to myself ``I wish I knew what options this thing had been compiled with. I wonder if it was optimized.'' The ELF object file format provides a couple of obvious means (.command and .note sections) for recording this exact infor- mation into each .o file. And I don't think that it would be very hard to get the front-end gcc/g++ driver to pass ALL compilation options down to cc1 and/or cc1plus. They in turn could easily still the options into a suitable ELF section. Note that this would also allow for some potentially inter- esting types of retrospective automated analysis of .o files. Release: gcc-2.95.2
From: Phil Edwards <pedwards@disaster.jaj.com> To: rfg@monkeys.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 05:56:24 -0400 On Sat, Apr 28, 2001 at 08:36:49PM -0000, rfg@monkeys.com wrote: > And I don't think that it would > be very hard to get the front-end gcc/g++ driver to pass > ALL compilation options down to cc1 and/or cc1plus. We already do; see print_switch_values in toplev.c for an example usage. In verbose mode, almost all the switches are dumped to stderr; if -fverbose-asm is used, they are dumped as comments to the assembly file. I say "dumped" when they're actually formatted nicely. And I say "almost" all the switches because the language-specific ones can't be seen. (I tried cleaning this up once for this specific purpose, but it involved touching a lot of files, and nobody was interested.) > They > in turn could easily still the options into a suitable ELF > section. I can't see any obvious documentation of .note sections in the gas source, and I don't see .command mentioned at all. I wouldn't mind playing with this idea while waiting on compiles, if you can point me towards some usage docs. Phil -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 06:50:29 -0400 On Sun, Apr 29, 2001 at 11:56:01AM -0000, Joseph S. Myers wrote: > On 29 Apr 2001, Phil Edwards wrote: > > > I can't see any obvious documentation of .note sections in the gas source, > > and I don't see .command mentioned at all. I wouldn't mind playing with this > > idea while waiting on compiles, if you can point me towards some usage docs. > > .note is where GCC used to output the useless "01.01" strings for every > file. .commment is where it outputs the compiler version string. I think that's .ident, not .comment. (Was ".command" a typo for ".comment"?) > As with > the compiler version string, compilation options are useful information. I just implemented this, sort of. At least, it switches to the .note section, but then just spews text. What would the correct directive be at that point? .ascii? Um, there's a /lot/ of text produced from print_switch_values. This sounds like something we'd like to have on by default, but that's about fifteen lines of options. Phil -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 07:20:29 -0400 On Sun, Apr 29, 2001 at 01:26:53PM +0100, Joseph S. Myers wrote: > On 29 Apr 2001, Phil Edwards wrote: > > I think that's .ident, not .comment. (Was ".command" a typo for ".comment"?) > > .ident assembler directives put data in .comment. Duh... this is what happens when I post without sleep. > Since the original message mentioned both .comment and .command, I think > .command did mean .comment. Pity, a .command section would've been useful for this. -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 11:47:39 -0700 In message <20010429055624.A28542@disaster.jaj.com>, you wrote: >On Sat, Apr 28, 2001 at 08:36:49PM -0000, rfg@monkeys.com wrote: >> And I don't think that it would >> be very hard to get the front-end gcc/g++ driver to pass >> ALL compilation options down to cc1 and/or cc1plus. > >We already do... How convenient! >> They >> in turn could easily still the options into a suitable ELF >> section. > >I can't see any obvious documentation of .note sections in the gas source, >and I don't see .command mentioned at all. I wouldn't mind playing with this >idea while waiting on compiles, if you can point me towards some usage docs. My alopogies if my slippery fingers typed in `.command' when I intended to write `.comment'. For documentation of the intended usage and format of data in ELF .note and .comment sections, you will need to refer to the original AT&T docu- mentation of ELF. I know that documentation (in various non-modified and slightly modified forms) is available on the web in various places, because I found it on the web in several places when I went looking for it a couple of months ago. I'll find a URL or two for you if you need them. Just let me know. Stuff that is placed into ELF .note sections is supposed to obey a very well defined format. However stuff in .comment sections is more in the nature of just free-form text lines, I believe. I can't remember anymore. What gets put into a .note section is basically 100% implementation defined, but when I glanced again at the original AT&T documentation on ELF the other day, it appears to me that the contents of .note is supposed to be, in effect, a set of name/value pairs (vaguely reminicent of UNIX environment variables). The required ``structure'' of the .note section just tells you where and how to encode one of these name/value pairs, in general.
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: <gcc-gnats@gcc.gnu.org> Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 12:55:32 +0100 (BST) On 29 Apr 2001, Phil Edwards wrote: > I can't see any obvious documentation of .note sections in the gas source, > and I don't see .command mentioned at all. I wouldn't mind playing with this > idea while waiting on compiles, if you can point me towards some usage docs. .note is where GCC used to output the useless "01.01" strings for every file. .commment is where it outputs the compiler version string. As with the compiler version string, compilation options are useful information. -- Joseph S. Myers jsm28@cam.ac.uk
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: <gcc-gnats@gcc.gnu.org> Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 13:26:53 +0100 (BST) On 29 Apr 2001, Phil Edwards wrote: > > .note is where GCC used to output the useless "01.01" strings for every > > file. .commment is where it outputs the compiler version string. > > I think that's .ident, not .comment. (Was ".command" a typo for ".comment"?) .ident assembler directives put data in .comment. Since the original message mentioned both .comment and .command, I think .command did mean .comment. Use e.g. "objdump -s -j .comment <some-executable>" to see what's currently in these sections. -- Joseph S. Myers jsm28@cam.ac.uk
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Sun, 29 Apr 2001 21:41:04 -0400 On Sun, Apr 29, 2001 at 06:56:00PM -0000, Ronald F. Guilmette wrote: > My alopogies if my slippery fingers typed in `.command' when I intended > to write `.comment'. :-) > For documentation of the intended usage and format of data in ELF .note > and .comment sections, you will need to refer to the original AT&T docu- > mentation of ELF. [...] > but when I glanced again at the original AT&T documentation on ELF the other > day, it appears to me that the contents of .note is supposed to be, in > effect, a set of name/value pairs (vaguely reminicent of UNIX environment > variables). The required ``structure'' of the .note section just tells > you where and how to encode one of these name/value pairs, in general. Yep. Just before I left last night (er, this morning), I pulled up wotsit.org and grabbed the ELF 1.1 spec. Useful site, that. After some sleep, I've concluded that my original idea of using the print_switch_values routine might be stupid. I don't think people would like options passed: -iprefix -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D__GNUG__=3 -D_GNU_SOURCE -D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 options enabled: -fpeephole -ffunction-cse -fkeep-static-consts -fpcc-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec -fbranch-count-reg -fexceptions -fcommon -fgnu-linker -fargument-alias -fident -fmath-errno -ftrapping-math -m80387 -mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 showing up in their object files, for example. (Or do you?) The kicker is that the driver doesn't pass down the set of command-line options directly to the compiler. It does some translations on them, and then adds a bunch of defaults, and then passes /all/ of that down. See the "options passed" block above, for example; all of those are options to the compiler that the driver is inserting. If I had used -fomit-frame-pointer, for example, then that would be at the end of the list after the -D__*'s. (Side note: the "options enabled" block are everything that's on by default, as modified by the "options passed". If you really wanted to re-create the compilation environment for a particular file, you'd need to use all of those. The defaults might have changed.) The compiler does have available a save_argv and save_argc, but that's how the "options passed" block is constructed in the first place. We don't have any obvious way of distinguishing which options the user passed from the default ones added by the specs file. Phil -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 02:09:48 -0700 In message <20010429214104.A29946@disaster.jaj.com>, you wrote: >After some sleep, I've concluded that my original idea of using the >print_switch_values routine might be stupid. I don't think people would like > > options passed: -iprefix -D__GNUC__=3 -D__GNUC_MINOR__=1 > -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ > -D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED__=1 > -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ > -D__tune_pentiumpro__ -D__GNUG__=3 -D_GNU_SOURCE -D__DEPRECATED > -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 > options enabled: -fpeephole -ffunction-cse -fkeep-static-consts > -fpcc-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec > -fbranch-count-reg -fexceptions -fcommon -fgnu-linker -fargument-alias > -fident -fmath-errno -ftrapping-math -m80387 -mhard-float > -mno-soft-float -mieee-fp -mfp-ret-in-387 > >showing up in their object files, for example. (Or do you?) Yes, it would be perfectly OK to put that all into a .comment or .note section. Those sections DO NOT get loaded into main memory at run time, and if necessary, `strip' and be used to remove them after the .o is built. >The kicker is that the driver doesn't pass down the set of command-line >options directly to the compiler. It does some translations on them, >and then adds a bunch of defaults, and then passes /all/ of that down. That might still be OK. It's better than not having the info at all! >(Side note: the "options enabled" block are everything that's on by >default, as modified by the "options passed". If you really wanted to >re-create the compilation environment for a particular file, you'd need >to use all of those. The defaults might have changed.) Good point. >The compiler does have available a save_argv and save_argc, but that's how >the "options passed" block is constructed in the first place. We don't >have any obvious way of distinguishing which options the user passed from >the default ones added by the specs file. I don't believe that it is important to draw that distinction anyway.
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 04:07:40 -0400 On Mon, Apr 30, 2001 at 09:16:00AM -0000, Ronald F. Guilmette wrote: > >After some sleep, I've concluded that my original idea of using the > >print_switch_values routine might be stupid. I don't think people would like [...] > >showing up in their object files, for example. (Or do you?) > > Yes, it would be perfectly OK to put that all into a .comment or .note > section. Those sections DO NOT get loaded into main memory at run time, > and if necessary, `strip' and be used to remove them after the .o is built. I know they don't have SHF_ALLOC set, I was concerned with diskspace. Which is probably cheap enough to not be worth caring about, on further reflection. For that matter, I had planned to have this controlled by a flag, on by default. People really low on space can always use the flag. (something like -fno-note-options) -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 09:42:02 -0700 In message <20010430040740.A31126@disaster.jaj.com>, you wrote: >On Mon, Apr 30, 2001 at 09:16:00AM -0000, Ronald F. Guilmette wrote: >> >After some sleep, I've concluded that my original idea of using the >> >print_switch_values routine might be stupid. I don't think people would l >ike >[...] >> >showing up in their object files, for example. (Or do you?) >> >> Yes, it would be perfectly OK to put that all into a .comment or .note >> section. Those sections DO NOT get loaded into main memory at run time, >> and if necessary, `strip' and be used to remove them after the .o is built. > >I know they don't have SHF_ALLOC set, I was concerned with diskspace. >Which is probably cheap enough to not be worth caring about, on further >reflection. Correct. >For that matter, I had planned to have this controlled by a flag, >on by default. People really low on space can always use the flag. >(something like -fno-note-options) I don't see that as either necessary or useful. As I noted, they can always run `strip' after the compile, if the extra info really bothers them.
From: "Ronald F. Guilmette" <rfg@monkeys.com> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: gcc-gnats@gcc.gnu.org, pedwards@disaster.jaj.com Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 10:21:12 -0700 In message <Pine.LNX.4.32.0104301813300.17624-100000@kern.srcf.societies.cam.ac .uk>, you wrote: >On 30 Apr 2001, Ronald F. Guilmette wrote: > >> As I noted, they can always run `strip' after the compile, if the extra >> info really bothers them. > >But does "strip" (without other options) remove these sections? It >doesn't (binutils 2.11.90.0.6) remove .comment and .note; for that reason, >Debian has modified "install -s" to pass --remove-section=.comment >--remove-section=.note to strip. a) It's no big deal to also supply --remove-section=.comment on the strip command line. b) In practice, nobody will give a damn about the presence or absense of this extra information anyway.
From: "Ronald F. Guilmette" <rfg@monkeys.com> To: Phil Edwards <pedwards@disaster.jaj.com> Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 17:29:44 -0700 In message <20010430184754.A1637@disaster.jaj.com>, you wrote: >On Mon, Apr 30, 2001 at 10:21:12AM -0700, Ronald F. Guilmette wrote: >> >But does "strip" (without other options) remove these sections? It >> >doesn't (binutils 2.11.90.0.6) remove .comment and .note; for that reason, >> >Debian has modified "install -s" to pass --remove-section=.comment >> >--remove-section=.note to strip. >> >> a) It's no big deal to also supply --remove-section=.comment on the >> strip command line. > >Other implementations of strip do not understand this option. We should >not punish them. If somebody is using gcc, they can bloody well used GNU strip too. If they don't, that's their problem. Try using gcc output with somebody else's symbolic debugger sometime. You'll see what I mean. Deep interoperability with Other People's Tools hasn't been on the GNU agenda for a long long time. I argued for it, long and hard, a long time ago, but I lost that battle. >> b) In practice, nobody will give a damn about the presence or absense of >> this extra information anyway. > >Yes, they will. More specifically, /we/ will as we build GCC itself. > >Right now things like crtbegin.o and libgcc2 and lib<pick-a-language> are >all getting this information added to them. It's not a problem with memory >consumption because they aren't allocated. It is however a correctness >problem because the final executable gets about five copies of the options >strings (the assembler and linker combine the separate instances of the >identically-named sections). That last (parenthesized) part is true, in a general, total, and complete sense, if and only if you are NOT using -s with ld. Otherwise the linker does not ``combine'' but rather _ignores_ certain input sections. >But the first set of options are those passed when compiling crtbegin, >the second set are those passed when compiling some chunk of libgcc2, >{etc}... Yes, you are correct that once you get past mere .o files and start get- ting into linking, keeping this data around (e.g. in the linker's output file) may perhaps be a less-than-wonderful idea. (But see below.) OK. So now _here_ is a good excuse to come up with a new GNU invention... a new ``GNU standardized'' ELF section name. For lack of a better name, let's call it `.ignore_me'. All .ignore_me sections would have special semantics (at least to the GNU linker) at link time. Specifically, the special semantics would be that the linker just avoids coping them into the final executable (or shared library). Hummm... OK. Wait a minute. That would work, but I have a better idea... Just _label_ each one of these hunks of option information with the specific corresponding .c or .C ``primary'' source file name that was being compiled when those options were used. Then the final linked file would, in effect contain essentially a complete history, telling you how it got built. Hell! You could practically write a program to automatically reverse-engineer and re-create the original Makefiles (or files functionally equivalent to them) just from the final linked executable! Ok, so maybe a use for such a capability won't come up THAT often, but hey! You never know. I always keep my server logs around for at least a full week, just in case. Why should this info be any different? It is always good to leave a trail of breadcrumbs, so that you can get back the way you came.
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: <gcc-gnats@gcc.gnu.org>, <pedwards@disaster.jaj.com> Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 18:16:14 +0100 (BST) On 30 Apr 2001, Ronald F. Guilmette wrote: > As I noted, they can always run `strip' after the compile, if the extra > info really bothers them. But does "strip" (without other options) remove these sections? It doesn't (binutils 2.11.90.0.6) remove .comment and .note; for that reason, Debian has modified "install -s" to pass --remove-section=.comment --remove-section=.note to strip. -- Joseph S. Myers jsm28@cam.ac.uk
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 18:47:54 -0400 On Mon, Apr 30, 2001 at 10:21:12AM -0700, Ronald F. Guilmette wrote: > >But does "strip" (without other options) remove these sections? It > >doesn't (binutils 2.11.90.0.6) remove .comment and .note; for that reason, > >Debian has modified "install -s" to pass --remove-section=.comment > >--remove-section=.note to strip. > > a) It's no big deal to also supply --remove-section=.comment on the > strip command line. Other implementations of strip do not understand this option. We should not punish them. > b) In practice, nobody will give a damn about the presence or absense of > this extra information anyway. Yes, they will. More specifically, /we/ will as we build GCC itself. Right now things like crtbegin.o and libgcc2 and lib<pick-a-language> are all getting this information added to them. It's not a problem with memory consumption because they aren't allocated. It is however a correctness problem because the final executable gets about five copies of the options strings (the assembler and linker combine the separate instances of the identically-named sections). But the first set of options are those passed when compiling crtbegin, the second set are those passed when compiling some chunk of libgcc2, there are many copies from various libstdc++ files in there if you happen to use C++, and only /one/ of those copies contains the options that the user actually passed when compiling the "real" source file. Which one? No way of knowing without doing a crapload of grep's. But all the sets are slightly different (e.g., we pass -D optiosn when building ourselves that a user wouldn't). I haven't tried a full bootstrap with my half-baked changes in yet, but would expect it to fail because all the .o's would probably differ. Anyhow, adding a disabling flag took about four lines of code. I still plan to make this on by default (otherwise it'll never get used, and the presence of the information will be highly unpredictable). Phil -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
From: Phil Edwards <pedwards@disaster.jaj.com> To: "Ronald F. Guilmette" <rfg@monkeys.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 7 May 2001 18:33:36 -0400 On Tue, May 01, 2001 at 12:36:01AM -0000, Ronald F. Guilmette wrote: > OK. So now _here_ is a good excuse to come up with a new GNU invention... > a new ``GNU standardized'' ELF section name. Given the overly-loose hammer and nail analogy that you sent me in private email, I'll assume you're being facetious here. :-) > Hummm... OK. Wait a minute. That would work, but I have a better idea... > > Just _label_ each one of these hunks of option information with the > specific corresponding .c or .C ``primary'' source file name that was > being compiled when those options were used. Then the final linked > file would, in effect contain essentially a complete history, telling > you how it got built. Hell! You could practically write a program > to automatically reverse-engineer and re-create the original Makefiles > (or files functionally equivalent to them) just from the final linked > executable! Actually, my current implementation already does this. I needed to figure out where an extra copy of the options was coming from, and I left the code in when I was done. And I've never tried writing a tool using the BFD library, but if I understand its purpose correctly, it should be easy to use it to write a build-option-pretty-printer for an executable. It's on that part of my TODO list titled, "probably useless but would be really fun to try."[*] Phil [*] Much of my life is under this category, so there's a good chance that this tool would be written, if I haven't misunderstood BFD. -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools.
State-Changed-From-To: open->suspended State-Changed-Why: Following Phil's suggestion, I suspend this one.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: pedwards@disaster.jaj.com, <rfg@monkeys.com> Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Tue, 5 Nov 2002 09:41:10 -0600 (CST) Phil, Ronald, you two have been writing a _lot_ of text about this report, but from reading two sentences every second page, I was not clear about whether anything has been implemented at all. What's the status of this report? I'm just trying to sift through the old reports and try to close that are no longer valid. 1800+ non-closed reports is simply getting too many... Thanks Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: Phil Edwards <phil@jaj.com> Cc: rfg@monkeys.com, <gcc-gnats@gcc.gnu.org> Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Tue, 5 Nov 2002 11:09:46 -0600 (CST) > [ note that the pedwards address is now invalid ] Yeah, I noticed that. > > you two have been writing a _lot_ of text about this report, but from > > reading two sentences every second page, I was not clear about whether > > anything has been implemented at all. What's the status of this report? > > > > I'm just trying to sift through the old reports and try to close that are > > no longer valid. 1800+ non-closed reports is simply getting too many... > > It should be suspended, not closed. The idea is a good one, but I don't > have time right now to actively work on it. OK, I'll do that. Thanks W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
From: Phil Edwards <phil@jaj.com> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu> Cc: rfg@monkeys.com, gcc-gnats@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Tue, 5 Nov 2002 12:04:51 -0500 [ note that the pedwards address is now invalid ] On Tue, Nov 05, 2002 at 09:41:10AM -0600, Wolfgang Bangerth wrote: > Phil, Ronald, > you two have been writing a _lot_ of text about this report, but from > reading two sentences every second page, I was not clear about whether > anything has been implemented at all. What's the status of this report? > > I'm just trying to sift through the old reports and try to close that are > no longer valid. 1800+ non-closed reports is simply getting too many... It should be suspended, not closed. The idea is a good one, but I don't have time right now to actively work on it. Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002
Changing to NEW based on http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00858.html
(In reply to comment #20) > Changing to NEW based on > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00858.html > Shouldn't the PR be closed now, after committing the patch from http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00211.html ?
Fixed in GCC 4.4 with -frecord-gcc-switches