Re: cpplib: Nix -g3.

Re: cpplib: Nix -g3.

[Neil Booth]

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.

Re: cpplib: Nix -g3.

[Zack Weinberg]

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

Re: cpplib: Nix -g3.

[Neil Booth]

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.

Re: cpplib: Nix -g3.

[Zack Weinberg]

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

Re: cpplib: Nix -g3.

[Neil Booth]

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')

Re: cpplib: Nix -g3.

[Zack Weinberg]

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

Re: cpplib: Nix -g3.

[Jason Merrill]

>>>>> "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

Re: cpplib: Nix -g3.

[Neil Booth]

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.

Re: cpplib: Nix -g3.

[Jason Merrill]

>>>>> "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

Re: cpplib: Nix -g3.

[Neil Booth]

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.

RE: cpplib: Nix -g3.

[David Korn]

>-----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
**********************************************************************