[Bug c++/77655] [6/7 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE on invalid c++ code on  |[6/7 Regression]ICE on
   |x86_64-linux-gnu (internal  |invalid c++ code on
   |compiler error: |x86_64-linux-gnu (internal
   |Segmentation fault (program |compiler error:
   |cc1plus))   |Segmentation fault (program
   ||cc1plus))
   Target Milestone|--- |6.3
  Known to fail||6.1.0, 6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 6.1.0.

[Bug c++/77655] [6/7 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Causes a stack overflow in:

#174 0x00ddeefe in dump_type(cxx_pretty_printer*, tree_node*, int) ()
at ../../gcc/cp/error.c:510
#175 0x0061b56d in dump_template_bindings (typenames=0x767e1f28,
args=0x767d7c80, parms=, pp=0x1e2af40
) at ../../gcc/cp/error.c:354
#176 dump_substitution (pp=0x1e2af40 , t=, template_parms=, template_args=0x767d7c80,
flags=) at ../../gcc/cp/error.c:1450
#177 0x00619b24 in dump_scope (flags=1, scope=,
pp=0x1e2af40 ) at ../../gcc/cp/error.c:153
#178 dump_aggr_type (flags=0, t=0x767e4150, pp=0x1e2af40
) at ../../gcc/cp/error.c:664
#179 dump_type (pp=0x1e2af40 , t=,
flags=0) at ../../gcc/cp/error.c:443
#180 0x00ddf47a in dump_type_prefix (flags=0, t=0x767e4150,
pp=0x1e2af40 ) at ../../gcc/cp/error.c:811
#181 dump_type_prefix(cxx_pretty_printer*, tree_node*, int) () at
../../gcc/cp/error.c:731
#182 0x00ddeefe in dump_type(cxx_pretty_printer*, tree_node*, int) ()
at ../../gcc/cp/error.c:510
#183 0x0061b56d in dump_template_bindings (typenames=0x767e1e38,
args=0x767d7c80, parms=, pp=0x1e2af40
) at ../../gcc/cp/error.c:354
#184 dump_substitution (pp=0x1e2af40 , t=, template_parms=, template_args=0x767d7c80,
flags=) at ../../gcc/cp/error.c:1450
#185 0x00619b24 in dump_scope (flags=1, scope=,
pp=0x1e2af40 ) at ../../gcc/cp/error.c:153
#186 dump_aggr_type (flags=0, t=0x767e4150, pp=0x1e2af40
) at ../../gcc/cp/error.c:664
#187 dump_type (pp=0x1e2af40 , t=,
flags=0) at ../../gcc/cp/error.c:443
#188 0x00ddf47a in dump_type_prefix (flags=0, t=0x767e4150,
pp=0x1e2af40 ) at ../../gcc/cp/error.c:811
#189 dump_type_prefix(cxx_pretty_printer*, tree_node*, int) () at
../../gcc/cp/error.c:731
#190 0x00ddeefe in dump_type(cxx_pretty_printer*, tree_node*, int) ()
at ../../gcc/cp/error.c:510
#191 0x0061c7b8 in args_to_string (verbose=0, p=0x767e1e10) at
../../gcc/cp/error.c:3091
#192 cp_printer (pp=0x1fc6050, text=0x7fffc930, spec=,
precision=, wide=, set_locus=,
verbose=false) at ../../gcc/cp/error.c:3520
#193 0x0142d125 in pp_format(pretty_printer*, text_info*) () at
../../gcc/pretty-print.c:631
#194 0x0142b3ca in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) () at ../../gcc/diagnostic.c:823
#195 0x00d3b822 in error_at (loc=loc@entry=2147483648,
gmsgid=gmsgid@entry=0x14bdd48 "no matching function for call to %<%D(%A)%>") at
../../gcc/diagnostic.c:1184
#196 0x005e4d12 in print_error_for_call_failure
(fn=fn@entry=0x767d78e0, args=0x767c3f00, candidates=0x2024fe0) at
../../gcc/cp/call.c:4054

#197 0x005e00b4 in build_new_function_call (fn=0x767d78e0,
args=0x7fffcc18, koenig_p=, complain=) at
../../gcc/cp/call.c:4120
#198 0x00e1cea9 in finish_call_expr(tree_node*, vec**, bool, bool, int) () at ../../gcc/cp/semantics.c:2461
#199 0x00daf277 in tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) () at ../../gcc/cp/pt.c:16641
#200 0x00db9080 in tsubst_expr(tree_node*, tree_node*, int, tree_node*,
bool) () at ../../gcc/cp/pt.c:15816
#201 0x00dc17d2 in gen_elem_of_pack_expansion_instantiation
(in_decl=, complain=, args=,
index=, parm_packs=, pattern=) at
../../gcc/cp/pt.c:10625
#202 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) () at
../../gcc/cp/pt.c:11047
#203 0x00db0942 in tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) () at ../../gcc/cp/pt.c:16502
---Type  to continue, or q  to quit---
#204 0x00dac4b4 in tsubst(tree_node*, tree_node*, int, tree_node*) ()
at ../../gcc/cp/pt.c:13545
#205 0x00dbb404 in tsubst_function_type(tree_node*, tree_node*, int,
tree_node*) () at ../../gcc/cp/pt.c:12617
#206 0x00dac38b in tsubst(tree_node*, tree_node*, int, tree_node*) ()
at ../../gcc/cp/pt.c:13375
#207 0x00db6902 in tsubst_decl(tree_node*, tree_node*, int) () at
../../gcc/cp/pt.c:11813
#208 0x00dbdaab in instantiate_template_1 (complain=3, orig_args=0x3,
tmpl=0x767da180) at ../../gcc/cp/pt.c:17415
#209 instantiate_template(tree_node*, tree_node*, int) () at
../../gcc/cp/pt.c:17466
#210 0x00dbbcff in fn_type_unification(tree_node*, tree_node*,
tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t,
int, bool, bool) () at ../../gcc/cp/pt.c:17825
#211 0x005e5064 in print_z_candidate (loc=loc@entry=2147483650,
msgstr=msgstr@entry=0x14bcdbf "candidate:",
candidate=candidate@entry=0x2024f20) at ../../gcc/cp/call.c:3440
#212 0x005e4e20 in print_z_candidates (loc=2147483650,
candidates=) at ../../gcc/cp/call.c:3510
#213 0x005e4d25 in print_error_for_call_failure
(fn=fn@entry=0x767d79a0, args=, candidates=)
at ../../gcc/cp/call.c:4059
#214 0x005e00b4 in build_new_function_call (fn=0x767d79a0,
args=0x7fffd418, koenig_p=

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Mon, 19 Sep 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
> 
> --- Comment #8 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #7)
> 
> > So it seems V2DFmode is available but discouraged via the above hook when
> > tuning for atom.
> > 
> > Indeed:
> > 
> > static machine_mode
> > ix86_preferred_simd_mode (machine_mode mode)
> > {
> > ...
> > case DFmode:
> >   if (!TARGET_VECTORIZE_DOUBLE)
> > return word_mode;
> 
> This part should be OK, the hook documentation says:
> 
>  -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
>   (machine_mode MODE)
>  This hook should return the preferred mode for vectorizing scalar
>  mode MODE.  The default is equal to 'word_mode', because the
>  vectorizer can do some transformations even in absence of
>  specialized SIMD hardware.
> 
> IIUC, word_mode should be returned for unsupported scalar modes.

It says "preferred" -- it only implicitely suggests that maybe
returning word_mode disables vectorization (it does not).

> > but targetm.vector_mode_supported_p happily returns true for V2DFmode.
> 
> Yes, also following the documentation:
> 
>  -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE)
>  Define this to return nonzero if the port is prepared to handle
>  insns involving vector mode MODE.  At the very least, it must have
>  move patterns for this mode.
> 
> We *do* have V2DF move patterns.

from the testcase it's clear you also have conversion patterns (ok, maybe
not -- eventually vectorization would fail if we didn't ICE -- will
check that).

I believe atom _does_ have full SSE2 support, no?  Using intrinsics
(even those expanding to GCC generic vector extension code) should
end up emitting SSE2 double instructions?

So what you want to tell the vectorizer is to not introduce vectorized
code using V2DFmode.  I still think a better way is to handle this
via costs (like a loop with mostly integer ops but a single FP double
op is probably still profitable to vectorize).

At least if you want the preferred_simd_mode to _disable_ vectorization
for V2DFmode that needs additional changes in the vectorizer code.  And
using word_mode from that hook when constructing the vector type
(using word_mode -- you're only lucky that word_mode is smaller than
DFmode that it fails) will end up with a vector type that has V2DF
mode anyway because stor-layout uses vector_mode_supported_p
to decide whether to use V2DFmode or BLKmode.

> > This means the above is _not_ a good way to achieve what it tries to
> > (make the vectorizer not use V2DFmode).  A more proper way would be to
> > handle this in ix86_add_stmt_cost, increasing the cost for double type
> > vectorization.
> > 
> > Nevertheless the vectorizer shouldn't ICE on this inconsistency, I'll see
> > what it takes to "fix" it on the vectorizer side.
> 
> Please note that we have similar situation with TARGET_PREFER_AVX128, the
> difference is that we still vectorize with narrower vector mode, whereas
> V2DFmode falls back to a word_mode.

