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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
gfortran -S conftestf.f -g -O2 -wrapper gdb,--args

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Fixed by Bernd's patch on the trunk.

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

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Sat Jan 21 07:23:47 2017
New Revision: 244741

URL: https://gcc.gnu.org/viewcvs?rev=244741=gcc=rev
Log:
2017-01-21  Bernd Schmidt  

rtl-optimization/79125
* cprop.c (local_cprop_pass): Handle cases where we make an
unconditional trap.

PR rtl-optimization/79125
* gcc.dg/torture/pr79125.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79125.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cprop.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Author: segher
Date: Sat Jan 21 03:11:49 2017
New Revision: 244740

URL: https://gcc.gnu.org/viewcvs?rev=244740=gcc=rev
Log:
rs6000: Small varargs for BE SVR4 (PR61729, PR77850)

The varargs code for SVR4 puts all (integer) arguments in 4-byte slots.
When it then reads an item from there as something not a multiple of 4
bytes, it needs to adjust the address if big endian.  We didn't yet do
that.

This fixes the g++.dg/abi/scoped1.C, gcc.dg/compat/scalar-by-value-4,
and gcc.dg/compat/scalar-return-4 testcases.


PR target/61729
PR target/77850
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Adjust address to
read from, for big endian.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

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

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Sat Jan 21 03:11:49 2017
New Revision: 244740

URL: https://gcc.gnu.org/viewcvs?rev=244740=gcc=rev
Log:
rs6000: Small varargs for BE SVR4 (PR61729, PR77850)

The varargs code for SVR4 puts all (integer) arguments in 4-byte slots.
When it then reads an item from there as something not a multiple of 4
bytes, it needs to adjust the address if big endian.  We didn't yet do
that.

This fixes the g++.dg/abi/scoped1.C, gcc.dg/compat/scalar-by-value-4,
and gcc.dg/compat/scalar-return-4 testcases.


PR target/61729
PR target/77850
* config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Adjust address to
read from, for big endian.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
It was fixed for gcc 6 by r227044 (and so was bug 53012).

[Bug c++/65608] [meta-bug] friend issues

[redi at gcc dot gnu.org]

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

Bug 60860 Summary: Friend function declaration incorrectly hides function in 
outer namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860

   What|Removed |Added

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

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed by the same r227044 commit as fixed bug 60860

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

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kalaxy at gmail dot com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 53012 has been marked as a duplicate of this bug. ***

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

[ikozhukhov at gmail dot com]

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

