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

[rbock at eudoxos dot de]

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

--- Comment #10 from Roland B  ---
(In reply to Marek Polacek from comment #9)
> Fixed on trunk, will backport to 9.3 later.

Thanks! Much appreciated :-)

[Bug c++/91394] C++ ABI incompatibility (stdexcept)

[tomas_paukrt at conel dot cz]

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

tomas_paukrt at conel dot cz changed:

   What|Removed |Added

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

--- Comment #2 from tomas_paukrt at conel dot cz ---
> What has the glibc version got to do with anything?

We have upgraded glibc 2.25 to glibc 2.30 and it introduced similar
compatibility issue, because new symbols (e.g. fcntl64@GLIBC_2.28) were present
in a fresh cross-compiled program, so the binary cannot run on the old system,
but in this case there is a simple workaround (.symver fcntl64,fcntl@GLIBC_2.4)
that makes the program work again, so I was looking for a similar workaround
for libstdc++.so and I have found _GLIBCXX_USE_CXX11_ABI.

> If it's not present on the old system that means you're not using the
> libstdc++.so from GCC 7.4.0, which you're required to do. You can't compile
> with a new GCC and then use an old libstdc++.so at runtime. That's always
> been true. Defining _GLIBCXX_USE_CXX11_ABI has nothing to do with that.

Sorry, but this is not true. If some program is cross-compiled with GCC 7.4.0
using -std=gnu++98 and _GLIBCXX_USE_CXX11_ABI is set to zero then the binary
can be run on the old system with the old libstdc++.so from GCC 4.9.4, because
it does not use any new symbol. Maybe it is a side effect, but it does not
change the fact that it simply works.

Unfortunately _GLIBCXX_USE_CXX11_ABI does not help in case of using
-std=gnu++11, because conditional compilation in some header files ignores
_GLIBCXX_USE_CXX11_ABI  and rely only on __cplusplus >= 201103. I have
cross-compiled two programs with patched "stdexcept" and they now run on the
old system too, so I believe that there is a way how to make all binaries
portable.

[Bug c/16804] Function pointer assignment/initialization (-Wc++-compat warning missing from -Wincompatible-pointer-types)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|Function pointer|Function pointer
   |assignment/initialization   |assignment/initialization
   |(missing warning)   |(-Wc++-compat warning
   ||missing from
   ||-Wincompatible-pointer-type
   ||s)

