compile with gcc option -O0 or -O

compile with gcc option -O0 or -O

[zou wonder]

HI guys:
 i am compiling codes with gcc4.4.4 :

but one weird problem is that the following codes compiled with option -O0

, then the logic could works well.

static BOOLE
tc_user_info_is_present
(
     VARIABLE_STR *var,
     VTASK        *task
)
{
   BOOLE result;

   if (mapIs_user_information(mapAsn)){
     result = 1;
   }
   else
   {
     result = 0;
   }
   return result;
}
but compiled with -O the codes could not work well.

but when i add some Trace in the code, compiled with -O , could also work well.


static BOOLE
tc_user_info_is_present
(
     VARIABLE_STR *var,
     VTASK        *task
)
{
   BOOLE result;

   if (mapIs_user_information(mapAsn)){
   XMM_ERROR("USER INFO SET");
     result = 1;
   }
   else
   {
    XMM_ERROR("USER INFO NOT SET");
     result = 0;
   }
   return result;
}

so my question is the what's the difference between the two options.

what's wrong with my program.

and the program is compiled in 64bit linux with -m32 option

thanks.

Re: compile with gcc option -O0 or -O

[Ian Lance Taylor]

zou wonder <wonder.zou@gmail.com> writes:

> but one weird problem is that the following codes compiled with option -O0

You need to show us a small complete self-contained example.

Normally a program which works at -O0 and fails at -O1 has an
uninitialized variable somewhere.

Ian

Re: compile with gcc option -O0 or -O

[David Brown]

On 16/09/2011 07:40, Ian Lance Taylor wrote:
> zou wonder<wonder.zou@gmail.com>  writes:
>
>> but one weird problem is that the following codes compiled with option -O0
>
> You need to show us a small complete self-contained example.
>
> Normally a program which works at -O0 and fails at -O1 has an
> uninitialized variable somewhere.
>
> Ian
>

Another common cause is aliasing - using pointer casts to access the 
same data in different ways.

And (especially if this is embedded programming), also check for missing 
"volatile" qualifiers.

Compile your code with lots of warnings - that will help spot mistakes. 
  The flags I often use are:

-Wall
-Wextra
-Winit-self
-Wmissing-include-dirs
-Wunused
-Wstrict-overflow
-Wfloat-equal
-Wundef
-Wunsafe-loop-optimizations
-Wpointer-arith
-Wcast-qual
-Wcast-align
-Wwrite-strings
-Wlogical-op
-Wmissing-declarations
-Wmissing-noreturn
-Wmissing-format-attribute
-Winline
-Wnested-externs
-Wdisabled-optimization
-Wunsafe-loop-optimizations
-Wpadded
-Wunreachable-code
-Wmissing-prototypes
-Wredundant-decls
-Wcast-qual
-Wcast-align
-Wpointer-arith
-Wnested-externs
-Wno-multichar

Re: compile with gcc option -O0 or -O

[Miles Bader]

David Brown <david@westcontrol.com> writes:
>>> but one weird problem is that the following codes compiled with option -O0
>>
>> You need to show us a small complete self-contained example.
>>
>> Normally a program which works at -O0 and fails at -O1 has an
>> uninitialized variable somewhere.
>
> Another common cause is aliasing - using pointer casts to access the
> same data in different ways.
>
> And (especially if this is embedded programming), also check for missing
> "volatile" qualifiers.
>
> Compile your code with lots of warnings - that will help spot
> mistakes. The flags I often use are:
>
> -Wall
> -Wextra
> -Winit-self
> -Wmissing-include-dirs
...

... but be a bit wary of any warning option which isn't included in
-Wall or -Wextra -- they're usually omitted for a reason (typically
because they yield tons of false positives on reasonable code).

-Miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: compile with gcc option -O0 or -O

[Jeffrey Walton]

