On 13/10/2012 9:47 a.m., Kinkie wrote:
On Fri, Oct 12, 2012 at 7:37 PM, Alex Rousskov
<[email protected]> wrote:
On 08/01/2012 01:13 PM, Kinkie wrote:
the attached patch partly fixes CLANG support for Trunk.
- Slot slots[]; ///< slots storage
+ Slot *slots; ///< slots storage
...
+ slots=new Slot[limit];
This and similar changes in trunk r12255 broke virtually all shared
memory caching. What used to be a part of an object in shared memory
became a pointer to a local memory object. Workers were not sharing
cache contents after this (among other problems). A failed OpenSUSE
testRock unit test exposed the bug.
I believe I was OoO when this patch was posted in August so I could not
review this in time. I am sure I would have caught this otherwise. Sorry.
Thanks for looking into it now.
If there are no better ideas, I am going to undo these changes. Clang
support is nice, but not as important as working code (and we should not
expect Clang understand and help us with shared memory constraints anyway).
I agree that having something that works somewhere is better than
having something that compiles everywhere and works nowhere.
However, I would like you to explore different options, for two
reasons: one is that portability has helped us uncover some bugs in
the past, so we should try to keep it. The second is that, according
to a recent slashdot article, FreeBSD 10 could deprecate gcc in favor
of clang (see
http://bsd.slashdot.org/story/12/05/13/1646230/freebsd-10-to-use-clang-compiler-deprecate-gcc),
and FreeBSD is a platform we very much care about.
No supposition needed. Thomas the FreeBSD maintainer informed a few
months back that it was already underway for their 10 release and Squid
had been identified as one of the blockers to their removing GCC. He can
work around it for a while but we need to support clang/clang++ for
future releases.
Amos
