[3.9 Release] Release Candidate 2 source and binaries available

We're getting close to the final release. I know the schedule on the
web page says 'final' should be tagged today, but I still think it
should be possible to get there this week.

Source and binaries for LLVM-3.9.0-rc2 are now available at
http://llvm.org/pre-releases/3.9.0/#rc2

Please try it out and let me know if you find any issues.

As we're running out of time, RC2 will be a short test cycle, so if
you're planning on testing it, please don't procrastinate it :slight_smile:

Thanks,
Hans

Hi Hans,

I did upload the aarch64 binary, didn’t you find it? Maybe I uploaded the wrong one?

Cheers,
Renato

I replied on the "has been tagged" thread; I couldn't find the binary
on the sftp. Maybe you uploaded the wrong version, or in some other
folder?

Didn’t see the reply, sorry. I’ll try again tomorrow.

clang+llvm-3.9.0-rc2-aarch64-linux-gnu.tar.xz
sha1sum: ecd0387db850c1382839dec11c60806f3829953f

Same file as before, so I probably uploaded to the wrong folder. :slight_smile:

Also, it'd be good to clean up that dir, as there are files since 3.4
there and it's hard to see what's in there already and what's not.

I don't think we need to keep all RCs from all past revisions in
there, and the official versions are already somewhere else.

cheers,
--renato

I replied on the "has been tagged" thread; I couldn't find the binary
on the sftp. Maybe you uploaded the wrong version, or in some other
folder?

clang+llvm-3.9.0-rc2-aarch64-linux-gnu.tar.xz
sha1sum: ecd0387db850c1382839dec11c60806f3829953f

Same file as before, so I probably uploaded to the wrong folder. :slight_smile:

Thanks!

Also, it'd be good to clean up that dir, as there are files since 3.4
there and it's hard to see what's in there already and what's not.

I don't think we need to keep all RCs from all past revisions in
there, and the official versions are already somewhere else.

Good point. I've cleared out the dir now. All the old pre-release
binaries are kept at http://llvm.org/pre-releases/ anyway.

Cheers,
Hans

Thanks!

--renato

Hi,

I noticed a regression in this build…

libclang, code completeAt…
the results returned inbuilt libraries, i.e. memset

all come back as char* functionname( void)

if I go back to older build (3.7.1) then this information returns.

Any ideas?

Dan

Hi Dan,

Can you narrow down the problem a bit more?

Is this only with the RC2? Or also with RC1? Does it work with 3.8.0
or 3.8.1? Some version of trunk?

