[Bug target/55243] New: STAMP variable is not defined in t-avr

[Bug target/55243] New: STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

             Bug #: 55243
           Summary: STAMP variable is not defined in t-avr
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rolf.ebert.gcc@gmx.de


Building AVR cross compiler for Ada (GNAT) fails as t-avr contains no valid
command in the STAMP variable

easiest work-around is to replace it with 'echo' command.

sed -i -e 's/$(STAMP)/echo timestamp >/' gcc/config/avr/t-avr

[Bug target/55243] STAMP variable is not defined in t-avr

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-11-08 21:51:21 UTC ---
STAMP should be set.  Can you provide the full log of the error?

[Bug target/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #2 from Rolf Ebert <rolf.ebert.gcc at gmx dot de> 2012-11-08 22:08:16 UTC ---
A complete build instruction is in 

http://arduino.ada-language.com/building-avr-gnat-for-avr-ada.html

I'll add a make output without the patch once I can build again (probably
tomorrow)

[Bug target/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #3 from Rolf Ebert <rolf.ebert.gcc at gmx dot de> 2012-11-11 21:29:58 UTC ---
Here is the requested build log:

make[2]: Entering directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gnattools'
rm -rf ../gcc/ada/tools
mkdir -p ../gcc/ada/tools
(cd ../gcc/ada/tools; cp -p ../sdefault.adb ../snames.ads ../snames.adb .)
rm -f ../gcc/ada/tools/mlib-tgt-specific.adb; cp -p
/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada/mlib-tgt-specific-xi.adb
../gcc/ada/tools/mlib-tgt-specific.adb;  rm -f ../gcc/ada/tools/indepsw.adb; cp
-p /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada/indepsw-gnu.adb
../gcc/ada/tools/indepsw.adb;
touch ../gcc/stamp-tools
# gnattools1-re
make -C ../gcc/ada/tools -f ../Makefile \
          "CC=gcc" "CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall"
"LDFLAGS=-Wl,--stack,12582912" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS="
"INCLUDES=-I. -I.. -I../.. -I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada
-I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config
-I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/../include
-I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc"
"ADA_INCLUDES=-IC:/Programme/MinGW2011/local/lib/gcc/mingw32/4.7.0/adalib/../adainclude
-IC:/Programme/MinGW2011/local/lib/gcc/mingw32/4.7.0/adalib/ -I.
-I/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/ada" "exeext=.exe"
"fsrcdir=/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc"
"srcdir=/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc" "GNATMAKE=gnatmake"
"GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT="
INCLUDES="" \
          gnatmake-re gnatlink-re
make[3]: Entering directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gcc/ada/tools'
gawk -f /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/genmultilib.awk -v
FORMAT=Makefile  
/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/genmultilib.awk
/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/avr-mcus.def > tmp-avr-mlib
/bin/sh /c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/../move-if-change \
                tmp-avr-mlib   
/c/Devel/gcc-cvs.not/build/gcc-4.7.2/gcc/config/avr/t-multilib
s-avr-mlib
make[3]: s-avr-mlib: Command not found
make[3]: *** [s-avr-mlib] Error 127
make[3]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gcc/ada/tools'
make[2]: *** [gnattools-cross] Error 2
make[2]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj/gnattools'
make[1]: *** [all-gnattools] Error 2
make[1]: Leaving directory `/c/Devel/gcc-cvs.not/build/gcc-obj'
make: *** [all] Error 2

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |ada

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-11-14 00:00:24 UTC ---
t-avr is the wrong place to set STAMP, it should be set in some Makefile(.in),
presumable in the ada part, somewhere around

./gcc/ada/gcc-interface/Makefile.in

You see STAMP being mentioned in repsective config.log?

[Bug ada/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #5 from Rolf Ebert <rolf.ebert.gcc at gmx dot de> 2012-11-17 10:02:49 UTC ---
STAMP isn't set by configure. It is rather hardcoded in gcc/Makefile.in

Correspondignly it has to be set in gnattools/Makefile.in, too:

--- gnattools/Makefile.in~    2011-10-13 00:41:57 +0200
+++ gnattools/Makefile.in    2012-11-16 20:50:48 +0100
@@ -111,6 +111,7 @@
     "GNATMAKE=gnatmake" \
     "GNATLINK=gnatlink" \
     "GNATBIND=gnatbind" \
+    "STAMP=echo timestamp >" \
     "TOOLSCASE=cross" \
     "LIBGNAT="

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-29
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-11-29 14:19:00 UTC ---
The GNAT tools are for the host, they have nothing to do with multilibs.  How
come the s-avr-mlib Makefile rule gets invoked here?

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gjl at gcc dot gnu.org

--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-02 23:17:19 UTC ---
(In reply to comment #6)
> The GNAT tools are for the host, they have nothing to do with multilibs.  How
> come the s-avr-mlib Makefile rule gets invoked here?

avr-gcc supports around 200 devices.  In order to keep the various parts of the
compiler in sync, some files are auto-generated from the device description in
$(srcdir)/config/avr/avr-mcus.def.

$(srcdir)/config/avr/t-avr reads:

...

AVR_MCUS = $(srcdir)/config/avr/avr-mcus.def

...

# MULTILIB_OPTIONS
# MULTILIB_DIRNAMES
# MULTILIB_EXCEPTIONS
# MULTILIB_MATCHES
$(srcdir)/config/avr/t-multilib: s-avr-mlib; @true

s-mlib: $(srcdir)/config/avr/t-multilib

s-avr-mlib: $(srcdir)/config/avr/genmultilib.awk $(AVR_MCUS)
    $(AWK) -f $< -v FORMAT=Makefile   $< $(AVR_MCUS) > tmp-avr-mlib
    $(SHELL) $(srcdir)/../move-if-change \
        tmp-avr-mlib     $(srcdir)/config/avr/t-multilib
    $(STAMP) $@


And in config.gcc there is 

tmake_file="avr/t-avr avr/t-multilib"


Thus, the assumption is that AWK, SHELL and STAMP are set correctly and
respective tools are available on the build platform.

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-03 06:39:56 UTC ---
> And in config.gcc there is 
> 
> tmake_file="avr/t-avr avr/t-multilib"
> 
> 
> Thus, the assumption is that AWK, SHELL and STAMP are set correctly and
> respective tools are available on the build platform.

OK, but the question is why this rule is invoked during the gnattools build? 
Moreover, why does s-avr-mlib need to be rebuilt at this point since it has
presumably already been built for the target libraries?

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-03 13:37:35 UTC ---
(In reply to comment #8)

> OK, but the question is why this rule is invoked during the gnattools build? 
> Moreover, why does s-avr-mlib need to be rebuilt at this point since it has
> presumably already been built for the target libraries?

I don't know anything about the gnat build system and when I build avr-gcc I
configure for C/C++.

What's odd is that even if GCC is only configured for C/C++, I get messages
about a missing gnatls.  For example, running make in the gcc subdirectory of
build prints

$build/gcc> make
/bin/sh: gnatls: command not found

The build itself works fine but that message is confusing and shows that
something is wrong with the gnat build system.

gnat stuff should not be needed of the compiler is not configured for ada,
should it?

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-03 14:35:35 UTC ---
> I don't know anything about the gnat build system and when I build avr-gcc I
> configure for C/C++.
> 
> What's odd is that even if GCC is only configured for C/C++, I get messages
> about a missing gnatls.  For example, running make in the gcc subdirectory of
> build prints
> 
> $build/gcc> make
> /bin/sh: gnatls: command not found
> 
> The build itself works fine but that message is confusing and shows that
> something is wrong with the gnat build system.
> 
> gnat stuff should not be needed of the compiler is not configured for ada,
> should it?

Probably, but if nobody really investigates, nothing will ever be fixed.

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #11 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 17:00:50 UTC ---
(In reply to comment #10)
>> I don't know anything about the gnat build system and when I build avr-gcc I
>> configure for C/C++.
>> 
>> What's odd is that even if GCC is only configured for C/C++, I get messages
>> about a missing gnatls.  For example, running make in the gcc subdirectory of
>> build prints
>> 
>> $build/gcc> make
>> /bin/sh: gnatls: command not found
>> 
>> The build itself works fine but that message is confusing and shows that
>> something is wrong with the gnat build system.
>> 
>> gnat stuff should not be needed of the compiler is not configured for ada,
>> should it?
> 
> Probably, but if nobody really investigates, nothing will ever be fixed.

$(build)/gcc/Makefile reads:


# per-language makefile fragments
ifneq ($(LANG_MAKEFRAGS),)
include $(LANG_MAKEFRAGS)
endif

# target and host overrides must follow the per-language makefile fragments
# so they can override or augment language-specific variables

# target overrides
ifneq ($(tmake_file),)
include $(tmake_file)
endif


LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn
contains:

    # put the host RTS dir first in the PATH to hide the default runtime
    # files that are among the sources
    RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib )))

which means gnatls is called no matter if it exists or not.

(In reply to comment #6)

> The GNAT tools are for the host, they have nothing to do with multilibs.
>  How come the s-avr-mlib Makefile rule gets invoked here?

The Makefile includes $(tmake_file) and thus
$(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP)
to build.

AFAIK make resolves its includes before it starts building the targets.

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 18:00:20 UTC ---
> LANG_MAKEFRAGS contains $(srcdir)/ada/gcc-interface/Make-lang.in which in turn
> contains:
> 
>     # put the host RTS dir first in the PATH to hide the default runtime
>     # files that are among the sources
>     RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib )))
> 
> which means gnatls is called no matter if it exists or not.

OK, thanks for investigating.  Tentative patch for ada/ to be attached.

> The Makefile includes $(tmake_file) and thus
> $(srcdir)/gcc/config/avr/t-multilib which is auto-generated and needs $(STAMP)
> to build.
> 
> AFAIK make resolves its includes before it starts building the targets.

So t-multilib is autogenerated in the source tree during the build???

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 18:02:19 UTC ---
Created attachment 28916
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28916
Tentative fix for gnatls issue

To be applied in the ada/ source directory.

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #14 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 18:25:19 UTC ---
(In reply to comment #12)

> So t-multilib is autogenerated in the source tree during the build???

Jepp.  Top $(srcdir)/gcc/config/avr/t-multilib reads:


# Auto-generated Makefile Snip
# Generated by    : ./gcc/config/avr/genmultilib.awk
# Generated from  : ./gcc/config/avr/avr-mcus.def
# Used by         : tmake_file from Makefile and genmultilib


Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. 
In order to keep various parts of the compiler in sync, some bits are
auto-generated, amongst them documentation, t-multilib and .opt parts.

Procedure is a move-if-change scheme, i.e. the auto-generated files are in the
repository and the procedure to build them is similar to building configure
from configure.ac and then putting both configure.ac /and/ configure into the
repo.

However, the auto-build runs automatically and thus needs some tools, namely 
$(SHELL), $(AWK), $(CC_FOR_BUILD), $(RUN_GEN) and $(STAMP).

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #15 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 18:36:33 UTC ---
(In reply to comment #13)
> Created attachment 28916 [details]
> Tentative fix for gnatls issue
> 
> To be applied in the ada/ source directory.

This works for me with, i.e. the 
/bin/sh: gnatls: command not found
is gone.

$ ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2
--enable-target-optspace=yes --enable-languages=c,c++

build:  i686-pc-linux-gnu
host:   i686-pc-linux-gnu
target: avr-unknown-none

Someone else will have to test if it works if Ada is on.  BTW, today is Ada's
birthday :-)

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 18:47:13 UTC ---
> > So t-multilib is autogenerated in the source tree during the build???
> 
> Jepp.  Top $(srcdir)/gcc/config/avr/t-multilib reads:
> 
> 
> # Auto-generated Makefile Snip
> # Generated by    : ./gcc/config/avr/genmultilib.awk
> # Generated from  : ./gcc/config/avr/avr-mcus.def
> # Used by         : tmake_file from Makefile and genmultilib

But this is a no-no, the compiler should be buildable with read-only sources
once it is packaged in the release tarballs.

> Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. 
> In order to keep various parts of the compiler in sync, some bits are
> auto-generated, amongst them documentation, t-multilib and .opt parts.
> 
> Procedure is a move-if-change scheme, i.e. the auto-generated files are in the
> repository and the procedure to build them is similar to building configure
> from configure.ac and then putting both configure.ac /and/ configure into the
> repo.

Building configure from configure.c isn't done at build time.

Either you generate t-multilib like configure and you can put it in $(srcdir)
or you generate it at build time and you must put it in $(builddir).

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 18:49:19 UTC ---
> This works for me with, i.e. the 
> /bin/sh: gnatls: command not found
> is gone.
> 
> $ ../../gcc.gnu.org/trunk/configure --target=avr
> --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2
> --enable-target-optspace=yes --enable-languages=c,c++
> 
> build:  i686-pc-linux-gnu
> host:   i686-pc-linux-gnu
> target: avr-unknown-none
> 
> Someone else will have to test if it works if Ada is on.  BTW, today is Ada's
> birthday :-)

It works.  Thanks for testing, I'm going to apply it on the mainline.

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #18 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 20:41:15 UTC ---
(In reply to comment #16)
>>> So t-multilib is autogenerated in the source tree during the build???
>> 
>> Jepp.  Top $(srcdir)/gcc/config/avr/t-multilib reads:
>> 
>> 
>> # Auto-generated Makefile Snip
>> # Generated by    : ./gcc/config/avr/genmultilib.awk
>> # Generated from  : ./gcc/config/avr/avr-mcus.def
>> # Used by         : tmake_file from Makefile and genmultilib
> 
> But this is a no-no, the compiler should be buildable with read-only sources
> once it is packaged in the release tarballs.


It works with read-only sources, provided everything is consistent.  Or are you
saying that a t-snip must not use $(STAMP)?

Actually, the PR boils down to the fact the STAMP is not defined, I am nut sure
if the compiler is supposed to build without STAMP.

>> Rationale is that avr-gcc supports an, IMHO, insane number of -mmcu=<device>. 
>> In order to keep various parts of the compiler in sync, some bits are
>> auto-generated, amongst them documentation, t-multilib and .opt parts.
>> 
>> Procedure is a move-if-change scheme, i.e. the auto-generated files are in the
>> repository and the procedure to build them is similar to building configure
>> from configure.ac and then putting both configure.ac /and/ configure into the
>> repo.
> 
> Building configure from configure.c isn't done at build time.
> 
> Either you generate t-multilib like configure and you can put it in $(srcdir)
> or you generate it at build time and you must put it in $(builddir).

Is basically follows an idea introduced with genopt.sh in

http://gcc.gnu.org/viewcvs?view=revision&revision=175248

Notice how t-avr builds avr-tables.opt, and that the latter is added to the
repo.

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 21:17:52 UTC ---
> It works with read-only sources, provided everything is consistent.  Or are
> you saying that a t-snip must not use $(STAMP)?

I'm saying that the build process should never touch the source tree.

> Actually, the PR boils down to the fact the STAMP is not defined, I am nut
> sure if the compiler is supposed to build without STAMP.

Probably not, but what I'm trying to understand is why we seem to be fiddling
with the source tree when building the gnattools.

> Is basically follows an idea introduced with genopt.sh in
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=175248
> 
> Notice how t-avr builds avr-tables.opt, and that the latter is added to the
> repo.

The point is that, if a file is present in the repo, it should not be generated
at build time, but only when it is updated in the repo.

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #20 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-10 22:57:41 UTC ---
(In reply to comment #19)
>> It works with read-only sources, provided everything is consistent.  Or are
>> you saying that a t-snip must not use $(STAMP)?
> 
> I'm saying that the build process should never touch the source tree.

Isn't ./gcc/doc/md.texi both in the repo and generated (from
./gcc/doc/md.texi.in)?  And, if parts of the docs are changed you will we
nagged to verify GFDL and to copy the new, auto-generated parts in place?

>> Actually, the PR boils down to the fact the STAMP is not defined, I am not
>> sure if the compiler is supposed to build without STAMP.
> 
> Probably not, but what I'm trying to understand is why we seem to be fiddling
> with the source tree when building the gnattools.

As far as gnattools are concerned, it makes no difference whether the
auto-generated files are stamped and written to $build or stamped and written
to $source.

I agree that the $source vs. $build matter should be cleaned up.

However, that won't help with this PR because the rules and the dependencies
and the needed tools will remain the same.

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-10 23:13:05 UTC ---
> As far as gnattools are concerned, it makes no difference whether the
> auto-generated files are stamped and written to $build or stamped and written
> to $source.
> 
> I agree that the $source vs. $build matter should be cleaned up.
> 
> However, that won't help with this PR because the rules and the dependencies
> and the needed tools will remain the same.

So we're back to square one: why on Earth does this file need to be regenerated
when the gnattools are built, since it has already been generated previously
during the build (in addition to being already present in the source tree)?

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #22 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-11 12:18:23 UTC ---
(In reply to comment #21)

What I don't understand is what is bad with Rolf's proposal of defining STAMP?

Stamping is not that unusual in the build process.  Up to now it was not
needed, but is it that critical to set STAMP like proposed above?

[Bug ada/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #23 from Rolf Ebert <rolf.ebert.gcc at gmx dot de> 2012-12-11 19:57:34 UTC ---
I see Eric's point in that the patch in comment #5 hides another bug in the
Makefile chemistry. There seems to be an unnecessary dependency from the
gnattools on multilibs.  Reminds me of #19959

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-12 11:35:07 UTC ---
> What I don't understand is what is bad with Rolf's proposal of defining STAMP?

We simply don't need to stamp anything for the gnattools.

> Stamping is not that unusual in the build process.  Up to now it was not
> needed, but is it that critical to set STAMP like proposed above?

Well, building the gnattools works flawlessly for all targets except for AVR,
because of a very questionable kludge.  So it makes sense to fix the kludge.

[Bug ada/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #25 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-14 18:26:07 UTC ---
Created attachment 28960
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28960
Don't use STAMP to please Ada

(In reply to comment #24)
> > What I don't understand is what is bad with Rolf's proposal of defining STAMP?
> 
> We simply don't need to stamp anything for the gnattools.

Notice $(srcdir)/gcc/ada/gcc-interface/Makefile.in reads:

# target overrides
ifneq ($(tmake_file),)
include $(tmake_file)
endif

# host overrides
ifneq ($(xmake_file),)
include $(xmake_file)
endif

There are other backends like x86 and mips that use STAMP in their t-snip, so I
wonder how you can conclude that ada does not include code that might require
STAMP?

Here is a patch that bypasses the need of STAMP in t-avr.  Rolf can test it.


    PR55243
    * config/avr/t-avr: Don't automatically rebuild
    $(srcdir)/config/avr/t-multilib
    $(srcdir)/config/avr/avr-tables.opt
    $(srcdir)/doc/avr-mmcu.texi
    (avr-mcus): New phony target to build them on request.
    (s-avr-mlib, s-avr-mmcu-texi): Remove.
    * avr/avr-mcus.def: Adjust comments.

[Bug ada/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-14 18:32:02 UTC ---
> Notice $(srcdir)/gcc/ada/gcc-interface/Makefile.in reads:
> 
> # target overrides
> ifneq ($(tmake_file),)
> include $(tmake_file)
> endif
> 
> # host overrides
> ifneq ($(xmake_file),)
> include $(xmake_file)
> endif
> 
> There are other backends like x86 and mips that use STAMP in their t-snip, so
> I wonder how you can conclude that ada does not include code that might 
> require STAMP?

I didn't say that though, rather that we don't need STAMP for the gnattools.
Of course we need it for the Ada compiler proper, like the other compilers.

> Here is a patch that bypasses the need of STAMP in t-avr.  Rolf can test it.
> 
> 
>     PR55243
>     * config/avr/t-avr: Don't automatically rebuild
>     $(srcdir)/config/avr/t-multilib
>     $(srcdir)/config/avr/avr-tables.opt
>     $(srcdir)/doc/avr-mmcu.texi
>     (avr-mcus): New phony target to build them on request.
>     (s-avr-mlib, s-avr-mmcu-texi): Remove.
>     * avr/avr-mcus.def: Adjust comments.

Nice, thanks.

[Bug target/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ada                         |target

--- Comment #27 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-16 11:08:26 UTC ---
.

[Bug target/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #28 from Rolf Ebert <rolf.ebert.gcc at gmx dot de> 2012-12-17 19:25:30 UTC ---
Created attachment 28988
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28988
Backport of gjl's patch to 4.7

I had to backport Georg's patch to 4.7.2.  It perferctly solves the issue and I
can build the AVR cross for Ada

  Rolf

[Bug target/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #29 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-12-17 22:53:42 UTC ---
(In reply to comment #24)
>> What I don't understand is what is bad with Rolf's proposal of defining STAMP?
> 
> We simply don't need to stamp anything for the gnattools.
> 
>> Stamping is not that unusual in the build process.  Up to now it was not
>> needed, but is it that critical to set STAMP like proposed above?
> 
> Well, building the gnattools works flawlessly for all targets except for AVR,

That argument doues not count, IMO.

Almost nothing in GCC was added without precedent: Features were added because
backend X needed them or frontend Y needed them.  To reject an extension just
because only one target needs it, is not an convincing argument.

It's still not known why the ada / gnat stuff rebuilds stuff already there a
sectons time and at a stage ada / gnat don't expect such a build.

Throwing out the need of STAMP works, but it does not answer the question why
ada does things it does not expect at a stage it does not expect.

(In reply to comment #26)

>> There are other backends like x86 and mips that use STAMP in their t-snip, so
>> I wonder how you can conclude that ada does not include code that might 
>> require STAMP?
>
>I didn't say that though, rather that we don't need STAMP for the gnattools.

If I understand correctly, someone familiar with the gnat build machiney and
philosophy might want to find out why it performs a mistimed rebuild of things
that are elready supposed to be there?  

BTW, avr/t-multilib cannot be generated from scratch in the build directory
because it is included in Makefile.  The dependencies in
gcc_update:files_and_dependencies() look reasonable.

[Bug target/55243] STAMP variable is not defined in t-avr

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #30 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-20 21:45:11 UTC ---
> Almost nothing in GCC was added without precedent: Features were added because
> backend X needed them or frontend Y needed them.  To reject an extension just
> because only one target needs it, is not an convincing argument.

I totally disagree of course.  You must first try to fit in the existing design
and, only when that fails, you're allowed to propose extensions.

> It's still not known why the ada / gnat stuff rebuilds stuff already there a
> sectons time and at a stage ada / gnat don't expect such a build.

Indeed.

> If I understand correctly, someone familiar with the gnat build machiney and
> philosophy might want to find out why it performs a mistimed rebuild of things
> that are elready supposed to be there?  

Yes, that's the crux of the matter.

[Bug target/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

--- Comment #31 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2013-01-07 13:12:18 UTC ---
Author: gjl
Date: Mon Jan  7 13:12:10 2013
New Revision: 194970

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194970
Log:
    Backport from 2013-01-07 trunk r194968.

    PR other/55243
    * config/avr/t-avr: Don't automatically rebuild
    $(srcdir)/config/avr/t-multilib
    $(srcdir)/config/avr/avr-tables.opt
    (avr-mcus): New phony target to build them on request.
    (s-avr-mlib): Remove.
    * avr/avr-mcus.def: Adjust comments.


Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config/avr/avr-mcus.def
    branches/gcc-4_7-branch/gcc/config/avr/t-avr

[Bug target/55243] STAMP variable is not defined in t-avr

[gjl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5
             Status|NEW                         |RESOLVED
      Known to work|                            |4.7.3
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.3

--- Comment #32 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2013-01-07 13:16:24 UTC ---
Fixed for 4.7.3

Change set for trunk:
http://gcc.gnu.org/viewcvs?view=revision&amp;revision=194968