Re: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o

Re: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o

[jason]

Synopsis: Interrupting gcc -MD removes .d file but not .o

Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: jason
Responsible-Changed-When: Mon Sep  9 05:30:53 2002
Responsible-Changed-Why:
    you wrote the current code

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7862

Re: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o

[neil]

Synopsis: Interrupting gcc -MD removes .d file but not .o

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sat Oct 12 10:13:16 2002
State-Changed-Why:
    Fixed by not deleting the .d file on interruption.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7862

preprocessor/7862: Interrupting gcc -MD removes .d file but not .o

[jason]

>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: