[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743 --- Comment #5 from Gary Funck --- (In reply to Eric Gallager from comment #4) > Any plans to resubmit the GUPC branch again? Eric, no not at this time. Thanks.
[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 --- Comment #10 from Gary Funck --- Thanks. Works for me.
[Bug sanitizer/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 --- Comment #1 from Gary Funck --- (In reply to Gary Funck from comment #0) > See also PR 70683. > > When the attached test case is compiled with -O3 and gcc checks are enabled, > the following ICE is triggered. > > It looks like this check was added by trunk revision r23546. Edit: that should be trunk revision 235469.
[Bug sanitizer/71872] New: ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71872 Bug ID: 71872 Summary: ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 38895 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38895=edit Non-reduced, pre-processed, test case for ICE in inchash::add_expr See also PR 70683. When the attached test case is compiled with -O3 and gcc checks are enabled, the following ICE is triggered. It looks like this check was added by trunk revision r23546. ice-hash-expr.i: In function ‘main’: ice-hash-expr.i:300:1: internal compiler error: in add_expr, at tree.c:7782 main () ^~~~ 0xde5865 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:7782 0xde65d3 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:7997 0xba4406 iterative_hash_expr /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.h:4786 0xba4406 innermost_loop_behavior_hash::hash(innermost_loop_behavior* const&) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:150 0xba4406 simple_hashmap_traits<default_hash_traits, data_reference*>::hash(innermost_loop_behavior* const&) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-map-traits.h:48 0xba4406 hash_map<innermost_loop_behavior_hash, data_reference*, simple_hashmap_traits<default_hash_traits, data_reference*> >::get_or_insert(innermost_loop_behavior* const&, bool*) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-map.h:161 0xba4406 hash_memrefs_baserefs_and_store_DRs_read_written_info /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:693 0xba4406 if_convertible_loop_p_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:1410 0xba4406 if_convertible_loop_p /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:1490 0xba6e41 tree_if_conversion /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:2647 0xba6e41 execute /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:2749 The offending tree expression looks like this: unit size align 32 symtab 0 alias set -1 canonical type 0x7fffefe0c888 precision 32 min max context pointer_to_this > public unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7fffefe2d930> constant arg 0 constant 1>> The assertion check is at line 7782. identity. */ 7778case VOID_CST: 7779 hstate.merge_hash (0); 7780 return; 7781case INTEGER_CST: 7782 gcc_checking_assert (!(flags & OEP_ADDRESS_OF)); 7783 for (i = 0; i < TREE_INT_CST_EXT_NUNITS (t); i++) 7784hstate.add_wide_int (TREE_INT_CST_ELT (t, i)); 7785 return; 7786case REAL_CST:
[Bug c/71787] #pragma GCC diagnostic unexpectedly terminates a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71787 --- Comment #2 from Gary Funck --- Manuel, thanks for the quick follow up.
[Bug c/71787] New: #pragma GCC diagnostic unexpectedly terminates a statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71787
Bug ID: 71787
Summary: #pragma GCC diagnostic unexpectedly terminates a
statement
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This bug may be related to PR41517.
Consider the following program:
#define NULL ((void *)0)
typedef enum {GET, SET} op_t;
extern void abort ();
void
get_set (op_t op,
int *ref,
int value __attribute__ ((unused)),
int *fetch)
{
int orig_value;
switch (op)
{
case GET:
orig_value = *ref;
break;
case SET:
if (fetch)
orig_value = *ref;
*ref = value;
break;
}
if (fetch)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
*fetch = orig_value;
#pragma GCC diagnostic pop
}
int
main ()
{
int v = 0;
int value;
get_set (GET, , 1, );
get_set (SET, , 10, );
get_set (SET, , 20, NULL);
}
When compiled and executed, it segfaults because the diagnostic push statement
is being handled as if it were a semi-colon.
If the sequence of statements above is changed to:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
if (fetch)
*fetch = orig_value;
#pragma GCC diagnostic pop
It executes as expected.
This is either a bug, or it would be helpful if the documentation is updated to
describe this behavior.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 Gary Funck changed: What|Removed |Added CC||gary at intrepid dot com --- Comment #11 from Gary Funck --- Might be a duplicate of a bug I reported, PR69036
[Bug middle-end/69026] dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69026 --- Comment #1 from Gary Funck --- This can be most easily reproduced by doing a regular configure and make, then cd-ing into the gcc build directory and forcing a re-compilation of dwarf2out.c at -O3. cd bld/gcc rm dwarf2out.o make CXXFLAGS='-O3 -g' dwarf2out.o [...] /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function ‘addr_table_entry* add_addr_table_entry(void*, ate_kind)’: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4295:41: error: ‘finder.addr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ may be used uninitialized in this function [-Werror=maybe-uninitialized] inchash::add_rtx (a->addr.rtl, hstate); ^ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4345:20: note: ‘finder.addr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ was declared here addr_table_entry finder; ^~
[Bug middle-end/69025] df-scan.c:2536 warning: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69025 --- Comment #1 from Gary Funck --- This can be most easily reproduced by doing a regular configure and make, then cd-ing into the gcc build directory and forcing a re-compilation of df-scan.c at -O3. cd bld/gcc rm df-scan.o make CXXFLAGS='-O3 -g' df-scan.o [...] In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/target.h:53:0, from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c: In function ‘void df_ref_record(df_ref_class, df_collection_rec*, rtx, rtx_def**, basic_block, df_insn_info*, df_ref_type, int)’: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hard-reg-set.h:156:44: error: array subscript is above array bounds [-Werror=array-bounds] (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT] \ ~^ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:2536:18: note: in expansion of macro ‘TEST_HARD_REG_BIT’ else if (!(TEST_HARD_REG_BIT (elim_reg_set, regno) ^ cc1plus: all warnings being treated as errors
[Bug tree-optimization/69036] New: g++ hangs compiling tree-ssa-loop-ivopts.c at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69036 Bug ID: 69036 Summary: g++ hangs compiling tree-ssa-loop-ivopts.c at -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com Target Milestone: --- While trying to build and bootstrap GCC at -O3 (using --with-build-config=bootstrap-O3) on an x86-64, the compiler hangs in the final stage while trying to build tree-ssa-loop-ivopts.o. As shown below, the failure can be triggered by doing a regular bootstrap build and then forcing the compilation of tree-ssa-loop-ivopts.c at -O3. Interestingly, it does not replicate _unless_ the compiler is fully bootstrap, which may indicate there is an issue with GCC (prev-gcc) compiling itself. Also, when the compiler hangs, it appears that its memory requirement steadily climbs over time. The first failing version appears to be this one: r231674 | rguenth | 2015-12-16 01:21:04 -0800 (Wed, 16 Dec 2015) | 8 lines 2015-12-16 Richard Biener <rguent...@suse.de> PR tree-optimization/68892 * tree-vect-slp.c (vect_analyze_slp_cost_1): Properly compute cost for permuted loads. * gcc.dg/vect/bb-slp-pr68892.c: New testcase. Steps to reproduce. 1. Standard configure and make. (cd ./src; svn up -q -r231674) src=`cd src; pwd` rm -rf bld mkdir bld cd bld $src/configure nj=`getconf _NPROCESSORS_ONLN` make -j$nj >& make.log 2. cd into gcc build directory and attempt to remake tree-ssa-loop-ivopts.o at -O3. cd gcc rm tree-ssa-loop-ivopts.o make CXXFLAGS='-O3 -g' tree-ssa-loop-ivopts.o [compiler hangs]
[Bug middle-end/69026] New: dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69026 Bug ID: 69026 Summary: dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com Target Milestone: --- This showed up as a bootstrap failure when CFLAGS='-O3' because when the final stage compiler is compiled with prev-gcc -Werror is asserted. /eng/upc/dev/gary/gupc-gcc-trunk/build/obj/./prev-gcc/xg++ -B/eng/upc/dev/gary/ gupc-gcc-trunk/build/obj/./prev-gcc/ -B/eng/upc/dev/gary/gupc-gcc-trunk/install /x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-gcc-trunk/build/ obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-gc c-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/eng /upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/in clude/x86_64-pc-linux-gnu -I/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x8 6_64-pc-linux-gnu/libstdc++-v3/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/ libstdc++-v3/libsupc++ -L/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64 -pc-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/gary/gupc-gcc-trunk/build/o bj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -O3 -g - gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-a ttribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wn o-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/eng/upc/de v/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/e ng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc- trunk/src/gcc/../libcpp/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../ libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I. ./libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo /eng/upc/dev/gar y/gupc-gcc-trunk/src/gcc/dwarf2out.c /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function ‘addr_table_e ntry* add_addr_table_entry(void*, ate_kind)’: eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function ‘addr_table_e ntry* add_addr_table_entry(void*, ate_kind)’: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4295:41: error: ‘finder.ad dr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ ma y be used uninitialized in this function [-Werror=maybe-uninitialized] inchash::add_rtx (a->addr.rtl, hstate); ^ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4345:20: note: ‘finder.add r_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’ was declared here addr_table_entry finder; ^~
[Bug middle-end/69025] New: df-scan.c:2536 warning: array su bscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69025 Bug ID: 69025 Summary: df-scan.c:2536 warning: array su bscript is above array bounds Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com Target Milestone: --- This showed up as bootstrap failure when building with CFLAGS='-O3', because when the stage2 compiler is compiled at -O3 using prev-gcc -Werror is asserted in the warning flags. Here's the error/warning. /eng/upc/dev/gary/gupc-gcc-trunk/build/obj/./prev-gcc/xg++ -B/eng/upc/dev/gary/ gupc-gcc-trunk/build/obj/./prev-gcc/ -B/eng/upc/dev/gary/gupc-gcc-trunk/install /x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-gcc-trunk/build/ obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-gc c-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/eng /upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/in clude/x86_64-pc-linux-gnu -I/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x8 6_64-pc-linux-gnu/libstdc++-v3/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/ libstdc++-v3/libsupc++ -L/eng/upc/dev/gary/gupc-gcc-trunk/build/obj/prev-x86_64 -pc-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/gary/gupc-gcc-trunk/build/o bj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -O3 -g - gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-a ttribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wn o-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/eng/upc/de v/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/e ng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc- trunk/src/gcc/../libcpp/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../ libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I. ./libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace -o df-scan.o -MT df-scan.o -MMD -MP -MF ./.deps/df-scan.TPo /eng/upc/dev/gary/gupc -gcc-trunk/src/gcc/df-scan.c In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/target.h:53:0, from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28: 1,1 Top from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c: In function ‘void df_ref_re cord(df_ref_class, df_collection_rec*, rtx, rtx_def**, basic_block, df_insn_inf o*, df_ref_type, int)’: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hard-reg-set.h:156:44: error: array su bscript is above array bounds [-Werror=array-bounds] (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT] \ ~^ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:2536:18: note: in expansion of macro ‘TEST_HARD_REG_BIT’ else if (!(TEST_HARD_REG_BIT (elim_reg_set, regno) ^
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #38 from Gary Funck --- (In reply to Richard Biener from comment #37) > > Does the following help on r230428 or newer? > > Index: gcc/tree-ssa.c > === > --- gcc/tree-ssa.c (revision 230428) > +++ gcc/tree-ssa.c (working copy) > @@ -1126,6 +1145,9 @@ delete_tree_ssa (struct function *fn) >fn->gimple_df->decls_to_pointers = NULL; >fn->gimple_df->modified_noreturn_calls = NULL; >fn->gimple_df = NULL; > + > + /* We no longer need the edge variable maps. */ > + redirect_edge_var_map_destroy (); > } > > /* Return true if EXPR is a useless type conversion, otherwise return Yes, was able to do a full bootstrap at -O3 of all languages.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #34 from Gary Funck --- (In reply to Richard Biener from comment #33) > Can you try the patch attached to comment #29? That seemed to fix the issue in 32/libgfortran, though I haven't tried a build from scratch yet. Regarding the patch, in cfgexpand.c, I had to change the call to redirect_edge_var_map_empty() (was: redirect_edge_var_map_destroy). Note there is no ggc_collect() call there, it appears in other places in the patch.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #36 from Gary Funck --- (In reply to rguent...@suse.de from comment #35) > Yes, I thought the cfgexpand.c place is a better one and the only one > that would be related to the place where I removed the old > redirect_edge_var_map_destroy call. > > Hmm. Maybe not for functions removed by cgraph code. > > Does > [... patch ..] > help? (without the comment #29 patch) > > Does the patch in comment #25 help? It is getting a bit confusing. Can you post a single patch to a given trunk reviiosn?
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #32 from Gary Funck --- (In reply to Gary Funck from comment #17) > We're seeing this ICE on x86-64, while building the 32-bit libgfortran. > We're building the target libraries with -O3 with GCC compiler checks > enabled. The recent r230424 commit did *not* fix this regression. Note that we're building with CFLAGS_FOR_TARGET='-O3 -g'.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #18 from Gary Funck --- (In reply to Gary Funck from comment #17) > We're seeing this ICE on x86-64, while building the 32-bit libgfortran. > We're building the target libraries with -O3 with GCC compiler checks > enabled. Taking garbage collection out of the picture by adding --param ggc-min-heapsize=10 to the command line led to a successful compilation.
[Bug rtl-optimization/68269] [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269 Gary Funck changed: What|Removed |Added CC||gary at intrepid dot com --- Comment #2 from Gary Funck --- We're seeing a similar failure (on IA64) while trying to build the compiler, at -O3 (--with-build-config=bootstrap-O3). /eng/upc/dev/gary/gupc-dev/bld/gupc/./prev-gcc/xg++ -B/eng/upc/dev/gary/gupc-de v/bld/gupc/./prev-gcc/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/ia64-unknown-linux -gnu/bin/ -nostdinc++ -B/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-l inux-gnu/libstdc++-v3/src/.libs -B/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64 -unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/eng/upc/dev/gary/gupc-dev/b ld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v3/include/ia64-unknown-linux-gnu -I/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v 3/include -I/eng/upc/dev/gary/gupc-dev/src/gupc/libstdc++-v3/libsupc++ -L/eng/ upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++-v3/src/.li bs -L/eng/upc/dev/gary/gupc-dev/bld/gupc/prev-ia64-unknown-linux-gnu/libstdc++- v3/libsupc++/.libs -c -DUSE_LIBUNWIND_EXCEPTIONS -O3 -g -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloade d-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/eng/upc/ dev/gary/gupc-dev/src/gupc/gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/build -I/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/../include -I/eng/upc/dev/gary/gupc- dev/src/gupc/gcc/../libcpp/include \ -o build/genmodes.o /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/gen modes.c /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/genmodes.c: In function 'void calc_wide r_mode()': /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/genmodes.c:895:1: internal compiler err or: in decompose, at rtl.h:2107 } ^ 0x4122b73f wi::int_traits<std::pair<rtx_def*, machine_mode> >::decompos e(long*, unsigned int, std::pair<rtx_def*, machine_mode> const&) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/rtl.h:2105 0x4122b73f wi::int_traits<std::pair<rtx_def*, machine_mode> >::decompos e(long*, unsigned int, std::pair<rtx_def*, machine_mode> const&) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/rtl.h:2105 0x4200166f simplify_const_binary_operation(rtx_code, machine_mode, rtx_ def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:3955 0x41fe42cf simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:1990 0x41ffc99f simplify_const_binary_operation(rtx_code, machine_mode, rtx_ def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:3764 0x41fe42cf simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/simplify-rtx.c:1990 0x4330d2ef fold_rtx /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:3730 0x43314b6f cse_insn /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:4632 0x433285cf cse_extended_basic_block /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:6528 0x43329a6f cse_main /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:6702 0x43330e3f rest_of_handle_cse /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:7522 0x4333122f execute /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/cse.c:7565
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #19 from Gary Funck --- We see similar failure an x86-64 opensuse VM in the 32-bit libgfortran build but on a different file: eoshift.c. After removing the .lo and .o files and re-running make, the build completed without error. As described in earlier comments, this issue is not easily reproducible.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #17 from Gary Funck --- We're seeing this ICE on x86-64, while building the 32-bit libgfortran. We're building the target libraries with -O3 with GCC compiler checks enabled. libtool: compile: /eng/upc/dev/gary/gupc-dev/bld/gupc/./gcc/xgcc -B/eng/upc/de v/gary/gupc-dev/bld/gupc/./gcc/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc -linux-gnu/bin/ -B/eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/lib/ -isystem /eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/include -isyst em /eng/upc/dev/gary/gupc-dev/rls/gupc/x86_64-pc-linux-gnu/sys-include -DHAVE_C ONFIG_H -I. -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran -iquote/eng/upc/d ev/gary/gupc-dev/src/gupc/libgfortran/io -I/eng/upc/dev/gary/gupc-dev/src/gupc/ libgfortran/../gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../gcc/con fig -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libquadmath -I../../.. /./gcc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libgcc -I../../libg cc -I/eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/../libbacktrace -I../../li bbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-pro totypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-functio n-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-section s -g3 -O3 -m32 -MT write.lo -MD -MP -MF .deps/write.Tpo -c /eng/upc/dev/gary/gu pc-dev/src/gupc/libgfortran/io/write.c -o write.o >/dev/null 2>&1 make[6]: *** [write.lo] Error 1 make[6]: Leaving directory `/eng/upc/dev/gary/gupc-dev/bld/gupc/x86_64-pc-linux -gnu/32/libgfortran' Above, that make step sends output /dev/null. Running the same command by hand, yields: /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c: In function ‘write_a’: /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c:232:1: error: invalid PHI argument write_a (st_parameter_dt *dtp, const fnode *f, const char *source, int len) ^ <<< Unknown tree: >>> /eng/upc/dev/gary/gupc-dev/src/gupc/libgfortran/io/write.c:232:1: internal compiler error: tree check: expected tree that contains ‘typed’ structure, have ‘’ in verify_gimple_phi, at tree-cfg.c:4658 0xe4fbe4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.c:9839 0xbf13bc contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.h:3173 0xbf13bc verify_gimple_phi /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree-cfg.c:4658 0xbf13bc verify_gimple_in_cfg(function*, bool) /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree-cfg.c:4952 0xab36f7 execute_function_todo /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:1945 0xab4b7a do_per_function /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:1632 0xab4b7a execute_todo /eng/upc/dev/gary/gupc-dev/src/gupc/gcc/passes.c:2000
[Bug libgcc/67792] GCC 5.2 - make clean fails in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67792 --- Comment #2 from Gary Funck --- (In reply to Andreas Schwab from comment #1) > Nobody is testing make clean, patches welcome. It's much easier to just > remove the build directory before starting over. OK. I don't plan on looking into it. It didn't fail on a recent trunk version, so probably it is fixed there.
[Bug libgcc/67792] New: GCC 5.2 - make clean fails in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67792 Bug ID: 67792 Summary: GCC 5.2 - make clean fails in libgcc Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com Target Milestone: --- When building with both the GCC 5.2 release and the latest gcc-5-branch, after a successful build and bootstrap, a 'make clean' at the top level fails as follows. make[1]: Leaving directory `/eng/upc/dev/gary/gcc-5-x/save/x86_64-unknown-linux -gnu/libstdc++-v3' make[1]: -B/eng/upc/dev/gary/gcc-5-x/rls/x86_64-unknown-linux-gnu/bin/: Command not found make[1]: Entering directory `/eng/upc/dev/gary/gcc-5-x/save/x86_64-unknown-linu x-gnu/libgcc' make[1]: -B/eng/upc/dev/gary/gcc-5-x/rls/x86_64-unknown-linux-gnu/bin/: Command not found /bin/sh: line 0: test: !=: unary operator expected rm -f libgcc_tm.h libgcc.map Makefile:172: *** Recursive variable `AR_FOR_TARGET' references itself (eventua lly). Stop. Above, the compiler has not yet been installed under 'rls/...', and therefore is not found. It wasn't clear to me why AR_FOR_TARGET is recursive: 170 # Flags to pass to recursive makes. 171 172 AR_FOR_TARGET = $(AR) Top-level configure: /eng/upc/dev/gary/gcc-5-x/src/configure CFLAGS='-g3 -O3' CXXFLAGS='-g3 -O3' CC= /usr/bin/gcc CXX=/usr/bin/g++ --prefix=/eng/upc/dev/gary/gcc-5-x/rls --enable-l anguages=all
[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341 --- Comment #3 from Gary Funck gary at intrepid dot com --- (In reply to Marek Polacek from comment #2) Gary, could you please try this again? I'd hope this has really been fixed with my recentish Go patch. Confirmed - fixed.
[Bug middle-end/67341] New: [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341
Bug ID: 67341
Summary: [ICE] libgo build failure: in
mark_stmt_if_obviously_necessary, at
tree-ssa-dce.c:278
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
A change made to the trunk within the past week/so (trunk version greater than
227110) triggers this ICE. Full bootstrap, release checks, CFLAGS='-O3'.
libtool: compile: /eng/upc/dev/gary/gupc-merge/bld/packed-opt/./gcc/gccgo
-B/eng/upc/dev/gary/gu
pc-merge/bld/packed-opt/./gcc/
-B/eng/upc/dev/gary/gupc-merge/rls/packed-opt/x86_64-pc-linux-gnu/
bin/ -B/eng/upc/dev/gary/gupc-merge/rls/packed-opt/x86_64-pc-linux-gnu/lib/
-isystem /eng/upc/dev
/gary/gupc-merge/rls/packed-opt/x86_64-pc-linux-gnu/include -isystem
/eng/upc/dev/gary/gupc-merge
/rls/packed-opt/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g
-I . -c -fgo-pkgpat
h=encoding/gob
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/decode.go
/eng/upc/dev
/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/decoder.go
/eng/upc/dev/gary/gupc-merge/src/gupc/
libgo/go/encoding/gob/dec_helpers.go
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/
doc.go /eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/encode.go
/eng/upc/dev/gary/gu
pc-merge/src/gupc/libgo/go/encoding/gob/encoder.go
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go
/encoding/gob/enc_helpers.go
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/error.go
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/type.go -fPIC -o
encoding/.libs/gob
.o
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/decode.go: In
function ‘gob.decIgnoreOpFor.pN20_encoding_gob.Decoder’:
/eng/upc/dev/gary/gupc-merge/src/gupc/libgo/go/encoding/gob/decode.go:843:1:
internal compiler error: in mark_stmt_if_obviously_necessary, at
tree-ssa-dce.c:278
func (dec *Decoder) decIgnoreOpFor(wireId typeId) decOp {
^
0xa80fab mark_stmt_if_obviously_necessary
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/tree-ssa-dce.c:278
0xa80fab find_obviously_necessary_stmts
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/tree-ssa-dce.c:397
0xa80fab perform_tree_ssa_dce
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/tree-ssa-dce.c:1635
[Bug go/67101] New: mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67101 Bug ID: 67101 Summary: mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address] Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: gary at intrepid dot com CC: cmang at google dot com Target Milestone: --- For a full bootstrap build, we also build Go and Fortran. In today's merge with trunk, the bootstrap failed, due to this error. /eng/upc/dev/gary/gupc-merge/src/gupc/libgo/runtime/mprof.goc: In function ‘runtime_Stack’: /eng/upc/dev/gary/gupc-merge/src/gupc/libgo/runtime/mprof.goc:408:5: error: calling ‘__builtin_frame_address’ with a nonzero argument is unsafe [-Werror=frame-address] sp = runtime_getcallersp(b); ^ cc1: all warnings being treated as errors make[4]: *** [mprof.lo] Error 1 make[4]: Leaving directory `/eng/upc/dev/gary/gupc-merge/bld/packed-opt/x86_64-pc-linux-gnu/libgo' This is likely triggered by the addition of -Wframe-address. 2015-08-02 Martin Sebor mse...@redhat.com * c-family/c.opt (-Wframe-address): New warning option. * doc/invoke.texi (Wframe-address): Document it. * doc/extend.texi (__builtin_frame_address, __builtin_return_address): Clarify possible effects of calling the functions with non-zero arguments and mention -Wframe-address. * builtins.c (expand_builtin_frame_address): Handle -Wframe-address.
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #49 from Gary Funck gary at intrepid dot com --- (In reply to Alexandre Oliva from comment #48) The errors reported in comments 44, 45, 46, and 47 are fixed in the git branch aoliva/pr64164. I'm giving it all some more testing before posting an updated, consolidated patch. I applied your patch (commit 9357ff1, 8/2/15) to our GUPC branch, based off trunk version 226386 on gcc112 (PPC64LE). It bootstrapped fine and passed the tests with -O0 --enable-checking and -O3 --disable-checking.
[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000 --- Comment #4 from Gary Funck gary at intrepid dot com --- (In reply to Alexandre Oliva from comment #3) The problem initially reported in this bug is now fixed in the git branch aoliva/pr64164. I'm not sure how to go about duplicating the one in comment 1, but, having fixed a number of additional split_complex issues since the patch that caused the problems was put in, I hope it's fixed too. Gary, would you please detail the toplevel configure and build command lines to trigger it, or perhaps give the branch a try and confirm that it fixes the problem? Thanks, Alexandre, The configuration command was along these lines: configure CFLAGS='-g3 -O0' CXXFLAGS='-g3 -O0' TARGET_CFLAGS='-g3 -O0' TARGET_CXXFLAGS='-g3 -O0' --enable-bootstrap=no --enable-checking=yes --enable-languages=c,c++ --disable-build-format-warnings PS: the issue did go away when merged with a later svn trunk version, consistent with Richard's comment #2.
[Bug target/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 Gary Funck gary at intrepid dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Gary Funck gary at intrepid dot com --- Confirmed: the patch resolved the bootstrap issue at -O3 with checks disabled.
[Bug target/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 Gary Funck gary at intrepid dot com changed: What|Removed |Added CC||segher at gcc dot gnu.org Component|rtl-optimization|target --- Comment #2 from Gary Funck gary at intrepid dot com --- Regression hunt indicates that following patch, intended to fix PR target/66217, likely caused the regression described above. Author: segher Date: Mon Jul 20 16:30:56 2015 New Revision: 226005 URL: https://gcc.gnu.org/viewcvs?rev=226005root=gccview=rev Log: PR target/66217 * config/rs6000/constraints.md (S, T, t): Delete. Update available letters comment. * config/rs6000/predicates.md (mask_operand, mask_operand_wrap, mask64_operand, mask64_2_operand, any_mask_operand, and64_2_operand, and_2rld_operand): Delete. (and_operand): Adjust. (rotate_mask_operator): New. * config/rs6000/rs6000-protos.h (build_mask64_2_operands, includes_lshift_p, includes_rshift_p, includes_rldic_lshift_p, includes_rldicr_lshift_p, insvdi_rshift_rlwimi_p, extract_MB, extract_ME): Delete. (rs6000_is_valid_mask, rs6000_is_valid_and_mask, rs6000_is_valid_shift_mask, rs6000_is_valid_insert_mask, rs6000_insn_for_and_mask, rs6000_insn_for_shift_mask, rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and, rs6000_emit_2insn_and): New. * config/rs6000/rs6000.c (num_insns_constant): Adjust. (build_mask64_2_operands, includes_lshift_p, includes_rshift_p, includes_rldic_lshift_p, includes_rldicr_lshift_p, insvdi_rshift_rlwimi_p, extract_MB, extract_ME): Delete. (rs6000_is_valid_mask, rs6000_is_valid_and_mask, rs6000_insn_for_and_mask, rs6000_is_valid_shift_mask, s6000_insn_for_shift_mask, rs6000_is_valid_insert_mask, rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and, rs6000_emit_2insn_and): New. (print_operand) 'b', 'B', 'm', 'M', 's', 'S', 'W': Delete. (rs6000_rtx_costs) CONST_INT: Delete mask_operand and mask64_operand handling. NOT: Don't fall through to next case. AND: Handle the various rotate-and-mask cases directly. IOR: Always cost as one insn. * config/rs6000/rs6000.md (splitter for bswap:SI): Adjust. (andmode3): Adjust expander for the new patterns. (andmode3_imm, andmode3_imm_dot, andmode3_imm_dot2, andmode3_imm_mask_dot, andmode3_imm_mask_dot2): Adjust condition. (*andmode3_imm_dot_shifted): New. (*andmode3_mask): Delete, rewrite as ... (andmode3_mask): ... New. (*andmode3_mask_dot, *andmode3_mask_dot): Rewrite. (andsi3_internal0_nomc): Delete. (*andsi3_internal6): Delete. (*andmode3_2insn): New. (insv, insvsi_internal, *insvsi_internal1, *insvsi_internal2, *insvsi_internal3, *insvsi_internal4, *insvsi_internal5, *insvsi_internal6, insvdi_internal, *insvdi_internal2, *insvdi_internal3): Delete. (*rotlmode3_mask, *rotlmode3_mask_dot, *rotlmode3_mask_dot2, *rotlmode3_insert, *rotlmode3_insert_2, *rotlmode3_insert_3, *rotlmode3_insert_4, two splitters for multi-precision shifts, *iormode_mask): New. (extzv, extzvdi_internal, *extzvdi_internal1, *extzvdi_internal2, *rotlsi3_mask, *rotlsi3_mask_dot, *rotlsi3_mask_dot2, *ashlsi3_imm_mask, *ashlsi3_imm_mask_dot, *ashlsi3_imm_mask_dot2, *lshrsi3_imm_mask, *lshrsi3_imm_mask_dot, *lshrsi3_imm_mask_dot2): Delete. (ashrmode3): Delete expander. (*ashrmode3): Rename to ... (ashrmode3): ... This. (ashrdi3_no_power, *ashrdisi3_noppc64be): Delete. (*rotldi3_internal4, *rotldi3_internal5 and split, *rotldi3_internal6 and split, *ashldi3_internal4, ashldi3_internal5 and split, *ashldi3_internal6 and split, *ashldi3_internal7, ashldi3_internal8 and split, *ashldi3_internal9 and split): Delete. (*anddi3_2rld, *anddi3_2rld_dot, *anddi3_2rld_dot2): Delete. (splitter for loading a mask): Adjust. * doc/md.texi (Machine Constraints): Remove q, S, T, t constraints. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/constraints.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md trunk/gcc/doc/md.texi
[Bug rtl-optimization/67045] New: [ICE][PPCLE64] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045
Bug ID: 67045
Summary: [ICE][PPCLE64] internal compiler error: in
choose_multiplier, at expmed.c:3373
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This issue may be related to bug #61047; it refers to a fix made on July 1, and
the regression described below seems to have appeared in the last month/so.
When bootstrapping trunk version 226240, using TARGET_CFLAGS='-O3' we see the
following bootstrap failure on PPCLE64 (gcc112).
/home/gfunck/gcc-trunk/bld/./gcc/xgcc -B/home/gfunck/gcc-trunk/bld/./gcc/
-B/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/bin/
-B/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/include -isystem
/home/gfunck/gcc-trunk/rls/powerpc64le-unknown-linux-gnu/sys-include-O2 -g3
-O3 -O2 -O2 -g3 -O3 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc
-I/home/gfunck/gcc-trunk/src/libgcc -I/home/gfunck/gcc-trunk/src/libgcc/.
-I/home/gfunck/gcc-trunk/src/libgcc/../gcc
-I/home/gfunck/gcc-trunk/src/libgcc/../include
-I/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/dpd
-I/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber -DHAVE_CC_TLS -o
decDouble.o -MT decDouble.o -MD -MP -MF decDouble.dep -c
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c
In file included from
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.h:68:0,
from
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c:33:
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decBasic.c: In function
‘__decDoubleFromInt32’:
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDoubleSymbols.h:24:28:
internal compiler error: in choose_multiplier, at expmed.c:3373
#define decDoubleFromInt32 __decDoubleFromInt32
^
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decDouble.c:58:30: note: in
expansion of macro ‘decDoubleFromInt32’
#define decFloatFromInt32decDoubleFromInt32
^
/home/gfunck/gcc-trunk/src/libgcc/../libdecnumber/decBasic.c:2284:12: note: in
expansion of macro ‘decFloatFromInt32’
decFloat * decFloatFromInt32(decFloat *result, Int n) {
^
As background, one of our builds sets CFLAGS and TARGET_CFLAGS to '-O3', rather
than the default '-O2' for TARGET_CFLAGS. Further checks are set to
'--enable-checking=release'. The config options used were:
CFLAGS='-g3 -O3' \
CXXFLAGS='-g3 -O3' \
../src/configure \
--enable-bootstrap \
--enable-checking=release \
--disable-build-format-warnings \
--enable-languages=c,c++,lto
It may matter that checks are set to 'release'.
[Bug rtl-optimization/67045] [ICE][PPC64LE] internal compiler error: in choose_multiplier, at expmed.c:3373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67045 --- Comment #1 from Gary Funck gary at intrepid dot com --- Additional info, this failed when trying to build the stage 2 target libgcc. make[3]: Leaving directory '/home/gfunck/gcc-trunk/bld/powerpc64le-unknown-linu x-gnu/libgcc' Makefile:15864: recipe for target 'all-stage2-target-libgcc' failed
[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 --- Comment #7 from Gary Funck gary at intrepid dot com --- Don't know what the criteria is for closing bugs, but as far as I'm concerned, this bug can be marked resolved and the other two referenced PR's marked as duplicates of this one. (They're against older rev's, so not sure if they're exactly duplicates, but the chances of the fix being back-ported is probably low.)
[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000 --- Comment #1 from Gary Funck gary at intrepid dot com --- We're seeing this as a bootstrap failure in libitm, built with checks enabled and both host and target compilation flags set to -O0. We do not see the ICE when compiled at -O3 and --enable-checking=release. This is based on GCC trunk version 226170. make[2]: Entering directory `/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libitm' /bin/sh ./libtool --tag=CXX --mode=compile /home/gfunck/gupc-dev/bld/packed-dbg/./gcc/xg++ -B/home/gfunck/gupc-dev/bld/packed-dbg/./gcc/ -nostdinc++ -nostdinc++ -I/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/libsupc++ -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/include/backward -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/testsuite/util -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/bin/ -B/home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/lib/ -isystem /home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/include -isystem /home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/home/gfunck/gupc-dev/src/gupc/libitm -I/home/gfunck/gupc-dev/src/gupc/libitm/config/linux/powerpc -I/home/gfunck/gupc-dev/src/gupc/libitm/config/linux -I/home/gfunck/gupc-dev/src/gupc/libitm/config/powerpc -I/home/gfunck/gupc-dev/src/gupc/libitm/config/posix -I/home/gfunck/gupc-dev/src/gupc/libitm/config/generic -I/home/gfunck/gupc-dev/src/gupc/libitm -ftls-model=initial-exec -mhtm -Wall -Werror -Wc,-pthread -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -g3 -O0 -D_GNU_SOURCE -MT barrier.lo -MD -MP -MF .deps/barrier.Tpo -c -o barrier.lo /home/gfunck/gupc-dev/src/gupc/libitm/barrier.cc libtool: compile: /home/gfunck/gupc-dev/bld/packed-dbg/./gcc/xg++ -B/home/gfunck/gupc-dev/bld/packed-dbg/./gcc/ -nostdinc++ -nostdinc++ -I/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/libsupc++ -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/include/backward -I/home/gfunck/gupc-dev/src/gupc/libstdc++-v3/testsuite/util -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/gfunck/gupc-dev/bld/packed-dbg/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/bin/ -B/home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/lib/ -isystem /home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/include -isystem /home/gfunck/gupc-dev/rls/packed-dbg/powerpc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/home/gfunck/gupc-dev/src/gupc/libitm -I/home/gfunck/gupc-dev/src/gupc/libitm/config/linux/powerpc -I/home/gfunck/gupc-dev/src/gupc/libitm/config/linux -I/home/gfunck/gupc-dev/src/gupc/libitm/config/powerpc -I/home/gfunck/gupc-dev/src/gupc/libitm/config/posix -I/home/gfunck/gupc-dev/src/gupc/libitm/config/generic -I/home/gfunck/gupc-dev/src/gupc/libitm -ftls-model=initial-exec -mhtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -g3 -O0 -D_GNU_SOURCE -MT barrier.lo -MD -MP -MF .deps/barrier.Tpo -c /home/gfunck/gupc-dev/src/gupc/libitm/barrier.cc -fPIC -DPIC -o .libs/barrier.o In file included from /home/gfunck/gupc-dev/src/gupc/libitm/libitm_i.h:87:0, from /home/gfunck/gupc-dev/src/gupc/libitm/barrier.cc:25: /home/gfunck/gupc-dev/src/gupc/libitm/barrier.cc: In function ‘void _ITM_WCF(_ITM_TYPE_CF*, _ITM_TYPE_CF)’: /home/gfunck/gupc-dev/src/gupc/libitm/dispatch.h:129:20: internal compiler error: in split_complex_args, at function.c:2336 void ITM_REGPARM _ITM_##LSMOD##T (_ITM_TYPE_##T *ptr, _ITM_TYPE_##T val) \ ^ /home/gfunck/gupc-dev/src/gupc/libitm/dispatch.h:141:3: note: in expansion of macro ‘ITM_WRITE’ ITM_WRITE(T, W, TARGET, M2) \ ^ /home/gfunck/gupc-dev/src/gupc/libitm/dispatch.h:187:3: note: in expansion of macro ‘CREATE_DISPATCH_FUNCTIONS_T’ CREATE_DISPATCH_FUNCTIONS_T (CF, TARGET, M2) \ ^ /home/gfunck/gupc-dev/src/gupc/libitm/barrier.cc:43:1: note: in expansion of macro ‘CREATE_DISPATCH_FUNCTIONS’ CREATE_DISPATCH_FUNCTIONS(GTM::abi_disp()-, ) ^ 0x10a2e723 split_complex_args
[Bug sanitizer/67009] libsanitizer: shift overflow warnings when boot strapping 32 bit library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009 --- Comment #4 from Gary Funck gary at intrepid dot com --- (In reply to Mikhail Maltsev from comment #3) Confirmed, I also see it in my builds since 20.07 (several cases of -Wshift-overflow were implemented in r225998). (In reply to Andrew Pinski from comment #1) tsan should not be building for 32bits. The warning appears in 64-bit build either. Perhaps the 32-bit configure/build issue should be broken out as a separate PR and the subject line for this issue changed to reflect that the overflow warnings aren't 32-bit specific.
[Bug sanitizer/67009] New: libsanitizer: shift overflow warnings when boot strapping 32 bit library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009 Bug ID: 67009 Summary: libsanitizer: shift overflow warnings when boot strapping 32 bit library Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- After a recent update, I noticed the following warnings in the 32-bit build of libsanitizer. /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:86:35: warning: result of ‘(3 30)’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:88:35: warning: result of ‘(2 30)’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:86:35: warning: result of ‘(3 30)’ requires 33 bits to represent, but ‘int’ only has 32
[Bug middle-end/66984] New: ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
Bug ID: 66984
Summary: ICE: fold_binary changes type of operand, causing
failure in verify_gimple_assign_binary
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This problem was previously reported in bug #46679 and bug #56363. I'm logging
it as new issue because it occurred as a recent regression in 6.0, though the
changes made to 6.0 contributed only in that improved tree folding exposed this
problem in our testing of UPC on the GUPC branch. As in the two bug reports
mentioned above, we can't easily replicate the issue, because the UPC code
generator uses FLOOR_DIV_EXPR, but C generally does not.
The tree verify failure occurs using -m32 (x86), because on that target the
size of 'int' equals the size of 'size_t' and they have the same mode.
The test case fails as follows:
timer_reduce.upc: In function ‘timers_reduce’:
timer_reduce.upc:3:6: error: type mismatch in binary expression
void timers_reduce(double *max_t, int j){
^
int
sizetype
int
D.1986 = D.1984 /[ex] THREADS.4;
timer_reduce.upc:3:6: internal compiler error: verify_gimple failed
0xeb38bb verify_gimple_in_seq(gimple_statement_base*)
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/tree-cfg.c:4805
0xbc91b6 gimplify_body(tree_node*, bool)
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/gimplify.c:9260
0xbc960d gimplify_function_tree(tree_node*)
/eng/upc/dev/gary/gupc-merge/src/gupc/gcc/gimplify.c:9349
[...]
The operand type is changed here in fold-const.c:
10820 /* If arg0 is a multiple of arg1, then rewrite to the fastest div
10821operation, EXACT_DIV_EXPR.
10822
10823Note that only CEIL_DIV_EXPR and FLOOR_DIV_EXPR are rewritten
now.
10824At one time others generated faster code, it's not clear if
they do
10825after the last round to changes to the DIV code in expmed.c.
*/
10826 if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
10827 multiple_of_p (type, arg0, arg1))
10828 return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);
(gdb) p code
$24 = FLOOR_DIV_EXPR
(gdb) p type
$25 = (tree) 0x7188c7e0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
integer_type 0x7188c7e0 int public SI
size integer_cst 0x71889ca8 type integer_type 0x7188c2a0
bitsizetype constant 32
unit size integer_cst 0x71889cc0 type integer_type 0x7188c1f8
sizetype constant 4
align 32 symtab 0 alias set -1 canonical type 0x7188c7e0 precision 32
min integer_cst 0x71889ee8 -2147483648 max integer_cst 0x71889f00
2147483647
pointer_to_this pointer_type 0x718a6a80
'op0' is the first operand, 'arg0' is 'op0' after applying STRIP_NOPS().
(gdb) p op0
$26 = (tree) 0x719e15c0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
nop_expr 0x719e15c0
type integer_type 0x7188c7e0 int public SI
size integer_cst 0x71889ca8 constant 32
unit size integer_cst 0x71889cc0 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7188c7e0 precision
32 min integer_cst 0x71889ee8 -2147483648 max integer_cst 0x71889f00
2147483647
pointer_to_this pointer_type 0x718a6a80
side-effects
arg 0 save_expr 0x719abee0
type integer_type 0x7188c1f8 sizetype public unsigned SI size
integer_cst 0x71889ca8 32 unit size integer_cst 0x71889cc0 4
align 32 symtab 0 alias set -1 canonical type 0x7188c1f8
precision 32 min integer_cst 0x71889cd8 0 max integer_cst 0x71889000
4294967295
side-effects
arg 0 mult_expr 0x719de668 type integer_type 0x7188c1f8
sizetype
arg 0 nop_expr 0x719abe00 type integer_type 0x7188c1f8
sizetype
arg 0 parm_decl 0x719e0280 j
arg 1 nop_expr 0x719abde0 type integer_type 0x7188c1f8
sizetype
readonly arg 0 var_decl 0x7198d7e0 THREADS
timer_reduce.upc:4:19
(gdb) p arg0
$27 = (tree) 0x719abee0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
save_expr 0x719abee0
type integer_type 0x7188c1f8 sizetype public unsigned SI
size integer_cst 0x71889ca8 constant 32
unit size integer_cst 0x71889cc0 constant 4
align 32 symtab 0 alias set -1 canonical type 0x7188c1f8 precision
32 min integer_cst 0x71889cd8 0 max integer_cst 0x71889000
4294967295
side-effects
arg 0 mult_expr 0x719de668 type integer_type 0x7188c1f8 sizetype
arg 0 nop_expr 0x719abe00 type integer_type 0x7188c1f8
sizetype
[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 --- Comment #4 from Gary Funck gary at intrepid dot com --- (In reply to Jay from comment #2) 1 please be sure that dividing the most negative number by -1 works. Perhaps just don't optimize anything with negstive numbers. - Checking for negative numbers at compile-time can only be done on integer constant values. - Whether dividing the max negative number by -1 just works depends upon the definition and implementation of FLOOR_DIV_EXPR. - For UPC's use of FLOOR_DIV_EXPR, it isn't possible to construct that scenario.
[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 --- Comment #5 from Gary Funck gary at intrepid dot com --- (In reply to Jay from comment #2) 2 I suggest that gcc's C/C++ frontends expose these other forms of division, for the sake of testability. Perhaps defining a builtin for CEIL_DIV_EXPR and FLOOR_DIV_EXPR might work. For the builtins, you could file an RFE and post a suggested patch (with test cases) for review.
[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 --- Comment #3 from Gary Funck gary at intrepid dot com --- (In reply to Richard Biener from comment #1) The usual fix in fold-const.c is to make sure to convert operands to the required type when building the final expression. Thus instead of 10828 return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1); do return fold_build2_loc (loc, EXACT_DIV_EXPR, type, fold_convert (type, arg0), fold_convert (type, arg1)); you can see this pattern in many places. Care to post a patch? It's pre-approved. OK, I'll post a patch. Thanks.
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 --- Comment #14 from Gary Funck gary at intrepid dot com --- *** Bug 66283 has been marked as a duplicate of this bug. ***
[Bug middle-end/66283] [ICE] [IA64] verify type mis-diagnosis: type variant differs by TYPE_NO_FORCE_BLK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66283 Gary Funck gary at intrepid dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Gary Funck gary at intrepid dot com --- Duplicate *** This bug has been marked as a duplicate of bug 66181 ***
[Bug middle-end/66283] [ICE] [IA64] verify type mis-diagnosis: type variant differs by TYPE_NO_FORCE_BLK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66283 --- Comment #1 from Gary Funck gary at intrepid dot com --- FYI, this also results in a bootstrap failure for C++ on IA64, when configured with: CFLAGS='-g3 -O0' \ CXXFLAGS='-g3 -O0' \ $src/configure \ --prefix=$rls \ --enable-checking \ --enable-languages=c,c++ /eng/upc/dev/gary/gcc-trunk/bld/./gcc/xgcc -shared-libgcc -B/eng/upc/dev/gary/gcc-trunk/bld/./gcc -nostdinc++ -L/eng/upc/dev/gary/gcc-trunk/bld/ia64-unknown-linux-gnu/libstdc++-v3/src -L/eng/upc/dev/gary/gcc-trunk/bld/ ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/gary/gcc-trunk/bld/ia64-unknown-linux-gnu/libstd c++-v3/libsupc++/.libs -B/eng/upc/dev/gary/gcc-trunk/rls/ia64-unknown-linux-gnu/bin/ -B/eng/upc/dev/gary/gcc- trunk/rls/ia64-unknown-linux-gnu/lib/ -isystem /eng/upc/dev/gary/gcc-trunk/rls/ia64-unknown-linux-gnu/include -isystem /eng/upc/dev/gary/gcc-trunk/rls/ia64-unknown-linux-gnu/sys-include -x c++-header -nostdinc++ -O2 -g3 -O0 -D_GNU_SOURCE -I/eng/upc/dev/gary/gcc-trunk/bld/ia64-unknown-linux-gnu/libstdc++-v3/include/ia64-un known-linux-gnu -I/eng/upc/dev/gary/gcc-trunk/bld/ia64-unknown-linux-gnu/libstdc++-v3/include -I/eng/upc/dev/ gary/gcc-trunk/src/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /eng/upc/dev/gary/gcc-trunk/src/libstdc++-v3/in clude/precompiled/stdc++.h \ -o ia64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /usr/include/bits/types.h:131:0, from /usr/include/ctype.h:28, from /eng/upc/dev/gary/gcc-trunk/bld/ia64-unknown-linux-gnu/libstdc++-v3/include/cctype:42, from /eng/upc/dev/gary/gcc-trunk/src/libstdc++-v3/include/precompiled/stdc++.h:35: /usr/include/bits/types.h:144:12: error: type variant differs by TYPE_NO_FORCE_BLK. __STD_TYPE __FSID_T_TYPE __fsid_t; /* Type of file system IDs. */ ^ record_type 0x20778928 ._0 asm_written no-force-blk type_5 BLK size integer_cst 0x205624f0 type integer_type 0x205a0150 bitsizetype constant 64 unit size integer_cst 0x20562508 type integer_type 0x205a00a8 sizetype constant 8 align 32 symtab 6757648 alias set -1 canonical type 0x20778928 fields field_decl 0x20655ad8 __val type array_type 0x20778b20 type integer_type 0x205a0690 int asm_written no-force-blk BLK size integer_cst 0x205624f0 64 unit size integer_cst 0x20 562508 8 align 32 symtab 6757728 alias set -1 canonical type 0x20778b20 domain integer_type 0x200 000775400 nonlocal decl_3 BLK file /usr/include/bits/types.h line 144 col 12 size integer_cst 0x205624 f0 64 unit size integer_cst 0x20562508 8 align 32 offset_align 128 offset integer_cst 0x20562520 constant 0 bit offset integer_cst 0x20562568 constant 0 context record_type 0x20778928 ._0 chain type_decl 0x20655a40 ._0 type record_type 0x207789d0 ._0 nonlocal in_system_header decl_4 VOID file /usr/include/bits/types.h line 144 col 12 align 1 context record_type 0x20778928 ._0 result record_type 0x20778928 ._0 context translation_unit_decl 0x20520078 D.1 full-name structanonymous X() X(constX) this=(X) n_parents=0 use_template=0 interface-unknown chain type_decl 0x206559a8 ._0 record_type 0x207789d0 ._0 type_5 BLK size integer_cst 0x205624f0 type integer_type 0x205a0150 bitsizetype constant 64 unit size integer_cst 0x20562508 type integer_type 0x205a00a8 sizetype constant 8 align 32 symtab 0 alias set -1 canonical type 0x20778928 fields field_decl 0x20655ad8 __val type array_type 0x20778b20 type integer_type 0x205a0690 int asm_written no-force-blk BLK size integer_cst 0x205624f0 64 unit size integer_cst 0x20 562508 8 align 32 symtab 6757728 alias set -1 canonical type 0x20778b20 domain integer_type 0x200 000775400 nonlocal decl_3 BLK file /usr/include/bits/types.h line 144 col 12 size integer_cst 0x205624 f0 64 unit size integer_cst 0x20562508 8 align 32 offset_align 128 offset integer_cst 0x20562520 constant 0 bit offset integer_cst 0x20562568 constant 0 context record_type 0x20778928 ._0 chain type_decl 0x20655a40 ._0 type record_type 0x207789d0 ._0 nonlocal in_system_header decl_4 VOID file /usr/include/bits/types.h line 144 col 12 align 1 context record_type 0x20778928 ._0 result record_type 0x20778928 ._0 context translation_unit_decl 0x20520078 D.1 full-name structanonymous X() X(constX) this=(X) n_parents=0 use_template=0 interface-unknown chain type_decl
[Bug c/66283] New: [ICE] [IA64] verify type mis-diagnosis: type variant differs by TYPE_NO_FORCE_BLK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66283
Bug ID: 66283
Summary: [ICE] [IA64] verify type mis-diagnosis: type variant
differs by TYPE_NO_FORCE_BLK
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Target Milestone: ---
This recent commit implemented additional type verification checks:
r223252 | hubicka | 2015-05-16 13:51:50 -0700 (Sat, 16 May 2015) | 3 lines
* tree.c (verify_type_variant): Verify tree_base and type_common flags.
(verify_type): Verify STRING_FLAG.
This triggers an ICE on IA64 when configured with --enable-checking and when
the test program below is compiled with -g. It may be possible to change
the test so that the declaration of struct S to asserts TYPE_NO_FORCE_BLK()
for a more common target like the x86_64, but I didn't try that.
typedef volatile struct S opaque_qualified_t;
struct S
{
unsigned long _s1;
int _s2;
};
void
proc (opaque_qualified_t *p __attribute__((unused)))
{
}
ice-no-force-blk.i: In function ‘proc’:
ice-no-force-blk.i:12:1: error: type variant differs by TYPE_NO_FORCE_BLK.
}
^
record_type 0x20b6eee0 S asm_written no-force-blk type_0 BLK
size integer_cst 0x20a72388 type integer_type 0x20ab0150
bitsizetype
constant 128
unit size integer_cst 0x20a723a0 type integer_type
0x20ab00a8 sizetype
constant 16
align 64 symtab 12587232 alias set -1 canonical type 0x20b6eee0
fields field_decl 0x20b41858 _s1
type integer_type 0x20ab0888 long unsigned int asm_written
public unsigned DI
size integer_cst 0x20a72340 constant 64
unit size integer_cst 0x20a72358 constant 8
align 64 symtab 12587632 alias set -1 canonical type
0x20ab0888 precision 64 min
integer_cst 0x20a72610 0 max integer_cst 0x20b20520
18446744073709551615
pointer_to_this pointer_type 0x20ab46e0
unsigned DI file ice-no-force-blk.i line 5 col 18 size integer_cst
0x20a72340 64
unit size integer_cst 0x20a72358 8
align 64 offset_align 128
offset integer_cst 0x20a72370 constant 0
bit offset integer_cst 0x20a723b8 constant 0 context
record_type 0x20b6eee0
S
chain field_decl 0x20b418f0 _s2 type integer_type
0x20ab0690 int
SI file ice-no-force-blk.i line 6 col 8
size integer_cst 0x20a72580 constant 32
unit size integer_cst 0x20a72598 constant 4
align 32 offset_align 128 offset integer_cst 0x20a72370 0
bit offset integer_cst
0x20a72340 64 context record_type 0x20b6eee0 S context
translation_unit_decl
0x20a200f0 D.1470
chain type_decl 0x20b41728 D.1463
record_type 0x20b6f030 opaque_qualified_t volatile BLK
size integer_cst 0x20a72388 type integer_type 0x20ab0150
bitsizetype
constant 128
unit size integer_cst 0x20a723a0 type integer_type
0x20ab00a8 sizetype
constant 16
align 64 symtab 12587152 alias set -1 canonical type 0x20b6ef88
fields field_decl 0x20b41858 _s1
type integer_type 0x20ab0888 long unsigned int asm_written
public unsigned DI
size integer_cst 0x20a72340 constant 64
unit size integer_cst 0x20a72358 constant 8
align 64 symtab 12587632 alias set -1 canonical type
0x20ab0888 precision 64 min
integer_cst 0x20a72610 0 max integer_cst 0x20b20520
18446744073709551615
pointer_to_this pointer_type 0x20ab46e0
unsigned DI file ice-no-force-blk.i line 5 col 18 size integer_cst
0x20a72340 64
unit size integer_cst 0x20a72358 8
align 64 offset_align 128
offset integer_cst 0x20a72370 constant 0
bit offset integer_cst 0x20a723b8 constant 0 context
record_type 0x20b6eee0
S
chain field_decl 0x20b418f0 _s2 type integer_type
0x20ab0690 int
SI file ice-no-force-blk.i line 6 col 8
size integer_cst 0x20a72580 constant 32
unit size integer_cst 0x20a72598 constant 4
align 32 offset_align 128 offset integer_cst 0x20a72370 0
bit offset integer_cst
0x20a72340 64 context record_type 0x20b6eee0 S context
translation_unit_decl
0x20a200f0 D.1470
pointer_to_this pointer_type 0x20b6f570
ice-no-force-blk.i:12:1: internal compiler error: verify_type failed
0x425159ff verify_type(tree_node const*)
/eng/upc/dev/gary/gupc-dev/src/gupc/gcc/tree.c:13209
0x40ad3d4f gen_type_die_with_usage
/eng/upc/dev/gary/gupc-dev
[Bug c/62198] spurious warning - initialization discards qualifier from pointer target type for pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198 --- Comment #4 from Gary Funck gary at intrepid dot com --- I realize that this bug has been closed as invalid, thus making the warning valid. However, if the warning is valid what can be done to this declaration to avoid the warning? const int (*X0)[10] = alloc (10 * sizeof (int)); The C99 spec. says: 6.7.3 Semantics 8. If the specification of an array type includes any type qualifiers, the element type is so qualified, not the array type. If the specification of a function type includes any type qualifiers, the behavior is undefined.116) 116) Both of these can occur through the use of typedefs Since the constraint above talks about the qualifiers being propagated to the element type, is it possible at all for an array type to be qualified? what is the syntax for that? It seems reasonable to conclude for the purpose of determining compatibility in the case of assignment of a qualified pointer-to-void to a pointer-to-array with a qualified element type that the ultimate element type would be used, but I didn't find anywhere in the C99 spec. that this was explicitly discussed. It's interesting that g++ just banned this situation outright: error: invalid conversion from ‘const void*’ to ‘const int (*)[10]’ [-fpermissive]
[Bug c/62198] New: spurious warning - initialization discards qualifier from pointer target type for pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198
Bug ID: 62198
Summary: spurious warning - initialization discards qualifier
from pointer target type for pointer to array
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Although this bug is filed against the 5.0 trunk, it can be duplicated with at
least 4.8.3.
Given:
$ cat q.c
typedef unsigned long size_t;
extern const void *alloc (size_t);
int main()
{
const int (*X0)[10] = alloc (10 * sizeof (int));
return !X0;
}
When compiled with gcc 4.8.3 the following warning is issued:
$ gcc -fpreprocessed -c q.c
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [enabled by default]
const int (*X0)[10] = alloc (10 * sizeof (int));
^
Same thing for GCC 5.0 (trunk version 214178):
$ xgcc -fpreprocessed -c q.c
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
const int (*X0)[10] = alloc (10 * sizeof (int));
^
Clang 3.4 issues no warning:
$ clang -Wall -pedantic -Wextra -c q.c
no output
Given that the qualifier 'const' is associated with the array's element type,
it seems that the front end should derive the qualifier from the element type
when it is the target type of a declared pointer, before making the discards
qualifier check.
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #7 from Gary Funck gary at intrepid dot com --- (In reply to Trevor Saunders from comment #6) thanks! I think the attached patch should fix all of those issues, would you mind testing it? Confirmed. With that patch, the stage1 compiler compiled successfully using g++ 4.5.1.
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #2 from Gary Funck gary at intrepid dot com --- (In reply to Trevor Saunders from comment #1) The following patch compiles with 4.9 for me, but I don't have easy access to a machine with 4.5 on it, would you mind testing if it works for you? Applied the patch to r212302 (2014-07-04), however, still seeing compilation failure: /a/gcc-4.5.1/bld/rls/bin/g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -O0 -g3 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libcpp/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I../libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace -o attribs.o -MT attribs.o -MMD -MP -MF ./.deps/attribs.TPo /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c:35:0: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:845:1: error: prototype for ‘typename Descriptor::value_type** hash_tableDescriptor, Allocator, false::find_slot_with_hash(hash_tableDescriptor, Allocator, false::compare_type*, hashval_t, insert_option)’ does not match any in class ‘hash_tableDescriptor, Allocator, false’ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:542:16: error: candidate is: hash_tableDescriptor, Allocator, false::value_type** hash_tableDescriptor, Allocator, false::find_slot_with_hash(hash_tableDescriptor, Allocator, false::compare_type*, hashval_t, insert_option) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:927:1: error: prototype for ‘void hash_tableDescriptor, Allocator, false::traverse_noresize(Argument)’ does not match any in class ‘hash_tableDescriptor, Allocator, false’ [...]
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #4 from Gary Funck gary at intrepid dot com --- Created attachment 33076 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33076action=edit make log after trying patch
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #5 from Gary Funck gary at intrepid dot com --- (In reply to Trevor Saunders from comment #3) Is the below list complete? I'd expect to see errors for the partial specialization for true as well. Attached the full make log.
[Bug bootstrap/61679] New: build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 Bug ID: 61679 Summary: build fails with G++ 4.5.1 - prototype for hash_table does not match any in class Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com This build failure shows up on a recent source version of GCC 4.10 (212138 2014-06-30). An attempt to bootstrap the compiler on an older system with GCC 4.5.1 installed fails as follows: /a/gcc-4.5.1/bld/rls/bin/g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -O0 -g3 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libcpp/include -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid -I../libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace -o attribs.o -MT attribs.o -MMD -MP -MF ./.deps/attribs.TPo /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c:35:0: /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:667:1: error: prototype for ‘typename Descriptor::value_type** hash_tableDescriptor, Allocator, false::find_empty_slot_for_expand(hashval_t)’ does not match any in class ‘hash_tableDescriptor, Allocator, false’ /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:606:16: error: candidate is: hash_tableDescriptor, Allocator, false::value_type** hash_tableDescriptor, Allocator, false::find_empty_slot_for_expand(hashval_t) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:807:1: error: prototype for ‘typename Descriptor::value_type* hash_tableDescriptor, Allocator, false::find_with_hash(hash_tableDescriptor, Allocator, false::compare_type*, hashval_t)’ does not match any in class ‘hash_tableDescriptor, Allocator, false’ [...]
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439
--- Comment #10 from Gary Funck gary at intrepid dot com ---
The following test case when compiled against a recent trunk revision (211365
2014-06-08) generates a warning, as intended by the patch described in comment
8.
int a, x;
int
main ()
{
switch (!x)
{
case 0:
a = 1;
break;
case 1:
a = 2;
break;
}
return 0;
}
s.c: In function ‘main’:
s.c:8:11: warning: switch condition has boolean value [-Wswitch-bool]
switch (!x)
^
However, -Wno-switch-bool does *not* suppress the warning.
Looking at gcc/c-family/c.opt, it has an Init(1) clause but no Var() clause.
It seems that if an Init() clause is present that a Var() clause must also be
present for this option to work as expected.
This patch fixes the issue.
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 211365)
+++ gcc/c-family/c.opt (working copy)
@@ -539,7 +539,7 @@ C ObjC C++ ObjC++ Var(warn_switch_enum)
Warn about all enumerated switches missing a specific case
Wswitch-bool
-C ObjC C++ ObjC++ Warning Init(1)
+C ObjC C++ ObjC++ Var(warn_switch_bool) Warning Init(1)
Warn about switches with boolean controlling expression
Wmissing-format-attribute
However, I'm not so certain that this option should be enabled by default, for
a few reasons:
1) The test case above shows the use of a boolean value used in the case
expression where both alternatives (0 and 1) are accounted for and no other
(overflow) cases are mentioned. Adding a cast to (int) will not clarify the
code at all and in fact then leaves apparent cases unaccounted for, which might
arguably lead to a warning to that effect on some compilers (present or
future).
2) If the compiler performed control flow analysis and range analysis to
determine that some cases are not accounted for or that some cases are
out-of-range, then enabling by default would seem appropriate. In the test
case above (in my opinion) no warning should be issued because both cases are
accounted for.
3) Perhaps this option should only be enabled explicitly or by -Wall. For
example, -Wswitch is enabled by -Wall.
Wswitch
C ObjC C++ ObjC++ Var(warn_switch) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall
)
Warn about enumerated switches, with no default, missing a case
[Bug other/61480] New: GCC options processing: Init() requires Var() for 'no-' to work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61480 Bug ID: 61480 Summary: GCC options processing: Init() requires Var() for 'no-' to work as expected Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: jsm28 at gcc dot gnu.org, nenad at intrepid dot com While researching an issue related to Bug 60439, I noticed that the specification for the -Wswitch-bool option quietly ignored -Wno-switch-bool. This was fixed by adding a Var() clause. Index: gcc/c-family/c.opt === --- gcc/c-family/c.opt (revision 211365) +++ gcc/c-family/c.opt (working copy) @@ -539,7 +539,7 @@ C ObjC C++ ObjC++ Var(warn_switch_enum) Warn about all enumerated switches missing a specific case Wswitch-bool -C ObjC C++ ObjC++ Warning Init(1) +C ObjC C++ ObjC++ Var(warn_switch_bool) Warning Init(1) Warn about switches with boolean controlling expression The internal document describing the format of the c.opt file didn't appear to mention this requirement. If there is such a requirement for things to work as expected, perhaps the tool that processes the options specification file should issue an error when Init() is present, but Var() is not?
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439 --- Comment #12 from Gary Funck gary at intrepid dot com --- I submitted Bug #61480 documenting the interaction between Var() and Init(). The test case that I posted is abstracted from actual code. As far as which switches should be default and/or enabled by -Wall, that question probably needs further review.
[Bug tree-optimization/61375] New: ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375 Bug ID: 61375 Summary: ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: nenad at intrepid dot com Target: x86_64 Created attachment 32880 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32880action=edit pre-processed C source, generates ICE at -O3 in tree-ssa When compiling the attached pre-processed source file at -O3, the following stack trace is generated. $ gcc -O3 -fpreprocessed -c ice-int_cst_value-int128.i ice-int_cst_value-int128.i: In function ‘test15’: ice-int_cst_value-int128.i:442:1: internal compiler error: in int_cst_value, at tree.c:10492 test15 () ^ 0xe3fb99 int_cst_value(tree_node const*) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:10492 0xd03709 find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1848 0xd0354c find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1815 0xd0354c find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1815 0xd039a9 find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1916 0xd03f6a find_bswap_or_nop /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:2034 0xd04ac3 execute /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:2322 The compiler is based on: Last Changed Rev: 211071 Last Changed Date: 2014-05-29 17:17:10 -0700 The test case can likely be reduced. The issue seems to relate to an attempt to simplify an expression that mixes an address and an __int128 value. The ICE triggered here: 10488 unsigned bits = TYPE_PRECISION (TREE_TYPE (x)); 10489 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x); 10490 10491 /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ 10492 gcc_assert (cst_and_fits_in_hwi (x)); where 'x' is: integer_cst 0x719ab0e0 type integer_type 0x719be690 upcr_pshared_ptr_t constant 0x0f000 and the type is a 128 bit integer: integer_type 0x719be690 upcr_pshared_ptr_t sizes-gimplified public unsigned TI size integer_cst 0x7189d6c0 type integer_type 0x7189f150 bitsizetype constant 128 unit size integer_cst 0x7189d6d8 type integer_type 0x7189f0a8 sizetype constant 16 align 128 symtab 0 alias set -1 canonical type 0x7189fb28 precision 128 min integer_cst 0x7189d9a8 0 max integer_cst 0x7189c668 0x context translation_unit_decl 0x719c3b80 D.1942 pointer_to_this pointer_type 0x719c97e0 The gimple statement being simplified looks like this: _15 = array.0_8 18446726481523507200 (gdb) p/x 18446726481523507200 $4 = 0xf000
[Bug go/60790] New: libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Bug ID: 60790 Summary: libatomic convenience library selects IFUNC implementation before obtaining cpu info. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: gary at intrepid dot com CC: nenad at intrepid dot com, PHHargrove at lbl dot gov, rth at gcc dot gnu.org Created attachment 32569 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32569action=edit libatomic cpuinfo patch We ran into this issue recently while implementing atomic memory support for GNU UPC. We followed an approach similar to libgo -- we included libatomic_convenience.a into libgupc.a. This lets libgupc access GCC's __atomic support without requiring the user to link explicitly with libatomic. While debugging the UPC AMO library on a modern X86-64 platform, we noticed that the locked implementation of compare-exchange-16 was being used in spite of the fact of that the CPU supports the CMPX16 operation directly. We determined that the IFUNC selector function was being called before the constructor function in init.c had run. Thus the libat_feat1_ecx variable was zero. Because the feature bit wasn't set, the selector function chose the CAS function which requires explicit locks. Interestingly, __atomic_is_lock_free(16, NULL) returns true, as expected on this platform because it is called after the init_cpuid() constructor is called. One way to fix this issue is to re-work the logic that queries the CPU feature register value, so that it explicitly initializes the value if it is zero. The assumption here is that __get_cpuid() will always return a non-zero value in the ECX feature register. A patch that implements this approach is attached.
[Bug go/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790 Gary Funck gary at intrepid dot com changed: What|Removed |Added Attachment #32569|0 |1 is obsolete|| --- Comment #1 from Gary Funck gary at intrepid dot com --- Created attachment 32570 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32570action=edit libatomic cpuinfo patch Test for edx when checking bit_CMPXCHG8B.
[Bug bootstrap/58572] [4.9 regression] make install uses -Wno-narrowing with system compiler which does not know about it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 --- Comment #1 from Gary Funck gary at intrepid dot com --- We're seeing a similar failure on SUSE SLE 11.2. The installed version of gcc is 4.3.4.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #12 from Gary Funck gary at intrepid dot com 2012-12-03 17:24:03 UTC --- (In reply to comment #10) Thanks for the experiment. I think that you just need to always bootstrap the compiler (i.e. don't pass --disable-bootstrap) since it's precisely designed to avoid this kind of problems. For cross-compilers, the trick is to bootstrap a native compiler and use it to build them. Thanks. I can confirm that a full bootstrap using the system installed /usr/bin/gcc and /usr/bin/g++ compilers with default compilation switches was able to build gcc and g++ without issue. Case closed.
[Bug bootstrap/55566] New: [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 Bug #: 55566 Summary: [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Created attachment 28854 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28854 build failure: IA64 segv - first seen in r193595 GCC fails to build, due to a segmentation violation while compiling libgcc2 during the bootstrap phase on an IA64 (altix) running SuSE SLES 11.1. The installed gcc compiler is gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], which is the compiler used to initially build gcc. Bisection indicates that this started to fail with this svn revision. r193595 | dnovillo | 2012-11-17 18:54:30 -0800 (Sat, 17 Nov 2012) | 537 lines This patch rewrites the old VEC macro-based interface into a new one based on the template class 'vec'. The user-visible changes are described in http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec. [...] It has continued to fail subsequent to that commit at least through 2012-11-30. Since about 2012-11-27, the segmentation violations that trace back originating through vec.h persist, but now the failure occurs when compiling a configure test when beginning to build libgcc. This continues to fail for a recent version of gcc trunk (r194044 2012-12-01). An excerpt configure test failure traceback is as follows. conftest.c: In function 'foo': conftest.c:19:1: internal compiler error: Segmentation fault } ^ 0x40b3b33f crash_signal src/gcc/toplev.c:334 0x40466f30 vecdf_ref_d*, va_stack, vl_embed::space(unsigned int) cons t src/gcc/vec.h:842 0x40466f30 vecdf_ref_d*, va_stack, vl_embed::quick_push(df_ref_d* con st) src/gcc/vec.h:947 0x40466f30 vecdf_ref_d*, va_stack, vl_ptr::quick_push(df_ref_d* const ) src/gcc/vec.h:1552 0x40466f30 vecdf_ref_d*, va_stack, vl_ptr::safe_push(df_ref_d* const ) src/gcc/vec.h:1565 0x40466f30 df_ref_create_structure 0x40466f30 df_ref_create_structure src/gcc/df-scan.c:2804 0x40467b3f df_ref_record src/gcc/df-scan.c:2873 0x4046923f df_get_call_refs src/gcc/df-scan.c:3403 [...] More complete logs with trace back are attached.
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-12-02 20:32:03 UTC --- Created attachment 28855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28855 build failure Ia64 segv - continues to fail in r194044 (in libgcc config. test)
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #2 from Gary Funck gary at intrepid dot com 2012-12-02 20:43:45 UTC --- The configure options specified are: CC=/usr/bin/gcc CXX=/usr/bin/g++ $src/configure --enable-languages=c,c++ --enable-checking --disable-bootstrap --disable-multilib --disable-libmudflap --disable-libssa --disable-lto --prefix=/eng/upc/dev/gary/gcc-trunk Configure reports: CFLAGS='-g -O2' CFLAGS_FOR_BUILD='-g -O2' CFLAGS_FOR_TARGET='-g -O2' CXXFLAGS='-g -O2' CXXFLAGS_FOR_BUILD='-g -O2' CXXFLAGS_FOR_TARGET='-g -O2'
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #3 from Gary Funck gary at intrepid dot com 2012-12-02 21:32:14 UTC --- This failure may be related to the use of the installed gcc compiler (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]). I tried a gcc 4.7.0 compiler that we built circa Feb, 2012 and it didn't segfault, but rather fails with an apparently unrelated error while compiling 'gmp' (redc_2.c:87:7: error: 'asm' operand requires impossible reload). I will try building svn revision 152973 on an x86-64 box, and see if the problem can be reproduced there.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #5 from Gary Funck gary at intrepid dot com 2012-12-02 21:45:52 UTC --- Cancel the previous comment regarding the idea that this might be related to using the system installed gcc. The build failed while trying to build gmp, and hadn't gotten to trying compile libgcc yet.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #6 from Gary Funck gary at intrepid dot com 2012-12-02 21:48:28 UTC --- This isn't a bootstrap since you pass --disable-bootstrap to configure ... Agreed. I didnt' know how to classify this problem. Since the version of 4.7.0 that I used appears incompatible with the version of gmp that we build as a pre-requisite, I will try a 4.6 compiler and see if I get a different result.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #7 from Gary Funck gary at intrepid dot com 2012-12-02 21:49:49 UTC --- (In reply to comment #4) The compiler bootstraps fine for me btw. Which version of the host compiler did you use to run the initial build step? Which OS and target architecture?
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #9 from Gary Funck gary at intrepid dot com 2012-12-03 02:02:18 UTC --- (In reply to comment #3) I will try building svn revision 152973 on an x86-64 box, and see if the problem can be reproduced there. I built fully bootstrapped the gcc/g++ compiler based on the 4.3 branch revision 152973 on an x86-64 FC15 platform and couldn't replicate the failure. On the SUES 11.1 IA64 platform, I built the 4.5.4 release compiler from sources via a full bootstrap. There is no segfault. It is looking like this failure is particular to the installed 4.3.4 g++ compiler. If I have time, I might try rebuilding that version on this IA64 system and see if the bug replicates. It seems that this bug report will likely be resolved as works for me, and we'll need to build with the 4.5.4 compiler.
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #10 from Gary Funck gary at intrepid dot com 2012-12-01 23:17:00 UTC --- (In reply to comment #9) OK, I applied it to our autotester and we will see tomorrow if it fixes the segfaults. If so, can I go ahead and commit it? Honza Ping: was this patch tested and then applied? thanks.
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #8 from Gary Funck gary at intrepid dot com 2012-11-09 15:26:46 UTC --- (In reply to comment #5) Completely untested patch for someone else to foster-parent: + } + } f = find_fallthru_edge (last_bb-succs); if (f f-probability * 100 / REG_BR_PROB_BASE = PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF)) I could not apply the patch cleanly. Perhaps it was garbled by line wraps, etc. Can you post the patch as an attachment?
[Bug rtl-optimization/55158] New: ICE: [4.8 Regreesion] [IA64] segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
Bug #: 55158
Summary: ICE: [4.8 Regreesion] [IA64] segv in schedule_region
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
Created attachment 28587
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28587
Test case: gcc segv when compiled at -O3 on IA64
See attached test case.
$ bld/gcc/cc1 -O3 gcc-ice-schedule-region.c -o gcc-ice-schedule-region.o
gasneti_check_node_list
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups *free_inline_summary
whole-program profile_estimate cp inline pure-const
static-varAssembling functions:
gasneti_check_node_list
gcc-ice-schedule-region.c: In function ‘gasneti_check_node_list’:
gcc-ice-schedule-region.c:53:1: internal compiler error: Segmentation fault
}
^
0x40b7b22f crash_signal
src/gcc/toplev.c:333
0x40ac2aaf schedule_region
src/gcc/sched-rgn.c:2998
0x40ac2aaf schedule_insns()
src/gcc/sched-rgn.c:3343
Here is the schedule_region source at that location.
2993 f = find_fallthru_edge (last_bb-succs);
2994 if (f f-probability * 100 / REG_BR_PROB_BASE =
2995 PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF))
2996{
2997 memcpy (bb_state[f-dest-index], curr_state,
2998 dfa_state_size);
2999 if (sched_verbose = 5)
3000fprintf (sched_dump, saving state for edge %d-%d\n,
3001 f-src-index, f-dest-index);
3002}
Here is the value of f-dest-index at the pointed and the value of the
selected element of bb_state.
(gdb) p f-dest-index
$1 = 23
(gdb) p bb_state[23]
$2 = (state_t) 0x431
Clearly not a valid address.
(gdb) p bb_state[22]
$3 = (state_t) 0x602f3d58
While the element before it looks OK.
This issue seemed to be introduced by this check in.
2012-10-08 Bernd Schmidt ber...@codesourcery.com
* sched-int.h (schedule_block): Adjust declaration.
* sched-rgn.c (bb_state_array, bb_state): New static variables.
(sched_rgn_init): Initialize them.
(sched_rgn_free): Free them.
(schedule_region): Save scheduling state for future blocks, and
which is svn revision 192203.
[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #1 from Gary Funck gary at intrepid dot com 2012-11-01 00:15:54
UTC ---
Some additional debugging information.
In sched_rgn_init(), the bb_state array is initialized.
3049{
3050 bb_state_array = (char *) xmalloc (last_basic_block *
dfa_state_size);
3051 bb_state = XNEWVEC (state_t, last_basic_block);
3052 for (i = 0; i last_basic_block; i++)
3053{
3054 bb_state[i] = (state_t) (bb_state_array + i *
dfa_state_size);
3055
3056 state_reset (bb_state[i]);
3057}
3058}
For the given test case.
(gdb) p last_basic_block
$3 = 23
Yet, it is the access of bb_state[23] that leads to the segfault.
The last basic block is 23, and the array bb_state[] is initialized only for
entries 0..22. Perhaps the number entries allocated should be
(last_basic_block + 1) with the initialization loop adjusted accordingly?
[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #2 from Gary Funck gary at intrepid dot com 2012-11-01 00:35:41
UTC ---
I tried making the change suggested in the previous comment and ran into a
segfault here:
5876dump_new_block_header (0, *target_bb, head, tail);
5877
5878 if (init_state == NULL)
5879state_reset (curr_state);
5880 else
5881memcpy (curr_state, init_state, dfa_state_size);
5882
5883 /* Clear the ready list. */
5884 ready.first = ready.veclen - 1;
5885 ready.n_ready = 0;
(gdb) p init_state
$10 = (state_t) 0x431
init_state is an invalid pointer.
Going up one level.
2985 curr_bb = first_bb;
2986 if (dbg_cnt (sched_block))
2987{
2988 edge f;
2989
2990 schedule_block (curr_bb, bb_state[first_bb-index]);
2991 gcc_assert (EBB_FIRST_BB (bb) == first_bb);
2992 sched_rgn_n_insns += sched_n_insns;
2993 f = find_fallthru_edge (last_bb-succs);
2994 if (f f-probability * 100 / REG_BR_PROB_BASE =
(gdb) p first_bb-index
$13 = 25
If the last basic block is 23, then this index is out-of-range.
[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743 --- Comment #3 from Gary Funck gary at intrepid dot com 2012-08-28 02:20:38 UTC --- Recently, I've been reviewing changes that we made on the GUPC branch (see comment #2) that are candidates for the trunk revision (or in this case, possibly the 4.7 branch). Index: gcc/config/darwin.c === --- gcc/config/darwin.c (.../trunk) (revision 190707) +++ gcc/config/darwin.c (.../branches/gupc) (revision 190718) @@ -3039,6 +3039,7 @@ darwin_override_options (void) } if (flag_var_tracking + optimize = 1 generating_for_darwin_version = 9 (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE) : (debug_info_level = DINFO_LEVEL_NORMAL)) Reading the problem description, unless the option scanning logic has changed for Darwin, it looks as if this change might still be necessary to suppress var tracking at -O0?
[Bug other/54324] New: GCC install document does not list minimum required g++ versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Bug #: 54324 Summary: GCC install document does not list minimum required g++ versions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html Currently, install.texi states: @heading Tools/packages necessary for building GCC @table @asis @item ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (KR) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. This appears to be out-of-date with respect to new GCC 4.8 C++ stage 1 build requirement.
[Bug other/54326] New: GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Bug #: 54326 Summary: GCC does not build with G++ version 3.4.0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html See also: Bug #54324 (install documentation does not list the minimum required g++ version) Paul Hargrove noted the following build failure on an older x86-32 Linux (Redhat 8.0) system. The g++ version is: g++ (GCC) 3.4.0 g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include -I/usr/local/pkg/mpc-0.8/include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/genoutput.o /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function `void note_constraint(rtx_def*, int)': /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: reinterpret_cast from type `const char (*)[1]' to type `char*' casts away constness make[2]: *** [build/genoutput.o] Error 1 make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' make[1]: *** [all-gcc] Error 2
[Bug other/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-08-19 20:54:51 UTC --- Don't know if this is relevant, but a recent thread on the clang-dev list explored the differences between GCC and clang in the handling of const and constexpr. clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023565.html
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 --- Comment #5 from Gary Funck gary at intrepid dot com 2012-08-18 18:39:42 UTC --- (In reply to comment #1) (Note, apparent s/4.2.1/4.1.2/g in initial description.) I'd suggest updating to just a later gcc build, if you can find *only slightly newer* rpm:s; as for a x86_64-linux F 8 with gcc-4.1.2-33 (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)), I'm well into stage 1 for r190498. FYI, the failing system has Redhat Release 8 (circa 2002). Fedocra Core 8 didn't come out until circa 2007. Thus, it would be surprising that an FC8 RPM will build on the much older RH8 system.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #41 from Gary Funck gary at intrepid dot com 2012-08-15 13:47:37 UTC --- (In reply to comment #38) What are the code generation deficiencies you are targeting with this? For testcase #1 I get sptr_result: .LFB0: .cfi_startproc movqS+8(%rip), %rdx movqS(%rip), %rax ret what would you expect instead? I don't think we should change MAX_FIXED_MODE_SIZE, nor make use of TImode unconditionally. All three test cases were designed simply to make them easy to check via an RTL scan for the presence/use of TImode. I chose three arbitrary small test cases with the only criteria that they used the struct's differently. As far as the motivation for suggesting the change, I noted that several other targets assign 128-bit struct's into TImode values. Therefore, I assumed that there must be some benefit, and that this was an oversight in the x86_64 implementation. In the GUPC implementation of the UPC programming language, a pointer into shared space has three components (virtual-offset,thread,phase). This pointer-to-shared (PTS) can be represented in a packed mode, where it uses 64 bits, but gives up some range for each of the fields. The more general form is the struct representation which provides full range for the fields and is 128-bits -- as the name implies, the underlying PTS representation manipulated by the compiler is a struct. Note that the packed representation could be a struct also (with bit fields), but back when this project was started code generation for structs and bit-fields wasn't very good; the code quality was better if the compiler hand-crafted the necessary bit field manipulations. Since UPC programs use PTS's frequently, we found that targeting them to TImode containers improved various micro-benchmarks. We noted that other targets like MIPS and PPC did this and assumed it would be a good idea for x86_64 to follow suit. We don't have any hard data on the level of performance improvement, though as Chip noted, some modest space savings were gained in libstdc++. I can re-run some UPC tests, if that helps, but they have a rather specific usage pattern. Maybe something like the SPEC benchmarks would be more compelling, but I don't have access to them.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #44 from Gary Funck gary at intrepid dot com 2012-08-15 14:45:42 UTC --- (In reply to comment #43) The problem is we return a TI union in XF register because the x86-64 psABI. Is this the same problem documented in comment #9? The patch that you suggested in comment #36 doesn't fix it?
[Bug other/54279] New: first stage build with g++ fails with . as the first component of $PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279 Bug #: 54279 Summary: first stage build with g++ fails with . as the first component of $PATH Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Posted here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01032.html This build failure is a likely result of the recent change to compile GCC with the C++ compiler during the first stage. 1. I have . on $PATH. 2. In one build of the latest GCC trunk, I specify CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything works. 3. In another build, I don't specify CC or CXX. Therefore they default to 'gcc' and 'g++'. This fails: g++: error trying to exec 'cc1plus': execvp: No such file or directory If I remove . from $PATH then the configuration in 3 will build. The problem is that there is a g++ executable under the built gcc directory, but cc1plus and other g++ component parts haven't been built yet.
[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #15 from Gary Funck gary at intrepid dot com 2012-08-14 13:17:26
UTC ---
(In reply to comment #14)
Yeah, IMHO it should have added
%{!mpower*: %(asm_default)}} \
line instead of
%{!mpowerpc*: -mcom}} \
That change fixed the build failure on a POWER7 system running RHEL 6.2 that I
tried it on, where it failed without the patch.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #34 from Gary Funck gary at intrepid dot com 2012-08-14 23:55:57
UTC ---
(In reply to comment #33)
We must make sure that
---
union S160
{
long double a;
};
extern union S160 check160 (void);
extern void checkx160 (union S160);
void
test160 (void)
{
checkx160 (check160 ());
}
---
compiles.
I agree. I looked into this briefly, but was unsure how to fix the issue.
What I can do is incorporate whatever fix is agreed upon into the patch, and
add this as an explicit test case. Even though it is slightly duplicative, it
will be clearer what's going on if a regression occurs later on.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #35 from Gary Funck gary at intrepid dot com 2012-08-15 00:00:43 UTC --- Note that for the test case in comment #34 (and comment #9) to fail that the MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal checking has to be enabled.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #37 from Gary Funck gary at intrepid dot com 2012-08-15 03:34:55 UTC --- (In reply to comment #36) (In reply to comment #35) Note that for the test case in comment #34 (and comment #9) to fail that the MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal checking has to be enabled. This patch seems to work: [...] Thanks, I couldn't figure out how to successfully apply that git-svn formatted patch to my svn based working copy. Would you like to first apply your patch, update the trunk, and then I'll test it against my patch, and then RFA if all goes well?
[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142
--- Comment #11 from Gary Funck gary at intrepid dot com 2012-08-13 23:00:57
UTC ---
It is possible that revision 189908 introduced the 'mcom' change.
Index: src/gcc/config/rs6000/rs6000.h
===
--- src/gcc/config/rs6000/rs6000.h (revision 189907)
+++ src/gcc/config/rs6000/rs6000.h (revision 189908)
@@ -101,17 +101,12 @@
you make changes here, make them also there. */
#define ASM_CPU_SPEC \
%{!mcpu*: \
- %{mpower: %{!mpower2: -mpwr}} \
- %{mpower2: -mpwrx} \
%{mpowerpc64*: -mppc64} \
%{!mpowerpc64*: %{mpowerpc*: -mppc}} \
- %{mno-power: %{!mpowerpc*: -mcom}} \
- %{!mno-power: %{!mpower*: %(asm_default)}}} \
+ %{!mpowerpc*: -mcom}} \
[...]
r189908 | segher | 2012-07-27 04:44:37 -0700 (Fri, 27 Jul 2012) | 115 lines
2012-07-26 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
Delete code for -mno-power, -mpower, and -mpower2.
* config/rs6000/aix43.h (NON_POWERPC_MASKS): Delete.
(SUBTARGET_OVERRIDE_OPTIONS): Delete check for POWER together
with -maix64.
[...]
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #30 from Gary Funck gary at intrepid dot com 2012-08-14 04:24:54 UTC --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00839.html
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #16 from Gary Funck gary at intrepid dot com 2012-08-12 18:08:05 UTC --- Created attachment 27995 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27995 test case #1 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #17 from Gary Funck gary at intrepid dot com 2012-08-12 18:11:25 UTC --- Created attachment 27996 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27996 test case #2 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #18 from Gary Funck gary at intrepid dot com 2012-08-12 18:17:19 UTC --- Created attachment 27997 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27997 test case #3 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #19 from Gary Funck gary at intrepid dot com 2012-08-12 18:30:25 UTC --- (In reply to comment #15) Do we have a run-time testcase? I attached three compile-time test cases that check if the generated RTL refers to TImode values. The test cases are set up to only run on x86_64 and x86 targets. I confirmed that they work as expected on an x86_64 target (with and without the MAX_FIXED_MODE_SIZE patch). Not sure if it will work on x86 or not. The test case may have to be tweaked for x86. Is this sufficient? I don't know how a run-time test would demonstrate the use of TImode, except in the form of a benchmark.
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #21 from Gary Funck gary at intrepid dot com 2012-08-12 21:24:40
UTC ---
(In reply to comment #20)
X86 doesn't support __int128 and requires SSE for TImode.
We may need to limit those testcases for int128 target.
OK, I'll add: /* { dg-require-effective-target int128 } */.
If it is an ABI, we can add a testcase to gcc.target/x86_64/abi
for x86-64. If there is no additional issues for x86-64, I think
we can close it after checking in those testcases.
This issue is performance-related, not ABI-related, per the discussion replies.
The tests will FAIL on the current compiler because it does not assign TI mode
to 128 bit struct's. The tests PASS if the suggested MAX_FIXED_MODE_SIZE
definition is added to config/i386/i386.h.
Note: Applying the new MAX_FIXED_MODE_SIZE definition patch will result in at
least one GCC test regression (see comment #9).
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck gary at intrepid dot com changed: What|Removed |Added Attachment #27995|0 |1 is obsolete|| --- Comment #22 from Gary Funck gary at intrepid dot com 2012-08-12 21:45:09 UTC --- Created attachment 28000 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28000 test case #1 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck gary at intrepid dot com changed: What|Removed |Added Attachment #27996|0 |1 is obsolete|| --- Comment #23 from Gary Funck gary at intrepid dot com 2012-08-12 21:47:47 UTC --- Created attachment 28001 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28001 test case #2 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 Gary Funck gary at intrepid dot com changed: What|Removed |Added Attachment #27997|0 |1 is obsolete|| --- Comment #24 from Gary Funck gary at intrepid dot com 2012-08-12 21:50:33 UTC --- Created attachment 28002 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28002 test case #3 - struct targeted to TImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #25 from Gary Funck gary at intrepid dot com 2012-08-12 22:08:50 UTC --- (In reply to comment #20) X86 doesn't support __int128 and requires SSE for TImode. We may need to limit those testcases for int128 target. If targeting struct's to TImode is supported on x86 targets then perhaps this definition will need to be refer to 128 bit target support? #define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode) Off-hand, I don't know the target macro that does this. something like this? #define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode : DImoe
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #26 from Gary Funck gary at intrepid dot com 2012-08-12 22:14:56 UTC --- Typo fixed below: #define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode : DImode
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
--- Comment #28 from Gary Funck gary at intrepid dot com 2012-08-12 22:43:16
UTC ---
(In reply to comment #27)
Please try this patch:
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index c4d85b7..6c4c2ce 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1853,6 +1853,10 @@ do {\
/* #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) 0 */
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
/* Define this macro if it is as good or better to call a constant
function address than to call an address kept in a register.
That's the patch that I have been using and testing against (ref: comment #9).
I suggested this:
#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImode
because it might allow x86 targets with SSE to also target TIMode for 128 bit
struct's (on the assumption that TImode will be more efficient).
[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142 --- Comment #7 from Gary Funck gary at intrepid dot com 2012-08-11 01:24:37 UTC --- We're still running into this build failure on PPC64, using a recent revision of the HEAD version. Is there additional information that is needed to help track down the cause of the build failure?
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020 --- Comment #14 from Gary Funck gary at intrepid dot com 2012-08-11 03:22:34 UTC --- (In reply to comment #13) Is this bug obsolete now? Comment #7 (2005-06-25) states that this is a valid bug, and near as I can tell the current compiler still does not target 16-byte aligned (or potentially aligned) struct's into TImode values. Thus, I don't see any technical reason mentioned in the subsequent comments that describe why this bug should be marked as obsolete.
[Bug target/54142] New: ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142 Bug #: 54142 Summary: ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Target: powerpc64 On several PPC64 systems, we are seeing the following build failure. /home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/ [...] -I/home/garyf/gcc-4.8/src/libgcc/../libdecnumber -DHAVE_CC_TLS -o _gcov_execle.o -MT _g cov_execle.o -MD -MP -MF _gcov_execle.dep -DL_gcov_execle -c /home/garyf/gcc-4. 8/src/libgcc/libgcov.c /tmp/ccqVYRai.s: Assembler messages: /tmp/ccqVYRai.s:63: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:66: Error: Unrecognized opcode: `srdi' /tmp/ccqVYRai.s:67: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:73: Error: Unrecognized opcode: `srdi' /tmp/ccqVYRai.s:74: Error: Unrecognized opcode: `sldi' /tmp/ccqVYRai.s:88: Error: Unrecognized opcode: `sldi' The failures above use the gcc-4.8-20120729 snapshot which is based on svn revision 189947. The configure target is: powerpc64-unknown-linux-gnu This was built on a rather old (FC6) system running on a Mac G5, but we have seen it also fail on newer PPC64 systems.
[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-07-31 16:12:18 UTC --- We have determined that we can bypass the failure with the following configure switches: --with-long-double-128 --with-cpu-32=power4 --with-tune-32=power6 --with-cpu-64=power4 --with-tune-64=power6 This binutils email thread may be relevant: http://sources.redhat.com/ml/binutils/2010-07/msg00260.html The assembler that we're using is based on binutils 2.20.51.0.2 which is circa the July, 2010 time frame.
