[Bug target/81300] -fpeephole2 breaks __builtin_ia32_sbb_u64, _subborrow_u64 on AMD64

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 05:30:58 2017
New Revision: 250196

URL: https://gcc.gnu.org/viewcvs?rev=250196=gcc=rev
Log:
Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* config/i386/i386.md (divsf3): Add TARGET_SSE to TARGET_SSE_MATH.
(rcpps): Ditto.
(*rsqrtsf2_sse): Ditto.
(rsqrtsf2): Ditto.
(div3): Macroize insn from divdf3 and divsf3
using MODEF mode iterator.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* config/i386/i386.md (setcc + movzbl/and to xor + setcc peepholes):
Require dead FLAGS_REG at the beginning of a peephole.

testsuite/ChangeLog:

Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* gcc.target/i386/pr81375.c: New test.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* gcc.target/i386/pr81300.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81300.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81375.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/81375] [6/7/8 Regression] unrecognizable insn

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 14 05:30:58 2017
New Revision: 250196

URL: https://gcc.gnu.org/viewcvs?rev=250196=gcc=rev
Log:
Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* config/i386/i386.md (divsf3): Add TARGET_SSE to TARGET_SSE_MATH.
(rcpps): Ditto.
(*rsqrtsf2_sse): Ditto.
(rsqrtsf2): Ditto.
(div3): Macroize insn from divdf3 and divsf3
using MODEF mode iterator.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* config/i386/i386.md (setcc + movzbl/and to xor + setcc peepholes):
Require dead FLAGS_REG at the beginning of a peephole.

testsuite/ChangeLog:

Backport from mainline
2017-07-10  Uros Bizjak  

PR target/81375
* gcc.target/i386/pr81375.c: New test.

Backport from mainline
2017-07-04  Uros Bizjak  

PR target/81300
* gcc.target/i386/pr81300.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81300.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr81375.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct

[halbert at halwitz dot org]

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

--- Comment #1 from Dan Halbert  ---
*** Bug 81439 has been marked as a duplicate of this bug. ***

[Bug lto/81439] -Wlto-type-mismatch with flexible array in struct

[halbert at halwitz dot org]

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

Dan Halbert  changed:

   What|Removed |Added

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

--- Comment #1 from Dan Halbert  ---
Inadvertent double submission due to bugzilla timeout when submitting bug the
first time. Second submission slightly clearer.

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

[Bug lto/81440] New: -Wlto-type-mismatch warning with flexible array in struct

[halbert at halwitz dot org]

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

Bug ID: 81440
   Summary: -Wlto-type-mismatch warning with flexible array in
struct
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: halbert at halwitz dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41757=edit
all example source files in description

I'm getting a -Wlto-type-mismatch size mismatch warning with a struct that ends
with a flexible array, declared in one file and initialized in another. I do
NOT get a warning with a simple flexible array in the same situation.

I think LTO should treat the struct with a flex array similarly to the plain
flex array, and not try to match the sizes.


(tested with arm-none-eabi-gcc 6.3.1, but I see the same issue with native gcc
6.3.0)

HAS WARNING:

ab_struct.h
---
typedef struct {
  int i;
  int ints[];
} struct_t;


a_struct.c
--
#include "ab_struct.h"

extern struct_t my_struct;

int main() {
 return my_struct.ints[0];
}


b_struct.c
--
#include "ab_struct.h"

struct_t my_struct = {
 20,
 { 1, 2 }
};


$ arm-none-eabi-gcc -flto -Wlto-type-mismatch a_struct.c b_struct.c -o foo
a_struct.c:3:17: warning: size of 'my_struct' differ from the size of original
declaration [-Wlto-type-mismatch]
extern struct_t my_struct;
^
b_struct.c:3:10: note: 'my_struct' was previously declared here
struct_t my_struct = {

-
NO WARNING with this plain flexible array, not in a struct:

a_array.c
-
extern  int ia[];

int main() {
 return ia[0];
}


b_array.c
-
int ia[] = { 1, 2 };

$ arm-none-eabi-gcc -flto -Wlto-type-mismatch a_array.c b_array.c -o foo
[no warning]

[Bug lto/81439] New: -Wlto-type-mismatch with flexible array in struct

[halbert at halwitz dot org]

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

Bug ID: 81439
   Summary: -Wlto-type-mismatch with flexible array in struct
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: halbert at halwitz dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41756=edit
all example source files in description

I'm getting a -Wlto-type-mismatch warning with a struct that ends with a
flexible array, declared in one file and initialized in another. I do NOT get a
warning with a simple flexible array in the same situation.

Since the plain flexible array does not generate a warning, I think perhaps LTO
should not generate a warning for the struct case either, since the idea of the
flexible array is to allow it to be of any length when initialized.

As a workaround, I've tried suppressing the warning with #pragmas in the source
code, but I guess they don't pass through to LTO.

(tested with arm-none-eabi-gcc 6.3.1, but I see the same issue with native gcc
6.3.0)

HAS WARNING:

ab_struct.h
---
typedef struct {
  int i;
  int ints[];
} struct_t;


a_struct.c
--
#include "ab_struct.h"

extern struct_t my_struct;

int main() {
 return my_struct.ints[0];
}


b_struct.c
--
#include "ab_struct.h"

struct_t my_struct = {
 20,
 { 1, 2 }
};


$ arm-none-eabi-gcc -flto -Wlto-type-mismatch a_struct.c b_struct.c -o foo
a_struct.c:3:17: warning: size of 'my_struct' differ from the size of original
declaration [-Wlto-type-mismatch]
extern struct_t my_struct;
^
b_struct.c:3:10: note: 'my_struct' was previously declared here
struct_t my_struct = {

-
NO WARNING with this plain flexible array, not in a struct:

a_array.c
-
extern  int ia[];

int main() {
 return ia[0];
}


b_array.c
-
int ia[] = { 1, 2 };

$ arm-none-eabi-gcc -flto -Wlto-type-mismatch a_array.c b_array.c -o foo
[no warning]

[Bug c++/81438] New: silent bad code generation with computed goto exit from catch block

[mednafen at sent dot com]

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

Bug ID: 81438
   Summary: silent bad code generation with computed goto exit
from catch block
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mednafen at sent dot com
  Target Milestone: ---

Created attachment 41755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41755=edit
Test case

Seems to be an old issue.  Would expect it to work correctly, or for there to
be a compilation-time error.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
Thanks.  Now I see that the runtime.lo.dep file that you attached earlier was
in fact erroneous.  I didn't see that before.  It lists "bytes.gox flag.gox
fmt.gox go/format.gox io.gox io/ioutil.gox log.gox math.gox os.gox", none of
which should be listed.  Also the file incorrectly lists mkfastlog2table.go and
mksizeclasses.go.

It looks like libgo/match.sh thinks that the files
libgo/go/runtime/mkfastlog2table.go and libgo/go/runtime/mksizeclasses.go
should be built as part of the runtime package.  This should not happen because
of the "// +build ignore" lines that appear in those files.

What is the output of

libgo/match.sh --goarch=sparc --goos=linux --srcdir=SRCDIR/libgo/go/runtime
--extrafiles="runtime_sysinfo.go sigtab.go" --tag=libffi

?

What is the output of

sed '/^package /q' < SRCDIR/libgo/go/runtime/mksizeclasses.go | grep '^//
+build ' | cat

?

[Bug tree-optimization/81437] New: missing -Wstringop-overflow reading past the end of a string

[msebor at gcc dot gnu.org]

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

Bug ID: 81437
   Summary: missing -Wstringop-overflow reading past the end of a
string
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC 8 diagnoses some non-trivial instances of reading past the end of an array
but misses some of the most basic ones.  For example, while it diagnoses past
the end reads in memcpy when the size is a variable in a range whose lower
bound  causes the invalid access it fails to issue the same diagnostic when the
variable is has a known value with the same effect.  Similarly, no warning is
issued for calls to strcpy whose where the source argument points past the
terminating NUL of a string.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout a.c
void f (char *d, unsigned n)
{
  const char a[] = "123";
  if (n < 1) n = 1;
  __builtin_memcpy (d, a + 4, n);   // warning (ok)
}

void g (char *d, unsigned n)
{
  const char a[] = "123";
  n = 1;
  __builtin_memcpy (d, a + 4, n);   // missing warning
}

void h (char *d)
{
  const char a[] = "123";
  __builtin_strcpy (d, a + 4);   // missing warning
}

;; Function f (f, funcdef_no=0, decl_uid=1816, cgraph_uid=0, symbol_order=0)

Removing basic block 3
f (char * d, unsigned int n)
{
  const char a[4];
  unsigned int _2;
  long unsigned int prephitmp_9;

   [100.00%] [count: INV]:
  if (n_4(D) == 0)
goto ; [50.00%] [count: INV]
  else
goto ; [50.00%] [count: INV]

   [50.00%] [count: INV]:

   [100.00%] [count: INV]:
  # _2 = PHI 
  prephitmp_9 = (long unsigned int) _2;
  __builtin_memcpy (d_5(D), [(void *) + 4B], prephitmp_9); [tail call]
  a ={v} {CLOBBER};
  return;

}


a.c: In function ‘f’:
a.c:5:3: warning: ‘__builtin_memcpy’ reading between 1 and 4294967295 bytes
from a region of size 0 [-Wstringop-overflow=]
   __builtin_memcpy (d, a + 4, n);   // warning (ok)
   ^~

;; Function g (g, funcdef_no=1, decl_uid=1821, cgraph_uid=1, symbol_order=1)

g (char * d, unsigned int n)
{
  const char a[4];
  unsigned char _5;

   [100.00%] [count: INV]:
  _5 = MEM[(char * {ref-all}) + 4B];
  MEM[(char * {ref-all})d_2(D)] = _5;
  a ={v} {CLOBBER};
  return;

}



;; Function h (h, funcdef_no=2, decl_uid=1825, cgraph_uid=2, symbol_order=2)

h (char * d)
{
  const char a[4];

   [100.00%] [count: INV]:
  __builtin_strcpy (d_2(D), [(void *) + 4B]); [tail call]
  a ={v} {CLOBBER};
  return;

}

[Bug tree-optimization/81436] New: missing -Wstringop-overflow on strncat to a zero-size buffer

[msebor at gcc dot gnu.org]

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

Bug ID: 81436
   Summary: missing -Wstringop-overflow on strncat to a zero-size
buffer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Strncat always appends a terminating NUL to the end of the copied string. 
Therefore, it's never safe to call it with a destination of zero size.  Such
calls should be diagnosed by -Wstringop-overflow but in GCC 7.1 they are not.

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
void sink (void*);

void f (const char *s, int n)
{
  char d[1];

  __builtin_strncat (d + 1, s, n);   // missing -Wstringop-overflow

  sink (d);
}

;; Function f (f, funcdef_no=0, decl_uid=1818, cgraph_uid=0, symbol_order=0)

f (const char * s, int n)
{
  char d[1];
  long unsigned int _1;

   [100.00%] [count: INV]:
  _1 = (long unsigned int) n_2(D);
  __builtin_strncat ([(void *) + 1B], s_4(D), _1);
  sink ();
  d ={v} {CLOBBER};
  return;

}

[Bug tree-optimization/81435] New: missing strlen optimization for strcat past the beginning of clear array

[msebor at gcc dot gnu.org]

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

Bug ID: 81435
   Summary: missing strlen optimization for strcat past the
beginning of clear array
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The tree-ssa-strlen pass is able to track the lengths of some dynamically
created and modified strings by calls to strcpy and strcat.  But in at least
one case where the strcat optimization could achieve parity with strcpy it does
not: when strcat is called to copy a string of known length pasty the beginning
of a zeroed-out buffer as is done in function g1() below the same optimization
done for strcpy is not done, and the pass loses track of the length of the
appended (copied) string.

$ cat a.c && gcc -O2 -S -Wall -Wextra  -fdump-tree-strlen=/dev/stdout a.c
void f0 (void)
{
  char a[4] = "234";
  char b[5] = "1";

  __builtin_strcpy (b + 1, a);

  if (__builtin_strlen (b + 1) != 3)   // optimized into 3
__builtin_abort ();
}

void f1 (void)
{
  char a[4] = "234";
  char b[5] = "";

  __builtin_strcpy (b + 1, a);

  if (__builtin_strlen (b + 1) != 3)   // optimized into 3
__builtin_abort ();
}

void g0 (void)
{
  char a[4] = "234";
  char b[5] = "1";

  __builtin_strcat (b + 1, a);

  if (__builtin_strlen (b + 1) != 3)   // optimized into 3
__builtin_abort ();
}

void g1 (void)
{
  char a[4] = "234";
  char b[5] = "";

  __builtin_strcat (b + 1, a);

  if (__builtin_strlen (b + 1) != 3)   // not optimized
__builtin_abort ();
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1815, cgraph_uid=0, symbol_order=0)

f0 ()
{
  char b[5];
  char a[4];
  long unsigned int _1;

   [100.00%] [count: INV]:
  a = "234";
  b = "1";
  __builtin_memcpy ([(void *) + 1B], , 4);
  _1 = 3;
  if (_1 != 3)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=1820, cgraph_uid=1, symbol_order=1)

f1 ()
{
  char b[5];
  char a[4];
  long unsigned int _1;

   [100.00%] [count: INV]:
  a = "234";
  b = "";
  __builtin_memcpy ([(void *) + 1B], , 4);
  _1 = 3;
  if (_1 != 3)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}



;; Function g0 (g0, funcdef_no=2, decl_uid=1825, cgraph_uid=2, symbol_order=2)

g0 ()
{
  char b[5];
  char a[4];
  long unsigned int _1;

   [100.00%] [count: INV]:
  a = "234";
  b = "1";
  __builtin_memcpy ([(void *) + 1B], , 4);
  _1 = 3;
  if (_1 != 3)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}



;; Function g1 (g1, funcdef_no=3, decl_uid=1830, cgraph_uid=3, symbol_order=3)

g1 ()
{
  char b[5];
  char a[4];
  long unsigned int _1;

   [100.00%] [count: INV]:
  a = "234";
  b = "";
  __builtin_strcat ([(void *) + 1B], );
  _1 = __builtin_strlen ([(void *) + 1B]);
  if (_1 != 3)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[gcc at thomasgereke dot de]

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

Thomas Gereke  changed:

   What|Removed |Added

 CC||gcc at thomasgereke dot de

--- Comment #22 from Thomas Gereke  ---
Seems the bug does still exist in 6.3.0 20170516 (Debian 6.3.0-18). I get a GP
on

  >x0x5574d8c8 <...[abi:cxx11]() const+264>movdqa 0x68(%rsp),%xmm0
   x0x5574d8ce <...[abi:cxx11]() const+270>lea0x80(%rsp),%r13
   x0x5574d8d6 <...[abi:cxx11]() const+278>movq   $0x0,0x50(%rsp)
   x0x5574d8df <...[abi:cxx11]() const+287>movl   $0x0,0x10(%rsp)
   x0x5574d8e7 <...[abi:cxx11]() const+295>movaps %xmm0,(%rsp)
   x0x5574d8eb <...[abi:cxx11]() const+299>movq   $0x0,0x6(%rsp)
   x0x5574d8f4 <...[abi:cxx11]() const+308>movw   $0x0,0xe(%rsp)
   x0x5574d8fb <...[abi:cxx11]() const+315>movdqa (%rsp),%xmm1
   x0x5574d900 <...[abi:cxx11]() const+320>movaps %xmm1,0x40(%rsp)

The asm code is obviously wrong, because movdqa 0x68(%rsp),%xmm0 followed by
movdqa (%rsp),%xmm1 without changes to %rsp has to fail. %rsp was
0x7fffecd477d0.

Code was C++ compiled with -O3 and x86_64. The underlying data structure is
boost::asio::ip::address, which consists of an enum (4 bytes), address_v4 (4
bytes) and address_v6 (16 bytes). The GP occurs when accessing the ipv6
address.

[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson  ---
Created attachment 41754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41754=edit
Assembly output with patch.

[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
Created attachment 41753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41753=edit
Assembly output without patch.

[Bug tree-optimization/81428] [7/8 Regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.

[jon at beniston dot com]

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

--- Comment #2 from Jon Beniston  ---
Thanks Jakub, the patch works for me.

[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[wilson at gcc dot gnu.org]

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

--- Comment #1 from Jim Wilson  ---
Created attachment 41752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41752=edit
Proposed patch to fix scheduler/fusing problem.

[Bug rtl-optimization/81434] New: AArch64 instruction fusing and pipeline scheduling problem

[wilson at gcc dot gnu.org]

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

Bug ID: 81434
   Summary: AArch64 instruction fusing and pipeline scheduling
problem
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

Consider this testcase extracted from OpenSSL sources

extern int Te0[256];
extern int Te1[256];
extern int Te2[256];
extern int Te3[256];

void
sub (unsigned int s0, unsigned int s1, unsigned int s2, unsigned int s3,
 unsigned int *rk, int *result)
{
  unsigned int t0;

  t0 =
Te0[(s0 >> 24)   ] ^
Te1[(s1 >> 16) & 0xff] ^
Te2[(s2 >>  8) & 0xff] ^
Te3[(s3  ) & 0xff] ^
rk[4];

  *result = t0;
}

If I compile with -O2 -mcpu=cortex-a57 -fsched-verbose=9
-fdump-rtl-sched2 -S and look at the tmp.c.295r.sched2 file, I see

;;3--> b  0: i  17 x8=x8+low(`Te3')   
:ca57_sx1|ca57_sx2
;;4--> b  0: i  23 x7=high(`Te1') 
:ca57_sx1|ca57_sx2
;;4--> b  0: i  24 x7=x7+low(`Te1')   
:ca57_sx1|ca57_sx2
;;5--> b  0: i  27 x1=zxt(x1,0x8,0x10)
:ca57_sx1|ca57_sx2
;;5--> b  0: i  28 x6=high(`Te0') 
:ca57_sx1|ca57_sx2
;;6--> b  0: i  29 x6=x6+low(`Te0')   
:ca57_sx1|ca57_sx2
;;7--> b  0: i  21 x8=zxn([x3*0x4+x8])
:ca57_load_model

The first thing to notice here are that we only scheduled one instruction in
cycle 3, even though we have two ALUs, an issue rate of 3, and there are other
ALU insns available to schedule.  The second thing is that the load was not
scheduled until cycle 7, even though it was ready in cycle 4, and there was an
available issue slot for it.

Part of the problem here is that the AArch64 port uses SCHED_GROUP for
instruction fusing.  The other part is that in the scheduler, when we have a
SCHED_GROUP, all non-sched-group instructions are forced to issue in the next
cycle.  This is OK if you can only issue one instruction per cycle, or if a
sched group insn can't issue in this cycle.  It is unnecessary and wrong if we
can issue multiple insns per cycle, and sched group insns can all issue in the
same cycle.  This is the case for Aarch64 cortex-a57 instruction fusing.  I can
also see the same issue for falkor, except that falkor is 4 issue, so there is
more of an effect on the schedule.

So considering the testcase above, we can't issue a second instruction in cycle
3 because the low() is a sched group insn.  We can't issue the load in the
fourth cycle because high/low are both sched group insns.  We can't issue the
load in the fifth cycle because high is a sched group insn.  We can't issue the
load in the sixth cycle because low is a sched group insn.  So the load finally
issues in cycle 7 when we have no sched group insns left.

I have a patch to fix this.  With the patch, I instead get

;;3--> b  0: i  17 x8=x8+low(`Te3')   
:ca57_sx1|ca57_sx2
;;3--> b  0: i  23 x7=high(`Te1') 
:ca57_sx1|ca57_sx2
;;4--> b  0: i  24 x7=x7+low(`Te1')   
:ca57_sx1|ca57_sx2
;;4--> b  0: i  27 x1=zxt(x1,0x8,0x10)
:ca57_sx1|ca57_sx2
;;4--> b  0: i  21 x8=zxn([x3*0x4+x8])
:ca57_load_model
;;5--> b  0: i  28 x6=high(`Te0') 
:ca57_sx1|ca57_sx2
;;5--> b  0: i  29 x6=x6+low(`Te0')   
:ca57_sx1|ca57_sx2

which looks better.  Without the patch, the testcase takes 22 cycles according
to the scheduler.  With the patch, the testcase takes 19 cycles according to
the scheduler.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #5 from martin  ---
Thanks. I did your suggested steps but it still fails.
In comment 4 I attached the ouput of "make -d"?

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

--- Comment #4 from martin  ---
Created attachment 41751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41751=edit
output of make -d

[Bug target/81294] _subborrow_u64 argument order inconsistent with intrinsic reference, icc

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-*-*, i?86-*-*|x86
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.2

--- Comment #5 from Uroš Bizjak  ---
Fixed for gcc-7.2+.

[Bug c++/79790] [C++17] ICE class template argument deduction failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #5 from Paolo Carlini  ---
Looking into it.

[Bug tree-optimization/70988] missing buffer overflow detection in chained strcat calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|ASSIGNED|NEW
  Component|middle-end  |tree-optimization
   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
  Known to fail||7.1.0, 8.0

--- Comment #4 from Martin Sebor  ---
Unassigning myself since I'm not actively working on this bug at the moment.

[Bug c/81405] [8 Regression] Buffer overflow when consolidating printing of out-of-order fix-it hints

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r250187.

[Bug c/81405] [8 Regression] Buffer overflow when consolidating printing of out-of-order fix-it hints

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jul 13 19:30:42 2017
New Revision: 250187

URL: https://gcc.gnu.org/viewcvs?rev=250187=gcc=rev
Log:
diagnostics: fix crash when consolidating out-of-order fix-it hints (PR
c/81405)

PR c/81405 identifies a crash when printing fix-it hints from
-Wmissing-braces when there are excess elements.

The fix-it hints are bogus (which I've filed separately as PR c/81432),
but they lead to a crash within the fix-it consolidation logic I added
in r247548, in line_corrections::add_hint.

The root cause is that some of the fix-it hints are out-of-order
with respect to the column numbers they affect, which can lead to negative
values when computing the gap between the fix-it hints, leading to bogus
memcpy calls that generate out-of-bounds buffer accesses.

The fix is to sort the fix-it hints after filtering them, ensuring that
the gap >= 0.  The patch also adds numerous assertions to the code, both
directly, and by moving the memcpy calls and their args behind
interfaces (themselves containing gcc_assert).

This fixes the crash; it doesn't fix the bug in -Wmissing-braces that
leads to the bogus hints.

gcc/ChangeLog:
PR c/81405
* diagnostic-show-locus.c (fixit_cmp): New function.
(layout::layout): Sort m_fixit_hints.
(column_range::column_range): Assert that the values are valid.
(struct char_span): New struct.
(correction::overwrite): New method.
(struct source_line): New struct.
(line_corrections::add_hint): Add assertions.  Reimplement memcpy
calls in terms of classes source_line and char_span, and
correction::overwrite.
(selftest::test_overlapped_fixit_printing_2): New function.
(selftest::diagnostic_show_locus_c_tests): Call it.

gcc/testsuite/ChangeLog:
PR c/81405
* gcc.dg/Wmissing-braces-fixits.c: Add coverage for PR c/81405.  */


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wmissing-braces-fixits.c

[Bug c/81432] Bogus fix-it hints from -Wmissing-braces when there are excess elements

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jul 13 19:30:42 2017
New Revision: 250187

URL: https://gcc.gnu.org/viewcvs?rev=250187=gcc=rev
Log:
diagnostics: fix crash when consolidating out-of-order fix-it hints (PR
c/81405)

PR c/81405 identifies a crash when printing fix-it hints from
-Wmissing-braces when there are excess elements.

The fix-it hints are bogus (which I've filed separately as PR c/81432),
but they lead to a crash within the fix-it consolidation logic I added
in r247548, in line_corrections::add_hint.

The root cause is that some of the fix-it hints are out-of-order
with respect to the column numbers they affect, which can lead to negative
values when computing the gap between the fix-it hints, leading to bogus
memcpy calls that generate out-of-bounds buffer accesses.

The fix is to sort the fix-it hints after filtering them, ensuring that
the gap >= 0.  The patch also adds numerous assertions to the code, both
directly, and by moving the memcpy calls and their args behind
interfaces (themselves containing gcc_assert).

This fixes the crash; it doesn't fix the bug in -Wmissing-braces that
leads to the bogus hints.

gcc/ChangeLog:
PR c/81405
* diagnostic-show-locus.c (fixit_cmp): New function.
(layout::layout): Sort m_fixit_hints.
(column_range::column_range): Assert that the values are valid.
(struct char_span): New struct.
(correction::overwrite): New method.
(struct source_line): New struct.
(line_corrections::add_hint): Add assertions.  Reimplement memcpy
calls in terms of classes source_line and char_span, and
correction::overwrite.
(selftest::test_overlapped_fixit_printing_2): New function.
(selftest::diagnostic_show_locus_c_tests): Call it.

gcc/testsuite/ChangeLog:
PR c/81405
* gcc.dg/Wmissing-braces-fixits.c: Add coverage for PR c/81405.  */


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Wmissing-braces-fixits.c

[Bug tree-optimization/81433] New: missing strlen optimization for strncpy

[msebor at gcc dot gnu.org]

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

Bug ID: 81433
   Summary: missing strlen optimization for strncpy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC can track the length of some strings created dynamically by calling strcpy
(among other functions) but it's missing the same optimization for the related
strncpy function.

The test case below shows two equivalent functions, where the first is
optimized while the second is not.  The tree-sssa-strlen pass has no support
for strncpy.  Since strncpy is often used as a replacement for strcpy, adding
such support where possible (i.e., in cases where the length of the source
string is known to be less than the specified size) is a potentially
significant optimization opportunity.

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
void f (void)
{
  char a[7];
  __builtin_strcpy (a, "123");
  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}

void g (void)
{
  char a[7];
  __builtin_strncpy (a, "123", sizeof a);
  if (__builtin_strlen (a) != 3)
__builtin_abort ();
}


;; Function f (f, funcdef_no=0, decl_uid=1814, cgraph_uid=0, symbol_order=0)

f ()
{
   [100.00%] [count: INV]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1818, cgraph_uid=1, symbol_order=1)

g ()
{
  char a[7];
  long unsigned int _1;

   [100.00%] [count: INV]:
  __builtin_strncpy (, "123", 7);
  _1 = __builtin_strlen ();
  if (_1 != 3)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  a ={v} {CLOBBER};
  return;

}

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[ed at catmur dot co.uk]

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

--- Comment #29 from Ed Catmur  ---
Created attachment 41750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41750=edit
stack-use-after-scope-read.cpp

Another testcase, no library required. Slight difference here is that the
offending op is a READ:

$ g++ -ggdb3 -fsanitize=address a.cpp && ./a.out 
=
==32502==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffb9ce33c8 at pc 0x00400c8c bp 0x7fffb9ce33b0 sp 0x7fffb9ce33a8
READ of size 8 at 0x7fffb9ce33c8 thread T0
#0 0x400c8b in from a.cpp:5
#1 0x4010b8 in C::g() a.cpp:20
#2 0x401073 in C::f() a.cpp:19
#3 0x401011 in C::~C() a.cpp:16
#4 0x40117e in A::~A() a.cpp:26
#5 0x400ef2 in main a.cpp:62
#6 0x7fd33f017d5c in __libc_start_main (/lib64/libc.so.6+0x1ed5c)
#7 0x400b88  (a.out+0x400b88)

Address 0x7fffb9ce33c8 is located in stack of thread T0
SUMMARY: AddressSanitizer: stack-use-after-scope a.cpp:5 in from
Shadow bytes around the buggy address:
  0x100077394620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100077394630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100077394640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100077394650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100077394660: 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100077394670: 00 00 00 00 00 00 f8 f8 f8[f8]f8 00 00 00 00 00
  0x100077394680: 00 00 f8 f8 f8 f8 f8 f8 00 00 00 00 00 00 00 00
  0x100077394690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000773946a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000773946b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000773946c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==32502==ABORTING

FWIW this was reduced from a Boost.PropertyTree testcase.

Confirming this is fixed by revision 249833 /
5b64e274ea8c9aaedcebc1d6ad285a11e64ab086

[Bug c++/81431] add warning for missing initializers in constructor

[tromey at gcc dot gnu.org]

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

--- Comment #1 from Tom Tromey  ---
Also related is bug 55837.

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Or both this bswap change and the match.pd addition.

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41749=edit
gcc8-pr81396.patch

While the bswap pass finds out this is a nop reshuffling, it hits:
  /* Useless bit manipulation performed by code.  */
  if (!n->base_addr && n->n == cmpnop)
return NULL;
and doesn't do anything (while in GCC6 it was less optimized and thus
n->base_addr was non-NULL and the bswap pass did something with it).
Either we can do something in the bswap pass with it as done in this untested
patch, or we could consider match.pd optimization for:
  _3 = BIT_FIELD_REF <_7, 8, 16>;
  _32 = (typeof(_7)) _3;
  _4 = _32 << 16;
into:
  _4 = _7 & (((1ULL << 8) - 1) << 16);
if the shift matches the bitpos and then rest of match.pd would be able to
figure it out, like it optimizes now at forwprop1 time e.g.:
typedef unsigned long long uint64_t;
uint64_t ReadLittleEndian64(uint64_t word) {
  uint64_t ret = 0;
  ret |= (word & 0xff);
  ret |= (((word & 0xff00) >> 8) << 8);
  ret |= (((word & 0xff) >> 16) << 16);
  ret |= (((word & 0xff00U) >> 24) << 24);
  ret |= (((word & 0xffULL) >> 32) << 32);
  ret |= (((word & 0xff00ULL) >> 40) << 40);
  ret |= (((word & 0xffULL) >> 48) << 48);
  ret |= (((word & 0xff00ULL) >> 56) << 56);
  return ret;
}

[Bug c/81405] [8 Regression] Invalid write of size 2 in line_corrections::add_hint(fixit_hint const*) (diagnostic-show-locus.c:1514)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
I'm testing a fix for this crash in diagnostic-show-locus.c.

I've opened PR c/81432 to track the fact that the fix-its that are being
printed when the crash happens are actually nonsensical.

[Bug c/81432] New: Bogus fix-it hints from -Wmissing-braces when there are excess elements

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 81432
   Summary: Bogus fix-it hints from -Wmissing-braces when there
are excess elements
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

PR c/81405 identifies a crash in diagnostic-show-locus.c in the code to
consolidate fix-it hints during printing, with:

   gcc.dg/init-excess-1.c -Wmissing-braces

The fix-it hints generated by -Wmissing-braces appear to be bogus.

I'm keeping PR c/81405 to track the crash in diagnostic-show-locus.c when
printing them, but am opening this PR to track the bogus fix-it hints from
-Wmissing-braces; their effect can be seen by:


gcc -c ../../src/gcc/testsuite/gcc.dg/init-excess-1.c \
  -Wmissing-braces \
  -fdiagnostics-generate-patch \
  -fno-diagnostics-show-caret

(using -fno-diagnostics-show-caret to avoid the crash in PR c/81405)

and they contain e.g. this hunk:

@@ -13,36 +13,36 @@
 int a1[0][0] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
 int a2[0][1] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
 int a3[1][0] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
-int a4[][0] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
-int a5[][0][0] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
-int a6[][0][1] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
-int a7[][1][0] = { 1, 2 }; /* { dg-warning "excess elements|near init" } */
+int a4[][0] = { {1}, {2 }}; /* { dg-warning "excess elements|near init" } */
+{int a5[][0][0] = { {{1, {{{2 }}}; /* { dg-warning "excess elements|near
init" } */
+{int a6[][0][1] = { {{1, {{{2 }}}; /* { dg-warning "excess elements|near
init" } */
+int a7[][1][0] = { {{1}}, {{2 }}}; /* { dg-warning "excess elements|near init"
} */

which is clearly nonsensical.

[Bug c++/81431] New: add warning for missing initializers in constructor

[tromey at gcc dot gnu.org]

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

Bug ID: 81431
   Summary: add warning for missing initializers in constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

I would like gcc to emit a warning when a constructor does not
initialize a POD member; and in particular I'd like this not to
be tied to -Wuninitialized.

Having a warning like this is good for robustness -- it avoids
situations where one forgets to initialize a scalar or the like.

I realize -Wuninitialized will do this, but that can be a difficult
warning to enable for an existing code base, due to false positives.

Something along the lines of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972#c9
would be nice.

-Weffc++ does warn about this, but it is too broad, as it includes
members that have a constructor.

Here's a simple example:

struct X
{
  int a,b;

  X() : a(5) { }
};

X x;

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 41748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41748=edit
Test for targetm_common.have_named_sections in pass_partition_blocks::gate

Patch I'm currently testing.

Not sure if this is the proper way to fix this though.

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
This PR may have been triggered by "Do not silently disable
flag_reorder_functions when profile info is missing" ( 
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00518.html )

[Bug lto/81430] New: nvptx acceleration compilation broken because of running pass_partition_blocks

[vries at gcc dot gnu.org]

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

Bug ID: 81430
   Summary: nvptx acceleration compilation broken because of
running pass_partition_blocks
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[ tentatively setting component to lto ]

Atm, when running the libgomp testsuite for an x86_64 compiler with nvptx
acceleration, we run into a number of ICEs in lto1.  I've investigated an ICE
in fix_crossing_unconditional_branches, which occurs for both openmp and
openacc.  The basic problem is that we're running pass_partition_blocks for
nvptx, while 
we don't want to do that.


Note that for standalone compilation for single-thread ptx execution, we don't
attempt to run pass_partition_blocks. This is because for nvptx,
TARGET_HAVE_NAMED_SECTIONS is set to false, and this bit in finish_options
switches off pass_partition_blocks:
...
   /* If the target requested unwind info, then turn off the partitioning   
 optimization with a different message.  Likewise, if the target does not   
 support named sections.  */

  if (opts->x_flag_reorder_blocks_and_partition
  && (!targetm_common.have_named_sections
  || (opts->x_flag_unwind_tables
  && targetm_common.unwind_tables_default
  && (ui_except == UI_SJLJ || ui_except >= UI_TARGET
{
  if (opts_set->x_flag_reorder_blocks_and_partition)
inform (loc,
"-freorder-blocks-and-partition does not work "
"on this architecture");
  opts->x_flag_reorder_blocks_and_partition = 0;
  opts->x_flag_reorder_blocks = 1;
}
...


But that doesn't seem to work for the offloading setup. The scenario is as
follows:
- testcase is compiled with -O2
- ix86_option_optimization_table enables OPT_freorder_blocks_and_partition at
  -O2
- cc1 writes out the flag as part of DECL_FUNCTION_SPECIFIC_OPTIMIZATION
- lto1 reads in the flag as part of DECL_FUNCTION_SPECIFIC_OPTIMIZATION
- lto1 uses the flag, and runs pass_partition_blocks
- pass_partition_blocks ICEs

[Bug testsuite/81399] New test case 27_io/basic_stringstream/assign/81338.cc fails on powerpc64le

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from seurer at gcc dot gnu.org ---
On the fresh test builds I did today this is now working.

[Bug fortran/81416] OpenMP craches if large arrays passed

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
>  DOUBLE PRECISION,DIMENSION(n) :: b

This array is on the stack.

[Bug c++/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
After I deleted -funsafe-loop-optimizations in GIMPLE passes, there is no
"unsafe-loop-optimizations" for any GIMPLE optimizers.  This message in
actuality means missed loop optimizations.  I am preparing patch dumping the
message to category MSG_MISSED_OPTIMIZATION.

On the other hand, I noticed the niter analysis for c++ iterator loop is bad. 
I will create another PR for it.

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle  ---
(In reply to Jakub Jelinek from comment #18)
> Created attachment 41744 [details]
> gcc8-pr65757.patch
> 
> Here is a full version, it compiles, no further testing so far.
> I guess I can bootstrap/regtest it next, but don't have time for further
> testing.  Guess it would be nice to tweak glibc math testsuite to test
> __float128 with it, I vaguely remember Tobias doing that years ago, but not
> sure
> if he had any patches for that.
> 

I dont know about anything else. I will also test here. Thanks for doing this!

[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|powerpc64*-*-*  |powerpc64*-*-* arm
 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
On arm the regression appeared between 249444 and 249453.

[Bug c++/81429] maybe_unused attribute triggers syntax error when used on first argument to a constructor

[jeff.benshetler at stackpath dot com]

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

--- Comment #1 from Jeff Benshetler  ---
Created attachment 41747
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41747=edit
Source test case that triggers the bug; corresponds to .ii file

Added in an abundance of caution. 
No header files are used. 
The first constructor has [[maybe_used]] on the first constructor parameter and
it triggers the bug.
The second constructor uses [[maybe_unused]] on the second constructor
parameter and it is fine.

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Thanks.  That file looks fine.

I don't understand why make is saying that there is a circular dependency,
implying that runtime.lo depends on runtime.s-gox.  It does not.

I suggest simply removing your BUILDDIR/TARGET/libgo directory and building
again.  If you still see the problem, I think you will need to use `make -d` to
understand where the mystery dependency is coming from.

[Bug c++/81429] New: maybe_unused attribute triggers syntax error when used on first argument to a constructor

[jeff.benshetler at stackpath dot com]

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

Bug ID: 81429
   Summary: maybe_unused attribute triggers syntax error when used
on first argument to a constructor
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.benshetler at stackpath dot com
  Target Milestone: ---

Created attachment 41746
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41746=edit
Preprocessed file that triggers the bug.

maybe_unused attribute triggers syntax error when used on first argument to a
constructor

Systm Type: Linux bnx1-lab1-dfw0.stackpath.systems 3.10.0-514.10.2.el7.x86_64
#1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Options given when GCC was configured/built: 
  tar xzf gcc-7.1.0.tar.gz
  cd gcc-7.1.0
  ./contrib/download_prerequisites
  cd ..
  mkdir objdir-7.1.0
  cd objdir-7.1.0
  ../gcc-7.1.0/configure --prefix=/opt/gcc-7.1.0 --enable-languages=c,c++
--disable-multilib
  make -j60
  sudo make install

Complete command line that triggers the bug: g++ -Wall -Wextra -save-temps -c
maybe_unused.cpp

Compiler Output
  maybe_unused.cpp:3:9: error: expected unqualified-id before ‘[’ token
 Foo([[maybe_unused]] int x) // fails
 ^
  maybe_unused.cpp:3:9: error: expected ‘)’ before ‘[’ token
This bug occurs with gcc-6.3.0, gcc-6.4.0, gcc-7.1.0. clang-3.9 is fine with
the code.

[Bug fortran/81416] OpenMP craches if large arrays passed

[bz0815 at tirol dot com]

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

--- Comment #2 from bz0815 at tirol dot com ---
(In reply to Andrew Pinski from comment #1)
> Try increasing your stack limit. I suspect it is too low. With -fopenmp
> turned on causes arrays to be always stored on the stack .

Many thanks for the hint, Andrew. Increasing the stack limit by
-Wl,--stack,16777216 solves the issue. -fopenmp implies -frecursive and
-frecursive forces all local arrays to be allocated on the stack. But which
array is local? Possibly the dummy argument of subroutine Print_Info. Is
gfortran passing this array really by value although its intent is out?

[Bug target/80583] [6/7/8 Regression] ICE with target attribute and vectorized float: internal compiler error: in convert_move, at expr.c:270

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|5.4.0   |
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[6/7/8 Regression] ICE with |[6/7/8 Regression] ICE with
   |target_clones and   |target attribute and
   |vectorized float: internal  |vectorized float: internal
   |compiler error: in  |compiler error: in
   |convert_move, at expr.c:270 |convert_move, at expr.c:270
  Known to fail||4.9.4, 5.4.0, 6.4.0, 7.1.0

--- Comment #6 from Martin Liška  ---
So it's a different story and it's related to target options:

$ cat /home/marxin/Programming/testcases/pr80583-2.ii
struct S {
  __attribute__((__vector_size__(8 * sizeof(0 int a;
};

int __attribute__((target("avx"))) foo() {
  S *b{};
  __attribute__((__vector_size__(8 * sizeof(0 int x = b->a;
}

$ g++ /home/marxin/Programming/testcases/pr80583-2.ii -c
during RTL pass: expand
/home/marxin/Programming/testcases/pr80583-2.ii: In function ‘int foo()’:
/home/marxin/Programming/testcases/pr80583-2.ii:7:55: internal compiler error:
in convert_move, at expr.c:232
   __attribute__((__vector_size__(8 * sizeof(0 int x = b->a;
   ^
0xa593ab convert_move(rtx_def*, rtx_def*, int)
../../gcc/expr.c:232
0xa60292 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5636
0xa619a7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5327
0x93d9a8 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3651
0x93d9a8 expand_gimple_stmt
../../gcc/cfgexpand.c:3749
0x93fb17 expand_gimple_basic_block
../../gcc/cfgexpand.c:5753
0x945ba6 execute
../../gcc/cfgexpand.c:6360

Which ICEs for all releases I have (4.5.0+).

[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Last reconfirmed|2017-06-23 00:00:00 |2017-7-13
 CC||thopre01 at gcc dot gnu.org

--- Comment #2 from Thomas Preud'homme  ---
These testcases (gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c) also
started to fail for ARM Cortex-M0, Cortex-M3 and Cortex-M4 arm-none-eabi
targets.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[willschm at gcc dot gnu.org]

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

--- Comment #16 from Will Schmidt  ---
(In reply to Bill Schmidt from comment #13)
> CCing Will Schmidt for the general gimple-folding issue of built-in calls
> with missing LHSes.

revision 250185 has been committed to handle the gimple-folding issue.

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64-none-linux-gnu
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-07-13
  Component|rtl-optimization|target
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |5.5
  Known to fail||4.8.5, 4.9.4, 5.4.1, 6.4.1,
   ||7.1.1, 8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all released GCC versions supporting aarch64.
Only ICEs on aarch64-linux targets, not bare-metal
I suspect the REG_EQUIV notes that we add in the aarch64 backend in the TLS
symbol handling code are to blame.

[Bug tree-optimization/81428] [7/8 Regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-13
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault

[anatol.pomozov at gmail dot com]

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

--- Comment #5 from Anatol  ---
Having 32bit preamble in 64bit code is a standard situation in x86 OS
development. Bootloader (such as GRUB multiboot) leaves the system in 32bit
protected mode. It is responsibility of the OS to finish 32bit initialization
(where only i386 instructions can be used) and switch to 64bit code. Once 32bit
initialization is done switching to 64code happens with "far jump with
selector" instruction
 "jmp $CODE_SELECTOR, $START64"


You cannot link 32bit and 64bit together (and least LD linker does not allow
it). Thus one have to use a trick, either:
1) objcopy code32.o from elf32 to elf64 format
2) if code32 was an ASM code then use ".code32" GAS directive and compile file
with 64bit flags.

Here is an example of #2 from LK operation system
https://github.com/littlekernel/lk/blob/master/arch/x86/64/start.S#L210

I tried both solution and they both work with GCC and CLANG. GCC crashes if I
enable LTO for #1.

[Bug ipa/81277] assert() in multiversioned functions causes compilation error

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok, having fixed PR70422, this issue will be fixed. I'm going to push patches
related to the PR.

[Bug bootstrap/81425] Bootstrap broken since r250158

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
wot, the Changelog's not enough?

apologies.

[Bug middle-end/81428] [7/8 Regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|[7.1 regression] ICE: in|[7/8 Regression] ICE: in
   |build_one_cst, at   |build_one_cst, at
   |tree.c:2079 with -O2. Fixed |tree.c:2079 with -O2. Fixed
   |point division. |point division.

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41740|0   |1
is obsolete||

--- Comment #18 from Jakub Jelinek  ---
Created attachment 41744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41744=edit
gcc8-pr65757.patch

Here is a full version, it compiles, no further testing so far.
I guess I can bootstrap/regtest it next, but don't have time for further
testing.  Guess it would be nice to tweak glibc math testsuite to test
__float128 with it, I vaguely remember Tobias doing that years ago, but not
sure
if he had any patches for that.

The patch is a result of manual incorporation of:
git diff 5b5b04d6282df0364424c6f2c0462e5c1a4394b0
15089e046b6c71bbefe29687fe4c7e569c9e1c03^ sysdeps/ieee754/ldbl-128/
git diff 15089e046b6c71bbefe29687fe4c7e569c9e1c03
02bbfb414f367c73196e6f23fa7435a08c92449f^ sysdeps/ieee754/ldbl-128/
git diff 02bbfb414f367c73196e6f23fa7435a08c92449f
2bc646c9e95b7c0005b2bc09c06671ffbb509629 sysdeps/ieee754/ldbl-128/

- the two revisions left out are the long double -> _Float128 and floatconstL
to
L(floatconst) changes, plus I've left out *jn*, *lgamma* and *x2y2m1* changes,
they were too big.  And no new APIs have been added.
Also, I've left *hypot* and *pow* changes related to issignaling, we don't have
issignalingq (yet).

[Bug libstdc++/81395] [5/6/7/8 Regression] basic_filebuf::overflow recurses and overflows stack

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  ---
Hi,

> It looks strange, because usually _M_set_buffer(-1) is used for uncommitted
> mode, but what it's actually doing is nuking the buffers. The next read
> would need to do an underflow to refill the get area (which is correct), or
> the next write would need to do a seek and then an overflow to make a put
> area available (which is correct).

Indeed, you are making explicit some vague thoughts of mine, which, by and
large pointed in the direction that uncommited mode may well be fine, modulo
possible performance implications, like, again very vague thoughts, we end up
re-reading something which we already read. Those cases I was hoping you could
investigate a bit ;)

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #4 from Uroš Bizjak  ---
CC maintainer.

[Bug libstdc++/81395] [5/6/7/8 Regression] basic_filebuf::overflow recurses and overflows stack

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Hmm, except that if we *do* have a pending output sequence there (i.e. data in
the put area), we'd discard it, losing data. I'll try to verify that with a
testcase.

So we want to avoid getting into a state where we have anything in the put area
while _M_reading is true, which is what comment 2 does.

It looks strange, because usually _M_set_buffer(-1) is used for uncommitted
mode, but what it's actually doing is nuking the buffers. The next read would
need to do an underflow to refill the get area (which is correct), or the next
write would need to do a seek and then an overflow to make a put area available
(which is correct).

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Following is a c testcase:

--cut here--
unsigned long long int ll = 0;
unsigned long long int ull1 = 1ULL;
unsigned long long int ull2 = 12008284144813806346ULL;
unsigned long long int ull3;

void
foo ()
{
  ll = -5597998501375493990LL;

  ll = (5677365550390624949L - ll) - (ull1 > 0);
  ull3 = (unsigned int)
(2067854353L <<
 (((ll + -2129105131L) ^ 10280750144413668236ULL) -
  10280750143997242009ULL)) >> ((2873442921854271231ULL | ull2)
- 12098357307243495419ULL);
}

int
main ()
{
  foo ();
  printf ("%llu expected 3998784)\n", ull3);
  printf ("%x expected 3d0440)\n", ull3);
  return 0;
}
--cut here--

The problem is in combine pass, which combines following sequence in the main
function:

(insn 17 16 18 2 (parallel [
(set (reg:SI 114)
(ior:SI (subreg:SI (reg:DI 113 [ ull2 ]) 0)
(const_int -8651009 [0xff7bfeff])))
(clobber (reg:CC 17 flags))
]) "pr81423.c":15 415 {*iorsi_1}
 (expr_list:REG_DEAD (reg:DI 113 [ ull2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 18 17 19 2 (parallel [
(set (reg:SI 115)
(plus:SI (reg:SI 114)
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "pr81423.c":16 217 {*addsi_1}
 (expr_list:REG_DEAD (reg:SI 114)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 19 18 20 2 (parallel [
(set (reg:SI 116)
(lshiftrt:SI (subreg:SI (reg:DI 111) 0)
(subreg:QI (reg:SI 115) 0)))
(clobber (reg:CC 17 flags))
]) "pr81423.c":15 544 {*lshrsi3_1}
 (expr_list:REG_DEAD (reg:SI 115)
(expr_list:REG_DEAD (reg:DI 111)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 20 19 21 2 (set (reg:DI 103 [ _20 ])
(zero_extend:DI (reg:SI 116))) "pr81423.c":15 131 {*zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 116)
(nil)))


Trying 17, 18, 19 -> 20:
Failed to match this instruction:
(set (reg:DI 103 [ _20 ])
(zero_extract:DI (reg:DI 111)
(const_int 32 [0x20])
(const_int 4 [0x4])))
Failed to match this instruction:
(set (reg:DI 103 [ _20 ])
(and:DI (lshiftrt:DI (reg:DI 111)
(const_int 4 [0x4]))
(const_int 4294967295 [0x])))
Successfully matched this instruction:
(set (reg:DI 116)
(ashift:DI (reg:DI 111)
(const_int 28 [0x1c])))
Successfully matched this instruction:
(set (reg:DI 103 [ _20 ])
(lshiftrt:DI (reg:DI 116)
(const_int 32 [0x20])))
allowing combination of insns 17, 18, 19 and 20
original costs 6 + 4 + 4 + 1 = 15
replacement costs 4 + 4 = 8
deferring deletion of insn with uid = 18.
deferring deletion of insn with uid = 17.
deferring deletion of insn with uid = 16.
modifying insn i219: {r116:DI=r111:DI<<0x1c;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_DEAD r111:DI
deferring rescan insn with uid = 19.
modifying insn i320: {r103:DI=r116:DI 0>>0x20;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_DEAD r116:DI
deferring rescan insn with uid = 20.


Please note that we have in the original sequence:

(insn 19 18 20 2 (parallel [
(set (reg:SI 116)
(lshiftrt:SI (subreg:SI (reg:DI 111) 0)
(subreg:QI (reg:SI 115) 0)))
(clobber (reg:CC 17 flags))
]) "pr81423.c":15 544 {*lshrsi3_1}
 (expr_list:REG_DEAD (reg:SI 115)
(expr_list:REG_DEAD (reg:DI 111)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

in effect, this insn is shifting value, truncated to 32 bits, from

rax0x1ed03d044002117482857472

by 4 via:

   0x00400557 <+71>:add$0x5,%ecx
   0x0040055a <+74>:shr%cl,%eax

resulting in:

rax0x3d0440 3998784
rcx0x4  4

However, combine tries to create:

(set (reg:DI 103 [ _20 ])
(zero_extract:DI (reg:DI 111)
(const_int 32 [0x20])
(const_int 4 [0x4])))

trying to extract 32bit value from position 4. This is not correct, due to
32bit  left shift  in the sequence, the combined insn should zero-extract 28
bits only.

[Bug libstdc++/81395] [5/6/7/8 Regression] basic_filebuf::overflow recurses and overflows stack

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
I don't think uncommitted mode is correct there, because stdio requires a seek
on the underlying FILE before writing to it. Setting _M_reading ensures that
will happen before the next write. Uncommitted mode would cause that seek to be
skipped.

So maybe this workaround (from comment 1) is a reasonable solution:

@@ -920,7 +925,7 @@
 {
   // Part one: update the output sequence.
   bool __testvalid = true;
-  if (this->pbase() < this->pptr())
+  if (this->pbase() < this->pptr() && __builtin_expect(!_M_reading, 1))
{
  const int_type __tmp = this->overflow();
  if (traits_type::eq_int_type(__tmp, traits_type::eof()))

This just prevents the infinite recursion, by not trying to perform a pending
write if we're currently in read mode.

[Bug c++/81232] compiler crashes for template function overload

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
This is fixed, together with many similar crashes - no need to add another
testcase - in 6.2.0.

[Bug middle-end/59521] __builtin_expect not effective in switch

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Yuri Gribov from comment #8)
> Created attachment 41737 [details]
> New draft patch
> 
> How about this? I added edge attribute for builtin_expect and later used it
> in emit_case_decision_tree to emit expected comparison prior to decision
> tree for other case values.
> 
> With this patch GCC optimizes original example. If it's not too ugly I'll do
> proper testing and send to gcc-patches.

The patch works for me for the described case, but does not for PGO, which
should do the same based on real numbers:

$ cat pr59521-profile.c
#include 
void
f(int ch) {
  switch (ch) {
case 100: puts("100"); break;   
case 10: puts("10"); break; 
case 1: puts("1"); break; 
} 
}

int main()
{
  for (int i = 0; i < 1; i++)
  {
int v;
if (i % 100 == 0)
  v = 100;
else if(i % 10 == 0)
  v = 10;
else
  v = 1;
f(v);
  }
}

$ gcc pr59521-profile.c -fprofile-generate && ./a.out && gcc pr59521-profile.c
-fprofile-use -S -fdump-tree-optimized=/dev/stdout

...
f (int ch)
{
   [100.00%] [count: 1]:
  switch (ch_2(D))  [0.00%] [count: 0], case 1:  [90.00%]
[count: 9000], case 10:  [9.00%] [count: 900], case 100:  [1.00%]
[count: 100]>
...

But assembly looks as follows:

cmpl$10, %eax
je  .L3
cmpl$100, %eax
je  .L4
cmpl$1, %eax
je  .L5
jmp .L6

Just a small note, Honza's planning to rewrite switch expansion to happen on
tree level. Maybe (hopefully) such transformations
will be easier on tree level?

[Bug libstdc++/78714] std::get_time / std::time_get::get does not accept full month name in %b

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-13
 Ever confirmed|0   |1

[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Another testcase from PR 71556:

#include 
#include 
#include 
#include 

int main()
{
std::tm t = {};
std::istringstream ss("9");
ss.imbue(std::locale("C.UTF-8"));
ss >> std::get_time(, "%H");
if (ss.fail()) {
std::cout << "Parse failed\n";
} else {
std::cout << std::put_time(, "%c") << '\n';
}
}

[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||j...@jak-linux.org

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

[Bug libstdc++/71556] set::get_time() requires leading 0s for %H and friends

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
The leading zeros were required in C++98, but are optional since C++1.

This is Bug 45896.

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

[Bug middle-end/81428] New: [7.1 regression] ICE: in build_one_cst, at tree.c:2079 with -O2. Fixed point division.

[jon at beniston dot com]

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

Bug ID: 81428
   Summary: [7.1 regression] ICE: in build_one_cst, at tree.c:2079
with -O2. Fixed point division.
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jon at beniston dot com
  Target Milestone: ---

Created attachment 41743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41743=edit
Failing Testcase

The attached fixed point division test case fails for arm-eabi-gcc (and some
other targets, so not target specific) when compiled at -O2 with GCC 7.1.0. GCC
6.1.0 appears to be ok.

arm-eabi-gcc test.c -O2
test.c: In function ‘main’:
test.c:65:5: internal compiler error: in build_one_cst, at tree.c:2079
 int main()
 ^~~~

test.c:65:5: internal compiler error: Aborted
arm-eabi-gcc: internal compiler error: Aborted (program cc1)

Code is:

inline static v2si_t  vwfdivr (v2si_t x, v2si_t y) 
{
  v2si_t r;
  int i;
  for (i = 0; i < 2; i++)
{
  long _Fract t1, t2, t3;
  t1 = lrbits(x[i]);
  t2 = lrbits(y[i]); 
  t3 = t1 / t2;
  r[i] = bitslr(t3);
}  
  return r;
}

It appears to be related to the division, as changing that to another
arithmetic operator results in the ICE disappearing.

[Bug middle-end/26461] liveness of thread local references across function calls

[stephan at tobies dot info]

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

--- Comment #18 from Stephan Tobies  ---
+1 - I have a use case where a QuickThread is migrated from one pthread to
another. TLS would need to be re-fetched after this migration, but is not due
to CSE optimizations. Having a way to disable this optimization, either locally
or on a per-file basis would be very useful!

[Bug tree-optimization/35503] Warning about restricted pointers?

[samuel.thiba...@ens-lyon.org]

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

--- Comment #10 from Samuel Thibault  ---
Well, the fact that there are a lot of false negative is not an argument for
not including it in -Wall :)

The current implementation does catch the issues I have seen in existing code,
so it is already useful to raise it.

[Bug tree-optimization/81427] New: Bad optimization for fibonacci function on PowerPC

[Simon.Richter at hogyros dot de]

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

Bug ID: 81427
   Summary: Bad optimization for fibonacci function on PowerPC
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

Created attachment 41742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41742=edit
Generated assembler code

Compiling the code

#include 

uint64_t fib(uint64_t n)
{
if(n == 0 || n == 1)
return n;
return fib(n-1) + fib(n-2);
}

for PowerPC (be/le, 32/64 in any combination) with -O3 gives a lengthy function
that is clearly suboptimal (each recursion level saves r14-r31 in a 320 bytes
stack frame. The code generated without optimizer looks sane.

[Bug c++/80287] C++ crash with __attribute((may_alias))

[yroux at gcc dot gnu.org]

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

--- Comment #8 from Yvan Roux  ---
OK, I'll submit a patch to add this second testcase on trunk and then only
include it in the backport on GCC 6.

Thanks

[Bug rtl-optimization/47582] Combine chains of movl into movq

[ktkachov at gcc dot gnu.org]

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

Bug 23684 Summary: Combine stores for non strict alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684

   What|Removed |Added

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

[Bug rtl-optimization/23684] Combine stores for non strict alignment targets

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktkachov at gcc dot gnu.org
  Known to work||7.1.1, 8.0
 Resolution|--- |FIXED

--- Comment #16 from ktkachov at gcc dot gnu.org ---
Fixed in GCC 7

[Bug tree-optimization/47059] compiler fails to coalesce loads/stores

[ktkachov at gcc dot gnu.org]

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

Bug 23684 Summary: Combine stores for non strict alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684

   What|Removed |Added

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

[Bug c++/80287] C++ crash with __attribute((may_alias))

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
Hmm, yes, maybe having a second test case without C++17 would be fine.

[Bug c++/80287] C++ crash with __attribute((may_alias))

[yroux at gcc dot gnu.org]

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

--- Comment #6 from Yvan Roux  ---
Hi,

I got a small issue when testing the backport into the branch:

g++.dg/lto/pr80287_0.C is not a suitable testcase for GCC 6 branch, since it
uses c++17 class std:any which is not available in GCC 6.  In the first place
this bug was found when building
libstdc++-v3/testsuite/20_util/any/assign/2.cc, but it is not related to
std:any, I found it on my side in ceph package build, and the issue is
exhibited when compiling this reduced testcase with -g:

struct A {
  operator long() {}
} __attribute__((__may_alias__));
struct {
  A ino;
} a;
char b = a.ino;

So, I wonder what is the best way to handle that, adding this new testcase on
trunk as g++.dg/pr80287.C and only backport this one into GCC 6, or avoid
std:any usage into g++.dg/lto/pr80287_0.C ?

[Bug lto/81406] [6/7/8 Regression] ICE in check_die, at dwarf2out.c:6185

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||aldyh at gcc dot gnu.org
Summary|ice in check_die, at|[6/7/8 Regression] ICE in
   |dwarf2out.c:6185|check_die, at
   ||dwarf2out.c:6185

--- Comment #3 from Martin Liška  ---
Confirmed, there's minimal reproducer:

$ cat pr81406.i
int a;
int *b (void);
static inline int __attribute__ ((__artificial__)) c ()
{
  if (a)
*b () = 2;
}
void *d() { return (void *)c; }

$ gcc -c -flto pr81406.i -O2 -g -fPIC && gcc -shared -fPIC -g pr81406.o
Duplicate attributes in DIE:
DIE0: DW_TAG_subprogram (0x2b3b30e12230)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_name: "c.part.0"
  DW_AT_type: die -> 0 (0x2b3b30e12280)
  DW_AT_artificial: 1
  DW_AT_inline: 3
  DW_AT_artificial: 1

during IPA pass: inline
In function ‘c.part.0’:
lto1: internal compiler error: in check_die, at dwarf2out.c:6175
0x6e78db check_die
../../gcc/dwarf2out.c:6175
0x70a21e dwarf2out_decl
../../gcc/dwarf2out.c:25765
0x70ab9d dwarf2out_abstract_function
../../gcc/dwarf2out.c:21660
0xb2a134 expand_call_inline
../../gcc/tree-inline.c:4923
0xb2bf84 gimple_expand_calls_inline
../../gcc/tree-inline.c:4953
0xb2bf84 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5093
0x126a12e inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.c:705
0x9c7b76 execute_one_ipa_transform_pass
../../gcc/passes.c:2234
0x9c7b76 execute_all_ipa_transforms()
../../gcc/passes.c:2276
0x69294f cgraph_node::expand()
../../gcc/cgraphunit.c:2045
0x693f40 expand_all_functions
../../gcc/cgraphunit.c:2188
0x693f40 symbol_table::compile()
../../gcc/cgraphunit.c:2540
0x5f4f1f lto_main()
../../gcc/lto/lto.c:3334

Started with r224393, adding Aldy.

[Bug target/81426] New: [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 81426
   Summary: [SH]: unable to find a register to spill in class
'R0_REGS' when building webkit2gtk
   Product: gcc
   Version: 7.1.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=webkit2
gtk=sh4=2.16.3-2=1496275824=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Created attachment 41741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41741=edit
Preprocessed source cc6kN21T.out (gzipped)

Trying to build webkit2gtk on Debian unstable sh4 with gcc-7.1.0 bails out
with:

/<>/Source/WTF/wtf/dtoa.cpp:1207:1: error: unable to find a
register to spill in class 'R0_REGS'
 }
 ^
/<>/Source/WTF/wtf/dtoa.cpp:1207:1: error: this is the insn:
(insn 1022 1021 1023 126 (parallel [
(set (subreg:SI (reg:QI 2 r2 [1073]) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 4 r4 [1069]) [-1  S1 A8])
(reg:QI 1072)
(reg:QI 7 r7 [1075])
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 4 r4 [1069]) [-1  S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) /usr/include/c++/6/bits/atomic_base.h:434 664
{atomic_compare_and_swapqi_soft_gusa}
 (expr_list:REG_DEAD (reg:QI 7 r7 [1075])
(expr_list:REG_DEAD (reg:QI 1072)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil))
/<>/Source/WTF/wtf/dtoa.cpp:1207: confused by earlier errors,
bailing out

Attaching pre-processed source.
(...)
Preprocessed source stored into /tmp/cc6kN21T.out file, please attach this to
your bugreport.

[Bug bootstrap/81425] Bootstrap broken since r250158

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Schwab  ---
http://gcc.gnu.org/viewcvs/gcc?view=revision=250159

[Bug bootstrap/81425] Bootstrap broken since r250158

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Marc Glisse from comment #1)
> Isn't that already fixed?
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00614.html

Yep, it works for me. Can please someone install the patch?

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Chris Severance from comment #3)
> Unless there's a security reason 0 should never be used as a canary value.
> Errant \0 should be caught 100% of the time. When I built malloc canaries
> for NPPTextFX I expressly avoided \0.

Agreed, it's not a good constant.

> 
> data[SMASH_ALIGN]='f' should be caught by bounds checking or a shadow stack,
> not ssp.

What do you mean by a shadow stack? If AddressSanitizer, then yes, it's doable:

$ gcc -fsanitize=address smashme.c -g && ./a.out 
=
==527==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd2b7aeb6
at pc 0x2b13549d69e7 bp 0x7ffdd2b7ad80 sp 0x7ffdd2b7a530
WRITE of size 7 at 0x7ffdd2b7aeb6 thread T0
#0 0x2b13549d69e6 in __interceptor_vsprintf
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1345
#1 0x2b13549d6d46 in __interceptor_sprintf
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1376
#2 0x40093b in smashme
/home/marxin/Programming/testcases/PR81021/smashme.c:21
#3 0x4009f7 in main /home/marxin/Programming/testcases/PR81021/smashme.c:28
#4 0x2b13558ff469 in __libc_start_main (/lib64/libc.so.6+0x20469)
#5 0x4007e9 in _start
(/home/marxin/Programming/testcases/PR81021/a.out+0x4007e9)

And by bounds checking you probably mean:

$ gcc -D_FORTIFY_SOURCE=2 smashme.c -O && ./a.out 
*** buffer overflow detected ***: ./a.out terminated
=== Backtrace: =
...

It doesn't overwrite any canaries. It only writes to icanary which
> is my canary, not a gcc canary. The only time it should be caught by ssp is
> when icanary is disabled and it overwrites CNRY at the top of the stack.

Currently we generate canary in between stack variables and return value. That
explains
why one can overwrite both icanary and also SSP canary.

> 
> For debug builds canaries should be placed between every stack variable and
> in the unused space of aligned but undersized variables. Is there such an
> option?

AFAICK not, but can be interesting enhancement.

[Bug bootstrap/81425] Bootstrap broken since r250158

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Isn't that already fixed?
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00614.html

[Bug bootstrap/81425] New: Bootstrap broken since r250158

[marxin at gcc dot gnu.org]

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

Bug ID: 81425
   Summary: Bootstrap broken since r250158
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

.././../libcc1/libcp1plugin.cc: In function ‘gcc_decl
plugin_build_decl(cc1_plugin::connection*, const char*, gcc_cp_symbol_kind,
gcc_type, const char*, gcc_address, const char*, unsigned int)’:
.././../libcc1/libcp1plugin.cc:1422:34: error: lvalue required as left operand
of assignment
  DECL_CONSTRUCTOR_P (decl) = 1;
  ^
.././../libcc1/libcp1plugin.cc:1424:33: error: lvalue required as left operand
of assignment
  DECL_DESTRUCTOR_P (decl) = 1;

[Bug c/81342] LTO: lto1: internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Anatol from comment #3)
> Hi
> 
> I indeed observe the issue in a kernel project. It is a custom x86 kernel
> that is not published yet.
> 
> I tried to narrow down use case and I think I found how to reproduce the
> issue easily. It looks like a trigger pattern is:
> 
> 1) compile one file as 32bit code (-m32)
> 2) convert it to 64bit elf object using objcopy
> 3) link the object above with regular 64bit elf
> 
> If "-flto" is not used then linking works fine otherwise I have the crash
> above.
> 
> Here is an attached repo case for your convenience.

Well how does it make sense to combine -m32 and -m64 in a single binary?
Without -flto having a cross-reference:

$ cat code32.c
int hello(int a)
{
  return a * a;
}

$ cat code64.c
void main(void) {
  return hello(1);
}

One gets:

$ gcc -g -ggdb -nostdlib -ffreestanding -std=c11 -fno-stack-protector
-mno-red-zone -fno-common -W -Wall -Wextra -O3 code32.o code64.o -o code_bin
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
004000f0

Thus without LTO it does not work.

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #2 from Uroš Bizjak  ---
The referred commit enabled new extzv and insv patterns, and in the
past, it exposed a bunch of bugs in the generic RTL part.

Let me analyse what is going on here.

[Bug tree-optimization/81418] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-13
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r249919.

[Bug tree-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-13
 CC||marxin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
Summary|Wrong code at -O2   |[6/7/8 Regression] Wrong
   ||code at -O2
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r225463.

[Bug ada/81424] New: gnat bugbox on i386

[pavel at zhukoff dot net]

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

Bug ID: 81424
   Summary: gnat bugbox on i386
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net
  Target Milestone: ---

During compilcation of gprbuild or gnatcoll on i686 in Fedora compiler exits
with unrecoverable error [1]. 
Reproducer https://landgraf.fedorapeople.org/gccbug.tgz. Compilation options
are in command.sh file inside.
Fedora bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1444614

It affects entire stack of Ada program in Fedora as all of them are blocked by
this.
As gcc<7 works fine and both gprbuild 2016 and 2017 from AdaCore cannot be
compiled with gcc>=7 I suspect the problem is in gcc itself not gprbuild.

[1] 
/builddir/build/BUILD/gprbuild-gpl-2017-src/gpr/src/gpr-compilation-protocol.ads:198:7:
note: 'PID' was declared here
+===GNAT BUG DETECTED==+
| 7.1.1 20170526 (Red Hat 7.1.1-2) (i686-redhat-linux) GCC error:  |
| in emit_move_insn, at expr.c:3698|
| Error detected around
/builddir/build/BUILD/gprbuild-gpl-2017-src/src/gprclean-main.adb:995:13|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 41740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41740=edit
gcc8-pr65757.patch

WIP patch.  There are still many files to do (and this is only before the long
double -> _Float128 changes patch).

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
I have actually started manual backporting of the 2012-2017
sysdeps/ieee754/ldbl-128/ differences, I'll attach what I have so far.

[Bug target/71989] aarch64 musl bootstrap fails for out-of-tree builds

[timo.teras at iki dot fi]

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

Timo Teräs  changed:

   What|Removed |Added

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

--- Comment #4 from Timo Teräs  ---
Seems to be fixed in gcc 6.4.0. Likely duplicate of PR77455.

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

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

[timo.teras at iki dot fi]

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

--- Comment #6 from Timo Teräs  ---
*** Bug 71989 has been marked as a duplicate of this bug. ***

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[timo.teras at iki dot fi]

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

Timo Teräs  changed:

   What|Removed |Added

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

--- Comment #9 from Timo Teräs  ---
I can confirm this to be fixed in GCC 6.4.0. Likely duplicate of PR77455.

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

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

[timo.teras at iki dot fi]

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

Timo Teräs  changed:

   What|Removed |Added

 CC||timo.teras at iki dot fi

--- Comment #5 from Timo Teräs  ---
*** Bug 71951 has been marked as a duplicate of this bug. ***

[Bug go/81421] Circular runtime.s-gox -> runtime.lo dependency dropped -> objcopy: 'runtime.s-gox.tmp': No such file

[mfe at live dot de]

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

martin  changed:

   What|Removed |Added

 CC||mfe at live dot de

--- Comment #2 from martin  ---
Created attachment 41739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41739=edit
runtime.lo.dep

I'll added the requested file.

Re: sanitizer bug maybe.

[Jim Wilson]

On 07/10/2017 10:29 AM, George R Goffe via gcc-bugs wrote:

../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:
 In function ‘int __sanitizer::TracerThread(void*)’:
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:276:22:
 error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be 
defined
struct sigaltstack handler_stack;


If you are doing a build using glibc mainline, then this is FSF GCC bug 
81066.

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

Jim