On Aug 24, 2011, at 6:28 PM, David Beer <dbeer at adaptivecomputing.com> wrote:
>>> ----- Original Message -----
>> On Aug 24, 2011, at 5:10 PM, David Beer <dbeer at adaptivecomputing.com>
>> wrote:
>>>>>>>>>>> ----- Original Message -----
>>>> On Aug 24, 2011, at 4:31 PM, David Beer
>>>> <dbeer at adaptivecomputing.com>
>>>> wrote:
>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>> On Wed, Aug 24, 2011 at 1:54 PM, Ken Nielson <
>>>>>>knielson at adaptivecomputing.com > wrote:
>>>>>>>>>>>>>>>>>> There is a new release candidate for TORQUE available. This has
>>>>>> the
>>>>>> fixes for the compiler warnings with the exception of
>>>>>> process_request.c, function get_creds line 288. dereferencing
>>>>>> type-punned pointer will break strict-aliasing rules.
>>>>>>>>>>>> in my opinion, this is a warning that shouldn't be ignored
>>>>>> indefinitely (not that anyone has suggested it). I think it would
>>>>>> be
>>>>>> good to fix before the official release. I would also add
>>>>>> -fno-strict-aliasing to my CFLAGS until it were fixed.
>>>>>>>>>>>> I would volunteer to the look at the code responsible for the
>>>>>> warning,
>>>>>> but I can't guarantee I would have a chance any time soon.
>>>>>>>>>>>> _______________________________________________
>>>>>> torquedev mailing list
>>>>>>torquedev at supercluster.org>>>>>>http://www.supercluster.org/mailman/listinfo/torquedev>>>>>>>>>> I tried to look at the error myself, but I didn't see any compiler
>>>>> warnings when I compiled the code:
>>>>>>>>>> $ gcc --version
>>>>> gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
>>>>> Copyright (C) 2010 Free Software Foundation, Inc.
>>>>> This is free software; see the source for copying conditions.
>>>>> There
>>>>> is NO
>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>>> PURPOSE.
>>>>>>>>>> I used to think that gcc warnings were a moving target (as Michael
>>>>> Jennings points out) because they added warnings, but it appears
>>>>> they also add and then remove things from the warning lists.
>>>>>>>>>> As far as the greater debate of whether or not gcc warnings should
>>>>> be enabled by default, I think it makes a lot of sense to only
>>>>> have
>>>>> developers compile with warnings enabled and let users just
>>>>> compile
>>>>> and run the code. When I'm a user, I only care about warnings that
>>>>> cause issues with the software. I think that this warning would
>>>>> have
>>>>> been caught as well except that it is only a warning for certain
>>>>> versions of gcc.
>>>>>>>>>> --
>>>>> David Beer
>>>>> Direct Line: 801-717-3386 | Fax: 801-717-3738
>>>>> Adaptive Computing
>>>>> 1656 S. East Bay Blvd. Suite #300
>>>>> Provo, UT 84606
>>>>>>>>>> _____________________________________________
>>>>>>>>>>>> What are your compiler flags?
>>>>>> gcc -g -W -Wall -Wno-unused-parameter -Wno-long-long -pedantic
>>> -Werror -D_LARGEFILE64_SOURCE -o .libs/printjob printjob.o
>>> ../lib/Libpbs/.libs/libtorque.so -Wl,--rpath -Wl,/usr/local/lib
>>>> I think this warning would require -O2 or higher (or explicit strict
>> aliasing optimization turned on)
>> I don't believe that optimization levels change what gcc considers a warning, but I recompiled it with -O2 and didn't receive a warning that way either.
>> gcc -g -O2 -W -Wall -Wno-unused-parameter -Wno-long-long -pedantic -Werror -D_LARGEFILE64_SOURCE -o .libs/hostn hostn.o ../lib/Libpbs/.libs/libtorque.so -Wl,--rpath -Wl,/usr/local/lib
Optimization level can affect what is considered a warning -- without strict aliasing optimization enabled there are no strict aliasing rules to break