[Bug target/79179] PowerPC64: -mcpu=power9 creates stxsd with bad offset

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Thu Jan 26 04:16:11 2017
New Revision: 244917

URL: https://gcc.gnu.org/viewcvs?rev=244917=gcc=rev
Log:
[gcc]
2017-01-25  Michael Meissner  

PR target/79179
* config/rs6000/vsx.md (vsx_extract__store): Use wY
constraint instead of o for the stxsd instruction.

[gcc/testsuite]
2017-01-25  Michael Meissner  

PR target/79179
* gcc.target/powerpc/pr79179.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79179.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #1 from Bill Schmidt  ---
This does not reproduce on current trunk on a POWER8 system, where the
-mno-allow-movmisalign option is not present in the options selected by the
testsuite machinery.  If I add that option by hand, it fails as shown here.

Our automated testers show the problem seen here on GCC 5 and GCC 6.  These
testers run on a POWER7 system.  Current trunk also fails on a POWER7 system,
where the -mno-allow-movmisalign option is once again present.

This is consistent with the purpose of -mallow-movmisalign, which is to allow a
code generation pattern that requires ISA 2.07 (POWER8 and above).  Without the
ability to use these patterns, it isn't reasonable to vectorize this loop on
POWER.

So we'll need to adjust the testcase to be skipped for POWER when the
movmisalign pattern isn't available.  I'll look into the best way to represent
that tomorrow.

Meanwhile, this isn't indicative of a problem, so downgrading the priority.

[Bug target/79160] gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Resolution in r244916.  Oops, forgot the PR line in the ChangeLog.

2017-01-25  Bill Schmidt  

* gcc.target/powerpc/vsx-elemrev-4.c: Change expected code
generation to accept D-mode memory accesses.

[Bug target/79160] gcc.target/powerpc/vsx-elemrev-4.c fails on powerpc BE

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Schmidt  ---
Fixed with patch from https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02001.html.

[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2017-01-24, at 1:34 PM, redi at gcc dot gnu.org wrote:

> Would you be able to test the patch at
> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01910.html on HPUX 11?

The patch fixes all the "aligned_alloc" g++ testsuite fails on HPUX 11.00.  It
appears
fine on 11.11.

Thanks very much,
Dave

--
John David Anglin   dave.ang...@bell.net

[Bug middle-end/71304] missing strlen optimizations after string truncation by assigning NUL

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #3 from Martin Sebor  ---
Not working on the patch anymore.

[Bug c++/71290] [6 Regression] Flexible array member is not diagnosed with -pedantic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7 Regression] Flexible   |[6 Regression] Flexible
   |array member is not |array member is not
   |diagnosed with -pedantic|diagnosed with -pedantic

--- Comment #8 from Martin Sebor  ---
Patch committed in r244910.  Fixed for 7.0.

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 25 23:11:53 2017
New Revision: 244910

URL: https://gcc.gnu.org/viewcvs?rev=244910=gcc=rev
Log:
PR c++/71290 - Flexible array member is not diagnosed with -pedantic

gcc/cp/ChangeLog:
PR c++/71290
* decl.c (grokdeclarator): Warn on flexible array members.

gcc/testsuite/ChangeLog:
PR c++/71290
* g++.dg/ext/flexarray-mangle-2.C: Adjust.
* g++.dg/ext/flexarray-mangle.C: Same.
* g++.dg/ext/flexarray-subst.C: Same.
* g++.dg/ext/flexary10.C: Same.
* g++.dg/ext/flexary11.C: Same.
* g++.dg/ext/flexary14.C: Same.
* g++.dg/ext/flexary16.C: Same.
* g++.dg/ext/flexary18.C: Same.
* g++.dg/ext/flexary19.C: Same.
* g++.dg/ext/flexary7.C: Same.
* gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations1.C: Same.
* gcc/testsuite/g++.dg/ubsan/object-size-1.C: Same.
* gcc/testsuite/obj-c++.dg/property/at-property-23.mm: Same.


Added:
trunk/gcc/testsuite/g++.dg/ext/pr71290.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations1.C
trunk/gcc/testsuite/g++.dg/ext/flexarray-mangle-2.C
trunk/gcc/testsuite/g++.dg/ext/flexarray-mangle.C
trunk/gcc/testsuite/g++.dg/ext/flexarray-subst.C
trunk/gcc/testsuite/g++.dg/ext/flexary10.C
trunk/gcc/testsuite/g++.dg/ext/flexary11.C
trunk/gcc/testsuite/g++.dg/ext/flexary14.C
trunk/gcc/testsuite/g++.dg/ext/flexary16.C
trunk/gcc/testsuite/g++.dg/ext/flexary18.C
trunk/gcc/testsuite/g++.dg/ext/flexary19.C
trunk/gcc/testsuite/g++.dg/ext/flexary7.C
trunk/gcc/testsuite/g++.dg/ubsan/object-size-1.C
trunk/gcc/testsuite/obj-c++.dg/property/at-property-23.mm

[Bug libstdc++/79226] Additional overloads needed for __complex__ types

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Hmm, this would automatically work if we had overloads real(complex) etc
instead of a template, it would probably also work if the front-end provided a
conversion from __complex__ float to complex instead of having a
constructor inside complex, but here we are in the bad situation where
templates make it impossible for the compiler to guess were to look for the
suitable conversion. I don't think this is worth fixing other than disabling i
even with -fext-numeric-literals in 14+ mode as in PR 79228 (which sounds
right, GNU extensions are nice only when they do not conflict with the
standard).

[Bug c++/78896] [C++17] Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 25 22:36:18 2017
New Revision: 244909

URL: https://gcc.gnu.org/viewcvs?rev=244909=gcc=rev
Log:
PR c++/78896
* decl.c (cp_finish_decomp): Disallow memberwise decomposition of
lambda expressions.

* g++.dg/cpp1z/decomp24.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77914] Wrong lambda definition accepted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 7+.

[Bug target/79179] PowerPC64: -mcpu=power9 creates stxsd with bad offset

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40584=edit
Proposed patch to fix the problem.

