[Bug target/107347] New: Sun Studio 12.6 assembler emits "warning: use of DCTI couples is deprecated" on sparc-sun-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107347 Bug ID: 107347 Summary: Sun Studio 12.6 assembler emits "warning: use of DCTI couples is deprecated" on sparc-sun-solaris2.11 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- Created attachment 53744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53744=edit Preprocessed source and generated assembler, compressed due to size Since upgrading to Studio 12.6 /usr/ccs/bin/as as the platform assembler for GCC on the sparc-sun-solaris2.11 target, the assembler emits warnings for all relevant versions of GCC (tested at least 12, 11, 10, 9, 8, 7). $ /usr/ccs/bin/as -V /usr/ccs/bin/as: Studio 12.6 Compiler Common 12.6 SunOS_sparc s11_3sru27_3 11/22/2017 $ g++-12 -mcpu=niagara4 -O3 -c -o /dev/null output_test_helper-preprocessed-12.cc /usr/ccs/bin/as: "/tmp/ccNN6N_b.s", line 7021: warning: use of DCTI couples is deprecated (Not sure if relevant, but different versions of GCC emit different numbers of the warning for the same file. The same command line using GCC 9 emits 3 warnings. The same command line using GCC 7 emits 2 warnings.) The Linux kernel was patched to fix this in 2017: https://lkml.org/lkml/2017/3/17/615 The binutils gas assembler was taught to emit the same warning in this commit: https://github.com/bminor/binutils-gdb/commit/46a2d504dd875caf60f9be191a55c9ff676bcd5c The complete text from the SPARC Architecture guide is in the LKML link above. GCC still generates assembler output that triggers this warning on the platform assembler, and I assume on a sufficiently new gas that was taught to emit the same warning. I've attached the preprocessed source and generated assembler for the file above. It generates the warning when the platform assembler is invoked as: $ /usr/ccs/bin/as -xarch=sparc4 -o output_test_helper-preprocessed-12.o output_test_helper-preprocessed-12.s /usr/ccs/bin/as: "output_test_helper-preprocessed-12.s", line 7021: warning: use of DCTI couples is deprecated The relevant generated assembler is: .LL1699: ld [%fp-2928], %o0 add %fp, -2920, %g1 cwbne %o0, %g1, .+16 nop ba,pt %xcc, .LL1902 nop call_ZdlPv, 0 mov%l0, %i0 ba,a,pt %xcc, .LL1999 .LL1782: --->call__cxa_guard_abort, 0 or %i5, %lo(_ZGVZN8internal12_GLOBAL__N_116GetSubstitutionsEvE13percentage_re), %o0 .LLEHB124: call_Unwind_Resume, 0 mov%i0, %o0 The arrow points to the line generating the warning. The programming note in the architecture manual spells out the issue: Programming Note As noted in TABLE 6-5 on page 115, an annulled branch-always (branch-always with a = 1) instruction is not architecturally a DCTI. However, since not all implementations make that distinction, for optimal performance, a DCTI should not be placed in the instruction word immediately following an annulled branch-always instruction (BA,A or BPA,A)."
[Bug target/107336] [10 regression] ICE segfault expand_expr_real_1 on sparc-sun-solaris2.11 with -m32 -mcpu=niagara4 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107336 --- Comment #8 from Andrew Paprocki --- (In reply to Eric Botcazou from comment #6) > Created attachment 53739 [details] > Tentative fix > > Totally untested. Tested, confirmed releases/gcc-10 branch with this patch fixes the issue. Thanks Andrew, Eric, Richard for the prompt response. -Andrew
[Bug target/107336] [10 regression] ICE segfault expand_expr_real_1 on sparc-sun-solaris2.11 with -m32 -mcpu=niagara4 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107336 Andrew Paprocki changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED Summary|[10/11 regression] ICE |[10 regression] ICE |segfault expand_expr_real_1 |segfault expand_expr_real_1 |on sparc-sun-solaris2.11|on sparc-sun-solaris2.11 |with -m32 -mcpu=niagara4|with -m32 -mcpu=niagara4 |-O3 |-O3 --- Comment #4 from Andrew Paprocki --- Changed to reflect this is just an issue with GCC 10 at this point. I built HEAD of the releases/gcc-10 branch and it still segfaults here with using attached test case: during RTL pass: expand In file included from /usr/lib/gcc-10.4/include/c++/10.4.1/random:51, from output_test_helper-10.cc:7: /usr/lib/gcc-10.4/include/c++/10.4.1/bits/random.tcc: In member function 'void std::mersenne_twister_engine<_UIntType, __w, __n, __m, __r, __a, __u, __d, __s, __b, __t, __c, __l, __f>::_M_gen_rand() [with _UIntType = unsigned int; unsigned int __w = 32; unsigned int __n = 624; unsigned int __m = 397; unsigned int __r = 31; _UIntType __a = 2567483615; unsigned int __u = 11; _UIntType __d = 4294967295; unsigned int __s = 7; _UIntType __b = 2636928640; unsigned int __t = 15; _UIntType __c = 4022730752; unsigned int __l = 18; _UIntType __f = 1812433253]': /usr/lib/gcc-10.4/include/c++/10.4.1/bits/random.tcc:405:14: internal compiler error: Segmentation Fault 0x162a903 crash_signal ../../gcc/toplev.c:328 0x103ceac expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10078 0x1035423 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:8366 0x102a2c3 store_expr(tree_node*, rtx_def*, int, bool, bool) ../../gcc/expr.c:5757 0x1029077 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5516 0xe3746b expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3784 0xe37993 expand_gimple_stmt ../../gcc/cfgexpand.c:3880 0xe40a8b expand_gimple_basic_block ../../gcc/cfgexpand.c:5929 0xe42a97 execute ../../gcc/cfgexpand.c:6584 I can confirm that the patch in the above linked bug does fix GCC 11.3.0.
[Bug target/107336] [10/11 regression] ICE segfault expand_expr_real_1 on sparc-sun-solaris2.11 with -m32 -mcpu=niagara4 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107336 --- Comment #3 from Andrew Paprocki --- The linked bugs have a patch for gimple-isel.cc that appears to fix the issue in GCC 11.3.0, but the ICE in GCC 10 is in expr.c and I don't see anything patching that. Is there another (related?) fix floating around for the GCC 10 ICE or is it a distinct bug?
[Bug c++/107336] New: [10/11 regression] ICE segfault expand_expr_real_1 on sparc-sun-solaris2.11 with -m32 -mcpu=niagara4 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107336 Bug ID: 107336 Summary: [10/11 regression] ICE segfault expand_expr_real_1 on sparc-sun-solaris2.11 with -m32 -mcpu=niagara4 -O3 Product: gcc Version: 10.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- Created attachment 53736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53736=edit GCC 10 & 11 pre-processed source files, compressed because they are 2MB each The ICE segfault happens when building google-benchmark 1.6.1 on sparc-sun-solaris2.11 in 32-bit mode. I've narrowed down the command line to: g++ -m32 -mcpu=niagara4 -O3 -c -o /dev/null output_test_helper-preprocessed.cc - Building -m64, the ICE does not happen - Building without -mcpu=niagara4, the ICE does not happen - Building with -O or -O2, the ICE does not happen - GCC 9.4.0 does not ICE - GCC 10.4.0 triggers ICE during RTL pass: expand - GCC 11.3.0 triggers ICE during GIMPLE pass: isel - GCC 12.1.0 does not ICE In GCC 10.4.0, the ICE occurs here: during RTL pass: expand In file included from /usr/lib/gcc-10.4/include/c++/10.4.0/random:51, from output_test_helper.cc:7: /usr/lib/gcc-10.4/include/c++/10.4.0/bits/random.tcc: In member function 'void std::mersenne_twister_engine<_UIntType, __w, __n, __m, __r, __a, __u, __d, __s, __b, __t, __c, __l, __f>::_M_gen_rand() [with _UIntType = unsigned int; unsigned int __w = 32; unsigned int __n = 624; unsigned int __m = 397; unsigned int __r = 31; _UIntType __a = 2567483615; unsigned int __u = 11; _UIntType __d = 4294967295; unsigned int __s = 7; _UIntType __b = 2636928640; unsigned int __t = 15; _UIntType __c = 4022730752; unsigned int __l = 18; _UIntType __f = 1812433253]': /usr/lib/gcc-10.4/include/c++/10.4.0/bits/random.tcc:405:14: internal compiler error: Segmentation Fault 0x162a8cf crash_signal ../../gcc/toplev.c:328 0x103ce38 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10078 0x10353af expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:8366 0x102a24f store_expr(tree_node*, rtx_def*, int, bool, bool) ../../gcc/expr.c:5757 0x1029003 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5516 0xe373f7 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3784 0xe3791f expand_gimple_stmt ../../gcc/cfgexpand.c:3880 0xe40a17 expand_gimple_basic_block ../../gcc/cfgexpand.c:5929 0xe42a23 execute ../../gcc/cfgexpand.c:6584 Using the same command line with GCC 11.3.0, the ICE still occurs, but changes to become: during GIMPLE pass: isel In file included from /usr/lib/gcc-11.3/include/c++/11.3.0/random:51, from output_test_helper.cc:7: /usr/lib/gcc-11.3/include/c++/11.3.0/bits/random.tcc: In member function 'void std::mersenne_twister_engine<_UIntType, __w, __n, __m, __r, __a, __u, __d, __s, __b, __t, __c, __l, __f>::_M_gen_rand() [with _UIntType = unsigned int; unsigned int __w = 32; unsigned int __n = 624; unsigned int __m = 397; unsigned int __r = 31; _UIntType __a = 2567483615; unsigned int __u = 11; _UIntType __d = 4294967295; unsigned int __s = 7; _UIntType __b = 2636928640; unsigned int __t = 15; _UIntType __c = 4022730752; unsigned int __l = 18; _UIntType __f = 1812433253]': /usr/lib/gcc-11.3/include/c++/11.3.0/bits/random.tcc:394:5: internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:270 0x1be84ff gimple_expand_vec_cond_expr ../../gcc/gimple-isel.cc:267 0x1be8673 gimple_expand_vec_exprs ../../gcc/gimple-isel.cc:297 0x1be8937 execute ../../gcc/gimple-isel.cc:350 No ICE occurs with GCC 12.1.0. If the underlying issue was fixed (accidentally or not), are there patches that can be applied to 10/11?
[Bug analyzer/100548] New: No GCC equivalent of built-in predefined macro __clang_analyzer__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100548 Bug ID: 100548 Summary: No GCC equivalent of built-in predefined macro __clang_analyzer__ Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- I scanned the `-fanalyzer -dM -E` output and there does not appear to be any built-in predefined macro to indicate that it is being evaluated by the analyzer. Clang defines the `__clang_analyzer__` built-in documented here: https://clang-analyzer.llvm.org/faq.html#exclude_code Can this be added?
[Bug analyzer/100546] New: -Wanayzer-null-dereference false positive through noreturn function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
Bug ID: 100546
Summary: -Wanayzer-null-dereference false positive through
noreturn function pointer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
Test case:
$ cat /tmp/test.cpp
#include
#include
static void noReturn(const char *str) __attribute__((noreturn));
static void noReturn(const char *str) {
printf("%s\n", str);
exit(1);
}
void (*noReturnPtr)(const char *str) =
int main(int argc, char **argv) {
char *str = 0;
if (!str)
noReturnPtr(__FILE__);
return printf("%c\n", *str);
}
Output:
$ g++-11 -fanalyzer -c /tmp/test.cpp
/tmp/test.cpp: In function 'int main(int, char**)':
/tmp/test.cpp:16:27: warning: dereference of NULL 'str' [CWE-476]
[-Wanalyzer-null-dereference]
16 | return printf("%c\n", *str);
| ^~~~
'int main(int, char**)': events 1-4
|
| 13 | char *str = 0;
| | ^~~
| | |
| | (1) 'str' is NULL
| 14 | if (!str)
| | ~~
| | |
| | (2) following 'true' branch (when 'str' is NULL)...
| 15 | noReturnPtr(__FILE__);
| | ~
| ||
| |(3) ...to here
| 16 | return printf("%c\n", *str);
| |
| | |
| | (4) dereference of NULL 'str'
|
[Bug analyzer/100543] New: -Wanalyzer-free-of-non-heap false positive / delete false positive due to constructor conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100543
Bug ID: 100543
Summary: -Wanalyzer-free-of-non-heap false positive / delete
false positive due to constructor conditional
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
# Test case:
#include
#include
#include
struct Assert {
[[ noreturn ]] static void noReturn();
};
template
union ObjectBuffer {
private:
char d_buffer[sizeof(TYPE)];
double d_align;
public:
char *buffer() { return d_buffer; }
TYPE& object() { return *reinterpret_cast(this); }
};
struct Foo {
char *d_buf;
unsigned d_sz;
Foo(char *buf, unsigned sz) : d_buf(buf), d_sz(sz) {
#ifdef ANALYZER_FAILURE
if (0 == d_buf) Assert::noReturn();
if (0 == d_sz) Assert::noReturn();
#endif
}
char *allocate(unsigned) { return d_buf; }
};
int main(int argc, char **argv) {
ObjectBuffer objectBuffer;
char buf[sizeof(Foo)];
void *ptr = new (objectBuffer.buffer()) Foo(buf, sizeof(buf));
return printf("%p\n", static_cast(ptr)->allocate(1));
}
## Output:
Works just fine:
$ g++-11 -fanalyzer -c /tmp/test.cpp
Fails:
$ g++-11 -DANALYZER_FAILURE -fanalyzer -c /tmp/test.cpp
/tmp/test.cpp: In function 'int main(int, char**)':
/tmp/test.cpp:36:65: warning: 'delete' of '&
objectBuffer.ObjectBuffer::d_buffer' which points to memory not on the
heap [CWE-590] [-Wanalyzer-free-of-non-heap]
36 | void *ptr = new (objectBuffer.buffer()) Foo(buf, sizeof(buf));
| ^
'int main(int, char**)': events 1-2
|
| 33 | int main(int argc, char **argv) {
| | ^~~~
| | |
| | (1) entry to 'main'
|..
| 36 | void *ptr = new (objectBuffer.buffer()) Foo(buf, sizeof(buf));
| | ~
| | |
| | (2) calling
'ObjectBuffer::buffer' from 'main'
|
+--> 'char* ObjectBuffer::buffer() [with TYPE = Foo]': events 3-4
|
| 15 | char *buffer() { return d_buffer; }
| | ^~
| | | |
| | | (4) pointer is from here
| | (3) entry to 'ObjectBuffer::buffer'
|
<--+
|
'int main(int, char**)': events 5-6
|
| 36 | void *ptr = new (objectBuffer.buffer()) Foo(buf, sizeof(buf));
| | ~~~^~ ~
| | | |
| | |
(6) calling 'Foo::Foo' from 'main'
| | (5) returning to 'main'
from 'ObjectBuffer::buffer'
|
+--> 'Foo::Foo(char*, unsigned int)': events 7-11
|
| 23 | Foo(char *buf, unsigned sz) : d_buf(buf), d_sz(sz) {
| | ^~~
| | |
| | (7) entry to 'Foo::Foo'
| 24 | #ifdef ANALYZER_FAILURE
| 25 | if (0 == d_buf) Assert::noReturn();
| | ~~
| | |
| | (8) following 'false' branch...
| 26 | if (0 == d_sz) Assert::noReturn();
| | ~~
| | ||
| | |(9) ...to here
| | (10) following 'false' branch...
| 27 | #endif
| 28 | }
| | ~
| | |
| | (11) ...to here
|
<--+
|
'int main(int, char**)': events 12-13
|
| 36 | void *ptr = new (objectBuffer.buffer()) Foo(buf, sizeof(buf));
| | ^
| | |
| |
(12) returning to 'main' from 'Foo::Foo'
| |
(13) call to 'delete' here
|
## Info:
"(13) call to 'delete' here" makes no sense. The entire thing is only triggered
by the presence of either conditional on line 25/26. If the conditional
branches are removed, it compiles fine.
[Bug analyzer/100540] New: -Wanalyzer-file-leak false positive due to conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100540
Bug ID: 100540
Summary: -Wanalyzer-file-leak false positive due to
conditionals
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
Test program:
#include
#include
char foo(const char *filename) {
FILE *fp;
if (!filename || strcmp(filename, "-") == 0) {
fp = stdin;
} else {
fp = fopen(filename, "r");
}
char c = fgetc(fp);
if (fp != stdin) {
fclose(fp);
}
return c;
}
int main(int argc, char **argv) {
if (argc > 1) {
char c = foo(argv[1]);
printf("%c\n", c);
}
return 0;
}
False positive:
$ gcc-11 -fanalyzer -c /tmp/test.c
/tmp/test.c: In function 'foo':
/tmp/test.c:18:12: warning: leak of FILE 'fp' [CWE-775] [-Wanalyzer-file-leak]
18 | return c;
|^
'foo': events 1-6
|
|6 | if (!filename || strcmp(filename, "-") == 0) {
| |^
| ||
| |(1) following 'false' branch...
|..
|9 | fp = fopen(filename, "r");
| |
| | |
| | (2) ...to here
| | (3) opened here
|..
| 14 | if (fp != stdin) {
| |~
| ||
| |(4) following 'false' branch...
|..
| 18 | return c;
| |~
| ||
| |(5) ...to here
| |(6) 'fp' leaks here; was opened at (3)
|
Expected outcome:
The analyzer should understand that without anything modifying stdin, stdout,
stderr, the return of fopen() can not be stdin, stdout, or stderr, so
fclose(fp) must be hit.
[Bug analyzer/100524] New: pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100524 Bug ID: 100524 Summary: pragma GCC diagnostic ignored "-Wanalyzer-too-complex" ignored by cc1 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- Invoking the compiler from the command line as: gcc -fanalyzer -Wanalyzer-too-complex -Werror=analyzer-too-complex ... Source code contains a function that generates a -Wanalyzer-too-complex error (exact error unimportant): ... cc1: error: terminating analysis for this program point: callstring: [(SN: 17 -> SN: 9 in X), (SN: 141 -> SN: 16 in X)] before (SN: 115 stmt: 0): # DEBUG emptySlots$1 => emptySlots$1_80EN: 973-975, EN: 1017-1018, EN: 1054-1056 [-Werror=analyzer-too-complex] test.c: At top level: test.c:516:22: error analysis bailed out early (916 'after-snode' enodes; 3258 enodes) [-Werror=analyzer-too-complex] 516 | ... | cc1: all warnings being treated as errors Placing pragma diagnostic guards around the function in question silences the compiler front-end error, but cc1 still produces the same errors and fails with -Werror=analyzer-too-complex: #pragma diagnostic GCC push #pragma diagnostic GCC ignored "-Wanalyzer-too-complex" // function definition that generates the error #pragma diagnostic GCC pop Output: ... cc1: error: terminating analysis for this program point: callstring: [(SN: 17 -> SN: 9 in X), (SN: 141 -> SN: 16 in X)] before (SN: 115 stmt: 0): # DEBUG emptySlots$1 => emptySlots$1_80EN: 973-975, EN: 1017-1018, EN: 1054-1056 [-Werror=analyzer-too-complex] cc1: all warnings being treated as errors The "test.c" output with the compiler error and source code context are no longer output, but cc1 still produces a fatal error and halts compilation. I would expect that if the warning is `#pragma diagnostic GCC ignored` that cc1 would respect this, otherwise it is not possible to fine-grain ignore specific complex portions of code in this manner.
[Bug target/93146] C++ TLS init function not generated on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93146 Andrew Paprocki changed: What|Removed |Added CC||andrew at ishiboo dot com --- Comment #3 from Andrew Paprocki --- Just wanted to echo that I hit this as well because gdb (I'm compiling 9.1) now uses `thread_local`: ld: 0711-317 ERROR: Undefined symbol: TLS init function for thread_local_segv_handler ld: 0711-317 ERROR: Undefined symbol: .TLS init function for thread_local_segv_handler Using `-fno-extern-tls-init` results in a successful build.
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #29 from Andrew Paprocki --- David, Using GCC 9.2.0 I can reproduce using the steps from comment 27. Did you run them yourself?
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #27 from Andrew Paprocki --- 60 second reproduction steps: $ curl -O https://ftp.pcre.org/pub/pcre/pcre-8.42.tar.gz $ tar zxvf pcre-8.42.tar.gz && cd pcre-8.42 $ CC="gcc-7" \ CXX="g++-7" \ CFLAGS="-maix32 -pthread" \ CXXFLAGS="-maix32 -pthread" \ LDFLAGS="-Wl,-bsvr4" \ ./configure && make -j It will fail: ld: 0711-308 SEVERE ERROR: Object pcre_stringpiece_unittest-pcre_stringpiece_unittest.o, csect <_pcrestringpieceunittest.ro_> The csect is part of the .text section. ld: 0711-308 SEVERE ERROR: Object pcre_scanner_unittest-pcre_scanner_unittest.o, csect <_pcrescannerunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status collect2: error: ld returned 12 exit status ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status
[Bug target/89096] [8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #26 from Andrew Paprocki --- Just re-summarizing now for 2020 since there have been a few twists and turns and distractions. This issue has nothing to do with CMake, -brtl, or -bexpall linker flags. This issue only occurs when GCC is told to pass the -bsvr4 linker flag, because the application wishes to use multiple -R parameters as documented in the man page (see comment 14). When that occurs, the error in this ticket happens. The already applied patches to GCC mentioned throughout the bug do not change any behavior -- it still fails to link. David, can you or someone on the linker team determine if this is an issue with the GCC side of things, or it is simply a bug in the linker? It is difficult for an outsider to determine if this is purely on the linker side or if GCC is not conforming somehow to what the linker expects.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 Andrew Paprocki changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #20 from Andrew Paprocki --- I applied the patch and attempted to rebuild pcre and it still fails in the same manner: ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. Dumping the assembler (same as last attachment) shows only use of .ro_ as RO: $ grep _pcrecppunittest.ro_ pcrecpp_unittest.s .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 .csect _pcrecppunittest.ro_[RO],4 There are a few places where this csect immediately follows a reference to .text, but I don't know if that is related at all. Those cases look like this: .csect .text[PR] .ref Lframe..1 .csect _pcrecppunittest.ro_[RO],4
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #19 from Andrew Paprocki --- Thanks, I’ll give it a try. From memory, the .s file I attached did not contain any RW csect by the same name like you mention in the description, but perhaps the patch still addresses the issue.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #17 from Andrew Paprocki --- Thanks, I’m just interested in the URL / bug / commit for the patch(es) you created so that I can apply them to our in-house GCC and test everything out. If you could point me to them I’d appreciate it.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #15 from Andrew Paprocki --- Created attachment 46597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46597=edit g++-6 -S output of pcrecpp_unittest.cc Generated with the command line: g++-6 -DHAVE_CONFIG_H -I. -I.. -maix32 -O -MT pcrecpp_unittest-pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo -S ../pcrecpp_unittest.cc
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #14 from Andrew Paprocki --- I can reproduce this error with a much simpler project, pcre, that uses autotools and libtool. Using pcre 8.42 from https://ftp.pcre.org/pub/pcre/pcre-8.42.tar.gz $ mkdir build $ cd build $ CC=gcc-6 CXX=g++-6 OBJECT_MODE=32 CFLAGS="-maix32 -O" CXXFLAGS="-maix32 -O" ../configure --enable-unicode-properties --enable-pcre16 --enable-pcre32 --enable-jit $ OBJECT_MODE=32 make V=1 ... g++-6 -DHAVE_CONFIG_H -I. -I.. -maix32 -O -MT pcrecpp_unittest-pcrecpp_unittest.o -MD -MP -MF .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo -c -o pcrecpp_unittest-pcrecpp_unittest.o `test -f 'pcrecpp_unittest.cc' || echo '../'`pcrecpp_unittest.cc mv -f .deps/pcrecpp_unittest-pcrecpp_unittest.Tpo .deps/pcrecpp_unittest-pcrecpp_unittest.Po /bin/sh ./libtool --tag=CXX --mode=link g++-6 -maix32 -O -o pcrecpp_unittest pcrecpp_unittest-pcrecpp_unittest.o libpcrecpp.la -lpthreads libtool: link: g++-6 -maix32 -O -o .libs/pcrecpp_unittest pcrecpp_unittest-pcrecpp_unittest.o -L/tmp/pcre/build/.libs -L./.libs -lpcrecpp -lpcre -L/path/to/gcc/lib -lstdc++ -lm -lpthreads -Wl,-blibpath:/usr/local/lib:/path/to/gcc/lib:/path/to/gcc/lib/.:/usr/lib:/lib ld: 0711-308 SEVERE ERROR: Object pcrecpp_unittest-pcrecpp_unittest.o, csect <_pcrecppunittest.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status Makefile:1518: recipe for target 'pcrecpp_unittest' failed make[1]: *** [pcrecpp_unittest] Error 1 I've narrowed this down to the usage of the -bsvr4 linker flag, which we use because we depend on passing multiple -R parameters and the linker behavior described in the man page: -R Path ... Multiple instances of this option are concatenated together with each Path separated by a colon. If -bsvr4 is placed on the collect2 command line (obtained from -v output of the link), the link fails with the output above. I know in the past flag ordering has mattered, and in this case it fails in the same manner when it is both the first flag and last flag on the command line. This fails without any usage of -bexpall and -brtl.
[Bug target/89096] [7/8/9/10 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #13 from Andrew Paprocki --- What is the other bug number w/ patch that you're referring to?
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #8 from Andrew Paprocki --- David, -brtl and -bexpall are coming from CMake itself: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/AIX-XL.cmake *All* software (open-source and closed-source) using CMake as a build system uses these flags by default when building on AIX. AIX is hard enough to wrangle open-source software on -- don't shoot the messenger. I'm just trying to determine the root cause of the failure and I have no problem putting in the time to PR CMake or multiple projects to override these settings if I have to in order to fix their worldview of AIX. > Is protobufs even known to build on AIX? Like I said above, protobufs builds and runs fine on AIX using GCC 5. I only hit this when I try GCC 6+.
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #6 from Andrew Paprocki --- The source code for main.cc is found here: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/compiler/main.cc
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #5 from Andrew Paprocki --- Created attachment 45571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45571=edit g++-8 -S output for main.cc
[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #4 from Andrew Paprocki --- This occurs while building a project that depends on the protobuf library. I'll attach main.cc.s, and command lines are below. If I take the exact main.cc.o compilation line and simply swap out GCC 8.2.0 for g++-7, g++-6, g++-5, both GCC 7.3.0 & GCC 6.4.0 fail in the same manner, but GCC 5.5.0 succeeds. This is how main.cc.o is compiled: g++-8 -maix64 -pthread -DGOOGLE_PROTOBUF_CMAKE_BUILD -DHAVE_PTHREAD -DHAVE_ZLIB -D_LIBCXXABI_FUNC_VIS="" -I/path/to/third_party/protobuf/cmake -I/path/to/third_party/protobuf/src -D__STDC_FORMAT_MACROS -O2 -g -DNDEBUG -std=c++11 -o CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -c /path/to/third_party/protobuf/src/google/protobuf/compiler/main.cc ... verbose output shows cc1plus invocation: cc1plus -quiet -v -I /path/to/third_party/protobuf/cmake -I /path/to/third_party/protobuf/src -imultilib pthread/ppc64 -iprefix /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/ -D_ALL_SOURCE -D__COMPATMATH__ -D__64BIT__ -D_THREAD_SAFE -D GOOGLE_PROTOBUF_CMAKE_BUILD -D HAVE_PTHREAD -D HAVE_ZLIB -D _LIBCXXABI_FUNC_VIS= -D __STDC_FORMAT_MACROS -D NDEBUG /path/to/third_party/protobuf/src/google/protobuf/compiler/main.cc -quiet -dumpbase main.cc -maix64 -auxbase-strip CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -g -O2 -std=c++11 -version -o /tmp/ccVqNDE3.s ... verbose output shows as invocation: as -u -a64 -mppc64 -many -o CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o /tmp/ccVqNDE3.s This is how the build is attempting to link main.cc.o into a binary: g++-8 -maix64 -pthread -D__STDC_FORMAT_MACROS -O2 -g -DNDEBUG -Wl,-bnoipath -Wl,-brtl -Wl,-bbigtoc -Wl,-bexpall CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -o protoc-3.6.1 -Wl,-blibpath:/path/to/lib64:/usr/lib:/lib libprotobuf.a libprotoc.a libprotobuf.a /path/to/lib64/libz.so Result of running verbose output on the link: COLLECT_GCC_OPTIONS='-maix64' '-pthread' '-D' '__STDC_FORMAT_MACROS' '-O2' '-g' '-D' 'NDEBUG' '-o' 'protoc-3.6.1' '-v' '-shared-libgcc' /path/to/gcc/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/collect2 -bpT:0x1000 -bpD:0x2000 -btextro -b64 -L/path/to/lib64 -brtl -R /path/to/lib64 -bsvr4 -o protoc-3.6.1 /lib/crt0_64.o /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/crtcxa.o /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/crtdbase.o -L/path/to/gcc/lib/pthread/ppc64 -R /path/to/gcc/lib/pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/../../../pthread/ppc64 -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0 -L/path/to/gcc/bin/../lib/gcc -L/path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/../../.. -bnoipath -brtl -bbigtoc -bexpall CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o -blibpath:/path/to/lib64:/usr/lib:/lib libprotobuf.a libprotoc.a libprotobuf.a /path/to/lib64/libz.so -lstdc++ -lm -lgcc_s /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/libgcc.a -lpthreads -lc -lgcc_s /path/to/gcc/bin/../lib/gcc/powerpc-ibm-aix7.1.0.0/8.2.0/pthread/ppc64/libgcc.a -brtl -R /path/to/lib64 ld: 0711-308 SEVERE ERROR: Object CMakeFiles/protoc.dir/__/src/google/protobuf/compiler/main.cc.o, csect <_main.ro_> The csect is part of the .text section. collect2: error: ld returned 12 exit status
[Bug target/89096] [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 --- Comment #2 from Andrew Paprocki --- Specifying -bnotextro does not make a working binary: Could not load program x: Relocation failed for x because: Relocation entry 3 (at address 0x10416AD3) has an invalid l_rsecnm field. Relocation entry 4 (at address 0x10416AD3) has an invalid l_rsecnm field. Relocation entry 5 (at address 0x10416EC3) has an invalid l_rsecnm field. Relocation entry 6 (at address 0x10416EC3) has an invalid l_rsecnm field. Relocation entry 7 (at address 0x1041A3D3) has an invalid l_rsecnm field. Relocation entry 8 (at address 0x1041A3D3) has an invalid l_rsecnm field. Relocation entry 9 (at address 0x1041B813) has an invalid l_rsecnm field. Relocation entry 10 (at address 0x1041B813) has an invalid l_rsecnm field. Relocation entry 11 (at address 0x1041BF93) has an invalid l_rsecnm field. Relocation entry 12 (at address 0x1041BF93) has an invalid l_rsecnm field. Relocation entry 13 (at address 0x1041D2F3) has an invalid l_rsecnm field. Relocation entry 14 (at address 0x1041D2F3) has an invalid l_rsecnm field. ...
[Bug target/89096] New: [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096 Bug ID: 89096 Summary: [6/7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- I am trying to determine if this change in behavior is intentional or if there is something that can be done to work with the linker default behavior... GCC 6+ started generating sections named `_.ro_` that when passed to AIX `ld` produce the following error: ld: 0711-308 SEVERE ERROR: Object main.cc.o, csect <_main.ro_> The csect is part of the .text section. This happens for any such `.ro` symbol, not just the one for `main`. These are generated in gcc/config/rs6000/rs6000.c: rs6000_gen_section_name (_read_only_section_name, main_input_filename, ".ro_"); GCC 5 compiled objects link properly with default `ld` invocation. In order to "fix" this and link an executable, the following flag must be passed to deviate from default linker behavior: notextro or nro Does not check to ensure that there are no load time relocation entries for the text section of the output object file. This is the default. That implies default linker behavior is to reject any load time relocation entries against the `.text` section. Can anything be done to eliminate the need for this non-standard option or is this now required for all linking of GCC-compiled objects?
[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623 --- Comment #4 from Andrew Paprocki --- ... relying on the fact that `g++` will compile the `.c` files as C.
[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623 --- Comment #3 from Andrew Paprocki --- Sorry, I said 'libgcc', but I meant the 'gcc/' sub-directory. It is always using the C++ compiler for the build and relying on the fact that `g++`
[Bug libgcc/88623] New: libgcc build uses CXX_FOR_BUILD but files have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623 Bug ID: 88623 Summary: libgcc build uses CXX_FOR_BUILD but files have .c extension Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- Currently, gcc/Makefile.in specifies: COMPILER_FOR_BUILD = $(CXX_FOR_BUILD) indicating that the source files in the directory should be compiled with the C++ compiler, but the source files still retain the .c suffix. Building in this manner encodes some GCC-specific behavior into the build process. For example, IBM's XL C++ compiler will not behave the same as GCC when a file with a .c suffix is passed to the C++ compiler. There exists a command-line option, `-+` to force treating input as C++ even if the filename extension is .c, but this appears to have other side effects when it comes to built-in macros such as __STDC__. This caused an issue due to include/getopt.h only checking for __STDC__. I was able to work around it by changing this line: #if defined (__STDC__) && __STDC__ to: #if (defined (__STDC__) && __STDC__) || defined(__cplusplus) To ensure maximum compatibility bootstrapping with non-GCC compilers, the libgcc source code file suffixes should change to reflect whether they are C or C++ and the correct CC_FOR_BUILD / CXX_FOR_BUILD should be used to compile them.
[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 --- Comment #4 from Andrew Paprocki --- (In reply to Marek Polacek from comment #1) > Please submit a full bug report, with preprocessed source if appropriate. I had to attach the .ii and .s file tgz'd due to the file size limit of the bugtracker.
[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 --- Comment #3 from Andrew Paprocki --- Compiler info: $ g++-8 -v Reading specs from /dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../lib/gcc/specs COLLECT_GCC=/dev/shm/refroot/opt/bb/bin/g++-8 COLLECT_LTO_WRAPPER=/dev/shm/refroot/opt/bb/lib/gcc-8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/8.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran,go --build=x86_64-unknown-linux-gnu --prefix=/opt/bb/lib/gcc-8.1 --with-ar=/opt/rh/devtoolset-4/root/usr/bin/ar --with-ld=/opt/rh/devtoolset-4/root/usr/bin/ld --with-nm=/opt/rh/devtoolset-4/root/usr/bin/nm --with-objcopy=/opt/rh/devtoolset-4/root/usr/bin/objcopy --with-objdump=/opt/rh/devtoolset-4/root/usr/bin/objdump --with-ranlib=/opt/rh/devtoolset-4/root/usr/bin/ranlib --with-readelf=/opt/rh/devtoolset-4/root/usr/bin/readelf --with-gmp-include=/opt/bb/include --with-gmp-lib=/opt/bb/lib64 --with-mpfr-include=/opt/bb/include --with-mpfr-lib=/opt/bb/lib64 --with-mpc-include=/opt/bb/include --with-mpc-lib=/opt/bb/lib64 --with-libiconv-prefix=/tmp/gcc-8.1-8.1.0-0/build/iconv --with-stage1-ldflags='-Wl,--enable-new-dtags -Wl,-R/opt/bb/lib64' --with-boot-ldflags='-Wl,--enable-new-dtags -Wl,-R/opt/bb/lib64' --enable-plugin --enable-vtable-verify --disable-bootstrap Thread model: posix gcc version 8.1.0 Host info: RHEL6 $ uname -a Linux nylxdev1 2.6.32-642.6.2.el6.x86_64 #1 SMP Mon Oct 24 10:22:33 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/85634] 8.1 ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 --- Comment #2 from Andrew Paprocki --- Created attachment 44057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44057=edit -save-temps output
[Bug c++/85634] New: 8.1 ICE in tsubst_copy, at cp/pt.c:15483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634 Bug ID: 85634 Summary: 8.1 ICE in tsubst_copy, at cp/pt.c:15483 Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- Easily reproducible on a RHEL6 Linux box using the just released GCC 8.1.0 compiler built from source. 1) Clone https://github.com/bloomberg/bde 2) cd bde/groups/bsl/bslstl 3) Compile bslstl_queue.t.cpp The full compiler command line and output is: g++-8 \ -Wall -Wno-unused-variable \ -DBDE_BUILD_TARGET_EXC \ -DBDE_BUILD_TARGET_MT \ -DBDE_BUILD_TARGET_OPT \ -fexceptions \ -O2 \ -fno-gcse \ -fno-strict-aliasing \ -DNDEBUG \ -D_POSIX_PTHREAD_SEMANTICS \ -D_REENTRANT \ -D_FILE_OFFSET_BITS=64 \ -DBDE_NO_CPP_STDLIB \ -D_RWSTD_COMPILE_INSTANTIATE=1 \ -I. \ -I../bslalg \ -I../bsltf \ -I../bslma \ -I../bslh \ -I../bslmf \ -I../bslscm \ -I../bsls \ -c \ -o /dev/null \ bslstl_queue.t.cpp Output: bslstl_queue.t.cpp: In instantiation of 'static void TestDriver<VALUE, CONTAINER>::testCase6() [with VALUE = signed char; CONTAINER = bsl::deque >]': bslstl_queue.t.cpp:6618:9: required from here bslstl_queue.t.cpp:5114:21: internal compiler error: in tsubst_copy, at cp/pt.c:15483 operatorPtr operatorEq = operator==; ^~ 0x6fe553 tsubst_copy ../../gcc/cp/pt.c:15483 0x6f75dc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:18975 0x6fc177 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:17412 0x6fd5e5 tsubst_init ../../gcc/cp/pt.c:15274 0x6fce7e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:16726 0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:16599 0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:16896 0x6fbb04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:16599 0x6fc0b5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/cp/pt.c:16896 0x6fa6ad instantiate_decl(tree_node*, bool, bool) ../../gcc/cp/pt.c:23977 0x715b1b instantiate_pending_templates(int) ../../gcc/cp/pt.c:24093 0x673430 c_parse_final_cleanups() ../../gcc/cp/decl2.c:4725 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug other/70346] [libvtv] 6.1.0 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70346 Andrew Paprocki changed: What|Removed |Added Version|6.0 |6.1.0 Summary|[libvtv] 6.0-20160313 build |[libvtv] 6.1.0 build |succeeds, install fails:|succeeds, install fails: |cannot stat |cannot stat |'.libs/libvtv.a': No such |'.libs/libvtv.a': No such |file or directory |file or directory --- Comment #5 from Andrew Paprocki --- Updating title/version to indicate 6.1.0 release. I got this in the 6.0 builds and also see it in the 6.1.0 release.
[Bug other/70346] [libvtv] 6.0-20160313 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70346 --- Comment #1 from Andrew Paprocki --- $ find . | grep libvtv\\. ./libvtv/.libs/libvtv.lai ./libvtv/.libs/libvtv.la ./libvtv/.libs/libvtv.so.0.0.0 ./libvtv/.libs/libvtv.so.0 ./libvtv/.libs/libvtv.so ./libvtv/libvtv.la ./sparcv9/libvtv/.libs/libvtv.lai ./sparcv9/libvtv/.libs/libvtv.la ./sparcv9/libvtv/.libs/libvtv.so.0.0.0 ./sparcv9/libvtv/.libs/libvtv.so.0 ./sparcv9/libvtv/.libs/libvtv.so ./sparcv9/libvtv/libvtv.la
[Bug other/70346] New: [libvtv] 6.0-20160313 build succeeds, install fails: cannot stat '.libs/libvtv.a': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70346
Bug ID: 70346
Summary: [libvtv] 6.0-20160313 build succeeds, install fails:
cannot stat '.libs/libvtv.a': No such file or
directory
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew at ishiboo dot com
Target Milestone: ---
Target: sparc-sun-solaris2.11
Build succeeds and seems to build libvtv.la and libvtv.so*, but the install
step fails because it can't find libvtv.a. It seems like there are missing
targets/dependencies or some kind of make race:
...
make[8]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
/usr/bin/make install-recursive
make[9]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
make[10]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
true DO=all multi-do # /usr/bin/make
make[11]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
true DO=install multi-do # /usr/bin/make
mkdir -p
'/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9'
/bin/sh ./libtool --mode=install install -c libvtv.la
'/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9'
libtool: install: install -c .libs/libvtv.so.0.0.0
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9/libvtv.so.0.0.0
libtool: install: (cd
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9 && {
ln -s -f libvtv.so.0.0.0 libvtv.so.0 || { rm -f libvtv.so.0 && ln -s
libvtv.so.0.0.0 libvtv.so.0; }; })
libtool: install: (cd
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9 && {
ln -s -f libvtv.so.0.0.0 libvtv.so || { rm -f libvtv.so && ln -s
libvtv.so.0.0.0 libvtv.so; }; })
libtool: install: chmod +x
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9/libvtv.so.0.0.0
libtool: install: install -c .libs/libvtv.lai
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9/libvtv.la
libtool: install: install -c .libs/libvtv.a
/tmp/gcc-6.0-6.0.0~20160313-0/debian/gcc-6.0/usr/lib/gcc-6.0/lib/sparcv9/libvtv.a
install: cannot stat '.libs/libvtv.a': No such file or directory
make[11]: *** [install-toolexeclibLTLIBRARIES] Error 1
make[11]: Leaving directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
make[10]: *** [install-am] Error 2
Only mention of libvtv.a anywhere else in the log are these earlier lines:
checking for int_least32_t... make[7]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
rm -f vtv_start.c
rm -f vtv_end.c
ln -s /tmp/gcc-6.0-6.0.0~20160313-0/libvtv/../libgcc/vtv_start.c vtv_start.c
ln -s /tmp/gcc-6.0-6.0.0~20160313-0/libvtv/../libgcc/vtv_end.c vtv_end.c
/usr/bin/make all-recursive
make[8]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
make[9]: Entering directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
/bin/sh ./libtool --tag=CXX --mode=link
/tmp/gcc-6.0-6.0.0~20160313-0/build/./gcc/xgcc
-B/tmp/gcc-6.0-6.0.0~20160313-0/build/./gcc/ -D_GNU_SOURCE -Wall -Wextra
-fno-exceptions -I./../libstdc++-v3/include
-I./../libstdc++-v3/include/sparc-sun-solaris2.11
-I../../../../libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -g -O2 -gdwarf-2 -m64
-m64 -o libvtv.la -rpath /usr/lib/gcc-6.0/lib/sparcv9
... (link of shared object here)
libtool: link: ar rc .libs/libvtv.a
libtool: link: ranlib .libs/libvtv.a
libtool: link: ( cd ".libs" && rm -f "libvtv.la" && ln -s "../libvtv.la"
"libvtv.la" )
libtool: link: (cd ".libs" && rm -f "libvtv.so.0" && ln -s "libvtv.so.0.0.0"
"libvtv.so.0")
libtool: link: (cd ".libs" && rm -f "libvtv.so" && ln -s "libvtv.so.0.0.0"
"libvtv.so")
yes
checking for uint64_t... libtool: link: ar rc .libs/libvtv.a
libtool: link: ranlib .libs/libvtv.a
libtool: link: ( cd ".libs" && rm -f "libvtv.la" && ln -s "../libvtv.la"
"libvtv.la" )
make[9]: Leaving directory
`/tmp/gcc-6.0-6.0.0~20160313-0/build/sparc-sun-solaris2.11/sparcv9/libvtv'
[Bug go/70304] 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70304 Andrew Paprocki changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #2 from Andrew Paprocki --- Opened https://sourceware.org/bugzilla/show_bug.cgi?id=19849
[Bug go/70304] New: 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70304 Bug ID: 70304 Summary: 5.3.0 solaris: objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.e rrorString Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: andrew at ishiboo dot com CC: cmang at google dot com Target Milestone: --- Compiling gcc 5.3.0 release on Solaris 11, using platform assembler/linker and passing binutils 2.26.20160125 objcopy to configure. Everything builds fine until it gets to go where it fails like so: rm -f libgobegin.a ar cru libgobegin.a libgobegin_a-go-main.o ranlib libgobegin.a rm -f libgolibbegin.a ar cru libgolibbegin.a libgolibbegin_a-go-libmain.o ranlib libgolibbegin.a f=`echo errors.lo | sed -e 's/.lo$/.o/'`; objcopy -j .go_export $f errors.gox.tmp && mv -f errors.gox.tmp errors.gox objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString objcopy: errors.o: no group info for section .group%__go_pimt__I5_ErrorFrN6_stringeee__N18_errors.errorString objcopy:errors.o: Bad value make[9]: *** [errors.gox] Error 1 make[9]: *** Waiting for unfinished jobs
[Bug c++/70305] New: 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70305 Bug ID: 70305 Summary: 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: andrew at ishiboo dot com Target Milestone: --- In 5.3.0 release on Solaris, the libstdc++, libitm, and libgfortran libraries all fail to link with hundreds of errors such as: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a(wlocale-inst.o): section [1504].rela.eh_frame: symbol .text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator<wchar_t, std::char_traits >::equal(std::istreambuf_iterator<wchar_t, std::char_traits > const&) const (section): symbol has been discarded with discarded section: [716].text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator<wchar_t, std::char_traits >::equal(std::istreambuf_iterator<wchar_t, std::char_traits > const&) const or ld: fatal: relocation error: R_SPARC_UA32: file ../src/c++11/.libs/libc++11convenience.a(wlocale-inst.o): section [1509].rel a.debug_line: symbol .text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::istreambuf_iterator<wchar_t, st d::char_traits >::equal(std::istreambuf_iterator<wchar_t, std::char_traits > const&) const (section): symb ol has been discarded with discarded section: [716].text._ZNKSt19istreambuf_iteratorIwSt11char_traitsIwEE5equalERKS2_%std::i streambuf_iterator<wchar_t, std::char_traits >::equal(std::istreambuf_iterator<wchar_t, std::char_traits > const&) const The Solaris 11 linker by default now is very strict about COMDAT relocation processing. A new linker flag has been added `-z relax=comdat` that relaxes COMDAT rules and enables sloppy relocation processing. In order to get a working 5.3.0 build, it is necessary to patch configure (since libtool is not patched) to add the `-z relax=comdat` linker flag in all cases where GCC is used with the Solaris linker. I opened this here because patching libtool to add this flag seems incorrect. The built xg++ compiler should not be generating code that causes the (now) more strict linker to fail. $ ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2329 $ as -V as: Sun Compiler Common 12 SunOS_sparc s11_2sru04_1 09/30/2014 $ uname -a SunOS xxx 5.11 11.2 sun4v sparc sun4v Solaris From the man page: -z relax=item1,item2,... The link-editor performs validity checks in order to ensure that the resulting output object is valid and usable at runtime. In addition, the link-editor can transition a variety of relocations to generate more optimal instruction sequences. The -z relax option can be used to relax validity checking and relocation tran- sitions in order to produce an output object that would otherwise be rejected. comdat The link-editor normally issues a fatal error upon encountering a relocation using a symbol that refer- ences an eliminated COMDAT section. If -z relax=comdat is enabled, the link-editor instead redirects such relocations to the equivalent symbol in the COMDAT section that was kept.
[Bug c++/70305] 5.3.0 solaris: ld: fatal: relocation error: R_SPARC_DISP32: file ../src/c++11/.libs/libc++11convenience.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70305 --- Comment #1 from Andrew Paprocki --- Created attachment 38028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38028=edit Modifications to configure Example showing where the `-z relax=comdat` flag needed to be applied in the generated configure files to get a working build. Ultimately this flag should not be necessary and the compiler should be emitting correct relocations.
[Bug other/43748] build machinery insufficient for installing target specific .def files as plugin headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748 Andrew Paprocki andrew at ishiboo dot com changed: What|Removed |Added CC||andrew at ishiboo dot com --- Comment #1 from Andrew Paprocki andrew at ishiboo dot com 2011-08-13 17:32:37 UTC --- This breaks the installation of gcc-4.5 via macports. When trying to build anything which uses the plugin API, it can't find darwin-sections.def so you have to manually extract it from the tarball and sudo cp it to the installed macports directory to get the build working.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
Andrew Paprocki andrew at ishiboo dot com changed:
What|Removed |Added
CC||andrew at ishiboo dot com
--- Comment #104 from Andrew Paprocki andrew at ishiboo dot com 2011-08-03
20:17:26 UTC ---
Wow, just got bit by this 10 year old bug on Solaris 10. The following code
correctly errors with Sun's compiler:
#include string.h
int main() { char* foo = strchr(z, 'z'); return 0; }
foo.c, line 2: Error: Cannot assign const char* to char*.
But under no invocation of g++ does this even print a warning (-Wall -Wextra
-Wcast-qual) because Solaris iso/string_iso.h only declares the return value
'const' when __cplusplus = 199711L.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #105 from Andrew Paprocki andrew at ishiboo dot com 2011-08-03
20:26:17 UTC ---
$ uname -a
SunOS sun 5.10 Generic_137111-08 sun4v sparc SUNW,T5240 Solaris
$ CC -V
CC: Sun C++ 5.10 SunOS_sparc 128228-10 2010/08/18
$ g++ -dumpversion
4.5.2
$ cat foo.cpp
#include string.h
int main() { char* foo = strchr(z, 'z'); return 0; }
$ CC -c foo.cpp
foo.cpp, line 2: Error: Cannot use const char* to initialize char*.
1 Error(s) detected.
$ g++ -std=c++0x -pedantic -Wall -Wextra -Wno-unused -c foo.cpp
$
[Bug c++/46643] New: warn_unused_result is not enforced if return type is templated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46643
Summary: warn_unused_result is not enforced if return type is
templated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: and...@ishiboo.com
In the simple test case below, both bar() and baz() should print a warning. In
reality, only baz() prints a warning:
#include map
templatetypename T
class foo {
public:
std::pairT, int bar() __attribute__((warn_unused_result));
int baz() __attribute__((warn_unused_result));
};
templatetypename T inline
std::pairT, int fooT::bar() { return std::pairT, int(0, 0); }
templatetypename T inline
int fooT::baz() { return 0; }
int main(void) {
fooint b;
b.bar();
b.baz();
return 0;
}
$ g++ -o a a.cpp
a.cpp: In function 'int main()':
a.cpp:19: warning: ignoring return value of 'int fooT::baz() [with T = int]',
declared with attribute warn_unused_result
