[
https://issues.apache.org/jira/browse/MESOS-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531060#comment-14531060
]
Cody Maloney edited comment on MESOS-2690 at 5/6/15 6:03 PM:
-------------------------------------------------------------
Grepping for {{-O2}} in {{CXXFLAGS}} is fairly fragile, and moderately unsafe
because it's one particular GCC optimization, which happens to be included in
{{-O2}}. Unless we implement parsing all of GCC's flags, finding which one
enables the optimization that breaks {{-Wno-maybe-uninitialized}} we've made a
very, very environment-specific patch to work around a particular bug which
could quite likely be fixed in a point release of GCC at some point rendering
the code incorrect.
In the spec file you can fairly simply add the flag to {{CXXFLAGS}} passing it
into configure like all the other manually-set {{CXXFLAGS}} by configure. What
sets the optimization flag which doesn't work well with our warning flags sets
the bypass for the bug that pops up as well. It's all set on the outside and
works its way in.
>From the automake manual:
{code}
This section attempts to answer all the above questions. We will mostly discuss
CPPFLAGS in our examples, but actually the answer holds for all the compile
flags used in Automake: CCASFLAGS, CFLAGS, CPPFLAGS, CXXFLAGS, FCFLAGS, FFLAGS,
GCJFLAGS, LDFLAGS, LFLAGS, LIBTOOLFLAGS, OBJCFLAGS, OBJCXXFLAGS, RFLAGS,
UPCFLAGS, and YFLAGS.
{code}
...
{code}
You should not add options to these user variables within configure either, for
the same reason. Occasionally you need to modify these variables to perform a
test, but you should reset their values afterwards. In contrast, it is OK to
modify the ‘AM_’ variables within configure if you AC_SUBST them, but it is
rather rare that you need to do this, unless you really want to change the
default definitions of the ‘AM_’ variables in all Makefiles.
{code} --
http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html
was (Author: cmaloney):
Grepping for {{-O2}} in {{CXXFLAGS}} is fairly fragile, and moderately unsafe
because it's one particular GCC optimization, which happens to be included in
{{-O2}}. Unless we implement parsing all of GCC's flags, finding which one
enables the optimization that breaks {{-Wno-maybe-uninitialized}} we've made a
very, very environment-specific patch to work around a particular bug which
could quite likely be fixed in a point release of GCC at some point rendering
the code incorrect.
In the spec file you can fairly simply add the flag to {{CXXFLAGS}} passing it
into configure like all the other manually-set {{CXXFLAGS}} by configure. What
sets the optimization flag which doesn't work well with our warning flags sets
the bypass for the bug that pops up as well. It's all set on the outside and
works its way in.
>From the automake manual:
{{code}}
This section attempts to answer all the above questions. We will mostly discuss
CPPFLAGS in our examples, but actually the answer holds for all the compile
flags used in Automake: CCASFLAGS, CFLAGS, CPPFLAGS, CXXFLAGS, FCFLAGS, FFLAGS,
GCJFLAGS, LDFLAGS, LFLAGS, LIBTOOLFLAGS, OBJCFLAGS, OBJCXXFLAGS, RFLAGS,
UPCFLAGS, and YFLAGS.
{{code}}
...
{{code}}
You should not add options to these user variables within configure either, for
the same reason. Occasionally you need to modify these variables to perform a
test, but you should reset their values afterwards. In contrast, it is OK to
modify the ‘AM_’ variables within configure if you AC_SUBST them, but it is
rather rare that you need to do this, unless you really want to change the
default definitions of the ‘AM_’ variables in all Makefiles.
{{code}} --
http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html
> --enable-optimize build fails with maybe-uninitialized
> ------------------------------------------------------
>
> Key: MESOS-2690
> URL: https://issues.apache.org/jira/browse/MESOS-2690
> Project: Mesos
> Issue Type: Bug
> Components: build
> Environment: GCC 4.8 -> 4.9
> Reporter: Joris Van Remoortere
> Assignee: Joris Van Remoortere
> Priority: Blocker
>
> When building with the `enable-optimize` flag, the build fails with
> `maybe-uninitialized' errors.
> This is due to a bug in GCC when building optimized code triggering false
> positives for this warning. Please see:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970
> We can disable this warning when using GCC + --enable-optimize.
> A quick work-around until there is a patch:
> ../configure CXXFLAGS="-Wno-maybe-uninitialized" <your-other-flags-here>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
