From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30680 invoked by alias); 4 Jan 2009 20:26:23 -0000 Received: (qmail 30649 invoked by uid 48); 4 Jan 2009 20:26:10 -0000 Date: Sun, 04 Jan 2009 20:26:00 -0000 Message-ID: <20090104202610.30648.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null' In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "patriciak784-gccmainling at yahoo dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-01/txt/msg00401.txt.bz2 ------- Comment #7 from patriciak784-gccmainling at yahoo dot de 2009-01-04 20:26 ------- (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. > Perhaps. I'm glad someone looked at this again. I just verified again that changing the lines to # if (flag_no_output) # { # /* Scan -included buffers, then the main file. */ # while(pfile->buffer) # cpp_scan_nooutput (pfile); # } does indeed fix or work around (with gcc 4.3 branch revision somewhere around rev143000) the original problem ('gcc -E -dM -fpreprocessed - < /dev/null') on mingw32 and x86_64 debian gnu linux. But my own problem (PR37331) is quite strange. When I run gcc 4.3 in the debugger it works, when I run it outside it fails with SIGSEV in cc1 which is just totally strange. But the really strange thing is that the official mingw 3.4.5r3 does always work for me. I'll have to try again on another PC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215