[4.0.0 Release] 'final' has been tagged

Project Infrastructure Release Testers
1

Dear testers,

The final version of 4.0.0 was just tagged (from the 4.0 branch at
r297335). There were no changes after rc4.

Please build the final binaries and upload to the sftp.

For others following along: this means 4.0.0 is complete, but it will
take a few days to get the tarballs ready and uploaded to the web
page. I will send the announcement once everything's done.

Many thanks for your hard work!

Hans

2

Built and tested OK on FreeBSD 10. I have uploaded:

SHA256 (clang+llvm-4.0.0-i386-unknown-freebsd10.tar.xz) = f3bfd0e4778d5e6b94f774e4531a61a662c7688e08b54cef5e5fc53711e65243
SHA256 (clang+llvm-4.0.0-amd64-unknown-freebsd10.tar.xz) = e8878b589c2558aeb9733661e9a23fd47d41be0dc200aa50acf7a7eb1ab53eee

-Dimitry

3

thank you for your work :slight_smile:

Uploaded in Debian, currently building:
https://buildd.debian.org/status/package.php?p=llvm-toolchain-4.0
S

4

Windows:

$ sha1sum *LLVM-4.0.0-win*.exe
b48a3dab37e2a1b5a5446b316832b9b80c6bd557 LLVM-4.0.0-win32.exe
5588c00484d5e1fe05bcce8201282b172448f6fc LLVM-4.0.0-win64.exe

Build script attached.

build_llvm_400.bat|attachment (3.76 KB)

5

Hi,
built and passed core tests on OpenMandriva x86_64, aarch64, x86_32 and armv7hl.

ttyl
bero

6

All done for Ubuntu x64:

clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-16.10.tar.xz

Ben

7

ARM and AArch64 looking good, uploaded.

4e62f3d5dcc95189eaec2d950950876a423f8a8c
clang+llvm-4.0.0-aarch64-linux-gnu.tar.xz
1b031f16683e3bcd779f50e6d47d0d1f3f265e9f
clang+llvm-4.0.0-armv7a-linux-gnueabihf.tar.xz

8

I was asked about Ubuntu x86_64 Ubuntu 14.04, so I built a package for that too:

$ sha256sum *.xz
1d15b6337ffc0876ed1a9827cae566e24639e0f5d7d186b2de04c38d762336b4
clang+llvm-4.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz

9

ARM and AArch64 looking good, uploaded.

This is not particularly related to this RC but in general with 4.0.0
I am seeing a failure quite common while building for arm

./.libs/libsqlite3.so: undefined reference to `__mulodi4'
clang-4.0: error: linker command failed with exit code 1 (use -v to

see invocation)

make: *** [Makefile:509: sqlite3] Error 1

There are few bug reports in bugzilla also reporting similar issue
e.g.

https://bugs.llvm.org//show_bug.cgi?id=14469

suggestion is to link compiler-rt which works in limited testing
but I think its a general problem where clang is assuming compiler-rt
functions will be provided during link which is fine if there was
an option to disable this behavior, I could not find any option to
do so.

10

Hi Khem,

11

Hi Khem,

>> ARM and AArch64 looking good, uploaded.
>>
>
> This is not particularly related to this RC but in general with 4.0.0
> I am seeing a failure quite common while building for arm
>
> > ./.libs/libsqlite3.so: undefined reference to `__mulodi4'
> > clang-4.0: error: linker command failed with exit code 1 (use -v to
> see invocation)
> > make: *** [Makefile:509: sqlite3] Error 1
>
> There are few bug reports in bugzilla also reporting similar issue
> e.g.
>
> https://bugs.llvm.org//show_bug.cgi?id=14469

Many of those bugs are pre-4.0.0. Did you see the same issues with
earlier LLVM versions as well, or are you saying these errors are new
with 4.0.0?

I only see it with 4.0 branch, may be I was lucky thus far.

12

Pushed macOS:

b1a351290bffd190ff190638b6f4c013b5991d6afinal/clang+llvm-4.0.0-x86_64-apple-darwin.tar.xz

13

Hi Hans

Hi Khem,

ARM and AArch64 looking good, uploaded.

This is not particularly related to this RC but in general with 4.0.0
I am seeing a failure quite common while building for arm

> ./.libs/libsqlite3.so: undefined reference to `__mulodi4'
> clang-4.0: error: linker command failed with exit code 1 (use -v to
see invocation)
> make: *** [Makefile:509: sqlite3] Error 1

There are few bug reports in bugzilla also reporting similar issue
e.g.

https://bugs.llvm.org//show_bug.cgi?id=14469

Many of those bugs are pre-4.0.0. Did you see the same issues with
earlier LLVM versions as well, or are you saying these errors are new
with 4.0.0?

I dug into a bit and here is a reproducer

#include <stddef.h>
size_t n;
size_t s;
ptrdiff_t z;
main()
{
    return __builtin_mul_overflow(n,s, &z);
}

compiling with
clang --target=armv7l -mfloat-abi=hard hello.c -S

This generates the call to __mulodi4

same code with gcc does not.

I see that sqlite3 as well as m4 package pokes the compiler for these
builtins before using them. For clang it uses __has_builtin() to
determine if a given builtin is supported before using it.

see
http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/xalloc-oversized.h

That is the source of trouble, since its in gnulib that explains why its
showing up in lot of packages.

perhaps this commit here
http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/xalloc-oversized.h?id=9c919a06435266a88d91ffb9eb3f70a82aa65b4b

brings this issue to fore.

14

I get a __mulodi4 call with your reproducer also with llvm 3.9 and
3.8, so I'm not sure this changed on our end. (I also added the
__has_builtin check from the code you linked, with the same result.)

In any case, it's no good generating calls to functions if they're not
defined in the runtime.

Can you file a bug about this in the Bugzilla and cc myself and Renato?

Thanks,
Hans

15

Hi Hans

Hi Khem,

ARM and AArch64 looking good, uploaded.

This is not particularly related to this RC but in general with 4.0.0
I am seeing a failure quite common while building for arm

> ./.libs/libsqlite3.so: undefined reference to `__mulodi4'
> clang-4.0: error: linker command failed with exit code 1 (use -v to
see invocation)
> make: *** [Makefile:509: sqlite3] Error 1

There are few bug reports in bugzilla also reporting similar issue
e.g.

https://bugs.llvm.org//show_bug.cgi?id=14469

Many of those bugs are pre-4.0.0. Did you see the same issues with
earlier LLVM versions as well, or are you saying these errors are new
with 4.0.0?

I dug into a bit and here is a reproducer

#include <stddef.h>
size_t n;
size_t s;
ptrdiff_t z;
main()
{
    return __builtin_mul_overflow(n,s, &z);
}

compiling with
clang --target=armv7l -mfloat-abi=hard hello.c -S

This generates the call to __mulodi4

same code with gcc does not.

I see that sqlite3 as well as m4 package pokes the compiler for these
builtins before using them. For clang it uses __has_builtin() to
determine if a given builtin is supported before using it.

see
xalloc-oversized.h\lib - gnulib.git - gnulib - GNU portability library

That is the source of trouble, since its in gnulib that explains why its
showing up in lot of packages.

perhaps this commit here
gnulib.git - gnulib - GNU portability library

brings this issue to fore.

I get a __mulodi4 call with your reproducer also with llvm 3.9 and
3.8, so I'm not sure this changed on our end. (I also added the
__has_builtin check from the code you linked, with the same result.)

thats right, it worked for me in past because the version of gnulib used
in m4 and sqlite3 was old which did not use __builtin_mul_overflow newer
versions have the new gnulib and hence the problem.

In any case, it's no good generating calls to functions if they're not
defined in the runtime.

nod

Can you file a bug about this in the Bugzilla and cc myself and Renato?

There is a bug already, I added you to CC, Renato is already CCed

https://bugs.llvm.org//show_bug.cgi?id=28629

16

Ah, I remember that one. A true gem that fell down the cracks and
hasn't been looked at in 4.0, I apologise.

I will put this into our roadmap and will look at it as soon as I can,
hopefully to 5.0 and if possible, back-ported to 4.0.1.

cheers,
--renato