[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[wilson at gcc dot gnu.org]

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

--- Comment #26 from Jim Wilson  ---
I can reproduce the problem with this new reduced testcase.  I don't have
knowledge of all of the details how the gcc implementation of LTO works, but my
understanding goes something like this.

The testcase is defining memset.  Memset is a reserved identifier (ISO C
section 7.1.3).  So the testcase is violating the ISO C standard.

The memset definition in the input source is LTO optimized, which means it gets
turned into an LTO symbol that is not immediately visible to the linker.  The
linker sees the startfiles first, and then the LTO optimized files.  The crt0.o
file has a reference to memset.  The linker can't use the LTO optimized memset
to satisfy this reference, because it is still a special LTO symbol not a
normal symbol.  So it pulls in memset from the C library to satisfy the
reference.  The linker then looks at the LTO optimized files, calls the
compiler to convert them from LTO symbols into normal symbols, and then
discovers that it has two memset functions, and because
--allow-multiple-definitions is given, it arbitrarily discards one instead of
giving an error.  Since the memset from libc.a was already linked in, I don't
think it has much choice, and has to drop the new one from LTO.

The main function was LTO optimized expecting that it would call the LTO
optimized memset function, which uses a restricted register set, thus allowing
main to use normally call clobbered registers across the memset call.  However,
if the linker drops the LTO optimized memset, then we get a call to the library
memset, which clobbers all call clobbered regs, and the main function fails.

The problem is primarily with the testcase, and secondarily with how LTO works.

If the LTO link converted the LTO symbols into normal symbols before trying to
resolve unsatisfied symbols from crt0.o, that would appear to solve the
problem.  This would require changes to the linker, changes that may or may not
be reasonable.

If crt0.o didn't call memset, that would solve the problem, but that isn't a
very reasonable solution.  There may also be issues with other standard library
functions and/or other start files.

If the newlib C library was built as a shared library that would appear to
solve the problem, as the LTO symbol would override the shared library symbol,
but that isn't a reasonable solution for an embedded target.

The easy solution is to stop running this test on embedded targets that don't
have a shared C library.

[Bug c/16351] NULL dereference warnings

[msebor at gcc dot gnu.org]

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

--- Comment #50 from Martin Sebor  ---
Yes, -Wnull-dereference is only in GCC 6 and later.  -Wnonnull is in 5 and
prior but it does only a superficial job of checking (it only detects null
pointer constants).  in GCC 7, -Wnonnull does a better job (but it's still far
from perfect).

Null pointer checking (and everything else) is always done per function.  The
challenge isn't in implementing it but rather in striking the right balance
between the stages of compilation at which the checking is done.  When done
early early we may miss instances that could be exposed by later stages
(optimizations).  When done late we start flagging instances introduced by the
earlier transformations that didn't appear in the original source code (and
that may never be executed).  It's a delicate balance between false negatives
and false positives.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #9 from Jeffrey Walton  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> > test.cxx:53:21: error: 'llrint' was not declared in this scope
> >llrint(0.0);
> >  ^
> > test.cxx:54:23: error: 'llrintf' was not declared in this scope
> >llrintf(0.0f);
> >^
> > test.cxx:55:23: error: 'llrintl' was not declared in this scope
> >llrintl(0.0l);
> >^
> > test.cxx:56:22: error: 'llround' was not declared in this scope
> >llround(0.0);
> >   ^
> > test.cxx:57:24: error: 'llroundf' was not declared in this scope
> >llroundf(0.0f);
> > ^
> > test.cxx:58:24: error: 'llroundl' was not declared in this scope
> >llroundl(0.0l);
> > ^
> 
> Because these six functions are missing we treat all C99 math functions as
> missing. We could split the checks into two pieces, so we check for these
> separately, which would allow the rest of the C99 math library to be
> imported into namespace std.

This patch for libc++ may be useful to you for OS X 10.6 and below (thanks to
KC):
https://github.com/jeremyhu/libcxx/commit/720feba4874d4ca3131753dc31af127e3c509c36

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #8 from Jeffrey Walton  ---

> Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of
> the MacPorts downloads. Its the largest percentage for the OS group. Confer,
> http://stats.macports.neverpanic.de/os_statistics#osx_version.
> 
> Also, according to https://trac.macports.org/ticket/53226#comment:5, the
> issue affects both PPC and Intel machines. So it affects 100% of the
> architectures (even though PPC makes up less than 2%).
> 
> I wonder how many Homebrew or Fink users (et al) have similar statistics.

My bad... I misread the statistic because both OS X 10.11 and 10.5 use green
(thanks CL). According to the statistic, OS X 10.5 appears to account for 5%
for the group.

