[Bug rtl-optimization/82020] ICE in decompose at rtl.h:2126

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82020

--- Comment #4 from Tom de Vries  ---
Author: vries
Date: Mon Nov 20 08:20:35 2017
New Revision: 254944

URL: https://gcc.gnu.org/viewcvs?rev=254944&root=gcc&view=rev
Log:
Fix comparison mode in simplify_ternary_operation

2017-11-20  Tom de Vries  

PR rtl-optimization/82020
* simplify-rtx.c (simplify_ternary_operation): Fix comparison mode of
IF_THEN_ELSE condition.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
While x86_64/i686 bootstrap worked, there are hundreds of regressions, e.g.
+FAIL: c-c++-common/attr-warn-unused-result.c  -Wc++-compat  (test for excess
errors)
+FAIL: gcc.dg/always_inline3.c  (test for errors, line 5)
+FAIL: gcc.dg/always_inline3.c (test for excess errors)
+FAIL: gcc.dg/inline-3.c scan-assembler-not big_function_2
+FAIL: gcc.dg/pr45083.c  (test for warnings, line 12)
+FAIL: gcc.dg/pr78973-2.c ilp32 (test for warnings, line 16)
+FAIL: gcc.dg/stack-check-2.c scan-tree-dump-not optimized "tail call"
+FAIL: gcc.dg/stack-check-2.c scan-tree-dump-not tailc "tail call"
+FAIL: gcc.dg/uninit-19.c  (test for warnings, line 14)
+FAIL: gcc.dg/uninit-19.c (test for excess errors)
+FAIL: gcc.dg/winline-3.c  (test for warnings, line 5)
+FAIL: gcc.dg/winline-3.c (test for excess errors)
+FAIL: gcc.dg/winline-5.c  (test for warnings, line 5)
+FAIL: gcc.dg/winline-5.c (test for excess errors)
+FAIL: gcc.dg/winline-6.c  (test for warnings, line 5)
+FAIL: gcc.dg/winline-6.c (test for excess errors)
+FAIL: gcc.dg/winline-7.c (test for excess errors)
+FAIL: gcc.dg/winline-9.c  (test for warnings, line 13)
+FAIL: gcc.dg/winline-9.c (test for excess errors)
+FAIL: gcc.dg/ipa/iinline-1.c scan-ipa-dump inline "hooray[^n]*inline copy
in test"
+FAIL: gcc.dg/ipa/iinline-1.c scan-ipa-dump inline "indirect_call"
+FAIL: gcc.dg/ipa/iinline-2.c scan-ipa-dump inline "hip2[^n]*inline copy in
main"
+FAIL: gcc.dg/ipa/iinline-2.c scan-ipa-dump inline "hooray[^n]*inline copy
in main"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray1[^n]*inline copy
in test1"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray2[^n]*inline copy
in test2"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray3[^n]*inline copy
in test3"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray4[^n]*inline copy
in test4"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray5[^n]*inline copy
in test5"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray6[^n]*inline copy
in test6"
+FAIL: gcc.dg/ipa/iinline-4.c scan-ipa-dump inline "hooray7[^n]*inline copy
in test7"
+FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^n]*inline
copy in test"
+FAIL: gcc.dg/ipa/iinline-cstagg-1.c scan-ipa-dump inline
"thisisthetarget[^n]*inline copy in outerfunction"
+FAIL: gcc.dg/ipa/iinline-cstagg-2.c scan-ipa-dump inline
"thisisthetarget[^n]*inline copy in outerfunction"
+FAIL: gcc.dg/ipa/inline-2.c scan-ipa-dump inline "op3 change 1.00. of
time"
+FAIL: gcc.dg/ipa/inline-3.c scan-ipa-dump inline "Scaling time by
probability:0.10"
+FAIL: gcc.dg/ipa/inline-4.c scan-ipa-dump inline "Inlined 1 calls, eliminated
0 functions"
+FAIL: gcc.dg/ipa/inline-4.c scan-ipa-dump-times inline "predicate: .false." 8
(found 0 times)
+FAIL: gcc.dg/ipa/inline-6.c scan-ipa-dump-times inline "Inlined into" 2 (found
0 times)
+FAIL: gcc.dg/ipa/inlinehint-1.c scan-ipa-dump inline "loop_iterations"
+FAIL: gcc.dg/ipa/inlinehint-2.c scan-ipa-dump inline "loop_stride"
+FAIL: gcc.dg/ipa/inlinehint-3.c scan-ipa-dump inline "in_scc"
+FAIL: gcc.dg/ipa/inlinehint-3.c scan-ipa-dump inline "same_scc"
+FAIL: gcc.dg/ipa/inlinehint-4.c scan-ipa-dump inline "Inlined lookup into
test"
+FAIL: gcc.dg/ipa/inlinehint-4.c scan-ipa-dump inline "Wrapper penalty"
+FAIL: gcc.dg/ipa/ipcp-agg-9.c scan-ipa-dump inline "hooray1[^n]*inline
copy in hiphip1"
+FAIL: gcc.dg/ipa/ipcp-ii-1.c scan-ipa-dump inline "hooray[^n]*inline copy
in hiphip.constprop"
+FAIL: gcc.dg/ipa/pr63416.c scan-tree-dump-not optimized "test_f3"
+FAIL: gcc.dg/ipa/pure-const-1.c scan-ipa-dump pure-const "found to be const:
i_am_const3"
+FAIL: gcc.dg/ipa/pure-const-1.c scan-tree-dump-times optimized "i_am_const3
.5" 1 (found 2 times)
+FAIL: gcc.dg/ipa/remref-0.c scan-ipa-dump inline "ipa-prop: Removed a
reference"
+FAIL: gcc.dg/ipa/remref-0.c scan-tree-dump-not optimized "hooray"
+FAIL: gcc.dg/ipa/remref-1a.c scan-ipa-dump inline "ipa-prop: Removed a
reference"
+FAIL: gcc.dg/ipa/remref-1a.c scan-tree-dump-not optimized "hooray"
+FAIL: gcc.dg/ipa/remref-1b.c scan-ipa-dump inline "ipa-prop: Removed a
reference"
+FAIL: gcc.dg/ipa/remref-1b.c scan-tree-dump-not optimized "hooray"
+FAIL: gcc.dg/ipa/remref-2a.c scan-ipa-dump-times inline "ipa-prop: Removed a
reference" 2 (found 0 times)
+FAIL: gcc.dg/ipa/remref-2a.c scan-tree-dump-not optimized "hooray"
+FAIL: gcc.dg/ipa/remref-2b.c scan-ipa-dump inline "ipa-prop: Removed a
reference"
+FAIL: gcc.dg/ipa/remref-2b.c scan-ipa-dump-times inline "ipa-prop: Removing
cloning-created reference" 2 (found 0 times)
+FAIL: gcc.dg/ipa/remref-2b.c scan-tree-dump-not optimized "hooray"
and many othe

[Bug ipa/60243] IPA is slow on large cgraph tree

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243

--- Comment #20 from rguenther at suse dot de  ---
On Sun, 19 Nov 2017, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
> 
> --- Comment #19 from Jan Hubicka  ---
> Author: hubicka
> Date: Sun Nov 19 18:55:30 2017
> New Revision: 254934
> 
> URL: https://gcc.gnu.org/viewcvs?rev=254934&root=gcc&view=rev
> Log:
> PR ipa/60243
> * tree-inline.c (estimate_num_insns): Set to 1 at least.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/tree-inline.c

While this fixes the new regression the appearant IPA SRA quadraticness
remains.

I'll add the testcase to our "random" set of testcases in the C++ bench.

[Bug rtl-optimization/82020] ICE in decompose at rtl.h:2126

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82020

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Tom de Vries  ---
Patch committed to trunk, test-case not required.

Marking resolved-fixed.

[Bug c++/83060] ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83060

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Guess we should diagnose and return error_mark_node from fold_offsetof_1.  Will
have a look.

[Bug c++/83059] ICE on invalid C++ code: in tree_to_uhwi, at tree.c:6633

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83059

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
get_atomic_generic_size bug, will fix.

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83041

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Both references get alias-set zero.  Given we do not know the dynamic type of
'a'
there can be very well a struct A live at that point which means p might point
to a.  For g there cannot be a B at a because it won't fit.

We do not figure the "redundant" assignments because we're not able to
CSE p->a[0] to the previous a[0] store.  This "trick" is not implemented.

I think we have a duplicate bug for this looking like

void foo (int *p, int *q)
{
  *p = 1;
  *q = 1;
  return *p;
}

which we should be able to optimize to return 1.

[Bug preprocessor/83063] New: [8 Regression] ICE on an invalid preprocessor snippet

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83063

Bug ID: 83063
   Summary: [8 Regression] ICE on an invalid preprocessor snippet
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r254707 we do an invalid read on:

$ cat ice.cpp
#define a(...) b##__VA_OPT__ ()
a ()

