This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
preprocessor/7862: Interrupting gcc -MD removes .d file but not .o
- From: jason at redhat dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 9 Sep 2002 12:17:13 -0000
- Subject: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o
- Reply-to: jason at redhat dot com
>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: