[Bug middle-end/70188] [4.9,5 Regression] gcc 4.9+ miscompiles code on hppa

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org
Summary|gcc 4.9+ miscompiles code   |[4.9,5 Regression] gcc 4.9+
   |on hppa |miscompiles code on hppa

--- Comment #2 from John David Anglin  ---
Problem doesn't occur with Debian hppa64-linux-gnu-gcc-4.8.

[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #43 from alalaw01 at gcc dot gnu.org ---
I think this can be closed now? I've raised PR/70189 for the followup
enhancement.

[Bug middle-end/70188] gcc 4.9+ miscompiles code on hppa

[deller at gmx dot de]

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

--- Comment #1 from deller at gmx dot de ---
Created attachment 37939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37939=edit
preprocessed source

[Bug middle-end/70189] New: Combine constant-pool logic from gimplify + SRA

[alalaw01 at gcc dot gnu.org]

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

Bug ID: 70189
   Summary: Combine constant-pool logic from gimplify + SRA
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

Following PR/63679 (r232506), gimplify.c (gimplify_init_constructor) uses lots
of heuristics to choose between pushing initializers out to the constant pool
(by calling tree_output_constant_def) or outputting many elementwise
statements. Then, in tree-sra.c (analyze_all_variable_accesses), we use more
heuristics to decide which constant-pool loads to completely_scalarize, 
turning those back into elementwise statements. (These get pulled back in from
the constant pool and the constant-pool entry deleted.) Both of these sets of
heuristics are platform dependent (gimplify.c uses can_move_by_pieces,
CLEAR_RATIO; tree-sra.c uses get_move_ratio).

Instead we should put all this logic in one place; this would make it clearer,
and we'd probably get better overall decisions. The suggestion is for
gimplify.c to always push out to the constant pool, as this makes initial tree
the same on all platforms, and for all the logic/heuristics to go into SRA (as,
being later, we then have more information available to maybe make better
decisions in the future).

[Bug middle-end/70188] New: gcc 4.9+ miscompiles code on hppa

[deller at gmx dot de]

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

Bug ID: 70188
   Summary: gcc 4.9+ miscompiles code on hppa
   Product: gcc
   Version: 4.9.4
   URL: https://patchwork.kernel.org/patch/8402441/
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deller at gmx dot de
CC: dave.anglin at bell dot net
  Target Milestone: ---
Target: hppa64-linux-gnu-gcc

Linux kernels above 4.3 don't boot any longer when compiled with gcc-4.9 or
gcc-5.
After some analysis, it seems gcc miscompiles the function
blk_bio_segment_split() in block/blk-merge.c.  Compiling this function with -O0
or -O1 does produce a functional Linux kernel, but when compiled with -O2 the
kernel crashes during SCSI detection.

I was able to extract the function from the kernel source and attached is a
preprocessed file for easier analysis. It seems the variables bvprv and/or
bvprvp get optimized out when compiled with -O2.

This command is used to compile the file:

hppa64-linux-gnu-gcc-4.9 -Wp,-MD,block/.blk-merge_part.o.d  -nostdinc -isystem
/usr/lib/gcc/hppa64-linux-gnu/4.9/include
-I/build/linux/linux-4.4.4/arch/parisc/include
-Iarch/parisc/include/generated/uapi -Iarch/parisc/include/generated 
-I/build/linux/linux-4.4.4/include -Iinclude
-I/build/linux/linux-4.4.4/arch/parisc/include/uapi
-Iarch/parisc/include/generated/uapi -I/build/linux/linux-4.4.4/include/uapi
-Iinclude/generated/uapi -include
/build/linux/linux-4.4.4/include/linux/kconfig.h 
-I/build/linux/linux-4.4.4/block -Iblock -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -pipe
-mno-space-regs -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO   
-fno-cse-follow-jumps -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(blk_merge_part)" 
-D"KBUILD_MODNAME=KBUILD_STR(blk_merge_part)" -c -o block/.tmp_blk-merge_part.o
/build/linux/linux-4.4.4/block/blk-merge_part.c

[Bug c/70166] Wrong optimization of type punning in unions with 2d array

[ch3root at openwall dot com]

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

--- Comment #2 from Alexander Cherepanov  ---
On 03/11/2016 12:16 PM, rguenth at gcc dot gnu.org wrote:
> You are not accessing through the union type but through a pointer to double
> and int because u.a and p->d decay to a pointer:
>
>*(int *)  = 1;
>*(double *) >d = 0.0;
>if (*(int *)  != 0)
>  {
>abort ();

This is true but I'm afraid it doesn't explain anything.

First of all, some data points:
- the example works fine with 1d array;
- the example works fine with **u.a replaced by u.a[0][0], *u.a[0] or 
(*u.a)[0];
- the example fails in the same way with u.a and p->d wrapped in structs.

In all these cases u.a and p->d decay to a pointer too but gcc does the 
right thing anyway. Furthermore, saying that the problem is in 
array-to-pointer decay means that arrays inside unions (including 
recursively) cannot be accessed directly at all (they would work only 
wrapped in structs and copied in and out inside these structs). I guess 
this is not intended and arrays inside unions are supposed to work somehow.

Ok, let's change if to "if (**u.a != (*u.a)[0])" and do -fdump-tree-all. 
In 003t.original we have this:

   *(int *)  = 1;
   *(double *) >d = 0.0;
   if (*(int *)  != (*(int[1] *) )[0])
 {
   abort ();

and in 004t.gimple we have this:

 D.1636 = 
 D.1639 = MEM[(int *)D.1636];
 D.1640 = u.a[0][0];
 if (D.1639 != D.1640) goto ; else goto ;
 :
 abort ();

It seems the general direction is to convert * to [] but gcc fails to 
convert **. Different treatment of **x and x[0][0] is not limited to 
unions in any way. In other cases I guess it will just prevent some 
optimizations but with unions it has a user-visible effect.

[Bug sanitizer/70147] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I tries to isolate the issue (attached patch reduces just the problematic
instrumentation):

$ g++ metafunction.ii -fsanitize=vptr -fdump-tree-optimized -g -O1
-flifetime-dse=0

binfo modified (zeroed)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7fe2b823cd20
fields 
ignored decl_6 BLK file
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/bits/basic_ios.h line 67
col 11
size 
unit size 
align 64 offset_align 128
offset 
bit offset  context
 chain > context 
full-name "class std::basic_ios"
needs-constructor needs-destructor X() has-type-conversion X(constX&)
this=(X&) sorted-fields 0x7fe2b69f4688 n_parents=1 use_template=3
interface-only
pointer_to_this  reference_to_this
 chain >
private static tree_2 bases 1 offset 
virtuals  inheritance chain >

inherited type:
  constant 2240>
unit size  constant 280>
align 64 symtab -1233927952 alias set -1 canonical type 0x7fe2b823f000
fields 
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set 2 canonical type 0x7fe2b8a740a8>
unsigned virtual DI file
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream line 58 col 11
size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
protected nonlocal decl_3 DI file
/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/istream line 82 col 18
size  unit size 
align 64 offset_align 128 offset  bit
offset  context  chain >> context

full-name "class std::basic_istream"
needs-constructor needs-destructor X() has-type-conversion X(constX&)
this=(X&) sorted-fields 0x7fe2b66c1cf0 n_parents=1 use_template=3
interface-only
pointer_to_this  reference_to_this
 chain >

The problematic code where we see the segfault is here:

   │0x40450a  
movq   $0x0,-0x40(%rbp) 
   │0x404512  
movb   $0x0,-0x38(%rbp) 
   │0x404516  
movb   $0x0,-0x37(%rbp) 
   │0x40451a  
movq   $0x0,-0x30(%rbp) 
   │0x404522 
movq   $0x0,-0x28(%rbp) 
   │0x40452a 
movq   $0x0,-0x20(%rbp) 
   │0x404532 
movq   $0x0,-0x18(%rbp) 
   │0x40453a  mov
   -0x190(%rbp),%rax
  >│0x404541  mov
   -0x18(%rax),%rax 
   |0x404545 
movq   $0x0,-0x190(%rbp,%rax,1) 
(gdb) p $rax
$1 = 1

Where both  std::basic_istream::basic_istream
and std::__cxx11::basic_istringstream::basic_istringstream are inlined within the problematic
function std::__cxx11::regex_traits::value.

tree-optimized dump differs in following related hunk (diff between
non-instrumented and instrumented):
@@ -2860,18 +2864,23 @@
   MEM[(struct basic_ios *)&__is + 120B]._M_num_put = 0B;
   MEM[(struct basic_ios *)&__is + 120B]._M_num_get = 0B;
   MEM[(struct  &)&__is] ={v} {CLOBBER};
-  _43 = MEM[(const void *
*)&_ZTTNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE + 8B];
-  MEM[(struct basic_istream *)&__is]._vptr.basic_istream = _43;
-  _44 = MEM[(long int *)_43 + -24B];
-  _45 = (sizetype) _44;
-  _46 = &__is.D.67909 + _45;
-  _47 = MEM[(const void *
*)&_ZTTNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE + 16B];
-  _46->D.42212._vptr.ios_base = _47;
+  _52 = MEM[(struct basic_istream *)&__is]._vptr.basic_istream;
+  _53 = MEM[(long int *)_52 + -24B];
+  _54 = (sizetype) _53;
+  _55 = &__is.D.67909 + _54;
+  _55->D.42212._vptr.ios_base = 0B;
+  _56 = MEM[(const void *
*)&_ZTTNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE + 8B];
+  MEM[(struct basic_istream *)&__is]._vptr.basic_istream = _56;
+  _57 = MEM[(long int *)_56 + -24B];
+  _58 = (sizetype) _57;
+  _59 = &__is.D.67909 + _58;
+  _60 = MEM[(const void *
*)&_ZTTNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE + 16B];
+  _59->D.42212._vptr.ios_base = _60;
   

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[wdijkstr at arm dot com]

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

--- Comment #17 from Wilco  ---
(In reply to Jiong Wang from comment #16)

>   * for the second patch at #c10, if we always do the following no matter
> op0 is virtual & eliminable or not
> 
>  "op1 = force_operand (op1, NULL_RTX);"
> 
> then there is no performance regression as well. Even more, there is
> significant perf improvement beyond current trunk on one benchmark.

I ran this modified patch through a few benchmarks and there are no
regressions. The codesize of SPEC2006 reduces significantly in several cases
(-0.25%), while there are only 2 minor increases of +0.02%, so the patch
reduces instruction counts quite effectively.

So we should go with the modified patch for GCC6.

[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
Created attachment 37938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37938=edit
Proposed test

[Bug lto/70187] [6 Regression] ICE (segfault) in lto1 with -Wsuggest-final-methods/-Wsuggest-final-types

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug lto/70187] New: [6 Regression] ICE (segfault) in lto1 with -Wsuggest-final-methods/-Wsuggest-final-types

[burnus at gcc dot gnu.org]

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

Bug ID: 70187
   Summary: [6 Regression] ICE (segfault) in lto1 with
-Wsuggest-final-methods/-Wsuggest-final-types
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37937=edit
testcase (test.ii)

g++ -c -w -r -nostdlib  -O2 -flto input26b.ii
g++ -Ofast -flto -Wsuggest-final-methods -Wsuggest-final-types input26b.o

ICEs with:

lto1: internal compiler error: Segmentation fault
0xa77adf crash_signal
../../gcc/toplev.c:335
0x886444 vec::operator[](unsigned int)
../../gcc/vec.h:714
0x886444 vec::operator[](unsigned int)
../../gcc/vec.h:1180
0x886444 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.c:3181
0x888a7a possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:114
0x888a7a ipa_devirt
../../gcc/ipa-devirt.c:3576


Worked a few days ago with the trunk in the preliminary patch PR69630 comment 3
applied. (As that PR is fixed, my current trunk build has no extra patches
applied.)

[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 11 Mar 2016, zackw at panix dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178
> 
> --- Comment #2 from Zack Weinberg  --- That was 
> my working hypothesis as well.  Isn't there some way we can annotate 
> s->data to reassure the compiler that *this* char* doesn't alias?  I 
> don't know enough about the guts of std::string to know whether 
> 'restrict' is accurate, but it certainly shouldn't be pointing to 
> anything but string contents.

We can use 'restrict', yes, but it will only have an effect if used
on an object a function parameter points to.

We do use it on valarray for example.  Not sure if it is valid for
std::string.

Note that using restrict on data members is poorly specified (if at all)
and I can't find it specified for C++ at all (just for C).  I only
find in 17.2 (C++14) that for C standard library functions
"any use of the restrict qualifier shall be omitted" ...

We do use the restrict feature for fortran arrray descriptors and
it works there (as function parameter).

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/68963] [4.9/5 Regression] O3 vs. O2 discards part of loop and terminates early

[jakub at gcc dot gnu.org]

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

Bug 70177 Summary: [6 Regression] ICE in extract_ops_from_tree starting with 
r233660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177

   What|Removed |Added

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

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 11 12:28:50 2016
New Revision: 234140

URL: https://gcc.gnu.org/viewcvs?rev=234140=gcc=rev
Log:
PR tree-optimization/70177
* gimple-expr.h (extract_ops_from_tree_1): Renamed to ...
(extract_ops_from_tree): ... this.  In the 2 argument
overload remove _1 suffix.
* gimple-expr.c (extract_ops_from_tree_1): Renamed to ...
(extract_ops_from_tree): ... this.
* gimple.c (gimple_build_assign, gimple_assign_set_rhs_from_tree):
Adjust callers.
* tree-ssa-loop-niter.c (derive_constant_upper_bound): Likewise.
* tree-ssa-forwprop.c (defcodefor_name): Call 3 operand
extract_ops_from_tree instead of 2 operand one.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr70177.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-expr.c
trunk/gcc/gimple-expr.h
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c
trunk/gcc/tree-ssa-loop-niter.c

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/70169] [4.9/5 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE at |[4.9/5 Regression] ICE at
   |-O1 and above on|-O1 and above on
   |x86_64-linux-gnu in |x86_64-linux-gnu in
   |gen_lsm_tmp_name, at|gen_lsm_tmp_name, at
   |tree-ssa-loop.c:791 |tree-ssa-loop.c:791

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted

[zackw at panix dot com]

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

--- Comment #2 from Zack Weinberg  ---
That was my working hypothesis as well.  Isn't there some way we can annotate
s->data to reassure the compiler that *this* char* doesn't alias?  I don't know
enough about the guts of std::string to know whether 'restrict' is accurate,
but it certainly shouldn't be pointing to anything but string contents.

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[alalaw01 at gcc dot gnu.org]

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

--- Comment #13 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Fri Mar 11 12:08:01 2016
New Revision: 234138

URL: https://gcc.gnu.org/viewcvs?rev=234138=gcc=rev
Log:
Fix PR/70013

gcc:

PR tree-optimization/70013
* tree-sra.c (analyze_access_subtree): Also set grp_unscalarized_data
for constant-pool entries.

gcc/testsuite:

* gcc.dg/tree-ssa/sra-20.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 11 12:07:01 2016
New Revision: 234137

URL: https://gcc.gnu.org/viewcvs?rev=234137=gcc=rev
Log:
PR rtl-optimization/70174
* expmed.c (store_bit_field_using_insv): Use gen_lowpart_if_possible
followed by gen_lowpart on force_reg instead of just gen_lowpart.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr70174.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70169] [4.9/5/6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 11 12:05:58 2016
New Revision: 234136

URL: https://gcc.gnu.org/viewcvs?rev=234136=gcc=rev
Log:
PR tree-optimization/70169
* tree-ssa-loop.c (gen_lsm_tmp_name): Handle FUNCTION_DECL and
LABEL_DECL like VAR_DECL.  Emit nothing instead of gcc_unreachable
for unknown codes.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr70169.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop.c

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

--- Comment #14 from Leon Winter  ---
I am not sure how smart he diagnostic of GCC is supposed to be it seems that
the source base of GCC itself has fallen victim to the false warning.

The following commit fixes a -Wmaybe-uninitialized warning:
commit 4dae4a1aef68d3947f10a2901c957784958f212a
Author: jakub 
Date:   Sun Jan 17 18:04:47 2016 +

* omp-low.c (mark_loops_in_oacc_kernels_region): Work around
-Wmaybe-uninitialized warning.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@232484
138bc75d-0d04-0410-961f-82ee72b054a4

However looking at the source code at the point of the actual usage of the
variable it must be set. The branch-return-condition before ensures
nr_outer_loops == 1 which can only be true if it was set in the loop. If that
is true, the variable single_outer must be set to loop which is again must be
!= null (as per loop breaking condition).
The commiter called the change a "work around" which indicates he was aware the
initialization might not have been needed.

[Bug c/70186] RFE: better handling of misspelled attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-11
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c/70186] New: RFE: better handling of misspelled attributes

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 70186
   Summary: RFE: better handling of misspelled attributes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

From a discussion on IRC:

  t.c:3:8: warning: ‘visbility’ attribute directive ignored [-Wattributes]
  struct S *foo __attribute__ ((visbility("hidden")));
 ^
Note the misspelling of the attribute name:
  "visbility"
should have read:
  "visibility"

The reported location of the diagnostic is also suboptimal; it should underline
the attribute, either:

  struct S *foo __attribute__ ((visbility("hidden")));
^~~~

or:

  struct S *foo __attribute__ ((visbility("hidden")));
^~~

Ideally we should use Levenshtein and emit a hint and a fixit:

  t.c:3:8: warning: ‘visbility’ attribute directive ignored; did you mean
'visibility'? [-Wattributes]
  struct S *foo __attribute__ ((visbility("hidden")));
^~~
-
visibility

or somesuch.

[Bug ipa/70161] [4.9/5/6 Regression] fdump-ipa-all-graph causes segfault

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37918|0   |1
is obsolete||

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 37936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37936=edit
updated tentative patch

[Bug ipa/70161] [4.9/5/6 Regression] fdump-ipa-all-graph causes segfault

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Hum, what does it do if only guarding the !pass->graph_dump_initialized
> check?

That fixes the segfault, but we run into another segfault with -fipa-pta (which
calls cgraph_node::get_body), due to dump_file_name being NULL. This patch
fixes that:
...
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 7727313..f187913 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3365,7 +3365,9 @@ cgraph_node::get_body (void)
 {
   opt_pass *saved_current_pass = current_pass;
   FILE *saved_dump_file = dump_file;
+  const char *saved_dump_file_name = dump_file_name;
   int saved_dump_flags = dump_flags;
+  dump_file_name = NULL;

   push_cfun (DECL_STRUCT_FUNCTION (decl));
   execute_all_ipa_transforms ();
@@ -3377,6 +3379,7 @@ cgraph_node::get_body (void)

   current_pass = saved_current_pass;
   dump_file = saved_dump_file;
+  dump_file_name = saved_dump_file_name;
   dump_flags = saved_dump_flags;
 }
   return updated;
...

However, looking at test.c.074i.inline.dot, we see that the graph has
duplicated edges. This seems an issue that also occcurs for normal dump files:
a simple-ipa pass dumps at execute, and an ipa pass dumps at execute and at
transform. AFAIU, an ipa pass does not do transforms at execute, so that dump
seems superfluous. This patch fixes that:
...
diff --git a/gcc/passes.c b/gcc/passes.c
index 8206463..2865033 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -2352,8 +2352,6 @@ execute_one_pass (opt_pass *pass)
 check_profile_consistency (pass->static_pass_number, 1, true);

   verify_interpass_invariants ();
-  if (dump_file)
-do_per_function (execute_function_dump, pass);
   if (pass->type == IPA_PASS)
 {
   struct cgraph_node *node;
@@ -2361,6 +2359,8 @@ execute_one_pass (opt_pass *pass)
FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
  node->ipa_transforms_to_apply.safe_push ((ipa_opt_pass_d *)pass);
 }
+  else if (dump_file)
+do_per_function (execute_function_dump, pass);

   if (!current_function_decl)
 symtab->process_new_functions ();
...

And then we run into:
- the ipa variant of PR70185.
- other errors:
  Warning: inline.c.070i.cp.dot: syntax error in line 1 near 'subgraph'
  Warning: inline.c.074i.inline.dot: syntax error in line 1 near 'subgraph'

The first can be fixed with the tentative fix for the PR.
The second by using a different (and simpler) fix for the original sigsegv:
...
diff --git a/gcc/passes.c b/gcc/passes.c
index bbe35b3..ad49d12 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -2219,7 +2219,7 @@ execute_one_ipa_transform_pass (struct cgraph_node *node,
 check_profile_consistency (pass->static_pass_number, 1, true);

   if (dump_file)
-do_per_function (execute_function_dump, NULL);
+do_per_function (execute_function_dump, pass);
   pass_fini_dump_file (pass);

   current_pass = NULL;
...
[ Btw, the 'do_per_function (execute_function_dump, pass)' is equivalent to
'execute_function_dump (cfun, pass)'. ]

> Otherwise your patch is equivalent to removing the
> 
>   if (dump_file)
> do_per_function (execute_function_dump, NULL);
> 
> call from execute_one_ipa_transform_pass, no?

Not equivalent, since removing that call also removes the normal dump.

> That is, no graph dumps from
> IPA passes?

Indeed, the original pass skipped dot graph dumps from ipa transforms (but
still dumped after execute).


I'll attach the updated tentative patch.

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
With TER we delay expanding of (unsigned b) until you require its expansion
during asm op expansion (and thus may be interleaved with asm expansion code).

I believe we had this issue in the past for other archs and libcalls.  Don't
remember what the solution there was though ;)  IIRC it was libcalls
expanded during libcall expansion or so like for a + (b * c) and both
+ and * resulting in a libcall.

[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #2 from Marek Polacek  ---
I'll look but I think there's a dup somewhere, or at least something very
similar.

[Bug rtl-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Ilya Enkovich  ---
Fixed

[Bug rtl-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[ienkovich at gcc dot gnu.org]

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

--- Comment #8 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Mar 11 11:25:29 2016
New Revision: 234135

URL: https://gcc.gnu.org/viewcvs?rev=234135=gcc=rev
Log:
gcc/

PR target/70160
* config/i386/i386.c (scalar_chain::convert_reg): Skip uses
of uninitialized values.

gcc/testsuite/

PR target/70160
* gcc.target/i386/pr70160.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70160.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/70171] Poor code generated when return struct using ternary operator

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 11 Mar 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70171
> 
> --- Comment #5 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #4)
> > Created attachment 37935 [details]
> > patch
> > 
> > Patch I am testing.
> 
> + /* { dg-final { scan-assembler-not "\[er\]sp" { target x86_64-*-* } } } */
> 
> You should always use "target i?86-*-* x86_64-*-*" and optionally limit to
> 64bit targets with "&& { ! ia32 }". Please see many examples in gcc.dg.

Will do.

[Bug tree-optimization/70171] Poor code generated when return struct using ternary operator

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #4)
> Created attachment 37935 [details]
> patch
> 
> Patch I am testing.

+ /* { dg-final { scan-assembler-not "\[er\]sp" { target x86_64-*-* } } } */

You should always use "target i?86-*-* x86_64-*-*" and optionally limit to
64bit targets with "&& { ! ia32 }". Please see many examples in gcc.dg.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/cxa_demangle.cpp
https://github.com/ianlancetaylor/demangle

[Bug tree-optimization/70171] Poor code generated when return struct using ternary operator

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Created attachment 37935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37935=edit
patch

Patch I am testing.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #4)
> >Ian's go demangler and the libcxxabi demangler also are unable to demangle 
> >these  symbols.
> 
> Because they are all the same code ...

No, they are not. These are all independent implementations.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
>Ian's go demangler and the libcxxabi demangler also are unable to demangle 
>these  symbols.

Because they are all the same code ...

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[alalaw01 at gcc dot gnu.org]

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

--- Comment #12 from alalaw01 at gcc dot gnu.org ---
Thanks, Martin - yes, I see.

Patch posted at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00680.html after
full regtest.

[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-11
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Indeed, started with r230365.

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Though, aarch64 ICEs in the same place, so this is likely not an i386
> > backend issue.
> 
> This is an issue with insv handling infrastructure.  The problem is in
> expmed.c, around line 669, where simplify_subreg is called with
> (symbol_ref:DI ...). This won't work.

Eh, gen_lowpart at line 678 instead of simplify_subreg - and the patch fixes
the right spot.

[Bug tree-optimization/70171] Poor code generated when return struct using ternary operator

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Btw, the C frontend produces optimized code here - it simply uses

  return select != 0 ? a : b;

in its GENERIC.  Maybe the C++ FE can avoid building a TARGET_EXPR like that
or use 

return  = TARGET_EXPR 

that is, without going through the address-taking and dereferencing game?

[Bug other/70185] fdump-tree-all-graph produces invalid dot files

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37934=edit
tentative patch

No more warnings, also for rtl:
...
$ rm *.c.* ; gcc test.c -O2 -S -fdump-tree-all-graph -fdump-rtl-all-graph  
$ for f in *.dot; do dot -Tpdf $f -o dot.pdf; done
$ 
...

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||iant at google dot com

--- Comment #3 from Markus Trippelsdorf  ---
trippels@gcc2-power8 ~ % cat down.ii
namespace std {
template  struct integral_constant {
  static constexpr _Tp value = 0;
};
template  struct conditional;
template  struct A;
template 
struct A<_B1, _B2> : conditional<_B1>::type {};
struct B : integral_constant {};
template  struct enable_if { typedef int type; };
template  struct conditional { typedef B type; };
struct type_info;
template  struct function;
template  struct _Base_manager {
  static int _M_manager() { ; }
};
template  struct C;
template 
struct C<_Res(_ArgTypes...), _Functor> : _Base_manager<_Functor> {};
template  using __check_func_return_type = int;
template 
struct function<_Res(_ArgTypes...)> {
  template 
  using _Callable = A<_Functor, __check_func_return_type<_Functor, _Res>>;
  template 
  using _Requires = typename enable_if<_Cond::value>::type;
  template , void>>
  function(_Functor);
};
template 
template 
function<_Res(_ArgTypes...)>::function(_Functor) {
  C<_Res(), _Functor>::_M_manager;
}
}
struct D {
  static const int value = 0;
};
namespace boost {
template  struct F { typedef T2 type; };
namespace function_types {
template  struct G;
template  struct H : G {};
template 
struct G {
  typedef D function_arity;
};
template 
struct function_arity : F::function_arity>::type {};
}
}
namespace folly {
namespace detail {
void addBenchmarkImpl(int, int, std::function);
}
template 
typename std::enable_if::value == 2>::type
addBenchmark(const char *, const char *, Lambda &&) {
  auto execute = [](unsigned) {};
  detail::addBenchmarkImpl(0, 0, execute);
}
}
int follyBenchmarkUnused2(folly::addBenchmark("", "", [](int) {}));

trippels@gcc2-power8 ~ % clang++ -w -std=c++14 down.ii -c
trippels@gcc2-power8 ~ % nm -C down.o
 t __cxx_global_var_init
 B follyBenchmarkUnused2
0070 t _GLOBAL__sub_I_down.ii
 U .TOC.
 t
_ZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcS8_OS3_
 U folly::detail::addBenchmarkImpl(int, int, std::function)
0090 t
_ZNSt13_Base_managerIZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcS9_OS4_EUljE_E10_M_managerEv
0070 t
_ZNSt8functionIFivEEC2IZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcSC_OS7_EUljE_iEES7_

trippels@gcc2-power8 ~ % g++ -w -std=c++14 down.ii -c
trippels@gcc2-power8 ~ % nm -C down.o
 B follyBenchmarkUnused2
014c t _GLOBAL__sub_I_follyBenchmarkUnused2
 U .TOC.
00ac t __static_initialization_and_destruction_0(int, int)
 t
_ZN5folly12addBenchmarkIUliE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_clEEE5valueLi2EEvE4typeEPKcSC_OS6_
 U folly::detail::addBenchmarkImpl(int, int, std::function)
007c t
_ZNSt8functionIFivEEC1IZN5folly12addBenchmarkIUliE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_clEEE5valueLi2EEvE4typeEPKcSG_OSA_EUljE_iEESA_
007c t
_ZNSt8functionIFivEEC2IZN5folly12addBenchmarkIUliE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_clEEE5valueLi2EEvE4typeEPKcSG_OSA_EUljE_iEESA_

Ian's go demangler and the libcxxabi demangler also are unable to demangle
these  symbols.

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Does -fno-ter fix the issue?
> How does the tree level look?

You mean -fno-tree-ter?
That gives:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
mov r4, r0
mov r0, r1
bl  __aeabi_f2uiz
mov r1, r0
mov r0, r4
.syntax divided
@ 7 "foo.c" 1
str r1, [r0]

@ 0 "" 2
.syntax unified
pop {r4, pc}

Which looks correct, thanks!

The optimized tree dump looks right to me with or without -fno-tree-ter

;; Function foo (foo, funcdef_no=0, decl_uid=4090, cgraph_uid=0,
symbol_order=0)

foo (unsigned int a, float b)
{
  register unsigned int r1 __asm__ (*r1);
  register unsigned int r0 __asm__ (*r0);
  unsigned int c;

  :
  c_2 = (unsigned int) b_1(D);
  r0 = a_4(D);
  r1 = c_2;
  __asm__ __volatile__("str %1, [%0]
" :  : "r0" "r" r0, "r1" "r" r1);
  return;

}

[Bug other/70185] New: fdump-tree-all-graph produces invalid dot files

[vries at gcc dot gnu.org]

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

Bug ID: 70185
   Summary: fdump-tree-all-graph produces invalid dot files
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Using fdump-tree-all-graph produces invalid dot files:
...
$ rm *.c.* ; gcc test.c -O2 -S -fdump-tree-all-graph  
$ for f in *.dot; do dot -Tpdf $f -o dot.pdf; done
Warning: test.c.006t.omplower.dot: syntax error in line 1 near '}'
Warning: test.c.007t.lower.dot: syntax error in line 1 near '}'
Warning: test.c.010t.eh.dot: syntax error in line 1 near '}'
Warning: test.c.292t.statistics.dot: syntax error in line 1 near '}'
$ cat test.c.006t.omplower.dot
}
$
...

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 37933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37933=edit
gcc6-pr70177.patch

Untested fix.  The questions about latent issues, where the upper bound
expression comes from and why it is so weird, remain.

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Does -fno-ter fix the issue?
How does the tree level look?

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Things are bad already at expand time:
2: r111:SI=r0:SI
3: r112:SF=r1:SF
4: NOTE_INSN_FUNCTION_BEG
7: r0:SI=r111:SI
8: r0:SF=r112:SF
9: r0:SI=call [`__aeabi_f2uiz'] argc:0
  REG_CALL_DECL `__aeabi_f2uiz'
  REG_EH_REGION 0x8000
   10: r113:SI=r0:SI
  REG_EQUAL uns_fix(r112:SF)
   11: r1:SI=r113:SI
   12: asm_operands

[Bug pch/70183] fdump-rtl-all-flags doesn't have impact on vzeroupper pass

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to vries from comment #1)
> Created attachment 37932 [details]
> tentative patch

Which has the desired effect:
...
$ rm *.c.* ; gcc test.c -S -fdump-rtl-all-slim -mavx -mvzeroupper
-fexpensive-optimizations
$ grep -c '(insn' *.c.* | grep -v ':0'
$ 
...

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #7)
> Comment on attachment 37931 [details]
> gcc6-pr70174.patch
> 
> + tmp = gen_lowpart (op_mode, force_reg (GET_MODE (value),
> +value1));
> 
> 
> Should GET_MODE here be of value1 and not value?

value1 == value at that point, and the force_reg a few lines above does exactly
the same.

[Bug pch/70183] fdump-rtl-all-flags doesn't have impact on vzeroupper pass

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37932=edit
tentative patch

[Bug inline-asm/70184] New: Exlpicit register variables overwritten by conversion libcall

[ktkachov at gcc dot gnu.org]

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

Bug ID: 70184
   Summary: Exlpicit register variables overwritten by conversion
libcall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm

Consider the testcase:
void foo(unsigned a, float b)
{
  unsigned c = (unsigned) b;
  register unsigned r0 __asm__("r0") = a;
  register unsigned r1 __asm__("r1") = c;
__asm__ volatile( "str %[r1], [%[r0]]\n"
  :
  : [r0] "r" (r0),
[r1] "r" (r1));
}

Compile for an arm target with (for example) -Os -mfloat-abi=soft
-march=armv7-a -marm.
This generates:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
mov r0, r1
bl  __aeabi_f2uiz
mov r1, r0
.syntax divided
@ 7 "foo.c" 1
str r1, [r0]

@ 0 "" 2
.syntax unified
pop {r4, pc}

The register r0 holding 'a' gets overwritten as part of the setup for the
rounding libcall so when it gets tied to the variable 'r0' expecting it to hold
'a' it gets garbage instead.

This testcase is warned about in:
https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables

but the code above explicitly follows the workaround suggested on that page so
I'd expect it to work.
Is this indeed a supported usecase of local register variables? and if so, is
there a workaround for this bug?

[Bug pch/70183] New: fdump-rtl-all-flags doesn't have impact on vzeroupper pass

[vries at gcc dot gnu.org]

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

Bug ID: 70183
   Summary: fdump-rtl-all-flags doesn't have impact on vzeroupper
pass
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Normally, we use the '(insn' notation:
...
$ rm *.c.* ; gcc test.c -S -fdump-rtl-all -mavx -mvzeroupper
-fexpensive-optimizations
$ grep -c '(insn' *.c.* | grep -v ':0'
inline.c.213r.expand:2
inline.c.214r.vregs:2
inline.c.215r.into_cfglayout:2
inline.c.216r.jump:4
inline.c.228r.reginfo:2
inline.c.246r.outof_cfglayout:2
inline.c.247r.split1:2
inline.c.249r.dfinit:2
inline.c.250r.mode_sw:2
inline.c.251r.asmcons:2
inline.c.255r.ira:2
inline.c.256r.reload:2
inline.c.259r.split2:2
inline.c.263r.pro_and_epilogue:8
inline.c.266r.jump2:8
inline.c.279r.stack:8
inline.c.280r.alignments:8
inline.c.282r.mach:8
inline.c.283r.barriers:8
inline.c.287r.shorten:8
inline.c.288r.nothrow:8
inline.c.289r.dwarf2:8
inline.c.290r.final:8
inline.c.291r.dfinish:8
inline.c.293r.vzeroupper:2
...

We switch that off using fdump-rtl-all-slim, but that doesn't impact
vzeroupper:
...
$ rm *.c.* ; ./lean-c/install/bin/gcc tes.tc -S -fdump-rtl-all-slim -mavx
-mvzeroupper -fexpensive-optimizations
vries@lenny:~/gcc_versions/devel$ grep -c '(insn' *.c.* | grep -v ':0'
inline.c.293r.vzeroupper:2

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
Comment on attachment 37931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37931
gcc6-pr70174.patch

+   tmp = gen_lowpart (op_mode, force_reg (GET_MODE (value),
+  value1));


Should GET_MODE here be of value1 and not value?

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Created attachment 37931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37931=edit
gcc6-pr70174.patch

Untested fix.

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> Though, aarch64 ICEs in the same place, so this is likely not an i386
> backend issue.

Though the revision where the failure starts says something about what to look
into.  That is the code which uses the insv mode specific patterns.

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> Though, aarch64 ICEs in the same place, so this is likely not an i386
> backend issue.

This is an issue with insv handling infrastructure.  The problem is in
expmed.c, around line 669, where simplify_subreg is called with (symbol_ref:DI
...). This won't work.

[Bug tree-optimization/70177] [6 Regression] ICE in extract_ops_from_tree starting with r233660

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||68963

--- Comment #4 from Richard Biener  ---
Using extract_ops_from_tree_1 looks fine to me.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68963
[Bug 68963] [4.9/5 Regression] O3 vs. O2 discards part of loop and terminates
early

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Though, aarch64 ICEs in the same place, so this is likely not an i386 backend
issue.

[Bug c/70166] Wrong optimization of type punning in unions with 2d array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You are not accessing through the union type but through a pointer to double
and int because u.a and p->d decay to a pointer:

  *(int *)  = 1;
  *(double *) >d = 0.0;
  if (*(int *)  != 0)
{
  abort ();

[Bug tree-optimization/70169] [4.9/5/6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Maybe finally get rid of the gcc_unreachable () by providing a sane default for
this non-critical fn?

[Bug rtl-optimization/70174] [6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-11
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r225484.

[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug tree-optimization/70171] Poor code generated when return struct using ternary operator

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-11
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
This is the C++ frontends work:

;; Function S struct_ternary(S, S, bool) (null)
;; enabled by -tree-original


< = TARGET_EXPR >>;

and while we have a pass that cleans this up for scalars it refuses to
operate on aggregates (because it tries to use a PHI in the transform).
Thus phiprop could handle this case emitting non-SSA code here and
do this for aggregates with non-BLKmode.  Basically transform

  :
  if (select_2(D) != 0)
goto ;
  else
goto ;

  :

  :
  # iftmp.1_1 = PHI <(2), (3)>
  D.2322 = MEM[(const struct S &)iftmp.1_1];

into

  :
  if (select_2(D) != 0)
goto ;
  else
goto ;

  :
D.2322 = b;
goto ;

  :
D.2322 = a;

  :


Let me try to tackle this for GCC 7.

[Bug tree-optimization/70169] [4.9/5/6 Regression] ICE at -O1 and above on x86_64-linux-gnu in gen_lsm_tmp_name, at tree-ssa-loop.c:791

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37930=edit
gcc6-pr70169.patch

Untested patch.

[Bug rtl-optimization/70174] ICE at -O1 and above on x86_64-linux-gnu in gen_lowpart_general, at rtlhooks.c:63

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
not sure if invalid.

[Bug libstdc++/70176] Regression with C++03 Issue cstdio

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-pc-cygwin

--- Comment #1 from Richard Biener  ---
Works for me on x86_64-linux.

[Bug c++/70178] Loop-invariant memory loads from std::string innards are not hoisted

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
This is because we don't know that for

struct string { char *data; } s;

s->data doesn't point to >data and thus writing to s->data[i] may invalidate
the pointer.  Unfortunately 'char' aliases everything so writing to a char *
object and then reading back as char * is valid from a TBAA perspective.

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
But it isn't possible always, there can't be calls that need PLT (because those
expect %ebx to contain the GOT pointer), and similarly e.g. TLS relocations
don't have non-_G_O_T_ variants.

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[twoh at fb dot com]

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

--- Comment #2 from Taewook Oh  ---
Here is a link to the preprocessed text: http://paste.ubuntu.com/15346235/

As I wrote in the description, it seems pretty clear that demangler applies an
incorrect rule to demangle expression. For "srT_oncl", if demangler applies the
correct rule

 ::= sr  ,

then "T_" can be processed by rule 

 ::= T_

and "oncl" can be processed by

 ::= on  
 ::= cl  # ().

GCC generates a slightly different name
(_ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkIUljE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_clEEE5valueLi2EEvE4typeEPKcSG_OSA_EUljE_E9_M_invokeERKSt9_Any_dataj)
but still cannot be demangled by c++filt.

[Bug c++/70181] missing -Wtautological-compare for constant expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think it is intentional, because it otherwise leads to way too many false
positives.  We don't warn for (0 == 0), that is very common, e.g. if the
constants come from macros.  And for constants it is the same thing.

[Bug middle-end/70159] missed CSE optimization

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 10 Mar 2016, spop at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
> 
> --- Comment #9 from Sebastian Pop  ---
> Created attachment 37927
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37927=edit
> patch for hoisting expressions
> 
> Updated the patch from PR23286 to hoist the redundant expressions:
> 
>   :
>   inv_4 = 1.0e+0 / d_3(D);
>   _18 = min_5(D) - a_6(D);
>   _19 = _18 / inv_4;
>   _20 = max_9(D) - a_6(D);
>   _21 = _20 / inv_4;
>   if (inv_4 >= 0.0)
> goto ;
>   else
> goto ;
> 
>   :
> 
>   :
>   # tmin_1 = PHI <_19(2), _21(3)>
>   # tmax_2 = PHI <_21(2), _19(3)>
>   _16 = tmin_1 + tmax_2;
>   return _16;
> 
> The attached patch does not pass make check and causes some infinite 
> recursion.

Yes, the patch has some issues still.  As for every stage1 I plan
to try picking it up again ...

I notice from the above output that it doesn't see the CSE
opportunity but inserts both expressions - it shouldn't do that,
so there's something "new wrong" with the patch (or your update
to it)

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-11
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Could you please attach a preprocessed file of the source that shows this
issue.
The snipped you have posted is not enough.

No demangler that I've tested could demangle the symbol, so it might well be 
a clang mangler bug.