[Bug target/79179] PowerPC64: -mcpu=power9 creates stxsd with bad offset

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug middle-end/79236] [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
To test, one can e.g. move libcuda.so.1 out of the way where dlopen will find
it, or I guess setting say OMP_DEFAULT_DEVICE=1 in the environment.

[Bug middle-end/79236] [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 40583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40583=edit
gcc7-pr79236.patch

Lightly tested (so far) patch.

[Bug middle-end/79236] [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-25
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug middle-end/79236] New: [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[jakub at gcc dot gnu.org]

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

Bug ID: 79236
   Summary: [7 Regression] Many libgomp tests fail if configured
with --enable-offload-targets=nvptx-none but NVidia HW
or libcuda.so.1 unavailable
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Many tests with combined simd constructs in target regions fail (timeout,
crash, ...) if nvptx-none offloading is configured, but fallback needs to be
used for whatever reason.
E.g.
FAIL: libgomp.c++/for-13.C execution test
FAIL: libgomp.c++/for-14.C execution test
FAIL: libgomp.c++/pr66199-5.C execution test
FAIL: libgomp.c++/pr66199-7.C execution test
FAIL: libgomp.c++/pr66199-8.C execution test
FAIL: libgomp.c/examples-4/teams-5.c execution test
FAIL: libgomp.c/examples-4/teams-6.c execution test
FAIL: libgomp.c/for-5.c execution test
FAIL: libgomp.c/for-6.c execution test
FAIL: libgomp.c/pr66199-5.c execution test
FAIL: libgomp.c/pr66199-7.c execution test
FAIL: libgomp.c/pr66199-8.c execution test
FAIL: libgomp.fortran/examples-4/teams-5.f90   -O1  execution test
FAIL: libgomp.fortran/examples-4/teams-5.f90   -O2  execution test
FAIL: libgomp.fortran/examples-4/teams-5.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/examples-4/teams-5.f90   -O3 -g  execution test
FAIL: libgomp.fortran/examples-4/teams-5.f90   -Os  execution test
FAIL: libgomp.fortran/examples-4/teams-6.f90   -O1  execution test
FAIL: libgomp.fortran/examples-4/teams-6.f90   -O2  execution test
FAIL: libgomp.fortran/examples-4/teams-6.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/examples-4/teams-6.f90   -O3 -g  execution test
FAIL: libgomp.fortran/examples-4/teams-6.f90   -Os  execution test
FAIL: libgomp.fortran/nestedfn5.f90   -O1  execution test
FAIL: libgomp.fortran/nestedfn5.f90   -O2  execution test
FAIL: libgomp.fortran/nestedfn5.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/nestedfn5.f90   -O3 -g  execution test
FAIL: libgomp.fortran/nestedfn5.f90   -Os  execution test
FAIL: libgomp.fortran/target1.f90   -O1  execution test
FAIL: libgomp.fortran/target1.f90   -O2  execution test
FAIL: libgomp.fortran/target1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/target1.f90   -O3 -g  execution test
FAIL: libgomp.fortran/target1.f90   -Os  execution test
FAIL: libgomp.fortran/target6.f90   -O1  execution test
FAIL: libgomp.fortran/target6.f90   -O2  execution test
FAIL: libgomp.fortran/target6.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/target6.f90   -O3 -g  execution test
FAIL: libgomp.fortran/target6.f90   -Os  execution test

all fail in that case.

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #19 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
[...]
> Even if we fixed that, this seems to have uncovered an issue with input.c:
> if I add some logging to input.c, there seems to be something going badly
> wrong with the caching of reading source lines, for this case at least.
> 
> get_next_line is being called many more times that I would have expected
> given the pattern of calls to location_get_source_line.  For some reason,
> the cache isn't working, and it's re-reading large chunks of the source file
> each time a diagnostic_show_locus is called (even on repeated calls to
> access the same line).

Instrumentation results in comment #17 shows that it's not re-reading the file
from disk, it's merely doing a lot of rescanning for newlines within the buffer
that it's loaded.

(gdb) p c->total_lines
$22 = 51888

and the line_record shows that, as expected, it's inserting a line_record entry
every 519 lines (100th of the total line count, as per
fcache_line_record_size).

It looks like the cache behavior could be improved.

In particular, repeated accesses to the same source line are more expensive
that they could be: each time it tries to count forwards from the last
line_record entry, rather than reusing the line information it got last time
(in input.c:read_line_num).  I'll try to fix it.

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm  ---
I wonder if it's worth injecting the equivalent of -fno-diagnostics-show-caret
into the Fortran FE for when it's throwing away diagnostics, perhaps by turning
gfc_buffer_error's bool flag into a tri-state:
  * unbuffered
  * buffered
  * discarderd

With the bogus linemap removed, median of 3 runs: 

real0m38.898s
user0m38.234s
sys 0m0.505s

and median of 3 runs with -fno-diagnostics-show-caret:

real0m38.400s
user0m37.729s
sys 0m0.539s

so adding -fno-diagnostics-show-caret makes it take only 98.7% of the wall time
of the old.

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[dmalcolm at gcc dot gnu.org]

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

--- Comment #17 from David Malcolm  ---
I added some instrumentation (covering all files read by input.c) and did some
crude timing:

Release build, with bogus linemap:

nb_read: 1869916
calls to: location_get_source_line: 37494
calls to: read_data: 10
calls to: get_next_line: 577038786
calls to: read_line_num: 37098

real1m10.032s
user1m9.293s
sys 0m0.507s


Release build, with bogus linemap, with -fno-diagnostics-show-caret:

nb_read: 0
calls to: location_get_source_line: 0
calls to: read_data: 0
calls to: get_next_line: 0
calls to: read_line_num: 0

real0m37.035s
user0m36.355s
sys 0m0.522s

Release build, without bogus linemap:

nb_read: 1869916
calls to: location_get_source_line: 37494
calls to: read_data: 10
calls to: get_next_line: 5773019
calls to: read_line_num: 37098

real0m39.018s
user0m38.321s
sys 0m0.532s


Release build, without bogus linemap, with -fno-diagnostics-show-caret:

nb_read: 0
calls to: location_get_source_line: 0
calls to: read_data: 0
calls to: get_next_line: 0
calls to: read_line_num: 0

real0m38.295s
user0m37.652s
sys 0m0.498s

Note how with the bogus linemap, without -fno-diagnostics-show-caret, the # of
calls to get_next_line increases from 5.7 * 10^6 to 5.7 * 10^8, a 100x
increase.

[Bug tree-optimization/78496] [7 Regression] Missed opportunities for jump threading

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
So I've been pondering this a bit more.  Essentially I see two paths forward.  

One is to enhance the backwards threader so that it can do more general
lookups/simplifications.  I've cobbled together some code for this, but it's
certainly not gcc-7 material and even once working it may not necessarily
capture this case.

The second would be to take advantage of some of the DOM restructuring we did a
year or so ago and do a block local jump threading pass where the edges/blocks
to consider are seeded by phi-only-cprop.  Depending on the cost iterating
phi-only-cprop and a local threader might be acceptable -- particularly if we
throttled back threading elsewhere.  

I haven't cobbled together any code for the second approach, but it shouldn't
be hard to prototype a non-iterating implementation.  Most of the
infrastructure we need is already in place.

[Bug c/79235] New: x86 - Can't read stack transferred parameters when using one of the parameters in a nested function

[oren.twaig at gmail dot com]

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

Bug ID: 79235
   Summary: x86 - Can't read stack transferred parameters when
using one of the parameters in a nested function
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oren.twaig at gmail dot com
  Target Milestone: ---

Created attachment 40582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40582=edit
example code + save-temp output + asm output

x86-64 standard calling convention supports passing more than six parameters
using the stack. The caller places the extra params on the stack which the
callee is expected to read from. As so, if we deference the first on-stack
param, we can get access to all the others.

Example (Full example + full asm are attached)::

function a(int a, int b, int c, int d, int e, int f, int on_stack)
{
int* pvargs = _stack;
int second=pvargs[1];

printf("second on_stack param=%d\n", second);
}

So far, all good.

However, There is a weird bug. If we use one of the stack-transfered parameters
in a nested function (of the function with expects more than six parameters)
the assembler of the callee (which contains the nested function) is no longer
correct and doesn't read the extra parameters from the correct place in the
stack.

Example (Full example + full asm are attached):


function a(int a, int b, int c, int d, int e, int f, int on_stack)
{
int* pvargs = _stack;
int second=pvargs[1];

no-inline _nested(void) {
printf("on_stack=%d\n", on_stack);  ->> referncing on_stack will cause
the bug.

printf("second on_stack param=%d\n", second); --> second will no longer
be printed correctly.
}   

}


In my more-adanced attached code, I did just that. Below is what happens when I
pass three '0xdeadbee[012]' on-stack. When DO_BUG is defined, I add a reference
to the on-stack variable as described earlier.



 comp="/tmp/6.3.0-gcc-bin/bin/gcc"; $comp --version |head -n 1; echo 
TESTING   & && echo without: && $comp -o main -O3 a.c  b.c && ./main 
&& echo &&  echo "with:   -DDO_BUG" && $comp -o main -O3 a.c  b.c -DDO_BUG  &&
./main
gcc (GCC) 6.3.0


 TESTING 

without:
  0=0xdeadbee0 1=0xdeadbee1 2=0xdeadbee2

with:   -DDO_BUG
  0=0xdeadbee0 1=0x8857fd60 2=0x5560fba0   --->> BUG, what happend to '1' and
'2' ???



We can clearly see the diff in the ASM. The callee changed! Instead of the
'72','80' and '88' correct offsets, we get some weird 'random' like offsets of
'48', '80', and '64'. Which obviously result in the wrong print.

diff b_good.s b_bad.s  -u

 #APP
 # 14 "b.c" 1
nop;nop;nop
 # 0 "" 2
 #NO_APP
-   movq72(%rsp), %rax
-   movl%eax, 28(%rsp)
-   movq80(%rsp), %rax
-   movl%eax, 24(%rsp)
-   movq88(%rsp), %rax
-   movl%eax, 20(%rsp)
+   movq48(%rsp), %rax
+   movl%eax, 44(%rsp)
+   leaq80(%rsp), %rax
+   movq%rax, 8(%rsp)
+   movl8(%rsp), %eax
+   movl%eax, 40(%rsp)
+   movq64(%rsp), %rax
+   movl%eax, 36(%rsp)
 #APP
 # 18 "b.c" 1
nop;nop;nop
 # 0 "" 2
 #NO_APP

[Bug target/79233] portable p-bit shift with p <= 64 not optimized on powerpc64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug middle-end/79223] missing -Wstringop-overflow on a memmove overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01994.html

[Bug middle-end/79222] missing -Wstringop-overflow= on a stpcpy overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01994.html

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01994.html

[Bug c++/77914] Wrong lambda definition accepted

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 25 20:51:10 2017
New Revision: 244907

URL: https://gcc.gnu.org/viewcvs?rev=244907=gcc=rev
Log:
PR c++/77914
* parser.c (cp_parser_lambda_declarator_opt): Pedwarn with
OPT_Wpedantic on lambda templates for -std=c++14 and higher.

* g++.dg/cpp1y/lambda-generic-77914.C: New test.
* g++.dg/cpp1y/lambda-generic-dep.C: Add -pedantic to dg-options,
expect a warning.
* g++.dg/cpp1y/lambda-generic-x.C: Add -Wpedantic to dg-options,
expect warnings.
* g++.dg/cpp1y/lambda-generic-mixed.C: Add empty dg-options.
* g++.dg/cpp1y/pr59636.C: Likewise.
* g++.dg/cpp1y/pr60190.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-77914.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-dep.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-mixed.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-x.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr59636.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr60190.C

[Bug middle-end/79234] New: warn on past the end reads by library functions

[msebor at gcc dot gnu.org]

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

Bug ID: 79234
   Summary: warn on past the end reads by library functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-overflow option can detect calls to some standard library
functions that write past the end of a destination object, but it doesn't
detect calls that attempt to read beyond the end of an object.  As the
following test case shows, even though all three functions access memory beyond
the end of an object only the first one that writes past the end is diagnosed.

This is an enhancement request to add an option to also detect and diagnose
past the end reads.  The feature should be a straightforward extension of the
-Wstringop-overflow approach (though under it own option).

$ cat t.c && gcc  -O2 -S -Wall -Wextra -Wpedantic t.c
#include 

char a[5];

void f (size_t n)
{
  memcpy (a, "01234567", n < 7 ? 7 : n);
}

void g (void *d, size_t n)
{
  memcpy (d, a, n < 7 ? 7 : n);
}

int h (size_t n)
{
  return memcmp (a, "01234567", n < 7 ? 7 : n);
}

t.c: In function ‘f’:
t.c:7:3: warning: ‘memcpy’ writing between 7 and 18446744073709551615 bytes
into a region of size 5 overflows the destination [-Wstringop-overflow=]
   memcpy (a, "01234567", n < 7 ? 7 : n);
   ^
tmp$

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
The problem seems located to the file evaluators_uti.f90 and occurred between
revisions  r243430 (2016-12-08, OK) and r243621 (2016-12-13, segfault).

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[cmacmackin at gmail dot com]

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

--- Comment #9 from Chris  ---
Last I heard, gfortran still doesn't invoke finalisation in this situation. In
any case, while (in my main code) I could certainly reduce the volume of leaked
memory via finalisation (by deallocating arrays contained in the derived type
variable), it wouldn't work to deallocate the variable itself.

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
I tested this with latest trunk, gfortran 7.0.0, and valgrind and the issue is
still there. I guess the implicit allocation that happens with:

type(SU2) :: g1, g2, g3

is not being implicitly deallocated. Does it require a finalization procedure?

or would a finalization procedure be a work around?

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #1)
> *** Bug 79231 has been marked as a duplicate of this bug. ***

Sorry for the duplicate spam... seems the commit button was overly sensitive.

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
I agree with Matthew.

[Bug c++/78896] [C++17] Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note, we don't ICE on the testcase anymore.

[Bug preprocessor/79214] -Wno-system-header defeats strncat buffer overflow warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Testing a patch.

[Bug target/79233] New: portable p-bit shift with p <= 64 not optimized on powerpc64

[vincent-gcc at vinc17 dot net]

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

Bug ID: 79233
   Summary: portable p-bit shift with p <= 64 not optimized on
powerpc64
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

The srd instruction of powerpc64 appears to support 64-bit shift, the result
being 0 in this case[*]. In ISO C, one would write:

unsigned long shift (unsigned long x, int s)
{
  return s != sizeof (unsigned long) * 8 ? x >> s : 0UL;
}

but the generated code with GCC 6.3.0 (tested on gcc112.fsffrance.org) gives:

shift:
cmpwi 7,4,64
beq 7,.L3
srd 3,3,4
blr
.p2align 4,,15
.L3:
li 3,0
blr

The test is unnecessary as the branch giving 0 is equivalent.

[*]
http://www.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.alangref/idalangref_srd_instrs.htm
"Shift amounts from 64 to 127 give a zero result."

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #13)
> Bin,
> 
> Are you likely to backport this fix to GCC-5 and GCC-6 - or is it going to
> be Martin's fix ? 
> 
> Ramana

I will check if the fix stands for 5/6 too and ask for approval.  Thanks.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #28 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #27)
> I think the problem is in the vnode->dynamically_initialized handling, as
> well as in get_translation_unit_decl being totally unreliable.
> When LTO merges VAR_DECLs from multiple TUs, it either should clear the
> dynamically_initialized flag, or should make sure that the decl that is used
> for the vnode actually is going to have get_translation_unit_decl the TU
> that it contained the definition.
> The #c20 testcase has in the end 3 globals:
> name = "__ioinit", module_name = 0x400f3c "/tmp/ccoQRMfD.ltrans0.o",
> has_dynamic_init = 1
> name = 0x400f5d "xptimer_clean", module_name = 0x400de0 "xptimer.cc",
> has_dynamic_init = 1
> name = 0x400f6b "xptimer_sweep", module_name = 0x400de0 "xptimer.cc",
> has_dynamic_init = 1
> 
> xptimer_clean and xptimer_sweep are both defined in xptiming.cc and declared
> in xptiming.h, xptimer.cc TU doesn't see any traces of it, yet
> get_translation_unit_decl returns for it the xptimer.cc TU, because
> DECL_CONTEXT of those 2 vars is a NAMESPACE_DECL and LTO merges
> NAMESPACE_DECLs too.
> Similarly, __ioinit has DECL_CONTEXT of std namespace and that, being
> prebuilt by the compiler, doesn't have surrounding TU.
> Even when considering only VAR_DECLs that have DECL_CONTEXT of
> TRANSLATION_UNIT_DECL directly, I believe this doesn't work right:
> 1) if the VAR_DECL has more than one definition (comdat, inline var, ...?),
> then I think we'd need to merge the two definitions with
> dynamically_initialized 1 as dynamically_initialized 0
> 2) wonder if we ever merge external decl with decl definition using the
> external decl's context
> 
> In short, the easiest fix is just to disable the initialization order
> checking altogether for LTO (by forcing dynamically_initialized = 0 in LTO).

