Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in / Register
Toggle navigation
C
capnproto
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Packages
Packages
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
submodule
capnproto
Commits
4cfeb8eb
Commit
4cfeb8eb
authored
Aug 23, 2013
by
Kenton Varda
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Better work-around for weird GCC 4.8 warning breaking tests.
parent
7638ec97
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
10 additions
and
8 deletions
+10
-8
char-test.c++
c++/src/kj/parse/char-test.c++
+0
-8
super-test.sh
super-test.sh
+10
-0
No files found.
c++/src/kj/parse/char-test.c++
View file @
4cfeb8eb
...
...
@@ -21,14 +21,6 @@
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
// SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#if !__clang__ && __GNUC__ == 4 && __GNUC_MINOR__ == 8
// GCC 4.8 warns that ConstResult_<T, Tuple<>>::operator() returns an uninitialized value from
// the second branch. This is bogus AFAICT. Moreover, the warning comes from the use of the
// `number` parser. GCC does not complain when this parser is used in the Cap'n Proto compiler;
// only when it is used in this test.
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#endif
#include "char.h"
#include "../string.h"
#include <gtest/gtest.h>
...
...
super-test.sh
View file @
4cfeb8eb
...
...
@@ -193,6 +193,16 @@ case ${CXX:-g++} in
# There's an unused private field in gtest.
export
CXXFLAGS
=
"
$CXXFLAGS
-Wno-unused-private-field"
;;
*
g++
*
)
if
(
${
CXX
:-
g
++
}
--version
|
grep
-q
' 4[.]8'
)
;
then
# GCC 4.8 emits a weird uninitialized warning in kj/parse/char-test, deep in one of the parser
# combinators. It could be a real bug but there is just not enough information to figure out
# where the problem is coming from, because GCC does not provide any description of the inlining
# that has occurred. Since I have not observed any actual problem (tests pass, etc.), I'm
# muting it for now.
CXXFLAGS
=
"
$CXXFLAGS
-Wno-maybe-uninitialized"
fi
;;
esac
cd
c++
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment