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.
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
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.
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
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.
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
Fixing the incorrect summary line. Arno
Closing, as nobody seems to care about GCC_EXEC_PREFIX being broken. Arno
*** Bug 25898 has been marked as a duplicate of this bug. ***
Reopen it since it is seen again.
This is now a regression because of PR 25898.
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.
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
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.
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
A patch was posted at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01757.html
Adding dependency on PR 21553
*** Bug 21553 has been marked as a duplicate of this bug. ***
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]$
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
Requalifying as a driver issue (handling of GCC_EXEC_PREFIX)
Will not be fixed in 4.2.0; retargeting at 4.2.1.
Change target milestone to 4.2.3, as 4.2.2 has been released.
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).
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
4.2.4 is being released, changing milestones to 4.2.5.
Closing 4.1 branch.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
Fixed by r235678.