This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Enable building of libsanitizer on sparc linux again.
On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany
> On Sat, Nov 17, 2012 at 7:10 PM, David Miller <firstname.lastname@example.org> wrote:
>> From: Konstantin Serebryany <email@example.com>
>> Date: Sat, 17 Nov 2012 19:01:56 -0800
>>> I am open to suggestions on how to avoid forking the two versions.
>>> If we fork, the original asan team will not be able to cope with two
>> The maintainer of the sanitizer's job is to do the merging and resolve
>> the conflicts between the two trees. This is how every other similar
>> situation is handled.
> I am new to the gcc community and may not know all the rules.
> But your nice words (lunacy, garbage, etc) are not helping us.
> As for the particular problem, I did not even see a patch (did I miss
> it? Sorry, I am just back from a long trip)
> I'd prefer to mention the ARCHs explicitly where possible, i.e.
> #if defined(__x86_64__) || definde (__sparc64__)
> instead of
> #if __WORDSIZE == 64 || ...
How about splitting this into a different config directory right now.
Maybe I will do this later today. This is what was needed when it was
merged into GCC rather than all of these #ifdef all over the code.
Look at how either libgomp or even glibc handles cases like this.
They have include directories which is based on the target and maybe
even a common directory which each target can over ride it (glibc is
the best at doing this).
The whole double review process is hard for the target maintainers of
GCC to work really. Target maintainers in GCC is not normally like an
extra review step as it does slow down the whole process of getting a
target patch reviewed.
>> What's happening here, frankly, is garbage.
>> The current situation is unacceptable and HJ's fix should go into the
>> GCC tree right now.
>> The current situation is preventing people from getting work done, and
>> unnecessarily consuming developer resources.