--- Comment #9 from Igor Kozhukhov  ---
$ gdb --version
GNU gdb (DilOS 7.11.1-2-5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparcv9-sun-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".

$ gfortran-5 -S conftestf.f -g -O2 -wrapper gdb
gdb: unrecognized option `-ffixed-form'

do you have another ideas/example?

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

[vincent-gcc at vinc17 dot net]

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

Bug ID: 79173
   Summary: add-with-carry and subtract-with-borrow support
(x86_64 and others)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

There should be a way to support full add-with-carry and subtract-with-borrow
by generating adc / sbb instructions on x86_64 (and similar instructions on
other targets).

GCC could add builtins, such as __builtin_addc* and __builtin_subc* (two
arguments, carry in, carry out, and the result), similar to Clang:
http://clang.llvm.org/docs/LanguageExtensions.html#multiprecision-arithmetic-builtins
as suggested in PR 60206 comment 3.

Detection of special constructs in standard C/... code would be useful too.
Here are some examples from
https://gcc.gnu.org/ml/gcc-help/2017-01/msg00067.html for subtraction:

typedef unsigned long T;

void sub1 (T *p, T u0, T u1, T u2, T v0, T v1, T v2)
{
  T t1;
  int b0, b1;

  p[0] = u0 - v0;
  b0 = u0 < v0;
  t1 = u1 - v1;
  b1 = u1 < v1;
  p[1] = t1 - b0;
  b1 |= p[1] > t1;
  p[2] = u2 - v2 - b1;
}

void sub2 (T *p, T u0, T u1, T u2, T v0, T v1, T v2)
{
  int b0, b1;

  p[0] = u0 - v0;
  b0 = u0 < v0;
  p[1] = u1 - v1 - b0;
  b1 = u1 < v1 || (u1 == v1 && b0 != 0);
  p[2] = u2 - v2 - b1;
}

In the second example, the b1 line could also be replaced by:

  b1 = u1 < v1 + b0 || v1 + b0 < v1;

For the subtractions, optimal code would contain 1 sub and 2 sbb's.

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
It seems to have been fixed before the r235368 commit that fixed bug 70522, I'm
trying to find the right commit.

[Bug c++/79172] New: -Wunused-but-set-parameter gone nuts

[petschy at gmail dot com]

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

Bug ID: 79172
   Summary: -Wunused-but-set-parameter gone nuts
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

I made a fresh build from the gcc 7 master branch (6f0a524c). Now my code
doesn't compile:

common/src/mgsnetCRSARC4Base.cpp: In constructor
‘mgs::net::CRSARC4Base::CRSARC4Base(uint32_t, uint32_t)’:
common/src/mgsnetCRSARC4Base.cpp:46:45: error: parameter ‘msends_’ set but not
used [-Werror=unused-but-set-parameter]
 mgs::net::CRSARC4Base::CRSARC4Base(uint32_t msends_, uint32_t mrecvs_) :
 ^~~
common/src/mgsnetCRSARC4Base.cpp:46:63: error: parameter ‘mrecvs_’ set but not
used [-Werror=unused-but-set-parameter]
 mgs::net::CRSARC4Base::CRSARC4Base(uint32_t msends_, uint32_t mrecvs_) :
   ^~~

This is a rather simple ctor:

46: mgs::net::CRSARC4Base::CRSARC4Base(uint32_t msends_, uint32_t mrecvs_) :
CTCPIPBase(msends_, mrecvs_),
m_rsa_padding(mgs::crypto::CRSAEngine::PADDING_8000)
{
m_rng.Seed();
}

The two params are forwarded to the ctor of the base class, so they are
definitely used; the implementation of the base ctor is in another cpp. It does
this at -O0 and -O3, too.

An earlier version of 7.0 had no such problem (probably a few months earlier I
guess), and current 6.2.1, 6.3.1 compiles the code fine.

Tried to make a reduced test case, but simply cloning the inheritance structure
and the ctor signatures didn't trigger the warning, unfortunately. I will have
another go with this if I have a little free time.

There are lots of other ctors that forward to the base class, but only this
single instance is picked out. Could it be because of virtual inheritance? This
is the only distinguishing attribute I can think of atm.

Bisected, hope this helps:

commit 4076953ad7a3e1f54c5caf6c7c23fd8878702001
Author: nathan 
Date:   Fri Oct 7 20:01:17 2016 +

cp/
PR c++/64433
DR1658, DR1611
* init.c (emit_mem_initializers): Don't construct vbases of
abstract classes.
(push_base_cleanups): Don't push vbase cleanups for abstract class
when in C++14 mode.
* method.c (synthethesized_method_walk): Don't walk vbases of
abstract classes when in C++14 mode.

testsuite/
PR c++/66443
* g++.dg/cpp0x/pr66443-cxx11.C: New.
* g++.dg/cpp0x/pr66443-cxx11-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14.C: New
* g++.dg/cpp1y/pr66443-cxx14-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14-3.C: New.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240874
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

[zeratul976 at hotmail dot com]

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

--- Comment #4 from Nathan Ridge  ---
(In reply to Nathan Ridge from comment #3)
> This appears to have been fixed in gcc 6.

Perhaps by bug 70522?

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[zeratul976 at hotmail dot com]

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

--- Comment #3 from Nathan Ridge  ---
(In reply to Nathan Ridge from comment #2)
> This appears to be fixed in gcc 6, possibly by the same change that fixed
> bug 60860 as well.

Perhaps by bug 70522?

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

[zeratul976 at hotmail dot com]

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

Nathan Ridge  changed:

   What|Removed |Added

 CC||zeratul976 at hotmail dot com

--- Comment #2 from Nathan Ridge  ---
This appears to be fixed in gcc 6, possibly by the same change that fixed bug
60860 as well.

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

[zeratul976 at hotmail dot com]

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

Nathan Ridge  changed:

   What|Removed |Added

 CC||zeratul976 at hotmail dot com

--- Comment #3 from Nathan Ridge  ---
This appears to have been fixed in gcc 6.

[Bug target/70179] PPC64 ICE with -mabi=ieeelongdouble and long double complex

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
I suspect the bug was fixed in a check in on May 2nd, 2016, when the complex
float128 was supported.

[Bug c/79171] I can't able to create static link of dynamic object.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
1) This is not GCC related at all, this is binutils related.
2) You are linking directly against a shared library and trying to create a
static executable; that will never work.

[Bug c/79171] New: I can't able to create static link of dynamic object.

[snbraj at sasken dot com]

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

Bug ID: 79171
   Summary: I can't able to create static link of dynamic object.
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: snbraj at sasken dot com
  Target Milestone: ---

Hi ,

I am trying to create static link of dynamic objects & archives.


Below is the  commands & flags used,getting below errors.

/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc
--sysroot=/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto
--disable-shared -Wundef -Wstrict-prototypes -Wno-trigraphs -g -O0 -fno-inline
-fno-short-enums -fpic -D_GNU_SOURCE -I.. -O2 -pipe -g
-feliminate-unused-debug-types -fstack-protector-all -pie -fpie
-D_FORTIFY_SOURCE=2 -static -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z
-Wl,relro -Wl,-z -Wl,now -o applypatch applypatch-applypatch.o
applypatch-bspatch.o applypatch-bsdiff.o applypatch-imgpatch.o
applypatch-freecache.o applypatch-utils.o applypatch-main.o  -lz
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libbz2.a
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libmincrypt.a
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libcutils.so
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/liblog.so
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libglib-2.0.so
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libstdc++.a
../mtdutils/.libs/libmtdutils.a ../edify/.libs/libedify.a
../minzip/.libs/libminzip.a -lm -lpthread
/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/4.9.3/ld:
attempted static link of dynamic object
`/local/mnt/workspace/bharath/AGL/poky/build/tmp-glibc/sysroots/auto/usr/lib64/libcutils.so'
collect2: error: ld returned 1 exit status

Is there any switch to override this?

Regards
Bharath

[Bug target/70179] PPC64 ICE with -mabi=ieeelongdouble and long double complex

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
I've tested this now on the GCC 7 trunk as well as GCC 6.2, on both big endian
and little endian systems, and it no longer fails.  It did fail in GCC 5.x.

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

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01643.html

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> what is correct command ?

gfortran -S conftestf.f -g -O2 -wrapper gdb

[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Unless -ffast-math or -fno-honor-nans is used, you cannot invert < to >=,
because you will get a different result if either operand is a NaN.  However,
the basic code for vector compares hasn't changed much since the early power7
days.

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

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #10 from Michael Karcher  ---
OK, I got it. I retract my last comment.

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

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
The warning seems to reliably disappear with -fno-schedule-insns, on every
combination I've tried it produces better (smaller stack and faster code) or
identical results to -fno-sched-critical-path-heuristic
-fno-sched-dep-count-heuristic for the test case, but the margins vary a lot
depending on gcc version and architecture. I tried various gcc versions on ARM,
as well as gcc-4.9.3 across many architectures.

"-fsched-pressure" on mips64 helps a lot (factor 2 in both frame size and
performance) but is still worse than "-fno-sched-critical-path-heuristic
-fno-sched-dep-count-heuristic" or "-fno-schedule-insns", which give factor 2.5
to 3.5 in performance and reduce the stack size to what it should be (220 to
272 bytes).
I tried gcc-4.9 and gcc-7.0 here, which show the same behavior, though "gcc-4.9
-fno-schedule-insns" is faster by a good margin (factor 1.1 to 1.2) compared to
the second fastest ("gcc-7 -fno-schedule-insns").

On arm and aarch64, "-fsched-pressure" has no effect on this test case that I
can see (have not compared the object files, but frame size and performance are
unchanged). "-fno-schedule-insns" is noticeably better, with frame size of 350
bytes on ARM compared to the default 824, and performance better by factor 1.6
compared to the default -O2. I also looked at the frame sizes on my older arm
compilers and saw the same on all 8 versions I have (4.5 through 7.0).

[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Seen also on powerpc64-unknown-linux-gnu, but not on
powerpc64le-unknown-linux-gnu.

[Bug target/79170] New: memcmp builtin expansion sequence can overflow

[acsawdey at gcc dot gnu.org]

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

Bug ID: 79170
   Summary: memcmp builtin expansion sequence can overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: acsawdey at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-*

The sequence generated for memcmp() builtin expansion can overflow in the subf
and produce the wrong result.

#include 
#include 
#include 
#include 

#define SIZE 16
int main ()
{
  unsigned char buffer1[SIZE] = { 0,0,0,0,0,0,0,1 };
  unsigned char buffer2[SIZE] = { 0x80,0,0,0,0,0,0,3 };

  asm(" ");

  int n =  memcmp(buffer1,buffer2, SIZE);
  printf("%d\n", n);
}

produces 

ldbrx 9,0,6
ldbrx 4,0,8
subf. 4,4,9
bne 0,.L2
addi 10,1,120
ldbrx 9,0,10
addi 10,1,104
ldbrx 4,0,10
subf 4,4,9
.L2:
cntlzd 4,4
addis 3,2,.LC0@toc@ha
addi 3,3,.LC0@toc@l
addi 4,4,-1
xori 4,4,0x3f
bl printf

If the subf result overflows such that the sign bit is not set in r4, then the
wrong result is produced.

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

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
The backend.h interface says that if you set the alignment, that is the
alignment.  I could change it to the GCC version--you can only increase the
alignment--but I'd rather keep the backend.h interface simple.

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

[ikozhukhov at gmail dot com]

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

--- Comment #7 from Igor Kozhukhov  ---
what is correct command ?
will be better for copy/past to be sure i do what you need :)

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

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
Well, it helped in that it uncovered a different problem.

Fixed again.

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

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Jan 20 20:39:10 2017
New Revision: 244731

URL: https://gcc.gnu.org/viewcvs?rev=244731=gcc=rev
Log:
PR go/79146
math/big: fix build on s390x

Don't build arith_decl_s390x.go for gccgo; it is only for assembly
code that has not yet been ported to gccgo.

For GCC PR 79146.

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/math/big/arith_decl_s390x.go

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
I cannot reproduce with a cross-compiler.  Please post a backtrace.

[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #18 from Jeffrey A. Law  ---
We can't close it at this point -- we haven't really fixed the core issue. 
David's patch was primarily to give more testing coverage for future work in
this space.  I believe we're currently relying on Jakub's hack patch from c#12
to keep glib2 happy.

If we're not going to address for gcc-7 we should probably change the target
milestone.

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

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
Removing in gcc-8 sounds reasonable to me.

Given that my analysis of undesirable sharing of range info for the other bug I
was looking at was enough for Richi to find and fix the problem, I guess I'll
poke further at this and see if I can come up with anything useful.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
The other thing to do is try with -fsched-pressure .  PowerPC turns on
-fsched-pressure by default (see PR 11488).

[Bug testsuite/79169] New: g++.dg/warn/Wduplicated-branches1.C fails on powerpc since its introduction in r244705

[seurer at gcc dot gnu.org]

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

Bug ID: 79169
   Summary: g++.dg/warn/Wduplicated-branches1.C fails on powerpc
since its introduction in r244705
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This was on a powerpc LE system but the same thing happens on BE.


Fri Jan 20 10:35:29 CST 2017
Differences from previous run:
> FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++11 (test for excess 
> errors)
> FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++14 (test for excess 
> errors)
> FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98 (test for excess 
> errors)




spawn /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++19/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++19/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -Wduplicated-branches -S -o Wduplicated-branches1.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:
In instantiation of 'void f(char, int*) [with T = short unsigned int]':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:20:44:
  required from here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:14:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:
In instantiation of 'void f(char, int*) [with T = short int]':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:21:42:
  required from here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:14:3:
warning: this condition has identical branches [-Wduplicated-branches]
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:
In instantiation of 'void f(char, int*) [with T = short unsigned int]':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:20:44:
  required from here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:14:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:
In instantiation of 'void f(char, int*) [with T = short int]':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:21:42:
  required from here
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:14:3:
warning: this condition has identical branches [-Wduplicated-branches]

PASS: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98  (test for warnings,
line 14)
PASS: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98  (test for warnings,
line 20)
FAIL: g++.dg/warn/Wduplicated-branches1.C  -std=gnu++98 (test for excess
errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C:9:3:
warning: this condition has identical branches [-Wduplicated-branches]

Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++19/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++19/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches1.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||11488

--- Comment #7 from Andrew Pinski  ---
See also PR11488.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11488
[Bug 11488] Pre-regalloc scheduling severely worsens performance

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

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #6 from Maxim Kuvyrkov  ---
Without looking at the code (it's 11pm) my guess is that 1st scheduling pass is
misbehaving in some way, most likely it is doing a lot of interblock moves. 
One of the big differences between x86 and ARM/MIPS scheduling is that x86
disables interblock scheduling.  Does -fno-schedule-insns fix the warnings on
ARM/MIPS?

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

[nathan at gcc dot gnu.org]

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

--- Comment #9 from Nathan Sidwell  ---
Created attachment 40557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40557=edit
template-ectomied

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r244728.

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Fri Jan 20 17:53:44 2017
New Revision: 244728

URL: https://gcc.gnu.org/viewcvs?rev=244728=gcc=rev
Log:
PR c++/78495 - wrong code inherited ctor and invisi-ref parm
* cp-gimplify.c (cp_generize_r): Don't skip thunks.

PR c++/79495
* g++.dg/cpp1z/inh-ctor38.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor38.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78014] -Wformat -vs- size_t

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
T(In reply to David Malcolm from comment #4)
> I wonder if it would be useful to have some kind of "-Wportability" or

I've wondered about that myself.  I agree that it would be useful beyond
-Wformat.

For -Wformat, I also agree that warning about %lu with size_t would be helpful.
 At the same time I suspect it would cause quite a few warnings for otherwise
perfectly safe code (similar to warning for %lu with an int argument in ILP32
or %llu with a long argument in LP64).

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I'd even go as far as saying that this is WONTFIX and we will not warn for
nested switches.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
This is probably because although we're handling ifs:
 1896   /* Ifs are tricky.  */
 1897   if (gimple_code (gsi_stmt (*gsi_p)) == GIMPLE_COND)
we're not handling switches like that.  Won't be that easy I'm afraid.

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-01-20
 Ever confirmed|0   |1

--- Comment #16 from Richard Earnshaw  ---
May be related to PR78041.  Can you test with latest trunk, or latests gcc-6
branch?

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[nickc at gcc dot gnu.org]

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

--- Comment #6 from Nick Clifton  ---
(In reply to ktkachov from comment #5)
> Fine with me, Nick. But I suppose gcc-patches is the place to ask, I think
> Segher also had something to say for shrink-wrapping

Oops - sorry - I knew that.  OK, I have sent the patch to the list:

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

Cheers
  Nick

[Bug sanitizer/79168] New: libtsan fails to link when cross compiling GCC tip for Aarch64 target

[brzycki at gmail dot com]

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

Bug ID: 79168
   Summary: libtsan fails to link when cross compiling GCC tip for
Aarch64 target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brzycki 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: ---

GCC tip has failed to successfully compile now since our last successful
nightly build on January 9 2017.

The error is the following:

.libs/tsan_rtl_aarch64.o: In function `InitializeGuardPtr()':
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libsanitizer/tsan/../../../../libsanitizer/tsan/tsan_rtl_aarch64.S:49:(.text+0x34):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against `.text'
.libs/tsan_rtl_aarch64.o: In function `setjmp':
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libsanitizer/tsan/../../../../libsanitizer/tsan/tsan_rtl_aarch64.S:81:(.text+0x54):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against `.text'
.libs/tsan_rtl_aarch64.o: In function `_setjmp':
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libsanitizer/tsan/../../../../libsanitizer/tsan/tsan_rtl_aarch64.S:128:(.text+0x94):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against `.text'
.libs/tsan_rtl_aarch64.o: In function `sigsetjmp':
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libsanitizer/tsan/../../../../libsanitizer/tsan/tsan_rtl_aarch64.S:177:(.text+0xd8):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against `.text'
.libs/tsan_rtl_aarch64.o: In function `__sigsetjmp':
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libsanitizer/tsan/../../../../libsanitizer/tsan/tsan_rtl_aarch64.S:228:(.text+0x120):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against `.text'
collect2: error: ld returned 1 exit status


And the command executed is the following:

libtool: link: 
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/./gcc/xgcc
-shared-libgcc
-B/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/./gcc
-nostdinc++
-L/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libstdc++-v3/src
-L/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/bin/
-B/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/lib/
-isystem
/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/include
-isystem
/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/sys-include
-fPIC -DPIC -shared -nostdlib
/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/sysroot/usr/lib/../lib64/crti.o
/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/./gcc/crtbeginS.o 
.libs/tsan_clock.o .libs/tsan_debugging.o .libs/tsan_fd.o .libs/tsan_flags.o
.libs/tsan_ignoreset.o .libs/tsan_interceptors.o .libs/tsan_interceptors_mac.o
.libs/tsan_interface_ann.o .libs/tsan_interface_atomic.o .libs/tsan_interface.o
.libs/tsan_interface_java.o .libs/tsan_libdispatch_mac.o
.libs/tsan_malloc_mac.o .libs/tsan_md5.o .libs/tsan_mman.o .libs/tsan_mutex.o
.libs/tsan_mutexset.o .libs/tsan_new_delete.o .libs/tsan_platform_linux.o
.libs/tsan_platform_mac.o .libs/tsan_platform_posix.o
.libs/tsan_platform_windows.o .libs/tsan_report.o .libs/tsan_rtl.o
.libs/tsan_rtl_mutex.o .libs/tsan_rtl_proc.o .libs/tsan_rtl_report.o
.libs/tsan_rtl_thread.o .libs/tsan_stack_trace.o .libs/tsan_stat.o
.libs/tsan_suppressions.o .libs/tsan_symbolize.o .libs/tsan_sync.o
.libs/tsan_rtl_aarch64.o  -Wl,--whole-archive
../sanitizer_common/.libs/libsanitizer_common.a
../interception/.libs/libinterception.a
../libbacktrace/.libs/libsanitizer_libbacktrace.a -Wl,--no-whole-archive 
-Wl,-rpath
-Wl,/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libstdc++-v3/src/.libs
-Wl,-rpath
-Wl,/sarc-c/compiler_tmp/tools/cross/aarch64-sarc-linux-gnu/gcc-7.0/2017-01-18-18-37-57-fe8aea6-master/aarch64-sarc-linux-gnu/lib/../lib64
-L/tmp/tmp.d1V9p3OGZO.cbatch02777/build-aarch64-sarc-linux-gnu/aarch64-sarc-linux-gnu/libstdc++-v3/src/.libs

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

[ronen at barzel dot org]

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

--- Comment #3 from ronen at barzel dot org ---
Ah OK.  Thanks for the quick attention.

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
N.B. https://gcc.gnu.org/projects/cxx-status.html shows that the "Refining
Expression Evaluation Order for Idiomatic C++" feature (which changed these
rules) isn't supported until GCC 7.

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to ronen from comment #0)
> According to http://en.cppreference.com/w/cpp/language/eval_order, 
> 
> 20) In every simple assignment expression E1=E2 and every compound
> assignment expression E1@=E2, every value computation and side-effect of E2
> is sequenced before every value computation and side effect of E1

Items 14-21 are marked "since C++17"

GCC 5 was released two years ago, long before that change was made to the C++17
draft, and it has quite minimal C++17 support.

[Bug c++/79167] New: LHS of assignment operator side-effect sequenced before RHS computation

[ronen at barzel dot org]

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

Bug ID: 79167
   Summary: LHS of assignment operator side-effect sequenced
before RHS computation
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ronen at barzel dot org
  Target Milestone: ---

Created attachment 40556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40556=edit
g++ --save-temps output

According to http://en.cppreference.com/w/cpp/language/eval_order, 

20) In every simple assignment expression E1=E2 and every compound
assignment expression E1@=E2, every value computation and side-effect of E2 is
sequenced before every value computation and side effect of E1

But in this case, the size of the map gets incremented by the LHS before
m.size() gets evaluated on the RHS:   

#include 
#include 
#include 

int main(int argc, char *argv[])
{
std::map m;
m["bug"] = m.size();
assert(m["bug"] == 0);
return 0;
}

i.e. m["bug"] should be equal to 0 but it is getting set to 1.

version:
$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$

To reproduce:
$ g++ bug.cpp
$ ./a.out
a.out: bug.cpp:9: int main(int, char**): Assertion `m["bug"] == 0' failed.
Aborted
$

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-20
 CC||nickc at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Nick Clifton  ---
Hi Guys,

  I have proposed an extended version of Richard's patch to fix this
regression:

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

Cheers
  Nick

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
The bootstrap should be fixed now, for the rest let's use PR65782.

[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
For the xmm16 to xmm31 registers a possible workaround could be to turn those
registers fixed on mingw (thus unavailable for register allocation and not call
saved).  See PR79127.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

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

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 20 16:28:16 2017
New Revision: 244726

URL: https://gcc.gnu.org/viewcvs?rev=244726=gcc=rev
Log:
PR c/79152
* gimplify.c (should_warn_for_implicit_fallthrough): Handle consecutive
non-case labels.

* c-c++-common/Wimplicit-fallthrough-35.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-35.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

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

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
-fno-schedule-insns is comparable in stack frame size to
"-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic" on all
architectures (give or take a few bytes), but actually produces much better
code.

In my simulated mips64 run, I see these numbers:

-O2:  49.0Mbit/s
-O2 -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic: 109.7
Mbit/s
-O2 -fno-schedule-insns: 179.2 Mbit/s

The trend is the same on arm an aarch64 for emulated runs, and I confirmed
earlier that the results on real hardware are comparable to what we get in
qemu.

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

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from wilco at gcc dot gnu.org ---
Fixed in GCC6 and GCC7

[Bug target/78397] The stack is not 8 bytes aligned on ARM

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Earnshaw  ---
Not a gcc bug.

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

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On January 20, 2017 3:07:37 PM GMT+01:00, "marxin at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985
>
>--- Comment #5 from Martin Liška  ---
>(In reply to rguent...@suse.de from comment #4)
>> On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985
>> > 
>> > Martin Liška  changed:
>> > 
>> >What|Removed |Added
>> >
>
>> >  Status|UNCONFIRMED |NEW
>> >Last reconfirmed||2017-01-20
>> >Assignee|unassigned at gcc dot gnu.org  |marxin at
>gcc dot gnu.org
>> >  Ever confirmed|0   |1
>> > 
>> > --- Comment #3 from Martin Liška  ---
>> > I'll try to bisect that, on aarch64 machine I see:
>> > 
>> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member
>function ‘void
>> > func_fma_steering::analyze()’:
>> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error:
>‘head’ may be
>> > used uninitialized in this function [-Werror=maybe-uninitialized]
>> > this->analyze_fma_fmul_insn (forest, chain, head);
>> >  ^
>> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error:
>‘forest’ may
>> > be used uninitialized in this function
>[-Werror=maybe-uninitialized]
>> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error:
>‘chain’ may
>> > be used uninitialized in this function
>[-Werror=maybe-uninitialized]
>> > 
>> > I'll try to bisect..
>> 
>> Yes, aarch64 has a similar issue.
>
>This is aarch64 machine :) Do you remember whether profiledbootstrap
>used to
>succeed (for bisect start)?

It used to, yes.  It at least works on the branch.

[Bug target/79166] [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

[Bug c++/78014] -Wformat -vs- size_t

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from David Malcolm  ---
I wonder if it would be useful to have some kind of "-Wportability" or
somesuch: warn about code that, although it might work OK on the user's current
configuration, would be problematic on other configurations.

This sounds useful for the end-user, but hard to implement (could be done
piecemeal, I suppose).

(and "portability" would cover a lot of aspects: 32-bit vs 64-bit, little vs
big-endian, etc etc).

What should a warning for the code in comment #0 look like?

test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t'
[-Wportability]

  printf("got %lu\n", x);
  ~~^
  %zu

or somesuch?

Or even, brainstorming here, give it some knowledge of other archs e.g.:

test.c:5: format code '%lu' assumes 'unsigned long', but argument is 'size_t';
this will break on NAMES_OF_ARCHS_HERE [-Wportability=i686,ppcle]

  printf("got %lu\n", x);
  ~~^
  %zu

(not sure that this last one is a good idea, but mentioning it for sake of
argument)

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

[wilco at gcc dot gnu.org]

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

--- Comment #3 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Fri Jan 20 15:34:41 2017
New Revision: 244724

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

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

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/eh_return.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/aarch64/aarch64-protos.h
branches/gcc-6-branch/gcc/config/aarch64/aarch64.c
branches/gcc-6-branch/gcc/config/aarch64/aarch64.h
branches/gcc-6-branch/gcc/config/aarch64/aarch64.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

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

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely  ---
I don't plan to change this for gcc 5 and gcc 6, because changing the type of
exception thrown by the library doesn't seem appropriate for a minor release
within the 5.x or 6.x series.

[Bug libstdc++/69240] Missing inequality operators for every param_type in

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 20 15:28:48 2017
New Revision: 244722

URL: https://gcc.gnu.org/viewcvs?rev=244722=gcc=rev
Log:
PR69240 Define inequality operators for  param types

PR libstdc++/69240
* include/bits/random.h (uniform_real_distribution::param_type)
(normal_distribution::param_type, lognormal_distribution::param_type)
(gamma_distribution::param_type, chi_squared_distribution::param_type)
(cauchy_distribution::param_type, fisher_f_distribution::param_type)
(student_t_distribution::param_type)
(bernoulli_distribution::param_type, binomial_distribution::param_type)
(geometric_distribution::param_type)
(negative_binomial_distribution::param_type)
(poisson_distribution::param_type)
(exponential_distribution::param_type)
(weibull_distribution::param_type)
(extreme_value_distribution::param_type)
(discrete_distribution::param_type)
(piecewise_constant_distribution::param_type)
(piecewise_linear_distribution::param_type): Define operator!=.
* include/bits/uniform_int_dist.h
(uniform_int_distribution::param_type): Likewise.
* include/ext/random (beta_distribution::param_type)
(rice_distribution::param_type, nakagami_distribution::param_type)
(pareto_distribution::param_type, k_distribution::param_type)
(arcsine_distribution::param_type, hoyt_distribution::param_type)
(triangular_distribution::param_type)
(von_mises_distribution::param_type)
(hypergeometric_distribution::param_type)
(logistic_distribution::param_type)
(uniform_on_sphere_distribution::param_type)
(uniform_inside_sphere_distribution::param_type): Likewise.
* testsuite/26_numerics/random/bernoulli_distribution/cons/parms.cc:
Test construction with param_type.
* testsuite/26_numerics/random/binomial_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/chi_squared_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/exponential_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/extreme_value_distribution/cons/
parms.cc: Likewise.
* testsuite/26_numerics/random/fisher_f_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/gamma_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/geometric_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/lognormal_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/negative_binomial_distribution/cons/
parms.cc: Likewise.
* testsuite/26_numerics/random/normal_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/poisson_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/student_t_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/uniform_int_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/uniform_real_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/weibull_distribution/cons/parms.cc:
Likewise.
* testsuite/ext/random/arcsine_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/beta_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/hoyt_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/hypergeometric_distribution/cons/parms.cc:
Likewise.
* testsuite/ext/random/k_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/logistic_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/nakagami_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/normal_mv_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/pareto_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/rice_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/triangular_distribution/cons/parms.cc:
Likewise.
* testsuite/ext/random/uniform_inside_sphere_distribution/cons/
parms.cc: Likewise.
* testsuite/ext/random/von_mises_distribution/cons/parms.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/uniform_int_dist.h
trunk/libstdc++-v3/include/ext/random
   
trunk/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/cons/parms.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/cons/parms.cc
   

[Bug libstdc++/69240] Missing inequality operators for every param_type in

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed for gcc 7.

[Bug c++/77284] [5 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5/6 Regression] ICE on |[5 Regression] ICE on valid
   |valid C++11 code using  |C++11 code using
   |initializer list: in|initializer list: in
   |potential_constant_expressi |potential_constant_expressi
   |on_1, at|on_1, at
   |cp/constexpr.c:5480 |cp/constexpr.c:5480

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 20 15:12:26 2017
New Revision: 244721

URL: https://gcc.gnu.org/viewcvs?rev=244721=gcc=rev
Log:
PR c++/77545
PR c++/77284
* constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT.

* g++.dg/cpp0x/range-for32.C: New test.
* g++.dg/cpp0x/range-for33.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for32.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for33.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77284] [5/6 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 20 15:12:26 2017
New Revision: 244721

URL: https://gcc.gnu.org/viewcvs?rev=244721=gcc=rev
Log:
PR c++/77545
PR c++/77284
* constexpr.c (potential_constant_expression_1): Handle CLEANUP_STMT.

* g++.dg/cpp0x/range-for32.C: New test.
* g++.dg/cpp0x/range-for33.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for32.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for33.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug other/78068] warning: implicit declaration of function ‘time’; did you mean ‘nice’? [-Wimplicit-function-declaration]

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Depends on||69968

--- Comment #4 from David Malcolm  ---
I had a go at fixing this by introducing a "require_close_matches" flag to
best_match (When set, it would require an edit distance of 1), and turning it
on for just this warning.

Unfortunately this broke the scanf<->sacnf transposition detection in one of
the testcases.

Maybe this would be a valid approach if we implemented transposition handling
when computing the edit distance.  (transposition-handling is PR 69968).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
[Bug 69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than
Levenshtein

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
In cases like this where it's just a dumb bug in our library headers (in a
non-standard extension which hadn't been adequately tested) we'd definitely
rather fix it here, not require other compilers to workaround it. Please do
continue to report any errors like this that you find, thanks.

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Fine with me, Nick. But I suppose gcc-patches is the place to ask, I think
Segher also had something to say for shrink-wrapping

[Bug c++/77829] Bad fix-it for nested-name-specifier

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Fri Jan 20 14:36:46 2017
New Revision: 244715

URL: https://gcc.gnu.org/viewcvs?rev=244715=gcc=rev
Log:
C++: fix fix-it hints for misspellings within explicit namespaces

gcc/cp/ChangeLog:
PR c++/77829
PR c++/78656
* cp-tree.h (suggest_alternatives_for): Add bool param.
(suggest_alternative_in_explicit_scope): New decl.
* error.c (qualified_name_lookup_error): When SCOPE is a namespace
that isn't the global one, call new function
suggest_alternative_in_explicit_scope, only calling
suggest_alternatives_for if it fails, and disabling near match
searches fort that case.  When SCOPE is the global namespace,
pass true for new param to suggest_alternatives_for to allow for
fuzzy name lookups.
* lex.c (unqualified_name_lookup_error): Pass true for new param
to suggest_alternatives_for.
* name-lookup.c (consider_binding_level): Add forward decl.
(suggest_alternatives_for): Add "suggest_misspellings" param,
using it to conditionalize the fuzzy name-lookup code.
(suggest_alternative_in_explicit_scope): New function.
* parser.c (cp_parser_primary_expression): When calling
finish_id_expression, pass location of id_expression rather
than that of id_expr_token.
(cp_parser_id_expression): Convert local "unqualified_id" from
tree to cp_expr to avoid implicitly dropping location information.

gcc/testsuite/ChangeLog:
PR c++/77829
PR c++/78656
* g++.dg/spellcheck-pr77829.C: New test case.
* g++.dg/spellcheck-pr78656.C: New test case.


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-pr77829.C
trunk/gcc/testsuite/g++.dg/spellcheck-pr78656.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/lex.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Jan 20 14:36:57 2017
New Revision: 244716

URL: https://gcc.gnu.org/viewcvs?rev=244716=gcc=rev
Log:
[ARM] PR target/71270 fix neon_valid_immediate for big-endian

PR target/71270
* config/arm/arm.c (neon_valid_immediate): Reject vector constants
in big-endian mode when they are not a single duplicated value.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
Fixed.
Opened PR 79166 for tracking codegen improvements for big-endian that can be
done as a result of https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[nickc at gcc dot gnu.org]

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

--- Comment #4 from Nick Clifton  ---
Created attachment 40555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40555=edit
Proposed patch

[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r244715; marking as resolved.

[Bug c++/77829] Bad fix-it for nested-name-specifier

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by r244715; marking as resolved.

[Bug target/79166] [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||armeb
   Target Milestone|--- |8.0

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #3 from Nick Clifton  ---
Hi Guys,

  I would like to close out this PR, so that it is no longer considered a
regression delaying the creation of the gcc 7 branch.  I propose changing the
comments in the two test cases like this:

-/* XFAIL due to PR70681.  */ 
+/* The XFAILs are because these targets produce better code without
+   shrinkwrapping, and hence the optimization is not triggered.  See
+   PR70681 for more details.  */

Which I think captures the essence of the reason for XFAILing.

I have verified that the ARM and POWERPC compilers do indeed produce code
sequences with fewer overall instructions, although the shorter code path
through the test functions is usually one instruction longer without the
shrinkwrapping.  (But the longer code path is usually two or three instructions
shorter).

So - is it OK to apply the uploaded patch to the mainline ?

Cheers
  Nick

[Bug target/79166] New: [ARM] Implement neon_valid_immediate tricks for BYTES_BIG_ENDIAN

[ktkachov at gcc dot gnu.org]

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

Bug ID: 79166
   Summary: [ARM] Implement neon_valid_immediate tricks for
BYTES_BIG_ENDIAN
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

As a result of the fix for PR 71270 the various tricks that
neon_valid_immediate can do to splat a constant across a vector have been
restricted to all but the most basic ones on BYTES_BIG_ENDIAN.

This is a PR to track implementing them properly on big-endian targets.
See also https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html

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

[mib.bugzilla at gmail dot com]

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

--- Comment #4 from mib.bugzilla at gmail dot com ---
Thank you so much! (That means I won't need to change the Intel compiler to
accommodate).  Best regards

[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Fri Jan 20 14:36:46 2017
New Revision: 244715

URL: https://gcc.gnu.org/viewcvs?rev=244715=gcc=rev
Log:
C++: fix fix-it hints for misspellings within explicit namespaces

gcc/cp/ChangeLog:
PR c++/77829
PR c++/78656
* cp-tree.h (suggest_alternatives_for): Add bool param.
(suggest_alternative_in_explicit_scope): New decl.
* error.c (qualified_name_lookup_error): When SCOPE is a namespace
that isn't the global one, call new function
suggest_alternative_in_explicit_scope, only calling
suggest_alternatives_for if it fails, and disabling near match
searches fort that case.  When SCOPE is the global namespace,
pass true for new param to suggest_alternatives_for to allow for
fuzzy name lookups.
* lex.c (unqualified_name_lookup_error): Pass true for new param
to suggest_alternatives_for.
* name-lookup.c (consider_binding_level): Add forward decl.
(suggest_alternatives_for): Add "suggest_misspellings" param,
using it to conditionalize the fuzzy name-lookup code.
(suggest_alternative_in_explicit_scope): New function.
* parser.c (cp_parser_primary_expression): When calling
finish_id_expression, pass location of id_expression rather
than that of id_expr_token.
(cp_parser_id_expression): Convert local "unqualified_id" from
tree to cp_expr to avoid implicitly dropping location information.

gcc/testsuite/ChangeLog:
PR c++/77829
PR c++/78656
* g++.dg/spellcheck-pr77829.C: New test case.
* g++.dg/spellcheck-pr78656.C: New test case.


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-pr77829.C
trunk/gcc/testsuite/g++.dg/spellcheck-pr78656.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/error.c
trunk/gcc/cp/lex.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #23 from ktkachov at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #22)
> (In reply to dhowe...@redhat.com from comment #21)
> > (In reply to Markus Trippelsdorf from comment #20)
> > > *** Bug 78879 has been marked as a duplicate of this bug. ***
> > 
> > Kernel bug or not, it should be noted that this means that you cannot use
> > gcc from r236831 to compile any kernel from the introduction and use of
> > ilog2() to the current day - and these kernel versions cannot be
> > retroactively fixed.
> 
> No. I build allmodconfig kernels regularly with gcc trunk and it works fine.

I still hit this when building an allmodconfig arm64 kernel with trunk

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

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #2 from Bill Schmidt  ---
I'll look into it...

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #6 from Richard Biener  ---
build_translation_unit_decl is called exactly _once_ ... but it looks like the
linemap operation screws up sth.

Compiler command I used for reproducing:

> ./f951 -quiet aermod.f90 -fno-checking -Ofast -march=core-avx2 -funroll-loops

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #4)
> r244557: 19.77s
> r244586: 34.18s
> r244587: 33.91s
> 
> so neither party is guilty...  bisecting.
> 
> r244575: 19.66s
> r244581: 33.84s
> r244578: 19.82s
> r244580: 19.76s
> r244581: 19.88s (?!)

 ^^^ err, forgot the make all-gcc here

it's really r244581, the tree.c hunk.

[Bug fortran/79165] [7 Regression] 100% compile-time increase for polyhedron aermod between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
r244557: 19.77s
r244586: 34.18s
r244587: 33.91s

so neither party is guilty...  bisecting.

r244575: 19.66s
r244581: 33.84s
r244578: 19.82s
r244580: 19.76s
r244581: 19.88s (?!)

(just svn up -r and make all-gcc each time)

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

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to rguent...@suse.de from comment #4)
> On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985
> > 
> > Martin Liška  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|UNCONFIRMED |NEW
> >Last reconfirmed||2017-01-20
> >Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
> > gnu.org
> >  Ever confirmed|0   |1
> > 
> > --- Comment #3 from Martin Liška  ---
> > I'll try to bisect that, on aarch64 machine I see:
> > 
> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void
> > func_fma_steering::analyze()’:
> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ 
> > may be
> > used uninitialized in this function [-Werror=maybe-uninitialized]
> > this->analyze_fma_fmul_insn (forest, chain, head);
> >  ^
> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ 
> > may
> > be used uninitialized in this function [-Werror=maybe-uninitialized]
> > ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ 
> > may
> > be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 
> > I'll try to bisect..
> 
> Yes, aarch64 has a similar issue.

This is aarch64 machine :) Do you remember whether profiledbootstrap used to
succeed (for bisect start)?

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

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 20 Jan 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78985
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-01-20
>Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
> gnu.org
>  Ever confirmed|0   |1
> 
> --- Comment #3 from Martin Liška  ---
> I'll try to bisect that, on aarch64 machine I see:
> 
> ../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void
> func_fma_steering::analyze()’:
> ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ may 
> be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> this->analyze_fma_fmul_insn (forest, chain, head);
>  ^
> ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
> ../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> I'll try to bisect..

Yes, aarch64 has a similar issue.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-20
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
I'll try to bisect that, on aarch64 machine I see:

../../gcc/config/aarch64/cortex-a57-fma-steering.c: In member function ‘void
func_fma_steering::analyze()’:
../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘head’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
this->analyze_fma_fmul_insn (forest, chain, head);
 ^
../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘forest’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
../../gcc/config/aarch64/cortex-a57-fma-steering.c:979:53: error: ‘chain’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]

I'll try to bisect..

[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> Though ia64 doesn't show the regression which would point at r244591.

Almost unbeliveable, the patch effectively just adds two rarely used patterns.
What happens if you back the mentioned patch out?

[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
Though ia64 doesn't show the regression which would point at r244591.

[Bug fortran/79165] [7 Regression] 100% compile-time increase between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 244586)
+++ gcc/fortran/trans-expr.c(revision 244587)
@@ -1839,11 +1839,10 @@ gfc_get_tree_for_caf_expr (gfc_expr *exp
   }

   /* Make sure the backend_decl is present before accessing it.  */
-  if (expr->symtree->n.sym->backend_decl == NULL_TREE)
-expr->symtree->n.sym->backend_decl
-   = gfc_get_symbol_decl (expr->symtree->n.sym);
-  caf_decl = expr->symtree->n.sym->backend_decl;
-  gcc_assert (caf_decl);
+  caf_decl = expr->symtree->n.sym->backend_decl == NULL_TREE
+  ? gfc_get_symbol_decl (expr->symtree->n.sym)
+  : expr->symtree->n.sym->backend_decl;
+
   if (expr->symtree->n.sym->ts.type == BT_CLASS)
 {
   if (expr->ref && expr->ref->type == REF_ARRAY)

removes setting expr->symtree->n.sym->backend_decl?

[Bug fortran/79165] New: [7 Regression] 100% compile-time increase between r244557 and r244598

[rguenth at gcc dot gnu.org]

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

Bug ID: 79165
   Summary: [7 Regression] 100% compile-time increase between
r244557 and r244598
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: vehre at gcc dot gnu.org
  Target Milestone: ---

http://gcc.opensuse.org/c++bench-czerny/pb11/pb11-summary.txt-1-0.html

I almost bet it's r244587?