On Fri, Sep 16, 2011 at 3:07 AM, David Brown <david@westcontrol.com> wrote:
> On 16/09/2011 07:40, Ian Lance Taylor wrote:
>>
>> zou wonder<wonder.zou@gmail.com>  writes:
>>
>>> but one weird problem is that the following codes compiled with option
>>> -O0
>>
>> You need to show us a small complete self-contained example.
>>
>> Normally a program which works at -O0 and fails at -O1 has an
>> uninitialized variable somewhere.
>>
>> Ian
>>
>
> Another common cause is aliasing - using pointer casts to access the same
> data in different ways.
>
> And (especially if this is embedded programming), also check for missing
> "volatile" qualifiers.
>
> Compile your code with lots of warnings - that will help spot mistakes.  The
> flags I often use are:
>
> -Wall
> -Wextra
> -Winit-self
> -Wmissing-include-dirs
> -Wunused
> -Wstrict-overflow
> -Wfloat-equal
> -Wundef
> -Wunsafe-loop-optimizations
> -Wpointer-arith
> -Wcast-qual
> -Wcast-align
> -Wwrite-strings
> -Wlogical-op
> -Wmissing-declarations
> -Wmissing-noreturn
> -Wmissing-format-attribute
> -Winline
> -Wnested-externs
> -Wdisabled-optimization
> -Wunsafe-loop-optimizations
> -Wpadded
> -Wunreachable-code
> -Wmissing-prototypes
> -Wredundant-decls
> -Wcast-qual
> -Wcast-align
> -Wpointer-arith
> -Wnested-externs
> -Wno-multichar
-Wformat=2 -Wformat-security? Great use of the tools, though. GCC has
some awesome diagnostic capabilities.

Jeff

Re: compile with gcc option -O0 or -O

[zou wonder]

hi david:
i have tried to enable all the warning option you provided :
and here are some warnings:

                from xmmmapte.cc:3:
/work/smsc/include/stlport/stl/_ostream.h:357: warning: inlining
failed in call to ‘stlpmtx_std::basic_ostream<_CharT, _Traits>&
stlpmtx_std::endl(stlpmtx_std::basic_ostream<_CharT, _Traits>&) [with
_CharT = char, _Traits = stlpmtx_std::char_traits<char>]’: call is
unlikely and code size would grow
/work/smsc/include/stlport/stl/_ostream.h:78: warning: called from here
In file included from xmmmapte.cc:3:
/work/smsc/include/stlport/stl/_string.h: In function ‘void
set_map_perror_from_report_cause(VARIABLE_STR*, VTASK*)’:
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2166: warning: called from here
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2166: warning: called from here
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2166: warning: called from here
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2166: warning: called from here
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2168: warning: called from here
/work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
_Alloc>::~basic_string() [with _CharT = char, _Traits =
stlpmtx_std::char_traits<char>, _Alloc =
stlpmtx_std::allocator<char>]’: call is unlikely and code size would
grow
xmmmap.cc:2168: warning: called from here
In file included from /work/smsc/include/stlport/stl/_string_io.h:23,

                 from /work/smsc/include/xmmhdrmx.h:24,
                 from xmmmanmx.cc:21:
/work/smsc/include/xrslimmx.h:213: warning: padding struct to align
‘xrsIpSocketParameters_s::portNumber’
In file included from /work/smsc/include/xsc_common_mx.h:25,
                 from /work/smsc/include/xscalamx.h:31,
                 from /work/smsc/include/xmmhdrmx.h:24,
                 from xmmmanmx.cc:21:
/work/smsc/include/xrsdefmx.h:54: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:59: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:89: warning: padding struct to align
‘<anonymous struct>::smUserData’
/work/smsc/include/xrsdefmx.h:93: warning: padding struct to align
‘<anonymous struct>::tariffClass’
/work/smsc/include/xrsdefmx.h:83: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:106: warning: padding struct to align
‘<anonymous struct>::msgRef’
/work/smsc/include/xrsdefmx.h:114: warning: padding struct to align
‘<anonymous struct>::msgRef’
/work/smsc/include/xrsdefmx.h:116: warning: padding struct to align
‘<anonymous struct>::destIMSIAddr’
/work/smsc/include/xrsdefmx.h:118: warning: padding struct to align
‘<anonymous struct>::smUserData’
/work/smsc/include/xrsdefmx.h:125: warning: padding struct to align
‘<anonymous struct>::msgRef’
/work/smsc/include/xrsdefmx.h:127: warning: padding struct to align
‘<anonymous struct>::smUserData’
/work/smsc/include/xrsdefmx.h:130: warning: padding struct to align
‘<anonymous struct>::origIMSIAddr’
/work/smsc/include/xrsdefmx.h:137: warning: padding struct to align
‘<anonymous struct>::msgRef’
/work/smsc/include/xrsdefmx.h:146: warning: padding struct to align
‘<anonymous struct>::msgRef’
/work/smsc/include/xrsdefmx.h:162: warning: padding struct to align
‘<anonymous struct>::destIMSIAddr’
/work/smsc/include/xrsdefmx.h:164: warning: padding struct to align
‘<anonymous struct>::smUserData’
/work/smsc/include/xrsdefmx.h:172: warning: padding struct to align
‘<anonymous struct>::moSmLimit’
/work/smsc/include/xrsdefmx.h:198: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:205: warning: padding struct to align
‘<anonymous struct>::imsiAddr’
/work/smsc/include/xrsdefmx.h:203: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:212: warning: padding struct to align
‘<anonymous struct>::cause’
/work/smsc/include/xrsdefmx.h:225: warning: padding struct size to
alignment boundary
/work/smsc/include/xrsdefmx.h:317: warning: padding struct to align ‘WPrim::req’

thanks
On Fri, Sep 16, 2011 at 2:31 PM, Ian Lance Taylor <iant@google.com> wrote:
> zou wonder <wonder.zou@gmail.com> writes:
>
>> another is what is the difference between -O0 and -O?
>
> Please reply to the mailing list, not just to me.  Thanks.
>
> -O0 means no optimization.  -O, which is the same as -O1, means to
> optimize the code.  This is explained in the manual.
>
>
>> On Fri, Sep 16, 2011 at 2:16 PM, zou wonder <wonder.zou@gmail.com> wrote:
>>> Hi Ian:
>>>
>>>     Acctually, i intercept the codes from our product, and there are
>>> tons of lines.
>>>
>>> so how can i provide that useful information?
>
> I don't know.  What I do know is that we can't help you without seeing
> much more of the program.  The tiny bit of code you showed looked fine.
> The problem was probably somewhere else.
>
> Ian
>
>
>>> On Fri, Sep 16, 2011 at 1:40 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>> zou wonder <wonder.zou@gmail.com> writes:
>>>>
>>>>> but one weird problem is that the following codes compiled with option -O0
>>>>
>>>> You need to show us a small complete self-contained example.
>>>>
>>>> Normally a program which works at -O0 and fails at -O1 has an
>>>> uninitialized variable somewhere.
>>>>
>>>> Ian
>>>>
>>>
>

Re: compile with gcc option -O0 or -O

[David Brown]

On 16/09/2011 09:54, Miles Bader wrote:
> David Brown<david@westcontrol.com>  writes:
>>>> but one weird problem is that the following codes compiled with option -O0
>>>
>>> You need to show us a small complete self-contained example.
>>>
>>> Normally a program which works at -O0 and fails at -O1 has an
>>> uninitialized variable somewhere.
>>
>> Another common cause is aliasing - using pointer casts to access the
>> same data in different ways.
>>
>> And (especially if this is embedded programming), also check for missing
>> "volatile" qualifiers.
>>
>> Compile your code with lots of warnings - that will help spot
>> mistakes. The flags I often use are:
>>
>> -Wall
>> -Wextra
>> -Winit-self
>> -Wmissing-include-dirs
> ...
>
> ... but be a bit wary of any warning option which isn't included in
> -Wall or -Wextra -- they're usually omitted for a reason (typically
> because they yield tons of false positives on reasonable code).
>

That depends on your definition of "reasonable code" !  I don't mean to 
say that the warnings /I/ use will suit everyone - or every type of 
programming.  I often have to reduce them if I am working with other 
people's code, to avoid having lots of minor warning messages that can 
make real problems hard to spot.

An example here would be my insistence on "-Wmissing-declarations 
-Wnested-externs -Wmissing-prototypes -Wredundant-decls".  When I write 
code, an object (variable, function, etc.) is either exported by a 
module, or it is local to a module.  That means it is either declared 
"extern" in "module.h" and defined in "module.c" (which must #include 
"module.h"), or it is defined "static" in "module.c".  And any external 
objects that are used must be accessed from #include'ing the other 
module's header file.  I think these are good rules for the code I write 
(though I can see that some types of code need more flexibility), and 
these warnings help enforce them.  But if you take typical old-fashioned 
(IMHO, of course) code then most objects are defined without "static" 
qualifiers or "extern" definitions, leading to lots of warnings.

And there are other warning flags that will be useful to other people, 
but not to me - "-pedantic" would be useful for people writing code that 
must work with different compilers, for example.

gcc has excellent static error checking capabilities - I make as much 
use of them as I can.

Re: compile with gcc option -O0 or -O

[David Brown]

On 16/09/2011 11:12, zou wonder wrote:
> hi david:
> i have tried to enable all the warning option you provided :
> and here are some warnings:
>

As I mentioned in another post, those were warning flags /I/ use, and 
may not suit other people's code.  In particular, you want to disable 
flags for warnings that don't affect the correctness of the code but 
lead to lots of warnings.  In your case here, all the warnings have come 
from two flags: -Winline, and -Wpadded.

-Winline warns you when the compiler does not inline a function that is 
otherwise marked for inlining (either explicitly, or implicitly from a 
class definition).  Normally I would say that this indicates that 
something is not happening as you expect it to, perhaps due to an error 
in your code.  But as gcc gets steadily smarter, it finds good reasons 
to ignore the "inline" hint.

-Wpadded warns when structs have extra space added for alignment 
purposes.  For the type of code I write, if there is extra space in the 
struct then I've made a mistake in the definition, so I like this 
warning.  For many other types of code, the warnings are just annoying 
noise.  It really depends on whether the struct has to match an existing 
external structure, or if it is only used within the program.

So remove these two and compile again.  Alternatively, begin with just 
"-Wall -Wextra" and see if they help you spot your mistake - most code 
should compile cleanly with these enabled.

mvh.,

David



