* compile with gcc option -O0 or -O
@ 2011-09-16 5:04 zou wonder
2011-09-16 5:41 ` Ian Lance Taylor
0 siblings, 1 reply; 14+ messages in thread
From: zou wonder @ 2011-09-16 5:04 UTC (permalink / raw)
To: gcc-help
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: compile with gcc option -O0 or -O 2011-09-16 5:04 compile with gcc option -O0 or -O zou wonder @ 2011-09-16 5:41 ` Ian Lance Taylor 2011-09-16 7:10 ` David Brown [not found] ` <CAOXjUBzK0snvjNcpi8D3mK5dmXwzH62XXETyjv+4f6S+LDmXyQ@mail.gmail.com> 0 siblings, 2 replies; 14+ messages in thread From: Ian Lance Taylor @ 2011-09-16 5:41 UTC (permalink / raw) To: zou wonder; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 5:41 ` Ian Lance Taylor @ 2011-09-16 7:10 ` David Brown 2011-09-16 7:54 ` Miles Bader 2011-09-16 8:27 ` Jeffrey Walton [not found] ` <CAOXjUBzK0snvjNcpi8D3mK5dmXwzH62XXETyjv+4f6S+LDmXyQ@mail.gmail.com> 1 sibling, 2 replies; 14+ messages in thread From: David Brown @ 2011-09-16 7:10 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 7:10 ` David Brown @ 2011-09-16 7:54 ` Miles Bader 2011-09-16 9:21 ` David Brown 2011-09-16 8:27 ` Jeffrey Walton 1 sibling, 1 reply; 14+ messages in thread From: Miles Bader @ 2011-09-16 7:54 UTC (permalink / raw) To: David Brown; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 7:54 ` Miles Bader @ 2011-09-16 9:21 ` David Brown 2011-09-16 10:06 ` Miles Bader 0 siblings, 1 reply; 14+ messages in thread From: David Brown @ 2011-09-16 9:21 UTC (permalink / raw) To: gcc-help 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 9:21 ` David Brown @ 2011-09-16 10:06 ` Miles Bader 2011-09-16 10:35 ` David Brown 0 siblings, 1 reply; 14+ messages in thread From: Miles Bader @ 2011-09-16 10:06 UTC (permalink / raw) To: David Brown; +Cc: gcc-help 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! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 10:06 ` Miles Bader @ 2011-09-16 10:35 ` David Brown 0 siblings, 0 replies; 14+ messages in thread From: David Brown @ 2011-09-16 10:35 UTC (permalink / raw) To: gcc-help 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 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 7:10 ` David Brown 2011-09-16 7:54 ` Miles Bader @ 2011-09-16 8:27 ` Jeffrey Walton 1 sibling, 0 replies; 14+ messages in thread From: Jeffrey Walton @ 2011-09-16 8:27 UTC (permalink / raw) To: David Brown; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAOXjUBzK0snvjNcpi8D3mK5dmXwzH62XXETyjv+4f6S+LDmXyQ@mail.gmail.com>]
[parent not found: <CAOXjUBwW2ghmfsF1OA5DY7hZOz-43r22biSG60VyWaviFau_-Q@mail.gmail.com>]
[parent not found: <mcrfwjx6lrk.fsf@coign.corp.google.com>]
* Re: compile with gcc option -O0 or -O [not found] ` <mcrfwjx6lrk.fsf@coign.corp.google.com> @ 2011-09-16 9:12 ` zou wonder 2011-09-16 9:32 ` David Brown 2011-09-16 9:47 ` Jonathan Wakely 0 siblings, 2 replies; 14+ messages in thread From: zou wonder @ 2011-09-16 9:12 UTC (permalink / raw) To: gcc-help; +Cc: david 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 >>>> >>> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 9:12 ` zou wonder @ 2011-09-16 9:32 ` David Brown 2011-09-16 9:47 ` Jonathan Wakely 1 sibling, 0 replies; 14+ messages in thread From: David Brown @ 2011-09-16 9:32 UTC (permalink / raw) To: gcc-help 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 >>>>> >>>> >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 9:12 ` zou wonder 2011-09-16 9:32 ` David Brown @ 2011-09-16 9:47 ` Jonathan Wakely 2011-09-19 9:57 ` zou wonder 1 sibling, 1 reply; 14+ messages in thread From: Jonathan Wakely @ 2011-09-16 9:47 UTC (permalink / raw) To: zou wonder; +Cc: gcc-help, david 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-16 9:47 ` Jonathan Wakely @ 2011-09-19 9:57 ` zou wonder 2011-09-19 10:32 ` David Brown 2011-09-21 2:18 ` zou wonder 0 siblings, 2 replies; 14+ messages in thread From: zou wonder @ 2011-09-19 9:57 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help, david 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 > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-19 9:57 ` zou wonder @ 2011-09-19 10:32 ` David Brown 2011-09-21 2:18 ` zou wonder 1 sibling, 0 replies; 14+ messages in thread From: David Brown @ 2011-09-19 10:32 UTC (permalink / raw) To: gcc-help 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 >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: compile with gcc option -O0 or -O 2011-09-19 9:57 ` zou wonder 2011-09-19 10:32 ` David Brown @ 2011-09-21 2:18 ` zou wonder 1 sibling, 0 replies; 14+ messages in thread From: zou wonder @ 2011-09-21 2:18 UTC (permalink / raw) To: david; +Cc: gcc-help 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 >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-09-21 2:18 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-16 5:04 compile with gcc option -O0 or -O zou wonder
2011-09-16 5:41 ` Ian Lance Taylor
2011-09-16 7:10 ` David Brown
2011-09-16 7:54 ` Miles Bader
2011-09-16 9:21 ` David Brown
2011-09-16 10:06 ` Miles Bader
2011-09-16 10:35 ` David Brown
2011-09-16 8:27 ` Jeffrey Walton
[not found] ` <CAOXjUBzK0snvjNcpi8D3mK5dmXwzH62XXETyjv+4f6S+LDmXyQ@mail.gmail.com>
[not found] ` <CAOXjUBwW2ghmfsF1OA5DY7hZOz-43r22biSG60VyWaviFau_-Q@mail.gmail.com>
[not found] ` <mcrfwjx6lrk.fsf@coign.corp.google.com>
2011-09-16 9:12 ` zou wonder
2011-09-16 9:32 ` David Brown
2011-09-16 9:47 ` Jonathan Wakely
2011-09-19 9:57 ` zou wonder
2011-09-19 10:32 ` David Brown
2011-09-21 2:18 ` zou wonder
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).