Re: [PATCH] improve hack in src/base/TextException.h

On 02/20/2011 10:05 PM, Amos Jeffries wrote:
> On 21/02/11 16:40, Alex Rousskov wrote:
>> On 02/18/2011 05:43 PM, Amos Jeffries wrote:
>>> On 19/02/11 11:25, Alex Rousskov wrote:
>>>> On 01/31/2011 07:17 AM, Kinkie wrote:
>>>>> TextException.h includes an hack to avoid the compiler noticing that
>>>>> there are multiple instances of FileNameHashCached() in the compiled
>>>>> binary.
>>>>> Intel's icc doesn't like the way it is implemented, and instead of
>>>>> trying to figure out how to have it stop complaining, I propose to use
>>>>> a specific-purpose gcc construct, as done in this patch. Thoughts?
>>>>> Votes?
>>>>
>>>> What does icc complain about? Kind of hard to agree to add more crap
>>>> without seeing what the real problem that needs fixing is...
>>>>
>>>> Alex.
>>>
>>> Current trunk with the patch reverted fails on ICC showing:
>>>
>>> ../../../src/base/TextException.h(66): error #42: operand types are
>>> incompatible ("void *" and "unsigned int (*)(const char *)")
>>> bool use(void *ptr=(__null)) { return ptr !=&FileNameHashCached;}
>>>
>>>
>>> With a marker pointing at the != comparison.
>>
>> Looks like casting&FileNameHashCached to (void*) would fix this.
>>
>>
>>> If you have any alternative fix ideas the 3.ALPHA-patch job in hudson
>>> works. You just have to include reversal of the rev11236 change since it
>>> has already been committed.
>>
>> Sorry, I am not sure I understand the above. Should I reverse r11236 and
>> commit a casting fix? Or do you want be to post a patch that some Hudson
>> job will pick up and test somehow first?
>
> This is what I mean....
>
> To test that suspected fix:
> (on a checkout of trunk with nothing pending)
>
> bzr revert -c11236 .
> ... edit the new fix into files
> bzr diff >test.patch
> ... login to Hudson
> ... click on "build job" for 3.ALPHA-PATCH-amd64-CentOs-icc
> ... upload test.patch as the file and set your email address to get the
> results.
>
> It takes about 10 minutes to reach that file. You get an email report of
> what is now causing the failure, anything past base/TextException.h and
> it has worked.
>
> If it fails you can revert change on your checkout and no harm done.
>
>
> :-) no trunk commit until it is confirmed. :-)

Looks like the test passed. The build now fails with
src/HttpRequestMethod.h(140): error #858: type qualifier on return type
is meaningless

Should I remove this specific build job? Or leave it and re-assign its
configured notification address back to squid-dev?

> repeat the build step on the other 3.ALPHA jobs if you want portability
> confirmation.

Committed to let the automated build do that for me...

Thank you,

Alex.
Received on Tue Feb 22 2011 - 01:27:39 MST