From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1402 invoked by alias); 9 Sep 2002 12:26:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 1382 invoked by uid 71); 9 Sep 2002 12:26:04 -0000 Resent-Date: 9 Sep 2002 12:26:04 -0000 Resent-Message-ID: <20020909122604.1381.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, jason@redhat.com Received: (qmail 29036 invoked by uid 61); 9 Sep 2002 12:17:13 -0000 Message-Id: <20020909121713.29028.qmail@sources.redhat.com> Date: Mon, 09 Sep 2002 05:26:00 -0000 From: jason@redhat.com Reply-To: jason@redhat.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o X-SW-Source: 2002-09/txt/msg00131.txt.bz2 List-Id: >Number: 7862 >Category: preprocessor >Synopsis: Interrupting gcc -MD removes .d file but not .o >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Mon Sep 09 05:26:03 PDT 2002 >Closed-Date: >Last-Modified: >Originator: jason@redhat.com >Release: 3.0.4, 3.2, trunk >Organization: >Environment: all >Description: [from customer bug report] We are using -MD option in gcc to manage the dependency information. The problem is this, if this is interrupted by a control-c gcc promptly deletes the .d file but not any .o file that may have been existed prior to compilation. So for example, the following situation could occur: 1. foo.C depends on foo.H 2. foo.H is changed followed by a gmake 3. foo.H is changed again followed by a gmake 4. gmake is interrupted 5. .d file gets deleted 6. foo.H is changed again but doing a gmake will now do nothing The problem is that now foo.o may have a bogus object layout. Expected Results: if foo.d is deleted, foo.o must be deleted as well; otherwise a makefile which relies on the contents of foo.d in order to decide when to rebuild foo.o will get the wrong answer. Either we should delete both, or neither. Note that if -o is not used in the compile, neither foo.d nor foo.o are deleted, because %W{!o: %b.d} doesn't actually add %b.d to the failure_delete_queue. The current behavior was established by http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00481.html >How-To-Repeat: Steps to Reproduce: 1. gcc -c foo.c -MD -o foo.o 2. ls -l foo.* (notice that both foo.d and foo.o exist) 3. gcc -c foo.c -MD -o foo.o (interrupt with ^C while cc1 is running) 4. ls -l foo.* (notice that foo.o exists, but foo.d does not) >Fix: I proposed a solution in http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00388.html but Neil wasn't happy with it. I'm waiting for more feedback. >Release-Note: >Audit-Trail: >Unformatted: