[ forwarded from http://bugs.debian.org/bug=330857 ] unpacking the attached tarball and cpp -I.. -I. test.c gives: % cpp -I.. -I. test.c # 1 "test.c" # 0 "<built-in>" # 1 "<command line>" # 1 "test.c" # 1 "../tao/ORB.h" 1 # 1 "../tao/Sequence_T.h" 1 # 1 "../tao/Sequence.h" 1 # 1 "../tao/Sequence_T.h" 1 # 4 "../tao/Sequence.h" 2 # 4 "../tao/Sequence_T.h" 2 # 1 "../tao/Sequence_T.cpp" 1 # 6 "../tao/Sequence_T.h" 2 # 1 "../tao/ORB.h" 2 # 2 "test.c" 2 <built-in>:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 9882 [details] Test case
Hmm, I think this is related to PR 15167. This worked with "4.0.0 20050225" and "3.5.0 20040909". Though it failed with "3.4.0 20040116" and 3.4.0 release and the current mainline. I am going to mark this currently as a 4.1 regression but not confirm it until I can get a newer 4.0.x and 3.4.x though I will fill out the known to work/fail for releases I tried.
The list of work/fail versions is very odd for this bug; it seems to have worked on mainline until sometime between 20050828 and 20050904. 3.3.5 passes, but all 3.4.x versions I tried fail. 4.0.0 passes but 4.0.2 fails. I fired off several mainline builds between the 3.3 branchpoint and early September to identify ranges on mainline where it passes and fails; those should help show if it's an intermittent failure or has definite fix and break points.
The most recent break on mainline was by this patch from jakub: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00974.html The same patch was applied to the 4.0 branch, causing the failure in 4.0.2. That patch from Jakub reverted part of this patch from Zack, which had fixed this bug on mainline: http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00122.html Before that, the failure on mainline started sometime between 2003-07-16 and 2003-09-15. I can identify the patch if it would be useful to anyone.
(In reply to comment #4) > Before that, the failure on mainline started sometime between 2003-07-16 and > 2003-09-15. I can identify the patch if it would be useful to anyone. Hmm, can you because in PR 15167, Neil said: >If it was broken back around 5th August 2003 I will look into this, as it was my >new code.
*** Bug 24271 has been marked as a duplicate of this bug. ***
A regression test identified this patch from Neil on 2003-08-02 as thene start of failures: http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00093.html
Hmm, "regression test" in the last comment should have been "regression hunt".
I'm marking this as P1, at least until we do some analysis.
On mainline, this appears to be fixable with a one line patch. We are failing in should_stack_file because we have a _cpp_file struct with buffer=0 and buffer_valid=1. We call read_file which immediately returns because buffer_valid is true. Then we try to read chars from the buffer and crash because it is still zero. The trivial fix is that we must clear buffer_valid when we clear buffer. This is done in _cpp_pop_file_buffer. The testcase works with this patch. I haven't looked at any of the patch history or at the older gcc versions yet.
Created attachment 10096 [details] clear buffer_valid when clearing buffer Untested patch for mainline which makes the testcase work.
The patch should use false instead of 0. These new fangled boolean types keep messing me up.
I believe the problem originated here: 2003-07-29 Neil Booth <neil@daikokuya.co.uk> PR preprocessor/11569 PR preprocessor/11649 * Makefile.in (LIBCPP_DEPS): Add HASHTAB_H. * cppfiles.c: Completely rewritten. ... This added the buffer_valid field, and added code that clears buffer without also clearing buffer_valid. This is revision 1.178 in the gcc/cppfiles.c file. The failure occurs only when we free a valid buffer, and then try to reuse that buffer because we still think it is valid. Whether this occurs depends on how buffers are managed by cpp, and how they are used by cpp, so I don't find it surprising that this latent bug has been disappearing and reappearing over time. The patch identified by Janis just makes the problem more visible because it adds more uses of buffer_valid. Now I'm off to test my patch. The same patch should work for all 3 gcc versions.
Subject: Bug 24202 Author: wilson Date: Fri Nov 4 02:10:19 2005 New Revision: 106472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106472 Log: Fix failure with pragma once where buffer is NULL and buffer_valid is true. PR preprocessor/24202 * files.c (_cpp_pop_file_buffer): Set buffer_valid to false. Modified: trunk/libcpp/ChangeLog trunk/libcpp/files.c
Subject: Bug 24202 Author: wilson Date: Fri Nov 4 02:12:48 2005 New Revision: 106473 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106473 Log: Fix pragma once bug where buffer is NULL and buffer_valid is true. PR preprocessor/24202 * files.c (_cpp_pop_file_buffer): Set buffer_valid to false. Modified: branches/gcc-4_0-branch/libcpp/ChangeLog branches/gcc-4_0-branch/libcpp/files.c
Fixed on the mainline and the 4.0 branch for 4.0.3 but is waiting for a back port for 3.4.x.
Subject: Bug 24202 Author: gdr Date: Wed Mar 1 10:11:05 2006 New Revision: 111599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111599 Log: Backport Jim Wilson's patch for PR 24202 Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/cppfiles.c
patch backported to 3.4.6.