[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)

2017-05-23 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-23
 CC||jakub at gcc dot gnu.org
  Component|target  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Uh.  .optimized:

float sumfloat_omp(const float*) (const float * arr)
{
  unsigned long ivtmp.22;
  vector(8) float D__lsm0.19;
  const vector(8) float vect__23.18;
  const vector(8) float vect__4.16;
  float stmp_sum_19.12;
  vector(8) float vect__18.10;
  float D.2841[8];
  vector(8) float _10;
  void * _77;
  unsigned long _97;

   [1.00%]:
  arr_13 = arr_12(D);
  __builtin_memset (&D.2841, 0, 32);
  _10 = MEM[(float *)&D.2841];
  ivtmp.22_78 = (unsigned long) arr_13;
  _97 = ivtmp.22_78 + 4096;

...

   [1.00%]:
  MEM[(float *)&D.2841] = vect__23.18_58;
  vect__18.10_79 = MEM[(float *)&D.2841];
  stmp_sum_19.12_50 = [reduc_plus_expr] vect__18.10_79;
  return stmp_sum_19.12_50;


well, that explains it ;)  Coming from

   [99.00%]:
  # i_33 = PHI 
  # ivtmp_35 = PHI 
  _21 = GOMP_SIMD_LANE (simduid.0_14(D));
  _1 = (long unsigned int) i_33;
  _2 = _1 * 4;
  _3 = arr_13 + _2;
  _4 = *_3;
  _22 = D.2841[_21];
  _23 = _4 + _22;
  D.2841[_21] = _23;
  i_25 = i_33 + 1;
  ivtmp_28 = ivtmp_35 - 1;
  if (ivtmp_28 != 0)
goto ; [98.99%]

so we perform the reduction in memory, then LIM performs store-motion on it
but the memset isn't inlined early enough to rewrite the decl into SSA
(CCP from GOMP_SIMD_VF is missing).  In DOM we have

  __builtin_memset (&D.2841, 0, 32);
  _10 = MEM[(float *)&D.2841];

so we do not fold that.

If OMP SIMD always zeros the vector then it could also emit the maybe easier
to optimize

  WITH_SIZE_EXPR<_3, D.2841> = {};

of course gimple_fold_builtin_memset should simply be improved to optimize
now constant-size memset to = {}.

I'll have a look.

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

2017-05-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |6.4
Summary|ipa-cp wrongly adding   |[6 regression] ipa-cp
   |LO(symbol) twice|wrongly adding LO(symbol)
   ||twice

--- Comment #8 from Eric Botcazou  ---
OK, I can reproduce now, it comes from the -fdelayed-branch option.

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

2017-05-23 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Investigating.

[Bug bootstrap/80860] AIX Bootstrap failure

2017-05-23 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-23
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.  Bisection in progress.

[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)

2017-05-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844

--- Comment #2 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #1)
> If OMP SIMD always zeros the vector then it could also emit the maybe easier
> to optimize
> 
>   WITH_SIZE_EXPR<_3, D.2841> = {};

It doesn't always zero, it can be pretty arbitrary.  For the default reductions
on integral/floating point types it does zero for +/-/|/^/|| reductions, but
e.g. 1 for */&&, or ~0 for &, or maximum or minimum for min or max.  For user
defined reductions it can be whatever the user requests, constructor for some
class type, function call, set to arbitrary value etc.
For other privatization clauses it is again something different (uninitialized
for private/lastprivate, some other var + some bias for linear, ...).
And then after the simd loop there is again a reduction or something similar,
but again can be quite complex in the general case.  If it helps, we could mark
the pre-simd and post-simd loops somehow in the loop structure or something,
but the actual work needs to be done later, especially after inlining,
including the vectorizer and other passes.
E.g. for the typical reduction where the vectorizer computes the "simd array"
in a vector temporary (or collection of them), it would be nice if we were able
to pattern recognize simple cases and turn those into vector reduction
patterns.

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

2017-05-23 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837

--- Comment #2 from Peter Cordes  ---
(In reply to Richard Biener from comment #1)
> GCC 8 generates a __atomic_load_16 call for me while GCC 6 does
> 
> lock cmpxchg16b (%rdi)

That's expected.  See https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02344.html
for the reason.  (Apparently the plan is for gcc7 to call libatomic, to make it
possible to change the implementation sooner in the future if that's deemed
appropriate, even in ways that breaks compat with code that inlines lock
cmpxchg16b.)

The bug here is that gcc7.1.0 goes berserk after the library call, but gcc8
doesn't.  I haven't tested on any other gcc7 versions.

[Bug tree-optimization/80844] OpenMP SIMD doesn't know how to efficiently zero a vector (its stores zeros and reloads)

2017-05-23 Thread peter at cordes dot ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844

--- Comment #3 from Peter Cordes  ---
(In reply to Jakub Jelinek from comment #2)
> It doesn't always zero, it can be pretty arbitrary.

Is if feasible have it just load the first vector of elements, instead of
broadcasting the identity value?  i.e. do the vector equivalent of 

 sum = a[0]
 for (i=1; ...)

i.e. peel the first iteration and optimize away the computation, leaving just
the load.  Another way to handle the actual loop body running zero times for
counts between 1 and 2 full vectors is to put the loop entry point after the
first load & accumulate.

(BTW, for operations like min/max/AND/OR where duplicate values don't affect
the result, an unaligned final vector would be much more efficient than a
scalar cleanup for the last less-than-full-vector of elements, but you still
need a scalar fallback if the total count can be smaller than 1 full vector...)

[Bug bootstrap/80860] AIX Bootstrap failure

2017-05-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860

--- Comment #2 from Segher Boessenkool  ---
It is memory corruption.  PR80843 may be the same.

It is caused by my r248256, sws for FP.

I have a patch.  What a silly bug.

[Bug bootstrap/80860] AIX Bootstrap failure

2017-05-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860

Segher Boessenkool  changed:

   What|Removed |Added

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

[Bug driver/80836] final binaries missing rpath despite all attempts to use the appropriate -Wl,-rpath= statement

2017-05-23 Thread rjvbertin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80836

René J.V. Bertin  changed:

   What|Removed |Added

   Host||linux

--- Comment #4 from René J.V. Bertin  ---
I've been trying to get this right, but without luck. In my latest attempt I
had -Wl,-rpath statements in BOOT_LDFLAGS as well as in LDFLAGS during the
configure, make and "make install" steps and I also configured them using
--with-stage1-ldflags . Yet my binaries didn't contain any rpath information at
all.

I don't think it's such an uncommon situation to build gcc for installation
somewhere other than /usr. Non-privileged users may build for installation
under their home directory, and what's more, a standard (64bit) build on Ubuntu
will apparently put the runtime libraries into /usr/lib64 or /usr/local/lib64,
which is NOT a system standard location.

There should really be a reliable and easily accessible method to achieve this:

--with-stdlib-rpaths : add the stdlib (libgcc_s, libstdc++, libfortran etc)
paths to the RPATH of the generated executable (including the GCC executables)
--with-rpaths : build the GCC executables and libraries with the paths to all
dependencies stored in the RPATH.

I think those are the 2 distinct aspects of the issue, but I'm not certain it's
justified not to handle them with a single option.

FWIW, this is all not an issue on Mac where dependencies are stored with their
full path by default. A hassle sometimes, but most of the time it makes life a
lot easier.

[Bug bootstrap/80860] AIX Bootstrap failure

2017-05-23 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860

--- Comment #3 from David Edelsohn  ---
But I had a successful bootstrap with r248295, which is after your patch.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue May 23 10:16:08 2017
New Revision: 248362

URL: https://gcc.gnu.org/viewcvs?rev=248362&root=gcc&view=rev
Log:
PR libstdc++/67214 Avoid signed overflow in num_get::_M_extract_int

2017-05-23  Xi Ruoyao  

PR libstdc++/67214
* include/bits/locale_facets.tcc (num_get::_M_extract_int): Add
explicit conversion to avoid signed overflow.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_facets.tcc

[Bug target/80862] New: [x86] Wrong rounding results for some test cases

2017-05-23 Thread sebastian.peryt at intel dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80862

Bug ID: 80862
   Summary: [x86] Wrong rounding results for some test cases
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.peryt at intel dot com
CC: julia.koval at intel dot com, ubizjak at gmail dot com
  Target Milestone: ---
Target: X86

Created attachment 41408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41408&action=edit
Patch to reproduce described error.

Recently I have found that rounding intrinsics for some particular cases
produce wrong results. There have to be three specific conditions fulfilled to
produce it:
- test has to be compiled with O1 or O2 (doesn't appear on O0),
- test case has to have only two intrinsics - regular (e.g. _mm512_cvtps_epi32)
and round (e.g. _mm512_cvt_roundps_epi32),
- both intrinsics must use the same input argument.

As a result value from first (regular) intrinsic is copied to the second
(round)intrinsic result. In asm output it can be seen that the same register is
used for both assignments:

vcvtps2dq %zmm0, %zmm1
vmovdqa64 %zmm1, -368(%rbp)
pushq -312(%rbp)
pushq -320(%rbp)
pushq -328(%rbp)
vcvtps2dq {rz-sae}, %zmm0, %zmm0
pushq -336(%rbp)
vmovdqa64 %zmm1, -304(%rbp)

>From what I gathered so far this is happening due to the use of parallel side
effect for rounding md template in i386/subst.md. Because parallel is executing
each side effect individually at first, on cse1 pass the part which is similar
for both intrinsics get optimized. After that the same register is assigned for
move operation in both assignments of the results and effectively regular and
round intrinsic produces the same result.

Probably some other side effect has to be used to set rounding flags to fix
this issue, but I am not sure which one it should be. Eventually some
modifications have to be made in cse.c to properly handle such use of parallel.

[Bug target/80863] New: [SH]: sh/sh.c:6772:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2330

2017-05-23 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80863

Bug ID: 80863
   Summary: [SH]: sh/sh.c:6772:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2330
   Product: gcc
   Version: 8.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna
pshot&arch=sh4&ver=20170520-1&stamp=1495506518&raw=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: doko at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Trying to build a current gcc-8 snapshot in Debian unstable on sh4 fails with:

/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu 
-I/<>/build/prev-sh4-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/.
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o sh.o -MT sh.o -MMD -MP
-MF ./.deps/sh.TPo ../../src/gcc/config/sh/sh.c
../../src/gcc/config/sh/sh.c: In function 'void output_stack_adjust(int, rtx,
int, HARD_REG_ELT_TYPE (*)[5], bool)':
../../src/gcc/config/sh/sh.c:6772:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2330
 }
 ^
mmap: Permission denied
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc7otGNI.out file, please attach this to
your bugreport.

I currently don't have the preprocessed source at hand, although I'm not sure
it's actually directly pasted to the build log [1].

Let me know when you need anything else.

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=sh4&ver=20170520-1&stamp=1495506518&raw=0

[Bug c/80852] Optimisation fails to recognise sum computed by loop

2017-05-23 Thread krister.walfridsson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80852

krister.walfridsson at gmail dot com changed:

   What|Removed |Added

 CC||krister.walfridsson at gmail 
dot c
   ||om

--- Comment #3 from krister.walfridsson at gmail dot com ---
This is related to (or a dup of) tree-optimization/46186

[Bug ipa/80581] [8 Regression] ICE: in estimate_node_size_and_time, at ipa-inline-analysis.c:3425

2017-05-23 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80581

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385

2017-05-23 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80743

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #8 from Jan Hubicka  ---
Mine.

[Bug bootstrap/80860] AIX Bootstrap failure

2017-05-23 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860

David Edelsohn  changed:

   What|Removed |Added

 CC|hubicka at gcc dot gnu.org |

--- Comment #4 from David Edelsohn  ---
Note that GCC bootstraps successfully with r248317, prior to richi's change

* df-scan.c (df_insn_refs_verify): Speedup when not verifying.

I will try after the sws patch, but, if not, there is something wrong with
richi's patch.

[Bug target/68211] Free __m128d subreg of double

2017-05-23 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68211

--- Comment #6 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #4)
> If the upper bits of the register can contain arbitrary garbage, then
> keeping it there might result in e.g. floating point exceptions being raised
> (it could be even a sNAN).  Of course a different thing is if we can prove
> what is in those upper bits and be sure it doesn't do any harm, or if the
> operations on it later on are masked.

For
  double f(double x){return __builtin_sqrt(x);}
we generate
vsqrtsd %xmm0, %xmm0, %xmm0
with -O -fno-math-errno.
I don't see what makes the rounded version different from the non-rounded
version.

[Bug target/80862] [x86] Wrong rounding results for some test cases

2017-05-23 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80862

--- Comment #1 from Marc Glisse  ---
Related to PR 73350.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk, but let's keep the bug report open, as this is worth
backporting.

[Bug c++/80858] When trying to copy std::unordered_map illegally, error message doesn't tell what's wrong

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80858

--- Comment #5 from Jonathan Wakely  ---
Yes, that's great, thanks.

As you observed, Clang doesn't indicate the location that triggers the invalid
instantiation, but EDG does, correctly pointing to line 22:

"um2.cc", line 9: error: no suitable constructor exists to convert from "int"
  to "Empty"
  T t(3);
  ^
  detected during:
instantiation of "A &A::operator=(const A &) [with
  T=Empty]" at line 22
