[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[meissner at linux dot vnet.ibm.com]

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

--- Comment #5 from Michael Meissner  ---
On Fri, Apr 14, 2017 at 07:26:57PM +, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
> 
> --- Comment #4 from Peter Bergner  ---
> So it seems rs6000_pragma_target_parse() ends up calling
> rs6000_option_override_internal(), which is modifying the options via global
> variables.  All other arches pass in the option variables to their
> *__option_override_internal(), that they want updated/set and those seem to be
> scoped to the area of the file they reside in.

If that is the case, then we need to modify the code not to touch the global
variables.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #13 from Vittorio Zecca  ---
In C strings are pointers, in Fortran they are not.

So ptr="string" is wrong.

As in the following:
character, pointer :: cptr
cptr="qwerty"
end
Running it I get a SIGSEGV.

[Bug tree-optimization/62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can

[segher at gcc dot gnu.org]

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

Bug 66612 Summary: [6/7/8 regression] FAIL: gcc.target/powerpc/20050830-1.c 
scan-assembler bdn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

   What|Removed |Added

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

[Bug tree-optimization/66612] [6/7/8 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #17 from Segher Boessenkool  ---
Fixed, we get perfect code on 64-bit as well now.  Thanks Bin!

[Bug tree-optimization/66612] [6/7/8 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
Author: segher
Date: Sat Apr 15 04:11:35 2017
New Revision: 246939

URL: https://gcc.gnu.org/viewcvs?rev=246939=gcc=rev
Log:
rs6000: Testcase 20050830-1.c no longer fails (PR66612)

Bin's commit r246810, for PR80153, fixes 20050830-1.c for -m64 (it
already passed for -m32).  So, this patch removes the remaining xfail.


gcc/testsuite/
PR tree-optimization/66612
* gcc.target/powerpc/20050830-1.c: Remove xfail.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/20050830-1.c

[Bug driver/53883] GCC 4.7.1 doesn't build on Mac OS X 10.4.11 Tiger/PowerPC (32-bit), at least with MacPorts

[travism1 at g dot ucla.edu]

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

M Travis  changed:

   What|Removed |Added

 CC||travism1 at g dot ucla.edu

--- Comment #12 from M Travis  ---
Here is a brief primer on MacPorts: https://www.everipedia.com/MacPorts/

[Bug gcov-profile/80435] New: Expose __gcov_flush to allow developers to dump coverage numbers on demand

[yaneurabeya at gmail dot com]

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

Bug ID: 80435
   Summary: Expose __gcov_flush to allow developers to dump
coverage numbers on demand
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaneurabeya at gmail dot com
  Target Milestone: ---

If a test program uses _exit in lieu of exit, the end-user must call
__gcov_flush. Unfortunately this API isn't currently exposed anywhere, so
calling it isn't possible unless someone adds appropriate extern's in program
headers.

It would be really nice if this API was exposed so others didn't need to back a
__gcov_flush definition in their sources (this seems to be the hack that
multiple individuals are using to workaround __gcov_flush not being made public
via binutils :(, e.g., https://gcc.gnu.org/ml/gcc-help/2015-06/msg00135.html ).

The companion bug I filed for this on the LLVM side can be found here:
http://bugs.llvm.org/show_bug.cgi?id=32555 .

[Bug middle-end/80346] pessimistic stringop-overflow

[law at redhat dot com]

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

--- Comment #15 from Jeffrey A. Law  ---
I was looking pretty hard for something the compiler could use to avoid the
problematical paths.  That's always my first approach since doing so removes
the warning and generates better code.

I just couldn't find anything useful.

For the undefined behavior path that can't be removed, my preference is to
insert a trap rather than going into the else clause -- hitting the trap stops
the program cold which is far safer from a security standpoint.  That's what we
do with things like dereferencing a NULL pointer or division by zero.  If our
out-of-bounds array bounds analysis was better, we'd be doing it there too.

[Bug middle-end/80346] pessimistic stringop-overflow

[bonzini at gnu dot org]

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

--- Comment #14 from Paolo Bonzini  ---
And also treat it as undefined behavior and go straight to the else... 
kidding, but not entirely!).

The main issue is that here we _are_ testing the overflow behavior of the
function, so we cannot pass sz for the last argument.  I guess we can add a
pragma or compiler flag to hide the warning.  Thanks!

[Bug middle-end/80346] pessimistic stringop-overflow

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
Given an unknown object size and a byte count of -1 we ought to be warning
IMHO.

[Bug middle-end/80346] pessimistic stringop-overflow

[bonzini at gnu dot org]

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

--- Comment #12 from Paolo Bonzini  ---
> So AFAICT, the warning for the first testcase is valid as well.

True, but isn't the maximum object size (2^63-1 aka PTRDIFF_MAX) as bogus as
2^64-1?  We are using -1 which is a bit ugly but SIZE_MAX would also warn and
the warning then makes less sense.

In other words, I'm not sure it's particularly useful to have a warning if GCC
cannot determine the object size at all.

[Bug other/80434] internal compiler error: Killed (program cc1plus)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
How much memory do you have on this machine?

[Bug other/80434] New: internal compiler error: Killed (program cc1plus)

[leclerc at ohsu dot edu]

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

Bug ID: 80434
   Summary: internal compiler error: Killed (program cc1plus)
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leclerc at ohsu dot edu
  Target Milestone: ---

Hi Bug Fixer People:

I really have no idea what I'm doing, but apparently something you were not
expecting. Your instructions for not being an idiot when reporting bugs is
quite intimidating to a non-expert but the error message asked for me to
'please submit a full bug report' so here goes:

What we need

Please include in your bug report all of the following items, the
first three of which can be obtained from the output of gcc -v:

* the exact version of GCC;
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
* the system type;
I don't know what of that stuff output from gcc -v tells me this so
this is what I know;
Ubuntu 16.04.4
R version 3.2.3
RStudio version: Version 1.0.136 – © 2009-2016 RStudio, Inc.

* the options given when GCC was configured/built;
not a clue, but I followed all the defaults cause I'm not good
enough to improvise
* the complete command line that triggers the bug;
 > install.packages("dplyr")
* the compiler output (error messages, warnings, etc.); and
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [dplyr.o] Error 4
* the preprocessed file (*.i*) that triggers the bug, generated by
  adding -save-temps to the complete compilation command, or, in
  the case of a bug report for the GNAT front end, a complete set
  of source files (see below).
I have no idea what you mean.



Probably altogether too much info, feel free to ingore this as well as the
whole report if it is crap:

In RStudio attempting to run something with libraries:
library("dplyr")
library("stringr")
needed to add the packages so, 
in R Studio pushed install button, 
in the dialog entered the package names,
In the console  dplyr said it needed tibble, tibble couldn't find file Rcpp.h
back to R Studio package tab, install button, Rcpp, bunch of console
stuff happened, looked fine
(ok to be honest there was a lot of no rcpp package for
version...don't you mean Rcpp.. first)
so back to the package tab, install, dplyr
In console again said it would install tibble and dplyr
bunch of stuff in misc. colors I don't get, but then "Done (tibble)"
bunch more stuff ending in:
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [dplyr.o] Error 4




Output on console:


> install.packages("dplyr") -save -temps
Installing package into ‘/home/leclerc/R/x86_64-pc-linux-gnu-library/3.2’
(as ‘lib’ is unspecified)
--2017-04-14 14:53:29-- 
https://cran.rstudio.com/src/contrib/dplyr_0.5.0.tar.gz
Resolving cran.rstudio.com (cran.rstudio.com)... 52.84.22.49
Connecting to cran.rstudio.com (cran.rstudio.com)|52.84.22.49|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 708476 (692K) [application/x-gzip]
Saving to: ‘/tmp/RtmpZUWuWp/downloaded_packages/dplyr_0.5.0.tar.gz’

 0K .. .. .. .. ..  7% 1.69M 0s
50K .. .. .. .. .. 14% 3.37M 0s
   100K .. .. .. .. .. 21% 4.68M 0s
   150K .. .. .. .. .. 28% 4.04M 0s
   200K .. .. .. .. .. 36% 4.27M 0s
   250K .. .. .. .. .. 43% 3.63M 0s
   300K .. .. .. .. .. 50% 5.70M 0s
   350K .. .. .. .. .. 57% 1.92M 0s
   400K .. .. .. .. .. 65% 3.79M 0s
   450K .. .. .. .. .. 72% 4.87M 0s
   500K .. .. .. .. .. 79% 4.41M 0s
   550K .. .. .. .. .. 86% 4.63M 0s
   600K .. .. .. .. .. 93% 2.50M 0s
   650K .. .. .. .. . 100% 4.61M=0.2s

2017-04-14 14:53:29 (3.42 MB/s) -
‘/tmp/RtmpZUWuWp/downloaded_packages/dplyr_0.5.0.tar.gz’ saved [708476/708476]

* installing *source* package ‘dplyr’ ...
** package ‘dplyr’ 

[Bug middle-end/80346] pessimistic stringop-overflow

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #11 from Jeffrey A. Law  ---
The warning for Martin's reduced testcase is clearly warranted.  Consider the
case were a == -1 and b == -1.


Now if we go back to the original testcase we have this:

static inline size_t
iov_from_buf(const struct iovec *iov, unsigned int iov_cnt,
 size_t offset, const void *buf, size_t bytes)
{
if (__builtin_constant_p(bytes) && iov_cnt &&
offset <= iov[0].iov_len && bytes <= iov[0].iov_len - offset) {
memcpy(iov[0].iov_base + offset, buf, bytes);
return bytes;
} else {
return iov_from_buf_full(iov, iov_cnt, offset, buf, bytes);
}
}


In the case where bytes = -1 (constant), iov_count != 0, offset = 0 and iov_len
= -1 we can clearly call memcpy with -1 as the length.  This corresponds to a
call like

 n = iov_from_buf(iov, niov, i, ibuf + i, -1);

Where niov != 0, i == 0, ibuf (don't care) and iov.iov_len == -1.  I don't see
anything that would inherently prevent that from occuring.

So AFAICT, the warning for the first testcase is valid as well.

[Bug target/79964] Cortex A53 codegen still not optimal

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #1 from PeteVine  ---
Turns out -frename-registers fixes this issue as well, thanks for the tip!

http://openbenchmarking.org/result/1704142-RI-1703089RI22

[Bug target/80433] [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c

[gcc at davidrobins dot net]

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

--- Comment #1 from David B. Robins  ---
Created attachment 41203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41203=edit
Pass register context for post_inc reload; allow GENNONACR_REGS as preferred.

I am attaching a potential fix in hopes it will help; I would be surprised if
I've uncovered a new issue in the reload code, but the change to pass the
register class for the code rather than the outer matches a few other cases and
fits the issue I'm seeing with the crisv32 ACR register being selected for a
post_inc insn that isn't supposed to use it.

(Not attaching aforementioned pass output files due to size, and because they
can easily be reproduced by attached source and above command.)

[Bug target/78994] -Ofast makes aarch64 C++ benchmark slower for A53

[tulipawn at gmail dot com]

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

--- Comment #9 from PeteVine  ---
Well, yes, that fixes the -Ofast issue for me:

-mcpu=cortex-a53 -frename-registers
iir:65952 ns per loop
iir_2:  63098 ns per loop

-mcpu=cortex-a57 (-frename-registers)
iir:62839 ns per loop
iir_2:  62677 ns per loop

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Apr 14 21:17:52 2017
New Revision: 246934

URL: https://gcc.gnu.org/viewcvs?rev=246934=gcc=rev
Log:
2017-04-14  Janus Weil  

PR fortran/80361
* class.c (generate_finalization_wrapper): Give the finalization
wrapper
the recursive attribute.

2017-04-14  Janus Weil  

PR fortran/80361
* gfortran.dg/class_62.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/class_62.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-14
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
It's a problem in IRA.  I am testing a patch.

[Bug target/80433] New: [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c

[gcc at davidrobins dot net]

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

Bug ID: 80433
   Summary: [CRIS] ICE at -O2: unrecognized insn (post_inc on acr)
building glibc sha512.c
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at davidrobins dot net
  Target Milestone: ---

Created attachment 41202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41202=edit
Preprocessed sha512.c from glibc.

Compiling attached preprocessed glibc (2.9) sha512.c as:

crisv32-linux-gnu-gcc sha512.i -S -O2 -o sha512.S

results in:

sha512.c: In function _sha512_process_block_:
sha512.c:206:1: error: unrecognizable insn:
 }
 ^
(insn 652 650 648 9 (set (reg:DI 10 r10)
(mem:DI (post_inc:SI (reg:SI 15 acr)) [1 MEM[base: _195, offset: 0B]+0
S8 A8])) "sha512.c":165 -1
 (expr_list:REG_INC (reg:SI 15 acr)
(nil)))
sha512.c:206:1: internal compiler error: in extract_insn, at recog.c:2311
0xa7ffd8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-svn/gcc/rtl-error.c:108
0xa80009 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-svn/gcc/rtl-error.c:116
0xa4a861 extract_insn(rtx_insn*)
../../gcc-svn/gcc/recog.c:2311
0xa4a8d1 extract_insn_cached(rtx_insn*)
../../gcc-svn/gcc/recog.c:2201
0x7d4fd7 cleanup_subreg_operands(rtx_insn*)
../../gcc-svn/gcc/final.c:3152
0xa744ce reload(rtx_insn*, int)
../../gcc-svn/gcc/reload1.c:1235
0x92211d do_reload
../../gcc-svn/gcc/ira.c:5469
0x92211d execute
../../gcc-svn/gcc/ira.c:5641
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

No error at lower optimization levels.

I have also attached the .271r.ira and .272r.reload pass output files.

Output of crisv32-linux-gnu-gcc -v:

Using built-in specs.
COLLECT_GCC=crisv32-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/cross/cris/6.3/libexec/gcc/crisv32-linux-gnu/7.0.1/lto-wrapper
Target: crisv32-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/opt/cross/cris/6.3
--without-headers --target=crisv32-linux-gnu --enable-languages=c,c++
--disable-multilib : (reconfigured) ../gcc-svn/configure
--prefix=/opt/cross/cris/6.3 --target=crisv32-linux-gnu
--enable-languages=c,c++ --disable-multilib : (repeat same a few more times)
Thread model: posix
gcc version 7.0.1 20170411 (experimental) (GCC)

[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
At -O2 the memset is removed very early in the optimization pipeline.   Thus
there's no warning at O2, but there is a warning at O1.  Reality is some
warnings are going to give false positives when optimizations are throttled
back and I wouldn't call that a regression for the C testcase.


What I am concerned about is in the original Fortran based test, we warned at
-O2, but not at -O1.  Something has been lost in the translation to C.

[Bug target/80098] ICE in curr_insn_transform, at lra-constraints.c:3816 on ppc64le

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Fixed in subversion id 246930.

[Bug target/80098] ICE in curr_insn_transform, at lra-constraints.c:3816 on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Fri Apr 14 20:27:18 2017
New Revision: 246930

URL: https://gcc.gnu.org/viewcvs?rev=246930=gcc=rev
Log:
[gcc]
2017-04-14  Michael Meissner  

PR target/80098
* config/rs6000/rs6000-cpus.def (OTHER_P9_VECTOR_MASKS): Define
masks of options that should be turned off if the VSX vector
options are turned off.
(OTHER_P8_VECTOR_MASKS): Likewise.
(OTHER_VSX_VECTOR_MASKS): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Call
rs6000_disable_incompatible_switches to validate no type switches
like -mvsx.
(rs6000_incompatible_switch): New function to disallow turning on
other vector options if -mno-vsx, -mno-power8-vector, or
-mno-power9-vector are specified.

[gcc/testsuite]
2017-04-14  Michael Meissner  

PR target/80098
* gcc.target/powerpc/pr80098-1.c: New test.
* gcc.target/powerpc/pr80098-2.c: Likewise.
* gcc.target/powerpc/pr80098-3.c: Likewise.
* gcc.target/powerpc/pr80098-4.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-3.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80098-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-cpus.def
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Hao Zhang from comment #3)
> (In reply to Hao Zhang from comment #2)
> > (In reply to Martin Liška from comment #1)
> > > Can't reproduce, can you please provide options you use to build the
> > > executable?
> > 
> > I didn't use any extra options besides g++ pow.cpp, and both my CFLAGS and
> > CXXFLAGS environment variables are empty. And I just found out moments ago
> > compiling with -O1 gives the right result while compiling with -O0 gives the
> > wrong result. I also tried to turn on each of the 42 optimizations provided
> > by -O1 individually, and I found none of the 42 optimizations ALONE can get
> > rid of the problem. So there must be some combinations of optimizations that
> > can get rid of the problem. 
> > 
> > My glibc version is 2.25 and kernel version is 4.10.9. And I have reproduced
> > the error on two different computers. Is there any other information I can
> > provide to help pinpoint the problem? Thanks!
> 
> I also found out that g++ -O1 pow.cpp gives the expected results, while the
> following command gives the wrong results:
> 
> g++ -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments
> -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse
> -fforward-propagate -fguess-branch-probability -fif-conversion2
> -fif-conversion -finline-functions-called-once -fipa-pure-const
> -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants
> -freorder-blocks -fshrink-wrap -fshrink-wrap-separate -fsplit-wide-types
> -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch
> -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts
> -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr
> -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fomit-frame-pointer
> pow.cpp
> 
> This is weird, isn't the two forms of command equivalent?

No.
And with -O0 it will just call powl. So if you get weird results your glibc is
to blame.

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

[theivorytower at gmail dot com]

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

--- Comment #3 from Hao Zhang  ---
(In reply to Hao Zhang from comment #2)
> (In reply to Martin Liška from comment #1)
> > Can't reproduce, can you please provide options you use to build the
> > executable?
> 
> I didn't use any extra options besides g++ pow.cpp, and both my CFLAGS and
> CXXFLAGS environment variables are empty. And I just found out moments ago
> compiling with -O1 gives the right result while compiling with -O0 gives the
> wrong result. I also tried to turn on each of the 42 optimizations provided
> by -O1 individually, and I found none of the 42 optimizations ALONE can get
> rid of the problem. So there must be some combinations of optimizations that
> can get rid of the problem. 
> 
> My glibc version is 2.25 and kernel version is 4.10.9. And I have reproduced
> the error on two different computers. Is there any other information I can
> provide to help pinpoint the problem? Thanks!

I also found out that g++ -O1 pow.cpp gives the expected results, while the
following command gives the wrong results:

g++ -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments
-fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse
-fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion
-finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference
-fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap
-fshrink-wrap-separate -fsplit-wide-types -fssa-backprop -fssa-phiopt
-ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
-ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter
-funit-at-a-time -fomit-frame-pointer pow.cpp

This is weird, isn't the two forms of command equivalent?

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

[theivorytower at gmail dot com]

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

--- Comment #2 from Hao Zhang  ---
(In reply to Martin Liška from comment #1)
> Can't reproduce, can you please provide options you use to build the
> executable?

I didn't use any extra options besides g++ pow.cpp, and both my CFLAGS and
CXXFLAGS environment variables are empty. And I just found out moments ago
compiling with -O1 gives the right result while compiling with -O0 gives the
wrong result. I also tried to turn on each of the 42 optimizations provided by
-O1 individually, and I found none of the 42 optimizations ALONE can get rid of
the problem. So there must be some combinations of optimizations that can get
rid of the problem. 

My glibc version is 2.25 and kernel version is 4.10.9. And I have reproduced
the error on two different computers. Is there any other information I can
provide to help pinpoint the problem? Thanks!

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
So it seems rs6000_pragma_target_parse() ends up calling
rs6000_option_override_internal(), which is modifying the options via global
variables.  All other arches pass in the option variables to their
*__option_override_internal(), that they want updated/set and those seem to be
scoped to the area of the file they reside in.

[Bug libstdc++/80432] std::pow gives wrong results for long double arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can't reproduce, can you please provide options you use to build the
executable?

[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Yep, started with r218451.

[Bug tree-optimization/80426] [7 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'd think that we shouldn't be creating symbolic range b + -2147483648 at all
when the IL has b - -2147483648.

[Bug fortran/80392] [5/6/7 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.8.5
Summary|ICE with allocatable|[5/6/7 Regression] [OOP]
   |polymorphic function result |ICE with allocatable
   |in a procedure pointer  |polymorphic function result
   |component   |in a procedure pointer
   ||component
  Known to fail||4.9.4, 5.4.1, 6.3.0, 7.0

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to zed.three from comment #0)
> With gfortran 7.0.1, I get an ICE:
> 
> gfortran-7: internal compiler error: Segmentation fault (program f951)
> 
> I also get an ICE with 5.4.1 and 6.2.1 (but not 4.8.5) if I remove the
> `bad_sub` implementation.

Right. This is clearly an ICE-on-valid regression:

module mwe

  implicit none

  type :: MyType
 procedure(my_op), nopass, pointer :: op
  end type

contains

  function my_op() result(foo)
class(MyType), allocatable :: foo
  end function

end module

[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
A more direct test case:

bergner@bns:~/gcc/BUGS/PR80210> cat sqrt.i 
double
foo (double a)
{
  return __builtin_sqrt (a);
}
#pragma GCC target "no-powerpc-gpopt"
bergner@bns:~/gcc/BUGS/PR80210>
/home/bergner/gcc/build/gcc-fsf-mainline-pr80210-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr80210-debug/gcc -Ofast -S sqrt.i 
sqrt.i: In function ‘foo’:
sqrt.i:5:1: error: unrecognizable insn:
 }
 ^
(insn 6 3 10 2 (set (reg:DF 155 [  ])
(sqrt:DF (reg/v:DF 156 [ a ]))) "sqrt.i":4 -1
 (nil))
sqrt.i:5:1: internal compiler error: in extract_insn, at recog.c:2311

The issue is that when we initialize for compilation, TARGET_PPC_GPOPT is true
due to TARGET_DEFAULT including it, which in turn is used to set HAVE_sqrtdf2. 
We then call init_all_optabs() and that does "ena[342] = HAVE_sqrtdf2;" which
records the fact we have the sqrtdf2 pattern, which will allow (later) the
__builtin_sqrt() to call down into the backend to generate the pattern. 
Otherwise, it would generate a call to sqrt.

After init_all_optabs, but before we expand the function, we scan the pragma
and that turns off TARGET_PPC_GPOPT disallowing the pattern which leads to the
ICE.

Now the pragma, since it is textually after the function, should not affect the
options used to compile the function foo, but it does.  This seems to be caused
by rs6000_pragma_target_parse() incorrectly modifying the global_options that
will be used to compile function foo.

Mike, you wrote this code.  When we see the pragma, shouldn't we be saving off
the current options for use by foo, before we alter the options that would be
used by functions that follow the pragma?  Our code in this area looks a fair
amount different than say x86, s390 and ARM, but it looks like they each are
creating a copy of the options, while we don't.

[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #3)
> Confirmed, only GCC 5.x is affected. Started to be fixed on trunk by
> r227307. adding Jeff to CC.

That might be covering up a latent bug depending on where the failure was
introduced.

[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug libstdc++/80432] New: std::pow gives wrong results for long double arguments

[theivorytower at gmail dot com]

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

Bug ID: 80432
   Summary: std::pow gives wrong results for long double arguments
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theivorytower at gmail dot com
  Target Milestone: ---

With the latest gcc 7.0.1, whenever I pass long double arguments to std::pow,
the results are either nan or inf for most of the times. For example, the
following simple code outputs -nan while the expected result is 2:

#include 
#include 

int main() {
long double a = 4;
long double b = 0.5;
std::cout << std::pow(a, b) << std::endl;
}

If I set = 0.007 and b = 0.2, the output is inf while the expected result is
0.370697. The program behaves as expected if the arguments are double instead
of long double. The following is my gcc version info:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/hao/installers/aur-gcc-git/src/gcc/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 7.0.1 20170413 (experimental) (GCC)

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Looks like r246854 is very relevant.  Thanks, Vlad!

[Bug c++/80431] New: Use of "this" pointer in member initializer causes constructor not to be called (or ICE on gcc 7)

[edolstra at gmail dot com]

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

Bug ID: 80431
   Summary: Use of "this" pointer in member initializer causes
constructor not to be called (or ICE on gcc 7)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edolstra at gmail dot com
  Target Milestone: ---

The following program is miscompiled by GCC 5.4.0 and 6.3.0:

=== start ===
extern "C" void puts(char const *);

struct Options { };

struct Option
{
Option(Options * options)
{
puts("CREATE");
}

~Option()
{
puts("DESTROY");
}
};

struct MyOptions : Options { };

struct MyOptions2 : virtual MyOptions
{
Option foo{this};
};

int main(int argc, char * * argv)
{
MyOptions2 opts;
}
=== end ===

Running this prints:

$ g++ ./this-bug.cc
$ ./a.out 
DESTROY

That is, the constructor for the "foo" member is never executed, but the
destructor is. This appears to be caused by the combination of the use of a
virtual base class, and the use of a "this" pointer in the initializer.
Changing foo to:

Option foo{(MyOptions*) this};

causes the constructor to run correctly:

$ ./a.out 
CREATE
DESTROY

Either variant works fine with Clang 3.9.1.

With GCC 7 (20170409 snapshot), the compiler gives an internal compiler error:

$ g++ ./this-bug.cc
./this-bug.cc:1:17: warning: declaration of ‘void puts(const char*)’ conflicts
with built-in declaration ‘int puts(const char*)’
[-Wbuiltin-declaration-mismatch]
 extern "C" void puts(char const *);
 ^~~~
./this-bug.cc: In constructor ‘MyOptions2::MyOptions2()’:
./this-bug.cc:20:8: internal compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in useless_type_conversion_p, at
gimple-expr.c:84
 struct MyOptions2 : virtual MyOptions
^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested on x86_64-linux (NixOS). Compiler info:

$ g++ -v
Using built-in specs.
COLLECT_GCC=/nix/store/mw03k1hhagbp2lnaa76k9gb8r9ha30gf-gcc-6.3.0/bin/g++
COLLECT_LTO_WRAPPER=/nix/store/mw03k1hhagbp2lnaa76k9gb8r9ha30gf-gcc-6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: 
Thread model: posix
gcc version 6.3.0 (GCC)

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
This was fixed somewhere in the revisions 246851 through 246857.

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[law at redhat dot com]

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

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

This is a latent bug in cross jumping AFAICT.

Essentially a forwarder block becomes unreachable during cfg_cleanup. Later
we're cross jumping an indirect (via more forwarders) successor of the now
unreachable forwarder and walk up the CFG looking for hunks of equivalent
insns. 

flow_find_cross_jump walks the insn chain backwards from two given points to
find identical insns for crossjumping.  That walk can cross basic block
boundaries (by design, see walk_to_nondebug_insn).

As a result flow_find_cross_jump can return in F1 and F2 insns that are not in
blocks BB1 and BB2.

So given this code in try_crossjump_to_edge:

  /* Likewise with dead code (possibly newly created by the other optimizations
 of cfg_cleanup).  */
  if (EDGE_COUNT (src1->preds) == 0 || EDGE_COUNT (src2->preds) == 0)
return false;

[ ... ]

  /* ... and part the second.  */
  nmatch = flow_find_cross_jump (src1, src2, , , );

  osrc1 = src1;
  osrc2 = src2;
  if (newpos1 != NULL_RTX)
src1 = BLOCK_FOR_INSN (newpos1);
  if (newpos2 != NULL_RTX)
src2 = BLOCK_FOR_INSN (newpos2);


The EDGE_COUNT checks verify that the original starting points for cross
jumping are reachable.  But as we walk up the CFG we may run into cases where
flow_find_cross_jump walks us into one or more new blocks and we never check to
see if those new blocks are reachable or not.

A short time later we do this:

  /* Avoid splitting if possible.  We must always split when SRC2 has
 EH predecessor edges, or we may end up with basic blocks with both
 normal and EH predecessor edges.  */
  if (newpos2 == BB_HEAD (src2)
  && !(EDGE_PRED (src2, 0)->flags & EDGE_EH))
redirect_to = src2;


If SRC2 is unreachable, then EDGE_PRED will read outside the vec's boundary
triggering the fault.

I'm pretty sure the fix is to verify the both blocks are reachable after
flow_find_cross_jump as well.

[Bug tree-optimization/80430] Vectorizer undervalues cost of alias checking for versioning

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||dje at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |8.0
  Known to fail||5.4.1, 6.3.1, 7.0

[Bug tree-optimization/80430] New: Vectorizer undervalues cost of alias checking for versioning

[wschmidt at gcc dot gnu.org]

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

Bug ID: 80430
   Summary: Vectorizer undervalues cost of alias checking for
versioning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

While investigating a performance loss due to vectorization, I noticed that the
cost model doesn't properly account for the outside cost due to a versioning
check for aliasing.  Note the FIXME here in tree-vect-loop.c:

  /* Requires loop versioning with alias checks.  */
  if (LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo))
{
  /*  FIXME: Make cost depend on complexity of individual check.  */
  unsigned len = LOOP_VINFO_COMP_ALIAS_DDRS (loop_vinfo).length ();
  (void) add_stmt_cost (target_cost_data, len, vector_stmt, NULL, 0,
vect_prologue);
  dump_printf (MSG_NOTE,
   "cost model: Adding cost of checks for loop "
   "versioning aliasing.\n");
}

Thus the outside cost typically gets a cost of 1 vector_stmt for this checking.
 In reality, about 20 gimple scalar statements are added, including several
conditional moves.  See vect_create_cond_for_alias_checks and friends in
tree-vect-loop-manip.c for the gory details.

This can cause real problems when an inner loop that isn't frequently executed
gets vectorized, and its outer loop executes many times, suffering the penalty
of the aliasing check.  (Even with a saner estimate of 20 * len scalar_stmts,
I've seen this happen due to static estimation still leading us to think this
is profitable.  But we should still clean this up.)

An example inner loop where this kind of pessimization occurs:

static void LZ4_wildCopy(void* dstPtr, const void* srcPtr, void* dstEnd)
{
BYTE* d = (BYTE*)dstPtr;
const BYTE* s = (const BYTE*)srcPtr;
BYTE* const e = (BYTE*)dstEnd;

do { memcpy(d,s,8); d+=8; s+=8; } while (d

[Bug target/80429] New: -fcompare-debug failure on ppc64le with LRA

[trippels at gcc dot gnu.org]

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

Bug ID: 80429
   Summary: -fcompare-debug failure on ppc64le with LRA
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dje at gcc dot gnu.org
  Target Milestone: ---
  Host: ppc64le
Target: ppc64le

Created attachment 41201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41201=edit
reduced testcase

This is an old issue. All supported compilers are affected when using -mlra.

 % g++ --save-temps -w -fcompare-debug -c -O3 SemaTemplateVariadic.ii
g++: error: SemaTemplateVariadic.ii: -fcompare-debug failure

 % diff -u SemaTemplateVariadic.gkd SemaTemplateVariadic.gk.gkd
--- SemaTemplateVariadic.gkd2017-04-14 14:58:01.192414182 +
+++ SemaTemplateVariadic.gk.gkd 2017-04-14 14:58:01.262415848 +
@@ -472,9 +472,9 @@
 (compare:CC (and:DI (reg/f:DI 9 9 [orig:156 _2 ] [156])
 (const_int 1 [0x1]))
 (const_int 0 [0])))
-(clobber (reg:DI 10 10 [189]))
+(clobber (reg:DI 10 10 [190]))
 ]) "SemaTemplateVariadic.ii":29# {*anddi3_imm_mask_dot}
- (expr_list:REG_UNUSED (reg:DI 10 10 [189])
+ (expr_list:REG_UNUSED (reg:DI 10 10 [190])
 (nil)))
 (jump_insn # 0 0 (set (pc)
 (if_then_else (ne (reg:CC 68 0 [174])
@@ -500,9 +500,9 @@
 (compare:CC (and:DI (reg:DI 9 9 [orig:161 _19 ] [161])
 (const_int 1 [0x1]))
 (const_int 0 [0])))
-(clobber (reg:DI 8 8 [190]))
+(clobber (reg:DI 8 8 [191]))
 ]) "SemaTemplateVariadic.ii":29# {*anddi3_imm_mask_dot}
- (expr_list:REG_UNUSED (reg:DI 8 8 [190])
+ (expr_list:REG_UNUSED (reg:DI 8 8 [191])
 (nil)))
 (jump_insn # 0 0 (set (pc)
 (if_then_else (ne (reg:CC 68 0 [178])

[Bug c/80428] New: Incorrect -Wunused-const-variable= instance

[tom.rini at gmail dot com]

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

Bug ID: 80428
   Summary: Incorrect -Wunused-const-variable= instance
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom.rini at gmail dot com
  Target Milestone: ---

With U-Boot v2017.05-rc1 and the 'ts4600_config' (make ts4600_config all to
reproduce) we see:
/home/trini/work/u-boot/u-boot/common/cli_readline.c:20:21: warning: ‘tab_seq’
defined but not used [-Wunused-const-variable=]
 static const char   tab_seq[] = ""; /* used to expand TABs */
 ^~~
/home/trini/work/u-boot/u-boot/common/cli_readline.c:19:19: warning:
‘erase_seq’ defined but not used [-Wunused-const-variable=]
 static const char erase_seq[] = "\b \b"; /* erase sequence */

The code in question is at:
http://git.denx.de/?p=u-boot.git;a=blob;f=common/cli_readline.c;h=ecded11ca3985f27b132ef4d20f7e79ee02c8379;hb=11db152246607868f0e74db958947fbf79f28119

If we examine the generated .map file we can see that
cli_readline_into_buffer() is kept in the binary as it is used.  That in turn
makes use of both tab_seq and erase_seq (as well as delete_char() which also
uses them).

[Bug sanitizer/80424] libasan uses tempnam tmpnam tmpnam_r

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Yes, exactly.

[Bug fortran/37336] [F03] Finish derived-type finalization

[dominiq at lps dot ens.fr]

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

Bug 67505 Summary: [F03] bogus runtime error with final subroutine and 
-fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67505

   What|Removed |Added

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

[Bug fortran/67505] [F03] bogus runtime error with final subroutine and -fcheck=recursion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr80361.

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

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kergonath at me dot com

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

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---


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

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||Glenn.Hyland at utas dot edu.au

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

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[dominiq at gcc dot gnu.org]

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

--- Comment #10 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Apr 14 13:00:02 2017
New Revision: 246929

URL: https://gcc.gnu.org/viewcvs?rev=246929=gcc=rev
Log:
2017-04-14  Dominique d'Humieres  

Backport from trunk
2015-11-18  Steven G. Kargl  

PR fortran/59910
PR fortran/80388
* primary.c (gfc_match_structure_constructor): Reduce a structure
constructor in a DATA statement.

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


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr59910.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/primary.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Fri Apr 14 13:00:02 2017
New Revision: 246929

URL: https://gcc.gnu.org/viewcvs?rev=246929=gcc=rev
Log:
2017-04-14  Dominique d'Humieres  

Backport from trunk
2015-11-18  Steven G. Kargl  

PR fortran/59910
PR fortran/80388
* primary.c (gfc_match_structure_constructor): Reduce a structure
constructor in a DATA statement.

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


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr59910.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/primary.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|--- |7.0

[Bug tree-optimization/80426] [7 Regression] Wrong constant folding

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com
   Target Milestone|--- |7.0

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|--- |7.0

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-04-14
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE on valid code at -O3 in |[7 Regression] ICE on valid
   |32-bit mode on  |code at -O3 in 32-bit mode
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |operator[], at vec.h:732|operator[], at vec.h:732
  Known to fail||7.0.1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242569, but it's not probably culprit.

[Bug tree-optimization/80426] [7 Regression] Wrong constant folding

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r236548.

[Bug c++/80427] New: DR1658 is implemented in C++03 and C++14 mode, but not C++11

[rs2740 at gmail dot com]

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

Bug ID: 80427
   Summary: DR1658 is implemented in C++03 and C++14 mode, but not
C++11
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Trunk GCC accepts this code given -std=c++03 or -std=c++14:

struct A {
A(int) {};
};

struct B : public virtual A {
virtual void foo() = 0;
};

struct C : public B {
C() : A(1) {}
virtual void foo()  {}
};

int main() {
C c;
return 0;
}

but rejects it with -std=c++11. 

This doesn't make much sense.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #30 from Bijan Chokoufe  ---
> Could you maybe do the following:
> 
> - Use your normal sources
> 
> - Change the compilation options to add -fdump-tree-all to the relevant
>   file
> 
> - Copy all the generated xxx.f90.whatever files (the tree dumps)
>   to a different directory
> 
> - Change intent(in) to volatile
> 
> - Rerun the compilation
> 
> and then run diff on the tree dump files to the original ones?
> If you see anything suspicious in the diffs, that might point
> to something.  Maybe you could also attach the diffs, so somebody
> else could take a look at it.

Did that, specifically I configured with FCFLAGS='-fdump-tree-all -O2 -g'. Then
I copied `.libs` to `with_volatile` (our trunk currently has the volatile
workaround per default), removed the `volatile` attribute and compiled again.
Here is the diff between `.libs` and `with_volatile` (unpack with `bzip2 -d
diff.bz2`) as I have no idea what to look for:

https://cloud.bijancn.de/index.php/s/ta2XMIVWhTUGAvX

[Bug tree-optimization/80426] [7 Regression] Wrong constant folding

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
Summary|Wrong constant folding  |[7 Regression] Wrong
   ||constant folding
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
VRP2:

_3: [0, 1]
b.1_4: VARYING
_5: [b.1_4 + -2147483648, b.1_4 + -2147483648]

Folding predicate _3 != _5 to 1

but the code was b.1_16 - -2147483648, not +.

[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
  Component|debug   |middle-end
 Ever confirmed|0   |1

--- Comment #5 from Markus Trippelsdorf  ---
Started with r246866, aka PR79671 fix.

[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Looks like RA issue.

[Bug sanitizer/80424] libasan uses tempnam tmpnam tmpnam_r

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Address sanitizer provides a sanitized versions of the functions you mentioned.
Which makes sense. The functions are not used internally, but by the software
you instrument. There it should be removed. Thus I believe the issue should be
closed as invalid.

[Bug tree-optimization/80426] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 80426
   Summary: Wrong constant folding
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC 7.0.1 for x86_64 miscompiles the following code.

% cat test.c

#define INT_MAX 0x7fff
#define INT_MIN (-INT_MAX-1)

int x;

int main (void)
{
  volatile int a = 0;
  volatile int b = -INT_MAX;
  int j;
  for( j = 0; j < 18; j += 1 ) {
x = ( (a == 0) != (b - (int)(INT_MIN) ) );
  }

  if (x != 0) __builtin_abort();

  return 0;
}

% gcc-7.0 test.c -O2
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 test.c -O3
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 test.c -Os
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-7.0.1 --disable-nls
--disable-multilib --program-suffix=-7.0 --enable-languages=c
Thread model: posix
gcc version 7.0.1 20170330 (experimental) (GCC)

[Bug middle-end/80421] [5 Regression] Case dispatch is scrambled in switch-statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.5.4, 4.6.4, 4.7.4, 4.8.5,
   ||4.9.4, 6.3.0, 7.0
   Keywords||wrong-code
   Last reconfirmed||2017-04-14
  Component|c   |middle-end
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Case dispatch is scrambled  |[5 Regression] Case
   |in switch-statement |dispatch is scrambled in
   ||switch-statement
  Known to fail||5.4.0

--- Comment #3 from Martin Liška  ---
Confirmed, only GCC 5.x is affected. Started to be fixed on trunk by r227307.
adding Jeff to CC.

[Bug target/80419] rpmbuild with rpmrc file crashed httpd rebuild

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-14
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
.

[Bug target/80419] rpmbuild with rpmrc file crashed httpd rebuild

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
We need more information than this.  Can try to see where the illegal
instruction happens and what it is?

[Bug rtl-optimization/80425] New: Extra inter-unit register move with zero-extension

[ubizjak at gmail dot com]

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

Bug ID: 80425
   Summary: Extra inter-unit register move with zero-extension
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

The testcase is taken from PR80381:

--cut here--
#include 

__m512i
f1 (__m512i x, int a)
{
  return _mm512_srai_epi32 (x, a);
}
--cut here--

When compiled with -O2 -mavx512f -mtune=intel, the resulting assembly reads:

f1:
movl%edi, %edi  # 8 *zero_extendsidi2/4 [length = 2]
vmovq   %rdi, %xmm1 # 21*movdi_internal/20  [length = 6]
vpsrad  %xmm1, %zmm0, %zmm0 # 13ashrv16si3/1[length = 6]
ret # 24simple_return_internal  [length = 1]

(insn 8) and (insn 21) could be merged to

vmovd   %edx, %xmm0 # 13*zero_extendsidi2/10[length = 6]

Register allocator somehow avoids zero-extension to SSE reg in (insn 8) and
generates input reload (insn 21) for (insn 13):

Inserting insn reload before:
   21: r100:DI=r196:DI
 ...
 Choosing alt 19 in insn 21:  (0) ?*Yi  (1) r {*movdi_internal}

RA could choose the same (?*Yi, r) alternative in the (insn 12).

REE pass also doesn't merge (insn 8) and (insn 21).

[Bug debug/80423] [7 Regression] GC related -fcompare-debug failure

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Created attachment 41200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41200=edit
unreduced testcase

On ppc64le:

 % /home/trippels/gcc_7/usr/local/bin/g++ -fcompare-debug --param
ggc-min-expand=20 --param ggc-min-heapsize=500 -c -O3 SampleProfReader.ii   
g++: error: SampleProfReader.ii: -fcompare-debug failure (length)

[Bug debug/80423] [7 Regression] GC related -fcompare-debug failure

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
MEM_KEEP_ALIAS_SET_P (x)
In mem expressions, 1 if we should keep the alias set for this mem unchanged
when we access a component. Set to 1, for example, when we are already in a
non-addressable component of an aggregate. Stored in the jump field and printed
as ‘/j’.

[Bug debug/80423] [7 Regression] GC related -fcompare-debug failure

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Ah, it works with -param ggc-min-expand=20 --param ggc-min-heapsize=500:

trippels@gcc2-power8 llvm_build % diff -u SampleProfReader.gkd
SampleProfReader.gk.gkd
--- SampleProfReader.gkd2017-04-14 06:32:16.681702585 +
+++ SampleProfReader.gk.gkd 2017-04-14 06:32:23.781870855 +
@@ -60591,7 +60591,7 @@
 (const_int 136 [0x88])) [ MEM[(struct _Rb_tree_header
*) + 88B]._M_header._M_left+0 S8 A64])
 (reg/f:DI 20 20 [600]))
"/home/trippels/gcc_7/usr/local/include/c++/7.0.1/bits/stl_tree.h":209#
{*movdi_internal64}
  (nil))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 10 10 [623])) [ MEM[(struct FunctionSamples
*)]+0 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [605])
 (parallel [
@@ -60613,7 +60613,7 @@
 (plus:DI (reg/f:DI 30 30 [orig:172 _59 ] [172])
 (const_int 40 [0x28])))# {*adddi3}
  (nil))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 10 10 [624])) [ MEM[(struct FunctionSamples
*)]+32 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [607])
 (parallel [
@@ -60624,7 +60624,7 @@
 ])))
"/home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp":386#
{*vsx_stxvd2x4_le_v4si}
  (expr_list:REG_DEAD (reg:DI 10 10 [624])
 (nil)))
-(insn # 0 0 (set (mem/c:DI (plus:DI (reg/f:DI 1 1)
+(insn # 0 0 (set (mem/j/c:DI (plus:DI (reg/f:DI 1 1)
 (const_int 112 [0x70])) [ MEM[(struct FunctionSamples
*)]+80 S8 A128])
 (reg:DI 9 9 [389]))
"/home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp":386#
{*movdi_internal64}
  (nil))
@@ -60632,7 +60632,7 @@
 (plus:DI (reg/f:DI 30 30 [orig:172 _59 ] [172])
 (const_int 8 [0x8])))
"/home/trippels/llvm/include/llvm/ProfileData/SampleProf.h":194# {*adddi3}
  (nil))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 8 8 [625])) [ MEM[(struct FunctionSamples
*)]+16 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [606])
 (parallel [
@@ -67874,7 +67874,7 @@
  (expr_list:REG_EQUIV (plus:DI (reg/f:DI 113 sfp)
 (const_int 120 [0x78]))
 (nil)))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 8 8 [1446])) [ MEM[(struct FunctionSamples
*)]+0 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [1595])
 (parallel [
@@ -67891,7 +67891,7 @@
 (insn # 0 0 (set (reg:DI 8 8 [1958])
 (const_int 64 [0x40]))
"/home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp":189#
{*movdi_internal64}
  (nil))
-(insn # 0 0 (set (mem/c:DI (plus:DI (reg/f:DI 1 1)
+(insn # 0 0 (set (mem/j/c:DI (plus:DI (reg/f:DI 1 1)
 (const_int 112 [0x70])) [ MEM[(struct FunctionSamples
*)]+80 S8 A128])
 (reg:DI 9 9 [841]))
"/home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp":189#
{*movdi_internal64}
  (nil))
@@ -67899,7 +67899,7 @@
 (plus:DI (reg/f:DI 30 30 [orig:193 _151 ] [193])
 (const_int 40 [0x28])))# {*adddi3}
  (nil))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 8 8 [1958])) [ MEM[(struct FunctionSamples
*)]+32 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [1597])
 (parallel [
@@ -67918,7 +67918,7 @@
 (plus:DI (reg/f:DI 30 30 [orig:193 _151 ] [193])
 (const_int 8 [0x8])))
"/home/trippels/llvm/include/llvm/ProfileData/SampleProf.h":194# {*adddi3}
  (nil))
-(insn:TI # 0 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 1 1)
+(insn:TI # 0 0 (set (mem/j/c:V4SI (plus:DI (reg/f:DI 1 1)
 (reg:DI 7 7 [1959])) [ MEM[(struct FunctionSamples
*)]+16 S16 A128])
 (vec_select:V4SI (reg:V4SI 43 11 [1596])
 (parallel [

[Bug debug/80423] [7 Regression] GC related -fcompare-debug failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||GC, wrong-code
 Status|NEW |UNCONFIRMED
   Last reconfirmed|2017-04-14 00:00:00 |
 Ever confirmed|1   |0

--- Comment #2 from Andrew Pinski  ---
--param ggc-min-expand=0 --param ggc-min-heapsize=0 

You might be able to reproduce it with:
--param ggc-min-expand=1 --param ggc-min-heapsize=1

Which makes it faster normally.

[Bug sanitizer/80424] New: libasan uses tempnam tmpnam tmpnam_r

[zeccav at gmail dot com]

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

Bug ID: 80424
   Summary: libasan uses tempnam tmpnam tmpnam_r
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Running make check on an address sanitized version of gcc trunk 246751
I get lots of the following:

/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tempnam' is dangerous, better use `mkstemp'
/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tmpnam' is dangerous, better use `mkstemp'
/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tmpnam_r' is dangerous, better use `mkstemp'

Is the address sanitizer using dangerous system calls?

Then they should be changed to mkstemp. 

Otherwise is there a way to avoid those warnings?
Maybe setting a global variable?

[Bug debug/80423] New: [7 Regression] GC related -fcompare-debug failure

[trippels at gcc dot gnu.org]

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

Bug ID: 80423
   Summary: [7 Regression] GC related -fcompare-debug failure
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 llvm_build % GCC_COMPARE_DEBUG=1
/home/trippels/gcc_7/usr/local/bin/g++ --param ggc-min-expand=30 --param
ggc-min-heapsize=2000 -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_GLOBAL_ISEL -D_DEBUG
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/ProfileData -I/home/trippels/llvm/lib/ProfileData
-Iinclude -I/home/trippels/llvm/include -fPIC -fvisibility-inlines-hidden
-Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -Wno-implicit-fallthrough -O3 -pipe
-UNDEBUG -fno-exceptions -fno-rtti -MD -MT
lib/ProfileData/CMakeFiles/LLVMProfileData.dir/SampleProfReader.cpp.o -MF
lib/ProfileData/CMakeFiles/LLVMProfileData.dir/SampleProfReader.cpp.o.d -o
lib/ProfileData/CMakeFiles/LLVMProfileData.dir/SampleProfReader.cpp.o -c
/home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp

g++: error: /home/trippels/llvm/lib/ProfileData/SampleProfReader.cpp:
-fcompare-debug failure (length)

Doesn't happen for gcc-6. 
Unfortunately the issue goes away if I add --save-temps, so I'm not sure how to
debug this any further.