[Bug preprocessor/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:a7b7818f3dbd14cc7577d25dcebaded07395c476

commit r11-346-ga7b7818f3dbd14cc7577d25dcebaded07395c476
Author: Christophe Lyon 
Date:   Wed May 13 06:41:19 2020 +

[PR 95013] Fix gcc.dg/unclosed-init.c

2020-05-13  Christophe Lyon  

PR preprocessor/95013
* gcc.dg/unclosed-init.c: Add missing comment in dg-error.

[Bug debug/95098] Out of scope variable visible during debugging at Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||edlinger at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Don't see this with gdb:

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 4 at 0x4004bd: file z.c, line 11.
Starting program: /home/rguenther/obj/gcc/a.out 

Temporary breakpoint 4, main () at z.c:11
11  int main() { b(); }
(gdb) s

Breakpoint 3, b () at z.c:4
4   for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
(gdb) p l_9
No symbol "l_9" in current context.
(gdb) info locals
l_10 = 

note there _is_ l_9 in the DWARF, even with a location:

 <2>: Abbrev Number: 8 (DW_TAG_lexical_block)
   DW_AT_low_pc  : 0xa
   DW_AT_high_pc : 0x0
 <3>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_name: l_9
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 7
   DW_AT_decl_column : 7
   DW_AT_type: <0xeb>
   DW_AT_location: 10 byte block: 3 0 0 0 0 0 0 0 0 9f 
(DW_OP_addr: 0; DW_OP_stack_value)

but

 :
   0:   c7 05 00 00 00 00 15movl   $0x15,0x0(%rip)# a 
   7:   00 00 00 
   a:   c3  retq   

and certainly the DW_AT_high_pc of the lexical block looks "odd" - the
block is not existent.  Assembly:

b:
.LFB0:
.file 1 "z.c"
.loc 1 2 9 view -0
.cfi_startproc
.loc 1 3 5 view .LVU1
.loc 1 4 5 view .LVU2
.loc 1 4 14 is_stmt 0 view .LVU3
movl$21, g_2(%rip)
.loc 1 4 20 is_stmt 1 view .LVU4
.LBB2:
.loc 1 7 2 view .LVU5
.LVL0:
.loc 1 8 2 view .LVU6
.LBE2:
.loc 1 10 1 is_stmt 0 view .LVU7
ret

so you can see .LBB2 to .LBE2 do not contain any actual instructions.
GIMPLE we expand from:

 b ()
{
   [local count: 1073741824]:
  [z.c:3:5] # DEBUG BEGIN_STMT
  [z.c:4:5] # DEBUG BEGIN_STMT
  [z.c:4:14] g_2 = 21;
  [z.c:4:20] # DEBUG BEGIN_STMT
  [z.c:7:2] # DEBUG BEGIN_STMT
  [z.c:7:7] # DEBUG l_9 => [z.c:7:13] &a
  [z.c:8:2] # DEBUG BEGIN_STMT
  [z.c:8:2] return;

does lldb try to interpret location views yet?  I suppose it might get
confused about the is_stmt 0 on the movl and only stop at ret
even though the "last" location on that is line 10 (but is_stmt 0 again).

It's difficult to produce a meaningful line-number program for the
resulting assembler ;)

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Just to quote EVRP sees

   :
  _1 = VIEW_CONVERT_EXPR(f);
  _2 = _1 & 1048575;
  if (_2 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _3 = f.x;
  _4 = (unsigned int) _3;
  y_8 = _4 * 4096;
  if (y_8 <= 199)

thus the f.x != 0 test has been folded by one of those $?%&! permature
fold-const transforms to

  if ((BIT_FIELD_REF  & 1048575) != 0)

the fix is to get rid of those (and fix the "fallout").

[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts

[zhongyunde at tom dot com]

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

--- Comment #2 from zhongyunde at tom dot com  ---
It is a generic issue for all targets, such as x86, it also don't enpand IVOPTs
as index is not used for DEST and Src directly. we may need expand IVOPTs, then
different targets can select different one according their Cost model.
Now, it seems ok for x86 as it have load/store insns folded the lshift operand,
so it doesn't need separate lshift operand in loop body .

== base on the ARM gcc 9.2.1 on https://gcc.godbolt.org, You'll get
separate lshift operand lsl in loop kernel, and ARM64 gcc 8.2 will use ldr
x3, [x1, x4, lsl 3] to avoid the separate lshift operand. so we can see all
target dont select an IV with Step 8. 
C0ADA(unsigned long long, long long*, long long*):
push{r4, r5, r6, r7, lr}@
mov r4, r0@ len, tmp135
mov r5, r1@ len, tmp136
orrsr1, r4, r5  @ tmp137, len
beq .L1 @,
mov r1, #0@ C05A1,
.L3:
lsl r0, r1, #3@ _2, C05A1,
add ip, r2, r1, lsl #3@ tmp120, Src, C05A1,
ldr lr, [r2, r0]  @ _4, *_3
ldr ip, [ip, #4]  @ _4, *_3
umull   r6, r7, lr, lr@ tmp125, _4, _4
mul ip, lr, ip@ tmp122, _4, tmp122
addsr1, r1, r4  @ C05A1, C05A1, len
subsr4, r4, #1  @ len, len,
sbc r5, r5, #0@ len, len,
add r0, r3, r0@ tmp121, Dest, _2
add r7, r7, ip, lsl #1@,, tmp122,
orrslr, r4, r5  @ tmp138, len
stm r0, {r6-r7}   @ *_5, tmp125
bne .L3 @,
.L1:
pop {r4, r5, r6, r7, lr}  @
bx  lr  @

Thanks for your notice.

[Bug debug/95098] New: Out of scope variable visible during debugging at Og

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95098
   Summary: Out of scope variable visible during debugging at Og
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

Variable l_9 is visible when the debugger hit line 4.

$ cat a.c
int g_2, a;
int b() {
  char l_10;
  for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
return g_2;
  {
int *l_9 = &a;
return;
  }
}
int main() { b(); }

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200508 (experimental) (GCC) 

$ lldb -v
  lldb version 11.0.0
  clang revision 23cbea9a04e023d5b79dfee5964fae769340c993
  llvm revision 23cbea9a04e023d5b79dfee5964fae769340c993

$ gcc -Og -g -o opt a.c

$ lldb opt 
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b main
Breakpoint 1: where = opt`main at a.c:11:14, address = 0x0040048d
(lldb) r
Process 61 launched: 'opt' (x86_64)
Process 61 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x0040048d opt`main at a.c:11:14
   8return;
   9  }
   10   }
-> 11   int main() { b(); }
(lldb) s
Process 61 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x00400482 opt`b at a.c:4:12
   1int g_2, a;
   2int b() {
   3  char l_10;
-> 4  for (g_2 = 21; (g_2 < (-27)); g_2 = 0)
   5return g_2;
   6  {
   7int *l_9 = &a;
(lldb) frame var -s -g
LOCAL: (char) l_10 = 
STATIC: (int *) l_9 = 0x0060102c
GLOBAL: (int) g_2 = 0
GLOBAL: (int) a = 0

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks|85316   |
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
The problem is if (f.x) gets lowered too early.
This is not directly a VPR issue either.
Changing the code slightly:
#include 
struct foo {
uint32_t x:20;
};
int bar(struct foo f)
{

   uint32_t y = (uint32_t)f.x;
if (y) {
y *= 4096;
if (y<200) return 1;
else return 2;
}
return 3;
}

GCC is able to optimize it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Biener  ---
> It the growth limit seems could be refined. The ^ is an exponent operation,
> right?

Yes.  The idea is to limit growth more when there is no benefit of unrolling
detected by the cost model (which currently simply counts likely eliminated
stmts).

(In reply to Jiu Fu Guo from comment #27)
> (In reply to Jiu Fu Guo from comment #26)
> > (In reply to Richard Biener from comment #20)
> > > (In reply to Jiu Fu Guo from comment #18)
> > > > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > > > if the loop has multi-exits or upbound is not a fixed number, we may 
> > > > not do
> > > > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> > > 
> > > That doens't make much sense (-funroll-all-loops is RTL unroller only).
> > 
> 
> For the loop which has multi-exits, it may not helpful to unroll it,
> especially "complete unroll" may be not helpful. Like loop in in_pack_i4.c.
> Since it would early exit, some iterations(may most iterations) were not
> executed.
> 
> Is it a good idea to disable the GIMPLE cunroll for this kind of loop? RTL
> unroll_stupid does not unroll this kind of loop either.

Well, GIMPLE cunroll specifically handles the situation of peeling such loops
and has a separate --param to control how many extra branches it may introduce
for those exits.  Generally disabling unrolling of such loops isn't a good
idea,
the reason for completely unrolling loops is abstraction removal and not
necessarily producing more optimal loop kernels (the loop is gone afterwards).

One of my TODO items is to work on its costing model to the extent that
we run value-numbering on the unrolled body (that's already done) and
roll back the unrolling if there wasn't any visible benefit.  The difficult
cases are like those in SPEC calculix where for full benefit you need to
unroll the 5(!) innermost loops and to even see any benefit you need to
unroll the 3 innermost loops.

[Bug middle-end/95052] Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

--- Comment #7 from Krzysztof Nowicki  ---
Thanks for the very quick response. I've applied the patch on top of GCC 9.1
and it indeed fixes the problem we've seen on MIPS64.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #16 from Thomas Koenig  ---
We really need a test case. SPEC is no different to any other closed-source
commercial software in that respect.

[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts

[amker at gcc dot gnu.org]

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

--- Comment #1 from bin cheng  ---
Please provide the exact configuration/compilation command lines in bug report
next time, which could save others' time to reproduce.  Considering I didn't
touch mips for years.

As for this specific issue, note right now SCEV can't model C05A1, thus
DEST[C05A1] and Src[C05A1], so there is not much IVOPTs can do with its
current shape.

We did discuss about extending the pass to handle non-scev memory references in
other PRs, but unless that is implemented, I see no easy fix here.

Thanks

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Blocks||85316
   Keywords||missed-optimization
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Confirmed via godbolt: https://godbolt.org/z/FexRgJ


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Bin Cheng :

https://gcc.gnu.org/g:f6e1a4cd83190746b6544917f7526fa480ca5f18

commit r11-345-gf6e1a4cd83190746b6544917f7526fa480ca5f18
Author: Bin Cheng 
Date:   Wed May 13 11:37:47 2020 +0800

Add missing unit dependence vector in data dependence analysis

Current data dependence analysis misses unit distant vector if DRs in
DDR have the same invariant access functions.  This adds the vector as
the constant access function case.

2020-05-13  Bin Cheng  
PR tree-optimization/94969

gcc/
* tree-data-dependence.c (constant_access_functions): Rename to...
(invariant_access_functions): ...this.  Add parameter.  Check for
invariant access function, rather than constant.
(build_classic_dist_vector): Call above function.
* tree-loop-distribution.c (pg_add_dependence_edges): Add comment.

gcc/testsuite/
* gcc.dg/tree-ssa/pr94969.c: New test.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #27 from Jiu Fu Guo  ---
(In reply to Jiu Fu Guo from comment #26)
> (In reply to Richard Biener from comment #20)
> > (In reply to Jiu Fu Guo from comment #18)
> > > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > > if the loop has multi-exits or upbound is not a fixed number, we may not 
> > > do
> > > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> > 
> > That doens't make much sense (-funroll-all-loops is RTL unroller only).
> 

For the loop which has multi-exits, it may not helpful to unroll it, especially
"complete unroll" may be not helpful. Like loop in in_pack_i4.c. Since it would
early exit, some iterations(may most iterations) were not executed.

Is it a good idea to disable the GIMPLE cunroll for this kind of loop? RTL
unroll_stupid does not unroll this kind of loop either.

[Bug tree-optimization/95097] New: Missed optimization with bitfield value ranges

[bugdal at aerifal dot cx]

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

Bug ID: 95097
   Summary: Missed optimization with bitfield value ranges
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

#include 
struct foo {
uint32_t x:20;
};
int bar(struct foo f)
{
if (f.x) {
uint32_t y = (uint32_t)f.x*4096;
if (y<200) return 1;
else return 2;
}
return 3;
}

Here, truth of the condition f.x implies y>=4096, but GCC does not DCE the
y<200 test and return 1 codepath.

I actually had this come up in real world code, where I was considering use of
an inline function with nontrivial low size cases when a "page count" bitfield
is zero, where I expected these nontrivial cases to be optimized out based on
already having tested that the page count being nonzero, but GCC was unable to
do it. LLVM/clang does it.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #26 from Jiu Fu Guo  ---
(In reply to Richard Biener from comment #20)
> (In reply to Jiu Fu Guo from comment #18)
> > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > if the loop has multi-exits or upbound is not a fixed number, we may not do
> > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> 
> That doens't make much sense (-funroll-all-loops is RTL unroller only).

-funroll-all-loops is used by RTL unroller (decide_unroll_stupid for loop like 
"while (cond) body"). 
And during option handling, -funroll-all-loops also enables -funroll-loops.
When I thinking about for "cunroll", we may also use a flag to control those
loops to be unrolled less, this option come into my mind.

> 
> I think the growth limits are simply too large unless we compute a "win"
> which we in this case do not.  So I'd say the growth limits should scale
> with win ^ (1/new param) thus if we estimate to eliminate 20% of the
> loop stmts due to unrolling then the limit to apply is
> limit * (0.2 ^ (1/X)) with X maybe defaulting to 2.

It the growth limit seems could be refined. The ^ is an exponent operation,
right?

> 
> I'd only apply this new limit for peeling (peeling is when the loop count
> is not constant and thus we keep the exit tests).
> 
> Of course people want more peeling (hello POWER people!)

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #25 from Jiu Fu Guo  ---
(In reply to Richard Biener from comment #23)
> (In reply to Richard Biener from comment #20)
> > (In reply to Jiu Fu Guo from comment #18)
> > > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > > if the loop has multi-exits or upbound is not a fixed number, we may not 
> > > do
> > > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> > 
> > That doens't make much sense (-funroll-all-loops is RTL unroller only).
> > 
> > I think the growth limits are simply too large unless we compute a "win"
> > which we in this case do not.  So I'd say the growth limits should scale
> > with win ^ (1/new param) thus if we estimate to eliminate 20% of the
> > loop stmts due to unrolling then the limit to apply is
> > limit * (0.2 ^ (1/X)) with X maybe defaulting to 2.
> > 
> > I'd only apply this new limit for peeling (peeling is when the loop count
> > is not constant and thus we keep the exit tests).
> > 
> > Of course people want more peeling (hello POWER people!)
> 
> Btw, the issue with the rs6000 code at present is that it uses
> unroll_only_small_loops but that only affects the RTL unroller
> while the enablement of -funroll-loops at -O2 affects GIMPLE
> as well but unconstrained (with -O3 params).  For the main
> unroll pass (not cunrolli) this triggers code size growth:
> 
>   unsigned int val = tree_unroll_loops_completely (flag_unroll_loops
>|| flag_peel_loops
>|| optimize >= 3, true);
> 
> the "original" patch also adjusted parameters.  If the intent is to only
> affect the RTL unroller then we need a separate flag controlling it
> (yeah, using the same flags as heuristic trigger was probably bad).

Yes, the patch controls RTL unroller for small loops, and also enabled cunroll
(through flag_unroll_loops). This cause cunroll may increase size as you
explained.

[Bug target/94118] Undocumented inline assembly [target] operand modifiers

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/94118] Undocumented inline assembly [target] operand modifiers

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:0fec3f62b9bfc03e5088a09036791c2ac84fe0c8

commit r11-344-g0fec3f62b9bfc03e5088a09036791c2ac84fe0c8
Author: liuhongt 
Date:   Fri May 8 17:47:33 2020 +0800

Document more x86 operand modifier.

Documents operand modifiers which are available in asm stmt but missing in
document.

 | Modifier | Description | Available in asm stmt | Existed in
documentation |
 | --- | --- | --- | - |
 | L,W,B,Q,S,T | print the opcode suffix for specified size of operand. |
Available | Not |
 | C | print opcode suffix for set/cmov insn. | Not | - |
 | c | like C, but print reversed condition | Not | - |
 | F,f | likewise, but for floating-point. | Not | - |
 | O | if HAVE_AS_IX86_CMOV_SUN_SYNTAX, expand to "w.", "l." or "q.",
otherwise nothing | Not | - |
 | R | print embedded rounding and sae. | Available | Not |
 | r | print only sae. | Available | Not |
 | z | print the opcode suffix for the size of the current operand. |
Available | Existed |
 | Z | likewise, with special suffixes for x87 instructions. | Availble |
Not |
 | * | print a star (in certain assembler syntax) | Not | - |
 | A | print an absolute memory reference. | Available | Existed |
 | E | print address with DImode register names if TARGET_64BIT. |
Available | Existed |
 | w | print the operand as if it's a "word" (HImode) even if it isn't. |
Available | Existed |
 | s | print a shift double count, followed by the assemblers argument
delimiter. | Available | Not |
 | b | print the QImode name of the register for the indicated operand %b0
would print %al if operands[0] is reg 0. | Available | Existed |
 | w | likewise, print the HImode name of the register. | Available |
Existed |
 | k | likewise, print the SImode name of the register. | Available |
Existed |
 | q | likewise, print the DImode name of the register. | Available |
Existed |
 | x | likewise, print the V4SFmode name of the register. | Available | Not
|
 | t | likewise, print the V8SFmode name of the register. | Available | Not
|
 | g | likewise, print the V16SFmode name of the register. | Avaliable |
Not |
 | h | print the QImode name for a "high" register, either ah, bh, ch or
dh. | Available | Existed |
 | y | print "st(0)" instead of "st" as a register. | Available | Not |
 | d | print duplicated register operand for AVX instruction. | Available |
Not |
 | D | print condition for SSE cmp instruction. | Not | - |
 | P | if PIC, print an @PLT suffix. | Available | Existed |
 | p | print raw symbol name. | Available | Existed |
 | X | don't print any sort of PIC '@' suffix for a symbol. | Not | - |
 | & | print some in-use local-dynamic symbol name. | Not | - |
 | H | print a memory address offset by 8; used for sse high-parts |
Available | Existed |
 | Y | print condition for XOP pcom* instruction. | Not | - |
 | V | print naked full integer register name without %. | Available |
Existed |
 | + | print a branch hint as 'cs' or 'ds' prefix | Not | - |
 | ; | print a semicolon (after prefixes due to bug in older gas). | Not |
- |
 | ~ | print "i" if TARGET_AVX2, "f" otherwise. | Not | - |
 | ^ | print addr32 prefix if TARGET_64BIT and Pmode != word_mode | Not | -
|
 | M | print addr32 prefix for TARGET_X32 with VSIB address. | Not | - |
 | ! | print NOTRACK prefix for jxx/call/ret instructions if required. |
Not | - |
 | N | print maskz if it's constant 0 operand. | Available | Not |
 | I | print comparision predicate operand for sse cmp condition. | Not | -
|

gcc/ChangeLog

PR target/94118
 * doc/extend.texi (x86Operandmodifiers): Document more x86
 operand modifier.
 * gcc/config/i386/i386.c: Add comment for operand modifier N
 and I.

Modified-by: liuhongt 

[Bug target/95078] Missing fwprop for SIB address

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Richard Biener from comment #1)
> TER should go away, not be extended.  So you are suggesting that we replace
> 
> leaq44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
> movl(%rdx), %eax
> movl$3, (%rsi)
> addl(%rdx), %eax
> 
> with
> 
> movl   44(%rdi,%rdx,4), %eax
> movl$3, (%rsi)
> addl   44(%rdi,%rdx,4), %eax
> 
Yes.
> ?  The variant that looks bigger is actually one byte smaller.  Note as
> soon as there are three uses it will be larger again...
> 
> So this is really something for RTL and yeah, fwprop only makes "local"
> decisions.  Note that I think that your proposed variant will consume
> more resources since the complex addressing modes are likely split into
> a separate uop.  Yes, overall I'd expect less latency for your sequence.
Yes, also it will increase register pressure since propagation mostly would
increase live range for base and index reg, it's a subtle optimization, maybe 
a cost model could help, and fwprop should be more "smart" to see the
redundance of adress calculation after propagation.

[Bug target/95023] Offloading AMD GCN wiki cannot be followed

[xw111luoye at gmail dot com]

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

--- Comment #2 from Ye Luo  ---
I got the following error when building the new lib. Tried gcc 8 and 10 with
master and newlib-3.3.0. No difference

/home/yeluo/opt/build-amdgcn-gcc/./gcc/xgcc
-B/home/yeluo/opt/build-amdgcn-gcc/./gcc/ -nostdinc
-B/home/yeluo/opt/build-amdgcn-gcc/amdgcn-amdhsa/gfx900/newlib/ -isystem
/home/yeluo/opt/build-amdgcn-gcc/amdgcn-amdhsa/gfx900/newlib/targ-include
-isystem /home/yeluo/opt/gcc/newlib/libc/include
-B/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/bin/
-B/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/lib/ -isystem
/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/include -isystem
/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/sys-include  -march=gfx900
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"newlib\ 3.3.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libc/stdlib -fno-builtin -D__DYNAMIC_REENT__
-DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI  -g -O2  -march=gfx900 -c -o
lib_a-drand48.o `test -f 'drand48.c' || echo
'../../../../../../gcc/newlib/libc/stdlib/'`drand48.c
/tmp/ccY9rfDl.s:1082:2: error: changed section flags for .rodata.cst8,
expected: 0x12
.section.rodata.cst8
^
/tmp/ccY9rfDl.s:1082:2: /home/yeluo/opt/build-amdgcn-gcc/./gcc/xgcc
-B/home/yeluo/opt/build-amdgcn-gcc/./gcc/ -nostdinc
-B/home/yeluo/opt/build-amdgcn-gcc/amdgcn-amdhsa/gfx900/newlib/ -isystem
/home/yeluo/opt/build-amdgcn-gcc/amdgcn-amdhsa/gfx900/newlib/targ-include
-isystem /home/yeluo/opt/gcc/newlib/libc/include
-B/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/bin/
-B/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/lib/ -isystem
/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/include -isystem
/opt/gcc/gcc-10.1.0/amdgcn-amdhsa/sys-include  -march=gfx900
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.3.0\" -DPACKAGE_STRING=\"newlib\ 3.3.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libc/stdlib -fno-builtin -D__DYNAMIC_REENT__
-DMISSING_SYSCALL_NAMES -DHAVE_INIT_FINI  -g -O2  -march=gfx900 -c -o
lib_a-ecvtbuf.o `test -f 'ecvtbuf.c' || echo
'../../../../../../gcc/newlib/libc/stdlib/'`ecvtbuf.c
error: changed section entsize for .rodata.cst8, expected: 8
.section.rodata.cst8
^
Makefile:980: recipe for target 'lib_a-wcstod.o' failed
make[8]: *** [lib_a-wcstod.o] Error 1
make[8]: *** Waiting for unfinished jobs
/tmp/ccptbvwm.s:4470:2: error: changed section flags for .rodata.cst8,
expected: 0x12
.section.rodata.cst8
^
/tmp/ccptbvwm.s:4470:2: error: changed section entsize for .rodata.cst8,
expected: 8
.section.rodata.cst8
^
/tmp/ccptbvwm.s:4661:2: error: changed section flags for .rodata.cst8,
expected: 0x12
.section.rodata.cst8
^
/tmp/ccptbvwm.s:4661:2: error: changed section entsize for .rodata.cst8,
expected: 8
.section.rodata.cst8
^

[Bug c++/95094] alignof(reference_to_type) doesn't return alignof(referenced_type) as it should by the standard

[sinbal2l at gmail dot com]

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

--- Comment #3 from Inbal Levi  ---
Actually, you are right,
I'm currently working on a paper to change it, should have waited for
afterward.
The reason to change it is to align (...) with C behavior.

[Bug c++/95093] Implement DR 1966, Colon following enumeration elaborated-type-specifier

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Probably related/covered in https://wg21.link/cwg2141 (PR50169).

[Bug debug/95096] Feature request: add -fsplit-dwarf

[i at maskray dot me]

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

--- Comment #1 from Fangrui Song  ---
Created https://sourceware.org/pipermail/gcc-patches/2020-May/545638.html

[Bug debug/95096] New: Feature request: add -fsplit-dwarf

[i at maskray dot me]

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

Bug ID: 95096
   Summary: Feature request: add -fsplit-dwarf
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

-gsplit-dwarf has an undesired property: it sets the debug info level to 2.
When plugged into a build system, this can enable debug info unnecessarily
(when the user does not specify -g or specifies -g0).

-fsplit-dwarf can enable .dwo, but do not enable debug info by itself.

Its reaction with -g1 may need some thoughts: whether line tables in .dwo will
be beneficial. As a start, we can add the option first, which should be simple
(for a beginner like me:/ )

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-12

[Bug c++/95094] alignof(reference_to_type) doesn't return alignof(referenced_type) as it should by the standard

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
But this doesn't seem like a very useful behaviour for the extension.

[Bug c++/95094] alignof(reference_to_type) doesn't return alignof(referenced_type) as it should by the standard

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
alignof with an expression rather than a type is a GNU extension ...

[Bug other/12411] Missed -Wsequence-point on functions (example reduced from historical GCC source)

[rafael at espindo dot la]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

 CC||rafael at espindo dot la

--- Comment #7 from Rafael Avila de Espindola  ---
I think we just hit a case similar to this bug where it would be nice get a
warning.

Given

-
struct foo {
void bar(int);
};
foo get_foo(int);
void g() {
int a = 0;
get_foo(a).bar(a++);
}


GCC will warn about the value of a. If instead of an integer we have an object,
like in


#include 
struct zed {
zed();
zed(const zed&);
zed(zed&&);
};
struct foo {
void bar(zed);
};
foo get_foo(zed);
void g() {
zed a;
get_foo(a).bar(std::move(a));
}


GCC produces no warning.

Let me know if I should report a new bug instead.

[Bug target/95095] New: Feature request: support -fno-unique-section-names

[i at maskray dot me]

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

Bug ID: 95095
   Summary: Feature request: support -fno-unique-section-names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

-ffunction-sections produces sections .text.foo , .text.bar , etc, which can
take significant amount of string table space.

In clang, -fno-unique-section-names emits multiple ".text" sections which can
share the section name. Multiple sections with the same name require the new
GNU as feature https://sourceware.org/bugzilla/show_bug.cgi?id=25380 (binutils
2.35).

For .text.exit.* .text.unlikely.* .text.hot.* .text.startup.* , the preferred
sections are .text.exit. .text.unlikely. .text.hot. .text.startup. The trailing
dots can avoid a linker problem described in https://reviews.llvm.org/D79600

- pasted below for your convenience

GNU ld's internal linker script uses
(https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=add44f8d5c5c05e08b11e033127a744d61c26aee)

.text   :
{
  *(.text.unlikely .text.*_unlikely .text.unlikely.*)
  *(.text.exit .text.exit.*)
  *(.text.startup .text.startup.*)
  *(.text.hot .text.hot.*)
  *(SORT(.text.sorted.*))
  *(.text .stub .text.* .gnu.linkonce.t.*)
  /* .gnu.warning sections are handled specially by elf.em.  */
  *(.gnu.warning)
}
Because *(.text.exit .text.exit.*) is ordered before *(.text .text.*), in a
-ffunction-sections build, the C library function exit will be placed before
other functions.
gold's -z keep-text-section-prefix has the same problem.

In lld, -z keep-text-section-prefix recognizes
.text.{exit,hot,startup,unlikely,unknown}.*, but not
.text.{exit,hot,startup,unlikely,unknown}, to avoid the strange placement
problem.

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

 CC||gcc-bugs at marehr dot 
dialup.fu-b
   ||erlin.de

--- Comment #6 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
It seems that I hit the same issue when making us of ranges:

```c++
#include 
#include 

static_assert(std::input_iterator);

struct alignment_file_input
{
  alignment_file_input(std::filesystem::path);

  template 
  alignment_file_input(stream_t);

  int* begin();
  int* end();
};
static_assert(std::ranges::input_range);

int main()
{
  alignment_file_input fin{int{}};

  auto && view = fin | std::views::take(1);
}
```

https://godbolt.org/z/__hw9w

[Bug c++/95094] New: alignof(reference_to_type) doesn't return alignof(referenced_type) as it ought to, by the standard

[sinbal2l at gmail dot com]

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

Bug ID: 95094
   Summary: alignof(reference_to_type) doesn't return
alignof(referenced_type) as it ought to, by the
standard
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sinbal2l at gmail dot com
  Target Milestone: ---

>From the C++ standard:

7.6.2.5 Alignof [expr.alignof]p3

3 When alignof is applied to a reference type, the result is the alignment of
the *referenced* type.  

IINM, in the latest version, the returned value is of the reference itself:

#include 

int main() {
alignas(32) double d;
double &ref_d = d;

printf("Alignment of d: %d\n", alignof(d)); // 32
printf("Alignment of ref_d: %d\n", alignof(ref_d)); // 8
}

https://godbolt.org/z/S9UJUv

P.S. thank you very much for doing such a great job! (3) (94594)

[Bug preprocessor/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
Fixed 2a0225e4786

[Bug preprocessor/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:2a0225e47868fbfceaecaa5e2de96c1c5a2251ea

commit r11-338-g2a0225e47868fbfceaecaa5e2de96c1c5a2251ea
Author: Nathan Sidwell 
Date:   Tue May 12 13:33:11 2020 -0700

preprocessor: EOF location is at end of file [PR95013]

My recent C++ parser change to pay attention to EOF location uncovered
a separate bug.  The preprocesor's EOF logic would set the EOF
location to be the beginning of the last line of text in the file --
not the 'line' after that, which contains no characters.  Mostly.
This fixes things so that when we attempt to read the last line of the
main file, we don't pop the buffer until the tokenizer has a chance to
create an EOF token with the correct location information.  It is then
responsible for popping the buffer.  As it happens, raw string literal
tokenizing contained a bug -- it would increment the line number
prematurely, because it cached buffer->cur in a local variable, but
checked buffer->cur before updating it to figure out if it was at end
of file.   We fix up that too.

The EOF token intentionally doesn't have a column number -- it's not a
position on a line, it's a non-existant line.

The testsuite churn is just correcting the EOF location diagnostics.

libcpp/
PR preprocessor/95013
* lex.c (lex_raw_string): Process line notes before incrementing.
Correct incrementing condition.  Adjust for new
_cpp_get_fresh_line EOF behaviour.
(_cpp_get_fresh_line): Do not pop buffer at EOF, increment line
instead.
(_cpp_lex_direct): Adjust for new _cpp_get_fresh_line behaviour.
(cpp_directive_only_process): Assert we got a fresh line.
* traditional.c (_cpp_read_logical_line_trad): Adjust for new
_cpp_get_fresh_line behaviour.

gcc/testsuite/
* c-c++-common/goacc/pr79428-1.c: Adjust EOF diagnostic location.
* c-c++-common/gomp/pr79428-2.c: Likewise.
* g++.dg/cpp0x/decltype63.C: Likewise.
* g++.dg/cpp0x/gen-attrs-64.C: Likewise.
* g++.dg/cpp0x/pr68726.C: Likewise.
* g++.dg/cpp0x/pr78341.C: Likewise.
* g++.dg/cpp1y/pr65202.C: Likewise.
* g++.dg/cpp1y/pr65340.C: Likewise.
* g++.dg/cpp1y/pr68578.C: Likewise.
* g++.dg/cpp1z/class-deduction44.C: Likewise.
* g++.dg/diagnostic/unclosed-extern-c.C: Likewise.
* g++.dg/diagnostic/unclosed-function.C: Likewise.
* g++.dg/diagnostic/unclosed-namespace.C: Likewise.
* g++.dg/diagnostic/unclosed-struct.C: Likewise.
* g++.dg/ext/pr84598.C: Likewise.
* g++.dg/other/switch4.C: Likewise.
* g++.dg/parse/attr4.C: Likewise.
* g++.dg/parse/cond4.C: Likewise.
* g++.dg/parse/crash10.C: Likewise.
* g++.dg/parse/crash18.C: Likewise.
* g++.dg/parse/crash27.C: Likewise.
* g++.dg/parse/crash34.C: Likewise.
* g++.dg/parse/crash35.C: Likewise.
* g++.dg/parse/crash52.C: Likewise.
* g++.dg/parse/crash59.C: Likewise.
* g++.dg/parse/crash61.C: Likewise.
* g++.dg/parse/crash67.C: Likewise.
* g++.dg/parse/error14.C: Likewise.
* g++.dg/parse/error56.C: Likewise.
* g++.dg/parse/invalid1.C: Likewise.
* g++.dg/parse/parameter-declaration-1.C: Likewise.
* g++.dg/parse/parser-pr28152-2.C: Likewise.
* g++.dg/parse/parser-pr28152.C: Likewise.
* g++.dg/parse/pr68722.C: Likewise.
* g++.dg/pr46852.C: Likewise.
* g++.dg/pr46868.C: Likewise.
* g++.dg/template/crash115.C: Likewise.
* g++.dg/template/crash43.C: Likewise.
* g++.dg/template/crash90.C: Likewise.
* g++.dg/template/error-recovery1.C: Likewise.
* g++.dg/template/error57.C: Likewise.
* g++.old-deja/g++.other/crash31.C: Likewise.
* gcc.dg/empty-source-2.c: Likewise.
* gcc.dg/empty-source-3.c: Likewise.
* gcc.dg/noncompile/pr30552-3.c: Likewise.
* gcc.dg/noncompile/pr35447-1.c: Likewise.
* gcc.dg/pr20245-1.c: Likewise.
* gcc.dg/pr28419.c: Likewise.
* gcc.dg/rtl/truncated-rtl-file.c: Likewise.
* gcc.dg/unclosed-init.c: Likewise.
* obj-c++.dg/property/property-neg-6.mm: Likewise.
* obj-c++.dg/syntax-error-10.mm: Likewise.
* obj-c++.dg/syntax-error-8.mm: Likewise.
* obj-c++.dg/syntax-error-9.mm: Likewise.

[Bug c++/95074] Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/95074] Function found via ADL when it should not

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:90b160f8ec515f54ddc36519a6aaa60abdabdec1

commit r11-336-g90b160f8ec515f54ddc36519a6aaa60abdabdec1
Author: Marek Polacek 
Date:   Tue May 12 14:56:13 2020 -0400

c++: Function found via ADL when it should not [PR95074]

I noticed that we don't implement [basic.lookup.argdep]/3: quite correctly;
it says "If X (the lookup set produced by unqualified lookup) contains
-- a block-scope function declaration that is not a using-declaration
[...]
then Y (the lookup set produced by ADL) is empty."
but we were still performing ADL in fn1 in the attached test.  The
problem was that we were only looking at the first function in the
overload set which in this case happened to be a using-declaration, and
those don't suppress ADL.  We have to look through the whole set to find
out if unqualified lookup found a block-scope function declaration, or
a member function declaration.

PR c++/95074
* parser.c (cp_parser_postfix_expression) :
When
looking for a block-scope function declaration, look through the
whole
set, not just the first function in the overload set.

* g++.dg/lookup/koenig15.C: New test.

[Bug c++/95036] [9/10/11 Regression] ICE with variadic type/nttp template templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #15 from anlauf at gcc dot gnu.org ---
A possible workaround is to partly revert the offending commit and handle
problematic cases individually.  The original commit intended to handle
two different ICEs with a common invalid code.

Bill, can you try the following patch?  (Note that this needs two adjustments
in the testsuite, but otherwise regtests for me.   I'm not 100%sure if the
PDT part is correct.)

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index dd72f44d377..dd7f5f43930 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1806,7 +1806,7 @@ gfc_multiply (gfc_expr *op1, gfc_expr *op2)
 gfc_expr *
 gfc_divide (gfc_expr *op1, gfc_expr *op2)
 {
-  if (op2 && op2->expr_type == EXPR_CONSTANT)
+  if (0 && op2 && op2->expr_type == EXPR_CONSTANT)
 {
   arith rc = ARITH_OK;
   switch (op2->ts.type)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index d650407da41..6866f460224 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2602,6 +2602,14 @@ variable_decl (int elem)
  gfc_free_expr (e);
}

+ if (not_constant && e->ts.type != BT_INTEGER)
+   {
+ gfc_error ("Explicit array shape at %C must be constant of "
+"INTEGER type and not %s type",
+gfc_basic_typename (e->ts.type));
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
  if (not_constant)
{
  gfc_error ("Explicit shaped array with nonconstant bounds at
%C");
@@ -3736,8 +3744,9 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
   if (kind_expr)
{
  /* Try simplification even for LEN expressions.  */
+ bool ok;
  gfc_resolve_expr (kind_expr);
- gfc_simplify_expr (kind_expr, 1);
+ ok = gfc_simplify_expr (kind_expr, 1);
  /* Variable expressions seem to default to BT_PROCEDURE.
 TODO find out why this is and fix it.  */
  if (kind_expr->ts.type != BT_INTEGER
@@ -3748,6 +3757,12 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
 gfc_basic_typename (kind_expr->ts.type));
  goto error_return;
}
+ if (kind_expr->ts.type == BT_INTEGER && !ok)
+   {
+ gfc_error ("The parameter expression at %C does not "
+"simplify to an INTEGER constant");
+ goto error_return;
+   }

  tail->expr = gfc_copy_expr (kind_expr);
}

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/545
   ||630.html
   Keywords||patch

--- Comment #7 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545630.html

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
It was fixed with r9-300-g1c9ee609dffac3f7.

[Bug c++/95087] [11 Regression] ICE in gimplify_expr, at gimplify.c:14382

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.1.0
   Last reconfirmed||2020-05-12
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
  Known to fail||11.0
 CC||iains at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started to fail with r11-178-gc7100843831147a0.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
@Marek: Would it be possible to fix these issues in C FE?

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Confirmed, this got fixed at some point in the GCC 7 development cycle.  So
let's close the bug.   Thanks for having a look.

[Bug libstdc++/94906] memory corruption in std::pmr::monotonic_buffer_resource

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 9.4 and 10.2

[Bug libstdc++/94906] memory corruption in std::pmr::monotonic_buffer_resource

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:45a6686e76bfcd48f7c72a23d0e15186f76b4bfc

commit r9-8588-g45a6686e76bfcd48f7c72a23d0e15186f76b4bfc
Author: Jonathan Wakely 
Date:   Tue May 12 09:54:44 2020 +0100

libstdc++: Fix incorrect size calculation in PMR resource  (PR 94906)

Calculating the size of a chunk being returned to the upstream allocator
was done with a 32-bit type, so it wrapped if the chunk was 4GB or
larger.

I don't know how to test this without allocating 4GB, so there's no test
in the testsuite. It has been tested manually of course.

Backport from mainline
2020-05-04  Jonathan Wakely  

PR libstdc++/94906
* src/c++17/memory_resource.cc
(monotonic_buffer_resource::_Chunk::release): Use size_t for shift
operands.

[Bug testsuite/95092] new test case gcc.dg/asan/pr95051.c fails

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

[Bug c++/95093] New: Implement DR 1966, Colon following enumeration elaborated-type-specifier

[mpolacek at gcc dot gnu.org]

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

Bug ID: 95093
   Summary: Implement DR 1966, Colon following enumeration
elaborated-type-specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

In C++11

  enum E { };
  void f(bool b)
  {
E e = b ? *new enum E : E{};
  }

should now compile: the colon is not an enum-base, it's part of a ternary
operator.  But we think we're defining a new type here, and reject it.

See http://wg21.link/cwg1966

[Bug tree-optimization/95051] error: invalid RHS for gimple memory store:

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:ac627eb4162d31aa4d009c3c9a8da7dfd6cc34e0

commit r11-335-gac627eb4162d31aa4d009c3c9a8da7dfd6cc34e0
Author: Jakub Jelinek 
Date:   Tue May 12 21:21:30 2020 +0200

testsuite: Fix up gcc.dg/asan/pr95051.c testcase [PR95051]

asan.exp adds -fsanitize=address which is incompatible with
-fsanitize=kernel-address,
so we need to disable it first.

2020-05-12  Jakub Jelinek  

PR sanitizer/95051
* gcc.dg/asan/pr95051.c: Add -fno-sanitize=all to dg-options.

[Bug debug/95080] [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl  ---
On Tue, May 12, 2020 at 06:43:54PM +, seurer at linux dot vnet.ibm.com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
> 
> --- Comment #13 from Bill Seurer  ---
> I don't know fortran and this appears to be part of a multi-thousand line
> extremely complex function.
> 

There is only a single division in that line of code.
Can you determine what the value of cldeps is?  The
error message suggests that it is 0.  If there is a
testcase that you can run, then change the code to

if (cldeps == 0) then
   print *, 'Whoops.  cldeps = ', cldeps
   stop 1
else
   asort(nxs) = 1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
end if

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[seurer at linux dot vnet.ibm.com]

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

--- Comment #13 from Bill Seurer  ---
I don't know fortran and this appears to be part of a multi-thousand line
extremely complex function.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Ah good point.

struct A {
  void operator delete(void*) = delete;
  void operator delete[](void*) = delete;
};

A* f();
A* f2();

using type1 = decltype(delete f());
using type2 = decltype(delete[] f2());

This fails as expected.

Comment 2 is not a bug then, but comment 1 and comment 3 still seem like bugs.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka  ---
(In reply to Jonathan Wakely from comment #1)
> Probably the same issue:
> 
> struct A {
>   void operator delete(void*) = delete;
>   void operator delete[](void*) = delete;
> };
> 
> using type1 = decltype(delete (A*)0);
> using type2 = decltype(delete[] (A*)0);
> 
> Neither of these invalid delete expressions gives an error.

Hmm, according to [expr.delete]/7.3 (https://eel.is/c++draft/expr.delete#7.3):

If the value of the operand of the delete-expression is a
null pointer value, it is unspecified whether a deallocation
function will be called as described above.

So I suppose we're not wrong to accept the above delete expressions?

If we use a non-zero pointer constant instead, then we do give an error for
this testcase:

79706-2.C:6:35: error: use of deleted function ‘static void A::operator
delete(void*)’
6 | using type1 = decltype(delete (A*)16);
  |   ^~
79706-2.C:2:8: note: declared here
2 |   void operator delete(void*) = delete;
  |^~~~
79706-2.C:7:37: error: use of deleted function ‘static void A::operator delete
[](void*)’
7 | using type2 = decltype(delete[] (A*)16);
  | ^~
79706-2.C:3:8: note: declared here
3 |   void operator delete[](void*) = delete;
  |^~~~

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Fixed on master branch so far.

[Bug bootstrap/94998] GCC 10 won't configure for host=x86, build!=host, linker=bfd due to CET

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:d17cdc17c90ce77cb90c569322c1f241d3530cec

commit r11-333-gd17cdc17c90ce77cb90c569322c1f241d3530cec
Author: H.J. Lu 
Date:   Tue May 12 10:39:42 2020 -0700

Enable CET in cross compiler if possible

Don't perform CET run-time check for host when cross compiling.  Instead,
enable CET in cross compiler if possible so that it will run on both CET
and non-CET hosts.

config/

PR bootstrap/94998
* cet.m4 (GCC_CET_HOST_FLAGS): Enable CET in cross compiler if
possible.

libiberty/

PR bootstrap/94998
* configure: Regenerated.

lto-plugin/

PR bootstrap/94998
* configure: Regenerated.

[Bug c++/79706] invalid delete[] expression doesn't cause substitution failure

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #11)
> /home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o
> module_ra_cam.fppized.o -I. -I./netcdf/include -I./inc -m64 -O0 -g3
> -mcpu=power8 -Wno-deprecated-declarations -fconvert=big-endian -std=legacy
> module_ra_cam.fppized.f90
> module_ra_cam.fppized.f90:6806:69:
> 
>  6806 |asort(nxs) =
> 1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
>   | 1
> Error: Division by zero at (1)
> 
> This error was also triggered by r11-205 but was not fixed by the patch.  It
> compiles cleanly with r11-204 and earlier.  I do not think (though cannot
> say for sure) that it really is a divide by zero.
> 
> This is part of 521.wrf_r in the spec2017 test suite

I don't have access to spec.

Can you provide enough context for a reproducer?

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:8a6790fb4e5090624fbd71e2b895e6bdd5319fd7

commit r11-332-g8a6790fb4e5090624fbd71e2b895e6bdd5319fd7
Author: Uros Bizjak 
Date:   Tue May 12 19:24:53 2020 +0200

i386: Add V2SFmode copysign, xorsign and signbit expanders [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (copysignv2sf3): New expander.
(xorsignv2sf3): Ditto.
(signbitv2sf3): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-4.c: New test.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[seurer at linux dot vnet.ibm.com]

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

--- Comment #11 from Bill Seurer  ---
/home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o
module_ra_cam.fppized.o -I. -I./netcdf/include -I./inc -m64 -O0 -g3
-mcpu=power8 -Wno-deprecated-declarations -fconvert=big-endian -std=legacy
module_ra_cam.fppized.f90
module_ra_cam.fppized.f90:6806:69:

 6806 |asort(nxs) =
1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
  | 1
Error: Division by zero at (1)

This error was also triggered by r11-205 but was not fixed by the patch.  It
compiles cleanly with r11-204 and earlier.  I do not think (though cannot say
for sure) that it really is a divide by zero.

This is part of 521.wrf_r in the spec2017 test suite

[Bug testsuite/95092] New: new test case gcc.dg/asan/pr95051.c fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95092
   Summary: new test case gcc.dg/asan/pr95051.c fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/asan/pr95051.c
-fsanitize=address -g
-I/home/seurer/gcc/git/gcc-test2/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  -fsanitize=kernel-address
--param=asan-stack=1 -O2 -S -o pr95051.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/asan/pr95051.c
-fsanitize=address -g
-I/home/seurer/gcc/git/gcc-test2/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects -fsanitize=kernel-address
--param=asan-stack=1 -O2 -S -o pr95051.s
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'
compiler exited with status 1
FAIL: gcc.dg/asan/pr95051.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
Excess errors:
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94454

--- Comment #11 from Patrick Palka  ---
I posted a patch to enable sanitization for the spec_hasher tables for GCC 11
here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545525.html

With current trunk I wasn't able to reproduce any sanitization errors in the
testsuite or in other libraries even with a debugging patch similar to Martin's
(on x86_64-pc-linux-gnu).  I suspect they have been fixed by the patches for
PR94454.

[Bug debug/95080] [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a 
Given that, most likely latent before.

[Bug fortran/95091] New: ICE in gfc_hash_value, at fortran/class.c:538

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

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

Bug ID: 95091
   Summary: ICE in gfc_hash_value, at fortran/class.c:538
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

A more complex example, switches between 44 (ok) and 45 (ICE) :
(backtrace varies with release and name length)


$ cat z1_44.f90
module m2345678901234567890123456789012345678901234
  type t2345678901234567890123456789012345678901234
  end type
  interface
module subroutine s2345678901234567890123456789012345678901234 &
  (x2345678901234567890123456789012345678901234)
end
  end interface
end
submodule(m2345678901234567890123456789012345678901234) &
  n2345678901234567890123456789012345678901234
  type, extends(t2345678901234567890123456789012345678901234) :: &
u2345678901234567890123456789012345678901234
  end type
end


$ cat z1_45.f90
module m23456789012345678901234567890123456789012345
  type t23456789012345678901234567890123456789012345
  end type
  interface
module subroutine s23456789012345678901234567890123456789012345 &
  (x23456789012345678901234567890123456789012345)
end
  end interface
end
submodule(m23456789012345678901234567890123456789012345) &
  n23456789012345678901234567890123456789012345
  type, extends(t23456789012345678901234567890123456789012345) :: &
u23456789012345678901234567890123456789012345
  end type
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
  type t23456789012345678901234567890123456789012345678901234567890123
  end type
  interface
module subroutine
s23456789012345678901234567890123456789012345678901234567890123 &
  (x23456789012345678901234567890123456789012345678901234567890123)
end
  end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890123) &
  n23456789012345678901234567890123456789012345678901234567890123
  type,
extends(t23456789012345678901234567890123456789012345678901234567890123) :: &
u23456789012345678901234567890123456789012345678901234567890123
  end type
end


$ gfortran-11-20200510 -c z1_44.f90
$
$ gfortran-11-20200510 -c z1_45.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x64003a gfc_match_function_decl()
../../gcc/fortran/decl.c:7355
gfortran: internal compiler error: Segmentation fault signal terminated program
f951


$ gfortran-11-20200510 -c z1_63.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x62c64c gfc_hash_value(gfc_symbol*)
../../gcc/fortran/class.c:538
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/95090] New: ICE: identifier overflow: 129

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

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

Bug ID: 95090
   Summary: ICE: identifier overflow: 129
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Switches between name length 54 (ok) and 55 (ICE) :


$ cat z1_54.f90
module m23456789012345678901234567890123456789012345678901234
   type t23456789012345678901234567890123456789012345678901234 &
  (n23456789012345678901234567890123456789012345678901234)
  integer, len :: n23456789012345678901234567890123456789012345678901234 =
8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234
   integer :: b23456789012345678901234567890123456789012345678901234(3)[*]
   data b23456789012345678901234567890123456789012345678901234 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234
  type(t23456789012345678901234567890123456789012345678901234 &
 (n23456789012345678901234567890123456789012345678901234)) :: &
 z23456789012345678901234567890123456789012345678901234
   end
end


$ cat z1_55.f90
module m234567890123456789012345678901234567890123456789012345
   type t234567890123456789012345678901234567890123456789012345 &
  (n234567890123456789012345678901234567890123456789012345)
  integer, len :: n234567890123456789012345678901234567890123456789012345 =
8
   end type
   integer :: a234567890123456789012345678901234567890123456789012345
   integer :: b234567890123456789012345678901234567890123456789012345(3)[*]
   data b234567890123456789012345678901234567890123456789012345 /1,2,3/
contains
   subroutine s234567890123456789012345678901234567890123456789012345
  type(t234567890123456789012345678901234567890123456789012345 &
 (n234567890123456789012345678901234567890123456789012345)) :: &
 z234567890123456789012345678901234567890123456789012345
   end
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, len ::
n23456789012345678901234567890123456789012345678901234567890123 = 8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234567890123
   integer ::
b23456789012345678901234567890123456789012345678901234567890123(3)[*]
   data b23456789012345678901234567890123456789012345678901234567890123 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123 &
 (n23456789012345678901234567890123456789012345678901234567890123)) ::
&
 z23456789012345678901234567890123456789012345678901234567890123
   end
end


$ cat z1_63_clean.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, len ::
n23456789012345678901234567890123456789012345678901234567890123 = 8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234567890123
   integer ::
b23456789012345678901234567890123456789012345678901234567890123(3)[*]
   data b23456789012345678901234567890123456789012345678901234567890123 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123 &
 (3)) :: &
 z23456789012345678901234567890123456789012345678901234567890123
   end
end


$ gfortran-11-20200510 -c z1_54.f90 -fcoarray=lib
$ gfortran-11-20200510 -c z1_55.f90 -fcoarray=single
$
$ gfortran-11-20200510 -c z1_55.f90 -fcoarray=lib
f951: internal compiler error: identifier overflow: 129
0x64db59 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x64f27a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x676b1f gfc_get_string(char const*, ...)
../../gcc/fortran/iresolve.c:69
0x71bb8a gfc_build_qualified_array
../../gcc/fortran/trans-decl.c:994
0x720d24 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1793
0x723b58 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5297
0x6e2f72 do_traverse_symtree
../../gcc/fortran/symbol.c:4147
0x72435b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5796
0x6fed94 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6abd11 translate_all_program_units
../../gcc/fortran/parse.c:6293
0x6abd11 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/95089] New: ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

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

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

Bug ID: 95089
   Summary: ICE in gfc_get_derived_type, at
fortran/trans-types.c:2843
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Switches between 57 (ok) and 58 (ICE) :


$ cat z1_57.f90
module m23456789012345678901234567890123456789012345678901234567
   type t23456789012345678901234567890123456789012345678901234567
  type(t23456789012345678901234567890123456789012345678901234567), &
  pointer :: z23456789012345678901234567890123456789012345678901234567
   end type
end


$ cat z1_58.f90
module m234567890123456789012345678901234567890123456789012345678
   type t234567890123456789012345678901234567890123456789012345678
  type(t234567890123456789012345678901234567890123456789012345678), &
  pointer :: z234567890123456789012345678901234567890123456789012345678
   end type
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123), &
  pointer ::
z23456789012345678901234567890123456789012345678901234567890123
   end type
end


$ gfortran-11-20200510 -c z1_57.f90 -fcoarray=lib
$ gfortran-11-20200510 -c z1_58.f90 -fcoarray=single
$
$ gfortran-11-20200510 -c z1_58.f90 -fcoarray=lib
f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2843
0x77bbf6 gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2843
0x77bee8 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1166
0x77c13e gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2247
0x7208fe gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1767
0x723b58 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5297
0x6e2f72 do_traverse_symtree
../../gcc/fortran/symbol.c:4147
0x72435b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5796
0x6fed94 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6abd11 translate_all_program_units
../../gcc/fortran/parse.c:6293
0x6abd11 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |10.0

--- Comment #5 from Patrick Palka  ---
Looks like this PR is completely fixed for GCC 10/11 since the concepts-cxx2a
merge.

[Bug c++/67491] [meta-bug] concepts issues

[ppalka at gcc dot gnu.org]

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

Bug 78752 Summary: [concepts] ICE with constrained variadic member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752

   What|Removed |Added

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

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:955b1f929906cabc5b17c40cbc7d767eebd64cc7

commit r11-331-g955b1f929906cabc5b17c40cbc7d767eebd64cc7
Author: Uros Bizjak 
Date:   Tue May 12 18:36:27 2020 +0200

i386: Add V2SFmode FMA insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (fmav2sf4): New insn pattern.
(fmsv2sf4): Ditto.
(fnmav2sf4): Ditto.
(fnmsv2sf4): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-3.c: New test.

[Bug fortran/95088] New: ICE in gfc_build_class_symbol, at fortran/class.c:653

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

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

Bug ID: 95088
   Summary: ICE in gfc_build_class_symbol, at fortran/class.c:653
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

The search for internal restrictions of names has brought to light 
a few critical cases, in the following case the change occurs between 
61 (ok) and 62 (ICE) :


$ cat z1_61.f90
module m234567890123456789012345678901234567890123456789012345678901
   type t234567890123456789012345678901234567890123456789012345678901 &
  (n234567890123456789012345678901234567890123456789012345678901)
  integer, kind ::
n234567890123456789012345678901234567890123456789012345678901
   end type
   type, extends
(t234567890123456789012345678901234567890123456789012345678901) :: &
  a234567890123456789012345678901234567890123456789012345678901
   end type
   interface
  module subroutine
s234567890123456789012345678901234567890123456789012345678901 &
 (x234567890123456789012345678901234567890123456789012345678901)

class(a234567890123456789012345678901234567890123456789012345678901(8)) :: &
x234567890123456789012345678901234567890123456789012345678901
  end
   end interface
end


$ cat z1_62.f90
module m2345678901234567890123456789012345678901234567890123456789012
   type t2345678901234567890123456789012345678901234567890123456789012 &
  (n2345678901234567890123456789012345678901234567890123456789012)
  integer, kind ::
n2345678901234567890123456789012345678901234567890123456789012
   end type
   type, extends
(t2345678901234567890123456789012345678901234567890123456789012) :: &
  a2345678901234567890123456789012345678901234567890123456789012
   end type
   interface
  module subroutine
s2345678901234567890123456789012345678901234567890123456789012 &
 (x2345678901234567890123456789012345678901234567890123456789012)

class(a2345678901234567890123456789012345678901234567890123456789012(8)) :: &
x2345678901234567890123456789012345678901234567890123456789012
  end
   end interface
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, kind ::
n23456789012345678901234567890123456789012345678901234567890123
   end type
   type, extends
(t23456789012345678901234567890123456789012345678901234567890123) :: &
  a23456789012345678901234567890123456789012345678901234567890123
   end type
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890123 &
 (x23456789012345678901234567890123456789012345678901234567890123)

class(a23456789012345678901234567890123456789012345678901234567890123(8)) :: &
x23456789012345678901234567890123456789012345678901234567890123
  end
   end interface
end


$ gfortran-11-20200510 -c z1_61.f90
$
$ gfortran-11-20200510 -c z1_62.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x62fcb8 gfc_build_class_symbol(gfc_typespec*, symbol_attribute*,
gfc_array_spec**)
../../gcc/fortran/class.c:653
0x6365ac build_sym
../../gcc/fortran/decl.c:1746
0x640e09 variable_decl
../../gcc/fortran/decl.c:2780
0x640e09 gfc_match_data_decl()
../../gcc/fortran/decl.c:6170
0x6a4533 match_word
../../gcc/fortran/parse.c:65
0x6a4533 decode_statement
../../gcc/fortran/parse.c:376
0x6a5f7a next_free
../../gcc/fortran/parse.c:1279
0x6a5f7a next_statement
../../gcc/fortran/parse.c:1511
0x6a8324 parse_spec
../../gcc/fortran/parse.c:3738
0x6a7cce parse_interface
../../gcc/fortran/parse.c:3601
0x6a7cce parse_spec
../../gcc/fortran/parse.c:3875
0x6ab59e parse_module
../../gcc/fortran/parse.c:6115
0x6ab8e7 gfc_parse_file()
../../gcc/fortran/parse.c:6428
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:fa31a3cdbf1571286671d8d3a83e31676862583e

commit r11-330-gfa31a3cdbf1571286671d8d3a83e31676862583e
Author: Patrick Palka 
Date:   Tue May 12 12:20:55 2020 -0400

c++: Add abbreviated fn template test for [PR78752]

This adds an abbreviated function template version of the testcase in
PR78752, which seems to already be fixed.

gcc/testsuite/ChangeLog:

PR c++/78752
* g++.dg/cpp2a/concepts-pr78752-2.C: New test.

[Bug c++/86142] hard error for bad delete-expression in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Looks ever since r10-2197, GCC 10 correctly performs SFINAE for the first two
overloaded calls.

But could you explain why

  int z = f();

should resolve to the second overload of f?

My understanding is that 'delete' on a pointer to void is undefined behavior,
but is not ill-formed, so there is no substitution failure and we should select
the first overload.

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Both testcases are accepted by gcc 8 and newer.

[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I believe this PR can be finally closed.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:2a2dea6b63ae600eb1d084c06d8a3ba42c66dd6b

commit r11-323-g2a2dea6b63ae600eb1d084c06d8a3ba42c66dd6b
Author: Uros Bizjak 
Date:   Tue May 12 17:08:03 2020 +0200

i386: Add V2SFmode NEG, ABS and logic insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (v2sf2): New insn pattern.
(*mmx_v2sf2): New insn_and_split pattern.
(*mmx_nabsv2sf2): Ditto.
(*mmx_andnotv2sf3): New insn pattern.
(*mmx_v2sf3): Ditto.
* config/i386/i386.md (absneg_op): New code attribute.
* config/i386/i386.c (ix86_build_const_vector): Handle V2SFmode.
(ix86_build_signbit_mask): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-2.c: New test.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:6416f67273aaeafd6ad89c2c82076dabb50f8dbe

commit r11-322-g6416f67273aaeafd6ad89c2c82076dabb50f8dbe
Author: Uros Bizjak 
Date:   Tue May 12 17:06:13 2020 +0200

i386: Add V2SFmode NEG, ABS and logic insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (v2sf2): New insn pattern.
(*mmx_v2sf2): New insn_and_split pattern.
(*mmx_nabsv2sf2): Ditto.
(*mmx_andnotv2sf3): New insn pattern.
(*mmx_v2sf3): Ditto.
* config/i386/i386.md (absneg_op): New code attribute.
* config/i386/i386.c (ix86_build_const_vector): Handle V2SFmode.
(ix86_build_signbit_mask): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-2.c: New test.

[Bug c++/95087] New: [11 Regression] ICE in gimplify_expr, at gimplify.c:14382

[asolokha at gmx dot com]

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

Bug ID: 95087
   Summary: [11 Regression] ICE in gimplify_expr, at
gimplify.c:14382
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200510 snapshot (g:13a46321516e2efd3bbb1f1899c539c6724240a9)
ICEs when compiling
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C w/
-fcoroutines:

% g++-11.0.0 -fcoroutines -c
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C: In function
'Coro bar()':
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C:37:1: error: a
'return' statement is not allowed in coroutine; did you mean 'co_return'?
   37 | bar () // { dg-error {a 'return' statement is not allowed} }
  | ^~~
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C:42:5: internal
compiler error: in gimplify_expr, at gimplify.c:14382
   42 | co_return;
  | ^
0x700e91 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14382
0xd5871b gimplify_cleanup_point_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd3f9c5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:13977
0xd42c46 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd5549a gimplify_cond_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:4256
0xd3f9e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:13542
0xd57c8b gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd57c8b gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14834
0xd580fd gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14988
0xb96967 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:670
0xb99587 analyze_functions
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:1227
0xb9a152 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:2971

[Bug c++/95074] Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/95081] Copyright infringement by ROS2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Parameter names are not copyrightable. If you want to define a class with the
same API as std::vector then of course you're going to use the same names for
the member functions.

The only thing copyrightable in there are the comments. I suggest you bring
this up with the ROS2 project, or the Free Software Foundation. There's no GCC
bug here.

See https://www.gnu.org/licenses/gpl-violation.en.html

[Bug c++/95085] diagnostic on designated-initializer from braced-init-list could be better

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2020-05-12

--- Comment #1 from Jonathan Wakely  ---
There is a related problem without designated initializers:

struct A { A(int); };
int f(A);
int i = f(A(nullptr));
int j = f(A{nullptr});

d.cc:3:20: error: no matching function for call to 'A::A(std::nullptr_t)'
...
d.cc:4:20: error: no matching function for call to 'A::A()'
...

It also seems inconsistent to say "initializer list argument" in one place and 
"" in another, although maybe the latter is
because it's inside a quoted C++ expression, not prose.

[Bug c++/95069] Capture by reference cannot use list-initalization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Reduced:

int i;
auto ok = [&x = i] {};
auto err = [&x{i}] {};

l.cc:3:17: error: cannot capture '{i}' by reference
3 | auto err = [&x{i}] {};
  | ^

[Bug c++/95069] Capture by reference cannot use list-initalization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nico at josuttis dot de

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

[Bug c++/95086] brace initialization in captures doesn't work with function calls

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I got impatient and reported it for you yesterday :-)

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

[Bug c++/95086] New: brace initialization in captures doesn't work with function calls

[nico at josuttis dot de]

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

Bug ID: 95086
   Summary: brace initialization in captures doesn't work with
function calls
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

AFAIK, since C++17 we should be able to do:

 [&coll{std::as_const(vec)}] {}

but it doesn't compile:
 prog.cc: In function 'int main()':
 prog.cc:10:44: error:
   cannot capture '{std::as_const >(vec)}' by reference
10 |   [&coll{std::as_const(vec)}] {  // ERROR???
   |^

However, both using = for the initialization:
 [&coll = std::as_const(vec)] {
and for simple initializations using braces:
 [max{42}] {
work fine.

Other compilers do it as I expect.
It seems to be a problem when reference captures are initialized by function
calls (or other expressions).

See
 https://wandbox.org/permlink/LMSfQ1nLszVHQ4LF

[Bug c++/95085] New: diagnostic on designated-initializer from braced-init-list could be better

[barry.revzin at gmail dot com]

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

Bug ID: 95085
   Summary: diagnostic on designated-initializer from
braced-init-list could be better
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

In this program (note the typo in the call to f):

struct A {
int width, height;
};

void f(A);
void g() {
f(A{.width=1, .hieght=2});
}

gcc's diagnostic is absolutely excellent:

:7:20: error: field designator 'hieght' does not refer to any field in
type 'A'; did you mean 'height'?
f(A{.width=1, .hieght=2});
   ^~
   height
:2:16: note: 'height' declared here
int width, height;
   ^

However, if instead of calling f(A{...}) we instead just call f({...}) (as is
common to do if the type name is meaningless and is just used as a proxy for
named function arguments):

struct A {
int width, height;
};

void f(A);
void g() {
f({.width=1, .hieght=2});
}

then we get a much worse diagnostic:

:7:5: error: no matching function for call to 'f'
f({.width=1, .hieght=2});
^
:5:6: note: candidate function not viable: cannot convert initializer
list argument to 'A'
void f(A);
 ^

Basically just: "error". Would it be possible to get the same quality of
diagnostic from the named call case as it is in the just-a-braced-init-list
case?

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 12 May 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
> 
> --- Comment #4 from H.J. Lu  ---
> The problem is since df_lr_bb_local_compute has
> 
>/* If the def is to only part of the reg, it does
>not kill the other defs that reach here.  */
> if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
>   {
> unsigned int dregno = DF_REF_REGNO (def);
> bitmap_set_bit (&bb_info->def, dregno);
> bitmap_clear_bit (&bb_info->use, dregno);
>   }
> 
> it doesn't consider
> 
> (insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
> (subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
>  (nil))
> 
> as a def.

Which it isn't since it sets the upper half of reg:DI 85 only.

[Bug tree-optimization/95084] New: code sinking prevents if-conversion

[rguenth at gcc dot gnu.org]

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

Bug ID: 95084
   Summary: code sinking prevents if-conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

There's a pass ordering issue between the sink pass and tree-if-conv, if
conversion for vectorization.  When sink sinks a possibly trapping operation
to a place that is only conditionally executed if-conversion fails which
results in failed vectorization.  This can be seen with
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545588.html applied
for gcc.dg/vect/pr56541.c (and it's ifcvt counterpart
gcc.dg/tree-ssa/ifc-pr56541.c).  But I've also seen this in other context.

Here

  iftmp.2_17 = rR_19 < rL_20 ? rR_19 : rL_20;
  iftmp.3_3 = rR_19 < rL_20 ? rL_20 : rR_19;
  if (iftmp.3_3 > 0.0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.4_14 = PHI 
  if (iftmp.4_14 > 0.0)

becomes

  iftmp.3_3 = rR_17 < rL_18 ? rL_18 : rR_17;
  if (iftmp.3_3 > 0.0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 435831803]:
  goto ; [100.00%]

   [local count: 627172605]:
  iftmp.2_15 = rR_17 < rL_18 ? rR_17 : rL_18;
  if (iftmp.2_15 > 0.0)

and the now conditionally executed FP comparison can trap.

[Bug target/95083] x86 fp_movcc expansion depends on real_cst sharing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|10.0|11.0
   Keywords||missed-optimization
 CC||uros at gcc dot gnu.org
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
Needs https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545588.html to
reproduce.

[Bug target/95083] New: x86 fp_movcc expansion depends on real_cst sharing

[rguenth at gcc dot gnu.org]

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

Bug ID: 95083
   Summary: x86 fp_movcc expansion depends on real_cst sharing
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see gcc.target/i386/avxfp-1.c FAILing, which is

double x;
void
t()
{
  x=x>5?x:5;
}

double x;
void
q()
{
  x=x<5?x:5;
}

and q() recognized as FP min by ix86_expand_fp_movcc because the doesn't
pass prepare_cmp_insn () and later ifcvt matches up the originally
distinct pseudos for the two mentions of '5'.  For t() prepare_cmp_insn ()
succeeeds and ix86_expand_fp_movcc expands this to a UNSPEC_BLEND
(because the two mentions of '5' get a different pseudo so this doesn't
look like a max).  The first prepare_cmp_insn fails because it is fed

(lt (reg:DF 82 [ x.3_1 ])
(const_double:DF 5.0e+0 [0x0.ap+3]))

and appearantly we cannot do a lt compare(?) (but later during ifcvt we can).

Note the above is when expanding from a COND_EXPR, thus

t ()
{
  double x.1_1;
  double iftmp.0_3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  x.1_1 = x;
  iftmp.0_3 = x.1_1 > 5.0e+0 ? x.1_1 : 5.0e+0;
  x = iftmp.0_3;
  return;

and

q ()
{
  double x.3_1;
  double iftmp.2_3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  x.3_1 = x;
  iftmp.2_3 = x.3_1 < 5.0e+0 ? x.3_1 : 5.0e+0;
  x = iftmp.2_3;
  return;

similar FAILs occur for

FAIL: gcc.target/i386/avxfp-1.c scan-assembler vmaxsd
FAIL: gcc.target/i386/avxfp-2.c scan-assembler vminsd
FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd

So what's missing is simplification of 

Trying 8 -> 9:
8: r87:DF=r85:DF

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
STV generates:

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
83 ec 08sub$0x8,%esp
f3 0f 7e 00 movq   (%eax),%xmm0
a1 00 00 00 00  mov0x0,%eax R_386_32c
66 0f 6f c8 movdqa %xmm0,%xmm1
66 0f 7e 44 24 10   movd   %xmm0,0x10(%esp)
66 0f 73 d1 20  psrlq  $0x20,%xmm1
66 0f d6 00 movq   %xmm0,(%eax)
66 0f 7e 4c 24 14   movd   %xmm1,0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
e8 fc ff ff ff  callR_386_PC32  e

instead of

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
8b 0d 00 00 00 00   mov0x0,%ecx R_386_32c
83 ec 08sub$0x8,%esp
8b 50 04mov0x4(%eax),%edx
8b 00   mov(%eax),%eax
89 51 04mov%edx,0x4(%ecx)
89 01   mov%eax,(%ecx)
52  push   %edx
50  push   %eax
e8 fc ff ff ff  callR_386_PC32  e

It is hard to tell if vector is faster.

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-12
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 CC||segher at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
Confirmed.

[Bug target/95082] New: LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[wschmidt at gcc dot gnu.org]

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

Bug ID: 95082
   Summary: LE implementations of vec_cnttz_lsbb and
vec_cntlz_lsbb are wrong
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

For little endian, we need to swap vctzlsbb and vclzlsbb, but today we generate
the BE instruction in all cases.

[Bug target/95076] Failure to tail-call on function call of different return type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, I believe it is safe in this case, but we would need the info whether the
conversion is ok or not already during the tailc pass and on many targets such
a conversion is not ok (e.g. if the target says that the value is zero-extended
into 64-bits or sign-extended, or 32-bit and 64-bit returned in different
register, whatever).
The question is if the existing target hooks are sufficient to query this or if
we need a new target hook.

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
This ia32 psABI return value discussion also applies here:

https://groups.google.com/forum/#!searchin/ia32-abi/return$20value%7Csort:date/ia32-abi/9H4BBrIdkmk/sjWw06ZPnS4J

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> GCC doesn't tail-call because the return types are not compatible.  With a
> call
> it cannot optimize the stack adjustment because of the ABI.
> 
> Note I'm not sure whether the ABI allows %rax to contain "garbage" in the
> upper half for a function returning in %eax.  So what LLVM does may be wrong.

Don't upper bits of %rax in GCC generate code also contain garbage?

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 CC||crazylht at gmail dot com
 Ever confirmed|0   |1

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
The problem is since df_lr_bb_local_compute has

   /* If the def is to only part of the reg, it does
   not kill the other defs that reach here.  */
if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
  {
unsigned int dregno = DF_REF_REGNO (def);
bitmap_set_bit (&bb_info->def, dregno);
bitmap_clear_bit (&bb_info->use, dregno);
  }

it doesn't consider

(insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
(subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
 (nil))

as a def.

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-12

--- Comment #6 from Richard Biener  ---
OK, so for non 7 BE we end up not vectorizing because it doesn't look
profitable
which IMHO is good.  It would be nice to also see dumps before the respective
rev. because in theory (well...) the cost computation should be the same.
Ah!  OK, so we now have

0x10002001470 _1 1 times vec_construct costs 2 in prologue
0x10002001470 _1 1 times vec_construct costs 2 in prologue
0x10002001470 _1 2 times vector_store costs 2 in body
0x10001ecfcc0 _1 1 times scalar_store costs 1 in body
0x10001ecfcc0 _2 1 times scalar_store costs 1 in body
0x10001ecfcc0 _3 1 times scalar_store costs 1 in body
0x10001ecfcc0 _4 1 times scalar_store costs 1 in body

that is, the SLP graph has the expected cost.  Originally we likely
had costed against 4 scalar stores and 4 scalar loads (but the scalar
loads will still be there).  On x86_64 we get

0x3975280 _1 1 times vec_construct costs 8 in prologue
0x3975280 _1 1 times vec_construct costs 8 in prologue
0x3975280 _1 2 times vector_store costs 24 in body
0x3942cb0 _1 1 times scalar_store costs 12 in body
0x3942cb0 _2 1 times scalar_store costs 12 in body
0x3942cb0 _3 1 times scalar_store costs 12 in body
0x3942cb0 _4 1 times scalar_store costs 12 in body

so it's still profitable there.

Note I suggest to leave the FAILs in place for now since in my dev tree
I see the vec_construct gone again so it would start passing again
on ppc as well.

Sorry for the intermediate breakage.

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenth at gcc dot gnu.org]

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

Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c 
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:119a7db1e05c9741803b3ff93266b00fd535732a

commit r11-320-g119a7db1e05c9741803b3ff93266b00fd535732a
Author: Richard Biener 
Date:   Tue May 12 14:13:32 2020 +0200

middle-end/94988 fix testcase for big-endian

The testcase only works for little-endian, mark it so.

2020-05-12  Richard Biener  

PR middle-end/94988
* gcc.dg/torture/pr94988.c: Disable runtime test for
* non-little-endian.

[Bug target/95032] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-187-g98329e3f5b85acc50d

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
(It currently enables p10 insns, but it leaves p9 insns disabled (and any
older insns your compiler doesn't default to as well)).