$ valgrind --leak-check=yes --trace-children=yes g++ ice.cpp
==18518== Memcheck, a memory error detector
==18518== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18518== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==18518== Command: g++ ice.cpp
==18518== 
==18520== Memcheck, a memory error detector
==18520== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18520== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==18520== Command:
/home/marxin/bin/gcc/lib/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus -quiet
-D_GNU_SOURCE ice.cpp -quiet -dumpbase ice.cpp -mtune=generic -march=x86-64
-auxbase ice -o /tmp/ccqffetG.s
==18520== 
==18520== Use of uninitialised value of size 8
==18520==at 0x16C6D0B: paste_all_tokens (macro.c:889)
==18520==by 0x16C6D0B: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2636)
==18520==by 0x8CE7AE: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:399)
==18520==by 0x75164E: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:793)
==18520==by 0x792E23: cp_parser_initial_pragma (parser.c:38614)
==18520==by 0x792E23: cp_lexer_new_main (parser.c:647)
==18520==by 0x792E23: cp_parser_new (parser.c:3859)
==18520==by 0x792E23: c_parse_file() (parser.c:39019)
==18520==by 0x8DA226: c_common_parse_file() (c-opts.c:1127)
==18520==by 0xDC0C8E: compile_file() (toplev.c:455)
==18520==by 0x60A5E4: do_compile (toplev.c:2059)
==18520==by 0x60A5E4: toplev::main(int, char**) (toplev.c:2194)
==18520==by 0x60C8AA: main (main.c:39)
==18520== 
==18520== Invalid read of size 1
==18520==at 0x16C6D0B: paste_all_tokens (macro.c:889)
==18520==by 0x16C6D0B: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2636)
==18520==by 0x8CE7AE: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:399)
==18520==by 0x75164E: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:793)
==18520==by 0x792E23: cp_parser_initial_pragma (parser.c:38614)
==18520==by 0x792E23: cp_lexer_new_main (parser.c:647)
==18520==by 0x792E23: cp_parser_new (parser.c:3859)
==18520==by 0x792E23: c_parse_file() (parser.c:39019)
==18520==by 0x8DA226: c_common_parse_file() (c-opts.c:1127)
==18520==by 0xDC0C8E: compile_file() (toplev.c:455)
==18520==by 0x60A5E4: do_compile (toplev.c:2059)
==18520==by 0x60A5E4: toplev::main(int, char**) (toplev.c:2194)
==18520==by 0x60C8AA: main (main.c:39)
==18520==  Address 0x4 is not stack'd, malloc'd or (recently) free'd

