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

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 22 Feb 2011 15:19:21 +1300

 On Mon, 21 Feb 2011 18:27:28 -0700, Alex Rousskov wrote:
> 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?

 Nothing extra is needed on your part. Hudson just archives the job log
 for 48 hours, the changes and email are automatically reset on every new
 build.

 Amos
Received on Tue Feb 22 2011 - 02:19:24 MST

This archive was generated by hypermail 2.2.0 : Tue Feb 22 2011 - 12:00:06 MST