[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 Ian McInerney changed: What|Removed |Added CC||ian.s.mcinerney at ieee dot org --- Comment #9 from Ian McInerney --- Based on all these examples, it seems like the potential for confusion/incorrect behavior is when the shadowed name is used on the right-hand side of an assignment inside the enum class declaration. So why does this need to trigger if it is just declaring the name and not using it in the enum class declatation? Can this warning instead only warn on a usage in the declaration? e.g. the original example in comment 1 never used foo in the enum class to initialize values in the enum, so where is the possibility for incorrect behavior in this case? Throwing a warning in this case leads to excess warnings in some cases when compiled with headers from MingW, since they tend to define things like RECT, INPUT, OUTPUT, etc. so the shadowing warnings are thrown if you use any of those names in an enum class.
[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #17 from Ian McInerney --- I think that r11-1899 is the more important one to backport, since that will also allow for warnings that are generated by headers inside "-isystem" include directories to not have the notes printed without the warning.
[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #15 from Ian McInerney --- Martin, can you backport you compiler patch to the GCC10 branch so it is fixed there as well? As I said, this makes the warning essentially useless to use on large codebases with the current release.
[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #14 from Ian McInerney --- Is it possible to backport this to the GCC 10 branch? The printing of these notes makes this warning almost impossible to use on any large project that uses the standard library.
[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #6 from Ian McInerney --- They are showing up when I don't have -Wsystem-headers passed in on the command line. Compiling the attached test program with `g++ -Wmismatched-tags main.cpp` shows the warnings. All that is doing is including basically all public library headers.
[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #5 from Ian McInerney --- Created attachment 48837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48837&action=edit test program
[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 --- Comment #2 from Ian McInerney --- I'd be fine with disabling them for the library (although I would have hoped they would have been disabled there from the start since warnings from the library weren't requested), but as it stands currently the warning can't be used due to all the noise being generated.
[Bug libstdc++/96063] New: mismatched-tags warnings in stdlib headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063 Bug ID: 96063 Summary: mismatched-tags warnings in stdlib headers Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ian.s.mcinerney at ieee dot org Target Milestone: --- There are several places in the library headers where warnings can be emitted for mismatched-tags (this was found when a mingw g++ compile misbehaved and printed warnings for system headers for some reason). I am still not sure why the compiler decided to throw the errors in the first place, but these seem like something that can be cleaned up. Warnings from building a C++ file that just includes all the headers: In file included from /usr/include/c++/10/bits/ios_base.h:46, from /usr/include/c++/10/ios:42, from /usr/include/c++/10/istream:38, from /usr/include/c++/10/sstream:38, from /usr/include/c++/10/complex:45, from main.cpp:7: /usr/include/c++/10/system_error:54:9: warning: ‘std::error_code’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 54 | class error_code; | ^~ /usr/include/c++/10/system_error:54:9: note: replace the class-key with ‘struct’ /usr/include/c++/10/system_error:180:10: note: ‘std::error_code’ defined as ‘struct’ here 180 | struct error_code | ^~ /usr/include/c++/10/system_error:55:9: warning: ‘std::error_condition’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 55 | class error_condition; | ^~~ /usr/include/c++/10/system_error:55:9: note: replace the class-key with ‘struct’ /usr/include/c++/10/system_error:278:10: note: ‘std::error_condition’ defined as ‘struct’ here 278 | struct error_condition | ^~~ In file included from /usr/include/c++/10/string:43, from /usr/include/c++/10/bitset:47, from main.cpp:6: /usr/include/c++/10/bits/localefwd.h:125:9: warning: ‘std::ctype_base’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 125 | class ctype_base; | ^~ /usr/include/c++/10/bits/localefwd.h:125:9: note: replace the class-key with ‘struct’ In file included from /usr/include/c++/10/bits/locale_facets.h:41, from /usr/include/c++/10/bits/basic_ios.h:37, from /usr/include/c++/10/ios:44, from /usr/include/c++/10/istream:38, from /usr/include/c++/10/sstream:38, from /usr/include/c++/10/complex:45, from main.cpp:7: /usr/include/c++/10/x86_64-redhat-linux/bits/ctype_base.h:41:10: note: ‘std::ctype_base’ defined as ‘struct’ here 41 | struct ctype_base | ^~ In file included from main.cpp:7: /usr/include/c++/10/complex:67:32: warning: ‘std::complex<_Tp>’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 67 | template class complex; |^~~ /usr/include/c++/10/complex:67:32: note: replace the class-key with ‘struct’ /usr/include/c++/10/complex:127:12: note: ‘std::complex<_Tp>’ defined as ‘struct’ here 127 | struct complex |^~~ /usr/include/c++/10/complex:68:20: warning: ‘std::complex’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 68 | template<> class complex; |^~ /usr/include/c++/10/complex:68:20: note: replace the class-key with ‘struct’ /usr/include/c++/10/complex:1082:12: note: ‘std::complex’ defined as ‘struct’ here 1082 | struct complex |^~ /usr/include/c++/10/complex:69:20: warning: ‘std::complex’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 69 | template<> class complex; |^~~ /usr/include/c++/10/complex:69:20: note: replace the class-key with ‘struct’ /usr/include/c++/10/complex:1227:12: note: ‘std::complex’ defined as ‘struct’ here 1227 | struct complex |^~~ /usr/include/c++/10/complex:70:20: warning: ‘std::complex’ declared with a mismatched class-key ‘class’ [-Wmismatched-tags] 70 | template<> class complex; |^~~~ /usr/include/c++/10/complex:70:20: note: replace the class-key with ‘struct’ /usr/include/c++/10/complex:1372:12: note: ‘std::complex’ defined as ‘struct’ here 1372 | struct complex |^~~~ In file included from /usr/include/c++/10/string:43, from /usr/include/c++/10/bitset:47, from main.cpp:6: /usr/include/c++/10/bits/localefwd.h:203:9: warning: ‘std::messages_base’ declared with
[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 --- Comment #5 from Ian McInerney --- Created attachment 47605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47605&action=edit Verbose output from successful linking
[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 --- Comment #4 from Ian McInerney --- Created attachment 47604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47604&action=edit GCC verbose output from failed linking
[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 --- Comment #3 from Ian McInerney --- Note that I am compiling this with g++ -fno-lto -v -Wl,-v main.cpp
[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 --- Comment #2 from Ian McInerney --- Created attachment 47603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47603&action=edit Object file from successful linking
[Bug inline-asm/93190] Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 --- Comment #1 from Ian McInerney --- Created attachment 47602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47602&action=edit Object file from failed linking
[Bug inline-asm/93190] New: Failure to link with .note.GNU-stack in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93190 Bug ID: 93190 Summary: Failure to link with .note.GNU-stack in inline assembly Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: ian.s.mcinerney at ieee dot org Target Milestone: --- Created attachment 47601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47601&action=edit Example program When compiling inline assembly that contains the line ".section .note.GNU-stack,"",%progbits", sometimes the linker fails with the error: "`.note.GNU-stack' referenced in section `.text' of /tmp/ccKoiXRb.o: defined in discarded section `.note.GNU-stack' of /tmp/ccKoiXRb.o" I have narrowed this down to the example in the attached main.cpp. When the iostream header is included the linking fails, but when it is commented out the linking works. It appears that there are some cases when the .note.GNU-stack section is being referenced inside the .text section of the created object file (taken from the compiled main.o of the failed linking) even though it is a discarded section in the linker: Relocation section '.rela.text' at offset 0x470 contains 9 entries: Offset Info Type Sym. ValueSym. Name + Addend 0036 000e0004 R_X86_64_PLT32 Add2 - 4 0043 0008000a R_X86_64_32 .note.GNU-stack + 0 004d 0014 R_X86_64_PLT32 printf - 4 0076 0004000a R_X86_64_32 .bss + 0 007b 00110004 R_X86_64_PLT32 _ZNSt8ios_base4InitC1E - 4 0080 0012000a R_X86_64_32 __dso_handle + 0 0085 0004000a R_X86_64_32 .bss + 0 008a 0013000a R_X86_64_32 _ZNSt8ios_base4InitD1E + 0 008f 00140004 R_X86_64_PLT32 __cxa_atexit - 4 The successful compilation produces a .text section that doesn't reference it: Relocation section '.rela.text' at offset 0x250 contains 3 entries: Offset Info Type Sym. ValueSym. Name + Addend 0036 00090004 R_X86_64_PLT32 Add2 - 4 0043 0006000a R_X86_64_32 .rodata + 0 004d 000b0004 R_X86_64_PLT32 printf - 4 This inconsistent behavior is very problematic. Ideally it should always compile/link fine with this included in the inline assembly. I have tested this using 9.2.1 from Fedora 31, and also 7.4.0 from Ubuntu 18.04 and it is present in both versions.
