[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Oh sure, if all you want to do is extend the prepare_shrinkwrap function,
that just works there and it doesn't need to do a lot of profitability
trade-offs.  However it isn't very effective there.  It's better to do it
just before register allocation.  IRA tries to do a little, too, also not
very effective :-(

If you want to just extend prepare_shrinkwrap, so that it handles more than
just the first BB, what order should it try?  Should it be just greedy, or
should it look how it can get best gain?

Shrink-wrapping could wrap about 3x as many BBs as it does currently, but
just extending prepare_shrinkwrap doesn't get very far.  Which is not an
argument to not do a better job there, of course ;-)

[Bug c/85562] -Wsuggest-attribute=malloc misleads about "returning normally"

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to prathamesh3492 from comment #3)
> Fix for PR85734 also fixes this bug.

That one is fixed on trunk, apparently. So, same for this one?

[Bug tree-optimization/84648] Missed optimization : loop not removed.

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
Author: amker
Date: Thu Nov 15 03:44:49 2018
New Revision: 266171

URL: https://gcc.gnu.org/viewcvs?rev=266171=gcc=rev
Log:

PR tree-optimization/84648
* tree-ssa-loop-niter.c (adjust_cond_for_loop_until_wrap): New.
(number_of_iterations_cond): Adjust exit cond for loop-until-wrap case
by calling adjust_cond_for_loop_until_wrap.

gcc/testsuite
* gcc.dg/tree-ssa/pr84648.c: New test.
* gcc.dg/pr68317.c: Add warning check on overflow.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84648.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr68317.c
trunk/gcc/tree-ssa-loop-niter.c

[Bug other/56334] __attribute__((aligned)) documentation is misleading

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from sandra at gcc dot gnu.org ---
Fixed per the recommendations in Comment 1.

[Bug other/56334] __attribute__((aligned)) documentation is misleading

[sandra at gcc dot gnu.org]

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov 15 02:55:26 2018
New Revision: 266170

URL: https://gcc.gnu.org/viewcvs?rev=266170=gcc=rev
Log:
2018-11-15  Sandra Loosemore  

PR other/56334

gcc/
* doc/extend.texi (Common Function Attributes): Clarify linker
restrictions on "aligned" attribute.
(Common Variable Attributes): Likewise.  Mention that linker
restrictions don't apply to stack-allocated variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug tree-optimization/88029] New: [9 Regression] ICE in execute_todo, at passes.c:1974

[asolokha at gmx dot com]

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

Bug ID: 88029
   Summary: [9 Regression] ICE in execute_todo, at passes.c:1974
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha2018 snapshot (r266019) ICEs when compiling
gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-13.c at any -O level except 0 and w/
-frounding-math -fno-tree-ccp:

% gcc-9.0.0-alpha2018 -O1 -frounding-math -fno-tree-ccp -w -c
gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-13.c
during GIMPLE pass: fre
gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-13.c: In function 'f':
gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-13.c:23:1: internal compiler error: in
execute_todo, at passes.c:1974
   23 | }
  | ^
0x653955 execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/passes.c:1974

