[Bug tree-optimization/89617] memmove used even after runtime guard against overlap

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't understand what in the standard you think prevents partial overlap. 
Arrays aren't like structures that can't partially overlap.

[Bug go/89171] Wrong default for GOROOT

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

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

Andreas Schwab  changed:

   What|Removed |Added

Summary|FAIL: go/build  |Wrong default for GOROOT

--- Comment #6 from Andreas Schwab  ---
It doesn't make sense to use ${prefix} as the default for GOROOT since most of
the files down there are unrelated.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  7 08:18:36 2019
New Revision: 269451

URL: https://gcc.gnu.org/viewcvs?rev=269451&root=gcc&view=rev
Log:
PR c++/89585
* doc/extend.texi (Basic Asm): Document qualifiers are not allowed
at toplevel.

* parser.c (cp_parser_asm_definition): Parse asm qualifiers even
at toplevel, but diagnose them.

* g++.dg/asm-qual-3.C: Adjust expected diagnostics.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/asm-qual-3.C

[Bug c++/89616] Parameter names can be redeclared in outermost block of a function definition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-07
 Ever confirmed|0   |1

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  7 08:32:09 2019
New Revision: 269452

URL: https://gcc.gnu.org/viewcvs?rev=269452&root=gcc&view=rev
Log:
PR c++/89585
* parser.c (cp_parser_asm_definition): Parse asm qualifiers even
at toplevel, but diagnose them.

* g++.dg/asm-qual-3.C: Adjust expected diagnostics.

Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/g++.dg/asm-qual-3.C

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

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

--- Comment #28 from Harald van Dijk  ---
Okay, the version without a warning was checked in. Should I have suggested the
warning elsewhere?

[Bug tree-optimization/89617] memmove used even after runtime guard against overlap

[jzwinck at gmail dot com]

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

--- Comment #2 from John Zwinck  ---
Jakub, here is a similar example using structs instead of arrays.  It still
generates different code, with RESTRICT giving memcpy instead of mov, but no
RESTRICT still using memmove which is suboptimal.

struct S
{
int arr[3];
};

inline void Copy(S& __restrict__ dest, const S& __restrict__ src)
{
std::copy(std::begin(src.arr), std::end(src.arr), dest.arr);
}

void f2(S& dest, const S& src)
{
if (&dest != &src)
{
#ifdef RESTRICT
Copy(dest, src);
#else
std::copy(std::begin(src.arr), std::end(src.arr), dest.arr);
#endif
}
}

Demo: https://godbolt.org/z/zmJTLU

That being said, Clang thinks that casting a larger array to a smaller one is
undefined behavior, so can you give a more specific example of when two arrays
might overlap yet not have the same starting address?

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[eb at emlix dot com]

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

