[Bug middle-end/78995] A strange copy error caused by O3 optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-01-05
  Component|c++ |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Does adding -fno-strict-aliasing fix the problem you are seeing?

I am suspecting the code is violating C/C++ aliasing rules.

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Thu Jan  5 07:38:48 2017
New Revision: 244093

URL: https://gcc.gnu.org/viewcvs?rev=244093=gcc=rev
Log:
PR tree-optimizatin/78812
* rtl.h (contains_mem_rtx_p): Prototype.
* ifcvt.c (containts_mem_rtx_p): Move from here to...
* rtlanal.c (contains_mem_rtx_p): Here and remvoe static linkage.
* gcse.c (prune_expressions): Use contains_mem_rtx_p to discover
and prune MEMs that are not at the toplevel of a SET_SRC rtx.  Look
through ZERO_EXTEND and SIGN_EXTEND when trying to avoid pruning
MEMs.

PR tree-optimization/78812
* g++.dg/torture/pr78812.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78812.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c
trunk/gcc/ifcvt.c
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/79000] New: ICE: in gen_member_die, at dwarf2out.c:23995

[trippels at gcc dot gnu.org]

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

Bug ID: 79000
   Summary: ICE: in gen_member_die, at dwarf2out.c:23995
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: lto
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

A Gentoo users emailed me the following mixed C/C++ LTO testcase:

markus@x4 /tmp % cat 1.ii
struct a {
  a();
} b;

markus@x4 /tmp % cat 2.i
typedef struct a b;
typedef struct a {
} b;
struct {
  b c;
} d;

markus@x4 /tmp % gcc -g -flto -r -nostdlib 1.ii 2.i
lto1: internal compiler error: in gen_member_die, at dwarf2out.c:23995
0x6fa800 gen_member_die
/home/markus/gcc/gcc/dwarf2out.c:23995
0x6fa800 gen_struct_or_union_type_die
/home/markus/gcc/gcc/dwarf2out.c:24096
0x6fa800 gen_tagged_type_die
/home/markus/gcc/gcc/dwarf2out.c:24306
0x712040 gen_typedef_die
/home/markus/gcc/gcc/dwarf2out.c:24213
0x6f787a gen_decl_die
/home/markus/gcc/gcc/dwarf2out.c:25155
0x6f84ae dwarf2out_decl
/home/markus/gcc/gcc/dwarf2out.c:25636
0x6f887c dwarf2out_type_decl
/home/markus/gcc/gcc/dwarf2out.c:25344
0x5eaf33 lto_read_decls
/home/markus/gcc/gcc/lto/lto.c:1756
0x5ed8e3 lto_file_finalize
/home/markus/gcc/gcc/lto/lto.c:2038
0x5ed8e3 lto_create_files_from_ids
/home/markus/gcc/gcc/lto/lto.c:2048
0x5ed8e3 lto_file_read
/home/markus/gcc/gcc/lto/lto.c:2089
0x5ed8e3 read_cgraph_and_symbols
/home/markus/gcc/gcc/lto/lto.c:2799
0x5ed8e3 lto_main()
/home/markus/gcc/gcc/lto/lto.c:3304

Breakpoint 1, gen_member_die (context_die=, type=0x0) at
/home/markus/gcc/gcc/dwarf2out.c:23995
23995 gcc_assert (TYPE_MAIN_VARIANT (type) == type);
(gdb) p type
$1 = (tree) 0x0

All supported gcc versions are affected.

[Bug c++/78999] New: problem with gcc on cygwin??? cygwin 2.6.1 with gcc 5.4.0

[bplummer at hotmail dot com]

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

Bug ID: 78999
   Summary: problem with gcc on cygwin???  cygwin 2.6.1 with gcc
5.4.0
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bplummer at hotmail dot com
  Target Milestone: ---

I can't get to the bottom of this.  I'm thinking that there is an internal
problem with the compiler.  Mismatch between 32 and 64 bit?  Library problem? 
Unfortunately, as this is beyond my pay grade, I've gone as far as I can go.

The following is the first thing I did after a complete reinstall of Cygwin
2.6.1.  I encountered this as I was trying to configure and build gcc-6.2.0 but
note that the test that I display here has nothing to do with gcc-6.2.0.  And
while I'm compiling for std=c++11, I don't think it has anything to do with
this.

Brian@MBPWin7-64 /tmp/gcc-6.2.0/build
$ uname -a
CYGWIN_NT-6.1 MBPWin7-64 2.6.1(0.305/5/3) 2016-12-16 11:55 x86_64 Cygwin

Brian@MBPWin7-64 /tmp/gcc-6.2.0/build
$ gcc --version
gcc (GCC) 5.4.0
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.


Brian@MBPWin7-64 /tmp/gcc-6.2.0/build
$ cat test.cpp
//Program to test the new C++11 lambda syntax and initalizer lists
#include 
#include 

using namespace std;

int main()
{
  // Test lambda
  cout << [](int m, int n) { return m + n;} (2,4) << endl;

  // Test initializer lists and range based for loop
  vector
 V({1,2,3});

  cout << "V =" << endl;
  for(auto e : V) {
cout << e << endl;
  }

  return 0;
}


Brian@MBPWin7-64 /tmp/gcc-6.2.0/build
$ gcc -std=c++11 test.cpp -o test
Cygwin runtime failure: /usr/lib/gcc/x86_64-pc-cygwin/5.4.0/cc1plus.exe:
Invalid relocation.  Offset 0xfffea2b0d031 at address 0x547c41cbb doesn't
fit into 32 bits

[Bug middle-end/78914] missing -Wnonnull for a trivial null pointer dereference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
As it turns out, the test case in comment #0 is diagnosed when the
-Wnull-dereference option is explicitly specified.  Unfortunately,
-Wnull-dereference isn't enabled  by either -Wall or -Wextra and must be
enabled explicitly.  This seems to have been changed in r226751 prior to which
-Wnull-dereference was in -Wall.  The -Wnull-dereference option was added in
response to bug 16351 and enabled in -Wall, but based on the discussion in the
bug it looks like it led to some false positives and so it was subsequently
yanked out of -Wall.  So with that I think this bug can be closed as a
duplicate of bug 16351 (which is still open).

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

[Bug c/16351] NULL dereference warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #46 from Martin Sebor  ---
*** Bug 78914 has been marked as a duplicate of this bug. ***

[Bug middle-end/78998] missing -Wnonnull for an unconditional call to strlen with a null argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78917

--- Comment #1 from Martin Sebor  ---
See also bug 78917 for another false negative.

[Bug middle-end/78998] New: missing -Wnonnull for an unconditional call to strlen with a null argument

[msebor at gcc dot gnu.org]

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

Bug ID: 78998
   Summary: missing -Wnonnull for an unconditional call to strlen
with a null argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The newly enhanced -Wnonnull warning misses the following trivial null pointer
dereference by strlen:

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.c 
int f (int i)
{
  char *s = 0;
  switch (i) case 0: s = "";
  if (!i) s = 0;

  return __builtin_strlen (s);
}

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

f (int i)
{
  long unsigned int _1;
  int _6;

   [100.00%]:
  _1 = __builtin_strlen (0B);
  _6 = (int) _1;
  return _6;

}

[Bug libstdc++/78996] uses macro as name

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||timshen at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Tim Shen  ---
Mark as fixed.

[Bug libstdc++/78996] uses macro as name

[timshen at gcc dot gnu.org]

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

--- Comment #2 from Tim Shen  ---
Author: timshen
Date: Thu Jan  5 03:18:17 2017
New Revision: 244092

URL: https://gcc.gnu.org/viewcvs?rev=244092=gcc=rev
Log:
2017-01-05  Tim Shen  

PR libstdc++/78996
* include/std/variant (__gen_vtable_impl): rename __unused to
__dimensions to avoid naming conflict.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug c/78987] Wrong location of a binary expression for -Waddress

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Also confirmed, like bug 78988.  Should these two bugs be one and the same or
is the location information set separately by each front end?

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[egall at gwmail dot gwu.edu]

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

