I am seeing the same behavior building gcc 4.8.0 locally using the following options to ./configure:

--enable-languages=c,c++ \
--enable-bootstrap \
--enable-lto \
--enable-threads=posix \
--disable-checking \
--enable-long-long \
--enable-__cxa_atexit \
--enable-clocale=generic \
--disable-multilib \
--with-system-zlib \
--prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--libexecdir=/usr/lib \
--sysconfdir=/etc \
--localstatedir=/var \
--libdir=/usr/lib \
--includedir=/usr/include \
--datadir=/usr/share \
--mandir=/usr/share/man \
--disable-nls \
--disable-silent-rules \
--disable-dependency-tracking

Created attachment 30880 [details]
patch which fixes the problem

This patch fixes the build failure when --disable-dependency-tracking is passed

Still occurs with 4.9.2 (and the same patch still fixes it).

This is still relevant for version 6.2.0.

(In reply to Richard Purdie from comment #2)
> Created attachment 30880 [details]
> patch which fixes the problem
> 
> This patch fixes the build failure when --disable-dependency-tracking is
> passed

Patches should be posted to gcc-patches@ .

But the bigger question is why  are you passing --disable-dependency-tracking
 ?

(In reply to Andrew Pinski from comment #5)
> (In reply to Richard Purdie from comment #2)
> > Created attachment 30880 [details]
> > patch which fixes the problem
> > 
> > This patch fixes the build failure when --disable-dependency-tracking is
> > passed
> 
> Patches should be posted to gcc-patches@ .
> 
> But the bigger question is why  are you passing --disable-dependency-tracking
>  ?

Its part of a Yocto Project build and we would only ever build it once so we don't need/want the overhead of the dependency tracking information.

Did the patch ever get sent to the gcc-patches list?

(In reply to Richard Purdie from comment #6)
> Its part of a Yocto Project build and we would only ever build it once so we
> don't need/want the overhead of the dependency tracking information.

But is there any noticeable overhead when using GCC to bootstrap?

Automake documents the option as:

  Some compilers do not offer any practical way to derive the list of
  dependencies as a side-effect of the compilation, requiring a separate
  run (maybe of another tool) to compute these dependencies. The performance
  penalty implied by these methods is important enough to disable them by
  default.

That doesn't apply here though, because GCC is generating the dependencies via -MD as a side effect of compilation. So there should be no need to use the option (other than saving a bit of disk space during the build).

(In reply to Jonathan Wakely from comment #8)
> (In reply to Richard Purdie from comment #6)
> > Its part of a Yocto Project build and we would only ever build it once so we
> > don't need/want the overhead of the dependency tracking information.
> 
> But is there any noticeable overhead when using GCC to bootstrap?
> 
> Automake documents the option as:
> 
>   Some compilers do not offer any practical way to derive the list of
>   dependencies as a side-effect of the compilation, requiring a separate
>   run (maybe of another tool) to compute these dependencies. The performance
>   penalty implied by these methods is important enough to disable them by
>   default.
> 
> That doesn't apply here though, because GCC is generating the dependencies
> via -MD as a side effect of compilation. So there should be no need to use
> the option (other than saving a bit of disk space during the build).

We pass this option in globally to anything using automake so whilst for one piece of software it might not be a huge gain, over a complete Linux stack built from source the disk space (lack of IO) speed wins are useful alone.

Confirmed that this issue persists in 9.1.0:

libtool: compile:  /tmp/gcc-9.1.0.build/./gcc/xgcc -B/tmp/gcc-9.1.0.build/./gcc/ -B/opt/gnu/x86_64-pc-linux-gnu/bin/ -B/opt/gnu/x86_64-pc-linux-gnu/lib/ -isystem /opt/gnu/x86_64-pc-linux-gnu/include -isystem /opt/gnu/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H -I/home/src/gcc/gcc-9.1.0/libatomic/config/x86 -I/home/src/gcc/gcc-9.1.0/libatomic/config/posix -I/home/src/gcc/gcc-9.1.0/libatomic -I. -Wall -Werror -pthread -g -O2 -MT load_1_.lo -MD -MP -MF .deps/load_1_.lo.Ppo -DN=1 -c /home/src/gcc/gcc-9.1.0/libatomic/load_n.c  -fPIC -DPIC -o load_1_.o
/home/src/gcc/gcc-9.1.0/libatomic/load_n.c:115:1: fatal error: opening dependency file .deps/load_1_.lo.Ppo: No such file or directory
  115 | EXPORT_ALIAS (SIZE(load));
      | ^~~~~~~~~~~~
compilation terminated.
gmake[4]: *** [load_1_.lo] Error 1
gmake[4]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/tmp/gcc-9.1.0.build/x86_64-pc-linux-gnu/libatomic'
gmake[1]: *** [all-target-libatomic] Error 2
gmake[1]: Leaving directory `/tmp/gcc-9.1.0.build'
gmake: *** [bootstrap-lean] Error 2

I'd like to echo Mr. Purdie's "We pass this option in globally to anything using automake" as the approach my site uses as well.

I still think the solution is "don't do that for gcc" but in any case, the patch still hasn't been sent to the mailing list so isn't going to get reviewed let alone applied.

I started to look at sorting out Yocto Project/Openembedded's gcc patches in general and ran into a contribution agreement legal quagmire. I still haven't been able to resolve that.

OK thanks for the update. I think your patch for this bug is trivial enough to not require any paperwork.

(In reply to Andrew Pinski from comment #5)
> But the bigger question is why  are you passing --disable-dependency-tracking
>  ?

I ran into this issue because Debian's debhelper's dh_auto_configure passes --disable-dependency-tracking automatically. ("Know your build tools" is the lesson here, I guess.)

(In reply to Stephen Kitt from comment #14)
> (In reply to Andrew Pinski from comment #5)
> > But the bigger question is why  are you passing --disable-dependency-tracking
> >  ?
> 
> I ran into this issue because Debian's debhelper's dh_auto_configure passes
> --disable-dependency-tracking automatically. ("Know your build tools" is the
> lesson here, I guess.)

There's other projects that automatically turn on --disable-dependency-tracking, too. MacPorts automatically passes --disable-dependency-tracking for all ports using the +universal variant, for example.

The GCC 7 branch is being closed, re-targeting to GCC 8.4.

The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:d6f420d98126ac51396b89fbe287a32287cd92ed

commit r10-6797-gd6f420d98126ac51396b89fbe287a32287cd92ed
Author: Richarde Purdie <rpurdie@rpsys.net>
Date:   Sat Feb 22 10:13:13 2020 -0500

    Honor --disable-dependency-tracking in libatomic
    
    	PR other/55930
    	* Makefile.am (M_DEPS): Honor -disable-dependency-tracking.
    	* Makefile.in: Regenerated.

I concur with Jon, this is trivial enough not to need any kind of paperwork.  I've committed the patch to the trunk.  I'm not planning to backport, but I wouldn't object if someone else did.

Thanks for the patch Richard.  Jon, thanks for marking the regression.  Otherwise it would have been missed for (yet another) cycle.

The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:128ff73d7c5b70b20991b191b64a27d64145d762

commit r10-6799-g128ff73d7c5b70b20991b191b64a27d64145d762
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Feb 22 19:55:09 2020 +0100

    libatomic: Fix last change [PR55930]
    
    2020-02-22  Jakub Jelinek  <jakub@redhat.com>
    
    	PR other/55930
    	* Makefile.am (M_DEPS): Guard the empty definition with
    	@AMDEP_FALSE@ rather than @AMDEP_TRUE@.
    	* Makefile.in: Regenerated.

GCC 8.4.0 has been released, adjusting target milestone.

I'm compiling gfortran in yocto project, but during do_configure it throw out an error:
unrecognized options: --disable-dependency-tracking

I grep disable-dependency-tracking is yocto layer "core/meta/recipes-devtools/gcc" and find key-word "disable-dependency-tracking" in ./gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch and ./gcc-9.2.inc. Followings are detailed output from grep:
./gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch:Subject: [PATCH 20/36] gcc 4.8+ won't build with --disable-dependency-tracking
./gcc-9.2.inc:           file://0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch \


It seems do_configure use "--disable-dependency-tracking" to compile, but this option is unrecognized. So how to apply "0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch" to do_configure? 

I'm new to yocto, please forgive my ignorance.

Created attachment 49526 [details]
gfortran config log

Created attachment 49527 [details]
gfortran.do_configure

this is the do_configure log where unrecognized disable-dependency-tracking occurs.

GCC 8 branch is being closed.

GCC 9.4 is being released, retargeting bugs to GCC 9.5.

Fixed in GCC 10.