llvm-gcc-4.2-2.5 fails to build from source on arm: MACHO_DYNAMIC_NO_PIC_P undeclared

Hi
   The fix is very simple: the defaulting of this macro to 0 in
gcc/config/arm/arm.h, present in 2.2 has been omitted in 2.5.

The attached patch puts the defaulting clause back, the same as it was in 2.2

    M

0004-arm-default-MACHO_DYNAMIC_NO_PIC_P.patch (385 Bytes)

Hello

The fix is very simple: the defaulting of this macro to 0 in
gcc/config/arm/arm.h, present in 2.2 has been omitted in 2.5.

The attached patch puts the defaulting clause back, the same as it was in 2.2

This is known problem which was fixed after 2.5 release.

Thanks. Do you have fixes for the other ARM bloopers? This is the
forthcoming Debian version and it's now dying on arm-gnueabi when it
links cc2-dummy saying

libbackend.a(arm.o): In function `current_file_function_operand':
/home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3506:
undefined reference to `ENCODED_SHORT_CALL_ATTR_P'
libbackend.a(arm.o): In function `arm_is_longcall_p':
/home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3581:
undefined reference to `ENCODED_LONG_CALL_ATTR_P'
collect2: ld returned 1 exit status

cheers

   M

Hello, Martin

Thanks. Do you have fixes for the other ARM bloopers? This is the
forthcoming Debian version and it's now dying on arm-gnueabi when it
links cc2-dummy saying

Please use the current Top-of-the-Tree version. I was successfully
built cross llvm-gcc for arm-elf / arm-gnu-linux-eabi target triples.

Sorry, that's not an option as I'm trying to fix the Debian version,
which uses "stable" releases. Each Debian build takes 6 hours, so
finding and fixing these bugs one by one is quite a long process.

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
powerpc and ia64, only succeeding on i386 and amd64:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
so it looks like the 2.5 release was never properly tested before it
was published.

If the issues and fixes are "known", can you make them known to the
public, for example by producing a 2.5.1 with the worst bugs fixed, or
by documenting the issues and patches in the "Known problems" section?
It would be a big help to all the distro maintainers.

Thanks & sorry to be the bringer of bad news...

   M

Hello, Martin

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
powerpc and ia64, only succeeding on i386 and amd64:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
so it looks like the 2.5 release was never properly tested before it
was published.

Unfortunately, ia64 and sparc were never considered as a 'tier-1'
targets for llvm-gcc, there was noone who cared about it. Also, our
linux resources are pretty limited, thus both ppc and arm were broken
at the time for 2.5 release.

Hopefully things will be much better with the coming 2.6 release, at
least one might expect arm and ppc to be more or less ok. ia64 support
was completely dropped and sparc should be brokens as of time of 2.5.

If the issues and fixes are "known", can you make them known to the
public, for example by producing a 2.5.1 with the worst bugs fixed, or
by documenting the issues and patches in the "Known problems" section?
It would be a big help to all the distro maintainers.

You might want to stick with next 2.6 release, which is scheduled to
be out within next 1.5 months