Also, that is a *very* high level description of the problem and it's
really hard to reproduce it. This may be a problem in backwards
compatibility of libclang (which shouldn't happen), or it could be
that the completeAt usage was assuming something that wasn't true.

If you could create a bug explaining the process, stating the most
recent version that you can see it working, and how to reproduce
without any additional tools (ie. by using libclang directly,
preferably with a piece of code that does it), then Clang folks could
have a better look at that.

cheers,
--renato

Hi Renato,

Ok so far I have tested with RC1 and RC2 they both show the regression.

Ok I will try to create a repo and get back in touch.

Thanks

Dan

I've tried to reproduce this, but can't see any difference between
completeAt in 3.7.1 and 3.9-rc2:

$ wget http://llvm.org/releases/3.7.1/clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
$ tar Jxf clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
$ g++ libclang_test.cc -I
clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04/include -L
clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04/lib -lclang
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:clang+llvm-3.7.1-x86_64-linux-gnu-ubuntu-14.04/lib
./a.out | head
string: 0 chunk: 0 kind: 15 text: char *
string: 0 chunk: 1 kind: 1 text: stpcpy
string: 0 chunk: 2 kind: 6 text: (
string: 0 chunk: 3 kind: 3 text: char *__restrict __dest
string: 0 chunk: 4 kind: 14 text: ,
string: 0 chunk: 5 kind: 3 text: const char *__restrict __src
string: 0 chunk: 6 kind: 7 text: )
string: 1 chunk: 0 kind: 15 text: void *
string: 1 chunk: 1 kind: 1 text: rawmemchr
string: 1 chunk: 2 kind: 6 text: (

$ wget http://llvm.org/pre-releases/3.9.0/rc2/clang+llvm-3.9.0-rc2-x86_64-linux-gnu-debian8.tar.xz
$ tar Jxf clang+llvm-3.9.0-rc2-x86_64-linux-gnu-debian8.tar.xz
$ g++ libclang_test.cc -I
clang+llvm-3.9.0-rc2-x86_64-linux-gnu-debian8/include -L
clang+llvm-3.9.0-rc2-x86_64-linux-gnu-debian8/lib -lclang
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:clang+llvm-3.9.0-rc2-x86_64-linux-gnu-debian8/lib
./a.out | head
string: 0 chunk: 0 kind: 15 text: char *
string: 0 chunk: 1 kind: 1 text: strncat
string: 0 chunk: 2 kind: 6 text: (
string: 0 chunk: 3 kind: 3 text: char *__restrict __dest
string: 0 chunk: 4 kind: 14 text: ,
string: 0 chunk: 5 kind: 3 text: const char *__restrict __src
string: 0 chunk: 6 kind: 14 text: ,
string: 0 chunk: 7 kind: 3 text: int __n
string: 0 chunk: 8 kind: 7 text: )
string: 1 chunk: 0 kind: 15 text: void *

Could it be that the newer clang for some reason grabs the string.h
header from a different location than the old one? "clang -v" should
print where it searches for headers.

char* functionname( void)

looks like a very strange prototype for memset though.

- Hans

a.cc (36 Bytes)

libclang_test.cc (1.23 KB)

Hi,

Ok here are my precise instructions which reproduce the issue.
I have copied my files including the library being used into a 7zip format.

Extract the zip file to c:\

This will extract a folder called AvalonStudio (the IDE I have integrated Clang into.) Don’t worry its only 20mb of files for minimal repro.

Then run your test on the file.

AvalonStudio\Projects\Repro\Repro\main.cpp
(you will see I have half completed memset function.)

with the following compiler arguments…
"-isystemc:\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.Clang\arm-none-eabi\include -isystemc:\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.Clang\lib\gcc\arm-none-eabi\5.4.1\include -xc++ -std=c++14 -Wunused-variable "

(if you are on Linux replace c:\ with the dir where you extracted zip file.)

Many thanks for looking at this with me.

Dan

repro.7z (1.91 MB)

Hi,

Ok here are my precise instructions which reproduce the issue.
I have copied my files including the library being used into a 7zip format.

Here is the link to download (I had attached it but I think it was rejected by email server)
https://1drv.ms/u/s!Avy6wigimZy_qY5T9uqsxkkmz0_QQg

Extract the zip file to c:\ (or on Linux ~)

This will extract a folder called AvalonStudio (the IDE I have integrated Clang into.) Don’t worry its only 20mb of files for minimal repro.

Then run your test on the file.

AvalonStudio\Projects\Repro\Repro\main.cpp
(you will see I have half completed memset function.)

with the following compiler arguments…
"-isystemc:\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.Clang\arm-none-eabi\include -isystemc:\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.Clang\lib\gcc\arm-none-eabi\5.4.1\include -xc++ -std=c++14 -Wunused-variable "

(if you are on Linux replace c:\ with the dir where you extracted zip file.)

Many thanks for looking at this with me.

Dan

Hans,

Did you have chance to try this repro?
I looked in the library header and the memset prototype looks normal, but libclang still reports the weird one.

Thanks

Dan

Apologies for the slow reply.

I've tried your repro (attaching my adjusted test program), but the
memset prototype it prints looks fine to me:

string: 2 chunk: 0 kind: 15 text: void *
string: 2 chunk: 1 kind: 1 text: memset
string: 2 chunk: 2 kind: 6 text: (
string: 2 chunk: 3 kind: 3 text: void *
string: 2 chunk: 4 kind: 14 text: ,
string: 2 chunk: 5 kind: 3 text: int
string: 2 chunk: 6 kind: 14 text: ,
string: 2 chunk: 7 kind: 3 text: int
string: 2 chunk: 8 kind: 7 text: )

There must be something else going on here, but it's hard for me to
tell without a self-contained reproducer. I also haven't used libclang
before, so if others have ideas here please chime in.

- Hans

libclang_test.cc (1.7 KB)