--- Comment #11 from Eric Gallager  ---
Thank you for adding this!

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (r244062).  Clang is happy with it.

[Bug c++/78988] Wrong location of a binary expression for -Waddress

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Confirmed.  The location doesn't look right in C either where GCC prints the
following:

b.c: In function ‘main2’:
b.c:7:7: warning: the address of ‘foo’ will always evaluate as ‘true’
[-Waddres]
   if (foo && bar && baz)
   ^~~
b.c:7:11: warning: the address of ‘bar’ will always evaluate as ‘true’
[-Waddress]
   if (foo && bar && baz)
   ^~
b.c:7:18: warning: the address of ‘baz’ will always evaluate as ‘true’
[-Waddress]
   if (foo && bar && baz)
  ^~

[Bug tree-optimization/78997] [7.0 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||msebor at gcc dot gnu.org
Summary|ICE on valid code at -O3 on |[7.0 regression] ICE on
   |x86_64-linux-gnu:   |valid code at -O3 on
   |verify_gimple failed|x86_64-linux-gnu:
   ||verify_gimple failed
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with bisection pointing to r242872:

2016-11-24  Richard Biener  

PR tree-optimization/78343
* passes.def: Add CD-DCE pass after loop splitting.
* tree-ssa-dce.c (find_obviously_necessary_stmts): Move
SCEV init/finalize ...
(perform_tree_ssa_dce): ... here.  Deal with being
executed inside the loop pipeline in aggressive mode.

* gcc.dg/tree-ssa/sccp-2.c: New testcase.
* gcc.dg/autopar/uns-outer-6.c: Adjust.
* gcc.dg/tree-ssa/20030808-1.c: Likewise.
* gcc.dg/tree-ssa/20040305-1.c: Likewise.
* gcc.dg/vect/pr38529.c: Likewise.

[Bug tree-optimization/78997] New: ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[su at cs dot ucdavis.edu]

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

Bug ID: 78997
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
verify_gimple failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.x.  The test is still about 2KB and has been
extremely tough to reduce. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20170104 (experimental) [trunk revision 244072] (GCC)
$
$ gcc-trunk -O2 small.c
$ gcc-6.2 -O3 small.c
$
$ gcc-trunk -O3 small.c
small.c: In function ‘foo’:
small.c:7:6: error: the first argument of a VEC_COND_EXPR must be of a boolean
vector type of the same number of elements as the result
 void foo ()
  ^~~
vector(8) short int
vector(16) unsigned char
vect__ifc__822.147_690 = VEC_COND_EXPR <vect_cst__692, vect_cst__691,
vect__ifc__824.146_710>;
small.c:7:6: internal compiler error: verify_gimple failed
0xc4f6cf verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5266
0xb2d552 execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1965
0xb2df09 execute_todo
../../gcc-source-trunk/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


-


int printf (const char *, ...);

static short f, p, q, s, u, aa, ab, ac;
static int b, c, d, e, h, k, l, m, n, o, r, t, v, w, x, y, z, ad, ae, af, ag,
ah, ai, aj, ak, al, am, an;
int a, ao, ap, aq, ar, g, as, at, au, av, aw, ax, ay;

void foo ()
{ 
  int ba[2], i, j, bb;
  while (b)
{ 
  b++;
  while (b)
{ 
  for (; aw; aw++)
for (; q; q++)
  { 
short bc[20];
if (k)
  for (i = 0; i < 4; i++)
for (j = 0; j < 4; j++)
  if (p)
bc[i * 4 + j] = 8;
for (; ad; ad--)
  t = bc[1];
  }
  for (bb = 0; bb < 5; bb++)
if (m && v)
  { 
printf ("%d", n);
v = g && v;
n = 0;
  }
  ab &= ba[0];
  aw = l;
  aa++;
  x++;
  while (1)
{ 
  int bd[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1};
  ap = a ? ba[1] : 0;
  if (ba[0] && o < ax)
{ 
  int be[] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1};
  for (; ae; ae++)
{ 
  e ^= ba[b] ^ aa;
  f = r;
  for (; y; y++)
aj &= u | ag;
  int e[] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1};
  if (a)
{ 
  r = c;
  aj &= ag |= aq;
}
  av = ai * u;
  af = c;
}
  au = d;
  p++;
  u = aj;
  a = ba[1];
  at = ar = af != ai && l;
  as = ax = f;
  ao = ak ? 0 : ah;
  aw = ao;
}
  ay = c;
  int bf[] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1};
  if (w < f)
{ 
  int bg[] = {0};
  if (aw)
break;
}
  else
aw = aa | (h &= ag) >> d, c = b = z && am;
  for (; w; w--)
l = ac ^= al |= b;
  for (; k; k = 0)
{ 
  int bh = m | s && n;
  m = bh;
  for (; t; t--)
f = q ^= (c < (e < ah));
}
  d = an |= b;
  if (v)
{ 
  int bi[] =
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1};
  if (aw)
break;
}
}
}
}
}

int main ()
{ 
  foo ();
  return 0;
}

[Bug libstdc++/78996] uses macro as name

[webrown.cpp at gmail dot com]

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

--- Comment #1 from W E Brown  ---
Created attachment 40465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40465=edit
Preprocessed source

[Bug libstdc++/78996] New: uses macro as name

[webrown.cpp at gmail dot com]

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

Bug ID: 78996
   Summary:  uses macro as name
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

Upon upgrading to g++-mp-7 (MacPorts gcc7 7-20170101_0) 7.0.0 20170101
(experimental) and compiling with significant options -std=c++1z -fconcepts, I
find a previously-unseen conflict.

At line 607, header  employs the identifier __unused as the name of a
template parameter pack.

Unfortunately, before #including , my test program has already
#included , which on my system contains the line:

  #define __unused  __attribute__((unused))

This seems the source of the conflict that now produces diagnostics from the
unchanged test program that last month compiled cleanly.

Preprocessed source is attached.  Thank you.

[Bug c++/78995] New: A strange copy error caused by O3 optimization

[zhangfei1 at cffex dot com.cn]

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

Bug ID: 78995
   Summary: A strange copy error caused by O3 optimization
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangfei1 at cffex dot com.cn
  Target Milestone: ---

Created attachment 40464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40464=edit
A demon to reproduce this bug

I come across a strange error while using the rte_memcpy function under gcc O3
optimization these days. 

A demon codes are as attachment. The problems are detailed as following,

What I want to do is just to copy 4 Bytes from a buffer to another struct
variable, as the 'key codes' and 'copy function' shown in the tail.
But the source 4 Bytes is 0x11223344, while the copied 4 Bytes is 0x22110040.
What happens?

I have done more test, and the results are as following,

1)  O0 optimization has no error, while O2 and O3 optimization has problem.
2) If I replace the copy function from rte_memcpy to memcpy, there will be no
error.
3) If I directly call the 'GetHeader function' in the constructor function,
there will be no error.
4) If I comment out the change endian codes, there will be no error.
5) If I replace the 'break' by 'return' in 'next function', there will be no
error.


I have done the test in gcc4.4.6 (Redhat6.3-x86_64),  gcc 4.8.5
(Redhat7.2-x86_64), and  gcc 5.2.1 (ubuntu15.10_x86_64). All of them have these
problems. 

To run the demon:
1) just run the ./make.sh will be ok. This will compile the codes, and generate
the target file a.out.



Would anyone give some help to me? 

Very thanks for your help.



/* ***  key codes */
//memcpy(_fieldHeader, m_pCurr, 4);
rte_memcpy(_fieldHeader, m_pCurr, 4);
m_fieldHeader.FieldID = ((m_fieldHeader.FieldID&0x00ff)<<8)|
((m_fieldHeader.FieldID&0xff00)>>8);
m_fieldHeader.Size =((m_fieldHeader.Size&0x00ff)<<8)|
((m_fieldHeader.Size&0xff00)>>8);

char *p = m_pCurr;
fprintf(stdout, "src: 0x%02x%02x%02x%02x\n", *p,*(p+1),*(p+2),*(p+3));

p = (char*)(_fieldHeader);
fprintf(stdout, "dst: 0x%02x%02x%02x%02x\n", *p,*(p+1),*(p+2),*(p+3));

fflush(stdout);

/*  copy function ***/
rte_memcpy(void *dst, const void *src, size_t n)
{
uintptr_t dstu = (uintptr_t)dst;
uintptr_t srcu = (uintptr_t)src;

*(uint32_t *)dstu = *(const uint32_t *)srcu;
}

[Bug target/78823] Poor code on PowerPC when moving SFmode values between GPRs and vector registers

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Thu Jan  5 00:43:53 2017
New Revision: 244084

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

PR target/71977
PR target/70568
PR target/78823
* config/rs6000/predicates.md (sf_subreg_operand): New predicate.
(altivec_register_operand): Do not return true if the operand
contains a SUBREG mixing SImode and SFmode.
(vsx_register_operand): Likewise.
(vsx_reg_sfsubreg_ok): New predicate.
(vfloat_operand): Do not return true if the operand contains a
SUBREG mixing SImode and SFmode.
(vint_operand): Likewise.
(vlogical_operand): Likewise.
(gpc_reg_operand): Likewise.
(int_reg_operand): Likewise.
* config/rs6000/rs6000-protos.h (valid_sf_si_move): Add
declaration.
* config/rs6000/rs6000.c (valid_sf_si_move): New function to
determine if a MOVSI or MOVSF operation contains SUBREGs that mix
SImode and SFmode.
(rs6000_emit_move_si_sf_subreg): New helper function.
(rs6000_emit_move): Call rs6000_emit_move_si_sf_subreg to possbily
fixup SUBREGs involving SImode and SFmode.
* config/rs6000/vsx.md (SFBOOL_*): New constants that are operand
numbers for the new peephole2 optimization.
(peephole2 for SFmode unions): New peephole2 to optimize cases in
the GLIBC math library that do AND/IOR/XOR operations on single
precision floating point.
* config/rs6000/rs6000.h (TARGET_NO_SF_SUBREG): New internal
target macros to say whether we need to avoid SUBREGs mixing
SImode and SFmode.
(TARGET_ALLOW_SF_SUBREG): Likewise.
* config/rs6000/rs6000.md (UNSPEC_SF_FROM_SI): New unspecs.
(UNSPEC_SI_FROM_SF): Likewise.
(iorxor): Change spacing.
(and_ior_xor): New iterator for AND, IOR, and XOR.
(movsi_from_sf): New insns for SImode/SFmode SUBREG support.
(movdi_from_sf_zero_ext): Likewise.
(mov_hardfloat, FMOVE32 iterator): Use register_operand
instead of gpc_reg_operand.  Add SImode/SFmode SUBREG support.
(movsf_from_si): New insn for SImode/SFmode SUBREG support.
(fma4): Use gpc_reg_operand instead of register_operand.
(fms4): Likewise.
(fnma4): Likewise.
(fnms4): Likewise.
(nfma4): Likewise.
(nfms4): Likewise.

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

PR target/71977
PR target/70568
PR target/78823
* gcc.target/powerpc/pr71977-1.c: New tests to check whether on
64-bit VSX systems with direct move, whether we optimize common
code sequences in the GLIBC math library for float math functions.
* gcc.target/powerpc/pr71977-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/70568] [5/6/7 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  ---
Author: meissner
Date: Thu Jan  5 00:43:53 2017
New Revision: 244084

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

PR target/71977
PR target/70568
PR target/78823
* config/rs6000/predicates.md (sf_subreg_operand): New predicate.
(altivec_register_operand): Do not return true if the operand
contains a SUBREG mixing SImode and SFmode.
(vsx_register_operand): Likewise.
(vsx_reg_sfsubreg_ok): New predicate.
(vfloat_operand): Do not return true if the operand contains a
SUBREG mixing SImode and SFmode.
(vint_operand): Likewise.
(vlogical_operand): Likewise.
(gpc_reg_operand): Likewise.
(int_reg_operand): Likewise.
* config/rs6000/rs6000-protos.h (valid_sf_si_move): Add
declaration.
* config/rs6000/rs6000.c (valid_sf_si_move): New function to
determine if a MOVSI or MOVSF operation contains SUBREGs that mix
SImode and SFmode.
(rs6000_emit_move_si_sf_subreg): New helper function.
(rs6000_emit_move): Call rs6000_emit_move_si_sf_subreg to possbily
fixup SUBREGs involving SImode and SFmode.
* config/rs6000/vsx.md (SFBOOL_*): New constants that are operand
numbers for the new peephole2 optimization.
(peephole2 for SFmode unions): New peephole2 to optimize cases in
the GLIBC math library that do AND/IOR/XOR operations on single
precision floating point.
* config/rs6000/rs6000.h (TARGET_NO_SF_SUBREG): New internal
target macros to say whether we need to avoid SUBREGs mixing
SImode and SFmode.
(TARGET_ALLOW_SF_SUBREG): Likewise.
* config/rs6000/rs6000.md (UNSPEC_SF_FROM_SI): New unspecs.
(UNSPEC_SI_FROM_SF): Likewise.
(iorxor): Change spacing.
(and_ior_xor): New iterator for AND, IOR, and XOR.
(movsi_from_sf): New insns for SImode/SFmode SUBREG support.
(movdi_from_sf_zero_ext): Likewise.
(mov_hardfloat, FMOVE32 iterator): Use register_operand
instead of gpc_reg_operand.  Add SImode/SFmode SUBREG support.
(movsf_from_si): New insn for SImode/SFmode SUBREG support.
(fma4): Use gpc_reg_operand instead of register_operand.
(fms4): Likewise.
(fnma4): Likewise.
(fnms4): Likewise.
(nfma4): Likewise.
(nfms4): Likewise.

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

PR target/71977
PR target/70568
PR target/78823
* gcc.target/powerpc/pr71977-1.c: New tests to check whether on
64-bit VSX systems with direct move, whether we optimize common
code sequences in the GLIBC math library for float math functions.
* gcc.target/powerpc/pr71977-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/71977] powerpc64: Use VSR when operating on float and integer

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Thu Jan  5 00:43:53 2017
New Revision: 244084

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

PR target/71977
PR target/70568
PR target/78823
* config/rs6000/predicates.md (sf_subreg_operand): New predicate.
(altivec_register_operand): Do not return true if the operand
contains a SUBREG mixing SImode and SFmode.
(vsx_register_operand): Likewise.
(vsx_reg_sfsubreg_ok): New predicate.
(vfloat_operand): Do not return true if the operand contains a
SUBREG mixing SImode and SFmode.
(vint_operand): Likewise.
(vlogical_operand): Likewise.
(gpc_reg_operand): Likewise.
(int_reg_operand): Likewise.
* config/rs6000/rs6000-protos.h (valid_sf_si_move): Add
declaration.
* config/rs6000/rs6000.c (valid_sf_si_move): New function to
determine if a MOVSI or MOVSF operation contains SUBREGs that mix
SImode and SFmode.
(rs6000_emit_move_si_sf_subreg): New helper function.
(rs6000_emit_move): Call rs6000_emit_move_si_sf_subreg to possbily
fixup SUBREGs involving SImode and SFmode.
* config/rs6000/vsx.md (SFBOOL_*): New constants that are operand
numbers for the new peephole2 optimization.
(peephole2 for SFmode unions): New peephole2 to optimize cases in
the GLIBC math library that do AND/IOR/XOR operations on single
precision floating point.
* config/rs6000/rs6000.h (TARGET_NO_SF_SUBREG): New internal
target macros to say whether we need to avoid SUBREGs mixing
SImode and SFmode.
(TARGET_ALLOW_SF_SUBREG): Likewise.
* config/rs6000/rs6000.md (UNSPEC_SF_FROM_SI): New unspecs.
(UNSPEC_SI_FROM_SF): Likewise.
(iorxor): Change spacing.
(and_ior_xor): New iterator for AND, IOR, and XOR.
(movsi_from_sf): New insns for SImode/SFmode SUBREG support.
(movdi_from_sf_zero_ext): Likewise.
(mov_hardfloat, FMOVE32 iterator): Use register_operand
instead of gpc_reg_operand.  Add SImode/SFmode SUBREG support.
(movsf_from_si): New insn for SImode/SFmode SUBREG support.
(fma4): Use gpc_reg_operand instead of register_operand.
(fms4): Likewise.
(fnma4): Likewise.
(fnms4): Likewise.
(nfma4): Likewise.
(nfms4): Likewise.

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