Yeah, that's what I thought about. Should I revert the whole bunch of related
patches or just force vnode->dynamically_initialized = 0 for LTO leaving a
comment with link to this PR?

> Or at least clear it when merging multiple varpool nodes that have
> dynamically_initialized = 1, and otherwise (if there is just one TU with
> vnode->dynamically_initialized == 1), make sure get_translation_unit_decl
> will return that TU for it and if we can't ensure that, clear
> dynamically_initialized too.  Which can be done e.g. by clearing it whenever
> DECL_CONTEXT actually isn't a TRANSLATION_UNIT_DECL directly or is some
> other TU, or by say adding TRANSLATION_UNIT_DECL tree into the vnode (grows
> memory usage though!) and looking it up from there.

[Bug fortran/79231] [Regression on 7.0.1] Run time error: malloc on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
Dup.

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

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
*** Bug 79231 has been marked as a duplicate of this bug. ***

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|[Regression on 7.0.1] Run   |[7 Regression] Run time
   |time error: malloc on valid |error: malloc on valid code
   |code|

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
I think the problem is in the vnode->dynamically_initialized handling, as well
as in get_translation_unit_decl being totally unreliable.
When LTO merges VAR_DECLs from multiple TUs, it either should clear the
dynamically_initialized flag, or should make sure that the decl that is used
for the vnode actually is going to have get_translation_unit_decl the TU that
it contained the definition.
The #c20 testcase has in the end 3 globals:
name = "__ioinit", module_name = 0x400f3c "/tmp/ccoQRMfD.ltrans0.o",
has_dynamic_init = 1
name = 0x400f5d "xptimer_clean", module_name = 0x400de0 "xptimer.cc",
has_dynamic_init = 1
name = 0x400f6b "xptimer_sweep", module_name = 0x400de0 "xptimer.cc",
has_dynamic_init = 1

xptimer_clean and xptimer_sweep are both defined in xptiming.cc and declared in
xptiming.h, xptimer.cc TU doesn't see any traces of it, yet
get_translation_unit_decl returns for it the xptimer.cc TU, because
DECL_CONTEXT of those 2 vars is a NAMESPACE_DECL and LTO merges NAMESPACE_DECLs
too.
Similarly, __ioinit has DECL_CONTEXT of std namespace and that, being prebuilt
by the compiler, doesn't have surrounding TU.
Even when considering only VAR_DECLs that have DECL_CONTEXT of
TRANSLATION_UNIT_DECL directly, I believe this doesn't work right:
1) if the VAR_DECL has more than one definition (comdat, inline var, ...?),
then I think we'd need to merge the two definitions with
dynamically_initialized 1 as dynamically_initialized 0
2) wonder if we ever merge external decl with decl definition using the
external decl's context

In short, the easiest fix is just to disable the initialization order checking
altogether for LTO (by forcing dynamically_initialized = 0 in LTO).
Or at least clear it when merging multiple varpool nodes that have
dynamically_initialized = 1, and otherwise (if there is just one TU with
vnode->dynamically_initialized == 1), make sure get_translation_unit_decl will
return that TU for it and if we can't ensure that, clear
dynamically_initialized too.  Which can be done e.g. by clearing it whenever
DECL_CONTEXT actually isn't a TRANSLATION_UNIT_DECL directly or is some other
TU, or by say adding TRANSLATION_UNIT_DECL tree into the vnode (grows memory
usage though!) and looking it up from there.

[Bug c++/79176] [6/7 Regression] ICE in mangle_decl with LTO and Os

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
  Component|middle-end  |c++
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> To me this sounds like a mismatch between the middle-end type_with_linkage_p
> and the C++ FE no_linkage_check.  Perhaps the former should call the latter
> using a langhook?

no_linkage_check is wrong here.

It decides that the lambda has no linkage because ~Item is !TREE_PUBLIC, so it
doesn't have "vague linkage".  ~Item is !TREE_PUBLIC because it's the
maybe-in-charge constructor which is internal to its comdat group, but it can
appear in multiple translation units so it really does have vague linkage. 
I'll fix.

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||amker at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org

--- Comment #13 from Ramana Radhakrishnan  ---
Bin,

Are you likely to backport this fix to GCC-5 and GCC-6 - or is it going to be
Martin's fix ? 

Ramana

[Bug middle-end/39838] [5/6 regression] unoptimal code for two simple loops

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[5/6/7 regression]  |[5/6 regression] unoptimal
   |unoptimal code for two  |code for two simple loops
   |simple loops|

--- Comment #25 from Jeffrey A. Law  ---
I don't think the codesize going up with -O2 is a significant issue here.  It
looks like the regression with -Os is fixed.  We can also see that we're doing
less memory traffic.

I think we should mark this as resolved for gcc-7.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #26 from Maxim Ostapenko  ---
(In reply to Maxim Ostapenko from comment #24)
> (In reply to Tobias Burnus from comment #23)
> > (In reply to Tobias Burnus from comment #22)
> > > As I recently did some incremental builds, I will retry it after a full
> > > bootstrap.
> > 
> > Didn't make a difference - I still see the ASAN run-time fail. I wonder
> > what's different between our systems.
> 
> Perhaps you use strict_init_order=true option (e.g.
> ASAN_OPTIONS=check_initialization_order=true:report_globals=3:
> strict_init_order=true)? 
> max@max:~/test-lto/test-2/test$
> ASAN_OPTIONS=check_initialization_order=true:report_globals=3:
> strict_init_order=true ./a.out 
> #0 0x41d885 in __asan_register_globals
> /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326
> #1 0x58a3b6 in _GLOBAL__sub_I_00099_1_main.4497
> (/home/max/test-lto/test-2/test/a.out+0x58a3b6)
> #2 0x58a40c in __libc_csu_init
> (/home/max/test-lto/test-2/test/a.out+0x58a40c)
> #3 0x7fb4c6568ed4 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
> #4 0x405f38  (/home/max/test-lto/test-2/test/a.out+0x405f38)
> 
> === ID 1015021569; 0x007c7f60 0x007c8120
> ==26120==Added Global[0x007c7f60]: beg=0x005a5960 size=1/64
> name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==  location (0x007c7f20):
> name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.
> h[0x005a5aa0], 79 35
> ==26120==Added Global[0x007c7fa0]: beg=0x0142cf20 size=1/64
> name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1
> ==26120==  location (0x007c7f30):
> name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74
> 25
> ==26120==Added Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64
> name=xptimer_clean module=xptimer.cc dyn_init=1
> ==26120==  location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9
> ==26120==Added Global[0x007c8020]: beg=0x0142cf60 size=16/64
> name=xptimer_sweep module=xptimer.cc dyn_init=1
> ==26120==  location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9
> ==26120==Added Global[0x007c8060]: beg=0x005a5a60 size=14/64
> name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Added Global[0x007c80a0]: beg=0x005a59e0 size=12/64
> name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Added Global[0x007c80e0]: beg=0x005a59a0 size=11/64
> name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Added Global[0x007c8120]: beg=0x005a5a20 size=14/64
> name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> DynInitPoison module: xptimer.cc
> DynInitPoison module: xptiming.cc
> =
> ==26120==Search Global[0x007c8120]: beg=0x005a5a20 size=14/64
> name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Search Global[0x007c80e0]: beg=0x005a59a0 size=11/64
> name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Search Global[0x007c80a0]: beg=0x005a59e0 size=12/64
> name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Search Global[0x007c8060]: beg=0x005a5a60 size=14/64
> name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==Search Global[0x007c8020]: beg=0x0142cf60 size=16/64
> name=xptimer_sweep module=xptimer.cc dyn_init=1
> ==26120==  location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9
> ==26120==Search Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64
> name=xptimer_clean module=xptimer.cc dyn_init=1
> ==26120==  location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9
> ==26120==Search Global[0x007c7fa0]: beg=0x0142cf20 size=1/64
> name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1
> ==26120==  location (0x007c7f30):
> name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74
> 25
> ==26120==Search Global[0x007c7f60]: beg=0x005a5960 size=1/64
> name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
> ==26120==  location (0x007c7f20):
> name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.
> h[0x005a5aa0], 79 35
> ==26120==ERROR: AddressSanitizer: initialization-order-fiasco on address
> 0x0142cf68 at pc 0x0058a25c bp 0x7ffc44459250 sp 0x7ffc44459230
> WRITE of size 1 at 0x0142cf68 thread T0
> #0 0x58a25b in __base_ctor  /home/max/test-lto/test-2/test/xptimer.cc:12
> #1 0x58a349 in __static_initialization_and_destruction_0
> /home/max/test-lto/test-2/test/xptiming.cc:6
> #2 0x58a377 in _GLOBAL__sub_I__ZN6xp_aux13xptimer_sweepE
> /home/max/test-lto/test-2/test/xptiming.cc:9
> #3 0x58a40c in __libc_csu_init
> (/home/max/test-lto/test-2/test/a.out+0x58a40c)
> #4 0x7fb4c6568ed4 in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
> #5 0x405f38  (/home/max/test-lto/test-2/test/a.out+0x405f38)
> 
> 

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I let this one slip through the cracks.  Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01983.html

[Bug c++/79232] New: error: invalid rhs for gimple memory store

[dcb314 at hotmail dot com]

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

Bug ID: 79232
   Summary: error: invalid rhs for gimple memory store
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 40581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40581=edit
gzipped C++ source code

The attached C++ source code does this:

plyvel/_plyvel.cpp: In function ‘int __Pyx_SetItemInt_ByteArray_Fast(PyObject*, 
Py_ssize_t, unsigned char, int, int)’:
plyvel/_plyvel.cpp:19998:29: error: invalid rhs for gimple memory store
D.53930

*iftmp.579;

D.53930 = *iftmp.579;
plyvel/_plyvel.cpp:19998:29: error: invalid rhs for gimple memory store
D.53936

*iftmp.586;

D.53936 = *iftmp.586;
plyvel/_plyvel.cpp:19998:29: internal compiler error: verify_gimple failed
0xee7e7d verify_gimple_in_seq(gimple*)
../../trunk/gcc/tree-cfg.c:4934
0xbe5ea4 gimplify_body(tree_node*, bool)
../../trunk/gcc/gimplify.c:12464
0xbe625c gimplify_function_tree(tree_node*)
../../trunk/gcc/gimplify.c:12554

I can see that this bug has been around since at least revision 242353,
dated 20161113.

I'll have a go at reducing the code.

[Bug fortran/79231] [Regression on 7.0.1] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
For us this is a serious regression that would exclude gfortran 7.1 if that
weren't fixed before the official release. Not optimistic that we can easily
work around here.
So please try to fix it in time! Will be much appreciated!

[Bug fortran/79231] New: [Regression on 7.0.1] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

Bug ID: 79231
   Summary: [Regression on 7.0.1] Run time error: malloc on valid
code
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following case (part of our unit test suite) throws run time errors (61 out
of 110 tests), and _all_ of the functional tests. I assume that they are all
related to the same 'feature' (change in the gfortran code). In the tarball, do 
make, and then 
./rt_error --check evaluators
Using r244868, all older gfortran versions since 4.8.5 are working. 
The code is rather lengthy (but still not the complete testsuite). I try to
provide 
a smaller test case if possible, but also a complete test suite. 

This is the error:
Running test: evaluator_1rt_error(56542,0x7fffb05123c0) malloc: *** error for
object 0x7fb4ebf00110: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x10cdfd7c9
#1  0x10cdfcb63
#2  0x7fffa78d2bb9
Abort trap: 6

Up to now I couldn't produce a proper backtrace.

[Bug fortran/79230] New: [Regression on 7.0.1] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

Bug ID: 79230
   Summary: [Regression on 7.0.1] Run time error: malloc on valid
code
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 40580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40580=edit
Unit test suite that experiences the run time error.

The following case (part of our unit test suite) throws run time errors (61 out
of 110 tests), and _all_ of the functional tests. I assume that they are all
related to the same 'feature' (change in the gfortran code). In the tarball, do 
make, and then 
./rt_error --check evaluators
Using r244868, all older gfortran versions since 4.8.5 are working. 
The code is rather lengthy (but still not the complete testsuite). I try to
provide 
a smaller test case if possible, but also a complete test suite. 

This is the error:
Running test: evaluator_1rt_error(56542,0x7fffb05123c0) malloc: *** error for
object 0x7fb4ebf00110: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x10cdfd7c9
#1  0x10cdfcb63
#2  0x7fffa78d2bb9
Abort trap: 6

Up to now I couldn't produce a proper backtrace.

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> 
> ICEs as well with -O1 and above.  Vlad, do you think you could have a look?

Sure, I'll look at this when I am done with PR79131.

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #1)
> 
> Probably the fix will need more time than for pr79058 but I hope to fix it
> on this week.

I have a fix for the PR. Unfortunately it brakes some GCC IP RA regression
tests.  IP RA was not adopted by LRA.  We were just fortunate that the IP RA
tests worked so far (actually for the IP RA tests, LRA just used allocation
from IRA and therefore tests worked successfully).

So now I need to implement IP RA part in LRA to commit the patch.  So probably
the fix will need one more week to be done.

[Bug c++/77914] Wrong lambda definition accepted

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 40578 [details]
> gcc7-pr77914.patch
> 
> So like this (untested)?

Looks good.

[Bug c++/78896] [C++17] Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> Jason, any thoughts on this?  Shall we just disallow lambdas in
> decompositions?  Shall the standard say anything about those?

Yes, the standard should probably explicitly prohibit this.  We definitely
should.

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

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Only three out of the five patches for bug 78703 have been committed.  I'm
still waiting for approval of the substantive patch 4, and patch 5 depends on
it.  With those committed I think the warning should behave close to how you
expect.  I suspect it will still need some fine tuning after GCC 7 is released.

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

[vhaisman at gmail dot com]

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

--- Comment #18 from Václav Haisman  ---
And I have just verified it is still the same with GCC 6.3.0.

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[siarhei.siamashka at gmail dot com]

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

--- Comment #8 from Siarhei Siamashka  ---
Since my report predates bug 68664 by several years, shouldn't bug 68664 be a
duplicate? In addition, my report was much more detailed, since it also
provided a practical use case, showcasing the importance of this problem.

Also if I understand it correctly, you have still not fixed the issue. So
closing it seems to be a bit premature. I'll keep a watch on bug 68664 and will
be sure to reopen my bugreport in the case if the fix does not help on ARM
Cortex A9.

Thanks for generating some sort of activity anyway. It's surely better than
nothing.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[burnus at gcc dot gnu.org]

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

--- Comment #25 from Tobias Burnus  ---
(In reply to Maxim Ostapenko from comment #24)
> Perhaps you use strict_init_order=true option (e.g.
> ASAN_OPTIONS=check_initialization_order=true:report_globals=3:
> strict_init_order=true)? 

strict_init_order=true/false doesn't make a difference, here. If either
check_initialization_order=true or strict_init_order=true (or both true) - and
report_globals > 0, I get an ASAN backtrace, otherwise not.

However, it seems as if you now get the same backtrace as I get - even though
you seem to need strict_init_order=true in addition.

[Bug target/79218] Missed swap optimization on powerpc64le simple test case

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
At the moment, swap optimization doesn't attempt to handle __int128 values, for
which swaps don't deal with elements of a vector, but pieces of a cohesive
integer value.  This may be overly conservative, and we may want to see what
breaks if this is relaxed by now.  But I wouldn't do this before GCC 8, because
it's a large change.

[Bug c/79227] Questionable -Wmisleading-indentation diagnostic in HSAIL-Tools

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Created attachment 40579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40579=edit
Patch to tweak Wmisleading indentation

This patch removes the "(guard_exploc.line == body_exploc.line)" condition from
the:
  /* Heuristic: only warn if the guard is the first thing
 on its line.  */

and hence silences the warning from the reproducer.  It doesn't introduce any
regressions in the testsuite (only tested briefly, though).

[Would need ChangeLog, and testsuite coverage]


Patrick, any thoughts?

[Bug c++/78896] [C++17] Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Jason, any thoughts on this?  Shall we just disallow lambdas in decompositions?
 Shall the standard say anything about those?

[Bug c++/78337] "internal compiler error: Segmentation fault", using local variable in lambda return-type deduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for 7+.

[Bug c++/77914] Wrong lambda definition accepted

[jakub at gcc dot gnu.org]

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

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

So like this (untested)?

[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for GCC 7.

[Bug c/79227] Questionable -Wmisleading-indentation diagnostic in HSAIL-Tools

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Some notes:

There are 7 cases in the reproducer, but it only warns for the 3rd case (lines
34-35).

In each of the 7 cases in the reproducer, NEXT_STMT_LOC and BODY_LOC are on the
same line:

  /* If NEXT_STMT_LOC and BODY_LOC are on the same line, consider
 the location of the guard.

Case 3 matches the following conditional, and thus warns:

  if (guard_exploc.line < body_exploc.line)
/* The guard is on a line before a line that contains both
   the body and the next stmt.  */
return true;

whereas the other cases match this conditional:

  else if (guard_exploc.line == body_exploc.line)
{
  /* They're all on the same line.  */

and try this heuristic:

  /* Heuristic: only warn if the guard is the first thing
 on its line.  */
  if (guard_vis_column == guard_line_first_nws)
return true;

...which doesn't match, hence we don't warn for them.

[Bug libstdc++/70607] [5/6/7 Regression] The return type of std::conj must be std::complex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for GCC 7. As I said, I don't think it's a good idea to change this
midway through the GCC 5 and GCC 6 releases.

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

[sirl at gcc dot gnu.org]

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

--- Comment #9 from Franz Sirl  ---
With r244892 and -O2 -Wformat-truncation=2 I nearly get the warnings I expect. 

What remains is case 3, but this seems to be a small deficiency in VRP. For the
term I used ((val < 0) ? -(val % 100) : (val % 100)), it seems VRP cannot
deduce that both branches of the IF finally result in [0, 99]. On the other
hand, a "normal" abs()-like macro would result in (((val % 100) < 0) ? -(val %
100) : (val % 100)), which some other pass turns into an ABS_EXPR which is
handled fine by VRP and accordingly the warning goes away too.

It seems a part of 78703 is still missing, because there are still warnings at
-O0?

To make my point about the warnings at -O0 more clear, I believe a false
positive at -O0 even though the argument was already properly (!) range limited
at the spot (which I believe would be a common way for programmers to kill the
warning) is really not helpful. So with a mini-VRP at -O0 for function
arguments the warning could be acceptable at -O0. But in its current state I
believe the warning should only be turned on automatically when VRP is active.

[Bug target/72758] AArch64 missing support for poly64_t/poly64x1_t/poly64x2_t/poly128_t intrinsics

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||tnfchris at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from tnfchris at gcc dot gnu.org ---
This was implemented in r243287.

[Bug libstdc++/70607] [5/6/7 Regression] The return type of std::conj must be std::complex

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 25 15:01:05 2017
New Revision: 244900

URL: https://gcc.gnu.org/viewcvs?rev=244900=gcc=rev
Log:
PR libstdc++/70607 make proj(T) and conj(T) return complex

PR libstdc++/61791
PR libstdc++/70607
* include/std/complex (real(T), imag(T)): Add _GLIBCXX_CONSTEXPR.
(proj(T), conj(T)): Change return types per DR 1522.
* include/tr1/complex (conj): Remove overloads and use std::conj.
* testsuite/26_numerics/complex/dr781_dr1137.cc: Rename to...
* testsuite/26_numerics/complex/dr781.cc: ... this, and update.
* testsuite/26_numerics/complex/value_operations/constexpr2.cc: Test
real(T) and imag(T). Allow testing for C++11 too.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781.cc
  - copied, changed from r244898,
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781_dr1137.cc
Removed:
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781_dr1137.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/complex
trunk/libstdc++-v3/include/tr1/complex
   
trunk/libstdc++-v3/testsuite/26_numerics/complex/value_operations/constexpr2.cc

[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 25 15:01:05 2017
New Revision: 244900

URL: https://gcc.gnu.org/viewcvs?rev=244900=gcc=rev
Log:
PR libstdc++/70607 make proj(T) and conj(T) return complex

PR libstdc++/61791
PR libstdc++/70607
* include/std/complex (real(T), imag(T)): Add _GLIBCXX_CONSTEXPR.
(proj(T), conj(T)): Change return types per DR 1522.
* include/tr1/complex (conj): Remove overloads and use std::conj.
* testsuite/26_numerics/complex/dr781_dr1137.cc: Rename to...
* testsuite/26_numerics/complex/dr781.cc: ... this, and update.
* testsuite/26_numerics/complex/value_operations/constexpr2.cc: Test
real(T) and imag(T). Allow testing for C++11 too.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781.cc
  - copied, changed from r244898,
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781_dr1137.cc
Removed:
trunk/libstdc++-v3/testsuite/26_numerics/complex/dr781_dr1137.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/complex
trunk/libstdc++-v3/include/tr1/complex
   
trunk/libstdc++-v3/testsuite/26_numerics/complex/value_operations/constexpr2.cc

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
Sorry, long pause while editing that comment made me leave out part of what I
was trying to say - I meant only discard notes that reference the CC reg. But
it seems an unnecessary complication.

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[bernds at gcc dot gnu.org]

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

--- Comment #11 from Bernd Schmidt  ---
Looks like other_insn is only used for cases where we rewrite cc sets in this
way, so Bin's patch does look reasonably narrow. We could maybe record the CC
reg being changed and only discard reg notes, but in my testing I've not been
able to produce code generation differences except for the testcase. Let's wait
for Segher's testing, but I think the patch is OK.

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So it seems r22 removes one stmt (e.g. in *.fnsplit dump):
--- c-ray-f.i.048t.fnsplit.21   2017-01-25 09:13:45.0 -0500
+++ c-ray-f.i.048t.fnsplit.22   2017-01-25 09:14:20.0 -0500
@@ -1124,7 +1124,6 @@ shade (struct sphere * obj, struct spoin

[1.29%]:
   ray.orig = sp_108(D)->pos;
-  ray.dir = sp_108(D)->vref;
   ray$dir$x_154 = MEM[(struct spoint *)sp_108(D) + 48B];
   ray$dir$y_155 = MEM[(struct spoint *)sp_108(D) + 56B];
   ray$dir$z_156 = MEM[(struct spoint *)sp_108(D) + 64B];
and that in turn changes the inlining decisions.  In r21:
 Inlined into render which now has time 9181 and size 89,net change of -11.
 Inlined into shade which now has time 2920 and size 183,net change of -18.
 Inlined into render which now has time 17981 and size 141,net change of +52.
 Inlined into get_primary_ray which now has time 109 and size 65,net change of
+36.
 Inlined into get_primary_ray which now has time 162 and size 102,net change of
+37.
 Inlined into trace which now has time 301 and size 152,net change of +102.
and in r22:
 Inlined into render which now has time 9181 and size 89,net change of -11.
 Inlined into shade which now has time 2918 and size 179,net change of -18.
 Inlined into render which now has time 17981 and size 141,net change of +52.
 Inlined into get_primary_ray which now has time 109 and size 65,net change of
+36.
 Inlined into get_primary_ray which now has time 162 and size 102,net change of
+37.
 Inlined into shade which now has time 2957 and size 216,net change of +37.
 Inlined into trace which now has time 301 and size 152,net change of +102.

The difference is that trace has been inlined into shade.

[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
I will have a look.  Thanks.

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target|powerpc*-*-*, aarch64*-*-*  |powerpc*-*-*, aarch64*-*-*,
   ||arm*-*-*

--- Comment #6 from James Greenhalgh  ---
While this could still be a series of target issues, the decision to make the
square root operation unconditional is bad across a number of targets, so I
wonder whether there is a common heuristic that can be tweaked. On AArch64 this
is happening in sched1, and the branch looks like it is being incorrectly
statically predicted as likely taken.

[Bug target/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
Also, make sure that the optimization is still done when a variable is a
constant or replaced by a constant (with Clang, the optimization is no longer
done in such a case).

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||siarhei.siamashka at gmail dot 
com

--- Comment #5 from James Greenhalgh  ---
*** Bug 53659 has been marked as a duplicate of this bug. ***

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from James Greenhalgh  ---


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

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #17 from Jakub Jelinek  ---
Avoid decltype in that case, or use decltype on some other function that has
the same arguments as malloc and same return value, just not such attributes.
void *my_malloc (size_t);
... decltype (my_malloc) ...

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
extern inline isn't needed:
int a, b, c;
void
foo (void *x, void *y)
{ 
  __asm__ ("": "=" (a), "=" (b), "=" (c): "r" (y), "2" (y));
}
ICEs as well with -O1 and above.  Vlad, do you think you could have a look?

[Bug target/77468] [7 Regression] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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

--- Comment #21 from PeteVine  ---
It would be great if https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 could
get squashed in one fell swoop.

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Any progress on this?

Re: Unable to create an account at gcc/bugzilla

[Markus Trippelsdorf]

On 2017.01.25 at 15:43 +0200, Oren Twaig wrote:
> Hi,
> 
> I would like to report a bug in GCC. However, can't create a user in
> the bug report system.
> Any suggestions?
> 
> Here are some more details:
> 
> i can't create a new account here:
> https://gcc.gnu.org/bugzilla/createaccount.cgi
> 
> It say something like :
> "User account creation filtered due to spam."
> 
> And when I enter my email and send, it say:
> 
> User account creation has been restricted.
> 
> Contact your administrator or the maintainer (overse...@gcc.gnu.org)
> for information about creating an account.

Just send a plain text mail to overse...@gcc.gnu.org and they will
create an account for you.

-- 
Markus

Unable to create an account at gcc/bugzilla

[Oren Twaig]

Hi,

I would like to report a bug in GCC. However, can't create a user in
the bug report system.
Any suggestions?

Here are some more details:

i can't create a new account here:
https://gcc.gnu.org/bugzilla/createaccount.cgi

It say something like :
"User account creation filtered due to spam."

And when I enter my email and send, it say:

User account creation has been restricted.

Contact your administrator or the maintainer (overse...@gcc.gnu.org)
for information about creating an account.

Please help,
Thanks,
Oren

[Bug lto/70929] [5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
I wonder why we don't simply do the following, which checks the type of the
originally built CALL_EXPR from the frontends which should have done the
job of matching up the actual arguments closely enough with the type of the
actual function called.

Also fixes the testcase (obviously).

Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 244897)
+++ gcc/cgraph.c(working copy)
@@ -3733,17 +3733,8 @@ bool
 gimple_check_call_matching_types (gimple *call_stmt, tree callee,
  bool args_count_match)
 {
-  tree lhs;
-
-  if ((DECL_RESULT (callee)
-   && !DECL_BY_REFERENCE (DECL_RESULT (callee))
-   && (lhs = gimple_call_lhs (call_stmt)) != NULL_TREE
-   && !useless_type_conversion_p (TREE_TYPE (DECL_RESULT (callee)),
-  TREE_TYPE (lhs))
-   && !fold_convertible_p (TREE_TYPE (DECL_RESULT (callee)), lhs))
-  || !gimple_check_call_args (call_stmt, callee, args_count_match))
-return false;
-  return true;
+  return types_compatible_p (gimple_call_fntype (call_stmt),
+TREE_TYPE (callee));
 }

 /* Reset all state within cgraph.c so that we can rerun the compiler

[Bug fortran/79229] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
On aarch64 r242068 (Date:   Fri Nov 11 12:53:36 2016 +)
fails with error in gcc/config/aarch64/cortex-a57-fma-steering.c.

I'm going to test merge base of gcc-6-branch and current trunk.

[Bug target/69264] [5/6 regression] ICE building spidermonkey -mcpu=970 -maltivec -O3: rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:4350

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 regression] ICE  |[5/6 regression] ICE
   |building spidermonkey   |building spidermonkey
   |-mcpu=970 -maltivec -O3:|-mcpu=970 -maltivec -O3:
   |rs6000_builtin_vectorizatio |rs6000_builtin_vectorizatio
   |n_cost, at  |n_cost, at
   |config/rs6000/rs6000.c:4350 |config/rs6000/rs6000.c:4350
  Known to fail|6.0 |6.3.0

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

[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 25 13:14:41 2017
New Revision: 244898

URL: https://gcc.gnu.org/viewcvs?rev=244898=gcc=rev
Log:
2017-01-25  Richard Biener  

PR testsuite/72850
* gcc.dg/tree-ssa/pr69270-3.c: Change back expected outcome
to what we had before adding the threading passes.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69270-3.c

[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/79229] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-25
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|[7.0.1 regression] ICE in   |[7 Regression] ICE in
   |gfc_trans_assignment_1 with |gfc_trans_assignment_1 with
   |-fcheck=mem |-fcheck=mem
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r241439.

[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
Testcase for the niter analysis issue:

#define NMAX 3000

static double a[NMAX][NMAX], b[NMAX][NMAX], c[NMAX][NMAX];

void dsyr2k(int N)
{
  int i,j,k;

  if (N > 0)
{
  i = 0;
  do
{
  j = 0;
  do
{
  k = j;
  do
{
  c[j][k] += a[i][j] * b[i][k] + b[i][j] * a[i][k];
  k++;
}
  while (k < N);
  j++;
}
  while (j= N_17(D)
# of iterations ((unsigned int) N_17(D) - (unsigned int) j_11) - 1, bounded
by 2147483646

as it fails to simplify this zero-if condition.  If it would look at
the evolution of j_11 (the IV PHI of the j loop) which is {0, +, 1}_2
it would see together with

Analyzing # of iterations of loop 2
  exit condition [1, + , 1](no_overflow) < N_17(D)
  bounds on difference of bases: 0 ... 2147483646
  result:
# of iterations (unsigned int) N_17(D) + 4294967295, bounded by 2147483646

and thus 1 * (N_17 - 1) >= N_17 is always false.

From the gcc.dg/graphite/scop-dsyr2k.c we now arrive at the above IL via
improved jump threading, optimizing out redundant loop header checks
(but as shown above IVO cannot recover).

[Bug c++/70768] [6/7 Regression] Increased compilation time

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
When comparing r224581 (the first cc1plus that doesn't ICE on the gcc5
preprocessed source) with r244763 cc1plus on the same source (though, both are
checking builds), the latter eats less memory, not more.

[Bug middle-end/79212] [6/7 Regression] internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

[davids at gcc dot gnu.org]

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

--- Comment #5 from davids at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Started with r233913, I'll have a look.

Hi Jakub, just to let you know I posted a possible fix for 7.0 release on the
mailing list yesterday if you want to have a look.

[Bug middle-end/79212] [6/7 Regression] internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r233913, I'll have a look.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #24 from Maxim Ostapenko  ---
(In reply to Tobias Burnus from comment #23)
> (In reply to Tobias Burnus from comment #22)
> > As I recently did some incremental builds, I will retry it after a full
> > bootstrap.
> 
> Didn't make a difference - I still see the ASAN run-time fail. I wonder
> what's different between our systems.

Perhaps you use strict_init_order=true option (e.g.
ASAN_OPTIONS=check_initialization_order=true:report_globals=3:strict_init_order=true)?
 
max@max:~/test-lto/test-2/test$
ASAN_OPTIONS=check_initialization_order=true:report_globals=3:strict_init_order=true
./a.out 
#0 0x41d885 in __asan_register_globals
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326
#1 0x58a3b6 in _GLOBAL__sub_I_00099_1_main.4497
(/home/max/test-lto/test-2/test/a.out+0x58a3b6)
#2 0x58a40c in __libc_csu_init
(/home/max/test-lto/test-2/test/a.out+0x58a40c)
#3 0x7fb4c6568ed4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
#4 0x405f38  (/home/max/test-lto/test-2/test/a.out+0x405f38)

=== ID 1015021569; 0x007c7f60 0x007c8120
==26120==Added Global[0x007c7f60]: beg=0x005a5960 size=1/64
name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==  location (0x007c7f20):
name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.h[0x005a5aa0],
79 35
==26120==Added Global[0x007c7fa0]: beg=0x0142cf20 size=1/64
name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1
==26120==  location (0x007c7f30):
name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 25
==26120==Added Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64
name=xptimer_clean module=xptimer.cc dyn_init=1
==26120==  location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9
==26120==Added Global[0x007c8020]: beg=0x0142cf60 size=16/64
name=xptimer_sweep module=xptimer.cc dyn_init=1
==26120==  location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9
==26120==Added Global[0x007c8060]: beg=0x005a5a60 size=14/64 name=*.LC3
module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Added Global[0x007c80a0]: beg=0x005a59e0 size=12/64 name=*.LC1
module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Added Global[0x007c80e0]: beg=0x005a59a0 size=11/64 name=*.LC0
module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Added Global[0x007c8120]: beg=0x005a5a20 size=14/64 name=*.LC2
module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
DynInitPoison module: xptimer.cc
DynInitPoison module: xptiming.cc
=
==26120==Search Global[0x007c8120]: beg=0x005a5a20 size=14/64
name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Search Global[0x007c80e0]: beg=0x005a59a0 size=11/64
name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Search Global[0x007c80a0]: beg=0x005a59e0 size=12/64
name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Search Global[0x007c8060]: beg=0x005a5a60 size=14/64
name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==Search Global[0x007c8020]: beg=0x0142cf60 size=16/64
name=xptimer_sweep module=xptimer.cc dyn_init=1
==26120==  location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9
==26120==Search Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64
name=xptimer_clean module=xptimer.cc dyn_init=1
==26120==  location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9
==26120==Search Global[0x007c7fa0]: beg=0x0142cf20 size=1/64
name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1
==26120==  location (0x007c7f30):
name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 25
==26120==Search Global[0x007c7f60]: beg=0x005a5960 size=1/64
name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0
==26120==  location (0x007c7f20):
name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.h[0x005a5aa0],
79 35
==26120==ERROR: AddressSanitizer: initialization-order-fiasco on address
0x0142cf68 at pc 0x0058a25c bp 0x7ffc44459250 sp 0x7ffc44459230
WRITE of size 1 at 0x0142cf68 thread T0
#0 0x58a25b in __base_ctor  /home/max/test-lto/test-2/test/xptimer.cc:12
#1 0x58a349 in __static_initialization_and_destruction_0
/home/max/test-lto/test-2/test/xptiming.cc:6
#2 0x58a377 in _GLOBAL__sub_I__ZN6xp_aux13xptimer_sweepE
/home/max/test-lto/test-2/test/xptiming.cc:9
#3 0x58a40c in __libc_csu_init
(/home/max/test-lto/test-2/test/a.out+0x58a40c)
#4 0x7fb4c6568ed4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
#5 0x405f38  (/home/max/test-lto/test-2/test/a.out+0x405f38)

0x0142cf68 is located 8 bytes inside of global variable 'xptimer_sweep'
defined in 'xptiming.cc:6:9' (0x142cf60) of size 16
  registered at:
#0 0x41d62c in __asan_register_globals

[Bug lto/70929] [5/6/7 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Honza, any progress on this?

[Bug c++/70768] [6/7 Regression] Increased compilation time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Well, you are comparing apples and oranges here, given that for each gcc
version you have different preprocessed source, and libstdc++ keeps changing,
it might very well be that in the headers there is just more templates etc.  It
can be even seen on the size of the preprocessed sources, the 5.3 is 300KB
shorter.
Trying to bisect the memory consumption is not possible, because r222000 up to
r224000 + plus something all ICE on the gcc 5 preprocessed source.

[Bug target/69264] [5/6/7 regression] ICE building spidermonkey -mcpu=970 -maltivec -O3: rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:4350

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 25 12:30:41 2017
New Revision: 244897

URL: https://gcc.gnu.org/viewcvs?rev=244897=gcc=rev
Log:
2017-01-25  Richard Biener  

PR tree-optimization/69264
* target.def (vector_alignment_reachable): Improve documentation.
* doc/tm.texi: Regenerate.
* targhooks.c (default_builtin_vector_alignment_reachable): Simplify
and add a comment.
* tree-vect-data-refs.c (vect_supportable_dr_alignment): Revert
earlier changes with respect to TYPE_USER_ALIGN.
(vector_alignment_reachable_p): Likewise.  Improve dumping.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr69264.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/tm.texi
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c