[Bug tree-optimization/78189] [5/6/7 Regression] movaps generated for unaligned store in aligned struct, when struct is referenced via unaligned member.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 08:05:08 2016
New Revision: 241892

URL: https://gcc.gnu.org/viewcvs?rev=241892&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR tree-optimization/78189
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Fix
alignment computation.

* g++.dg/torture/pr78189.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78189.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 08:06:08 2016
New Revision: 241893

URL: https://gcc.gnu.org/viewcvs?rev=241893&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR tree-optimization/37150
* tree-vectorizer.h (vect_transform_slp_perm_load): Add n_perms
parameter.
* tree-vect-slp.c (vect_supported_load_permutation_p): Adjust.
(vect_analyze_slp_cost_1): Account for the real number of
permutations emitted and for dead loads.
(vect_transform_slp_perm_load): Add n_perms parameter counting
the number of emitted permutations.
* tree-vect-stmts.c (vectorizable_load): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/78189] [5/6 Regression] movaps generated for unaligned store in aligned struct, when struct is referenced via unaligned member.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] movaps   |[5/6 Regression] movaps
   |generated for unaligned |generated for unaligned
   |store in aligned struct,|store in aligned struct,
   |when struct is referenced   |when struct is referenced
   |via unaligned member.   |via unaligned member.
  Known to fail||5.4.0, 6.2.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/78224] [5/6/7 Regression] g++ ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
  Component|middle-end  |tree-optimization
  Known to work||4.7.4
   Target Milestone|--- |5.5
Summary|g++ v4.8+ ICE at -O2(-O1 on |[5/6/7 Regression] g++ ICE
   |gcc6) and above in  |at -O2(-O1 on gcc6) and
   |verify_loop_structure, at   |above in
   |cfgloop.c:1646  |verify_loop_structure, at
   ||cfgloop.c:1646
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.4.0, 6.2.0,
   ||7.0

--- Comment #2 from Richard Biener  ---
Confirmed.

t.ii: In function ‘void the_game(float)’:
t.ii:35:6: error: missing PHI def
 void the_game(float turn_amount)
  ^
first_18 = PHI <0(9), 1(2), (7)>

t.ii:35:6: internal compiler error: verify_gimple failed

on the GCC 6 branch and

t.ii:35:6: error: loop with header 3 not in loop tree
 void the_game(float turn_amount)
  ^~~~
t.ii:35:6: internal compiler error: in verify_loop_structure, at cfgloop.c:1646
0xbd58e6 verify_loop_structure()
/space/rguenther/src/svn/trunk/gcc/cfgloop.c:1646
0xf27531 checking_verify_loop_structure
/space/rguenther/src/svn/trunk/gcc/cfgloop.h:611
0xf276e4 loop_optimizer_init(unsigned int)
/space/rguenther/src/svn/trunk/gcc/loop-init.c:129
0x1346b7d tree_ssa_cs_elim
/space/rguenther/src/svn/trunk/gcc/tree-ssa-phiopt.c:116

on trunk.

[Bug middle-end/78228] [6/7 Regression] fstrict-overflow breaks code without overflow?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
No, it is phiopt1 that introduces ABS, but disabling VRP fixes it so I guess
some bogus range info is around.

   :
   _4 = i_3(D) < 0;
   width_5 = (unsigned int) _4;
-  if (i_3(D) > 0)
+  _19 = ABS_EXPR ;
+  i_18 = -_19;
+  if (i_18 < -9)

from:

  :
  # RANGE [0, 1]
  _4 = i_3(D) < 0;
  # RANGE [0, 1] NONZERO 1
  width_5 = (unsigned int) _4;
  if (i_3(D) > 0)
goto ;
  else
goto ;

  :
  # RANGE [-2147483647, -1]
  i_6 = -i_3(D);

  :
  # RANGE [-2147483648, 0]
  # i_1 = PHI 

which IMHO looks ok.

Looks like a abs_replacement bug where it creates a negate w/o proper
checking.

[Bug libstdc++/78231] New: Should std::sort use unqualifed iter_swap?

[correaa at llnl dot gov]

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

Bug ID: 78231
   Summary: Should std::sort use unqualifed iter_swap?
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: correaa at llnl dot gov
  Target Milestone: ---

Currently `std::sort` uses `std::iter_swap` internally. I think it is more
correct to use an unqualified `iter_swap` (after a `using std::swap_iter`
line).
This way, special iterators can be specialize the way they are value-swapped in
`std::sort` without touching the namespace `std`. (analogous to the case of
`std::swap` vs `swap`).

It sounds that the standard is vague regarding this issue.

See for example, line 1411 in
https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01347.html

note: this may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20577

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
  Component|rtl-optimization|target
   Target Milestone|--- |6.3
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Happens after forwprop.

t.i: In function ‘void fn3()’:
t.i:8:10: error: BB 6 can not throw but has an EH edge
 void fn3() {
  ^~~

looks like __builtin_ia32_tzcnt_u32 is not marked NOTHROW but we now fold
that in the backend.  CCing Jakub - this is a recent regression.  Foldings
may not transfer EH info themselves.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 241891)
+++ gcc/config/i386/i386.c  (working copy)
@@ -37664,7 +37664,7 @@ ix86_gimple_fold_builtin (gimple_stmt_it
  gsi_insert_before (gsi, g, GSI_SAME_STMT);
  g = gimple_build_assign (gimple_call_lhs (stmt), NOP_EXPR, lhs);
  gimple_set_location (g, loc);
- gsi_replace (gsi, g, true);
+ gsi_replace (gsi, g, false);
  return true;
}
   break;

fixes this.  Otherwise untested.

[Bug middle-end/78225] [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

[Bug tree-optimization/78218] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Indeed.

   :
-  a[1].v = 1;
   a[0] = a[1];
-  a[1].v = 0;
+  MEM[(int *)&a + 4B] = 0;

it misses the use of a[1] in a[0] = a[1]

I have a patch.

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Testing the patch (w/o fixing the nothrow thing)

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Are you sure -fcompare-debug does sth sensible with -flto?  With
-fno-use-linker-plugin you are turning on -ffat-lto-objects and thus you end up
emitting anything in the first place but you are comparing the fat part of the
LTO objects.

Difference:

--- t.gk.gkd2016-11-07 09:51:53.028517152 +0100
+++ t.gkd   2016-11-07 09:51:52.940516156 +0100
@@ -1,6 +1,6 @@


-;; Function VwViewer::FindViewPlane(std::__cxx11::basic_string, std::allocator > const&)
(_ZN8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE,
funcdef_no=21, cgraph_uid=1, symbol_order=1)
+;; Function VwViewer::FindViewPlane(std::__cxx11::basic_string, std::allocator > const&)
(_ZN8VwViewer13FindViewPlaneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE,
funcdef_no=19, cgraph_uid=1, symbol_order=1)

 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
@@ -51,7 +51,7 @@
 2:   struct VwAssimilator_2D D.;
 1:   struct VwAssimilator_2D_Geometry D.;

-;; Function VwViewer_2D::drawStickyBox() (_ZN11VwViewer_2D13drawStickyBoxEv,
funcdef_no=19, cgraph_uid=3, symbol_order=3)
+;; Function VwViewer_2D::drawStickyBox() (_ZN11VwViewer_2D13drawStickyBoxEv,
funcdef_no=21, cgraph_uid=3, symbol_order=3)

 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
ymbol_order=3)


so funcdef_no "swaps".

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 39977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39977&action=edit
Test-case

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Martin Liška  ---
(In reply to Aldy Hernandez from comment #2)
> This looks like a duplicate of pr77949, but I cannot confirm since I can't
> reproduce it.  Since this looks like it could be white space or column
> sensitive, could the reporter please include the testcase as an attachment,
> as opposed to cut and pasted onto the bug report?  Thanks.

I've attached the test-case. I guess it would be duplicate as it begins with
the same revision.

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So the caller of the gimple folding hook handles the EH stuff?

Of course it would be better if the builtins are ECF_NOTHROW; but that likely
needs analysing on if there are any x86 md builtins that aren't ECF_NOTHROW
(e.g. for -fnon-call-exceptions perhaps all that load/store/gather/scatter
should be), if there are any that shouldn't be ECF_LEAF etc.

[Bug driver/78196] [7 Regression] GCC self-test breaks native Windows x86 builds

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from tnfchris at gcc dot gnu.org ---
Author: tnfchris
Date: Mon Nov  7 09:17:55 2016
New Revision: 241895

URL: https://gcc.gnu.org/viewcvs?rev=241895&root=gcc&view=rev
Log:
 Fix the Windows native x86-64 build.

PR driver/78196
* Makefile.in (SELFTEST_FLAGS): Added -o /dev/null.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

[Bug driver/78196] [7 Regression] GCC self-test breaks native Windows x86 builds

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from tnfchris at gcc dot gnu.org ---
Fix committed in r241895

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> So the caller of the gimple folding hook handles the EH stuff?

Yes.

> Of course it would be better if the builtins are ECF_NOTHROW; but that
> likely needs analysing on if there are any x86 md builtins that aren't
> ECF_NOTHROW (e.g. for -fnon-call-exceptions perhaps all that
> load/store/gather/scatter should be), if there are any that shouldn't be
> ECF_LEAF etc.

Yeah, I'm leaving that for sth trunk only (and for somebody else).

[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Here's a list of the currently failing test cases.
That doesn't look to bad, problems mostly seem to be
with SELECT TYPE and ALLOCATE.

llocate_class_3.f90
allocate_with_source_16.f90
alloc_comp_class_3.f03
class_37.f03
class_allocate_22.f90
class_array_15.f03
class_to_type_1.f03
coarray_allocate_4.f08
coindexed_1.f90
dec_type_print.f90
dtio_5.f90
extends_type_of_1.f03
extends_type_of_3.f90
pr62125.f90
pr67525.f90
realloc_on_assign_27.f08
select_type_12.f03
select_type_13.f03
select_type_14.f03
select_type_17.f03
select_type_18.f03
select_type_19.f03
select_type_24.f90
select_type_25.f90
select_type_26.f03
select_type_27.f03
select_type_28.f03
select_type_2.f03
select_type_30.f03
select_type_34.f90
select_type_5.f03
select_type_8.f03
type_to_class_2.f03
type_to_class_3.f03
unlimited_polymorphic_1.f03
unlimited_polymorphic_22.f90
unlimited_polymorphic_24.f03
unlimited_polymorphic_25.f90
unlimited_polymorphic_26.f90

[Bug fortran/78226] Fill out location information everywhere

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> Here's a list of the currently failing test cases.
> ...

Confirmed with the addition of

linked_list.f90

All these failures are due to

Warning: No nextc in expression in statement at (1)

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Nono, you misunderstood -- I meant for the if-converter to produce

 if (LOOP_VECTORIZED)
  {
for (;;) // outer loop
  for (;;)
// if-converted inner loop
  }
 else
  {
for (;;) // outer loop
  for (;;) // inner loop
  }

if (and only if) the outer loop CFG shape matches what the vectorizer will
later eventually handle.

You still need adjustments to the vectorizer but only in its handling of
eliminating the LOOP_VECTORIZED conditional.

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So it's

addq(%r14), %rdi
jns .L98

.L98:
cmpl$2, %r9d
jne .L97
testq   %rdi, %rdi
jle .L97 

vs.

addq(%r14), %rdi
cmpq$0, %rdi
jge .L98

.L98:
jle .L97
cmpl$2, %r9d
jne .L97

I would guess the order of the branches after .L98 in the first case is
unrelated (to be checked).

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So the non-canonical GIMPLE is actually created by loop versioning and
update-ssa
replacing uses with new defs but not re-canonicalizing operand order.  Not
gimplification as I speculated.

[Bug fortran/50069] FORALL fails on a character array

[louis.krupp at zoho dot com]

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

--- Comment #9 from louis.krupp at zoho dot com ---
The attached patch adds a slight variation of Tobias Burnus's patch for 50069
to my patch for 55086, and it seems to fix the two tests in 50069.

"make check-fortran" runs with no surprises.

Louis


  On Sun, 06 Nov 2016 09:09:26 -0800 dominiq at lps dot ens.fr
 wrote  
 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 
 >  
 > Dominique d'Humieres  changed: 
 >  
 >What|Removed |Added 
 >  
 >  CC||lkrupp at gcc dot gnu.org 
 >  
 > --- Comment #8 from Dominique d'Humieres  --- 
 > Related to pr55086, but the two tests are not fixed by the patch at 
 > https://gcc.gnu.org/ml/fortran/2016-10/msg00228.html even when compiled with 
 > the option -fforce-forall-temp. 
 >  
 > --  
 > You are receiving this mail because: 
 > You are on the CC list for the bug.

[Bug target/77822] [6/7 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

--- Comment #18 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Nov  7 11:43:57 2016
New Revision: 241898

URL: https://gcc.gnu.org/viewcvs?rev=241898&root=gcc&view=rev
Log:
[AArch64] Fix PR target/77822: Use tighter predicates for zero_extract patterns

PR target/77822
* config/aarch64/aarch64.md (*tb1): Use
aarch64_simd_shift_imm_ predicate for operand 1.
(, ANY_EXTRACT): Use tighter predicates on operands 2 and 3
to restrict them to an appropriate range and add FAIL check if the
region they specify is out of range.  Delete useless constraint
strings.
(*, ANY_EXTRACT): Add appropriate predicates on operands
2 and 3 to restrict their range and add pattern predicate.

* g++.dg/torture/pr77822.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr77822.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[6/7 Regression] arm64  |[6 Regression] arm64 Error:
   |Error: immediate value out  |immediate value out of
   |of range 0 to 63 at operand |range 0 to 63 at operand 3
   |3   |

--- Comment #19 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. will backport to the branch after it's had some time to bake

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

--- Comment #20 from ktkachov at gcc dot gnu.org ---
One of the RTL sequences before combine showing the problem is:

(insn 94 93 95 18 (set (reg:DI 143)
(const_int 160 [0xa0])) "bad.cpp":19 50 {*movdi_aarch64}
 (nil))
(insn 95 94 96 18 (set (reg:DI 144)
(ashiftrt:DI (reg:DI 75 [ b.0_3 ])
(subreg:QI (reg:DI 143) 0))) "bad.cpp":19 647
{*aarch64_ashr_sisd_or_int_di3}
 (expr_list:REG_DEAD (reg:DI 143)
(expr_list:REG_EQUAL (ashiftrt:DI (reg:DI 75 [ b.0_3 ])
(const_int -96 [0xffa0]))
(nil
(insn 96 95 97 18 (set (reg:DI 145)
(and:DI (reg:DI 144)
(const_int 1 [0x1]))) "bad.cpp":19 470 {anddi3}
 (expr_list:REG_DEAD (reg:DI 144)
(nil)))
(insn 97 96 98 18 (set (reg:CC 66 cc)
(compare:CC (reg:DI 145)
(const_int 0 [0]))) "bad.cpp":19 393 {cmpdi}
 (expr_list:REG_DEAD (reg:DI 145)
(nil)))
(jump_insn 98 97 99 18 (set (pc)
(if_then_else (eq (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 105)
(pc))) "bad.cpp":19 9 {condjump}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 5000 (nil)))



Some of the dubious combinations combine tries are:

Trying 94, 95 -> 96:
Successfully matched this instruction:
(set (reg:DI 145)
(zero_extract:DI (reg:DI 75 [ b.0_3 ])
(const_int 1 [0x1])
(const_int 160 [0xa0])))


Trying 96 -> 97:
Failed to match this instruction:
(set (reg:CC_NZ 66 cc)
(compare:CC_NZ (zero_extract:DI (reg:DI 75 [ b.0_3 ])
(const_int 1 [0x1])
(const_int 160 [0xa0]))
(const_int 0 [0])))

Trying 96 -> 98:
Successfully matched this instruction:
(set (pc)
(if_then_else (eq (zero_extract:DI (reg:DI 75 [ b.0_3 ])
(const_int 1 [0x1])
(const_int 160 [0xa0]))
(const_int 0 [0]))
(label_ref:DI 105)
(pc)))


If I put a breakpoint at expand_compound_operation I already see arguments such
as:
(zero_extract:DI (reg:DI 75 [ b.0_3 ])
(const_int 1 [0x1])
(const_int 160 [0xa0]))

Given that the input is already dodgy (DImode shift by 160) I don't know
whether the subst or make_compound_operation
machinery in combine should be trying too hard to reject forming these
zero_extracts. Maybe something should be taking
SHIFT_COUNT_TRUNCATED into account?

[Bug middle-end/78228] [6/7 Regression] fstrict-overflow breaks code without overflow?

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 12:25:09 2016
New Revision: 241899

URL: https://gcc.gnu.org/viewcvs?rev=241899&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR tree-optimization/78228
* tree-ssa-phiopt.c (abs_replacement): Avoid introducing
undefined behavior.

* gcc.dg/tree-ssa/phi-opt-15.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/78218] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 12:26:00 2016
New Revision: 241900

URL: https://gcc.gnu.org/viewcvs?rev=241900&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR tree-optimization/78218
* gimple-ssa-store-merging.c
(pass_store_merging::terminate_all_aliasing_chains):
Drop unused argument, fix alias check to also consider uses.
(pass_store_merging::execute): Adjust.

* gcc.dg/torture/pr78218.c: New testcase.

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

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 12:26:48 2016
New Revision: 241901

URL: https://gcc.gnu.org/viewcvs?rev=241901&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR target/78229
* config/i386/i386.c (ix86_gimple_fold_builtin): Do not adjust
EH info.

* g++.dg/pr78229.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/pr78229.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78228] [6 Regression] fstrict-overflow breaks code without overflow?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[6/7 Regression]|[6 Regression]
   |fstrict-overflow breaks |fstrict-overflow breaks
   |code without overflow?  |code without overflow?

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/78218] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
Ah, so combine isn't really doing anything wrong here -- for the "plain"
shift it already only refuses it because the target does not allow it.
Some targets *do* allow shifting by amounts more than a register width.

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug target/78229] [6/7 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2305

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  7 12:32:34 2016
New Revision: 241902

URL: https://gcc.gnu.org/viewcvs?rev=241902&root=gcc&view=rev
Log:
2016-11-07  Richard Biener  

PR target/78229
* config/i386/i386.c (ix86_gimple_fold_builtin): Do not adjust
EH info.

* g++.dg/pr78229.C: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr78229.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
Oh, I see.  Makes sense.  I'll look into it soonish after handling a
high-priority interrupt that came in over the weekend...

[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Hmm, good question whether it makes sense or not; some -fcompare-debug checking
with LTO would be useful, the question is only what to compare. 

Simply rejecting -fcompare-debug with -ffat-lto-objects would be also
acceptable for me, assuming that -fcompare-debug -fno-fat-lto-objects does
something sensible.

[Bug rtl-optimization/78232] New: [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c

[clyon at gcc dot gnu.org]

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

Bug ID: 78232
   Summary: [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: segher at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

Hi,

Since r241824:
commit 6df23cf103de2671effb6adaf49348409141b462
Author: segher 
Date:   Thu Nov 3 16:04:22 2016 +

combine lhs zero_extract fix (PR78186)


PR rtl-optimization/78186
* combine.c (change_zero_ext): Mask the RHS of a zero_extract as
well, when converting to IOR.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241824
138bc75d-0d04-0410-96

I have noticed execution failures on "old" arm targets:
   gcc.dg/torture/pr48124-4.c   -O1  execution test
  gcc.dg/torture/pr48124-4.c   -O2  execution test
  gcc.dg/torture/pr48124-4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
  gcc.dg/torture/pr48124-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
  gcc.dg/torture/pr48124-4.c   -O3 -g  execution test
  gcc.dg/torture/pr48124-4.c   -Os  execution test

For instance on target arm-none-linux-gnueabi --with-cpu=cortex-a9
--with-mode=arm
and running the tests with -march=armv5t

or on arm-none-eabi with default mode/cpu and no special runtest flags
if that's easier.

[Bug target/65105] [i386] XMM registers are not used for 64bit computations on 32bit target

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 13:07:32 2016
New Revision: 241903

URL: https://gcc.gnu.org/viewcvs?rev=241903&root=gcc&view=rev
Log:
PR middle-end/71529
* gcc.target/i386/pr71529.C: Moved to ...
* g++.dg/opt/pr71529.C: ... here.  New test.  Guard for i?86/x86_64.

PR target/64411
* gcc.target/i386/pr64411.C: Moved to ...
* g++.dg/opt/pr64411.C: ... here.  New test.  Guard for i?86/x86_64
lp64.

PR target/65105
* gcc.target/i386/pr65105-4.C: Moved to ...
* g++.dg/opt/pr65105-4.C: ... here.  New test.  Guard for i?86/x86_64.
Run into compile test rather than execute test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr64411.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/g++.dg/opt/pr65105-4.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/g++.dg/opt/pr71529.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Removed:
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 13:07:32 2016
New Revision: 241903

URL: https://gcc.gnu.org/viewcvs?rev=241903&root=gcc&view=rev
Log:
PR middle-end/71529
* gcc.target/i386/pr71529.C: Moved to ...
* g++.dg/opt/pr71529.C: ... here.  New test.  Guard for i?86/x86_64.

PR target/64411
* gcc.target/i386/pr64411.C: Moved to ...
* g++.dg/opt/pr64411.C: ... here.  New test.  Guard for i?86/x86_64
lp64.

PR target/65105
* gcc.target/i386/pr65105-4.C: Moved to ...
* g++.dg/opt/pr65105-4.C: ... here.  New test.  Guard for i?86/x86_64.
Run into compile test rather than execute test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr64411.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/g++.dg/opt/pr65105-4.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/g++.dg/opt/pr71529.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Removed:
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 13:07:32 2016
New Revision: 241903

URL: https://gcc.gnu.org/viewcvs?rev=241903&root=gcc&view=rev
Log:
PR middle-end/71529
* gcc.target/i386/pr71529.C: Moved to ...
* g++.dg/opt/pr71529.C: ... here.  New test.  Guard for i?86/x86_64.

PR target/64411
* gcc.target/i386/pr64411.C: Moved to ...
* g++.dg/opt/pr64411.C: ... here.  New test.  Guard for i?86/x86_64
lp64.

PR target/65105
* gcc.target/i386/pr65105-4.C: Moved to ...
* g++.dg/opt/pr65105-4.C: ... here.  New test.  Guard for i?86/x86_64.
Run into compile test rather than execute test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr64411.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/g++.dg/opt/pr65105-4.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/g++.dg/opt/pr71529.C
  - copied, changed from r241902,
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Removed:
trunk/gcc/testsuite/gcc.target/i386/pr64411.C
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
trunk/gcc/testsuite/gcc.target/i386/pr71529.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener  ---
Oh, and the duplicate costing is from the repeated use of pol_z(:,0,kg) and
similar terms.  It's counted only once during scalar cost compute and not at
all
if not all of the uses are vectorized.

[Bug c/78233] New: compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static

[suokkos at gmail dot com]

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

Bug ID: 78233
   Summary: compute_idf fails quick_push size check when compiling
libgcc for Debian armel with qemu-arm-static
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suokkos at gmail dot com
  Target Milestone: ---

Created attachment 39980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39980&action=edit
libgcc2.i from xgcc

Same source compiled fine with amd64 native tools.

GCC tested are:
1. xgcc (GCC) 7.0.0 20161105 (experimental) (github: trunk@241870)
2. gcc (Debian 6.2.0-11) 6.2.0 20161103

System:
/usr/bin/qemu-arm-static
Debian sid chroot

Configure:
1. ../configure
That resulted to config.status including
--enable-languages=c,c++,fortran,lto,objc
2. About
PATH=/home/coren/project/gcc-6-6.2.0/bin:/usr/lib/arm-linux-gnueabi/gcc/bin:/home/coren/bin:/opt/wine-staging/bin:/usr/local/bin:/usr/bin:/bin
CC=arm-linux-gnueabi-gcc-6 CXX=arm-linux-gnueabi-g++-6   
LDFLAGS_FOR_TARGET=-Wl,-z,relro  
LD_LIBRARY_PATH=/home/coren/project/gcc-6-6.2.0/build/gcc/ada/rts ../configure
-v --with-pkgversion='Debian 6.2.0-10'
--with-bugurl='file:///usr/share/doc/gcc-6/README.Bugs'
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=arm-linux-gnueabi- --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 --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armel/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armel
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armel
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv4t --with-float=soft --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi

Command to trigger the bug:
/home/coren/project/gcc/buildarmel/./gcc/xgcc
-B/home/coren/project/gcc/buildarmel/./gcc/
-B/usr/local/armv7l-unknown-linux-gnueabi/bin/
-B/usr/local/armv7l-unknown-linux-gnueabi/lib/ -isystem
/usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF
_muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS

Backtrace from error:
#12 0x00eca52c in fancy_abort(char const*, int, char const*) ()
#13 0x002e15c4 in compute_idf(bitmap_head*, bitmap_head*) ()
#14 0x007d5070 in (anonymous namespace)::pass_build_ssa::execute(function*) ()
#15 0x00665db4 in execute_one_pass(opt_pass*) ()

Compiler error:
../../../libgcc/libgcc2.c: In function ‘__muldi3’:
../../../libgcc/libgcc2.c:557:1: internal compiler error: in quick_push, at
vec.h:863
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 13:33:37 2016
New Revision: 241905

URL: https://gcc.gnu.org/viewcvs?rev=241905&root=gcc&view=rev
Log:
PR target/77834
* alias.c (nonoverlapping_memrefs_p): If one decl is
FUNCTION_DECL or LABEL_DECL and the other is not, return 1.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c

[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov  7 13:46:31 2016
New Revision: 241906

URL: https://gcc.gnu.org/viewcvs?rev=241906&root=gcc&view=rev
Log:
2016-11-07  Thomas Koenig  

Backport from trunk
PR fortran/78221
* arith.c (gfc_complex2real):  Change gfc_warning_now to
gfc_warning.

2016-11-07  Thomas Koenig  

Backport from trunk
PR fortran/78221
* gfortran.dg/warn_conversion_9.f90:  New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_conversion_9.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/arith.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/78234] New: [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[trippels at gcc dot gnu.org]

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

Bug ID: 78234
   Summary: [7 Regression] LLVM reports
dynamic-stack-buffer-overflow in
gimple-ssa-store-merging.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
  Target Milestone: ---

with CXX="clang++ -fsanitize=address -fsanitize-address-use-after-scope"
../gcc/configure ...

I get:

markus@x4 libgcc % LSAN_OPTIONS="detect_leaks=0"
/var/tmp/gcc_build_dir_/./gcc/xgcc -B/var/tmp/gcc_build_dir_/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-g -O2 -O2  -g -O2 -DIN_GCC-W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include
-I../../../gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS -Wno-missing-prototypes -Wno-type-limits -o trunctfxf2.o -MT
trunctfxf2.o
-MD -MP -MF trunctfxf2.dep  -c ../../../gcc/libgcc/soft-fp/trunctfxf2.c
-fvisibility=hidden -DHIDE_EXPORTS
=
==4958==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7fff682b1f03 at pc 0x02f8cb35 bp 0x7fff682b1eb0 sp 0x7fff682b1ea8
READ of size 1 at 0x7fff682b1f03 thread T0
#0 0x2f8cb34 in (anonymous namespace)::clear_bit_region(unsigned char*,
unsigned int, unsigned int)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:332:14
#1 0x2f8bf63 in (anonymous namespace)::encode_tree_to_bitpos(tree_node*,
unsigned char*, int, int, unsigned int)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:449:6
#2 0x2f8b4c6 in (anonymous namespace)::merged_store_group::apply_stores()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:657:18
#3 0x2f8787f in (anonymous
namespace)::imm_store_chain_info::coalesce_immediate_stores()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:925:24
#4 0x2f8787f in (anonymous
namespace)::imm_store_chain_info::terminate_and_process_chain()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:1260
#5 0x2f8787f in (anonymous
namespace)::pass_store_merging::terminate_and_release_chain((anonymous
namespace)::imm_store_chain_info*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:844
#6 0x2f8a72e in (anonymous
namespace)::pass_store_merging::terminate_all_aliasing_chains((anonymous
namespace)::imm_store_chain_info**, bool, gimple*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:829:4
#7 0x2f85e1f in (anonymous
namespace)::pass_store_merging::execute(function*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:1488:4
#8 0x1630b4a in execute_one_pass(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2341:22
#9 0x1632baa in execute_pass_list_1(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2430:11
#10 0x1632bcf in execute_pass_list_1(opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2431:9
#11 0x1601146 in execute_pass_list(function*, opt_pass*)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/passes.c:2441:3
#12 0xb7ffbb in cgraph_node::expand()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2001:3
#13 0xb8a28a in expand_all_functions()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2137:10
#14 0xb8a28a in symbol_table::compile()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2494
#15 0xb8bf50 in symbol_table::finalize_compilation_unit()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/cgraphunit.c:2584:3
#16 0x18bc495 in compile_file()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:493:15
#17 0x18ba33e in do_compile()
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:2012:11
#18 0x18ba33e in toplev::main(int, char**)
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/toplev.c:2146
#19 0x327a648 in main
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/main.c:39:17
#20 0x7f4f7fb932f0 in __libc_start_main
/home/markus/glibc/csu/../csu/libc-start.c:286
#21 0x588e69 in _start /home/markus/glibc/csu/../sysdeps/x86_64/start.S:120

Address 0x7fff682b1f03 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow
/var/tmp/gcc_build_dir_/gcc/../../gcc/gcc/gimple-ssa-store-merging.c:332

[Bug middle-end/78233] compute_idf fails quick_push size check when compiling libgcc for Debian armel with qemu-arm-static

[suokkos at gmail dot com]

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

--- Comment #1 from Pauli  ---
Sorry. Error in original report:
gcc (Debian 6.2.0-11) 6.2.0 20161103

with command:
gcc -isystem /usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF
_muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS

works fine. I forgot that actual compile job is separate process when testing
system gcc.

On amd64 host:
/home/coren/project/gcc/buildamd64/./gcc/xgcc
-B/home/coren/project/gcc/buildamd64/./gcc/ -isystem
/usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc
-I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include-o _muldi3.o -MT _muldi3.o -MD -MP -MF
_muldi3.dep -DL_muldi3 -c
/home/coren/project/gcc/buildarmel/armv7l-unknown-linux-gnueabi/libgcc/libgcc2.i
-fvisibility=hidden -DHIDE_EXPORTS

works fine.


Too bad compile cycle for armel is very long (about 30 hours) making it very
annoying that cc1 doesn't have debug symbols.

[Bug fortran/78221] [6/7 Regression] bogus warning: Non-zero imaginary part discarded in conversion [-Wconversion]

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Koenig  ---
Fixed on all affected branches, closing.

[Bug tree-optimization/78224] [5/6/7 Regression] g++ ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
On the branch this is call-cdce, probably on trunk as well.  It wrecks loop
info
when the call is in the loop latch and we have an EH loop exit in this case:

  /* Now find the join target bb -- split bi_call_bb if needed.  */
  if (stmt_ends_bb_p (bi_call))
{
  /* We checked that there was a fallthrough edge in
 can_guard_call_p.  */
  join_tgt_in_edge_from_call = find_fallthru_edge (bi_call_bb->succs);
  gcc_assert (join_tgt_in_edge_from_call);
  free_dominance_info (CDI_DOMINATORS);
}

if we split the edge everything is fine.  Otherwise the pass needs to handle
PHIs in join_tgt_in_edge_from_call->dest.  So we can conditionally split
only.

Index: gcc/tree-call-cdce.c
===
--- gcc/tree-call-cdce.c(revision 241902)
+++ gcc/tree-call-cdce.c(working copy)
@@ -800,15 +800,21 @@ shrink_wrap_one_built_in_call_with_conds
   join_tgt_in_edge_from_call = find_fallthru_edge (bi_call_bb->succs);
   if (join_tgt_in_edge_from_call == NULL)
 return false;
+  /* We don't want to handle PHIs.  */
+  if (EDGE_COUNT (join_tgt_in_edge_from_call->dest->preds) > 1)
+   join_tgt_bb = split_edge (join_tgt_in_edge_from_call);
+  else
+   join_tgt_bb = join_tgt_in_edge_from_call->dest;
   free_dominance_info (CDI_DOMINATORS);
 }
   else
-join_tgt_in_edge_from_call = split_block (bi_call_bb, bi_call);
+{
+  join_tgt_in_edge_from_call = split_block (bi_call_bb, bi_call);
+  join_tgt_bb = join_tgt_in_edge_from_call->dest;
+}

   bi_call_bsi = gsi_for_stmt (bi_call);

-  join_tgt_bb = join_tgt_in_edge_from_call->dest;
-
   /* Now it is time to insert the first conditional expression
  into bi_call_bb and split this bb so that bi_call is
  shrink-wrapped.  */


similar patch works on trunk.

[Bug tree-optimization/78234] [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-07
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I think I saw this independently while writing some unit tests.
I'm already testing a patch.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #22 from Dominik Vogt  ---
Does that mean that every pattern that uses zero_extract or sign_extract needs
to check itself that 0 <= size+pos < GET_MODE_BITS (mode)?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

dhowells at redhat dot com  changed:

   What|Removed |Added

 CC||dhowells at redhat dot com

--- Comment #13 from dhowells at redhat dot com  ---
Another possibility, at least for handling ilog2(), could be to provide
__builtin_ilog2(unsigned long x) as an alternative.

Note that the kernel ilog2() has the property that the result is undefined if
x==0 (and will jump to ilog2_NaN() if x is constant 0).

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to dhowe...@redhat.com from comment #13)
> Another possibility, at least for handling ilog2(), could be to provide
> __builtin_ilog2(unsigned long x) as an alternative.
> 
> Note that the kernel ilog2() has the property that the result is undefined
> if x==0 (and will jump to ilog2_NaN() if x is constant 0).

Ugh, no.  Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
(or ctzl or ctzll depending on what the type is)?

[Bug libstdc++/78235] New: [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

Bug ID: 78235
   Summary: [7 Regression] libstdc++ testsuite run.cc ICE in
int_bit_position
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

Created attachment 39981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39981&action=edit
preprocessed source from 20_util/variant/run.cc

In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/run.cc:21:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant: In instantiation
of 'class std::variant, std::allocator > >':
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/run.cc:54:  
required from here
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956: internal
compiler error: tree check: expected field_decl, have template_decl in
int_bit_position, at tree.h:5396

[Bug libstdc++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New.

[Bug tree-optimization/46006] vectorization outside of loops

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So currently we indeed miss the "sinks":

t.i:29:6: note: === vect_analyze_data_ref_accesses ===
t.i:29:6: note: Detected interleaving load MEM[(struct B *)&v] and MEM[(struct
B *)&v + 8B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)&v] and MEM[(struct
B *)&v + 16B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)&v] and MEM[(struct
B *)&v + 24B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)&v] and MEM[(struct
B *)&v + 32B]
t.i:29:6: note: Detected interleaving load MEM[(struct B *)&v] and MEM[(struct
B *)&v + 40B]
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->c.y
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->c.z
t.i:29:6: note: Detected interleaving load u_43(D)->c.x and u_43(D)->d
t.i:29:6: note: Detected interleaving load of size 6 starting with v$a$x_48 =
MEM[(struct B *)&v];
t.i:29:6: note: Detected interleaving load of size 4 starting with _5 =
u_43(D)->c.x;
t.i:29:6: note: not vectorized: no grouped stores in basic block.

two classes of sinks are currently missing: reductions and vector CONSTRUCTORs

parts of the testcase might be handled with reduction support.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||janus at gcc dot gnu.org
Summary|[5/6/7 Regression] ICE with |[5/6/7 Regression] [F08]
   |attempted pointer   |ICE on invalid pointer
   |initialization  |initialization

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
> The example is not legal.  Nonetheless, the compiler should not ICE.

Could you explain why exactly the example is illegal? I guess because 'data'
lacks the TARGET attribute?

When removing the POINTER attribute on 'data', the example is correctly
rejected. So possibly the problem is that 'data%i' is believed to have the
POINTER attribute, because 'data' itself is a pointer.

[Bug libstdc++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
20_util/variant/compile.cc produces a similar error:

In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/compile.cc:21:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant: In instantiation
of 'class std::variant, std::allocator > >':
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:881:  
required by substitution of 'template static std::true_type
std::__do_is_default_constructible_impl::__test(int) [with _Tp =
std::variant,
std::allocator > >;  = ]'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:892:  
required from 'struct std::__is_default_constructible_impl, std::allocator >
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:143:  
required from 'struct std::__and_, std::allocator >
> > >, std::__is_default_constructible_impl, std::allocator >
> > >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:896:  
required from 'struct std::__is_default_constructible_atom, std::allocator >
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:917:  
required from 'struct std::__is_default_constructible_safe, std::allocator >
>, false>'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:923:  
required from 'struct std::is_default_constructible, std::allocator >
> >'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/type_traits:2966:  
required from 'constexpr const bool
std::is_default_constructible_v, std::allocator >
> >'
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/compile.cc:56:
required from here
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/variant:956: internal
compiler error: tree check: expected field_decl, have template_decl in
int_bit_position, at tree.h:5396

[Bug fortran/71860] [5/6/7 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|[5/6/7 Regression] ICE on   |[5/6/7 Regression] [OOP]
   |pointing to null(mold), |ICE on pointing to
   |verify_gimple failed|null(mold), verify_gimple
   ||failed

--- Comment #3 from janus at gcc dot gnu.org ---
Is this example invalid? If yes, why?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #15 from dhowells at redhat dot com  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to dhowe...@redhat.com from comment #13)
> ...
> Ugh, no.  Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
> (or ctzl or ctzll depending on what the type is)?

Comparing the kernel's ilog2() to your suggestion:

int kernel_ilog2(unsigned long x)
{
return ilog2(x);
}

int jakub_ilog2(unsigned long x)
{
return x && (x & -x) == x ? __builtin_ctz (x) : -1;
}

compiled with -Os for x86_64 gives:

 :
   0:   83 c8 ffor $0x,%eax
   3:   48 0f bd c7 bsr%rdi,%rax
   7:   c3  retq   

0008 :
   8:   83 c8 ffor $0x,%eax
   b:   48 85 fftest   %rdi,%rdi
   e:   74 17   je 27 
  10:   48 89 famov%rdi,%rdx
  13:   0f bc c7bsf%edi,%eax
  16:   48 f7 daneg%rdx
  19:   48 21 faand%rdi,%rdx
  1c:   48 39 d7cmp%rdx,%rdi
  1f:   ba ff ff ff ff  mov$0x,%edx
  24:   0f 45 c2cmovne %edx,%eax
  27:   c3  retq   

Note that in the kernel variant, the initial OR instruction is superfluous, but
is required by fls() and fls64() which x86_64 is using behind the scenes.  Not
all arches, however, use fls() and fls64() to implement ilog2().

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[coollpe at hotmail dot com]

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

--- Comment #17 from peien luo  ---
(In reply to Dmitry Vyukov from comment #16)
> > The stack size limit in my box is 8M. I have also checked /proc/limits.
> 
> So, is increasing stack size help?
> Tsan increases stack consumption. 8MB is not that much provided that you
> have 1MB frames.
> 
> > By enabling -fstack-protector-all, in gdb it still may get segfault here 
> > (at function entry).
> 
> Stack protector will not help to detect/prevent stack overflow. It only
> prevents PC overwrite on buffer overflows.

Increased to 80MB, no help.

In a 4.9.0 tsan case, I have come across a segfault in gdb with back trace:
23  void MutexSet::Add(u64 id, bool write, u64 epoch) {
24// Look up existing mutex with the same id.
25for (uptr i = 0; i < size_; i++) {
26  if (descs_[i].id == id) {
27descs_[i].count++;
28descs_[i].epoch = epoch;
29return;
30  }

(gdb) p size_
$2 = 139907922088632

(gdb) bt
#0  0x7f3ed9c5f37c in __tsan::MutexSet::Add
(this=this@entry=0x7f3ec6f63080, id=55166398195828824, 
write=write@entry=true, epoch=1680548) at
../../../../libsanitizer/tsan/tsan_mutexset.cc:26
#1  0x7f3ed9c555e5 in __tsan::MutexLock (thr=thr@entry=0x7f3ec6e78840,
pc=pc@entry=139907918263873, 
addr=addr@entry=138040248895576) at
../../../../libsanitizer/tsan/tsan_rtl_mutex.cc:109
#2  0x7f3ed9c4f6ae in __interceptor_pthread_mutex_lock (m=0x7d8c0858)
at ../../../../libsanitizer/tsan/tsan_interceptors.cc:811
...

something overflowed?

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #16 from dhowells at redhat dot com  ---
I guess the following could be used:

int clz_ilog2(unsigned long x)
{
return __builtin_clz(x);
}

which compiles to:

0027 :
  27:   0f bd c7bsr%edi,%eax
  2a:   83 f0 1fxor$0x1f,%eax
  2d:   c3  retq   

though the XOR is superfluous - for any valid input to ilog2(), I think the
output is always in the range 0-31.

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Here's the commit, the PR number was incorrect.

Author: tkoenig
Date: Mon Nov  7 15:25:21 2016
New Revision: 241909

URL: https://gcc.gnu.org/viewcvs?rev=241909&root=gcc&view=rev
Log:
2016-11-07  Thomas Koenig  

PR fortran/78226
* match.c (gfc_match_select_type):  Add where for expr1.
* resolve.c (resolev_select_type): Add where for expr1 of new
statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[dhowells at redhat dot com]

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

--- Comment #17 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #16)
> ...
> 0027 :
>   27:   0f bd c7bsr%edi,%eax
>   2a:   83 f0 1fxor$0x1f,%eax
>   2d:   c3  retq   
> 
> though the XOR is superfluous - for any valid input to ilog2(), I think the
> output is always in the range 0-31.

Ah - it's not actually an AND, so the XOR isn't necessarily superfluous.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

--- Comment #23 from Dominik Vogt  ---
Regarding the ARM patch:

+  {
+if (!IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
+  1, GET_MODE_BITSIZE (DImode) - 1))
+ FAIL;
+  }

Isn't this patch too simple?  On s390x we get "pos" -N (operand 3) with "size"
M, so the correct check should be:

  if (! IN_RANGE (INTVAL (operands[3]), 0, GET_MODE_BITSIZE (DImode) - 1)
  || IN_RANGE (INTVAL (operands[3]) + INTVAL (operands[2]),
   1, GET_MODE_BITSIZE (DImode)))
FAIL;

It's just luck that the test program does not generate something like

  (zero_extract (...) (-1) (16))

Which can only be caught by testing "pos" individually.

--

Also, I don't understand why the valid range is "1, GET_MODE_BITSIZE (DImode) -
1", shouldn't it be "1, GET_MODE_BITSIZE (DImode)" without the "- 1"?

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

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

--- Comment #24 from ktkachov at gcc dot gnu.org ---
(In reply to Dominik Vogt from comment #23)
> Regarding the ARM patch:
> 
> +  {
> +if (!IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
> +1, GET_MODE_BITSIZE (DImode) - 1))
> + FAIL;
> +  }
> 
> Isn't this patch too simple?  On s390x we get "pos" -N (operand 3) with
> "size" M, so the correct check should be:
> 
>   if (! IN_RANGE (INTVAL (operands[3]), 0, GET_MODE_BITSIZE (DImode) - 1)
>   || IN_RANGE (INTVAL (operands[3]) + INTVAL (operands[2]),
>1, GET_MODE_BITSIZE (DImode)))
> FAIL;
> 
> It's just luck that the test program does not generate something like
> 
>   (zero_extract (...) (-1) (16))
> 
> Which can only be caught by testing "pos" individually.
> 
> --
> 
> Also, I don't understand why the valid range is "1, GET_MODE_BITSIZE
> (DImode) - 1", shouldn't it be "1, GET_MODE_BITSIZE (DImode)" without the "-
> 1"?

operands[3] also gets the aarch64_simd_shift_imm_di predicate which checks that
IN_RANGE (INTVAL (op), 0, 63), so we should be okay

[Bug libstdc++/78236] New: regex_iterator constructor is incomplete and creates uninitialized values that may be used

[christophe.monat at st dot com]

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

Bug ID: 78236
   Summary: regex_iterator constructor is incomplete and creates
uninitialized values that may be used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.monat at st dot com
  Target Milestone: ---

Created attachment 39982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982&action=edit
Porposed patch to fix the regex_iterator constructor

The following code snippet, when compiled on X8664 with gcc-trunk, dumps core
with any optimization level (you might need to add -std=c++11 depending on your
compiler version).

#include 
#include 

int main(int argc, char *argv[])
{
  char const s[] = "afoo";
  std::basic_regex r("(f+)");
  {
std::cregex_iterator i(s, s+sizeof(s), r);
std::cregex_iterator j(s, s+sizeof(s), r);
assert(i == j);
  }
  // The iterator manipulation code must be repeated in the same scope
  // to expose the undefined read during the execution of the ==
  // operator (stack location reuse)
  {
std::cregex_iterator i(s, s+sizeof(s), r);
std::cregex_iterator j;
assert(!(i == j));
  }
  return 0;
}

This happens during the execution of the operator== that reads some of the
private implementation fields, some of which appear not to be initialized.

The issue is due to the fact that the regex_iterator
(libstdc++v3/include/bits/regex.h) has for instance a pointer member (const
regex_type* _M_pregex) and a user-defined constructor that fails to initialize
it

I have attached a trivial patch that initializes the two fields that are to be
explicitly initialized to avoid the reported issue.

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[christophe.monat at st dot com]

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

--- Comment #1 from Christophe Monat  ---
Comment on attachment 39982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39982
Proposed patch to fix the regex_iterator constructor

>diff --git a/libstdc++-v3/include/bits/regex.h 
>b/libstdc++-v3/include/bits/regex.h
>index a7d45e6..bb0a167 100644
>--- a/libstdc++-v3/include/bits/regex.h
>+++ b/libstdc++-v3/include/bits/regex.h
>@@ -2454,7 +2454,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>* one-past-the-end of a range.
>*/
>   regex_iterator()
>-  : _M_match()
>+  : _M_pregex(), _M_flags(regex_constants::match_default), _M_match()
>   { }
> 
>   /**

[Bug libstdc++/78237] New: std::timed_mutex::try_lock_for/until affected by system realtime clock

[marejde at gmail dot com]

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

Bug ID: 78237
   Summary: std::timed_mutex::try_lock_for/until affected by
system realtime clock
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marejde at gmail dot com
  Target Milestone: ---

The following program:

#include 
#include 
#include 
#include 

int main(void)
{
std::recursive_timed_mutex mutex;

bool ret = mutex.try_lock_for(std::chrono::seconds(2));
std::cout << "ret = " << ret << "\n";

std::thread thread([&mutex]() {
std::this_thread::sleep_for(std::chrono::seconds(1));
auto now = std::chrono::steady_clock::now();
bool ret = mutex.try_lock_until(now +
std::chrono::seconds(60));
std::cout << "ret = " << ret << "\n";
});

thread.join();

return 0;
}

does not work as expected when modifying the system time. try_lock_until()
returns false immediately when time is advanced passed now + 60s.

Compiling with Clang and libc++ try_lock_until() waits for 60 seconds
regardless of what the system time is changed to.

Looking at the implementation in libstdc++ it looks like it ends up calling
pthread_mutex_timedwait() (that uses CLOCK_REALTIME) while the libc++
implementation implements the methods with a condition variable.

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

--- Comment #25 from Dominik Vogt  ---
I see.

This test verifies that a negative "pos" is indeed rejected:
--
#include  
int g; 
void foo(int64_t b) 
{ 
  if (b >> 65 & 1) 
g = b; 
} 
--

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[herve.codina at gmail dot com]

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

Hervé Codina  changed:

   What|Removed |Added

 CC||herve.codina at gmail dot com

--- Comment #5 from Hervé Codina  ---
Same problem using Tavian attached source file on gcc 4.9.3 and 5.2.0.

Note that the problem appears when optimization is turned on (flag -O1 or more)
Without optimization, no warning.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-07
  Component|libgcc  |target
Summary|libgcc, compilation for |libgcc, compilation for
   |target m68k-linux breaks in |target m68k-linux breaks in
   |linux_atomic.c, #define |linux_atomic.c
   |COMMA , |
 Ever confirmed|0   |1

--- Comment #3 from Joseph S. Myers  ---
Confirmed.  Building libgcc for m68k-linux-gnu --with-arch=cf fails for every
GCC version from 4.7 onwards (4.6 didn't have linux-atomic.c, so I'm not sure
if this counts as a regression).

Errors with current mainline:

/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c: In
function '__sync_bool_compare_and_swap_1':
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:197:13:
internal compiler error: in emit_library_call_value_1, at calls.c:4624
 return (__sync_val_compare_and_swap_##WIDTH (ptr, oldval, newval) \
 ^
/scratch/jmyers/glibc/many7/src/gcc/libgcc/config/m68k/linux-atomic.c:202:1:
note: in expansion of macro 'SUBWORD_BOOL_CAS'
 SUBWORD_BOOL_CAS (unsigned char,  1)
 ^~~~
0x6a7dc7 emit_library_call_value_1
/scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4623
0x6acb5f emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
/scratch/jmyers/glibc/many7/src/gcc/gcc/calls.c:4817
0x9e576e expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*,
rtx_def*, rtx_def*, bool, memmodel, memmodel)
/scratch/jmyers/glibc/many7/src/gcc/gcc/optabs.c:6210
0x690b1b expand_builtin_compare_and_swap
/scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:5059
0x69db77 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/scratch/jmyers/glibc/many7/src/gcc/gcc/builtins.c:6606
0x7bdd4d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:10773
0x7c8e4f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5548
0x7ca790 expand_assignment(tree_node*, tree_node*, bool)
/scratch/jmyers/glibc/many7/src/gcc/gcc/expr.c:5317
0x6bb4ba expand_call_stmt
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:2666
0x6bb4ba expand_gimple_stmt_1
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3581
0x6bb4ba expand_gimple_stmt
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:3747
0x6bd28e expand_gimple_basic_block
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:5754
0x6c3176 execute
/scratch/jmyers/glibc/many7/src/gcc/gcc/cfgexpand.c:6368
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/77309] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Author: bernds
Date: Mon Nov  7 16:59:11 2016
New Revision: 241912

URL: https://gcc.gnu.org/viewcvs?rev=241912&root=gcc&view=rev
Log:
PR rtl-optimization/77309
* combine.c (make_compound_operation): Allow EQ for IN_CODE, and
don't assume an equality comparison for plain COMPARE.
(simplify_comparison): Pass a more accurate code to
make_compound_operation.

testsuite/
PR rtl-optimization/77309
* gcc.dg/torture/pr77309.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77309.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77596] [F03] procedure pointer with implicit interface in type pointing to a function can be 'called'

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #3 from janus at gcc dot gnu.org ---
I have a patch to fix this ...

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
Author: fw
Date: Mon Nov  7 17:08:40 2016
New Revision: 241914

URL: https://gcc.gnu.org/viewcvs?rev=241914&root=gcc&view=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c

Backport from mainline
2016-10-24  Florian Weimer  


PR libgcc/78064
* unwind-c.c: Include auto-target.h.


Modified:
branches/gcc-6-branch/   (props changed)
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/unwind-c.c

Propchange: branches/gcc-6-branch/
('svn:mergeinfo' modified)

[Bug middle-end/78016] REG_NOTE order is not kept during insn copy

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #5 from Jiong Wang  ---
This bug itself should have been fixed by

 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241913

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |c++
   Target Milestone|--- |7.0

--- Comment #3 from Andrew Pinski  ---
> expected field_decl, have template_decl in int_bit_position

template_decl should not have leaked to int_bit_position at all.

[Bug c++/78235] [7 Regression] libstdc++ testsuite run.cc ICE in int_bit_position

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Related to PR 66149.

[Bug middle-end/35691] Missed (a == 0) && (b == 0) into (a|(typeof(a)(b)) == 0 when the types don't match

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Mon Nov  7 17:32:17 2016
New Revision: 241915

URL: https://gcc.gnu.org/viewcvs?rev=241915&root=gcc&view=rev
Log:
2016-11-07  Prathamesh Kulkarni  

PR middle-end/35691
* match.pd: Add following two patterns:
(x == 0 & y == 0) -> (x | typeof(x)(y)) == 0.
(x != 0 | y != 0) -> (x | typeof(x)(y)) != 0.

testsuite/
* gcc.dg/pr35691-1.c: New test-case.
* gcc.dg/pr35691-4.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr35691-1.c
trunk/gcc/testsuite/gcc.dg/pr35691-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 17:33:27 2016
New Revision: 241916

URL: https://gcc.gnu.org/viewcvs?rev=241916&root=gcc&view=rev
Log:
PR target/78227
* config/i386/i386.c (ix86_expand_sse_cmp): Force dest into
cmp_mode argument even for -O0 if cmp_mode != mode and maskcmp.

* gcc.target/i386/pr78227-1.c: New test.
* gcc.target/i386/pr78227-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr78227-1.c
trunk/gcc/testsuite/gcc.target/i386/pr78227-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  7 17:35:16 2016
New Revision: 241917

URL: https://gcc.gnu.org/viewcvs?rev=241917&root=gcc&view=rev
Log:
PR target/77834
* dse.c (dse_step5): Call scan_reads even if just
insn_info->frame_read.  Improve and fix dump file messages.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #18 from Dmitry Vyukov  ---
Looks like shadow stack overflow.
Do you use fibers, ucontext, longjmp, exceptions or any other non-obvious
control flow constructs?
Fibers and exceptions are not supported. Longjmp should work.

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Confirmed with the attachment.  Thanks.

Let's leave this open for now, as the ICE occurs in a different place than
PR77949.  It could be another unrelated bug caused by the same patch.  Though
it seems like this is a better place to start, since the testcase is
considerable shorter.

[Bug fortran/78238] New: ICE: verify_gimple failed, with -fdefault-integer-8

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78238
   Summary: ICE: verify_gimple failed, with -fdefault-integer-8
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Valid code with explicitly no integer variable in source,
and in first test case with no 4-byte integer value.
ICE with option -fdefault-integer-8 or similar, seen with 7.


$ cat z1.f90
program p
   type t
  class(*), allocatable :: q(:)
   end type
   type(t) :: z
   real :: a(2_8) = [1.0, 2.0]
   allocate (z%q(2_8), source=a)
   call s
contains
   subroutine s
  select type (x => z%q)
  type is (real)
 if ( any(x/=a) ) call abort
  end select
   end
end


$ cat z2.f90
program p
   type t
  class(*), allocatable :: q(:)
   end type
   type(t) :: z
   real :: a(2) = [1.0, 2.0]
   allocate (z%q(2), source=a)
   call s
contains
   subroutine s
  select type (x => z%q)
  type is (real)
 if ( any(x/=a) ) call abort
  end select
   end
end


$ gfortran-7-20161106 -fdefault-integer-8 z1.f90
z1.f90:10:0:

subroutine s

Error: mismatching comparison operand types
integer(kind=4)
integer(kind=8)
if (_10 == 64409183) goto ; else goto ;
z1.f90:10:0: internal compiler error: verify_gimple failed
0xc745fd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4876
0x9dcbc2 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12251
0x9dcf56 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12339
0xcd1892 gimplify_all_functions
../../gcc/tree-nested.c:3280
0xcd1877 gimplify_all_functions
../../gcc/tree-nested.c:3282
0xcd9fd6 lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3299
0x84aa76 cgraph_node::analyze()
../../gcc/cgraphunit.c:632
0x84e073 analyze_functions
../../gcc/cgraphunit.c:1087
0x84ed88 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2562

[Bug fortran/78239] New: ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78239
   Summary: ICE in char_len_param_value, at fortran/decl.c:926,
with -fimplicit-none
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Some valid cases flag an ICE with option -fimplicit-none.
Affects version 5, 6 and 7.


$ cat z1.f90
subroutine s(n)
   character(n) :: c
   c = 'c'
end


$ gfortran-7-20161106 -fimplicit-none z1.f90
f951: internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x6790df char_len_param_value
../../gcc/fortran/decl.c:926
0x67b1a4 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:2847
0x680419 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3055
0x681746 gfc_match_data_decl()
../../gcc/fortran/decl.c:4819
0x6d7b89 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6daa9e match_word
../../gcc/fortran/parse.c:377
0x6daa9e decode_statement
../../gcc/fortran/parse.c:377
0x6dc8a4 next_free
../../gcc/fortran/parse.c:1149
0x6dc8a4 next_statement
../../gcc/fortran/parse.c:1382
0x6de63c parse_spec
../../gcc/fortran/parse.c:3551
0x6e05c3 parse_progunit
../../gcc/fortran/parse.c:5521
0x6e1e74 gfc_parse_file()
../../gcc/fortran/parse.c:6037
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #4 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 18:33:49 2016
New Revision: 241919

URL: https://gcc.gnu.org/viewcvs?rev=241919&root=gcc&view=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/incpath.c

[Bug fortran/78239] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

An invalid example, with uninitialized parameter n :


$ cat z2.f90
program p
   character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
end


$ gfortran-7-20161106 -fimplicit-none z2.f90
f951: internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x6790df char_len_param_value
../../gcc/fortran/decl.c:926
0x67b1a4 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:2847
0x6badcd gfc_match_type_spec(gfc_typespec*)
../../gcc/fortran/match.c:2051
0x662e89 gfc_match_array_constructor(gfc_expr**)
../../gcc/fortran/array.c:1123
0x6bfc79 match_primary
../../gcc/fortran/matchexp.c:153
0x6bfc79 match_level_1
../../gcc/fortran/matchexp.c:211
0x6bfc79 match_mult_operand
../../gcc/fortran/matchexp.c:267
0x6bfed8 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6c016c match_level_2
../../gcc/fortran/matchexp.c:480
0x6c02c2 match_level_3
../../gcc/fortran/matchexp.c:551
0x6c03d4 match_level_4
../../gcc/fortran/matchexp.c:599
0x6c03d4 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6c0592 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6c0682 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6c0772 match_level_5
../../gcc/fortran/matchexp.c:811
0x6bfae1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x691292 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2702
0x682784 variable_decl
../../gcc/fortran/decl.c:2391
0x682784 gfc_match_data_decl()
../../gcc/fortran/decl.c:4891

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #5 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 18:35:50 2016
New Revision: 241920

URL: https://gcc.gnu.org/viewcvs?rev=241920&root=gcc&view=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/incpath.c

[Bug fortran/78240] New: ICE in match_clist_expr, at fortran/decl.c:728

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78240
   Summary: ICE in match_clist_expr, at fortran/decl.c:728
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code with an uninitialized parameter n.
Affects version 6 and 7, needs option -fdec* :


$ cat z1.f90
program p
   structure /s/
  integer x(n) /1/
   end structure
end


$ gfortran-7-20161106 -fdec z1.f90
f951: internal compiler error: in match_clist_expr, at fortran/decl.c:728
0x682abe match_clist_expr
../../gcc/fortran/decl.c:728
0x682abe variable_decl
../../gcc/fortran/decl.c:2350
0x682abe gfc_match_data_decl()
../../gcc/fortran/decl.c:4891
0x6d7b89 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6daa9e match_word
../../gcc/fortran/parse.c:377
0x6daa9e decode_statement
../../gcc/fortran/parse.c:377
0x6dc8a4 next_free
../../gcc/fortran/parse.c:1149
0x6dc8a4 next_statement
../../gcc/fortran/parse.c:1382
0x6dd6ca parse_struct_map
../../gcc/fortran/parse.c:3071
0x6de3c1 parse_spec
../../gcc/fortran/parse.c:3691
0x6e05c3 parse_progunit
../../gcc/fortran/parse.c:5521
0x6e1b64 gfc_parse_file()
../../gcc/fortran/parse.c:6030
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

For completeness, without -fdec :


$ gfortran-7-20161106 z1.f90
z1.f90:2:12:

structure /s/
1
Error: STRUCTURE at (1) is a DEC extension, enable with -fdec-structure
z1.f90:4:6:

end structure
  1
Error: Expecting END PROGRAM statement at (1)
z1.f90:3:16:

   integer x(n) /1/
1
Error: Variable 'n' cannot appear in the expression at (1)
z1.f90:3:18:

   integer x(n) /1/
  1
Error: The module or main program array 'x' at (1) must have constant shape

in gfc_format_decoder, at fortran/error.c:935
0x68b46e gfc_format_decoder
../../gcc/fortran/error.c:935
0x13f1eef pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:660
0x13e5310 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:947
0x68b307 gfc_error
../../gcc/fortran/error.c:1277
0x68c700 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1306
0x6f152a check_data_variable
../../gcc/fortran/resolve.c:14939
0x6f152a traverse_data_var
../../gcc/fortran/resolve.c:15130
0x6fbc91 resolve_data
../../gcc/fortran/resolve.c:15185
0x6fbc91 resolve_types
../../gcc/fortran/resolve.c:15939
0x6f76ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16027
0x6e1bba resolve_all_program_units
../../gcc/fortran/parse.c:5883
0x6e1bba gfc_parse_file()
../../gcc/fortran/parse.c:6130
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug driver/78206] bootstrap failure under Apple sandbox that blacklists reads in /usr/local

[mrs at gcc dot gnu.org]

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

--- Comment #6 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Mon Nov  7 19:17:04 2016
New Revision: 241926

URL: https://gcc.gnu.org/viewcvs?rev=241926&root=gcc&view=rev
Log:
2016-11-06  Jack Howarth  

PR driver/78206
* incpath.c: (remove_dup(): Also silently ignore EPERM.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/incpath.c

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov  7 19:33:27 2016
New Revision: 241927

URL: https://gcc.gnu.org/viewcvs?rev=241927&root=gcc&view=rev
Log:
2016-11-07  Thomas Koenig  

PR fortran/78226
* expr.c (gfc_generate_initializer):  Add where to EXPR_NULL
statement.
* iresolve.c (gfc_resolve_extends_type_of):  Add where to
both arguments of the function.
* resolve.c (resolve_select_type):  Add where to the
second argument of the new statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/resolve.c

[Bug fortran/78238] ICE: verify_gimple failed, with -fdefault-integer-8

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Works for me on x86_64-*-freebsd.  What system are you using?
Also, what happens if you use -freal-4-real-8?

[Bug libgcc/78064] unwind-c.c never uses _Unwind_GetIPInfo

[fw at gcc dot gnu.org]

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

--- Comment #6 from Florian Weimer  ---
Author: fw
Date: Mon Nov  7 19:54:05 2016
New Revision: 241929

URL: https://gcc.gnu.org/viewcvs?rev=241929&root=gcc&view=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c

Backport from mainline
2016-10-24  Florian Weimer  


PR libgcc/78064
* unwind-c.c: Include auto-target.h.

Modified:
branches/gcc-5-branch/   (props changed)
branches/gcc-5-branch/libgcc/ChangeLog
branches/gcc-5-branch/libgcc/unwind-c.c

Propchange: branches/gcc-5-branch/
('svn:mergeinfo' modified)

[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
The test hasn't changed since December 2014 and it's still failing in recent
test results:

https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00722.html

Jason didn't like the change I proposed in comment #5 and I haven't come back
to it since then.  I'm busy wrapping up my stage 1 projects and don't expect to
have the time to revisit this for a while, so I'm unassigning myself from this
to give other a chance to work on it.

[Bug rtl-optimization/78241] New: [7 Regression] wrong code with -funroll-loops

[zsojka at seznam dot cz]

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

Bug ID: 78241
   Summary: [7 Regression] wrong code with -funroll-loops
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 39983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39983&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -Og -funroll-loops testcase.c
$ ./a.out
Aborted

Correct value is 0x, wrong value is 16.
Tested targets that fail in 7.0.0:
aarch64-unknown-linux-gnu
armv7a-hardfloat-linux-gnueabi
armv7a-softfp-linux-gnueabi
powerpc64le-unknown-linux-gnu
powerpc64-unknown-linux-gnu
sparc-unknown-linux-gnu
x86_64-pc-linux-gnu

[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-241681-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161029 (experimental) (GCC)

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #1)
> For completeness, without -fdec :
> 
> 
> $ gfortran-7-20161106 z1.f90
> z1.f90:2:12:
> 
> structure /s/
> 1
> Error: STRUCTURE at (1) is a DEC extension, enable with -fdec-structure
> z1.f90:4:6:
> 
> end structure
>   1
> Error: Expecting END PROGRAM statement at (1)
> z1.f90:3:16:
> 
>integer x(n) /1/
> 1
> Error: Variable 'n' cannot appear in the expression at (1)
> z1.f90:3:18:
> 
>integer x(n) /1/
>   1
> Error: The module or main program array 'x' at (1) must have constant shape
> 
> in gfc_format_decoder, at fortran/error.c:935
> 0x68b46e gfc_format_decoder
> ../../gcc/fortran/error.c:935
> 0x13f1eef pp_format(pretty_printer*, text_info*)
> ../../gcc/pretty-print.c:660
> 0x13e5310 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../gcc/diagnostic.c:947
> 0x68b307 gfc_error
> ../../gcc/fortran/error.c:1277
> 0x68c700 gfc_error(char const*, ...)
> ../../gcc/fortran/error.c:1306
> 0x6f152a check_data_variable
> ../../gcc/fortran/resolve.c:14939
> 0x6f152a traverse_data_var
> ../../gcc/fortran/resolve.c:15130
> 0x6fbc91 resolve_data
> ../../gcc/fortran/resolve.c:15185
> 0x6fbc91 resolve_types
> ../../gcc/fortran/resolve.c:15939
> 0x6f76ac gfc_resolve(gfc_namespace*)
> ../../gcc/fortran/resolve.c:16027
> 0x6e1bba resolve_all_program_units
> ../../gcc/fortran/parse.c:5883
> 0x6e1bba gfc_parse_file()
> ../../gcc/fortran/parse.c:6130
> 0x725822 gfIndex: resolve.c

===
--- resolve.c   (revision 241667)
+++ resolve.c   (working copy)
@@ -14973,8 +14975,7 @@ check_data_variable (gfc_data_variable *

   if (!gfc_array_size (e, &size))
{
- gfc_error ("Nonconstant array section at %L in DATA statement",
-&e->where);
+ gfc_error ("Nonconstant array section at %C in DATA statement");
  mpz_clear (offset);
  return false;
}
c_be_parse_file
> ../../gcc/fortran/f95-lang.c:198