[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima  ---
I've applied a quick fix.  I'd like to keep this open for further
checks.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima  ---
Author: kkojima
Date: Tue Jan 17 04:07:51 2017
New Revision: 244516

URL: https://gcc.gnu.org/viewcvs?rev=244516=gcc=rev
Log:
PR target/78633
* config/sh/sh.md (cmpeqsi_t+1): Call copy_rtx to avoid invalid
RTL sharing.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #8 from Alan Modra  ---
Fixed

[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic

[amodra at gcc dot gnu.org]

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

--- Comment #7 from Alan Modra  ---
Author: amodra
Date: Tue Jan 17 02:54:11 2017
New Revision: 244515

URL: https://gcc.gnu.org/viewcvs?rev=244515=gcc=rev
Log:
PR79066, non-PIC code generated for powerpc glibc with -fpic

PR target/79066
* config/rs6000/rs6000.md (elf_high, elf_low): Disable when pic.
* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Don't allow
symbolic stack limit when pic.
testsuite/
* gcc.target/powerpc/pr79066.c: New.

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

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #1)
> IMNSHO the GCC behavior is the right thing to do, that is how the source
> looks like.  If the preprocessed file has been hand-edited, it is just a
> user bug.

I disagree.  Suppose the translation unit comes from a header from version X of
software installed on the system it was obtained on by a user (say a bug
submitter).  Suppose version Y of the same software is installed on the system
where the translation unit is being compiled (say by whoever is debugging it
for the user).  Then even when it isn't edited, diagnostics that point into the
header included in the translation unit will print potentially unrelated lines
from the header where the translation unit is being compiled.  That's just
wrong.  GCC should print the code from the translation unit, not some unrelated
files that just happen to have the same name as those referenced in it.

[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 #12 from Jan Hubicka  ---
Created attachment 40526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40526=edit
Patch I am testing

The profile is quite inconsistent since thread1.
The problem is that duplicate_thread_path does
  if (total_count)  
{   
  scale_bbs_frequencies_gcov_type (region, n_region,
   total_count - entry_count,   
   total_count);
  scale_bbs_frequencies_gcov_type (region_copy, n_region, entry_count,  
   total_count);
}   
  else  
{   
  scale_bbs_frequencies_int (region, n_region, total_freq - entry_freq, 
 total_freq);   
  scale_bbs_frequencies_int (region_copy, n_region, entry_freq,
total_freq);
}   

This is wrong when the duplicated path have extra entries that are not
duplicated which happens in the testcase.

The attached patch fixes it.  It is still not 100% correct as the outgoing
probabilities of the original path should be updated based on the path being
copied out, but I am not sure it is worth the trouble (and risk of roundoff
errors). I will think a bit more about this tomorrow.

[Bug demangler/79111] New: demangle_template tries to allocate 18446744070799748648 bytes

[ppluzhnikov at google dot com]

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

Bug ID: 79111
   Summary: demangle_template tries to allocate
18446744070799748648 bytes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com
  Target Milestone: ---

Test case from LLVM libFuzzer.

Using current trunk binutils (libiberty identical to current trunk GCC
r244514):

cxxfilt __H209__nuDD2
cxxfilt: out of memory allocating 18446744070799748648 bytes after a total of
135168 bytes

(gdb) b __libc_malloc if bytes > 1
Breakpoint 2 at 0x77893660: file malloc.c, line 2876.
(gdb) c
Continuing.

Breakpoint 2, __GI___libc_malloc (bytes=140737488345896) at malloc.c:2876
2876malloc.c: No such file or directory.
(gdb) up 2
#2  0x007bd246 in demangle_template (work=work@entry=0x7fffdba0,
mangled=mangled@entry=0x7fffdb28, tname=tname@entry=0x7fffdb40,
trawname=trawname@entry=0x0, is_type=is_type@entry=0,
remember=remember@entry=0)
at ../../libiberty/cplus-dem.c:2232
2232  work->tmpl_argvec = XNEWVEC (char *, r);
(gdb) p r
$1 = -363725371

(gdb) bt
#0  __GI___libc_malloc (bytes=140737488345896) at malloc.c:2876
#1  0x007d1158 in xmalloc (size=18446744070799748648) at
../../libiberty/xmalloc.c:147
#2  0x007bd246 in demangle_template (work=work@entry=0x7fffdba0,
mangled=mangled@entry=0x7fffdb28, tname=tname@entry=0x7fffdb40,
trawname=trawname@entry=0x0, is_type=is_type@entry=0,
remember=remember@entry=0)
at ../../libiberty/cplus-dem.c:2232
#3  0x007c05e6 in demangle_signature (work=work@entry=0x7fffdba0,
mangled=mangled@entry=0x7fffdb28, declp=declp@entry=0x7fffdb40) at
../../libiberty/cplus-dem.c:1695
#4  0x007c1435 in internal_cplus_demangle
(work=work@entry=0x7fffdba0, mangled=0x7fffe0af "_nuDD2",
mangled@entry=0x7fffe0a0 "__H209__nuDD2") at
../../libiberty/cplus-dem.c:1261
#5  0x007bc492 in cplus_demangle (mangled=0x7fffe0a0
"__H209__nuDD2", options=11) at ../../libiberty/cplus-dem.c:922
#6  0x00405644 in demangle_it (mangled_name=0x7fffe0a0
"__H209__nuDD2") at ../../binutils/cxxfilt.c:62
#7  0x0040525c in main (argc=2, argv=0x7fffdd88) at
../../binutils/cxxfilt.c:227


Should get_count() check for int overflow?

[Bug regression/53203] [5/6/7 Regression]: gcc.dg/setjmp-1.c

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from Hans-Peter Nilsson  ---
I guess it's of no use keeping this PR open if it
- gets on people's radars just for being open
- is hidden since long (with no known reproducer)
- has been out of the reporter's mind for at least four years
- triggers the reporter to sheepishly list at least three reasons to close it
Thus closed.  I guess WORKSFORME fits best.

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

[wdijkstr at arm dot com]

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

--- Comment #31 from Wilco  ---
(In reply to Jan Hubicka from comment #30)
> > 
> > When I looked at gap at the time, the main change was the reordering of a 
> > few
> > if statements in several hot functions. Incorrect block frequencies also 
> > change
> > register allocation in a bad way, but I didn't notice anything obvious in 
> > gap.
> > And many optimizations are being disabled on blocks with an incorrect 
> > frequency
> > - this happens all over the place and is the issue causing the huge Coremark
> > regression.
> 
> This is the issue with jump threading code no longer sanely updating profile,
> right?  I will try to find time to look into it this week.

I don't know the exact details but James proved that the blocks are incorrectly
assumed cold so part of the optimization doesn't trigger as expected. I'm not
sure whether that is because the frequencies got too low, set incorrectly or
not set at all. 

> > I could do some experiments but I believe the key underlying problem is that
> > GCC treats the block frequencies as accurate when they are really very vague
> > estimates (often incorrect) and so should only be used to break ties.
> > 
> > In fact I would claim that even modelling if-statements as a balanced 50/50 
> > is
> > incorrect. It suggests that a block that is guarded by multiple 
> > if-statements
> > handling exceptional cases is much less important than the very same block 
> > that
> > isn't, even if they are both always executed. Without profile data providing
> > actual frequencies we should not optimize the outer block for speed and the
> > inner block for size.
> 
> There are --param options to control this. They was originally tuned based on
> Spec2000 and x86_64 scores (in GCC 3.x timeframe). if you can get resonable
> data that they are not working very well anymore (or for ARM), we could try
> to
> tune them better.
> 
> I have WIP patches to get the propagation bit more fine grained and
> propagate i.e.
> info if BB is reachable only bo known to be cold path (such that one that has
> EH edge on it). This may make the logic bit more reliable.

I'll have a look, but I think the key is to think in terms of block importance
(from cold to hot). Apart from highly skewed cases (eg. exception edges or
loops), most blocks should be equally important to optimize.

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

[hubicka at ucw dot cz]

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

--- Comment #30 from Jan Hubicka  ---
> 
> When I looked at gap at the time, the main change was the reordering of a few
> if statements in several hot functions. Incorrect block frequencies also 
> change
> register allocation in a bad way, but I didn't notice anything obvious in gap.
> And many optimizations are being disabled on blocks with an incorrect 
> frequency
> - this happens all over the place and is the issue causing the huge Coremark
> regression.

This is the issue with jump threading code no longer sanely updating profile,
right?  I will try to find time to look into it this week.
> 
> I could do some experiments but I believe the key underlying problem is that
> GCC treats the block frequencies as accurate when they are really very vague
> estimates (often incorrect) and so should only be used to break ties.
> 
> In fact I would claim that even modelling if-statements as a balanced 50/50 is
> incorrect. It suggests that a block that is guarded by multiple if-statements
> handling exceptional cases is much less important than the very same block 
> that
> isn't, even if they are both always executed. Without profile data providing
> actual frequencies we should not optimize the outer block for speed and the
> inner block for size.

There are --param options to control this. They was originally tuned based on
Spec2000 and x86_64 scores (in GCC 3.x timeframe). if you can get resonable
data that they are not working very well anymore (or for ARM), we could try to
tune them better.

I have WIP patches to get the propagation bit more fine grained and propagate
i.e.
info if BB is reachable only bo known to be cold path (such that one that has
EH edge on it). This may make the logic bit more reliable.

Honza

[Bug c/79110] New: FAIL: gcc.dg/format/pr78304.c (test for warnings, line 9)

[danglin at gcc dot gnu.org]

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

Bug ID: 79110
   Summary: FAIL: gcc.dg/format/pr78304.c (test for warnings,
line 9)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/format/pr78304.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -Wall -Wextra -S
-o pr78304.s(timeout = 300)spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/format/pr78304.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -Wall -Wextra -S -o
pr78304.s
FAIL: gcc.dg/format/pr78304.c (test for warnings, line 9)
PASS: gcc.dg/format/pr78304.c(test for excess errors)Executing on host:
/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/format/pr78304.c-fno-diag
nostics-show-caret -fdiagnostics-color=never-DWIDE  -O2 -Wall -Wextra -S -o 
pr78304.s(timeout = 300)spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/format/pr78304.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -DWIDE -O2 -Wall -Wextra
-S -o pr783
04.s
FAIL: gcc.dg/format/pr78304.c   -DWIDE   (test for warnings, line 9
PASS: gcc.dg/format/pr78304.c   -DWIDE  (test for excess errors)

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

[wdijkstr at arm dot com]

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

--- Comment #29 from Wilco  ---
(In reply to Jan Hubicka from comment #28)
> > On SPEC2000 the latest changes look good, compared to the old predictor gap
> > improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.
> 
> It is rather surprising you are seeing such large changes for one branch
> predictor
> change.  Is most of it really comming just from the bb-reorder changes? On
> x86 the
> effect is mostly within noise and on Itanium Gap improve by 2-3%.
> It may be interesting to experiment with reorderin and prediction more on
> this target.

When I looked at gap at the time, the main change was the reordering of a few
if statements in several hot functions. Incorrect block frequencies also change
register allocation in a bad way, but I didn't notice anything obvious in gap.
And many optimizations are being disabled on blocks with an incorrect frequency
- this happens all over the place and is the issue causing the huge Coremark
regression.

I could do some experiments but I believe the key underlying problem is that
GCC treats the block frequencies as accurate when they are really very vague
estimates (often incorrect) and so should only be used to break ties.

In fact I would claim that even modelling if-statements as a balanced 50/50 is
incorrect. It suggests that a block that is guarded by multiple if-statements
handling exceptional cases is much less important than the very same block that
isn't, even if they are both always executed. Without profile data providing
actual frequencies we should not optimize the outer block for speed and the
inner block for size.

[Bug c/79109] New: FAIL: gcc.dg/attr-alloc_size-4.c (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 79109
   Summary: FAIL: gcc.dg/attr-alloc_size-4.c (test for excess
errors)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c   
-fno-d
iagnostics-show-caret -fdiagnostics-color=never   -O2 -Wall
-Walloc-size-larger-
than=1234 -S -o attr-alloc_size-4.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
-fno-di
agnostics-show-caret -fdiagnostics-color=never -O2 -Wall
-Walloc-size-larger-tha
n=1234 -S -o attr-alloc_size-4.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c: In function
'te
st_uint_cst':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:84:3: warning:
a
rgument 1 value '1235' exceeds maximum object size 1234
[-Walloc-size-larger-tha
n=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:20:7: note: in
a
 call to allocation function 'f_uint_1' declared
here/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:85:3:
warning: argument 1 value '4294967294' exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:20:7: note: in
a call to allocation function 'f_uint_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:86:3: warning:
argument 1 value '4294967295' exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:20:7: note: in
a call to allocation function 'f_uint_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c: In function
'test_uint_range':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:101:3: warning:
argument 1 range [1235, 1236] exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:20:7: note: in
a call to allocation function 'f_uint_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c: In function
'test_int_cst':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:112:3: warning:
argument 1 value '-2147483648' is negative [-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:113:3: warning:
argument 1 value '-1' is negative [-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:118:3: warning:
argument 1 value '2147483647' exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c: In function
'test_int_range':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:130:3: warning:
argument 1 range [-2, -1] is negative [-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:132:3: warning:
argument 1 range [1235, 2345] exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:133:3: warning:
argument 1 range [2147483646, 2147483647] exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:138:3: warning:
argument 1 range [1235, 2147483647] exceeds maximum object size 1234
[-Walloc-size-larger-than=]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:22:7: note: in
a call to allocation function 'f_int_1' declared here
/home/dave/gnu/gcc/gcc/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=]

[Bug middle-end/78703] -fprintf-return-value floating point handling incorrect in locales with a mulltibyte decimal point

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01892.html

[Bug tree-optimization/78608] [7 Regression] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
The reported error should be resolved by the minimal patch from comment #3
committed in r244511.  The rest of the bigger patch referenced in comment #5
may be committed separately later.

[Bug tree-optimization/78608] [7 Regression] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Tue Jan 17 00:14:52 2017
New Revision: 244511

URL: https://gcc.gnu.org/viewcvs?rev=244511=gcc=rev
Log:
PR tree-optimization/78608 - gimple-ssa-sprintf.c:570:17: runtime error:
negation of -9223372036854775808 cannot be represented in type 'long int'

gcc/ChangeLog:
* gimple-ssa-sprintf.c (tree_digits): Avoid negating TYPE_MIN.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c

[Bug c++/79095] [7 regression] spurious stringop-overflow warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug c++/79095] [7 regression] spurious stringop-overflow warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The warning is reproducible with the test case below.  The memset call is
inserted by the loop distribution pass.  The pass should avoid inserting
memcpy/memmove/memset calls with excessively large arguments (> SIZE_MAX / 2)
because they are certainly incorrect and, if executed, will lead to buffer
overflow and memory corruption.  I'm testing a patch that inserts a trap
instead.

FWIW, the warning is working as I hoped it would: it's helping find bugs.  In
this case, the problem is exposed by the loop to memset transformation.  The
warning isn't necessarily useful to the user because the code is inserted by
GCC itself but it has exposed an opportunity to both make the generated code
safer (avoid the memory corruption) and more efficient (it can help GCC
generate code based on the assumption that the overflow is unlikely to happen).

$ cat t.ii && gcc -O3 -S -Wall -Wextra -Wpedantic -xc++
-fdump-tree-optimized=/dev/stdout t.ii 
typedef long unsigned int size_t;

inline void
fill (int *p, size_t n, int)
{
  while (n--)
*p++ = 0;
}

struct B
{
  int* p0, *p1, *p2;

  size_t size () const {
return size_t (p1 - p0);
  }

  void resize (size_t n) {
if (n > size())
  append (n - size());
  }

  void append (size_t n)
  {
if (size_t (p2 - p1) >= n)   {
  fill (p1, n, 0);
}
  }
};

void foo (B )
{
  b.resize (b.size () - 1);
}

;; Function void foo(B&) (_Z3fooR1B, funcdef_no=4, decl_uid=2299, cgraph_uid=4,
symbol_order=4)

Removing basic block 6
Removing basic block 7
void foo(B&) (struct B & b)
{
  int * _4;
  int * _5;
  int * _6;
  long int _7;
  long int _8;
  long int _13;
  long int _14;

   [4.91%]:
  _4 = MEM[(int * *)b_3(D)];
  _5 = MEM[(int * *)b_3(D) + 8B];
  _13 = (long int) _5;
  _14 = (long int) _4;
  if (_13 == _14)
goto ; [54.00%]
  else
goto ; [46.00%]

   [2.65%]:
  _6 = MEM[(int * *)b_3(D) + 16B];
  _7 = (long int) _6;
  _8 = _7 - _13;
  if (_8 == -4)
goto ; [37.68%]
  else
goto ; [62.32%]

   [1.00%]:
  __builtin_memset (_5, 0, 18446744073709551612); [tail call]

   [4.91%]:
  return;

}


In function ‘void foo(B&)’:
cc1plus: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 -Wstringop-overflow=]

[Bug bootstrap/78880] [7 Regression] Revision 243196 breaks bootstrap on x86_64-w64-mingw32

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Patch reverted until Tadek can debug/fix.

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at gcc dot gnu.org]

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

--- Comment #16 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 16 23:43:05 2017
New Revision: 244509

URL: https://gcc.gnu.org/viewcvs?rev=244509=gcc=rev
Log:
2017-01-16  Jeff Law  

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-2.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/79090] [7 regression] DSE wrongly removes store at variable offset

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 16 23:43:05 2017
New Revision: 244509

URL: https://gcc.gnu.org/viewcvs?rev=244509=gcc=rev
Log:
2017-01-16  Jeff Law  

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-2.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 16 23:43:05 2017
New Revision: 244509

URL: https://gcc.gnu.org/viewcvs?rev=244509=gcc=rev
Log:
2017-01-16  Jeff Law  

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-2.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/33562] [5/6 Regression] aggregate DSE disabled

[law at gcc dot gnu.org]

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

--- Comment #32 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan 16 23:43:05 2017
New Revision: 244509

URL: https://gcc.gnu.org/viewcvs?rev=244509=gcc=rev
Log:
2017-01-16  Jeff Law  

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

PR tree-optimization/79090
PR tree-optimization/33562
PR tree-optimization/61912
PR tree-optimization/77485
* tree-ssa-dse.c (compute_trims): Accept STMT argument.  Dump STMT
and computed trims into the dump file.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-2.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug fortran/79107] ICE on name resolution within internal subroutine

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
AFAICT this has been fixed between revisions r240001 and r242898.

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

[hubicka at ucw dot cz]

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

--- Comment #28 from Jan Hubicka  ---
> On SPEC2000 the latest changes look good, compared to the old predictor gap
> improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.

It is rather surprising you are seeing such large changes for one branch
predictor
change.  Is most of it really comming just from the bb-reorder changes? On x86
the
effect is mostly within noise and on Itanium Gap improve by 2-3%.
It may be interesting to experiment with reorderin and prediction more on this
target.

Honza

[Bug fortran/57042] Strange typespec with -fdump-parse-tree

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|ICE/Segfault with   |Strange typespec with
   |-fdump-parse-tree   |-fdump-parse-tree

--- Comment #12 from Thomas Koenig  ---
Adjusting bug summary to reflect what is left of the bug.

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
Confirmed and most probably mine.

[Bug driver/49726] [5/6 Regression] -g0 file.S -g does not produce debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] -g0  |[5/6 Regression] -g0 file.S
   |file.S -g does not produce  |-g does not produce debug
   |debug info  |info

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

[Bug target/79080] [7 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn) (error: shared rtx)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/79089] [7 Regression] error: incorrect sharing of tree nodes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Note "--param ggc-min-expand=0 --param ggc-min-heapsize=0" is required to
reproduce the issue.  Otherwise it passes.

[Bug middle-end/79089] [7 Regression] error: incorrect sharing of tree nodes

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 16 21:35:30 2017
New Revision: 244507

URL: https://gcc.gnu.org/viewcvs?rev=244507=gcc=rev
Log:
PR c/79089
* gimplify.c (gimplify_init_constructor): If want_value and
object == lhs, unshare lhs to avoid invalid tree sharing.  Formatting
fix.

* gcc.c-torture/compile/pr79089.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr79089.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79080] [7 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn) (error: shared rtx)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 16 21:34:35 2017
New Revision: 244506

URL: https://gcc.gnu.org/viewcvs?rev=244506=gcc=rev
Log:
PR target/79080
* loop-doloop.c (doloop_modify): Call unshare_all_rtl_in_chain on
sequence.  Formatting fixes.
(doloop_optimize): Formatting fixes.

* gcc.dg/pr79080.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79080.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-doloop.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #11)
> Looks like a GC issue as I was reducing the code but removing the comments
> and empty lines caused the testcase to no longer crash.  Adding --param
> ggc-min-expand=1 --param ggc-min-heapsize=1 allowed it to ICE now.

Oops, I forgot that struct ipa_node_params is not a GTYed structure.  Will do
that first thing tomorrow.

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Andrew Senkevich from comment #10)
> > This commit breaks 5 SPEC CPU 2006 benchmarks (416.gamess, 454.calculix,
> > 459.GemsFDTD, 465.tonto, 481.wrf) with ICE on x86_64 (and looks like on
> > aarch64 the same - https://gcc.gnu.org/ml/gcc/2017-01/msg00126.html).
> 
> Looks like a GC issue as I was reducing the code but removing the comments
> and empty lines caused the testcase to no longer crash.  Adding --param
> ggc-min-expand=1 --param ggc-min-heapsize=1 allowed it to ICE now.

Filed the reduced testcase as PR 79108.

[Bug driver/49726] [5/6/7 Regression] -g0 file.S -g does not produce debug info

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 16 21:33:07 2017
New Revision: 244505

URL: https://gcc.gnu.org/viewcvs?rev=244505=gcc=rev
Log:
PR driver/49726
* gcc.c (debug_level_greater_than_spec_func): New function.
(static_spec_functions): Add debug-level-gt spec function.
(ASM_DEBUG_SPEC, cpp_options): Use %:debug-level-gt(0) instead of
!g0.
* config/darwin.h (DSYMUTIL_SPEC, ASM_DEBUG_SPEC): Likewise.
* config/darwin9.h (DSYMUTIL_SPEC, ASM_DEBUG_SPEC): Likewise.
* common.opt (g, gcoff, gdwarf, gdwarf-, ggdb, gno-pubnames,
gpubnames, ggnu-pubnames, gno-record-gcc-switches,
grecord-gcc-switches, gno-strict-dwarf, gstrict-dwarf, gstabs,
gstabs+, gtoggle, gvms, gxcoff, gxcoff+): Add Driver flag.
c-family/
* c.opt (gen-decls): Add Driver flag.
ada/
* gcc-interface/lang.opt (gant, gnatO, gnat): Add Driver flag.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/lang.opt
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/config/darwin.h
trunk/gcc/config/darwin9.h
trunk/gcc/gcc.c

[Bug ipa/79108] New: [7 Regression] ICE on some fortran code with -flto -Ofast

[pinskia at gcc dot gnu.org]

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

Bug ID: 79108
   Summary: [7 Regression] ICE on some fortran code with -flto
-Ofast
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: GC, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take the following fortran 90 code:
MODULE Errorcheck_mod
CONTAINS
SUBROUTINE Check_open(ios, outputstr, errortype)
character(len=*), intent(in) :: outputstr
if (ios > 0 .AND. errortype == FATAL) then
  write(*,*) 'The value of ios was:', ios
end if
END SUBROUTINE Check_open
END MODULE Errorcheck_mod

 CUT 
Compile it like:
gfortran  -nostdlib -r -Ofast -flto --param ggc-min-expand=0 --param
ggc-min-heapsize=0 errorcheck.f90
You get the following ICE:
lto1: internal compiler error: in ipa_get_type, at ipa-prop.h:448
0x107c737 ipa_get_type
../../gcc/gcc/ipa-prop.h:448
0x107c737 propagate_constants_across_call
../../gcc/gcc/ipa-cp.c:2259
0x10810f7 propagate_constants_topo
../../gcc/gcc/ipa-cp.c:3170
0x10810f7 ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:3267
0x1082173 ipcp_driver
../../gcc/gcc/ipa-cp.c:4997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
   Target Milestone|--- |7.0

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Senkevich from comment #10)
> This commit breaks 5 SPEC CPU 2006 benchmarks (416.gamess, 454.calculix,
> 459.GemsFDTD, 465.tonto, 481.wrf) with ICE on x86_64 (and looks like on
> aarch64 the same - https://gcc.gnu.org/ml/gcc/2017-01/msg00126.html).

Looks like a GC issue as I was reducing the code but removing the comments and
empty lines caused the testcase to no longer crash.  Adding --param
ggc-min-expand=1 --param ggc-min-heapsize=1 allowed it to ICE now.

[Bug target/61729] FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Okay, I'll make it work for SVR4 in the rs6000 backend then.

The generic code makes suboptimal code, many ABIs need to update (even
those that haven't changed for 25 years), and more backends will need
to adjust; but if this is what C++ decided, we'll have to work with that.

Thanks for the confirmation.

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m, pinskia at gmail dot com

--- Comment #10 from Andrew Senkevich  ---
This commit breaks 5 SPEC CPU 2006 benchmarks (416.gamess, 454.calculix,
459.GemsFDTD, 465.tonto, 481.wrf) with ICE on x86_64 (and looks like on aarch64
the same - https://gcc.gnu.org/ml/gcc/2017-01/msg00126.html).

commit 72b16d90bd23d9c5758c165f8258522871c755ff
Author: jamborm 
Date:   Mon Jan 9 18:26:37 2017 +

[PR 78365] Prudent type handling in IPA VR-prop

[Bug jit/69435] Truncated lines in jit.log

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> Followup was here:
>   http://lists.gnu.org/archive/html/dejagnu/2016-02/msg6.html

which is:
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=e3d0bafb18ebf56cad1822dafc4332643903b084

and would appear to be present in DejaGnu 1.6 onwards.

[Bug jit/69435] Truncated lines in jit.log

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Followup was here:
  http://lists.gnu.org/archive/html/dejagnu/2016-02/msg6.html

2016-02-15  Ben Elliston  

Reported by David Malcolm.
* lib/dejagnu.exp (text): Allow angle brackets in test messages.

diff --git a/lib/dejagnu.exp b/lib/dejagnu.exp
index b2ffe40..89016b4 100644
--- a/lib/dejagnu.exp
+++ b/lib/dejagnu.exp
@@ -20,7 +20,7 @@
 # This file was written by Rob Savoye .

 # A hairy pattern to recognize text.
-set text "\[- A-Za-z0-9\.\;\"\_\:\'\`\(\)\!\#\=\+\?\&\*]"
+set text "\[- A-Za-z0-9\.\;\"\_\:\'\`\(\)\!\#\=\+\?\&\*<>]"

 set SIZE size
 if { [which $SIZE] == 0 } {

[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #17 from David Malcolm  ---
(In reply to David Malcolm from comment #12)
> (In reply to David Malcolm from comment #11)
> > Author: dmalcolm
> > Date: Tue Dec 22 22:27:45 2015
> > New Revision: 231919
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=231919=gcc=rev
> > Log:
> > PR c/68473: sanitize source range-printing within certain macro expansions
> 
> This commit corresponds to the patch from comment #5, rather than the one
> from comment #9.  Keeping this open in the hope of doing a more thorough fix
> for this, but this may need to wait for gcc 7.

I believe the commits in comment #14 and comment #15 address this.

I've verified that both reproducers are fixed; marking this one as resolved.

[Bug fortran/79107] New: ICE on name resolution within internal subroutine

[baradi09 at gmail dot com]

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

Bug ID: 79107
   Summary: ICE on name resolution within internal subroutine
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

I get an ICE on the minimal self containing input below. Shifting the module
import from within the internal subroutine to the host (program) level avoids
the ICE. Also, enabling the type(Extended) to be public in module mod_test (by
commenting out the private statement in mod_test) avoids the ICE as well.

module mod_base

  type :: Base
  contains
procedure :: init
  end type Base

contains

  subroutine init(this)
class(Base), intent(inout) :: this
continue
  end subroutine init

end module mod_base


module mod_extended
  use mod_base

  type, extends(Base) :: Extended
  end type Extended

end module mod_extended


module mod_test
  use mod_extended
  ! If you comment out the next line, no
  private

  public :: test

contains

  subroutine test(this)
class(Extended), intent(inout) :: this
continue
  end subroutine test

end module mod_test


program prg_test
  use mod_extended

  call run_test()

contains

  subroutine run_test()
! If you import mod_test on the program level, no ICE
use mod_test
type(Extended) :: myExt
!!!
!!! ICE at next line
!!!
call myExt%init()
call test(myExt)

  end subroutine run_test

end program prg_test

[Bug c++/79104] [7.0 regression] ambiguity calling std::begin on a local constexpr array of structs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This changed with r240819.

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
IMNSHO the GCC behavior is the right thing to do, that is how the source looks
like.  If the preprocessed file has been hand-edited, it is just a user bug.

[Bug preprocessor/79106] New: wrong source line printed in diagnostics for a translation unit

[msebor at gcc dot gnu.org]

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

Bug ID: 79106
   Summary: wrong source line printed in diagnostics for a
translation unit
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When printing the source file line in diagnostic messages for a translation
unit (a .i or .ii file) GCC uses the source file the translation unit was
created from rather than the translation unit itself.  That can be pretty
confusing for those unaware of this "feature."  (It took me a few minutes to
figure out what was going on while reducing a large translation unit to a small
test case.)

$ (set -x && cat a.c && cat a.i && /build/gcc-5-branch/gcc/xgcc -B
/build/gcc-5-branch/gcc -S a.i)
+ cat a.c
int foo (void) {
  return -1;
}

+ cat a.i
# 1 "a.c"
int foo (void) {
  return "";
}
+ /build/gcc-5-branch/gcc/xgcc -B /build/gcc-5-branch/gcc -S a.i
a.c: In function ‘foo’:
a.c:2:10: warning: return makes integer from pointer without a cast
[-Wint-conversion]
   return -1;
  ^

Clang, in contrast, prints the contents of translation unit as one would
presumably expect as I do:

$ clang -S a.i
a.c:2:10: warning: incompatible pointer to integer conversion returning
  'char [1]' from a function with result type 'int' [-Wint-conversion]
  return "";
 ^~
1 warning generated.

[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

Maxim Ostapenko  changed:

   What|Removed |Added

  Attachment #40514|0   |1
is obsolete||

--- Comment #12 from Maxim Ostapenko  ---
Created attachment 40525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40525=edit
Untested fix 2.

The patch I'm testing now.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

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

Untested patch that fixes the ICE on this testcase by marking directly called
functions as needed.  Will see what will it do with the size of the debug info.
Of course, it is not sufficient, with -fdebug-types-section we can still ICE
unless the earlier patch is also applied 9or some more sophisticated one to
construct skeleton DIEs if type inside of type unit is detected).

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||vehre at gcc dot gnu.org
  Component|middle-end  |fortran
Summary|ICE when mixing |ICE when mixing
   |"-fprofile-arcs |"-fprofile-arcs
   |-ftest-coverage" and|-ftest-coverage" and
   |"-fcoarray=lib" |"-fcoarray=lib" on gcc-6
   ||only
 Ever confirmed|0   |1

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #23 from Vladimir Makarov  ---
Thanks for reporting and investigation this problem.  I've just started to work
on this PR.

[Bug target/79105] New: Autovectorized NEON code slower than vfpv4 on Cortex A5

[tulipawn at gmail dot com]

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

Bug ID: 79105
   Summary: Autovectorized NEON code slower than vfpv4 on Cortex
A5
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

As the title says, many results seem to suffer from switching to -mfpu=neon,
etc.

http://openbenchmarking.org/result/1701165-TA-1701143TA78

Could anyone explain the abnormally small difference between armv7 and aarch64
in OpenSSL?

[Bug c/78304] [7 Regression] -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jan 16 18:08:45 2017
New Revision: 244502

URL: https://gcc.gnu.org/viewcvs?rev=244502=gcc=rev
Log:
Fix testcases for PR c/78304

The testcases as written made assumptions about size_t and long
being invalid for use with "%u".

We only need some invalid type, so this patch converts them to
attempt a "const char *" with "%u", which should be invalid for
every target.

gcc/testsuite/ChangeLog:
PR c/78304
* gcc.dg/format/pr78304.c: Convert argument from integral type
to a pointer.
* gcc.dg/format/pr78304-2.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/pr78304-2.c
trunk/gcc/testsuite/gcc.dg/format/pr78304.c

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

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Compiling the test in comment 0 with -fcoarray=lib -lcaf_single at r244453
fails at link time with

Undefined symbols for architecture x86_64:
  "_caf_token.0.3515", referenced from:
  __caf_init.1.3517 in ccsoo9HI.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

[Bug fortran/79097] coarray and pointer component

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||vehre at gcc dot gnu.org
   Host|x86_64-apple-darwin15.6.0   |
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from vehre at gcc dot gnu.org ---
The memory pointing to is not registered correctly with coarrays.

[Bug c++/79104] [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
As a couple of additional data points EDG 4.11 and IBM XLC++ both reject the
test case.  EDG with an error similar to GCC.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Now, even going through all cgraph edges and marking the callee DIEs as used
(setting die_mark for them) early (but I guess it would be better to do the
early finish then after early optimizations, but before free_lang_data) would
help in this particular case, but not when we only need devirtualization or
later optimizations to turn indirect calls into direct calls.
Creating a skeleton DIE tree in resolve_addr is yet another option, but I'm not
very familiar with the break_out_comdat_types details (generate_skeleton and
the like) to know how difficult it would be exactly.  Though, for LTO we'll
need to figure out anyway where to create those.

[Bug c++/79104] [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56973

--- Comment #1 from Martin Sebor  ---
See bug 56973 for the original test case.

[Bug c++/79104] New: [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

Bug ID: 79104
   Summary: [7.0 regression] ambiguity calling std::end on a local
constexpr array of structs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The program below reduced from the test case for bug 56973 compiles
successfully with GCC 6 (in addition to Clang and Oracle Solaris Studio) but
fails with the current trunk of GCC 7.0 (and also EDG 4.11).  Making the array
static or moving the declaration to namespace scope resolves the error. 
Changing the array from one of structs to one of characters also works.

$ cat u.C && g++ u.C
template 
inline auto
begin (C& c) -> decltype (c.begin ());

template 
inline constexpr T*
begin (T ()[N]) { return a; }

void f ()
{
  constexpr struct { const char *s; } a[] = { { "a" } };

  auto i = begin (a);

  auto test=[&]() {
i = begin (a);
  };
}
u.C: In lambda function:
u.C:16:17: error: no matching function for call to ‘begin(const f():: [1])’
 i = begin (a);
 ^
u.C:3:1: note: candidate: template decltype (c.begin()) begin(C&)
 begin (C& c) -> decltype (c.begin ());
 ^
u.C:3:1: note:   template argument deduction/substitution failed:
u.C: In substitution of ‘template decltype (c.begin()) begin(C&) [with
C = const f():: [1]]’:
u.C:16:17:   required from here
u.C:3:29: error: request for member ‘begin’ in ‘c’, which is of non-class type
const f():: [1]’
 begin (C& c) -> decltype (c.begin ());
   ~~^
u.C:7:1: note: candidate: constexpr T* begin(T (&)[N]) [with T = const
f()::; long unsigned int N = 1]
 begin (T ()[N]) { return a; }
 ^
u.C:7:1: note:   no known conversion for argument 1 from ‘const f():: [1]’ to ‘const f():: (&)[1]’

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
The effort is quite significant, because several support functions have to be
ported from other commits. I.e., I do not want to spend too much time on it.

[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 #27 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #26)
> Hello, did the Gap scores on arm too? Both Itanium and PPC testers seems to
> show improved gap scores, so hope arm and the other ppc tester too.

On SPEC2000 the latest changes look good, compared to the old predictor gap
improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The important thing is that it is only possible to refer to a single DIE in the
type unit (.debug.types.* in DWARF4, .debug_info DW_UT_type unit in DWARF5);
in the #c0 case it is the Bar DW_TAG_structure_type, a child of
DW_TAG_unit_type.
If one needs to refer to anything else, the DIE with selected needed children
needs to be copied from the type unit to the compilation unit.
So if you e.g. look at what debug info we generate for:
struct Bar { void Baz (); int i; };
Bar b;
void Foo (Bar ) { t.Baz (); }
(compile with -g -fdebug-types-section -O2 -dA -gstrict-dwarf, the last option
so that it doesn't ICE), and
struct Bar { void Baz (); static int i; };
int Bar::i = 17;
Bar b;
void Foo (Bar ) { t.Baz (); }
(compile with -g -fdebug-types-section -O2 -dA), you'll see that in the former
case we don't know about any references to Bar::Baz and everything that needs
Bar only needs Bar itself and thus there is the type unit, the b variable's
DW_AT_type uses DW_FORM_ref_sig8 to refer to the Bar DIE in the type unit and
similarly DW_TAG_reference_type's DW_AT_type (used in t's type).
Without -gstrict-dwarf there is a need for the reference to Bar::Baz that can't
refer to the type unit, but we don't know about that reference during early
debug finish.
Now compare that to the second case.  We need to refer to Bar::i, because we
provide a definition for that.  So there is a skeleton DW_TAG_structure_type in
the compilation unit for Bar type, with DW_AT_signature that says for anything
not mentioned here, refer to the type unit's Bar.  This testcase doesn't ICE
without -gstrict-dwarf.

[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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-16
 CC||mpf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dgilmore at mips dot com
 Ever confirmed|0   |1

--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Maciej W. Rozycki from comment #11)
> TBH this does look like trying to rely on UB to me, as per section
> 6.5.6 "Additive operators" clause 8 of the C language standard, which
> states (among others):
> 
> "If both the pointer operand and the result point to elements of the
> same array object, or one past the last element of the array object,
> the evaluation shall not produce an overflow; otherwise, the behavior
> is undefined."
> 
> Here under the triggering conditions the pointer the integer is added
> to with LDXC1 does not point to an element of the array operated on (or
> to one past the last), so the hardware operation matches the standard's
> semantics WRT overflow and I don't think we ought to be pushing it.

Aren't language rules mostly irrelevant at this stage though?
We don't really have the concept of a pointer after generating RTL we just
happen to have some values in a mode that is the same as Pmode.

mips.h comment for Pmode:

/* Specify the machine mode that pointers have.
   After generation of rtl, the compiler makes no further distinction
   between pointers and any other objects of this machine mode.  */

> So it looks like a middle end bug to me and the backend is fine in
> faithfully assuming its RTL pattern won't be passed operands leading to
> UB.

I can't see any feature/option/setting that gives this guarantee. Why do you
think the backend can make this assumption?

[Bug target/61729] FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
FWIW, new C floating-point types such as _Float16 and _Float32 are not 
promoted in variable arguments either, which has required a few back-end 
changes.  Complex types such as _Complex float or _Complex char never are 
promoted, but for a long time it seems we weren't testing those in 
variable arguments either (I'm not sure if we now have tests for such 
types in variable arguments).

So it's consistent with that to have unpromoted new C++ types (and 
presumably naming those types in va_arg needs to work correctly), but they 
might well cause more problems than the above examples.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #9 from Zaak  ---
Will this fix get back ported to the 6 and 5 branches?

[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 #11 from Maxim Ostapenko  ---
(In reply to Maxim Ostapenko from comment #10)
> Yeah, but it seems that lto doesn't propagate source location either:
> 
> /* Output info about new location into bitpack BP.
>After outputting bitpack, lto_output_location_data has
>to be done to output actual data.  */
> 
> void
> lto_output_location (struct output_block *ob, struct bitpack_d *bp,
>  location_t loc)
> {
>   expanded_location xloc;
> 
>   loc = LOCATION_LOCUS (loc);
>   bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
> loc < RESERVED_LOCATION_COUNT
> ? loc : RESERVED_LOCATION_COUNT);
>   if (loc < RESERVED_LOCATION_COUNT)
> return;
> 
> [...]
> }
> 
> where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
> We can probably teach it to propagate source location but is it OK for
> current stage?

Hm, attached patch seems to propagate source location normally:

diff --git a/gcc/tree-streamer-in.c b/gcc/tree-streamer-in.c
index 3496df5..714a5b1 100644
--- a/gcc/tree-streamer-in.c
+++ b/gcc/tree-streamer-in.c
@@ -405,6 +405,7 @@ unpack_ts_translation_unit_decl_value_fields (struct
data_in *data_in,
  struct bitpack_d *bp, tree expr)
 {
   TRANSLATION_UNIT_LANGUAGE (expr) = xstrdup (bp_unpack_string (data_in, bp));
+  DECL_SOURCE_LOCATION (expr) = stream_input_location_now (bp, data_in);
   vec_safe_push (all_translation_units, expr);
 }

diff --git a/gcc/tree-streamer-out.c b/gcc/tree-streamer-out.c
index 0ee2abe..3c11d61 100644
--- a/gcc/tree-streamer-out.c
+++ b/gcc/tree-streamer-out.c
@@ -359,6 +359,7 @@ pack_ts_translation_unit_decl_value_fields (struct
output_block *ob,
struct bitpack_d *bp, tree expr)
 {
   bp_pack_string (ob, bp, TRANSLATION_UNIT_LANGUAGE (expr), true);
+  stream_output_location (ob, bp, DECL_SOURCE_LOCATION (expr));
 }


diff --git a/gcc/tree.c b/gcc/tree.c
index cffa36d..ee611e2 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4758,7 +4758,9 @@ vec *all_translation_units;
 tree
 build_translation_unit_decl (tree name)
 {
-  tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL,
+  linemap_add (line_table, LC_ENTER, false, main_input_filename, 1);
+  location_t loc = linemap_line_start (line_table, 1, 0);
+  tree tu = build_decl (loc, TRANSLATION_UNIT_DECL,
name, NULL_TREE);
   TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name;
   vec_safe_push (all_translation_units, tu);

The only issue is failing diagnostic test now:
/home/max/workspace/downloads/gcc/gcc/diagnostic.c:1557:
test_print_parseable_fixits_insert: FAIL: ASSERT_STREQ
("fix-it:\"test.c\":{5:10-5:10}:\"added content\"\n", pp_formatted_text ())
expected="fix-it:"test.c":{5:10-5:10}:"added content"
" actual="fix-it:"/dev/null":{33:10-33:10}:"added content"
"

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #29 from Jonathan Wakely  ---
GCC 7 will throw the new ios_base::failure type (unless built so the cxx11 ABI
is completely disabled).

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 16 15:58:06 2017
New Revision: 244498

URL: https://gcc.gnu.org/viewcvs?rev=244498=gcc=rev
Log:
PR66145 use new ABI for std::ios::failure exceptions

PR libstdc++/66145
* src/c++11/functexcept.cc: Use new ABI for std::ios_base::failure
exceptions.
* testsuite/27_io/basic_ios/copyfmt/char/1.cc: Don't override ABI
for test, so new ios::failure can be caught.
* testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/ios_base/storage/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/functexcept.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc

[Bug tree-optimization/79054] missing range information with INT_MAX

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
I committed r244497 to avoid exercising the test case on that line on
non-x86_64 targets.  It passes on x86_64 with the native compiler and with a
sparc-sun-solaris2.11 cross-compiler, in both ILP32 and LP64 modes.

This bug tracks the GCC bug that causes the test assertion failure.  If there
are any other failures in this particular assertion they should probably be
brought up in bug 79051 which tracked the failing assertion for this test case
(now caused by the ineffective/incomplete target directive and the missing
preprocessor guard).  If any other assertions in the test fail I think it would
be best to open a separate bug for those since they are likely unrelated to
this bug.

[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 #7 from Martin Sebor  ---
Author: msebor
Date: Mon Jan 16 15:50:47 2017
New Revision: 244497

URL: https://gcc.gnu.org/viewcvs?rev=244497=gcc=rev
Log:
PR testsuite/79051 - FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line
140)

gcc/testsuite/ChangeLog:
* gcc.dg/attr-alloc_size-4.c: Avoid exercising a test case except
on x86.


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

[Bug c++/79103] [7 Regression] build_variant_type_copy ICE

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Yes, I noticed, patch reverted, sorry.

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Bug 79103 Summary: [7 Regression] build_variant_type_copy ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79103

   What|Removed |Added

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

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6 Regression] ICE|[5/6/7 Regression] ICE
   |following 2x pack expansion |following 2x pack expansion
   |in non-pack with template   |in non-pack with template
   |alias   |alias

--- Comment #9 from Paolo Carlini  ---
Patch reverted, unfortunately,
tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc regresses.

[Bug c++/71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jan 16 15:43:06 2017
New Revision: 244496

URL: https://gcc.gnu.org/viewcvs?rev=244496=gcc=rev
Log:
/c-family
2017-01-16  Paolo Carlini  

Revert:
2017-01-16  Paolo Carlini  

PR c++/71737
* c-common.c (set_underlying_type): Always set DECL_ORIGINAL_TYPE.

/testsuite
2017-01-16  Paolo Carlini  

Revert:
2017-01-16  Paolo Carlini  

PR c++/71737
* g++.dg/cpp0x/pr71737.C: New.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr71737.C

[Bug c++/79103] [7 Regression] build_variant_type_copy ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
 Ever confirmed|0   |1

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

[Bug c++/79103] New: [7 Regression] build_variant_type_copy ICE

[dje at gcc dot gnu.org]

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

Bug ID: 79103
   Summary: [7 Regression] build_variant_type_copy ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
Blocks: 71737
  Target Milestone: ---
Target: powerpc-ibm-aix*

The patch for PR 71737 introduced a new regression in libstdc++

libstdc++-v3/include/tr1/shared_ptr.h:556: internal compiler error:
tree check: expected class 'type', have 'exceptional' (error_mark) in
build_variant_type_copy, at tree.c:6737


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71737
[Bug 71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with
template alias

[Bug bootstrap/78616] Poison strndup in system.h

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #15 from David Malcolm  ---
(In reply to Jeffrey A. Law from comment #12)
> Regression fixed (regression marker removed).  All that's left is to poison
> strndup in system.h

Poisoned in r244494; marking this PR as resolved.

[Bug bootstrap/78616] Poison strndup in system.h

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jan 16 15:03:41 2017
New Revision: 244494

URL: https://gcc.gnu.org/viewcvs?rev=244494=gcc=rev
Log:
system.h: Poison strndup (PR bootstrap/78616)

gcc/ChangeLog:
PR bootstrap/78616
* system.h: Poison strndup.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/system.h

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Perhaps we could combine the #c1 patch with some changes to make sure we don't
prune those types that appear in callgraph edges callee contexts?
Is the early finish debug hook called after some minimal cgraph optimizations
(removal of unused functions)?

[Bug c/79102] New: gcc fails to auto-vectorise the product of an array of complex floats

[drraph at gmail dot com]

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

Bug ID: 79102
   Summary: gcc fails to auto-vectorise the product of an array of
complex floats
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drraph at gmail dot com
  Target Milestone: ---

Consider this simple piece of code.

#include 
complex float f(complex float x[]) {
  complex float p = 1.0;
  for (int i = 0; i < 128; i++)
p *= x[i];
  return p;
}

If I compile it with -O3 -march=bdver2 -ffast-math  I get

f:
vmovss  xmm2, DWORD PTR .LC1[rip]
vxorps  xmm1, xmm1, xmm1
lea rax, [rdi+256]
.L2:
vmovss  xmm0, DWORD PTR [rdi+4]
add rdi, 8
vmulss  xmm3, xmm0, xmm2
vmulss  xmm0, xmm0, xmm1
vfmadd132ss xmm1, xmm3, DWORD PTR [rdi-8]
vfmsub132ss xmm2, xmm0, DWORD PTR [rdi-8]
cmp rax, rdi
jne .L2
vmovss  DWORD PTR [rsp-8], xmm2
vmovss  DWORD PTR [rsp-4], xmm1
vmovq   xmm0, QWORD PTR [rsp-8]
ret
.LC1:
.long   1065353216


This is unvectorised code. However if I do the same using float instead, that
is with:

float f(float x[], int n ) {
  float p = 1.0;
  for (int i = 0; i < 32; i++)
p *= x[i];
  return p;
}

I get

vmovups xmm2, XMMWORD PTR [rdi]
vmulps  xmm0, xmm2, XMMWORD PTR [rdi+16]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+32]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+48]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+64]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+80]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+96]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+112]
vpsrldq xmm1, xmm0, 8
vmulps  xmm0, xmm0, xmm1
vpsrldq xmm1, xmm0, 4
vmulps  xmm0, xmm0, xmm1
ret

This is vectorised.

As a test I also the Intel C compiler version 17. In this case the assembly you
get using complex float is however vectorised giving:

f:
mov   rdx, rdi  #4.3
and   rdx, 15   #4.3
movsd xmm0, QWORD PTR p.152.0.0.1[rip]  #3.19
test  dl, dl#4.3
je..B1.4# Prob 50%  #4.3
test  dl, 7 #4.3
jne   ..B1.12   # Prob 10%  #4.3
movsd xmm0, QWORD PTR [rdi] #5.10
mov   dl, 1 #4.3
..B1.4: # Preds ..B1.3 ..B1.1
movzx eax, dl   #4.3
neg   dl#4.3
and   dl, 3 #4.3
movzx edx, dl   #4.3
movss xmm1, DWORD PTR .L_2il0floatpacket.0[rip] #3.19
neg   rdx   #4.3
movlhps   xmm0, xmm1#3.19
add   rdx, 128  #4.3
..B1.5: # Preds ..B1.5 ..B1.4
movapsxmm2, xmm0#5.5
movupsxmm1, XMMWORD PTR [rdi+rax*8] #5.10
shufpsxmm2, xmm0, 160   #5.5
mulps xmm2, xmm1#5.5
xorps xmm1, XMMWORD PTR .L_2il0floatpacket.1[rip]   #5.5
shufpsxmm1, xmm1, 177   #5.5
shufpsxmm0, xmm0, 245   #5.5
mulps xmm1, xmm0#5.5
movupsxmm3, XMMWORD PTR [16+rdi+rax*8]  #5.10
add   rax, 4#4.3
addps xmm2, xmm1#5.5
movapsxmm0, xmm2#5.5
shufpsxmm0, xmm2, 160   #5.5
mulps xmm0, xmm3#5.5
xorps xmm3, XMMWORD PTR .L_2il0floatpacket.1[rip]   #5.5
shufpsxmm3, xmm3, 177   #5.5
shufpsxmm2, xmm2, 245   #5.5
mulps xmm3, xmm2#5.5
addps xmm0, xmm3#5.5
cmp   rax, rdx  #4.3
jb..B1.5# Prob 99%  #4.3
movapsxmm1, xmm0#3.19
movhlps   xmm1, xmm0 

[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 #10 from Maxim Ostapenko  ---
Yeah, but it seems that lto doesn't propagate source location either:

/* Output info about new location into bitpack BP.
   After outputting bitpack, lto_output_location_data has
   to be done to output actual data.  */

void
lto_output_location (struct output_block *ob, struct bitpack_d *bp,
 location_t loc)
{
  expanded_location xloc;

  loc = LOCATION_LOCUS (loc);
  bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
loc < RESERVED_LOCATION_COUNT
? loc : RESERVED_LOCATION_COUNT);
  if (loc < RESERVED_LOCATION_COUNT)
return;

[...]
}

where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
We can probably teach it to propagate source location but is it OK for current
stage?

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

[mail at milianw dot de]

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

--- Comment #16 from Milian Wolff  ---
So how can I silence the warning then for the case I pasted in the first
comment:

~~~+
#include 

template struct foo {};
foo emit_unexpected_warning;

int main() { return 0; }
~~~+

Most notably when you take into account that this is only sometimes required
based on the optimization level. Should I simply not use decltype and instead
paste the definition of malloc inline? Or is there a "silent" decltype
alternative I could use?

[Bug fortran/78781] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from vehre at gcc dot gnu.org ---
No regressions reported so far, closing.

[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vehre at gcc dot gnu.org ---
No regressions reported so far, closing.

[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 Depends on||70696
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #14 from vehre at gcc dot gnu.org ---
Now that I have a second to check what is going on:

The error is fixed by the patch for 70696. The event-code in caf_single was
assuming a uint32_t but allocated only a bool, which made valgrind and the
instrumentation rightfully report an invalid access.

I have added the dependency to 70696 to get you notified, that when the
backport to gcc-6 is checked in this should be fixed on gcc-6, too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
[Bug 70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #8 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jan 16 13:32:39 2017
New Revision: 244493

URL: https://gcc.gnu.org/viewcvs?rev=244493=gcc=rev
Log:
PR libstdc++/78389 fix backwards size adjustments

Backport from mainline
2017-01-16  Ville Voutilainen  

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)): Fix backwards size adjustments.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: Add
better test for the sizes.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/list.tcc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #7 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jan 16 13:30:58 2017
New Revision: 244492

URL: https://gcc.gnu.org/viewcvs?rev=244492=gcc=rev
Log:
PR libstdc++/78389 fix backwards size adjustments

Backport from mainline
2017-01-16  Ville Voutilainen  

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)): Fix backwards size adjustments.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: Add
better test for the sizes.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/list.tcc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So initially we generate

DIE0: DW_TAG_GNU_call_site (0x768cd690)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_low_pc: label: *.LVL1
  DW_AT_abstract_origin: address

but that later gets rewritten invalidly where Jakub points out.  The regression
is because we prune the DIE for Baz as unused after

  /* Generate separate COMDAT sections for type DIEs. */
  if (use_debug_types)
{
  break_out_comdat_types (comp_unit_die ());

... now it is in a type unit ...

  /* In the process of copying declarations from one unit to another,
 we may have left some declarations behind that are no longer
 referenced.  Prune them.  */
  prune_unused_types ();
}

... and gets pruned.  But nothing adjusts what the decl refers to via
lookup_decl_die (not sure if we are supposed to adjust sth here).

Previously the call-site attribute kept the DIE live in the main CU DIE so
we had duplicate DIEs in the type unit plus the main CU.  With -gstrict-dwarf
it is only on the type unit as expected.

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Indeed it is.

[Bug tree-optimization/79054] missing range information with INT_MAX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
I see the same failure on i386-pc-solaris2.12, sparc-sun-solaris2.12, and
i686-pc-linux-gnu:

+FAIL: gcc.dg/attr-alloc_size-4.c (test for excess errors)

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=]

  Rainer

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #9 from Thomas Preud'homme  ---
It fails on arm-none-eabi too. But given it allocates 12 bytes on the stack and
goes on to write 32 bytes that seems pretty normal, no? Shouldn't this test
just be a compile test?

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> CCing Bin, he was looking into PRE/predcom as well AFAIR.  predictive
> commoning here performs unrolling to be able to avoid some loop-carried
> dependencies
> while PRE has the larger distances covered by for example
> 
>  [85.00%]:
> # prephitmp_656 = PHI <_125(6), pretmp_655(5)>
> # prephitmp_674 = PHI 
> 
> this kind of loop carried PHIs should be a hint for a tree level unroller
> to perform unrolling (just in case they literally appear in source for
> example).
> OTOH if unrolling can solve the RA problem then the it must be solvable not
> unrolled as well?  Note that with predcom we end up with 11 pointer IVs while
> with PRE we have just one (but use 20 others from the outer loop...) -
> possibly
> the versioning predcom performs makes IVO not do any outer loop IVO.  Using
> -fschedule-insns -fsched-pressure helps somewhat but not much.
> 
> So it looks like a RA related issue and IVO is as much relevant as PRE doing
> predictive commoning at -O2 (and at -O3 doing predcoms job but worse in this
> case).
> 
> During PHI translation we can tame this down to a level pre this rev. again,
> for example with the following.  But ideally we'd compute antic and do
> insertion
> for the full dataflow problem and only apply this "cost modeling" during
> elimination to not lose secondary level transforms that are profitable
> (also below we do not know whether we need to insert a PHI for the value in
> the end).
> 
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c  (revision 244484)
> +++ gcc/tree-ssa-pre.c  (working copy)
> @@ -1465,16 +1465,16 @@ phi_translate_1 (pre_expr expr, bitmap_s
>   {
> /* For non-CONSTANTs we have to make sure we can eventually
>insert the expression.  Which means we need to have a
> -  leader for it.  */
> -   if (constant->kind != CONSTANT)
> +  leader for it.  Avoid doing this across backedges though.
> */
> +   if (constant->kind == CONSTANT)
> + return constant;
> +   else if (! dominated_by_p (CDI_DOMINATORS, pred, phiblock))
>   {
> unsigned value_id = get_expr_value_id (constant);
> constant = find_leader_in_sets (value_id, set1, set2);
> if (constant)
>   return constant;
>   }
> -   else
> - return constant;
>   }
>  
> tree result = vn_nary_op_lookup_pieces (newnary->length,
> 
> 
> But as said, a whole different question is whether we want PRE to add IVs at
> all
> (but we do have some testcases requesting exactly that, for example
> gcc.dg/tree-ssa/pr71347.c or ssa-pre-23.c requesting store-motion w/o
> actually sinking the store).
> 
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c  (revision 244484)
> +++ gcc/tree-ssa-pre.c  (working copy)
> @@ -4290,6 +4290,31 @@ eliminate_dom_walker::before_dom_childre
>VN_INFO_RANGE_INFO (lhs));
> }
>  
> + if (sprime
> + && TREE_CODE (sprime) == SSA_NAME
> + && do_pre
> + && loop_outer (b->loop_father)
> + && has_zero_uses (sprime)
> + && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime)))
> +   {
> + gimple *def_stmt = SSA_NAME_DEF_STMT (sprime);
> + basic_block def_bb = gimple_bb (def_stmt);
> + if (gimple_code (def_stmt) == GIMPLE_PHI
> + && def_bb->loop_father->header == def_bb)
> +   {
> + bool ok = true;
> + edge_iterator ei;
> + edge e;
> + FOR_EACH_EDGE (e, ei, def_bb->preds)
> +   if (dominated_by_p (CDI_DOMINATORS, e->src, e->dest)
> +   && TREE_CODE (PHI_ARG_DEF_FROM_EDGE (def_stmt, e))
> == SSA_NAME)
> + ok = false;
> + /* Don't keep sprime available.  */
> + if (!ok)
> +   sprime = NULL_TREE;
> +   }
> +   }
> +
>   /* Inhibit the use of an inserted PHI on a loop header when
>  the address of the memory reference is a simple induction
>  variable.  In other cases the vectorizer won't do anything

I am trying to model register pressure and use that information to direct
predcom.  So far it detects only one case 436.cactusADM but does improve a lot.
 Though it's hard to model cost of pre_expr, but for loop carries ones, we may
be able to simply control the number using pressure 

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[andrew.n.senkevich at gmail dot com]

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

--- Comment #12 from Andrew Senkevich  ---
(In reply to Kirill Yukhin from comment #10)
> (In reply to Andrew Senkevich from comment #8)
> > I think we should follow here declarations from icc headers to be compatible
> > with it.
> Okay. Could you pls state which rules ICC follows for all gather/scatter
> intrinsics?
> Could we use void const * for base in all gather intrinsics?
> What about scatters?

ICC uses "void const*" for gathers, "void*" for scatters.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to John Paul Adrian Glaubitz from comment #1)
> > I'll report back tomorrow.
> 
> Problem persists:

Correction: The patch fixes the alignment problem, but it exposes another bug:

root@mama:~# gccgo-6 hello-world.go -o hello-world2
root@mama:~# ./hello-world2
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x2 addr=0xa5eec0cf]

runtime stack:
runtime_dopanic
../../../src/libgo/runtime/panic.c:135
runtime_throw
../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
../../../src/libgo/runtime/go-signal.c:249
sig_panic_info_handler
../../../src/libgo/runtime/go-signal.c:283

:0
scanblock
../../../src/libgo/runtime/mgc0.c:1117
markroot
../../../src/libgo/runtime/mgc0.c:1368
runtime_parfordo
../../../src/libgo/runtime/parfor.c:93
gc
../../../src/libgo/runtime/mgc0.c:2270
mgc
../../../src/libgo/runtime/mgc0.c:2215
runtime_mstart
../../../src/libgo/runtime/proc.c:1076

goroutine 16 [garbage collection]:
runtime_mcall
../../../src/libgo/runtime/proc.c:295
runtime_gc
../../../src/libgo/runtime/mgc0.c:2191
runtime_mallocgc
../../../src/libgo/runtime/malloc.goc:259
__go_new
../../../src/libgo/runtime/go-new.c:16
main.main
/root/hello-world.go:6
runtime_main
../../../src/libgo/runtime/proc.c:626

goroutine 17 [runnable]:
kickoff
../../../src/libgo/runtime/proc.c:232
created by runtime_main
../../../src/libgo/runtime/proc.c:598

goroutine 18 [runnable]:
kickoff
../../../src/libgo/runtime/proc.c:232
created by runtime_createfing
../../../src/libgo/runtime/mgc0.c:2577
root@mama:~#

Looks like we're missing a signal handler on m68k.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
 CC||amker at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
CCing Bin, he was looking into PRE/predcom as well AFAIR.  predictive commoning
here performs unrolling to be able to avoid some loop-carried dependencies
while PRE has the larger distances covered by for example

 [85.00%]:
# prephitmp_656 = PHI <_125(6), pretmp_655(5)>
# prephitmp_674 = PHI 

this kind of loop carried PHIs should be a hint for a tree level unroller
to perform unrolling (just in case they literally appear in source for
example).
OTOH if unrolling can solve the RA problem then the it must be solvable not
unrolled as well?  Note that with predcom we end up with 11 pointer IVs while
with PRE we have just one (but use 20 others from the outer loop...) - possibly
the versioning predcom performs makes IVO not do any outer loop IVO.  Using
-fschedule-insns -fsched-pressure helps somewhat but not much.

So it looks like a RA related issue and IVO is as much relevant as PRE doing
predictive commoning at -O2 (and at -O3 doing predcoms job but worse in this
case).

During PHI translation we can tame this down to a level pre this rev. again,
for example with the following.  But ideally we'd compute antic and do
insertion
for the full dataflow problem and only apply this "cost modeling" during
elimination to not lose secondary level transforms that are profitable
(also below we do not know whether we need to insert a PHI for the value in
the end).

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 244484)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -1465,16 +1465,16 @@ phi_translate_1 (pre_expr expr, bitmap_s
  {
/* For non-CONSTANTs we have to make sure we can eventually
   insert the expression.  Which means we need to have a
-  leader for it.  */
-   if (constant->kind != CONSTANT)
+  leader for it.  Avoid doing this across backedges though. 
*/
+   if (constant->kind == CONSTANT)
+ return constant;
+   else if (! dominated_by_p (CDI_DOMINATORS, pred, phiblock))
  {
unsigned value_id = get_expr_value_id (constant);
constant = find_leader_in_sets (value_id, set1, set2);
if (constant)
  return constant;
  }
-   else
- return constant;
  }

tree result = vn_nary_op_lookup_pieces (newnary->length,


But as said, a whole different question is whether we want PRE to add IVs at
all
(but we do have some testcases requesting exactly that, for example
gcc.dg/tree-ssa/pr71347.c or ssa-pre-23.c requesting store-motion w/o actually
sinking the store).

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 244484)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4290,6 +4290,31 @@ eliminate_dom_walker::before_dom_childre
   VN_INFO_RANGE_INFO (lhs));
}

+ if (sprime
+ && TREE_CODE (sprime) == SSA_NAME
+ && do_pre
+ && loop_outer (b->loop_father)
+ && has_zero_uses (sprime)
+ && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime)))
+   {
+ gimple *def_stmt = SSA_NAME_DEF_STMT (sprime);
+ basic_block def_bb = gimple_bb (def_stmt);
+ if (gimple_code (def_stmt) == GIMPLE_PHI
+ && def_bb->loop_father->header == def_bb)
+   {
+ bool ok = true;
+ edge_iterator ei;
+ edge e;
+ FOR_EACH_EDGE (e, ei, def_bb->preds)
+   if (dominated_by_p (CDI_DOMINATORS, e->src, e->dest)
+   && TREE_CODE (PHI_ARG_DEF_FROM_EDGE (def_stmt, e)) ==
SSA_NAME)
+ ok = false;
+ /* Don't keep sprime available.  */
+ if (!ok)
+   sprime = NULL_TREE;
+   }
+   }
+
  /* Inhibit the use of an inserted PHI on a loop header when
 the address of the memory reference is a simple induction
 variable.  In other cases the vectorizer won't do anything

[Bug translation/79100] Superfluous % in messages from cfgloop.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
%' is documented format string:
   %': apostrophe (should only be used in untranslated messages;
   translations should use appropriate punctuation directly).

[Bug c++/79101] Registers aren't used for passing and returning objects when there is a move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is a bug in Clang, not GCC. This case has been discussed with the C++ ABI
group and GCC's behaviour is what was intended.

https://llvm.org/bugs/show_bug.cgi?id=19668

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Should be fixed for gcc 7.

In general we still don't support building libstdc++ with Clang, and if you are
reporting bugs with unsupported setups please be sure to make it clear what
strange configuration y9ou're using.

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 16 11:41:41 2017
New Revision: 244491

URL: https://gcc.gnu.org/viewcvs?rev=244491=gcc=rev
Log:
PR78702 fix accessibility of locale::facet::__shim

PR libstdc++/78702
* include/bits/locale_classes.h (locale::facet::__shim): Change from
private to protected.
* src/c++11/cxx11-shim_facets.cc (__shim_accessor): Define helper to
make locale::facet::__shim accessible.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_classes.h
trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc