gcc testsuite not setup for LLVM (and non-Apple Platforms)

[llvmbot]

Bugzilla Link	3870
Resolution	LATER
Resolved on	Dec 02, 2010 01:41
Version	trunk
OS	Linux
Attachments	Result of "make -i check" for 'llvm-gcc' 4.2.1
Reporter	LLVM Bugzilla Contributor
CC	@asl

Extended Description

The Testsuite not setup for LLVM and non-Apple Platforms such as Debian Linux.

I obtained the Trunk for LLVM (and it's accompanying gcc 4.2.1) and found
various problems compiling it on Debian Lenny 5.0. There are too many
patches to create 'llvm-gcc' from FSF's gcc-4_2-branch (dated 20070719)
(both "APPLE LOCAL" and "LLVM LOCAL") that it will be difficult to
make a direct comparison between 'llvm-gcc' and (un-modified) 'gcc'.

It would be better to separate the LLVM and Apple patches from each
other so they can be applied to newer versions of FSF's gcc . Your
choice of 4.2.1 is really great as it is quite stable but you will
have a nightmare trying to "diff and patch" your changes to gcc 4.4 .

The biggest problem may be that when you run the Testsuite Mailer
("../llvm-gcc-4.2_trunk/contrib/test_summary") it will send mail to
the FSF's gcc mailing list at: gcc-testresults@gcc.gnu.org . That
may not be appreciated since your 'gcc' is 4.2.1 (too old) and
it is modified. Unless the LLVM people look there they will not
even see the Testsuite Results.

Along these same lines when your 'llvm-gcc' crashes it says to use
http://developer.apple.com/bugreporter as the address to report
Bugs (instead of here at http://llvm.org/bugs/ ). Apple only
wants Bug Reports for it's un-modified gcc for Apple's Operating
Systems (and not LLVM Bug Reports for Linux Platforms such as Debian).

I had little luck in getting Ada to compile and so I ommited it from the
"--enable-languages=" list (I did read: ../docs/GCCFEBuildInstrs.html ).

uname -a

Linux debian 2.6.29-rc8-686 #​1 SMP Sat Mar 21 06:26:18 UTC 2009 i686 GNU/Linux

gcc/xgcc -v

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../llvm-gcc-4.2_trunk/configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/mnt/drive2/llvm-gcc/llvm-gcc-4.2_trunk_obj/../install --program-prefix=llvm- --enable-llvm=/mnt/drive2/llvm-gcc/install --enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-multilib --enable-stage1-checking=assert --enable-checking=release --with-arch=k8 --with-gmp=/usr/local --with-mpfr=/usr/local : (reconfigured) ../llvm-gcc-4.2_trunk/configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/mnt/drive2/llvm-gcc/llvm-gcc-4.2_trunk_obj/../install --program-prefix=llvm- --enable-llvm=/mnt/drive2/llvm-gcc/install --enable-languages=c,c++,fortran,objc,obj-c++ --enable-multilib --enable-stage1-checking=assert --enable-checking=release --with-arch=k8 --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5643) (LLVM build)

I am enclosing the Testsuite Results (from "make -i check"). Many of
the failures are due to "Testsuite Failures" and not problems with
'llvm-gcc' (mostly due to assuming that 'llvm-gcc' is to be executed
on a "--Darwin" Platform).

Best of luck with your Project,
Rob

[llvmbot]

I planned to omit the testsuite changes in my planned port of llvm-gcc to gcc-4.4. Personally I only ever run the Ada testsuite. What problems did you have building the Ada front-end?

[llvmbot]

I planned to omit the testsuite changes in my planned port of llvm-gcc to
gcc-4.4. Personally I only ever run the Ada testsuite. What problems did you
have building the Ada front-end?

"What problems did you have building the Ada front-end?"
It broke in various places. I only saved one log so I can
only show you one spot where it broke:

(output of "make"):
...
gnatbind -C -I- -I. -Iada -I../../llvm-gcc4.2-2.5.source/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali
error: "s-imenne.adb" must be compiled
...

Part of the problem (not your fault) is that 'gcc' requires that
the 'Ada' used to compile be older than the one it is compiling. Thus
I need to use gcc 4.1's Ada and can not use 'gcc 4.4 (or 4.3) Ada' to
compile 'gcc 4.2.1's Ada'. The older versions of 'Ada' are hard to find
for Debian since they (Team Debian) prefer to work on 'gcc 4.3'.

I had to add URLs to my Repository to get the older version of gnat. I
used 'aptitude' to juggle dependencies between 'gnat', 'c' and 'c++' to get
versions that 'aptitude' (and the Package Manager) said were compatible.

Another issue is that Java broke here:
../../../llvm-gcc-4.2_trunk/libjava/prims.cc:107: warning: deprecated conversion from string constant to 'char*'
../../../llvm-gcc-4.2_trunk/libjava/prims.cc: In function 'void catch_fpe(int)':
../../../llvm-gcc-4.2_trunk/libjava/prims.cc:173: warning: dereferencing type-punned pointer will break strict-aliasing rules
./include/java-signal.h: At global scope:
./include/java-signal.h:112: error: 'void restore()' used but never defined
make[3]: *** [prims.lo] Error 1

and while I was able to fix that there were other parts of the build
that broke also. I felt my limited knowledge of Java would lead to
more breakage than success; so I disabled Language 'java' instead of
hacking in more repairs.

I like to build the whole set of Languages and submit a FULL report
but that was not to be on my first attempt. Fixing the "c" errors
will be helpful and the Testsuite Report I enclosed should help.

Thanks,
Rob

[asl]

and while I was able to fix that there were other parts of the build
that broke also. I felt my limited knowledge of Java would lead to
more breakage than success; so I disabled Language 'java' instead of
hacking in more repairs.
Hi, Rob.

Please consider reading readme.llvm file. The java frontend is broken and I think will never be supported. Same applies to objc/objc++ stuff on non-darwin platforms.

The only "usable" and more or less supported languages set is c,c++,fortran,ada (modulo some bugs and limited functionality). I doubt anyone is interested in other frontends.

[llvmbot]

I obtained the Trunk for LLVM (and it's accompanying gcc 4.2.1) and found
various problems compiling it on Debian Lenny 5.0. There are too many
patches to create 'llvm-gcc' from FSF's gcc-4_2-branch (dated 20070719)
(both "APPLE LOCAL" and "LLVM LOCAL") that it will be difficult to
make a direct comparison between 'llvm-gcc' and (un-modified) 'gcc'.

It would be better to separate the LLVM and Apple patches from each
other so they can be applied to newer versions of FSF's gcc . Your
choice of 4.2.1 is really great as it is quite stable but you will
have a nightmare trying to "diff and patch" your changes to gcc 4.4 .

Hi Rob,

It's not advisable to port the "APPLE LOCAL" and "LLVM LOCAL" markers to newer versions of FSF's gcc. Indeed, some of those patches are there to fix bugs that are only in the gcc-4.2 compiler (at least those that Apple came across). For LLVM's purposes, only the patches that affect us the most are front-end patches, as LLVM uses few of gcc's transformations and none of its optimization passes. (See several files which are essentially #ifdef'ed out if compiling for LLVM.) If someone wanted to use a newer version of FSF's gcc for LLVM's front-end, then they would have to start over virtually from scratch.

At the present time, we have no plans to migrate to future versions of FSF's gcc compiler. We have an LLVM-native front-end (called clang) that is actively being developed to replace llvm-gcc.

[llvmbot]

I planned to omit the testsuite changes in my planned port of llvm-gcc to
gcc-4.4. Personally I only ever run the Ada testsuite. What problems did you
have building the Ada front-end?

The other problem was a fault at: SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT .

There was no output to say what actually caused the assert though some
portions of the code have some functions that do tell exactly what
is wrong. I had a peek at the code but since I don't know Ada I had
to disable it instead of trying to fix (and possibly breaking) it.

and while I was able to fix that there were other parts of the build
that broke also. I felt my limited knowledge of Java would lead ...
Hi, Rob.
Please consider reading readme.llvm file. The java frontend is broken ...
The only "usable" and more or less supported languages set is c,c++,fortran,ada
(modulo some bugs and limited functionality). I doubt anyone is interested in
other frontends.

Just trying to build everything and submit a complete Testsuite Report.

LLVM certainly has some advances over 'gcc' but "new gcc (4.5)" is also
ahead of LLVM in some places (Graphite). It would be better (IMNSHO)
if "LLVM Trunk" and "gcc Trunk" were a lot closer together.

If someone wanted to use a newer version of FSF's gcc for LLVM's
front-end, then they would have to start over virtually from scratch.
Yes, that is a complaint of mine. The two will only continue to diverge
if an effort is not made to make them mergable. If they can not be
merged then don't expect to incorporate your changes wholesale but
expect to submit Patches one at a time (and you have many!).

The 'gcc Group' considers 4.2.1 too old to support. While I feel that
is an error and that they ought to keep 4.2.1 alive; it's not my call.

The 4.4 (soon to branch 4.5) gcc really works quite well with few errors.

Thanks everyone for your interest in my first Report,
Rob

[llvmbot]

If someone wanted to use a newer version of FSF's gcc for LLVM's
front-end, then they would have to start over virtually from scratch.
Yes, that is a complaint of mine. The two will only continue to diverge
if an effort is not made to make them mergable. If they can not be
merged then don't expect to incorporate your changes wholesale but
expect to submit Patches one at a time (and you have many!).

The 'gcc Group' considers 4.2.1 too old to support. While I feel that
is an error and that they ought to keep 4.2.1 alive; it's not my call.

The 4.4 (soon to branch 4.5) gcc really works quite well with few errors.

Unfortunately, the standard response applies in this situation. "This is an open source project, so if you want to do it, then you'll have to do it yourself." :-)

I know that in the past, we've gone from 3.3 to 4.0 to 4.2. Each upgrade was non-trivial, not because we didn't keep track of the LOCAL changes, but because each compiler was quite different from the previous one and upgrading came with its own challenges far beyond porting over the LOCAL changes.

[llvmbot]

(output of "make"):
...
gnatbind -C -I- -I. -Iada -I../../llvm-gcc4.2-2.5.source/gcc/ada -o
ada/b_gnat1.c -n ada/gnat1drv.ali
error: "s-imenne.adb" must be compiled

This usually means that the system Ada compiler is too recent.
This is discussed in http://llvm.org/docs/GCCFEBuildInstrs.html
which also has links to some appropriate compiler binaries that
you can easily install (the GNAT GPL ones). There is no problem
using a GNAT compiler for the C and Ada parts, and the system
compiler for C++. There is no need to have one compiler that
does all three.

The other problem was a fault at: SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT.

You can't bootstrap the Ada compiler currently, because the
compiler builds itself with setjmp/longjmp style exception
handling which LLVM doesn't support. At this point you mention
an exception is thrown, which crashes the compiler if the
compiler built itself. This is why the instructions at
http://llvm.org/docs/GCCFEBuildInstrs.html specify
--disable-bootstrap. This is also discussed in the release notes.

[llvmbot]

If someone wanted to use a newer version of FSF's gcc for LLVM's
front-end, then they would have to start over virtually from scratch.
Yes, that is a complaint of mine. The two will only continue to diverge
if an effort is not made to make them mergable. If they can not be
merged then don't expect to incorporate your changes wholesale but
expect to submit Patches one at a time (and you have many!).
...

Unfortunately, the standard response applies in this situation. "This is an
open source project, so if you want to do it, then you'll have to do it
yourself." :-)
I tried, see next comment.

I know that in the past, we've gone from 3.3 to 4.0 to 4.2. Each upgrade was
non-trivial, not because we didn't keep track of the LOCAL changes, but because
each compiler was quite different from the previous one and upgrading came with
its own challenges far beyond porting over the LOCAL changes.

If you want to go from 3.3.x to 4.0.0 you need to "patch up" your
"llvm-ized" source to near the END of 3.x.x where the 4.0.0 Branch
starts then you will have the least fixes (potential rejects). The
"real" Start Date of 4.0.0 will usually be prior to the "actual end"
of 3.4.x so you will need to do a bit of 'syncing by hand'.

Yes, that can be tough, but if you finish a port to 4.4 it will be
branching to 4.5 *R.S.N. and thus you will have two ports for one.

To attempt to derive the "patch set" for llvm I tried to do a
'diff' of gcc-4_2-branch (svn -r 20070719) against llvm-gcc-2.5 (and
the Trunk too) but I ended up with a file over 500M in size - YUK!

I then did a diff against Apple's "gcc_42-5553" and llvm-gcc-4.2_trunk
(release_23) and managed to get the ".diff" file to be ONLY 1.6M - still
big but much better. The problem is that even "gcc_42-5553" is still
quite different than "FSF Original gcc" but doing that gives me
an idea of what is involved (and reveals some FINE! patches that
"FSF gcc" would benefit from).

so if you want to do it, then you'll have to do it > yourself." :-)
So it is not as though I did not try ...

I'll re-try an 'svn up' and all Languages enabled (except Java) compilation.

Thanks one and all for your wise advice,
Rob

PS: The purpose of this Bug Report was to file the Attachment in order
that anyone so inclined may work on some of the Testsuite failures.

[llvmbot]

so if you want to do it, then you'll have to do it > yourself." :-)
So it is not as though I did not try ...

Not to say you haven't. :-)

It should be pointed out that we are not interested in syncing LLVM-GCC up to a newer GCC. In fact, the new GPL license makes doing such a thing a non-starter.

[llvmbot]

I plan to port llvm-gcc to gcc-4.4. I understand that the
license is an issue for Apple, but it is irrelevant to me
and probably to many.

[llvmbot]

I plan to port llvm-gcc to gcc-4.4. I understand that the
license is an issue for Apple, but it is irrelevant to me
and probably to many.

They have "gcc code" in "their code" they should be glad to share.

4.4 was "Released" recently.

If you use svn you can get 4.5 (which is 4.4.0 plus a few
weeks work) then you will have a "4.5 version" That makes
it easier to apply Patches easily and keep updated for
the next year or so.

It would be great if you could utilize the "gcc Testsuite"
AS-IS (unmodified) and place the "LLVM Testsuite" into
a different subdirectory so it can be ran separately. We
need to be able to run "gcc_trunk/contrib/test_summary".

It would also be great if we could use the gcc Optimizations
and Graphite. One of the neatest features (for me) about
llvm-gcc is that it can output non-binary code ("C" "MSIL"
etc.) I notice when I look at the resulting code that
gcc 4.4.0 can create slightly better code than the old gcc
(and Apple Optimizations) used in llvm-gcc. A new switch
to choose between the two would be nice.

Please email us (by posting in this thread) the URL when your
llvm-gcc 4.5 Port is ready. You can email me directly if someone
tells you NOT to post the URL in this Thread.

Go Duncan Go, Go Duncan Go,
Rob

[llvmbot]

Are we going to fix something here? I'm not sure what the actionable item is.

[lattner]

No, there is nothing actionable left here.