Need 2.7 release team volunteers

Clang Frontend
#1

I’m looking for someone to qualify x86-32 linux for 2.7 and beyond.

If you want a basic idea of how the release process works, see this:
http://llvm.org/docs/HowToReleaseLLVM.html

Please email me if you are interested!

Thanks,
Tanya

#2

I looked at the mentioned page. I see in the coverage matrix:

Architecture OS compiler

#3

Hello

2. CentOS (RHEL) 5 mainline is at:
gcc-4.1.2
with engineering previews at 4.4.0

4.1.2 is assumedly less featureful than the two mentioned
versions, and 4.4.0 later --- will tests on such suffice?

Please double check - 4.1.2 might be broken:
http://llvm.org/docs/GettingStarted.html#brokengcc

#4

BTW,

I am testinbg gcc 4.4.1 on MingW and I must admit that it’s not working perfectly. On the other hand I am testing it by compiling Qt4 which is a … “interesting test case”… but then again, the problems are quite predictable but not understandable.

Which tests can I run on my side for testing clang over mingw?

#5

Hello, Diego

I am testinbg gcc 4.4.1 on MingW and I must admit that it's not working
perfectly. On the other hand I *am* testing it by compiling Qt4 which is a
... "interesting test case"... but then again, the problems are quite
predictable but not understandable.

Well, one can easily expect so.
For example, release binaries of llvm/llvm-gcc on mingw are still
compiled with mingw gcc 3.4.5 mostly due to the problems of stability
of newer gcc for mingw.

#6

Sorry, but this does not convince me.

gcc → clang.c → clang → Qt.c → Qt.exe

You say that the clang.exe compiled using mingw 4.4.1, creates bad code, which in turns clang.exe miscompiles some code…? If that would have been true - I would have seen it in my Qt/mingw4.4.1 binaries. IMHO, this means clang is misbehaving.

For me, easy to test. Just recompile clang using cl.exe, and with this compiler, compile Qt. Now the 250,000 question: how to compile clang using cmake if also gcc is in path?

I will issue a recompilation this week and report probably by Saturday.

#7

Hello, Diego

I am testinbg gcc 4.4.1 on MingW and I must admit that it's not working
perfectly. On the other hand I *am* testing it by compiling Qt4 which

is

a
... "interesting test case"... but then again, the problems are quite
predictable but not understandable.

Well, one can easily expect so.
For example, release binaries of llvm/llvm-gcc on mingw are still
compiled with mingw gcc 3.4.5 mostly due to the problems of stability
of newer gcc for mingw.

I am testing a lot clang on mingw and I confirm that toolchain from
mingw.org(4.4.0) has problems with it that's why I am using toolchain
from mingw-w64(configured to generated x86 code).
I will release an installer very soon.

#8

Vincent, can you also test with these packages?
http://www.tdragon.net/recentgcc/

#9

I'm looking for someone to qualify x86-32 linux for 2.7 and beyond.

If you want a basic idea of how the release process works, see this:
http://llvm.org/docs/HowToReleaseLLVM.html

Please email me if you are interested!

I looked at the mentioned page. I see in the coverage matrix:

Architecture OS compiler
--------------------------------
...
x86-32 Linux gcc 4.2.X, gcc 4.3.X
...
x86-64 Linux gcc 4.2.X, gcc 4.3.X

and have a couple questions

1. As clang went self hosting, should it also be added throughout the matrix to spot regressions?

We'll do it for the next release.

2. CentOS (RHEL) 5 mainline is at:
  gcc-4.1.2
with engineering previews at 4.4.0

4.1.2 is assumedly less featureful than the two mentioned versions, and 4.4.0 later --- will tests on such suffice?

4.4 is fine. Those are just a list of acceptable compilers to qualify. We dropped 3.4 basically.

[Debian testing seems to be at 4.3.4]

I already run a 'nightly', and will graft in the testing mentioned at
  http://llvm.org/docs/HowToReleaseLLVM.html

Awesome, I typically send out mail to the general list to do testing and will be sending one shortly.

I also get warnings on doco matters -- shall I file those as well?

The doxygen stuff needs to be cleaned up, but it wont be a release blocker. If you are talking about other warnings, you can file bugs, but they wont be release blockers.

Thanks,
Tanya

#10

I was working through this webpage, this week, and find that I am not understanding what is being said. Is there a tester here who has pushed the automation of this into a script that might be shared here or privately with me?

I'll keep plugging at it, but that is a more 'explorational' approach and will be slower than 'cribbing' from the worked example of another. As I am long out of school, it is perhaps all right to read another's answers on homework :wink:

-- Russ herrold

#11

If you want to qualify for a specific target, then you will need to do everthing listed on that page. I have a script to do a lot of it automatically and another to diff nightly tester results.

Typically, what I ask of the community is to do a subset. So, most will just take the pre-packaged binaries that are released as a pre-release and do the testing with those. Or some will build only release mode and do testing. I'll send out instructions for this once the pre-release1 has been released to the community.

So are you actually interested in becoming a part of the release team and doing a full qualification for some target or did you just want to do community testing? I interpreted your response as wanting to do community testing, but perhaps I was wrong.

If you wanted to become a part of the release team, please send me mail offlist with the targets you want to qualify.

Thanks,
Tanya

#12

Bah, headers still broken, sending to list this time: