We held a GCC mini-summit at Google on Wednesday, April 18. About 40
people came. This is my very brief summary of what we talked about.
Corrections and additions very welcome.
The goal of the mini-summit was just to let gcc developers meet face
to face and talk. There was no goal of actually making any decisions,
and, indeed, no decisions were made.
If you comment on some particular item here, I'd like to suggest that
you change the Subject line so that conversations can be tracked more
easily.
I didn't do a good job of recording who said what. And indeed most of
this is from memory. I apologize for any mistakes or slights. They
are entirely unintentional.
1) Introductions.
2) A phone call with Uday Khedker and other gcc developers in India
from IIT Bombay in Mumbai. David Edelsohn arranged for this to
happen. The call had to be from another room, and I didn't
participate, so I don't have any details.
3) A discussion of gcc 4.2 and the gcc release process in general.
Nobody objected to shipping gcc 4.2 today, even though it does not
meet the goal of fewer than 100 regressions from an earlier
release. People did comment that we should fix all the P1 bugs
before shipping.
We count regressions from any old release. That means that we have
open bugs which were regressions in 3.x, but we are still counting
them as release-blocking regressions. There were a few suggestions
about how to avoid this:
a) only count regressions from the last two releases.
b) discount old regressions over time, perhaps by lowering their
priority.
c) add voting to bugzilla for which old regressions should count as
release-blocking. Somebody suggested using the number of e-mail
addresses CC'ed on the bug as votes.
d) some people commented that this was a good thing, since it
encourages us to fix old regressions, and that we should not
avoid it at all.
Somebody observed that our focus on regressions can cause us to
ignore important wrong-code bugs which should be fixed even if they
are not actually regressions--perhaps they are bugs in new features
which were not present in earlier versions.
4) A discussion of dataflow. Ken Zadeck described the current state
of dataflow branch. It seems stable, and just about within the
compilation time guidelines set by the SC. He will do more testing
and retesting this weekend, and hopes to commit it to mainline
quite soon, maybe as early as next week if the testing goes well.
5) A discussion of tuples, the IR, and LTO. Diego Novillo described
the tuples proposal, which is an incremental change to the IR. Ken
Zadeck described the current state of his LTO work. He described
LTO as having three parts: writing out types, which is being done
in DWARF; serializing trees; eliminating langhooks.
Discussion about writing out types in DWARF, since apparently
several new DWARF attributes had to be invented to capture
everything that gcc cares about. Michael Eager pointed out that if
the new attributes would be of use for the debugger, he and the
DWARF standardization committee would like to hear about them.
Discussion of LTO and IMA; Geoff Keating said that if LTO works
better than IMA, IMA should be removed. There was some concern
that LTO would be slower than IMA, since in some ways it has to do
more work, since the trees have to be written out and read in;
however, in other ways it does less work.
Discussion of a middle-end type system. Daniel Berlin said that it
wasn't clear that we really needed a type system. He proposed that
the middle-end use structural equivalence for the type system, and
that front-ends annotate types which appear the same but are not.
Interestingly, the types_compatible_p langhook is only used for C
and C++ at present. People talked about the consequences for
debugging information, with no clear outcome. Frontends would have
to annotate types with their alias set in order for TBAA to work
properly.
6) Lunch at the main Google cafeteria.
7) Daniel Berlin described the most recent draft of GPLv3. His
conclusion is that, unlike earlier drafts, it is not substantially
different from GPLv2. There was a fair amount of discussion. In
particular there was some concern about the libgcc exception
license, and whether that could ever go away. The general feeling
was that that was unlikely.
8) A discussion of register allocation. This didn't go too far as
none of the people working on register allocation were there.
Diego Novillo briefly described Vlad Makarov's work and mentioned
Andrew MacLeod's work. David Edelsohn mentioned Peter Bergner's
work. There was some discussion of eliminating reload as the first
step, and of taking pieces out of reload as the first incremental
step.
9) A discussion of maintainership and code review. We discussed the
new non-algorithmic maintainers, and there was general agreement
that it seemed to be OK. Zdenek Dvorak mentioned that the
boundaries of non-algorithmic were unclear, and Joe Buck agreed
that that was inevitable.
We talked about variants on the current system, like having people
who could approve other people's patches but did not have the right
to commit their own patches. It is clear that some people already
review patches which they can not approve. This is a good thing
but there was no clear idea of how to encourage it. Diego Novillo
talked about the difficulties of switching between code writing
mode and patch review mode.
We discussed the patch tracker. None of the active maintainers who
were there appear to use it very much or at all. I proposed
automatic e-mail pings, but that wasn't generally welcomed.
Richard Henderson suggested that the patch tracker should have a
way to quickly and easily approve a patch. A couple of people said
it would be nice to be able to use the tracker to send an e-mail
reply; it does provide a mechanism for that, but it is web-based
rather than being part of one's usual mail reader. One possibility
mentioned was to have a button for the patch tracker to send the
maintainer a copy of the e-mail, which would be a convenient way to
write the reply in a preferred mail reader.
10) Eric Christopher reported that Tom Tromey (who was not present)
had suggested a new mascot for gcc: a unicorn with rainbows. This
was met with general approval, and Eric suggested that everybody
e-mail Tom with their comments. I personally would like to see
the drawing.
11) H.J. Lu discussed SPEC CPU 2006. He reported that a couple of the
tests do not run successfully, and it appears to be due to bugs in
the tests which cause gcc to compile them in unexpected ways. He
has been reporting the problems to the SPEC committee, but is
being ignored. He encouraged other people to try it themselves
and make their own reports.
12) Jose Dana reported his results comparing different versions of gcc
and icc at CERN. They have a lot of performance sensitive C++
code, and have gathered a large number of standalone snippets
which they use for performance comparisons. Some of these can
directly become bugzilla enhancement requests. In general this
could ideally be turned into a free performance testsuite. All
the code is under free software licenses.
13) Michael Meissner raised the idea of compiling functions
differently for different processors, choosing the version based
on a runtime decision. This led to some discussion of how this
could be done effectively. In particular if there is an
architectural difference, such as Altivec, you may get prologue
instructions which save and restore registers which are not
present on all architectures.
14) I asked whether people found the meeting to be valuable. The
general sense was that it was. I asked whether people would be
interested in coming to another one in the future. The general
sense was that they would. So perhaps we will hold another one in
the fall, either at Google or elsewhere.
15) We adjourned for ice cream.
