[Bug target/79144] cmpstrnsi optimization breaks glibc

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-19
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Alan Modra  ---
Testing a fix

[Bug target/79145] New: iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[petr.cvek at tul dot cz]

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

Bug ID: 79145
   Summary: iwmmxt: Internal compiler error caused by an
unrecognizable insn, during XORing long long with a
char constant
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petr.cvek at tul dot cz
  Target Milestone: ---

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---

We have two different SSA_NAMEs where their SSA_NAME_INFO is the same pointer. 
Thus modification range info by way of set_range_info changes the underlying
range on both SSA_NAMEs.  From a debugging session:

(gdb) p cfun->gimple_df->ssa_names.m_vecdata[1045].ssa_name.info.range_info
$33 = (range_info_def *) 0x7fffefa4a420
(gdb) p cfun->gimple_df->ssa_names.m_vecdata[938].ssa_name.info.range_info
$34 = (range_info_def *) 0x7fffefa4a420


So to follow how we get to that state.

First ccp_finalize calls set_nonzero_bits on SSA_NAME 938.  That allocates a
hunk of memory and initializes it with the right information.

Then ccp_finalize calls set_nonzero_bits on SSA_NAME 1045.  That allocates
another hunk of memory and initializes it appropriately.

The actual recorded ranges are different -- they differ in nonzero_bits.

So far, so good.  No problems.

Then FRE comes along and decides the two SSA_NAMEs are equal and executes this
code:

 /* Use that from the dominator.  */
  SSA_NAME_RANGE_INFO (to) = SSA_NAME_RANGE_INFO (from);
  SSA_NAME_ANTI_RANGE_P (to) = SSA_NAME_ANTI_RANGE_P (from);



TO is SSA_NAME 1045, FROM is SSA_NAME 938.

At that point we have two distinct SSA_NAMEs with a shared SSA_NAME_RANGE_INFO
pointer.

EVRP then comes along and calls set_range_info on SSA_NAME 1045, which has the
side effect of changing the range info on SSA_NAME 938.  This changes the
nonzero bits associated with SSA_NAME 938 (which ultimately results in
incorrect code starting in a later CCP pass).

Shortly thereafter we release SSA_NAME 1045 because its LHS is going to be
fully propagated away.

And it makes perfect sense why last week'd change to not set range info on
statements marked for removal can cause this bug to go latent.  We avoid the
call to set_range_info on SSA_NAME 1045 and thus don't clobber the nonzero bits
for SSA_NAME 938.

FWIW, knowing that I can diff the .ccp2 dumps to look for evidence of this
issue gave me some hope I could reduce the testcase further without worrying
about still being able to execute the test.  Alas that didn't make any
significant difference -- a few things were removed, but not enough to
significantly simplify the test.

BTW, I don't expect to be online much over the next few days...  Good luck...

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |7.0

[Bug target/79145] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||iwmmxt
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-01-19
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
testcase? which ICE?

[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |6.4
Summary|std::pair p = {};  |[6/7 Regression]
   |fails to compile due to |std::pair p = {};
   |ambiguous overload  |fails to compile due to
   ||ambiguous overload

[Bug c++/79129] [7 Regression] ICE with -fdebug-types-section starting with r240578

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

[Bug target/79145] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[petr.cvek at tul dot cz]

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

Petr Cvek  changed:

   What|Removed |Added

Version|unknown |6.3.0
  Known to fail||6.3.0

--- Comment #2 from Petr Cvek  ---
During buildroot for iwmmxt arch (PXA27x), several sources failed on this
error:

./z32.c: In function ‘main’:
./z32.c:20:1: error: unrecognizable insn:
 }
 ^
(insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ])
(xor:DI (reg:DI 110 [ t1.0_2 ])
(const_int 85 [0x55]))) ./z32.c:13 -1
 (nil))
./z32.c:20:1: internal compiler error: in extract_insn, at recog.c:2287

Testing showed, that the error is caused by using an XOR when one operand is
long long and second is a constant char (or a variable optimized to the
constant). Different operand sizes are OK, using xscale target is OK and doing
XOR manually (by AND, OR and negation) is OK too.

Example program:

#define XOR(x,y) ((x & ! y) | (! x & y ))

int main(void) {

volatile long long t1;

t1 ^= 0x55;//FAILS

t1=XOR(t1,0x55);   //is OK

return 0;
}

GCC was compiled by crosstool-ng, configuration:

# arm-unknown-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-unknown-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/libexec/gcc/arm-unknown-linux-gnueabi/6.3.0/lto-wrapper
Target: arm-unknown-linux-gnueabi
Configured with:
/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/src/gcc-6.3.0/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-unknown-linux-gnueabi
--prefix=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi
--with-sysroot=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG
crosstool-ng-1.22.0-452-gc7b1e295' --enable-__cxa_atexit --enable-libmudflap
--enable-libgomp --enable-libssp --enable-libquadmath
--enable-libquadmath-support --enable-libsanitizer --disable-libmpx
--with-gmp=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpfr=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-mpc=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--with-isl=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix
--enable-target-optspace --enable-plugin
--with-libintl-prefix=/mnt/hd2/home/crossgen/crosstool-ng_arm/.build/arm-unknown-linux-gnueabi/buildtools
--enable-multiarch
--with-local-prefix=/opt/vocore_mips_gcc/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 6.3.0 (crosstool-NG crosstool-ng-1.22.0-452-gc7b1e295) 

P.S. It is highly possible this bug is long time present (at least one/two
years).

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 Ever confirmed|0   |1

--- Comment #17 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #16)
> Thanks for all the feedback. With this patch, it now builds. Is the style of
> change to configure.host OK?

I think the following patch to libgfortran is better. The patch will disable
x87 only when -msoft-float is in effect, as already done in libgcc.

--cut here--
diff --git a/libgfortran/config/fpu-387.h b/libgfortran/config/fpu-387.h
index b219a65..266bf739 100644
--- a/libgfortran/config/fpu-387.h
+++ b/libgfortran/config/fpu-387.h
@@ -23,6 +23,11 @@ a copy of the GCC Runtime Library Exception along with this
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */

+#ifdef _SOFT_FLOAT
+#include "fpu-generic.h"
+
+#else /* !_SOFT_FLOAT */
+
 #ifndef __SSE_MATH__
 #include "cpuid.h"
 #endif
@@ -506,3 +511,4 @@ set_fpu_underflow_mode (int gradual)
   __asm__ __volatile__ ("%vldmxcsr\t%0" : : "m" (cw_sse));
 }

+#endif /* !_SOFT_FLOAT */
--cut here--

[Bug target/79145] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[petr.cvek at tul dot cz]

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

--- Comment #3 from Petr Cvek  ---
Cmdline is of course:

arm-unknown-linux-gnueabi-gcc -mcpu=iwmmxt ./z32.c

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #12 from Richard Biener  ---
Ok, with r235817 and a tiny verifier I can reproduce the sharing.  Will
investigate/fix.  It's gone latent on trunk...

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Ah.

Setting value number of t34_9752(D) to t34_9752(D) (changed)
Setting value number of t42_9760(D) to t42_9760(D) (changed)
WARNING: Giving up with SCCVN due to SCC size 10003 exceeding 1

so we're failing to call scc_vn_restore_ssa_info when we fail this way.  oops.

[Bug c++/79138] ICE when trying to do template auto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-01-19
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started to ICE with r242017, before that the code was rejected.
However, clang 3.9.1 also rejects the code:

clang++ pr79138.cpp -c -std=c++1z
pr79138.cpp:5:11: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:8:11: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:11:11: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:11:23: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:18:11: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:28:11: error: 'auto' not allowed in template parameter
template 
  ^~~~
pr79138.cpp:36:19: error: expected body of lambda expression
[](int i) constexpr { return i%2 == 0; });
  ^
7 errors generated.

[Bug target/79145] [5/6/7 Regression] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |NEW
 CC||ktkachov at gcc dot gnu.org
  Known to work||4.8.5
   Target Milestone|--- |5.5