--- Comment #7 from Eric Gallager  ---
(In reply to Martin Sebor from comment #6)
> GCC does diagnose the initialization with -Wc++-compat so it seems that
> making this work as suggested is just a matter of including the same warning
> in -Wincompatible-pointer-types:
> 
> $ gcc -S -Wc++-compat -xc z.C
> z.C:3:27: warning: pointer target types incompatible in C++ [-Wc++-compat]
> 3 | enum Moo (*Miau) (void) = quack;
>   |   ^
> 
> Even if enums are strictly compatible with unsigned the mismatch still is
> suggestive of a mistake on the part of the programmer and the warning would
> help detect it.

Retitling to clarify

[Bug c/49702] Undefined static functions resolve to external definitions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> Possibly related: bug 19315? (both cases of statics becoming externs; that
> for variables, this for functions)

Update: that has since been fixed by r263556; I haven't checked to see if that
revision fixed this bug too, yet, though...
(cc-ing Iain, who did that revision)

[Bug c/37041] [meta-bug] -Wc++-compat refinements

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||meta-bug
Summary|-Wc++-compat refinements|[meta-bug] -Wc++-compat
   ||refinements
  Alias||Wc++-compat

--- Comment #9 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> We should collect individual Wc++-compat issues here.

making it a meta-bug then; alias Wc++-compat

[Bug c++/68301] self-dependent reference member initialization not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing Manu due to this being an issue with -Wuninitialized and he's usually
pretty knowledgeable about those

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[linkw at gcc dot gnu.org]

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

--- Comment #18 from Kewen Lin  ---
Created attachment 46687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46687=edit
Powerpc case on vector rotation

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #9 from Marek Polacek  ---
I think I have a fix.  Will test tomorrow morning.

[Bug c++/87519] -Wsign-conversion -Wconversion explicit cast fails to silence warning

[Keith.S.Thompson at gmail dot com]

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

Keith Thompson  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail dot 
com

--- Comment #8 from Keith Thompson  ---
Another test case:

#include 
int main() {
int i = 42;
size_t s0 = sizeof (int) + (size_t)i;
size_t s1 = sizeof (int) + static_cast(i);
}

https://stackoverflow.com/q/57403497/827263
https://stackoverflow.com/a/57404123/827263

[Bug c++/78209] Decltype of rvalue reference

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
This seems to fix it:

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27598,6 +27598,8 @@ do_auto_deduction (tree type, tree init, tree
auto_node,
   else if (AUTO_IS_DECLTYPE (auto_node))
 {
   tree stripped_init = tree_strip_any_location_wrapper (init);
+  if (REFERENCE_REF_P (stripped_init))
+   stripped_init = TREE_OPERAND (stripped_init, 0);
   bool id = (DECL_P (stripped_init)
 || ((TREE_CODE (init) == COMPONENT_REF
  || TREE_CODE (init) == SCOPE_REF)

(then id is true and decltype deduces the right type).

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[luoxhu at cn dot ibm.com]

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

--- Comment #34 from Xiong Hu XS Luo  ---
(In reply to rguent...@suse.de from comment #32)
> On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > 
> > --- Comment #31 from Xiong Hu XS Luo  ---
> > (In reply to rguent...@suse.de from comment #30)
> > > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > > > 
> > > > --- Comment #28 from Xiong Hu XS Luo  ---
> > > > (In reply to Richard Biener from comment #24)
> > > > > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p 
> > > > > which
> > > > > has
> > > > > 
> > > > >   /* FIXME: Builtins corresponding to real functions probably should 
> > > > > have
> > > > >  symbol table entries.  */
> > > > >   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > > return false;
> > > > > 
> > > > > we could try to do sth like
> > > > > 
> > > > >   if (TREE_CODE (decl) == FUNCTION_DECL
> > > > >   && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > > > >   || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > > > >   && !associated_internal_fn (decl
> > > > > return false;
> > > > > 
> > > > > but that would still leave us with too many undefineds I guess
> > > > > (gcc_unreachable for one).
> > > > > 
> > > > > We do not currently track builtins that do have a library 
> > > > > implementation
> > > > > (whether that it is used in the end is another thing, but less 
> > > > > important).
> > > > > 
> > > > > What we definitely can do is put a whitelist above like via the 
> > > > > following
> > > > > which also catches the case of definitions of builtins.
> > > > > 
> > > > > Index: gcc/symtab.c
> > > > > ===
> > > > > --- gcc/symtab.c(revision 273968)
> > > > > +++ gcc/symtab.c(working copy)
> > > > > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > > > >   first place.  */
> > > > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > > > >  return false;
> > > > > +
> > > > >/* FIXME: Builtins corresponding to real functions probably should 
> > > > > have
> > > > >   symbol table entries.  */
> > > > > -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > > -return false;
> > > > > +  if (TREE_CODE (decl) == FUNCTION_DECL
> > > > > +  && !definition
> > > > > +  && fndecl_built_in_p (decl))
> > > > > +{
> > > > > +  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > > > > +   switch (DECL_FUNCTION_CODE (decl))
> > > > > + {
> > > > > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > > > > + CASE_FLT_FN (BUILT_IN_SIN):
> > > > > +   return true;
> > > > > + default:
> > > > > +   break;
> > > > > + }
> > > > > +  return false;
> > > > > +}
> > > > >  
> > > > >/* We have real symbol that should be in symbol table.  However 
> > > > > try to
> > > > > trim
> > > > >   down the refernces to libraries bit more because linker will 
> > > > > otherwise
> > > > 
> > > > Hi Richard, no undefineds generated with below code, what's your 
> > > > opinion about
> > > > the updated code, please? Thanks.
> > > 
> > > It will break code calling __builtin_unreachable for example since
> > > we'll emit an UNDEF that cannot be satisfied.
> > 
> > Thanks. I tried to add __builtin_unreachable() in the test case, it can also
> > works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
> > internal-fn.def, so associated_internal_fn will return IFN_LAST for it, 
> > then no
> > UNDEF of __builtin_unreachable will be emitted to object file.
> > 
> > Most of functions in internal-fn.def are math functions, I am not sure 
> > whether
> > you mean the BUILT_IN_NOP or something else?
> 
> OK, so a specific example woul dbe __builtin_clz.  IIRC the
> DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
> _not_ the symbol in libgcc (you'd have to double-check).
> 
> That said, using associated_internal_fn is probably mostly safe but
> not a complete fix since we have builtins like __builtin_strcpy
> as well (but of course the C library is always linked).
> 
> But I'm fine with an approach that incrementally improves things
> here, but without possibly causing link-failures due to bogus
> UNDEFs

Add x = __builtin_clz(x); and __builtin_strcpy(str, "test\n") to the test code,
the object file's symbol will be:
luoxhu@genoa lto $ ~/workspace/gcc-git/gcc-master_debug/gcc/gcc-nm
-B/home/luoxhu/workspace/gcc-git/gcc-master_debug/gcc/ atan2bashzowie.o
 U atan2
 U __builtin_clz
 T main
 U rand
 T rand_finite_double
 C str
 T zowie

_builtin_clz is also defined in internal-fn.def, it could be linked
successfully with libgcc.
__builtin_strcpy 

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[clhamilto at gmail dot com]

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

--- Comment #22 from Curtis Hamilton  ---
I've made progress in getting the go frontend to build, but have run into the
following error:

In file included from
/usr/ports/lang/gcc7/work/gcc-7.4.0/libgo/runtime/runtime.h:113:0,
 from
/usr/ports/lang/gcc7/work/gcc-7.4.0/libgo/go/reflect/makefunc_ffi_c.c:5:
./runtime.inc:779:17: error: field '_kern' has incomplete type
  struct __usem2 _kern;
 ^
In file included from
/usr/ports/lang/gcc7/work/gcc-7.4.0/libgo/runtime/runtime.h:113:0,
 from
/usr/ports/lang/gcc7/work/gcc-7.4.0/libgo/go/bytes/indexbyte.c:9:
./runtime.inc:779:17: error: field '_kern' has incomplete type
  struct __usem2 _kern;
 ^
gmake[6]: *** [Makefile:3342: bytes/index.lo] Error 1
gmake[6]: *** Waiting for unfinished jobs


I can't find any reference to "_kern" elswhere in the code.  Can someone help?

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Aug  7 22:33:27 2019
New Revision: 274201

URL: https://gcc.gnu.org/viewcvs?rev=274201=gcc=rev
Log:
2019-08-07  Steven G. Kargl  

PR fortran/91359
* pr91359_2.f:  Fix missing hyphen in dg-do
* pr91359_1.f:  Ditto.  Remove RESULT variable to test actual fix!

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr91359_1.f
trunk/gcc/testsuite/gfortran.dg/pr91359_2.f

[Bug fortran/88076] Shared Memory implementation for Coarrays

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #12 from kargl at gcc dot gnu.org ---
Hi Nicolas,

Any progress/update on a shared memory coarray implementation?

[Bug c++/91360] Implement P1143R2: constinit

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

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

[Bug c++/86974] Support Clang's require_constant_initialization attribute

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Yes it is.

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

[Bug c++/86974] Support Clang's require_constant_initialization attribute

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I think this is now "superseded" by PR91360, C++20 constinit.

[Bug c++/85125] constant expression with const_cast UB does not emit error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Recently I posted a patch for this:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01914.html

With that, the original testcase now gives:

85125.C:6:22: error: non-constant condition for static assertion
6 | static_assert(f()==77, "");
  |   ~~~^~~~
85125.C:6:20:   in ‘constexpr’ expansion of ‘f()’
85125.C:3:27: error: modifying a const object ‘(int&)(& i)’ is not allowed in a
constant expression
3 |   const_cast(i) = 88;
  |   ^~~~
85125.C:2:17: note: originally declared ‘const’ here
2 |   int const i = 77;
  | ^

and the one from Comment 3 gives:

85125-2.C:12:16: error: non-constant condition for static assertion
   12 | static_assert(f());
  |   ~^~
85125-2.C:12:16:   in ‘constexpr’ expansion of ‘f()’
85125-2.C:8:12: error: modifying a const object ‘*(int*)s.S::ptr’ is not
allowed in a constant expression
8 | *s.ptr = 2;
  | ~~~^~~
85125-2.C:7:16: note: originally declared ‘const’ here
7 | auto const s = S{};
  |^

[Bug c++/67533] internal compiler error: in build_call_a, at cp/call.c:372

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Test added.

Future improvements: 

[Bug translation/90117] Replace %<%s%> with %qs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Yes, it does, and most instances of this warning in GCC code should already be
cleaned up so I think we can resolve this bug as fixed.

$ cat pr90117.c && gcc -S -Wall -Wformat-diag pr90117.c
__attribute__ ((format (gcc_cdiag, 1, 2))) void 
cdiag (const char*, ...);

void f (void)
{
  cdiag ("%<%s%>", "");
}

pr90117.c: In function ‘f’:
pr90117.c:6:11: warning: quoted ‘%s’ directive in format; use ‘%qs’ instead
[-Wformat-diag]
6 |   cdiag ("%<%s%>", "");
  |   ^~

[Bug c++/67533] internal compiler error: in build_call_a, at cp/call.c:372

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug  7 21:21:57 2019
New Revision: 274200

URL: https://gcc.gnu.org/viewcvs?rev=274200=gcc=rev
Log:
PR c++/67533
* g++.dg/tls/thread_local-ice5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tls/thread_local-ice5.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/91385] Zero-extended negation (*negsi2_1_zext) is not generated

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
Fixed for gcc-10.

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[vsevolod.livinskij at frtk dot ru]

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

--- Comment #15 from Vsevolod Livinskiy  ---
I don't know if it is the same error or not, but the reproducer looks similar.
It takes about 11 minutes before GCC fails.

Reproducer:
extern int a[][1240092];
int b;
void c() {
  for (int d = 2; d <= 9; d++)
for (int e = 32; e <= 41; e++)
  b += a[d][5];
}

Error:
>$ gcc -march=skylake-avx512 -c -O3 small.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1

GCC version:
gcc version 10.0.0 (rev. 274155)

[Bug c++/91394] C++ ABI incompatibility (stdexcept)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to tomas_paukrt from comment #0)
> Some C++ programs cross-compiled with GCC 7.4.0 using -std=gnu++11 do not
> work on a system which have glibc 2.25 cross-compiled with GCC 4.9.4 even if
> the symbol _GLIBCXX_USE_CXX11_ABI was set to zero during cross-compilation.

What has the glibc version got to do with anything?

> A program that calls constructor out_of_range(const char*) will be using
> symbol _ZNSt12out_of_rangeC1EPKc@GLIBCXX_3.4.21 which is not present on the
> old system

If it's not present on the old system that means you're not using the
libstdc++.so from GCC 7.4.0, which you're required to do. You can't compile
with a new GCC and then use an old libstdc++.so at runtime. That's always been
true. Defining _GLIBCXX_USE_CXX11_ABI has nothing to do with that.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-07
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Thomas Koenig  ---
The first one, with the two different calls, should be flagged.  It does
not do so even with trunk.

Confirmed as an enhancement.

Of course, using modules would catch this.

[Bug c++/91391] Bogus -Wcomma-subscript

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #0)
[...]
> template-parameter-list, and I wonder whether it should warn about a
> (hypothetical) comma expression in a call to an overloaded operator [] at
> all.

([expr.pre]/2 "Overloaded operators obey the rules for syntax and evaluation
order specified in [expr.compound], but the requirements of operand type and
value category are replaced [...]", so it presumably shall warn there)

[Bug c/84685] Designated initializers warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug target/91385] Zero-extended negation (*negsi2_1_zext) is not generated

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Aug  7 18:34:11 2019
New Revision: 274183

URL: https://gcc.gnu.org/viewcvs?rev=274183=gcc=rev
Log:
PR target/91385
* config/i386/sse.md (*negsi2_1_zext): Simplify insn pattern.
(*negsi2_cmpz_zext): Ditto.

testsuite/ChangeLog:

PR target/91385
* gcc.target/i386/pr91385.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr91385.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/91391] Bogus -Wcomma-subscript

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/cp/parser.c.jj  2019-08-07 09:24:36.099089282 +0200
+++ gcc/cp/parser.c 2019-08-07 20:26:47.669663334 +0200
@@ -2102,7 +2102,7 @@ static cp_expr cp_parser_assignment_expr
 static enum tree_code cp_parser_assignment_operator_opt
   (cp_parser *);
 static cp_expr cp_parser_expression
-  (cp_parser *, cp_id_kind * = NULL, bool = false, bool = false);
+  (cp_parser *, cp_id_kind * = NULL, bool = false, bool = false, bool =
false);
 static cp_expr cp_parser_constant_expression
   (cp_parser *, bool = false, bool * = NULL, bool = false);
 static cp_expr cp_parser_builtin_offsetof
@@ -7524,33 +7524,9 @@ cp_parser_postfix_open_square_expression
  index = cp_parser_braced_list (parser, _nonconst_p);
}
   else
-   {
- /* [depr.comma.subscript]: A comma expression appearing as
-the expr-or-braced-init-list of a subscripting expression
-is deprecated.  A parenthesized comma expression is not
-deprecated.  */
- if (warn_comma_subscript)
-   {
- /* Save tokens so that we can put them back.  */
- cp_lexer_save_tokens (parser->lexer);
-
- /* Look for ',' that is not nested in () or {}.  */
- if (cp_parser_skip_to_closing_square_bracket_1 (parser,
- CPP_COMMA) == -1)
-   {
- auto_diagnostic_group d;
- warning_at (cp_lexer_peek_token (parser->lexer)->location,
- OPT_Wcomma_subscript,
- "top-level comma expression in array subscript "
- "is deprecated");
-   }
-
- /* Roll back the tokens we skipped.  */
- cp_lexer_rollback_tokens (parser->lexer);
-   }
-
- index = cp_parser_expression (parser);
-   }
+   index = cp_parser_expression (parser, NULL, /*cast_p=*/false,
+ /*decltype_p=*/false,
+ /*warn_comma_p=*/warn_comma_subscript);
 }

   parser->greater_than_is_operator_p = saved_greater_than_is_operator_p;
@@ -9932,12 +9908,13 @@ cp_parser_assignment_operator_opt (cp_pa
CAST_P is true if this expression is the target of a cast.
DECLTYPE_P is true if this expression is the immediate operand of decltype,
  except possibly parenthesized or on the RHS of a comma (N3276).
+   WARN_COMMA_P is true if a comma should be diagnosed.

Returns a representation of the expression.  */

 static cp_expr
 cp_parser_expression (cp_parser* parser, cp_id_kind * pidk,
- bool cast_p, bool decltype_p)
+ bool cast_p, bool decltype_p, bool warn_comma_p)
 {
   cp_expr expression = NULL_TREE;
   location_t loc = UNKNOWN_LOCATION;
@@ -9984,6 +9961,17 @@ cp_parser_expression (cp_parser* parser,
break;
   /* Consume the `,'.  */
   loc = cp_lexer_peek_token (parser->lexer)->location;
+  if (warn_comma_p)
+   {
+ /* [depr.comma.subscript]: A comma expression appearing as
+the expr-or-braced-init-list of a subscripting expression
+is deprecated.  A parenthesized comma expression is not
+deprecated.  */
+ warning_at (loc, OPT_Wcomma_subscript,
+ "top-level comma expression in array subscript "
+ "is deprecated");
+ warn_comma_p = false;
+   }
   cp_lexer_consume_token (parser->lexer);
   /* A comma operator cannot appear in a constant-expression.  */
   if (cp_parser_non_integral_constant_expression (parser, NIC_COMMA))

Untested fix prior to any merging of bool flags.  Guess that should be done
incrementally if at all, so that the merit can be judged separately.
Wonder about the auto_diagnostic_group d; in your earlier change, isn't
something like that needed only if you call more than one diagnostic routine
and want all of them being treated as a group?  In this case there is just one
warning_at, so it makes no sense to me.
The cp_parser_namespace_name use doesn't make sense to me either.

[Bug translation/90117] Replace %<%s%> with %qs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Martin, does -Wformat-diag catch this?

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Fixed on trunk, will backport to 9.3 later.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug  7 17:32:12 2019
New Revision: 274181

URL: https://gcc.gnu.org/viewcvs?rev=274181=gcc=rev
Log:
PR c++/81429 - wrong parsing of constructor with C++11 attribute.
* parser.c (cp_parser_constructor_declarator_p): Handle the scenario
when a parameter declaration begins with [[attribute]].

* g++.dg/cpp0x/gen-attrs-68.C: New test.
* g++.dg/cpp0x/gen-attrs-69.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-68.C
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-69.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c/67224] UTF-8 support for identifier names in GCC

[joseph at codesourcery dot com]

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

--- Comment #30 from joseph at codesourcery dot com  ---
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future

is the form to complete and send to ass...@gnu.org (to do an assignment 
covering past and future changes to GCC, which is usually the best one to 
use).

[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Martin Sebor from comment #1)
> > Confirmed.  There are few other similar bugs for these fix-it hints (e.g.,
> > pr80567 or pr80684).  I haven't looked at the implementation but from the
> > symptoms it feels like the problem is that the search doesn't fully consider
> > the context in which the undeclared is used.   I.e., it doesn't distinguish
> > between a function call, other kinds of expressions, a type, or even a
> > keyword, etc.
> 
> Hopefully GCC can learn to make these distinctions in time for GCC 9.

er, well, GCC 10 now

[Bug c/82967] "did you mean" suggestions are way too suggestive

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|9.2 |8.5

--- Comment #14 from Eric Gallager  ---
(In reply to David Malcolm from comment #11)
> Fixed on trunk; keeping open until I backport it to gcc-8-branch.

adjusting target milestone then

[Bug c++/91391] Bogus -Wcomma-subscript

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #2)
> ...except when it's:
> 
> void
> fn (int *a, int b, int c)
> {
>   a[b < c, b > c]; // should warn
> }

Maybe handle it instead with a parser flag that in certain contexts you
temporarily enable or disable?
Temporarily enable when parsing the [] expression and temporarily disable when
parsing an assignment expression?
Or instead hand inline cp_parser_expression into
cp_parser_postfix_open_square_expression and do the warning in the inlined
code?
Or add another defaulted argument to cp_parser_expression and only warn if that
argument is true and only pass true if called from
cp_parser_postfix_open_square_expression?
Or somehow merge the cast_p, decltype_p and this new warn_comma_p into a
bitmask (using enum?) and just pass one argument instead of 3?

[Bug c/88451] No rounding in fixed-point arithmetic (Decimal to fixed-point conversion, multiplication)

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
I don't think anyone has really been maintaining the fixed-point support 
for a very long time.

[Bug c++/91394] New: C++ ABI incompatibility (stdexcept)

[tomas_paukrt at conel dot cz]

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

Bug ID: 91394
   Summary: C++ ABI incompatibility (stdexcept)
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas_paukrt at conel dot cz
  Target Milestone: ---

Some C++ programs cross-compiled with GCC 7.4.0 using -std=gnu++11 do not work
on a system which have glibc 2.25 cross-compiled with GCC 4.9.4 even if the
symbol _GLIBCXX_USE_CXX11_ABI was set to zero during cross-compilation.

There are several places in the file "stdexcept" like this:

> class out_of_range : public logic_error 
> {
> public:
>   explicit out_of_range(const string& __arg) _GLIBCXX_TXN_SAFE;
> #if __cplusplus >= 201103L
>   explicit out_of_range(const char*) _GLIBCXX_TXN_SAFE;
> #endif
>   virtual ~out_of_range() _GLIBCXX_USE_NOEXCEPT;
> };

A program that calls constructor out_of_range(const char*) will be using symbol
_ZNSt12out_of_rangeC1EPKc@GLIBCXX_3.4.21 which is not present on the old
system, so I suggest to change the conditional compilation on such places to
this:

> #if _GLIBCXX_USE_CXX11_ABI && __cplusplus >= 201103L
>   explicit out_of_range(const char*) _GLIBCXX_TXN_SAFE;
> #endif

[Bug lto/91393] New: lto1: internal compiler error: decompressed stream: Destination buffer is too small

[dcb314 at hotmail dot com]

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

Bug ID: 91393
   Summary: lto1: internal compiler error: decompressed stream:
Destination buffer is too small
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Command line is

gcc -shared  -fPIC -DPIC  .libs/__fxstatat.o .libs/__fxstatat64.o
.libs/__getcwd_chk.o .libs/__getwd_chk.o .libs/__lxstat.o .libs/__lxstat64.o
.libs/__open.o .libs/__open64.o .libs/__open64_2.o .libs/__open_2.o
.libs/__openat64_2.o .libs/__openat_2.o .libs/__opendir2.o
.libs/__readlink_chk.o .libs/__readlinkat_chk.o .libs/__realpath_chk.o
.libs/__statfs.o .libs/__xmknod.o .libs/__xmknodat.o .libs/__xstat.o
.libs/__xstat64.o .libs/_xftw.o .libs/_xftw64.o .libs/access.o .libs/acct.o
.libs/audit_log_acct_message.o .libs/bind.o .libs/bindtextdomain.o
.libs/canonicalize_file_name.o .libs/chdir.o .libs/chmod.o .libs/chown.o
.libs/chroot.o .libs/clearenv.o .libs/connect.o .libs/creat.o .libs/creat64.o
.libs/dedotdot.o .libs/dl_iterate_phdr.o .libs/dladdr.o .libs/dlmopen.o
.libs/dlopen.o .libs/eaccess.o .libs/euidaccess.o .libs/execl.o .libs/execle.o
.libs/execlp.o .libs/execv.o .libs/execve.o .libs/execvp.o .libs/faccessat.o
.libs/fchmodat.o .libs/fchownat.o .libs/fopen.o .libs/fopen64.o .libs/freopen.o
.libs/freopen64.o .libs/fts.o .libs/fts64.o .libs/ftw.o .libs/ftw64.o
.libs/futimesat.o .libs/get_current_dir_name.o .libs/getcwd.o
.libs/getcwd_real.o .libs/getpeername.o .libs/getsockname.o .libs/getwd.o
.libs/getxattr.o .libs/glob.o .libs/glob64.o .libs/glob_pattern_p.o
.libs/inotify_add_watch.o .libs/lchmod.o .libs/lchown.o .libs/lckpwdf.o
.libs/lgetxattr.o .libs/libfakechroot.o .libs/link.o .libs/linkat.o
.libs/listxattr.o .libs/llistxattr.o .libs/lremovexattr.o .libs/lsetxattr.o
.libs/lstat.o .libs/lstat64.o .libs/lutimes.o .libs/mkdir.o .libs/mkdirat.o
.libs/mkdtemp.o .libs/mkfifo.o .libs/mkfifoat.o .libs/mknod.o .libs/mknodat.o
.libs/mkostemp.o .libs/mkostemp64.o .libs/mkostemps.o .libs/mkostemps64.o
.libs/mkstemp.o .libs/mkstemp64.o .libs/mkstemps.o .libs/mkstemps64.o
.libs/mktemp.o .libs/open.o .libs/open64.o .libs/openat.o .libs/openat64.o
.libs/opendir.o .libs/pathconf.o .libs/popen.o .libs/posix_spawn.o
.libs/posix_spawnp.o .libs/rawmemchr.o .libs/readlink.o .libs/readlinkat.o
.libs/realpath.o .libs/rel2abs.o .libs/rel2absat.o .libs/remove.o
.libs/removexattr.o .libs/rename.o .libs/renameat.o .libs/revoke.o
.libs/rmdir.o .libs/rpl_lstat.o .libs/scandir.o .libs/scandir64.o
.libs/setenv.o .libs/setxattr.o .libs/stat.o .libs/stat64.o .libs/statfs.o
.libs/statfs64.o .libs/statvfs.o .libs/statvfs64.o .libs/stpcpy.o
.libs/strchrnul.o .libs/strlcpy.o .libs/symlink.o .libs/symlinkat.o
.libs/system.o .libs/tempnam.o .libs/tmpnam.o .libs/truncate.o
.libs/truncate64.o .libs/ulckpwdf.o .libs/unlink.o .libs/unlinkat.o
.libs/utime.o .libs/utimensat.o .libs/utimes.o   -ldl -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -g -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld   -Wl,-soname
-Wl,libfakechroot.so -o .libs/libfakechroot.so
lto1: internal compiler error: decompressed stream: Destination buffer is too
small
0xb95044 lto_uncompression_zstd
../../trunk/gcc/lto-compress.c:170
0xb95044 lto_end_uncompression(lto_compression_stream*, lto_compression)
../../trunk/gcc/lto-compress.c:408
0xb92f7c lto_get_section_data(lto_file_decl_data*, lto_section_type, char
const*, unsigned long*, bool)
../../trunk/gcc/lto-section-in.c:164
0x86876c cgraph_node::get_untransformed_body()
../../trunk/gcc/cgraph.c:3578

What would I need to do to encourage zstd to use a larger buffer ?

svn blame says

272996 marxin   if (ZSTD_isError (dsize))
272996 marxin internal_error ("decompressed stream: %s",
ZSTD_getErrorName (dsize));

[Bug c++/91388] -Wreturn-type "no return statement" warning in function that is already ill-formed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
That's for C and this is very specifically about C++ (as I'm attempting to
suppress duplicate errors after manually diagnosing ill-formed instantiations
of a template, via type traits and if-constexpr ... none of which exist in C
:-)

Definitely appropriate for the "See Also" field though, thanks.

[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

Summary|[9/10 Regression] -MF   |[9 Regression] -MF clashes
   |clashes with -flto on   |with -flto on aarch64
   |aarch64 |

--- Comment #41 from Richard Earnshaw  ---
Fixed on trunk so far.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #40 from Richard Earnshaw  ---
Author: rearnsha
Date: Wed Aug  7 16:15:35 2019
New Revision: 274176

URL: https://gcc.gnu.org/viewcvs?rev=274176=gcc=rev
Log:
PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC_OPTIONS in
lto-wrapper.c

Some options are handled differently by the main driver (gcc, g++,
etc) from the back-end compiler programs (cc1, cc1plus, etc) in that
in the driver they do not take an additional argument, while in the
compiler programs they do.  The processing option option CL_DRIVER
controls this alternative interpretation of the options.

The environment variable COLLECT_GCC_OPTIONS is the list of options to
add to a compile if the compiler re-invokes itself at some point.  As
such, the options are driver options, so CL_DRIVER should be used when
processing this list.  Currently lto-wrapper is doing this
incorrectly.

PR driver/91130
* lto-wrapper.c (find_and_merge_options): Use CL_DRIVER when
processing COLLECT_GCC_OPTIONS.
(run_gcc): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #19 from Segher Boessenkool  ---
So how does this cause 12% degradation (20% by some other measurements)
on power9?  Pretty much everything is the *opposite* way around for us:
we do have cheap conditional moves, we do prefer integer registers.

[Bug jit/91330] JIT "dir" entry for info is incomplete

[tromey at gcc dot gnu.org]

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

--- Comment #1 from Tom Tromey  ---
This is pretty easy to fix in gcc/jit/docs/conf.py:

diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 3e630db47ef..1224bdcc07d 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -244,7 +244,7 @@ man_pages = [
 #  dir menu entry, description, category)
 texinfo_documents = [
   ('index', 'libgccjit', u'libgccjit Documentation',
-   u'David Malcolm', 'libgccjit', 'One line description of project.',
+   u'David Malcolm', 'libgccjit', 'GCC-based Just In Time compiler library.',
'Miscellaneous'),
 ]




However, I don't have the version of sphinx that was used to generate
the docs, and when I run the version I do have, there are tons of changes.
So, maybe someone else ought to do this part.

[Bug translation/90121] extra space in error message

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|9.2 |---

--- Comment #3 from Eric Gallager  ---
non-regressions don't get a target milestone

[Bug tree-optimization/88771] Misleading -Werror=array-bounds error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|9.2 |---

--- Comment #24 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #22)
> Martin cleaned up the warning message and I'm considering that as fixing the
> regression.  Thus regression marker removed.

So... that means the target milestone can be removed, too, right? I'm doing
that

> 
> I doubt everyone is in agreement on the overall "should we warn or not"
> question. So I'm keeping the BZ open.  I wouldn't be at all surprised if
> there is no consensus possible WRT whether or not we should be warning. 
> Which usually leads to a flag to enable/disable the particular behavior ;(

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #17 from Richard Earnshaw  ---
Created attachment 46686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46686=edit
candidate patch

Could you try this patch please?  So far only very lightly tested.

[Bug c/91392] New: g++: internal compiler error: Aborted (program cc1plus)

[harry.onslow at emenda dot com]

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

Bug ID: 91392
   Summary: g++: internal compiler error: Aborted (program
cc1plus)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harry.onslow at emenda dot com
  Target Milestone: ---

Created attachment 46685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46685=edit
the preprocessed file (*.ii*) that triggers the bug

Hi Support,
Please find the required details below.
Regards,
Harry


D:\workspace\cases\6088\workspace>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw
--with-isl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
--with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared
--enable-threads --with-dwarf2 --disable-sjlj-exceptions
--enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw
--with-libintl-prefix=/mingw --enable-libstdcxx-debug --with-tune=generic
--enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

D:\workspace\cases\6088\workspace>g++ -c -std=c++14 10_MISRA.PTR.ARITH.cpp
-save-temps
10_MISRA.PTR.ARITH.cpp: In constructor
'workspace::project::Wrapper::Wrapper(workspace::project::Wrapper&&)':
10_MISRA.PTR.ARITH.cpp:8:8: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:677
 struct Wrapper
^~~

10_MISRA.PTR.ARITH.cpp:8:8: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #16 from Richard Earnshaw  ---
I had the wrong set of insns previously. The problem cases are:

(insn/f 8031 8030 8303 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28))
(nil
(note 8303 8031 7890 4 NOTE_INSN_PROLOGUE_END)
(insn:TI 7890 8303 7889 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 704 [0x2c0])) [63 %sfp+-2912 S8 A64])
(reg/f:DI 2 x2 [1833])) "../include/list.h":29:13 47 {*movdi_aarch64}
 (nil))
(insn 7889 7890 7887 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 712 [0x2c8])) [63 %sfp+-2904 S8 A64])
(reg/f:DI 3 x3 [1834])) "../include/list.h":29:13 47 {*movdi_aarch64}
 (nil))
(insn:TI 7887 7889 229 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 720 [0x2d0])) [63 %sfp+-2896 S8 A64])
(reg/f:DI 4 x4 [1838])) "log.c":422:11 47 {*movdi_aarch64}
 (nil))

Which after peephole2 is transformed to:

(insn/f 8031 8030 8303 4 (set (mem/c:DI (reg:DI 7 x7) [17  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28))
(nil
(note 8303 8031 8556 4 NOTE_INSN_PROLOGUE_END)
(insn 8556 8303 7887 4 (parallel [
(set (mem/c:DI (plus:DI (reg:DI 7 x7)
(const_int 8 [0x8])) [63 %sfp+-2912 S8 A64])
(reg/f:DI 2 x2 [1833]))
(set (mem/c:DI (plus:DI (reg:DI 7 x7)
(const_int 16 [0x10])) [63 %sfp+-2904 S8 A64])
(reg/f:DI 3 x3 [1834]))
]) "../include/list.h":29:13 -1
 (nil))
(insn:TI 7887 8556 8557 4 (set (mem/c:DI (plus:DI (reg:DI 7 x7)
(const_int 24 [0x18])) [63 %sfp+-2896 S8 A64])
(reg/f:DI 4 x4 [1838])) "log.c":422:11 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg/f:DI 4 x4 [1838])
(nil)))

In this case, it looks like one of the 4-store peepholes has been partially
applied, and then failed for some reason, but the modifications have not been
unwound.  (there is then a second peephole that does match the second and third
stores which confuses things a bit).

The reason for the non-match is that one of the insns has a frame-related note
set on it, but the peephole produces three output isns and we can't handle
that.

I think the fix is to make a full copy of the mems before doing the adjust;
then if the change is unwound we haven't modified the original insns by
mistake.

[Bug c/91285] _Pragma does not work in a useful fashion

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Note that all the standard C pragmas are even more restricted than GCC's 
statement-like pragmas - the standard pragmas (which aren't implemented in 
GCC) are defined by the C standard to be allowed only "either outside 
external declarations or preceding all explicit declarations and 
statements inside a compound statement".

The wider the range of contexts in which a pragma is permitted, the harder 
it is to define its semantics.  For diagnostic pragmas, note that some 
diagnostics are associated with a *range* of locations within an 
expression, leading to obvious questions about the semantics if diagnostic 
pragma state varies within that range.  (Though that could also arise when 
statement-like pragmas are used within the existing statement expression 
extension.)

[Bug c++/91391] Bogus -Wcomma-subscript

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
...except when it's:

void
fn (int *a, int b, int c)
{
  a[b < c, b > c]; // should warn
}

[Bug c++/91334] [10 Regression] ICE in propagate_necessity at gcc/tree-ssa-dce.c:813 since r273791

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
[hjl@gnu-mic-1 build_base_lto.]$
/export/gnu/import/git/gcc-test-spec-lto/usr/bin/g++ -S -DSPEC_CPU -DNDEBUG 
-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
-Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O2
   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX XPath.cpp  -ffast-math
In file included from ./XPathDefinitions.hpp:21,
 from XPath.hpp:22,
 from XPath.cpp:18:
XPath.cpp: In member function ‘void
xalanc_1_8::XPath::executeMore(xalanc_1_8::XalanNode*,
xalanc_1_8::XPath::OpCodeMapPositionType, xalanc_1_8::XPathExecutionContext&,
xalanc_1_8::FormatterListener&, xalanc_1_8::XPath::MemberFunctionPtr) const’:
./PlatformDefinitions.hpp:66:35: internal compiler error: Segmentation fault
   66 |  #define XALAN_CPP_NAMESPACE_END  }
  |   ^
XPath.cpp:5696:1: note: in expansion of macro ‘XALAN_CPP_NAMESPACE_END’
 5696 | XALAN_CPP_NAMESPACE_END
  | ^~~
0xfbcc0f crash_signal
../../src-trunk/gcc/toplev.c:326
0xb26b73 lookup_page_table_entry
../../src-trunk/gcc/ggc-page.c:632
0xb26b73 ggc_set_mark(void const*)
../../src-trunk/gcc/ggc-page.c:1531
0xd6a781 gt_ggc_mx_symtab_node(void*)
/export/gnu/import/git/gcc-test-spec-lto/bld/gcc/gtype-desc.c:1302
0xee51fd gt_ggc_ma_order
./gt-passes.h:31
0xee51fd gt_ggc_ma_order
./gt-passes.h:26
0xcf6995 ggc_mark_root_tab
../../src-trunk/gcc/ggc-common.c:77
0xcf6b9c ggc_mark_roots()
../../src-trunk/gcc/ggc-common.c:94
0xb274f5 ggc_collect()
../../src-trunk/gcc/ggc-page.c:2201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-mic-1 build_base_lto.]$ 

-O2 -ffast-math is needed to trigger ICE.

[Bug c++/91380] Requesting a better diagnostic for dumb include mistake

[barry.revzin at gmail dot com]

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

--- Comment #3 from Barry Revzin  ---
In case it's at all helpful, here's the clang review that Tim found for this
diagnostic: https://reviews.llvm.org/D51333

[Bug c++/91388] -Wreturn-type "no return statement" warning in function that is already ill-formed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
related to and/or possible dup of bug 60440?

[Bug libgcc/91379] internal compiler error __gcov_fork

[cbunch at cfhp dot com]

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

--- Comment #2 from Clinton Bunch  ---
As I stated, I've tried to compile 4.9.4, 5.3.0, 5.5.0, 6.1.0, 6.5.0 and 8.3.0
I get the same error on all of them.  I reported on 9.1.0 as it is the current
version.  I can't get a gcc more recent than 4.9.2 to even attempt a build and
none of these versions will compile with the HP C/C++ compiler.

[Bug c++/91391] Bogus -Wcomma-subscript

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-07
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine, we shouldn't warn about ',' nested in < >.

[Bug c++/91391] New: Bogus -Wcomma-subscript

[sbergman at redhat dot com]

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

Bug ID: 91391
   Summary: Bogus -Wcomma-subscript
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent git master (4ad9380bafd772cea54392c7189cab07a2121fc9 here):

> $ cat test.cc
> #include 
> #include 
> int main() {
> std::map, int> m;
> m[std::pair(0, 0)] = 0;
> }

> $ g++ -fsyntax-only -std=c++2a test.cc
> test.cc: In function ‘int main()’:
> test.cc:5:20: warning: top-level comma expression in array subscript is 
> deprecated [-Wcomma-subscript]
> 5 | m[std::pair(0, 0)] = 0;
>   |^

It should apparently not warn about the nested comma in the
template-parameter-list, and I wonder whether it should warn about a
(hypothetical) comma expression in a call to an overloaded operator [] at all.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #15 from Richard Earnshaw  ---
From looking at the dumps it would appear that one of the STP generating
peepholes might have bailed out, but that some of the changes have not been
undone.

From the pass before, we have:

(insn/f:TI 8028 8027 8029 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 672 [0x2a0])) [17  S8 A8])
(reg:DI 25 x25)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 25 x25)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 672 [0x2a0])) [17  S8 A8])
(reg:DI 25 x25))
(nil
(insn/f 8029 8028 8030 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 680 [0x2a8])) [17  S8 A8])
(reg:DI 26 x26)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 26 x26)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 680 [0x2a8])) [17  S8 A8])
(reg:DI 26 x26))
(nil
(insn/f:TI 8030 8029 8031 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 688 [0x2b0])) [17  S8 A8])
(reg:DI 27 x27)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 27 x27)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 688 [0x2b0])) [17  S8 A8])
(reg:DI 27 x27))
(nil
(insn/f 8031 8030 8303 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28))

