[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

["patriciak784-gccmainling at yahoo dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from patriciak784-gccmainling at yahoo dot de  2008-09-04 13:35 -------
I did examine both problems a bit further.
If I understand correctly what is happening, there is the object parse_in which
is, during program flow, passed to preprocess_file as argument pfile.
An object of type cpp_reader seems to have several buffers which are organized
as a stack. The topmost buffer worked is saved in ->buffer.
And now preprocess_file gets the cpp_reader object and as 'flag_no_output' is
true (I don't know why...) the function tries to pop all buffers from the
buffer stack and by popping them does some processing on them (by doing a loop
as long as there is a previous buffer pfile->buffer->prev and then doing
another call to cpp_scan_nooutput for the last buffer).
All files seem to have at least one buffer but processing "/dev/null"
temporarily creates a buffer but unallocates it beacause EOF is reached before
calling preprocess_file. 
And this function does not check if there _is_ a buffer pfile->buffer != NULL
and therefore both commands fail.
At the moment the important lines (file gcc/c-ppoutput.c lines 71..77) look
like this:
  if (flag_no_output)
    {
      /* Scan -included buffers, then the main file.  */
      while (pfile->buffer->prev)
        cpp_scan_nooutput (pfile);
      cpp_scan_nooutput (pfile);
    }
I did try
  if (flag_no_output)
    {
      if(pfile->buffer)
     {
      /* Scan -included buffers, then the main file.  */
      while (pfile->buffer->prev)
        cpp_scan_nooutput (pfile);
      cpp_scan_nooutput (pfile);
     }
    }
And it does indeed work - no segfaults any more! :->
This part can perhaps even be optimized a bit:
  if (flag_no_output)
    {
      /* Scan -included buffers, then the main file.  */
      while(pfile->buffer)
        cpp_scan_nooutput (pfile);
    }
I didn't test that one yet but I suppose it works.
I suppose someone should run the testsuite and post the results...

And one more thing:
running 'gcc -c out.o -x c /dev/null' now prints:
cc1: warning: nul.gch: too short to be a PCH file (nul.gch probably because on
windows /dev/null is internally converted to the system file NUL which does the
same this as /dev/null on *nix)
Do you think this output is the right thing to do? Or is that a bug, too?
At least out.o is an empty object file.
and running 'gcc -E -dM -fpreprocessed - < /dev/null' doesn't print anything.


-- 


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