>                  from xmmmapte.cc:3:
> /work/smsc/include/stlport/stl/_ostream.h:357: warning: inlining
> failed in call to ‘stlpmtx_std::basic_ostream<_CharT, _Traits>&
> stlpmtx_std::endl(stlpmtx_std::basic_ostream<_CharT, _Traits>&) [with
> _CharT = char, _Traits = stlpmtx_std::char_traits<char>]Â’: call is
> unlikely and code size would grow
> /work/smsc/include/stlport/stl/_ostream.h:78: warning: called from here
> In file included from xmmmapte.cc:3:
> /work/smsc/include/stlport/stl/_string.h: In function ‘void
> set_map_perror_from_report_cause(VARIABLE_STR*, VTASK*)Â’:
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2166: warning: called from here
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2166: warning: called from here
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2166: warning: called from here
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2166: warning: called from here
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2168: warning: called from here
> /work/smsc/include/stlport/stl/_string.h:372: warning: inlining failed
> in call to ‘stlpmtx_std::basic_string<_CharT, _Traits,
> _Alloc>::~basic_string() [with _CharT = char, _Traits =
> stlpmtx_std::char_traits<char>, _Alloc =
> stlpmtx_std::allocator<char>]Â’: call is unlikely and code size would
> grow
> xmmmap.cc:2168: warning: called from here
> In file included from /work/smsc/include/stlport/stl/_string_io.h:23,
>
>                   from /work/smsc/include/xmmhdrmx.h:24,
>                   from xmmmanmx.cc:21:
> /work/smsc/include/xrslimmx.h:213: warning: padding struct to align
> ‘xrsIpSocketParameters_s::portNumber’
> In file included from /work/smsc/include/xsc_common_mx.h:25,
>                   from /work/smsc/include/xscalamx.h:31,
>                   from /work/smsc/include/xmmhdrmx.h:24,
>                   from xmmmanmx.cc:21:
> /work/smsc/include/xrsdefmx.h:54: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:59: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:89: warning: padding struct to align
> ‘<anonymous struct>::smUserData’
> /work/smsc/include/xrsdefmx.h:93: warning: padding struct to align
> ‘<anonymous struct>::tariffClass’
> /work/smsc/include/xrsdefmx.h:83: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:106: warning: padding struct to align
> ‘<anonymous struct>::msgRef’
> /work/smsc/include/xrsdefmx.h:114: warning: padding struct to align
> ‘<anonymous struct>::msgRef’
> /work/smsc/include/xrsdefmx.h:116: warning: padding struct to align
> ‘<anonymous struct>::destIMSIAddr’
> /work/smsc/include/xrsdefmx.h:118: warning: padding struct to align
> ‘<anonymous struct>::smUserData’
> /work/smsc/include/xrsdefmx.h:125: warning: padding struct to align
> ‘<anonymous struct>::msgRef’
> /work/smsc/include/xrsdefmx.h:127: warning: padding struct to align
> ‘<anonymous struct>::smUserData’
> /work/smsc/include/xrsdefmx.h:130: warning: padding struct to align
> ‘<anonymous struct>::origIMSIAddr’
> /work/smsc/include/xrsdefmx.h:137: warning: padding struct to align
> ‘<anonymous struct>::msgRef’
> /work/smsc/include/xrsdefmx.h:146: warning: padding struct to align
> ‘<anonymous struct>::msgRef’
> /work/smsc/include/xrsdefmx.h:162: warning: padding struct to align
> ‘<anonymous struct>::destIMSIAddr’
> /work/smsc/include/xrsdefmx.h:164: warning: padding struct to align
> ‘<anonymous struct>::smUserData’
> /work/smsc/include/xrsdefmx.h:172: warning: padding struct to align
> ‘<anonymous struct>::moSmLimit’
> /work/smsc/include/xrsdefmx.h:198: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:205: warning: padding struct to align
> ‘<anonymous struct>::imsiAddr’
> /work/smsc/include/xrsdefmx.h:203: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:212: warning: padding struct to align
> ‘<anonymous struct>::cause’
> /work/smsc/include/xrsdefmx.h:225: warning: padding struct size to
> alignment boundary
> /work/smsc/include/xrsdefmx.h:317: warning: padding struct to align ‘WPrim::req’
>
> thanks
> On Fri, Sep 16, 2011 at 2:31 PM, Ian Lance Taylor<iant@google.com>  wrote:
>> zou wonder<wonder.zou@gmail.com>  writes:
>>
>>> another is what is the difference between -O0 and -O?
>>
>> Please reply to the mailing list, not just to me.  Thanks.
>>
>> -O0 means no optimization.  -O, which is the same as -O1, means to
>> optimize the code.  This is explained in the manual.
>>
>>
>>> On Fri, Sep 16, 2011 at 2:16 PM, zou wonder<wonder.zou@gmail.com>  wrote:
>>>> Hi Ian:
>>>>
>>>>      Acctually, i intercept the codes from our product, and there are
>>>> tons of lines.
>>>>
>>>> so how can i provide that useful information?
>>
>> I don't know.  What I do know is that we can't help you without seeing
>> much more of the program.  The tiny bit of code you showed looked fine.
>> The problem was probably somewhere else.
>>
>> Ian
>>
>>
>>>> On Fri, Sep 16, 2011 at 1:40 PM, Ian Lance Taylor<iant@google.com>  wrote:
>>>>> zou wonder<wonder.zou@gmail.com>  writes:
>>>>>
>>>>>> but one weird problem is that the following codes compiled with option -O0
>>>>>
>>>>> You need to show us a small complete self-contained example.
>>>>>
>>>>> Normally a program which works at -O0 and fails at -O1 has an
>>>>> uninitialized variable somewhere.
>>>>>
>>>>> Ian
>>>>>
>>>>
>>
>

