[Bug c++/91265] New: new breakage for g++.dg/cpp0x/pr82560.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265 Bug ID: 91265 Summary: new breakage for g++.dg/cpp0x/pr82560.C Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For C++ testsuite file g++.dg/cpp0x/pr82560.C, somewhere between revision 273750 and 273800, with flag -O2, I get this: /home/dcb/gcc/results.273750/bin/g++ /home/dcb/gcc/results.273800/bin/g++ during GIMPLE pass: cddce ./g++.dg/cpp0x/pr82560.C: In function ‘int main()’: ./g++.dg/cpp0x/pr82560.C:28:1: internal compiler error: Segmentation fault 28 | } | ^ 0xfbaf6f crash_signal ../../trunk/gcc/toplev.c:326 0x11c9455 verify_use ../../trunk/gcc/tree-ssa.c:884 0x11cd940 verify_ssa(bool, bool) ../../trunk/gcc/tree-ssa.c:1161
[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #17 from Iain Sandoe --- (In reply to Jason Merrill from comment #6) I was looking into this area trying to diagnose/solve a testsuite fail on Darwin (see pr91087). > > I would expect A B C, and gcc currently outputs B A C. I assume that's because the SysV ABI says: "Termination functions specified by users via the atexit mechanism must be executed before any termination functions of shared objects.” and, therefore (for PIC at least) we would get incorrect nesting of CTORs and DTORs if the __attribute__((constructor)) was not run first. > Instead of emitting > constructor functions directly into .init_array as we do now, we should > remember them and call them from __static_initialization_and_destruction_0. Implementing this would probably also provide a workaround for the Darwin bug (by avoiding the use of special sections for the attributed ctor/dtors. Is there any specification that demands a specific section for the __attribute__((constructor/destructor))s?
[Bug ada/91266] New: [10 regression] acats cd2a31a fails for 32b hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91266 Bug ID: 91266 Summary: [10 regression] acats cd2a31a fails for 32b hosts. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- between r273419 and 273457 this test has started to fail on at least 3 32b hosts.
[Bug ada/91266] [10 regression] acats cd2a31a fails for 32b hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91266 Iain Sandoe changed: What|Removed |Added Target||i686-pc-linux-gnu, ||i686-apple-darwin9, ||powerpc-apple-darwin9 Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-26 Host||i686-pc-linux-gnu, ||i686-apple-darwin9, ||powerpc-apple-darwin9 Ever confirmed|0 |1 Known to fail||10.0 Build||i686-pc-linux-gnu, ||i686-apple-darwin9, ||powerpc-apple-darwin9
[Bug middle-end/91267] New: [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 Bug ID: 91267 Summary: [10 regression] SEGV in value_range_base::equal_p Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, i386-pc-solaris2.11, s390x-ibm-linux-gnu, ia64-suse-linux-gnu Between 20190724 (r273763) and 20190725 (r273802), and Ada test regressed on both Solaris/SPARC and x86, 32 and 64-bit. There are also reports on Linux/s390x and Linux/ia64. +FAIL: gnat.dg/opt78.adb (test for excess errors) Excess errors: raised CONSTRAINT_ERROR : SIGSEGV The failure can be seen with $ gnat1 -quiet -O -fRTS=/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libada /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt78.adb -o opt78.s Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x09854e3d in value_range_base::equal_p (this=0x0, other=...) at /vol/gcc/src/hg/trunk/local/gcc/tree-vrp.c:220 220 return (m_kind == other.m_kind (gdb) where #0 0x09854e3d in value_range_base::equal_p (this=0x0, other=...) at /vol/gcc/src/hg/trunk/local/gcc/tree-vrp.c:220 #1 0x09854f49 in value_range::equal_p (this=0x0, other=..., ignore_equivs=false) at /vol/gcc/src/hg/trunk/local/gcc/tree-vrp.c:231 #2 0x098f34ca in vr_values::update_value_range (this=0xaff10e8, var=0xfa563e38, new_vr=0xfeffd530) at /vol/gcc/src/hg/trunk/local/gcc/vr-values.c:207 #3 0x09e9ca4e in evrp_range_analyzer::record_ranges_from_stmt ( this=0xfeffd690, stmt=0xfa564d50, temporary=false) at /vol/gcc/src/hg/trunk/local/gcc/gimple-ssa-evrp-analyze.c:317 #4 0x096a70e6 in dom_opt_dom_walker::before_dom_children (this=0xfeffd678, bb=0xfa40e708) at /vol/gcc/src/hg/trunk/local/gcc/gimple-iterator.h:213 #5 0x09e7403b in dom_walker::walk (this=0xfeffd678, bb=0xfa40e708) at /vol/gcc/src/hg/trunk/local/gcc/domwalk.c:364 #6 0x096a5121 in (anonymous namespace)::pass_dominator::execute ( this=0xaca8da8, fun=0xfa555138) at /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dom.c:724 #7 0x09461c4e in execute_one_pass (pass=0xaca8da8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2474 #8 0x09462395 in execute_pass_list_1 (pass=0xaca8da8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2560 #9 0x094623a8 in execute_pass_list_1 (pass=0xaca8638, pass@entry=0xaca84f8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2561 #10 0x094623de in execute_pass_list (fn=0xfa555138, pass=0xaca84f8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2571 #11 0x0909d8f5 in cgraph_node::expand (this=0xfa5590d4) at /vol/gcc/src/hg/trunk/local/gcc/context.h:48 #12 0x0909e870 in expand_all_functions () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2332 #13 symbol_table::compile (this=this@entry=0xfa4070d0) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2688 #14 0x090a0db5 in symbol_table::compile (this=0xfa4070d0) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2868 #15 symbol_table::finalize_compilation_unit (this=0xfa4070d0) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2868 #16 0x0954e015 in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:481 #17 0x0955045d in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2190 #18 toplev::main (this=0xfeffd87e, argc=, argv=) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2325 #19 0x09ff89c1 in main (argc=7, argv=0xfeffd8e0) at /vol/gcc/src/hg/trunk/local/gcc/main.c:39 Quite likely caused by one of Richard's tree-vrp.c patches in that rev range.
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 --- Comment #14 from Martin Jambor --- Author: jamborm Date: Fri Jul 26 08:44:51 2019 New Revision: 273825 URL: https://gcc.gnu.org/viewcvs?rev=273825&root=gcc&view=rev Log: [PR 89330] Remove non-useful speculations from new_edges 2019-07-26 Martin Jambor PR ipa/89330 * ipa-inline-transform.c (check_speculations_1): New function. (push_all_edges_in_set_to_vec): Likewise. (check_speculations): Use check_speculations_1, new parameter new_edges. (inline_call): Pass new_edges to check_speculations. * ipa-inline.c (add_new_edges_to_heap): Assert edge_callee is not NULL. (speculation_useful_p): Early return true if edge is inlined, remove later checks for inline_failed. testsuite/ * g++.dg/lto/pr89330_[01].C: New test. * g++.dg/tree-prof/devirt.C: Added -fno-profile-values to dg-options. Added: trunk/gcc/testsuite/g++.dg/lto/pr89330_0.C trunk/gcc/testsuite/g++.dg/lto/pr89330_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-prof/devirt.C
[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242 --- Comment #6 from Jaydeep Chauhan --- (In reply to Martin Liška from comment #5) > (In reply to Jaydeep Chauhan from comment #4) > > Hello, > > > > With latest trunk issue is not reproducible for all three > > case(clastb_1.c,clastb_4.c,clastb_6.c). > > > > Command line options: > > > > gcc/cc1 gcc-10.0/gcc/testsuite/gcc.target/aarch64/sve/clastb_6.c > > -march=armv8.2-a+sve > > > > GCC build options: > > > > COLLECT_GCC=./10_0/prefix/bin/aarch64-windriver-linux-gcc-10.0.0 > > COLLECT_LTO_WRAPPER=/home/bft/Jaydeep/gcc/arm/10_0/prefix/libexec/gcc/ > > aarch64-windriver-linux/10.0.0/lto-wrapper > > Target: aarch64-windriver-linux > > Configured with: /home/bft/Jaydeep/gcc/arm/10_0//gcc-10.0/configure > > --prefix=/home/bft/Jaydeep/gcc/arm/10_0/prefix --build=x86_64-pc-linux > > --host=x86_64-pc-linux --target=aarch64-windriver-linux > > --program-prefix=aarch64-windriver-linux- > > --exec_prefix=/home/bft/Jaydeep/gcc/arm/10_0/prefix --disable-silent-rules > > --disable-dependency-tracking --with-gnu-ld --enable-shared > > --enable-languages=c,c++ --enable-threads=posix --disable-multilib > > --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch > > --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp > > --disable-bootstrap --disable-libmudflap --with-system-zlib > > --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no > > --with-cloog=no --enable-checking=release --enable-cheaders=c_global > > --enable-poison-system-directories --enable-nls --enable-__cxa_atexit > > Thread model: posix > > Supported LTO compression algorithms: zlib > > gcc version 10.0.0 20190725 (experimental) (GCC) > > That's because you use --enable-checking=release. I can reproduce it on > trunk right now with a cross compiler. It's still not reproducible in gcc trunk.Now i also have removed --enable-checking option. Please share build option or step to reproduce issue. GCC build Options: Using built-in specs. COLLECT_GCC=./prefix/bin/aarch64-windriver-linux-gcc COLLECT_LTO_WRAPPER=/home/bft/Jaydeep/gcc/arm/10_0/prefix/libexec/gcc/aarch64-windriver-linux/10.0.0/lto-wrapper Target: aarch64-windriver-linux Configured with: /home/bft/Jaydeep/gcc/arm/10_0//gcc-10.0/configure --prefix=/home/bft/Jaydeep/gcc/arm/10_0/prefix --build=x86_64-pc-linux --host=x86_64-pc-linux --target=aarch64-windriver-linux --program-prefix=aarch64-windriver-linux- --exec_prefix=/home/bft/Jaydeep/gcc/arm/10_0/prefix --enable-languages=c,c++ --disable-libquadmath --disable-libquadmath-support --disable-werror --disable-bootstrap --enable-gold Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.0 20190725 (experimental) (GCC)
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- Created attachment 46628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46628&action=edit preprocessed C source code Here is a preprocessed C source code file which seems to demonstrate the problem. Flag -O3 required. I'll have a go at reducing the code.
[Bug libstdc++/91210] Segmentation fault in random.tcc when compiling GCC 9.1 on linux powerpc(ppc) 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91210 --- Comment #3 from Martin Marko --- Any suggestion to fix/workaround this? Building GCC 8.3 works fine on this machine.
[Bug c++/91210] Segmentation fault in random.tcc when compiling GCC 9.1 on linux powerpc(ppc) 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91210 Jonathan Wakely changed: What|Removed |Added Keywords||build Component|libstdc++ |c++ --- Comment #4 from Jonathan Wakely --- If the compiler crashes it's not a libstdc++ bug.
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #2 from David Binderman ---
Reduced C source code is
a, b;
c(f) {
char *d, *e;
while (d) {
if (f)
if (e)
g();
h(e - (d + a));
b = e - d;
d = i();
}
}
Problem seems to occur between revisions 273750 and 273800.
[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #11 from Florian Weimer --- (In reply to Richard Biener from comment #3) > Hmm, non-equality compares of different objects produce unspecified results, > no? GCC on ELF provides defined address ordering for separate objects via linker ordering and section attributes. I think part of these extensions is that it is possible to check at run time whether an object falls into a specific section, and where. Support for this must be preserved in some fashion.
[Bug ada/91268] New: [10 Regression] adaint.c:38: warning: "_REENTRANT" redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91268 Bug ID: 91268 Summary: [10 Regression] adaint.c:38: warning: "_REENTRANT" redefined Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 /test/gnu/gcc/objdir/./prev-gcc/xg++ -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/bin/ -nostdinc++ -B/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -I/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/prev-hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -mdisable-indexing -Wmissing-format-attribute -Woverloaded-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -Wno-error -DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o ada/adaint.o -MT ada/adaint.o -MMD -MP -MF ada/.deps/adaint.TPo ../../gcc/gcc/ada/adaint.c ../../gcc/gcc/ada/adaint.c:38: warning: "_REENTRANT" redefined 38 | #define _REENTRANT | : note: this is the location of the previous definition cc1plus: all warnings being treated as errors Makefile:1118: recipe for target 'ada/adadecode.o' failed make[3]: *** [ada/adadecode.o] Error 1 Revision 273554 was okay.
[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227 --- Comment #12 from Marc Glisse --- (In reply to Florian Weimer from comment #11) > GCC on ELF provides defined address ordering for separate objects via linker > ordering and section attributes. I think part of these extensions is that > it is possible to check at run time whether an object falls into a specific > section, and where. Support for this must be preserved in some fashion. How about casting to uintptr_t before comparing? It isn't really formalized, but I think that's the extension gcc provides to safely do such comparisons.
[Bug target/89517] [8/9 Regression] AArch64's configure option --with-arch can silently lead to incorrectly configured compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517 --- Comment #4 from Tamar Christina --- Author: tnfchris Date: Fri Jul 26 13:13:48 2019 New Revision: 273827 URL: https://gcc.gnu.org/viewcvs?rev=273827&root=gcc&view=rev Log: AArch64: Make processing less fragile in config.gcc Due to config.gcc all the options need to be on one line because of the grep lines which would select only the first line of the option. This causes it not to select the right bits on options that are spread over multiple lines when the --with-arch configure option is used. The issue happens silently and you just get a compiler with an incorrect set of default flags. The current rules are quite rigid: 1) No space between the AARCH64_OPT_EXTENSION and the opening (. 2) No space between the opening ( and the extension name. 3) No space after the extension name before the ,. 4) Spaces are only allowed after a , and around |. This patch makes this a lot less fragile by using the C pre-processor to flatten the list and then provides much more flexible regex using group matching to process the options instead of string replacement. This removes all the restrictions above and makes the code a bit more readable. gcc/ChangeLog: PR target/89517 * config.gcc: Relax parsing of AARCH64_OPT_EXTENSION. * config/aarch64/aarch64-option-extensions.def: Add new comments and restore easier to read options. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/aarch64/aarch64-option-extensions.def
[Bug middle-end/91242] ICE on aarch64 SVE tests - gcc.target/aarch64/sve/clastb_[146].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242 --- Comment #7 from Steve Ellcey --- (In reply to Martin Liška from comment #5) > (In reply to Jaydeep Chauhan from comment #4) > > Hello, > > > > With latest trunk issue is not reproducible for all three > > case(clastb_1.c,clastb_4.c,clastb_6.c). > > > > Command line options: > > > > gcc/cc1 gcc-10.0/gcc/testsuite/gcc.target/aarch64/sve/clastb_6.c > > -march=armv8.2-a+sve Are you running the test by hand? When I look at the failure in my gcc test run log file I see that it was compiled with -O2 -ftree-vectorize as well as -march=armv8.2-a+sve. I didn't specify those options, they got added on from the dg-options entry in the test program. From my gcc testsuite log file: spawn -ignore SIGHUP /home/sellcey/tot/obj/gcc/gcc/xgcc -B/home/sellcey/tot/obj/gcc/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -march=armv8.2-a+sve -O2 -ftree-vectorize --save-temps -ffat-lto-objects -fno-ident -c -o clastb_1.o /home/sellcey/tot/src/gcc/gcc/testsuite/gcc.target/aarch64/sve/clastb_1.c
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 --- Comment #3 from David Binderman --- Revision 273775 seems ok, so range is now [273775, 273800].
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 --- Comment #4 from David Binderman --- Revision 273788 seems ok, so range is now [273788, 273800].
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #105 from C. Heide ---
It looks like that's already disabled on ia64 in 8.3 (I don't see any .text.hot
or .text.unlikely sections in any executables so far), which has the following:
ia64.c:
> /* Always default to .text section until HP-UX linker is fixed. */
>
> ATTRIBUTE_UNUSED static section *
> ia64_hpux_function_section (tree decl ATTRIBUTE_UNUSED,
> enum node_frequency freq ATTRIBUTE_UNUSED,
> bool startup ATTRIBUTE_UNUSED,
> bool exit ATTRIBUTE_UNUSED)
> {
> return NULL;
> }
hpux.h:
> /* The HP-UX linker has a bug that causes calls from functions in
>.text.unlikely to functions in .text to cause a segfault. Until
>it is fixed, prevent code from being put into .text.unlikely or
>.text.hot. */
>
> #define TARGET_ASM_FUNCTION_SECTION ia64_hpux_function_section
The crash I'm currently stuck at is in stage2 libgcc configuration tests, where
even with a trivial "int main() { return 0; }" source file it produces:
> during RTL pass: mach
> conftest.c: In function 'main':
> conftest.c:4:1: internal compiler error: Segmentation fault
> }
> ^
> 0x4f18c2f crash_signal
> ../../gcc/toplev.c:325
and if I reproduce it with cc1 under GDB, the call stack is:
> Program received signal SIGSEGV, Segmentation fault.
> 0x07519d10 in ?? ()
> (gdb) where
> #0 0x07519d10 in ?? ()
> #1 0x0657fda0 in remove (var=) at
> ../../gcc/var-tracking.c:507
> #2 hash_table::~hash_table (this= out>, __in_chrg=)
> at ../../gcc/hash-table.h:625
> #3 0x0002 in ?? ()
> #4 0x in ?? ()
I've been trying to gather more debug information, but I can't build with -O0
or I get the PCREL21B relocation errors at link, and GDB seems...quirky on
ia64.
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 --- Comment #5 from David Binderman --- Revision 273794 seems broken, so range is now [273788, 273794].
[Bug c++/91265] new breakage for g++.dg/cpp0x/pr82560.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-26 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/91265] new breakage for g++.dg/cpp0x/pr82560.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265 --- Comment #2 from Marek Polacek --- Started with r273791.
[Bug middle-end/91267] [10 regression] SEGV in value_range_base::equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267 --- Comment #6 from David Binderman --- Revision 273791 seems ok, so range is now [273791, 273794]. The culprit seems to be r273792 | rguenth | 2019-07-25 11:25:13 +0100 (Thu, 25 Jul 2019) | 64 lines
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #106 from dave.anglin at bell dot net --- On 2019-07-26 12:25 p.m., cameron.heide at betasystems dot com wrote: >> #1 0x0657fda0 in remove (var=) at >> ../../gcc/var-tracking.c:507 >> #2 hash_table::~hash_table (this=> out>, __in_chrg=) >> at ../../gcc/hash-table.h:625 >> #3 0x0002 in ?? () >> #4 0x in ?? () > I've been trying to gather more debug information, but I can't build with -O0 > or I get the PCREL21B relocation errors at link, and GDB seems...quirky on > ia64. Not surprising... Probably, you can get more info as follows: Run cc1 under gdb and set args. Put a break on var-tracking.c:507. Probably, the fault occurs on first call to remove but this can be checked by running program with ignor set to a large number. When program hits break, disassemble around break with "disass $pc-32,$pc+32". Single step forward. If code branches, disassemble new code. Do this until you hit fault. This should show where/how things go wrong.
[Bug c++/91264] modifying const-qual object in constexpr context not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91264
--- Comment #3 from Marek Polacek ---
Another:
struct X {
int j;
constexpr X() : j(0) { }
};
struct Y {
X x;
constexpr Y() : x{} { }
};
constexpr void
g ()
{
constexpr Y y{};
Y *p = const_cast(&y);
p->x.j = 99;
}
static_assert((g(), 1), "");
I have a patch that handles all the tests in this PR so far.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #107 from C. Heide --- Thanks for the tips; I don't do a lot of assembly-level debugging in GDB. It looks like it fails almost immediately upon entering the remove function: > Breakpoint 1, variable_hasher::remove (var=0x0) at > /build_area_local/ntmake/gcc-8.3.0.ia64/gcc/var-tracking.c:507 > 507 variable_htab_free (var); > (gdb) disass $pc-32,$pc+32 > Dump of assembler code from 0x6d777a1 to 0x6d777e1: >0x06d777a1 : > mov r35=r12 >0x06d777a2 : > adds r12=-16,r12 >0x06d777b0 : [MII] > nop.m 0x0 >0x06d777b1 : > mov r33=b0 >0x06d777b2 : > mov r36=r1;; >0x06d777c0 : [MMB] > st4 [r35]=r32 > => 0x06d777c1 : > ld4 r37=[r35] >0x06d777c2 : > br.call.sptk.many b0=0x7a70e90 >0x06d777d0 : [MII] > mov r1=r36 >0x06d777d1 : > nop.i 0x0;; >0x06d777d2 : > mov.i ar.pfs=r34 >0x06d777e0 : [MII] > nop.m 0x0 > End of assembler dump. > (gdb) stepi > 0x06d777c2 507 variable_htab_free (var); > (gdb) stepi > warning: error while checking for dld breakpoint: Cannot access memory at > address 0x7a70e90 > 0x07a70e90 in ?? () > (gdb) stepi > > Program received signal SIGSEGV, Segmentation fault. > 0x07a70e90 in ?? () where that address in the br.call.sptk.many opcode doesn't correspond to anything valid. If I disassemble the var-tracking.o file used in the build, this block looks like: > <_ZN15variable_hasher6removeEP8variable>: >0: 00 10 19 0a 80 05 [MII] alloc r34=ar.pfs,6,5,0 >6: 30 02 30 00 42 80 mov r35=r12 >c: 01 67 fc 8c adds r12=-16,r12 > 10: 01 00 00 00 01 00 [MII] nop.m 0x0 > 16: 10 02 00 62 00 80 mov r33=b0 > 1c: 04 08 00 84 mov r36=r1;; > 20: 18 00 80 46 90 11 [MMB] st4 [r35]=r32 > 26: 50 02 8c 20 20 00 ld4 r37=[r35] > 2c: 08 00 00 50 br.call.sptk.many b0=20 > <_ZN15variable_hasher6removeEP8variable+0x20> which feels valid? (I know near-zilch about ia64 assembly.) And for comparison this is the raw bytecode for this bundle as seen in the debugger: > (gdb) x/16xb 0x06d777c0 > 0x6d777c0 : 0x180x000x80 > 0x460x900x110x500x02 > 0x6d777c8 : 0x8c0x200x20 > 0x000xd80x960xcf0x50 Is it back to being some kind of linker problem with relocations or such?
[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178
--- Comment #8 from Vsevolod Livinskiy ---
It looks like the fix doesn't handle all of the cases. I still can see similar
bugs on the trunk.
Reproducer:
int a[100][70304];
int b[100];
void c() {
for (int d = 2; d < 4; d++)
for (int e = 2; e <= 50; e++)
for (int f = 32; f <= 38; f++)
b[d + f] -= a[e][5];
}
Error"
>$ gcc -O3 -march=skylake-avx512 repr.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1
GCC version 10.0.0 (revision: 273743)
[Bug testsuite/91258] [10 regression] g++.dg/ubsan/vla-1.C and gcc.dg/strlenopt-70.c fail starting with r273783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91258 --- Comment #6 from seurer at gcc dot gnu.org --- Digging in to the details of the compilation a bit the error occurs when collect2 calls ld as part of lto. There is a lot of differences in the assembler output in the lto stuff before/after r273783. Perhaps you can figure out something from that (diff attached). ++ /usr/bin/ld -v -plugin /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../liblto_plugin.so -plugin-opt=/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../lto-wrapper -plugin-opt=-fresolution=/tmp/cc96yrZX.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -V -m elf64ppc -dynamic-linker /lib64/ld64.so.1 -o ./vla-1.exe /lib/../lib64/crt1.o /lib/../lib64/crti.o /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../crtbegin.o -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libsanitizer/ubsan/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm/.libs -L/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../.. -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libsanitizer -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libsanitizer/ubsan -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libitm -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/cc47HC2I.o -lstdc++ -lm -lubsan -lgcc_s -lgcc -lc -lgcc_s -lgcc /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../crtend.o /lib/../lib64/crtn.o GNU ld version 2.27-34.base.el7 GNU ld version 2.27-34.base.el7 Supported emulations: elf64ppc elf32ppc elf32ppclinux elf32ppcsim elf32_spu In function 'f', inlined from 'main' at /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ubsan/vla-1.C:11:4: /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ubsan/vla-1.C:6:24: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=] I tried a couple different versions of binutils/ld and they all generate the same error. Looking through the verbose output of ld I see nothing useful.
[Bug testsuite/91258] [10 regression] g++.dg/ubsan/vla-1.C and gcc.dg/strlenopt-70.c fail starting with r273783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91258 --- Comment #5 from seurer at gcc dot gnu.org --- Created attachment 46629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46629&action=edit diff of assembler output before and after r273783
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #108 from dave.anglin at bell dot net --- On 2019-07-26 3:13 p.m., cameron.heide at betasystems dot com wrote: >> 2c: 08 00 00 50 br.call.sptk.many b0=20 >> <_ZN15variable_hasher6removeEP8variable+0x20> > which feels valid? (I know near-zilch about ia64 assembly.) And for comparison > this is the raw bytecode for this bundle as seen in the debugger: What's the address of _ZN15variable_hasher6removeEP8variable? If you run "readelf -S var-tracking.o", should be able to find relocation for branch. If you compile var-tracking.c with -save-temps, you will see generated generated assembly code. Compare this branch with others. Most branches would appear to work. It's probably because this routine is c++ code.
[Bug objc/53345] some OPT_Wformat is enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #5 from Eric Gallager --- cc-ing Iain since this is specific to Objective C
[Bug objc/77481] @finally not executed if exception not caught or rethrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77481 Eric Gallager changed: What|Removed |Added CC||mikestump at comcast dot net --- Comment #3 from Eric Gallager --- cc-ing other objc maintainer (i.e. Mike)
[Bug objc/40864] Designated initializers for multi-dimensional arrays fail in Objective-C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #4 from Eric Gallager --- cc-ing objc maintainers
[Bug objc/53943] Compiler ICE with -fobjc-direct-dispatch flag on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53943 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #5 from Eric Gallager --- cc-ing objc maintainers
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #109 from C. Heide --- _ZN15variable_hasher6removeEP8variable is just this same function, located at 0x6d777a0; I didn't realize at first that the objdump disassembly wasn't showing me the actual relocation unless I specify '-r', in which case it's: > 20: 18 00 80 46 90 11 [MMB] st4 [r35]=r32 > 22: PCREL21B.text+0xa780 > 26: 50 02 8c 20 20 00 ld4 r37=[r35] > 2c: 08 00 00 50 br.call.sptk.many b0=20 > <_ZN15variable_hasher6removeEP8variable+0x20> or the relocation section as seen by readelf: > Relocation section > '.rela.gnu.linkonce.t._ZN15variable_hasher6removeEP8variable' at offset > 0x1594b8 contains 1 entry: > Offset InfoTypeSym. Value Symbol's Name + Addend > 0022 0149 R_IA64_PCREL21B .text + a780 and the function at the offset 0xa780 is: > a780 <_ZL18variable_htab_freePv>: > a780: 00 10 21 0a 80 05 [MII] alloc r34=ar.pfs,8,5,0 > a786: 30 02 30 00 42 80 mov r35=r12 > a78c: 01 64 fc 8c adds r12=-64,r12 > a790: 01 00 00 00 01 00 [MII] nop.m 0x0 > a796: 10 02 00 62 00 80 mov r33=b0 > a79c: 04 08 00 84 mov r36=r1;; which is the static function expected, as seen in the source at var-tracking.c:507. So it seems fine within the object file itself, but if I disassemble the final cc1 executable, it's become the invalid address: > 06d777a0 <_ZN15variable_hasher6removeEP8variable>: > 6d777a0: 00 10 19 0a 80 05 [MII] alloc r34=ar.pfs,6,5,0 > 6d777a6: 30 02 30 00 42 80 mov r35=r12 > 6d777ac: 01 67 fc 8c adds r12=-16,r12 > 6d777b0: 01 00 00 00 01 00 [MII] nop.m 0x0 > 6d777b6: 10 02 00 62 00 80 mov r33=b0 > 6d777bc: 04 08 00 84 mov r36=r1;; > 6d777c0: 18 00 80 46 90 11 [MMB] st4 [r35]=r32 > 6d777c6: 50 02 8c 20 20 00 ld4 r37=[r35] > 6d777cc: d8 96 cf 50 br.call.sptk.many > b0=7a70e90 <_etext_f+0xc87090> According to the cc1 symbol table, variable_htab_free should be at 0x5a70e90. Which I just realized is exactly 0x200 off the invalid address...
[Bug libobjc/54720] libobjc install-strip target not populated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 Eric Gallager changed: What|Removed |Added CC||nicola.pero@meta-innovation ||.com, pinskia at gcc dot gnu.org --- Comment #6 from Eric Gallager --- cc-ing libobjc maintainers
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #110 from dave.anglin at bell dot net --- On 2019-07-26 5:36 p.m., cameron.heide at betasystems dot com wrote: >> Relocation section >> '.rela.gnu.linkonce.t._ZN15variable_hasher6removeEP8variable' at offset >> 0x1594b8 contains 1 entry: >> Offset InfoTypeSym. Value Symbol's Name + Addend >> 0022 0149 R_IA64_PCREL21B .text + a780 > and the function at the offset 0xa780 is: >> a780 <_ZL18variable_htab_freePv>: >> a780: 00 10 21 0a 80 05 [MII] alloc r34=ar.pfs,8,5,0 >> a786: 30 02 30 00 42 80 mov r35=r12 >> a78c: 01 64 fc 8c adds r12=-64,r12 >> a790: 01 00 00 00 01 00 [MII] nop.m 0x0 >> a796: 10 02 00 62 00 80 mov r33=b0 >> a79c: 04 08 00 84 mov r36=r1;; > which is the static function expected, as seen in the source at > var-tracking.c:507. So it seems fine within the object file itself, but if I > disassemble the final cc1 executable, it's become the invalid address: >> 06d777a0 <_ZN15variable_hasher6removeEP8variable>: >> 6d777a0: 00 10 19 0a 80 05 [MII] alloc r34=ar.pfs,6,5,0 >> 6d777a6: 30 02 30 00 42 80 mov r35=r12 >> 6d777ac: 01 67 fc 8c adds r12=-16,r12 >> 6d777b0: 01 00 00 00 01 00 [MII] nop.m 0x0 >> 6d777b6: 10 02 00 62 00 80 mov r33=b0 >> 6d777bc: 04 08 00 84 mov r36=r1;; >> 6d777c0: 18 00 80 46 90 11 [MMB] st4 [r35]=r32 >> 6d777c6: 50 02 8c 20 20 00 ld4 r37=[r35] >> 6d777cc: d8 96 cf 50 br.call.sptk.many >> b0=7a70e90 <_etext_f+0xc87090> > According to the cc1 symbol table, variable_htab_free should be at 0x5a70e90. > Which I just realized is exactly 0x200 off the invalid address... Okay, this is problem linkonce sections. I think we need to figure out why ia64_hpux_function_section isn't working. Maybe try return text_section in ia64_hpux_function_section.
[Bug c/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #1 from Sergei Trofimovich --- Created attachment 46630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46630&action=edit bug.c
[Bug c/91269] New: sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
Bug ID: 91269
Summary: sparc64-gcc fails to build glibc (-fcall-used-g6) on
niagara4: Assembler messages: Error: Illegal operands
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
Target Milestone: ---
Original failure happens when glibc is built as:
../glibc/configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=sparc64-unknown-linux-gnu CFLAGS="-O2 -mcpu=niagara4 -pipe" && make
Single file iso-2022-jp-3.c fails to build as:
sparc64-unknown-linux-gnu-gcc iso-2022-jp-3.c -c -std=gnu11 -fgnu89-inline
-O2 -mcpu=niagara4 -pipe -Wall -Wwrite-strings -Wundef -Werror
-fmerge-all-constants -frounding-math -fno-stack-protector -Wstrict-prototypes
-Wold-style-definition -fmath-errno -fcall-used-g6 -Wa,-Av9a -mvis -fPIC
-U_FORTIFY_SOURCE -I../include
-I/home/slyfox/dev/git/glibc-build-sparc64/iconvdata
-I/home/slyfox/dev/git/glibc-build-sparc64
-I../sysdeps/unix/sysv/linux/sparc/sparc64
-I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux/sparc
-I../sysdeps/sparc/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/sparc/sparc64/fpu/multiarch
-I../sysdeps/sparc/sparc64/fpu -I../sysdeps/sparc/sparc64/multiarch
-I../sysdeps/sparc/sparc64 -I../sysdeps/wordsize-64
-I../sysdeps/ieee754/ldbl-128 -I../sysdeps/ieee754/dbl-64/wordsize-64
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/sparc/fpu -I../sysdeps/sparc -I../sysdeps/ieee754
-I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include
/home/slyfox/dev/git/glibc-build-sparc64/libc-modules.h -DMODULE_NAME=iconvdata
-include ../include/libc-symbols.h -DPIC -DSHARED -DTOP_NAMESPACE=glibc -o
/home/slyfox/dev/git/glibc-build-sparc64/iconvdata/iso-2022-jp-3.os -MD -MP -MF
/home/slyfox/dev/git/glibc-build-sparc64/iconvdata/iso-2022-jp-3.os.dt -MT
/home/slyfox/dev/git/glibc-build-sparc64/iconvdata/iso-2022-jp-3.os
{standard input}: Assembler messages:
{standard input}:2619: Error: Illegal operands
Attached self-contained reproducer fails in a similar way:
OK:
$ sparc64-unknown-linux-gnu-gcc -O2 -fno-stack-protector -fcall-used-g6
-mcpu=niagara3 -c bug.c -o bug.o
bug.c: In function 'c':
bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer from
integer without a cast [-Wint-conversion]
13 | cp = b[k];
|^
Bad:
$ sparc64-unknown-linux-gnu-gcc -O2 -fno-stack-protector -fcall-used-g6
-mcpu=niagara4 -c bug.c -o bug.o
bug.c: In function 'c':
bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer from
integer without a cast [-Wint-conversion]
13 | cp = b[k];
|^
/tmp/ccohisfz.s: Assembler messages:
/tmp/ccohisfz.s:145: Error: Illegal operands
$ sparc64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/sparc64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-unknown-linux-gnu/9.1.0/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with:
/tmp/portage-tmpdir/portage/cross-sparc64-unknown-linux-gnu/gcc-9.1.0-r1/work/gcc-9.1.0/configure
--host=x86_64-pc-linux-gnu --target=sparc64-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/sparc64-unknown-linux-gnu/gcc-bin/9.1.0
--includedir=/usr/lib/gcc/sparc64-unknown-linux-gnu/9.1.0/include
--datadir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/9.1.0
--mandir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/9.1.0/man
--infodir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/9.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc64-unknown-linux-gnu/9.1.0/include/g++-v9
--with-python-dir=/share/gcc-data/sparc64-unknown-linux-gnu/9.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.1.0-r1 p1.1' --disable-esp --enable-libstdcxx-time
--with-build-config=bootstrap-lto --enable-poison-system-directories
--with-sysroot=/usr/sparc64-unknown-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.1.0 (Gentoo 9.1.0-r1 p1.1)
[Bug c/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #2 from Sergei Trofimovich --- $ sparc64-unknown-linux-gnu-gcc -O2 -fno-stack-protector -fcall-used-g6 -mcpu=niagara4 -c bug.c -o bug.o bug.c: In function 'c': bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 13 | cp = b[k]; |^ /tmp/cc0K0Ide.s: Assembler messages: /tmp/cc0K0Ide.s:145: Error: Illegal operands
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #3 from Sergei Trofimovich --- $ sparc64-unknown-linux-gnu-gcc -S -O2 -fno-stack-protector -fcall-used-g6 -mcpu=niagara4 -c bug.c -o bug.S bug.c: In function 'c': bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 13 | cp = b[k]; |^ $ sparc64-unknown-linux-gnu-gcc -c -O2 -fno-stack-protector -fcall-used-g6 -mcpu=niagara4 -c bug.S -o bug.o bug.c: Assembler messages: bug.c:145: Error: Illegal operands $ nl -bt bug.S | grep -C3 145 142 cwbe%g0, %g0, .L5 143 .L40: 144 mov %i0, %o0 145 std %f9, [%fp+1999] 146 stx %g4, [%fp+2007] 147 stx %o2, [%fp+2015] 148 callu, 0 Commenting out line '145 std %f9, [%fp+1999]' does not make error disappear. Line numbers are probably skewed.
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #4 from Sergei Trofimovich --- > Commenting out line '145 std %f9, [%fp+1999]' does not make > error disappear. Line numbers are probably skewed. Oh, it's because I used ';' as a comment. Commenting out with '#' makes the error go away. Perhaps 1999 is too large an offset for 'std'.
[Bug c++/85137] [concepts] ICE with undeclared concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85137
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #2 from Arthur O'Dwyer ---
Here's another crash in the same vicinity, probably the same bug.
// https://concepts.godbolt.org/z/DSIz-y
template concept C = true;
template concept D = ;
template struct foo;
template struct foo {};
% g++ -std=c++2a -fconcepts -Dconcept="concept bool"
[...]
internal compiler error: in non_atomic_constraint_p, at cp/logic.cc:321
5 | template struct foo {};
| ^~
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 Matt Turner changed: What|Removed |Added CC||mattst88 at gmail dot com --- Comment #5 from Matt Turner --- With -mcpu=niagara4 and *without* -fcall-used-g6 it compiles fine.
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #6 from Matt Turner --- (In reply to Matt Turner from comment #5) > With -mcpu=niagara4 and *without* -fcall-used-g6 it compiles fine. Also doesn't occur with -O1 or -mno-lra.
[Bug target/91269] sparc64-gcc fails to build glibc (-fcall-used-g6) on niagara4: Assembler messages: Error: Illegal operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269 --- Comment #7 from Matt Turner --- (In reply to Sergei Trofimovich from comment #4) > > Commenting out line '145 std %f9, [%fp+1999]' does not make > > error disappear. Line numbers are probably skewed. > > Perhaps 1999 is too large an offset for 'std'. Sergei noticed that 'std' must take an even numbered register, so s/f9/f8/ on that line causes it to assemble.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #111 from C. Heide ---
(In reply to dave.anglin from comment #110)
> Okay, this is problem linkonce sections. I think we need to figure out why
> ia64_hpux_function_section
> isn't working. Maybe try return text_section in ia64_hpux_function_section.
I gave that a try (just "return text_section;" in there) but it looks like
something is still generating linkonce sections:
Output (during compile of eh_alloc.cc):
> /var/tmp//ccOX5Jzg.s: Assembler messages:
> /var/tmp//ccOX5Jzg.s:8406: Error: can't resolve `.text' {.text section} -
> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
> /var/tmp//ccOX5Jzg.s:8407: Error: can't resolve `.text' {.text section} -
> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
> /var/tmp//ccOX5Jzg.s:8411: Error: can't resolve `.text' {.text section} -
> `.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev' {*UND* section}
Generated assembly:
> .file "eh_alloc.cc"
> .pred.safe_across_calls p1-p5,p16-p63
> .section.text, "ax", "progbits"
> .Ltext0:
> .section
> .gnu.linkonce.r._ZNK9__gnu_cxx24__concurrence_lock_error4whatEv.str1.8,"aMS",@progbits,1
> .align 8
> .LC1:
> stringz "__gnu_cxx::__concurrence_lock_error"
> .section.text, "ax", "progbits"
> .align 16
> .weak _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
> .proc _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv#
> _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv:
> etc...
though I think the error is referring specifically to these (debug?) entries
later on:
> .LLST0:
> data4.ua
> .LVL6-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
> data4.ua
> .LVL7-.gnu.linkonce.t._ZN9__gnu_cxx24__concurrence_lock_errorD0Ev#
> data2.ua0x2
> data1 0x90
