[Bug target/80190] darwin: untranslateable placeholder "non-ASCII character"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Should be fixed for GCC 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 80190, which changed state.

Bug 80190 Summary: darwin: untranslateable placeholder "non-ASCII character"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80190

   What|Removed |Added

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

[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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[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 #33 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 07:45:23 2019
New Revision: 269483

URL: https://gcc.gnu.org/viewcvs?rev=269483&root=gcc&view=rev
Log:
PR c++/89585
* parser.c (cp_parser_asm_definition): Just warn instead of error
on volatile qualifier outside of function body.

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

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

[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 #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 07:43:58 2019
New Revision: 269482

URL: https://gcc.gnu.org/viewcvs?rev=269482&root=gcc&view=rev
Log:
PR c++/89599
* constexpr.c (potential_constant_expression_1): Reject
REINTERPRET_CAST_P NOP_EXPRs.

* g++.dg/ubsan/vptr-4.C: Adjust expected diagnostics.
* g++.dg/parse/array-size2.C: Likewise.
* g++.dg/cpp0x/constexpr-89599.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-89599.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/array-size2.C
trunk/gcc/testsuite/g++.dg/ubsan/vptr-4.C

[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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 07:42:51 2019
New Revision: 269481

URL: https://gcc.gnu.org/viewcvs?rev=269481&root=gcc&view=rev
Log:
PR c++/89622
* call.c (joust): Call print_z_candidate only if pedwarn returned
true.

* g++.dg/warn/pr89622.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr89622.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80190] darwin: untranslateable placeholder "non-ASCII character"

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 07:39:31 2019
New Revision: 269480

URL: https://gcc.gnu.org/viewcvs?rev=269480&root=gcc&view=rev
Log:
PR target/80190
* config/darwin.c: Include intl.h.
(darwin_build_constant_cfstring): Improve i18n of diagnostics by not
composing the message out of two separate parts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.c

[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[fdumont at gcc dot gnu.org]

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

--- Comment #6 from François Dumont  ---
Author: fdumont
Date: Fri Mar  8 05:53:09 2019
New Revision: 269479

URL: https://gcc.gnu.org/viewcvs?rev=269479&root=gcc&view=rev
Log:
2019-03-08  François Dumont  

PR libstdc++/89477
* include/debug/map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
* include/debug/multimap.h (multimap): Likewise.
* include/debug/set.h (multimap): Likewise.
* include/debug/multiset.h (multimap): Likewise.
* include/debug/unordered_map (unordered_map): Likewise.
(unordered_multimap): Likewise.
* include/debug/unordered_set (unordered_set): Likewise.
(unordered_multiset): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/map.h
trunk/libstdc++-v3/include/debug/multimap.h
trunk/libstdc++-v3/include/debug/multiset.h
trunk/libstdc++-v3/include/debug/set.h
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/include/debug/unordered_set

[Bug libstdc++/89608] Undetected iterator invalidations on unordered containers in debug mode

[fdumont at gcc dot gnu.org]

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

--- Comment #2 from François Dumont  ---
Author: fdumont
Date: Fri Mar  8 05:37:50 2019
New Revision: 269478

URL: https://gcc.gnu.org/viewcvs?rev=269478&root=gcc&view=rev
Log:
2019-03-08  François Dumont  

PR libstdc++/89608
* include/debug/unordered_map (unordered_map<>::_M_check_rehashed):
Invalidate all iterators in case of rehash.
(unordered_multimap<>::_M_check_rehashed): Likewise.
* include/debug/unordered_set
(unordered_set<>::_M_check_rehashed): Likewise.
(unordered_multiset<>::_M_check_rehashed): Likewise.
* testsuite/23_containers/unordered_set/debug/89608_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/debug/89608_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/include/debug/unordered_set

[Bug driver/83243] -fuse-ld=lld

[Arfrever.FTA at GMail dot Com]

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

Arfrever Frehtes Taifersar Arahesis  changed:

   What|Removed |Added

 CC||Arfrever.FTA at GMail dot Com

--- Comment #7 from Arfrever Frehtes Taifersar Arahesis  ---
(In reply to H.J. Lu from comment #5)

> commit 4eea76dbfc871614e116961b048d9aa38eee66ea
> Author: law 
> Date:   Thu Nov 8 22:05:27 2018 +
> 
> * collect2.c (linker_select):  Add USE_LLD_LD.
> (ld_suffixes): Add ld.lld.
> (main): Handle -fuse-ld=lld.
> * common.opt (-fuse-ld=lld): New option.
> * doc/invoke.texi (-fuse-ld=lld): Document.
> * opts.c (common_handle_option): Handle OPT_fuse_ld_lld.
> 

gcc/common.opt uses phrase "the lld LLVM linker", while gcc/doc/invoke.texi
uses phrase "the LLVM lld linker".
For consistency, I suggest to change gcc/common.opt to use phrase "the LLVM lld
linker" which looks better ("LLVM", as name of parent project, should come at
the beginning of full name).

[Bug target/89411] RISC-V backend will generate wrong instruction for longlong type like lw a3,-2048(a5)

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
Created attachment 45925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45925&action=edit
work in progress patches for a fix

This implements two ways to fix it, a simple way that just fails for BLKmode,
and a more complex way that passes in a SYMBOL_REF and tries to extract decl
size and alignment from it.  There are ifdefs so you can choose which one gets
used.  I'd like to do a lot more testing to see what the optimization effect is
from the two patches, and to see how often they trigger, and to make sure they
won't generate a compiler error on anything important (like gcc, glibc, newlib,
linux kernel).

[Bug target/89627] Miscompiled constructor call

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #1 from Jim Wilson  ---
This is the same problem that Andrew Burgess just reported.  He found it while
looking at gdb testsuite failures.  He reported it against the psABI
https://github.com/riscv/riscv-elf-psabi-doc/issues/88
This has a link to a patch, but the patch is trying to fix the ABI which is
wrong.  We only need the last two hunks of the patch which fix a bug in
riscv_pass_fpr_single.

https://github.com/T-J-Teru/gcc/commit/ae183138a618a01acf2cf009544d4ce0dda61ab9

I'm waiting for Andrew to submit the patch so I can approve it.

[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

[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++/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 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 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 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 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 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 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/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 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/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 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 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 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 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 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 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

--- 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 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 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/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/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

--- 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/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 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

[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 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

[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/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/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 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 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 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 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 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 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 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

[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] 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 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 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 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 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 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 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 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 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 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++/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 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++/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/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 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 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 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 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 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 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 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 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 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 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 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 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++/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 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 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 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 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 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 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 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 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/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 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++/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 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 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 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 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++/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 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++/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.