[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 --- Comment #3 from Andrew Pinski --- Note clang also rejects it for -std=c++20 and accepts it for -std=c++17. Let me dig into the changes, I suspect this is another standard change.
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Andrew Pinski --- Wait you didn't mention you needed -std=c++20 to get the failure.
[Bug c++/96645] [9/10/11/12/13 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||mrjoel at lixil dot net --- Comment #28 from Andrew Pinski --- *** Bug 105606 has been marked as a duplicate of this bug. ***
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Both examples compile just fine with the released GCC 12. You must be using a pre-released version when testing. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/105606] New: [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606
Bug ID: 105606
Summary: [12 Regression] std::pair with nested struct and NSDMI
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mrjoel at lixil dot net
Target Milestone: ---
The following snippets fail to compile with GCC 12.1.0. The first relates more
to actual code usage while the second I believe to be a more minimal
reproducer.
This looks closely related to the examples and discussion in bug 96645 and yet
this case compiles in versions through 11, only failing to compile in 12.
It may also be closely related to (or have it as an underlying cause) bug
102199.
Snippet 1
=
#include
#include
struct Outer {
struct Inner {
int a{0};
};
std::pair p;
void f() {
std::map> m;
m[0] = p;
}
};
Snippet 2
=
#include
struct Outer {
struct Inner {
int a{0}; // removing initialization compiles
};
std::pair p; // commenting out compiles
void f() {
[[maybe_unused]] std::pair localp;
}
};
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #12 from tt_1 --- with gcc-12.1.0, glibc-2.34-r13 and old binutils-2.33.1-r1: /usr/bin/armv7a-unknown-linux-gnueabihf-g++ --sysroot /usr/armv7a-unknown-linux-gnueabihf -fstack-protector-strong -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wno-error=unused-but-set-variable -Wformat -Wformat-security -Wformat-overflow=2 -Wno-psabi -fno-sized-deallocation -fno-aligned-new -O2 -pipe -fomit-frame-pointer -fno-tree-loop-vectorize -mthumb -mno-thumb-interwork -mfpu=neon -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer -funwind-tables -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libmozjs-91.so -o libmozjs-91.so /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/libmozjs-91_so.list -lpthread -Wl,-O1 -Wl,--as-needed -mthumb -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -fstack-protector-strong -Wl,-rpath-link,/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/dist/bin -Wl,-rpath-link,/usr/lib /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/thumbv7neon-unknown-linux-gnueabihf/release/libjsrust.a -Wl,--version-script,symverscript -Wl,-soname,libmozjs-91.so.0 -lm -L/usr/armv7a-unknown-linux-gnueabihf/usr/lib -lplds4 -lplc4 -lnspr4 -lz -lm -ldl /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: DWARF error: can't find .debug_ranges section. ../../../config/external/icu/common/rbbi.o: in function `icu_69::RuleBasedBreakIterator::operator==(icu_69::BreakIterator const&) const': rbbi.cpp:(.text._ZNK6icu_6922RuleBasedBreakIteratoreqERKNS_13BreakIteratorE+0x14): undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: DWARF error: can't find .debug_ranges section. ../../../config/external/icu/common/schriter.o: in function `icu_69::StringCharacterIterator::operator==(icu_69::ForwardCharacterIterator const&) const': schriter.cpp:(.text._ZNK6icu_6923StringCharacterIteratoreqERKNS_24ForwardCharacterIteratorE+0x18): undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: DWARF error: can't find .debug_ranges section. ../../../config/external/icu/common/stringtriebuilder.o: in function `icu_69::StringTrieBuilder::Node::operator==(icu_69::StringTrieBuilder::Node const&) const': stringtriebuilder.cpp:(.text._ZNK6icu_6917StringTrieBuilder4NodeeqERKS1_+0x18): undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: ../../../config/external/icu/common/stringtriebuilder.o: in function `icu_69::StringTrieBuilder::FinalValueNode::operator==(icu_69::StringTrieBuilder::Node const&) const': stringtriebuilder.cpp:(.text._ZNK6icu_6917StringTrieBuilder14FinalValueNodeeqERKNS0_4NodeE+0x18): undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: ../../../config/external/icu/common/stringtriebuilder.o: in function `icu_69::StringTrieBuilder::SplitBranchNode::operator==(icu_69::StringTrieBuilder::Node const&) const': stringtriebuilder.cpp:(.text._ZNK6icu_6917StringTrieBuilder15SplitBranchNodeeqERKNS0_4NodeE+0x18): undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: ../../../config/external/icu/common/stringtriebuilder.o:stringtriebuilder.cpp:(.text._ZNK6icu_6917StringTrieBuilder14ListBranchNodeeqERKNS0_4NodeE+0x18): more undefined references to `std::type_info::operator==(std::type_info const&) const' follow collect2: error: ld returned 1 exit status looks identical to me (the additional dwarf bug has been fixed in binutils since)
[Bug c/105323] assignment that is unused afterwards is not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105323 --- Comment #2 from Li Zhong --- Any further comment on this? To do data flow analysis in local variable relatively costs less time and can definitely help developers find more bugs like forgetting return value, etc.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Eric Gallager changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Fabian Groffen from comment #3) > The problem with this snippet is that it doesn't work on Frameworks, does > it? At least for me, it seems it searches from usr/include only? Yeah I'm pretty sure fixincludes doesn't work with Frameworks; is that worth opening a separate bug for, or should it just be tracked as part of this one?
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #7 from Jerry DeLisle --- My apologies for taking some time to get back to this. After a closer look, I realize that in the original test case there is no problem. The semicolon is an acceptable value separator regardless of decimal='point' or decimal='comma' Take these two examples: 1) The comma is the decimal keeper so semicolon must be used as the separator implicit none integer n,m,ios real r character(20):: testinput = '1;17;3,14159' n = 999 print *,'testinput = "',testinput,'"' read(testinput,*,decimal='comma', iostat=ios) n, m, r print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program 2) The point is the decimal keeper so semicolon may be used as the separator or a comma implicit none integer n,m,ios real r character(20):: testinput = '1;17;3.14159' n = 999 print *,'testinput = "',testinput,'"' read(testinput,*,decimal='point', iostat=ios) n, m, r print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program In the original test case, the semicolon is a separator and is simply ending the read as no value is there.
[Bug c/81233] -Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81233 Eric Gallager changed: What|Removed |Added Status|RESOLVED|REOPENED Summary|--Wdiscarded-qualifiers and |-Wdiscarded-qualifiers and |Wincompatible-pointer-types |Wincompatible-pointer-types |missing important detail|missing important detail CC||egallager at gcc dot gnu.org Resolution|FIXED |--- --- Comment #5 from Eric Gallager --- (In reply to Marek Polacek from comment #3) > Fixed. Further improvements are possible. Uh... reopening for the possible further improvements; -Wdiscarded-qualifiers still doesn't say quite enough, IMO
[Bug preprocessor/105605] New: Manual/doc: Default dependency target (-MT) omits dependence on -o (output file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105605 Bug ID: 105605 Summary: Manual/doc: Default dependency target (-MT) omits dependence on -o (output file) Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: scott.g.mcpeak at gmail dot com Target Milestone: --- In the current documentation for preprocessor options: https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html under the description of the -MT switch, it says: Change the target of the rule emitted by dependency generation. By default CPP takes the name of the main input file, deletes any directory components and any file suffix such as `.c', and appends the platform's usual object suffix. The result is the target. The second sentence is true of -M/-MM, but not of -MD/-MMD: $ mkdir tmp; cd tmp $ echo 'int x;' > foo.c $ gcc -MMD -c foo.c -o bar.o# Note "-o bar.o". $ ls bar.d bar.o foo.c $ cat bar.d bar.o: foo.c# Note target name: "bar.o". If the manual were correct, the target would be called "foo.o" because no -MT is specified and the source file name is "foo.c". The GCC behavior here is perfectly sensible of course, but the manual does not describe it correctly. In general, based on experimentation with GCC-12.1.0, a correct description of the procedure for determining the target name or names is to use the first of: 1. The sequence of names given to -MT, then those given to -MQ, each respective sequence in command line order, if there are any -MQ/-MT switches; or 2. For -MD and -MMD, the argument to -o, if present; or 3. The source file name, without any directory, one suffix removed (if it had any), and the platform object file suffix added. If no source files are present, no dependency information is created (even with -MF), so we can't fall through case 3. When multiple source files are present, these rules apply to each dependency output file separately. In particular, case 3 yields a potentially different target name for each dependency output file. Interestingly, for case 1, the order of -MT versus -MQ is reversed in GCC-9.3.0, which puts the -MQs first. In summary: case 2 should be documented.
[Bug middle-end/105604] [10/11/12 Regression] ICE: in tree_to_shwi with vla in struct and sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, ||ice-on-valid-code Target Milestone|--- |10.4 Summary|[10/11/12 Regression] ICE: |[10/11/12 Regression] ICE: |in tree_to_shwi, at |in tree_to_shwi with vla in |tree.cc:6369|struct and sprintf --- Comment #1 from Andrew Pinski --- Feels like someone forgot to check if the type had a non constant size/offsets.
[Bug middle-end/105604] New: [10/11/12 Regression] ICE: in tree_to_shwi, at tree.cc:6369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604
Bug ID: 105604
Summary: [10/11/12 Regression] ICE: in tree_to_shwi, at
tree.cc:6369
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Originally reported by cpu in https://bugs.gentoo.org/844091. Here is my
attempt at minimizing it:
//$ cat main.c
struct {
long users;
long size;
char *data;
} * main_trans;
void *main___trans_tmp_1;
int sprintf(char *, char *, ...);
int main() {
int users = 0;
struct {
long users;
long size;
char *data;
int links[users];
char buf[];
} *trans = trans;
trans->data = trans->buf;
main___trans_tmp_1 = trans;
main_trans = main___trans_tmp_1;
sprintf(main_trans->data, "test");
}
$ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -c -Wall -O2 -pipe -fomit-frame-pointer main.c
during GIMPLE pass: strlen
main.c: In function ‘main’:
main.c:8:5: internal compiler error: in tree_to_shwi, at tree.cc:6369
8 | int main() {
| ^~~~
0x1116ade tree_to_shwi(tree_node const*)
gcc/tree.cc:6369
0x1116b36 int_byte_position(tree_node const*)
gcc/tree.cc:3616
0x1cd1ce8 get_origin_and_offset_r
gcc/gimple-ssa-sprintf.cc:2354
0x1cd1845 get_origin_and_offset_r
gcc/gimple-ssa-sprintf.cc:2307
0x1cd1f29 get_origin_and_offset_r
gcc/gimple-ssa-sprintf.cc:2370
0x1cd64ce get_origin_and_offset
gcc/gimple-ssa-sprintf.cc:2427
0x1cd64ce handle_printf_call(gimple_stmt_iterator*, pointer_query&)
gcc/gimple-ssa-sprintf.cc:4703
0x103ff10 strlen_pass::check_and_optimize_call(bool*)
gcc/tree-ssa-strlen.cc:5461
0x103ffb3 strlen_pass::check_and_optimize_stmt(bool*)
gcc/tree-ssa-strlen.cc:5665
0x1040326 strlen_pass::before_dom_children(basic_block_def*)
gcc/tree-ssa-strlen.cc:5849
0x1c5d56b dom_walker::walk(basic_block_def*)
gcc/domwalk.cc:309
0x10409cf printf_strlen_execute
gcc/tree-ssa-strlen.cc:5908
0x1040c58 execute
gcc/tree-ssa-strlen.cc:6007
I seem to be able to reproduce ICE on: 10.3.0, 11.3.0, 12.1.0.
This does not ICE: 9.3.0
$ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -v
Reading specs from /tmp/gb/gcc/specs
COLLECT_GCC=/tmp/gb/gcc/xgcc
COLLECT_LTO_WRAPPER=/tmp/gb/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap
--with-native-system-header-dir=/<>/glibc-2.34-115-dev/include
--prefix=/tmp/gb/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1
-ggdb3'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220514 (experimental) (GCC)
[Bug preprocessor/105603] New: Manual incorrectly says -MD -E -o specifies dependency output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105603 Bug ID: 105603 Summary: Manual incorrectly says -MD -E -o specifies dependency output file Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: scott.g.mcpeak at gmail dot com Target Milestone: --- In the current documentation for preprocessor options: https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html under the description of the -MD switch, it says: If -MD is used in conjunction with -E, any -o switch is understood to specify the dependency output file (see -MF), but if used without -E, each -o is understood to specify a target object file. At least with current GCC-12.1.0 (also confirmed with GCC-9.3.0), this is simply false. The -MD switch does dependency generation in addition to normal operation, which for -E means preprocessing and sending that output to -o: $ mkdir tmp; cd tmp $ echo 'int x;' > foo.c $ gcc -MD -E -o foo.i foo.c $ ls foo.c foo.d foo.i $ cat foo.i # foo.i is pp output [...] # 1 "foo.c" int x; $ cat foo.d # dependencies written to foo.d foo.o: foo.c /usr/include/stdc-predef.h There is nothing special about the -MD -E -o combination; each of the switches is behaving in its usual, orthogonal way. Now, I speculate that the author intended to describe -M/-MM, since with those switches, the primary output of the compiler is dependency information, and consequently -o says where it goes: $ rm *.d *.i $ gcc -M -E -o foo.d foo.c $ ls foo.c foo.d $ cat foo.d foo.o: foo.c /usr/include/stdc-predef.h However, even here, there is nothing special going on. -M -E is simply equivalent to -M alone, and -o is doing its usual job of specifying where to put the primary output. Therefore, I think this paragraph should simply be deleted. Tangentially, I'll note that the equivalence of "-M -E" and "-M" is not clearly documented, but that's part of a more general behavior of the precedence chain of -M[M] > -E > -S > -c, which probably should be documented, but not in the vicinity of the topic of this bug report. For completeness, I observe this on "Target: x86_64-pc-linux-gnu".
[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #5 from Eric Gallager --- One thing to consider now that GCC has a static analyzer is that putting the kind of useless "if" in question before a "free" can make the analyzer shut up about possible double-free warnings, so if this were to become its own diagnostic, there might be separate diagnostics that prompt users to do opposite things...
[Bug driver/34280] using -o with -MM produces truncated output with multiple input files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34280 Scott McPeak changed: What|Removed |Added CC||scott.g.mcpeak at gmail dot com --- Comment #2 from Scott McPeak --- This issue still exists in GCC-12.1.0, and I want to note a few other related behaviors. The behavior of -M[M] is inconsistent with that of -E, -S, and -c. For example, with -c: $ touch foo.c bar.c $ gcc -c foo.c bar.c -o combined.o gcc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple files compilation terminated. But with -M or -MM: $ gcc -MM foo.c bar.c -o combined.d $ cat combined.d bar.o: bar.c Also note that the issue affects -MF as well: $ gcc -MM foo.c bar.c -MF combined.d $ cat combined.d bar.o: bar.c and, consequently, extends to -M[M]D: $ gcc -c foo.c bar.c -MMD -MF combined.d $ cat combined.d bar.o: bar.c I think (concurring with Andrew) that these combinations ought to be rejected when there are multiple input files: * (-M or -MM) and (-o or -MF) * (-MD or -MMD) and -MF However, a case can be made to allow those combinations if the specified output file is "-" (standard output) since that does work, for example: $ gcc -MM foo.c bar.c -MF - foo.o: foo.c bar.o: bar.c Finally, why does this seemingly obscure bug matter? The GCC command line language has become a de-facto standard, and a wide variety of software tools work by interpreting, and in some cases emulating, that language. These tools need to know about and properly handle dark corners like this one because someone, somewhere will be relying on it, albeit almost certainly inadvertently. It would be beneficial to users and tool makers alike for GCC to take the lead in rejecting nonsensical command line combinations (as it has, for example, with C++ language conformance, in my perception).
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #1 from Brecht Sanders --- Apparently this issue is not related to the .exe extension, but rather to where it is looking for cc1.exe. If somepath/bin is where gcc.exe lives than it helpst to add somepath/libexec/gcc/x86_64-w64-mingw32/12.1.0 to the PATH to around this issue. But this should not be necessary. I also find it strange that I don't have this issue with the MSVCRT build of MinGW-w64, but I do have the issue with the UCRT build of MinGW-w64. Is there a different path or architecture triplet at play for UCRT?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #11 from tt_1 --- well, my systems toolchain is gcc-12.1.0, glibc-2.34-r13 and binutils-2.37_p1-r2 - on gentoo, binutils is slotted so I can downgrade rather easily. but I guess you would like me to try another binutils to bootstrap the cross-compiler toolchain, right? removing the cross-compiler-toolchain and rebootstraping the whole cross-compiler is in fact very easy and I'm happy to try any sensible combination. available binutils for cross are: 2.32-r2, 2.33.1-r1, 2.34-r2, 2.35.2, 2.36.1-r2, 2.37_p1-r2, 2.38-r2 or did you in fact ask me to downgrade glibc, from 2.34 to 2.33?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #10 from Andrew Pinski --- 00082930 T _ZNKSt9type_infoeqERKS_ As expected. I still suspect a binutils issue. Is there a way to go back to 2.33.x?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #9 from tt_1 --- Created attachment 52978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52978&action=edit compressed output of nm for cross-compilers libstdc++ this is the output of nm for the cross-compilers libstdc++.so
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #8 from Andrew Pinski --- Can you do nm on libstdc++.so in the sysroot?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #7 from tt_1 --- Created attachment 52977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52977&action=edit verbose output without -Wl, Bsymbolic-functions
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #6 from tt_1 --- Created attachment 52976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52976&action=edit verbose output without -Wl, as-needed
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to tt_1 from comment #3) > > maybe something went wrong with this patch: > > > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=3633cc54284450433b81f0340483e15df1a49a3c > > > > its arm specific, and merges different implementations into one. > > > > But I'm not close to being an expert here. > > Right and I am still thinking there is a linker issue. > > Can you remove -Wl,--as-needed option from the command line and try again? The other one to try to remove is -Wl,-Bsymbolic-functions .
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #4 from Andrew Pinski --- (In reply to tt_1 from comment #3) > maybe something went wrong with this patch: > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=3633cc54284450433b81f0340483e15df1a49a3c > > its arm specific, and merges different implementations into one. > > But I'm not close to being an expert here. Right and I am still thinking there is a linker issue. Can you remove -Wl,--as-needed option from the command line and try again?
[Bug libstdc++/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 tt_1 changed: What|Removed |Added Component|target |libstdc++ --- Comment #3 from tt_1 --- maybe something went wrong with this patch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3633cc54284450433b81f0340483e15df1a49a3c its arm specific, and merges different implementations into one. But I'm not close to being an expert here.
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #2 from tt_1 --- Created attachment 52975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52975&action=edit verbose output with -v thank you for your answer, I'm uncertain as the error is from linking but points to gcc-12 headers?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #1 from Andrew Pinski --- This could be a binutils issue. Can you add -v to the command line and provide the output?
[Bug target/105602] New: [OpenMP][gcn] — Support multiple arch in gcc/config/gcn/t-omp-device? Add 'amdgcn' (additionally to/instead of 'amd')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105602
Bug ID: 105602
Summary: [OpenMP][gcn] — Support multiple arch in
gcc/config/gcn/t-omp-device? Add 'amdgcn'
(additionally to/instead of 'amd')
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
I note that GCC has in gcc/config/gcn/t-omp-device:
echo kind: gpu > $@
echo arch: gcn >> $@
echo isa: fiji gfx900 gfx906 gfx908 >> $@
That is, GCC supports as context selector:
match(construct={target},device={arch(gcn)})
In contrast, llvm has, e.g. in clang/lib/Headers/openmp_wrappers/cmath:
#pragma omp begin declare variant match(device = {arch(amdgcn)})
Thus: LLVM uses 'amdgcn'.
Expected: arch = 'amdgcn' (also) works in GCC for better compatibility. I did
not find a documentation and I think either variant is fine – albeit 'amdgcn'
seems to be more natural.
[Bug libstdc++/105601] New: spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 Bug ID: 105601 Summary: spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const' Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: herrtimson at yahoo dot de Target Milestone: --- hey there, I really hope I'm not misstaken here - tried to cross compile spidermonkey-91 from an amd64 host to an armv7a target to me it seems that there is possibly a bug somehwere in libstdc++-v3? /usr/bin/armv7a-unknown-linux-gnueabihf-g++ --sysroot /usr/armv7a-unknown-linux-gnueabihf -fstack-protector-strong -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wno-error=unused-but-set-variable -Wformat -Wformat-security -Wformat-overflow=2 -Wno-psabi -fno-sized-deallocation -fno-aligned-new -O2 -pipe -fomit-frame-pointer -fno-tree-loop-vectorize -mthumb -mno-thumb-interwork -mfpu=neon -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer -funwind-tables -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libmozjs-91.so -o libmozjs-91.so /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/libmozjs-91_so.list -lpthread -Wl,-O1 -Wl,--as-needed -mthumb -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -fstack-protector-strong -Wl,-rpath-link,/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/dist/bin -Wl,-rpath-link,/usr/lib /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/thumbv7neon-unknown-linux-gnueabihf/release/libjsrust.a -Wl,--version-script,symverscript -Wl,-soname,libmozjs-91.so.0 -lm -L/usr/armv7a-unknown-linux-gnueabihf/usr/lib -lplds4 -lplc4 -lnspr4 -lz -lm -ldl /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/../../../config/external/icu/common/rbbi.o: in function `std::type_info::operator!=(std::type_info const&) const': /usr/lib/gcc/armv7a-unknown-linux-gnueabihf/12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/../../../config/external/icu/common/schriter.o: in function `std::type_info::operator!=(std::type_info const&) const': /usr/lib/gcc/armv7a-unknown-linux-gnueabihf/12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o: in function `icu_69::StringTrieBuilder::Node::operator==(icu_69::StringTrieBuilder::Node const&) const': /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/firefox-91.9.0/intl/icu/source/common/stringtriebuilder.cpp:388: undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/firefox-91.9.0/intl/icu/source/common/stringtriebuilder.cpp:388: undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/firefox-91.9.0/intl/icu/source/common/stringtriebuilder.cpp:388: undefined reference to `std::type_info::operator==(std::type_info const&) const' /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld: /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/build/js/src/build/../../../config/external/icu/common/stringtriebuilder.o:/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-lang/spidermonkey-91.9.0/work/firefox-91.9.0/intl/icu/source/common/stringtriebuilder.cpp:388: more undefined references to `std::type_info::operator==(std::type_info const&) const' follow collect2: error: ld returned 1 exit status I will attach the
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 --- Comment #9 from Jonathan Wakely --- It was already closed a year ago.