Yeah.

Note that preferred_simd_mode was introduced to choose a prefered vector
size for a given mode, not really to disable vectorization for selected
modes.  See it's originally only use:

  /* If no size was supplied use the mode the target prefers.   Otherwise
 lookup a vector mode of the specified size.  */
  if (size == 0)
simd_mode = targetm.vectorize.preferred_simd_mode (inner_mode);
  else
simd_mode = mode_for_vector (inner_mode, size / nbytes);

it seems later there was at least one additional use added that follows
your idea:

int
estimate_move_cost (tree type, bool ARG_UNUSED (speed_p))
{
  HOST_WIDE_INT size;

  gcc_assert (!VOID_TYPE_P (type));

  if (TREE_CODE (type) == VECTOR_TYPE)
{
  machine_mode inner = TYPE_MODE (TREE_TYPE (type));
  machine_mode simd
= targetm.vectorize.preferred_simd_mode (inner);
  int simd_mode_size = GET_MODE_SIZE (simd);
  return ((GET_MODE_SIZE (TYPE_MODE (type)) + simd_mode_size - 1)
  / simd_mode_size);
}

not sure why we override TYPE_MODE with preferred_simd_mode.  It's not
that the x86 backend will emit word_mode loads/stores for V2DFmode
loads/stores on i?86 with -mtune=atom?

[Bug fortran/77657] New: link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

[damian at sourceryinstitute dot org]

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

Bug ID: 77657
   Summary: link error with implementation of user-defined derived
type input/output (UD-DTIO) in child extending
abstract parent
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

It appears there might be a problem with linking an abstract interface in the
module  of a parent type with a child type in another module:


$ cat ud-dtio-abstract.f90 
MODULE abstract_parent
  implicit none

  type, abstract :: parent
  contains
procedure(write_formatted_interface), deferred :: write_formatted
generic :: write(formatted) => write_formatted
  end type parent

  abstract interface
subroutine write_formatted_interface(this,unit,iotype,vlist,iostat,iomsg)
  import parent
  class(parent), intent(in) :: this
  integer, intent(in) :: unit
  character (len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character (len=*), intent(inout) :: iomsg
end subroutine
  end interface

end module

module child_module
  use abstract_parent, only : parent
  implicit none

  type, extends(parent) :: child
  contains
procedure :: write_formatted
  end type
contains
  subroutine write_formatted(this,unit,iotype,vlist,iostat,iomsg)
class(child), intent(in) :: this
integer, intent(in) :: unit
character (len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
  end subroutine
end module

  use child_module, only : child
  implicit none
  write(*,*) child()

$ gfortran ud-dtio-abstract.f90 
/tmp/ccOmINhD.o: In function `MAIN__':
ud-dtio-abstract.f90:(.text+0xac): undefined reference to
`write_formatted_interface_'
collect2: error: ld returned 1 exit status

$ gfortran --version
GNU Fortran (GCC) 7.0.0 20160904 (experimental)

[Bug fortran/77649] Wrong error reported with bound checking enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed on all releases I have (4.5.0+).

[Bug fortran/77643] ICE with "character(len=:), pointer :: p => null()"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
  Known to work||4.5.4
 Ever confirmed|0   |1
  Known to fail||4.6.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.6.0. GCC 4.5.4 reports:

pr77643.f90:4.15:

 character(len=:), pointer :: r   ! works
   1
Error: Syntax error in CHARACTER declaration at (1)
pr77643.f90:6.15:

 character(len=:), pointer :: p => null() ! ICE
   1
Error: Syntax error in CHARACTER declaration at (1)

[Bug tree-optimization/77654] restrict pointer attribute not preserved with -fprefetch-loop-arrays

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Looks good though addr_base should always be a pointer but it might not be an
SSA name so better check that.  Patches should go to gcc-patc...@gcc.gnu.org
btw.

[Bug tree-optimization/77653] [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=77653

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0
Summary|wrong code at -Os and above |[7 Regression] wrong code
   |on x86_64-linux-gnu (in |at -Os and above on
   |both 32-bit and 64-bit  |x86_64-linux-gnu (in both
   |modes)  |32-bit and 64-bit modes)

[Bug c++/77651] [7 Regression] c++ -Wno-aligned-new ICEs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So maybe document this as an extension (and specify its semantics -- I'm
curious how the glibc code behaves)

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|[4.9/5/6/7 Regression]  |[5/6/7 Regression] Setting
   |Setting conversion to a |conversion to a integer to
   |integer to double to 0 3/4  |double to 0 3/4 through a
   |through a loop  |loop

[Bug tree-optimization/77647] [6/7 Regression] Missed opportunity to use register value causes additional load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||5.4.0
   Target Milestone|--- |6.3
Summary|Missed opportunity to use   |[6/7 Regression] Missed
   |register value causes   |opportunity to use register
   |additional load |value causes additional
   ||load

--- Comment #2 from Richard Biener  ---
DOM doesn't propagate the equivalence on the not unreachable edge, that is,
it doesn't copy-propagate because of PR71947

  if (ret_3 != _5)
goto ;
  else
goto ;

  :
  __builtin_unreachable ();

  :
  _4 = ret_3 + _5;

DOM does the following after Jeffs patch:

Optimizing block #4

1>>> STMT 1 = ret_3 le_expr _5
1>>> STMT 1 = ret_3 ge_expr _5
1>>> STMT 1 = ret_3 eq_expr _5
1>>> STMT 0 = ret_3 ne_expr _5
0>>> COPY ret_3 = _5
0>>> COPY _5 = ret_3
Optimizing statement _4 = ret_3 + _5;
  Replaced 'ret_3' with variable '_5'
  Replaced '_5' with variable 'ret_3'
  Folded to: _4 = ret_3 + _5;

which is of course a quite stupid replacement.  I still believe the change
should be reverted ... Jeff, are you still investigating this?

Works on the GCC 5 branch:

Optimizing block #4

0>>> COPY _5 = ret_3
1>>> STMT 1 = ret_3 le_expr _5
1>>> STMT 1 = ret_3 ge_expr _5
1>>> STMT 1 = ret_3 eq_expr _5
1>>> STMT 0 = ret_3 ne_expr _5
Optimizing statement _4 = ret_3 + _5;
  Replaced '_5' with variable 'ret_3'
LKUP STMT _4 = ret_3 plus_expr ret_3
2>>> STMT _4 = ret_3 plus_expr ret_3

with assembly

foo:
.LFB1:
.cfi_startproc
#APP
# 4 "t.c" 1
movq  (%rdi),%rax

# 0 "" 2
#NO_APP
addq%rax, %rax
ret

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.5

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

[Bug c++/77658] New: internal compiler error: in assign_temp, at function.c:961

[naupacte at sfr dot fr]

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

Bug ID: 77658
   Summary: internal compiler error: in assign_temp, at
function.c:961
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naupacte at sfr dot fr
  Target Milestone: ---

//A very strange combination is needed to produce the ICE:
//Full program:

struct A
{
//A();
~A(); // NEEDED to produce ICE
};

#ifdef FIRST_CASE
A a (int) { throw ""; return {};}
A b (int) { throw ""; return {};}

A c (int) { throw ""; return {};}
A d (int) { throw ""; return {};}
A e (int) { throw ""; return {};}

#else // second case

A a (int) { throw 1;}
A b (int) { throw 1;}

A c (int) { throw 1;}
A d (int) { throw 1;}
A e (int) { throw 1;}

#endif
//EOF

NB: THERE MUST be at least 5 such functions:
- returning type A
- and throwing same type
- having one (unique?) same argument type





MacBookPro$  /opt/local/bin/gcc-mp-6 -x c++ -c .cpp  -O3
program.cpp: In function 'A a(int)':
program.cpp:16:3: internal compiler error: in assign_temp, at function.c:961
 A a (int) { throw 1;}
   ^

program.cpp:16:3: internal compiler error: Abort trap: 6
gcc-mp-6: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


MacBookPro$ /opt/local/bin/gcc-mp-6 -v
Using built-in specs.
COLLECT_GCC=/opt/local/bin/gcc-mp-6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin15/6.1.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc6/gcc6/work/gcc-6.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin15
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6.1.0_0'
Thread model: posix
gcc version 6.1.0 (MacPorts gcc6 6.1.0_0)

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Ok, this is because we value-number the indirect call result to the result of
the direct call (correctly) but that has no VDEF (it's detected pure) and thus
we fail to value-number the indirect calls VDEF.

@@ -3470,6 +3577,10 @@ visit_reference_op_call (tree lhs, gcall
 {
   if (vnresult->result_vdef && vdef)
changed |= set_ssa_val_to (vdef, vnresult->result_vdef);
+  else if (vdef)
+   /* If the call was discovered to be pure or const reflect
+  that as far as possible.  */
+   changed |= set_ssa_val_to (vdef, gimple_vuse (stmt));

   if (!vnresult->result && lhs)
vnresult->result = lhs;

[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #6)
> Created attachment 39057 [details]
> sparcv9 pr57558-1.c.149t.vect
> 
> The new gcc.dg/vect/pr57558-1.c test FAILs on 64-bit Solaris/SPARC:
> 
> +FAIL: gcc.dg/vect/pr57558-1.c -flto -ffat-lto-objects  scan-tree-dump vect
> "vec
> torized 1 loops"
> +FAIL: gcc.dg/vect/pr57558-1.c scan-tree-dump vect "vectorized 1 loops"
I revised the test and now this should be fixed.
> 
> I'm attaching the dump.
> 
>   Rainer

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[amker at gcc dot gnu.org]

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

Bug 57558 Summary: Loop not vectorized if iteration count could be infinite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558

   What|Removed |Added

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

[Bug tree-optimization/57558] Loop not vectorized if iteration count could be infinite

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from amker at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Created attachment 39653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39653&action=edit
Target-dependent patch that disables DFmode vectorization via vector costs

Proposed target-dependent patch.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #9)

> I believe atom _does_ have full SSE2 support, no?  Using intrinsics
> (even those expanding to GCC generic vector extension code) should
> end up emitting SSE2 double instructions?

True.

> So what you want to tell the vectorizer is to not introduce vectorized
> code using V2DFmode.  I still think a better way is to handle this
> via costs (like a loop with mostly integer ops but a single FP double
> op is probably still profitable to vectorize).

The patch, attached in the previous message implements the above suggestion,
and also fixes the testcase with -mtune=atom. However, I have no performance
data to base cost values on, so the patch artificially rises the cost of DFmode
vector insns for 20:

+  /* FIXME: The value here is arbitrary
+ and could potentially be improved with analysis.  */
+  if (vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode
+  && !TARGET_VECTORIZE_DOUBLE)
+cost += 20;

[...]

> not sure why we override TYPE_MODE with preferred_simd_mode.  It's not
> that the x86 backend will emit word_mode loads/stores for V2DFmode
> loads/stores on i?86 with -mtune=atom?

Oh... no. We *do* have V2DFmode, but we want to avoid it as much as possible.

[Bug c++/63693] ICE in resolve_typename_type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||dannix84 at gmail dot com

--- Comment #7 from Paolo Carlini  ---
*** Bug 70254 has been marked as a duplicate of this bug. ***

[Bug c++/70254] Compiler crash

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Paolo Carlini  ---
Dup.

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

[Bug c++/63693] ICE in resolve_typename_type

[yury.zaytsev at traveltainment dot de]

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

--- Comment #8 from Yury V. Zaytsev  ---
So, not going to be backported to 5.x?

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Hmm, the vectorized loop itself looks ok to me.  Unfortunately I can't get gdb
to
help me debugging the result array.  Looks like the 3rd invocation of
evaluate_1dim_real gets the bogus data:

-   0.0.   -1.1904761904761946E-002
  0.   0.12500  -0.1  
0.41663  -0.28571428571428570   0.10416  
-1.5873015873015872E-002
+   0.0.   -1.1904761904761946E-002
  0.   0.12500  -0.1  
0.41663  -0.285714285714285700.   
0. 

--param vect-max-peeling-for-alignment=0 simplifies the generated code but
doesn't fix the issue.

Adding -fno-tree-dse does.

;; Function integrate_poly_indefinite
(__poly_module_MOD_integrate_poly_indefinite, funcdef_no=17, decl_uid=3532,
cgraph_uid=17, symbol_order=17)

  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_32] = _44;
'
  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_91] = _97;
'
integrate_poly_indefinite (struct poly & restrict p)


And:

  # .MEM_5 = VDEF <.MEM_4(D)>
  p_intD.4173.coefficientsD.3452.dataD.3438 = 0B;
...
  # .MEM_12 = VDEF <.MEM_10>
  # USE = nonlocal escaped null { D.4173 D.4174 D.7974 D.7975 D.7976 }
(nonlocal)
  # CLB = nonlocal escaped null { D.4173 }
  init_poly (&p_intD.4173, &D.4174, _11);
...
  # PT = null
  _14 = p_intD.4173.coefficients.data;

so somehow init_poly side effect is not properly reflected.  Constraints look
good:

p_int.128+64 = &NULL
...
callarg(28) = &p_int.0+96
callarg(28) = *callarg(28) + UNKNOWN
CALLUSED(26) = callarg(28)
CALLCLOBBERED(27) = callarg(28)
*callarg(28) = NONLOCAL
...
_14 = p_int.128+64

but in the end:

p_int.0+96 = { ESCAPED NONLOCAL } same as p_int.0+96
p_int.128+64 = { NULL }
p_int.192+320 = { } same as _15
p_int.512+64 = { NULL }
p_int.576+320 = { } same as p_int.576+320

so somehow callarg(28) = *callarg(28) + UNKNOWN does not have the desired
effect.

[Bug c++/77659] New: internal compiler error: in gimplify_expr, at gimplify.c:8858

[zoidbergx at tlen dot pl]

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

Bug ID: 77659
   Summary: internal compiler error: in gimplify_expr, at
gimplify.c:8858
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoidbergx at tlen dot pl
  Target Milestone: ---

Created attachment 39654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39654&action=edit
preprocessored file main.cpp

"gcc -v" output:

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


command line:

g++ -std=c++14 main.cpp


compiler output:

main.cpp: In member function ‘void Foo::bar() [with T = char]’:
main.cpp:12:37: internal compiler error: in gimplify_expr, at gimplify.c:8858
 unsigned baz = get_max_value(baz);
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Comment:
internal compiler error appears in case of "-std=c++14" used; in case of
"-std=c++11" used everything is ok.

[Bug c++/77659] internal compiler error: in gimplify_expr, at gimplify.c:8858

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
template  Type get_max_value(Type);
struct A {
  struct B {
int baz = get_max_value(baz);
  };
  template  void m_fn1() { new B{}; }
};
void foo() {
  A a;
  a.m_fn1();
}

[Bug c++/77659] internal compiler error: in gimplify_expr, at gimplify.c:8858

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
on trunk with checking enabled:

markus@x4 tmp % g++ -c m.ii   
m.ii: In instantiation of ‘void A::m_fn1() [with  =
int]’:
m.ii:10:16:   required from here
m.ii:4:29: internal compiler error: in tsubst_copy, at cp/pt.c:14610
 int baz = get_max_value(baz);
 ^~~
0x6b8cb9 tsubst_copy
../../gcc/gcc/cp/pt.c:14610
0x6bd55a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16363
0x6bc863 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16271
0x6bc90e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16170
0x6bc703 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16147
0x6bd2cc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16928
0x6bd615 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16617
0x6bdb64 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17086
0x6bca48 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16910
0x6bc4d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16479
0x6b2120 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15936
0x6b0280 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15242
0x6b183d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15419
0x6aed50 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:22159
0x6f61fb instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:22276
0x73aa4f c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4617

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
struct S { int *p; int *q; };

int **__attribute__((noinline,noclone,pure)) foo (struct S *s)
{
  return &s->q;
}

int main()
{
  struct S s;
  int i = 1, j = 2;
  int **x;
  s.p = &i;
  s.q = &j;
  x = foo (&s);
  **x = 7;
  if (j != 7)
__builtin_abort ();
  return 0;
}

[Bug fortran/71952] [Coarray, F2008] Rejects valid coarray access with array partref

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Well, patch submitted as r240231 although it doesn't show here. Waiting one
week for regressions before closing.

[Bug c++/77658] internal compiler error: in assign_temp, at function.c:961

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-9-20
 CC||marxin at gcc dot gnu.org
  Known to work||6.2.0, 7.0
 Resolution|--- |FIXED
  Known to fail||6.1.0

--- Comment #1 from Martin Liška  ---
The only affected release is 6.1.0, the ICE is fixed on both trunk and 6.2.0.
Fixed in r236430.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to rguent...@suse.de from comment #9)
> 
> > I believe atom _does_ have full SSE2 support, no?  Using intrinsics
> > (even those expanding to GCC generic vector extension code) should
> > end up emitting SSE2 double instructions?
> 
> True.
> 
> > So what you want to tell the vectorizer is to not introduce vectorized
> > code using V2DFmode.  I still think a better way is to handle this
> > via costs (like a loop with mostly integer ops but a single FP double
> > op is probably still profitable to vectorize).
> 
> The patch, attached in the previous message implements the above suggestion,
> and also fixes the testcase with -mtune=atom. However, I have no performance
> data to base cost values on, so the patch artificially rises the cost of
> DFmode vector insns for 20:
> 
> +  /* FIXME: The value here is arbitrary
> + and could potentially be improved with analysis.  */
> +  if (vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode
> +  && !TARGET_VECTORIZE_DOUBLE)
> +cost += 20;
> 
> [...]

If V2DFmode moves are fine(?) then maybe not do this for the load/store
kinds - this means only handling vector_stmt this way (and maybe
vect_promote_demote?) - at least make sure to not handle scalar_*
(not sure if vectype is always NULL for those -- docs say only
memory ops may depend on vectype).
Instead of += 20 I'd have done *=  to
make it more independent of the absolute value of the cost numbers.

If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
over the details (there's also similar offsetting for silvermont)

> > not sure why we override TYPE_MODE with preferred_simd_mode.  It's not
> > that the x86 backend will emit word_mode loads/stores for V2DFmode
> > loads/stores on i?86 with -mtune=atom?
> 
> Oh... no. We *do* have V2DFmode, but we want to avoid it as much as possible.

That's what I thought.

[Bug c++/77467] Segmentation fault with switch statement in constexpr function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #39559|0   |1
is obsolete||

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

Updated untested fix.

[Bug tree-optimization/77644] missed optimization with sqrt in comparison

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Created attachment 39656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39656&action=edit
patch for the ICE

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #13)
> Created attachment 39656 [details]
> patch for the ICE

+/* { dg-additional-options "-march=i686 -mtune=atom -msse2" { target ia32 } }
*/

You can use

/* { dg-additional-options "-mtune=atom -msse2" { target i?86-*-* x86_64-*-* }
} */

and the test will also break on x86_64.

[Bug c++/77660] New: Conversion operator unknown or ambiguous: gcc or clang behave differently

[naupacte at sfr dot fr]

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

Bug ID: 77660
   Summary: Conversion operator unknown or ambiguous: gcc or clang
behave differently
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naupacte at sfr dot fr
  Target Milestone: ---

In relation with bug #50306:
(using gcc5.4.1 or gcc6.1 from macports)

struct A;
struct B;

template  struct Ptr
{
template  operator const Ptr& () const;
#ifdef GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS
template  operator   Ptr  () const; // required by gcc
but skipped for clang
#endif
};


const Ptr& foo1 (const Ptr& b) { return b;}//gcc ok 
  Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set
  Ptr  foo2a(const Ptr& b) { return static_cast>(b);} //gcc
patch


Who is right? Gcc cannot convert from const Ptr& to Ptr via const
Ptr&. I guess it has an influence on its inability to get the common type
for brace-lists or ?: pairs when only the reference conversion is given.

To avoid error: define GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS only for gcc.
Otherwise, we get:

GCC

/opt/local/bin/gcc-mp-6 -x c++ -std=c++1y -c program.cpp

program.cpp: In function 'Ptr foo2(const Ptr&)':
program.cpp:22:47: error: could not convert 'b' from 'const Ptr' to 'Ptr'
   Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set

CLANG
=

clang-mp-3.8 -x c++ -std=c++1y -c program.cpp
-DGCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS

program.cpp:22:47: error: conversion from 'const Ptr' to 'Ptr' is
ambiguous
  Ptr  foo2 (const Ptr& b) { return b;}// needs
GCC_BUT_CLANG_DECLARES_IT_IS_AMBIGUOUS to be set
  ^
program.cpp:13:76: note: candidate function [with U = A]
template  operator const Ptr& () const;
   ^
program.cpp:15:76: note: candidate function [with U = A]
template  operator   Ptr  () const;
   ^
program.cpp:23:47: error: ambiguous conversion for static_cast from 'const
Ptr' to 'Ptr'
  Ptr  foo2a(const Ptr& b) { return static_cast>(b);} //gcc
patch
  ^~
program.cpp:11:27: note: candidate is the implicit copy constructor
template  struct Ptr
  ^
program.cpp:11:27: note: candidate is the implicit move constructor
2 errors generated.

[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Created attachment 39657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39657&action=edit
patch in testing

Contains two C testcases -- the Fortran bug is in another code path, a Fortran
testcase suitable for the testsuite would be appreciated (single-file, runtime,
fails without, passes with the patch).  Unfortunately(?) there is no way to
create "fn spec" attributes in C testcases.

[Bug c++/77655] [5/6/7 Regression]ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||paolo at gcc dot gnu.org
  Known to work|5.4.0   |
   Target Milestone|6.3 |5.5
Summary|[6/7 Regression]ICE on  |[5/6/7 Regression]ICE on
   |invalid c++ code on |invalid c++ code on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: |compiler error:
   |Segmentation fault (program |Segmentation fault (program
   |cc1plus))   |cc1plus))
  Known to fail||5.4.0

--- Comment #3 from Jakub Jelinek  ---
With -std=c++0x the ICE is much older.
In particular, r170459 started to ICE on this (before that it got rejected with

pr77655.C: In function ‘decltype (g(0, (g)(h::a)...)) h(A&& ...) [with A
= {}, decltype (g(0, (g)(h::a)...)) = void]’:
pr77655.C:8:5:   instantiated from here
pr77655.C:4:3: error: no matching function for call to ‘h(h(A&& ...) [with A =
{}, decltype (g(0, (g)(h::a)...)) = void]::)’
pr77655.C:4:3: note: candidate is:
pr77655.C:3:6: note: template decltype (g(0, (g)(h::a)...))
h(A&& ...)

while r170459 gives:

Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

and starting with r198487 it gets the current diagnostics + ICE afterwards.

[Bug bootstrap/77661] New: --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

Bug ID: 77661
   Summary: --enable-maintainer-mode causes in-tree-build of MPC
to fail
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Compiling GCC with in-tree MPC (+ mpfr + gmp + ISL) fails with
--enable-maintainer-mode as the latter also updates the configure scripts of
those.

In particular, the in-tree-build of MPC fails with:

make[3]: Entering directory `build/mpc'
(CDPATH="${ZSH_VERSION+.}:" && cd ../../mpc && /bin/sh mpc/missing autoheader)
aclocal.m4:17: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
configure.ac:27: error: Autoconf version 2.65 or higher is required
aclocal.m4:497: AM_INIT_AUTOMAKE is expanded from...
configure.ac:27: the top level
autom4te: m4 failed with exit status: 63
autoheader: 'autom4te' failed with exit status: 63
WARNING: 'autoheader' is probably too old.
 You should only need it if you modified 'acconfig.h' or
 'configure.ac' or m4 files included by 'configure.ac'.
 The 'autoheader' program is part of the GNU Autoconf package:
 
 It also requires GNU m4 and Perl in order to run:
 
 
make[3]: *** [../../mpc/config.h.in] Error 63
make[3]: Leaving directory `build/mpc'

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #12)

> If V2DFmode moves are fine(?) then maybe not do this for the load/store
> kinds - this means only handling vector_stmt this way (and maybe
> vect_promote_demote?) - at least make sure to not handle scalar_*
> (not sure if vectype is always NULL for those -- docs say only
> memory ops may depend on vectype).

Moves are fine, V2DFmode vector arithmetic insns (addpd, subpd, mulpd) have
much higher latencies (e.g. 6 for addpd, 9 for mulpd), comparing to their
{SF,DF}mode (or V4SFmode) versions (1 for addps, 2 for mulps).

> Instead of += 20 I'd have done *=  to
> make it more independent of the absolute value of the cost numbers.

IMO, having no other data at hand than Agner Fog's instruction tables, it looks
that penalizing vector_stmt cost with a factor of 5 should be OK for a start.

> If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
> over the details (there's also similar offsetting for silvermont)

ix86_builtin_vectorization_cost is also called from there. OTOH,
ix86_add_stmt_cost uses some other arguments (e.g. location), which I think are
irrelevant to the insn type cost adjustment.

Let me play a bit with the patch.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Tue, 20 Sep 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
> 
> --- Comment #15 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #12)
> 
> > If V2DFmode moves are fine(?) then maybe not do this for the load/store
> > kinds - this means only handling vector_stmt this way (and maybe
> > vect_promote_demote?) - at least make sure to not handle scalar_*
> > (not sure if vectype is always NULL for those -- docs say only
> > memory ops may depend on vectype).
> 
> Moves are fine, V2DFmode vector arithmetic insns (addpd, subpd, mulpd) have
> much higher latencies (e.g. 6 for addpd, 9 for mulpd), comparing to their
> {SF,DF}mode (or V4SFmode) versions (1 for addps, 2 for mulps).
> 
> > Instead of += 20 I'd have done *=  to
> > make it more independent of the absolute value of the cost numbers.
> 
> IMO, having no other data at hand than Agner Fog's instruction tables, it 
> looks
> that penalizing vector_stmt cost with a factor of 5 should be OK for a start.
> 
> > If you'd do the cost adjustment in ix86_add_stmt_cost you have more control
> > over the details (there's also similar offsetting for silvermont)
> 
> ix86_builtin_vectorization_cost is also called from there. OTOH,
> ix86_add_stmt_cost uses some other arguments (e.g. location), which I think 
> are
> irrelevant to the insn type cost adjustment.

At least you won't get called for the scalar loop copy and you have
definite acccess to vectype.

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Does adding --disable-maintainer-mode to Makefile.def extra_configure_flags for
MPC help?

[Bug tree-optimization/77646] [5/6 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] GCC  |[5/6 Regression] GCC
   |Segfault with -O3   |Segfault with -O3
  Known to fail|7.0 |

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

[Bug tree-optimization/77646] [5/6 Regression] GCC Segfault with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 20 12:20:37 2016
New Revision: 240261

URL: https://gcc.gnu.org/viewcvs?rev=240261&root=gcc&view=rev
Log:
2016-09-20  Richard Biener  

PR tree-optimization/77646
* tree-ssa-sccvn.c (visit_reference_op_call): Always value-number
a VDEF.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77646.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #16)

> At least you won't get called for the scalar loop copy and you have
> definite acccess to vectype.

Thanks for the hint, the following patch is effective as well:

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 60b81bb..9d72681 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -49554,9 +49554,7 @@ ix86_preferred_simd_mode (machine_mode mode)
return V4SFmode;

 case DFmode:
-  if (!TARGET_VECTORIZE_DOUBLE)
-   return word_mode;
-  else if (TARGET_AVX512F)
+  if (TARGET_AVX512F)
return V8DFmode;
   else if (TARGET_AVX && !TARGET_PREFER_AVX128)
return V4DFmode;
@@ -49647,6 +49645,11 @@ ix86_add_stmt_cost (void *data, int count, enum
vect_cost_for_stmt kind,
   tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
   int stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);

+  /* Penalize DFmode vector operations for !TARGET_VECTORIZE_DOUBLE.  */
+  if (kind == vector_stmt && !TARGET_VECTORIZE_DOUBLE
+  && vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode)
+stmt_cost *= 5;  /* FIXME: The value here is arbitrary.  */
+
   /* Statements in an inner loop relative to the loop being
  vectorized are weighted more heavily.  The value here is
   arbitrary and could potentially be improved with analysis.  */
--cut here--

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Tue, 20 Sep 2016, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77621
> 
> --- Comment #17 from Uroš Bizjak  ---
> (In reply to rguent...@suse.de from comment #16)
> 
> > At least you won't get called for the scalar loop copy and you have
> > definite acccess to vectype.
> 
> Thanks for the hint, the following patch is effective as well:

Looks good to me.

> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 60b81bb..9d72681 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -49554,9 +49554,7 @@ ix86_preferred_simd_mode (machine_mode mode)
> return V4SFmode;
> 
>  case DFmode:
> -  if (!TARGET_VECTORIZE_DOUBLE)
> -   return word_mode;
> -  else if (TARGET_AVX512F)
> +  if (TARGET_AVX512F)
> return V8DFmode;
>else if (TARGET_AVX && !TARGET_PREFER_AVX128)
> return V4DFmode;
> @@ -49647,6 +49645,11 @@ ix86_add_stmt_cost (void *data, int count, enum
> vect_cost_for_stmt kind,
>tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
>int stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
> 
> +  /* Penalize DFmode vector operations for !TARGET_VECTORIZE_DOUBLE.  */
> +  if (kind == vector_stmt && !TARGET_VECTORIZE_DOUBLE
> +  && vectype && GET_MODE_INNER (TYPE_MODE (vectype)) == DFmode)
> +stmt_cost *= 5;  /* FIXME: The value here is arbitrary.  */
> +
>/* Statements in an inner loop relative to the loop being
>   vectorized are weighted more heavily.  The value here is
>arbitrary and could potentially be improved with analysis.  */
> --cut here--

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||cltang at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Broken by r240155.

[Bug c++/77656] 64-bit integral template parameter gets incorrectly sized as 32-bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
template> (sizeof(int) * __CHAR_BIT__))>
class A {};
template class B : A {};
template class C : A<(unsigned long long) T> {};

Perhaps tsubst of TEMPLATE_PARM_INDEX instead of just
return convert_from_reference (unshare_expr (arg));
also convert it to the TEMPLATE_PARM_INDEX's type (if it is integral type only,
or when?)?

Also, is e.g.

template class A {};
A<0xU> a;
A<0x1U> b;

valid C++11 (0x1U is too large to fit into unsigned short)?  clang++
accepts it in C++98 and rejects with narrowing conversion error in -std=c++11
and later, g++ only warns:
warning: large integer implicitly truncated to unsigned type [-Woverflow]

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #4 from Oleg Endo  ---
(In reply to Rich Felker from comment #0)
> 
> Even if we have a set-associative cache on J-core in the future, I plan to
> have Linux provide a vdso memcpy function that can use DMA transfers, which
> are several times faster than what you can achieve with any cpu-driven
> memcpy and which free up the cpu for other work. However it's impossible to
> for such a function to get called as long as gcc is inlining it.

Just a note on the side... the above can also be done on a off-the-shelf SH
MCU.  However, it is only going to be beneficial for large memory blocks, since
you'd have to synchronize (i.e. flush) the data cache lines of the memcpy'ed
regions.  For small blocks DMA packet setup time will dominate, unless you've
got one dedicated DMA channel sitting around just waiting for memcpy commands. 
Normally it's better to avoid copying large memory blocks at all and use
reference-counted buffers or something like that instead.   That is of course,
unless you've got some special cache coherent DMA machinery ready at hand and
memory is very fast :)


(In reply to Rich Felker from comment #2)
> I'm testing a patch where I used 256 as the limit and it made the Linux
> kernel very slightly faster (~1-2%) and does not seem
> to hurt anywhere.
> 

I'm curious, how did you measure this performance of the kernel?  Which part in
particular got faster in which situation?

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Richard Biener from comment #1)
> Does adding --disable-maintainer-mode to Makefile.def extra_configure_flags
> for MPC help?

Yes, using

--- a/Makefile.def
+++ b/Makefile.def
@@ -65,3 +65,3 @@ host_modules= { module= mpfr; lib_path=src/.libs;
bootstrap=true;
 host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
-   extra_configure_flags='--disable-shared
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
+   extra_configure_flags='--disable-shared
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@
--disable-maintainer-mode';
no_install= true; };

(Makefile.in will then get the changed by regenerating it.)

[Bug c++/77659] [5/6/7 Regression] internal compiler error: in gimplify_expr, at gimplify.c:8858

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|internal compiler error: in |[5/6/7 Regression] internal
   |gimplify_expr, at   |compiler error: in
   |gimplify.c:8858 |gimplify_expr, at
   ||gimplify.c:8858

--- Comment #3 from Jakub Jelinek  ---
Started with r216750.

[Bug bootstrap/77661] --enable-maintainer-mode causes in-tree-build of MPC to fail

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01294.html

[Bug c++/77662] New: arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)

[shopaddr1234 at dubna dot us]

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

Bug ID: 77662
   Summary: arm-linux-gnueabihf-g++: internal compiler error:
Killed (program cgcc)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shopaddr1234 at dubna dot us
  Target Milestone: ---

computer: raspberry pi model B

OS:
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

$ uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux

gcc version 4.9.2 (Raspbian 4.9.2-10)

I tried apt-get install -s gcc++ to upgrade, it said I already have the newest
version.

I am trying to install scikit-learn for python 3.4. I first need to install
scikit-learn dependencies: numpy and scipy. numpy was built and installed fine.
used pip3 to install them: 

sudo pip3 install scipy. 

Installation compiles sources, because I guess there is no compiled version of
scipy for this OS or processor.

After running for several hours I got this output:

arm-linux-gnueabihf-g++: internal compiler error: Killed (program cc1plus)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  In file included from
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1777:0,
   from
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/ndarrayobject.h:18,
   from scipy/sparse/sparsetools/sparsetools.h:5,
   from scipy/sparse/sparsetools/bsr.cxx:4:
 
/usr/local/lib/python3.4/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2:
warning: #warning "Using deprecated NumPy API, disable it by " "#defining
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
   #warning "Using deprecated NumPy API, disable it by " \
^
  arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  error: Command "arm-linux-gnueabihf-g++ -pthread -DNDEBUG -g -fwrapv -O2
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -D__STDC_FORMAT_MACROS=1 -Iscipy/sparse/sparsetools
-I/usr/local/lib/python3.4/dist-packages/numpy/core/include
-I/usr/include/python3.4m -c scipy/sparse/sparsetools/bsr.cxx -o
build/temp.linux-armv6l-3.4/scipy/sparse/sparsetools/bsr.o" failed with exit
status 4

  
  Failed building wheel for scipy
  Running setup.py clean for scipy
  Complete output from command /usr/bin/python3 -u -c "import setuptools,
tokenize;__file__='/tmp/pip-build-r3h3rnv3/scipy/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" clean
--all:

  `setup.py clean` is not supported, use one of the following instead:

- `git clean -xdf` (cleans all files)
- `git clean -Xdf` (cleans all versioned files, doesn't touch
files that aren't checked into the git repo)

  Add `--force` to your command to use it anyway if you must (unsupported)

[Bug c++/77662] arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
GCC 4.9 is no longer supported.
Please try a newer version (GCC 5 and onwards).
In any case, this looks to me like the kernel killing the process because it
used too much memory.

Try adding some swap memory.

[Bug fortran/77657] link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Created attachment 39658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39658&action=edit
Patch for the PR

This is regtesting as I write. All the dtio testcases are fine.

Paul

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 13:48:40 2016
New Revision: 240263

URL: https://gcc.gnu.org/viewcvs?rev=240263&root=gcc&view=rev
Log:
PR middle-end/77624
* builtins.c (fold_builtin_atomic_always_lock_free): Only look through
cast to void * if the cast is from some other pointer type.

* c-c++-common/pr77624-1.c: New test.
* c-c++-common/pr77624-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr77624-1.c
trunk/gcc/testsuite/c-c++-common/pr77624-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Documenting the semantics of this extension would work, though to be usable
safely, GCC would also need to change to recognize that the nested flexible
array member aliases the subsequent members and treat the two sets as if they
were declared in a union.  My own preference, however, would be to reject such
constructs in user code.  As long as changing Glibc to use a zero-length array
is feasible (those would continue to be accepted in this context), it should be
possible to do.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
Created attachment 39659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39659&action=edit
proposed patch set.

So I think this is working reasonably, but haven't tested fully across the
range of Darwins yet == have a go please!

There are 4 patches here:

1. A patch that solves a latent problem with atom-recognition where a
non-weak-local follows a weak-global in a data or const sections.   This is
exposed by the fixes for the actual bug. (needed once patch 3 is applied)

2a. A patch that allows ld64 to be recognized as a linker, and picks up its
version (and as an example also checks support for -export_dynamic) - this was
part of another patch set but is needed now to support patch 3 (which actually
solves the PR)

2b - just the regenerated config files for 2a.

3. This is the one that does the actual fix, by switching section use when the
linker supports merging of weak stuff without special sections - we might be
able to refine the 'earliest linker' version somewhat - this only represents
what I could test reasonably quickly.

The patch provides a target flag "-mtarget-linker" (after the similarly-named
LLVM one) and uses it to determine if the linker needs coalesced sections to
deal with weak symbols.  If not, then we emit in the regular sections.

 - needed a tweak to config/i386.c to allow for PICbase thunk output to be
switched to a non-coalesced section too.

[Bug middle-end/77624] [5/6 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: in  |compiler error: in
   |fold_builtin_atomic_always_ |fold_builtin_atomic_always_
   |lock_free, at   |lock_free, at
   |builtins.c:5583)|builtins.c:5583)

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

[Bug ipa/77587] [5/6 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] C|[5/6 Regression] C compiler
   |compiler produces incorrect |produces incorrect stack
   |stack alignment with|alignment with
   |__attribute__((weak))   |__attribute__((weak))
  Known to fail|7.0 |

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

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Created attachment 39660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39660&action=edit
Patch proposal

There was another location in proc.c which was in need of a conversion.

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Tue Sep 20 15:15:36 2016
New Revision: 240264

URL: https://gcc.gnu.org/viewcvs?rev=240264&root=gcc&view=rev
Log:
PR libstdc++/77619
* include/bits/stl_construct.h: (_Construct_novalue): New.
(_Destroy_n_aux, _Destroy_n): New.
* include/bits/stl_uninitialized.h: (type_traits):
New include in C++11 mode.
(__uninitialized_default_novalue_1): New.
(__uninitialized_default_novalue_n_1): Likewise.
(__uninitialized_default_novalue): Likewise.
(__uninitialized_default_novalue_n): Likewise.
(__uninitialized_copy_n_pair): Likewise.
(uninitialized_default_construct):
Use __uninitialized_default_novalue.
(uninitialized_default_construct_n):
Use __uninitialized_default_novalue_n.
(uninitialized_value_construct): Use __uninitialized_default.
(uninitialized_value_construct_n): Use __uninitialized_default_n.
(uninitialized_move): Use uninitialized_copy.
(uninitialized_move_n): Use __uninitialized_copy_n_pair.
(destroy_at): Use _Destroy.
(destroy): Likewise.
(destroy_n): Likewise.
* testsuite/20_util/specialized_algorithms/
memory_management_tools/1.cc: Add tests for exceptions,
add tests for trivial cases for construct and move.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_construct.h
trunk/libstdc++-v3/include/bits/stl_uninitialized.h
   
trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/1.cc

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug c++/77638] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:17:41 2016
New Revision: 240266

URL: https://gcc.gnu.org/viewcvs?rev=240266&root=gcc&view=rev
Log:
PR c++/77638
* parser.c (cp_parser_template_declaration_after_parameter): For 2
argument operator"" template set ok to false for
parm == error_mark_node.

* g++.dg/cpp0x/udlit-tmpl-arg-neg2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-tmpl-arg-neg2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77626] [6/7 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:18:31 2016
New Revision: 240267

URL: https://gcc.gnu.org/viewcvs?rev=240267&root=gcc&view=rev
Log:
PR c++/77626
* constexpr.c (cxx_fold_indirect_ref): Don't call byte_position on
FIELD_DECLs with error_mark_node type.  Remove useless break; after
return.

* g++.dg/other/pr77626.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/pr77626.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:19:14 2016
New Revision: 240268

URL: https://gcc.gnu.org/viewcvs?rev=240268&root=gcc&view=rev
Log:
PR testsuite/63299
* g++.old-deja/g++.jason/init3.C (My_string::~My_string): Use delete[]
instead of delete.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.jason/init3.C

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far, leaving still open for possible backports.

[Bug c++/77638] [6 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_af

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE on |[6 Regression] ICE on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: tree check: |compiler error: tree check:
   |expected tree that contains |expected tree that contains
   |‘decl common’ structure,|‘decl common’ structure,
   |have ‘error_mark’ in|have ‘error_mark’ in
   |cp_parser_template_declarat |cp_parser_template_declarat
   |ion_after_parameters, at|ion_after_parameters, at
   |cp/parser.c:25722)  |cp/parser.c:25722)

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

[Bug c++/77626] [6 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |-Wall on x86_64-linux-gnu   |-Wall on x86_64-linux-gnu
   |(internal compiler error:   |(internal compiler error:
   |Segmentation fault, |Segmentation fault,
   |byte_from_pos,  |byte_from_pos,
   |cxx_fold_indirect_ref)  |cxx_fold_indirect_ref)

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

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|WONTFIX |FIXED

--- Comment #4 from Jakub Jelinek  ---
Actually fixed.

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 20 15:16:55 2016
New Revision: 240265

URL: https://gcc.gnu.org/viewcvs?rev=240265&root=gcc&view=rev
Log:
PR c++/77637
* parser.c (cp_parser_std_attribute_list): Reject ... without
preceding attribute.

* g++.dg/cpp0x/gen-attrs-62.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-62.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/77663] New: libgfortran/caf/single.c: four minor problems

[dcb314 at hotmail dot com]

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

Bug ID: 77663
   Summary: libgfortran/caf/single.c: four minor problems
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[trunk/libgfortran/caf/single.c:1468]: (style) Redundant condition:
realloc_need
ed. '!realloc_needed || (realloc_needed && dst_reallocatable)' is equivalent to 
'!realloc_needed || dst_reallocatable'
[trunk/libgfortran/caf/single.c:153]: (error) Memory leak: local
[trunk/libgfortran/caf/single.c:1923]: (error) Memory leak: single_token
[trunk/libgfortran/caf/single.c:90]: (error) va_list 'args' was opened but not
c
losed by va_end().

#1 is a simple optimisation, #2 looks only slightly pointful,
#3 I'm not sure about and #4 I know of no architecture where
this matters.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #39659|0   |1
is obsolete||

--- Comment #20 from Iain Sandoe  ---
Created attachment 39661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39661&action=edit
patchset cf 240230


patchset rebased to 240230 - should apply cleanly.

[Bug rtl-optimization/77664] New: Missed optimization: signed int >= 0 && < unsigned short

[achurch+gcc at achurch dot org]

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

Bug ID: 77664
   Summary: Missed optimization: signed int >= 0 && < unsigned
short
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: achurch+gcc at achurch dot org
  Target Milestone: ---

Given the following code:

extern void foo(void);
void bar(int a, unsigned short b)
{
  if (a >= 0 && a < b)
foo();
}

the "a >= 0 && a < b" test could be implemented as a single unsigned
comparison, e.g. on x86-64:

bar:
   cmp %esi,%edi
   jb foo
   ret

GCC, however, misses this optimization (even at -O3) and generates two separate
comparisons:

bar:
   test %edi,%edi
   js 0f
   movzwl %si,%esi
   cmp %esi,%edi
   jl 1f
0: repz ret
   nopl (%rax)
1: jmp foo

(The movzwl is also unnecessary per my reading of the x86-64 ABI, but that's a
different issue.)

FWIW, Clang 3.8.1 successfully optimizes this at -O and higher.

(Component is a guess; please move if appropriate.)

[Bug c++/69481] ICE with C++11 alias using with templates

[akim.demaille at gmail dot com]

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

Akim Demaille  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot com

--- Comment #9 from Akim Demaille  ---
Hi all,

Our of curiosity, could someone explain why GCC makes a difference between
typedef and using here?  I guess that if GCC does not map them all to the same
type of structure, then it must be because it needs to tell the difference
later.  And I guess it's not a does/does-not support templates that makes the
difference, as the grammar probably suffice here.

Thanks in advance!

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Sep 20 16:48:19 2016
New Revision: 240275

URL: https://gcc.gnu.org/viewcvs?rev=240275&root=gcc&view=rev
Log:
PR go/77642

runtime: pass correct type to __splitstack_find

The code was passing uintptr* to a function that expected size_t*.

Based on patch by Andreas Krebbel.

Fixes GCC PR 77642.

Reviewed-on: https://go-review.googlesource.com/29433

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/proc.c

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed.  Thanks for the patch.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[uros at gcc dot gnu.org]

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

--- Comment #19 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Sep 20 17:36:03 2016
New Revision: 240277

URL: https://gcc.gnu.org/viewcvs?rev=240277&root=gcc&view=rev
Log:
PR target/77621
* config/i386/i386.c (ix86_preferred_simd_mode) :
Don't return word_mode for !TARGET_VECTORIZE_DOUBLE.
(ix86_add_stmt_cost): Penalize DFmode vector operations
for !TARGET_VECTORIZE_DOUBLE.

testsuite/ChangeLog:

PR target/77621
* gcc.target/i386/pr77621.c: New test.
* gcc.target/i386/vect-double-2.c: Update scan-tree-dump-times
pattern, loop should vectorize with -mtune=atom.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr77621.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/vect-double-2.c

[Bug fortran/77665] New: ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172

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

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

Bug ID: 77665
   Summary: ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172
   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: ---

Affects versions 5, 6, 7 at optimization level -Os, -O1 or higher.


$ cat z1.f90
program p
   type t
  integer :: a = 0
   end type
   type(t) :: x
   integer :: i
   !$omp declare reduction (+:t: omp_out%a = omp_out%a + omp_in%a)
   !$omp simd reduction(+:x)
   do i = 1, 8
! if ( abs(i) > 5 )  stop  ! or "call abort" etc.
  if ( abs(i) < 5 )  stop
! if ( abs(i) <= 5 ) stop
! if ( abs(i) /= 5 ) stop
  x%a = x%a + 1
   end do
   print *, x%a
end


$ gfortran-7-20160918 -O2 -fopenmp z1.f90
z1.f90:17:0:

 end

internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c:172
0xa152a7 expand_GOMP_SIMD_VF
../../gcc/internal-fn.c:172
0x80348f expand_call_stmt
../../gcc/cfgexpand.c:2578
0x80348f expand_gimple_stmt_1
../../gcc/cfgexpand.c:3579
0x80348f expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x8050ce expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x80b276 execute
../../gcc/cfgexpand.c:6363

[Bug go/77625] go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Sep 20 17:52:23 2016
New Revision: 240279

URL: https://gcc.gnu.org/viewcvs?rev=240279&root=gcc&view=rev
Log:
PR go/77625

compiler: allocate std::ofstream as a local variable

GCC PR 77625 points out a warning about new std::ofstream.  I don't know
how that is supposed to work, but in this case the std::ofstream may as
well be a local variable anyhow.

Reviewed-on: https://go-review.googlesource.com/29435

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/ast-dump.cc

[Bug fortran/77666] New: ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:471

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

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

Bug ID: 77666
   Summary: ICE in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.c:471
   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: ---

Affects versions down to at least 4.8 :


$ cat z1.f90
subroutine s(x)
   integer, allocatable :: x(:)
   integer :: q
   q = 0
!$omp parallel private(x) reduction(+:q)
   q = q + sum(x)
!$omp end parallel
   print *, q
end


$ cat z2.f90
subroutine s(x)
   integer, allocatable :: x(:)
   logical :: q
   q = .false.
!$omp parallel private(x) reduction(.or.:q)
   q = q .or. any (x > 0)
!$omp end parallel
   print *, q
end


$ _g2d_nofo_v7test -fopenmp -c z1.f90
z1.f90:5:0:

 !$omp parallel private(x) reduction(+:q)

internal compiler error: in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.c:471
0x78f7b6 gfc_omp_clause_default_ctor(tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans-openmp.c:471
0xb25a4b lower_rec_input_clauses
../../gcc/omp-low.c:4953
0xb2a17d lower_omp_taskreg
../../gcc/omp-low.c:15661
0xb1c0e6 lower_omp_1
../../gcc/omp-low.c:17036
0xb1c0e6 lower_omp
../../gcc/omp-low.c:17180
0xb1b44c lower_omp_1
../../gcc/omp-low.c:17019
0xb1b44c lower_omp
../../gcc/omp-low.c:17180
0xb1bdec lower_omp_1
../../gcc/omp-low.c:17028
0xb1bdec lower_omp
../../gcc/omp-low.c:17180
0xb22fcf execute_lower_omp
../../gcc/omp-low.c:17915
0xb22fcf execute
../../gcc/omp-low.c:17952

[Bug go/77625] go/gofrontend/ast-dump.cc:169:42: error: ‘new’ of type ‘std::ofstr eam {aka std::basic_ofstream}’ with extended alignment 16

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed.

[Bug fortran/77667] New: ICE in expand_call, at calls.c:2588

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

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

Bug ID: 77667
   Summary: ICE in expand_call, at calls.c:2588
   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: ---

With invalid code :


$ cat z1.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) :: x
   data x /t(4, nul())/
   print *, x%a, associated(x%b)
end


$ gfortran-7-20160918 z1.f90
z1.f90:9:0:

 end

internal compiler error: Segmentation fault
0xc21a5f crash_signal
../../gcc/toplev.c:336
0x7eea98 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:2588
0x9058ac expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10737
0xf092a3 expand_expr
../../gcc/expr.h:279
0xf092a3 output_constant
../../gcc/varasm.c:4758
0xf0a311 output_constant
../../gcc/varasm.c:4665
0xf0a311 output_constructor_regular_field
../../gcc/varasm.c:5018
0xf0a311 output_constructor
../../gcc/varasm.c:5288
0xf0bbb4 output_constant
../../gcc/varasm.c:4665
0xf0bbb4 assemble_variable_contents
../../gcc/varasm.c:2074
0xf133f9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2250
0xf18be8 varpool_node::assemble_decl()
../../gcc/varpool.c:589
0x83ee1b output_in_order
../../gcc/cgraphunit.c:2232
0x83f1fd symbol_table::compile()
../../gcc/cgraphunit.c:2472
0x841c52 symbol_table::compile()
../../gcc/cgraphunit.c:2542
0x841c52 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2568

---


Older releases give :


$ gfortran-6 z1.f90
z1.f90:9:0:

 end

internal compiler error: Segmentation fault


$ gfortran-5 z1.f90
z1.f90:9:0:

 end
 ^
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1059


$ gfortran-4.9 z1.f90
z1.f90:9:0: internal compiler error: in gen_reg_rtx, at emit-rtl.c:866
 end
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/77667] ICE in expand_call, at calls.c:2588

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Variants with a type mismatch give a suboptimal error message :


$ cat z2.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) :: x
   data x /t(4, f())/
   print *, x%a, associated(x%b)
end


$ cat z3.f90
program p
   type t
  integer :: a
  logical, pointer :: b
   end type
   type(t) :: x
   data x /t(4, f())/
   print *, x%a, associated(x%b)
end


$ gfortran-7-20160918 z3.f90
z3.f90:9:0:

 end

Error: initializer for floating value is not a floating constant

[Bug rtl-optimization/77668] New: register allocation shoud not occupy register for return value early

[yumeyao at hotmail dot com]

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

Bug ID: 77668
   Summary: register allocation shoud not occupy register for
return value early
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yumeyao at hotmail dot com
  Target Milestone: ---

when return value is declared (or, RVO introduced returning this pointer), RA
seems to be very greedy on occupying r0(eax/rax) for the return value, even if
the return value is not used yet.

With such RA strategy, the quick register reserved for return value is no
longer usable for tmp variables.

Here is just one simple example demonstrating this issue:
compile with -m32 -O[anylevel] targeting Intel x86
always able to reproduce on gcc 4.x to 6.2.0 and on 7.0 snapshots.

getA() is where RVO is applied, resulting "this" pointer (for returning)
occupying one register.
In total, 4 registers used. The life-scope of "this" pointer and one tmp
variable don't overlap, where 1 register should be enough, but 2 registers
allocated.

getA_RVO() with the complex syntax is where we 'manually' do the RVO stuff to
make the function prototype identical to RVO'ed getA() (calling convention on
returning stack poping is not same, though)
in getA_RVO(), I just showed up that we can use the same register for ret (eax)
as a temp register before we actually start using it, thus only 3 registers
used.

getA_RVO2() is just a simple test to clarify the problem is not caused by RVO,
as we manually declare the return var and assign to it, but the return var
still extended its life-span. So likely the problem is caused by RA being
greedy on ret reg.


struct A {
  int a;
  int b;
  int c;

  A(int i, int j) {
int tmp;
int h = i;
int e;
__asm__ __volatile__( //do something in assembly
  "or $123, %0;"
  "mov %0, %1;"
  "xor $234, %1;"
  "lea 20(%0), %2;"
  : "+r"(h), "=r"(tmp), "=r"(e)
);
b = h;
c = e;
a = j;
  }
};


A getA(int i, int j) {
  return A(i, j);
}

getA(int, int):
 push   %ebx
 mov0x8(%esp),%eax
 mov0xc(%esp),%edx
 or $0x7b,%edx
 mov%edx,%ebx
 xor$0xea,%ebx
 lea0x14(%edx),%ecx
 mov%edx,0x4(%eax)
 mov0x10(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 pop%ebx
 ret$0x4

A* getA_RVO(A* src, int i, int j) {
  A* ret;
  int h = i;
  int e;
  __asm__ __volatile__(
"or $123, %0;"
"mov %0, %1;"
"xor $234, %1;"
"lea 20(%0), %2;"
"mov %3, %1;"  //switch this line with ret = src
: "+r"(h), "=r"(ret), "=r"(e)
: "rm"(src)
  );
  //ret = src;
  ret->b = h;
  ret->c = e;
  ret->a = j;
  return ret;
}

getA_RVO(A*, int, int):
 mov0x8(%esp),%edx
 or $0x7b,%edx
 mov%edx,%eax
 xor$0xea,%eax
 lea0x14(%edx),%ecx
 mov0x4(%esp),%eax
 mov%edx,0x4(%eax)
 mov0xc(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 ret

//switch the commented lines in getA_RVO() to get getA_RVO2

getA_RVO2(A*, int, int):
 push   %ebx
 mov0x8(%esp),%eax
 mov0xc(%esp),%edx
 or $0x7b,%edx
 mov%edx,%ebx
 xor$0xea,%ebx
 lea0x14(%edx),%ecx
 mov%edx,0x4(%eax)
 mov0x10(%esp),%edx
 mov%ecx,0x8(%eax)
 mov%edx,(%eax)
 pop%ebx
 ret

[Bug target/77478] Incorrect code generated with -O3, m32, -msse2 and -ffast-math

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
Thanks, seeing alignment info in dumps helps (I think you meant -vops rather
than -alias?).

This doesn't seem to reproduce on trunk. On gcc-5 branch, I see alignment
increasing in dom2 pass.

Specifically, the 147t.slsr dump prior to dom2 has:

  :
...
  vectp.10_4 = vectp.22_88;
...
  # rhs access alignment 32+0
  vect__22.11_163 = MEM[(float *)vectp.10_4];

and then 149.dom2 has:

  :
...
  vectp.10_4 = vectp.22_88;
...
  # rhs access alignment 128+0
  vect__22.11_163 = MEM[(float *)vectp.22_88];

[Bug c++/66362] Compiling and linking with option -static-libgcc breaks pthread library stack (funcs and macroses)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is not a supported config as glibc needs to call into the shared libgcc to
throw the exception and there needs to be only one copy of the unwinding
functions.

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

--- Comment #9 from michael at mijobe dot org ---
same result

[Bug fortran/77657] link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Bravo!

:D

[Bug fortran/77665] ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
  Known to work||4.9.0
 Ever confirmed|0   |1
  Known to fail||4.9.1

--- Comment #1 from Martin Liška  ---
Confirmed, started in between 4.9.0 and 4.9.1.

[Bug fortran/77666] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:471

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||jakub at redhat dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All releases that I have are affected (4.5.0+).

[Bug fortran/77667] ICE in expand_call, at calls.c:2588

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-20
 CC||marxin at gcc dot gnu.org
  Known to work||4.5.4
 Ever confirmed|0   |1
  Known to fail||4.6.0

--- Comment #2 from Martin Liška  ---
Started with 4.6.0, ICE messages are various, as reported.

[Bug lto/77669] New: Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

Bug ID: 77669
   Summary: Incorrect LTO code on embedded ARM
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wgh at beyondunreal dot com
  Target Milestone: ---

So I've been playing around with my STM32 microcontroller and various compiler
options, and noticed that my program doesn't work when I build it with LTO.

I've observed this behaviour on GCC 4.9.3 and 5.4.0.

The problematic piece of code looks like this:
auto i = std::uniform_int_distribution<>(0, ncolors - 1)(random_engine);

Where random_engine is declared at global level
static std::minstd_rand random_engine;

The function simply never returns.

According to my debugging, the generator returns always zero, and it causes the
"downscale" loop inside uniform_int_distribution::operator()
(/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h)
to loop forever.

I'll try to post some more debugging info soon.

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0/armv7m-hardfloat-eabi-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7m-hardfloat-eabi/5.4.0/lto-wrapper
Target: armv7m-hardfloat-eabi
Configured with:
/var/tmp/portage/cross-armv7m-hardfloat-eabi/gcc-5.4.0/work/gcc-5.4.0/configure
--host=x86_64-pc-linux-gnu --target=armv7m-hardfloat-eabi
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0
--includedir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include
--datadir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0
--mandir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/man
--infodir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/info
--with-gxx-include-dir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5
--with-python-dir=/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.4.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-poison-system-directories --with-sysroot=/usr/armv7m-hardfloat-eabi
--disable-bootstrap --with-newlib --enable-multilib --disable-altivec
--disable-fixed-point --with-float=hard --with-arch=armv7-m --with-mode=thumb
--with-float=hard --with-fpu=vfpv3-d16 --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto
--without-isl --disable-libsanitizer
Thread model: single
gcc version 5.4.0 (Gentoo 5.4.0 p1.0, pie-0.6.5)

[Bug target/77670] New: PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

Bug ID: 77670
   Summary: PowerPC64 Spec 2006 fails on 453.povray using
-mcpu=power9 -mpower9-minmax
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39662&action=edit
-save-temps file (cut down) that shows the problem

The new min/max instructions in PowerPC ISA 3.0 generate an insn not found
error.  Note, these instructions are not currently enabled with -mcpu=power9,
they are enabled with a separate switch: -mpower9-minmax.  It is likely that
the same bug appears in GCC 6.2.

To replicate, compile the attached .ii file with -O3 -mcpu=power9
-mpower9-minmax -ffast-math -w.  The following error is generated:

hcmplx.cpp: In function 'void pov::Normal_Calc_HCompl_Reciprocal(double*, int,
pov::FRACTAL*)':
hcmplx.cpp:891:1: error: unrecognizable insn:
(insn 62 61 63 5 (parallel [
(set (reg:DF 305)
(if_then_else:DF (ne:CCFP (reg:DF 310)
(reg/v:DF 230 [ det ]))
(reg:DF 309)
(reg/v:DF 203 [ xx ])))
(clobber (scratch:V2DI))
]) -1
 (nil))
hcmplx.cpp:891:1: internal compiler error: in extract_insn, at recog.c:2310
0x10a83fe3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/trunk-240142/gcc/rtl-error.c:108
0x10a84047 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/meissner/fsf-src/trunk-240142/gcc/rtl-error.c:116
0x10a49a1b extract_insn(rtx_insn*)
/home/meissner/fsf-src/trunk-240142/gcc/recog.c:2310
0x10791fbb instantiate_virtual_regs_in_insn
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1580
0x10791fbb instantiate_virtual_regs
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1948
0x10791fbb execute
/home/meissner/fsf-src/trunk-240142/gcc/function.c:1997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Similar errors occur on the gamess and soplex benchmarks.

The reason this occurs it creates a floating point CMOVE instruction with a NE.
 The way to fix it is to provide insns to invert the sense of the test.

[Bug target/77670] PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-20
 Ever confirmed|0   |1

[Bug lto/77669] Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

--- Comment #1 from wgh at beyondunreal dot com ---
The loop in question looks like this, in C++ and aseembly:

if (__urngrange > __urange)
  {
// downscaling
const __uctype __uerange = __urange + 1; // __urange can be zero
const __uctype __scaling = __urngrange / __uerange;
const __uctype __past = __uerange * __scaling;
do
  __ret = __uctype(__urng()) - __urngmin;
while (__ret >= __past);
__ret /= __scaling;
  }


080001d6
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6>:
 ...
 ...
 80001f4:   f7ff ffda   bl  80001ac
<_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>
 80001f8:   1e43subsr3, r0, #1
 80001fa:   429ccmp r4, r3
 80001fc:   d9fabls.n   80001f4
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6+0x1e>

So LCG has been greatly optimized and has become a single __calc call.
gdb shows some extra "fake" frames, even though they have been optimized out.

#0  __calc (__x=0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.tcc:62
#1  0x080001f8 in std::__detail::__mod(unsigned int) ()
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:151   
#2  operator() (this=0x2430 ) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:332
#3  operator() (this=this@entry=0x2001ffd0, __param=..., __urng=...)
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:242
#4  0x080002be in operator() (__urng=..., this=0x2001ffd0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:16

The __calc function looks like this in assembly:
080001ac <_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>:
 80001ac:   f64a 52c8   movwr2, #44488  ; 0xadc8
 80001b0:   fbb0 f1f2   udivr1, r0, r2
 80001b4:   fb02 0311   mls r3, r2, r1, r0
 80001b8:   f64b 428f   movwr2, #48271  ; 0xbc8f
 80001bc:   4353mulsr3, r2
 80001be:   f640 5247   movwr2, #3399   ; 0xd47
 80001c2:   fb02 f001   mul.w   r0, r2, r1
 80001c6:   4283cmp r3, r0
 80001c8:   bf3citt cc
 80001ca:   f103 4300   addcc.w r3, r3, #2147483648 ; 0x8000
 80001ce:   f103 33ff   addcc.w r3, r3, #4294967295 ; 0x
 80001d2:   1a18subsr0, r3, r0
 80001d4:   4770bx  lr

It should calculate x = (ax + c) mod m, where a = 48271u, c = 0u, m =
2147483647u

So in case of x=0, new x will also be zero. Hmm, sounds weird.

[Bug target/77669] Incorrect LTO code on embedded ARM

[wgh at beyondunreal dot com]

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

--- Comment #2 from wgh at beyondunreal dot com ---
It looks like LTO somehow breaks constructors for static variables. I have no
better idea ATM.

[Bug target/77670] PowerPC64 Spec 2006 fails on 453.povray using -mcpu=power9 -mpower9-minmax

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Sep 20 23:51:01 2016
New Revision: 240294

URL: https://gcc.gnu.org/viewcvs?rev=240294&root=gcc&view=rev
Log:
Fix PR 77670

Modified:
branches/ibm/minmax/gcc/ChangeLog.meissner
branches/ibm/minmax/gcc/config/rs6000/predicates.md
branches/ibm/minmax/gcc/config/rs6000/rs6000.md

[Bug c++/58589] diagnostics: missing proper file:line on C++ compilation error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Probably related to PR74585.  In both cases we have full stores followed by
partial loads, and DSE isn't able to figure out the store is dead as a result.