I would like to comment on some other bugs as well:
478535: there are no plans to support of legacy IBM S390 platform,
only 64 bit one (that's s390x in tartget triple). The current plans
are to use clang only, not llvm-gcc, however I might be able to find
few hours to give llvm-gcc a try.
539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM
builds of llvm-gcc (both for bare-metal arm-elf and normal
arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681
511721: I believe it should be fixed on ToT.
518592: Sounds like compiler / linker problem, it's not LLVM related at all

both ppc and arm were broken at the time for 2.5 release.

Ah, OK, thanks. That resolves my problem! :slight_smile:

I've edited your remarks and appended them to the debian bug report,
which should solve the issue, see bugs.debian.org/539496

I would like to comment on some other bugs as well:
478535: there are no plans to support of legacy IBM S390 platform,
only 64 bit one (that's s390x in tartget triple). The current plans
are to use clang only, not llvm-gcc, however I might be able to find
few hours to give llvm-gcc a try.
539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM
builds of llvm-gcc (both for bare-metal arm-elf and normal
arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681
511721: I believe it should be fixed on ToT.
518592: Sounds like compiler / linker problem, it's not LLVM related at all

Thanks. I've forwarded these comments to the bug tracker.
In general. anyone can add comments to Debian bug reports simply by
sending email to 478535@bugs.debian.org or whatever

With respect to 539496, yes, all major distributions are moving to ARM
EABI, for which the minimum architecture is armv4t, while armv4 is
becoming rare.
But if you also mean "no plans to support ARMv4t", I would say that it
is currently very common in small devices where a compiler with a
small memory requirement and producing compact object code is most
valuable. Exmples: the openmoko linux phone and the many single-board
ARM computers currently on the market.
The only incompatability that ARMv5t causes is the extra
count-leading-zeros instruction, which is seldom useful to a compiler
except in asm code for division - a small gain - so I would urge LLVM
to continue support for ARMv4t unless there are compelling reasons not
to do so.
But I may have misunderstood you.

Re: resources, there is a 600MHz 512MB ARM (v5t) here, as well as a
little armv4t board, which are on 24/7 and which I am happy for people
to use over ssh to debug arm and arm-eabi issues. If that would be
useful to anyone, just send mail privately suggesting a username

Thanks again

   M

Hello, Martin

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,

powerpc and ia64, only succeeding on i386 and amd64:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable

so it looks like the 2.5 release was never properly tested before it

was published.

Unfortunately, ia64 and sparc were never considered as a ‘tier-1’
targets for llvm-gcc, there was noone who cared about it. Also, our
linux resources are pretty limited, thus both ppc and arm were broken
at the time for 2.5 release.

Hopefully things will be much better with the coming 2.6 release, at
least one might expect arm and ppc to be more or less ok. ia64 support
was completely dropped and sparc should be brokens as of time of 2.5.

I just want to comment on this. We test our releases very throughly for supported targets. Supported means that they are actively maintained and tested day after day. If no one steps up to be a maintainer for these targets, then they will not become a part of the release criteria.

With that said, we only qualified for x86-32, x86-64, mingw32, and ppc (mac os 10.5 only). So pretty much all the ones that are failing were not supported for 2.5. This list is only slightly expanded for 2.6, and will not include arm, ia64, sparc, or ppc. arm will probably work with 2.5, but unless someone wants to qualify it for the release (I do not have a volunteer), then it will not be on the list of supported targets.

We’d love help with these targets. Ideally, we need someone to set up an appropriate buildbot and actively monitor it and fix issues or file bug reports for things that come up.

Thanks,
Tanya

Hello, Martin

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
powerpc and ia64, only succeeding on i386 and amd64:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
so it looks like the 2.5 release was never properly tested before it
was published.

Unfortunately, ia64 and sparc were never considered as a 'tier-1'
targets for llvm-gcc, there was noone who cared about it. Also, our
linux resources are pretty limited, thus both ppc and arm were broken
at the time for 2.5 release.

Hopefully things will be much better with the coming 2.6 release, at
least one might expect arm and ppc to be more or less ok. ia64 support
was completely dropped and sparc should be brokens as of time of 2.5.

I just want to comment on this. We test our releases very throughly for supported targets. Supported means that they are actively maintained and tested day after day. If no one steps up to be a maintainer for these targets, then they will not become a part of the release criteria.

With that said, we only qualified for x86-32, x86-64, mingw32, and ppc (mac os 10.5 only). So pretty much all the ones that are failing were not supported for 2.5. This list is only slightly expanded for 2.6, and will not include arm, ia64, sparc, or ppc.

For what it's worth, Daniel and I recently set up a Mac OS 10.5 PPC G5 box as a build bot machine. I've been monitoring it, so it's doing well for the 2.6 release. :slight_smile:

-bw

Hello, Martin

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,

powerpc and ia64, only succeeding on i386 and amd64:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable

so it looks like the 2.5 release was never properly tested before it

was published.

Unfortunately, ia64 and sparc were never considered as a ‘tier-1’

targets for llvm-gcc, there was noone who cared about it. Also, our

linux resources are pretty limited, thus both ppc and arm were broken

at the time for 2.5 release.

Hopefully things will be much better with the coming 2.6 release, at

least one might expect arm and ppc to be more or less ok. ia64 support

was completely dropped and sparc should be brokens as of time of 2.5.

I just want to comment on this. We test our releases very throughly for supported targets. Supported means that they are actively maintained and tested day after day. If no one steps up to be a maintainer for these targets, then they will not become a part of the release criteria.

With that said, we only qualified for x86-32, x86-64, mingw32, and ppc (mac os 10.5 only). So pretty much all the ones that are failing were not supported for 2.5. This list is only slightly expanded for 2.6, and will not include arm, ia64, sparc, or ppc.

For what it’s worth, Daniel and I recently set up a Mac OS 10.5 PPC G5 box as a build bot machine. I’ve been monitoring it, so it’s doing well for the 2.6 release. :slight_smile:

Now you set yourself up. Would you be willing to qualify 2.6 for Mac OS 10.5 ppc? If you have time,that would be very useful. :slight_smile: If not, I understand.

-Tanya

LOL! I'll do what I can. :slight_smile: Just ping me if it looks like I'm not starting the qual process for the machine.

-bw

Hi Tanya, Bill, Anton and Martin.

I have recently set-up and installed a ARM buildbot that have currently
been building since August 21.
You can follow its progress here
http://google1.osuosl.org:8011/builders/llvm-arm-linux

I have also started to investigate the test failures and writing
bugreports. Currently about all test failures except are related to the
ExecutionEngine JIT and i am doing my best to stabilise it. There are
also one failure with the theTransforms/LICM/2003-12-11-SinkingToPHI.ll
test.

Im currently investigating the following bugs that are probably causing
most of these JIT-showstoppers for ARM:
http://llvm.org/bugs/show_bug.cgi?id=4772 ARM unittest
JIT.GlobalInFunction fail during ARM Machine...
http://llvm.org/bugs/show_bug.cgi?id=4592 ARM JIT 1+1=0
http://llvm.org/bugs/show_bug.cgi?id=4593 ARM JIT BrainF -jit hello.bf
Asserts while deleting putchar

Any advise on how to best tackle the remaining ~28 JIT bugs using common
tools like gdb and code manipulation are most welcome.

Anton do you know if there are current any bugs that breaks clang/gcc on
ARM?

With this said i gladly volunteer during the coming months to do my best
make at least the ARM stable for the 2.6 release.

Greetings and have a great day!
Xerxes

Den 2009-08-20 01:30, Tanya Lattner skrev:

I refuse to have anything to do with the build bots anymore.

Cheers!
-bw

Wonderful. It would be helpful to write up a bug report for the bits that don't work, and then to XFAIL them, so that the bot turns green. People watch mainly for the green to red transitions, and having it forever be red (orange) isn't as useful.

Mike Stump skrev:

I have recently set-up and installed a ARM buildbot

Wonderful. It would be helpful to write up a bug report for the bits
that don't work, and then to XFAIL them, so that the bot turns green.
People watch mainly for the green to red transitions, and having it
forever be red (orange) isn't as useful.

Best would of course bee to fix the tests rather than hiding the
failures but adding XFAIL after bugreports are files and on bugs that
cant easily be fixed seems like a good idea in the long run.

Today I and Dunbar detected a large regression in the ARM JIT between
2009-07-08 rev 74992 and 2009-07-10 rev 75243 that might reduce about 20
of the failing tests if fixed.
http://llvm.org/bugs/show_bug.cgi?id=4812

I will look if i can change the storage on the buildbot from NFS to a
attach a usb harddrive, this will hopefully solve the

make[2]: warning: Clock skew detected.

warnings that are caused by different clock times on the buildbot and
the NFS server and hopefully will change all compiles from orange to green.

cheers
Xerxes