* RE: cpplib: Nix -g3. @ 2001-01-12 5:50 David Korn 2001-01-12 14:23 ` Neil Booth 0 siblings, 1 reply; 11+ messages in thread From: David Korn @ 2001-01-12 5:50 UTC (permalink / raw) To: 'Zack Weinberg', Neil Booth; +Cc: Jakub Jelinek, gcc, gcc-patches >-----Original Message----- >From: Zack Weinberg [ mailto:zackw@Stanford.EDU ] >Sent: 12 January 2001 04:41 >On Thu, Jan 11, 2001 at 06:54:40PM +0000, Neil Booth wrote: >> Zack Weinberg wrote:- >> >> > That too might've been something to do with. IIRC we're supposed to >> > spit out >> > >> > # 1 "file.c" >> > >> > in between each builtin macro definition. 1 might have been 0. This >> > was a very long time ago. >> >> Well, the nice thing is that this is the natural behaviour when you >> remove those if statements. It also re-preprocesses correctly with >> -fpreprocessed, with the patch below to prevent double-initialization >> of builtins and command line switches. I must have got something >> right when I moved all this stuff to cppmain.c :-) >> >> As for # 1 file.c or # 0 file.c, who's the right person to ask? If 0 >> is the line number we want, it won't be too hard to correct, I think. > >The gdb people might know. I'd say leave it as 1 until someone >complains. PMFBI, but I think something I've spotted in the vxworks port might be relevant to this issue: _BIG_ENDIAN gets defined in one of the OS header files, but it's also passed in the specs as a -D flag. Is this the situation you're talking about? Because what I see for a line number is: --- F:/Tornado/target/h/types/vxArch.h:46: warning: `_BIG_ENDIAN' redefined *Initialization*:1: warning: this is the location of the previous definition --- Would that be line 0, by any chance? DaveK -- The Boulder Pledge: "Under no circumstances will I ever purchase anything offered to me as the result of an unsolicited email message. Nor will I forward chain letters, petitions, mass mailings, or virus warnings to large numbers of others. This is my contribution to the survival of the online community." ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-12 5:50 cpplib: Nix -g3 David Korn @ 2001-01-12 14:23 ` Neil Booth 0 siblings, 0 replies; 11+ messages in thread From: Neil Booth @ 2001-01-12 14:23 UTC (permalink / raw) To: David Korn; +Cc: 'Zack Weinberg', Jakub Jelinek, gcc, gcc-patches David Korn wrote:- > F:/Tornado/target/h/types/vxArch.h:46: warning: `_BIG_ENDIAN' redefined > *Initialization*:1: warning: this is the location of the previous definition > --- > > Would that be line 0, by any chance? > > DaveK A line number doesn't really make much sense, so if anything I think it should just show the "file" name. Neil. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20010109233506.C7013@daikokuya.demon.co.uk>]
[parent not found: <20010109155204.A2032@wolery.stanford.edu>]
[parent not found: <20010110000706.C10605@daikokuya.demon.co.uk>]
[parent not found: <20010110041336.V1120@devserv.devel.redhat.com>]
* Re: cpplib: Nix -g3. [not found] ` <20010110041336.V1120@devserv.devel.redhat.com> @ 2001-01-10 13:38 ` Neil Booth 2001-01-10 15:46 ` Zack Weinberg 0 siblings, 1 reply; 11+ messages in thread From: Neil Booth @ 2001-01-10 13:38 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Zack Weinberg, gcc Jakub Jelinek wrote:- > BTW: cpp0 -g3 (nor cpp0 -dD) omits the builtin macros and macros specified > on the command line in the output (this got broken during the last lexer > rewrite). You're not really supposed to invoke cpp0 directly. But, yes, cppmain does ignore those regardless of how it's invoked. I thought it was intentional - it's been in cppmain.c for a while. This were causing me a minor headache, in fact, for making cpp_reader opaque - I'd be quite happy to get rid of it and output the lot - if Zack has no objections. It's caused by the condition if (pfile->done_initializing) { [...] } in cb_define and cb_undef of cppmain.c. Neil. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-10 13:38 ` Neil Booth @ 2001-01-10 15:46 ` Zack Weinberg 2001-01-10 15:59 ` Neil Booth 0 siblings, 1 reply; 11+ messages in thread From: Zack Weinberg @ 2001-01-10 15:46 UTC (permalink / raw) To: Neil Booth; +Cc: Jakub Jelinek, gcc On Wed, Jan 10, 2001 at 09:11:05PM +0000, Neil Booth wrote: > Jakub Jelinek wrote:- > > > BTW: cpp0 -g3 (nor cpp0 -dD) omits the builtin macros and macros specified > > on the command line in the output (this got broken during the last lexer > > rewrite). > > You're not really supposed to invoke cpp0 directly. > > But, yes, cppmain does ignore those regardless of how it's invoked. I > thought it was intentional - it's been in cppmain.c for a while. > > This were causing me a minor headache, in fact, for making cpp_reader > opaque - I'd be quite happy to get rid of it and output the lot - if > Zack has no objections. > > It's caused by the condition > > if (pfile->done_initializing) > { > [...] > } > > in cb_define and cb_undef of cppmain.c. There was a very good reason for this which I don't remember anymore. I think it might have had to do with the printer not being set up early enough, so it would crash. zw ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-10 15:46 ` Zack Weinberg @ 2001-01-10 15:59 ` Neil Booth 2001-01-11 0:57 ` Zack Weinberg 0 siblings, 1 reply; 11+ messages in thread From: Neil Booth @ 2001-01-10 15:59 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jakub Jelinek, gcc Zack Weinberg wrote:- > There was a very good reason for this which I don't remember anymore. > I think it might have had to do with the printer not being set up > early enough, so it would crash. I think you might be right about the printing. Anyway, that problem is no more. Cool, another kludge we can eliminate. The only issue is where this stuff shows up the in preprocessed output - the line numbering might be screwy, giving problems with a re-read and -fpreprocessed. Maybe that was a reason? Neil. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-10 15:59 ` Neil Booth @ 2001-01-11 0:57 ` Zack Weinberg 2001-01-11 10:54 ` Neil Booth 0 siblings, 1 reply; 11+ messages in thread From: Zack Weinberg @ 2001-01-11 0:57 UTC (permalink / raw) To: Neil Booth; +Cc: Jakub Jelinek, gcc On Wed, Jan 10, 2001 at 11:58:53PM +0000, Neil Booth wrote: > Zack Weinberg wrote:- > > > There was a very good reason for this which I don't remember anymore. > > I think it might have had to do with the printer not being set up > > early enough, so it would crash. > > I think you might be right about the printing. Anyway, that problem > is no more. Cool, another kludge we can eliminate. > > The only issue is where this stuff shows up the in preprocessed output > - the line numbering might be screwy, giving problems with a re-read > and -fpreprocessed. Maybe that was a reason? That too might've been something to do with. IIRC we're supposed to spit out # 1 "file.c" in between each builtin macro definition. 1 might have been 0. This was a very long time ago. zw ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-11 0:57 ` Zack Weinberg @ 2001-01-11 10:54 ` Neil Booth 2001-01-11 20:41 ` Zack Weinberg 2001-01-14 11:52 ` Jason Merrill 0 siblings, 2 replies; 11+ messages in thread From: Neil Booth @ 2001-01-11 10:54 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jakub Jelinek, gcc, gcc-patches Zack Weinberg wrote:- > That too might've been something to do with. IIRC we're supposed to > spit out > > # 1 "file.c" > > in between each builtin macro definition. 1 might have been 0. This > was a very long time ago. Well, the nice thing is that this is the natural behaviour when you remove those if statements. It also re-preprocesses correctly with -fpreprocessed, with the patch below to prevent double-initialization of builtins and command line switches. I must have got something right when I moved all this stuff to cppmain.c :-) As for # 1 file.c or # 0 file.c, who's the right person to ask? If 0 is the line number we want, it won't be too hard to correct, I think. Bootstrapping i586 Linux. Neil. * cppinit.c (cpp_start_read): If -fpreprocessed, ignore -D, -U and -A, and don't initialize the builtins. * cppmain.c (cb_define, cb_undef): Unconditionally process the callback. * tradcpp.c (main): Fix typo. Index: cppinit.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cppinit.c,v retrieving revision 1.138 diff -u -p -r1.138 cppinit.c --- cppinit.c 2001/01/10 23:27:59 1.138 +++ cppinit.c 2001/01/11 18:09:02 @@ -859,10 +859,9 @@ do_includes (pfile, p, scan) } } -/* This is called after options have been processed. Check options - for consistency, and setup for processing input from the file named - FNAME. (Use standard input if FNAME == NULL.) Return 1 on success, - 0 on failure. */ +/* This is called after options have been processed. Setup for + processing input from the file named FNAME. (Use standard input if + FNAME == NULL.) Return 1 on success, 0 on failure. */ int cpp_start_read (pfile, fname) @@ -915,18 +914,23 @@ cpp_start_read (pfile, fname) if (!_cpp_read_file (pfile, fname)) return 0; - /* Install __LINE__, etc. */ - init_builtins (pfile); - - /* Do -U's, -D's and -A's in the order they were seen. */ - p = CPP_OPTION (pfile, pending)->directive_head; - while (p) + /* If already preprocessed, don't install __LINE__, etc., and ignore + command line definitions and assertions. */ + if (! CPP_OPTION (pfile, preprocessed)) { - (*p->handler) (pfile, p->arg); - q = p->next; - free (p); - p = q; + init_builtins (pfile); + + /* Do -U's, -D's and -A's in the order they were seen. */ + p = CPP_OPTION (pfile, pending)->directive_head; + while (p) + { + (*p->handler) (pfile, p->arg); + q = p->next; + free (p); + p = q; + } } + pfile->done_initializing = 1; /* The -imacros files can be scanned now, but the -include files @@ -1131,10 +1135,10 @@ static const struct cl_option cl_options command-line matches. Returns its index in the option array, negative on failure. Complications arise since some options can be suffixed with an argument, and multiple complete matches can occur, - e.g. -iwithprefix and -iwithprefixbefore. Moreover, we want to - accept options beginning with -g and -W that we do not recognise, - but not to swallow any subsequent command line argument; these are - handled as special cases in cpp_handle_option. */ + e.g. -iwithprefix and -iwithprefixbefore. Moreover, we need to + accept options beginning with -W that we do not recognise, but not + to swallow any subsequent command line argument; this is handled as + special cases in cpp_handle_option. */ static int parse_option (input) const char *input; Index: cppmain.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cppmain.c,v retrieving revision 1.52 diff -u -p -r1.52 cppmain.c --- cppmain.c 2001/01/10 21:32:15 1.52 +++ cppmain.c 2001/01/11 18:09:03 @@ -344,18 +344,15 @@ cb_define (pfile, node) cpp_reader *pfile; cpp_hashnode *node; { - if (pfile->done_initializing) - { - maybe_print_line (cpp_get_line (pfile)->output_line); - fprintf (print.outf, "#define %s", node->name); + maybe_print_line (cpp_get_line (pfile)->output_line); + fprintf (print.outf, "#define %s", node->name); - /* -dD command line option. */ - if (CPP_OPTION (pfile, dump_macros) == dump_definitions) - fputs ((const char *) cpp_macro_definition (pfile, node), print.outf); + /* -dD command line option. */ + if (CPP_OPTION (pfile, dump_macros) == dump_definitions) + fputs ((const char *) cpp_macro_definition (pfile, node), print.outf); - putc ('\n', print.outf); - print.lineno++; - } + putc ('\n', print.outf); + print.lineno++; } static void @@ -363,12 +360,9 @@ cb_undef (pfile, node) cpp_reader *pfile; cpp_hashnode *node; { - if (pfile->done_initializing) - { - maybe_print_line (cpp_get_line (pfile)->output_line); - fprintf (print.outf, "#undef %s\n", node->name); - print.lineno++; - } + maybe_print_line (cpp_get_line (pfile)->output_line); + fprintf (print.outf, "#undef %s\n", node->name); + print.lineno++; } static void Index: tradcpp.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tradcpp.c,v retrieving revision 1.30 diff -u -p -r1.30 tradcpp.c --- tradcpp.c 2001/01/10 23:28:00 1.30 +++ tradcpp.c 2001/01/11 18:09:22 @@ -647,7 +647,7 @@ main (argc, argv) int quoted = argv[i][2] == 'Q'; if (*tgt == '\0' && i + 1 == argc) - fatal ("Filename missing after %s option", argv[i]); + fatal ("Target missing after %s option", argv[i]); else { if (*tgt == '\0') ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-11 10:54 ` Neil Booth @ 2001-01-11 20:41 ` Zack Weinberg 2001-01-14 11:52 ` Jason Merrill 1 sibling, 0 replies; 11+ messages in thread From: Zack Weinberg @ 2001-01-11 20:41 UTC (permalink / raw) To: Neil Booth; +Cc: Jakub Jelinek, gcc, gcc-patches On Thu, Jan 11, 2001 at 06:54:40PM +0000, Neil Booth wrote: > Zack Weinberg wrote:- > > > That too might've been something to do with. IIRC we're supposed to > > spit out > > > > # 1 "file.c" > > > > in between each builtin macro definition. 1 might have been 0. This > > was a very long time ago. > > Well, the nice thing is that this is the natural behaviour when you > remove those if statements. It also re-preprocesses correctly with > -fpreprocessed, with the patch below to prevent double-initialization > of builtins and command line switches. I must have got something > right when I moved all this stuff to cppmain.c :-) > > As for # 1 file.c or # 0 file.c, who's the right person to ask? If 0 > is the line number we want, it won't be too hard to correct, I think. The gdb people might know. I'd say leave it as 1 until someone complains. zw ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-11 10:54 ` Neil Booth 2001-01-11 20:41 ` Zack Weinberg @ 2001-01-14 11:52 ` Jason Merrill 2001-01-14 11:59 ` Neil Booth 1 sibling, 1 reply; 11+ messages in thread From: Jason Merrill @ 2001-01-14 11:52 UTC (permalink / raw) To: Neil Booth; +Cc: Zack Weinberg, Jakub Jelinek, gcc, gcc-patches >>>>> "Neil" == Neil Booth <neil@daikokuya.demon.co.uk> writes: > Zack Weinberg wrote:- >> That too might've been something to do with. IIRC we're supposed to >> spit out >> >> # 1 "file.c" >> >> in between each builtin macro definition. None of the debugging backends actually use this information, so I wouldn't bother if it's at all inconvenient. Jason ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-14 11:52 ` Jason Merrill @ 2001-01-14 11:59 ` Neil Booth 2001-01-15 4:14 ` Jason Merrill 0 siblings, 1 reply; 11+ messages in thread From: Neil Booth @ 2001-01-14 11:59 UTC (permalink / raw) To: Jason Merrill; +Cc: Zack Weinberg, Jakub Jelinek, gcc, gcc-patches Jason Merrill wrote:- > None of the debugging backends actually use this information, so I wouldn't > bother if it's at all inconvenient. It's already doing it that way. The # 1 stuff comes out of cppmain.c naturally without extra code :-) The only question was should the lines be # 0, but if nothing uses it that can wait until something does. Neil. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: cpplib: Nix -g3. 2001-01-14 11:59 ` Neil Booth @ 2001-01-15 4:14 ` Jason Merrill 0 siblings, 0 replies; 11+ messages in thread From: Jason Merrill @ 2001-01-15 4:14 UTC (permalink / raw) To: Neil Booth; +Cc: Zack Weinberg, Jakub Jelinek, gcc, gcc-patches >>>>> "Neil" == Neil Booth <neil@daikokuya.demon.co.uk> writes: > Jason Merrill wrote:- >> None of the debugging backends actually use this information, so I wouldn't >> bother if it's at all inconvenient. > It's already doing it that way. The # 1 stuff comes out of cppmain.c > naturally without extra code :-) The only question was should the > lines be # 0, but if nothing uses it that can wait until something > does. Ah. FWIW, the dwarf2 .debug_macinfo spec requires that command-line macros have a line number of 0 (and appear before the first DW_MACINFO_start_file op). Jason ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-01-15 4:14 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-12 5:50 cpplib: Nix -g3 David Korn 2001-01-12 14:23 ` Neil Booth [not found] <20010109233506.C7013@daikokuya.demon.co.uk> [not found] ` <20010109155204.A2032@wolery.stanford.edu> [not found] ` <20010110000706.C10605@daikokuya.demon.co.uk> [not found] ` <20010110041336.V1120@devserv.devel.redhat.com> 2001-01-10 13:38 ` Neil Booth 2001-01-10 15:46 ` Zack Weinberg 2001-01-10 15:59 ` Neil Booth 2001-01-11 0:57 ` Zack Weinberg 2001-01-11 10:54 ` Neil Booth 2001-01-11 20:41 ` Zack Weinberg 2001-01-14 11:52 ` Jason Merrill 2001-01-14 11:59 ` Neil Booth 2001-01-15 4:14 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).