public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: jason@redhat.com
To: gcc-gnats@gcc.gnu.org
Subject: preprocessor/7862: Interrupting gcc -MD removes .d file but not .o
Date: Mon, 09 Sep 2002 05:26:00 -0000	[thread overview]
Message-ID: <20020909121713.29028.qmail@sources.redhat.com> (raw)


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


             reply	other threads:[~2002-09-09 12:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-09  5:26 jason [this message]
2002-09-09  5:30 jason
2002-10-12 10:13 neil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020909121713.29028.qmail@sources.redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).