Bug 14435 - [4.9/5/6/7 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
Summary: [4.9/5/6/7 Regression] gnatchop cannot use the compiled compiler in Ada's tes...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 3.4.0
: P4 normal
Target Milestone: 7.0
Assignee: Not yet assigned to anyone
URL:
Keywords: patch
: 21553 25898 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-03-04 21:46 UTC by H.J. Lu
Modified: 2020-04-14 06:10 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.0.4
Last reconfirmed: 2006-01-25 16:56:53


Attachments
A testcase (432 bytes, application/octet-stream)
2006-01-26 14:47 UTC, H.J. Lu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2004-03-04 21:46:47 UTC
Ada testsuite log gives very little information. I got many

Running chapter a ...
/export/build/gnu/gcc-3.4/build-pentium4-
linux/gcc/testsuite/ada/acats/tests/a/a22006b.ada:
parse errors detected
/export/build/gnu/gcc-3.4/build-pentium4-
linux/gcc/testsuite/ada/acats/tests/a/a22006b.ada:
chop may not be successful
/export/build/gnu/gcc-3.4/build-pentium4-
linux/gcc/testsuite/ada/acats/tests/a/a22006b.ada:
error parsing offset info
no compilation units found
no source files written

on Linux/x86. To reproduce,

1. Build gcc 3.4 with ada.
2. Install gcc 3.4.
3. Replace gnat1 in the installed gcc 3.4 directory with a dummy shell
script which returns 1.
4. Run "make check-ada" in the gcc build direcory and watch massive failures.

It looks like Ada testsuite forgets to make sure the newly build Ada
compiler is used instead of the installed one.
Comment 1 Arnaud Charlet 2004-03-05 00:12:59 UTC
This bug report is incomplete, here is what I get, as expected:

<<
                === acats support ===
Generating support files...gnatmake: "macrosub.adb" not found
**** Failed to compile macrosub
make: *** [check-gnat] Error 1
>>

Since the host gnatmake is screwed up, there's no way you can get past the
set up point.

So I suspect your problem is elsewhere.
The ACATS scripts make sure the compiler in the build directory is used
for compiling the ACATS tests, there's no doubt about it.

Putting this PR on hold for now.

Arno
Comment 2 H.J. Lu 2004-03-05 01:47:04 UTC
Please make sure you DON'T use the installed gcc 3.4 to bootstrap gcc 3.4.
In my case, I am using RedHat EL 3. The system compiler is used to bootstrap
gcc 3.4. Changing gnat1 in the installed gcc 3.4 shouldn't affect host
gnatmake.
Comment 3 Arnaud Charlet 2004-03-05 08:33:44 UTC
It doesn't affect host gnatmake.

The issue here is really specific to gnatchop.
gnatmake uses the right compiler, as explained several times.

target gnatchop indeed uses a gnat1 in the default install dir
if there's one, which is because the GCC_EXEC_PREFIX environment
variable is broken in GCC: setting GCC_EXEC_PREFIX is no longer
doing the expected job of being equivalent to -Bxxxx

Note also that the documentation on GCC_EXEC_PREFIX is inconsistent and
unclear.

Requalifying this PR so that the behavior of GCC_EXEC_PREFIX is restored
and so that the ACATS test suite can use it, and remove the kludge
put in place to work around it, and which indeed does not work completely
with gnatchop as you reported.

Here are more info on GCC_EXEC_PREFIX being broken:

$ export GCC_EXEC_PREFIX=/home/charlet/cvs/gcc-obj/gcc/
$ gcc -v -c -x ada /dev/null
Reading specs from /home/charlet/cvs/gcc-obj/gcc/specs <- this part is fine
Configured with: ../gcc-head/configure [..]
gcc version 3.5.0 20040220 (experimental)
 /home/charlet/cvs/gcc-obj/install/libexec/gcc/i686-pc-linux-gnu/3.5.0/gnat1 -
quiet -dumpbase null.ada -mtune=pentiumpro /dev/null -o /tmp/ccIDh52n.s  <- this
part isn't, the wrong gnat1 is called

As you can see (and same for cc1), the wrong gnat1 is called.
Once this regression is fixed, it will be possible to clean up
the acats driver.

Arno
Comment 4 Andrew Pinski 2004-03-16 01:54:11 UTC
Actually it is because of the last paragraph in the docs:
In addition, the prefix is used in an unusual way in finding the directories to search for header files. For 
each of the standard directories whose name normally begins with /usr/local/lib/gcc (more precisely, 
with the value of GCC_INCLUDE_DIR), GCC tries replacing that beginning with the specified prefix to 
produce an alternate directory name. Thus, with -Bfoo/, GCC will search foo/bar where it would 
normally search /usr/local/lib/bar. These alternate directories are searched first; the standard 
directories come next. 
So you have use -B./ also.
Comment 5 charlet 2004-03-16 08:43:19 UTC
Subject: Re:  Ada's testsuite does not use the compiled compiler

> So you have use -B./ also.

And what if I can't ? This is really a regression in the behvior of
GCC_EXEC_PREFIX to me, in particular since part of the doc mentions that
GCC_EXEC_PREFIX is equivalent to -Bxxx, which is wrong if I understand your
comment correctly.

If you're right and GCC_EXEC_PREFIX always needs to be used with -B./ then
GCC_EXEC_PREFIX is useless and should be completely removed.

I'd rather see the old GCC_EXEC_PREFIX behavior restored.

Arno
Comment 6 Arnaud Charlet 2004-03-16 14:13:26 UTC
Fixing the incorrect summary line.

Arno
Comment 7 Arnaud Charlet 2005-05-17 11:58:14 UTC
Closing, as nobody seems to care about GCC_EXEC_PREFIX being broken.

Arno
Comment 8 H.J. Lu 2006-01-22 14:47:25 UTC
*** Bug 25898 has been marked as a duplicate of this bug. ***
Comment 9 H.J. Lu 2006-01-24 13:43:52 UTC
*** Bug 25898 has been marked as a duplicate of this bug. ***
Comment 10 H.J. Lu 2006-01-24 14:10:18 UTC
Reopen it since it is seen again.
Comment 11 H.J. Lu 2006-01-24 14:10:46 UTC
*** Bug 25898 has been marked as a duplicate of this bug. ***
Comment 12 Andrew Pinski 2006-01-24 14:12:53 UTC
This is now a regression because of PR 25898.
Comment 13 H.J. Lu 2006-01-25 16:56:53 UTC
How committed are we to fix this bug? Last time it was closed as WONTFIX. If
we are 100% committed to fix this, I can try to come up with something.
Comment 14 charlet@adacore.com 2006-01-25 16:59:37 UTC
Subject: Re:  [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics

> How committed are we to fix this bug? Last time it was closed as WONTFIX. If
> we are 100% committed to fix this, I can try to come up with something.

Well, the first thing to do is really to fix the documentation, since
GCC_EXEC_PREFIX is mentioned in several places in the documentation,
in an inconsistent manner.

Some places do document the behavior which the Ada test suite would like
to rely upon (GCC_EXEC_PREFIX strictly equivalent to the -B switch), that's
basically the old behavior, and some other places don't (that's the new
behavior).

I would personally vote for fixing things so that GCC_EXEC_PREFIX can be
used instead of -B

Arno
Comment 15 H.J. Lu 2006-01-25 17:25:33 UTC
The gcc 4.2 manual says

`GCC_EXEC_PREFIX'
     If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
     names of the subprograms executed by the compiler.  No slash is
     added when this prefix is combined with the name of a subprogram,
     but you can specify a prefix that ends with a slash if you wish.

Is gnat1 a subprogram executed by the compiler? If anwser is yes and
we agree the manual is correct, I will try to fix the driver.
Comment 16 charlet@adacore.com 2006-01-25 17:31:27 UTC
Subject: Re:  [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics

> Is gnat1 a subprogram executed by the compiler? If anwser is yes and
> we agree the manual is correct, I will try to fix the driver.

gnat1 is similar to cc1 and cc1plus, i.e. executed by the gcc driver.

Arno
Comment 17 H.J. Lu 2006-01-25 19:28:13 UTC
A patch was posted at

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01757.html
Comment 18 Arnaud Charlet 2006-01-26 09:56:35 UTC
Adding dependency on PR 21553
Comment 19 H.J. Lu 2006-01-26 14:20:56 UTC
*** Bug 21553 has been marked as a duplicate of this bug. ***
Comment 20 H.J. Lu 2006-01-26 14:47:36 UTC
Created attachment 10733 [details]
A testcase

[hjl@gnu-12 prefix]$ make
gcc --version
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-53)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GCC_EXEC_PREFIX=./ gcc -S foo.i | grep GOOD || exit 1
GOOD
[hjl@gnu-12 prefix]$

[hjl@gnu-16 prefix]$ make
gcc --version
gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GCC_EXEC_PREFIX=./ gcc -S foo.i | grep GOOD || exit 1
make: *** [foo.s] Error 1
[hjl@gnu-16 prefix]$

With my patch, I got

[hjl@gnu-16 prefix]$ make
/export/build/gnu/gcc/build-x86_64-linux/./prev-gcc//xgcc --version
xgcc (GCC) 4.2.0 20060126 (experimental) [trunk revision 110254 clean]
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GCC_EXEC_PREFIX=./ /export/build/gnu/gcc/build-x86_64-linux/./prev-gcc//xgcc -S foo.i | grep GOOD || exit 1
GOOD
[hjl@gnu-16 prefix]$
Comment 21 Jason 2006-02-27 18:11:45 UTC
Note / patch taken from duplicate bug 21553

------- Comment #5 From Jason 2005-09-20 02:17 [reply] -------

(In reply to comment #0)
> looking at gcc.c it looks like the problem is coming from the following line:
>  gcc_libexec_prefix = make_relative_prefix 
>     (gcc_exec_prefix,
>      standard_exec_prefix,
>      standard_libexec_prefix);
> 
> The problem is that make_relative_prefix is expecting a program name as first
> argument. But the gcc_exec_prefix is a directory. So that's why /my_prefix/ is
> removed when computing gcc_libexec_prefix...

I think there are more issues than that incorrect argument.  From what I could
see was that even though make_relative_path expects a program name the return
path discards it which may be okay.  

I am not sure on the original intent but preserving the common suffixes on arg2
and arg3 and then reapplying to the result seems to fix or at least work around
the problem.

From make-relative-prefix.c :

For example, if @var{bin_prefix} is @code{/alpha/beta/gamma/gcc/delta},
@var{prefix} is @code{/alpha/beta/gamma/omega/}, and @var{progname} is
@code{/red/green/blue/gcc}, then this function will return
@code{/red/green/blue/../../omega/}.

progname = /red/green/blue/gcc
bin_prefix = /alpha/beta/gamma/gcc/delta
prefix = /alpha/beta/gamma/omega/
returns = /red/green/blue/../../omega/

In this case :

progname = <NEW_PATH>/gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = <COMPILE_PATH>/gcc-X.X.X/lib/gcc (standard_exec_prefix)
prefix = <COMPILE_PATH>/gcc-X.X.X/libexec/gcc (standard_libexec_prefix)
returns = <NEW_PATH>/gcc-Y.Y.Y/lib/../../libexec/gcc

1. make bin_prefix relative to prefix
   <COMPILE_PATH>/gcc-X.X.X/lib/gcc/../../libexec/gcc
2. Replace the program path '<NEW_PATH>/gcc-X.X.X/lib' (dropped prg name gcc)
   <NEW_PATH>/gcc-Y.Y.Y/lib/../../libexec/gcc

So the ../.. is caused by the fact in step one make_relative_path needed to go
up two directories.

If we strip the common suffixes of bin_prefix and prefix and then reappend we
will get the desired result.

common_suffix=/gcc
progname = <NEW_PATH>/gcc-Y.Y.Y/lib/gcc (gcc_exec_prefix)
bin_prefix = <COMPILE_PATH>/gcc-X.X.X/lib (standard_exec_prefix w/out common suffix)
prefix = <COMPILE_PATH>/gcc-X.X.X/libexec (standard_libexec_prefix w/out common
suffix)
returns = <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec/gcc

1. make bin_prefix relative to prefix
   <COMPILE_PATH>/gcc-X.X.X/lib/../libexec
2. Replace the program path '<NEW_PATH>/gcc-X.X.X/lib' (dropped prg name gcc)
   <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec
3. Reappend common suffix
   <NEW_PATH>/gcc-Y.Y.Y/lib/../libexec/gcc

> Besides this I think that since 3.4.x series GCC_EXEC_PREFIX is quite useless
> indeed it is quite hard to redefine the location where cc1 is found

This worked properly in gcc 3.4.3 and prior releases.

To reproduce the problem install to a non-standard location.  Remove (rename)
the build area.  Rename the non-standard location to another non-standard name
and set the GCC_EXEC_PREFIX.  In 3.4.3 this worked...

Here is a patch file against gcc 4.0.1 (gcc/gcc.c) which implements the
algorithm mentioned above.

3232,3235c
  else 
    {
      /* Find common ending of stanard_exec_prefix and standard_libexec_prefix.
      // Essentially we are stripping /gcc/ for later use... This is required
      // because make_relative path will just add ..'s for these directories.
      // This is not the intention as the make_relative_path given three 
      // paths "progname", "bin_prefix", and "prefix"; returns the path that
      // is in the same position relative to "progname's" directory as "prefix"
      // is relative to "bin_prefix".  So we can achieve the desired result by
      // stripping this common suffix and concat'ing the result */
      const char *exec_ptr = standard_exec_prefix + strlen (standard_exec_prefix);
      const char *libexec_ptr = standard_libexec_prefix + strlen
(standard_libexec_prefix);
      char *exec_buf;
      char *libexec_buf;
      char *gccexec_buf;
      int exec_len;
      int libexec_len;
      while (exec_ptr > standard_exec_prefix
             && libexec_ptr > standard_libexec_prefix
             && *exec_ptr == *libexec_ptr )
        {
          --exec_ptr;
          --libexec_ptr;
        }
      if (exec_ptr > standard_exec_prefix)
        ++exec_ptr;
      exec_len = exec_ptr - standard_exec_prefix;
      exec_buf = xmalloc(exec_len + 1);
      strncpy(exec_buf, standard_exec_prefix, exec_len);
      exec_buf[exec_len] = '\0';
      if (libexec_ptr > standard_libexec_prefix)
        ++libexec_ptr;
      libexec_len = libexec_ptr - standard_libexec_prefix;
      libexec_buf = xmalloc(libexec_len + 1);
      strncpy(libexec_buf, standard_libexec_prefix, libexec_len);
      libexec_buf[libexec_len] = '\0';
      /* NOTE: make_relative_path really takes a program name as the
      //       first argument.  However, even though it is a directory
      //       it just needs to be stripped. */
      gccexec_buf = make_relative_prefix (gcc_exec_prefix,
                                          exec_buf,
                                          libexec_buf);
      free(exec_buf);
      free(libexec_buf);
      if (gccexec_buf)
        {
          gcc_libexec_prefix = concat(gccexec_buf, exec_ptr, NULL);
          free(gccexec_buf);
        }
      else
        gcc_libexec_prefix = 0;
    }
.
w




Comment 22 Arnaud Charlet 2007-04-30 10:52:46 UTC
Requalifying as a driver issue (handling of GCC_EXEC_PREFIX)
Comment 23 Mark Mitchell 2007-05-14 22:25:28 UTC
Will not be fixed in 4.2.0; retargeting at 4.2.1.
Comment 24 Mark Mitchell 2007-10-09 19:20:56 UTC
Change target milestone to 4.2.3, as 4.2.2 has been released.
Comment 25 Joseph S. Myers 2008-01-17 16:14:16 UTC
The issue with make_relative_prefix needing a program name should have been addressed by my patch:

r113345 | jsm28 | 2006-04-28 12:15:36 +0000 (Fri, 28 Apr 2006) | 3 lines

        * gcc.c (process_command): Add program name to GCC_EXEC_PREFIX
        value before passing to make_relative_prefix.

As for the rest of this issue, HJ, could you resubmit whatever is still relevant of your patch?

This bug has not previously been assigned a priority by an RM.  Downgrading to P4, but please 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 (my patch was for an issue showing up with -frepo and collect2 calling back to the compiler).
Comment 26 Joseph S. Myers 2008-02-01 16:52:36 UTC
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
Comment 27 Joseph S. Myers 2008-05-19 20:22:31 UTC
4.2.4 is being released, changing milestones to 4.2.5.
Comment 28 Joseph S. Myers 2008-07-04 22:44:20 UTC
Closing 4.1 branch.
Comment 29 Joseph S. Myers 2009-03-31 16:16:10 UTC
Closing 4.2 branch.
Comment 30 Richard Biener 2009-08-04 12:25:59 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 31 Richard Biener 2010-05-22 18:10:00 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 32 Richard Biener 2011-06-27 12:13:01 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 33 Jakub Jelinek 2012-03-13 12:45:52 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 34 Jakub Jelinek 2013-04-12 15:16:10 UTC
GCC 4.6.4 has been released and the branch has been closed.
Comment 35 Richard Biener 2014-06-12 13:43:04 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 36 Jakub Jelinek 2014-12-19 13:32:46 UTC
GCC 4.8.4 has been released.
Comment 37 Richard Biener 2015-06-23 08:15:42 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 38 Jakub Jelinek 2015-06-26 19:57:21 UTC
GCC 4.9.3 has been released.
Comment 39 Eric Botcazou 2016-04-30 17:26:43 UTC
Fixed by r235678.