[Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree

[nicow.mattia at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287

Bug ID: 108287
   Summary: AVR build: gcc/config/avr/t-avr tries to edit the
source tree
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicow.mattia at gmail dot com
  Target Milestone: ---

This only occurs when building for target=avr.

As per the build instructions, I'm building GCC out of the source tree. The
configure call looks like this:

```
$src/configure \
  --target=avr \
  --prefix=$out \
   ...
```

Here, `$src` is a RO directory, and the build will eventually fail like this:

```
...
g++ -std=gnu++11 
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/config/avr/gen-avr-mmcu-texi.cc
-o gen-avr-mmcu-texi
./gen-avr-mmcu-texi >
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/doc/avr-mmcu.texi
/bin/sh:
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/doc/avr-mmcu.texi:
Permission denied
```

The culprit is `gcc/config/avr/t-avr` at line 94:

```
$(srcdir)/doc/avr-mmcu.texi: gen-avr-mmcu-texi$(build_exeext)
$(RUN_GEN) ./$< > $@
```

I'm currently using the following patch to work around the issue:

```
diff --git a/gcc/config/avr/t-avr b/gcc/config/avr/t-avr
index deadbeef..deadbeef 100644
--- a/gcc/config/avr/t-avr  2023-01-03 21:56:23
+++ b/gcc/config/avr/t-avr  2023-01-03 21:56:32
@@ -91,9 +91,6 @@
   $(srcdir)/config/avr/avr-arch.h $(TM_H)
$(CXX_FOR_BUILD) $(CXXFLAGS_FOR_BUILD) $< -o $@ $(INCLUDES)

-$(srcdir)/doc/avr-mmcu.texi: gen-avr-mmcu-texi$(build_exeext)
-   $(RUN_GEN) ./$< > $@
-
 s-device-specs: gen-avr-mmcu-specs$(build_exeext)
rm -rf device-specs
mkdir device-specs && cd device-specs && $(RUN_GEN) ../$<
```

[Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree

[nicow.mattia at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287

--- Comment #3 from Nicolas Mattia  ---
(In reply to Andrew Pinski from comment #1)
> The best fix is do something similar to aarch64 in config/aarch64/t-aarch64:
> $(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
> s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
> $(srcdir)/config/aarch64/aarch64-cores.def
> $(SHELL) $(srcdir)/config/aarch64/gentune.sh \
> $(srcdir)/config/aarch64/aarch64-cores.def > \
> tmp-aarch64-tune.md
> ifneq ($(strip $(ENABLE_MAINTAINER_RULES)),)
> $(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
> $(srcdir)/config/aarch64/aarch64-tune.md
> else
> @if ! cmp -s tmp-aarch64-tune.md \
>   $(srcdir)/config/aarch64/aarch64-tune.md; then \
>   echo "aarch64-tune.md has changed; either"; \
>   echo "configure with --enable-maintainer-mode"; \
>   echo "or copy tmp-aarch64-tune.md to
> $(srcdir)/config/aarch64/aarch64-tune.md"; \
>   exit 1; \
> fi
> endif
> $(STAMP) s-aarch64-tune-md
> 
> I suspect the issue is rather the timestamp on the files is incorrect
> causing the trying of generating of the file.

I see you already confirmed, so let me re-confirm. Not only is the `$src`
directory read-only, but all timestamps are set to the epoch.

I'm happy to contribute the fix but will need some hand holding!