[Bug c++/78948] [C++17] constexpr if instantiating too eagerly

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from Jason Merrill  ---
I seem to remember some discussion in Oulu about why it wouldn't work to call
discarded statements unevaluated, but I don't remember the reasoning.  I
suppose it's that we say a few things about unevaluated operands that we don't
want to apply: prohibiting lambdas, and allowing bare non-static data members
(DR 850).  The former is easy to handle; the latter doesn't seem worth worrying
much about.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #7 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #5)
> (In reply to Jonathan Wakely from comment #2)
> ...
> > But OS X 10.5.8 is pretty old, and this might not be worth doing if it
> > doesn't affect current versions of OS x.
> 
> The issue seems to affect Android as well:
> http://stackoverflow.com/q/22922961. I am not sure if its the exact same
> issue however.
> 
> Splitting the checks may benefit more than an ancient PowerMac.
> 
> For what its worth, I keep the antique hardware around for testing on the
> PowerPC, which is big-endian. Otherwise it would be retired.

Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of the
MacPorts downloads. Its the largest percentage for the OS group. Confer,
http://stats.macports.neverpanic.de/os_statistics#osx_version.

Also, according to https://trac.macports.org/ticket/53226#comment:5, the issue
affects both PPC and Intel machines. So it affects 100% of the architectures
(even though PPC makes up less than 2%).

I wonder how many Homebrew or Fink users (et al) have similar statistics.

[Bug pch/78970] GCC crashes if input file is dash

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
This change causes a regression testing glibc.  glibc uses "gcc -E -x 
c-header -", which now results in an error "cannot use '-' as input 
filename for a precompiled header".  But that use with -E is not creating 
a precompiled header, so should not result in an error.

[Bug other/79018] New: translatable string typo in params.def:1105

[fmarchal at perso dot be]

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

Bug ID: 79018
   Summary: translatable string typo in params.def:1105
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

The message "Maximum number of constant stores to merge in thestore merging
pass" lacks a space in "the store" I presume.

Message found in
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed
to translators.

[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
(In reply to Aldy Hernandez from comment #6)
[...] 
> That should still be line 1 and column 511.  Why is it line 4 and column
> 127?  Something smells fishy.

Something is going wrong with the linemaps.  I'm investigating.

[Bug preprocessor/13498] CPP include search path documentation is incorrect

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from sandra at gcc dot gnu.org ---
The search path reported by -v for various versions/targets of CPP I have
installed here doesn't look like what was reported from the previous discussion
on this ticket back in 2003.  I think the best way to
correct/robustify/future-proof this documentation is to tell users to use -v,
instead of hard-coding a directory list in the CPP manual.  (Maybe as a future
enhancement it would be friendlier to have a new -print-include-path option
specifically to get this information, instead of having to dig through the -v
output.)

I also confirmed that the "paragraph about dirs appearing twice" is inaccurate
per current behavior, and will take that out as part of the rewrite.

[Bug target/71695] m68k: long long multiplication broken

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Martin,
No idea what might be going on here.

Could you compile yourr testcase with "-fdump-tree-all-blocks-details -dap" on
whatever system exhibits this problem and attach the slew of debugging dumps to
this BZ.  A compressed tarball would be fine.

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #16 from Jeffrey A. Law  ---
Fixed on the trunk.  No current plans to backport to release branches.

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[law at gcc dot gnu.org]

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

--- Comment #15 from Jeffrey A. Law  ---
Author: law
Date: Fri Jan  6 21:21:02 2017
New Revision: 244184

URL: https://gcc.gnu.org/viewcvs?rev=244184=gcc=rev
Log:
2017-01-06  Mikael Pettersson  

PR target/57583
* config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option.
* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle
TARGET_LONG_JUMP_TABLE_OFFSETS.
* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise.
(ASM_OUTPUT_ADDR_DIFF_ELF): Likewise.
* config/m68k/m68k.md (tablejump expander): Likewise.
(*tablejump_pcrel_hi): Renamed from unnamed insn, reject
TARGET_LONG_JUMP_TABLE_OFFSETS.
(*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS.
* doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/linux.h
trunk/gcc/config/m68k/m68k.h
trunk/gcc/config/m68k/m68k.md
trunk/gcc/config/m68k/m68k.opt
trunk/gcc/config/m68k/m68kelf.h
trunk/gcc/config/m68k/netbsd-elf.h
trunk/gcc/doc/invoke.texi

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> > test.cxx:53:21: error: 'llrint' was not declared in this scope
> >llrint(0.0);
> >  ^
> > test.cxx:54:23: error: 'llrintf' was not declared in this scope
> >llrintf(0.0f);
> >^
> > test.cxx:55:23: error: 'llrintl' was not declared in this scope
> >llrintl(0.0l);
> >^
> > test.cxx:56:22: error: 'llround' was not declared in this scope
> >llround(0.0);
> >   ^
> > test.cxx:57:24: error: 'llroundf' was not declared in this scope
> >llroundf(0.0f);
> > ^
> > test.cxx:58:24: error: 'llroundl' was not declared in this scope
> >llroundl(0.0l);
> > ^
> 
> Because these six functions are missing we treat all C99 math functions as
> missing. We could split the checks into two pieces, so we check for these
> separately, which would allow the rest of the C99 math library to be
> imported into namespace std.
> 
> But OS X 10.5.8 is pretty old, and this might not be worth doing if it
> doesn't affect current versions of OS x.

10.5.8 is what I'm still on, too. Iain Sandoe has been committing patches
targeting 10.4 and 10.5 recently, as well. I'd say it's worth doing.

[Bug middle-end/71905] bogus -Wlarger-than=N and -Wframe-larger-than= -Wstack-usage= warnings on small objects with large N

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> To get around the INT_MAX limit the -Walloc-size-larger-than accepts numbers
> with suffixes like KB and MB.  Other options that accept sizes should
> probably accept the same suffixes for consistency.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #5 from Jeffrey Walton  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> ...   ^
> 
> Because these six functions are missing we treat all C99 math functions as
> missing. We could split the checks into two pieces, so we check for these
> separately, which would allow the rest of the C99 math library to be
> imported into namespace std.
> 
> But OS X 10.5.8 is pretty old, and this might not be worth doing if it
> doesn't affect current versions of OS x.

The issue seems to affect Android as well: http://stackoverflow.com/q/22922961.
I am not sure if its the exact same issue however.

Splitting the checks may benefit more than an ancient PowerMac.

For what its worth, I keep the antique hardware around for testing on the
PowerPC, which is big-endian. Otherwise it would be retired.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
(In reply to Jonathan Wakely from comment #3)
> Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5
> -dumpmachine' to the Target field of this bug report? Thanks.

  $ /opt/local/bin/g++-mp-5 -dumpmachine
  ppc-apple-darwin9

If it matters, the machine is 32-bit by default:

  $ getconf LONG_BIT
  32

But its capable of 64-bit code with -m64 or -arch ppc64.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5
-dumpmachine' to the Target field of this bug report? Thanks.

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jeffrey Walton from comment #0)
> test.cxx:53:21: error: 'llrint' was not declared in this scope
>llrint(0.0);
>  ^
> test.cxx:54:23: error: 'llrintf' was not declared in this scope
>llrintf(0.0f);
>^
> test.cxx:55:23: error: 'llrintl' was not declared in this scope
>llrintl(0.0l);
>^
> test.cxx:56:22: error: 'llround' was not declared in this scope
>llround(0.0);
>   ^
> test.cxx:57:24: error: 'llroundf' was not declared in this scope
>llroundf(0.0f);
> ^
> test.cxx:58:24: error: 'llroundl' was not declared in this scope
>llroundl(0.0l);
> ^

Because these six functions are missing we treat all C99 math functions as
missing. We could split the checks into two pieces, so we check for these
separately, which would allow the rest of the C99 math library to be imported
into namespace std.

But OS X 10.5.8 is pretty old, and this might not be worth doing if it doesn't
affect current versions of OS x.

[Bug c++/78966] Unjustified variadic template instantiation

[gcc-bugzilla at contacts dot eelis.net]

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

Eelis  changed:

   What|Removed |Added

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

--- Comment #6 from Eelis  ---
Ah, thanks for the explanation! That makes sense.

I guess that to avoid this problem, one should adhere to a rule along the lines
of:

"If you're about to write a function like

  template
  R f(X);

then if f is potentially overloaded, and X cannot be instantiated with an empty
pack, you better write f as:

  template
  R f(X)

because otherwise calls to those other fs may end up requiring X to be
instantiable with an empty pack."

I now use this workaround for my operator<< for std::variant.

Closing.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
At least for me it hangs already in that r216281:
timeout 20 /opt/notnfs/gcc-bisect/obj/gcc/cc1.216281 -quiet -O3
-march=pentium-m -m32 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer
pr78911.c; echo $?
124
-bash-4.3$ timeout 20 /opt/notnfs/gcc-bisect/obj/gcc/cc1.216280 -quiet -O3
-march=pentium-m -m32 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer
pr78911.c; echo $?
0
(the latter is instant, fraction of a second).

[Bug c++/78966] Unjustified variadic template instantiation

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #5 from Richard Smith  ---
The vari in f is a non-deduced context because the corresponding argument
is an overloaded function that cannot be resolved. The pack T can't be deduced,
so it is inferred to be an empty pack.

Here's another case that needs the above rules in order to work:

  template struct X {};
  template struct vari { vari(void(*)(X)); };

  template void f(vari);
  template void g(X);

  void h() { f(g); } // 'f' is equivalent to 'f<>'; T is an empty pack

[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton  ---
Also see Issue 53226 in the MacPorts issue tracker. "gcc5 @5.4: error:
'std::log2' has not been declared", https://trac.macports.org/ticket/53226.

[Bug libstdc++/79017] New: Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"

[noloader at gmail dot com]

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

Bug ID: 79017
   Summary: Old PowerMac G5, MacPorts GCC 5.4, C++11 and
"std::log2 has not been declared"
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I'm working on a PowerMac G5. It runs OS X 10.5.8. It has MacPorts installed
for updated gear.

The program:

$ cat test.cxx
#include 
int main(int argc, char* argv[])
{
double d = std::log2(2.3456789f);
return 0;
}

Results:

$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main(int, char**)':
test.cxx:4:16: error: 'log2' is not a member of 'std'
 double d = std::log2(2.3456789f);
^
test.cxx:4:16: note: suggested alternative:
In file included from /usr/include/math.h:26:0,
 from /opt/local/include/gcc5/c++/cmath:44,
 from test.cxx:1:
/usr/include/architecture/ppc/math.h:431:15: note:   'log2'
 extern double log2( double );
   ^

Compiler:

$ /opt/local/bin/g++-mp-5 --version
g++-mp-5 (MacPorts gcc5 5.4.0_0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
...

***

From JW offlist:

#include 
int main() {
  typedef double_t  my_double_t;
  typedef float_t   my_float_t;
  acosh(0.0);
  acoshf(0.0f);
  acoshl(0.0l);
  asinh(0.0);
  asinhf(0.0f);
  asinhl(0.0l);
  atanh(0.0);
  atanhf(0.0f);
  atanhl(0.0l);
  cbrt(0.0);
  cbrtf(0.0f);
  cbrtl(0.0l);
  copysign(0.0, 0.0);
  copysignf(0.0f, 0.0f);
  copysignl(0.0l, 0.0l);
  erf(0.0);
  erff(0.0f);
  erfl(0.0l);
  erfc(0.0);
  erfcf(0.0f);
  erfcl(0.0l);
  exp2(0.0);
  exp2f(0.0f);
  exp2l(0.0l);
  expm1(0.0);
  expm1f(0.0f);
  expm1l(0.0l);
  fdim(0.0, 0.0);
  fdimf(0.0f, 0.0f);
  fdiml(0.0l, 0.0l);
  fma(0.0, 0.0, 0.0);
  fmaf(0.0f, 0.0f, 0.0f);
  fmal(0.0l, 0.0l, 0.0l);
  fmax(0.0, 0.0);
  fmaxf(0.0f, 0.0f);
  fmaxl(0.0l, 0.0l);
  fmin(0.0, 0.0);
  fminf(0.0f, 0.0f);
  fminl(0.0l, 0.0l);
  hypot(0.0, 0.0);
  hypotf(0.0f, 0.0f);
  hypotl(0.0l, 0.0l);
  ilogb(0.0);
  ilogbf(0.0f);
  ilogbl(0.0l);
  lgamma(0.0);
  lgammaf(0.0f);
  lgammal(0.0l);
  llrint(0.0);
  llrintf(0.0f);
  llrintl(0.0l);
  llround(0.0);
  llroundf(0.0f);
  llroundl(0.0l);
  log1p(0.0);
  log1pf(0.0f);
  log1pl(0.0l);
  log2(0.0);
  log2f(0.0f);
  log2l(0.0l);
  logb(0.0);
  logbf(0.0f);
  logbl(0.0l);
  lrint(0.0);
  lrintf(0.0f);
  lrintl(0.0l);
  lround(0.0);
  lroundf(0.0f);
  lroundl(0.0l);
  nan(0);
  nanf(0);
  nanl(0);
  nearbyint(0.0);
  nearbyintf(0.0f);
  nearbyintl(0.0l);
  nextafter(0.0, 0.0);
  nextafterf(0.0f, 0.0f);
  nextafterl(0.0l, 0.0l);
  nexttoward(0.0, 0.0);
  nexttowardf(0.0f, 0.0f);
  nexttowardl(0.0l, 0.0l);
  remainder(0.0, 0.0);
  remainderf(0.0f, 0.0f);
  remainderl(0.0l, 0.0l);
  remquo(0.0, 0.0, 0);
  remquof(0.0f, 0.0f, 0);
  remquol(0.0l, 0.0l, 0);
  rint(0.0);
  rintf(0.0f);
  rintl(0.0l);
  round(0.0);
  roundf(0.0f);
  roundl(0.0l);
  scalbln(0.0, 0l);
  scalblnf(0.0f, 0l);
  scalblnl(0.0l, 0l);
  scalbn(0.0, 0);
  scalbnf(0.0f, 0);
  scalbnl(0.0l, 0);
  tgamma(0.0);
  tgammaf(0.0f);
  tgammal(0.0l);
  trunc(0.0);
  truncf(0.0f);
  truncl(0.0l);
  return 0;
}

Results in:

$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main()':
test.cxx:53:21: error: 'llrint' was not declared in this scope
   llrint(0.0);
 ^
test.cxx:54:23: error: 'llrintf' was not declared in this scope
   llrintf(0.0f);
   ^
test.cxx:55:23: error: 'llrintl' was not declared in this scope
   llrintl(0.0l);
   ^
test.cxx:56:22: error: 'llround' was not declared in this scope
   llround(0.0);
  ^
test.cxx:57:24: error: 'llroundf' was not declared in this scope
   llroundf(0.0f);
^
test.cxx:58:24: error: 'llroundl' was not declared in this scope
   

[Bug c++/78966] Unjustified variadic template instantiation

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
Note that clang also triggers the static_assert, so there might be something
deeper going on here. :)

[Bug c++/78966] Unjustified variadic template instantiation

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com

--- Comment #3 from Ville Voutilainen  ---
Jason, care to look at this? There have been suggestions along the lines
that [temp.inst]/6 might mean that the template may or may not get
instantiated, so I'm not sure whether there's a conformance issue here.
There certainly might be a QoI issue nonetheless.

[Bug c/16351] NULL dereference warnings

[jg at jguk dot org]

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

--- Comment #49 from Jon Grant  ---
(In reply to Martin Sebor from comment #48)
> Send a check to Manuel ;)  The feature is available under the
> -Wnull-dereference option (see comment 31).  Unfortunately, due to false
> positives, the option was removed from -Wall in a subsequent commit
> (r226751) and has to be enabled explicitly.
> 
> The similar -Wnonnull option that was just recently enhanced to detect
> related problems is in -Wall, and it seems to me that it would make sense to
> treat both of these options the same: i.e., enable both with -Wall.  To do
> that, the former option might need to be tweaked to reduce its false
> positive rate.  At the same time, the -Wnonnull option still has a high rate
> of false negatives and so it could stand to be enhanced to do a better job. 
> The challenge is striking the right balance between the two rates that is
> acceptable to everyone.

Thank you for your reply.

-Werror=null-dereference doesn't seem to be in my compiler:
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Is it just in GCC6 branch?

-Wnonnull  is present though.


Re the feature, I think it can't be that hard to check per function can it...?

[Bug tree-optimization/79006] [6/7 Regression] Invalid transformation in tree-dominators pass

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #1 from Bill Schmidt  ---
Hm, no, this isn't invalid code at all.  Sorry for the noise.  I need to get
back with the guy that reported this to me and see what's going on.  I think he
lost the original problem when reducing the test case.

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Martin Liška from comment #6)
> Created attachment 40409 [details]
> head -n70 tc.i.274r.reload
> 
> So the problem is older than r221983.

Why do you think so? Reverting r221983 one-liner, introduced in PR65710 as a
performance fix for earlier patch, allows me to compile the testcase.

(In reply to Jakub Jelinek from comment #7)

> Started hanging with r216281.

Referred commit allowed atomic_compare_and_swapdi_doubleword pattern to
directly use %ebx, which was not allowed before pseudo PIC reg was introduced.
Mentioned pattern pushes i686 register pressure to the limit, it is somehow
problematic for RA to handle, but RA managed to do correct reg allocation up to
r221983.

[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 17:06:24 2017
New Revision: 244169

URL: https://gcc.gnu.org/viewcvs?rev=244169=gcc=rev
Log:
Check for __cxa_thread_atexit for freebsd crosses

PR libstdc++/78968
* crossconfig.m4: Check for __cxa_thread_atexit on *-*-freebsd*.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/crossconfig.m4

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[renlin at gcc dot gnu.org]

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

--- Comment #25 from Renlin Li  ---
Created attachment 40474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40474=edit
reduced objdump assembler file

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[renlin at gcc dot gnu.org]

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

--- Comment #24 from Renlin Li  ---
Created attachment 40473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40473=edit
memset.c

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[renlin at gcc dot gnu.org]

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

--- Comment #23 from Renlin Li  ---
Created attachment 40472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40472=edit
test case

[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #22 from Renlin Li  ---
(In reply to James Greenhalgh from comment #19)

> That would be an error:
> 
> /tmp/ccpefK3l.ltrans0.ltrans.o: In function `memset':
> :(.text+0x4a0): multiple definition of `memset'
> .../aarch64-none-elf/lib/libc.a(lib_a-memset.o):
> .../newlib/libc/machine/aarch64/memset.S:90: first defined here
> 
> Were it not for the flag added to resolve PR55994
> -Wl,--allow-multiple-definition .
> 
> So, in my opinion, the testcase is broken and could always have failed in
> this way. The combination of register allocation, LTO and order the linker
> sees symbols explains why this is hard to reproduce.

I had exactly the same errors and issues today.
I reduced it to a minimum test case. Please check the new attachment

The build command line is:
aarch64-none-elf-gcc -O2 -specs=aem-ve.specs -Wl,--allow-multiple-definition
-lm -flto main.c memset.c  -o new.exe

The expected output should be "A A A 2"

80001038 :
80001038:   a9bf7bfdstp x29, x30, [sp,#-16]!
8000103c:   9123adrpx3, 80025000 <__global_locale+0x68>
80001040:   52800044mov w4, #0x2// #2
80001044:   91060060add x0, x3, #0x180
80001048:   910003fdmov x29, sp
8000104c:   b9018064str w4, [x3,#384]
80001050:   d2800402mov x2, #0x20   // #32
80001054:   52800821mov w1, #0x41   // #65
80001058:   91002000add x0, x0, #0x8

# At this function entry, x4 is not saved. Because LTO thinks the local memset
# implementation will not clobber it. However, the libc version of memeset is
# linked in the final binary. The implementation there will clobber x4. This
# will cause run-time data corruption, which is shown here.

8000105c:   94000a39bl  80003940 
80001060:   a8c17bfdldp x29, x30, [sp],#16
80001064:   52800823mov w3, #0x41   // #65
80001068:   9080adrpx0, 80011000 <__swbuf_r+0x70>
8000106c:   2a0303e2mov w2, w3
80001070:   2a0303e1mov w1, w3
80001074:   91152000add x0, x0, #0x548
80001078:   140015c0b   80006778 
8000107c:   .inst   0x ; undefined



This is mentioned above. But allow me to ask again:
"aarch64-none-elf-gcc -O2  main.c memset.c  -o new.o -specs=aem-ve.specs -lm
-flto"
will give the "multiple definition of `memset'" error
while
"aarch64-none-elf-gcc -O2  main.c memset.c  -o new.o -specs=aem-ve.specs -lm"
won't.

Should them behavior the same? By adding "-Wl,--allow-multiple-definition" do
fix this erro. But why it's the test case that is broken instead of the lto
pass?

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

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka  ---
Author: hubicka
Date: Fri Jan  6 16:10:09 2017
New Revision: 244167

URL: https://gcc.gnu.org/viewcvs?rev=244167=gcc=rev
Log:
PR middle-end/77484
* predict.def (PRED_POLYMORPHIC_CALL): Set to 58
* predict.c (tree_estimate_probability_bb): Reverse direction of
polymorphic call predictor.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/predict.def

[Bug middle-end/79016] New: missing -Wstringop-overflow= overflowing allocated buffers

[msebor at gcc dot gnu.org]

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

Bug ID: 79016
   Summary: missing -Wstringop-overflow= overflowing allocated
buffers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wstringop-overflow warning correctly detects the buffer overflow in the
fauto() and funnamed() functions below but misses all the other instances of it
in the rest of the functions.

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
void f (void*);

void fauto (void)
{
  char d[3];

  f (__builtin_memset (d, 0, 5));
}

void funnamed (void)
{
  f (__builtin_memset ((char[3]){ 0 }, 1, 5));
}

void falloca (void)
{
  char *d = __builtin_alloca (3);

  f (__builtin_memset (d, 0, 5));
}

void fmalloc (void)
{
  char *d = __builtin_malloc (3);

  f (__builtin_memset (d, 0, 5));
}

void fvla (unsigned n)
{
  if (n > 3)
n = 3;

  char d [n];

  f (__builtin_memset (d, 0, 5));
}

b.c: In function ‘fauto’:
b.c:7:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   f (__builtin_memset (d, 0, 5));
   ^~
b.c: In function ‘funnamed’:
b.c:12:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   f (__builtin_memset ((char[3]){ 0 }, 1, 5));
   ^~~

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[mikpelinux at gmail dot com]

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

--- Comment #14 from Mikael Pettersson  ---
Patch submitted:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00419.html

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ian at airs dot com
 Resolution|--- |FIXED

--- Comment #6 from Ian Lance Taylor  ---
Should be fixed.

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Jan  6 16:04:01 2017
New Revision: 244165

URL: https://gcc.gnu.org/viewcvs?rev=244165=gcc=rev
Log:
PR go/78978
libgo: build with -Wa,-nH if possible on Solaris

By default the Solaris assembler records the required hardware
capability in the object file.  This means that the AES hashing code
breaks on systems that do not support AES, even though the code uses a
runtime check to only actually invoke the AES instructions on systems
that support it.  An earlier fix for the problem only fixed the shared
library, not the static libgo.a.  Fix the problem for real by using an
assembler option to not record the hardware capability.

For GCC PR 78978.

Patch by Rainer Orth.

Reviewed-on: https://go-review.googlesource.com/34910

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/testsuite/Makefile.in

[Bug middle-end/78605] bogus -Wformat-length=1 with %f

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed.

[Bug middle-end/78605] bogus -Wformat-length=1 with %f

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Jan  6 15:45:42 2017
New Revision: 244164

URL: https://gcc.gnu.org/viewcvs?rev=244164=gcc=rev
Log:
PR middle-end/78605 - bogus -Wformat-length=1 with %f

gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr78605.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78605.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Slightly cleaned up testcase:

/* PR rtl-optimization/78911 */
/* { dg-do compile } */
/* { dg-options "-O3 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer" } */
/* { dg-additional-options "-fPIC" { target fpic } } */
/* { dg-additional-options "-march=pentium-m" { target ia32 } } */

int a, b, d, e;
long long *c;

static int
foo (long long *x)
{
  return __sync_val_compare_and_swap (x, b, a);
}

void
bar (void)
{
  if (!c)
return;
  e = foo ([d]);
}

Started hanging with r216281.

[Bug sanitizer/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org
  Component|tree-optimization   |sanitizer

--- Comment #7 from Jakub Jelinek  ---
Ah, ok, I'd say this is a kernel bug.
scripts/mod/file2alias.c (handle_moddevtable) has:
/* All our symbols are of form
__moddevice_table. */
name = strstr(symname, "__mod_");
so the __odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table symbol is also
recognized as a device table (which is wrong).
I bet
_GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table
or
_GLOBAL__sub_D_65535_0___mod_cpu__cpu_feature_match_SHA1_device_table
could trigger it too.  Dunno what is the rationale behind accepting 
there, perhaps accepting only empty prefix or _ prefix would be better.

On the gcc side, we could work around this by adding:
  if (flag_sanitize & SANITIZE_KERNEL_ADDRESS)
return false;
to asan_needs_odr_indicator_p, that assumes the kernel never wants ODR
verification (as it is written in C, that might be very likely).

[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Author: ro
Date: Fri Jan  6 14:33:47 2017
New Revision: 244162

URL: https://gcc.gnu.org/viewcvs?rev=244162=gcc=rev
Log:
Build libgo with -Wa,-nH if possible (PR go/78978) [non-libgo parts]

libstdc++-v3:
PR go/78978
* acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Remove.
* configure.ac: Call GCC_CHECK_ASSEMBLER_HWCAP instead of
GLIBCXX_CHECK_ASSEMBLER_HWCAP.
* fragment.am (CONFIG_CXXFLAGS): Use HWCAP_CFLAGS instead of
HWCAP_FLAGS.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* Makefile.in, doc/Makefile.in, include/Makefile.in,
libsupc++/Makefile.in, po/Makefile.in, python/Makefile.in,
src/Makefile.in, src/c++11/Makefile.in, src/c++98/Makefile.in,
src/filesystem/Makefile.in, testsuite/Makefile.in: Regenerate.

config:
PR go/78978
* hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): New macro.

Modified:
trunk/config/ChangeLog
trunk/config/hwcaps.m4
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/Makefile.in
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/aclocal.m4
trunk/libstdc++-v3/configure   (contents, props changed)
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/doc/Makefile.in
trunk/libstdc++-v3/fragment.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/libsupc++/Makefile.in
trunk/libstdc++-v3/po/Makefile.in
trunk/libstdc++-v3/python/Makefile.in
trunk/libstdc++-v3/src/Makefile.in
trunk/libstdc++-v3/src/c++11/Makefile.in
trunk/libstdc++-v3/src/c++98/Makefile.in
trunk/libstdc++-v3/src/filesystem/Makefile.in
trunk/libstdc++-v3/testsuite/Makefile.in

[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[wilco at gcc dot gnu.org]

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

--- Comment #18 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Fri Jan  6 14:26:06 2017
New Revision: 244161

URL: https://gcc.gnu.org/viewcvs?rev=244161=gcc=rev
Log:
With -fpu=neon DI mode shifts are expanded after reload.  DI mode registers can 
either fully or partially overlap on both ARM and Thumb-2.  However the shift
expansion code can only deal with the full overlap case, and generates
incorrect
code for partial overlaps.  The fix is to add new variants that support either
full overlap or no overlap.

Backport from mainline
2016-10-25  Wilco Dijkstra  

gcc/
PR target/78041
* config/arm/neon.md (ashldi3_neon): Add "r 0 i" and " r i" variants.
Remove partial overlap check for shift by 1.
(ashldi3_neon): Likewise.
testsuite/
* gcc.target/arm/pr78041.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/pr78041.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/neon.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
.

[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |5.4.0
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.3.0, 7.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for 5.5 and 6.4

[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
I've added a workaround to the libstdc++ code, which will be included in the
gcc 5.5, 6.4 and 7.1 releases.

You'll need the updated libstdc++ headers to be able to compile this code with
clang, e.g. by requesting the Ubuntu GCC maintainers to include this patch in
their gcc builds.

[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 14:04:33 2017
New Revision: 244158

URL: https://gcc.gnu.org/viewcvs?rev=244158=gcc=rev
Log:
Add deleted std::thread(const thread&&) constructor

Backport from mainline
2017-01-03  Jonathan Wakely  

PR libstdc++/78956
* include/std/thread (thread(const thread&&)): Add deleted
constructor.
* testsuite/30_threads/thread/cons/lwg2097.cc: New test.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/30_threads/thread/cons/lwg2097.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/std/thread

[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 14:04:26 2017
New Revision: 244157

URL: https://gcc.gnu.org/viewcvs?rev=244157=gcc=rev
Log:
PR78991 make __gnu_cxx::__ops constructors explicit

PR libstdc++/78991
* include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val)
(_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val)
(_Iter_comp_to_iter, _Iter_negate): Make constructors explicit.
* testsuite/25_algorithms/sort/78991.cc: New test.

Added:
branches/gcc-5-branch/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/predefined_ops.h

[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc*-*-*, aarch64*, |powerpc*-*-*, aarch64*,
   |arm*, x86*  |arm*, x86*, sparc*
 CC||ro at gcc dot gnu.org
   Host|powerpc*-*-*|
   Target Milestone|--- |7.0
  Build|powerpc*-*-*|

--- Comment #4 from Rainer Orth  ---
Same on sparc.

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Those options don't include -fsanitize=kernel-address, so no idea where that
> earlier mentioned
> _GLOBAL__sub_D_65535_0___odr_asan.
> __mod_cpu__cpu_feature_match_SHA1_device_table
> comes from.  But, even with -fsanitize=kernel-address added to the option
> there is no *__odr_asan* symbol.
> cpu_feature_match_SHA1 is 4 bytes long regardless of that option.

Sorry, I posted the wrong command line (I was playing with different
combinations).
The proper command line is:
aarch64-none-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.sha1-ce-glue.o.d 
-nostdinc -isystem
/arm/pdtl/builds/fsf-trunk.1182/installed/rhe6x86_64/aarch64-none-linux-gnu/bin/../lib/gcc/aarch64-none-linux-gnu/7.0.0/include
-I./arch/arm64/include -I./arch/arm64/include/generated/uapi
-I./arch/arm64/include/generated  -I./include -I./arch/arm64/include/uapi
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -mbig-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1
-fno-asynchronous-unwind-tables -mpc-relative-literal-loads
-fno-delete-null-pointer-checks -Wno-frame-address -O2
--param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone
-fno-partial-inlining -fno-stack-protector -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -pg -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO   
-fsanitize=kernel-address -fasan-shadow-offset=0xdf90 --param
asan-stack=1 --param asan-globals=1 --param
asan-instrumentation-with-call-threshold=0   -fsanitize-coverage=trace-pc 
-DMODULE -mcmodel=large  -DKBUILD_BASENAME='"sha1_ce_glue"' 
-DKBUILD_MODNAME='"sha1_ce"' -c 

which does include -fsanitize=kernel-address

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Those options don't include -fsanitize=kernel-address, so no idea where that
earlier mentioned
_GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table
comes from.  But, even with -fsanitize=kernel-address added to the option there
is no *__odr_asan* symbol.
cpu_feature_match_SHA1 is 4 bytes long regardless of that option.

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Jan  6 13:56:48 2017
New Revision: 244155

URL: https://gcc.gnu.org/viewcvs?rev=244155=gcc=rev
Log:
Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06  Martin Liska  

PR bootstrap/79003
* lra-constraints.c: Rename invariant to lra_invariant.
* predict.c (set_even_probabilities): Initialize e to NULL.
2017-01-06  Martin Liska  

PR bootstrap/79003
* Makefile.in: Add -fno-lto to {C,CPP,LD}FLAGS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/predict.c
trunk/libdecnumber/ChangeLog
trunk/libdecnumber/Makefile.in

[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
From a discussion on IRC:

What's the general story on lock policies?
Are environments supposed to support all three?
(if possible)
no. it's something only used in std::shared_ptr, and generally entirely
invisible to users
What's supposed to happen if one (can't be supported)?
most people will only ever use the default one, which gets chosen according to
the target
_S_single always works, it just isn't thread-safe
But that's surely bogus if detected dynamically
if _S_atomic doesn't work for a given target then users should not try to use
it
(ie based on the CPU architecture
_S_single is only ever the default if gcc is built with --disable-threads 
Ok, so we can ignore that one, then
yeah
but seems that mutex and atomic can't be a compile time choice; it must be
selected at configure time
based on the base architecture used at that point
yes (or you have to ensure every translation unit in the program uses the same
choice)
(including the libstdc++.so linked to)
But we can't guarantee that if you use the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
macros
since those are dependent on certain patterns being enabled in the back-end of
the compiler, and that's dependent on the architecture.
yep
I think it would be better to move the _atomic _mutex check into configure and
create a new macro based on the result of a test performed then
at least then a build of the library would always work with code compiled with
that compiler
agreed
(even if it isn't quite as efficient if you normally have a later rev of the
architecture)
OK, I'll put that in the PR
so IIUC, if gcc is configured for armv7 (and so chooses the _S_atomic policy)
and then somebody builds their code with -mcpu=armv5 they will need to link to
libatomic to get the necessary atomic ops
if that's correct, it seems fine to me. when this lock policy stuff was
invented we didn't have libatomic, and so some arches simply didn't have
atomics, period
Yes, provided the compiler correctly falls back into the library code in that
case.
now we can punt to libatomic, so can use _S_atomic for any arch with a
libatomic implementation
It would be a bit odd-ball to build for ARMv5 if your library is v7 anyway
(you'd still need a v7 device to run it on)
yep
So I won't loose too much sleep over that combination
people seem to do that though
maybe just for testing, I don't know
Probably for that
ok, so not a real case we need to support
good
Not performant, anyway
Do you mind if I just paste the above directly into the PR?

[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 13:20:10 2017
New Revision: 244153

URL: https://gcc.gnu.org/viewcvs?rev=244153=gcc=rev
Log:
Add deleted std::thread(const thread&&) constructor

Backport from mainline
2017-01-03  Jonathan Wakely  

PR libstdc++/78956
* include/std/thread (thread(const thread&&)): Add deleted
constructor.
* testsuite/30_threads/thread/cons/lwg2097.cc: New test.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/30_threads/thread/cons/lwg2097.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/std/thread

[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 13:20:05 2017
New Revision: 244152

URL: https://gcc.gnu.org/viewcvs?rev=244152=gcc=rev
Log:
PR78991 make __gnu_cxx::__ops constructors explicit

PR libstdc++/78991
* include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val)
(_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val)
(_Iter_comp_to_iter, _Iter_negate): Make constructors explicit.
* testsuite/25_algorithms/sort/78991.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/predefined_ops.h

[Bug debug/79015] New: ICE in get_insn_template in gcc/final.c:2081

[marxin at gcc dot gnu.org]

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

Bug ID: 79015
   Summary: ICE in get_insn_template in gcc/final.c:2081
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

All releases I have (4.5.0) ICE in following code:

$ cat /tmp/ice.c
int
foo (int x, int y)
{
  int z = x + y;
  return x * y;
}

__attribute__((optimize ("no-var-tracking"))) int
bar (int x, int y)
{
  int z = x + y;
  return x * y;
}

$ ./xgcc -B. /tmp/ice.c -g -O
/tmp/ice.c: In function ‘bar’:
/tmp/ice.c:13:1: internal compiler error: in get_insn_template, at final.c:2081
 }
 ^
0x8df156 get_insn_template(int, rtx_def*)
../../gcc/final.c:2081
0x8e171a final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2982
0x8e27d2 final(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:2046
0x8e2f89 rest_of_handle_final
../../gcc/final.c:4475
0x8e2f89 execute
../../gcc/final.c:4548

[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 #20 from Jan Hubicka  ---
Hi,
it turns out that Martin added another column to his statistics script which I
have misinterpretted.
https://gcc.opensuse.org/SPEC/CINT/sb-terbium-head-64/recent.html also shows
interesting reaction
to the change.  I will update the probabilities to correct values one by one
and let us see
how benchmarks react.  Is changing one a day enough for periodic testers to
catch up?

The hitrates on spec2k6 combined with spec v6 is as follows.
It means that indirect call should have 14%, call  67% and polymorphic call
should have oposite outcime and 59% The statistic samples are quite small and
dominated by one use, so we may diverge from those values if it seem to make
sense.

Honza


COMBINED

HEURISTICS   BRANCHES  (REL)  BR. HITRATE  
 HITRATE   COVERAGE COVERAGE  (REL)
loop guard with recursion  13   0.0%   92.31%   85.06%
/  85.06% 66724402676.67G   0.4%
Fortran loop preheader 42   0.0%   97.62%   97.78%
/  99.07%14487181.45M   0.0%
loop iv compare71   0.1%   78.87%   49.26%
/  63.89%  163168352  163.17M   0.0%
loop exit with recursion   85   0.1%   75.29%   84.89%
/  86.96% 98737414359.87G   0.6%
extra loop exit98   0.1%   71.43%   31.39%
/  76.96%  312263024  312.26M   0.0%
recursive call121   0.1%   64.46%   37.55%
/  82.78%  531996473  532.00M   0.0%
Fortran repeated allocation/deallocation  392   0.4%  100.00%  100.00%
/ 100.00%630   630.00   0.0%
guess loop iv compare 402   0.4%   90.05%   95.82%
/  96.04% 56831517715.68G   0.3%
indirect call 425   0.4%   52.00%   14.06%
/  91.41% 38153329633.82G   0.2%
Fortran zero-sized array  549   0.6%   99.64%  100.00%
/ 100.00%   20794317   20.79M   0.0%
const return  651   0.7%   94.93%   84.04%
/  93.18% 10677746531.07G   0.1%
null return   716   0.7%   92.18%   91.83%
/  93.39% 34213219563.42G   0.2%
negative return   734   0.8%   97.14%   64.62%
/  65.01% 47448863154.74G   0.3%
continue  773   0.8%   66.11%   79.71%
/  87.43%29089649102   29.09G   1.6%
polymorphic call  803   0.8%   43.59%   59.05%
/  86.63% 38285550303.83G   0.2%
Fortran fail alloc944   1.0%  100.00%  100.00%
/ 100.00% 167691  167.69K   0.0%
Fortran overflow 1237   1.3%  100.00%  100.00%
/ 100.00%   55197159   55.20M   0.0%
loop guard   1861   1.9%   48.90%   69.86%
/  84.62%17979028127   17.98G   1.0%
noreturn call3769   3.9%   99.95%  100.00%
/ 100.00% 81750534258.18G   0.5%
loop exit5017   5.2%   83.50%   90.01%
/  91.68%   143815212145  143.82G   8.1%
opcode values positive (on trees)5763   6.0%   66.23%   60.41%
/  86.25%43349211449   43.35G   2.4%
loop iterations  6276   6.6%   99.94%   78.54%
/  78.54%   662671304506  662.67G  37.3%
early return (on trees)  9512   9.9%   61.02%   58.05%
/  85.82%56222551226   56.22G   3.2%
pointer (on trees)  10969  11.5%   63.29%   75.18%
/  89.33%23318221976   23.32G   1.3%
opcode values nonequal (on trees)   11633  12.2%   63.23%   74.53%
/  85.23%   118246028039  118.25G   6.7%
guessed loop iterations 13631  14.2%   96.54%   92.61%
/  93.12%   417886815060  417.89G  23.5%
call20747  21.7%   54.47%   67.24%
/  92.56%50096613362   50.10G   2.8%

[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan  6 12:33:58 2017
New Revision: 244150

URL: https://gcc.gnu.org/viewcvs?rev=244150=gcc=rev
Log:
PR78991 make __gnu_cxx::__ops constructors explicit

PR libstdc++/78991
* include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val)
(_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val)
(_Iter_comp_to_iter, _Iter_negate): Make constructors explicit and
move function objects.
(__iter_comp_iter, __iter_comp_val, __val_comp_iter, __pred_iter)
(__iter_comp_val, __iter_comp_iter, __negate): Move function objects.
* testsuite/25_algorithms/sort/78991.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/predefined_ops.h

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Created attachment 40471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40471=edit
Preprocessed source

The command used to compile that file is:
aarch64-none-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.sha1-ce-glue.o.d 
-nostdinc -isystem
/arm/pdtl/builds/fsf-trunk.1182/installed/rhe6x86_64/aarch64-none-linux-gnu/bin/../lib/gcc/aarch64-none-linux-gnu/7.0.0/include
-I./arch/arm64/include -I./arch/arm64/include/generated/uapi
-I./arch/arm64/include/generated  -I./include -I./arch/arm64/include/uapi
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -mbig-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1
-fno-asynchronous-unwind-tables -mpc-relative-literal-loads
-fno-delete-null-pointer-checks -Wno-frame-address -O2
--param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone
-fno-partial-inlining -fno-stack-protector -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -pg -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO
-DMODULE -mcmodel=large  -DKBUILD_BASENAME='"sha1_ce_glue"' 
-DKBUILD_MODNAME='"sha1_ce"' -c

I'm still working on untangling what the kernel build system does with the
object files to generate that error...

[Bug tree-optimization/79014] New: Absent vectorization with memory loads

[jkb at sanger dot ac.uk]

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

Bug ID: 79014
   Summary: Absent vectorization with memory loads
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jkb at sanger dot ac.uk
  Target Milestone: ---

I have some code which vectorises using icc to some success, but fails to
vectorise in gcc (and clang too).  The noddy example is as follows:

#define NX 32

typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;

int bar(uint32_t *s3, uint32_t *in, int in_size, uint8_t *out, int out_size) {
const uint32_t mask = (1u << 12)-1;
int i;
uint32_t R[NX] = {0};
for (i = 0; i < out_size; i+= NX) {
int z;
#pragma omp simd aligned(in, out: 32)
for (z = 0; z < NX; z++) {
R[z] *= in[i+z];
out[i+z] = s3[R[z] & mask];
}
}
return 0;
}

This is called from a second file containing a main function to test it:

#include 

typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;

#define BS (1013*1047)

uint32_t s3[1<<12];
uint32_t in[BS];
uint8_t out[BS];

extern int bar(uint32_t *s3, uint32_t *in, int in_size, uint8_t *out, int
out_size);

int main(void) {
int i;

for (i = 0; i < (1<<12); i++)
s3[i] = (rand() << 16) ^ rand();

for (i = 0; i < BS; i++)
in[i] = (rand() << 16) ^ rand();

for (i = 0; i < 1; i++)
bar(s3, in, BS, out, BS);

return 0;
}

(The omp pragma there is purely for icc, it seems to make little difference to
gcc.)  Some benchmarks:

gcc-6.1.0:   33743262303 cycles, 97919071795 instructions
icc-15.0.0:  21561762894 cycles, 58128430729 instructions
clang-3.8.0: 36884730520 cycles, 92597500495 instructions

Compilation is via "gcc -g -O3 -fopenmp -march=native a.c b.c" and the host is
a Xeon E5-2660 (@2.2Ghz) with avx but not avx2 support (so realistically this
can be vectorised using SSE4 only as it's integer maths).  This also means it
isn't using the gather instructions, but loading from memory to sse4 registers.

icc -S confirms this, with a lot of xmm register usage.

icc with -qopt-report=5 dumps out:

   LOOP BEGIN at a.c(14,14)
  remark #15389: vectorization support: reference R has unaligned access  
[ a.c(15,13) ]
  remark #15389: vectorization support: reference R has unaligned access  
[ a.c(15,13) ]
  remark #15389: vectorization support: reference in has unaligned access  
[ a.c(15,13) ]
  remark #15389: vectorization support: reference out has unaligned access 
 [ a.c(16,13) ]
  remark #15389: vectorization support: reference R has unaligned access  
[ a.c(16,13) ]
  remark #15381: vectorization support: unaligned access used inside loop
body   [ a.c(16,13) ]
  remark #15399: vectorization support: unroll factor set to 2
  remark #15301: OpenMP SIMD LOOP WAS VECTORIZED
  remark #15448: unmasked aligned unit stride loads: 2 
  remark #15449: unmasked aligned unit stride stores: 2 
  remark #15458: masked indexed (or gather) loads: 1 
  remark #15475: --- begin vector loop cost summary ---
  remark #15476: scalar loop cost: 17 
  remark #15477: vector loop cost: 4.500 
  remark #15478: estimated potential speedup: 3.770 
  remark #15479: lightweight vector operations: 12 
  remark #15488: --- end vector loop cost summary ---
  remark #25015: Estimate of max trip count of loop=2
   LOOP END

I've no idea why it thinks those are unaligned, but it vectorised it anyway.

Gcc -fopt-info-vec-missed reports:

a.c:11:5: note: failed: evolution of base is not affine.
a.c:11:5: note: bad data references.
a.c:15:18: note: not vectorized: not suitable for gather load _28 = *_27;

a.c:15:18: note: bad data references.
a.c:11:5: note: not vectorized: no vectype for stmt: R = {};
 scalar_type: uint32_t[32]
a.c:11:5: note: not vectorized: not enough data-refs in basic block.
a.c:19:12: note: not vectorized: not enough data-refs in basic block.
a.c:13:9: note: not vectorized: not enough data-refs in basic block.
a.c:16:22: note: not consecutive access _28 = *_27;
a.c:16:22: note: not vectorized: no grouped stores in basic block.
a.c:11:5: note: not vectorized: not enough data-refs in basic block.

Adding __attribute__((aligned(32))) to the R[] definition didn't help.

I've explored up to gcc 7 via the online tool at https://godbolt.org/ and can
confirm the lack of vectorisation still, although that seems to show clang
gains vectorisation too.

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Ping, any progress?
Is the module built with -fsanitize=kernel-address?  I don't see any
cpu_device_id struct in the kernel, so the message is just weird.
There is module_cpu_feature_match though which uses MODULE_DEVICE_TABLE.
Perhaps the sanitization adds the odr byte into that section?

Though, not sure how that would happen, because the odr byte is only created in
asan_add_global which is called when asan_protect_global is true, which should
not be the case for variables with user sections.

In any case, please attach the preprocessed source.

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[vehre at gcc dot gnu.org]

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

--- Comment #6 from vehre at gcc dot gnu.org ---
Well, obviously not:
- see depends on
- run gfortran with leak check (take care not to drown in the reports) and
address those leaks.
- then do the same for the testcases themself (the work upto now just addressed
the issues at compile time, still pending is runtime!)

[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So fixed?

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Mikael Pettersson from comment #12)
> Thanks for testing, I'll submit it for gcc-7 shortly.

Ah, awesome, thanks! Would also be cool to have this backported to the gcc-6
branch if possible.

[Bug c++/79013] New: Inconsistent auto diagnostic in member declarations

[jakub at gcc dot gnu.org]

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

Bug ID: 79013
   Summary: Inconsistent auto diagnostic in member declarations
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: inadgob at yahoo dot com, jakub at gcc dot gnu.org,
jason at gcc dot gnu.org, lhyatt at gmail dot com,
marxin at gcc dot gnu.org, rs2740 at gmail dot com,
unassigned at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 78693
Blocks: 79009
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #78693 +++

Multiple unresolved unclear issues from the above PR:

struct A
{
  auto foo(), bar();
};

auto A::foo() { return 1; }
auto A::bar() { return 2; }

Is this valid or not?  Both g++ and clang++ accept it.

[dcl.spec.auto]/7 says only:
"If the init-declarator-list contains more than one init-declarator, they shall
all form declarations of variables."

which presumably doesn't apply to analogical member-declarator-list and
member-declarator, but should it?

Another similar testcase:

struct B
{
  static auto const a = 5, foo(), bar();
};

auto const B::foo() { return 1; }
auto const B::bar() { return 2; }

Another issue:

struct C
{
  static auto const a = 5, b = 6L;
};

clang++ rejects this, g++ doesn't:

pr78693-5.C:3:10: error: 'auto' deduced as 'int' in declaration of 'a' and
deduced as 'long' in declaration of 'b'
  static auto const a = 5, b = 6L;

The question is if [dcl.spec.auto]/7 further sentence:

"The type of each declared variable is determined by placeholder type deduction
(7.1.7.4.1), and if the type that replaces the placeholder type is not the same
in each deduction, the program is ill-formed."

applies just to the init-declarator-list or also to member-declarator-list.
Consistency and common sense would suggest that we should reject it like
clang++ does, does the C++ standard need to be changed for that though?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
[Bug 78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when
having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009
[Bug 79009] Missing 'inconsistent deduction for ‘auto’' error when having a
dependent initializer and a nondependent one in the same declaration

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[mikpelinux at gmail dot com]

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

--- Comment #12 from Mikael Pettersson  ---
Thanks for testing, I'll submit it for gcc-7 shortly.

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
Ok, the patch does indeed work. Tested by compiling the offending source code
file in mednafen which currently fails to build from source [1]:

Without "-mlong-jump-table-offsets", I get:

(sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# g++-7
-c -std=c++11 m68k.cpp -o m68k.o -I../../../include -DMSB_FIRST
-DSIZEOF_DOUBLE=8
(...)
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
/tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows:
`switch'-statement too large.
(sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k#
With the option set, it works:

(sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# g++-7
-c -std=c++11 m68k.cpp -mlong-jump-table-offsets -o m68k.o -I../../../include
-DMSB_FIRST -DSIZEOF_DOUBLE=8
(sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# ls -l
total 4100
-rw-r--r-- 1 glaubitz glaubitz   21029 Jul 31 19:22 gen.cpp
-rw-r--r-- 1 glaubitz glaubitz   41754 Aug 23 05:26 m68k.cpp
-rw-r--r-- 1 glaubitz glaubitz   11780 Aug 22 22:13 m68k.h
-rw-r--r-- 1 root root 3242396 Jan  6 10:18 m68k.o
-rw-r--r-- 1 glaubitz glaubitz  868437 Jul 31 19:22 m68k_instr.inc
(sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k#

Anything that speaks against applying this patch against gcc-7 and gcc-6?

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mednafen=m68k=0.9.39.2%2Bdfsg-1=1482769622

[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #40458|0   |1
is obsolete||

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

Updated patch that fixes the ICE.

[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc*-*-*|powerpc*-*-*, aarch64*,
   ||arm*, x86*
   Last reconfirmed|2017-01-05 00:00:00 |2017-1-6
 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Also see this on arm and aarch64

[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Just to document, I see another Werror in LTO bootstrap:

../../gcc/predict.c: In function ‘set_even_probabilities’:
../../gcc/predict.c:798:8: error: ‘e’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
   edge e;
^

Where LIM does following transformation:

   [15.14%]:
  _1 = _23(D)->succs;
  if (_1 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [15.13%]:
  _79 = MEM[(struct vec * *)bb_23(D) + 8B];
  e_lsm.1284_111 = e;
  e_lsm.1285_130 = 0;
  goto ; [100.00%]

   [0.04%]:
  _ZL12ei_container13edge_iterator.isra.19.part.20 ();

   [99.96%]:
  # nedges_90 = PHI 
  # _93 = PHI <_94(14), 0(35)>
  # e_lsm.1284_2 = PHI 
  # e_lsm.1285_15 = PHI 
  if (_79 != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

I guess it's a false positive.