PR target/71977
PR target/70568
PR target/78823
* gcc.target/powerpc/pr71977-1.c: New tests to check whether on
64-bit VSX systems with direct move, whether we optimize common
code sequences in the GLIBC math library for float math functions.
* gcc.target/powerpc/pr71977-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr71977-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[bruno at clisp dot org]

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

bruno at clisp dot org changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #14 from bruno at clisp dot org ---
I'm seeing this also, with gcc 4.9.0. Configured on x86_64 Linux with
../gcc-4.9.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--enable-shared --enable-version-specific-runtime-libs --enable-nls
--enable-threads=posix --enable-__cxa_atexit
--with-as=/arch/x86_64-linux-gnu/gnu/bin/as
--with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-libelf=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-cloog=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0
--with-ecj-jar=/downloads/sourceware.org-ecj/ecj-latest.jar

The build with --enable-version-specific-runtime-libs fails to find libgcc_s
when linking programs. The build without this option works fine.

Analyzing the difference:

* Location of installed libraries other than libgcc_s:
Most 32-bit libraries get installed in
  - PREFIX/lib32 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32 for the build with
--enable-version-specific-runtime-libs.
Most 64-bit libraries get installed in
  - PREFIX/lib64 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0 for the build with
--enable-version-specific-runtime-libs.

* Location of installed libgcc_s (.so symlink and .so.1):
32-bit libgcc_s gets installed in
  - PREFIX/lib32 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32 for the build with
--enable-version-specific-runtime-libs.
64-bit libgcc_s gets installed in
  - PREFIX/lib64 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64 for the build with
--enable-version-specific-runtime-libs.

* The library path (set of -L options) that collect2 passes to ld, however, is
the same in both cases (without and with
--enable-version-specific-runtime-libs). Namely:

When creating 32-bit binaries:
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib32
/lib/i386-linux-gnu
/lib/../lib32
/usr/lib/i386-linux-gnu
/usr/lib/../lib32
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0
PREFIX/lib/gcc
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../..
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu

When creating 64-bit binaries:
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0
PREFIX/lib/gcc
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib64
/lib/x86_64-linux-gnu
/lib/../lib64
/usr/lib/x86_64-linux-gnu
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../..

This library path contains the location of all installed libraries except
libgcc_s.

Conclusion:

So it looks really like a bug in the installation rules for libgcc_s.
- The 32-bit libgcc_s ought to be installed in
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32, not
PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32.
- The 64-bit libgcc_s ought to be installed in
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0, not
PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64.

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
  # i_5 = PHI 
  # j_27 = PHI 
  # prephitmp_7 = PHI <0(3), prephitmp_17(4)>
  _14 = i_5 > 9;
  _18 = prephitmp_7 | _14;
  if (_18 != 0)
goto ; [44.99%]
  else
goto ; [55.01%]


Most likely conditional warning does not understand the above case :).

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||4.1.0, 5.3.0, 6.2.0, 7.0

--- Comment #3 from Martin Sebor  ---
The test case doesn't fail with -O2 prior to r193157 but it does fail with -O3
all the way back to r104500 so it doesn't appear to be a recent regression.

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  The following is a somewhat simplified test case.

$ cat t.c && gcc -O2 -S -Wall t.c
extern int rand ();

const char* foo (int i, int *p)
{
  int j = rand ();

  if (i >= j)
return "";

  *p = j;
  return 0;
}

int bar (int i)
{
  if (i < 0)
i = rand ();
  return i < 10;
}

int foobar (int i)
{
  int j;
  const char *p = foo (i, );

  if (bar (i))
{
  if (p)
return 0;
}
  else
return 0;

  return j;
}
t.c: In function ‘foobar’:
t.c:23:7: warning: ‘j’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   int j;
   ^

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
So I  see a case in postreload-gcse.c where we might mis-handle when the
destination is a ZERO_EXTRACT or STRICT_LOW_PART.  Neither happen often which
is probably why we've never noticed.

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

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
Hey, that works for me too! (62565 vs 70758 in favour of -Ofast). Usefully
strange :)

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
I'm mostly concerned about other places where we assume that a memory reference
is supposed to show up at the toplevel of a source/dest.

For example, it looks like we don't properly handle the case where we have a
REG_EQUAL note of the form (any_extend (mem (...)).

THankfully, most of gcse.c will DTRT with such an rtx and the cases for
REG_EQUAL notes don't appear to be correctness issues.  The only correctness
issue so far is prune_expressions.

I need to look at postreload-gcse.c as well.

All those cases will need to use a helper of some sort to look inside the rtx. 
The mechanics of that (such as using contains_mem_rtx_p) aren't terribly
concerning/interesting at this stage.

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #10)
> Since that's not a MEM_P, the expression isn't removed from antic/transp
> which makes it subject to hoisting across the abnormal edge.
> 
> This could be easily fixed by walking into the ZERO/SIGN_EXTEND rtx, but
> there may be other places where an embedded MEM might appear (hell, on a
> cisc machine it would be just about anywhere).  So I want to do a bit of
> auditing of gcse.c.

Can't you just use contains_mem_rtx_p (move it from ifcvt.c to rtlanal.c and
export)?

[Bug c/78989] Missing -Waddress warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||77513

--- Comment #6 from Andrew Pinski  ---
I suspect PR 77513 can be considered the dup.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513
[Bug 77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[Bug c/78989] Missing -Waddress warning

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Isn't there a dup somewhere?  I Know this was filed before.

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
So EDGE_EH implies EDGE_ABNORMAL, so the patch in c#8 isn't going to have any
impact.  The real bug is more subtle.

prune_expressions walks the expression table looking for expressions that occur
in blocks with abnormal edges.  We then remove those expressions from
antic/transp.

The bug is it uses MEM_P.  Which is (of course) false if the given RTX has an
embedded MEM.  A good example would be:

(zero_extend:DI (mem/c:QI (plus:DI (reg/f:DI 34 %fp)
(const_int -1 [0x])) [2 T.a+0 S1 A8]))

Since that's not a MEM_P, the expression isn't removed from antic/transp which
makes it subject to hoisting across the abnormal edge.

This could be easily fixed by walking into the ZERO/SIGN_EXTEND rtx, but there
may be other places where an embedded MEM might appear (hell, on a cisc machine
it would be just about anywhere).  So I want to do a bit of auditing of gcse.c.

[Bug c++/60685] exception not caught by enclosing catch

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
This is indeed fixed in the current releases.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|-Ofast makes aarch64 C++|-Ofast makes aarch64 C++
   |benchmark slower|benchmark slower for A53

--- Comment #2 from Andrew Pinski  ---
For me on ThunderX, -Ofast is faster:
apinski@apinski-ss1:~/src/tests1$ g++ main.ii -Ofast -std=c++14 -mcpu=thunderx
apinski@apinski-ss1:~/src/tests1$ ./a.out
DSP Bench C++
Biquad coefficients:
b0=1.0045897513638202,
b1=-1.9900946111700766,
b2=0.98618704929508227,
a1=-1.9900946111700766,
a2=0.99077680065890239,
iir:62008 ns per loop
iir_2:  62008 ns per loop
apinski@apinski-ss1:~/src/tests1$ g++ main.ii -O3 -std=c++14 -mcpu=thunderx
apinski@apinski-ss1:~/src/tests1$ ./a.out
DSP Bench C++
Biquad coefficients:
b0=1.0045897513638202,
b1=-1.9900946111700766,
b2=0.98618704929508227,
a1=-1.9900946111700766,
a2=0.99077680065890239,
iir:80256 ns per loop
iir_2:  80256 ns per loop
apinski@apinski-ss1:~/src/tests1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
5.4.0-6ubuntu1~16.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.1)


On the trunk:
apinski@apinski-ss1:~/src/tests1$ ~/src/local/tools/bin/g++  main.ii -O3
-std=c++14 -mcpu=thunderx
apinski@apinski-ss1:~/src/tests1$ ./a.out
DSP Bench C++
Biquad coefficients:
b0=1.0045897513638202,
b1=-1.9900946111700766,
b2=0.98618704929508227,
a1=-1.9900946111700766,
a2=0.99077680065890239,
iir:80630 ns per loop
iir_2:  80629 ns per loop
apinski@apinski-ss1:~/src/tests1$ ~/src/local/tools/bin/g++  main.ii -Ofast
-std=c++14 -mcpu=thunderx
apinski@apinski-ss1:~/src/tests1$ ./a.out
DSP Bench C++
Biquad coefficients:
b0=1.0045897513638202,
b1=-1.9900946111700766,
b2=0.98618704929508227,
a1=-1.9900946111700766,
a2=0.99077680065890239,
iir:62108 ns per loop
iir_2:  62118 ns per loop
apinski@apinski-ss1:~/src/tests1$ ~/src/local/tools/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/apinski/src/local/tools/bin/g++
COLLECT_LTO_WRAPPER=/data/src/local/tools/bin/../libexec/gcc/aarch64-unknown-linux-gnu/7.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure
--prefix=/home/apinski/src/local/objdir/../tools
--enable-languages=c,c++,fortran,go --disable-werror --with-sysroot=/
--enable-plugins --enable-gnu-indirect-function --with-pkgversion='My build'
Thread model: posix
gcc version 7.0.0 20161110 (experimental) [trunk revision 242061] (My build)

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://github.com/supercur |
   |io/dsp-bench-cpp|
  Component|middle-end  |target

--- Comment #1 from Andrew Pinski  ---
https://github.com/supercurio/dsp-bench-cpp

[Bug middle-end/78994] New: -Ofast makes aarch64 C++ benchmark slower

[tulipawn at gmail dot com]

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

Bug ID: 78994
   Summary: -Ofast makes aarch64 C++ benchmark slower
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Created attachment 40463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40463=edit
Preprocessed source + assembly files

After make && ./build/dsp-bench, the results look as follows

@ -O3 -mcpu=cortex-a53 -ftree-vectorize

iir:67945 ns per loop
iir_2:  67952 ns per loop

@ -Ofast -mcpu=cortex-a53 -ftree-vectorize

iir:73367 ns per loop
iir_2:  73349 ns per loop

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

[daiw at gmx dot net]

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

Tobias  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias  ---
resolved as invalid. now posted here:
https://llvm.org/bugs/show_bug.cgi?id=31537

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

[daiw at gmx dot net]

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

--- Comment #2 from Tobias  ---
Thanks. The evidence you collected shows quite clear, that it probably is a
problem with clang.
So I now posted it here: https://llvm.org/bugs/show_bug.cgi?id=31537

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Done for GCC 7.

[Bug c++/64767] Could GCC warn when a pointer is compared against '\0'?

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  4 21:47:04 2017
New Revision: 244076

URL: https://gcc.gnu.org/viewcvs?rev=244076=gcc=rev
Log:
PR c++/64767
* c.opt (Wpointer-compare): New option.

* c-parser.c (c_parser_postfix_expression): Mark zero character
constants by setting original_type in c_expr.
* c-typeck.c (parser_build_binary_op): Warn when a pointer is compared
with a zero character constant.
(char_type_p): New function.

* typeck.c (cp_build_binary_op): Warn when a pointer is compared with
a zero character literal.

* doc/invoke.texi: Document -Wpointer-compare.

* c-c++-common/Wpointer-compare-1.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wpointer-compare-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/78910] Wrong print-return-value for a negative number

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
How positive you are that this is a libstdc++ bug rather than a clang bug?  It
works correctly with GCC 5.4.0's front-end and GCC 7.0's libstdc++ and
front-end.

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Created attachment 40462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40462=edit
Gimple dump from when warning is emitted

[Bug c++/78949] incorrect "unused variable" warning with SSE2

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] Bogus  |[6 Regression] Bogus
   |'inconsistent deduction for |'inconsistent deduction for
   |‘auto’' error when having a |‘auto’' error when having a
   |dependent initializer and a |dependent initializer and a
   |nondependent one in the |nondependent one in the
   |same declaration|same declaration

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.  Will file a new PR for the still present
accepts-invalid in templates.

[Bug middle-end/78993] New: False positive from -Wmaybe-uninitialized

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 78993
   Summary: False positive from -Wmaybe-uninitialized
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40461=edit
Reproducer, based on input.c

As noted in the thread at:
  https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00049.html
there's a false positive at -O3 from -Wmaybe-uninitialized in gcc's input.c

I'm attaching a minimized reproducer.

$ g++ (GCC) 7.0.0 20161221 (experimental)
$ g++ -c input.cc -O3 -Wall
input.cc: In function ‘void assert_char_at_range(location_t, int, int, int,
int)’:
input.cc:85:56: warning: ‘*((void*)& actual_range +4)’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
 loc = get_location_from_adhoc_loc (line_table, loc);
^
input.cc:96:16: note: ‘*((void*)& actual_range +4)’ was declared here
   source_range actual_range;
^~~~
input.cc:85:56: warning: ‘actual_range’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 loc = get_location_from_adhoc_loc (line_table, loc);
^
input.cc:96:16: note: ‘actual_range’ was declared here
   source_range actual_range;
^~~~

This appears to be a false positive: to access fields of actual_range,
execution needs to get past:

  const char *err = get_source_range_for_char (idx, _range);
  if (should_have_column_data_p (strloc))
{
  if (err)
fail ();
}
  else
return;

  *access happens here*

Given that fail is no-return, the only way to reach the access is for "err" to
be NULL.

Looking at a gimple dump, get_source_range_for_char has been inlined.
This can only return NULL if actual_range is written to, but presumably during
optimization we somehow lose track of this invariant
(or I'm misreading the code...)

Also, the location for the warning is odd: it's reported as within
assert_char_at_range, but the location given is within
should_have_column_data_p.

[Bug c++/78949] incorrect "unused variable" warning with SSE2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  4 21:34:27 2017
New Revision: 244075

URL: https://gcc.gnu.org/viewcvs?rev=244075=gcc=rev
Log:
PR c++/78949
* typeck.c (cp_build_unary_op): Call mark_rvalue_use on arg if it has
vector type.

* c-c++-common/Wunused-var-16.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wunused-var-16.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  4 21:30:35 2017
New Revision: 244074

URL: https://gcc.gnu.org/viewcvs?rev=244074=gcc=rev
Log:
PR c++/78693
* parser.c (cp_parser_simple_declaration): Only complain about
inconsistent auto deduction if auto_result doesn't use auto.

* g++.dg/cpp0x/pr78693.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78693.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78992] New: Incorrect sigaction definition on 32-bit sparc

[jrtc27 at jrtc27 dot com]

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

Bug ID: 78992
   Summary: Incorrect sigaction definition on 32-bit sparc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrtc27 at jrtc27 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: ---

Created attachment 40460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40460=edit
Patch forwarded upstream

The attached patch is needed to fix the sanitizer build on 32-bit sparc.
Forwarded upstream to https://reviews.llvm.org/D28309.

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[pthaugen at gcc dot gnu.org]

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

