This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]