--- Comment #29 from Rolf Eike Beer  ---
I guess this would also need a backport into gcc-7-branch as the "asm inline"
changes were backported also there, no?

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
(In reply to Harald van Dijk from comment #28)
> Okay, the version without a warning was checked in. Should I have suggested
> the warning elsewhere?

For 8.x we do not want to warn, that will break people building with -Werror.
For 9.x, Jason said that perhaps we should warn instead of error for volatile,
so I'll submit incremental patch.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek  ---
Created attachment 45914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45914&action=edit
gcc9-pr89585.patch

Incremental patch to warn for GCC 9 instead of error.

[Bug c++/89612] [7/8/9 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/89610] Move-assigning a pmr container sometimes copies the elements instead of moving them

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||wrong-code
Version|unknown |8.3.1

--- Comment #1 from Richard Biener  ---
Suppose you tested GCC 8.

[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #18 from Thomas Koenig  ---
(In reply to Valeriy E. Ushakov from comment #16)
> Why do I have to go through this strange ritual of
> taking this patch out of gcc's own bugtracker and sending it to gcc's own
> list for proposed patches?

I am knowledge-free about this particular area, just wanted to make
some general comments.

Several reasons, some of them overlapping.

This is how gcc development operates.  For a large project like gcc
with many volunteers, you need to have rules, and in general, people
should stick to them.

Posting to gcc-patches gives everybody a chance to look at patches
and speak up if they have any concerns or advice.  Not very many
people read individual PRs.

Finally, it's a very good thing that you need approval from somebody.
Compilers are notoriously complex beasts, and regressions for some
corner case can creep in quite easily - less easily if somebody
else has a look.

Of course, another thing that can be done is to add a maintainer for
a particular area to the PR. I have done so with this.

[Bug c++/89585] GCC 8.3: asm volatile no longer accepted at file scope

[harald at gigawatt dot nl]

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

--- Comment #32 from Harald van Dijk  ---
(In reply to Jakub Jelinek from comment #30)
> For 8.x we do not want to warn, that will break people building with -Werror.
> For 9.x, Jason said that perhaps we should warn instead of error for
> volatile, so I'll submit incremental patch.

Good point about -Werror.

The suggestion for a warning was based on it remaining an error in GCC 9. If it
is going to be downgraded to a warning there, there's no point in a warning in
GCC 8, so I'm happy with that approach. Thank you!

One comment about the patch: it looks like resetting volatile_p (which you
removed) and inline_p (which is still in) will have no effect, since the one
use is conditional on parser->in_function_body anyway. Am I missing a use
there? If not, is that in because the code is easier to understand if it is, or
is it an oversight?

The reset of goto_p affects how the remainder will be parsed, so that
definitely does have an effect.

[Bug tree-optimization/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The compile time evaluation of a loop to determine final values when scev can't
do it is also mentioned in PR87465.

Perhaps we can have some valueization where we keep current values of SSA_NAMEs
(dunno if it should use SCCVN stuff or just a SSA_NAME -> invariant mapping),
and then just start from loop preheader edge, valueize non-virtual PHIs, then
for each non-debug statement gimple_fold_stmt_to_constant and store that to the
valueization data structure if it succeeds, otherwise punt.  Have some param
for upper limit on how many statements we want to evaluate at most, probably
need some special code to deal with GIMPLE_CONDs, GIMPLE_SWITCH etc.
Maybe extend it at some point so that it can handle also some non-invariants
(like say having the result be some base SSA_NAME + invariant or some similar
exceptions).  Guess it could help also with some vectorized loops we don't
completely unroll, I think we have some PRs where vectorization disabled final
value computation, if we'd without unrolling managed to constant evaluate the
outcome of the loop, they'd be fixed too.

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #5 from Paolo Carlini  ---
Seems fixed in trunk: shall we remove the regression marker?

[Bug c/89618] New: Inner loop won't vectorize unless dummy statement is included

[moritz.kreutzer at siemens dot com]

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

Bug ID: 89618
   Summary: Inner loop won't vectorize unless dummy statement is
included
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz.kreutzer at siemens dot com
  Target Milestone: ---

We have a loop in which we are scattering data to an array of length "n" where
can assure no write conflicts only within confined ranges of length "m". Our
implementation includes splitting this loop into an outer and an inner loop and
specifying "#pragma GCC ivdep" for the inner loop:


https://godbolt.org/z/ulnRrk
===
const int m = 32;

for (int j = 0; j < n/m; ++j)
{
  int const start = j*m;
  int const end = (j+1)*m;

  #pragma GCC ivdep
  for (int i = start; i < end; ++i)
  {
a[off[i]] = a[i] < 0 ? a[i] : 0;
  }

#ifdef VECTORIZE
  // dummy statement required for vectorization
  if (a[0] == 0.) a[0] = 0.; 
#endif
}
===

The issue is that GCC (trunk and any earlier version) won't vectorize the code
unless we add the obviously useless dummy statement (guarded by "#ifdef
VECTORIZE"). This is counterintuitive, involves some overhead which we want to
avoid, and may be cumbersome or even impossible to implemented depending on the
specific structure of the inner loop (the body may be passed as a lambda,
etc.).

Without knowing about the internals of GCC, I can imagine that in the absence
of the dummy statment, GCC jams the loops and tries and fails to vectorize the
remaining (outer) loop because it doesn't have an "ivdep" pragma. Can we avoid
this behavior? If my thinking is correct, something like ICC's "#pragma
nounroll_and_jam" could work, but GCC doesn't (officially?) support anything
like it as far as I can see. 

Thanks,
Moritz

[Bug c++/89619] New: g++ does not terminate

[stas.pyatykh at gmail dot com]

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

Bug ID: 89619
   Summary: g++ does not terminate
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stas.pyatykh at gmail dot com
  Target Milestone: ---

Created attachment 45915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45915&action=edit
test program

g++ does not terminate while compiling the attached code. No output is
produced. The code does not have #include or other preprocessor directives.

The command line is
g++ test.cpp -O1

The compiler version is 7.3.0.
The operating system is Ubuntu 18.04 LTS.

The output of g++ -v is

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --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-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04


The command line 
g++ test.cpp -O0
terminates successfully.

[Bug tree-optimization/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
So the only odd behavior of VRP I see with the new iteration order is:

+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+Argument #0 (5 -> 6 executable)
+   _3: ~[0B, 0B]
+Argument #1 (8 -> 6 executable)
+   __s_19: [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void
*)&__PRETTY_FUNCTION__ + 10B]]
+Meeting
+  ~[0B, 0B]
+and
+  [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void *)&__PRETTY_FUNCTION__
+ 10B]]
+to
+  ~[0B, 0B]
+Found new range for __s_16: [_3, -1B]

so how did we end up adjusting ~[0B, 0B] to [_3, -1B] (when we usually
prefer NULL/non-NULL for pointers)?

Then we are appearantly re-visiting the PHI node:

+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+Argument #0 (5 -> 6 executable)
+   _3: ~[0B, 0B]
+Argument #1 (8 -> 6 executable)
+   __s_19: ~[0B, 0B]
+Meeting
+  ~[0B, 0B]
+and
+  ~[0B, 0B]
+to
+  ~[0B, 0B]
+

but not finding a new range (so we indeed prefer the "old" one somehow).

We first discover this via

+Visiting PHI node: # PT = null { D.29657 } (nonlocal)
+__s_16 = PHI <_3(5), __s_19(8)>
+Argument #0 (5 -> 6 executable)
+   _3: ~[0B, 0B]
+Argument #1 (8 -> 6 executable)
+   __s_19: [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void
*)&__PRETTY_FUNCTION__ + 10B]]
+Meeting
+  ~[0B, 0B]
+and
+  [&MEM[(void *)&__PRETTY_FUNCTION__ + 10B], &MEM[(void *)&__PRETTY_FUNCTION__
+ 10B]]
+to
+  ~[0B, 0B]
+Found new range for __s_16: [_3, -1B]

[Bug target/89578] [9 Regression] 5% runtime regression for 481.wrf at -Ofast -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
One difference that is clearly visible is missed vectorization of

 module_small_step_em.fppized.f90:1399:14: note:  LOOP VECTORIZED
 module_small_step_em.fppized.f90:1376:14: note:  LOOP VECTORIZED
-module_small_step_em.fppized.f90:1376:14: note:  LOOP VECTORIZED
 module_small_step_em.fppized.f90:1354:14: note:  LOOP VECTORIZED

This is the following inner loop which we vectorize before the change but not
after.  Before we have

create runtime check for data references MEM[(float[0:D.14326] *)_891][_13070]
and MEM[(float[0:D.14326] *)_891][_4424]
module_small_step_em.fppized.f90:1376:14: note:  created 1 versioning for alias
checks.
module_small_step_em.fppized.f90:1376:14: optimized:  loop versioned for
vectorization because of possible aliasing

where afterwards

module_small_step_em.fppized.f90:1376:14: missed:   number of versioning for
alias run-time tests exceeds 10 (--param vect-max-version-for-alias-checks)

SUBROUTINE advance_w( w, rw_tend, ww, u, v,   &
...
! Jammed 3 doubly nested loops over k/i into 1 for slight improvement
! in efficiency.  No change in results (bit-for-bit). JM 20040514
! (left a blank line where the other two k/i-loops were)
!
DO k=2,k_end
  DO i=i_start, i_end
w(i,k,j)=w(i,k,j)+dts*rw_tend(i,k,j)   &
 + msft_inv(i)*cqw(i,k,j)*(&
+.5*dts*g*mut_inv(i)*rdn(k)*   &
 (c2a(i,k  ,j)*rdnw(k  )   &
*((1.+epssm)*(rhs(i,k+1  )-rhs(i,k))   &
 +(1.-epssm)*(ph(i,k+1,j)-ph(i,k  ,j)))&
 -c2a(i,k-1,j)*rdnw(k-1)   &
*((1.+epssm)*(rhs(i,k)-rhs(i,k-1  ))   &
 +(1.-epssm)*(ph(i,k  ,j)-ph(i,k-1,j)  &

+dts*g*msft_inv(i)*(rdn(k)*&
 (c2a(i,k  ,j)*alt(i,k  ,j)*t_2ave(i,k  ,j)&
 -c2a(i,k-1,j)*alt(i,k-1,j)*t_2ave(i,k-1,j))   &
   +(rdn(k)*(c2a(i,k  ,j)*alb(i,k  ,j) &
-c2a(i,k-1,j)*alb(i,k-1,j))*mut_inv(i)-1.) &
 *muave(i,j))
  ENDDO
ENDDO


There is almost no difference in the IL after if-conversion but changes
like

-  _14697 = MEM[(float[0:D.14440] *)_959 clique 40 base 47][_15604];
+  _14697 = MEM[(float[0:D.14440] *)_959 clique 71 base 47][_15604];
   _9355 = _14697 * 4.905000209808349609375e+0;
-  _9371 = MEM[(float[0:D.14436] *)_957 clique 40 base 28][_15604];
+  _9371 = MEM[(float[0:D.14436] *)_957 clique 71 base 28][_15604];

which is introduced by unroll-and-jam by means of unrolling the outer loop
once.  The restrict clique remapping is strictly speaking required here.

There are of course cases where remapping can be elided but they are
difficult to reconstruct.

Basically each clique > 1 belongs to a specific inline block and whether
we need to remap it when copying a stmt depends on whether we duplicate
"within" that block or we duplicate the block itself.

A good "hint" would be (for example for unroll-and-jam) whether cliques
mentioned in the to be copied loop are also mentioned in stmts belonging
exclusively to the outer loop that is unrolled (but then they could have
been moved there by invariant motion for example).

I'm not sure if we want to look at the BLOCK tree.  Or whether we want to
build a similar thing into the loop structure, noting inline contexts
(the single clique that needs not remapping when copying the loop).

Note I haven't been able to verify whether the above loop is executed
at all but -fno-loop-unroll-and-jam makes performance equal (and faster
than ever...).

[Bug c++/89619] g++ does not terminate

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-07
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It terminates just fine for me - it's just a "bit" slow.  GCC 8 is way faster.

> /usr/bin/time /space/rguenther/install/gcc-7.3/bin/g++ t.C -O
61.43user 0.06system 1:01.50elapsed 99%CPU (0avgtext+0avgdata
142964maxresident)k
0inputs+1016outputs (0major+55908minor)pagefaults 0swaps

The issue is the initializer is unrolled in GCC 7 while it is a loop in later
releases.  IIRC there was a C++ FE bug fixed, but not a regression, so it
probably won't be backported.

[Bug c++/89619] g++ does not terminate

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It does terminate, it just takes a long time:

$ time g++-7.3.0 t.cc -O1

real6m16.685s
user6m16.163s
sys 0m0.038s

With GCC 8.2.0 it's much faster:

real0m44.389s
user0m44.029s
sys 0m0.057s


With a recent build from gcc-8-branch (8.3.1 20190303) it's almost instant:

real0m0.066s
user0m0.053s
sys 0m0.014s


This is probably a duplicate of one of the existing bugs about initialization
of large arrays.

[Bug c/89618] Inner loop won't vectorize unless dummy statement is included

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch.

[Bug tree-optimization/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 45916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45916&action=edit
gcc9-pr89550.patch

While investigating why r264868 didn't warn even when the IL is pretty much the
same, I've found that it is because c_strlen was called with a different
location (from system header) during ccp and without -Wsystem-headers it set
TREE_NO_WARNING, yet hasn't emitted any warnings, and then later on it would
warn, but doesn't, because TREE_NO_WARNING was set.

This patch fixes all such spots I found, I guess it might cause more warnings
generally, will see what it does in the testsuite.

[Bug c++/89620] New: Add fix-it hint for missing comma in template argument list

[redi at gcc dot gnu.org]

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

Bug ID: 89620
   Summary: Add fix-it hint for missing comma in template argument
list
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct pair { };

pair p;


x.cc:3:18: error: two or more data types in declaration of ‘type name’
 pair p;
  ^~~~
x.cc:3:29: error: wrong number of template arguments (1, should be 2)
 pair p;
 ^
x.cc:1:41: note: provided for ‘template struct pair’
 template struct pair { };
 ^~~~

G++ notices there are two "data types" where one is expected, but also that one
template argument is given where two are expected. It could suggest a comma
between the two type names, which would solve both problems.


For this code, clang suggests there's a missing '>' between the types, which
doesn't actually fix the problem:

x.cc:3:18: error: expected '>'
pair p;
 ^
x.cc:3:18: error: expected unqualified-id
2 errors generated.


For a similar case without decltype G++ gives the same errors, but clang says
something different:

x.cc:3:10: error: cannot combine with previous 'int' declaration specifier
pair p;
 ^
x.cc:3:1: error: too few template arguments for class template 'pair'
pair p;
^
x.cc:1:41: note: template is declared here
template struct pair { };
^
2 errors generated.

[Bug fortran/89621] New: Internal Compiler Error with allocatable character and openmp

[mweiland at freenet dot de]

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

Bug ID: 89621
   Summary: Internal Compiler Error with allocatable character and
openmp
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mweiland at freenet dot de
  Target Milestone: ---

Created attachment 45917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45917&action=edit
Source code which triggers the compiler bug.

Bug is triggered by :
gfortran -c minimal.f90 -fopenmp
(minimal.f90 is in attachement).

--- Output of Compiler:

gfortran -c ../src/minimal.f90 -fopenmp
../src/minimal.f90:15:0:

   !$omp parallel do

internal compiler error: Segmentation fault
0xad4caf crash_signal
../../gcc/toplev.c:337
0x71dd9c gfc_omp_clause_copy_ctor(tree_node*, tree_node*, tree_node*)
../../gcc/fortran/trans-openmp.c:614
0x9f65c5 lower_rec_input_clauses
../../gcc/omp-low.c:4339
0x9f89ad lower_omp_taskreg
../../gcc/omp-low.c:7441
0x9f006e lower_omp_1
../../gcc/omp-low.c:8815
0x9f006e lower_omp
../../gcc/omp-low.c:8959
0x9f0e88 lower_omp_1
../../gcc/omp-low.c:8799
0x9f0e88 lower_omp
../../gcc/omp-low.c:8959
0x9f0dad lower_omp_1
../../gcc/omp-low.c:8807
0x9f0dad lower_omp
../../gcc/omp-low.c:8959
0x9f4a8f execute_lower_omp
../../gcc/omp-low.c:9001
0x9f4a8f execute
../../gcc/omp-low.c:9038
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



- information about environment and gcc version: --
gcc -v
Reading specs from
/afs/ipp-garching.mpg.de/common/soft/gcc/7.2.0/@sys/bin/../lib/gcc/x86_64-pc-linux-gnu/7.2.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/afs/ipp-garching.mpg.de/common/soft/gcc/7.2.0/@sys/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/afs/ipp/.cs/gcc/7.2.0/amd64_sles11
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 7.2.0 (GCC)

[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 45918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45918&action=edit
patch

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
On
struct thread {
  template thread(F) { }
};

template
void sleep_for(D) { }

template struct duration { };
using milliseconds = duration;

void f()
{
  thread sleeper([]{
while (true) {
  for (unsigned cc = 0; cc < 1; ++cc) ;
  milliseconds m;
}
  });
}
-std=c++17 -O1 this stopped timing out with r268185.
But, following modification still times out with current trunk:
struct thread {
  template thread(F) { }
};

template
void sleep_for(D) { }

template struct duration { };
using milliseconds = duration;

void f()
{
  thread sleeper([]{
while (true) {
  for (unsigned cc = 0; cc < 1; ++cc) ;
  milliseconds m;
}
return true;
  });
}
(timeout 60s).  So, this doesn't seem to be fixed.

[Bug libstdc++/89610] Move-assigning a pmr container sometimes copies the elements instead of moving them

[Casey at Carter dot net]

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

--- Comment #2 from Casey Carter  ---
This isn't a "missed-optimization", it's non-conforming behavior. The
Allocator-aware container requirements
(http://eel.is/c++draft/container.requirements.general#16.sentence-41) require
only that the element type is Cpp17MoveAssignable and Cpp17MoveInsertable into
the container type, so copies - even if the syntax is valid - cannot achieve
the required postcondition that the target of the move assignment is equal to
the value the source of the move assignment had before moving.

[Bug tree-optimization/89595] [8/9 Regression] DOM miscompiles code

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  7 12:46:44 2019
New Revision: 269453

URL: https://gcc.gnu.org/viewcvs?rev=269453&root=gcc&view=rev
Log:
2019-03-07  Richard Biener  

PR tree-optimization/89595
* tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
stmt iterator as reference, take boolean output parameter to
indicate whether the stmt was removed and thus the iterator
already advanced.
(dom_opt_dom_walker::before_dom_children): Re-iterate over
stmts created by folding.

* gcc.dg/torture/pr89595.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr89595.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/89595] [8 Regression] DOM miscompiles code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] DOM|[8 Regression] DOM
   |miscompiles code|miscompiles code

--- Comment #5 from Richard Biener  ---
Fixed on trunk.

[Bug c++/53415] problematic error message for ambiguity

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Nathan Ridge from comment #0)
> 1. Template argument deduction/substitution is failing because of a
> *warning*? The following reduced example:
> 
> struct string
> {
> string(char*);
> };
> 
> template 
> void operator+(const string&, const T&);
> 
> struct T
> {
> enum {value = 0};
> };
> 
> int main()
> {
> return 0 + T::value; 
> }
> 
> gives a similar warning but no errors. It is inconsistent for an ambiguity
> to cause just a warning in one case, and failure of template argument
> deduction/substitution in another.

That's by design. G++ extensions that change the meaning of ill-formed code are
disabled in SFINAE contexts. This is similar to the -Wnarrowing option, for
which the manual says:

"Note that this does not affect the meaning of well-formed code; narrowing
conversions are still considered ill-formed in SFINAE contexts."

This ensures that static properties of the code (e.g. detectable using decltype
or other compile-time metaprogramming) are consistent with other compilers that
don't implement the same non-standard extension.

> 2. There is no caret diagnostic associated with the "ISO C++ says that these
> are ambiguous" warning, so it's difficult to tell what "these" are. (We can
> infer from the candidates being operator+, but there could have been many
> uses of operator+ in that expression, and only one of them ambiguous, so it
> would be nice to have a caret pointing to that one).

I can't reproduce this part of the report, I see a location for the ambiguity,
with all versions I tested from 4.8.0 onwards:

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second: [enabled by default]
 S<0 + T::value> foo(X);
 ^

Since GCC 6 it's a range not a single location:

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
 S<0 + T::value> foo(X);
   ~~^~

And with current trunk the range is correct :-)

a.cc:19:5: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
   19 | S<0 + T::value> foo(X);
  |   ~~^

[Bug c++/89622] New: G++ prints notes, but no warning or error

[redi at gcc dot gnu.org]

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

Bug ID: 89622
   Summary: G++ prints notes, but no warning or error
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The following code compiles successfuly, but prints two mysterious notes:

# 1 "ambig.cc"
# 1 "ambig.h" 1

# 2 "ambig.h" 3


# 3 "ambig.h" 3
template
struct X
{
  X() { }
  template X(int, U&&) { }
  template X(char, const X&) { }
};

template
X wrap_X(X x)
{
  return X('a', x);
}
# 2 "ambig.cc" 2


# 3 "ambig.cc"
int main()
{
  X x;
  wrap_X(x);
}


$ g++ ambig.ii
In file included from ambig.cc:1:
ambig.h: In instantiation of 'X wrap_X(X) [with T = void]':
ambig.cc:6:11:   required from here
ambig.h:8:24: note: candidate 1: 'X::X(char, const X&) [with U = void; T
= void]'
ambig.h:7:24: note: candidate 2: 'X::X(int, U&&) [with U = X&; T =
void]'


Adding -Wsystem-headers reveals that the notes are related to a warning that is
suppressed:

ambig.h: In instantiation of 'X wrap_X(X) [with T = void]':
ambig.cc:6:11:   required from here
ambig.h:14:10: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
ambig.h:8:24: note: candidate 1: 'X::X(char, const X&) [with U = void; T
= void]'
ambig.h:7:24: note: candidate 2: 'X::X(int, U&&) [with U = X&; T =
void]'


If the warning is suppressed then the notes should be too.

I get the same behaviour back to 4.3 so this doesn't seem to be a regression.

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 45919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45919&action=edit
gcc9-pr87481.patch

Untested fix.

[Bug c++/53415] problematic error message for ambiguity

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
P.S. also -pedantic-errors makes it an error, not just a warning

[Bug target/89623] New: Can't build mips-wrs-vxworks cross-compiler

[marxin at gcc dot gnu.org]

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

Bug ID: 89623
   Summary: Can't build mips-wrs-vxworks cross-compiler
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Can't build due to:

In file included from ./tm.h:19:0,
 from /home/mliska/Programming/gcc2/gcc/genpreds.c:26:
./options.h:5894:2: error: #error too many target masks
 #error too many target masks

options.h:
...
#define MASK_ABICALLS (1U << 0)
#define MASK_BRANCHLIKELY (1U << 1)
#define MASK_CHECK_ZERO_DIV (1U << 2)
#define MASK_DIVIDE_BREAKS (1U << 3)
#define MASK_SINGLE_FLOAT (1U << 4)
#define MASK_BIG_ENDIAN (1U << 5)
#define MASK_EXPLICIT_RELOCS (1U << 6)
#define MASK_FIX_R1 (1U << 7)
#define MASK_FIX_R4000 (1U << 8)
#define MASK_FIX_R4400 (1U << 9)
#define MASK_FIX_R5900 (1U << 10)
#define MASK_FLOAT64 (1U << 11)
#define MASK_FLOATXX (1U << 12)
#define MASK_64BIT (1U << 13)
#define MASK_SOFT_FLOAT_ABI (1U << 14)
#define MASK_IMADD (1U << 15)
#define MASK_MIPS16 (1U << 16)
#define MASK_LLSC (1U << 17)
#define MASK_LONG64 (1U << 18)
#define MASK_LOONGSON_EXT (1U << 19)
#define MASK_LOONGSON_EXT2 (1U << 20)
#define MASK_LOONGSON_MMI (1U << 21)
#define MASK_MEMCPY (1U << 22)
#define MASK_MICROMIPS (1U << 23)
#define MASK_MSA (1U << 24)
#define MASK_ODD_SPREG (1U << 25)
#define MASK_PAIRED_SINGLE_FLOAT (1U << 26)
#define MASK_RELAX_PIC_CALLS (1U << 27)
#define MASK_VXWORKS_RTP (1U << 28)
#define MASK_SMARTMIPS (1U << 29)
#define MASK_SPLIT_ADDRESSES (1U << 30)
#define MASK_SYNCI (1U << 31)
#define MASK_VR4130_ALIGN (1U << 32)
...

[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included

[moritz.kreutzer at siemens dot com]

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

--- Comment #3 from Moritz Kreutzer  ---
Great, thanks for the quick action Richard!

[Bug c++/89622] G++ prints notes, but no warning or error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45920&action=edit
gcc9-pr89622.patch

Untested fix.

[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"

[boger at gcc dot gnu.org]

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

--- Comment #6 from boger at gcc dot gnu.org ---
Works now, thanks.

[Bug libstdc++/89610] Move-assigning a pmr container sometimes copies the elements instead of moving them

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|missed-optimization |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-07
 Ever confirmed|0   |1

[Bug c++/89619] g++ does not terminate

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

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

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

[Bug c++/87436] [7 Regression] G++ produces >300MB .rodata section to initialize struct with big array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||stas.pyatykh at gmail dot com

--- Comment #14 from Jakub Jelinek  ---
*** Bug 89619 has been marked as a duplicate of this bug. ***

[Bug c++/89612] [7/8/9 Regression] internal compiler error: in push_access_scope, at cp/pt.c:237

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
I might have a patch.

[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  7 14:53:37 2019
New Revision: 269458

URL: https://gcc.gnu.org/viewcvs?rev=269458&root=gcc&view=rev
Log:
2019-04-07  Richard Biener  

PR middle-end/89618
* cfgloopmanip.c (copy_loop_info): Copy forgotten fields.
* tree-inline.c (copy_loops): Simplify.

* gcc.target/i386/pr89618.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr89618.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail||8.3.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk, not sure if worth backporting?

[Bug c++/89599] C-style function-pointer-to-void* cast is handled inconsistently

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45921&action=edit
gcc9-pr89599.patch

Untested fix.

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Thu Mar  7 15:10:22 2019
New Revision: 269459

URL: https://gcc.gnu.org/viewcvs?rev=269459&root=gcc&view=rev
Log:
PR c++/80916 - spurious "static but not defined" warning.

Nothing can refer to an internal decl with no definition, so we shouldn't
treat such a decl as a possible devirtualization target.

* gimple-fold.c (can_refer_decl_in_current_unit_p): Return false
for an internal symbol with DECL_EXTERNAL.

Added:
trunk/gcc/testsuite/g++.dg/warn/unused-fn1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c

[Bug libstdc++/55233] libstdc++ atomic does not support hle_acquire/release

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I think this change is broken for -fshort-enums because the std::memory_order
enum will be a single byte, and not be able to store the HLE bits.

[Bug c++/80916] [7/8 Regression] Spurious "declared 'static' but never defined" warni

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] Spurious |[7/8 Regression] Spurious
   |"declared 'static' but  |"declared 'static' but
   |never defined" warning  |never defined" warni

--- Comment #13 from Jason Merrill  ---
Fixed on trunk so far.

[Bug libstdc++/89624] New: HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[redi at gcc dot gnu.org]

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

Bug ID: 89624
   Summary: HLE acquire/release bits in std::memory_order don't
work with -fshort-enums or -fstrict-enums
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

static_assert((std::memory_order_acquire | std::__memory_order_hle_acquire)
!= std::memory_order_acquire, "HLE acquire sets a bit");

This fails with -fshort-enums because it makes the std::memory_order enum only
occupy a single byte, so the HLE bits don't exist:

  enum __memory_order_modifier
{
  __memory_order_mask  = 0x0,
  __memory_order_modifier_mask = 0x,
  __memory_order_hle_acquire   = 0x1,
  __memory_order_hle_release   = 0x2
};

For -fstrict-enums those bits create values which are not valid values of the
enum type.

I think we need to give std::memory_order a fixed underlying type of int, so
that its size doesn't change with -fshort-enums and all values of int are
valid.

This will be an ABI break for -fshort-enums though, but that's already happened
for PR 88996 because the new definition is a scoped enum, which always has a
fixed underlying type.

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> This will be an ABI break for -fshort-enums though, but that's already
> happened for PR 88996 because the new definition is a scoped enum, which
> always has a fixed underlying type.

To be clear, the recent break can be easily fixed:

--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -53,7 +53,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   /// Enumeration for memory_order
 #if __cplusplus > 201703L
-  enum class memory_order : int
+  // This determines the underlying type of memory_order,
+  // because its size can change when -fshort-enums is used.
+  enum __unscoped_memory_order { __unscoped_memory_order_max = 5 };
+
+  enum class memory_order : __underlying_type(__unscoped_memory_order)
 {
   relaxed,
   consume,

But that wouldn't solve the problem for the HLE bits.

[Bug libstdc++/55233] libstdc++ atomic does not support hle_acquire/release

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> I think this change is broken for -fshort-enums because the
> std::memory_order enum will be a single byte, and not be able to store the
> HLE bits.

That's now PR 89624.

[Bug c++/88123] [8/9 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/85665] Multiple typos in diagnostics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Most of this is nds32 target related, so should be fixed by the corresponding
maintainer.  As for two spaces after ., that is standard GCC convention and I
believe it is used in many other spots.  I'll handle the ipa-devirt.c issue.

[Bug libgcc/89625] New: Freeing memory under the lock in __deregister_frame_info_bases

[antoshkka at gmail dot com]

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

Bug ID: 89625
   Summary: Freeing memory under the lock in
__deregister_frame_info_bases
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

`__deregister_frame_info_bases` in file unwind-dw2-fde.c calls `free
(ob->u.sort);` under the locked `object_mutex`. This can be avoided by
remembering the pointer to free and freeing it outside the critical section.

This has been fixed in upstream glibc
https://github.com/bminor/glibc/commit/2604882cefd3281679b8177245fdebc7061b8695#diff-17235859a5d2697ce97070a69ab9a602

[Bug ipa/88235] [7/8/9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Thu Mar  7 16:03:34 2019
New Revision: 269462

URL: https://gcc.gnu.org/viewcvs?rev=269462&root=gcc&view=rev
Log:
Relax cgraph_node::clone_of_p to also look through former clones

2019-03-07  Martin Jambor  

PR ipa/88235
* cgraph.h (cgraph_node): New inline method former_thunk_p.
* cgraph.c (cgraph_node::dump): Dump a note if node is a former thunk.
(clone_of_p): Treat expanded thunks like thunks, be optimistic if they
have multiple callees.  At the end check if declarations match as
opposed to cgraph_nodes.

testsuite/
* g++.dg/ipa/pr88235.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr88235.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Ping to Paul.

[Bug c++/88820] [7/8 Regression] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in in
   |in C++2a mode for code  |C++2a mode for code which
   |which is able to be |is able to be compiled in
   |compiled in C++17 mode  |C++17 mode

--- Comment #13 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/88820] [7/8/9 Regression] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Thu Mar  7 16:15:56 2019
New Revision: 269463

URL: https://gcc.gnu.org/viewcvs?rev=269463&root=gcc&view=rev
Log:
PR c++/88820 - ICE with CTAD and member template used in DMI.

Here the problem was that in order to form a FUNCTION_DECL for foo in
the uninstantiated template, we were trying to deduce template args for S
from the template parm itself, and failing.

* pt.c (do_class_deduction): Handle parm used as its own arg.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction64.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/89626] New: Extraneous error message when compiling vector __int128

[kelvin at gcc dot gnu.org]

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

Bug ID: 89626
   Summary: Extraneous error message when compiling vector
__int128
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc-linux (P7 big-endian, -m64)
Target: powerpc-linux (P7 big-endian -m64)
 Build: trunk revision 253662

Created attachment 45922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45922&action=edit
Reproducer source file

"vector __int128" is not recognized as legal syntax though "vector unsigned
__int128" and "vector int" are both recognized as legal.

The problem appears to result during a preprocessor phase of compilation which
expands the vector keyword differently depending on context.  See the attached
files.

This problem has only been seen when the compiler runs on P7 big-endian -m64.

[Bug target/89626] Extraneous error message when compiling vector __int128

[kelvin at gcc dot gnu.org]

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

--- Comment #1 from kelvin at gcc dot gnu.org ---
Created attachment 45923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45923&action=edit
preprocessed source code for reproducer

[Bug target/89626] Extraneous error message when compiling vector __int128

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #2 from kelvin at gcc dot gnu.org ---
The command line and error messages follow:

kelvin@bns:~/gcc/tests> echo $GCC_BUILD
/home/kelvin/gcc/build/gcc-trunk487532.b4patch
kelvin@bns:~/gcc/tests> make vector__int128.pp.s
$GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc/ -S -mvsx -m64 -o vector__int128.pp.s
vector__int128.pp.c
vector__int128.c:39:14: error: unknown type name ‘vector’
   39 | __int128 e0 (vector __int128 v)
  |  ^~
vector__int128.c: In function ‘main’:
vector__int128.c:45:3: error: ‘vector’ undeclared (first use in this function)
   45 |   vector __int128 dv = { CONST0 };
  |   ^~
vector__int128.c:45:3: note: each undeclared identifier is reported only once
for each function it appears in
vector__int128.c:45:9: error: expected ‘;’ before ‘__int128’
   45 |   vector __int128 dv = { CONST0 };
  | ^
  | ;
vector__int128.c:48:7: warning: implicit declaration of function ‘e0’; did you
mean ‘u0’? [-Wimplicit-function-declaration]
   48 |   d = e0 (dv);
  |   ^~
  |   u0
vector__int128.c:48:11: error: ‘dv’ undeclared (first use in this function);
did you mean ‘d’?
   48 |   d = e0 (dv);
  |   ^~
  |   d
make: *** [vector__int128.pp.s] Error 1

[Bug target/89626] Extraneous error message when compiling vector __int128

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Looks like the preprocess conditional identifier does not recognize __int128 as
something it should be used with vector.

I doubt this is a real bug as vector __int128 is not defined in the PowerPC
specifications.

vector unsigned __int128
is accepted by accident really, recongizing unsigned as something vector can
come beforehand.

[Bug translation/79999] possible typo in gimplify.c: depend(sink:)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Dunno, the clauses are depend(source) and depend(sink: i-1, j+2) or similar.
So source is never followed by a semicolon, sink always followed by semicolon
and some expressions.
Maybe I should reword it to longer % clause with % modifier
and % clause with % modifier.

[Bug c++/88123] [8/9 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
The problem is that we don't preserve the unqualified lookup in our template
representation of operator expressions the way we do for normal calls.  Here's
a variant that never worked, because we're instantiating the lambda call
operator out of its definition context:

struct bar {};

namespace foo
{
  void operator+(bar) {}
} // namespace foo  

auto fn() {
  using namespace foo;
  return [](auto x) { +x;};
}

int main()
{
  auto l = fn();
  l(bar());
}

[Bug lto/87525] [7/8/9 Regression] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
Author: jamborm
Date: Thu Mar  7 16:42:20 2019
New Revision: 269464

URL: https://gcc.gnu.org/viewcvs?rev=269464&root=gcc&view=rev
Log:
Zero local estimated benefit for cloning extern inline function

2019-03-07  Martin Jambor  

PR lto/87525
* ipa-cp.c (perform_estimation_of_a_value): Account zero time benefit
for extern inline functions.

testsuite/
* gcc.dg/ipa/ipcp-5.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug d/89016] ICE in ArrayLiteralExp::toStringExp, at d/dmd/expression.c:3873

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Buclaw  ---
Fixed in r269465.

[Bug translation/79999] possible typo in gimplify.c: depend(sink:)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45924&action=edit
gcc9-pr7.patch

Untested fix.

[Bug target/89627] New: Miscompiled constructor call

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

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

Bug ID: 89627
   Summary: Miscompiled constructor call
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: wilson at gcc dot gnu.org
  Target Milestone: ---
Target: riscv64-*-*

$ cat bind2nd.cc
#include 
#include 

int
main ()
{
  auto b = std::bind2nd (std::divides (), 2.0);
  double v = b (1);
  std::cout << "v = " << v << '\n';
}
$ g++ -g bind2nd.cc
$ ./a.out
v = Inf

I think the miscompilation occurs in the bind2nd function after the call to the
binder2nd constructor:

Dump of assembler code for function std::bind2nd,
double>(std::divides const&, double const&):
   0x00010902 <+0>: addisp,sp,-96
   0x00010904 <+2>: sd  ra,88(sp)
   0x00010906 <+4>: sd  s0,80(sp)
   0x00010908 <+6>: addis0,sp,96
   0x0001090a <+8>: sd  a0,-72(s0)
   0x0001090e <+12>:sd  a1,-80(s0)
=> 0x00010912 <+16>:ld  a5,-80(s0)
   0x00010916 <+20>:fld fa5,0(a5)
   0x00010918 <+22>:fsd fa5,-24(s0)
   0x0001091c <+26>:addia4,s0,-24
   0x00010920 <+30>:addia5,s0,-40
   0x00010924 <+34>:mv  a2,a4
   0x00010926 <+36>:ld  a1,-72(s0)
   0x0001092a <+40>:mv  a0,a5
   0x0001092c <+42>:jal ra,0x10986
 >::binder2nd(std::divides const&,
double const&)>
   0x00010930 <+46>:ld  a5,-40(s0)
   0x00010934 <+50>:sd  a5,-56(s0)
   0x00010938 <+54>:ld  a5,-32(s0)
   0x0001093c <+58>:sd  a5,-48(s0)
   0x00010940 <+62>:fld fa5,-56(s0)
   0x00010944 <+66>:fmv.d   fa0,fa5
   0x00010948 <+70>:ld  ra,88(sp)
   0x0001094a <+72>:ld  s0,80(sp)
   0x0001094c <+74>:addisp,sp,96
   0x0001094e <+76>:ret

[Bug target/89626] Extraneous error message when compiling vector __int128

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
If you use -mcpu=power8 (or up) it works fine.

[Bug target/89626] Extraneous error message when compiling vector __int128

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
  if (rid_code == RID_UNSIGNED || rid_code == RID_LONG
  || rid_code == RID_SHORT || rid_code == RID_SIGNED
  || rid_code == RID_INT || rid_code == RID_CHAR
  || rid_code == RID_FLOAT
  || (rid_code == RID_DOUBLE && TARGET_VSX)
  || (rid_code == rid_int128 () && TARGET_VADDUQM))

Seems like this is intentional, vector double not allowed without -mvsx and
vector __int128 without power8.

[Bug target/89628] New: aarch64_vector_pcs does not use v24-v31 as temp regs

[nsz at gcc dot gnu.org]

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

Bug ID: 89628
   Summary: aarch64_vector_pcs does not use v24-v31 as temp regs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

consider

typedef __Float32x4_t vec;

__attribute__((aarch64_vector_pcs))
vec f(vec a0, vec a1, vec a2, vec a3, vec a4, vec a5, vec a6, vec a7)
{
vec t0, t1, t2, t3, t4, t5, t6, t7, s0, s1, s2, s3;
t0 = a0 - a7;
t1 = a1 - a6;
t2 = a2 - a5;
t3 = a3 - a4;
t4 = a4 - a3;
t5 = a5 - a2;
t6 = a6 - a1;
t7 = a7 - a0;
s0 = t0 * t1;
s1 = t2 * t3;
s2 = t4 * t5;
s3 = t6 * t7;
return s0 * s1 * s2 * s3 * a0 * a1 * a2 * a3 * a4 * a5 * a6 * a7;
}

the aarch64 vpcs has 8 arg + 8 temp regs to use, so i think such code should
not need to spill, however current gcc seems to compile it as

f:
stp q16, q17, [sp, -96]!
fsubv16.4s, v2.4s, v5.4s
stp q18, q19, [sp, 32]
fsubv17.4s, v0.4s, v7.4s
stp q20, q21, [sp, 64]
fsubv18.4s, v1.4s, v6.4s
fsubv20.4s, v3.4s, v4.4s
fsubv21.4s, v5.4s, v2.4s
fsubv19.4s, v4.4s, v3.4s
fmulv17.4s, v17.4s, v18.4s
fmulv16.4s, v16.4s, v20.4s
fsubv18.4s, v6.4s, v1.4s
fsubv20.4s, v7.4s, v0.4s
fmulv19.4s, v19.4s, v21.4s
fmulv16.4s, v17.4s, v16.4s
fmulv17.4s, v18.4s, v20.4s
ldp q20, q21, [sp, 64]
fmulv16.4s, v16.4s, v19.4s
ldp q18, q19, [sp, 32]
fmulv16.4s, v16.4s, v17.4s
fmulv16.4s, v16.4s, v0.4s
fmulv1.4s, v16.4s, v1.4s
ldp q16, q17, [sp], 96
fmulv2.4s, v1.4s, v2.4s
fmulv3.4s, v2.4s, v3.4s
fmulv4.4s, v3.4s, v4.4s
fmulv5.4s, v4.4s, v5.4s
fmulv6.4s, v5.4s, v6.4s
fmulv0.4s, v6.4s, v7.4s
ret

note that v24..v31 regs are not used but there are 6 spills.

[Bug target/89626] Extraneous error message when compiling vector __int128

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
"vector signed __int128" and "vector unsigned __int128" are both defined,
and both work fine.  But "vector __int128" is not defined in the ABI, and
does not work unless you are building for power8 or up.

Bill, what should the ABI say about this?

[Bug libstdc++/89629] New: std::hash segfault for long strings

[dan at stahlke dot org]

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

Bug ID: 89629
   Summary: std::hash segfault for long strings
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at stahlke dot org
  Target Milestone: ---

_Hash_bytes crashes when len is 2^31 or greater.  The length is converted to
int at hash_bytes.cc line 142, resulting in a negative number if the length
doesn't fit in an int variable.  Then end < buf resulting in an infinite loop
that eventually runs into inaccessible memory.

#include 
#include 
#include 

int main() {
size_t big = size_t(1) << 31;
std::cout << "line " << __LINE__ << std::endl;
// this succeeds
std::hash{}(std::string(big - 1, 'a'));
std::cout << "line " << __LINE__ << std::endl;
// segfault at libstdc++-v3/libsupc++/hash_bytes.cc:147
std::hash{}(std::string(big, 'a'));
std::cout << "line " << __LINE__ << std::endl;
}

[Bug target/89626] Extraneous error message when compiling vector __int128

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
If vector followed by __int128 is unconditionally mapped to __vector, then so
should vector double.

[Bug target/89602] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  7 19:10:21 2019
New Revision: 269467

URL: https://gcc.gnu.org/viewcvs?rev=269467&root=gcc&view=rev
Log:
PR target/89602
* config/i386/sse.md (avx512f_mov_mask,
*avx512f_load_mask, avx512f_store_mask): New define_insns.
(avx512f_load_mask): New define_expand.
* config/i386/i386-builtin.def (__builtin_ia32_loadsd_mask,
__builtin_ia32_loadss_mask, __builtin_ia32_storesd_mask,
__builtin_ia32_storess_mask, __builtin_ia32_movesd_mask,
__builtin_ia32_movess_mask): New builtins.
* config/i386/avx512fintrin.h (_mm_mask_load_ss, _mm_maskz_load_ss,
_mm_mask_load_sd, _mm_maskz_load_sd, _mm_mask_move_ss,
_mm_maskz_move_ss, _mm_mask_move_sd, _mm_maskz_move_sd,
_mm_mask_store_ss, _mm_mask_store_sd): New intrinsics.

* gcc.target/i386/avx512f-vmovss-1.c: New test.
* gcc.target/i386/avx512f-vmovss-2.c: New test.
* gcc.target/i386/avx512f-vmovss-3.c: New test.
* gcc.target/i386/avx512f-vmovsd-1.c: New test.
* gcc.target/i386/avx512f-vmovsd-2.c: New test.
* gcc.target/i386/avx512f-vmovsd-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovsd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovsd-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovsd-3.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovss-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovss-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vmovss-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512fintrin.h
trunk/gcc/config/i386/i386-builtin.def
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/88918] [meta-bug] x86 intrinsic issues

[jakub at gcc dot gnu.org]

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

Bug 89602 Summary: Missing AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89602

   What|Removed |Added

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

[Bug target/89602] Missing AVX512 intrinsics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Implemented for 9.1+.

[Bug target/89626] Extraneous error message when compiling vector __int128

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #8 from seurer at gcc dot gnu.org ---
Segher, when we were cleaning up the ABI documentation one of the things we did
is to always explicitly use unsigned and signed.  The current ABI lists only
the explicit signed/unsigned types as being valid.  See table 2.12 for
instance.

If I recall correctly there were some problems we had seen without "signed"
precisely because of how "vector" is handled by the preprocessor.

[Bug target/89626] Extraneous error message when compiling vector __int128

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
vector __int128 is equivalent to vector signed __int128, and only is defined
for the ELFv2 ABI.  Technically ELFv2 can be used anywhere, but in practice it
is little-endian only.LE systems require a minimum of POWER8.

[Bug translation/79999] possible typo in gimplify.c: depend(sink:)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  7 19:46:11 2019
New Revision: 269468

URL: https://gcc.gnu.org/viewcvs?rev=269468&root=gcc&view=rev
Log:
PR translation/7
* gimplify.c (gimplify_omp_ordered): Reword diagnostics to talk about
depend clause with source (or sink) modifier.
* omp-expand.c (expand_omp_ordered_sink): Likewise.

* c-c++-common/gomp/doacross-1.c: Adjust expected diagnostics.
* c-c++-common/gomp/doacross-3.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/doacross-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/omp-expand.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/gomp/doacross-1.c

[Bug c++/29040] missing access control checks in subclasses for nested types

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  ---
My draft doesn't the templated case:

struct c
{
private: template struct n
  {
int j;
  };
};

struct d:public c
{
  template
  void f (struct n *p);
};

Interestingly, currently we neither handle correctly a version of it without
the class-key:

struct c
{
private: template struct n
  {
int j;
  };
};

struct d:public c
{
  template
  void f (/*struct*/ n *p);
};

but maybe it's just a special case of our long standing issues with access
control vs templates.

[Bug translation/79999] possible typo in gimplify.c: depend(sink:)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for 9.1+.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

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

Bug 7 Summary: possible typo in gimplify.c: depend(sink:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7

   What|Removed |Added

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

[Bug c++/84518] [8/9 Regression] ICE with lambda capturing broken variable

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
These are fixed in trunk: I'm adding the testcases and removing the 9
regression marker.

[Bug c++/84518] [8/9 Regression] ICE with lambda capturing broken variable

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Mar  7 20:49:42 2019
New Revision: 269469

URL: https://gcc.gnu.org/viewcvs?rev=269469&root=gcc&view=rev
Log:
2019-03-07  Paolo Carlini  

PR c++/84518
* g++.dg/cpp0x/lambda/lambda-ice30.C: New.
* g++.dg/cpp0x/lambda/lambda-ice31.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice30.C
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice31.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/80003] i386.c: %s placeholder is no semantic grammar unit

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  7 21:32:21 2019
New Revision: 269471

URL: https://gcc.gnu.org/viewcvs?rev=269471&root=gcc&view=rev
Log:
PR target/80003
* config/i386/i386.c (ix86_set_func_type): Make sure diagnostics
doesn't start with a capital letter and doesn't end with a dot.
(ix86_function_arg_boundary): Make sure diagnostics doesn't start
with a capital letter.
(ix86_mangle_function_version_assembler_name): Likewise.
(ix86_generate_version_dispatcher_body): Likewise.
(fold_builtin_cpu): Likewise.
(get_builtin_code_for_version): Likewise.  Remove extraneous space.
(ix86_handle_interrupt_attribute): Make the diagnostics easier for
translators, wrap full type name in %qs.

* gcc.target/i386/pr68657.c: Adjust expected diagnostics wording.
* gcc.target/i386/interrupt-6.c: Likewise.
* g++.target/i386/pr57362.C: Adjust capitalization in dg-prune-output.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.target/i386/pr57362.C
trunk/gcc/testsuite/gcc.target/i386/interrupt-6.c
trunk/gcc/testsuite/gcc.target/i386/pr68657.c

[Bug target/89602] Missing AVX512 intrinsics

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
It got fixed with r269292 in particular.

[Bug target/89626] Extraneous error message when compiling vector __int128

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
But it behaves exactly likes this on LE ELFv2 systems as well.

Only explicitly signed and unsigned types are documented, sure, but that
does not make all that much sense, IMO.

[Bug target/89626] Extraneous error message when compiling vector __int128

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-07
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Segher Boessenkool  ---
I'll take this.

[Bug target/80003] i386.c: %s placeholder is no semantic grammar unit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Should be fixed for 9.1+.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

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

Bug 80003 Summary: i386.c: %s placeholder is no semantic grammar unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80003

   What|Removed |Added

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

[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
Patch posted here:

https://gcc.gnu.org/ml/fortran/2019-03/msg00026.html

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #4 from Eric Gallager  ---
on my TODO list: add the "easyhack" keyword to all the bugs this one depends
upon

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |trivial

[Bug go/89406] Go testing leaves many temporary directories in /tmp around

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #14 from Ian Lance Taylor  ---
I haven't heard about any more problems, so closing.

[Bug c++/88123] [8/9 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Mar  8 02:54:41 2019
New Revision: 269477

URL: https://gcc.gnu.org/viewcvs?rev=269477&root=gcc&view=rev
Log:
PR c++/88123 - lambda and using-directive.

For named function calls in a template, the result of unqualified lookup is
safed in CALL_EXPR_FN.  But for operator expressions, no unqualified lookup
is performed until we know whether the operands have class type.  So when we
see in a lambda a use of an operator that might be overloaded, we need to do
that lookup then and save it away somewhere.  One possibility would be in
the expression, but we can't really add extra conditional operands to
standard tree codes.  I mostly implemented another approach using a new
WITH_LOOKUP_EXPR code, but teaching everywhere how to handle a new tree code
is always complicated.  Then it occurred to me that we could associate the
lookups with the function, which is both simpler and smaller.  So this patch
stores any operator bindings needed by a lambda function in an internal
attribute on the lambda call operator.

* name-lookup.c (op_unqualified_lookup)
(maybe_save_operator_binding, discard_operator_bindings)
(push_operator_bindings): New.
* typeck.c (build_x_binary_op, build_x_unary_op): Call
maybe_save_operator_binding.
* decl.c (start_preparsed_function): Call push_operator_bindings.
* tree.c (cp_free_lang_data): Call discard_operator_bindings.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-using1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/name-lookup.h
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c

[Bug c++/88123] [8 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] faulty |[8 Regression] faulty
   |qualified name lookup of|qualified name lookup of
   |overloaded operator within  |overloaded operator within
   |generic lambda via  |generic lambda via
   |using-directive |using-directive

--- Comment #6 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/87748] [8/9 Regression] G++-8 treats SFINAE as error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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