[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r248155.

[Bug middle-end/80823] New: [8 Regression] ICE: verify_flow_info failed

[trippels at gcc dot gnu.org]

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

Bug ID: 80823
   Summary: [8 Regression] ICE: verify_flow_info failed
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 linux % cat book3s_pr_papr.i
int a, c;
int b[1];
int fn1() {
  switch (a)
  case 0:
  case 2:
return 1;
  return 0;
}
void fn2() {
  int i;
  for (;; ++i) {
c = b[i];
int d = !fn1();
if (d)
  __asm__("");
  }
}

trippels@gcc2-power8 linux % gcc -c -O3 book3s_pr_papr.i
book3s_pr_papr.i: In function ‘fn2’:
book3s_pr_papr.i:10:6: error: missing edge 2->4
 void fn2() {
  ^~~
book3s_pr_papr.i:10:6: internal compiler error: verify_flow_info failed
0x10359553 verify_flow_info()
../../gcc/gcc/cfghooks.c:260
0x1094081b checking_verify_flow_info
../../gcc/gcc/cfghooks.h:198
0x1094081b cleanup_tree_cfg_noloop
../../gcc/gcc/tree-cfgcleanup.c:837
0x1094081b cleanup_tree_cfg()
../../gcc/gcc/tree-cfgcleanup.c:883
0x107bbfc7 execute_function_todo
../../gcc/gcc/passes.c:1922
0x107bcd53 do_per_function
../../gcc/gcc/passes.c:1653
0x107bcfd3 execute_todo
../../gcc/gcc/passes.c:2023

[Bug libstdc++/80796] New: std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

[webrown.cpp at gmail dot com]

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

Bug ID: 80796
   Summary: std::make_xxx_searcher / std::search(iter, iter,
searcher) is missing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d25fe0be at outlook dot com
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com

I hesitate to submit this as a PR since they might simply have not been
implemented yet, as they're not listed in libstdc++/manual/status.html
explicitly.

The searchers are present, as stated in the status page.

The std::make_xxx_searcher / std::search is listed in P0220R1, the same paper
as the searchers ('Library Fundamentals V1 TS Components: Searchers').

FWIW, std::experimental::make_xxx_searcher / std::experimental::search (N3905)
are present, only the corresponding ones in std:: are missing,

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #7 from Daniel Santos  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > Well, this was my introduction to DejaGnu and the test harness.  I found 
> > that
> > none of these support doing a build when there is more than one object file 
> > --
> > in my case, I'm linking the output of both ms-sysv.c and do_test.S.  
> > However,
> 
> Huh?  What about dg-additional-sources, which seems to be exactly what
> you need and is even documented in sourcebuild.texi ;-)

I think my limitation is the generated headers.  I was examining how
struct-layout-1.exp works (as it is the most similar test to mine) and it
generates all of it's sources for each job, but they are pretty small.  I don't
suppose you know of a way to generates my sources (headers) in one place and
then access them when ms-sysv.exp runs do you?  I'm semi-content with leaving
it as it is (presuming all of the flaws can be fixed), but it would be nice to
be able to use the standard functions.

On the flip side, each of these tests are fairly slow (especially with rtl
checking) and I understand that the way dg splits up tests might not
parallelize well with fewer, slower tests.

Daniel

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #6 from Daniel Santos  ---
Created attachment 41386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41386=edit
proposed fix

Rainer,

Would you be so kind as to test this on Solaris for me please?  I don't have
access to a Solaris machine and I've never set it up before, so I wouldn't even
know where to start to try to build an OpensSolaris VM.

Also, I don't know if Mike will accept adding the new
gcc/testsuite/lib/parallelize.exp, if not I'll just reintegrate it into the
ms-sysv.exp file.

[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
The trimmed length is incorrect.

With this test:

program test_character
  real:: a
  character(len=2, kind=4):: char1, char2

  char2 = 4_"Ã"

  open(6, encoding="utf-8")

  write(*,'(a)') trim(char2)
  !print *, len(trim(char2),4)
end program


The length computed for len(trim(char2),4) is 2.

$ ./a.out >test.out 
[jerry@amda8 pr66499]$ xxd test.out 
: c383 c283 0a 

We have an extra word being emitted.  Two extra bytes.

[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2013-11-08 00:00:00 |2017-05-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #16 from Martin Sebor  ---
Confirmed.

I don't think the char* overload can ever match the string overload because the
former has to compute the length of the char* argument and (possibly also)
compare the strings, while the latter can avoid the first step because the
lengths of both arguments are precomputed.

But the char* overload can be sped up by avoiding string::compare which always
traverses the strings, when operator== only has to do that if their lengths are
the same.

It also doesn't help that string::compare is not expanded inline (because
std::string is declared extern).

In my tests, the following definition speeds the operator up by a factor of 5,
making it about 20% faster than strcmp:

  template
inline bool
operator==(const basic_string<_CharT>& __lhs,
const _CharT* __rhs)
  {
return !__lhs.compare (__rhs);

typedef typename basic_string<_CharT>::size_type size_type;
const size_type __len1 = __lhs.length ();
const size_type __len2 = __builtin_strlen (__rhs);

return __len1 == __len2
  && !char_traits<_CharT>::compare (__lhs.data (), __rhs,
__len1 < __len2 ? __len1 : __len2);
  }

[Bug libgomp/80822] New: libgomp incorrect affinity when OMP_PLACES=threads

[weeks at iastate dot edu]

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

Bug ID: 80822
   Summary: libgomp incorrect affinity when OMP_PLACES=threads
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weeks at iastate dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41385=edit
xthi.c from Cray, Inc. modified to remove MPI code

On the NERSC Cori system, the Haswell nodes have two Intel Xeon E5-2698 v3
processors, each with 16 CPU cores with HyperThreading enabled. Using
OMP_PLACES=threads, libgomp from gcc 6.3.0 appears to mistakenly assume that
CPU (hardware thread) 0 and 1 share the same core, while in reality 0 and 32
are on the same core, etc.

To illustrate, attached (xthi-omp.c) is a version of xthi.c from the "Cray XC
Series User Application Placement Guide (CLE 6.0.UP01) S-2496"
(https://pubs.cray.com/content/00330629-DC/FA00256413) that has been modified
to remove the MPI code. The output of en MPI 1.10.2 "lstopo --of console"
command (lstopo.out) that shows the processor topology is at the bottom of this
text.

In the first example (OMP_NUM_THREADS=32 OMP_PLACES=threads
OMP_PROC_BIND=spread), CPU cores 0, 2, 4, ..., 30 each have two OpenMP threads,
while CPU cores 1,3,...,31 have none:

==
$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
0,32
$ gcc --version
gcc (GCC) 6.3.0 20161221 (Cray Inc.)
Copyright (C) 2016 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.

$ gcc -fopenmp -o xthi-omp.x xthi-omp.c
$ OMP_NUM_THREADS=32 OMP_PLACES=threads OMP_PROC_BIND=spread ./xthi-omp.x |
sort -k 4n,4n
Hello from thread 0, on nid9. (core affinity = 0)
Hello from thread 1, on nid9. (core affinity = 2)
Hello from thread 2, on nid9. (core affinity = 4)
Hello from thread 3, on nid9. (core affinity = 6)
Hello from thread 4, on nid9. (core affinity = 8)
Hello from thread 5, on nid9. (core affinity = 10) 
Hello from thread 6, on nid9. (core affinity = 12) 
Hello from thread 7, on nid9. (core affinity = 14) 
Hello from thread 8, on nid9. (core affinity = 16) 
Hello from thread 9, on nid9. (core affinity = 18) 
Hello from thread 10, on nid9. (core affinity = 20) 
Hello from thread 11, on nid9. (core affinity = 22) 
Hello from thread 12, on nid9. (core affinity = 24) 
Hello from thread 13, on nid9. (core affinity = 26) 
Hello from thread 14, on nid9. (core affinity = 28) 
Hello from thread 15, on nid9. (core affinity = 30) 
Hello from thread 16, on nid9. (core affinity = 32) 
Hello from thread 17, on nid9. (core affinity = 34) 
Hello from thread 18, on nid9. (core affinity = 36) 
Hello from thread 19, on nid9. (core affinity = 38) 
Hello from thread 20, on nid9. (core affinity = 40) 
Hello from thread 21, on nid9. (core affinity = 42) 
Hello from thread 22, on nid9. (core affinity = 44) 
Hello from thread 23, on nid9. (core affinity = 46) 
Hello from thread 24, on nid9. (core affinity = 48) 
Hello from thread 25, on nid9. (core affinity = 50) 
Hello from thread 26, on nid9. (core affinity = 52) 
Hello from thread 27, on nid9. (core affinity = 54) 
Hello from thread 28, on nid9. (core affinity = 56) 
Hello from thread 29, on nid9. (core affinity = 58) 
Hello from thread 30, on nid9. (core affinity = 60) 
Hello from thread 31, on nid9. (core affinity = 62) 
==

In the second example, OMP_PROC_BIND=close results in 1 OpenMP thread per core,
opposite of the intended effect:

==
$ OMP_NUM_THREADS=32 OMP_PLACES=threads OMP_PROC_BIND=close ./xthi-omp.x | sort
-k 4n,4n
Hello from thread 0, on nid9. (core affinity = 0)
Hello from thread 1, on nid9. (core affinity = 1)
Hello from thread 2, on nid9. (core affinity = 2)
Hello from thread 3, on nid9. (core affinity = 3)
Hello from thread 4, on nid9. (core affinity = 4)
Hello from thread 5, on nid9. (core affinity = 5)
Hello from thread 6, on nid9. (core affinity = 6)
Hello from thread 7, on nid9. (core affinity = 7)
Hello from thread 8, on nid9. (core affinity = 8)
Hello from thread 9, on nid9. (core affinity = 9)
Hello from thread 10, on nid9. (core affinity = 10)
Hello from thread 11, on nid9. (core affinity = 11)
Hello from thread 12, on nid9. (core affinity = 12)
Hello from thread 13, on nid9. (core affinity = 13)
Hello from thread 14, on nid9. (core affinity = 14)

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #7 from Ian Lance Taylor  ---
Thanks.  I committed a patch that should avoid this problem--a mismatch between
the installed libgo and the in-tree libgo--in the future.

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu May 18 22:44:12 2017
New Revision: 248255

URL: https://gcc.gnu.org/viewcvs?rev=248255=gcc=rev
Log:
PR go/80814
* Makefile.am (AM_GOCFLAGS): Define.
* Makefile.in: Rebuild.

Modified:
trunk/gotools/ChangeLog
trunk/gotools/Makefile.am
trunk/gotools/Makefile.in

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
That should have read:

> ...hide their bodies from the optimizer...

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
That does work.  I had tried with the attribute on the end of the declaration
and it barfed.

I was going to say I'd worry that declaring the members extern template might
effectively hide them from their bodies optimizer and pessimize other code, but
I see that the whole std::string specialization is declared extern template so
it's already hidden, which is why the optimization doesn't happen to begin
with.

[Bug tree-optimization/80821] New: genmatch conflicting predicates

[glisse at gcc dot gnu.org]

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

Bug ID: 80821
   Summary: genmatch conflicting predicates
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Here is an artificial .pd file to demonstrate the issue:

(match (p1 @0) INTEGER_CST@0)
(match (p2 @0) REAL_CST@0)
(simplify (convert (p1 @0)) @0)
(simplify (convert (p2 @0)) @0)

genmatch generates a gimple_simplify_CONVERT_EXPR with twice the line

  tree op0_pops[1];

at the same level, causing a compilation error.

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[me at hussam dot eu.org]

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

--- Comment #5 from Hussam Al-Tayeb  ---
(In reply to Ian Lance Taylor from comment #3)

> Have you run `make install` to install an earlier version of the build? 
> Perhaps the compilation command is incorrectly looking at the installed .gox
> files before looking at the newly built ones.

It looks like this may have been the case. Removing the gcc-go subpackage and
recompiling without reverting that commit makes a full build successful.
The installing all of gcc including gcc-go and recompiling from scratch also
completes successfully.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

--- Comment #5 from Daniel Santos  ---
OK, I think I've got these fixed but I need to rerun my tests now.  Somebody
else discovered another flaw that caused the test to break with -j1 (when
parallelization wasn't being used).  I hate that I've had to go so far off of
the beaten path with this test, but I don't see another way to do it right now
unless I pre-generated all of the headers (for each parallelization directory),
but they are about 9 MB each so I think that would be a very bad idea -- if you
ran -j48, you could get 1.7 GiB of stupid headers.

(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> Exactly: I'd avoid that if you can.  It will only complicate things.

The only advantage is that I can get the offsets of the test_data struct
members cleanly using inline gcc, but for now I've just replaced them with hard
offsets and put asserts in the main() of the C file to validate that those
offsets haven't changed.

Daniel

[Bug c++/80783] missing constexpr diagnostic for functions that cannot be constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Severity|enhancement |normal

--- Comment #4 from Martin Sebor  ---
Ah.  For exit, GCC recognizes it as a built-in function and doesn't diagnose
it.The same happens with puts for instance.  It should diagnose these.

For atoi, it's attribute pure that makes the difference, and the fact that the
function returns a value.  Attribute const has the same effect.  It looks to me
like calls to such finctions whose return value is unused are eliminated
(because they have no effect) before they can be checked.  This also seems like
a bug.  Let me change this back from enhancement to bug.

Note that it's not valid to declare extern "C" standard library functions like
free() to have a different type (like free(double)).  GCC recognizes many of
them as built-in functions and GCC 7 will warn about such conflicting
declarations with -Wbuiltin-declaration-mismatch.  This doesn't make this bug
report invalid, but it does mean that those test cases aren't really valid.

$ cat u.C && gcc -S -Wall -Wextra u.C
int foo () __attribute__ ((__pure__));

constexpr int f () { foo (); return 0; }

int bar ();

constexpr int g () { bar (); return 0; }

u.C: In function ‘constexpr int f()’:
u.C:3:26: warning: statement has no effect [-Wunused-value]
 constexpr int f () { foo (); return 0; }
  ^~
u.C: In function ‘constexpr int g()’:
u.C:7:26: error: call to non-constexpr function ‘int bar()’
 constexpr int g () { bar (); return 0; }
  ^~

[Bug c++/80783] missing constexpr diagnostic for functions that cannot be constexpr

[victor.nawothnig at gmail dot com]

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

--- Comment #3 from Victor Nawothnig  ---
Created attachment 41384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41384=edit
Examples

All testcases and their results attached for better readability

[Bug c++/80783] missing constexpr diagnostic for functions that cannot be constexpr

[victor.nawothnig at gmail dot com]

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

--- Comment #2 from Victor Nawothnig  ---
Except all the following examples violate the core constant expression
constraint ([expr.const] 2.3), but GCC diagnoses only some:

```
$ echo '#include  \n constexpr int f() { atoi(""); return 1; }' |
g++-6 -x c++ -c -
: In function 'constexpr int f()':
:2:26: error: call to non-constexpr function 'int atoi(const char*)'
$ echo '#include  \n constexpr int f() { atexit(0); return 1; }' |
g++-6 -x c++ -c -
: In function 'constexpr int f()':
:2:28: error: call to non-constexpr function 'int atexit(void (*)())'
$ echo 'void g(); constexpr int f() { g(); return 1; }' | g++-6 -x c++ -c -
: In function 'constexpr int f()':
:1:32: error: call to non-constexpr function 'void g()'
$ echo '#include  \n constexpr int f() { calloc(0,0); return 1; }' |
g++-6 -x c++ -c -
(success)
$ echo '#include  \n constexpr int f() { malloc(0); return 1; }' |
g++-6 -x c++ -c -
(success)
$ echo '#include  \n constexpr int f() { free(0); return 1; }' | g++-6
-x c++ -c -
(success)
```


And regarding your last argument, here is to show that this is not the case. It
seems like something about the signature influences how GCC applies its
constexpr diagnostic.
```
$ echo 'extern "C" void free(void *); constexpr int f() { free(0); return 1; }'
| g++-6 -x c++ -c -
(success)
$ echo 'extern "C" int free(double); constexpr int f() { free(0); return 1; }'
| g++-6 -x c++ -c -
: In function 'constexpr int f()':
:1:54: error: call to non-constexpr function 'int free(double)'
```
```
$ echo 'extern "C" void exit (int); constexpr int f() { exit(0); return 1; }' |
g++-6 -x c++ -c -
(success)
$ echo 'extern "C" void exit (double); constexpr int f() { exit(0); return 1;
}' | g++-6 -x c++ -c -
: In function 'constexpr int f()':
:1:56: error: call to non-constexpr function 'void exit(double)'
```

That test came from trying to narrow it down to either the libstdc++-v3 or g++.

[Bug target/80819] [5/6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[peter at cordes dot ca]

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

--- Comment #2 from Peter Cordes  ---
(In reply to Andrew Pinski from comment #1)
> >-mtune=generic still stores/reloads instead of using movd for %edi and %edx, 
> >which is worse for most CPUs. 
> Worse on most Intel but not most AMD CPUs.  You can use -mtune=intel if you
> want to tune for Intel machines :).

Store/reload isn't a lot better on AMD Bulldozer-family, not enough to justify
making worse code for Intel CPUs.  -mtune=generic doesn't mean tune=non-intel,
it's a weighted average of all relevant CPUs, and should avoid slowing down
common CPUs for small gains on rare CPUs.

I wrote up my argument for -mtune=generic to favour a movd/movq strategy, or
maybe a mix of movd and store/reload, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820.  (Also that znver1 should
definitely use movd, and that there's a store/reload that slipped through the
cracks for -mtune=haswell.)  I probably should have made that two or three
separate bugs, but I already have another 3 or 4 half-finished bug reports
typed up :/

[Bug target/80820] New: _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

[peter at cordes dot ca]

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

Bug ID: 80820
   Summary: _mm_set_epi64x shouldn't store/reload for
-mtune=haswell, Zen should avoid store/reload, and
generic should think about it.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

gcc with -mtune=generic likes to bounce through memory when moving data from
integer registers to xmm for things like _mm_set_epi32.

There are 3 related tuning issues here:

* -mtune=haswell -mno-sse4 still uses one store/reload for _mm_set_epi64x.

* -mtune=znver1 should definitely favour movd/movq instead of store/reload.
  (Ryzen has 1 m-op movd/movq between vector and integer with 3c latency,
shorter than store-forwarding.  All the reasons to favour store/reload on other
AMD uarches are gone.)

* -mtune=generic should probably favour movd/movq.  I think it's better for a
weighted-average of CPUs we care about for -mtune=generic.  Most of the text
below is an attempt to back up this claim, but I don't have hardware to test
with so all I can do is look at Agner Fog's tables and microarch pdf.

 movd is about break-even on Bulldozer, better on SnB-family, much better on
Core2/Nehalem, and significantly worse only on AMD K8/K10.  Or maybe use a
hybrid strategy that does half with movd and half with store/reload, which can
actually be better than either strategy alone on Bulldozer and SnB-family.

---

The tune=haswell issue is maybe separate from the others, since gcc already
knows that bouncing through memory isn't the optimal strategy.

#include 
__m128i combine64(long long a, long long b) {
  return _mm_set_epi64x(b,a);
}

gcc8 -O3 -mtune=haswell emits:

movq%rsi, -16(%rsp)
movq%rdi, %xmm0
movhps  -16(%rsp), %xmm0

(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80819 for the wasted store
with -msse4 -mno-avx).


I think what clang and ICC do is optimal for the SSE2-only case, for Intel CPUs
and Ryzen:

movq%rsi, %xmm1
movq%rdi, %xmm0
punpcklqdq  %xmm1, %xmm0

_mm_set_epi32(d,c,b,a) with -mtune=haswell gives us the expected movd/punpck
(without SSE4), no store/reload.


-


Using movd or movq instead of a store/reload is a code-size win: movd %eax,
%xmm0 is 4 bytes (or 5 with a REX prefix for movq or high registers). 
Store/reload to -0x10(%rsp) is 10, 11, or 12 bytes, depending on operand size
and high register(s).

movd int->xmm is lower latency than store/reload on most CPUs, especially Intel
SnB-family where it's 1c latency, and also AMD Ryzen.   On SnB family,
store/reload's only advantage is rare cases where port5 is a throughput
bottleneck and latency isn't important.

It replaces a store and a load uop with 1 ALU uop on Intel Core2 and later, and
Atom/Silvermont/KNL.  Also 1 uop on VIA Nano.

movd int->xmm is 2 ALU uops on AMD K10/Bulldozer-family and Jaguar, and P4, and
3 on K8/Bobcat.  It never costs any more total uops for the front-end (since a
movd load is 2 uops on K8/Bobcat), but decoding a multi-uop instruction can
sometimes be a bottleneck (especially on K8 where a 3 m-op instruction is a
"vectorpath" (microcode)).


Store/reload has one per clock throughput on every CPU, AFAIK.  On most CPUs
that have much weight in -mtune=generic, movd's throughput is one-per-clock or
better.  (According to Agner Fog's tables, only Bobcat, K8/K10, and P4 have
throughput of one per 2 or 3 clocks for movd/movq int->xmm).  The biggest
problem is K10, with something like one per 2.8c throughput (according to a
couple reports from http://users.atw.hu/instlatx64/, e.g. 
http://users.atw.hu/instlatx64/AuthenticAMD0100FA0_K10_Thuban_InstLatX64.txt). 
Agner Fog says 3, but none of these are measuring with other instructions mixed
in.

Some CPUs have better than one-per-clock throughput for movd/movq: Core2 is
0.5, and Nehalem is 0.33.  So do we hurt them a lot to help PhenomII?  I'd
guess that Core2+Nehalem has somewhat more weight in tune=generic than K10. 
Some AMD PhenomII CPUs are still around, though.  (But we could exclude them
for code built with -mssse3)


-

Probably the deciding factor for tune=generic is whether it hurts AMD
Bulldozer-family significantly or at all.  It looks there's not much difference
either way: similar throughput and latency.

However, store/reload may have an advantage when two cores in a cluster are
competing for their shared vector unit.  Probably both of movd's macro-ops need
to run on the shared vector unit, but for store/reload maybe only the load
needs the shared resource.  IDK if this is correct or relevant, though. 
Probably -mtune=bdver* should keep using store/reload, but 

[Bug target/80817] [missed optimization][x86] relaxed atomics

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Alexander Monakov from comment #1)
> void f(volatile int *p)
> {
>   ++*p;
> }


That's PR 50677 for instance. Some targets do handle it, there have been
discussions in the past, this seems to require special care for every
instruction of every target that wants to allow the simplification.

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
When user specializations are allowed, who knows what might happen.

As an experiment,

  namespace std { extern template  __attribute__((pure)) int
string::compare(const char*)const; }

seems to work. I think it may make sense to add the attribute only in the
extern template case, since that's the case where the explicit instantiation is
hindering IPA.

[Bug c/80806] gcc does not warn if local array is memset only

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The challenge is that the DECL_READ_P flag is set indiscriminately by the front
end (in convert_lvalue_to_rvalue called from c_parser_expr_list while parsing
the argument list in the function call expression) in response to seeing the
array being passed to a function as an argument.  There's no logic that would
take into account the properties of the function is being called.  In general,
GCC also has no notion of "out" only arguments (such as memset's first), or
"in" only (such as memcpy's second).  It may be a useful concept to introduce
in the form of an attribute.  With such an attribute, this issue could then be
detected in for any function whose arguments were decorated with it.

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Thu May 18 19:34:13 2017
New Revision: 248254

URL: https://gcc.gnu.org/viewcvs?rev=248254=gcc=rev
Log:
[gcc]
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

[gcc/testsuite]
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/80795] Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Yet another dup of bug 64095.

[Bug libstdc++/80478] Calling `std::bind` on member functions marked as `noexcept` fails to compile with -std=c++1z

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 7.2

[Bug libstdc++/80478] Calling `std::bind` on member functions marked as `noexcept` fails to compile with -std=c++1z

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 18:04:15 2017
New Revision: 248247

URL: https://gcc.gnu.org/viewcvs?rev=248247=gcc=rev
Log:
PR libstdc++/80478 make std::mem_fn work with noexcept functions

PR libstdc++/80478
* include/std/functional (_Mem_fn_traits_base): Add specializations
for noexcept member function types.
* testsuite/20_util/function_objects/mem_fn/80478.cc: New test.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/80478.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/functional

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 18 18:03:30 2017
New Revision: 248246

URL: https://gcc.gnu.org/viewcvs?rev=248246=gcc=rev
Log:
PR target/80799
* config/i386/mmx.md (*mov_internal): Enable
alternatives 11, 12, 13 and 14 also for 32bit targets.
Remove alternatives 15, 16, 17 and 18.
* config/i386/sse.md (vec_concatv2di): Change
alternative (!x, *y) to (x, ?!*Yn).

testsuite/ChangeLog:

PR target/80799
* g++.dg/other/i386-11.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/other/i386-11.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/mmx.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/80817] [missed optimization][x86] relaxed atomics

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
In the second example it's correct that lock;addq is generated, the
read-modify-write operation still needs to be atomic itself,
memory_order_relaxed indicates that it does not imply an order with respect to
other memory operations.

The first example could only be optimized on RTL level (on gimple there's no
memory rmw operations), but on RTL atomic accesses are represented as unspecs
or volatile accesses (they can't be plain accesses because the compiler may not
tear them etc, but there's no special RTL for atomic access, so volatile MEM is
the best fit), so on RTL it's similar to how

void f(volatile int *p)
{
  ++*p;
}

is not optimized either (and the issue is visible only on cisc-ish targets with
composite memory read-modify-write instructions, otherwise the load and store
would be separate anyway).

[Bug libstdc++/80478] Calling `std::bind` on member functions marked as `noexcept` fails to compile with -std=c++1z

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 17:32:06 2017
New Revision: 248245

URL: https://gcc.gnu.org/viewcvs?rev=248245=gcc=rev
Log:
PR libstdc++/80478 make std::mem_fn work with noexcept functions

PR libstdc++/80478
* include/std/functional (_Mem_fn_traits_base): Add specializations
for noexcept member function types.
* testsuite/20_util/function_objects/mem_fn/80478.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/function_objects/mem_fn/80478.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug target/80819] [5/6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>-mtune=generic still stores/reloads instead of using movd for %edi and %edx, 
>which is worse for most CPUs. 
Worse on most Intel but not most AMD CPUs.  You can use -mtune=intel if you
want to tune for Intel machines :).

[Bug target/80819] New: [5/6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

[peter at cordes dot ca]

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

Bug ID: 80819
   Summary: [5/6/7/8 regression] Useless store to the stack  in
_mm_set_epi64x with SSE4 -mno-avx
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

#include 
__m128i combine64(long long a, long long b) {
  return _mm_set_epi64x(b,a);
}

gcc5/6/7/8-snapshot with -O3 -msse4 -mtune=haswell emits:

movq%rdi, %xmm0
movq%rsi, -16(%rsp)   # dead store into the red-zone
pinsrq  $1, %rsi, %xmm0

The same thing happens with -mtune=generic -msse4: it stores both halves to
memory, but only reloads the first half.  The upper half is transferred with
pinsrq

movq%rdi, -16(%rsp)
movq%rsi, -24(%rsp)   # dead store
movq-16(%rsp), %xmm0
pinsrq  $1, %rsi, %xmm0


-mavx avoids the useless store, for tune=generic and tune=haswell.

This is a left-over from the store/reload strategy it uses without SSE4 (which
is worse than movq/movq/punpcklqdq, but that's a separate bug):

movq%rsi, -16(%rsp)
movq%rdi, %xmm0
movhps  -16(%rsp), %xmm0

It's a regression from gcc4.x, where we get the expected good sequence for
-msse4 -mtune=haswell.

movq%rdi, %xmm0
pinsrq  $1, %rsi, %xmm0


---

It doesn't happen for _mm_set_epi32.  e.g.
__m128i combine32(int a, int b, int c, int d) {
  return _mm_set_epi32(d,c,b,a);
}

compiles (with -mtune=haswell -msse4) to code that looks good to me.
movd%edx, %xmm1
movd%edi, %xmm0
pinsrd  $1, %ecx, %xmm1
pinsrd  $1, %esi, %xmm0
punpcklqdq  %xmm1, %xmm0

clang uses 1 movd and 3x pinsrd, which is 2 bytes shorter and also 7 uops for
port5 on Haswell, but has less slightly ILP.  (On CPUs where pinsrd is 2 uops,
the first one is probably an int->vector uop that can run before the
destination vector is ready.)

-mtune=generic still stores/reloads instead of using movd for %edi and %edx,
which is worse for most CPUs.  (Which is a bug, IMO: I'll file a separate bug
for that.)  But it does then use pinsrd with a register source for %ecx and
%esi, instead of a store/reload there.

[Bug c++/80783] missing constexpr diagnostic for functions that cannot be constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-18
 CC||msebor at gcc dot gnu.org
Summary|Inconsistent constexpr  |missing constexpr
   |diagnostic for some cstdlib |diagnostic for functions
   |functions   |that cannot be constexpr
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
GCC doesn't diagnose constexpr functions that cannot be invoked without
violating the core constant expression constraint.  So in the first case:

  constexpr size_t f() { exit(0); return 1; }

the function cannot be invoked in a constexpr context but could be called
elsewhere.  As QoI, GCC could diagnose it but isn't required to and doesn't.  I
agree that it would be a useful enhancement to add a diagnostic for it like
Clang's -Winvalid-constexpr so I'll confirm this as a request for one.

The nonstandard signature warning is about the incorrect/invalid declarations
of the standard functions and is unrelated to constexpr.

[Bug libstdc++/80448] #include fails with Clang 5.0

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Fixed in 5.5, 6.4 and 7.1

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-04-01 00:00:00 |2017-5-18

--- Comment #1 from Jonathan Wakely  ---
Standalone testcase using C++17 std::string_view:

#include 

struct constexpr_char_traits: public std::char_traits {
  static constexpr size_t length(const char* val) {
size_t res = 0;
for (; val[res] != '\0'; ++res)
  ;
return res;
  }

  static constexpr int compare(const char* lhs, const char* rhs, std::size_t
count) {
for (size_t pos = 0; pos < count; ++pos) {
  if (lhs[pos] != rhs[pos])
return lhs[pos] - rhs[pos];
}
return 0;
  }
};

using string_view = std::basic_string_view;

constexpr
string_view get() {
string_view res;
constexpr string_view start_pattern = "x";
res = res.substr(res.find(start_pattern) + start_pattern.size());
res = res.substr(0, res.find_first_of(";]"));
res = res.substr(res.rfind("::"));
return res;
}

static_assert( get() == get(), "" );

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Looks somewhat similar to PR 80754 ?

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 5.5, 6.4 and 7.1

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

--- Comment #7 from Jonathan Wakely  ---
Fixed in 5.5, 6.4 and 7.1

[Bug rtl-optimization/80818] New: LRA clobbers live hard reg clobbered during rematerialization

[krebbel at gcc dot gnu.org]

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

Bug ID: 80818
   Summary: LRA clobbers live hard reg clobbered during
rematerialization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41383=edit
Experimental patch

GCC revision: r248043

The live range for the following insn does not appear to be calculated
correctly:
(insn 1451 57711 1452 121 (parallel [
(set (reg:SI 1360 [ _2122 ])
(plus:SI (plus:SI (gtu:SI (reg:CCU 33 %cc)
(const_int 0 [0]))
(reg:SI 1404 [ _2207 ]))
(reg:SI 1427 [ _2244 ])))
(clobber (reg:CC 33 %cc))
]) "t.f90":61 1661 {*addsi3_alc}
 (expr_list:REG_DEAD (reg:SI 1427 [ _2244 ])
(expr_list:REG_DEAD (reg:SI 1404 [ _2207 ])
(expr_list:REG_DEAD (reg:CCU 33 %cc)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))


The CC reg is read as part of an operand but also clobbered in that insn.

The following operand registers are being recorded by lra:
{early_clobber_alts = 0, biggest_mode = SImode, type = OP_OUT, subreg_p = 0,
early_clobber = 0, regno = 1360, next = 0x4090910}
{early_clobber_alts = 0, biggest_mode = SImode, type = OP_IN, subreg_p = 0,
early_clobber = 0, regno = 1404, next = 0x40908f0}
{early_clobber_alts = 0, biggest_mode = SImode, type = OP_IN, subreg_p = 0,
early_clobber = 0, regno = 1427, next = 0x40908d0}
{early_clobber_alts = 0, biggest_mode = CCUmode, type = OP_IN, subreg_p = 0,
early_clobber = 0, regno = 33, next = 0x0}

and these hard regs:

{early_clobber_alts = 18446744073709551615, biggest_mode = CCmode, type =
OP_OUT, subreg_p = 0, early_clobber = 1, regno = 33, next = 0x0}

Marking the r33 entry early_clobber does not appear to be correct to me and
makes r33 dead before that insn.


The attached patch is a quick hack which prevents the early_clobber flag to be
set if the hard reg also appears also as input reg in an operand.

[Bug libstdc++/80504] missing qualification causes ADL to be used in std::ref / std::cref

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:31:36 2017
New Revision: 248237

URL: https://gcc.gnu.org/viewcvs?rev=248237=gcc=rev
Log:
PR libstdc++/80504 qualify calls to avoid ADL

Backport from mainline
2017-04-24  Jonathan Wakely  

PR libstdc++/80504
* include/std/functional (ref, cref): Qualify calls.
* testsuite/20_util/reference_wrapper/80504.cc: New test.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/20_util/reference_wrapper/80504.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/std/functional

[Bug libstdc++/67440] pretty-printing of a const set fails

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:31:07 2017
New Revision: 248233

URL: https://gcc.gnu.org/viewcvs?rev=248233=gcc=rev
Log:
PR libstdc++/67440 make pretty printers work with GDB 7.6 again

Backport from mainline
2017-03-16  Jonathan Wakely  

PR libstdc++/67440
* python/libstdcxx/v6/printers.py (find_type): Avoid gdb.Type.name
for GDB 7.6 compatibility, use gdb.Type.unqualified instead.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug libstdc++/80448] #include fails with Clang 5.0

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:31:22 2017
New Revision: 248236

URL: https://gcc.gnu.org/viewcvs?rev=248236=gcc=rev
Log:
PR libstdc++/80448 remove noexcept from defaulted functions

Backport from mainline
2017-04-19  Jonathan Wakely  

PR libstdc++/80448
* include/experimental/bits/fs_dir.h (directory_iterator)
(recursive_directory_iterator): Remove noexcept from defaulted
constructors.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/experimental/fs_dir.h

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:31:02 2017
New Revision: 248232

URL: https://gcc.gnu.org/viewcvs?rev=248232=gcc=rev
Log:
PR69699 document why __GLIBCXX__ macro is useless

Backport from mainline
2017-01-17  Jonathan Wakely  

PR libstdc++/69699
* doc/xml/manual/abi.xml (abi.versioning.history): Explain why the
_GLIBCXX__ macro is not useful. Remove redundant date information
and link to the GCC release timeline.
(abi.versioning.active): Move partial sentence into the previous
paragraph.
* doc/html/*: Regenerate.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/doc/html/manual/abi.html
branches/gcc-5-branch/libstdc++-v3/doc/xml/manual/abi.xml

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:30:57 2017
New Revision: 248231

URL: https://gcc.gnu.org/viewcvs?rev=248231=gcc=rev
Log:
PR 71444 define more error constants for mingw-w64

Backport from mainline
2016-12-21  Jonathan Wakely  

PR libstdc++/71444
* config/os/mingw32-w64/error_constants.h
(address_family_not_supported, address_in_use, address_not_available)
(already_connected, connection_aborted, connection_already_in_progress)
connection_refused, connection_reset, cross_device_link)
(destination_address_required, host_unreachable, message_size)
(network_down, network_reset, network_unreachable, no_buffer_space)
(no_protocol_option, not_a_socket, not_connected, operation_canceled)
(operation_in_progress, operation_not_supported, protocol_error)
(protocol_not_supported, too_many_links, too_many_symbolic_link_levels)
(value_too_large, wrong_protocol_type): Define.
(bad_message, identifier_removed, no_link, no_message_available)
(no_message, no_stream_resources, not_a_stream, owner_dead)
(state_not_recoverable, stream_timeout, text_file_busy): Define
conditionally.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Guard test for no_message with _GLIBCXX_HAVE_ENOMSG.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/config/os/mingw32-w64/error_constants.h
   
branches/gcc-5-branch/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 15:30:42 2017
New Revision: 248230

URL: https://gcc.gnu.org/viewcvs?rev=248230=gcc=rev
Log:
libstdc++/78236 fix past-the-end std::regex_iterator

Backport from mainline
2016-11-09  Tim Shen  

PR libstdc++/78236
* libstdc++-v3/include/bits/regex.h (regex_iterator::regex_iterator()):
Define end() as _M_pregex == nullptr.
* libstdc++-v3/include/bits/regex.tcc (regex_iterator::operator==(),
regex_iterator::operator++()): Fix operator==() and operator++() to
look at null-ness of _M_pregex on both sides.
* testsuite/28_regex/regression.cc: New testcase.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/regex.h
branches/gcc-5-branch/libstdc++-v3/include/bits/regex.tcc
branches/gcc-5-branch/libstdc++-v3/testsuite/28_regex/regression.cc

[Bug libstdc++/80504] missing qualification causes ADL to be used in std::ref / std::cref

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 5.5

[Bug target/80817] New: [missed optimization][x86] relaxed atomics

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 80817
   Summary: [missed optimization][x86] relaxed atomics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

Using gcc 7.1 on x86, the following

#include 

void increment_relaxed(std::atomic& counter) {

 atomic_store_explicit(,
  atomic_load_explicit(, std::memory_order_relaxed) + 1,
  std::memory_order_relaxed);
}

compiles to:

.cfi_startproc
movq(%rdi), %rax
addq$1, %rax
movq%rax, (%rdi)
ret
.cfi_endproc

while I would expect that 

.cfi_startproc
addq$1, (%rdi)
ret
.cfi_endproc

would be fine and more efficient. 

I also looked at 

atomic_fetch_add_explicit(, uint64_t(1), std::memory_order_relaxed); 

but that surprised me with

.cfi_startproc
lock addq   $1, (%rdi)
ret
.cfi_endproc

[Bug middle-end/80807] Improve FORTIFY_SOURCE protection for sprintf

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Overflow in calls to formatted functions with a format string containing
directives other than "%s" is not detected at compile time in GCC versions
prior to 7.  In GCC 7 the overflow is diagnosed even without _FORTIFY_SOURCE or
optimization.

I don't expect it to be feasible to backport the GCC 7 work to prior versions
so I'm going to resolve this request as a duplicate of the already implemented
enhancement request pr49905.

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

[Bug middle-end/49905] Better sanity checking on sprintf src & dest to produce warning for dodgy code ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||bugzilla@poradnik-webmaster
   ||a.com

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

[Bug libstdc++/80816] New: thread_local destructor on windows cause use-after-free

[ebarbaro at simteq dot com]

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

Bug ID: 80816
   Summary: thread_local destructor on windows cause
use-after-free
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebarbaro at simteq dot com
  Target Milestone: ---

Created attachment 41382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41382=edit
self contained example

Use of C++11 thread_local on mingw64 seems to suffer a use-after-free when the
thread_local object is destroyed.

The attached code prints "~foo():5" when executed normally. But if it is run
through gdb it prints "~foo():feeefeee".

"feeefeee" seems to be magic number used by the windows CRT debug HeapFree() to
mark deallocated blocks. It seems that the dynamic memory used to store the
thread_local object is free'd before the thread_local destructor is called.


gcc --version

gcc.exe (Rev3, Built by MSYS2 project) 6.3.0

[Bug libstdc++/80493] std::experimental::optional::swap is ill formed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 6.4, but not earlier because we don't have is_nothrow_swappable in
gcc-5-branch.

[Bug libstdc++/80811] out-of-line string members less efficient than they could be

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Thanks for the pointer!  It's a good question.  I'd expect non-modifying
algorithms to be pure.  Only one reason for them to have side-effects comes to
mind: to test whether they implement the standard requirements to the letter
(e.g., call traits_type::eq on every character, or maybe
allocator_type::address).  Can you think of some other use case?

Certainly the required specializations are pure.  If it does make a significant
difference in efficiency, I wonder if attribute pure could be applied to just
those by some enable_if trick.

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[me at hussam dot eu.org]

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

--- Comment #4 from Hussam Al-Tayeb  ---
(In reply to Ian Lance Taylor from comment #3)
> I can't recreate the problem.  It looks like the compilation step in the
> failing command is reading old versions of the .gox files, versions that use
> the old pkgpath rather than the new one introduced by the commit.  But if
> you are using a from-scratch build, I don't see where the old pkgpath could
> be coming from.
I will try again. My build script should be rm -rf ing the build directory,
recreating it, etc...
Perhaps something went wrong this time.
> Have you run `make install` to install an earlier version of the build? 
> Perhaps the compilation command is incorrectly looking at the installed .gox
> files before looking at the newly built ones.
Yes, I have a previous revision installed.

Anyway, I will try again and let you know.
Thank you.

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
I can't recreate the problem.  It looks like the compilation step in the
failing command is reading old versions of the .gox files, versions that use
the old pkgpath rather than the new one introduced by the commit.  But if you
are using a from-scratch build, I don't see where the old pkgpath could be
coming from.

Have you run `make install` to install an earlier version of the build? 
Perhaps the compilation command is incorrectly looking at the installed .gox
files before looking at the newly built ones.

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #9)
> Author: redi
> Date: Thu May 18 14:35:23 2017
> New Revision: 248212
> 
> URL: https://gcc.gnu.org/viewcvs?rev=248212=gcc=rev

Doh, I managed to cherry-pick a fix that was already on the branch.

[Bug libstdc++/80493] std::experimental::optional::swap is ill formed

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:45 2017
New Revision: 248216

URL: https://gcc.gnu.org/viewcvs?rev=248216=gcc=rev
Log:
PR libstdc++/80493 fix invalid exception specification

Backport from mainline
2017-04-24  Jonathan Wakely  

PR libstdc++/80493
* include/experimental/optional (optional::swap): Fix exception
specification.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/experimental/optional

[Bug libstdc++/80504] missing qualification causes ADL to be used in std::ref / std::cref

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:54 2017
New Revision: 248217

URL: https://gcc.gnu.org/viewcvs?rev=248217=gcc=rev
Log:
PR libstdc++/80504 qualify calls to avoid ADL

Backport from mainline
2017-04-24  Jonathan Wakely  

PR libstdc++/80504
* include/std/functional (ref, cref): Qualify calls.
* testsuite/20_util/reference_wrapper/80504.cc: New test.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/reference_wrapper/80504.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/std/functional

[Bug libstdc++/80448] #include fails with Clang 5.0

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:40 2017
New Revision: 248215

URL: https://gcc.gnu.org/viewcvs?rev=248215=gcc=rev
Log:
PR libstdc++/80448 remove noexcept from defaulted functions

Backport from mainline
2017-04-19  Jonathan Wakely  

PR libstdc++/80448
* include/experimental/bits/fs_dir.h (directory_iterator)
(recursive_directory_iterator): Remove noexcept from defaulted
constructors.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/experimental/bits/fs_dir.h

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:23 2017
New Revision: 248212

URL: https://gcc.gnu.org/viewcvs?rev=248212=gcc=rev
Log:
PR libstdc++/80137 use std::nextafter instead of looping

Backport from mainline
2017-03-28  Jonathan Wakely  

PR libstdc++/80137
* include/bits/random.tcc (generate_canonical): Use std::nextafter
or numeric_limits::epsilon() to reduce out-of-range values.
* testsuite/26_numerics/random/uniform_real_distribution/operators/
64351.cc: Verify complexity requirement is met.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:12 2017
New Revision: 248210

URL: https://gcc.gnu.org/viewcvs?rev=248210=gcc=rev
Log:
PR69699 document why __GLIBCXX__ macro is useless

Backport from mainline
2017-01-17  Jonathan Wakely  

PR libstdc++/69699
* doc/xml/manual/abi.xml (abi.versioning.history): Explain why the
_GLIBCXX__ macro is not useful. Remove redundant date information
and link to the GCC release timeline.
(abi.versioning.active): Move partial sentence into the previous
paragraph.
* doc/html/*: Regenerate.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/abi.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/bugs.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-6-branch/libstdc++-v3/doc/html/manual/using_macros.html
branches/gcc-6-branch/libstdc++-v3/doc/xml/manual/abi.xml

[Bug libstdc++/67440] pretty-printing of a const set fails

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:35:18 2017
New Revision: 248211

URL: https://gcc.gnu.org/viewcvs?rev=248211=gcc=rev
Log:
PR libstdc++/67440 make pretty printers work with GDB 7.6 again

Backport from mainline
2017-03-16  Jonathan Wakely  

PR libstdc++/67440
* python/libstdcxx/v6/printers.py (find_type): Avoid gdb.Type.name
for GDB 7.6 compatibility, use gdb.Type.unqualified instead.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:34:56 2017
New Revision: 248208

URL: https://gcc.gnu.org/viewcvs?rev=248208=gcc=rev
Log:
PR 71444 define more error constants for mingw-w64

Backport from mainline
2016-12-21  Jonathan Wakely  

PR libstdc++/71444
* config/os/mingw32-w64/error_constants.h
(address_family_not_supported, address_in_use, address_not_available)
(already_connected, connection_aborted, connection_already_in_progress)
connection_refused, connection_reset, cross_device_link)
(destination_address_required, host_unreachable, message_size)
(network_down, network_reset, network_unreachable, no_buffer_space)
(no_protocol_option, not_a_socket, not_connected, operation_canceled)
(operation_in_progress, operation_not_supported, protocol_error)
(protocol_not_supported, too_many_links, too_many_symbolic_link_levels)
(value_too_large, wrong_protocol_type): Define.
(bad_message, identifier_removed, no_link, no_message_available)
(no_message, no_stream_resources, not_a_stream, owner_dead)
(state_not_recoverable, stream_timeout, text_file_busy): Define
conditionally.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Guard test for no_message with _GLIBCXX_HAVE_ENOMSG.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/config/os/mingw32-w64/error_constants.h
   
branches/gcc-6-branch/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 14:34:50 2017
New Revision: 248207

URL: https://gcc.gnu.org/viewcvs?rev=248207=gcc=rev
Log:
libstdc++/78236 fix past-the-end std::regex_iterator

Backport from mainline
2016-11-09  Tim Shen  

PR libstdc++/78236
* libstdc++-v3/include/bits/regex.h (regex_iterator::regex_iterator()):
Define end() as _M_pregex == nullptr.
* libstdc++-v3/include/bits/regex.tcc (regex_iterator::operator==(),
regex_iterator::operator++()): Fix operator==() and operator++() to
look at null-ness of _M_pregex on both sides.
* testsuite/28_regex/regression.cc: New testcase.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/regex.h
branches/gcc-6-branch/libstdc++-v3/include/bits/regex.tcc
branches/gcc-6-branch/libstdc++-v3/testsuite/28_regex/regression.cc

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[me at hussam dot eu.org]

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

--- Comment #2 from Hussam Al-Tayeb  ---
(In reply to Ian Lance Taylor from comment #1)
> Are you doing a from-scratch build or an incremental build?  Try removing
> the x86_64-pc-linux-gnu/libgo directory to force it to be rebuilt.

I was doing a from-scratch build. It avoids accidental issues.

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Are you doing a from-scratch build or an incremental build?  Try removing the
x86_64-pc-linux-gnu/libgo directory to force it to be rebuilt.

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug middle-end/80815] New: wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

Bug ID: 80815
   Summary: wrong code because of broken runtime alias check in
vectorizer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Hi,
I was suspecting that vect_prune_runtime_alias_check_list is broken, now I can
create a test case for it:
#include 

int arr[2048];

int
foo (int *a, int *b)
{
  int i;
  int *a1 = a;
  int *a0 = a1 - 512;
  for (i = 0; i < 500; i++)
{
  *b = *a0 + *a1;
  b++;
  a0--;
  a1--;
}
  return 0;
}

int main (void)
{
  int *a = [1027];
  int *b = [1024];

  int i;
  for (i = 0; i < 2048; i++)
arr[i] = i;

  foo (a, b);

  for (i = 0; i < 2048; i++)
fprintf (stdout, "%d: %d\n", i, arr[i]);

  return 0;
}

Compiled on x86_64 with below two commands:

Binary 1)
$ ../gcc -O2 -fno-inline ../x.c -o x.exe
$ ./x.exe >/tmp/x

Binary 2)
../gcc -Ofast -fno-inline ../x.c -o y.exe
$ ./y.exe >/tmp/y

We have:
$ diff /tmp/x /tmp/y
1027,1028c1027,1028
< 1026: 2053
< 1027: 2054
---
> 1026: 1538
> 1027: 1536

I think the root cause is in below code:

  /* Generally the new segment length is the maximum of the
 left segment size and the right segment size plus the distance.
 ???  We can also build tree MAX_EXPR here but it's not clear this
 is profitable.  */
  else if (tree_fits_uhwi_p (dr_a1->seg_len)
   && tree_fits_uhwi_p (dr_a2->seg_len))
{
  unsigned HOST_WIDE_INT seg_len_a1 = tree_to_uhwi
(dr_a1->seg_len);
  unsigned HOST_WIDE_INT seg_len_a2 = tree_to_uhwi
(dr_a2->seg_len);
  dr_a1->seg_len = size_int (MAX (seg_len_a1, diff + seg_len_a2));
  do_remove = true;
}

Here dr_a1 is *a0, dr_a2 is *a1 and dr_b1/dr_b2 is *b, and their ranges is like

-->
a0_en  a0a1_endb   a1   b_end

It should merge range_a0/range_a1 and result in range of a1, but because:
1) seg_len_a1 wraps to a large unsigned integer;
2) seg_len_a2 wraps to a large unsigned integer;
3) diff + seg_len_a2 wraps again to a small unsigned integer;
The program falsely merges ranges to range_a0.  As a result, loop is vectorized
because range_a0 and range_b are considered not alias to each other.  This is
wrong because *a1 and *b overlaps at the first several iterations and have
circle in dependence.

[Bug c++/80780] Front-end support needed for experimental::source_location

[lbjonnes at cisco dot com]

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

--- Comment #4 from lbjonnes at cisco dot com ---
"redi at gcc dot gnu.org"  writes:

| https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780
>
| Bug ID: 80780
|Summary: Front-end support needed for
| experimental::source_location
|Product: gcc
|Version: 8.0
| Status: UNCONFIRMED
|   Severity: normal
|   Priority: P3
|  Component: c++
|   Assignee: unassigned at gcc dot gnu.org
|   Reporter: redi at gcc dot gnu.org
|   Target Milestone: ---
>
| I've just added a partial implementation of  to
| trunk (r248110).
>
| The missing pieces need some FE help.
>
| 1) because the location info returned by source_location::current() should be
| the location of the caller the current implementation uses default arguments:
>
|   struct source_location
|   {
| // 14.1.2, source_location creation
| static constexpr source_location
| current(const char* __file = __builtin_FILE(),
| const char* __func = __builtin_FUNCTION(),
| int __line = __builtin_LINE(),
| int __col = 0) noexcept

btw. adding a __builtin_COLUMN is quite easy, and I had a patch ealier
to do just that. I won't send it though since I have now papers in order
and the likelyhood of me getting said papers are slim.

| {
|   source_location __loc;
|   __loc._M_file = __file;
|   __loc._M_func = __func;
|   __loc._M_line = __line;
|   __loc._M_col = __col;
|   return __loc;
| }
>
| This works OK, but means the signature of the function doesn't match the one
in
| the TS (which has no parameters). The standard does allow us to add
parameters
| with default arguments to member functions, but it might be nice if it wasn't
| needed. I'm not sure how best to do that. Maybe make the FE recognise
| std::experimental::fundamentals_v2::source_location::current() as magic, so
| that location info inside the function uses the location of the caller? Maybe
| add a new attribute to perform said magic for any inline function? (If
| current() is called indirectly, e.g. through a function pointer, the result
is
| unspecified so the magic doesn't need to work when the function isn't
inlined).
>
| 2) source_location::current().function_name() uses __func__ which is not very
| descriptive in C++. It would be nice to have a __builtin_PRETTY_FUNCTION to
get
| a better function name than __builtin_FUNCTION provides.
>
| 3) source_location::column().column() always returns zero, because there's no
| "__builtin_column" to get a column number, the way __builtin_LINE gives a
line
| number.
>
>
| I mistakenly though that calling current() in a default member initializer
gave
| the wrong locations, but it does the right thing (giving the location of the
| constructor body that initializes the member).

[Bug libgomp/80809] Multi-free error for variable size array used within OpenMP task

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll handle this.

[Bug libgomp/80809] Multi-free error for variable size array used within OpenMP task

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
The double-free diagnostic is due to heap corruption via OOB access in
main._omp_cpyfn.2, -fsanitize=address catches this, even with OMP_NUM_THREADS=1
and 'x' given as 3.

I think there are two issues here, first is that 'data' becomes implicitly
firstprivate in the task region while it should have been shared, and second is
that omp-expand gets confused about the size of omp_data_o passed to GOMP_task:

  :
  D.2629 = D.2628 + 35;
  D.2630 = (long int) D.2629;
  D.2631 = D.2630 & -8;
  __builtin_GOMP_task (main._omp_fn.1, &.omp_data_o.11, main._omp_cpyfn.2,
D.2631, 8, 1, 0, 0B);

where D.2628 is not initialized.

I think the issues are separate, the second one remains even with
'firstprivate(data)' on the enclosing parallel which makes it implicitly
firstprivate on the task region iiuc.

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #11 from Pedro Alves  ---
Yes, Cygwin and MinGW ABIs are different, and GDB doesn't know about it.  It
assumes Cygwin == MinGW.  I'll follow up in the gdb tracker.

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[jrose.manila at gmail dot com]

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

--- Comment #10 from Julian Rose  ---
(In reply to Julian Rose from comment #9)
> (In reply to Jonathan Wakely from comment #8)
> > It uses the ms-abi for calling conventions but LP64, no LLP64:
> > https://cygwin.com/cygwin-ug-net/programming.html
> > 
> > That's by design, and so GCC's behaviour is not a bug. If GDB is
> > inconsistent that's not a GCC bug.
> 
> Ok, that's good for me. 
> 
> Thanks all for the replies. I shall do as comment 6.

https://sourceware.org/bugzilla/show_bug.cgi?id=21500

[Bug fortran/79968] diagnostics: merge similar diagnostics containing -fdec-structure

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/79968] diagnostics: merge similar diagnostics containing -fdec-structure

[foreese at gcc dot gnu.org]

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

--- Comment #3 from Fritz Reese  ---
Author: foreese
Date: Thu May 18 10:24:37 2017
New Revision: 248188

URL: https://gcc.gnu.org/viewcvs?rev=248188=gcc=rev
Log:
2017-05-18  Fritz Reese 

PR fortran/79968

gcc/fortran/ChangeLog:

PR fortran/79968
* decl.c (match_attr_spec, gfc_match_automatic,
gfc_match_static, gfc_match_structure_decl): Unify diagnostic
errors regarding -fdec options.
* io.c (match_dec_etag, match_dec_vtag, match_dec_ftag): Ditto.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/io.c

[Bug go/80814] [7 Regression] commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-linux
   Priority|P3  |P1
  Known to work||7.1.0
Version|unknown |7.1.1
   Target Milestone|--- |7.2
Summary|commit  |[7 Regression] commit
   |aa443150c83535fedccb3dee80d |aa443150c83535fedccb3dee80d
   |aa7e01fafd92d causes a  |aa7e01fafd92d causes a
   |build error.|build error.

[Bug c++/79651] ICE on invalid c++ code in lambda_expr_this_capture in lambda.c:718

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-18
 Ever confirmed|0   |1

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Breaks at least g++.dg/warn/Wstrict-aliasing-6.C which I think is expected
fallout.

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[jrose.manila at gmail dot com]

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

--- Comment #9 from Julian Rose  ---
(In reply to Jonathan Wakely from comment #8)
> It uses the ms-abi for calling conventions but LP64, no LLP64:
> https://cygwin.com/cygwin-ug-net/programming.html
> 
> That's by design, and so GCC's behaviour is not a bug. If GDB is
> inconsistent that's not a GCC bug.

Ok, that's good for me. 

Thanks all for the replies. I shall do as comment 6.

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> The set1 == 0 stuff has been added in r136679.

Yep, to not regress some -Wstrict-aliasing testcase I think.  I'll test

Index: gcc/c-family/c-warn.c
===
--- gcc/c-family/c-warn.c   (revision 248179)
+++ gcc/c-family/c-warn.c   (working copy)
@@ -537,10 +537,10 @@ strict_aliasing_warning (tree otype, tre
= get_alias_set (TREE_TYPE (TREE_OPERAND (expr, 0)));
  alias_set_type set2 = get_alias_set (TREE_TYPE (type));

- if (set1 != set2 && set2 != 0
- && (set1 == 0
- || (!alias_set_subset_of (set2, set1)
- && !alias_sets_conflict_p (set1, set2
+ if (set2 != 0
+ && set1 != set2
+ && !alias_set_subset_of (set2, set1)
+ && !alias_sets_conflict_p (set1, set2))
{
  warning (OPT_Wstrict_aliasing, "dereferencing type-punned "
   "pointer will break strict-aliasing rules");

[Bug go/80814] New: commit aa443150c83535fedccb3dee80daa7e01fafd92d causes a build error.

[me at hussam dot eu.org]

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

Bug ID: 80814
   Summary: commit aa443150c83535fedccb3dee80daa7e01fafd92d causes
a build error.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: me at hussam dot eu.org
CC: cmang at google dot com
  Target Milestone: ---

The following commit causes a build error in gcc-7-branch here
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=aa443150c83535fedccb3dee80daa7e01fafd92d
reverting it fixes the build error.

This is what I get:

/home/hussam/cache/toolkit/gcc/src/gcc-build/./gcc/gccgo
-B/home/hussam/cache/toolkit/gcc/src/gcc-build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
 -g -march=x86-64 -mtune=native -O2  -fstack-protector-strong 
-static-libstdc++ -static-libgcc  -L ../x86_64-pc-linux-gnu/libgo -L
../x86_64-pc-linux-gnu/libgo/.libs -o go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/bug.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/build.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/clean.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/context.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/discovery.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/doc.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/env.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/fix.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/fmt.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/generate.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/get.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/go11.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/help.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/http.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/list.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/main.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/note.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/pkg.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/run.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/signal.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/signal_unix.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/test.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/testflag.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/tool.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/vcs.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/version.go
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/vet.go
../x86_64-pc-linux-gnu/libgo/zstdpkglist.go zdefaultcc.go  
/tmp/ccaa6GxL.o: In function `__go_init_main':
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go:1648:
undefined reference to `golang_org_x_crypto_chacha20poly1305..import'
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go:1648:
undefined reference to `golang_org_x_text_transform..import'
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go:1648:
undefined reference to `golang_org_x_net_http2_hpack..import'
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go:1648:
undefined reference to `golang_org_x_text_unicode_norm..import'
/home/hussam/cache/toolkit/gcc/src/gcc/gotools/../libgo/go/cmd/go/alldocs.go:1648:
undefined reference to `golang_org_x_text_width..import'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:673: go] Error 1
make[2]: Leaving directory
'/home/hussam/cache/toolkit/gcc/src/gcc-build/gotools'
make[1]: *** [Makefile:15054: all-gotools] Error 2
make[1]: Leaving directory '/home/hussam/cache/toolkit/gcc/src/gcc-build'
make: *** [Makefile:937: all] Error 2

[Bug libstdc++/59170] pretty printers: end iterator invalid pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #17)
> The only thing remaining is to add checks for debug iterators to detect when
> they are past-the-end.

Re-opening, I forgot about this part.

[Bug libstdc++/59170] pretty printers: end iterator invalid pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #20 from Jonathan Wakely  ---
Fixed for 5.5

[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
Fixed for 5.5

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
It uses the ms-abi for calling conventions but LP64, no LLP64:
https://cygwin.com/cygwin-ug-net/programming.html

That's by design, and so GCC's behaviour is not a bug. If GDB is inconsistent
that's not a GCC bug.

[Bug libstdc++/59170] pretty printers: end iterator invalid pointer

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 09:23:43 2017
New Revision: 248183

URL: https://gcc.gnu.org/viewcvs?rev=248183=gcc=rev
Log:
PR59170 make pretty printers check for singular iterators

Backport from mainline
2016-12-15  Jonathan Wakely  

PR libstdc++/59170
* python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string)
(StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string)
(StdRbtreeIteratorPrinter.to_string)
(StdDequeIteratorPrinter.to_string): Add check for value-initialized
iterators.
* testsuite/libstdc++-prettyprinters/simple.cc: Test them.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
   
branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc

[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Author: redi
Date: Thu May 18 09:23:38 2017
New Revision: 248182

URL: https://gcc.gnu.org/viewcvs?rev=248182=gcc=rev
Log:
PR59161 make pretty printers always return strings

Backport from mainline
2016-12-15  Jonathan Wakely  

PR libstdc++/59161
* python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string)
(StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string)
(StdRbtreeIteratorPrinter.to_string, StdDequeIteratorPrinter.to_string)
(StdDebugIteratorPrinter.to_string): Return string instead of
gdb.Value.
* testsuite/libstdc++-prettyprinters/59161.cc: New test.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/libstdc++-prettyprinters/59161.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #18 from Paolo Carlini  ---
Thanks Jon. It occurs to me that bugs depending on DRs not yet resolved
normally are suspended. Let's do that here too.

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
Created attachment 41381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41381=edit
Patch in testing

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #3)
> This is caused by r243527.

Thanks.  FYI, the above revision just triggers the issue.

I have a patch.

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

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

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

--- Comment #7 from Andreas Schwab  ---
Why shouldn't gcc configured for cygwin use the windows ABI?

[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I see something similar, without the error message about latch.

destDir/testFile.1790.c: In function ‘func_19.part.6’:
destDir/testFile.1790.c:935:1: error: size of loop 1 should be 14, not 15
 }
 ^
destDir/testFile.1790.c:935:1: internal compiler error: in
verify_loop_structure, at cfgloop.c:1644

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Julian Rose from comment #3)
> Would it be appropriate to close this bug report and raise a new one at
> https://sourceware.org/bugzilla/?

Yes please. GCC is correct.

[Bug libstdc++/80810] char_traits members taking reference arguments instead of values

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes I noticed this recently, and plan to change it.

For the char and wchar_t specializatiosn it looks like we simply never changed
them to match the C++11 change. The char16_t and char32_t specializations that
were added in C++11 should have been added with the new signatures, since they
never existed in the old form.

[Bug middle-end/80807] Improve FORTIFY_SOURCE protection for sprintf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-18
  Component|c   |middle-end
  Known to work||7.1.0
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0

--- Comment #1 from Richard Biener  ---
I get with GCC 7:

> gcc-7 t.c -O3 -D_FORTIFY_SOURCE=2 -Wall -S
t.c: In function ‘test’:
t.c:6:29: warning: ‘__builtin___sprintf_chk’ writing a terminating nul past the
end of the destination [-Wformat-overflow=]
   sprintf(buf, "%c%c", a, b);
 ^
In file included from /usr/include/stdio.h:936:0,
 from t.c:1:
/usr/include/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output 3
bytes into a destination of size 2
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  ^~
   __bos (__s), __fmt, __va_arg_pack ());
   ~

confirmed with GCC 5 and 6.

[Bug c/80806] gcc does not warn if local array is memset only

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/80808] [7/8 Regression] gnupg miscompilation on arm starting with r241660

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug sanitizer/80797] -fsanitize=null doesn't instrument >x

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Vittorio Zecca from comment #4)
> I applied your patch to version 8 trunk 247930 and it seems to work,
> but on your example I get 
> 
> ubsan-1.c:10:8: runtime error: member access within null pointer of type
> 'struct S'
> ubsan-1.c:11:8: runtime error: member access within null pointer of type
> 'struct S'

Thanks for testing.

> pointing at column 8 to v and v2.
> Shouldn't they point to s or i?

Yeah, they should.

[Bug sanitizer/80797] -fsanitize=null doesn't instrument >x

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 8.

[Bug sanitizer/80797] -fsanitize=null doesn't instrument >x

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 18 07:18:24 2017
New Revision: 248179

URL: https://gcc.gnu.org/viewcvs?rev=248179=gcc=rev
Log:
PR sanitizer/80797
* ubsan.c (instrument_null): Unwrap ADDR_EXPRs.
(pass_ubsan::execute): Call gimple_assign_single_p instead of
gimple_assign_load_p.

* c-c++-common/ubsan/null-12.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/null-12.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #12 from Vittorio Zecca  ---
Bug still present in gcc 8.0.0 trunk 247930.

In this test case:

  subroutine extract(this, v)
  type :: foo
   real :: v
  end type
  class(foo), target :: this(:)
  real, pointer :: v(:)
  select type (this)
  class is (foo)
   v => this(1:2)%v
  end select
  end subroutine