--- Comment #10 from Pat Haugen  ---
(In reply to Jakub Jelinek from comment #9)
> Any progress on this?

Besides waiting for pr77536 to be fixed, I'm not sure what specifically can be
done on this issue to fix the problem. I personally have not done anything wrt
to trying to fix the vectorizer frequencies since I'm unfamiliar with the
middle-end.

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

[daiw at gmx dot net]

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

Bug ID: 78991
   Summary: std::sort and std::unique can not use std::function
with clang++ -std=c++14
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daiw at gmx dot net
  Target Milestone: ---

The following two minimal examples both compile with

clang++ -std=c++11 main.cpp

but do not with

clang++ -std=c++14 main.cpp


// example 1
#include 
#include 
#include 
int main()
{
  std::vector xs = {0,1,2};
  std::function cmp = [](int x, int y)
{ return x < y; };
  std::sort(std::begin(xs), std::end(xs), cmp);
}


// example 2
#include 
#include 
#include 
int main()
{
  std::vector xs = {0,1,2};
  std::function p = [](int x, int y)
{ return x == y; };
  std::unique(std::begin(xs), std::end(xs), p);
}


The error message looks like this:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/algorithm:61:
In file included from
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/stl_algobase.h:71:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/predefined_ops.h:123:31:
error: indirection requires pointer operand ('int' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }


The used version is the default one from the package manager in Ubuntu 16.04:
clang++ --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[Bug driver/78957] ICE: SIGSEGV with -fno-sso-struct=web

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug driver/78957] ICE: SIGSEGV with -fno-sso-struct=web

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  4 20:25:13 2017
New Revision: 244072

URL: https://gcc.gnu.org/viewcvs?rev=244072=gcc=rev
Log:
PR driver/78957
* c.opt (fsso-struct=): Add RejectNegative.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr78957.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/testsuite/ChangeLog

[Bug c++/71182] [6 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] parser.c   |[6 Regression] parser.c
   |cp_lexer_previous_token |cp_lexer_previous_token
   |sanitizer detects member|sanitizer detects member
   |call on null pointer|call on null pointer

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  4 20:05:14 2017
New Revision: 244070

URL: https://gcc.gnu.org/viewcvs?rev=244070=gcc=rev
Log:
PR c++/71182
* parser.c (cp_lexer_previous_token): Use vec_safe_address in the
assertion, as lexer->buffer may be NULL.

* g++.dg/cpp0x/pr71182.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr71182.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78953] Errors in compiling Spec 2006 for power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 244044.

[Bug target/78900] ICE in gcc.target/powerpc/signbit-3.c

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Fixed in trunk in subversion id 244044.  I will hold the bug open until it is
checked into the GCC 6 branch.

[Bug target/78056] [7 Regression] build failure on Power7

[kelvin at gcc dot gnu.org]

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

--- Comment #20 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Jan  4 20:03:00 2017
New Revision: 244068

URL: https://gcc.gnu.org/viewcvs?rev=244068=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-01-04  Kelvin Nilsen  

PR target/78056
* gcc.target/powerpc/pr78056-1.c: New test.
* gcc.target/powerpc/pr78056-2.c: New test.
* gcc.target/powerpc/pr78056-3.c: New test.
* gcc.target/powerpc/pr78056-4.c: New test.
* gcc.target/powerpc/pr78056-5.c: New test.
* gcc.target/powerpc/pr78056-6.c: New test.
* gcc.target/powerpc/pr78056-7.c: New test.
* gcc.target/powerpc/pr78056-8.c: New test.
* lib/target-supports.exp
(check_effective_target_powerpc_popcntb_ok): New procedure to test
whether the effective target supports the popcntb instruction.

gcc/ChangeLog:

2017-01-04  Kelvin Nilsen  

PR target/78056
* doc/sourcebuild.texi (PowerPC-specific attributes): Add
documentation of the powerpc_popcntb_ok attribute.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
code to issue warning messages if a requested CPU configuration is
not supported by the binary (assembler and loader) toolchain.
(spe_init_builtins): Add two assertions to prevent ICE if attempt is
made to define a built-in function that has been disabled.
(paired_init_builtins): Add assertion to prevent ICE if attempt is
made to define a built-in function that has been disabled.
(altivec_init_builtins): Add comment explaining why definition
of the DST built-in functions is not preceded by an assertion
check.  Add assertions to prevent ICE if attempts are made to
define an altivec predicate or an abs* built-in function that has
been disabled.
(htm_init_builtins): Add comment explaining why definition of the
htm built-in functions is not preceded by an assertion check.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-3.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-5.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-6.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-7.c
trunk/gcc/testsuite/gcc.target/powerpc/pr78056-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c/78989] Missing -Waddress warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
...or to use a rich location to send two locations for the warning, giving:

return (asan_poison_variables &&  
  ^~
# 6 "gimplify.cpp" 3 4
  __null
  ~~
  );

and for the logic that uses diagnostic_report_warnings_p to check all locations
in the rich location, requiring all to be within a system header for the
warning to be rejected.

[Bug c/78989] Missing -Waddress warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Looking at the PRs you filed about the locations (PR78987 and PR78988), perhaps
the best approach here is for the location of the warning to be either this:

return (asan_poison_variables &&  
~~^~
# 6 "gimplify.cpp" 3 4
  __null
  ~~
  );

or this:

return (asan_poison_variables &&  

# 6 "gimplify.cpp" 3 4
  __null
  ^~
  );

i.e. for the location to be a range starting at the LHS start, finishing at the
RHS finish, with the caret at either the && or the RHS...

...and then for in_system_header_at to only reject the warning if *all* of the
range of the location is fully within a system header, rather than just
partially within a header?

[Bug tree-optimization/67955] tree-dse does not use pointer info

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan  4 19:22:44 2017
New Revision: 244067

URL: https://gcc.gnu.org/viewcvs?rev=244067=gcc=rev
Log:
PR tree-optimizatin/67955
* tree-ssa-alias.c (same_addr_size_stores_p): Check offsets first.
Allow any SSA_VAR_P as the base objects.  Use integer_zerop.  Verify
the points-to solution does not include pt_null.  Use DECL_PT_UID
unconditionally.

PR tree-optimization/67955
* gcc.dg/tree-ssa/ssa-dse-28.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-28.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c

[Bug c/44677] Warn for variables incremented but not used

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #6)
> I haven't thought through the implementation challenges but defining the
> extended -Wunused-but-set-variabl rule that's being suggested here seems
> straightforward: every write to an object must be followed by another access
> to it (either read or write).  If not, it's diagnosed.

That is not straightforward at all.  The FE doesn't have IL on which it can
analyze write accesses being followed by something (no cfg, no SSA form), and
in the middle end it is way too late for such a warning (because as soon as you
optimize away something, you could optimize away those reads and warning just
because the optimizers managed to optimize away some use are not really
helpful).

[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux

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

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

--- Comment #8 from Andreas Schwab  ---
The binutils testsuite depends on it.

[Bug c/44677] Warn for variables incremented but not used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
I haven't thought through the implementation challenges but defining the
extended -Wunused-but-set-variabl rule that's being suggested here seems
straightforward: every write to an object must be followed by another access to
it (either read or write).  If not, it's diagnosed.

This seems analogous to the -Wuninitialized checker/rule that might be stated
as: the first read of an object must be preceded by a write to it.

[Bug fortran/78990] New: ICE when assigning polymorphic array function result

[cmacmackin at gmail dot com]

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

Bug ID: 78990
   Summary: ICE when assigning polymorphic array function result
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cmacmackin at gmail dot com
  Target Milestone: ---

Created attachment 40459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40459=edit
Minimal reproducer

When a function returns a polymorphic array which is to be assigned to a local
array (via defined assignment), gfortran experiences a segfault. I've attached
a minimal example, which produces an ICE in gfortran 6.2.0 and 5.4.1 (both from
the Ubuntu 16.04 repos, the former from the ubuntu-toolchain-r/test PPA). The
error message is as follows:

minimal.f90:36:0:

   v3 = return_t1(v1)

internal compiler error: Segmentation fault
0xa71b9f crash_signal
../../src/gcc/toplev.c:333
0x696d84 gfc_conv_array_stride(tree_node*, int)
../../src/gcc/fortran/trans-array.c:2776
0x696d84 gfc_trans_preloop_setup
../../src/gcc/fortran/trans-array.c:3528
0x69793a gfc_start_scalarized_body(gfc_loopinfo*, stmtblock_t*)
../../src/gcc/fortran/trans-array.c:3586
0x6ed5cf gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../src/gcc/fortran/trans-stmt.c:476
0x68ef73 trans_code
../../src/gcc/fortran/trans.c:1768
0x6b25dc gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:6167
0x64a800 translate_all_program_units
../../src/gcc/fortran/parse.c:5915
0x64a800 gfc_parse_file()
../../src/gcc/fortran/parse.c:6121
0x68c1c2 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Note that I'm not 100% certain that this is legal code (I don't have access to
any other compilers to check).

[Bug c/78989] Missing -Waddress warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Dunno if we don't want to special case macros in system headers that expand to
a single token or what other heuristics to use.

[Bug c/78989] Missing -Waddress warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Looks like -Wsystem-headers in action again.  NULL is a macro defined in a
system header...