implicit generation of "B &B::operator=(const B &)" at line 22

1 error detected in the compilation of "um2.cc".

[Bug middle-end/80743] [8 Regression] ICE in estimate_node_size_and_time, at ipa-inline-analysis.c:3385

2017-05-23 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80743

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #9 from Markus Trippelsdorf  ---
Fixed by r248366.

[Bug c++/80864] New: Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

2017-05-23 Thread oss at florianjw dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864

Bug ID: 80864
   Summary: Brace-initialization of a constexpr variable of an
array in a POD triggers ICE from templates
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oss at florianjw dot de
  Target Milestone: ---

The following code triggers an ICE in GCC 6.3.0 and 6.3.1 under independent
systems:

``
struct array {
char c[1];
};

template 
void gun() {
constexpr auto c = array{{}};
}

void fun() {
gun();
}
``

`g++ test.cpp`:

``
test.cpp: In instantiation of ‘void gun() [with T = int]’:
test.cpp:13:11:   required from here
test.cpp:8:29: internal compiler error: in reshape_init_r, at cp/decl.c:5898
  constexpr auto c = array{{}};
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
``

I didn't find a bug-report with this exact problem, but this one could possibly
be related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79607

[Bug target/80861] ARM (VFPv3): Inefficient float-to-char conversion goes through memory

2017-05-23 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80861

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-23
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
(In reply to Gergö Barany from comment #0)
> Created attachment 41407 [details]
> Input C file for triggering the bug
> 
> Consider the attached code:
> 
> $ cat tst.c
> char fn1(float p1) {
>   return (char) p1;
> }

Confirmed. This is due to the extend patterns allowing memory, but they aren't
marked as having a higher cost, so it decides the spill given register move
cost is larger than memory move cost. A quick workaround would be to add ??m to
the various extend patterns.

[Bug bootstrap/80865] New: broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn

2017-05-23 Thread mojca at macports dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865

Bug ID: 80865
   Summary: broken compilation on Mac OS X 10.5 / powerpc:
unrecognizable insn
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mojca at macports dot org
  Target Milestone: ---

Created attachment 41409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41409&action=edit
Full build log from a broken gcc build

Version 7-20170226 fails to compile on powerpc architecture on Mac. (I can
check version 7.1.0 as soon as the version gets updated in MacPorts.)

In file included from /path/to/gcc-7-20170226/libgcc/unwind-dw2.c:1728:0:
/path/to/gcc-7-20170226/libgcc/unwind.inc: In function
'_Unwind_RaiseException':
/path/to/gcc-7-20170226/libgcc/unwind.inc:136:1: error: unrecognizable insn:
 }
 ^
(jump_insn/f 193 192 194 14 (parallel [
(return)
(use (symbol_ref:SI ("*eh_rest_world_r10")))
(clobber (reg:SI 11 r11))
(set (reg:SI 70 cr2)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int 4 [0x4])) [30  S4 A8]))


Full build logs are here:
https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/28045
as well as in the attachment.

Sorry for being unable to provide more details, but I don't know what exactly
to report.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923

2017-05-23 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803