Summary|iwmmxt: Internal compiler   |[5/6/7 Regression] iwmmxt:
   |error caused by an  |Internal compiler error
   |unrecognizable insn, during |caused by an unrecognizable
   |XORing long long with a |insn, during XORing long
   |char constant   |long with a char constant
  Known to fail||4.9.4, 5.4.1, 7.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Confirmed on 4.9 onwards. 4.8 doesn't ICE.

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

[s_gccbugzilla at nedprod dot com]

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

--- Comment #8 from Niall Douglas  ---
(In reply to Marek Polacek from comment #7)
> I'm giving up; there's just too much C++.

Thanks for looking into it. You should know that the above code works without
issue on clang and VS2017 (with C++ 14 constexpr enabled too!).

In your reduced test case I don't think you're packing the storage and the type
of storage into a single byte. That's what the original does, and appears to be
the cause of the ICE on GCC: use of bitfields in constexpr. It certainly should
not be the case that the constexpr is accessing storage not initialised by
constexpr e.g. a bit 8 when valid bits are 0 ... 7.

Niall

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #32 from Jan Hubicka  ---
Apparently fixed. The coremark is PR77445

[Bug lto/78407] [5/6/7 Regression] LTO breaks separate overriding of symbol aliases

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 19 10:00:56 2017
New Revision: 244612

URL: https://gcc.gnu.org/viewcvs?rev=244612&root=gcc&view=rev
Log:
PR lto/78407
* symtab.c (symtab_node::equal_address_to): Fix comparing of
interposable aliases.

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

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
(In reply to Jeffrey A. Law from comment #12)
> It does raise the question of how long we're going to support -mno-lra on
> PPC.

The plan is to remove it in GCC 8.

[Bug ipa/70582] [6/7 regression] gcc.dg/attr-weakref-1.c FAILs

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #9 from Jan Hubicka  ---
I guess it should no longer be waiting then.  I will try to take a look.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
How does the memory use look with current tree?

[Bug ipa/65654] [8 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0
Summary|[7 Regression] 447.dealII   |[8 Regression] 447.dealII
   |in SPEC CPU 2006 failed to  |in SPEC CPU 2006 failed to
   |build with LTO  |build with LTO

--- Comment #10 from Jan Hubicka  ---
Retaretting to GCC 8. I have verified that the inline metrics is mostly fine
and those roundoff errors cumulating can not be easily fixed without migration
to sreals which I will finally do early next stage1.

[Bug rtl-optimization/79121] [6/7 Regression] invalid expansion of sign-extend unsigned plus left shift

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Jan 19 10:35:38 2017
New Revision: 244613

URL: https://gcc.gnu.org/viewcvs?rev=244613&root=gcc&view=rev
Log:
[expand] Fix for PR rtl-optimization/79121 incorrect expansion of extend
plus left shift

When generating a shift from an extended value moving from one to two
machine registers, the type of the right shift is for the most
significant word should be determined by the signedness of the inner
type, not the signedness of the result type.

gcc:
PR rtl-optimization/79121
* expr.c (expand_expr_real_2, case LSHIFT_EXPR): Look at the signedness
of the inner type when shifting an extended value.

gcc/testsuite:
* gcc.c-torture/execute/pr79121.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr79121.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/79121] [6 Regression] invalid expansion of sign-extend unsigned plus left shift

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

Version|7.0 |6.0
Summary|[6/7 Regression] invalid|[6 Regression] invalid
   |expansion of sign-extend|expansion of sign-extend
   |unsigned plus left shift|unsigned plus left shift

--- Comment #3 from Richard Earnshaw  ---
Fixed on trunk.  Backport to gcc-6 still needed.

[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c

[rai...@emrich-ebersheim.de]

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

--- Comment #13 from Rainer Emrich  ---
The proposed patch indeed fixes the issue on x86_64-w64-mingw32, libgfortran
builds again.

The results of a complete testsuite run can be found here:
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01881.html

Comparing the fortran results to an earlier run yields:

1704,1707c1727,1729
< # of expected passes  43782
< # of unexpected failures  266
< # of expected failures89
< # of unresolved testcases 1
---
> # of expected passes  44069
> # of unexpected failures  267
> # of expected failures92

IMHO that's fine.

[Bug c++/79129] [7 Regression] ICE with -fdebug-types-section starting with r240578

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rtl-optimization/78580] [6 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*

[bugs-gcc at rationality dot eu]

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

bugs-gcc at rationality dot eu changed:

   What|Removed |Added

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

--- Comment #7 from bugs-gcc at rationality dot eu ---
Thanks for fixing

[Bug target/79145] [5/6/7 Regression] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
I'm testing a simple fix.

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 19 12:00:42 2017
New Revision: 244623

URL: https://gcc.gnu.org/viewcvs?rev=244623&root=gcc&view=rev
Log:
2017-01-19  Richard Biener  

PR tree-optimization/72488
* tree-ssa-sccvn.c (run_scc_vn): When we abort the VN make
sure to restore SSA info.
* tree-ssa.c (verify_ssa): Verify SSA info is not shared.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa.c

[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Bug 72488 Summary: [7 Regression] wrong code (SIGFPE) at -Os and above on 
x86_64-linux-gnu (in the 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488

   What|Removed |Added

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

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 19 12:02:43 2017
New Revision: 244625

URL: https://gcc.gnu.org/viewcvs?rev=244625&root=gcc&view=rev
Log:
2017-01-19  Richard Biener  

PR tree-optimization/72488
* tree-ssa-sccvn.c (run_scc_vn): When we abort the VN make
sure to restore SSA info.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-sccvn.c

[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |6.4

--- Comment #16 from Richard Biener  ---
Fixed on trunk and branch.

[Bug c++/78495] [7 regression][new inheriting ctors] variant members lead to uninitialized parameter

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 40543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40543&action=edit
reduced testcase

The problem is not with unnamed union members, but with inheriting ctors
passing by value.  The temporary 'Ptr' object is passed by implicit reference,
but in the inheriting ctor we pass the address of that reference to the Base
ctor.   In this case that means we end up initializing Base::val with a pointer
into the stack frame, rather than NULL.

Note the original testcase has a typo ': val(static_cast(val))' --
the ctor parm and the member variable have the same name, so that's doing self
initialization -- not copying the incoming parm. (not that that;s the bug being
exposed).

[Bug other/79046] g++ -print-file-name=plugin uses full version number in path

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 19 12:23:00 2017
New Revision: 244627

URL: https://gcc.gnu.org/viewcvs?rev=244627&root=gcc&view=rev
Log:
PR other/79046
* aclocal.m4: Include ../config/acx.m4.
* configure: Regenerated.
* Makefile.in: Regenerated.
* mpxrt/Makefile.in: Regenerated.
* mpxwrap/Makefile.in: Regenerated.

Modified:
trunk/libmpx/ChangeLog
trunk/libmpx/Makefile.in
trunk/libmpx/aclocal.m4
trunk/libmpx/configure
trunk/libmpx/mpxrt/Makefile.in
trunk/libmpx/mpxwrap/Makefile.in

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
It's still reproducible with current trunk, it's over 1GB on my development
machine. I did a simple script that dumps sizes of all LTO object loaded to
WPA:

GCC 7:
asm : 19.67 KB
profile : 31.76 KB
pureconst   : 1.08 MB
refs: 1.66 MB
icf : 2.44 MB
inline  : 7.05 MB
symbol_nodes: 13.63 MB
jmpfuncs: 14.98 MB
symtab  : 59.27 MB
decls   : 287.71 MB
symbols : 564.43 MB
total   : 952.31 MB

Total symbols: 505244

GCC 6:
./parse-lto.py /tmp/6.txt
asm : 19.66 KB
profile : 34.56 KB
pureconst   : 1.09 MB
refs: 1.67 MB
icf : 2.43 MB
inline  : 7.03 MB
jmpfuncs: 10.30 MB
symbol_nodes: 13.66 MB
symtab  : 59.89 MB
decls   : 284.59 MB
symbols : 559.50 MB
total   : 940.21 MB

Total symbols: 503275

Thus I guess there's no difference in amount of streamed data.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
Created attachment 40544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40544&action=edit
GCC 6 graph

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
Created attachment 40545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40545&action=edit
GCC 7 graph

[Bug rtl-optimization/79125] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #4 from Bernd Schmidt  ---
Actually just the same approach we used for the global pass ought to just work.
Watch for conditional traps turning into unconditional ones, put those in a
vec, split basic blocks later for every element in the vec.

[Bug go/79146] New: Bootstrpping go on s390x fails; redefined symbols

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79146
   Summary: Bootstrpping go on s390x fails; redefined symbols
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com, krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390x
Target: s390x

Bootstrapping on s390x fails with these errors:

.../gcc/libgo/go/crypto/elliptic/p256_s390x.go:24:2: error: redefinition of
‘p256’
  p256Curve
  ^
.../libgo/go/crypto/elliptic/p256_generic.go:10:2: note: previous definition of
‘p256’ was here
  p256 p256Curve
  ^
.../libgo/go/crypto/elliptic/p256_s390x.go:34:1: error: redefinition of
‘initP256Arch’
 func initP256Arch() {
 ^
.../libgo/go/crypto/elliptic/p256_generic.go:13:1: note: previous definition of
‘initP256Arch’ was here
 func initP256Arch() {
 ^
.../libgo/go/crypto/elliptic/p256_s390x.go:36:8: error: incompatible types in
assignment (cannot use type p256CurveFast as type p256Curve)
   p256 = p256CurveFast{p256Params}
^

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||kuganv at linaro dot org

--- Comment #19 from Jan Hubicka  ---
Looking into detailed mem reports we have increase in jump functions size:
ipa-prop.c:4701 (ipa_read_node_info)  0:  0.0%  47378288: 
2.4% 161144168:  6.7%  20010080: 11.8%   1238962
to
ipa-prop.c:5047 (ipa_read_node_info)  0:  0.0%  74541136:  
3.1% 567308480: 17.9%  13645376:  7.0%   1238212

So while we read about same number of jump functions, the memory usage almost
triples.  The reason is that jump function got a lot bigger now:

  /* Information about zero/non-zero bits.  */  
  struct ipa_bits bits; 

  /* Information about value range, containing valid data only when vr_known is 
 true.  */  
  value_range m_vr; 
  bool vr_known;

where

/* Information about zero/non-zero bits.  */
struct GTY(()) ipa_bits
{
  /* The propagated value.  */
  widest_int value;
  /* Mask corresponding to the value.
 Similar to ccp_lattice_t, if xth bit of mask is 0,
 implies xth bit of value is constant.  */
  widest_int mask;
  /* True if jump function is known.  */
  bool known;
};

/* Info about value ranges.  */
struct GTY(()) ipa_vr
{
  /* The data fields below are valid only if known is true.  */
  bool known;
  enum value_range_type type;
  wide_int min;
  wide_int max;
};

I think two wide_ints and two widest_ints are major offenders.  We need to find
a way to avoid allocating them for all nodes.  Perhaps implement sharing of
equal ipa_bits and ipa_vr records?

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

--- Comment #33 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #32)
> Apparently fixed. The coremark is PR77445

Yes, my SPEC2006 results look good, no real change. Coremark is now up by 20%
or more, thanks for that :-)

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
As reported in PR77484, coremark is now up by 20% or more.
Are we out of regression land now? If not does the patch in #15 help?

[Bug c++/79130] [C++17] FI20 change vs. direct initialization

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Jan 19 14:37:51 2017
New Revision: 244635

URL: https://gcc.gnu.org/viewcvs?rev=244635&root=gcc&view=rev
Log:
PR c++/79130 - decomposition and direct-initialization

* init.c (build_aggr_init): Communicate direct-initialization to
build_vec_init.
(build_vec_init): Check for array copy sooner.
* parser.c (cp_parser_decomposition_declaration): Remove call to
build_x_compound_expr_from_list.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/cpp1z/decomp6.C

[Bug ipa/71190] [7 Regression] ICE in assemble_variable_contents, at varasm.c:2054

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Ok, it's caused by IPA CP, will be fixed by:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00609.html

[Bug libstdc++/79147] New: Uselsss _GLIBCXX_PACKAGE_* macros in

[redi at gcc dot gnu.org]

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

Bug ID: 79147
   Summary: Uselsss _GLIBCXX_PACKAGE_* macros in

   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The libstdc++ headers define these macros:

/* Define to the address where bug reports for this package should be sent. */
#define _GLIBCXX_PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define _GLIBCXX_PACKAGE_NAME "package-unused"

/* Define to the full name and version of this package. */
#define _GLIBCXX_PACKAGE_STRING "package-unused version-unused"

/* Define to the one symbol short name of this package. */
#define _GLIBCXX_PACKAGE_TARNAME "libstdc++"

/* Define to the version of this package. */
#define _GLIBCXX_PACKAGE__GLIBCXX_VERSION "version-unused"

These are all pretty useless, but the last one is particularly silly. It should
probably by _GLIBCXX_PACKAGE_VERSION, but the sed rule in include/Makefile.am
modifies it twice:

sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
-e '/[   ]_GLIBCXX_LONG_DOUBLE_COMPAT[   ]/d' \
< ${CONFIG_HEADER} >> $@ ;\

If we did s/PACKAGE_/_GLIBCXX_PACKAGE_/ instead then it would give a more
sensible result.

We should also consider replacing this whole thing with something based on
AX_PREFIX_CONFIG_H instead, so everything in the auto-generated config.h gets

[Bug libstdc++/79147] Uselsss _GLIBCXX_PACKAGE_* macros in

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> We should also consider replacing this whole thing with something based on
> AX_PREFIX_CONFIG_H instead, so everything in the auto-generated config.h gets

... automatically prefixed.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
Look at tree-ssanames.c:range_info_def for "tricks" (make them variable size):

/* Value range information for SSA_NAMEs representing non-pointer variables. 
*/

struct GTY ((variable_size)) range_info_def {
  /* Minimum, maximum and nonzero bits.  */
  TRAILING_WIDE_INT_ACCESSOR (min, ints, 0)
  TRAILING_WIDE_INT_ACCESSOR (max, ints, 1)
  TRAILING_WIDE_INT_ACCESSOR (nonzero_bits, ints, 2)
  trailing_wide_ints <3> ints;
};

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |7.0
Summary|Bootstrpping go on s390x|[7 Regression]
   |fails; redefined symbols|Bootstrapping go on s390x
   ||fails; redefined symbols

[Bug middle-end/44440] [5/6/7 regression] ira_initialization and buitins construction taking too much of startup time

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Now I get (for 500 invocations)
   real   user  sys
 GCC 7:0m9.816s   0m6.274s  0m3.546s
 GCC 6:0m7.880s   0m4.253s  0m3.605s
 GCC 5:0m7.655s   0m4.264s  0m3.159s
 GCC 4.6:  0m7.271s   0m4.094s  0m3.085s

We used to lazilly initialize regalloc cost tables before IRA was merged. I
think it contributes to major part of the slowdown.

Note that newly, in addition to the regclass cost, we do fair amount of
software simulated multiplies and divides

   4.59%  cc1  cc1[.] do_multiply   
   3.11%  cc1  [kernel.kallsyms]  [k] clear_page
   3.01%  cc1  libc-2.19.so   [.] memset
   2.86%  cc1  cc1[.] ggc_internal_alloc
   2.83%  cc1  [kernel.kallsyms]  [k] page_fault
   2.79%  cc1  [kernel.kallsyms]  [k] filemap_map_pages 
   2.45%  cc1  cc1[.] init_reg_sets_1   
   2.22%  cc1  cc1[.] do_add
   2.18%  cc1  libc-2.19.so   [.] __GI___strcmp_ssse3   
   2.02%  cc1  cc1[.] ht_lookup_with_hash   
   1.85%  cc1  cc1[.] do_divide 
   1.49%  cc1  cc1[.] hash_table::find_with_hash
   1.41%  cc1  [kernel.kallsyms]  [k] unmap_single_vma  
   1.37%  cc1  [kernel.kallsyms]  [k] release_pages 
   1.29%  cc1  cc1[.] decl_attributes   
   1.21%  cc1  libc-2.19.so   [.] _int_malloc   
   1.19%  cc1  libc-2.19.so   [.] strlen
   1.12%  cc1  cc1[.] normalize

[Bug rtl-optimization/79148] New: stack addresses are spilled to stack slots on x86-64 at -Os instead of rematerializing the addresses

[froydnj at gcc dot gnu.org]

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

Bug ID: 79148
   Summary: stack addresses are spilled to stack slots on x86-64
at -Os instead of rematerializing the addresses
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: froydnj at gcc dot gnu.org
  Target Milestone: ---

Noticed this while browsing around Firefox source code compiled with GCC 5.4; a
colleague confirms that this happens with 6.3 as well.  Compiling:

https://people.mozilla.org/~nfroyd/Unified_cpp_widget0.ii.gz

(Tried to get it under the attachment limit with xz, didn't happen)

with options:

-mtune=generic -march=x86-64 -g -Os -std=gnu++11 -fPIC -fno-strict-aliasing
-fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-freorder-blocks -fno-omit-frame-pointer -fstack-protector-strong

gives, for the function
_ZN7mozilla6widget11GfxInfoBase20GetFeatureStatusImplEiPiR18nsAString_internalRK8nsTArrayINS0_13GfxDriverInfoEER19nsACString_internalPNS0_15OperatingSystemE
a bit of code that looks like:

.LVL3402:
leaq-784(%rbp), %rax  [1a]
.LVL3403:
movq%rax, %rdi
.LVL3404:
movq%rax, -816(%rbp)  [1b]
call_ZN12nsAutoStringC1Ev
.LVL3405:
.loc 14 887 0
leaq-624(%rbp), %rax  [2a]
movq%rax, %rdi
movq%rax, -824(%rbp)  [2b]
call_ZN12nsAutoStringC1Ev
.LVL3406:
.loc 14 888 0
leaq-464(%rbp), %rax  [3a]
movq%rax, %rdi
movq%rax, -800(%rbp)  [3b]
call_ZN12nsAutoStringC1Ev
.LVL3407:
.loc 14 889 0
movq(%r12), %rax
movq-816(%rbp), %rsi  [1c]
movq%r12, %rdi
call*104(%rax)
.LVL3408:
.loc 14 890 0
testl   %eax, %eax
js  .L2479
movq(%r12), %rax
movq-824(%rbp), %rsi  [2c]
movq%r12, %rdi
call*120(%rax)
.LVL3409:
.loc 14 889 0
testl   %eax, %eax
js  .L2479
.loc 14 891 0
movq(%r12), %rax
movq-800(%rbp), %rsi  [3c]
movq%r12, %rdi
call*168(%rax)

The problem here, for each of the trio of instructions marked [1], [2], and
[3], is that the instructions [1b], [2b], and [3b] that store the stack
addresses are really unnecessary; replacing [1c], [2c], and [3c] with the `lea`
instructions from [1a], [2a], and [3a] is the same size and doesn't require the
stack slot storage, so we could eliminate those instructions ([1b], [2b], and
[3b]) and (possibly) make the stack frame smaller as well.

I think rematerializing the stack addresses on x86/x86-64 ought always to be a
win in terms of size (I don't know whether you'd want to make the same choices
when compiling for speed); I think it'd be a similar win for RISC-y chips, at
least so long as the stack frame sizes are reasonably small.

[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #5 from Bill Schmidt  ---
Work is complete.

[Bug rtl-optimization/79149] New: bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[arnd at linaro dot org]

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

Bug ID: 79149
   Summary: bad optimization on MIPS and ARM leading to excessive
stack usage in some cases
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 40546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40546&action=edit
compressed preprocessed source for wp512 crypto from linux kernel

Build-testing the Linux kernel on MIPS shows warnings about possible kernel
stack overflow in the kernel's crypto libraries, in particular the wp512
algorithm, as the stack frame grows beyond the normal per-function limit of
1024 bytes we use in the kernel.

I have been able to avoid the problem by turning off two specific
optimizations,
and I have reproduced the same thing with both gcc-4.9 and gcc-7.0:

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-7.0.0 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 1128 bytes is larger
than 100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-7.0.0 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 304 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-4.9.3 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 1096 bytes is larger
than 100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/mips-linux-gcc-4.9.3 -fno-strict-aliasing -O2 -c
-Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic 
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 272 bytes is larger than
100 bytes [-Wframe-larger-than=]

To cross-check the problem, I have tried compiling the same file on ARM, which
shows similar results but stays below the warning limit:

/home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.0 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 816 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.0 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i 
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 344 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-4.9.3 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 840 bytes is larger than
100 bytes [-Wframe-larger-than=]

$ /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-4.9.3 -fno-strict-aliasing -O2
-c -Wall -Wframe-larger-than=100 -Wno-pointer-sign  wp512.i  
-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic
../../crypto/wp512.c: In function 'wp512_process_buffer':
../../crypto/wp512.c:987:1: warning: the frame size of 376 bytes is larger than
100 bytes [-Wframe-larger-than=]

However, using an x86 compiler, the frame for the same source is always under
300 bytes, and the options have no effect.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #18 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
> 

> +#ifdef _SOFT_FLOAT
> +#include "fpu-generic.h"
> +
This seems like a good solution but the build can't find fpu-generic.h

In file included from ../../../../gcc/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h:27:25: fatal error: fpu-generic.h: No such file or directory
 #include "fpu-generic.h"

I changed that line to 

#ifdef _SOFT_FLOAT
#include "config/fpu-generic.h"

and it built. Is that OK?

[Bug target/79127] [7 Regression] Error: invalid register for .seh_savexmm in matmul_i4.c

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 19 15:41:15 2017
New Revision: 244636

URL: https://gcc.gnu.org/viewcvs?rev=244636&root=gcc&view=rev
Log:
PR target/79127
* acinclude.m4 (LIBGFOR_CHECK_AVX512F): Ensure the test clobbers
some zmm16+ registers to verify they are handled by unwind info
properly if needed.
* configure: Regenerated.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure

[Bug target/79144] cmpstrnsi optimization breaks glibc

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Alan,
  Thanks for jumping in here. What I tried yesterday was this code to try to
get the correct name:

+ const char *id =
+   IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
+   (builtin_decl_explicit (BUILT_IN_STRCMP)));
+ if (id == NULL || *id == 0)
+   id = "strcmp";
+ else if (*id == '*')
+   id++;
+ emit_library_call_value (gen_rtx_SYMBOL_REF (Pmode, id),
+  target, LCT_NORMAL, GET_MODE (target), 2,
+  force_reg (Pmode, XEXP (src1, 0)), Pmode,
+  force_reg (Pmode, XEXP (src2, 0)), Pmode);

But this didn't work for reasons I don't quite understand.

The other discussion of this starts here on gcc-patches:

https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00843.html

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
Looking at distinct number of value ranges and bits, we can get:

grep hash_vr /tmp/7.dump.ipa | sort | uniq -c | wc -l
65224

grep hash_bits /tmp/7.dump.ipa | sort | uniq -c | wc -l
13421

Where total # of jump functions at the end of WPA is 3258685.

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[vehre at gcc dot gnu.org]

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

--- Comment #12 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Thu Jan 19 15:52:32 2017
New Revision: 244637

URL: https://gcc.gnu.org/viewcvs?rev=244637&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2017-01-19  Andre Vehreschild  

PR fortran/70696
* trans-decl.c (gfc_build_qualified_array): Add static decl to parent
function only, when the decl-context is not the translation unit.

gcc/testsuite/ChangeLog:

2017-01-19  Andre Vehreschild  

PR fortran/70696
* gfortran.dg/coarray_43.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/coarray_43.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71648] C++ ICE on ppc64 with -m64

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
This appears to be fixed on trunk -- between David and me we've tested this on
AIX 32- and 64-bit, PPC64LE on P8, and PPC64 on P7.  We'll need to bisect and
see what fixed the problem and work on a backport for GCC 6.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #9 from Rainer Orth  ---
(In reply to Martin Sebor from comment #7)

Unfortunately, that change is still wrong and causes failures on e.g.
i386-pc-solaris2.12 and
i686-pc-linux-gnu:


Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:142:3:
warning: argument 1 range [1236, 2147483647] exceeds maximum object size 1234
[-Walloc-size-larger-than=]

If you match __i386__ in the #if, you need to do the same in the target
selector,
as in the attached patch.

Tested with the appropriate runtest invocation on i386-pc-solaris2.12 and
amd64-pc-solaris2.12.

  Rainer

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #19 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #18)
> I changed that line to 
> 
> #ifdef _SOFT_FLOAT
> #include "config/fpu-generic.h"
> 
> and it built. Is that OK?

Yes.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #22 from Martin Liška  ---
Btw. sizeof(value_range) == 32 and sizeof(ipa_bits) == 88 on a x86_64 machine.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  ---
Created attachment 40547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40547&action=edit
proposed patch

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[mpf at gcc dot gnu.org]

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

--- Comment #14 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Thu Jan 19 16:05:59 2017
New Revision: 244640

URL: https://gcc.gnu.org/viewcvs?rev=244640&root=gcc&view=rev
Log:
MIPS: PR target/78176 add -mlxc1-sxc1.

gcc/

PR target/78176
* config.gcc (supported_defaults): Add lxc1-sxc1.
(with_lxc1_sxc1): Add validation.
(all_defaults): Add lxc1-sxc1.
* config/mips/mips.opt (mlxc1-sxc1): New option.
* gcc/config/mips/mips.h (OPTION_DEFAULT_SPECS): Add a default for
mlxc1-sxc1.
(TARGET_CPU_CPP_BUILTINS): Add builtin_define for
__mips_no_lxc1_sxc1.
(ISA_HAS_LXC1_SXC1): Gate with mips_lxc1_sxc1.
* gcc/doc/invoke.texi (-mlxc1-sxc1): Document the new option.
* doc/install.texi (--with-lxc1-sxc1): Document the new option.

gcc/testsuite/

* gcc.target/mips/lxc1-sxc1-1.c: New file.
* gcc.target/mips/lxc1-sxc1-2.c: Likewise.
* gcc.target/mips/mips.exp (mips_option_groups): Add ghost option
HAS_LXC1.
(mips_option_groups): Add -m[no-]lxc1-sxc1.
(mips-dg-init): Detect default -mno-lxc1-sxc1.
(mips-dg-options): Handle HAS_LXC1 arch upgrade/downgrade.

Added:
trunk/gcc/testsuite/gcc.target/mips/lxc1-sxc1-1.c
trunk/gcc/testsuite/gcc.target/mips/lxc1-sxc1-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/mips/mips.h
trunk/gcc/config/mips/mips.opt
trunk/gcc/doc/install.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/mips.exp

[Bug tree-optimization/71264] [5 Regression] ICE in convert_move

[ro at gcc dot gnu.org]

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

--- Comment #23 from Rainer Orth  ---
(In reply to rguent...@suse.de from comment #22)
> On Mon, 24 Oct 2016, ebotcazou at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71264
> > 
> > --- Comment #21 from Eric Botcazou  ---
> > > It is supposed to be vectorized on targets w/o V4QImode support.
> > > Not sure if the list of targets that FAIL the testcase would be smaller
> > > if I change the scan to an explicit list of targets (x86)?
> > 
> > Not sure indeed, it passes on PowerPC & PowerPC64 too for example.
> > 
> > > Meanwhile just add more targets to the xfail -- it really is a missed
> > > optimization as I guess for example arm also has V4SImode.
> > 
> > There is no XFAIL currently but we can certainly add one.
> 
> Ah, right ... my tree has local changes:
> 
> Index: gcc/testsuite/gcc.dg/vect/pr71264.c
> ===
> --- gcc/testsuite/gcc.dg/vect/pr71264.c (revision 241395)
> +++ gcc/testsuite/gcc.dg/vect/pr71264.c (working copy)
> @@ -7,6 +7,8 @@ typedef uint8_t footype __attribute__((v
>  void test(uint8_t *ptr, uint8_t *mask)
>  {
>footype mv;
> +  ptr = __builtin_assume_aligned (ptr, __alignof__ (footype));
> +  mask = __builtin_assume_aligned (mask, __alignof__ (footype));
>__builtin_memcpy(&mv, mask, sizeof(mv));
>for (unsigned i = 0; i < 16; i += 4)
>  {
> @@ -17,4 +19,4 @@ void test(uint8_t *ptr, uint8_t *mask)
>  }
>  }
>  
> -/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } 
> } */
> +/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { 
> xfail sparc*-*-* } } } */

Shouldn't this patch be applied then?

  Rainer

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
Depending on memory layout of the structure, but these 2 structures increase
memory of about ((32+88)*3258685)/(1024**2) ~372 MB.

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
Created attachment 40548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40548&action=edit
GCC 6 -fmem-report

[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
Created attachment 40549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40549&action=edit
GCC 7 -fmem-report

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 16:40:46 2017
New Revision: 244642

URL: https://gcc.gnu.org/viewcvs?rev=244642&root=gcc&view=rev
Log:
PR78905 define _GLIBCXX_RELEASE macro

PR libstdc++/78905
* doc/xml/manual/abi.xml (abi.versioning.history): Add markup to
macro names, filenames, and literal values. Document _GLIBCXX_RELEASE.
Document that the deprecated _GLIBCXX_VERSION macro was removed for
the 4.0.0 release.
* doc/html/*: Regenerate.
* include/Makefile.am (_GLIBCXX_RELEASE): Set value.
* include/Makefile.in: Regenerate.
* include/bits/c++config (_GLIBCXX_RELEASE): Add #define.
* testsuite/ext/profile/mutex_extensions_neg.cc: Use lineno of 0 in
dg-error.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/manual/abi.html
trunk/libstdc++-v3/doc/xml/manual/abi.xml
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc

[Bug target/71648] C++ ICE on ppc64 with -m64

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
This actually appears to be fixed in GCC 6 as well, so the fix must have been
backported.  Konstantinos, can you please try with GCC 6.3 and confirm that the
problem goes away for you?

Thanks,
Bill

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Thanks.  The patch looks good to me.  You should be able to commit the patch
without approval.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has, i.e.
the GCC major version, as an integer constant, but defined by the library
headers not the compiler).

If that macro is present you have a version of libstdc++ that provides a
working . To be really sure you could check it's defined to a value >=
5, in order to handle (hypothetical) unofficial 4.7 or 4.8 builds that have the
patch backported.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Matt Clarkson from comment #2)
> Because wehen I compile with clang against the libstdc++ the problem will
> still occur and __GNUC__ will not be defined.

N.B. Clang does define __GNUC__ but it always defines it to 4 (and defines
__GNUC_MINOR__ to 1 and __GNUC_PATCHLEVEL__ to 2, because it identifies as GCC
4.1.2, the last release Apple shipped for their OS).

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
The changes in r244150 turned some internal copies into moves, improving the PR
70898 testcase from 61 seconds to 29 seconds.

If I modify the testcase attached here to track moves as well as copies, GCC 6
prints:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 4 + 0
After 3 calls to push: 16 + 0
After 3 calls to pop : 33 + 0

Since r244150 GCC 7 trunk prints:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 2 + 2
After 3 calls to push: 8 + 8
After 3 calls to pop : 17 + 16

I'm testing a patch that reduces the PR 70898 test to under 4s and makes the
attachment here print:

Printing counts of numbers of calls to comparator copy + move constructors.
Before queue construction: 0 + 0
After queue construction : 1 + 3
After 3 calls to push: 4 + 12
After 3 calls to pop : 7 + 26

This doesn't help if your comparison function is only copyable and not movable,
but it's 2017 not 2007 so I think that's OK.

[Bug target/78478] Compile Error for i386-rtems

[joel at gcc dot gnu.org]

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

--- Comment #20 from Joel Sherrill  ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to 
> > 
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> > 
> > and it built. Is that OK?
> 
> Yes.

Looks like it works, Thanks.

Based on my testing,  these need to be applied to both the gcc 6 branch and
master. Should I just commit them with the PR noted or do they need to go
through gcc-patches first?

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at gcc dot gnu.org]

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

--- Comment #12 from Rainer Orth  ---
Author: ro
Date: Thu Jan 19 17:42:50 2017
New Revision: 244647

URL: https://gcc.gnu.org/viewcvs?rev=244647&root=gcc&view=rev
Log:
Fix gcc.dg/attr-alloc_size-4.c on i?86 (PR testsuite/79051)

PR testsuite/79051
* gcc.dg/attr-alloc_size-4.c (test_int_range) [__i386__ ||
__x86_64__]: Allow for target i?86-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c

[Bug target/77455] [AArch64] eh_return implementation fails

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from wilco at gcc dot gnu.org ---
Fixed on trunk in r244547:

This patch simplifies the handling of EH return.  We force the use of the
frame pointer so the return location is always at FP + 8.  This means we
can emit a simple volatile access in EH_RETURN_HANDLER_RTX without needing md
patterns, splitters and frame offset calculations.  The new implementation also
fixes various bugs in aarch64_final_eh_return_addr, which does not work with
-fomit-frame-pointer, alloca or outgoing arguments.

gcc/
* config/aarch64/aarch64.md (eh_return): Remove pattern and splitter.
* config/aarch64/aarch64.h (AARCH64_EH_STACKADJ_REGNUM): Remove.
(EH_RETURN_HANDLER_RTX): New define.
* config/aarch64/aarch64.c (aarch64_frame_pointer_required):
Force frame pointer in EH return functions.
(aarch64_expand_epilogue): Add barrier for eh_return.
(aarch64_final_eh_return_addr): Remove.
(aarch64_eh_return_handler_rtx): New function.
* config/aarch64/aarch64-protos.h (aarch64_final_eh_return_addr):
Remove.
(aarch64_eh_return_handler_rtx): New prototype.

testsuite/
* gcc.target/aarch64/eh_return.c: New test.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Martin Sebor  ---
> Thanks.  The patch looks good to me.  You should be able to commit the patch
> without approval.

Indeed, done.

Rainer

[Bug rtl-optimization/79150] New: ICE: in commit_one_edge_insertion, at cfgrtl.c:2077 for the gcc.dg/pr77834.c test

[toma.tabacu at imgtec dot com]

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

Bug ID: 79150
   Summary: ICE: in commit_one_edge_insertion, at cfgrtl.c:2077
for the gcc.dg/pr77834.c test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toma.tabacu at imgtec dot com
  Target Milestone: ---

gcc.dg/pr77834.c has been failing on mips-mti-elf and mips-mti-linux-gnu with
the default options since around 7 November (I haven't checked, but I assume
it's since it was committed) with the following ICE:

gcc/gcc/testsuite/gcc.dg/pr77834.c: In function ‘foo’:
gcc/gcc/testsuite/gcc.dg/pr77834.c:18:1: internal compiler error: in
commit_one_edge_insertion, at cfgrtl.c:2077
 }
 ^
0x8e76c4 commit_one_edge_insertion(edge_def*)
gcc/gcc/cfgrtl.c:2077
0x8c7665 execute
gcc/gcc/cfgexpand.c:6430
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Here's the compiler version:

$ ~/obj-mips-mti-linux-gnu/gcc/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=~/obj-mips-mti-linux-gnu/gcc/gcc/xgcc
Target: mips-mti-linux-gnu
Configured with: ~/src/gcc/configure CFLAGS='-O0 -g3' CXXFLAGS='-O0 -g3'
--prefix=~/install-mips-mti-linux-gnu --disable-multilib
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-libssp
--disable-libmudflap --disable-decimal-float --with-mips-plt
--target=mips-mti-linux-gnu --enable-languages=c,c++,fortran
--with-sysroot=~/install-mips-mti-linux-gnu/sysroot --enable-__cxa_atexit
--enable-checking=all
Thread model: posix
gcc version 7.0.0 20170119 (experimental) (GCC) 

I've looked into this a little, but I'd appreciate some help.
Sorry for being so late in reporting this.

[Bug c++/62161] more precise locations for command-line diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Given that the driver takes the user-supplied command line and uses it to
invoke cc1 etc, the command-line seen by cc1 doesn't bear a simple relationship
to the one the user provided.

So I don't know if there's a good way to implement this.

Notes:

c-opts.c:c_finish_options creates the  linemap by calling:

1381  cb_file_change (parse_in,
1382  linemap_check_ordinary (linemap_add (line_table,
LC_RENAME, 0,
1383  
_(""), 0)));

[Bug tree-optimization/79151] New: Missed vectorization with identical formulas

[tkoenig at gcc dot gnu.org]

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

Bug ID: 79151
   Summary: Missed vectorization with identical formulas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Consider the following code. The function "scalar" contains two formulas in a
function which are identical, except for the coefficients which
differ.

This could be vectorized.  As an example of how this could be done,
see the function "vector" where vectorization intrinsics are used.

You will see that "vector" is much shorter; all the operations are
done using vector intrinsics.

This is for x86_64-pc-linux-gnu.

#include 

void scalar(const double *restrict a, const double *restrict b,
double x, double *ar, double *br)
{
  double ra, rb;
  int i;

  ra = a[0] + a[1]/x - 1.0/(a[0]-a[1]);
  rb = b[0] + b[1]/x - 1.0/(b[0]-b[1]);

  *ar = ra;
  *br = rb;
}

void vector(const double *restrict a, const double *restrict b,
double x, double *ar, double *br)
{
  typedef double v2do __attribute__((vector_size (16)));
  v2do c0, c1, r;

  c0[0] = a[0];
  c0[1] = b[0];
  c1[0] = a[1];
  c1[1] = b[1];

  r = c0 + c1/x - 1.0/(c0-c1);
  *ar = r[0];
  *br = r[1];
}

double a[] = {1.0, -1.5};
double b[] = {1.3, -1.2};

int main()
{
  double x = 1.24;
  double ar, br;

  scalar(a, b, x, &ar, &br);
  printf("%f %f\n", ar, br);
  vector(a, b, x, &ar, &br);
  printf("%f %f\n", ar, br);

  return 0;
}

Assembly for the function "scalar":

scalar:
.LFB11:
.cfi_startproc
movsd   8(%rdi), %xmm4
movsd   8(%rsi), %xmm5
movapd  %xmm4, %xmm1
movsd   (%rdi), %xmm2
movapd  %xmm5, %xmm7
divsd   %xmm0, %xmm1
divsd   %xmm0, %xmm7
addsd   %xmm2, %xmm1
subsd   %xmm4, %xmm2
movapd  %xmm2, %xmm4
movsd   (%rsi), %xmm3
movsd   .LC0(%rip), %xmm2
movapd  %xmm7, %xmm0
movapd  %xmm2, %xmm6
addsd   %xmm3, %xmm0
subsd   %xmm5, %xmm3
divsd   %xmm4, %xmm6
divsd   %xmm3, %xmm2
subsd   %xmm6, %xmm1
movsd   %xmm1, (%rdx)
subsd   %xmm2, %xmm0
movsd   %xmm0, (%rcx)
ret

Assembly for the function "vector":

vector:
.LFB12:
.cfi_startproc
movsd   8(%rsi), %xmm2
movsd   8(%rdi), %xmm3
unpcklpd%xmm0, %xmm0
unpcklpd%xmm2, %xmm3
movapd  .LC1(%rip), %xmm2
movsd   (%rdi), %xmm1
movapd  %xmm3, %xmm4
movhpd  (%rsi), %xmm1
divpd   %xmm0, %xmm4
movapd  %xmm4, %xmm0
addpd   %xmm1, %xmm0
subpd   %xmm3, %xmm1
divpd   %xmm1, %xmm2
addpd   %xmm2, %xmm0
movlpd  %xmm0, (%rdx)
movhpd  %xmm0, (%rcx)
ret

[Bug c++/79130] [C++17] FI20 change vs. direct initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

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

--- Comment #4 from Franz Sirl  ---
Hmm, %hhd is not usable on some of our platforms and also only really helpful
with exact %x outputs:

  snprintf(buffer, 3, "%02hhx", val);

What about:

  snprintf(buffer, 4, "%03hx", val & 0xfff);

Here the 'h' modifier doesn't help at all and also in my eyes 'val & 0xfff' or
'abs(val % 100)' would be much more natural range limiters for warning
suppression. It's a pity there isn't at least a minimum "arguments-only-VRP"
even at -O0.

Can't we have another level or two for -Wformat-truncation that only warns when
VRP is active?

Note that I believe that

  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);

shouldn't warn when VRP is active. Seems to be a minor deficiency in VRP.

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 18:26:41 2017
New Revision: 244648

URL: https://gcc.gnu.org/viewcvs?rev=244648&root=gcc&view=rev
Log:
PR67085 move comparison functions in heap operations

PR libstdc++/67085
* include/bits/stl_heap.h (push_heap, __adjust_heap, __pop_heap)
(pop_heap, __make_heap, make_heap, __sort_heap, sort_heap): Use
_GLIBCXX_MOVE when passing comparison function to other functions.
(is_heap_until, is_heap): Use std::move when passing comparison
function.
* testsuite/23_containers/priority_queue/67085.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_heap.h

[Bug c/79152] New: -Wimplicit-fallthrough false positive triggered by goto statements

[sirl at gcc dot gnu.org]

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

Bug ID: 79152
   Summary: -Wimplicit-fallthrough false positive triggered by
goto statements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This strange creduce'd testcase warns with current trunk:

typedef struct {
char *   bs;
} xstruct;

void test (char ch, long handle) {
switch (ch) {
case 1:
goto label1;
goto label;
(ch) = *(((xstruct *) (handle))->bs++);
label:
label1:
((xstruct *) handle)->bs ;
}
}

# gcc-trunk -c -Wimplicit-fallthrough testcase.c
testcase.c: In function 'test':
testcase.c:10:14: warning: this statement may fall through
[-Wimplicit-fallthrough=]
 (ch) = *(((xstruct *) (handle))->bs++);
 ~^
testcase.c:11:1: note: here
 label:
 ^

I believe this is a false positive. I hope the creduce'd testcase is enough to
highlight the problem.

[Bug c/79153] New: -Wimplicit-fallthrough missed warning

[sirl at gcc dot gnu.org]

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

Bug ID: 79153
   Summary: -Wimplicit-fallthrough missed warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

I believe this testcase modeled after real code should warn when falling
through into 'case 4'.

int
test (int v1, int v2)
{
  switch (v1)
{
case 3:
  switch (v2)
{
case 1:
  return 28;
case 2:
  return 38;
case 3:
  return 88;
}
case 4:
  return 168;
}
  return -1;
}

[Bug c/79049] Unknown escape sequence not correctly pointed out

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Notes to self: warning is emitted by convert_escape in libcpp/charset.c:1466
here:
1461  /* diagnostic.c does not support "%03o".  When it does, this
1462 code can use %03o directly in the diagnostic again.  */
1463  char buf[32];
1464  sprintf(buf, "%03o", (int) c);
1465  cpp_error (pfile, CPP_DL_PEDWARN,
1466 "unknown escape sequence: '\\%s'", buf);

when first parsing the string token, via cpp_interpret_string, and so
loc_readers is NULL.

[Bug target/78478] Compile Error for i386-rtems

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
(In reply to Joel Sherrill from comment #20)

> Looks like it works, Thanks.
> 
> Based on my testing,  these need to be applied to both the gcc 6 branch and
> master. Should I just commit them with the PR noted or do they need to go
> through gcc-patches first?

The i386/rtemself.h change is OK and can be committed to gcc-7 and gcc-6
branch. Please post this patch to gcc-patches first, and state that it is
pre-approved.

Regarding gfortran patch, I will propose the patch that detects _SOFT_FLOAT at
configure time to libgfortran ML. So, I'll take care of this part.

[Bug fortran/79154] New: omp declare simd in pure function?

[chinoune.mehdi at hotmail dot com]

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

Bug ID: 79154
   Summary: omp declare simd in pure function?
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chinoune.mehdi at hotmail dot com
  Target Milestone: ---

Created attachment 40550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40550&action=edit
the fortran program

I tried to build the program (see attachment) with gfortran (5.4.0 linux,cygwin
6.2.0,6.3.0 mingw 6.2.0 linux ...)
it gave me this error:
test_simd.f90:6:6:

 !$omp declare simd(add)
  1
Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL procedures

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I see no warning at -O0 on

  snprintf (buffer, 4, "%03hx", val & 0xfff);

or at -O2 on:

  snprintf (buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);

(It does warn at -O0 as expected.)  This is on x86_64 (both ILP32 and LP64) but
there are known issues in VRP that have been seen to lead to false positives.

What target are you seeing false positives on and with what revision?

[Bug target/79155] New: Typo in cpuid.h comment

[myriachan at gmail dot com]

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

Bug ID: 79155
   Summary: Typo in cpuid.h comment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

x86's gcc/config/i386/cpuid.h contains the following comment:

/* Return highest supported input value for cpuid instruction.  ext can
   be either 0x0 or 0x800 to return highest supported value for
   basic or extended cpuid information.  Function returns 0 if cpuid
   is not supported or whatever cpuid returns in eax register.  If sig
   pointer is non-null, then first four bytes of the signature
   (as found in ebx register) are returned in location pointed by sig.  */

The second hex constant should be 0x8000, with one more zero.  The
implementation of __get_cpuid below uses 0x8000 correctly.

[Bug libstdc++/78905] Add a macro to determine that the library is implemented

[mattyclarkson at gmail dot com]

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

--- Comment #9 from Matt Clarkson  ---
(In reply to Jonathan Wakely from comment #7)
> GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has,
> i.e. the GCC major version, as an integer constant, but defined by the
> library headers not the compiler).
> 
> If that macro is present you have a version of libstdc++ that provides a
> working . To be really sure you could check it's defined to a value
> >= 5, in order to handle (hypothetical) unofficial 4.7 or 4.8 builds that
> have the patch backported.

Sweet! Will update the snippet on Stack Overflow. Thank you for this, you the
man ;)

[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 19 20:29:07 2017
New Revision: 244650

URL: https://gcc.gnu.org/viewcvs?rev=244650&root=gcc&view=rev
Log:
Fix unsafe moves inside loops

PR libstdc++/67085
* include/bits/stl_heap.h (__is_heap): Use _GLIBCXX_MOVE.
(__make_heap, __sort_heap): Don't use _GLIBCXX_MOVE inside loops.
* testsuite/23_containers/priority_queue/67085.cc: Adjust expected
number of copies.
* testsuite/25_algorithms/make_heap/movable.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/make_heap/movable.cc
  - copied, changed from r244648,
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc

[Bug libstdc++/79156] New: incorrect c++ usage in gcc7 void function returns a value

[mib.bugzilla at gmail dot com]

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

Bug ID: 79156
   Summary: incorrect c++ usage in gcc7  void function
returns a value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mib.bugzilla at gmail dot com
  Target Milestone: ---

Hello, I work on the Intel c++ compiler and I found this problem when compiling
the gcc7 version of  dated Jan 1, 2017. I believe the error message is
accurate and it could be fixed with a minor change.

In file included from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr.h(52),
 from
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/memory(81),
 from mem.cpp(1):
/xyz/gcc/7-20170101/rhel70/efi2/bin/../include/c++/7.0.0/bits/shared_ptr_base.h(1823):
error: return value type does not match the function type
{ return __p; }


The function being complained about looks like this:
 friend void
  __enable_shared_from_this_base(const __shared_count<_Lp>&,
 const __enable_shared_from_this* __p)
  { return __p; }

  mutable __weak_ptr<_Tp, _Lp>  _M_weak_this;
};

Changing "friend void" to "friend auto" would be a simple fix.

Thanks and regards, Melanie Blower (melanie dot blower at intel dot com)

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-19
 Ever confirmed|0   |1

[Bug libstdc++/79156] incorrect c++ usage in gcc7 void function returns a value

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to mib.bugzilla from comment #0)
> Changing "friend void" to "friend auto" would be a simple fix.

That wouldn't compile in C++11 mode. I think shouldn't return anything.

[Bug target/78478] Compile Error for i386-rtems

[uros at gcc dot gnu.org]

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

--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:00:53 2017
New Revision: 244651

URL: https://gcc.gnu.org/viewcvs?rev=244651&root=gcc&view=rev
Log:
PR target/78478
* config/ax_check_define.m4: New file.

libgfortran/ChangeLog:

PR target/78478
* acinclude.m4: Include ../config/ax_check_define.m4
* configure.ac: Check if _SOFT_FLOAT is defined.
* configure.host (i?86 | x86_64): Use fpu-generic when
have_soft_float is set.
* configure: Regenerate.


Added:
trunk/config/ax_check_define.m4
Modified:
trunk/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/configure.host

[Bug fortran/79157] New: gfortran crashed on sparc with openmpi build

[ikozhukhov at gmail dot com]

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

Bug ID: 79157
   Summary: gfortran crashed on sparc with openmpi build
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ikozhukhov at gmail dot com
  Target Milestone: ---

i have DilOS - illumos based platform.
i have DilOS on SPARC T5220
i have gcc-5.4.1 64bit bootstrap with GNU AS + illumos ld
$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/gcc/5/lib/gcc/sparcv9-sun-solaris2.11/5.4.0/lto-wrapper
Target: sparcv9-sun-solaris2.11
Configured with: ../configure --prefix=/usr/gcc/5
--build=sparcv9-sun-solaris2.11 --bindir=/usr/gcc/5/bin
--sbindir=/usr/gcc/5/sbin --libdir=/usr/gcc/5/lib --libexecdir=/usr/gcc/5/lib
--infodir=/usr/gcc/5/share/info --mandir=/usr/gcc/5/share/man
--target=sparcv9-sun-solaris2.11 --enable-targets=sparc-sun-solaris2.11
--enable-shared --enable-plugins --enable-lto --enable-initfini-array
--enable-tls --enable-threads=posix --with-build-config=no --with-system-zlib
gcc_cv_ld_as_needed=no --disable-bootstrap --without-gnu-ld
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran,objc --with-gnu-as
--with-as=/usr/bin/gas
Thread model: posix
gcc version 5.4.0 (GCC) 

try to build openmpi and i can see message about:

configure:35796: checking size of Fortran CHARACTER
configure:35864: gcc-6 -DNDEBUG -g -O2 -mcpu=v9 -D_REENTRANT -finline-functions
-fno-strict-aliasing -I. -c conftest.c
configure:35871: $? = 0
configure:35881: gfortran -g -O2  conftestf.f90 conftest.o -o conftest  
configure:35888: $? = 0
configure:35932: ./conftest
configure:35939: $? = 0
configure:35955: result: 1
configure:35978: checking for C type corresponding to CHARACTER
configure:36024: result: char
configure:36093: checking alignment of Fortran CHARACTER
configure:36171: gcc -DNDEBUG -g -O2 -mcpu=v9 -D_REENTRANT -finline-functions
-fno-strict-aliasing -I. -c conftest.c
configure:36178: $? = 0
configure:36188: gfortran -g -O2 conftestf.f conftest.o -o conftest  
conftestf.f:1:0:

   program falign
 ^
internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:36195: $? = 1
configure:36212: result: Error!
configure:36214: error: Could not determine alignment of CHARACTER

i have reproduced crash with steps from configure script.

i tried to reproduce it by gcc-6.3.0 + GNU AS + illumos ld - but it is working
without crash.
problem with gcc-5.4 on SPARC on illumos based platform.

if you want/need access to to SPARC - please let me know - i can provide zone
where you can try reproduce it and use for your investigation.

[Bug testsuite/63256] [5/6/7 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[acsawdey at gcc dot gnu.org]

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

--- Comment #10 from acsawdey at gcc dot gnu.org ---
Looking at this again. Present state of play is:

sms-4.c fails with -m64 BE and LE
sms-8.c fails with -m32 BE

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
The following testcases still have xfails:
  c-c++-common/pr69543-3.c
  c-c++-common/pr69543-4.c
so this isn't quite fixed yet.

[Bug fortran/79154] omp declare simd in pure function?

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Chinoune from comment #0)
> Created attachment 40550 [details]
> the fortran program
> 
> I tried to build the program (see attachment) with gfortran (5.4.0
> linux,cygwin 6.2.0,6.3.0 mingw 6.2.0 linux ...)
> it gave me this error:
> test_simd.f90:6:6:
> 
>  !$omp declare simd(add)
>   1
> Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL
> procedures

AFAIK, GCC support OpenMP 4.0.  On p. 26 of OpenMP 4.0 Standard, one
finds

  Restrictions

  The following restriction applies to all OpenMP directives:
  · OpenMP directives may not appear in PURE or ELEMENTAL procedures.

so you get the above error message.  I'll note that OpenMP 4.5 Standard
states
Restrictions

The following restriction applies to all OpenMP directives:

  Restrictions

  · OpenMP directives, except SIMD and declare target directives,
may not appear in pure
procedures.

I'll further note that the GCC wiki page for OpenMP sugeests that
no one is actively working on $.5 support.

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[abutcher at gcc dot gnu.org]

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

--- Comment #26 from Adam Butcher  ---
(In reply to Nathan Sidwell from comment #25)
> Fixed.  We capture this if we find at least one non-static member function. 
> This agrees with Clang's implementation, after discussion with Richard Smith.
> 

Nice.  Your [much cleaner] patch sorts out the starred case above too.  With
GCC master (7.0.0 20170119) with your patch the results are:

  auto l0 = [&](auto z) { f (z); };// C:8 G:1 G':8 G'':8
  auto l1 = [&](auto) { f (2.4); };// C:8 G:1 G':8 G'':1 * fixed :)
  auto l2 = [&](auto) { O::x (2.4); }; // C:8 G:1 G':1 G'':1
  auto l3 = [&](auto) { N::y (2.4); }; // C:1 G:1 G':1 G'':1
  auto l4 = [&](auto) { }; // C:1 G:1 G':1 G'':1
  auto l5 = [&](int z) { f (z); }; // C:8 G:8 G':8 G'':8
  auto l6 = [&](int) { f (2.4); }; // C:8 G:1 G':1 G'':1
  auto l7 = [&](int) { O::x (2.4); };  // C:8 G:1 G':1 G'':1
  auto l8 = [&](int) { N::y (2.4); };  // C:1 G:1 G':1 G'':1
  auto l9 = [&](int) { };  // C:1 G:1 G':1 G'':1

with closure sizes indicated for C = Clang RELEASE_391/final, G = GCC prior to
fix, G' = GCC with my old patch, G'' = latest GCC with your patch.

It's interesting you reference Clang's implementation though as, judging by the
results of the above test, Clang is capturing 'this' far more often than it
should be; even in cases where a enclosed class member is not referenced at all
(in extreme cases the referenced fn is a static member function of a completely
different class).  And even stranger, Clang appears to behave the same for
monomorphic lambdas too.  Not sure what's going on there.