Which looks like a perfect candidate for replacing with two STP instructions.

After peepholing, we have:

(insn/f:TI 8028 8027 8029 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 672 [0x2a0])) [17  S8 A8])
(reg:DI 25 x25)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 25 x25)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 672 [0x2a0])) [17  S8 A8])
(reg:DI 25 x25))
(nil
(insn/f 8029 8028 8030 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 680 [0x2a8])) [17  S8 A8])
(reg:DI 26 x26)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 26 x26)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 680 [0x2a8])) [17  S8 A8])
(reg:DI 26 x26))
(nil
(insn/f:TI 8030 8029 8031 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 688 [0x2b0])) [17  S8 A8])
(reg:DI 27 x27)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 27 x27)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 688 [0x2b0])) [17  S8 A8])
(reg:DI 27 x27))
(nil
(insn/f 8031 8030 8303 4 (set (mem/c:DI (reg:DI 7 x7) [17  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [17  S8 A8])
(reg:DI 28 x28))
(nil

And we can see that the last insn has been modified.  There's nothing earlier
in the log to suggest that there was any substitution here.

My suspicion is this hunk:

  replace_equiv_address_nv (mem_1, plus_constant (Pmode, operands[8],
  new_off_1), true);
  replace_equiv_address_nv (mem_2, plus_constant (Pmode, operands[8],
  new_off_1 + msize), true);
  replace_equiv_address_nv (mem_3, plus_constant (Pmode, operands[8],
  new_off_3), true);
  replace_equiv_address_nv (mem_4, plus_constant (Pmode, operands[8],
  new_off_3 + msize), true);

  if (!aarch64_mem_pair_operand (mem_1, mode)
  || !aarch64_mem_pair_operand (mem_3, mode))
return false;

Is somehow modifying the insn in-place, but then the test is failing somehow.

[Bug tree-optimization/91227] pointer relational expression not folded but equivalent inequality is

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
Just to be clear: my suggestion to fold the relational expressions is only for
incoming pointers with addresses of local variables that GCC already assumes
cannot be synthesized (I assume it does that on the basis of what the
provenance proposals refer to as address nondeterminism).  I am not suggesting
to fold arbitrary relational expressions in general.

[Bug c++/91346] Implement P1668R1: Permit unevaluated inline asm in constexpr functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Implemented for 10.1.

[Bug c++/91346] Implement P1668R1: Permit unevaluated inline asm in constexpr functions

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug  7 14:20:40 2019
New Revision: 274169

URL: https://gcc.gnu.org/viewcvs?rev=274169=gcc=rev
Log:
PR c++/91346 - Implement P1668R1, allow unevaluated asm in constexpr.
* constexpr.c (cxx_eval_constant_expression): Handle ASM_EXPR.
(potential_constant_expression_1) : Allow.
* cp-tree.h (finish_asm_stmt): Adjust.
* parser.c (cp_parser_asm_definition): Grab the locaion of "asm" and
use it.  Change an error to a pedwarn.  Allow asm in C++2a, warn
otherwise.
* pt.c (tsubst_expr): Pass a location down to finish_asm_stmt.
* semantics.c (finish_asm_stmt): New location_t parameter.  Use it.

* g++.dg/cpp2a/inline-asm1.C: New test.
* g++.dg/cpp2a/inline-asm2.C: New test.
* g++.dg/cpp1y/constexpr-neg1.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/inline-asm1.C
trunk/gcc/testsuite/g++.dg/cpp2a/inline-asm2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-neg1.C

[Bug translation/79618] prevent missing space in multiline string literals

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
It doesn't.  -Wformat-diag runs after adjacent string literals have been
concatenated.  Detecting these kinds of issues would mean enhancing the
preprocessor.

[Bug sanitizer/91389] [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Don't do it then?  The no fallthru early discovery isn't perfect and with the
sanitizer instrumentation it gets even harder.
Looks like a dup of PR86899 to me anyway.
If I do a small modification like:
class A {
  struct B {
enum {} type;
  };
  B *m_fn1();
};
struct C { C (); ~C (); };
A::B *A::m_fn1() {
  C c;
  B *a;
  switch (a->type) {
break;
  default:
return a;
  }
}
then it emits the false positive warning even with just -O0 -Wreturn-type.
I really think it doesn't hurt if people remove the clearly unreachable code
from their code to get rid of this warning.

[Bug rtl-optimization/91332] ICE: Segfault in gfortran when compiling massive subroutine with -O3

[clogged.drainpipe at gmail dot com]

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

--- Comment #2 from Madarpok .  ---
I can confirm that raising the stack limit with ulimit -s unlimited does not
prevent this crash.
Something inside gfortran is breaking/overflowing.

[Bug fortran/91390] New: treatment of extra parameter in a subroutine call

[valera.veryazov at teokem dot lu.se]

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

Bug ID: 91390
   Summary: treatment of extra parameter in a subroutine call
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valera.veryazov at teokem dot lu.se
  Target Milestone: ---

 file1.f =
program test
n=10
c   correct call
   call s('hej')
c   one extra parameter
   call s('hej',n)
   end
 file2.f =
   subroutine s(a)
   character a*(*)
   print *, len(a)
   end

First call is correct, the second call prints garbage. 
(of course, it is not a bug, but a feature of handling 
strings as a parameter).

[Bug sanitizer/91389] New: [7/8/9/10 Regression] error: control reaches end of non-void function with -fsanitize=thread since r219201

[marxin at gcc dot gnu.org]

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

Bug ID: 91389
   Summary: [7/8/9/10 Regression] error: control reaches end of
non-void function with -fsanitize=thread since r219201
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Starting from the revision we generate a warning:

$ cat godot2.ii
class A {
  struct B {
enum {} type;
  };
  B *m_fn1();
};
A::B *A::m_fn1() {
  B *a;
  switch (a->type) {
break;
  default:
return a;
  }
}

$ g++ -c godot2.ii  -c -Werror=return-type
$ g++ -c godot2.ii  -c -Werror=return-type -fsanitize=thread
godot2.ii: In member function ‘A::B* A::m_fn1()’:
godot2.ii:14:1: error: control reaches end of non-void function
[-Werror=return-type]
   14 | }
  | ^
cc1plus: some warnings being treated as errors

Can you Jakub please take a look?

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[edlinger at gcc dot gnu.org]

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

--- Comment #9 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Aug  7 13:45:06 2019
New Revision: 274163

URL: https://gcc.gnu.org/viewcvs?rev=274163=gcc=rev
Log:
2019-08-07  Bernd Edlinger  

PR tree-optimization/91109
* lra-remat.c (update_scratch_ops): Remove assignment of the
hard register.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #39 from Martin Liška  ---
(In reply to Richard Biener from comment #34)
> So like the following then.
> 
> Index: gcc/lto-wrapper.c
> ===
> --- gcc/lto-wrapper.c   (revision 274111)
> +++ gcc/lto-wrapper.c   (working copy)
> @@ -133,7 +133,6 @@ maybe_unlink (const char *file)
>  static void
>  get_options_from_collect_gcc_options (const char *collect_gcc,
>   const char *collect_gcc_options,
> - unsigned int lang_mask,
>   struct cl_decoded_option
> **decoded_options,
>   unsigned int *decoded_options_count)
>  {
> @@ -176,8 +175,7 @@ get_options_from_collect_gcc_options (co
>argc = obstack_object_size (_obstack) / sizeof (void *) - 1;
>argv = XOBFINISH (_obstack, const char **);
>  
> -  decode_cmdline_options_to_array (argc, (const char **)argv,
> -  lang_mask,
> +  decode_cmdline_options_to_array (argc, (const char **)argv, CL_DRIVER,
>decoded_options, decoded_options_count);
>obstack_free (_obstack, NULL);
>  }
> @@ -1009,8 +1007,7 @@ find_and_merge_options (int fd, off_t fi
>  {
>struct cl_decoded_option *f2decoded_options;
>unsigned int f2decoded_options_count;
> -  get_options_from_collect_gcc_options (collect_gcc,
> -   fopts, CL_LANG_ALL,
> +  get_options_from_collect_gcc_options (collect_gcc, fopts,
> _options,
> _options_count);
>if (!fdecoded_options)
> @@ -1283,7 +1280,6 @@ run_gcc (unsigned argc, char *argv[])
>  fatal_error (input_location,
>  "environment variable % must be set");
>get_options_from_collect_gcc_options (collect_gcc, collect_gcc_options,
> -   CL_LANG_ALL,
> _options,
> _options_count);

Great, the patch works on aarch64. So the problem I saw before was probably
related to the second usage of CL_LANG_ALL that I didn't replace with
CL_DRIVER.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
(In reply to Martin Liška from comment #13)
> > 
> > The key question is how does one dump rtl with -flto? It doesn't work at
> > all, making debugging this difficult...
> 
> It does, look:
> 
> marxin@marxinbox:/tmp> gcc -c main.c -flto
> marxin@marxinbox:/tmp> gcc main.o -flto -o 

Ah right, so you need an explicit -o, otherwise it doesn't write the dump
files in the current directory...

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
> 
> The key question is how does one dump rtl with -flto? It doesn't work at
> all, making debugging this difficult...

It does, look:

marxin@marxinbox:/tmp> gcc -c main.c -flto
marxin@marxinbox:/tmp> gcc main.o -flto -o 
marxin@marxinbox:/tmp> gcc main.o -flto -o  -fdump-rtl-all
marxin@marxinbox:/tmp> ls -l xxx*
-rwxr-xr-x 1 marxin users 20544 Aug  7 15:28 
-rw-r--r-- 1 marxin users  1454 Aug  7 15:28 .ltrans0.233r.expand
-rw-r--r-- 1 marxin users  1041 Aug  7 15:28 .ltrans0.234r.vregs
-rw-r--r-- 1 marxin users  1042 Aug  7 15:28
.ltrans0.235r.into_cfglayout
-rw-r--r-- 1 marxin users  1997 Aug  7 15:28 .ltrans0.236r.jump
-rw-r--r-- 1 marxin users  1010 Aug  7 15:28 .ltrans0.248r.reginfo
-rw-r--r-- 1 marxin users  1069 Aug  7 15:28
.ltrans0.269r.outof_cfglayout
-rw-r--r-- 1 marxin users  1041 Aug  7 15:28 .ltrans0.270r.split1
-rw-r--r-- 1 marxin users  2389 Aug  7 15:28 .ltrans0.272r.dfinit
-rw-r--r-- 1 marxin users  2471 Aug  7 15:28 .ltrans0.273r.mode_sw
-rw-r--r-- 1 marxin users  2389 Aug  7 15:28 .ltrans0.274r.asmcons
-rw-r--r-- 1 marxin users  4419 Aug  7 15:28 .ltrans0.279r.ira
-rw-r--r-- 1 marxin users  4519 Aug  7 15:28 .ltrans0.280r.reload
-rw-r--r-- 1 marxin users  2158 Aug  7 15:28
.ltrans0.282r.postreload_jump
-rw-r--r-- 1 marxin users  2126 Aug  7 15:28 .ltrans0.285r.split2
-rw-r--r-- 1 marxin users  3635 Aug  7 15:28
.ltrans0.289r.pro_and_epilogue
-rw-r--r-- 1 marxin users  3178 Aug  7 15:28 .ltrans0.292r.jump2
-rw-r--r-- 1 marxin users  3228 Aug  7 15:28 .ltrans0.305r.stack
-rw-r--r-- 1 marxin users  3146 Aug  7 15:28 .ltrans0.306r.alignments
-rw-r--r-- 1 marxin users  3146 Aug  7 15:28 .ltrans0.308r.mach
-rw-r--r-- 1 marxin users  3146 Aug  7 15:28 .ltrans0.309r.barriers
-rw-r--r-- 1 marxin users  3257 Aug  7 15:28 .ltrans0.314r.shorten
-rw-r--r-- 1 marxin users  3257 Aug  7 15:28 .ltrans0.315r.nothrow
-rw-r--r-- 1 marxin users  3847 Aug  7 15:28 .ltrans0.316r.dwarf2
-rw-r--r-- 1 marxin users  3257 Aug  7 15:28 .ltrans0.317r.final
-rw-r--r-- 1 marxin users  1960 Aug  7 15:28 .ltrans0.318r.dfinish

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #12 from Wilco  ---
(In reply to Martin Liška from comment #10)
> I'm attaching all tree and rtl dumps for the problematic LTRANS unit:
> https://drive.google.com/file/d/1CW4cWvpm1VVXFIP80XCf1IzYXWwTsynZ/
> view?usp=sharing
> 
> I can confirm what Andreas sees:
> 
> (note 8303 8031 7890 4 NOTE_INSN_PROLOGUE_END)
> (insn:TI 7890 8303 7889 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
> (const_int 704 [0x2c0])) [63 %sfp+-2912 S8 A64])
> (reg/f:DI 2 x2 [1833])) "../include/list.h":29:13 47 {*movdi_aarch64}
>  (nil))
> (insn 7889 7890 7887 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
> (const_int 712 [0x2c8])) [63 %sfp+-2904 S8 A64])
> (reg/f:DI 3 x3 [1834])) "../include/list.h":29:13 47 {*movdi_aarch64}
>  (nil))
> 
> gets transformed by peephole2 to:
> (note 8303 8031 8556 4 NOTE_INSN_PROLOGUE_END)
> (insn 8556 8303 7887 4 (parallel [
> (set (mem/c:DI (plus:DI (reg:DI 7 x7)
> (const_int 8 [0x8])) [63 %sfp+-2912 S8 A64])
> (reg/f:DI 2 x2 [1833]))
> (set (mem/c:DI (plus:DI (reg:DI 7 x7)
> (const_int 16 [0x10])) [63 %sfp+-2904 S8 A64])
> (reg/f:DI 3 x3 [1834]))
> ]) "../include/list.h":29:13 -1
>  (nil))
> 
> I don't know what's the meaning of x7 register, but it's not set during main
> function execution.

Basically the backend can combine up to 4 loads or stores and insert an
addressing instruction so that all offsets are in range
(aarch64_gen_adjusted_ldpstp). It appears a later optimization removes the
initialization of x7 as dead and so the address is wrong.

The key question is how does one dump rtl with -flto? It doesn't work at all,
making debugging this difficult...

[Bug lto/91375] [8/9/10 Regression] ICE on valid code in subbinfo_with_vtable_at_offset at ipa-devirt.c:2760 since r256685

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||gcc-bugzilla at tobias dot 
goedder
   ||z.info

--- Comment #4 from Martin Liška  ---
*** Bug 91387 has been marked as a duplicate of this bug. ***

[Bug lto/91387] Segfault using -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

class A {
public:
  A();
};
#pragma GCC optimize("fp-contract=off")
class B : virtual A {};
void fn1() { throw B(); }

The suggested fix for the duplicate works.

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

[Bug lto/91387] Segfault using -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, I'm reducing that.

[Bug c++/91388] New: -Wreturn-type "no return statement" warning in function that is already ill-formed

[redi at gcc dot gnu.org]

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

Bug ID: 91388
   Summary: -Wreturn-type "no return statement" warning in
function that is already ill-formed
   Product: gcc
   Version: 9.1.1
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: ---

template struct copyable;

template
T func(const T& t)
{
  static_assert(copyable::value);
  return t;
}

struct NoCopy {
  NoCopy() { }
  NoCopy(const NoCopy&) = delete;
};

template<> struct copyable { static constexpr bool value = false; };

int main()
{
  NoCopy nc;
  func(nc);
}

This produces the following diagnostics:

nc.cc:20:10:   required from here
nc.cc:6:30: error: static assertion failed
6 |   static_assert(copyable::value);
  |  ^
nc.cc:7:10: error: use of deleted function 'NoCopy::NoCopy(const NoCopy&)'
7 |   return t;
  |  ^
nc.cc:12:3: note: declared here
   12 |   NoCopy(const NoCopy&) = delete;
  |   ^~

As the author of func I have already added a static assertion to check if
the return statement will be well-formed, so the second error is redundant (and
I'd prefer for my users to not see it, the static assertion is for their
benefit).

So I try writing the function like this instead:

template
T func(const T& t)
{
  static_assert(copyable::value);

  if constexpr (copyable::value)
return t;
}

Now the compiler says:

nc.cc: In instantiation of 'T func(const T&) [with T = NoCopy]':
nc.cc:22:10:   required from here
nc.cc:6:30: error: static assertion failed
6 |   static_assert(copyable::value);
  |  ^
nc.cc:10:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   10 | }
  | ^

To suppress the warning I need to do:

template
T func(const T& t)
{
  static_assert(copyable::value);

  if constexpr (copyable::value)
return t;
  __builtin_unreachable();
}

I don't think it should be necessary to mark it unreachable. The fact the
static assertion failed means it's already guaranteed to be unreachable,
because it's not even compilable!

Could the -Wreturn-type warning be suppressed when the function is already
ill-formed?

I note that clang's -Wreturn-type diagnostic is phrased "warning: control
reaches end of non-void function" and isn't given for ill-formed functions.
That makes sense because control cannot reach the end of a function that cannot
possibly execute.

[Bug libgcc/91379] internal compiler error __gcov_fork

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Note the GCC 4.9 is out of support, please use at least GCC 7.

[Bug c++/91387] New: Segfault using -flto

[gcc-bugzilla at tobias dot goedderz.info]

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

Bug ID: 91387
   Summary: Segfault using -flto
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at tobias dot goedderz.info
  Target Milestone: ---

Created attachment 46684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46684=edit
Preprocessed source code

Hi,

I'm experiencing g++ segfaults during compilation. This is a "minimal" example
in terms of command line parameters, using the preprocessed source (which is
not minimal):

> $ /usr/bin/g++-8 -std=c++14 -O2 -flto -fno-devirtualize -c 
> ShapeContainerTest.ii
> during IPA pass: cp
> /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp:
>  In function ‘arangodb::velocypack::Builder::openCompoundValue(unsigned char) 
> [clone .part.119]’:
> /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp:427:2:
>  internal compiler error: Segmentation fault
>  }}
>   ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

This is with g++ (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0.

I have two other files exhibiting a similar error, if it's of interest. The one
referenced above is attached.

Please tell me if and how I can be of further help.

Best regards,

Tobias

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

[matz at gcc dot gnu.org]

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

--- Comment #11 from Michael Matz  ---
(In reply to rguent...@suse.de from comment #10)
> >It's the only affine functions that don't progress with each iteration.
> > I
> >think, at least :)
> 
> Hm. At least we analyze wrapping ones, but I guess 0, 1, 0, 1 would be
> caught in another way..

Yes, we analyze them, but for nothing.  They aren't affine either, and hence
result in unknown dependences.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
And I can also verify that adding -fno-peephole -fno-peephole2 to CFLAGS helps
to resolve the issue.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
I'm attaching all tree and rtl dumps for the problematic LTRANS unit:
https://drive.google.com/file/d/1CW4cWvpm1VVXFIP80XCf1IzYXWwTsynZ/view?usp=sharing

I can confirm what Andreas sees:

(note 8303 8031 7890 4 NOTE_INSN_PROLOGUE_END)
(insn:TI 7890 8303 7889 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 704 [0x2c0])) [63 %sfp+-2912 S8 A64])
(reg/f:DI 2 x2 [1833])) "../include/list.h":29:13 47 {*movdi_aarch64}
 (nil))