Re: compile with gcc option -O0 or -O

[Jonathan Wakely]

On 16 September 2011 10:12, zou wonder wrote:
> hi david:
> i have tried to enable all the warning option you provided :
> and here are some warnings:

As Miles said, many of the warning options David suggested are not
suitable for all code, you will get most of the benefit just using
-Wall -Wextra

Re: compile with gcc option -O0 or -O

[Miles Bader]

David Brown <david@westcontrol.com> writes:
>> ... but be a bit wary of any warning option which isn't included in
>> -Wall or -Wextra -- they're usually omitted for a reason (typically
>> because they yield tons of false positives on reasonable code).
>
> That depends on your definition of "reasonable code" !

Of course.  :)

In general, though, there is some thought behind what's included in
-Wall/-Extra.  Stuff that's omitted tends to be where the warnings are
domain-specific, reflect programming practices which aren't widespread
enough, or where the gcc implementation is simply lacking in some
obvious way (sometimes it's very tricky to get the heuristics right).

-Wpadded, for instance, may be very interesting for embedded devs, but
probably not so much for many others, and yields vast quantities of
warnings on "ordinary" code.

-Wfloat-equal, on the other hand, reflects a rule of thumb which is very
useful when applied intelligently (i.e., by a human), but is less well
suited to automatic application.  [Testing for floating-point equality
is unreliable if the values being tested are the result of calculation,
but _is_ reliable if the values are the result of simple assignment,
especially certain values like 0.0 -- and the compiler is very unlikely
to be able to distinguish these cases.  If you _know_ that your
code-base never, ever, tests equality in the latter case, you can safely
use -Wfloat-equal, but this isn't something that can be relied upon.]

<etc etc blah blah>

-miles

-- 
values of β will give rise to dom!

Re: compile with gcc option -O0 or -O

[David Brown]

On 16/09/2011 12:05, Miles Bader wrote:
> David Brown<david@westcontrol.com>  writes:
>>> ... but be a bit wary of any warning option which isn't included in
>>> -Wall or -Wextra -- they're usually omitted for a reason (typically
>>> because they yield tons of false positives on reasonable code).
>>
>> That depends on your definition of "reasonable code" !
>
> Of course.  :)
>
> In general, though, there is some thought behind what's included in
> -Wall/-Extra.  Stuff that's omitted tends to be where the warnings are
> domain-specific, reflect programming practices which aren't widespread
> enough, or where the gcc implementation is simply lacking in some
> obvious way (sometimes it's very tricky to get the heuristics right).
>

Absolutely true, of course.

gcc is designed to support a huge range of code and coding practices - 
with that range covering different application areas, different 
programmer experiences and abilities, different code quality 
requirements, different fashions, different code sizes, and different 
times.  It has to work well for amateur code written 20 years ago and 
aeroplane-quality code written to modern standards.  So the -Wall and 
-Wextra groups are picked to give a reasonable compromise, and the 
individual flags are there for people who want more control.

> -Wpadded, for instance, may be very interesting for embedded devs, but
> probably not so much for many others, and yields vast quantities of
> warnings on "ordinary" code.
>
> -Wfloat-equal, on the other hand, reflects a rule of thumb which is very
> useful when applied intelligently (i.e., by a human), but is less well
> suited to automatic application.  [Testing for floating-point equality
> is unreliable if the values being tested are the result of calculation,
> but _is_ reliable if the values are the result of simple assignment,
> especially certain values like 0.0 -- and the compiler is very unlikely
> to be able to distinguish these cases.  If you _know_ that your
> code-base never, ever, tests equality in the latter case, you can safely
> use -Wfloat-equal, but this isn't something that can be relied upon.]
>
> <etc etc blah blah>
>
> -miles
>

Re: compile with gcc option -O0 or -O

[zou wonder]

Hi All:
  i have just enable -Wall -Wextra. but seem there is no any useful
infomation. just some things like:

/work/smsc/include/xscmsgqueuemx.h:62: warning: unused parameter ‘seconds’
/work/smsc/include/xscmsgqueuemx.h:247: warning: unused parameter ‘pri’
xmmgiwparam.cc: In function ‘uint8 findSCerrInd(TASK_TYPE*,
GIW_VAR_STR*, uint8*, uint8*, uint8*, uint8*)’:
xmmgiwparam.cc:555: warning: suggest parentheses around ‘&&’ within ‘||’
xmmgiwparam.cc: At global scope:
xmmgiwparam.cc:212: warning: unused parameter ‘type’
xmmgiwparam.cc:1391: warning: unused parameter ‘task’
xmmgiwparam.cc:1462: warning: unused parameter ‘task’
xmmgiwparam.cc:1574: warning: unused parameter ‘msg’
xmmgiwparam.cc: In function ‘void put_giwu_MOdataInd(GIW_VAR_STR*, giw_asn*)’:
xmmgiwparam.cc:1946: warning: unused variable ‘address’
xmmgiwparam.cc: In function ‘void put_giw_up_params(MESSAGE*,
PRIMITIVE, GIW_VAR_STR*)’:
xmmgiwparam.cc:2055: warning: unused variable ‘alertingMSaddr’
xmmgiwparam.cc:2060: warning: unused variable ‘addr_str’
xmmgiwparam.cc: In function ‘void put_giwd_openReq(GIW_VAR_STR*,
giw_asn*, ISDNAddress*)’:
xmmgiwparam.cc:2915: warning: suggest parentheses around ‘&&’ within ‘||’
xmmgiwparam.cc:2933: warning: suggest parentheses around ‘&&’ within ‘||’
xmmgiwparam.cc: In function ‘void put_giwd_forwardSMReq(MESSAGE*,
GIW_VAR_STR*, giw_asn*)’:
xmmgiwparam.cc:3163: warning: suggest parentheses around ‘&&’ within ‘||’
xmmgiwparam.cc: At global scope:
xmmgiwparam.cc:3143: warning: unused parameter ‘msg’
xmmgiwparam.cc: In function ‘void put_giw_down_params(MESSAGE*,
PRIMITIVE, GIW_VAR_STR*)’:
xmmgiwparam.cc:3347: warning: unused variable ‘smRPsmea’
xmmgiwparam.cc:3348: warning: unused variable ‘scAddrForHLR’
,








I am wondering now,  Could i add the optimization options which is
enable by -O one by one?

by then, hope i could find which optimization option affect my code?

but I do not know what is the difference options which is owned just by -O?


thanks again.

On Fri, Sep 16, 2011 at 5:47 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 16 September 2011 10:12, zou wonder wrote:
>> hi david:
>> i have tried to enable all the warning option you provided :
>> and here are some warnings:
>
> As Miles said, many of the warning options David suggested are not
> suitable for all code, you will get most of the benefit just using
> -Wall -Wextra
>

Re: compile with gcc option -O0 or -O

[David Brown]

On 19/09/2011 11:56, zou wonder wrote:
> Hi All:
>    i have just enable -Wall -Wextra. but seem there is no any useful
> infomation. just some things like:
> <snip>
>
>
>
>
>
> I am wondering now,  Could i add the optimization options which is
> enable by -O one by one?
>
> by then, hope i could find which optimization option affect my code?
>
> but I do not know what is the difference options which is owned just by -O?
>
>

The gcc manual shows quite clearly which individual optimisation flags 
are enabled by -O1 (and other -O options).  However, what it doesn't say 
very well is that there is a huge difference between -O1 and just using 
the flags by themselves - using -O (other than -O0) turns on the 
fundamental optimisation engine in gcc, and thus is much more than just 
a series of optimisation flags.  So you cannot use -O0 and enable these 
flags one by one.  On the other hand, you /can/ enable -O1 and /disable/ 
specific optimisations one by one until the code is working again.

However, since the warning flags haven't helped spot anything obvious, 
your best plan is to do as suggested by Ian in his first reply - make a 
small self-contained example that demonstrates your problem.  In many 
cases, that exercise is enough to let you spot the problem yourself. 
Failing that, you have something you can post and other people can try, 
so that others can help you better.



> thanks again.
>
> On Fri, Sep 16, 2011 at 5:47 PM, Jonathan Wakely<jwakely.gcc@gmail.com>  wrote:
>> On 16 September 2011 10:12, zou wonder wrote:
>>> hi david:
>>> i have tried to enable all the warning option you provided :
>>> and here are some warnings:
>>
>> As Miles said, many of the warning options David suggested are not
>> suitable for all code, you will get most of the benefit just using
>> -Wall -Wextra
>>
>

Re: compile with gcc option -O0 or -O

[zou wonder]

Hi David:

  Thanks for your reply, and I will try your suggestion.

Thanks all the guys again.


On Mon, Sep 19, 2011 at 5:56 PM, zou wonder <wonder.zou@gmail.com> wrote:
> Hi All:
>  i have just enable -Wall -Wextra. but seem there is no any useful
> infomation. just some things like:
>
> /work/smsc/include/xscmsgqueuemx.h:62: warning: unused parameter ‘seconds’
> /work/smsc/include/xscmsgqueuemx.h:247: warning: unused parameter ‘pri’
> xmmgiwparam.cc: In function ‘uint8 findSCerrInd(TASK_TYPE*,
> GIW_VAR_STR*, uint8*, uint8*, uint8*, uint8*)’:
> xmmgiwparam.cc:555: warning: suggest parentheses around ‘&&’ within ‘||’
> xmmgiwparam.cc: At global scope:
> xmmgiwparam.cc:212: warning: unused parameter ‘type’
> xmmgiwparam.cc:1391: warning: unused parameter ‘task’
> xmmgiwparam.cc:1462: warning: unused parameter ‘task’
> xmmgiwparam.cc:1574: warning: unused parameter ‘msg’
> xmmgiwparam.cc: In function ‘void put_giwu_MOdataInd(GIW_VAR_STR*, giw_asn*)’:
> xmmgiwparam.cc:1946: warning: unused variable ‘address’
> xmmgiwparam.cc: In function ‘void put_giw_up_params(MESSAGE*,
> PRIMITIVE, GIW_VAR_STR*)’:
> xmmgiwparam.cc:2055: warning: unused variable ‘alertingMSaddr’
> xmmgiwparam.cc:2060: warning: unused variable ‘addr_str’
> xmmgiwparam.cc: In function ‘void put_giwd_openReq(GIW_VAR_STR*,
> giw_asn*, ISDNAddress*)’:
> xmmgiwparam.cc:2915: warning: suggest parentheses around ‘&&’ within ‘||’
> xmmgiwparam.cc:2933: warning: suggest parentheses around ‘&&’ within ‘||’
> xmmgiwparam.cc: In function ‘void put_giwd_forwardSMReq(MESSAGE*,
> GIW_VAR_STR*, giw_asn*)’:
> xmmgiwparam.cc:3163: warning: suggest parentheses around ‘&&’ within ‘||’
> xmmgiwparam.cc: At global scope:
> xmmgiwparam.cc:3143: warning: unused parameter ‘msg’
> xmmgiwparam.cc: In function ‘void put_giw_down_params(MESSAGE*,
> PRIMITIVE, GIW_VAR_STR*)’:
> xmmgiwparam.cc:3347: warning: unused variable ‘smRPsmea’
> xmmgiwparam.cc:3348: warning: unused variable ‘scAddrForHLR’
> ,
>
>
>
>
>
>
>
>
> I am wondering now,  Could i add the optimization options which is
> enable by -O one by one?
>
> by then, hope i could find which optimization option affect my code?
>
> but I do not know what is the difference options which is owned just by -O?
>
>
> thanks again.
>
> On Fri, Sep 16, 2011 at 5:47 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 16 September 2011 10:12, zou wonder wrote:
>>> hi david:
>>> i have tried to enable all the warning option you provided :
>>> and here are some warnings:
>>
>> As Miles said, many of the warning options David suggested are not
>> suitable for all code, you will get most of the benefit just using
>> -Wall -Wextra
>>
>