[Bug target/82852] [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82852

--- Comment #2 from Andrey Guskov  ---
Yeah, seems like it`s gone.

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851

Andrey Guskov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrey Guskov  ---
Yes.

[Bug target/82852] [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82852

Andrey Guskov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0

--- Comment #3 from Markus Trippelsdorf  ---
Started with r54937.

Another testcase:

trippels@gcc2-power8 ~ % cat scavenger.ii
struct A {
  virtual void VisitPointers(int *, int **, int **) = 0;
  virtual void VisitNextCodeLink() { VisitPointers(0, 0, 0); }
};
struct B : A {
  __attribute__((always_inline)) void VisitPointers(int *, int **, int **);
};
void B::VisitPointers(int *, int **, int **) {}

trippels@gcc2-power8 ~ % g++ -O3 -c scavenger.ii
scavenger.ii:8:6: warning: always_inline function might not be inlinable
[-Wattributes]
 void B::VisitPointers(int *, int **, int **) {}
  ^
scavenger.ii: In member function ‘virtual void A::VisitNextCodeLink()’:
scavenger.ii:8:6: error: inlining failed in call to always_inline ‘virtual void
B::VisitPointers(int*, int**, int**)’: caller is not optimized
scavenger.ii:3:51: note: called from here
   virtual void VisitNextCodeLink() { VisitPointers(0, 0, 0); }
  ~^

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

--- Comment #4 from Markus Trippelsdorf  ---
Sorry, started with r254937.

[Bug rtl-optimization/82180] assign_spill_hard_regs spills to unaligned register pair

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82180

Tom de Vries  changed:

   What|Removed |Added

 CC||kcy at codesourcery dot com

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> Trying a bit harder, I can fix the problem by skipping over the unaligned
> register here:
> ...
> diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
> index 492fc18..6ecfad2 100644
> --- a/gcc/lra-spills.c
> +++ b/gcc/lra-spills.c
> @@ -276,7 +276,10 @@ assign_spill_hard_regs (int *pseudo_regnos, int n)
>for (k = 0; k < spill_class_size; k++)
> {
>   hard_regno = ira_class_hard_regs[spill_class][k];
> - if (! overlaps_hard_reg_set_p (conflict_hard_regs, mode,
> hard_regno))
> + if (!
> ira_prohibited_class_mode_regs[spill_class][PSEUDO_REGNO_MODE (regno)]
> + && ! overlaps_hard_reg_set_p (conflict_hard_regs, mode,
> +   hard_regno))
> break;
> }
>if (k >= spill_class_size)
> ...
> 

Kwok has pointed out that in fact ira_prohibited_class_mode_regs is a
HARD_REG_SET which needs to be tested using TEST_HARD_REG_BIT.

[Bug tree-optimization/83053] [8 Regression] ICE in vrp_prop::check_array_ref at cc/tree-vrp.c:4811

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83053

--- Comment #2 from Martin Liška  ---
I see in tree-vrp.c:4804:

(gdb) p print_generic_expr(stderr, ref, 0)
*array.0_159[0]$10 = void
(gdb) p debug_tree(ref)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 8 canonical-type
0x769bc9d8 context 
pointer_to_this  chain >

arg:0 
type_2 BLK size  unit-size

align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769cae70 domain 
pointer_to_this >

arg:0 
visited var 
def_stmt array.0_159 = *array_281._data.data;
version:159
ptr-info 0x76639528>
arg:1 
   
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0
start:
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0
finish:
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0>
arg:1  constant 0>
   
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0
start:
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0
finish:
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:97:0>

$ (gdb) p debug_tree((tree)0x769cae70)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 8 canonical-type
0x769bc9d8 context 
pointer_to_this  chain >
type_2 BLK size  unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769cae70
domain 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 11 canonical-type
0x76827738 precision:64 min  max 
pointer_to_this >
DI size  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
precision:64 min  max >
pointer_to_this >

(gdb) p debug_tree(maxbound)
 
constant 9223372036854775807>
$13 = void
(gdb) p debug_tree(eltsize)
 
constant 0>

Thus there's division by zero and we end up with up_bound_p1 == NULL_TREE.
I'm testing that with r254943 with:

 ./f951
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
-quiet -dumpbase actual_array_offset_1.f90 -mtune=generic -march=x86-64
-auxbase actual_array_offset_1 -O2 -Warray-bounds=1 -version
-fintrinsic-modules-path finclude -o /tmp/ccU1hBES.s

[Bug tree-optimization/83043] [8 Regression] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83043

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|FAIL:   |[8 Regression] FAIL:
   |libgomp.graphite/force-para |libgomp.graphite/force-para
   |llel-1.c|llel-1.c
   |scan-tree-dump-times|scan-tree-dump-times
   |graphite "2 loops carried   |graphite "2 loops carried
   |no dependency" 1 (found 0   |no dependency" 1 (found 0
   |times)  |times)

--- Comment #5 from Richard Biener  ---
Possibly some optimize_loop_nest_for_speed check changes.

[Bug c++/83045] [8 Regression] -Wreturn-type regression in C++

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83045

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |8.0
Summary|-Wreturn-type regression in |[8 Regression]
   |C++ |-Wreturn-type regression in
   ||C++

[Bug tree-optimization/83044] [8 Regression] ice in contains_struct_check

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83044

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |8.0
Summary|ice in  |[8 Regression] ice in
   |contains_struct_check   |contains_struct_check

[Bug rtl-optimization/82180] assign_spill_hard_regs spills to unaligned register pair

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82180

--- Comment #4 from Tom de Vries  ---
Created attachment 42656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42656&action=edit
Tentative patch

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83047

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/83049] Allow overloading of ?: conditional operator

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83049

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/83052] [8 Regression] ICE in extract_insn, at recog.c:2305 starting from r254560

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83052

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
Version|7.0 |8.0
   Target Milestone|--- |8.0
Summary|ICE in extract_insn, at |[8 Regression] ICE in
   |recog.c:2305 starting from  |extract_insn, at
   |r254560 |recog.c:2305 starting from
   ||r254560

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83051

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O3:   |[8 Regression] ICE on valid
   |in edge_badness, at |code at -O3: in
   |ipa-inline.c:1024   |edge_badness, at
   ||ipa-inline.c:1024

[Bug ipa/83054] [8 Regression] ICE in operator>, at profile-count.h:823

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83054

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug c++/83058] [8 Regression] ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83058

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|ICE on C++ code with|[8 Regression] ICE on C++
   |negative array index: in|code with negative array
   |warn_placement_new_too_smal |index: in
   |l, at cp/init.c:2666|warn_placement_new_too_smal
   ||l, at cp/init.c:2666

[Bug fortran/83064] New: DO CONCURRENT inconsistent results

[cfztol at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064

Bug ID: 83064
   Summary: DO CONCURRENT inconsistent results
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cfztol at hotmail dot com
  Target Milestone: ---

This bug is related to 83017. I'm trying to parallelize a pure function with
the do concurrent construct. The following table shows compile flags and
results from the test program at the end of this message. GCC revision r254890:

Unrolled do-loop

Options   Parallel  Correct
-Og-ftree-parallelize-loops=2 N Y
-O1-ftree-parallelize-loops=2 Y N - arbitrary
-O2-ftree-parallelize-loops=2 Y N - always zero
-O3-ftree-parallelize-loops=2 Y Y
-Ofast -ftree-parallelize-loops=2 Y Y

Modulo inside do-loop, or Indexed via host associated array

Options   Parallel  Correct
-Og-ftree-parallelize-loops=2 N Y
-O1-ftree-parallelize-loops=2 Y N - arbitrary
-O2-ftree-parallelize-loops=2 Y N - arbitrary
-O3-ftree-parallelize-loops=2 Y N - arbitrary
-Ofast -ftree-parallelize-loops=2 Y N - arbitrary

So the loop is parallelized always, unless -Og optimization level is used.
However, the computed value of PI is only correct in a few cases, depending of
optimization level and details of the pure function. I think that is a bug -
especially since consecutive runs give different results (marked with
"arbitrary" in the table above).

Here's my test program:

program main
use, intrinsic :: iso_fortran_env
implicit none

integer, parameter :: nsplit = 4
integer(int64), parameter :: ne = 2
integer(int64) :: stride, low(nsplit), high(nsplit), edof(ne), i
real(real64), dimension(nsplit) :: pi

edof(1::4) = 1
edof(2::4) = 2
edof(3::4) = 3
edof(4::4) = 4

stride = ceiling(real(ne)/nsplit)
do i = 1, nsplit
high(i) = stride*i
end do
do i = 2, nsplit
low(i) = high(i-1) + 1
end do
low(1) = 1
high(nsplit) = ne

pi = 0
do concurrent (i = 1:nsplit)
pi(i) = sum(compute( low(i), high(i) ))
end do
print *, "PI", 4*sum(pi)
print *, "PI", 4*atan(1.0)

contains

pure function compute( low, high ) result( tmp )
integer(int64), intent(in) :: low, high
real(real64), dimension(nsplit) :: tmp
integer(int64) :: j, k

tmp = 0

! Unrolled loop
! do j = low, high, 4
! k = 1
! tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 ) 
! k = 2
! tmp(k) = tmp(k) + (-1)**(j+2) / real( 2*j+1 ) 
! k = 3
! tmp(k) = tmp(k) + (-1)**(j+3) / real( 2*j+3 ) 
! k = 4
! tmp(k) = tmp(k) + (-1)**(j+4) / real( 2*j+5 ) 
! end do

! Loop with modulo operation
! do j = low, high
! k = mod( j, nsplit ) + 1
! tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 ) 
! end do

! Loop with subscripting via host association
do j = low, high
k = edof(j)
tmp(k) = tmp(k) + (-1.0_real64)**(j+1) / real( 2*j-1 )  
end do
end function

end program main

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008

--- Comment #4 from rguenther at suse dot de  ---
On Sun, 19 Nov 2017, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
> 
> Jan Hubicka  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-11-19
>  Ever confirmed|0   |1
> 
> --- Comment #3 from Jan Hubicka  ---
> I now get fir first loop:
> 
> 
> a.c:6:5: note: Cost model analysis:   
>   
>   Vector inside of loop cost: 1120
>   
>   Vector prologue cost: 0 
>   
>   Vector epilogue cost: 0 
>   
>   Scalar iteration cost: 328  
>   
>   Scalar outside cost: 0  
>   
>   Vector outside cost: 0  
>   
>   prologue iterations: 0  
>   
>   epilogue iterations: 0  
>   
>   Calculated minimum iters for profitability: 0   
>   
> a.c:6:5: note:   Runtime profitability threshold = 4  
>   
> a.c:6:5: note:   Static estimate profitability threshold = 4  
>   
> 
> For second lop I get:
> 
> a.c:20:5: note: type of def: internal 
>   
> a.c:20:5: note: mark relevant 1, live 0: sum.0_60 = (unsigned int) sum_102;   
>   
> a.c:20:5: note: worklist: examine stmt: sum.0_60 = (unsigned int) sum_102;
>   
> a.c:20:5: note: vect_is_simple_use: operand sum_102   
>   
> a.c:20:5: note: def_stmt: sum_102 = PHI <0(6), sum_75(7)> 
>   
> a.c:20:5: note: type of def: unknown  
>   
> a.c:20:5: note: Unsupported pattern.  
>   
> a.c:20:5: note: not vectorized: unsupported use in stmt.  
>   
> a.c:20:5: note: unexpected pattern.   
> 
> Is it really that hard to sum values in vector?  

The issue is the vectorizer doesn't currently handle conversions:

t.c:20:5: note: Analyze phi: sum_102 = PHI <0(6), sum_75(7)>
t.c:20:5: note: reduction: not commutative/associative: sum_75 = (int) 
_61;

I have patches to fix that though.  Sitting somewhere...  see PR65930.

[Bug c++/83040] __attribute__((always_inline)) causes internal_compiler_error (segmentation fault) (with recursive meta-template programming function)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83040

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1
  Known to fail||7.2.1

--- Comment #1 from Richard Biener  ---
"don't do this"?  Or use constexpr?  That you need to bump the template-depth
should already tell you you're doing sth that's bad.

Anyway, confirmed with GCC 7.2, note that GCC 5 is no longer maintained.

[Bug lto/83061] -Wmaybe-uninitialized warnings in gcc/lto/lto-object.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83061

--- Comment #1 from Richard Biener  ---
Well, the warnings are false positives given the uses are guarded with an error
check (that can never trigger due to implementation details).

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
I think it's a typo, should be:

diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 4f1860fb284..2c2706897d9 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -325,7 +325,7 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
   inlinable = false;
 }
   if (!early && (!opt_for_fn (callee->decl, optimize)
-|| opt_for_fn (caller->decl, optimize)))
+|| !opt_for_fn (caller->decl, optimize)))
 {
   e->inline_failed = CIF_FUNCTION_NOT_OPTIMIZED;
   inlinable = false;

Honza?

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83047

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Heh, what a coincidence!  This is something I run into while working on the
bswap store-merging support, from wondering why bswap pass needs dominance info
I've noticed it uses it exactly to pick the last from the loads rather than say
the first one if it is in multiple basic blocks and added to my todo list that
that is something needed for the store merging itself too.

Note, it probably isn't sufficient, we could have:
  int a = q[0];
  foo (a); /* Some function that conditionally exits, throws externally or
loops forever.  */
  int b = q[1]; /* q[1] might not be mapped if foo exits/throws/loops forever. 
*/
  p[0] = a;
  p[1] = b;
Wonder if we need to (perhaps lazily) compute uids of stmts in certain bbs and
use that to compute which of the loads is last.

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83047

--- Comment #5 from Jakub Jelinek  ---
Created attachment 42657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42657&action=edit
gcc8-pr83047.patch

Untested fix.

[Bug ipa/83065] New: [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83065

Bug ID: 83065
   Summary: [8 Regression] SPEC CPU2017 523/623 compfail (ICE)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r254834 triggers this fail @ 523/623 base6, both on Intel Haswell and Intel
Silvermont:

during IPA pass: inline
lto1: internal compiler error: in to_cgraph_frequency, at profile-count.c:252
0x66f1a5 profile_count::to_cgraph_frequency(profile_count) const
../../../gcc/gcc/profile-count.c:252
0xb0f819 cgraph_edge::frequency()
../../../gcc/gcc/cgraph.h:3121
0xb0f819 ipa_propagate_frequency_1
../../../gcc/gcc/ipa-profile.c:343
0xb0fc4d cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../../gcc/gcc/cgraph.h:3216
0xb0fc4d ipa_propagate_frequency(cgraph_node*)
../../../gcc/gcc/ipa-profile.c:411
0xafcbf9 inline_update_callee_summaries
../../../gcc/gcc/ipa-fnsummary.c:2833
0xafcd33 inline_update_callee_summaries
../../../gcc/gcc/ipa-fnsummary.c:2837
0xafcd33 inline_update_callee_summaries
../../../gcc/gcc/ipa-fnsummary.c:2837
0xafcd33 inline_update_callee_summaries
../../../gcc/gcc/ipa-fnsummary.c:2837
0xafdea9 ipa_merge_fn_summary_after_inlining(cgraph_edge*)
../../../gcc/gcc/ipa-fnsummary.c:3083
0x13bc7d4 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../../gcc/gcc/ipa-inline-transform.c:448
0x13b4f7a inline_small_functions
../../../gcc/gcc/ipa-inline.c:2033
0x13b4f7a ipa_inline
../../../gcc/gcc/ipa-inline.c:2441
0x13b4f7a execute
../../../gcc/gcc/ipa-inline.c:2848
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/6023] Unhelpful error message with forgotten "template"

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6023

Paolo Carlini  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 CC|klaus.kretschel at dlr dot de  |
 Resolution|--- |FIXED

--- Comment #9 from Paolo Carlini  ---
I think we can close this one.

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Mon Nov 20 09:55:02 2017
New Revision: 254946

URL: https://gcc.gnu.org/viewcvs?rev=254946&root=gcc&view=rev
Log:
PR bootstrap/83062
* ipa-inline.c (can_inline_edge_p): Fix typo in previous patch.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83062

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Markus Trippelsdorf  ---
Thanks for the quick fix.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 20 10:10:23 2017
New Revision: 254948

URL: https://gcc.gnu.org/viewcvs?rev=254948&root=gcc&view=rev
Log:
PR tree-optimization/78821
* gimple-ssa-store-merging.c (find_bswap_or_nop_load): Give up
if base is TARGET_MEM_REF.  If base is not MEM_REF, set base_addr
to the address of the base rather than the base itself.
(find_bswap_or_nop_1): Just use pointer comparison for vuse check.
(find_bswap_or_nop_finalize): New function.
(find_bswap_or_nop): Use it.
(bswap_replace): Return a tree rather than bool, change first
argument from gimple * to gimple_stmt_iterator, allow inserting
into an empty sequence, allow ins_stmt to be NULL - then emit
all stmts into gsi.  Fix up MEM_REF address gimplification.
(pass_optimize_bswap::execute): Adjust bswap_replace caller.
(struct store_immediate_info): Add N and INS_STMT non-static
data members.
(store_immediate_info::store_immediate_info): Initialize them
from newly added ctor args.
(merged_store_group::apply_stores): Formatting fixes.  Sort by
bitpos at the end.
(stmts_may_clobber_ref_p): For stores call also
refs_anti_dependent_p.
(gather_bswap_load_refs): New function.
(imm_store_chain_info::try_coalesce_bswap): New method.
(imm_store_chain_info::coalesce_immediate_stores): Use it.
(split_group): Handle LROTATE_EXPR and NOP_EXPR rhs_code specially.
(imm_store_chain_info::output_merged_store): Fail if number of
new estimated stmts is bigger or equal than old.  Handle LROTATE_EXPR
and NOP_EXPR rhs_code.
(pass_store_merging::process_store): Compute n and ins_stmt, if
ins_stmt is non-NULL and the store rhs is otherwise invalid, use
LROTATE_EXPR rhs_code.  Pass n and ins_stmt to store_immediate_info
ctor.
(pass_store_merging::execute): Calculate dominators.

* gcc.dg/store_merging_16.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/store_merging_16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83045] [8 Regression] -Wreturn-type regression in C++

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83045

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, problem is following: before the patch we emitted return statement
that was caught in tree-cfg.c. Now we end up with:

test2 (int a)
{
   :
  if (a != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  __builtin_unreachable ();

}

Thus the warnings in tree-cfg can't see that. On the other hand, having a
function that doesn't do an abnormal return:

test2 (int a)
{
   :
  if (a != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  foo ();

   :
  __builtin_unreachable ();

}

C++ FE warning is triggered:

/home/marxin/Programming/testcases/pr83045-2.c: In function ‘int test2(int)’:
/home/marxin/Programming/testcases/pr83045-2.c:15:1: warning: no return
statement in function returning non-void [-Wreturn-type]

That said, I don't know how to fix that properly?

[Bug tree-optimization/83044] [8 Regression] ice in contains_struct_check

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83044

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
*** Bug 83053 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/83053] [8 Regression] ICE in vrp_prop::check_array_ref at cc/tree-vrp.c:4811

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83053

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Liška  ---
The origin PR contains more easier C test-case.

*** This bug has been marked as a duplicate of bug 83044 ***

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015

--- Comment #3 from Jan Hubicka  ---
Terbium however now fails with
In file included from
/gcc/spec/sb-terbium-head-64/gcc/libgcc/config/ia64/unwind-ia64.c:2448:
/gcc/spec/sb-terbium-head-64/gcc/libgcc/unwind.inc: In function
'_Unwind_Resume_or_Rethrow':
/gcc/spec/sb-terbium-head-64/gcc/libgcc/unwind.inc:273:3: error: too many
arguments to function 'uw_install_context'
   uw_install_context (&this_context, &cur_context, frames);
   ^~
/gcc/spec/sb-terbium-head-64/gcc/libgcc/config/ia64/unwind-ia64.c:2167:1: note:
declared here
 uw_install_context (struct _Unwind_Context *current __attribute__((unused)),

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015

Jan Hubicka  changed:

   What|Removed |Added

 CC||igor.v.tsimbalist at intel dot 
com

--- Comment #4 from Jan Hubicka  ---
Igor, the unwind issue seems to be yours.

[Bug libstdc++/83066] New: [8 regression] 26_numerics/gcd/gcd_neg.cc fails since r254736

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83066

Bug ID: 83066
   Summary: [8 regression] 26_numerics/gcd/gcd_neg.cc fails since
r254736
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r254736 I have noticed that gcd_neg.cc now fails on:
26_numerics/gcd/gcd_neg.cc  (test for errors, line 30)
26_numerics/gcd/gcd_neg.cc  (test for errors, line 138)
26_numerics/gcd/gcd_neg.cc  (test for errors, line 36)
26_numerics/gcd/gcd_neg.cc  (test for errors, line 40)

[Bug c++/55826] -ftime-report causes internal compiler error with Boost.Asio

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55826

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
Closing as fixed. I can't reproduce the issue anymore, anywhere. Otherwise,
please re-open.

[Bug c++/83060] ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83060

--- Comment #2 from Paolo Carlini  ---
Related to PR82872?

[Bug lto/83061] -Wmaybe-uninitialized warnings in gcc/lto/lto-object.c

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83061

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Markus Trippelsdorf  ---
Yes, it was caused by Honza's inliner typo.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #17 from Uroš Bizjak  ---
Hm, even with the latest patch, the testcase from comment #5:

typedef __SIZE_TYPE__ size_t;

void baz (char *buf, unsigned int data)
{
  buf[0] = data;
  buf[1] = data >> 8;

  buf[2] = ~data >> 8;
  buf[3] = ~data;
}

still compiles to:

movl%esi, %eax
movw%si, (%rdi)
notl%esi
notl%eax
movb%sil, 3(%rdi)
movb%ah, 2(%rdi)
ret

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[igor.v.tsimbalist at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015

--- Comment #5 from igor.v.tsimbalist at intel dot com ---
Created attachment 42658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42658&action=edit
patch

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83046

--- Comment #3 from Martin Liška  ---
(In reply to Thomas Schwinge from comment #0)
> ... starting with r254437 "Instrument function exit with
> __builtin_unreachable in C++".
> 
> Program received signal SIGSEGV, Segmentation fault.
> input_offload_tables (do_force_output=true) at
> [...]/source-gcc/gcc/lto-cgraph.c:1942
> 1942varpool_node::get (var_decl)->force_output = 1;
> (gdb) bt
> #0  input_offload_tables (do_force_output=true) at
> [...]/source-gcc/gcc/lto-cgraph.c:1942
> #1  0x005a0927 in read_cgraph_and_symbols (fnames= out>, nfiles=) at [...]/source-gcc/gcc/lto/lto.c:2863
> #2  lto_main () at [...]/source-gcc/gcc/lto/lto.c:3314
> #3  0x00a7f63f in compile_file () at
> [...]/source-gcc/gcc/toplev.c:455
> #4  0x0056ef20 in do_compile () at
> [...]/source-gcc/gcc/toplev.c:2059
> #5  toplev::main (this=this@entry=0x7fffcfb0, argc=argc@entry=15,
> argv=0x17908e0, argv@entry=0x7fffd0b8) at
> [...]/source-gcc/gcc/toplev.c:2194
> #6  0x00571457 in main (argc=15, argv=0x7fffd0b8) at
> [...]/source-gcc/gcc/main.c:39
> 
> Obviously, that test case has a "-Wreturn-type mismatch" (which is not
> diagnosed for C++; see reduced PR83045), and fixing that cures this nvptx
> offloading ICE.

Hello.

Can you please provide steps to reproduce this?

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #18 from Uroš Bizjak  ---
Maybe related to bswap optimization is also:

typedef __SIZE_TYPE__ size_t;

void baz (char *buf, unsigned int data)
{
  buf[0] = data >> 8;
  buf[1] = data;
}

which currently generates (-O2 -march=haswell)

rolw$8, %si
movw%si, (%rdi)

but could use "movbew %si, (%rdi)".

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[igor.v.tsimbalist at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015

--- Comment #6 from igor.v.tsimbalist at intel dot com ---
Andreas has sent this issue as a reply to my commit. I proposed a fix and asked
for approval. Here is my reply

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01647.html

I have attached the patch also.

[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83065

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83063

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/83066] [8 regression] 26_numerics/gcd/gcd_neg.cc fails since r254736

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83066

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/65381] [6/7/8 Regression] ICE during array result, assignment

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Debug make check|[8 Regression] Debug make
   |regressions in GCC 8.0  |check regressions in GCC
   ||8.0

[Bug c++/83059] ICE on invalid C++ code: in tree_to_uhwi, at tree.c:6633

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83059

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42659&action=edit
gcc8-pr83059.patch

Untested fix.

[Bug tree-optimization/81165] [8 Regression] Regression in GCC-8.0.0's optimizer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Regression in GCC-8.0.0's   |[8 Regression] Regression
   |optimizer   |in GCC-8.0.0's optimizer

[Bug fortran/82969] [6/7/8 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82969

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #19 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #17)
> Hm, even with the latest patch, the testcase from comment #5:
> still compiles to:
> 
> movl%esi, %eax
> movw%si, (%rdi)
> notl%esi
> notl%eax
> movb%sil, 3(%rdi)
> movb%ah, 2(%rdi)
> ret

The reason for that is that the IL is something the bswap framework can't
handle.  Let's look just at the simplified:
void baz (char *buf, unsigned int data)
{
  buf[2] = ~data >> 8;
  buf[3] = ~data;
}

  _1 = ~data_6(D);
  _2 = _1 >> 8;
  _3 = (char) _2;
  MEM[(char *)buf_7(D) + 2B] = _3;
  _4 = (char) data_6(D);
  _5 = ~_4;
  MEM[(char *)buf_7(D) + 3B] = _5;

If it was instead:
  _1 = ~data_6(D);
  _2 = _1 >> 8;
  _3 = (char) _2;
  MEM[(char *)buf_7(D) + 2B] = _3;
  _4 = (char) _1;
  MEM[(char *)buf_7(D) + 3B] = _4;
then it would handle that.  So I think it is a missed optimization in FRE or
whatever else does SCCVN, or something match.pd should handle.

As for:
> void baz (char *buf, unsigned int data)
> {
>   buf[0] = data >> 8;
>   buf[1] = data;
> }
not using movbew, that is something that should be done in the backend.
For the middle-end, we don't have bswap16 and consider {L,R}ROTATE_EXPR by 8
as the canonical 16-bit byte swap.  Please also have a look:
unsigned short
baz (unsigned short *buf)
{
  unsigned short a = buf[0];
  return ((unsigned short) (a >> 8)) | (unsigned short) (a << 8);
}
where we could also emit movbew instead of movw + rolw (if it is actually a
win).  Thus, I think i386.md should provide patterns for combine (or peephole2
if the former doesn't work for some reason) for this.

[Bug target/83067] wrong code on arm-linux-gnueabi

[yangyibiao at nju dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83067

--- Comment #1 from Yibiao Yang  ---
Note that this issue was found by Yibiao Yang and shqking.

[Bug target/83067] New: wrong code on arm-linux-gnueabi

[yangyibiao at nju dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83067

Bug ID: 83067
   Summary: wrong code on arm-linux-gnueabi
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
  Target Milestone: ---

$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc --version
gcc --version
gcc (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat small.c
#define f(g) ({ unsigned long long u = (g); -((unsigned long long)(u));})

void main()
{
printf("%d\n", f(65527));
}

$ arm-linux-gnueabi-gcc -static small.c; ./a.out
-150998972

$ gcc small.c; ./a.out
-65527

[Bug c/82963] -Waddress too trigger happy

[arnd at linaro dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82963

Arnd Bergmann  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Arnd Bergmann  ---
The change in gcc-7 was done in r235878 to address pr48778. From reading that
pr, it sounds to me that both warnings should fall into the same category, it's
just that this one is not as common, so nobody has complained before.

[Bug target/83067] wrong code on arm-linux-gnueabi

[yangyibiao at nju dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83067

--- Comment #2 from Yibiao Yang  ---
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/5/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armel-cross
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armel-cross
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv5t --with-float=soft --disable-werror
--enable-multilib --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.1-2ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~16.04)

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #20 from rguenther at suse dot de  ---
On Mon, 20 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821
> 
> --- Comment #19 from Jakub Jelinek  ---
> (In reply to Uroš Bizjak from comment #17)
> > Hm, even with the latest patch, the testcase from comment #5:
> > still compiles to:
> > 
> > movl%esi, %eax
> > movw%si, (%rdi)
> > notl%esi
> > notl%eax
> > movb%sil, 3(%rdi)
> > movb%ah, 2(%rdi)
> > ret
> 
> The reason for that is that the IL is something the bswap framework can't
> handle.  Let's look just at the simplified:
> void baz (char *buf, unsigned int data)
> {
>   buf[2] = ~data >> 8;
>   buf[3] = ~data;
> }
> 
>   _1 = ~data_6(D);
>   _2 = _1 >> 8;
>   _3 = (char) _2;
>   MEM[(char *)buf_7(D) + 2B] = _3;
>   _4 = (char) data_6(D);
>   _5 = ~_4;
>   MEM[(char *)buf_7(D) + 3B] = _5;
> 
> If it was instead:
>   _1 = ~data_6(D);
>   _2 = _1 >> 8;
>   _3 = (char) _2;
>   MEM[(char *)buf_7(D) + 2B] = _3;
>   _4 = (char) _1;
>   MEM[(char *)buf_7(D) + 3B] = _4;
> then it would handle that.  So I think it is a missed optimization in FRE or
> whatever else does SCCVN, or something match.pd should handle.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 254945)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3632,6 +3632,38 @@ visit_nary_op (tree lhs, gassign *stmt)
}
}
}
+case BIT_NOT_EXPR:
+  {
+if (TREE_CODE (rhs1) == SSA_NAME)
+ {
+   gassign *def = dyn_cast  (SSA_NAME_DEF_STMT 
(rhs1));
+   if (def
+   && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def)))
+ {
+   tree ops[3] = {};
+   tree rhs11 = gimple_assign_rhs1 (def);
+   if (TYPE_PRECISION (TREE_TYPE (rhs11))
+   >= TYPE_PRECISION (TREE_TYPE (rhs1)))
+ {
+   ops[0] = rhs11;
+   tree tem = vn_nary_op_lookup_pieces (1, BIT_NOT_EXPR,
+TREE_TYPE 
(rhs11),
+ops, NULL);
+   if (tem)
+ {
+   ops[0] = tem;
+   result = vn_nary_build_or_lookup (NOP_EXPR, type, 
ops);
+   if (result)
+ {
+   bool changed = set_ssa_val_to (lhs, result);
+   vn_nary_op_insert_stmt (stmt, result);
+   return changed;
+ }
+ }
+ }
+ }
+ }
+  }
 default:;
 }



> As for:
> > void baz (char *buf, unsigned int data)
> > {
> >   buf[0] = data >> 8;
> >   buf[1] = data;
> > }
> not using movbew, that is something that should be done in the backend.
> For the middle-end, we don't have bswap16 and consider {L,R}ROTATE_EXPR by 8
> as the canonical 16-bit byte swap.  Please also have a look:
> unsigned short
> baz (unsigned short *buf)
> {
>   unsigned short a = buf[0];
>   return ((unsigned short) (a >> 8)) | (unsigned short) (a << 8);
> }
> where we could also emit movbew instead of movw + rolw (if it is actually a
> win).  Thus, I think i386.md should provide patterns for combine (or peephole2
> if the former doesn't work for some reason) for this.
> 
>

[Bug libstdc++/83066] [8 regression] 26_numerics/gcd/gcd_neg.cc fails since r254736

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83066

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |FIXED

--- Comment #1 from Ville Voutilainen  ---
Fixed in r254785.

[Bug rtl-optimization/83068] New: Suboptimal code generated with -m32 using MMX reg

[bradfier at fstab dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83068

Bug ID: 83068
   Summary: Suboptimal code generated with -m32 using MMX reg
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bradfier at fstab dot me
  Target Milestone: ---

Follow up from ML post here: [1]

I tried compiling the following simple function with different -march flags in
-m32 mode:

> uint64_t sum(uint64_t a, uint64_t b) {
> return a + b;
> }

Using g++ -m32 -O2 the generated ASM is the following:

>  # 64-m32-example.cpp:6: return a + b;
>mov eax, DWORD PTR [esp+12] # b, b
>add eax, DWORD PTR [esp+4]  # tmp90, a
>mov edx, DWORD PTR [esp+16] # b, b
>adc edx, DWORD PTR [esp+8]  #, a
>  # 64-m32-example.cpp:7: }
>ret

However when I compile with -m32 -O2 -march=broadwell (or native, my
processor is a Skylake part) I get the following code instead:

>vmovq   xmm1, QWORD PTR [esp+12] # b, b
>  # 64-m32-example.cpp:6: return a + b;
>vmovq   xmm0, QWORD PTR [esp+4]  # tmp92, a
>vpaddq  xmm0, xmm0, xmm1 # tmp90, tmp92, b
>vmovd   eax, xmm0# tmp93, tmp90
>vpextrd edx, xmm0, 1 # tmp94, tmp90,
>  # 64-m32-example.cpp:7: }
>ret

This seems to be generated for any processor type where MMX is available,
although I have not tested exhaustively.

I thought this looked suspect, so I ran a benchmark using Hayai.

For the code using regular mov and add instructions, a 'run' is 10,000
iterations:
--
 Run Times: (1 run = 10,000 iterations)
 Average time: 0.006 us (~0.095 us)
 Fastest time: 0.000 us (-0.006 us / -100.000 %)
 Slowest time: 3.958 us (+3.952 us / +68209.689 %)
  Median time: 0.000 us (1st quartile: 0.000 us | 3rd quartile: 0.000 us)

 Average performance: 172586379.48293 runs/s
Best performance: inf runs/s (+inf runs/s / +inf %)
   Worst performance: 252652.85498 runs/s (-172333726.62795 runs/s / -99.85361
%)
  Median performance: inf runs/s (1st quartile: inf | 3rd quartile: inf)
--

I do wonder if these numbers are suspect, they seem too fast even for a simple
function,
but I don't know enough about the Intel OOE to be sure what's going on.

What's clear is the code using MMX and vector instructions is much slower:
--
 Run Times: (1 run = 10,000 iterations)
 Average time: 24.901 us (~1.144 us)
 Fastest time: 23.867 us (-1.034 us / -4.153 %)
 Slowest time: 61.867 us (+36.966 us / +148.451 %)
  Median time: 24.867 us (1st quartile: 24.867 us | 3rd quartile: 24.867 us)

 Average performance: 40158.86848 runs/s
Best performance: 41898.85616 runs/s (+1739.98768 runs/s / +4.33276 %)
   Worst performance: 16163.70601 runs/s (-23995.16247 runs/s / -59.75059 %)
  Median performance: 40213.93815 runs/s (1st quartile: 40213.93815 | 3rd
quartile: 40213.93815)
--


If this is a genuine regression I can look into where it's coming from,
I have my eye on dimode_scalar_chain::compute_convert_gain, but I'll keep
digging for now.

Thanks,

Richard


[1]: https://gcc.gnu.org/ml/gcc/2017-11/msg00128.html

[Bug rtl-optimization/83068] Suboptimal code generated with -m32 using MMX reg

[bradfier at fstab dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83068

--- Comment #1 from Richard Bradfield  ---
And as usual I forget to mention these things:

I am compiling everything using gcc trunk, at commit r254929 from Sun Nov 19

This behaviour is not present in GCC 7.2

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83046

--- Comment #4 from Thomas Schwinge  ---
(In reply to Martin Liška from comment #3)
> (In reply to Thomas Schwinge from comment #0)
> > ... starting with r254437 "Instrument function exit with
> > __builtin_unreachable in C++".

> > Obviously, that test case has a "-Wreturn-type mismatch" (which is not
> > diagnosed for C++; see reduced PR83045), and fixing that cures this nvptx
> > offloading ICE.
> 
> Can you please provide steps to reproduce this?

You'll either have to build an offloading compiler, but -- much simpler! -- I
assume it will be sufficient to resolve the issue seen in the
"-foffload=disable" case:

Configure GCC as usual, but add "--enable-offload-targets=nvptx-none=/no/where"
(to generally enable offloading, but without providing an actual nvptx
offloading compiler), build, and then run:

$ make check-target-libgomp
RUNTESTFLAGS='--target_board=unix\{-foffload=disable\}
{c,c++}.exp=gang-static-2.c'
[...]
Running target unix/-foffload=disable
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using ../../../../source-gcc/libgomp/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running ../../../../source-gcc/libgomp/testsuite/libgomp.c/c.exp ...
Running ../../../../source-gcc/libgomp/testsuite/libgomp.c++/c++.exp ...
Running ../../../../source-gcc/libgomp/testsuite/libgomp.hsa.c/c.exp ...
Running ../../../../source-gcc/libgomp/testsuite/libgomp.oacc-c/c.exp ...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/gang-static-2.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
Running ../../../../source-gcc/libgomp/testsuite/libgomp.oacc-c++/c++.exp
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/gang-static-2.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  (test for excess errors)

=== libgomp Summary ===

# of expected passes1
# of unexpected failures2
# of unresolved testcases   1
# of unsupported tests  4
[...]

Compilation should either succeed (as it still does for C, and did before for
C++), or terminate with a suitable diagnostic (the issue discussed in PR83045
"-Wreturn-type regression in C++").

For "c.exp" the "execution test" FAILs: "libgomp: target function wasn't
mapped" (expected in this special configuration), but for c++.exp you'll see
compilation FAIL with "excess errors":

/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x0): undefined reference to
`main._omp_fn.7'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x8): undefined reference to
`main._omp_fn.6'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x10): undefined reference to
`main._omp_fn.5'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x18): undefined reference to
`main._omp_fn.4'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x20): undefined reference to
`main._omp_fn.3'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x28): undefined reference to
`main._omp_fn.2'
/tmp/ccBzwk9H.o:(.gnu.offload_funcs+0x30): undefined reference to
`main._omp_fn.1'
collect2: error: ld returned 1 exit status
compiler exited with status 1

(I'll probably not be able to look into that myself in the next few weeks.)

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #21 from Jakub Jelinek  ---
Created attachment 42660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42660&action=edit
gcc8-pr78821-i386.patch

Untested patch for the -mmovbe movbew loads/stores.  Note, is there any
particular reason why we don't use for AT&T syntax w/l/q suffixes for movbe?
At least looking at binutils testsuite, it covers both movbe without suffix and
movbe[wlq].  On the other side, for bswap insn there are no suffixes.

[Bug middle-end/24222] [meta-bug] The gimplifier shouldn't emit warnings or errors

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24222
Bug 24222 depends on bug 26748, which changed state.

Bug 26748 Summary: gimplify_expr_stmt in cp-gimplifer.c does warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26748

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c++/26748] gimplify_expr_stmt in cp-gimplifer.c does warnings

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26748

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Andrew Pinski from comment #0)
> > I don't have a testcase but gimplify_expr_stmt produces warnings:
> > warning (OPT_Wextra, "statement with no effect");
> > ...
> >   else if (warn_unused_value)
> > warn_if_unused_value (stmt, input_location);
> 
> WAITING on a testcase

Closing since there's been no response with a testcase so I can't reproduce the
bug.

[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Paolo Carlini from comment #3)
> > Patches go to gcc-patches...
> 
> WAITING until patch is submitted

Patch was never submitted, so I'm going to assume no one cares about this and
close it.

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[itsimbal at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83015

--- Comment #7 from itsimbal at gcc dot gnu.org ---
Author: itsimbal
Date: Mon Nov 20 12:30:25 2017
New Revision: 254951

URL: https://gcc.gnu.org/viewcvs?rev=254951&root=gcc&view=rev
Log:
PR bootstrap/83015
* config/cr16/unwind-cr16.c (uw_install_context): Add FRAMES
parameter.
* config/xtensa/unwind-dw2-xtensa.c: Likewise
* config/ia64/unwind-ia64.c: Add frames parameter.
* unwind-sjlj.c: Likewise.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/cr16/unwind-cr16.c
trunk/libgcc/config/ia64/unwind-ia64.c
trunk/libgcc/config/xtensa/unwind-dw2-xtensa.c
trunk/libgcc/unwind-sjlj.c

[Bug c++/50445] Rejects use of constant expression using a pointer non-type template parameter

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50445

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> The error message is now:
> 
> $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 50445.cc
> 50445.cc: In instantiation of ‘const int X<(& values)>::val0’:
> 50445.cc:7:22:   required from here
> 50445.cc:4:19: error: the value of ‘values’ is not usable in a constant
> expression
>   static int const val0 = values[0];
>^~~~
> 50445.cc:1:18: note: ‘values’ was not declared ‘constexpr’
>  extern int const values[] = { 1, 2, 3 };
>   ^~
> 50445.cc:7:26: error: size of array ‘array’ is not an integral
> constant-expression
>  int array[X::val0];
>   ^
> $
> 
> ...which I think clears things up. Although maybe the note saying 'values'
> was not declared 'constexpr' could have a fix-it hint added to it showing
> where to insert the 'constexpr'? Putting in WAITING to see what the reporter
> thinks.

No reply so I'm going to assume the new message is enough of an improvement.

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov 20 12:57:50 2017
New Revision: 254952

URL: https://gcc.gnu.org/viewcvs?rev=254952&root=gcc&view=rev
Log:
PR c++/82781
* constexpr.c (cxx_eval_vector_conditional_expression): New function.
(cxx_eval_constant_expression) : Use it instead
of cxx_eval_conditional_expression.

* g++.dg/ext/constexpr-pr82781.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/constexpr-pr82781.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #22 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #21)
> Created attachment 42660 [details]
> gcc8-pr78821-i386.patch
> 
> Untested patch for the -mmovbe movbew loads/stores.  Note, is there any
> particular reason why we don't use for AT&T syntax w/l/q suffixes for movbe?
> At least looking at binutils testsuite, it covers both movbe without suffix
> and movbe[wlq].  On the other side, for bswap insn there are no suffixes.

No particular reason - we should add suffixes.

OTOH, proposed patch should use enabled attribute to enable xchg, and split the
pattern after reload to lose FLAGS_REG clobber for xchg and movbe
aliternatives.

[Bug c++/83050] Please provide shortcircuit attribute for || and && operators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83050

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/83049] Allow overloading of ?: conditional operator

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83049

--- Comment #2 from Jonathan Wakely  ---
In general GCC tries to avoid adding language extensions until they have at
least been proposed for addition to the standard, not the other way around.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #23 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #22)
> (In reply to Jakub Jelinek from comment #21)
> > Created attachment 42660 [details]
> > gcc8-pr78821-i386.patch
> > 
> > Untested patch for the -mmovbe movbew loads/stores.  Note, is there any
> > particular reason why we don't use for AT&T syntax w/l/q suffixes for movbe?
> > At least looking at binutils testsuite, it covers both movbe without suffix
> > and movbe[wlq].  On the other side, for bswap insn there are no suffixes.
> 
> No particular reason - we should add suffixes.

Ok, will add them incrementally.

> OTOH, proposed patch should use enabled attribute to enable xchg, and split
> the pattern after reload to lose FLAGS_REG clobber for xchg and movbe
> aliternatives.

I believe enabled attribute can't depend on 
optimize_function_for_size_p (cfun).
Splitting after reload is something I can certainly do.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #24 from Uroš Bizjak  ---
Created attachment 42661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42661&action=edit
Add bswaphi2 pattern

What do you think about going through bswaphi2 pattern, as in the attached
patch. Using of xcgh in place of bswap is suggested by Intel, but we can still
transform it to rotate in peephole2 pass.

[Bug testsuite/82951] gcc.c-torture/execute/20040409-1.c undefined behavior

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82951

--- Comment #4 from Marc Glisse  ---
Author: glisse
Date: Mon Nov 20 13:26:39 2017
New Revision: 254954

URL: https://gcc.gnu.org/viewcvs?rev=254954&root=gcc&view=rev
Log:
VRP: x+1 and -x cannot be INT_MIN

2017-11-20  Marc Glisse  

gcc/
* vr-values.c (extract_range_from_binary_expr): Use a full range
for VR_VARYING.

gcc/testsuite/
PR testsuite/82951
* gcc.c-torture/execute/20040409-1.c: Move invalid tests...
* gcc.c-torture/execute/20040409-1w.c: ... here with -fwrapv.
* gcc.c-torture/execute/20040409-2.c: Move invalid tests...
* gcc.c-torture/execute/20040409-2w.c: ... here with -fwrapv.
* gcc.c-torture/execute/20040409-3.c: Move invalid tests...
* gcc.c-torture/execute/20040409-3w.c: ... here with -fwrapv.
* gcc.dg/tree-ssa/cmpmul-1.c: Tweak condition.
* gcc.dg/tree-ssa/vrp118.c: New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-1w.c
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-2w.c
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-3w.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp118.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-2.c
trunk/gcc/testsuite/gcc.c-torture/execute/20040409-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/cmpmul-1.c
trunk/gcc/vr-values.c

[Bug middle-end/83069] New: [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069

Bug ID: 83069
   Summary: [8 Regression] internal compiler error: in
from_gcov_type, at profile-count.h:676
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r254929 failed to build 416.gamess in SPEC CPU 2006:

gfortran -c -o chgpen.fppized.o -O3 -funroll-loops -ffast-math -ffixed-form
-std=legacy chgpen.fppized.f

during IPA pass: inline
chgpen.fppized.f:847:0:

   SUBROUTINE CGPQUA(POT,CCX,CCY,CCZ,KOUNT,DAO,L2,G)

internal compiler error: in from_gcov_type, at profile-count.h:676
0x689f92 estimate_bb_frequencies(bool)
../../src-trunk/gcc/profile-count.h:676
0xd0e3bf rebuild_frequencies()
../../src-trunk/gcc/predict.c:3911
0xcf33f4 execute_function_todo
../../src-trunk/gcc/passes.c:1975
0xcf3d7e execute_todo
../../src-trunk/gcc/passes.c:2048
0x686d97 execute_one_ipa_transform_pass
../../src-trunk/gcc/passes.c:2245
0x686d97 execute_all_ipa_transforms()
../../src-trunk/gcc/passes.c:2281
0xa3b55a cgraph_node::expand()
../../src-trunk/gcc/cgraphunit.c:2132
0xa3c77b expand_all_functions
../../src-trunk/gcc/cgraphunit.c:2275
0xa3c77b symbol_table::compile()
../../src-trunk/gcc/cgraphunit.c:2623
0xa3ea59 symbol_table::compile()
../../src-trunk/gcc/cgraphunit.c:2537
0xa3ea59 symbol_table::finalize_compilation_unit()
../../src-trunk/gcc/cgraphunit.c:2716
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #25 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #23)
> I believe enabled attribute can't depend on 
> optimize_function_for_size_p (cfun).

Indeed. Maybe preferred_for_size can come handy here (and in bswaphi_lowpart
that obviously predates introduction of this tune flag).

[Bug libfortran/83070] New: -Wsign-compare warning in eoshift0

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83070

Bug ID: 83070
   Summary: -Wsign-compare warning in eoshift0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

../../../trunk-git/libgfortran/intrinsics/eoshift0.c: In function ‘eoshift0’:
../../../trunk-git/libgfortran/intrinsics/eoshift0.c:119:11: warning:
comparison of integer expressions of different signedness: ‘index_type {aka
long int}’ and ‘size_t {aka long unsigned int}’ [-Wsign-compare]
if (rs != r_ex)
   ^~
../../../trunk-git/libgfortran/intrinsics/eoshift0.c:125:11: warning:
comparison of integer expressions of different signedness: ‘index_type {aka
long int}’ and ‘size_t {aka long unsigned int}’ [-Wsign-compare]
if (as != a_ex)
   ^~

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #26 from Jakub Jelinek  ---
Comment on attachment 42661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42661
Add bswaphi2 pattern

 [(set (match_operand:HI 0 "register_operand")

Is that so that you don't have to bother with forcing operands[1] into a reg if
operands[0] is a MEM and not equal to operands[1]?

The disadvantage of your approach is that the RA will have fewer possibilities
(for -m32 not being able to use %si/%di/%bp, and for all arches not being able
to do 16-bit bswap on memory directly (rolw $8, mem).  Guess the latter could
be fixed by another peephole2, the former can't.

On the other side, it has the advantage that flags aren't clobbered from the
beginning, so perhaps sched1 or similar can do a better job.

[Bug testsuite/82951] gcc.c-torture/execute/20040409-1.c undefined behavior

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82951

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #5 from Marc Glisse  ---
.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #27 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #26)
> Comment on attachment 42661 [details]
> Add bswaphi2 pattern
> 
>  [(set (match_operand:HI 0 "register_operand")
> 
> Is that so that you don't have to bother with forcing operands[1] into a reg
> if operands[0] is a MEM and not equal to operands[1]?

Yes ;) Just a little shortcut - combine can fix this without problems nowadays.

> The disadvantage of your approach is that the RA will have fewer
> possibilities (for -m32 not being able to use %si/%di/%bp, and for all
> arches not being able to do 16-bit bswap on memory directly (rolw $8, mem). 
> Guess the latter could be fixed by another peephole2, the former can't.

I don't think mem/mem case is interesting, also IIRC, RA starts register
allocation with regclass that has lowest number of registers to avoid spilling
failures.

> On the other side, it has the advantage that flags aren't clobbered from the
> beginning, so perhaps sched1 or similar can do a better job.

Yes, the above reason was my motivation for the proposed patch.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #28 from Jakub Jelinek  ---
Ok, let's go with your patch then.

[Bug ipa/83051] [8 Regression] ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83051

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
This will be some round off as values are:

edge_time: 1115091708.00
callee_info->time: 1115091707.00

[Bug go/83071] New: gccgo: ICE in set_type

[pmatos at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83071

Bug ID: 83071
   Summary: gccgo: ICE in set_type
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: pmatos at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

I have written a very simple program in Go and somehow I surprisingly managed
to crash the compiler.

This is my first Go program so maybe I am playing outside the normal rules...
still, it shouldn't ICE.

asmparser.go:


package asmparser

import "container/list"

// Structure representing assembler files
// An AsmFile is a list of assembler specific keywords and labels interspersed
with
// architectural specific instructions.
type AsmFile list.List

// Interface for entrie
type AsmEntry struct {
lineno int
entry  *Entry
}

type Entry interface {
isInsn() bool
isKeyword() bool
isLabel() bool
}

type Insn struct {
mnemonic string
args list.List
}

func (insn Insn) isInsn() bool {
return true
}

func (insn Insn) isKeyword() bool {
return false
}

func (insn Insn) isLabel() bool {
return false
}

type Keyword struct {
name string
args string
}

func (kw Keyword) isInsn() bool {
return false
}

func (kw Keyword) isKeyword() bool {
return true
}

func (kw Keyword) isLabel() bool {
return false
}

type Label struct {
name string
}

func (l Label) isInsn() bool {
return false
}

func (l Label) isKeyword() bool {
return true
}

func (l Label) isLabel() bool {
return false
}

// Hand-written parser
func EatWhitespace(input string) (string, int) {
var eaten int = 0
for len(input) > 0 {
if input[0] != ' ' {
return input, eaten
}
input++
eaten++
}
return input, eaten
}


$ go build
# gitlab.linki.tools/go-devtools/asmparser
go1: internal compiler error: in set_type, at
go/gofrontend/expressions.cc:16320
0x6013af Numeric_constant::set_type(Type*, bool, Location)
../../../gcc/gcc/go/gofrontend/expressions.cc:16320
0x8c06f9 Integer_expression::do_check_types(Gogo*)
../../../gcc/gcc/go/gofrontend/expressions.cc:2003
0x8dde63 Expression::check_types(Gogo*)
../../../gcc/gcc/go/gofrontend/expressions.h:902
0x8dde63 Check_types_traverse::expression(Expression**)
../../../gcc/gcc/go/gofrontend/gogo.cc:3297
0x8b190d Expression::traverse(Expression**, Traverse*)
../../../gcc/gcc/go/gofrontend/expressions.cc:45
0x8bb538 Expression_list::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/expressions.cc:15857
0x8e05b1 Block::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:5977
0x8e05b1 Block::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:5977
0x8e05b1 Block::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:5977
0x8e05b1 Block::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:5977
0x8e07c9 Function::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:5101
0x8e3ebb Bindings::traverse(Traverse*, bool)
../../../gcc/gcc/go/gofrontend/gogo.cc:7803
0x8e41d1 Gogo::traverse(Traverse*)
../../../gcc/gcc/go/gofrontend/gogo.cc:2497
0x8e44e6 Gogo::check_types()
../../../gcc/gcc/go/gofrontend/gogo.cc:3307
0x8dd76f go_parse_input_files(char const**, unsigned int, bool, bool)
../../../gcc/gcc/go/gofrontend/go.cc:133
0x8d8bcf go_langhook_parse_file
../../../gcc/gcc/go/go-lang.c:323
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Fails wth both gccgo 7.2.1 (distributed with Fedora) and 
$ go version
go version go1.9 gccgo (GCC) 8.0.0 20171120 (experimental) linux/amd64

which I just built locally.

[Bug other/83048] wrap multi-statement macros in do {} while (0)

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83048

--- Comment #2 from Tom de Vries  ---
I wonder if we could use a macro like this:
...
#define SAFE_MACRO_STMT(stmt)   \
  do {  \
if (1)  \
  stmt; \
else\
  {}\
if (0)  \
  stmt; \
  } while (0)


#if ERROR == 0

// No warning or error
#define foo return

#elif ERROR == 1

// error: else without a previous if
#define foo return;

#elif ERROR == 2

// error: else without a previous if
#define foo return; return

#elif ERROR == 3

// warning: suggest explicit braces to avoid ambiguous else [-Wparentheses]
#define foo if (1) return; else return

#else

#error "Invalid value of ERROR"

#endif

void
bar (void)
{
  SAFE_MACRO_STMT (foo);
}
...

If we wrap all target macro calls in SAFE_MACRO_STMT we trigger an error or a
warning if the target macro implementation is not equivalent to a single stmt.

[Bug tree-optimization/83072] New: Late VRP optimization

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072

Bug ID: 83072
   Summary: Late VRP optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Before r254954, cmpmul-1.c was optimized during EVRP:

int f(int a, int b, int c){
  c |= 1;
  a *= c;
  b *= c;
  return a == b;
}

After that revision, the range deduced for c|1 contains zero (we may want to
revisit that at some point, but that's a separate issue), so I changed the
testcase to

int f(int a, int b, int c){
  if(c==0)__builtin_unreachable();
  a *= c;
  b *= c;
  return a == b;
}

which is only optimized during forwprop3, after __builtin_unreachable() is
removed. Since EVRP knows how to perform this optimization, it may be worth
investigating why it fails to perform it in this case.

[Bug tree-optimization/83007] [8 Regression] -Wstringop-overflow false positive

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83007

--- Comment #2 from Martin Liška  ---
Thank you Martin for the explanation, I'll fix the code.

[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821

--- Comment #29 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #24)
> Using of xcgh in place of bswap is suggested by Intel ...
For reference:

http://www.felixcloutier.com/x86/BSWAP.html

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83046

--- Comment #5 from Martin Liška  ---
Thanks for instructions, but apparently does not work for me:

make check-target-libgomp
RUNTESTFLAGS='--target_board=unix\{-foffload=disable\}
{c,c++}.exp=gang-static-2.c'
make[1]: Entering directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp'
Making check in testsuite
make[2]: Entering directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp/testsuite'
make  check-DEJAGNU
make[3]: Entering directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp/testsuite'
srcdir='../../../../libgomp/testsuite'; export srcdir; \
EXPECT=expect; export EXPECT; \
runtest=runtest; \
if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then \
  exit_status=0; l='libgomp'; for tool in $l; do \
if $runtest  --tool $tool --srcdir $srcdir
--target_board=unix\{-foffload=disable\} {c,c++}.exp=gang-static-2.c; \
then :; else exit_status=1; fi; \
  done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi; \
exit $exit_status
Test run by marxin on Mon Nov 20 15:03:00 2017
Native configuration is x86_64-pc-linux-gnu

=== libgomp tests ===

Schedule of variations:
unix/-foffload=disable

Running target unix/-foffload=disable
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../../libgomp/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running ../../../../libgomp/testsuite/libgomp.c/c.exp ...
Running ../../../../libgomp/testsuite/libgomp.c++/c++.exp ...
Running ../../../../libgomp/testsuite/libgomp.hsa.c/c.exp ...
Running ../../../../libgomp/testsuite/libgomp.oacc-c/c.exp ...
Running ../../../../libgomp/testsuite/libgomp.oacc-c++/c++.exp ...

=== libgomp Summary ===

# of untested testcases 2
# of unsupported tests  2
make[3]: Leaving directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp/testsuite'
make[2]: Leaving directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp/testsuite'
make[2]: Entering directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp'
true  DO=all multi-do # make
:
:
:
make[2]: Leaving directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp'
make[1]: Leaving directory
'/home/marxin/Programming/gcc/objdir2/x86_64-pc-linux-gnu/libgomp'

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
--disable-multilib --prefix=/home/marxin/bin/gcc --disable-bootstrap
--enable-offload-targets=nvptx-none=/no/where
Thread model: posix
gcc version 8.0.0 20171120 (experimental) (GCC)

[Bug target/83067] wrong code on arm-linux-gnueabi

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83067

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from ktkachov at gcc dot gnu.org ---
The correct format specifier to print an unsigned long long is "%llu", not
"%d".
If you want to print the signed variant (i.e. -65527) you should use "%lld"

[Bug target/82960] spu_machine_dependent_reorg does not handle jump_table_data insn

[uweigand at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82960

--- Comment #3 from Ulrich Weigand  ---
I'll have a look.   I still need to get my SPU build environment back up and
running, the build currently fails due to unrelated issues.

I remember looking at this a few years back:
https://gcc.gnu.org/ml/gcc-patches/2013-04/msg00151.html

This seemed to have fixed the problem back then, not sure why this no longer
works.

[Bug c++/83060] ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83060

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Surely related to that.
The question is what to do.  E.g.
struct A { int i; int s[8]; } a;

int *p = &a.s[-1];
int *q = &a.s[__PTRDIFF_MAX__];
is accepted even with -pedantic-errors without any warnings, only if p/q are
constexpr there are errors.
So, shall we handle offsetof like the above without constexpr and not complain
at all (and thus drop the overflow bits somewhere silently)?

Another thing is that fold_offsetof_1 is I bet called with unfolded trees, so
just doing offsetof (A, s[0 - 1]) or offsetof (A, s[__PTRDIFF_MAX__]) could
bypass the -Warray-bounds stuff in that function.  Shall it c_fully_fold the
array index, or shall we just build OFFSETOF_EXPR always and handle it during
folding (guess that might be GCC9 material)?

For negative values, I wonder if we just shouldn't move the
  t = convert (sizetype, t);
before the
  /* Check if the offset goes beyond the upper bound of the array.  */
  if (TREE_CODE (t) == INTEGER_CST && tree_int_cst_sgn (t) >= 0)
(and then we wouldn't need to even do the && tree_int_cst_sgn (t) >= 0 part),
so that negative references are considered like very large positive ones; or if
there should be a special warning.
In any case, at least for __PTRDIFF_MAX__ the overflow is introduced during the
MULT_EXPR folding.