--- Comment #6 from Bill Schmidt  ---
(In reply to Ian Lance Taylor from comment #5)
> To reproduce:
> make GOTESTFLAGS=--keep net/check
> 
> My apologies if I omitted the "/check" before.

Thanks!  That helps.

> 
> Yes, you have identified the point in the libgo Makefile that produces this,
> but the point is that the test program built by `make net/check` (and
> preserved if you use `GOTESTFLAGS=--keep`) is somehow miscompiled.

Right, I got that -- but was struggling along to try to figure out how to
generate that program, since I couldn't get it to hang around.  I'll try again
with the /check...

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

2017-05-23 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597

--- Comment #16 from Pat Haugen  ---
(In reply to Dmitry Babokin from comment #14)
> Original test case still fails with compiler switches that I've originally
> reported (-fsanitize=undefined).

Is your failure fixed with r248325?

[Bug c++/80866] New: [8 Regression] segfault in is_overloaded_fn()

2017-05-23 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866

Bug ID: 80866
   Summary: [8 Regression] segfault in is_overloaded_fn()
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

% cat pow_test.ii
void pow();
namespace math {
template  void pow(T);
}
using namespace math;
decltype(pow<>(0)) z();

 % g++ -c pow_test.ii
pow_test.ii:6:10: internal compiler error: Segmentation fault
 decltype(pow<>(0)) z();
  ^
0xd537bf crash_signal
../../gcc/gcc/toplev.c:337
0x7acc14 is_overloaded_fn(tree_node*)
../../gcc/gcc/cp/tree.c:2297
0x792535 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/gcc/cp/semantics.c:3742
0x6f25c2 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5325
0x70576f cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6781
0x70652d cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8117
0x707543 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:8796
0x707c67 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8897
0x708544 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9184
0x70c388 cp_parser_expression
../../gcc/gcc/cp/parser.c:9353
0x70c87c cp_parser_decltype_expr
../../gcc/gcc/cp/parser.c:13756
0x70c87c cp_parser_decltype
../../gcc/gcc/cp/parser.c:13836
0x71294f cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:16735
0x7001bd cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16520
0x70140a cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13353
0x720551 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12678
0x721455 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12625
0x726924 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12523
0x72855b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12399
0x72883a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4364

[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 23 15:54:59 2017
New Revision: 248371

URL: https://gcc.gnu.org/viewcvs?rev=248371&root=gcc&view=rev
Log:
2017-05-23  Jerry DeLisle  

PR libgfortran/80256
* gfortran.dg/bind_c_array_params_2.f90: Modify to pass on
Cygwin.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90

[Bug fortran/80256] Cygwin test fail: bind_c_array_params_2.f90 scan-assembler-times

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Closing

[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()

2017-05-23 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #1 from Nathan Sidwell  ---
Ok, this is also present on modules branch, but looks like it'll be obvious.

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue May 23 16:11:57 2017
New Revision: 248374

URL: https://gcc.gnu.org/viewcvs?rev=248374&root=gcc&view=rev
Log:
PR libstdc++/67578 Implement non-trivial std::random_device::entropy

2017-05-23  Xi Ruoyao  
Jonathan Wakely  

PR libstdc++/67578
* acinclude.m4: Bump libtool_VERSION.
* config/abi/pre/gnu.ver: Create GLIBCXX_3.4.24 with new symbol.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add test for .
* doc/xml/manual/abi.xml: Document new library version.
* include/bits/random.h (random_device::entropy)
[_GLIBCXX_USE_RANDOM_TR1]: Add call to new _M_getentropy member.
(random_device::_M_getentropy): Declare.
* src/c++11/random.cc (random_device::_M_getentropy): Define.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.24 to known
versions, and make it the latest version.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/doc/xml/manual/abi.xml
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/src/c++11/random.cc
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc

[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed

2017-05-23 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823

--- Comment #3 from Peter Bergner  ---
Testing a patch.

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Implemented for GCC 8.

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

2017-05-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578

--- Comment #6 from Jonathan Wakely  ---
N.B. we still return zero for the default random_device if using the RDRAND
instruction. I don't know what we could do there, except maybe trust Intel and
return the maximum value.

[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed

2017-05-23 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823

--- Comment #4 from Peter Bergner  ---
Stupid thinko on my part.  An extra increment is causing us to skip some of the
case labels in the switch statement, which only causes an ICE/problem if the
skipped case happens to point to the same unreachable block as an earlier case
label.  In that case, the earlier case has already removed the unreachable
block, but skipped case label still points to it, leading to the verify_flow
ICE.
I'm testing the following:

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 248375)
+++ gcc/tree-cfg.c  (working copy)
@@ -1726,7 +1726,6 @@ group_case_labels_stmt (gswitch *stmt)
remove_edge_and_dominated_blocks (base_edge);
  gimple_switch_set_label (stmt, base_index, NULL_TREE);
  new_size--;
- i++;
}
 }

[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()

2017-05-23 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Tue May 23 17:04:56 2017
New Revision: 248377

URL: https://gcc.gnu.org/viewcvs?rev=248377&root=gcc&view=rev
Log:
PR c++/80866
* parser.c (cp_parser_template_id): Keep the lookup when stashing
the template_id.

PR c++/80866
* g++.dg/parse/pr80866.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr80866.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80866] [8 Regression] segfault in is_overloaded_fn()

2017-05-23 Thread nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80866

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r248377.

[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029

2017-05-23 Thread oarias at knights dot ucf.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242

Orlando Arias  changed:

   What|Removed |Added

 CC||oarias at knights dot ucf.edu

--- Comment #3 from Orlando Arias  ---
Greetings,

I also ran into this problem when compiling newlib [snapshot 2.5.0.20170421]
with a bootstrapping gcc using version 7.1.0 for the msp430-elf target.

$ msp430-elf-gcc -v
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/msp430-elf/7.1.0/lto-wrapper
Target: msp430-elf
Configured with: ../configure --prefix=/usr --program-prefix=msp430-elf-
--target=msp430-elf --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-shared --disable-nls --disable-threads --enable-languages=c
--enable-multilib --without-headers --with-newlib
--with-local-prefix=/usr/msp430-elf --with-sysroot=/usr/msp430-elf
--with-as=/usr/bin/msp430-elf-as --with-ld=/usr/bin/msp430-elf-ld
--disable-libgomp
Thread model: single
gcc version 7.1.0 (GCC) 

The particular line that fails is (expanded):

 if ((nmemb >= ((size_t)1 << (sizeof(size_t) * 4)) || size >= ((size_t)1 <<
(sizeof(size_t) * 4))) &&
 nmemb > 0 && 
 (0xfUL) 
  / nmemb < size) {


Failure occurs at the comparison:

../../../../../../newlib/libc/stdlib/reallocarray.c:37:36: internal compiler
error: in simplify_subreg, at simplify-rtx.c:6034
  nmemb > 0 && SIZE_MAX / nmemb < size) {

Is there any way to disable/bypass this particular behavior? Thank you.

Cheers,
Orlando.

[Bug target/54168] ARM: Redundant instructions emitted at -O3

2017-05-23 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54168

Wilco  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||wilco at gcc dot gnu.org
  Known to work||6.3.1
 Resolution|--- |FIXED
  Known to fail||4.8.2, 5.4.1

--- Comment #3 from Wilco  ---
(In reply to Mans Rullgard from comment #0)
> Created attachment 27932 [details]
> Test case
> 
> Compiling the attached code for ARM results in redundant instructions even
> at -O3 optimisation.  Note this sequence (interleaved with other
> instructions):
> 
> ldrhr3, [r0]@ unaligned
> and r3, r3, #2
> uxthr3, r3
> cmp r3, #0
> beq .L2
> 
> The UXTH is clearly redundant since no more than 16 bits can be set by LDRH.
> Once this is removed, the CMP can be folded with the AND as ANDS.
> 
> Interestingly, this badness only happens with -march=armv6 or higher.  If
> the target is v5, sane code is generated.
> 
> This is a regression in the 4.7 and 4.8 branches.  4.6 and earlier behave
> properly.

GCC6.3 produces with -O3:

ldrhr0, [r1]
andsr0, r0, #2
it  ne
movne   r0, #0
beq .L8

Closing as GCC4.8 isn't active.

[Bug bootstrap/80867] New: [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

2017-05-23 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80867

Bug ID: 80867
   Summary: [7 Regression] gnat bootstrap broken on
powerpc64le-linux-gnu
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with the gcc-7-branch r248347, last successful build was based on r248295.

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/powerpc64le-linux-gnu/bin/ -B/usr/powerpc64le-linux-gnu/
lib/ -isystem /usr/powerpc64le-linux-gnu/include -isystem
/usr/powerpc64le-linux-gnu/sys-include -isystem /<>/build/
sys-include-c -g -O2   -W -Wall -gnatpg -nostdinc  -gnatn -g -O3
-fdebug-prefix-map=/<>/build/powerpc64le-linux-
gnu/libada=. -fstack-protector-strong  a-strfix.adb -o a-strfix.o


raised STORAGE_ERROR : stack overflow or erroneous memory access
../gcc-interface/Makefile:296: recipe for target 'a-strfix.o' failed
make[8]: *** [a-strfix.o] Error 1
make[8]: Leaving directory '/<>/build/gcc/ada/rts'
gcc-interface/Makefile:2828: recipe for target 'gnatlib' failed
make[7]: *** [gnatlib] Error 2
make[7]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:2920: recipe for target 'gnatlib-shared-dual' failed
make[6]: *** [gnatlib-shared-dual] Error 2
make[6]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:3016: recipe for target 'gnatlib-shared' failed
make[5]: *** [gnatlib-shared] Error 2
make[5]: Leaving directory '/<>/build/gcc/ada'
Makefile:118: recipe for target 'gnatlib-shared' failed
make[4]: *** [gnatlib-shared] Error 2
make[4]: Leaving directory
'/<>/build/powerpc64le-linux-gnu/libada'
Makefile:20686: recipe for target 'all-target-libada' failed
make[3]: *** [all-target-libada] Error 2

configured with

 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-7
 --program-prefix=powerpc64le-linux-gnu-
 --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-libquadmath
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --enable-objc-gc=auto
 --enable-secureplt
 --with-cpu=power8
 --enable-targets=powerpcle-linux
 --disable-multilib
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-checking=release
 --build=powerpc64le-linux-gnu
 --host=powerpc64le-linux-gnu
 --target=powerpc64le-linux-gnu

and using -O3 as the optimization flag for the build (apparently -O2 works as
seen in another build).

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923

2017-05-23 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803

--- Comment #7 from Bill Schmidt  ---
Thanks, Ian, I have the saved executable now.

[Bug c/80868] New: "Duplicate const" warning emitted in `const typeof(foo) bar;`

2017-05-23 Thread george.burgess.iv at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868

Bug ID: 80868
   Summary: "Duplicate const" warning emitted in `const
typeof(foo) bar;`
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george.burgess.iv at gmail dot com
  Target Milestone: ---

Minimal test-case (repros with 7.1: https://godbolt.org/g/A2dTCP):

$ cat tc.c
const int i;
const typeof(i) j;

$ gcc -std=gnu89 -pedantic tc.c
2:17: warning: duplicate 'const' [-Wpedantic]
 const typeof(i) j;

Expected behavior: no duplicate const warning when there's only one `const` on
the decl for `j`.

While the current behavior is understandable, I think it would be good to relax
the warning in this case. typeof is often used in macros, so silencing this
warning isn't always trivial. Since typeof is also a language extension, I
don't believe that C89 6.5.3 (which I assume is the only reason GCC is emitting
these complaints in the first place) needs to apply here.

Thank you for your time :)

[Bug ada/80869] New: Ada.Directories is missing Name_Case_Equivalence

2017-05-23 Thread simon at pushface dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869

Bug ID: 80869
   Summary: Ada.Directories is missing Name_Case_Equivalence
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x64_64-apple-darwin15
 Build: x86_64-apple-darwin15

As in Summary. AARM A.16(20.2) refers.

http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-A-16.html#p20.2

I guess when it was decided not to implement the optional
Hierarchical_File_Names in AI05-0049 the other, non-optional, change was
missed?

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0049-1.txt?rev=1.12&raw=N

[Bug c++/80396] New builtin to make std::make_integer_sequence efficient and scalable

2017-05-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80396

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue May 23 20:14:01 2017
New Revision: 248384

URL: https://gcc.gnu.org/viewcvs?rev=248384&root=gcc&view=rev
Log:
PR c++/80396 - built-in for make_integer_sequence.

* pt.c (builtin_pack_fn_p, builtin_pack_call_p)
(expand_integer_pack, expand_builtin_pack_call): New.
(find_parameter_packs_r): Check builtin_pack_call_p.
(check_for_bare_parameter_packs): Handle it.
(tsubst_pack_expansion): Call expand_builtin_pack_call.
(declare_integer_pack): New.
(init_template_processing): Call it.
* decl2.c (mark_used): Check builtin_pack_fn_p.

Added:
trunk/gcc/testsuite/g++.dg/ext/integer-pack1.C
trunk/gcc/testsuite/g++.dg/ext/integer-pack2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/doc/extend.texi

[Bug c++/80396] New builtin to make std::make_integer_sequence efficient and scalable

2017-05-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80396

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Done.

[Bug c++/80294] [5/6 Regression] ICE with constexpr and inheritance

2017-05-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80294

--- Comment #19 from Jason Merrill  ---
Author: jason
Date: Tue May 23 20:48:58 2017
New Revision: 248385

URL: https://gcc.gnu.org/viewcvs?rev=248385&root=gcc&view=rev
Log:
PR c++/80294 - ICE with constexpr and inheritance.

* constexpr.c (reduced_constant_expression_p):
A null constructor element is non-constant.
(cxx_eval_indirect_ref): Don't VERIFY_CONSTANT before
returning an empty base.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637

2017-05-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Tue May 23 20:51:33 2017
New Revision: 248386

URL: https://gcc.gnu.org/viewcvs?rev=248386&root=gcc&view=rev
Log:
PR c++/80267 - ICE with nested capture of reference

PR c++/60992
* pt.c (tsubst_copy): Handle lookup finding a capture proxy.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way

2017-05-23 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Tue May 23 20:51:33 2017
New Revision: 248386

URL: https://gcc.gnu.org/viewcvs?rev=248386&root=gcc&view=rev
Log:
PR c++/80267 - ICE with nested capture of reference

PR c++/60992
* pt.c (tsubst_copy): Handle lookup finding a capture proxy.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested6.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug libgcc/80870] New: ICE building sh-elf crosscompiler on macOS

2017-05-23 Thread Anders.Montonen at iki dot fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870

Bug ID: 80870
   Summary: ICE building sh-elf crosscompiler on macOS
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Anders.Montonen at iki dot fi
  Target Milestone: ---

Host os: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017;
root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64

Host compiler: Apple LLVM version 8.1.0 (clang-802.0.42)

Configure string: ../gcc-7.1.0/configure --prefix=/Users/anders/local
--target=sh-elf --disable-nls --enable-languages="c,c++" --with-newlib

Output:
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include
-isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh
-L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys
-L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh
-B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem
/Users/anders/local/sh-elf/include -isystem
/Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc
-I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc
-I../../../../gcc-7.1.0/libgcc/../include  -DHAVE_CC_TLS  -o _eprintf.o -MT
_eprintf.o -MD -MP -MF _eprintf.dep -DL_eprintf -c
../../../../gcc-7.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include
-isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh
-L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys
-L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh
-B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem
/Users/anders/local/sh-elf/include -isystem
/Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc
-I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc
-I../../../../gcc-7.1.0/libgcc/../include  -DHAVE_CC_TLS  -o __gcc_bcmp.o -MT
__gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c
../../../../gcc-7.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/xgcc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/./gcc/ -nostdinc
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/ -isystem
/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/newlib/targ-include
-isystem /Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/newlib/libc/include
-B/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/sh
-L/Users/anders/work/toolchain/gcc/7.1.0/sh-elf/sh-elf/libgloss/libnosys
-L/Users/anders/work/toolchain/gcc/7.1.0/gcc-7.1.0/libgloss/sh
-B/Users/anders/local/sh-elf/bin/ -B/Users/anders/local/sh-elf/lib/ -isystem
/Users/anders/local/sh-elf/include -isystem
/Users/anders/local/sh-elf/sys-include-g -O2 -ml -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc
-I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc
-I../../../../gcc-7.1.0/libgcc/../include  -DHAVE_CC_TLS  -o _divdi3.o -MT
_divdi3.o -MD -MP -MF _divdi3.dep -DL_divdi3 -c
../../../../gcc-7.1.0/libgcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-7.1.0/libgcc/libgcc2.c: In function '__divdi3':
../../../../gcc-7.1.0/libgcc/libgcc2.c:1091:9: internal compiler error: in
emit_move_insn, at expr.c:3698
  d0 = 1 / d0; /* Divide intentionally by zero.  */
  ~~~^~~~
libbacktrace could not find

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

2017-05-23 Thread slyfox at inbox dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #4 from Sergei Trofimovich  ---
Found similar false positive on lxc project.

Original snippet of code:
https://github.com/lxc/lxc/blob/5059aae90584d7d80b3494088920da4ba73e2b2a/src/lxc/cgroups/cgfsng.c#L1379-L1395

Simplified version:

$ cat a.c

#include 

void f(char * p /* NNN\0" */) {
for (int idx = 0; idx < 1000; idx++) {
// guaranteed to be in [0-999] range
snprintf (p, 4, "%d", idx);
}
}

$ gcc -O2 -c a.c -Wall
a.c: In function 'f':
a.c:6:25: warning: '__builtin___snprintf_chk' output may be truncated before
the last format character [-Wformat-truncation=]
 snprintf (p, 4, "%d", idx);
 ^~~~
/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output
between 2 and 5 bytes into a destination of size 4

If I change 1000 to 999
for (int idx = 0; idx < 999; idx++) {
no warning will be issued.

Looks like what happens here is that gcc does not distinct between
idx in the for loop itself that has range of [0-999]
and idx outside for loop, which has value range of [1000-1000].

[Bug c++/80871] New: Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs

2017-05-23 Thread barry.revzin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871

Bug ID: 80871
   Summary: Template partial ordering considered non-ambiguous
with deduced and non-deduced parameter packs
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

#ifdef VARIADIC
template  
constexpr int foo(Us... ) { return 1; }

template  
constexpr int foo(Us... ) { return 2; }
#else
template 
constexpr int foo(U ) { return 1; }

template 
constexpr int foo(U ) { return 2; }
#endif

int main() {
static_assert(foo(1) == 1, "!"); 
}

Without -DVARIADIC, the call to foo(1) is considered ambiguous and the program
fails to compile. But with -DVARIADIC, the program compiles. The call should be
ambiguous, since Ts... does not participate in partial ordering.

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 23 21:39:41 2017
New Revision: 248388

URL: https://gcc.gnu.org/viewcvs?rev=248388&root=gcc&view=rev
Log:
2017-05-23  Paul Thomas  

Backport from trunk
PR fortran/80333
* trans-io.c (nml_get_addr_expr): If we are dealing with class
type data set tmp tree to get that address.
(transfer_namelist_element): Set the array spec to point to the
the class data.

* gfortran.dg/dtio_30.f03: New test.

* list_read.c (nml_read_obj): Compute pointer into class/type
arrays from the nl->dim information. Update it for each iteration
of the loop for the given object.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dtio_30.f03
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/list_read.c

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #6 from Jerry DeLisle  ---
Fixed on 7 and closing.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923

2017-05-23 Thread wschmidt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803

--- Comment #8 from Bill Schmidt  ---
More headaches.  I see the failure as part of "make GOTESTFLAGS=--keep
net/check", as follows:

$ head -c 1000 TEST.log
--- FAIL: TestParseIP (20.94s)
ip_test.go:47: ParseIP("127.0.1.2") = 127.0.1.2, want 
ip_test.go:55: IP.UnmarshalText("127.0.1.2") = 127.0.1.2, , want
?7f0001027f017f0102037f0102037f0102037f0102037f0102037f0102037f010203200148602001006820014860200100683139322e302e322e3100302e302e302e303139322e302e322e31c201302e302e302e30003a3a20010db801230012000120010db80001323030313a6462383a3a310020010db800010001000120010db8000100010001200100010001323030313a3a313a303a303a310020010db80001323030313a6462383a303a303a313a3a20010db8000100012001

But with "LD_LIBRARY_PATH=../../.libs ./a.out -test.run=TestParseIP", this
particular failure mode does not occur (though the tests FAIL):

$ ./a.out -test.run=TestParseIP
--- FAIL: TestParseIP (0.03s)
ip_test.go:47: ParseIP("127.0.1.2") = 127.0.1.2, want 
ip_test.go:55: IP.UnmarshalText("127.0.1.2") = 127.0.1.2, , want

ip_test.go:47: ParseIP("127.0.0.1") = 127.0.0.1, want 
ip_test.go:55: IP.UnmarshalText("127.0.0.1") = 127.0.0.1, , want

ip_test.go:47: ParseIP("127.001.002.003") = 127.1.2.3, want 
ip_test.go:55: IP.UnmarshalText("127.001.002.003") = 127.1.2.3, ,
want 
ip_test.go:47: ParseIP(":::127.1.2.3") = 127.1.2.3, want 
ip_test.go:55: IP.UnmarshalText(":::127.1.2.3") = 127.1.2.3, ,
want 
ip_test.go:47: ParseIP(":::127.001.002.003") = 127.1.2.3, want

ip_test.go:55: IP.UnmarshalText(":::127.001.002.003") = 127.1.2.3,
, want 
ip_test.go:47: ParseIP(":::7f01:0203") = 127.1.2.3, want 
ip_test.go:55: IP.UnmarshalText(":::7f01:0203") = 127.1.2.3, ,
want 
ip_test.go:47: ParseIP("0:0:0:0:::127.1.2.3") = 127.1.2.3, want

ip_test.go:55: IP.UnmarshalText("0:0:0:0:::127.1.2.3") =
127.1.2.3, , want 
ip_test.go:47: ParseIP("0:0:0:0:00::127.1.2.3") = 127.1.2.3,
want 
ip_test.go:55: IP.UnmarshalText("0:0:0:0:00::127.1.2.3") =
127.1.2.3, , want 
ip_test.go:47: ParseIP("0:0:0:0:::127.1.2.3") = 127.1.2.3, want

ip_test.go:55: IP.UnmarshalText("0:0:0:0:::127.1.2.3") = 127.1.2.3,
, want 
ip_test.go:47: ParseIP("2001:4860:0:2001::68") = 2001:4860:0:2001::68,
want 
ip_test.go:55: IP.UnmarshalText("2001:4860:0:2001::68") =
2001:4860:0:2001::68, , want 
ip_test.go:47: ParseIP("2001:4860::2001::::0068") =
2001:4860:0:2001::68, want 
ip_test.go:55:
IP.UnmarshalText("2001:4860::2001::::0068") =
2001:4860:0:2001::68, , want 
FAIL

I don't have any explanation for this...

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

2017-05-23 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-23
 Ever confirmed|0   |1
  Known to fail||7.1.0

--- Comment #5 from Martin Sebor  ---
(In reply to Sergei Trofimovich from comment #4)
> Found similar false positive on lxc project.

Thanks for the test case.  The VRP pass computes the correct range information
for the argument but the range made available outside it via the
get_range_info() function is that of idx_6, not idx_10 below (compile with
-fdump-tree-vrp=/dev/stdout to see the output).  It's possible that this
problem is caused by the same underlying limitation as the one in comment #0. 
Let me confirm this bug on that basis.

Value ranges after VRP:

idx_1: [1, 999]  EQUIVALENCES: { idx_6 } (1 elements)
idx_6: [1, 1000]
idx_10: [0, 999]
.MEM_11: VARYING


Removing basic block 5
f (char * p)
{
  int idx;

   [1.00%]:

   [99.00%]:
  # idx_10 = PHI 
  __builtin_snprintf (p_4(D), 4, "%d", idx_10);
  idx_6 = idx_10 + 1;
  if (idx_6 != 1000)
goto ; [98.99%]
  else
goto ; [1.01%]

   [1.00%]:
  return;

}

[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80741

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 23 22:05:56 2017
New Revision: 248390

URL: https://gcc.gnu.org/viewcvs?rev=248390&root=gcc&view=rev
Log:
2017-05-23  Jerry DeLisle  

Backport from trunk
PR libgfortran/80741
* transfer.c (finalize_transfer): Reset last_char to 'empty'.
* file_pos.c (formatted_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.

* trans-io.c (transfer_namelist_element): Change check from
NULL_TREE to null_pointer_node.

* gfortran.dg/read_4.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/read_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/file_pos.c
branches/gcc-7-branch/libgfortran/io/transfer.c

[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80741

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #10 from Jerry DeLisle  ---
Fixed on 7 and closing

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247923

2017-05-23 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803

--- Comment #9 from Ian Lance Taylor  ---
It's possible that the long output is due to memory corruption from an earlier
test.  The way the test is actually run as part of the larger testsuite is
LD_LIBRARY_PATH=../../.libs ./a.out -test.short

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

2017-05-23 Thread babokin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597

--- Comment #17 from Dmitry Babokin  ---
Yes, it's fix with current trunk.

[Bug c/80868] "Duplicate const" warning emitted in `const typeof(foo) bar;`

2017-05-23 Thread ndesaulniers at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80868

Nick Desaulniers  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #1 from Nick Desaulniers  ---
Other discussions:

LKML: https://patchwork.kernel.org/patch/9693821/
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=723720
LLVM: https://bugs.llvm.org/show_bug.cgi?id=32985

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

2017-05-23 Thread babokin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313

--- Comment #16 from Dmitry Babokin  ---
Here's another test case with a contrary example, where a variable gets pulled
into the braces and it also causes false positive. Transformation is: const1 *
(const2 * var1 - const3 * var2) => const1*const2*var1 - const3*var2;

> cat f.cpp
#include 
signed char var_10 = 77;
long long int var_13 = 1547580415367384384LL;

long foo() {
  long a = -6 *
// 0xbf8a6c24aa342bc0 = -4644781160949077056
   (long(16636733186465668563ULL * var_13 ) -
// 0xd4cdd0f8c2df13cf = -3112602000603278385
long(678280911954875019ULL * var_10));
  return a;
}

int main () {
long a = foo ();
std::cout << a << std::endl;
return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp; ./a.out
f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 -
228867929910118694 cannot be represented in type 'long int'
9193074962074792026

If it's unrelated issue, let me know and I'll file a separate bug for it.

[Bug libfortran/78379] Processor-specific versions for matmul

2017-05-23 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379

--- Comment #33 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #32)
> Created attachment 41406 [details]
> Additional files for the previous patch
> 
> Here are the new files for the patch.

Well I tried to apply the patch and test without using maintainer mode.

Running my tests in the debugger, breaking and dis-assembly shows xmmm
instructions and calls to matmul_vanilla so I think I need to enable maintainer
mode and rebuild, or something is not quite right.

Suggestions?

[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info

2017-05-23 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969

--- Comment #6 from Martin Sebor  ---
I also found the following discussion about what looks like the same problem:

  https://patchwork.ffmpeg.org/patch/3630

[Bug libgcc/80870] ICE building 7.1.0 sh-elf crosscompiler on macOS

2017-05-23 Thread Anders.Montonen at iki dot fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870

Anders Montonen  changed:

   What|Removed |Added

 Target||sh-elf
  Known to work||6.3.0

--- Comment #1 from Anders Montonen  ---
Building GCC 6.3.0 with the same settings works.

[Bug c++/80812] internal compiler error: in build_value_init_noctor, at cp/init.c:483

2017-05-23 Thread jamrial at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812

--- Comment #1 from James Almer  ---
This started with r248153

[Bug c++/80812] [8 Regression] ICE: in build_value_init_noctor, at cp/init.c:483

2017-05-23 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80812

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-24
 CC||trippels at gcc dot gnu.org,
   ||ville at gcc dot gnu.org
Summary|internal compiler error: in |[8 Regression] ICE: in
   |build_value_init_noctor, at |build_value_init_noctor, at
   |cp/init.c:483   |cp/init.c:483
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
trippels@gcc67 ~ % cat foo.ii
struct A;
template  using __bool_constant = A;
template  struct B : __bool_constant<__is_constructible(_Tp)> {};
template  struct C;
template  struct C<_Tp &> { typedef _Tp type; };
template  struct D;
struct F {
  F();
};
template  using __alloc_rebind = F;
struct G {
  template  using rebind_alloc = __alloc_rebind;
};
struct H {
  typedef G::rebind_alloc other;
};
struct I {
  struct : H::other {
  } _M_dataplus;
};
template  struct list;
template  using _t = typename T::type;
template  using bool_ = A;
template  struct _if_;
template  using if_c = _t<_if_>>>;
template  using uncvref_t = _t>;
template  T *_nullptr_v();
template )>
void models_(Concept *);
template 
struct models
: bool_<_t(_nullptr_v()))>::value> {};
template 
auto model_of() -> if_c::valueint>;
struct J {
  template  void requires_(decltype(B{}));
};
struct K {
  template  void requires_(decltype(model_of));
};
template  using View = models;
struct {
  template >())>::type>
  void operator()(T &&);
} all;
void test_iter() {
  using P = I;
  P ia[]{{}};
  all(ia);
}

trippels@gcc67 ~ % g++ -c foo.ii
foo.ii: In instantiation of ‘struct B’:
foo.ii:37:30:   required by substitution of ‘template void models_(Concept*) [with Ts = {I [1]}; Concept = J;
 = ]’
foo.ii:33:39:   required from ‘struct models’
foo.ii:35:6:   required by substitution of ‘template void models_(Concept*) [with Ts = {I [1]}; Concept = K;
 = ]’
foo.ii:33:39:   required from ‘struct models’
foo.ii:44:34:   required by substitution of ‘template
> void::operator()(T&&) [with T = I (&)[1]; int  =
]’
foo.ii:50:9:   required from here
foo.ii:3:32: internal compiler error: in build_value_init_noctor, at
cp/init.c:485

[Bug libfortran/78379] Processor-specific versions for matmul

2017-05-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #41405|0   |1
is obsolete||
  Attachment #41406|0   |1
is obsolete||

--- Comment #34 from Thomas Koenig  ---
Created attachment 41410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41410&action=edit
Patch which has all the files

Well, I suspect my way of splitting the previous patch into
one real patch and one *.tar.gz - file was not really the best way
to go :-)

Here is a patch which should include all the new files.

At least it fits into the 1000 kb limit.