------- Comment #10 from patriciak784-gccmainling at yahoo dot de  2009-02-01 
11:22 -------
(In reply to comment #6)

> read_original_filename lexes a token, which hits EOF, which

> causes the buffer to be popped.

> 

> This is sort of an odd scenario.

> Perhaps working around it in preprocess_file is best.

> 

Tom, I did investigate that problem a bit more with the compilers (see end of
comment for versioninfo).

All 4.x branches + trunk @ rev 143756 fail in preprocess_file but 3.4.6
doesn't.

The reason 3.4.6 does not fail is the patch applied to 3.4 branch by Richard
Guenther because of PR20239(perhaps we should even mark this bug as a duplicate
and reopen 20239).
The patch didn't make it into 4.0 because the code there had already been
changed from
  if (CPP_OPTION (pfile, preprocessed))
    {
      read_original_filename (pfile);
+      if (!pfile->map)
+       return NULL;
      fname = pfile->map->to_file;
    }
to
  if (CPP_OPTION (pfile, preprocessed))
    {
      read_original_filename (pfile);
      fname = pfile->line_table->maps[pfile->line_table->used-1].to_file;
    }
(see function cpp_read_main_file in gcc/cppinit.c libcpp/init.c respectively)
The two lines beginning with + are Richard's fix.

pfile->map seems to get NULL if there is only whitespace in the file or nothing
at all. Therefore 3.4.4 segfaulted on pfile->map->to_file.
By returning NULL, the function calling cpp_read_main_file,
c_common_post_options will increment errorcount
(=global_dc->diagnostic_count[DK_ERROR])
which leads to the code calling preprocess_file to be skipped and therefore
there is no segfault on 3.4.6.
On the 4.x branches cpp_read_main_file will not return NULL in that case and
preprocess_file will be executed and segfault.

I just wonder why in PR20239, 4.0.0 is said to work. I don't know which
revision Andrew Pinski used but rev 95634 fails for me and I fail to build the
3.3.3 release which is supposed to succeed either.
Perhaps the code leading to the error was introduced around that time and 4.0
branch and trunk but I don't actually think so. If 3.3.3 worked, I assume the
bug was introduced in the 3.4 development cycle.

After all it is now up to you Tom or another maintainer to decide if to apply
my piece of code or create something else (perhaps something in
cpp_read_main_file like Richard did about 4 years ago). I have no objections
against either possibility.
Perhaps someone could verify what I did and update known to fail and known to
work to 3.4.6 | 4.0.4 4.1.3 4.2.5 4.3.4 4.4.0.

And one last thing: this is a regression from 3.4.6.

==========================gcc versioninfo =====================================
I compiled gcc 3.4,4.0,4.1,4.2,4.3 and 4.4 from svn rev 143756
-v outputs:
Reading specs from
/media/OSS/final/gcc-3.4/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.6/specs
Configured with: ../../gcc3.4/configure --prefix=/gcc/final/gcc-3.4
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 3.4.6
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.0/configure --prefix=/gcc/final/gcc-4.0
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.0.4
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.1/configure --prefix=/gcc/final/gcc-4.1
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.1.3 20080704 (prerelease)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.2/configure --prefix=/gcc/final/gcc-4.2-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.2.5 20090129 (prerelease)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.3/configure --prefix=/gcc/final/gcc-4.3-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.3.4 20090129 (prerelease) (GCC) 
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.4/configure --prefix=/gcc/final/gcc-4.4-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090129 (experimental) (GCC)
===============================================================================
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4_0-branch/configure
--prefix=/gcc/final/gcc-4.0-95634 --disable-multilib --enable-languages=c,c++
--with-gnu-ld --with-gnu-as --disable-nls --with-system-zlib
--disable-bootstrap
Thread model: posix
gcc version 4.0.0 20050227 (prerelease) <- rev 95634


-- 


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

Reply via email to