Bug 56627 - class hash instead of struct hash
Summary: class hash instead of struct hash
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 57730 58025 58030 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-15 18:44 UTC by ahansson
Modified: 2013-10-05 08:08 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ahansson 2013-03-15 18:44:55 UTC
In the gcc 4.8.0 c++ standard library headers, bitset and bits/stl_bvector.h both incorrectly use class instead of struct for the hash function.

For example, bits/stl_bvector.h:

#if __cplusplus >= 201103L
   template<typename> friend class hash;
#endif

class should be struct
Comment 1 Andrew Pinski 2013-03-15 19:18:23 UTC
In C++, class and struct are interchangeable.
Comment 2 ahansson 2013-03-15 21:04:01 UTC
(In reply to comment #1)
> In C++, class and struct are interchangeable.

Agreed. Technically the code is ok, and in line with the language standard. 

However, as at least one of the most popular compilers (clang 3.2 RELEASE with -Wall) issues a warning for this. Thus, it might be worthwhile fixing.
Comment 3 Andrew Pinski 2013-03-15 21:17:15 UTC
(In reply to comment #2)
> (In reply to comment #1)rd. 
> However, as at least one of the most popular compilers (clang 3.2 RELEASE with
> -Wall) issues a warning for this. Thus, it might be worthwhile fixing.

And it only issues it because it tries to be compatible with MS's compiler.
  I think this is broken to issue a warning at all and rather see clang fixed and/or ignored in this case.
Comment 4 Jonathan Wakely 2013-03-16 02:22:39 UTC
I'm happy to fix things in libstdc++ that are broken and cause real problems for clang users, but this is correct C++ and causes a spurious warning. Not a bug, not worth wasting time on.
Comment 5 Paolo Carlini 2013-03-16 09:40:02 UTC
I agree. And we discussed it already somewhere.
Comment 6 ahansson 2013-03-16 12:01:39 UTC
(In reply to comment #4)
> I'm happy to fix things in libstdc++ that are broken and cause real problems
> for clang users, but this is correct C++ and causes a spurious warning. Not a
> bug, not worth wasting time on.

The potential for "real problems" was my main reason for pointing it out. I ran some (unrelated) tests on Fedora Rawhide (fc19) with clang 3.2 RELEASE and gcc 4.8.0 and this issue popped up as -Wall -Werror was used for the project in question.

The two lines mentioned are the only issues encountered. If it is worth "fixing" or not I leave up to you to decide, I merely wanted to highlight the potential issues.
Comment 7 Paolo Carlini 2013-06-26 21:05:51 UTC
*** Bug 57730 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2013-07-30 04:43:59 UTC
*** Bug 58025 has been marked as a duplicate of this bug. ***
Comment 9 Matt Arsenault 2013-07-30 04:59:44 UTC
(In reply to Andrew Pinski from comment #8)
> *** Bug 58025 has been marked as a duplicate of this bug. ***

They don't have to be consistent by the standard, but the purpose of warnings is not to strictly report deviations from the standard. Many point out likely mistakes or inconsistencies in "standard" conforming code (e.g. -Wlogical-op). This is an absolutely trivial fix.
Comment 10 Andrew Pinski 2013-07-30 05:03:11 UTC
(In reply to Matt Arsenault from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > *** Bug 58025 has been marked as a duplicate of this bug. ***
> 
> They don't have to be consistent by the standard, but the purpose of
> warnings is not to strictly report deviations from the standard. Many point
> out likely mistakes or inconsistencies in "standard" conforming code (e.g.
> -Wlogical-op). This is an absolutely trivial fix.

Actually this warning makes less sense than -Wlogical-op due to the way struct and class are defined.  -Wlogical-op makes sense since due to forgetting how || and && interact, there is no interaction here, only using struct in one case and class in another which is valid and known what happens even without looking up what happens.  The real reason why they added this option is due to another compiler which implements non-standard behavior for struct and class (not naming the company here but they also don't care about C99).
Comment 11 Jonathan Wakely 2013-07-30 08:31:28 UTC
I'm think I'm just going to change the code to shut everyone up, despite it being a nonsense warning about a non-issue, because I'm sick of these discussions.

Fine, you win, we'll silence the stupid warning.
Comment 12 Jonathan Wakely 2013-07-30 14:59:18 UTC
*** Bug 58030 has been marked as a duplicate of this bug. ***
Comment 13 Paolo Carlini 2013-07-31 14:22:20 UTC
Jon, I have two spare minutes and if you don't mind I'm taking care of the stupid change myself.
Comment 14 Jonathan Wakely 2013-07-31 14:32:51 UTC
Sure, I was going to do it this evening but please go ahead, thanks.
Comment 15 Paolo Carlini 2013-07-31 14:37:33 UTC
Done for 4.8.2 and 4.9.0.