[Bug testsuite/36443] New: HOST_CC doesn't work with --disable-bootstrap

[Bug testsuite/36443] New: HOST_CC doesn't work with --disable-bootstrap

[hjl dot tools at gmail dot com]

When --disable-bootstrap, HOST_CC is set to gcc. It is
used in

g++.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]
gcc.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]
objc.dg/gnu-encoding/gnu-encoding.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]

"make check" will create site.exp with

set GCC_EXEC_PREFIX "$(libdir)/gcc/"

This will make system gcc 4.1 and 4.3 fail to compile
since they can't find their own head files.


-- 
           Summary: HOST_CC doesn't work with --disable-bootstrap
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-05 21:32 -------
--disable-bootstrap should not be used really, why are you using it anyways?


-- 


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

[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2008-06-05 21:34 -------
(In reply to comment #1)
> --disable-bootstrap should not be used really, why are you using it anyways?
> 

There is no easy way to debug gcc compiled with -O2.

Why do we put

set GCC_EXEC_PREFIX "$(libdir)/gcc/"

in site.exp when we aren't testing installed gcc?


-- 


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

Re: [Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap

[Andrew Pinski]

On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> There is no easy way to debug gcc compiled with -O2.

You know if you compile cc1 manually inside the gcc directory, it will
compile with -O0 -g.  Also you can use stage1-gcc directory to debug
and build cc1plus, etc.

-- Pinski

[Bug testsuite/36443] HOST_CC doesn't work with --disable-bootstrap

[pinskia at gmail dot com]

------- Comment #3 from pinskia at gmail dot com  2008-06-05 21:42 -------
Subject: Re:  HOST_CC doesn't work with --disable-bootstrap

On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> There is no easy way to debug gcc compiled with -O2.

You know if you compile cc1 manually inside the gcc directory, it will
compile with -O0 -g.  Also you can use stage1-gcc directory to debug
and build cc1plus, etc.

-- Pinski


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOST_CC doesn't work with --disable-bootstrap

[hjl dot tools at gmail dot com]

------- Comment #4 from hjl dot tools at gmail dot com  2008-06-05 21:58 -------
This behavior was introduced by

http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html

I rarely install gcc on my build machines. I am not
sure why they are needed for testing gcc just built.
If they are used for testing installed gcc, shouldn't
there be different targets?


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at codesourcery dot
                   |                            |com, mark at codesourcery
                   |                            |dot com
            Summary|HOST_CC doesn't work with --|[4.3/4.4 Regression]:
                   |disable-bootstrap           |HOST_CC doesn't work with --
                   |                            |disable-bootstrap


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2008-06-06 21:02 -------
From:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00350.html

the problem isn't limited to --disable-bootstrap.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com
            Summary|[4.3/4.4 Regression]:       |[4.3/4.4 Regression]: HOSTCC
                   |HOST_CC doesn't work with --|doesn't work with unstalled
                   |disable-bootstrap           |gcc


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #6 from hjl dot tools at gmail dot com  2008-06-06 21:09 -------
You only see it your system compiler is gcc 4.3 or above

[hjl@gnu-6 tmp]$ cat x.c
#include <limits.h>
[hjl@gnu-6 tmp]$ GCC_EXEC_PREFIX=/foo gcc -M x.c 
In file included from x.c:1:
/usr/include/limits.h:125:26: error: no include path in which to search for
limits.h
[hjl@gnu-6 tmp]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) 
[hjl@gnu-6 tmp]$ 
[hjl@gnu-2 tmp]$ GCC_EXEC_PREFIX=/foo gcc -M x.c 
x.o: x.c /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h \
  /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/syslimits.h \
  /usr/include/limits.h /usr/include/features.h /usr/include/sys/cdefs.h \
  /usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \
  /usr/include/gnu/stubs-64.h /usr/include/bits/posix1_lim.h \
  /usr/include/bits/local_lim.h /usr/include/linux/limits.h \
  /usr/include/bits/posix2_lim.h
[hjl@gnu-2 tmp]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
[hjl@gnu-2 tmp]$ 


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[mmitchel at gcc dot gnu dot org]

------- Comment #7 from mmitchel at gcc dot gnu dot org  2008-06-06 22:59 -------
We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're
testing to search the right paths.

Note that in creating site.exp, we do:

        @echo "set GCC_EXEC_PREFIX \"$(libdir)/gcc/\"" >> ./tmp0

If I understand correctly, the issue in:

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html

may be that DejaGNU wants to compile testglue, and therefore needs
GCC_EXEC_PREFIX set at that point, since testglue is of course built with the
compiler being tested.

Maybe HOSTCC should be "GCC_EXEC_PREFIX= gcc"?


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #8 from hjl dot tools at gmail dot com  2008-06-07 01:06 -------
(In reply to comment #7)
> We set GCC_EXEC_PREFIX when testing in-tree GCC because we want the GCC we're
> testing to search the right paths.
> 

How does gcc search the right paths when GCC_EXEC_PREFIX points
to non-existent directory because gcc isn't installed? Even if
there is a GCC_EXEC_PREFIX directory, it could be a very old
gcc installation and you may search very old files, instead of
the current ones, which are just built, but not installed yet.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[mark at codesourcery dot com]

------- Comment #9 from mark at codesourcery dot com  2008-06-08 20:23 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with unstalled gcc

hjl dot tools at gmail dot com wrote:

> How does gcc search the right paths when GCC_EXEC_PREFIX points
> to non-existent directory because gcc isn't installed? Even if
> there is a GCC_EXEC_PREFIX directory, it could be a very old
> gcc installation and you may search very old files, instead of
> the current ones, which are just built, but not installed yet.

I don't remember all of the details of these changes.

However, the compiler historically searched the configured libdir no 
matter what.  This problem with having random old stuff in the place 
where you're going to be installing the new compiler is not new.  People 
wanted that behavior for in-tree testing so that if you've already put a 
new libc in libdir the compiler you're testing can find it.

I suspect that if you remove the setting in site.exp you will break the 
following scenario:

1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with corresponding --prefix option
3. User runs "make check"


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #10 from hjl dot tools at gmail dot com  2008-06-08 20:45 -------
(In reply to comment #9)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with unstalled gcc
> 
> hjl dot tools at gmail dot com wrote:
> 
> > How does gcc search the right paths when GCC_EXEC_PREFIX points
> > to non-existent directory because gcc isn't installed? Even if
> > there is a GCC_EXEC_PREFIX directory, it could be a very old
> > gcc installation and you may search very old files, instead of
> > the current ones, which are just built, but not installed yet.
> 
> I don't remember all of the details of these changes.
> 
> However, the compiler historically searched the configured libdir no 
> matter what.  This problem with having random old stuff in the place 
> where you're going to be installing the new compiler is not new.  People 
> wanted that behavior for in-tree testing so that if you've already put a 
> new libc in libdir the compiler you're testing can find it.
> 
> I suspect that if you remove the setting in site.exp you will break the 
> following scenario:
> 
> 1. User puts libraries/headers in $pefix/{lib,include}
> 2. User builds GCC with corresponding --prefix option
> 3. User runs "make check"
> 

Can't we at least test if $(libdir)/gcc/ exists before setting it
blindly?


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[mark at codesourcery dot com]

------- Comment #11 from mark at codesourcery dot com  2008-06-08 21:12 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with unstalled gcc

hjl dot tools at gmail dot com wrote:

>> I suspect that if you remove the setting in site.exp you will break the 
>> following scenario:
>>
>> 1. User puts libraries/headers in $pefix/{lib,include}
>> 2. User builds GCC with corresponding --prefix option
>> 3. User runs "make check"
> 
> Can't we at least test if $(libdir)/gcc/ exists before setting it
> blindly?

That seems like it might work.

What is the effective default value of GCC_EXEC_PREFIX for the compiler 
being tested if we don't set the variable?

Also, have you tested my suggested change to HOSTCC?  If HOSTCC is 
another GCC then any environment variables that affect the compiler 
we're trying to test will also affect HOSTCC.  It seems to me that the 
best way to avoid that causing problems is to make sure that HOSTCC 
sets/unsets the environment variables it needs.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #12 from hjl dot tools at gmail dot com  2008-06-08 22:54 -------
(In reply to comment #11)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with unstalled gcc
> 
> hjl dot tools at gmail dot com wrote:
> 
> >> I suspect that if you remove the setting in site.exp you will break the 
> >> following scenario:
> >>
> >> 1. User puts libraries/headers in $pefix/{lib,include}
> >> 2. User builds GCC with corresponding --prefix option
> >> 3. User runs "make check"

Do you have an example to show it doesn't work if
GCC_EXEC_PREFIX isn't set. From what I can tell,
for most people, GCC_EXEC_PREFIX is equivalent to
unset since GCC_EXEC_PREFIX points to nowhere.
"make check" works for them, myself included. That
means that gcc testsuite can test uninstalled gcc
without setting GCC_EXEC_PREFIX. Isuggest we don't
set it and watch for fallout. We can investigate and
fix the problem when we get bug reports. Those bugs can
be assigned to me and I will fix them.

> > 
> > Can't we at least test if $(libdir)/gcc/ exists before setting it
> > blindly?
> 
> That seems like it might work.
> 
> What is the effective default value of GCC_EXEC_PREFIX for the compiler 
> being tested if we don't set the variable?
> 

build_diretory/gcc/../lib/gcc/

which doesn't exist, at least for my build.

> Also, have you tested my suggested change to HOSTCC?  If HOSTCC is 
> another GCC then any environment variables that affect the compiler 
> we're trying to test will also affect HOSTCC.  It seems to me that the 
> best way to avoid that causing problems is to make sure that HOSTCC 
> sets/unsets the environment variables it needs.
> 

That means we have to do it whenever HOSTCC is used, including new
and old tests. I don't think it is the right fix, given that no one
has shown GCC_EXEC_PREFIX really has to be set here.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[mark at codesourcery dot com]

------- Comment #13 from mark at codesourcery dot com  2008-06-09 00:05 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with unstalled gcc

hjl dot tools at gmail dot com wrote:

>>>> 1. User puts libraries/headers in $pefix/{lib,include}
>>>> 2. User builds GCC with corresponding --prefix option
>>>> 3. User runs "make check"
> 
> Do you have an example to show it doesn't work if
> GCC_EXEC_PREFIX isn't set.

Yes -- the scenario you quote above.  If you want to remove the setting 
of GCC_EXEC_PREFIX, you need to explain how that is going to work.

> That means we have to do it whenever HOSTCC is used, including new
> and old tests. I don't think it is the right fix, given that no one
> has shown GCC_EXEC_PREFIX really has to be set here.

In order to properly control the test environment for the compiler just 
built, all environment variables used by the compiler being tested 
should be explicitly set or cleared.  Otherwise, the behavior of the 
tests will depend on things set in the user's environment, possibly for 
their /usr/bin/gcc, which clearly makes no sense.

Unless you can find a way to localize those environment changes only to 
the tested compiler (by setting/restoring them around every call to the 
compiler being tested for example), HOSTCC must set/clear all the 
environment variables that it uses.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2008-06-09 02:28 -------
(In reply to comment #13)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with unstalled gcc
> 
> hjl dot tools at gmail dot com wrote:
> 
> >>>> 1. User puts libraries/headers in $pefix/{lib,include}
> >>>> 2. User builds GCC with corresponding --prefix option
> >>>> 3. User runs "make check"
> > 
> > Do you have an example to show it doesn't work if
> > GCC_EXEC_PREFIX isn't set.
> 
> Yes -- the scenario you quote above.  If you want to remove the setting 
> of GCC_EXEC_PREFIX, you need to explain how that is going to work.

Is 3-stage bootstrap used here? How does stage 1/2/3 compilers
find those libraries and header files?

> 
> > That means we have to do it whenever HOSTCC is used, including new
> > and old tests. I don't think it is the right fix, given that no one
> > has shown GCC_EXEC_PREFIX really has to be set here.
> 
> In order to properly control the test environment for the compiler just 
> built, all environment variables used by the compiler being tested
> should be explicitly set or cleared.  Otherwise, the behavior of the 
> tests will depend on things set in the user's environment, possibly for 
> their /usr/bin/gcc, which clearly makes no sense.

Will setting GCC_EXEC_PREFIX not test the just built files, but those
under GCC_EXEC_PREFIX instead?

> 
> Unless you can find a way to localize those environment changes only to 
> the tested compiler (by setting/restoring them around every call to the 
> compiler being tested for example), HOSTCC must set/clear all the 
> environment variables that it uses.
> 

Doesn't it make a very hard requirement for HOSTCC? You may clear
all all environment variables for gcc 4.3 today. Someone may add a new
variable later to gcc 4.5. Then you have to go back to change all
HOSTCC.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2008-06-09 06:59 -------
"Unless you can find a way to localize those environment changes only to 
the tested compiler (by setting/restoring them around every call to the 
compiler being tested for example), HOSTCC must set/clear all the 
environment variables that it uses."

Unfortunately, $HOSTCC is invoked from tcl, not from shell, so e.g. sticking
unset GCC_EXEC_PREFIX; into $HOSTCC doesn't work.

The patch I've posted a few days ago temporarily removes it from the
environment for $HOSTCC invocations in struct-layout-1.exp.  Other than that,
ALT_*_UNDER_TEST might contain a host compiler, so similar unsetting/setting
would be needed in c-compat.exp too.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with unstalled gcc

[hjl dot tools at gmail dot com]

------- Comment #16 from hjl dot tools at gmail dot com  2008-06-09 14:16 -------
(In reply to comment #9)
> I suspect that if you remove the setting in site.exp you will break the 
> following scenario:
> 
> 1. User puts libraries/headers in $pefix/{lib,include}

I am not convinced it is the right thing to do. What
are those libraries/headers? Are they from gcc? If yes,
you don't need to do it. If not, can you use --sysroot
to handle non-gcc libraries/headers?

> 2. User builds GCC with corresponding --prefix option
> 3. User runs "make check"
> 


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mark at codesourcery dot com]

------- Comment #17 from mark at codesourcery dot com  2008-06-09 21:16 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with unstalled gcc

hjl dot tools at gmail dot com wrote:
> ------- Comment #16 from hjl dot tools at gmail dot com  2008-06-09 14:16 -------
> (In reply to comment #9)
>> I suspect that if you remove the setting in site.exp you will break the 
>> following scenario:
>>
>> 1. User puts libraries/headers in $pefix/{lib,include}
> 
> I am not convinced it is the right thing to do. What
> are those libraries/headers? Are they from gcc? If yes,
> you don't need to do it. If not, can you use --sysroot
> to handle non-gcc libraries/headers?

In general, no, these are not from GCC.  They're probably from your C 
library -- which might not be GLIBC or Newlib, of course.  And, they 
probably include your installed assembler and linker -- which not be 
from GNU binutils, of course.

I don't know if --sysroot might be a solution.  Historically, I believe 
the scenario I put forth has worked, so you are going to break people's 
test methodology.  Maybe there is some solution that involves changing 
the compiler flags used in site.exp (like by adding --sysroot, or -B 
options, or something) so that you don't need to set GCC_EXEC_PREFIX.

But, I think that's going to be complicated.  That's why I think the 
right thing to do is to set up HOSTCC to be robust.  Like having the 
command to run default to:

   unset GCC_EXEC_PREFIX && gcc

rather than just:

   gcc


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #18 from hjl dot tools at gmail dot com  2008-06-09 23:58 -------
(In reply to comment #17)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with unstalled gcc
> 
> hjl dot tools at gmail dot com wrote:
> > ------- Comment #16 from hjl dot tools at gmail dot com  2008-06-09 14:16 -------
> > (In reply to comment #9)
> >> I suspect that if you remove the setting in site.exp you will break the 
> >> following scenario:
> >>
> >> 1. User puts libraries/headers in $pefix/{lib,include}
> > 
> > I am not convinced it is the right thing to do. What
> > are those libraries/headers? Are they from gcc? If yes,
> > you don't need to do it. If not, can you use --sysroot
> > to handle non-gcc libraries/headers?
> 
> In general, no, these are not from GCC.  They're probably from your C 
> library -- which might not be GLIBC or Newlib, of course.  And, they 
> probably include your installed assembler and linker -- which not be 
> from GNU binutils, of course.
>

They sound to me the ideal usage for --sysroot. They aren't from
gcc and they don't change from one gcc version to another one.
You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ...
--syroot supports libraries and headers.  Does it support
assembler and linker?


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mark at codesourcery dot com]

------- Comment #19 from mark at codesourcery dot com  2008-06-10 00:38 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with installed gcc

hjl dot tools at gmail dot com wrote:

> They sound to me the ideal usage for --sysroot. They aren't from
> gcc and they don't change from one gcc version to another one.
> You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ...
> --syroot supports libraries and headers.  Does it support
> assembler and linker?

Not as far as I know; --sysroot is about the target, not the host.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #20 from hjl dot tools at gmail dot com  2008-06-10 01:45 -------
(In reply to comment #19)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with installed gcc
> 
> hjl dot tools at gmail dot com wrote:
> 
> > They sound to me the ideal usage for --sysroot. They aren't from
> > gcc and they don't change from one gcc version to another one.
> > You can use one --sysroot for gcc 4.1, 4.2, 4.3, 4.4, ...
> > --syroot supports libraries and headers.  Does it support
> > assembler and linker?
> 
> Not as far as I know; --sysroot is about the target, not the host.

So setting GCC_EXEC_PREFIX is to support "make check" using
non-system assembler and linker with gcc for a target which
probably isn't a GNU target/OS. Am I correct?


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mark at codesourcery dot com]

------- Comment #21 from mark at codesourcery dot com  2008-06-10 05:02 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with installed gcc

hjl dot tools at gmail dot com wrote:

>>> --syroot supports libraries and headers.  Does it support
>>> assembler and linker?
>> Not as far as I know; --sysroot is about the target, not the host.
> 
> So setting GCC_EXEC_PREFIX is to support "make check" using
> non-system assembler and linker with gcc for a target which
> probably isn't a GNU target/OS. Am I correct?

Or which *is* a GNU target/OS, but isn't using an in-tree build of all 
the components -- like, for example, if you already have good versions 
of the cross tools around.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #22 from hjl dot tools at gmail dot com  2008-06-10 05:49 -------
(In reply to comment #21)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with installed gcc
> 
> hjl dot tools at gmail dot com wrote:
> 
> >>> --syroot supports libraries and headers.  Does it support
> >>> assembler and linker?
> >> Not as far as I know; --sysroot is about the target, not the host.
> > 
> > So setting GCC_EXEC_PREFIX is to support "make check" using
> > non-system assembler and linker with gcc for a target which
> > probably isn't a GNU target/OS. Am I correct?
> 
> Or which *is* a GNU target/OS, but isn't using an in-tree build of all 
> the components -- like, for example, if you already have good versions 
> of the cross tools around.
> 

I have done that all the time. I just combine a known good gcc source tree
with a known good binutils source tree. The main problem is many times
the common directories, like include, libiberty and top level files, aren't
compatible between gcc and binutils. My solutions are

1. Use PATH for build/testing if I can't use combined tree.  Or
2. Patch the common directories/files so that they are compatible between
gcc and binutils.

I thought it was my problem. I believe such changes belong to vendor
branches, not gcc trunk.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.2


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[jakub at gcc dot gnu dot org]

------- Comment #23 from jakub at gcc dot gnu dot org  2008-06-12 11:17 -------
Subject: Bug 36443

Author: jakub
Date: Thu Jun 12 11:17:05 2008
New Revision: 136698

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136698
Log:
        PR testsuite/36443
        * gcc.dg/compat/struct-layout-1.exp: Temporarily unset
        GCC_EXEC_PREFIX from environment when running $HOSTCC.
        * g++.dg/compat/struct-layout-1.exp: Likewise.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
    trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2008-06-12 11:39 -------
Subject: Bug 36443

Author: jakub
Date: Thu Jun 12 11:38:55 2008
New Revision: 136700

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136700
Log:
        PR testsuite/36443
        * gcc.dg/compat/struct-layout-1.exp: Temporarily unset
        GCC_EXEC_PREFIX from environment when running $HOSTCC.
        * g++.dg/compat/struct-layout-1.exp: Likewise.

Modified:
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/g++.dg/compat/struct-layout-1.exp
    branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2008-06-12 11:41 -------
Committed patch Janis approved as temporary solution.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #26 from hjl dot tools at gmail dot com  2008-06-12 12:33 -------
Don't we need the same workaround in

./objc.dg/gnu-encoding/gnu-encoding.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[pinskia at gcc dot gnu dot org]

------- Comment #27 from pinskia at gcc dot gnu dot org  2008-07-15 14:41 -------
(In reply to comment #26)
> Don't we need the same workaround in
Yes.

I can confirm this with 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-07-15 14:41:05
               date|                            |


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl at gcc dot gnu dot org]

------- Comment #28 from hjl at gcc dot gnu dot org  2008-07-17 05:14 -------
Subject: Bug 36443

Author: hjl
Date: Thu Jul 17 05:13:27 2008
New Revision: 137909

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137909
Log:
2008-07-17  H.J. Lu  <hongjiu.lu@intel.com>

        PR testsuite/36443
        * objc.dg/gnu-encoding/gnu-encoding.exp: Temporarily unset
        GCC_EXEC_PREFIX from environment when running $HOSTCC.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[jsm28 at gcc dot gnu dot org]

------- Comment #29 from jsm28 at gcc dot gnu dot org  2008-08-27 22:04 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rguenth at gcc dot gnu dot org]

------- Comment #30 from rguenth at gcc dot gnu dot org  2009-01-24 10:20 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.3                       |4.3.4


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl at gcc dot gnu dot org]

------- Comment #31 from hjl at gcc dot gnu dot org  2009-01-26 18:14 -------
Subject: Bug 36443

Author: hjl
Date: Mon Jan 26 18:13:58 2009
New Revision: 143681

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143681
Log:
2009-01-26  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2008-07-17  H.J. Lu  <hongjiu.lu@intel.com>

        PR testsuite/36443
        * objc.dg/gnu-encoding/gnu-encoding.exp: Temporarily unset
        GCC_EXEC_PREFIX from environment when running $HOSTCC.

Modified:
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #32 from hjl dot tools at gmail dot com  2009-01-27 15:48 -------
*** Bug 38820 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rob1weld at aol dot com


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #33 from hjl dot tools at gmail dot com  2009-01-27 15:54 -------
I think it is a very bad idea to set GCC_EXEC_PREFIX for "make check".
If some people want binary tools, which aren't the part of installed gcc,
in the GCC_EXEC_PREFIX directory when running "make check", they
should use a branch or local change for this purpose. They shouldn't
impose their desires on all gcc developers.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #34 from hjl dot tools at gmail dot com  2009-01-27 16:06 -------
If I have an old gcc 4.4 installed on my machine, will setting
GCC_EXEC_PREFIX use the old installed gcc 4.4 for "make check"?


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

------- Comment #35 from janis at gcc dot gnu dot org  2009-01-27 18:45 -------
In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
compiler being tested in the build directory is invoked with -B. 
GCC_EXEC_PREFIX will only be used to find files that are not in the build
directory.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #36 from rob1weld at aol dot com  2009-01-27 21:12 -------
(In reply to comment #33)
*** Bug 38820 has been marked as a duplicate of this bug. ***
(In reply to comment #34)
> If I have an old gcc 4.4 installed on my machine, will setting
> GCC_EXEC_PREFIX use the old installed gcc 4.4 for "make check"?


That was my concern and here is proof:

# gcc/xgcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../gcc_trunk/configure
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --disable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-symvers --enable-version-specific-runtime-libs
--without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj
--enable-gtk-peer --enable-plugin --enable-tool-wrappers
--enable-portable-native-sync --enable-hash-synchronization
--enable-interpreter --enable-local-sockets --enable-gjdoc
--enable-java-awt=gtk,xlib,x --enable-gc-debug --enable-libgcj-debug
--enable-objc-gc --disable-concept-checks --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --with-tune=k8
--with-cpu=k8 --with-arch=k8 --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-dssi --enable-libgcj-multifile
--build=i386-redhat-linux --prefix=/mnt/drive2/gcc_test --with-cloog=/usr/local
Thread model: posix
gcc version 4.4.0 20090126 (experimental) [trunk revision 143680] (GCC) 


Here is a small portion of the build output:

make[4]: Leaving directory `/mnt/drive2/gcc_build/i386-redhat-linux/libgcc'
# Early copyback; see "all" above for the rationale.  The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/sh ../../../gcc_trunk/libgcc/../mkinstalldirs ../.././gcc
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o
crtprec64.o crtprec80.o crtfastmath.o";                                       
\
        for file in $parts; do                                  \
          rm -f ../.././gcc/$file;              \
          /usr/bin/install -c -m 644 $file ../.././gcc/;        \
        done
# @multilib_flags@ is still needed because this may use
# /mnt/drive2/gcc_build/./gcc/xgcc -B/mnt/drive2/gcc_build/./gcc/
-B/mnt/drive2/gcc_test/i386-redhat-linux/bin/
-B/mnt/drive2/gcc_test/i386-redhat-linux/lib/ -isystem
/mnt/drive2/gcc_test/i386-redhat-linux/include -isystem
/mnt/drive2/gcc_test/i386-redhat-linux/sys-include and -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../gcc_trunk/libgcc/../mkinstalldirs .


Notice this:
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o
crtprec64.o crtprec80.o crtfastmath.o";        


# locate crtbegin.o | grep usr
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtbegin.o

# locate crtprec80.o | grep usr
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtprec80.o

# locate crtfastmath.o | grep usr
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtfastmath.o


Lets us use newly compiled crt* files instead of the wrong ones.

The priority here is "NORMAL", someone bump it to MAJOR for us.

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #37 from rob1weld at aol dot com  2009-01-27 21:26 -------
(In reply to comment #20)
> (In reply to comment #19)
> > Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
> >  with installed gcc
> > hjl dot tools at gmail dot com wrote:
> > > They sound to me the ideal usage for --sysroot. They aren't from
> > > ...
> So setting GCC_EXEC_PREFIX is to support "make check" using
> non-system assembler and linker with gcc for a target which
> probably isn't a GNU target/OS. Am I correct?

I have compiled gcc for Fedora 10 and OpenSolaris 2008.11 (with
and without using GNU ld selected by ./configure options) and 
found that GCC_EXEC_PREFIX is simply always set. 

It is not "... set to support "make check" using non-system assembler
and linker with ..." it is simply just being set, no matter the reason.

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #38 from rob1weld at aol dot com  2009-01-27 21:32 -------
Clearly, it is wrong:

# locate crtprec80.o
/mnt/drive2/gcc_build/gcc/crtprec80.o
/mnt/drive2/gcc_build/i386-redhat-linux/libgcc/crtprec80.o
/mnt/drive2/gcc_build/prev-gcc/crtprec80.o
/mnt/drive2/gcc_build/prev-i386-redhat-linux/libgcc/crtprec80.o
/mnt/drive2/gcc_build/stage1-gcc/crtprec80.o
/mnt/drive2/gcc_build/stage1-i386-redhat-linux/libgcc/crtprec80.o
/mnt/drive2/gcc_test/lib/gcc/i386-redhat-linux/4.4.0/crtprec80.o
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtprec80.o


# ls -l /usr/lib/gcc/i386-redhat-linux/4.3.2/crtprec80.o
/mnt/drive2/gcc_test/lib/gcc/i386-redhat-linux/4.4.0/crtprec80.o
-rw-r--r-- 1 root root 2204 2009-01-26 18:35
/mnt/drive2/gcc_test/lib/gcc/i386-redhat-linux/4.4.0/crtprec80.o
-rw-r--r-- 1 root root 2372 2008-11-05 04:12
/usr/lib/gcc/i386-redhat-linux/4.3.2/crtprec80.o

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #39 from rob1weld at aol dot com  2009-01-28 03:08 -------
H.J. Lu,

This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435#c25 ) requests
that Bug Report be modified "restore to P3 if it affects non-Ada testsuites
or any case where the compiler exports GCC_EXEC_PREFIX internally rather 
than GCC_EXEC_PREFIX being set manually by a compiler user ...".

Should we set "depends" / "blocks" for that report too.

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #40 from rob1weld at aol dot com  2009-01-28 13:52 -------
Notes from 38820: I had "Known to fail" set to 4.4.0 4.3.2

Another 'proof' this is a Bug.

You are allowed to build GCC after you set (reasonable) Environment
variables. Examples are:
export set CC="gcc -v"
export set CC="gcc -mregparm=2"
export set CC="gcc -msseregparm"
export set CC="gcc gcc -ffloat-store -msse4 -mfpmath=sse,387"


Further support for the argument that this is a Bug is shown in "info gcc" :

`-mregparm=NUM'
`-msseregparm'
     *Warning:* if you use this switch, and NUM is nonzero, then you
     must build all modules with the same value, including any
     libraries.  This includes the system libraries and startup modules.

You are allowed to compile GCC in this manner (and may desire to do so
for testing purposes). If you do build GCC this way then GCC_EXEC_PREFIX
must be set correctly (to the newly compiled system libraries and startup
modules).

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #41 from rob1weld at aol dot com  2009-01-29 15:01 -------
(In reply to comment #35)
> In response to comment #34, the -B option overrides GCC_EXEC_PREFIX and the
> compiler being tested in the build directory is invoked with -B. 
> GCC_EXEC_PREFIX will only be used to find files that are not in the build
> directory.

It causes a few problems and is (obviously?) incorrect.


Proof:

To _exactly_ reproduce the conditions may not be necessary but here they are:

Compile, test and install the trunk (from early this year) on an
Athlon-X2. You likely need to ./configure with additional options,
I believe that "--with-tune=k8 --with-cpu=k8 --with-arch=k8" would
be the minimum. The full list is at the end of this page:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html

Update your source with "contrib/gcc_update" and rebuild (it is
possible to use that script and not reconfigure but you may if 
you wish).

Now, do NOT Install gcc.

Run "make -i check" and when it is complete rename or copy the log.

# mv gcc_build/gcc/testsuite/gcc/gcc.log
gcc_build/gcc/testsuite/gcc/gcc.log.PREVIOUS


Now, run "make install".

Run "make -i check" and when it is complete do this:

# ../gcc_trunk/contrib/compare_tests
../gcc_build/gcc/testsuite/gcc/gcc.log.PREVIOUS_1
../gcc_build/gcc/testsuite/gcc/gcc.log
New tests that FAIL:

gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)popcountdi2
gcc.target/i386/funcspec-3.c scan-assembler popcntq

New tests that PASS:

gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)sse42_pop_l
gcc.target/i386/funcspec-3.c scan-assembler call\t(.*)sse4a_pop_i
gcc.target/i386/funcspec-3.c scan-assembler popcntl
gcc.target/i386/funcspec-3.c (test for excess errors)


That is the "Official Log Comparison Script" and it reports a 
difference on the result of "make -i check" on an un-installed
gcc versus an installed gcc.


Can I say "This is P1, all test results suspect, most invalid." ?

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

------- Comment #42 from janis at gcc dot gnu dot org  2009-01-29 18:32 -------
I'm looking into this.  It's all very messy and confusing, so I'm trying to
step back and understand the big picture.

Is there a reason that GCC_EXEC_PREFIX is set to $(libdir)/gcc/ for the
compiler tests but not for the library tests?

Is is a problem that HOSTCC uses LD_LIBRARY_PATH set for the compiler under
test?


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-07-15 14:41:05         |2009-01-29 18:32:17
               date|                            |


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

------- Comment #43 from janis at gcc dot gnu dot org  2009-01-29 22:36 -------
Rob, your various assertions do not show that there is a bug here.  The failure
of gcc.target/i386/funcspec-3.c described in comment #41 does not prove that
the compiler under test is using GCC files from the install tree.  I think it's
either an intermittent failure or some problem with running the testsuite where
you've already run them.  In particular, that test doesn't appear to use any
files that are in $(libdir)/gcc/, it's a compile-only test and cc1 is not in
that part of the installation.  The assertion in comment #37 that
"GCC_EXEC_PREFIX is simply always set" is not true; it is only being set within
the testsuite and from the Makefile as part of an invocation of runtest.  The
others don't make much sense, either.

I built GCC from 20090106, broke a couple of thing affecting cc1, float.h, and
libgcc.a, and installed it.  Then I configured current mainline to use the same
installation location, built it, and ran the tests affected the what I broke;
they all passed.  I added a test to print the value of GCC_EXEC_PREFIX and it
confirmed that it was set.  It does NOT affect the use of the compiler under
test.

Once again, the use of -B in the testsuite overrides GCC_EXEC_PREFIX for files
that are part of GCC.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #44 from rob1weld at aol dot com  2009-01-29 23:12 -------
(In reply to comment #43)
> Rob, your various assertions do not show that there is a bug here.  ...
...
> I built GCC from 20090106, broke a couple of thing affecting cc1, float.h, and
> libgcc.a, and installed it.  Then I configured current mainline to use the same
> installation location, built it, and ran the tests affected the what I broke;
> they all passed.  I added a test to print the value of GCC_EXEC_PREFIX and it
> confirmed that it was set.  It does NOT affect the use of the compiler under
> test.
> Once again, the use of -B in the testsuite overrides GCC_EXEC_PREFIX for files
> that are part of GCC.

I can do that too.


Here is a diff of the result of "../gcc_trunk/contrib/test_summary -t", watch:

# gdiff -Naur /mail-4.4.0_20090125-408-1.txt /mail-4.4.0_20090125-408-2.txt 
(nothing printed)

The Expect scripts are not guaranteed to 'grep' every aspect of the ".log"
files. Andrew says: "The correct procedure to compare logs is with
'../gcc_trunk/contrib/compare_tests' ...". The PASS / FAIL does not show
up for anything the scripts do not see _and_ the tests we do have do not
test every aspect of gcc. Even my simple proof will miss further proofs.

This Bug Report already established that there was concerns about this
Bug before "H.J. Lu" reopened and duped my other Bug Report to here. Are
"H.J. Lu" et. al. and myself missing something ? 

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #45 from rob1weld at aol dot com  2009-01-31 22:13 -------
Here is another attempt using "gcc version 4.4.0 20090128 (experimental) [trunk
revision 143729]" to compile "gcc version 4.4.0 20090131 (experimental) [trunk
revision 143817]".

I have an Athlon X2 running OpenSolaris in 32-bit boot mode on VirtualBox.

To attempt to make as much difference between the compilers as possible
I first set a few Environment Variables prior to ./configuring the build:

export set CC='gcc -ffloat-store -msse3 -mssse3 -m3dnow -msse4.1
-mfpmath=sse,387'
export set CPPFLAGS=-fexceptions
export set CXX='g++ -ffloat-store -msse3 -mssse3 -m3dnow -msse4.1
-mfpmath=sse,387'


Here is the result of the "../gcc_trunk/contrib/compare_tests" output:

# ../gcc_trunk/contrib/compare_tests
../gcc_build/gcc/testsuite/gcc/gcc.log.BACKUP.PRE_INSTALL
../gcc_build/gcc/testsuite/gcc/gcc.log.BACKUP.POST_INSTALL 
# (Nothing Printed)

This particular time there is no difference on that one log file.
Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mmitchel at gcc dot gnu dot org]

------- Comment #46 from mmitchel at gcc dot gnu dot org  2009-02-02 22:00 -------
As I understand it, the complaint here is that GCC_EXEC_PREFIX being set
affects HOSTCC, when HOSTCC is itself some other GCC.

But, we have to make sure that the newly built compiler searches the right
directory.  That's why GCC_EXEC_PREFIX is set.  (You can fix this by arranging
to fix GCC's build process, so that components are installed within the build
tree in the same way they would be at install time, and then you can forget all
about GCC_EXEC_PREFIX, -B options, and everything else.  But, it's a huge
project.)

HOSTCC is an arbitrary compiler.  It need not even be a GNU compiler.  DejaGNU,
"make check", etc. set all manner of random environment variables.  Therefore,
if you want to be robust, HOSTCC needs to set/unset any environment variables
relevant to its operation.

-- Mark


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #47 from rob1weld at aol dot com  2009-02-05 04:06 -------
(In reply to comment #46)
> As I understand it, the complaint here is that GCC_EXEC_PREFIX being set
> affects HOSTCC, when HOSTCC is itself some other GCC. ...

It is true (for most of us in this thread) that "GCC_EXEC_PREFIX" is being
set to a value and we agree that it is likely that the value set would NOT
work in all circumstances.

One example is inherently derived from where we see it being set (wrongly),
during "make -i check" _PRIOR_ to running "make install". We (some of us)
can see that the Testsuite Results vary WILDLY (sometimes) depending on the
"Installed Gcc" versus the "Tested Gcc".



Here is an EXTREME example:


On OpenSolaris 2008.11 install "gcc version 4.4.0 20090131 trunk revision
143817" ./configured with these options:

../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld 


Now with "gcc version 4.4.0 20090131 trunk revision 143817" installed
./configure "gcc version 4.4.0 20090204 trunk revision 143918" using
these options:

../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld 


Now run "gmake" and do the Three-Stage Build. DO NOT INSTALL GCC.
Run "gmake -i check" and save the logs (that you want to compare).

# cd ../gcc_build
# cp gcc/testsuite/gcc/gcc.log gcc/testsuite/gcc/gcc.log.PRE-INSTALL
# cp gcc/testsuite/gnat/gnat.log gcc/testsuite/gnat/gnat.log.PRE-INSTALL
# cp gcc/testsuite/obj-c++/obj-c++.log
gcc/testsuite/obj-c++/obj-c++.log.PRE-INSTALL
# cp gcc/testsuite/g++/g++.log gcc/testsuite/g++/g++.log.PRE-INSTALL
# cp gcc/testsuite/gfortran/gfortran.log
gcc/testsuite/gfortran/gfortran.log.PRE-INSTALL
# cp gcc/testsuite/objc/objc.log gcc/testsuite/objc/objc.log.PRE-INSTALL
# cp gcc/testsuite/ada/acats/acats.log
gcc/testsuite/ada/acats/acats.log.PRE-INSTALL
# cp i386-pc-solaris2.11/libstdc++-v3/testsuite/libstdc++.log
i386-pc-solaris2.11/libstdc++-v3/testsuite/libstdc++.log.PRE-INSTALL
# cp i386-pc-solaris2.11/libgomp/testsuite/libgomp.log
i386-pc-solaris2.11/libgomp/testsuite/libgomp.log.PRE-INSTALL
# cp i386-pc-solaris2.11/libffi/testsuite/libffi.log
i386-pc-solaris2.11/libffi/testsuite/libffi.log.PRE-INSTALL
# cp i386-pc-solaris2.11/libjava/testsuite/libjava.log
i386-pc-solaris2.11/libjava/testsuite/libjava.log.PRE-INSTALL
# cp i386-pc-solaris2.11/libmudflap/testsuite/libmudflap.log
i386-pc-solaris2.11/libmudflap/testsuite/libmudflap.log.PRE-INSTALL


Now Install gcc and then re-run "gmake -i check" and _sometimes_ you
will get _some_ results that are different (and sometimes you will not).


So let us see what happens when "gcc version 4.4.0 20090131 trunk revision
143817" (./configured to use GNU's linker) is used to build ""gcc version 
4.4.0 20090204 trunk revision 143918" (configured to use Sun's linker):


# ../gcc_trunk/contrib/compare_tests
../gcc_build/gcc/testsuite/gcc/gcc.log.PRE-INSTALL
../gcc_build/gcc/testsuite/gcc/gcc.log | wc -l
       0


It look like the "C" compiler is OK (it _might_ not be). Lets try "C++":


# ../gcc_trunk/contrib/compare_tests
../gcc_build/gcc/testsuite/g++/g++.log.PRE-INSTALL
../gcc_build/gcc/testsuite/g++/g++.log | wc -l
    4140

Woah! Broken.


Thanks,
Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mark at codesourcery dot com]

------- Comment #48 from mark at codesourcery dot com  2009-02-06 18:35 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with installed gcc

rob1weld at aol dot com wrote:

> One example is inherently derived from where we see it being set (wrongly),
> during "make -i check" _PRIOR_ to running "make install". We (some of us)
> can see that the Testsuite Results vary WILDLY (sometimes) depending on the
> "Installed Gcc" versus the "Tested Gcc".

There is no perfect answer here.  Not setting GCC_EXEC_PREFIX is wrong
for some usage models.  Setting it may be wrong for your usage model.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[hjl dot tools at gmail dot com]

------- Comment #49 from hjl dot tools at gmail dot com  2009-02-06 19:15 -------
For most people, GCC_EXEC_PREFIX points to either a directory which
doesn't exist or a different version of gcc. Since GCC_EXEC_PREFIX
may point a directory which doesn't exist, it isn't really needed
by "make check" for most people. Only very small percentage of gcc
developers need GCC_EXEC_PREFIX for "make check".


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[mark at codesourcery dot com]

------- Comment #50 from mark at codesourcery dot com  2009-02-06 19:22 -------
Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
 with installed gcc

hjl dot tools at gmail dot com wrote:

> For most people, GCC_EXEC_PREFIX points to either a directory which
> doesn't exist or a different version of gcc. Since GCC_EXEC_PREFIX
> may point a directory which doesn't exist, it isn't really needed
> by "make check" for most people. Only very small percentage of gcc
> developers need GCC_EXEC_PREFIX for "make check".

I don't know how that's been measured.

Improving the heuristic by avoiding the doesn't-exist case might be a
fine option, as I stated previously.  If you really want to clean this
up, add some variable you can set on the "make" command-line, or at
configure-time, that allows the user to say which use case applies.

I don't see a lot of value in arguing over the default.  There's no
right answer; ergo, we need a switch.


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

------- Comment #51 from janis at gcc dot gnu dot org  2009-02-06 19:30 -------
Mark pointed out way back in comment #9 that GCC used to effectively do the
same thing by searching the install directory even without GCC_EXEC_PREFIX.  I
understand that setting it makes people nervous, but I haven't seen any
specific evidence that setting it is actually a problem.  I often reuse an
existing install directory, and if there were problems with picking up GCC
components from GCC_EXEC_PREFIX during testing then I would have seen failures
from new tests.

Rob, you haven't convinced me that there is a problem.  I'd want to see
specifics, like building a particular revision and then running a particular
test using

  make -k RUNTESTFLAGS="... xx.exp=testname.c" check

I posted a patch last week that cleans things up a bit by setting
GCC_EXEC_PREFIX in one place and switching it back again for running $HOSTCC;
see http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html .


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[rob1weld at aol dot com]

------- Comment #52 from rob1weld at aol dot com  2009-02-07 06:00 -------
(In reply to comment #48)
> Subject: Re:  [4.3/4.4 Regression]: HOSTCC doesn't work
>  with installed gcc
> 
> rob1weld at aol dot com wrote:
> > One example is inherently derived from where we see it being set (wrongly),
> > ...
> 
> There is no perfect answer here.  Not setting GCC_EXEC_PREFIX is wrong
> for some usage models.  Setting it may be wrong for your usage model.


One answer is to have "make -i check" TEST to determine if the user
did a "make install" previously. One way to get a "proof-positive"
test (and use a new feature that seems to be unused) is to check
the executables checksum.

# /usr/local/bin/gcc -v test_gcc_1.c 2>&1 | grep Compiler\ executable\ checksum
Compiler executable checksum: 66c417bcdd572534d3c78dc025037bd3

# gcc/xgcc -v test_gcc_1.c 2>&1 | grep Compiler\ executable\ checksum
Compiler executable checksum: 66c417bcdd572534d3c78dc025037bd3

Now it should be safe to run "make -i check" on the basis that the
compiler was installed prior to running the tests. This does not
guarantee that the tests are correct, only that the environment is
the same as it would be after "make install" is done.

_IF_ it is determined that the compiler was NOT installed (using the
prior test method) then to avoid actually having to install gcc (which
the user _would_ do _if_ they wanted to) the "make -i check" procedure
would then be to install to a temporary directory (as though a
different "--prefix=" was specified ONLY for "make -i check" (which
has NO prior "make install).


This may not fix everything but it will be up to us 'doubters' to
come up with new scenarios which prove there remains circumstances
under which "make -i check" will give results we can prove untrue.

This is likely to occur during "pseudo-cross-compiling" (changing
your ABI, object file format, Linker, 32vs64, or compiling for
a subset of the Instruction Set (EG: Host=i686 Target=i386), etc...).

Rob


-- 


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

[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc

[janis at gcc dot gnu dot org]

------- Comment #53 from janis at gcc dot gnu dot org  2009-02-09 17:22 -------
Rob, you don't seem to understand that setting GCC_EXEC_PREFIX does NOT cause
the tests to use GCC files from the install tree.  The test framework
explicitly uses -B options to override GCC_EXEC_PREFIX, so the only effect of
the variable is to find non-GCC files in the install tree.


-- 


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

[Bug testsuite/36443] [4.3/4.4/4.5 Regression]: HOSTCC doesn't work with installed gcc

[rguenth at gcc dot gnu dot org]

------- Comment #54 from rguenth at gcc dot gnu dot org  2009-08-04 12:29 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug testsuite/36443] [4.3/4.4/4.5/4.6 Regression]: HOSTCC doesn't work with installed gcc

[rguenth at gcc dot gnu dot org]

------- Comment #55 from rguenth at gcc dot gnu dot org  2010-05-22 18:12 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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