Template related warnings when compiling with "-W -Wall"

[GoogleCodeExporter]

Hello, I tried using sparse_hash_map to replace std::map in a big application, 
and I got many warnings during compilation. I isolated the problem to the "-W 
-Wall" compilation parameters and compiling google-sparsehash v1.7 with those 
parameters also issues the same warnings. 

They are huge, template related warnings so it's not meaningful to copy-paste 
them here, just try compiling with those flags. 

Unfortunately sparse_hash_map doesn't work for me as drop-in replacement to 
std::map, sometimes I get garbage when reading from specific places... I can't 
tell if it's related to these warnings but I'll look into the issue more and 
report back if it is so.

Original issue reported on code.google.com by ji...@gmx.net on 20 Jun 2010 at 1:57

[GoogleCodeExporter]

} They are huge, template related warnings so it's not meaningful to copy-paste 
them
} here

Actually, it is meaningful.  Please copy them into this bug report.

} I isolated the problem to the "-W -Wall" compilation parameters

You can look at Makefile.am to see what compiler flags sparsehash uses to 
compile the tests (which compile without warnings, at least on the systems I've 
tested on).  You may want to try adding -Wno-sign-compare to your build, to see 
if that helps you at all.

} Unfortunately sparse_hash_map doesn't work for me as drop-in replacement to
} std::map, sometimes I get garbage when reading from specific places...

This is most likely a bug in your program somewhere -- different containers 
will behave differently in the face of buggy code, sometimes working correctly, 
sometimes not.  You might try running with valgrind to see if that picks up 
anything.

Original comment by csilv...@gmail.com on 21 Jun 2010 at 4:52

• Added labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I warned you that it's a lot of output, but since you need it I attach a file 
with the output (Best is to view it with "less -S" otherwise it's pretty 
unreadable). System is linux fedora 13 and exact steps to reproduce are the 
following (I don't think that Wno-sign-compare makes any difference):

$ cd sparsehash-1.7
$ ./configure CPPFLAGS='-W -Wall -Wno-sign-compare'
$ make >output.txt 2>&1

Original comment by ji...@gmx.net on 21 Jun 2010 at 6:20

Attachments:

• output.txt

[GoogleCodeExporter]

Ah, looks like they're all unused-parameter warnings.  Your version of gcc must 
include that in -Wall.  You can turn them off by -Wno-unused-parameter (I think 
that's the flag; you'll need to double check).  Some of these are already fixed 
in svn-root, others should be fixed before the next release.  btw, what version 
of gcc are you using?

Anyway, this isn't related to any of the problems you might be seeing.

Original comment by csilv...@gmail.com on 21 Jun 2010 at 6:34

• Changed state: Started

[GoogleCodeExporter]

gcc 4.4.4

Please note that "-Wall" isn't producing any warnings, but "-W -Wall" does. Not 
all of them are unused-parameter warning as far as I can see, I /think/ most 
are multiple instantiation warnings... BTW I don't have a clue what "-W -Wall" 
offers over just -Wall, can't find documentation either, but the project I was 
given already uses those parameters.

Original comment by ji...@gmx.net on 21 Jun 2010 at 6:39

[GoogleCodeExporter]

At least on the output.txt file that you attached, all the warnings are 
unused-variable.

Ah, it looks like -W is a synonym for -Wextra.  According to 'man gcc', -Wall 
does not include -Wunused-parameter, but -Wextra -Wall does.  So that explains 
what you're seeing, and why I'm not seeing it.

Original comment by csilv...@gmail.com on 21 Jun 2010 at 6:51

[GoogleCodeExporter]

Ah I see now, thanks. Indeed all warnings are unused-variable related. I was 
confused by the "instantiated from here" messages.

Original comment by ji...@gmx.net on 22 Jun 2010 at 7:51

[GoogleCodeExporter]

For the next release, I'll add -Wextra to the default Makefile flags, which 
will hopefully keep this issue from recurring.

Original comment by csilv...@gmail.com on 29 Jul 2010 at 5:29

[GoogleCodeExporter]

This should be fixed in sparsehash 1.8, just released.

Original comment by csilv...@gmail.com on 29 Jul 2010 at 9:52

• Changed state: Fixed