Bug 83591 - -Wduplicated-branches fires in system headers in template instantiation
Summary: -Wduplicated-branches fires in system headers in template instantiation
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2017-12-26 06:50 UTC by Tony E Lewis
Modified: 2020-09-15 10:06 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-12-26 00:00:00


Attachments
Intermediate file (168 bytes, text/plain)
2017-12-26 06:52 UTC, Tony E Lewis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony E Lewis 2017-12-26 06:50:30 UTC
Compiling with:


g++ -Werror -Wduplicated-branches -c -isystem sysheaddir b.cpp


where b.cpp is :


#include "a.hpp"


...and sysheaddir/a.hpp is:


template <class...>
void f() {
	int b;
	( b ? b : b );
}

void g() {
	f<>();
}


...gives:


sysheaddir/a.hpp:8:6:   required from here
cc1plus: error: this condition has identical branches [-Werror=duplicated-branches]
cc1plus: all warnings being treated as errors


Thought the code *does* have duplicate branches, I see two problems with this:
 * the warning is firing even though all the code relevant to the warning is in a system header
 * the warning doesn't provide the line number on which the identical branches appear

I suspect that it's already the intended design that this warning shouldn't fire in system headers. Indeed, if I add a simple `void h() { int b; b ? b : b; }` into b.cpp, it triggers the warning but if I add it to the system header sysheaddir/a.hpp, it doesn't.


I'm using g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0. It looks to me from using godbolt.org, that the same problems persist in trunk (8.0.0 20171225).


I suspect this is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541 but it has differences:
 * I'm highlighting a true positive warning in a *system* header (rather than a false positive in the .cpp file)
 * I'm highlighting the lack of line number in the warning message
Comment 1 Tony E Lewis 2017-12-26 06:52:55 UTC
Created attachment 42965 [details]
Intermediate file
Comment 2 Tony E Lewis 2017-12-26 07:11:36 UTC
Further, even adding:


#pragma GCC diagnostic ignored "-Wduplicated-branches"


...doesn't appear to stop these warnings in this example code, though it does correctly silence the warning in non-template functions.
Comment 3 Manuel López-Ibáñez 2017-12-26 19:34:27 UTC
> cc1plus: error: this condition has identical branches

This suggests that GCC has somehow lost the source location info for this warning (even the file location), so GCC does not know that it happens inside a system header nor it can be silenced with #pragmas, since those rely on the location.

> I suspect this is related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541 but it has differences:

I think PR82541 is asking that cond ? A : B is not warned about if A and B are textually different, even if they are template parameters that expand to the same expression.

In your case, the warning is correct, but the location is broken, so the location-based tricks to silence it do not work.
Comment 4 Tony E Lewis 2017-12-28 09:14:11 UTC
Thanks for the response. That all sounds sensible.
Comment 5 T vd Sijs 2020-09-03 15:35:12 UTC
I ran into this same issue on gcc 7.2.0. 

This issue seems to be resolved in gcc 9.3.0.
Comment 6 T vd Sijs 2020-09-03 15:36:05 UTC
I ran into this same issue on gcc 7.2.0. 

This issue seems to be resolved in gcc 9.3.0.
Comment 7 Tony E Lewis 2020-09-04 08:55:28 UTC
Thanks for this comment T vd Sijs. Yes - I'm also able to compile this without problem in 9.3 (and in 10.1).

Manuel López-Ibáñez: are you happy that all underlying issues are resolved and this can be closed?
Comment 8 Manuel López-Ibáñez 2020-09-04 17:10:44 UTC
(In reply to Tony E Lewis from comment #7)
> Manuel López-Ibáñez: are you happy that all underlying issues are resolved
> and this can be closed?

Sure.
Comment 9 Tony E Lewis 2020-09-15 10:06:16 UTC
Closing as fixed.