[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux

[bruno at clisp dot org]

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

--- Comment #7 from bruno at clisp dot org ---
(In reply to Andreas Schwab from comment #6)
> Note that if you use --with-ld, -B no longer works.
Thanks Andreas.
In fact, I've never used the -B option (except during gcc bootstrap).
Some 20 years ago I used the options -V and -b, but over time I found it more
reliable to not share anything between installed GCC binaries of different
versions or targets, i.e. use a different --prefix each time.

[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

Marek Polacek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |valid C++11 code using  |valid 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 #6 from Marek Polacek  ---
Fixed on trunk so far.

[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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 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 #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  4 17:47:04 2017
New Revision: 244062

URL: https://gcc.gnu.org/viewcvs?rev=244062=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:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for32.C
trunk/gcc/testsuite/g++.dg/cpp0x/range-for33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77284] [5/6/7 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 #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  4 17:47:04 2017
New Revision: 244062

URL: https://gcc.gnu.org/viewcvs?rev=244062=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:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for32.C
trunk/gcc/testsuite/g++.dg/cpp0x/range-for33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/78989] New: Missing -Waddress warning

[marxin at gcc dot gnu.org]

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

Bug ID: 78989
   Summary: Missing -Waddress warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following test-case does not report warning:

$ cat /tmp/gimplify.ii 
int 
asan_poison_variables ()
{
 return (asan_poison_variables &&  
# 6 "gimplify.cpp" 3 4
  __null
  );
}

./xgcc -B. /tmp/gimplify.ii -Wall -c
[nothing]

While:

cat /tmp/gimplify.ii 
int 
asan_poison_variables ()
{
 return (asan_poison_variables &&  
  __null
  );
}
$ ./xgcc -B. /tmp/gimplify.ii -Wall -c
/tmp/gimplify.ii: In function ‘int asan_poison_variables()’:
/tmp/gimplify.ii:5:31: warning: the address of ‘int asan_poison_variables()’
will never be NULL [-Waddress]
   __null
   ^~

It's somehow related to the location if *.ii file, but I don't know how.
Thanks

[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Thanks.  The preprocessed file is what we need.  I see two snprintf calls being
optimized in the SEQAN_TEST_test_random_beta_write function:

  On line 52569 substituting 3 for snprintf return value (output constant).
  On line 52569 snprintf in-bounds return value in range [3, 8].

The line numbers correspond to the preprocessed file with #line directives and
empty lines removed and point to the template below:

  inline typename Size::Type
  appendNumber(TTarget & target, double source);

Of the two lines, the first one is the one that would affect the subsequent
write call.  The source argument is 0.5 which is represented exactly in binary
and which snprintf formats as the three bytes "0.5" and that's also what GCC
assumes.  The second line corresponds to the argument value of 0.3.  0.3 is not
represented exactly and how it's formatted depends on the rounding mode.  When
rounded down, it's formatted as "0.29" (8 bytes), when up or to nearest
(the typical default) it's "0.3" (3 bytes).  So GCC determines the return value
is [3, 8].  The range is not used in the subsequent write call but it could be
used if the return value of the function were used elsewhere.  I checked
appendNumber callers and none uses it.

From the assertion in comment #0:
Assertion failed : CharString("~Beta(0.5,0.3)") == os.str() was: ~Beta(0.5,0.3)
!= ~Beta(0.5,0.3
[NON-XML-CHAR-0x8]


)

it looks as though the return value with your version of GCC is greater than 3
and the function ends up writing junk after the "0.3".  You can see what GCC
thinks the return value is by compiling the file with
-fdump-tree-printf-return-value and looking in the output file (named something
like test_random.c.173t.printf-return-value2) for lines that start with the
text "On line "  You should see the same two lines as above (with different
line numbers).   When you look at the snprintf calls in the function body below
you should see something like this:

  snprintf (, 32, "%g", 5.0e-1);
  _204 = 3;
  ...
  _355 = snprintf (, 32, "%g",
2.99988897769753748434595763683319091796875e-1);
  len_356 = (size_t) _355;


showing that the first return value is optimized to the constant 3 and the
second return value is no optimized (it comes from the function call).  If the
return value from the second call is optimized into a constant that would point
to a bug in GCC.  If not, it would point to a bug in snprintf.

If this is too complicated please attach the output file produced by the
-fdump-tree-printf-return-value function to this report.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #40403|0   |1
is obsolete||

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

WIP updated patch, but there is still some bug in the vops after
slpeel_tree_duplicate_loop_to_edge_cfg.

[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux

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

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

--- Comment #6 from Andreas Schwab  ---
Note that if you use --with-ld, -B no longer works.

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #9)
> Sounds good. I can give it a try in the following days or weeks and see if I
> can get a C code with such large switch statements compiled.

Building a patched version of gcc-7 now. Then I'll try whether the problem
vanishes when using the -mlong-jump-table-offsets option.

[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux

[bruno at clisp dot org]

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

--- Comment #5 from bruno at clisp dot org ---
Thanks Jakub. The ld --version and "-m elf_i386 -L /usr/lib/" trick solves it!
(I was already using the "as --32" trick.)

Another way is to define a simpler ld32 script
== ld32 =
#!/bin/sh
exec ld -m elf_i386 -L /usr/lib/ "$@"
=
specify this script through the --with-ld option, AND use the --disable-lto
option.

[Bug c/78987] Wrong location of a binary expression for -Waddress

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
C++ related issue: PR78988.

[Bug c++/78988] New: Wrong location of a binary expression for -Waddress

[marxin at gcc dot gnu.org]

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

Bug ID: 78988
   Summary: Wrong location of a binary expression for -Waddress
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

This is C++ equivalent of PR78987

Starting from 4.8, where location description was added.

$ cat /tmp/wrong-conditions.c 
void foo() {}
void bar() {}
void baz() {}

int main2(int argc, int argc2)
{
  if (foo && bar && baz)
return 1;

  return 0;
}

$ ./xg++ -B. /tmp/wrong-conditions.c -c -Wall
/tmp/wrong-conditions.c: In function ‘int main2(int, int)’:
/tmp/wrong-conditions.c:7:14: warning: the address of ‘void foo()’ will never
be NULL [-Waddress]
   if (foo && bar && baz)
  ^~~
/tmp/wrong-conditions.c:7:14: warning: the address of ‘void bar()’ will never
be NULL [-Waddress]
/tmp/wrong-conditions.c:7:21: warning: the address of ‘void baz()’ will never
be NULL [-Waddress]
   if (foo && bar && baz)
 ^~~

Where location of 'foo' is wrong and location for 'bar' is missing.

[Bug c/78987] New: Wrong location of a binary expression for -Waddress

[marxin at gcc dot gnu.org]

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

Bug ID: 78987
   Summary: Wrong location of a binary expression for -Waddress
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from 4.8, where location description was added.

$ cat /tmp/wrong-conditions.c 
void foo() {}
void bar() {}
void baz() {}

int main2(int argc, int argc2)
{
  if (foo && bar && baz)
return 1;

  return 0;
}

$ ./xgcc -B. /tmp/wrong-conditions.c -c -Wall
/tmp/wrong-conditions.c: In function ‘main2’:
/tmp/wrong-conditions.c:7:7: warning: the address of ‘foo’ will always evaluate
as ‘true’ [-Waddress]
   if (foo && bar && baz)
   ^~~
/tmp/wrong-conditions.c:7:11: warning: the address of ‘bar’ will always
evaluate as ‘true’ [-Waddress]
   if (foo && bar && baz)
   ^~
/tmp/wrong-conditions.c:7:18: warning: the address of ‘baz’ will always
evaluate as ‘true’ [-Waddress]
   if (foo && bar && baz)
  ^~

Location of the first is correct, last 2 are wrong.

[Bug c++/78986] New: template inner classes are not affected by visibility specifiers

[michele.caini at gmail dot com]

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

Bug ID: 78986
   Summary: template inner classes are not affected by visibility
specifiers
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

Consider the following code:

class B { struct T {}; };
class D: B { template struct U: T {}; };
int main() {}

GCC accepts it, but it shouldn't for T is private in B and U cannot inherit
from it in D.
GCC correctly rejects the code below:

class B { struct T {}; };
class D: B { struct U: T {}; };
int main() {}

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

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Trunk no longer defines __cxa_thread_atexit if it's found in libc. We might
want to backport this to the gcc-5-branch and gcc-6-branch.

I will try to test this in a FreeBSD 11 VM some time soon.

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

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan  4 15:41:19 2017
New Revision: 244057

URL: https://gcc.gnu.org/viewcvs?rev=244057=gcc=rev
Log:
PR78968 add configure check for __cxa_thread_atexit in libc

PR libstdc++/78968
* config.h.in: Regenerate.
* configure: Likewise.
* configure.ac: Check for __cxa_thread_atexit.
* libsupc++/atexit_thread.cc [_GLIBCXX_HAVE___CXA_THREAD_ATEXIT]:
Don't define __cxa_thread_atexit if libc provides it.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/libsupc++/atexit_thread.cc

[Bug rtl-optimization/78932] [ARM] -O2 generates wrong code

[xqr4n54r1 at hotmail dot com]

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

--- Comment #2 from xqr4n54r1 at hotmail dot com ---
Created attachment 40457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40457=edit
memcpy instead of get_unaligned_be


* I wrote memcpy instead of get_unaligned_be{16|32} and I saw that solved the
problem. I think that the basic block reordering does not work correctly.

Attachment has following :

- filter_O2.{c|s} :  Indicates that the problem has occurred.
- filter_memcpy.{c|s} : Indicates solution that compile memcpy instead
get_unaligned_be{16|32} I mentioned above.

[Bug c++/66735] [C++14] lambda init-capture fails for const references

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jan  4 15:23:40 2017
New Revision: 244056

URL: https://gcc.gnu.org/viewcvs?rev=244056=gcc=rev
Log:
cp/
PR c++/66735
* cp-tree.h (DECLTYPE_FOR_REF_CAPTURE): New.
(lambda_capture_field_type): Update prototype.
* lambda.c (lambda_capture_field_type): Add is_reference parm.
Add referenceness here.
(add_capture): Adjust lambda_capture_field_type call, refactor
error checking.
* pt.c (tsubst): Adjust lambda_capture_field_type call.

testsuite/
PR c++/66735
* g++.dg/cpp1y/pr66735.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr66735.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/lambda.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66735] [C++14] lambda init-capture fails for const references

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #7 from Nathan Sidwell  ---
Fixed trunk r244056.

[Bug c++/54367] [meta-bug] lambda expressions

[nathan at gcc dot gnu.org]

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

Bug 66735 Summary: [C++14] lambda init-capture fails for const references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66735

   What|Removed |Added

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

[Bug sanitizer/57507] gcc 4.8: thread sanitizer: std::thread false(?) positive

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
This should no longer be a problem, because std::thread doesn't use
std::shared_ptr these days.

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

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 40456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40456=edit
Untested patch

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

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 40455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40455=edit
Untested patch

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Ok, basic problem is in _cpp_save_file_entries, where we calculate md5sum of
all inputs files. Providing '-' will cause to have input file as fd == 0 and

  ff = fdopen (f->fd, "rb");
  md5_stream (ff, result->entries[count].sum);
  fclose (ff);

will fail as fdopen fails for 0 fd.

Thoughts?

Another corner case is using --save-temps that will also confuse command line:
cc1: error: unrecognized command line option ‘-.i’

./cc1 -fpreprocessed -.i -quiet -dumpbase - -mtune=generic -march=x86-64
-auxbase - -version -o -.s --output-pch= pes.pch

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

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

[rguenth at gcc dot gnu.org]

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

Bug ID: 78985
   Summary: [7 Regression] profiledbootstrap failure by
-Wuninitialized
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build, diagnostic
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: s390x-*-*

profiledbootstrap fails for me on s390x-linux for quite some time now
(also on aarch64-linux in a similar way, but re-checking with current trunk
didn't finish/fail yet).  lab_over is obviously not uninitialized
(but eventually jump threading gets in the way - I did not analyze this yet
as I lack a way to extract a testcase at the moment).


../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,go --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libmpx --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7
--disable-multilib --without-system-libunwind --with-tune=zEC12
--with-arch=z196 --with-long-double-128 --enable-decimal-float
--build=s390x-suse-linux --host=s390x-suse-linux
...
[ 4042s] ../../gcc/config/s390/s390.c: In function 'tree_node*
s390_gimplify_va_
arg(tree, tree, gimple**, gimple**)':
[ 4042s] ../../gcc/config/s390/s390.c:12296:52: error: 'lab_over' may be used
un
initialized in this function [-Werror=maybe-uninitialized]
[ 4042s]  gimple_seq_add_stmt (pre_p, gimple_build_label (lab_over));
[ 4042s]  ~~~^~
...
[ 4044s] cc1plus: all warnings being treated as errors
[ 4044s] make[3]: *** [Makefile:2221: s390.o] Error 1
[ 4044s] make[3]: *** Waiting for unfinished jobs
[ 4045s] rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gfortran.pod
gcc.pod gccgo.pod gcov-tool.pod
[ 4045s] make[3]: Leaving directory
'/home/abuild/rpmbuild/BUILD/gcc-7.0.0-r244052/obj-s390x-suse-linux/gcc'
[ 4045s] make[2]: *** [Makefile:4725: all-stagefeedback-gcc] Error 2
[ 4045s] make[2]: Leaving directory
'/home/abuild/rpmbuild/BUILD/gcc-7.0.0-r244052/obj-s390x-suse-linux'

[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3

[h2+bugs at fsfe dot org]

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

--- Comment #10 from Hannes Hauswedell  ---
Created attachment 40454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40454=edit
intermediate for O3 -fno-printf-return-value

[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3

[h2+bugs at fsfe dot org]

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

--- Comment #9 from Hannes Hauswedell  ---
Created attachment 40453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40453=edit
intermediate for O3

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

[h2+bugs at fsfe dot org]

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

--- Comment #14 from Hannes Hauswedell  ---
sorry, please ignore the attachments, bugzilla dropped me in a different issue
than planned.

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

[h2+bugs at fsfe dot org]

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

--- Comment #13 from Hannes Hauswedell  ---
Created attachment 40452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40452=edit
intermediate for O3 -fno-printf-return-value