[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
We give an error since g++ 4.8 and the Comment 4 testcase is also rejected by
clang.  Thus closing.

[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> AFAICT the patch in comment 5 fixes the tests in comments 1 and 5, but not
> the test in comment 0.

% cat a.f90
program p
   real :: a, b
   data b /a%kind/
   print *, b
end

% gfcx -o z a.f90 && ./z
   4.

[Bug middle-end/31377] wrap_help error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
svn blame says nickc wrote this code in r121849; cc-ing him

[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
I've checked in a patch on trunk to replace the bad example with the
explanation in Comment 1, suitably translated into user-speak.  However, in
subsequent comments this issue wandered off into discussion of enabling IPA
automatically with -flto and other related code changes.  Is the issue
adequately resolved just by the documentation change, or do we want to keep it
open to track the requested code changes?

[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs

[sandra at gcc dot gnu.org]

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov 15 00:41:10 2018
New Revision: 266168

URL: https://gcc.gnu.org/viewcvs?rev=266168=gcc=rev
Log:
2018-11-14  Sandra Loosemore  

PR lto/55102
PR lto/56700

gcc/
* doc/invoke.texi (Optimize Options): Remove bad example about
interaction between -flto and -O.  Replace it with a note that
you need to compile with -O and not just link.  Copy-edit -flto
discussion to reduce verbiage and improve flow.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug lto/56700] Optimizing at compile and link result in different binary size than only optimizing at link time

[sandra at gcc dot gnu.org]

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Thu Nov 15 00:41:10 2018
New Revision: 266168

URL: https://gcc.gnu.org/viewcvs?rev=266168=gcc=rev
Log:
2018-11-14  Sandra Loosemore  

PR lto/55102
PR lto/56700

gcc/
* doc/invoke.texi (Optimize Options): Remove bad example about
interaction between -flto and -O.  Replace it with a note that
you need to compile with -O and not just link.  Copy-edit -flto
discussion to reduce verbiage and improve flow.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
AFAICT the patch in comment 5 fixes the tests in comments 1 and 5, but not the
test in comment 0.

[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||foreese at gcc dot gnu.org
  Known to work||5.5.0
   Target Milestone|--- |7.4
  Known to fail||6.5.0, 7.3.0, 8.2.0, 9.0

--- Comment #2 from Dominique d'Humieres  ---
> The 2 of the 3 asserts aren't needed.  The third is silly.

The code has been introduced by Fritz Reese at revision r239489.

[Bug c++/88026] Explicit deduction guide fails for move-only type

[toe-ger at web dot de]

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

--- Comment #2 from toe-ger at web dot de ---
Workaround that seems to generally work:
Change deduction guide to

template 
S(T&&)->S>;

[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
Better patch.  Permits %re and %im in data statement.
program p
   complex, parameter :: a = (42.5,23)
   real :: b
   data b /a%re/
   print *, b
end

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 266155)
+++ gcc/fortran/decl.c  (working copy)
@@ -388,6 +388,14 @@ match_data_constant (gfc_expr **result)
 }
   else if (m == MATCH_YES)
 {
+  /* If a parameter inquiry ends up here, symtree is NULL but **result
+contains the right constant expression.  Check here.  */
+  if ((*result)->symtree == NULL
+ && (*result)->expr_type == EXPR_CONSTANT
+ && ((*result)->ts.type == BT_INTEGER 
+ || (*result)->ts.type == BT_REAL))
+   return m;
+
   /* F2018:R845 data-stmt-constant is initial-data-target.
 A data-stmt-constant shall be ... initial-data-target if and
 only if the corresponding data-stmt-object has the POINTER

[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #4 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 266155)
+++ gcc/fortran/decl.c  (working copy)
@@ -388,6 +388,13 @@ match_data_constant (gfc_expr **result)
 }
   else if (m == MATCH_YES)
 {
+  /* If a parameter inquiry ends up here, symtree is NULL but **result
+contains the right constant expression.  Check here.  */
+  if ((*result)->symtree == NULL
+ && (*result)->expr_type == EXPR_CONSTANT
+ && (*result)->ts.type == BT_INTEGER)
+   return m;
+
   /* F2018:R845 data-stmt-constant is initial-data-target.
 A data-stmt-constant shall be ... initial-data-target if and
 only if the corresponding data-stmt-object has the POINTER

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[boger at gcc dot gnu.org]

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

--- Comment #4 from boger at gcc dot gnu.org ---
Created attachment 45005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45005=edit
Hack workaround to show bad loop

Through my debugging I found that if I add the print statement as shown in this
patch in math/big/int.go function lehmerGCD then the bugs in the tests for the
math/big and crypto packages go away. I realize this is not a valid workaround
but should show what loop contains the bad code.

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
This appears to have to do with alignment. In this test case,
expand_block_clear() sees alignment of only 8 bits for the pointer p. If you
declare a local struct st and pass that to __builtin_memset, it sees alignment
of 128 bits and generates 4 stxv or stvx.

There is a bug here though:

  for (offset = 0; bytes > 0; offset += clear_bytes, bytes -= clear_bytes)
{
  machine_mode mode = BLKmode;
  rtx dest;

  if (TARGET_ALTIVEC
  && ((bytes >= 16 && align >= 128)
  || (bytes >= 32 && TARGET_EFFICIENT_UNALIGNED_VSX)))

The intention here was to only do unaligned VSX if there were at least 32 bytes
to clear. However because bytes is decremented, what this actually does is to
always do the last 16 bytes using std if it is unaligned. This doesn't make a
lot of sense and would be an easy fix.

[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
  In general moving from propagation of hard regs is good thing for RA. 
Although there are exception as this PR.

  The problem starts with IRA.  It decides that r91 should be a general regs
based  on cost calculation.  The cost calculation code in IRA is very
sensitive.  A change there usually results in new PRs with unexpected code
generation.

  I'll investigate more the PR and how to fix the PR with minimal effect to
other targets and tests.  But right now I can guess that the cost of move of
greg with sse-regs and move of sse-regs is the same for intel but if we choose
sse-regs they are coalesced and the move is removed.

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #2 from acsawdey at gcc dot gnu.org ---
What can I say? expand_block_clear() steps through the block to be cleared,
using smaller writes at the end if necessary. The rtx is generated for the
write by:

  dest = adjust_address (orig_dest, mode, offset);

  emit_move_insn (dest, CONST0_RTX (mode));

My guess is scheduling moved the gpr stores up.

[Bug c++/88028] internal compiler error: in reshape_init_r, at cp/decl.c:6159

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
ICE started with r240802.  Before that:

88028.C: In instantiation of ‘constexpr const auto R::h’:
88028.C:16:34:   required from ‘struct R’
88028.C:23:24:   required from here
88028.C:16:34: error: invalid use of template type parameter ‘A’
 struct R { static constexpr auto h = A{S{}}; };
  ^

[Bug c++/87893] [9 Regression] ICE in gimplify_expr, at gimplify.c:12557 on arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
When trying to cp_fold pair::pair() ctor call, guess related to arm ABI
feature of returning pointer to the object from the ctor,
2542if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
2543&& !flag_no_inline)
2544  r = maybe_constant_value (x);
returns for some reason a VOID_CST and then
2549if (DECL_CONSTRUCTOR_P (callee))
2550  {
2551loc = EXPR_LOCATION (x);
2552tree s = build_fold_indirect_ref_loc (loc,
2553  CALL_EXPR_ARG (x,
0));
2554r = build2_loc (loc, INIT_EXPR, TREE_TYPE (s), s, r);
2555  }
tries to initialize the class with that.  VOID_CST is a result of the ctor call
constexpr evaluation doing:
  if (DECL_CONSTRUCTOR_P (fun))
/* This can be null for a subobject constructor call, in
   which case what we care about is the initialization
   side-effects rather than the value.  We could get at the
   value by evaluating *this, but we don't bother; there's
   no need to put such a call in the hash table.  */
result = lval ? ctx->object : ctx->ctor;
where for some reason both ctx->object and ctx->ctor are NULL and then
  else if (!result)
result = void_node;
both in cxx_eval_call_expression.  No idea why that happens though and why
pair::pair() call isn't being folded at all on the same testcase on
x86_64-linux.

[Bug c++/88028] internal compiler error: in reshape_init_r, at cp/decl.c:6159

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Marek Polacek  ---
Not a regression, g++ 6 rejects it.

[Bug c++/88028] New: internal compiler error: in reshape_init_r, at cp/decl.c:6159

[mpolacek at gcc dot gnu.org]

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

Bug ID: 88028
   Summary: internal compiler error: in reshape_init_r, at
cp/decl.c:6159
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

template 
using b = T;

template 
struct g { typedef T d[N]; };

template 
struct A { typename g::d e; };

template 
A(T)->A, 1>;

struct S {};

template 
struct R { static constexpr auto h = A{S{}}; };

using U = R;

void
fn ()
{
  const A foo = U::h;
}


$ ./cc1plus -quiet x.C -std=c++17
x.C: In instantiation of ‘constexpr const A R::h’:
x.C:23:26:   required from here
x.C:16:34: internal compiler error: in reshape_init_r, at cp/decl.c:6159
   16 | struct R { static constexpr auto h = A{S{}}; };
  |  ^
0x90b2d0 reshape_init_r
/home/mpolacek/src/gcc/gcc/cp/decl.c:6159
0x90a65b reshape_init_class
/home/mpolacek/src/gcc/gcc/cp/decl.c:5941
0x90b37d reshape_init_r
/home/mpolacek/src/gcc/gcc/cp/decl.c:6172
0x90b608 reshape_init(tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl.c:6232
0xb009fa finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:2821
0xab071a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:19190
0xaa9689 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:17739
0xac3b9b regenerate_decl_from_template
/home/mpolacek/src/gcc/gcc/cp/pt.c:23870
0xac6759 instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:24364
0x950343 maybe_instantiate_decl
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5247
0x950f9b mark_used(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5398
0x95198b mark_used(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5514
0xb04e21 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:3716
0x9f8c57 cp_parser_primary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:5698
0x9fc1c1 cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7102
0x9ff6f9 cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8382
0xa00801 cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9150
0xa008f4 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9252
0xa016ff cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9548
0xa01efd cp_parser_constant_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9830
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/88027] PowerPC generates slightly weird code for memset

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 45004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45004=edit
File that shows the problem

I changed the test not to return 0 between showing the test and the code
generated.  This attachment does not return anything which matches the code
generated.

[Bug target/88027] PowerPC generates slightly weird code for memset

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
 CC||acsawdey at linux dot 
vnet.ibm.com
   ||, dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
  Build||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
   Severity|normal  |enhancement

[Bug c++/80864] [7/8/9/ Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Known to work||4.9.4
   Target Milestone|--- |7.4
Summary|Brace-initialization of a   |[7/8/9/ Regression]
   |constexpr variable of an|Brace-initialization of a
   |array in a POD triggers ICE |constexpr variable of an
   |from templates  |array in a POD triggers ICE
   ||from templates

--- Comment #3 from Marek Polacek  ---
It's a regression: GCC 4.9.4 compiled it.

[Bug c/61727] #pragma simd is undocumented

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I'm confused by this issue.  Is there really a "#pragma simd" separate from
"#pragma omp simd"?  Digging around in the code, I've only found stuff related
to the latter.  I might be able to make more progress on writing documentation
if I knew exactly what code needed documenting.  :-P

[Bug target/88027] New: PowerPC generates slightly weird code for memset

[meissner at gcc dot gnu.org]

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

Bug ID: 88027
   Summary: PowerPC generates slightly weird code for memset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If the PowerPC GCC compiler is doing a memset operation to clear some aligned
memory, it will do most of the stores using vector stores, but the last quad
word will be done using GPR stores:

Consider the following code:

struct st {
  vector double a[4];
};

long
bar (struct st *p)
{
  __builtin_memset ((void *) p, '\0', sizeof (struct st));
  return 0;
}

GCC -O3 -mcpu=power9 generates:

bar:
xxspltib 0,0; 0 in fpr0 (aka vsr0)
li 9,0  ; 0 in gpr9
std 9,48(3) ; store the last 2 double words as GPRs
std 9,56(3)
stxv 0,0(3) ; store the first 3 quad words as vectors
stxv 0,16(3)
stxv 0,32(3)
blr

GCC -O3 -mcpu=power8 generates:

bar:
vspltisw 0,0; 0 in v0 (aka vsr32) 
li 9,0  ; 0 in gpr9
li 8,16 ; index for 2nd quad word
li 10,32; index for 3rd quad word
xxpermdi 12,32,32,2 ; word swap (should be optimized out)
std 9,48(3) ; store last doubleword -1 as GPR
stxvd2x 12,0,3  ; store first quad word as vector
stxvd2x 12,3,8  ; store second quad word as vector
std 9,56(3) ; store last double word as GPR
stxvd2x 12,3,10 ; store third quad word as vector
blr

In addition to switching between storing as GPRs and as vectors, some machines
prefer the stores to be in ascending order for better optimization.

[Bug c++/88026] Explicit deduction guide fails for move-only type

[toe-ger at web dot de]

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

--- Comment #1 from toe-ger at web dot de ---
Godbolt decided to swap the output from gcc and msvc again. Sorry for that.

[Bug c++/64035] [C++11] ICE in reshape_init_r when using initializer list aggregate initialization for default function parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Now fixed:

commit a6cdf4f3c0b36d3fa8ccd8acf238433a501c5ab8
Author: jason 
Date:   Wed Mar 14 01:03:13 2018 +

PR c++/82336 - link error with list-init default argument.

* decl.c (check_default_argument): Unshare an initializer list.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258512
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug debug/82738] [meta-bug] issues with the -Og optimization level

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
 Depends on||88024

--- Comment #2 from sandra at gcc dot gnu.org ---
Adding PR 88024 to the list.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88024
[Bug 88024] At -O0 and -Og, GCC should warn if you explicitly try to enable an
option that is ignored

[Bug debug/82738] [meta-bug] issues with the -Og optimization level

[sandra at gcc dot gnu.org]

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

Bug 59658 Summary: Document -f* flags enabled by -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59658

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/59658] Document -f* flags enabled by -Og

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from sandra at gcc dot gnu.org ---
Patch committed to trunk.

If somebody cares to address 88024 we can further improve the documentation for
both -O0 and -Og to list options that are always disabled at those levels.

[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Marek Polacek  ---
The original testcase got fixed by:

commit 8da6002afc1d531ed086dd29ebf303d4235cfdfa
Author: jakub 
Date:   Fri Mar 16 08:05:06 2018 +

PR c++/84874
* decl.c (reshape_init_class): Don't assert d->cur->index == field
if d->cur->index is a FIELD_DECL, instead set field to
d->cur->index.

* g++.dg/cpp2a/desig7.C: New test.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258585
138bc75d-0d04-0410-961f-82ee72b054a4

Comment 14 also compiles now.

[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
It might be related to Bug 86246 then.

[Bug middle-end/59658] Document -f* flags enabled by -Og

[sandra at gcc dot gnu.org]

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Nov 14 20:05:13 2018
New Revision: 266162

URL: https://gcc.gnu.org/viewcvs?rev=266162=gcc=rev
Log:
2018-11-14  Sandra Loosemore  

PR middle-end/59658

gcc/
* doc/invoke.texi (Optimize Options): Clarify that -O0 and -Og
also suppress many optimizations.  Alphabetize option lists for
-O1, -O2, and -Os.  Add list of options disabled with -Og, and
correct documentation for those options to say that.
* opts.c (default_options_table): Sort table by level and option
name, to make it easier to correlate to the manual.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/opts.c

[Bug c++/80864] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r216750.

[Bug c++/80864] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||janniksilvanus at gmail dot com

--- Comment #1 from Marek Polacek  ---
*** Bug 86931 has been marked as a duplicate of this bug. ***

[Bug c++/86931] constexpr variable initialization: internal compiler error: in reshape_init_r, at cp/decl.c:6042

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Actually looks like a dup.

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

[Bug fortran/88025] [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
The 2 of the 3 asserts aren't needed.  The third is silly.

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 266155)
+++ gcc/fortran/expr.c  (working copy)
@@ -4461,12 +4461,10 @@ gfc_apply_init (gfc_typespec *ts, symbol_attribute *at
 {
   if (ts->type == BT_CHARACTER && !attr->pointer && init
   && ts->u.cl
-  && ts->u.cl->length && ts->u.cl->length->expr_type == EXPR_CONSTANT)
+  && ts->u.cl->length
+  && ts->u.cl->length->expr_type == EXPR_CONSTANT
+  && ts->u.cl->length->ts.type == BT_INTEGER)
 {
-  gcc_assert (ts->u.cl && ts->u.cl->length);
-  gcc_assert (ts->u.cl->length->expr_type == EXPR_CONSTANT);
-  gcc_assert (ts->u.cl->length->ts.type == BT_INTEGER);
-
   HOST_WIDE_INT len = gfc_mpz_get_hwi (ts->u.cl->length->value.integer);

   if (init->expr_type == EXPR_CONSTANT)

[Bug tree-optimization/87896] [9 Regression] ICE in verify_flow_info failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"

[jakub at gcc dot gnu.org]

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

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

[Bug tree-optimization/87898] [8 Regression] ICE in separate_decls_in_region_debug, at tree-parloops.c:961

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |separate_decls_in_region_de |separate_decls_in_region_de
   |bug, at tree-parloops.c:961 |bug, at tree-parloops.c:961

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

[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This used to call X::operator float() const until r255605 when it started to
ICE.
The ICE got fixed with r256986, but starting with that revision it already
calls X::operator float() const.

[Bug debug/88006] -fdebug-types-section gives undefined reference

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r87462

[Bug debug/87462] [7/8/9 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov 14 19:30:47 2018
New Revision: 266158

URL: https://gcc.gnu.org/viewcvs?rev=266158=gcc=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/88006] -fdebug-types-section gives undefined reference

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov 14 19:30:47 2018
New Revision: 266158

URL: https://gcc.gnu.org/viewcvs?rev=266158=gcc=rev
Log:
[debug/88006] -fdebug-types-section gives undefined ref

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01280.html
PR debug/88006
PR debug/87462
* dwarf2out.c (dwarf2out_finish): Apply resolve_addr to comdat
type list.

* g++.dg/debug/dwarf2/pr87462.C: New.
* g++.dg/debug/dwarf2/pr88006.C: New.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr87462.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr88006.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/87462] [7/8/9 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nathan at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Nathan Sidwell  ---
Fixed r266158

[Bug tree-optimization/87977] [9 Regression] ICE: verify_ssa failed (error: definition in block 4 follows the use)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/88026] New: Explicit deduction guide fails for move-only type

[toe-ger at web dot de]

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

Bug ID: 88026
   Summary: Explicit deduction guide fails for move-only type
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toe-ger at web dot de
  Target Milestone: ---

*Example code*:
struct move_only {
move_only() = default;
move_only(const move_only &) = delete;
};

template 
struct S {
S(T &){}
};

template 
S(T)->S;

int main() {
move_only m;
S s = m;
(void)s;
}

*Expected output*:
*Actual output*:
: In function 'int main()':
:16:11: error: class template argument deduction failed:
 S s = m;
   ^
:16:11: error: use of deleted function 'move_only::move_only(const
move_only&)'
:3:5: note: declared here
 move_only(const move_only &) = delete;
 ^
:12:1: note:   initializing argument 1 of 'S(T)-> S [with T =
move_only]'
 S(T)->S;
 ^

*Reproduction*:
https://godbolt.org/z/G0_8dw

[Bug libgomp/87995] [9 regression] libgomp.c/../libgomp.c-c++-common/cancel-taskgroup-3.c fails consistently after r265930

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce on x86_64-linux, tried 2048 invocations of the testcase in a
row, times various OMP_NUM_THREADS settings (32, 64, 1, 2, 4, 8).  All on
16c32t machine.  So, can you build it with additional -g and see where it
aborts or how else it fails?  What OMP_NUM_THREADS do you use?  If it is an
abort, can you replace it with printing the corresponding value and see what
value isn't correctly reduced and what value do you get?

[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up testcase:

int a;
int bar (void);
void baz (void);

void
foo (void)
{
  for (int c = 1; c <= 3;)
{
  int d = bar () && !0;
  switch (c)
case 1:
if (d)
case 2:
case 3:
  baz ();
  if (a)
c++;
}
}

The problem is that EDGE_IGNORE is not being cleared when it should anymore.
It is set during vr_values::simplify_switch_using_ranges, then checked in
inside of thread_outgoing_edges, but later on thread_through_all_blocks
eventually calls create_block_for_threading -> duplicate_block and that creates
new edges using the flags of the old succs edges.  While the original edges
that had EDGE_IGNORE set are in to_remove_edges vector and thus don't leak into
the IL afterwards, the copies of them created by duplicate_block are not and
leak into the IL, violating
/* An edge we should ignore.  It should be entirely local to
   passes.  ie, it is never set on any edge upon the completion
   of any pass.  */
DEF_EDGE_FLAG(IGNORE, 17)
requirement.  So, either we need some vr-values.c method that will clear
EDGE_IGNORE flags on to_remove_edge edges and call it before we start
duplicating any blocks, or something else went wrong (maybe we shouldn't
duplicate_blocks that have such edges?).

[Bug middle-end/59658] Document -f* flags enabled by -Og

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I've been poking at this issue.  I note that we don't document exactly which
optimization flags are completely ignored at -O0 due to the abbreviated pass
list, either, just:

  Most optimizations are only enabled if an ‘-O’ level is set on the command
  line.  Otherwise they are disabled, even if individual optimization flags 
  are specified.

I filed PR 88024 to suggest a warning for such ignored options and some code
changes that would make it easier to document which ones they are.  Meanwhile I
will document the -O1 options that are specifically disabled at -Og and add
wording about the skipped passes for -Og similar to that for -O.

[Bug c++/55227] designated initializer for char array by string constant

[jr at heisey dot org]

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

J.R. Heisey  changed:

   What|Removed |Added

 CC||jr at heisey dot org

--- Comment #3 from J.R. Heisey  ---
struct S s1 = { { a : "" } };
struct S s2 = { { .a = ""} };

This compiles with 6.2.1 for ARM by Linaro.
You need separate braces around the array initializer to distinguish it from
the struct initializer.

[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug target/87285] [9 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3235) with -O2 -std=gnu++11

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/88023] [9 Regression] ICE: verify_ssa failed (error: definition in block 39 does not dominate use in block 34)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed on trunk in r266070.

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[boger at gcc dot gnu.org]

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

--- Comment #3 from boger at gcc dot gnu.org ---
Created attachment 45003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45003=edit
Reproducer testcase for gccgo testresults failures in GCD

You should be able to build this using gccgo:
gccgo -o gcdbug gcdbug.go

Here is the link to the Go documentation for GCD:
https://golang.org/pkg/math/big/#Int.GCD

So far it looks like many of the testcase failures call GCD at some point.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to David Malcolm from comment #2)
> Actually, I'm still not able to reproduce this, but the fix seems obvious;
> am working on it.

I see it on multiple examples:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/bprob/g++-bprob-1.C -O3
-floop-parallelize-all -fno-tree-loop-im

or

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/gomp/pr25990.c
-floop-nest-optimize -O3

or

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/vect/vect-8.f90
-floop-nest-optimize -Ofast -fno-tree-vrp

I can test patch candidate for you if you want?

[Bug fortran/88025] New: [7/8/9 Regression] ICE in gfc_apply_init, at fortran/expr.c:4468

[gs...@t-online.de]

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

Bug ID: 88025
   Summary: [7/8/9 Regression] ICE in gfc_apply_init, at
fortran/expr.c:4468
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This invalid code affects versions down to gfortran-5 :


$ cat z1.f90
program p
   type t
  character(('')) :: c = 'c'
   end type
end


$ gfortran-5 -c z1.f90
z1.f90:3:16:

   character(('')) :: c = 'c'
1
Error: Expression at (1) must be of INTEGER type, found CHARACTER


$ gfortran-9-2018 -c z1.f90
f951: internal compiler error: in gfc_apply_init, at fortran/expr.c:4468
0x61befc gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*)
../../gcc/fortran/expr.c:4468
0x60e003 build_struct
../../gcc/fortran/decl.c:2111
0x60e003 variable_decl
../../gcc/fortran/decl.c:2786
0x60e003 gfc_match_data_decl()
../../gcc/fortran/decl.c:5921
0x66d0d3 match_word
../../gcc/fortran/parse.c:65
0x66d0d3 decode_statement
../../gcc/fortran/parse.c:376
0x66eb5a next_free
../../gcc/fortran/parse.c:1234
0x66eb5a next_statement
../../gcc/fortran/parse.c:1466
0x6705a4 parse_derived
../../gcc/fortran/parse.c:3278
0x6705a4 parse_spec
../../gcc/fortran/parse.c:3819
0x672c37 parse_progunit
../../gcc/fortran/parse.c:5671
0x6742b9 gfc_parse_file()
../../gcc/fortran/parse.c:6211
0x6bc89f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79426] [7/8/9 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[gs...@t-online.de]

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

--- Comment #8 from G. Steinmetz  ---

And to make the picture complete, if you _add_ another integer  
(regarding comment 5), it compiles silently (but breaks at run time).


$ cat z2.f90
program p
   type t
  integer :: a
  integer :: b
  integer :: c
  class(*), pointer :: u(:)
   end type
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ gfortran-9-2018 z2.f90
$
$ a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
#...

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Agree with Jakub that if really not necessary, I wouldn't complicate
libsanitizer. Slowness is nicely seen in your table Maxim:
https://github.com/google/sanitizers/issues/837#issuecomment-322519336

Can you Maximum more describe which difficulties do you see using libsanitizer
on 32-bit ARM target? When will you eventually migrate to aarch64 as primary
target?

[Bug fortran/79426] [7/8/9 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[gs...@t-online.de]

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

--- Comment #7 from G. Steinmetz  ---

And with type "t" stripped down to a class only, respectively.
Case analogous to the one in comment 3.


$ cat zc2.f90
program p
   type t
  class(*), pointer :: u(:)
   end type
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ gfortran-9-2018 -c zc2.f90
zc2.f90:1:0:

1 | program p
  |
internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
0x6bf9d7 gfc_advance_chain(tree_node*, int)
../../gcc/fortran/trans.c:58
0x6ea85a gfc_class_len_get(tree_node*)
../../gcc/fortran/trans-expr.c:229
0x727331 trans_associate_var
../../gcc/fortran/trans-stmt.c:2020
0x72d9d1 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2073
0x6bff57 trans_code
../../gcc/fortran/trans.c:1918
0x6e7674 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x6744d6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6744d6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc89f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79426] [7/8/9 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[gs...@t-online.de]

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

--- Comment #6 from G. Steinmetz  ---

In all za* examples above reduce the type by an integer variable. 
Now type "t" contains one integer and one class(*) :


$ cat zb2.f90
program p
   type t
  integer :: a
  class(*), pointer :: u(:)
   end type
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ gfortran-9-2018 -c zb2.f90
zb2.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xb297bf crash_signal
../../gcc/toplev.c:325
0x6ea85e gfc_class_len_get(tree_node*)
../../gcc/fortran/trans-expr.c:233
0x727331 trans_associate_var
../../gcc/fortran/trans-stmt.c:2020
0x72d9d1 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2073
0x6bff57 trans_code
../../gcc/fortran/trans.c:1918
0x6e7674 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x6744d6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6744d6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc89f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79426] [7/8/9 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #5 from G. Steinmetz  ---

Reducing test case from comment 0 with "select type" results in za1/za2.
Problem is also relevant for "associate" construct, see za3.
And it holds for "allocatable" attribute too, see exemplary za6/za7.
Here type "t" contains two integers and one class(*).


$ cat za1.f90
module m
   type t
  integer :: a
  integer :: b
  class(*), pointer :: u(:)
   end type
end
program p
   use m
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ cat za2.f90
program p
   type t
  integer :: a
  integer :: b
  class(*), pointer :: u(:)
   end type
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ cat za3.f90
program p
   type t
  integer :: a
  integer :: b
  class(*), pointer :: u(:)
   end type
   type(t) :: z
   associate (y => z%u(1))
   end associate
end


$ cat za6.f90
program p
   type t
  integer :: a
  integer :: b
  class(*), allocatable :: u(:)
   end type
   type(t) :: z
   select type (y => z%u(1))
   end select
end


$ cat za7.f90
program p
   type t
  integer :: a
  integer :: b
  class(*), allocatable :: u(:)
   end type
   type(t) :: z
   associate (y => z%u(1))
   end associate
end


$ gfortran-9-2018 -c za2.f90
za2.f90:1:0:

1 | program p
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2426
0x95f1b4 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2425
0x774aad trans_associate_var
../../gcc/fortran/trans-stmt.c:2027
0x77abc9 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2073
0x6e6817 trans_code
../../gcc/fortran/trans.c:1918
0x71be1d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x699c56 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x699c56 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6e2b7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/79440] internal compiler error: in fold_convert_loc, at fold-const.c:2373

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---

Reduced test case from comment 0 :


$ cat z3.f90
module m
   type t
   end type
   type t2
  class(t), pointer :: a
   end type
   type, extends(t2) :: t3
   end type
   type t4
  class(t2), pointer :: b
   end type
end
program p
   use m
   type(t), target, allocatable :: y
   type(t4), allocatable :: z
   allocate (z%b, source=t3(y))
end


$ cat z4.f90
program p
   type t
   end type
   type t2
  class(t), pointer :: a
   end type
   type, extends(t2) :: t3
   end type
   type t4
  class(t2), pointer :: b
   end type
   type(t), target, allocatable :: y
   type(t4), allocatable :: z
   allocate (z%b, source=t3(y))
end


$ gfortran-9-2018 -c z4.f90
z4.f90:14:0:

   14 |allocate (z%b, source=t3(y))
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2548
0x95f280 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2548
0x731cfc gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7642
0x732da8 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7824
0x732462 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7659
0x732da8 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.c:7824
0x733daa gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7891
0x72bc9c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8059
0x7340e5 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8184
0x77e95c gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5927
0x6e67a7 trans_code
../../gcc/fortran/trans.c:1990
0x71be1d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x699c56 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x699c56 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6e2b7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures

[boger at gcc dot gnu.org]

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

--- Comment #2 from boger at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> C testcase anyone? ;)  I never succeeded extracting anything meaningful from
> the Go testsuite logs to be able to reproduce sth (no cut possible).

I am working on a small Go testcase where you should be able to just do:
gccgo -o test test.go

I'm trying to narrow it down a bit more.

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[bruno.bugs.contact at gmail dot com]

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

Bruno Bugs  changed:

   What|Removed |Added

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

--- Comment #4 from Bruno Bugs  ---
As discussed on irc, gcc is correct here.

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
What really matters here is triviality of the destructor, and that isn't
affected by the user-declared defaulted dtor.

Clang fails this test, because memcpy overwrites the tail padding:

#include 
#include 
#include 
struct Base {
unsigned x;
short y;
~Base() = default;

void set(const Base& b);
};

void Base::set(const Base& b) {
static_assert(std::is_trivially_copyable::value,"");
std::memcpy(this, , sizeof(Base));
}

struct Der : Base {
 short z;
};

int i[] = { sizeof(Base), sizeof(Der) };

int main()
{
Der d;
d.z = 99;
Base b{};
d.set(b);
assert(d.z == 99);
}

I think GCC is correct here.

[Bug driver/88024] New: At -O0 and -Og, GCC should warn if you explicitly try to enable an option that is ignored

[sandra at gcc dot gnu.org]

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

Bug ID: 88024
   Summary: At -O0 and -Og, GCC should warn if you explicitly try
to enable an option that is ignored
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

While poking at documentation issue PR59658, I realized that there is a code
bug in the handling of optimization options too:  there ought to be a
diagnostic if you try to enable an optimization that is completely ignored due
to the different pass lists for -O0 and -Og.  E.g.

gcc -O0 -fif-conversion -fshrink-wrap foo.c

ought to warn you that those options have no effect at -O0.

I think this could be fixed by adding some additional properties to the
default_options_table in opts.c, which would have the additional benefit of
making it easier to document (and maintain the documentation for) these
options.

[Bug rtl-optimization/85594] ICE during expand when compiling with -fwrapv -fopenmp

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
Moreover, adding -O1 -ftree-loop-vectorize makes current trunk snapshot ICE
like this:

% gcc-9.0.0-alpha2018 -O1 -fopenmp -ftree-loop-vectorize -fwrapv -c
gcc/testsuite/gcc.dg/gomp/pr81768-2.c
during GIMPLE pass: ifcvt
gcc/testsuite/gcc.dg/gomp/pr81768-2.c: In function 'foo._omp_fn.1':
gcc/testsuite/gcc.dg/gomp/pr81768-2.c:10:9: internal compiler error: tree
check: expected ssa_name, have var_decl in SSA_VAL, at tree-ssa-sccvn.c:461
   10 | #pragma omp target parallel for schedule(static, 32) collapse(3)
  | ^~~
0x6ca2ea tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree.c:9623
0x6ac4fe tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree.h:3154
0x6ac4fe SSA_VAL(tree_node*, bool*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:461
0x6ac4fe vuse_ssa_val
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:479
0x6ac4fe vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:2615
0xe96960 visit_reference_op_load
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:3968
0xe96960 visit_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:4378
0xe981c4 process_bb
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6011
0xe99550 do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6618
0xe9a667 do_rpo_vn(function*, edge_def*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa-sccvn.c:6707
0xd59209 tree_if_conversion(loop*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3066
0xd5a9b6 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3142
0xd5a9b6 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-if-conv.c:3130

Should I file a separate PR for this?

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The C++03 definition of POD struct (which is what matters for the ABI) requires
that it has no user-defined destructor.

Your type has a user-declared destructor, which is implicitly-defined when
odr-used. That is not user-defined. So it's can be a POD struct.

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 14 16:43:38 2018
New Revision: 266152

URL: https://gcc.gnu.org/viewcvs?rev=266152=gcc=rev
Log:
PR bootstrap/86739
* hash-map.h (hash_map::iterator::reference_pair): New class.
(hash_map::iterator::operator*): Return it rather than std::pair.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hash-map.h

[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The meaning of "user-declared" in C++03 is closer to "has a function body" than
the meaning in C++11, where it includes defaulted definitions.
A defaulted definition in C++11 is equivalent to an implicit (i.e. not
user-declared) definition in C++03. So I would argue that your type is a POD
for the purposes of layout, and GCC is correct.

Consider:

struct Base {
unsigned x;
short y;
#if __cplusplus >= 201103L
~Base() = default;
#endif
};

struct Der : Base {
 short z;
};

int i[] = { sizeof(Base), sizeof(Der) };

I would argue that the #if block should not affect the ABI of this type, i.e.
it should be identical in C++03 and C++11, so it should be a "POD for the
purposes of layout". Otherwise adding explicitly-defaulted special members (to
conform to guidance like the Rule of Zero) causes ABI changes.

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The dynamic offset code has the problem that a) it is usually larger b) usually
slower c) ABI incompatible.

[Bug sanitizer/88022] Support dynamic shadow offset in ASan

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from chefmax at gcc dot gnu.org ---
I think nothing prevents us from trying several ranges, the question is whether
upstream guys will accept this...
I've just noticed that the code for dynamic shadow offset is already present in
libsanitizer sources and it seems that it's not hard to enable it for Linux.

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug tree-optimization/88023] New: [9 Regression] ICE: verify_ssa failed (error: definition in block 39 does not dominate use in block 34)

[asolokha at gmx dot com]

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

Bug ID: 88023
   Summary: [9 Regression] ICE: verify_ssa failed (error:
definition in block 39 does not dominate use in block
34)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-9.0.0-alpha2018 snapshot (r266019) ICEs when compiling
gcc/testsuite/gcc.c-torture/compile/20150108.c w/ -O1 (-O2, -O3)
-ftree-loop-vectorize --param max-loop-header-insns=2:

% gcc-9.0.0-alpha2018 -O1 -ftree-loop-vectorize --param
max-loop-header-insns=2 -c gcc/testsuite/gcc.c-torture/compile/20150108.c
gcc/testsuite/gcc.c-torture/compile/20150108.c: In function 'fn1':
gcc/testsuite/gcc.c-torture/compile/20150108.c:5:5: error: definition in block
39 does not dominate use in block 34
5 | int fn1 () {
  | ^~~
for SSA_NAME: _107 in statement:
s_lsm.23_90 = PHI <_107(34), _107(39)>
PHI argument
_107
for PHI node
s_lsm.23_90 = PHI <_107(34), _107(39)>
during GIMPLE pass: vect
gcc/testsuite/gcc.c-torture/compile/20150108.c:5:5: internal compiler error:
verify_ssa failed
0xeea820 verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/tree-ssa.c:1188
0xc04add execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/passes.c:1932
0xc058de execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha2018/work/gcc-9-2018/gcc/passes.c:1979

[Bug target/86891] [9 Regression] wrong code with -O -frerun-cse-after-loop -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||collison at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
  Component|tree-optimization   |target

--- Comment #1 from Jakub Jelinek  ---
Started with r262890.
I believe the bug is in the RTL of the *sub3_carryinCV* patterns (though
I admit I don't know exactly what those insns do on aarch64).

Through -O and disabling of some GIMPLE opts we end up with arguments to
SUB_OVERFLOW that aren't constant during expansion, but will be turned into
constants during RTL optimizations.

We effectively are checking if unsigned subtraction 0xfff9U -
0xfff8U overflows.
The aarch64 expander has a pattern for usubvti4, and on input we have
that 0xfff9U constant in (reg:TI 111) and the -(unsigned __int128) 8 constant
in (reg:TI 117).  The expander emits:
(insn 23 22 24 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (subreg:DI (reg:TI 111) 0)
(subreg:DI (reg:TI 117) 0)))
(set (reg:DI 121)
(minus:DI (subreg:DI (reg:TI 111) 0)
(subreg:DI (reg:TI 117) 0)))
]) "pr86891.c":9 298 {subdi3_compare1}
 (nil))
(insn 24 23 25 2 (set (reg:DI 123)
(subreg:DI (reg:TI 111) 8)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(insn 25 24 26 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (sign_extend:TI (reg:DI 123))
(plus:TI (sign_extend:TI (subreg:DI (reg:TI 117) 8))
(ltu:TI (reg:CC 66 cc)
(const_int 0 [0])
(set (reg:DI 122)
(minus:DI (minus:DI (reg:DI 123)
(subreg:DI (reg:TI 117) 8))
(ltu:DI (reg:CC 66 cc)
(const_int 0 [0]
]) "pr86891.c":9 367 {*subdi3_carryinCV}
 (nil))
(insn 26 25 27 2 (set (subreg:DI (reg:TI 120) 0)
(reg:DI 121)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(insn 27 26 28 2 (set (subreg:DI (reg:TI 120) 8)
(reg:DI 122)) "pr86891.c":9 47 {*movdi_aarch64}
 (nil))
(jump_insn 28 27 71 2 (set (pc)
(if_then_else (ltu (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 31)
(pc))) "pr86891.c":9 9 {condjump}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 31)

I assume these instructions DTRT at runtime.
Now consider what happens when you propagate those constants into that RTL.
insn 23 sets pseudo 121 to 0xfff9ULL - (-8ULL), i.e. 0x10001ULL with overflow
(first argument is smaller than second argument), so I expect carry is set.

Now, insn 25 I'd hope performs r122 = 0ULL - (-1ULL) - 1 (the last being
carry), which is I think modelled properly by the (set (reg:DI 122) (minus
...)) part of the insn.
What is incorrect is the compare part of insn 25.  Because it is compare 0
(-(unsigned __int128)1 + carry), i.e. comparison of 0 and 0, so no CC is set,
even when I hope
the instruction actually should set carry (if it doesn't it couldn't be used
even at runtime, because 0xfff9ULL - (-(unsigned __int128)8) does overflow.

Note, the i386.md pattern which I'd think would be similar in what it does at
runtime, is:
(define_insn "sub3_carry_ccc"
  [(set (reg:CCC FLAGS_REG)
(compare:CCC
  (zero_extend: (match_operand:DWIH 1 "register_operand" "0"))
  (plus:
(ltu: (reg:CC FLAGS_REG) (const_int 0))
(zero_extend:
  (match_operand:DWIH 2 "x86_64_sext_operand" "rmWe")
   (clobber (match_scratch:DWIH 0 "=r"))]
  ""
  "sbb{}\t{%2, %0|%0, %2}"
  [(set_attr "type" "alu")
   (set_attr "mode" "")])

i.e. instead of comparing (sign_extend:TI (operand 1)) with (plus:TI
(sign_extend:TI (operand 2)) (ltu:TI (cc) (const_int 0))) in aarch64 backend it
compares
(zero_extend:TI (operand 1)) with (plus:TI (ltu:TI (cc) (const_int 0))
(zero_extend:TI (operand 2)).  Not really sure if the order of carry and
extension of operand 2 matters that much
(needs to be checked in combine log if it should be matches by combiner in some
cases), but I think the zero_extend vs. sign_extend is significant.

Now, looking at what aarch64 does for add with carry, there are separate
patterns like add3_carryinC which set CC_C mode and use zero_extend and
add3_carryinV which sets CC_V mode and uses sign_extend.
So, shouldn't sub3_carryin{C,V} be split similarly and if we check carry
flag, we should use subdi3_carryinC?

[Bug middle-end/86575] [7/8 Regression] -Wimplicit-fallthrough affects code generation

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

Summary|[7/8/9 Regression]  |[7/8 Regression]
   |-Wimplicit-fallthrough  |-Wimplicit-fallthrough
   |affects code generation |affects code generation

--- Comment #5 from Michael Matz  ---
Fixed in trunk.  Not planning backporting, it's not a very important problem.

[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
Then people realized that there was a problem if the SUBREGs were spilled onto
the stack at some point, hence an additional test on LOAD_EXTEND_OP:

r8787 | wilson | 1995-01-21 03:23:10 +0100 (Sat, 21 Jan 1995) | 3 lines

(num_sign_bit_copies): Can handle paradoxical subreg only
if LOAD_EXTEND_OP is defined to SIGN_EXTEND.

r19928 | amylaar | 1998-05-21 13:35:10 +0200 (Thu, 21 May 1998) | 3 lines

* combine.c (nonzero_bits): For paradoxical subregs, take
LOAD_EXTENDED_OP into account.

Then, in order to fix PR c/2454 on some platform, the mechanism was killed for
the first time without much ado:

r55386 | sayle | 2002-07-11 03:23:07 +0200 (Thu, 11 Jul 2002) | 5 lines

PR c/2454
* combine.c (nonzero_bits): LOAD_EXTEND_OP should only apply
to SUBREGs of MEMs.  (num_sign_bit_copies): Likewise.

Now the mechanism was quite powerful on RISC architectures whose loads are
implicitly extended via LOAD_EXTEND_OP and the infrastructure was still present
in the compiler so I decided to revive it after stumbling for the 47th time on
a trivially redundant extension in some SPARC assembly.  This initially
required  only a few adjustments and fixes left and right outside the combiner
but it now appears that they are major issues within the combiner itself which
cannot be solved in a satisfactory way.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
I am seeing this for a fortran compilation but not for the same .c compilation
as Martin did:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran5/../../gfortran
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran5/../../
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -O2 -floop-nest-optimize -S -o pr42334-1.s
during GIMPLE pass: graphite
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f:3:0:
internal compiler error: in dump_printf_loc, at dumpfile.c:1287
0x105747f7 dump_printf_loc(dump_flag, dump_location_t const&, char const*, ...)
/home/seurer/gcc/gcc-trunk/gcc/dumpfile.c:1287
0x1152c9d3 translate_isl_ast_to_gimple::scop_to_isl_ast(scop*)
/home/seurer/gcc/gcc-trunk/gcc/graphite-isl-ast-to-gimple.c:1417
0x1152ee7f graphite_regenerate_ast_isl(scop*)
/home/seurer/gcc/gcc-trunk/gcc/graphite-isl-ast-to-gimple.c:1476
0x11528793 graphite_transform_loops()
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:413
0x11529753 graphite_transforms
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:476
0x11529753 execute
/home/seurer/gcc/gcc-trunk/gcc/graphite.c:553
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f   -O  (test for excess errors)

[Bug tree-optimization/71026] Missing division optimizations

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
It looks the only case left to do is f5:

x * C <= 0.0 -> x <= 0.0 if C >= 1.0
x * C <= 0.0 -> x < FLT_MIN/C if C < 1.0

[Bug middle-end/86575] [7/8/9 Regression] -Wimplicit-fallthrough affects code generation

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  ---
Author: matz
Date: Wed Nov 14 15:43:54 2018
New Revision: 266148

URL: https://gcc.gnu.org/viewcvs?rev=266148=gcc=rev
Log:
Fix PR middle-end/86575

PR middle-end/86575
* gimplify.c (collect_fallthrough_labels): Add new argument,
return location via that, don't modify statements.
(warn_implicit_fallthrough_r): Adjust call, don't use
statement location directly.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c

[Bug rtl-optimization/85925] [7/8/9 regression] Mis-compilation at -02, masking with 257 goes wrong in combine

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
OK, it's probably time to concede final defeat, although this will bring back
quite a few redundant extensions on RISC architectures like ARM and SPARC.

For the records, here's a bit of history about this stuff: in the early days,
the code was straightforward and just looked inside paradoxical SUBREGs on
targets for which WORD_REGISTER_OPERATIONS is defined:

nonzero_bits:

#ifndef WORD_REGISTER_OPERATIONS
  /* On many CISC machines, accessing an object in a wider mode
 causes the high-order bits to become undefined.  So they are
 not known to be zero.  */
  if (GET_MODE_SIZE (GET_MODE (x))
  > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x
nonzero |= (GET_MODE_MASK (GET_MODE (x))
& ~ GET_MODE_MASK (GET_MODE (SUBREG_REG (x;
#endif

num_sign_bit_copies:

#ifdef WORD_REGISTER_OPERATIONS
  /* For paradoxical SUBREGs on machines where all register operations
 affect the entire register, just look inside.  Note that we are
  5473 kennerpassing MODE to the recursive call, so the number of
sign bit copies
  5473 kennerwill remain relative to that mode, not the inner mode.
 */
  2189 kenner 
  2189 kenner   if (GET_MODE_SIZE (GET_MODE (x))
  2189 kenner > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x
  2189 kenner   return num_sign_bit_copies (SUBREG_REG (x), mode);
  2189 kenner #endif

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Actually, I'm still not able to reproduce this, but the fix seems obvious; am
working on it.

[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed, though for some reason I needed to add -floop-parallelize-all to the
flags in comment #0 to trigger it.

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0

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

[Bug go/87470] [9 Regression] libgo/go/runtime/malloc.go failed to build with -mx32

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
This was fixed by https://golang.org/cl/138817,
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00045.html .

[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||janus at gcc dot gnu.org
  Known to work||8.2.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Dominique d'Humieres  ---
Probably r264350 (pr88009).

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 14 14:33:44 2018
New Revision: 266147

URL: https://gcc.gnu.org/viewcvs?rev=266147=gcc=rev
Log:
2018-11-14  Richard Biener  

PR middle-end/87985
* tree-data-ref.c (split_constant_offset): Add wrapper
allocating a cache hash-map.
(split_constant_offset_1): Cache results of expanding
expressions from SSA def stmts.

* gcc.dg/pr87985.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87985.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug rtl-optimization/88018] [8/9 Regression] ICE in insert_insn_on_edge at cfgrtl.c:1952 since r255066

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
A latent issue before that I guess.

The problem is we have a call which can throw, isn't marked noreturn, but is
followed by __builtin_unreachable () call.  In RTL that is represented by the
bb having just EH edge and no fallthru edge.

The stack pass emits some insn(s) after such a call and calls
fixup_abnormal_edges to fix that up.  fixup_abnormal_edges relies on the
presence of the fallthru edge though.  I guess easiest would be just delete
those insns and not insert them on the fallthru edge (which doesn't exist).

[Bug fortran/87946] [7/8/9 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 CC||pault at gcc dot gnu.org
  Known to work||6.4.0
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Could be caused by r241450 (pr69834).

[Bug tree-optimization/87917] ICE in initialize_matrix_A at gcc/tree-data-ref.c:3150

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
(In reply to Sebastian Pop from comment #3)
> > Sebastian - can you say if
> > evolution_function_is_affine_multivariate_p ({0, +, {0, +, 4}_1}_2, 1)
> > should really return true?
> 
> You are right, {0, +, {0, +, 4}_1}_2 is not a valid affine multivariate
> function: only the base (not the step) should vary in an outer loop.
> 
> For example, this would be an affine multivariate: {{0, +, 4}_1, +, 42}_2.

Hmm, but evolution_function_is_affine_multivariate_p currently says:

  switch (TREE_CODE (chrec))
{
case POLYNOMIAL_CHREC:
  if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum))
{
  if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum))
return true;

so for {0, +, {0, +, 1}_1 }_2 and asking for loopnum == 2 where loop 2 is
nested inside loop 1 this would already return true because {0, +, 1}_1
is invariant in 2.  Now for the testcase we are asking for loopnum == 1
where the above doesn't hold but we then fall through to

  else
{
  if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC
  && CHREC_VARIABLE (CHREC_RIGHT (chrec))
 != CHREC_VARIABLE (chrec)
  && evolution_function_is_affine_multivariate_p
  (CHREC_RIGHT (chrec), loopnum))
return true;

which surely looks bogus (the != should probably be a flow_loop_nested_p
in some way).  A SCEV like {0, +, {0, +, 1}_1 }_1 isn't valid anyways.

If trying to make sense of evolution_function_is_affine_multivariate_p
by looking at evolution_function_is_affine_p and
evolution_function_is_univariate_p I would come up with sth like

if (evolution_function_is_invariant_p (CHREC_RIGHT (chrec),
   CHREC_VARIABLE (chrec))
&& (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC
|| evolution_function_is_affine_multivariate_p (CHREC_RIGHT
(chrec)))
  return true;
else
  return false;

That is, why's the evolution of CHREC_LEFT restricted at all here?

That said - this would also make the loopnum argument to
evolution_function_is_affine_multivariate_p moot.  So like the following
together with removing the arg everywhere.  It doesn't fix the ICE
though since we then implicitely ask for loopnum == 2.

Index: tree-chrec.c
===
--- tree-chrec.c(revision 266145)
+++ tree-chrec.c(working copy)
@@ -1063,7 +1063,7 @@ evolution_function_is_invariant_p (tree
evolution.  */

 bool
-evolution_function_is_affine_multivariate_p (const_tree chrec, int loopnum)
+evolution_function_is_affine_multivariate_p (const_tree chrec)
 {
   if (chrec == NULL_TREE)
 return false;
@@ -1071,33 +1071,11 @@ evolution_function_is_affine_multivariat
   switch (TREE_CODE (chrec))
 {
 case POLYNOMIAL_CHREC:
-  if (evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec), loopnum))
-   {
- if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum))
-   return true;
- else
-   {
- if (TREE_CODE (CHREC_RIGHT (chrec)) == POLYNOMIAL_CHREC
- && CHREC_VARIABLE (CHREC_RIGHT (chrec))
-!= CHREC_VARIABLE (chrec)
- && evolution_function_is_affine_multivariate_p
- (CHREC_RIGHT (chrec), loopnum))
-   return true;
- else
-   return false;
-   }
-   }
-  else
-   {
- if (evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
loopnum)
- && TREE_CODE (CHREC_LEFT (chrec)) == POLYNOMIAL_CHREC
- && CHREC_VARIABLE (CHREC_LEFT (chrec)) != CHREC_VARIABLE (chrec)
- && evolution_function_is_affine_multivariate_p
- (CHREC_LEFT (chrec), loopnum))
-   return true;
- else
-   return false;
-   }
+  return (evolution_function_is_invariant_p (CHREC_RIGHT (chrec),
+CHREC_VARIABLE (chrec))
+ && (TREE_CODE (CHREC_RIGHT (chrec)) != POLYNOMIAL_CHREC
+ || evolution_function_is_affine_multivariate_p
+   (CHREC_RIGHT (chrec;

 default:
   return false;


Hmm, maybe what is missing is a check at the top whether the CHREC itself
varies in loopnum?  Anyway, the current code doesn't make much sense to me.

And what dependence analysis does - asking for dependence of two DRs
in loop 2 (the inner one) with respect to 

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-10-23 00:00:00 |2018-11-14
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=88020 |

--- Comment #6 from Jonathan Wakely  ---
From Bug 88020:

template 
struct S{
S(T){}
};
static_assert(sizeof(S{0}));



:5:22: error: missing template arguments after 'S'
 static_assert(sizeof(S{0}));
  ^
:2:8: note: 'template struct S' declared here
 struct S{
^

[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-14
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from gcc7 up to trunk (9.0). With gcc6 I get the error

Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug c++/88020] Deduction guides fail inside sizeof

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
.

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

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||toe-ger at web dot de

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