(insn 7889 7890 7887 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 712 [0x2c8])) [63 %sfp+-2904 S8 A64])
(reg/f:DI 3 x3 [1834])) "../include/list.h":29:13 47 {*movdi_aarch64}
 (nil))

gets transformed by peephole2 to:
(note 8303 8031 8556 4 NOTE_INSN_PROLOGUE_END)
(insn 8556 8303 7887 4 (parallel [
(set (mem/c:DI (plus:DI (reg:DI 7 x7)
(const_int 8 [0x8])) [63 %sfp+-2912 S8 A64])
(reg/f:DI 2 x2 [1833]))
(set (mem/c:DI (plus:DI (reg:DI 7 x7)
(const_int 16 [0x10])) [63 %sfp+-2904 S8 A64])
(reg/f:DI 3 x3 [1834]))
]) "../include/list.h":29:13 -1
 (nil))

I don't know what's the meaning of x7 register, but it's not set during main
function execution.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #38 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #37)
> (In reply to Martin Liška from comment #36)
> > (In reply to Jakub Jelinek from comment #35)
> > > Yeah, plus removing " according to LANG_MASK" from
> > > get_options_from_collect_gcc_options function comment.  But Martin claims 
> > > it
> > > doesn't work.
> > 
> > Yes, I needed both CL_DRIVER | CL_LANG_ALL to have it working.
> 
> I can't reproduce that though, works just fine for me with just CL_DRIVER
> (richi's patch), verified it processes the -MF argument properly.
> ./xgcc -B ./ -c -flto pr91130.c
> ./xgcc -B ./ -o pr91130{,.o} -flto -MMD -MF deps
> that previously failed now works.

Ok, I'll give it one more try with Richi's patch.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #36)
> (In reply to Jakub Jelinek from comment #35)
> > Yeah, plus removing " according to LANG_MASK" from
> > get_options_from_collect_gcc_options function comment.  But Martin claims it
> > doesn't work.
> 
> Yes, I needed both CL_DRIVER | CL_LANG_ALL to have it working.

I can't reproduce that though, works just fine for me with just CL_DRIVER
(richi's patch), verified it processes the -MF argument properly.
./xgcc -B ./ -c -flto pr91130.c
./xgcc -B ./ -o pr91130{,.o} -flto -MMD -MF deps
that previously failed now works.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #36 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #35)
> Yeah, plus removing " according to LANG_MASK" from
> get_options_from_collect_gcc_options function comment.  But Martin claims it
> doesn't work.

Yes, I needed both CL_DRIVER | CL_LANG_ALL to have it working.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
Yeah, plus removing " according to LANG_MASK" from
get_options_from_collect_gcc_options function comment.  But Martin claims it
doesn't work.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
I ended up with 5 files that are needed for the issue and my backtrace is then:

│0xaaab3930subsp, sp, #0xbc0
│0xaaab3934  stpx29, x30, [sp]
│0xaaab3938  movx29, sp
│0xaaab393c stpx19, x20, [sp, #16]
│0xaaab3940 stpx23, x24, [sp, #48]
│0xaaab3944 subsp, sp, #0x260
│0xaaab3948 addx9, sp, #0x390
│0xaaab394c movw23, w0
│0xaaab3950 movw0, #0x
// #-1
│0xaaab3954 movx24, x1
│0xaaab3958 strxzr, [sp, #928]
│0xaaab395c stpwzr, w0, [x9, #-8]
│0xaaab3960 stpwzr, w0, [x9]
│0xaaab3964 strxzr, [sp, #936]
│0xaaab3968 bl 0xaaab2d20

│0xaaab396c strx0, [sp, #752]
│0xaaab3970 cbzx0, 0xaaab46f0

│0xaaab3974 strx21, [sp, #640]
│0xaaab3978 adrp   x1, 0xaaac4000
<__for_each_matched_rec+48>
│0xaaab397c strx22, [sp, #648]
│0xaaab3980 addx1, x1, #0x6c8
│0xaaab3984 strx25, [sp, #672]
│0xaaab3988 addx0, sp, #0x460
│0xaaab398c strx26, [sp, #680]
│0xaaab3990 addx8, sp, #0x3b8
│0xaaab3994strx27, [sp, #688]
│0xaaab3998addx3, sp, #0x3c8
>│0xaaab399cstrx28, [x7]

Segfault happens at the last instruction.

[Bug c++/91382] Missing pedwarn when using [[maybe_unused]] in C++14

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
True enough.  I noticed clang++ warns:
warning: use of the 'maybe_unused' attribute is a C++17 extension
[-Wc++17-extensions]
but this is a dup of Bug 86368 at best.  Closing.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #34 from Richard Biener  ---
So like the following then.

Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 274111)
+++ gcc/lto-wrapper.c   (working copy)
@@ -133,7 +133,6 @@ maybe_unlink (const char *file)
 static void
 get_options_from_collect_gcc_options (const char *collect_gcc,
  const char *collect_gcc_options,
- unsigned int lang_mask,
  struct cl_decoded_option
**decoded_options,
  unsigned int *decoded_options_count)
 {
@@ -176,8 +175,7 @@ get_options_from_collect_gcc_options (co
   argc = obstack_object_size (_obstack) / sizeof (void *) - 1;
   argv = XOBFINISH (_obstack, const char **);

-  decode_cmdline_options_to_array (argc, (const char **)argv,
-  lang_mask,
+  decode_cmdline_options_to_array (argc, (const char **)argv, CL_DRIVER,
   decoded_options, decoded_options_count);
   obstack_free (_obstack, NULL);
 }
@@ -1009,8 +1007,7 @@ find_and_merge_options (int fd, off_t fi
 {
   struct cl_decoded_option *f2decoded_options;
   unsigned int f2decoded_options_count;
-  get_options_from_collect_gcc_options (collect_gcc,
-   fopts, CL_LANG_ALL,
+  get_options_from_collect_gcc_options (collect_gcc, fopts,
_options,
_options_count);
   if (!fdecoded_options)
@@ -1283,7 +1280,6 @@ run_gcc (unsigned argc, char *argv[])
 fatal_error (input_location,
 "environment variable % must be set");
   get_options_from_collect_gcc_options (collect_gcc, collect_gcc_options,
-   CL_LANG_ALL,
_options,
_options_count);

[Bug debug/86675] C++ lambdas are not debugable with -std=c++17 (or above) and -Og

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
cat >86675.cc /dev/null | grep return



The first GDB session breaks at:

3   return 31415;

The second at:

2   return [] {

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
So if one can reproduce a way for a smaller testcase (likely only for trunk
then) is to -fdump-tree-optimized-gimple and make a GIMPLE FE testcase from
main()
(adding relevant typedefs from the preprocessed sources).  It may not
necessarily reproduce the issue of course...

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
I'm reducing the LTO files that are needed to expose the problem..

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So I can't reproduce with a cross easily (w/o a libc I can only
do a partial link).  Nevertheless I see some

  58:   910e63e6add x6, sp, #0x398
...
  90:   a90008c2stp x2, x2, [x6]

which is probably what was intended.

[Bug driver/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

  Component|target  |driver

--- Comment #33 from Richard Earnshaw  ---
This is a problem in lto-wrapper, so really a driver bug.

[Bug debug/86675] C++ lambdas are not debugable with -std=c++17 (or above) and -Og

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Confirmed. With -std=gnu++17 the breakpoint on line 3 (the return statement
inside the lambda expression) actually breaks on line 2:

Breakpoint 1, main () at 86675.cc:2
2   return [] {

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to Richard Earnshaw from comment #4)
> R8 is the register used for the address of the return value location when
> the result cannot be stored in registers.  Are you sure that this isn't a
> problem in the caller?

Scratch that, can't be the case in main.

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
R8 is the register used for the address of the return value location when the
result cannot be stored in registers.  Are you sure that this isn't a problem
in the caller?

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

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

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

--- Comment #3 from Andreas Schwab  ---
Created attachment 46683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46683=edit
Preprocessed sources with Makefile, part 3

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

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

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

--- Comment #2 from Andreas Schwab  ---
Created attachment 46682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46682=edit
Preprocessed sources with Makefile, part 2

[Bug target/91386] open-iscsi iscsiadm miscompiled by LTO on aarch64

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

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

--- Comment #1 from Andreas Schwab  ---
Created attachment 46681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46681=edit
Preprocessed sources with Makefile, part 1

[Bug target/91386] New: open-iscsi iscsiadm miscompiled by LTO on aarch64

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

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

Bug ID: 91386
   Summary: open-iscsi iscsiadm miscompiled by LTO on aarch64
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

This is the start of main from iscsiadm:

8fe0:   d13003ffsub sp, sp, #0xc00
8fe4:   a9007bfdstp x29, x30, [sp]
8fe8:   910003fdmov x29, sp
8fec:   a9025bf5stp x21, x22, [sp, #32]
8ff0:   2a0003f6mov w22, w0
8ff4:   f420adrpx0, 8f000

8ff8:   a90153f3stp x19, x20, [sp, #16]
8ffc:   f9479800ldr x0, [x0, #3888]
9000:   a90363f7stp x23, x24, [sp, #48]
9004:   d10983ffsub sp, sp, #0x260
9008:   aa0103f7mov x23, x1
900c:   f941ldr x1, [x0]
9010:   f9072fe1str x1, [sp, #3672]
9014:   d281mov x1, #0x0// #0
9018:   b90397ffstr wzr, [sp, #916]
901c:   b9039bffstr wzr, [sp, #920]
9020:   f901d7ffstr xzr, [sp, #936]
9024:   f901dbffstr xzr, [sp, #944]
9028:   97fffd12bl  8470 
902c:   f9017fe0str x0, [sp, #760]
9030:   b4007540cbz x0, 9ed8 
9034:   f90153f9str x25, [sp, #672]
9038:   b021adrpx1, e000 
903c:   f90157fastr x26, [sp, #680]
9040:   910d0021add x1, x1, #0x340
9044:   f9015bfbstr x27, [sp, #688]
9048:   911263e0add x0, sp, #0x498
904c:   f900011cstr x28, [x8]

The last insn is part of the prologue to save register x28, but x8 is never
set.

This breaks during peephole2:

(insn/f:TI 7430 7429 7271 4 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [69  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [69  S8 A8])
(reg:DI 28 x28))
(nil

is transformed into:

(insn/f:TI 7430 7429 7842 4 (set (mem/c:DI (reg:DI 8 x8) [69  S8 A8])
(reg:DI 28 x28)) 47 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 28 x28)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 696 [0x2b8])) [69  S8 A8])
(reg:DI 28 x28))
(nil

[Bug target/91385] Zero-extended negation (*negsi2_1_zext) is not generated

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86_64
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-07
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Mine. I have a patch.