[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-linux-gnueabihf
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-05-14

--- Comment #1 from Richard Biener  ---
You seem to build from inside the source directory, that is not supported. 
Please create a separate object directory like

mkdir obj
cd obj
../configure 

and re-try.

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

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

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

--- Comment #2 from Andreas Schwab  ---
$ CFLAGS_FOR_TARGET="${-march=armv7-a -mhard-float}"
bash: ${-march=armv7-a -mhard-float}: bad substitution

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:42ef8a5e662a765dc794a7a5c0227bcd83556e44

commit r11-379-g42ef8a5e662a765dc794a7a5c0227bcd83556e44
Author: Uros Bizjak 
Date:   Thu May 14 09:15:23 2020 +0200

i386: Add V2SFmode conversion functions [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (mmx_fix_truncv2sfv2si2): rename from
mmx_pf2id.
Add SSE/AVX alternative.  Change operand predicates from
nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.
(fix_truncv2sfv2si2): New expander.
(fixuns_truncv2sfv2si2): Ditto.

(mmx_floatv2siv2sf2): rename from mmx_floatv2si2.
Add SSE/AVX alternative.  Change operand predicates from
nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.
(floatv2siv2sf2): New expander.
(floatunsv2siv2sf2): Ditto.

* config/i386/i386-builtin.def (IX86_BUILTIN_PF2ID):
Update for rename.
(IX86_BUILTIN_PI2FD): Ditto.

testsuite/ChangeLog:

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

[Bug fortran/95107] [10/11 Regression] ICE in hash_operand, at fold-const.c:3768

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I see a Fortran FE ICE since at least 4.8.0:

$ gcc pr95107.f90 -O2 -c -fno-automatic
pr95107.f90:9:0:

9 |associate (y => x%b)
  | 
internal compiler error: tree check: expected array_type, have record_type in
gfc_conv_array_initializer, at fortran/trans-array.c:6057
0x765fb0 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9686
0x607cf7 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3296
0x607cf7 gfc_conv_array_initializer(tree_node*, gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/trans-array.c:6055
0x9798aa gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
/home/marxin/Programming/gcc/gcc/fortran/trans-expr.c:7665
0x95fe19 gfc_get_symbol_decl(gfc_symbol*)
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.c:1895
0x962ba7 generate_local_decl
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.c:5906
0x91e282 do_traverse_symtree
/home/marxin/Programming/gcc/gcc/fortran/symbol.c:4147
0x959274 generate_local_vars
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.c:6112
0x959274 gfc_process_block_locals(gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.c:7123
0x9b9eca gfc_trans_block_construct(gfc_code*)
/home/marxin/Programming/gcc/gcc/fortran/trans-stmt.c:2267
0x935d10 trans_code
/home/marxin/Programming/gcc/gcc/fortran/trans.c:1960
0x963fcb gfc_generate_function_code(gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.c:6835
0x8e750e translate_all_program_units
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6306
0x8e750e gfc_parse_file()
/home/marxin/Programming/gcc/gcc/fortran/parse.c:6545
0x932faf gfc_be_parse_file
/home/marxin/Programming/gcc/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-381-gd0fb9ffc1b8f3b86bbdf0e915cec2136141b329b
Author: Jakub Jelinek 
Date:   Thu May 14 09:51:05 2020 +0200

openmp: Fix placement of 2nd+ preparation statement for PHIs in simd clone
lowering [PR95108]

For normal stmts, preparation statements are inserted before the stmt, so
if we need multiple,
they are in the correct order, but for PHIs we emit them after labels in
the entry successor
bb, and we used to emit them in the reverse order that way.

2020-05-14  Jakub Jelinek  

PR middle-end/95108
* omp-simd-clone.c (struct modify_stmt_info): Add after_stmt
member.
(ipa_simd_modify_stmt_ops): For PHIs, only add before first stmt in
entry block if info->after_stmt is NULL, otherwise add after that
stmt
and update it after adding each stmt.
(ipa_simd_modify_function_body): Initialize info.after_stmt.

* gcc.dg/gomp/pr95108.c: New test.

[Bug target/95112] i686 procedures have prolog endbr32

[akobets at mail dot ru]

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

--- Comment #2 from Alexander Kobets  ---
Yes, that it.
I am not sure, that CF must be enabled by default, at your discretion.
Thank you.

[Bug middle-end/95108] [9/10 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |tree_fits_uhwi_p, at|tree_fits_uhwi_p, at
   |tree.c:7292 |tree.c:7292

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

[Bug target/94743] IRQ handler doesn't save scratch VFP registers

[clyon at gcc dot gnu.org]

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

--- Comment #18 from Christophe Lyon  ---

> I'm working on this, and just realized that this also means saving FPSR. It
> seems there's no support for that yet in arm.md (unlike aarch64.md), am I
> missing something?
> 

Sorry, I see it's called FPSCR for arm.

[Bug rtl-optimization/95123] New: [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-t

[asolokha at gmx dot com]

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

Bug ID: 95123
   Summary: [10/11 Regression] Wrong code w/ -O2
-fselective-scheduling2 -funroll-loops --param
early-inlining-insns=5 --param
loop-invariant-max-bbs-in-loop=3 --param
max-jump-thread-duplication-stmts=0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

The following program, compiled w/ gcc-11.0.0-alpha20200510 snapshot
(g:13a46321516e2efd3bbb1f1899c539c6724240a9) w/ -O2 -fselective-scheduling2
-funroll-loops --param early-inlining-insns=5 --param
loop-invariant-max-bbs-in-loop=3 --param max-jump-thread-duplication-stmts=0,
segfauls on run-time:

int ak, mt;
const int g5[1] = { -1 }, ip[5] = { 0 };
unsigned int eu;

void
cm (unsigned char t9)
{
  (void) t9;
  eu = (eu & (~0 - 1)) + ip[eu + 1 > 1];
}

void
qe (unsigned int nc)
{
  cm (nc);
  cm (nc);
  cm (nc);
  asm ("");
  cm (nc);
}

int
main (void)
{
  int xh, bc = mt == 2;

  mt = ak;

  for (xh = 0; xh < 1; ++xh)
{
  qe (g5[xh]);
  asm (";");
  if (!!bc)
__builtin_puts ("");
}

  for (xh = 0; xh < 5; ++xh)
{
  qe (ip[xh]);
  asm (";");
  if (!!bc)
__builtin_printf ("%d\n", xh);

}

  for (xh = 0; xh < 3; ++xh)
{
  qe (ip[xh]);
  if (!!bc)
mt += xh;
}

  return 0;
}

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fselective-scheduling2 --param
early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param
max-jump-thread-duplication-stmts=0 -o good cd8zuepp.c
% ./good
% echo $?
0

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fselective-scheduling2
-funroll-loops --param early-inlining-insns=5 --param
loop-invariant-max-bbs-in-loop=3 --param max-jump-thread-duplication-stmts=0 -o
bad cd8zuepp.c
% ./bad 
zsh: segmentation fault (core dumped)  ./bad

[Bug tree-optimization/48998] ICE: verify_flow_info failed: Wrong frequency of block 227 -161996 with -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
Is it still an issue?

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[chengcongxiu at huawei dot com]

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

--- Comment #3 from chengcongxiu at huawei dot com  ---
(In reply to Richard Biener from comment #1)
> You seem to build from inside the source directory, that is not supported. 
> Please create a separate object directory like
> 
> mkdir obj
> cd obj
> ../configure 
> 
> and re-try.

But option is arm-linux-gnueabi-gcc -msoft-float， the toolchain is OK, so
separate object directory is not userful

[Bug c/95124] New: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396

[anbu1024.me at gmail dot com]

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

Bug ID: 95124
   Summary: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
diag_attr_exclusions, at attribs.c:396
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat reduced.c 

int foo () { 
x; 

void bar ( ) 
{ 
struct struct_0 * var_5 = ( { int x  __attribute__ ( ( unused ,
section ( ".text" ) ) ) ; } )
}
}


$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-10 reduced.c 
reduced.c: In function ‘foo’:
reduced.c:3:2: error: ‘x’ undeclared (first use in this function)
3 |  x;
  |  ^
reduced.c:3:2: note: each undeclared identifier is reported only once for each
function it appears in
reduced.c: In function ‘bar’:
reduced.c:7:10: internal compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396
7 |   struct struct_0 * var_5 = ( { int x  __attribute__ ( ( unused ,
section ( ".text" ) ) ) ; } )
  |  ^~~~
0x731f2f tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-10-20200419/gcc/tree.c:9777
0x5eaf44 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-10-20200419/gcc/tree.h:3410
0x5eaf44 diag_attr_exclusions
../../gcc-10-20200419/gcc/attribs.c:396
0x7d4fda diag_attr_exclusions
../../gcc-10-20200419/gcc/attribs.c:379
0x7d6fb5 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc-10-20200419/gcc/attribs.c:694
0x7f2554 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
../../gcc-10-20200419/gcc/c/c-decl.c:5117
0x84cdd5 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2271
0x8302bf c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5718
0x831f6f c_parser_postfix_expression
../../gcc-10-20200419/gcc/c/c-parser.c:9113
0x834ada c_parser_unary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8273
0x83632d c_parser_cast_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8115
0x8365b9 c_parser_binary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7918
0x837595 c_parser_conditional_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7652
0x837bb0 c_parser_expr_no_commas
../../gcc-10-20200419/gcc/c/c-parser.c:7569
0x83aa4c c_parser_initializer
../../gcc-10-20200419/gcc/c/c-parser.c:5227
0x83aa4c c_parser_initializer
../../gcc-10-20200419/gcc/c/c-parser.c:5219
0x84d193 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2248
0x8302bf c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5718
0x84c8c4 c_parser_compound_statement
../../gcc-10-20200419/gcc/c/c-parser.c:5617
0x84e381 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2505
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.3.1 20200425
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-9 reduced.c 
reduced.c: In function ‘foo’:
reduced.c:3:2: error: ‘x’ undeclared (first use in this function)
3 |  x;
  |  ^
reduced.c:3:2: note: each undeclared identifier is reported only once for each
function it appears in
reduced.c: In function ‘bar’:
reduced.c:7:37: error: section attribute cannot be specified for local
variables
7 |   struct struct_0 * var_5 = ( { int x  __attribute__ ( ( unused ,
section ( ".text" ) ) ) ; } )
  | ^
reduced.c:7:29: error: void value not ignored as it ought to be
7 |   struct struct_0 * var_5 = ( { int x  __attribute__ ( ( unused ,
section ( ".text" ) ) ) ; } )
  | ^
reduced.c:8:2: error: expected ‘,’ or ‘;’ before ‘}’ token
8 |  }
  |  ^
reduced.c: In function ‘foo’:
reduced.c:9:1: error: expecte

[Bug tree-optimization/95118] [10/11 Regression] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:568c985113b29574c4e25e1a016475668fc17c28

commit r11-383-g568c985113b29574c4e25e1a016475668fc17c28
Author: Richard Biener 
Date:   Thu May 14 08:53:03 2020 +0200

middle-end/95118 - fix printing of denormal zero

This fixes printing a REAL_CST generated from value-numbering
punning some bits to a real which turns out as zero with big
negative exponent.  This causes the loop in real_to_decimal_for_mode to
never terminate.

2020-05-14  Richard Biener  

PR middle-end/95118
* real.c (real_to_decimal_for_mode): Make sure we handle
a zero with nonzero exponent.

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

[Bug tree-optimization/95118] [10 Regression] gcc-10 and master -O3 -fopt-info-vec causes gcc to hang

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[10/11 Regression] gcc-10   |[10 Regression] gcc-10 and
   |and master -O3  |master -O3 -fopt-info-vec
   |-fopt-info-vec causes gcc   |causes gcc to hang
   |to hang |
  Known to fail||10.1.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to pskocik from comment #11)
> Thanks for the shot at a fix, Richard Biener.
> 
> Since I have reported this, I think I should mentioned a related
> suboptimality that should probably be getting fixed alongside with this (if
> this one is getting fixed), namely that while
> 
> 
> int64_t zextend_int_to_int64_nospill(int *X) 
> { 
> union { int64_t _; } r = {0}; return memcpy(&r._,X,sizeof(*X)),r._;
> }
> 
> (and hopefully later even 
> 
> int64_t zextend_int_to_int64_spill(int *X) { int64_t r = {0}; return
> memcpy(&r,X,sizeof(*X)),r; }
> )
> 
> generates, on x86_64, the optimal
> 
> zextend_int_to_int64_nospill:
> mov eax, DWORD PTR [rdi]
> ret
> 
> for zeroextending promotions of sub-int types, an extra xor instruction gets
> generated, e.g.:
> 
> 
> int64_t zextend_short_to_int64_nospill_but_suboptimal(short *X) 
> {
> union { int64_t _; } r ={0}; return memcpy(&r._,X,sizeof(*X)),r._;
> }
> 
> =>
> 
> zextend_short_to_int64_nospill_but_suboptimal:
> xor eax, eax
> mov ax, WORD PTR [rdi]
> ret
> 
> which was surprising to me because it doesn't happen with zero-extending
> memcpy-based promotion from {,u}ints to larger types ({,u}{,l}longs).
> 
> https://gcc.godbolt.org/z/ZjXaCw

I think this is PR93507 for which I have a patch queued as well.

[Bug c++/95103] Unexpected -Wclobbered in bits/vector.tcc with -O2

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
Richard's explanation in comment #1 is correct. The compiler assumes any
external call in the destructor can transfer control back to setjmp.

In principle in this case the warning is avoidable by observing that jmp_buf is
local and does not escape, but for any other returns_twice function the problem
would remain, as there's no jmp_buf-like key to track (think vfork).

(iow: solving this would need special-casing warning code for setjmp, which
currently works the same for all functions with the returns_twice attribute)

Let's close this?

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> > --- Comment #9 from Richard Biener  ---
> [...]
> > Hmm, OK looks like memcpy is not folded, likely because the source is
> > not known to be appropriately aligned.
> [...]
> > should fix this.  Can you verify and if so, commit?  Thx.
> 
> Unfortunately, it doesn't.

OK, this only helps a bit later since CCP is required to propagate the
alignment, the following forwprop pass to elide the memcpy and then
finally the update-address-taken invocation in the _second_ CCP pass
after inlining will have

pr94703.c.093t.ccp2:No longer having address taken: r

I've long pondered to remove the memcpy folding restriction for strict-align
targets but never went through.

I'll update the testcase to require

/* { dg-require-effective-target non_strict_align } */

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
This is probably due to sel-sched, and very sensitive to compiler revision: I
tried checking with a 20200511 (one day difference) on Compiler Exporer, and
could not reproduce the miscompilation.

If you still have the compiler binary, you can help out by testing with
sel-sched debug counters: if you append -fdbg-cnt=sel_sched_insn_cnt:0 to the
"bad" command line, it should work again (as sel-sched will not move anything),
with -fdbg-cnt=sel_sched_insn_cnt:9 it should fail. We use this for
isolating a problematic transformation (by bisecting on the counter value).

(other sel-sched debug counters are sel_sched_cnt and sel_sched_region_cnt, but
they are more coarse-grained, by pass and region, instead of insn,
respectively)

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-384-g0d1ccfd0cc2e1add15929c43e6c7472336d33e65
Author: Richard Biener 
Date:   Thu May 14 11:50:20 2020 +0200

testsuite/94703 - skip gcc.dg/tree-ssa/pr94703.c on strict-align targets

The specific dump scanning doesn't work on strict-align targets,
the following simply skips the testcase for those.

2020-05-14  Richard Biener  

PR testsuite/94703
* gcc.dg/tree-ssa/pr94703.c: Skip for strict-align targets.

[Bug target/95125] New: Unoptimal code for vectorized conversions

[ubizjak at gmail dot com]

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

Bug ID: 95125
   Summary: Unoptimal code for vectorized conversions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase

--cut here--
float f[4];
double d[4];
int i[4];

void
float_truncate (void)
{
  for (int n = 0; n < 4; n++)
f[n] = d[n];
}

void
float_extend (void)
{
  for (int n = 0; n < 4; n++)
d[n] = f[n];
}

void
float_float (void)
{
  for (int n = 0; n < 4; n++)
f[n] = i[n];
}

void
fix_float (void)
{
  for (int n = 0; n < 4; n++)
i[n] = f[n];
}

void
float_double (void)
{
  for (int n = 0; n < 4; n++)
d[n] = i[n];
}

void
fix_double (void)
{
  for (int n = 0; n < 4; n++)
i[n] = d[n];
}
--cut here--

when compiled with "-O3 -mavx" should result in a single conversion
instruction.

float_truncate:
vxorps  %xmm0, %xmm0, %xmm0
vcvtsd2ss   d+8(%rip), %xmm0, %xmm2
vmovaps %xmm2, %xmm3
vcvtsd2ss   d(%rip), %xmm0, %xmm1
vcvtsd2ss   d+16(%rip), %xmm0, %xmm2
vcvtsd2ss   d+24(%rip), %xmm0, %xmm0
vunpcklps   %xmm0, %xmm2, %xmm2
vunpcklps   %xmm3, %xmm1, %xmm0
vmovlhps%xmm2, %xmm0, %xmm0
vmovaps %xmm0, f(%rip)
ret

float_extend:
vcvtps2pd   f(%rip), %xmm0
vmovapd %xmm0, d(%rip)
vxorps  %xmm0, %xmm0, %xmm0
vmovlps f+8(%rip), %xmm0, %xmm0
vcvtps2pd   %xmm0, %xmm0
vmovapd %xmm0, d+16(%rip)
ret

float_float:
vcvtdq2ps   i(%rip), %xmm0
vmovaps %xmm0, f(%rip)
ret

fix_float:
vcvttps2dq  f(%rip), %xmm0
vmovdqa %xmm0, i(%rip)
ret

float_double:
vcvtdq2pd   i(%rip), %xmm0
vmovapd %xmm0, d(%rip)
vpshufd $238, i(%rip), %xmm0
vcvtdq2pd   %xmm0, %xmm0
vmovapd %xmm0, d+16(%rip)
ret

fix_double:
pushq   %rbp
vmovapd d(%rip), %xmm1
vinsertf128 $0x1, d+16(%rip), %ymm1, %ymm0
movq%rsp, %rbp
vcvttpd2dqy %ymm0, %xmm0
vmovdqa %xmm0, i(%rip)
vzeroupper
popq%rbp
ret

Clang manages to emit optimal code.

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-05-14
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Martin Liška  ---
I can't reproduce that with the mentioned revision.
Where does it segfault?

[Bug c/95126] New: Missed opportunity to turn static variables into immediates

[pskocik at gmail dot com]

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

Bug ID: 95126
   Summary: Missed opportunity to turn static variables into
immediates
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Example:

For:

struct small{ short a,b; signed char c; };

void call_func(void)
{
extern int func(struct small X);
static struct small const s = { 1,2,0 };
func(s);
}

clang renders (x86_64):

 :
   0:   bf 01 00 02 00  movedi,0x20001
   5:   e9 00 00 00 00  jmpa 6:
R_X86_64_PLT32   func-0x4

whereas gcc renders:

 :
   0:   0f b7 3d 00 00 00 00movzx  edi,WORD PTR [rip+0x0]# 7
3: R_X86_64_PC32.rodata-0x2
   7:   0f b7 05 00 00 00 00movzx  eax,WORD PTR [rip+0x0]# e
a: R_X86_64_PC32.rodata-0x4
   e:   48 c1 e7 10 shlrdi,0x10
  12:   48 09 f8or rax,rdi
  15:   0f b7 3d 00 00 00 00movzx  edi,WORD PTR [rip+0x0]# 1c
  18: R_X86_64_PC32   .rodata
  1c:   48 c1 e7 20 shlrdi,0x20
  20:   48 09 c7or rdi,rax
  23:   e9 00 00 00 00  jmp28   24:
R_X86_64_PLT32  func-0x4


https://gcc.godbolt.org/z/Qxq6Rh

[Bug c++/95103] Unexpected -Wclobbered in bits/vector.tcc with -O2

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The content of the warning isn't very helpful, but I think it's pointing out a
real issue in the code, not a false positive.

Any valid longjmp which followed that setjmp would have undefined behaviour if
executed, because 'v' has a non-trivial destructor.

The current wording is unclear, but CWG 2361 should clarify it, and LWG 1265
(closed as NAD) suggested different wording which would re-formulate the
function as:

void f3() try {
std::vector v;
for (int i = 0; i != 2; ++i) {
if (!f2("xx")) f1();
v.push_back(0);
}
// ...
} catch (...) {
}

An exception thrown from the "..." part would cause the destruction of 'v' and
since that destructor is non-trivial, it would have undefined behaviour.

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
So it looks like the rdseed usage is new in GCC 10 libstdc++ and it prevails
over the previous rdrand support if supported on your CPU.

I can reproduce this on a CPU with rdseed support and libstdc++ from GCC 10.

The code invoked looks correct to me:

  20:   83 e8 01sub$0x1,%eax
  23:   74 12   je 37
<_ZNSt12_GLOBAL__N_112__x86_rdseedEPv+
0x37>
  25:   f3 90   pause  
  27:   0f c7 fardseed %edx
  2a:   89 11   mov%edx,(%rcx)
  2c:   73 f2   jae20
<_ZNSt12_GLOBAL__N_112__x86_rdseedEPv+
0x20>

the number of tries libstdc++ does is 100.  Note rdrand doesn't exhibit this
issue.

So it might very well be a hardware limitation.  Btw, the reproducer can be
"enhanced" by providing the method of operation:

std::random_device rd("rdseed");

that makes sure it will fail in a different way on a not capable CPU
(Intel Broadwell or later or AMD Zen).

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Don't use -mhard-float or -msoft-float.  Instead, you should be using
-mfloat-abi=[hard|softfp|soft] as appropriate.  Also, rather than encoding this
into various sets of flags you should configure the compiler with
--with-float=[hard|softfp|soft] as your environment requires.  Then it should
not be necessary to pass various flags into the library builds.

There's no such option as -mhardfloat.

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||redi at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
HJ, is what libstdc++ does "unreasonable" (it uses rdseed by default if
available) and could it do better?  Can you reproduce the issue?
The docs quoted by Andrew suggest that libstdc++ should, when retries
are not enough, fall back to another method.

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Alexander Monakov from comment #1)
> If you still have the compiler binary, you can help out by testing with
> sel-sched debug counters: if you append -fdbg-cnt=sel_sched_insn_cnt:0 to
> the "bad" command line, it should work again (as sel-sched will not move
> anything), with -fdbg-cnt=sel_sched_insn_cnt:9 it should fail. We use
> this for isolating a problematic transformation (by bisecting on the counter
> value).

It still works w/ counter value 79, starts failing at 80.

[Bug c++/95103] Unexpected -Wclobbered in bits/vector.tcc with -O2

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
No, this analogy does not work. setjmp both sets up a buffer and receives
control, so it corresponds to both try and catch together. A matching "C++"
code would look like:

> void f3() {
> std::vector v;
> for (int i = 0; i != 2; ++i) {
> if (!f2("xx")) f1();
> v.push_back(0);
> }
> try {
> catch (...) {
> }
> }

where it's evident that v does not leave scope and its desctructor cannot be
reached.

(comment #1 and #3 still stand)

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
(In reply to Martin Liška from comment #2)
> I can't reproduce that with the mentioned revision.
> Where does it segfault?

Program received signal SIGSEGV, Segmentation fault.
main () at iu1wkpbg.c:39
39qe (ip[xh]);
(gdb) disassemble 
Dump of assembler code for function main:

<…>

   0x461f <+159>:   je 0x45a0 
   0x4625 <+165>:   xor%ebp,%ebp
   0x4627 <+167>:   xor%edi,%edi
   0x4629 <+169>:   callq  0x47e0 
   0x462e <+174>:   cmp$0x2,%ebx
   0x4631 <+177>:   lea0x2a8(%rip),%rsi# 0x48e0

   0x4638 <+184>:   mov%ebp,%esi
   0x463a <+186>:   je 0x4650 
   0x463c <+188>:   add$0x1,%rbp
   0x4640 <+192>:   cmp$0x5,%rbp
   0x4644 <+196>:   je 0x466f 
=> 0x4646 <+198>:   mov(%rsi,%rbp,4),%edi
   0x4649 <+201>:   jmp0x4629 

<…>

(gdb) info registers rsi
rsi0x0 0

In a good version I see this instead:

 636:   8b 3c a8mov(%rax,%rbp,4),%edi

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
OK, it works if I add -fPIC to the list of compiler options.

[Bug c++/95127] New: Self-calling lambda with auto return type gives misleading error message

[xzlsmc at gmail dot com]

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

Bug ID: 95127
   Summary: Self-calling lambda with auto return type gives
misleading error message
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xzlsmc at gmail dot com
  Target Milestone: ---

$ cat bug.cc
int main() {
  auto f = [](const auto &g, auto x) { return g(g, x); };
  f(f, 0);
}
$ gcc -std=c++14 bug.cc
bug.cc: In instantiation of ‘main():: [with
auto:1 = main()::; auto:2 = int]’:
bug.cc:3:9:   required from here
bug.cc:2:48: error: use of ‘main():: [with
auto:1 = main()::; auto:2 = int]’ before
deduction of ‘auto’
2 |   auto f = [](const auto &g, auto x) { return g(g, x); };
  |   ~^~

This error message is technically correct, but the `auto' it refers to is very
misleading here: it's the implicit `auto' return type of the lambda expression,
rather than either `auto' argument type.  The message can become clearer if
changed to "use of ... before deduction of _return type_".

GCC version: 9.3.1

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
Oh, you're probably configuring your compiler with --enable-default-pie. Please
paste the entire gcc -v. I can reproduce the miscompile it if I pass -fpie
-pie.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to wnereiz from comment #9)
> This issue seems not limit to a certain GCC version. I tried the code with
> gcc7, gcc9 and gcc10 on openSUSE Tumbleweed. All failed.

As Richard said, the code to use rdseed was added for GCC 10, so there is no
way you're seeing the same problem on earlier releases.

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha  ---
(In reply to Alexander Monakov from comment #6)
> Oh, you're probably configuring your compiler with --enable-default-pie.
> Please paste the entire gcc -v. I can reproduce the miscompile it if I pass
> -fpie -pie.

% gcc-11.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-11.0.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/configure
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/11.0.0
--includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/11.0.0/include
--datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/11.0.0
--mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/11.0.0/man
--infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/11.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/11.0.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/11.0.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--disable-vtable-verify --disable-libvtv --without-zstd --disable-libquadmath
--enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer
--enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200510 (experimental) (GCC)

[Bug c++/95127] Self-calling lambda with auto return type gives misleading error message

[xzlsmc at gmail dot com]

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

xzlsmc  changed:

   What|Removed |Added

  Attachment #48532|0   |1
is obsolete||

--- Comment #1 from xzlsmc  ---
Created attachment 48534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48534&action=edit
`gcc -v' and bug.ii stuff

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
We could do this easily enough (which could be simplified if RDRAND is
guaranteed to be available when RDSEED is available):

--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -105,7 +105,13 @@ namespace std _GLIBCXX_VISIBILITY(default)
   while (__builtin_ia32_rdseed_si_step(&val) == 0)
{
  if (--retries == 0)
-   std::__throw_runtime_error(__N("random_device: rdseed failed"));
+   {
+#if USE_RDRAND
+ return __x86_rdrand(nullptr);
+#else
+ std::__throw_runtime_error(__N("random_device: rdseed failed"));
+#endif
+   }
  __builtin_ia32_pause();
}


I'd rather not have to do everything shown at
https://software.intel.com/content/www/us/en/develop/articles/intel-digital-random-number-generator-drng-software-implementation-guide.html
to produce a stronger seed from RDRAND.

[Bug target/95128] New: aarch64: configure option for outline-atomics

[nsz at gcc dot gnu.org]

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

Bug ID: 95128
   Summary: aarch64: configure option for outline-atomics
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on aarch64, non-gnu targets likely want to turn outline atomics off
in their toolchain (since outlining is ineffective without the hwcap
based initializer that can select lse atomics at runtime).

[Bug target/95128] aarch64: configure option for outline-atomics

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-14

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Agreed. I'd be happy to review such a patch

[Bug target/95129] New: aarch64: make outline-atomics work on non-gnu targets

[nsz at gcc dot gnu.org]

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

Bug ID: 95129
   Summary: aarch64: make outline-atomics work on non-gnu targets
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

the initializer in libgcc uses __getauxval which is not
available on non-gnu targets so outlining atomics is
ineffective.

change the runtime lse check in libgcc such that non-glibc
targets can implement it too (e.g. calling __getauxval via
a weak reference and no #ifdef __gnu_linux__ check allows
a libc to implement it later, unfortunately a non-linux os
may not have the same hwcap mechanism so a more generic
libc<->libgcc abi would be better).

[Bug target/95128] aarch64: configure option for outline-atomics

[nsz at gcc dot gnu.org]

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

--- Comment #2 from nsz at gcc dot gnu.org ---
i also opened bug 95129 to fix the runtime detection.

[Bug target/95129] aarch64: make outline-atomics work on non-gnu targets

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
i also opened bug 95128 to just configure the outline-atomics away.

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Martin Liška  ---
Started with r10-4944-g1e83bd7003e03160, which is change in inliner. Thus it is
a latent issue.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #11 from Avi Kivity  ---
I started a conversation on the std-proposals list about this.

Meanwhile, how about a -fnonstandard-coroutines-that-actually-work flag that
captures the parameter to a non-static member function coroutine by value, if
it is an rvalue when the call happens? Without it, lambda coroutines are
useless for asynchronous coroutines.

[Bug target/95129] aarch64: make outline-atomics work on non-gnu targets

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2020-05-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/95105] Bogus reference-compatibility error for arm_sve_vector_bits

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-385-g2c814af65ef9f146519cba657890a4fd93c5be38
Author: Richard Sandiford 
Date:   Thu May 14 12:20:32 2020 +0100

aarch64: Fix arm_sve_vector_bits on typedefs [PR95105]

Compiling this testcase with -march=armv8.2-a+sve
-msve-vector-bits=512:

--
typedef __SVFloat32_t foo;
typedef foo bar __attribute__((arm_sve_vector_bits(512)));
template struct s { T x; };
extern s a;
bar &b = a.x;
--

gave the bogus error:

  cannot bind non-const lvalue reference of type âbar&â to an rvalue
  of type âbarâ

The testcase works if the attribute is applied directly
to __SVFloat32_t instead of via foo.

This shows a more general problem with the way that we were handling
the arm_sve_vector_bits attribute: we started by building a distinct
copy of the type to which the attribute was applied, instead of starting
with its main variant.  This new type then became its own main variant,
meaning that the relationship between types that have the attribute
could be different from the relationship between types that don't have
the attribute.

This patch instead copies the main variant of the original type and then
reapplies all the differences.

2020-05-14  Richard Sandiford  

gcc/
PR target/95105
* config/aarch64/aarch64-sve-builtins.cc
(handle_arm_sve_vector_bits_attribute): Create a copy of the
original type's TYPE_MAIN_VARIANT, then reapply all the differences
between the original type and its main variant.

gcc/testsuite/
PR target/95105
* gcc.target/aarch64/sve/acle/general/attributes_8.c: New test.
* g++.target/aarch64/sve/acle/general-c++/attributes_1.C: Likewise.

[Bug c++/95111] coroutines use-after-free with lambdas

[ville.voutilainen at gmail dot com]

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

--- Comment #12 from Ville Voutilainen  ---
It sure seems to me that a coroutine lambda's captures should be copied to the
coroutine state. I don't think the standard says that anywhere.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #13 from Avi Kivity  ---
Yes. gcc has a minor bug in that the lambda is reflected as a pointer instead
of a reference in coroutine_traits. The major bug is in the standard.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> I'd rather not have to do everything shown at
> https://software.intel.com/content/www/us/en/develop/articles/intel-digital-
> random-number-generator-drng-software-implementation-guide.html to produce a

That was meant to link to section 5.2.6 "Generating Seeds from RDRAND"
https://software.intel.com/content/www/us/en/develop/articles/intel-digital-random-number-generator-drng-software-implementation-guide.html#inpage-nav-5-7

> stronger seed from RDRAND.

Given that RDRAND is already an acceptable implementation for
std::random_device, and the standard makes no guarantees about the
cryptographic strength of values returned from std::random_device, using RDRAND
directly is a reasonable alternative.

[Bug target/94087] std::random_device often fails when used from multiple threads

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #13)
> We could do this easily enough (which could be simplified if RDRAND is
> guaranteed to be available when RDSEED is available):
> 

All Intel processors with RDSEED supports RDRAND which requires checking
of the CF bit in EFLAGS.

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
> 
> --- Comment #12 from Jonathan Wakely  ---
> (In reply to wnereiz from comment #9)
> > This issue seems not limit to a certain GCC version. I tried the code with
> > gcc7, gcc9 and gcc10 on openSUSE Tumbleweed. All failed.
> 
> As Richard said, the code to use rdseed was added for GCC 10, so there is no
> way you're seeing the same problem on earlier releases.

We only ship a single C++ runtime which is usually from the latest
compiler thus a GCC 7 compiled binary run on openSUSE Tumbleweed
picks up libstdc++.so.6 built from GCC 10 sources.

[Bug c/95130] New: GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[martin at martin dot st]

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

Bug ID: 95130
   Summary: GCC ignoring attribute(format(gnu_printf)) on printf
in mingw
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at martin dot st
  Target Milestone: ---

Since a long time (GCC 4.4?) GCC does support annotating functions with either
the format attribute "gnu_printf" or "ms_printf" to distinguish between
different format string interpretations.

However, it seems like the attribute is ignored for the "printf" symbol;
regardless what the function declaration says, GCC treats it as "ms_printf".
This has become an issue now that mingw-w64 supports using the UCRT instead of
msvcrt.dll, and in this case the stdio functions are declared with the
gnu_printf attribute, and inttypes.h uses the same format specifiers as in GNU
mode.

A reproducible example of the problem:

$ cat format.c
__attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
*__format, ...);
__attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
*__format, ...); 

void function(void) {
long long unsigned x = 42;
othername("%llu\n", x);
printf("%llu\n", x);
}
$ x86_64-w64-mingw32-gcc -c -Wformat format.c 
format.c: In function 'function':
format.c:7:15: warning: unknown conversion type character 'l' in format
[-Wformat=] 
7 | printf("%llu\n", x); 
  |   ^
format.c:7:12: warning: too many arguments for format [-Wformat-extra-args]
7 | printf("%llu\n", x);
  |^~~~


Note how both functions, printf and othername, are declare with identical
gnu_printf format attributes - GCC does take this into account for "othername"
and doesn't produce a warning, but GCC seems to disregard the attribute in the
printf declaration and behave as if it was declared as ms_printf.

If the printf function declaration is changed into a static inline function,
the actual attribute used is honored though.

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de  ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
> 
> --- Comment #14 from Jonathan Wakely  ---
> (In reply to Jonathan Wakely from comment #13)
> > I'd rather not have to do everything shown at
> > https://software.intel.com/content/www/us/en/develop/articles/intel-digital-
> > random-number-generator-drng-software-implementation-guide.html to produce a
> 
> That was meant to link to section 5.2.6 "Generating Seeds from RDRAND"
> https://software.intel.com/content/www/us/en/develop/articles/intel-digital-random-number-generator-drng-software-implementation-guide.html#inpage-nav-5-7
> 
> > stronger seed from RDRAND.
> 
> Given that RDRAND is already an acceptable implementation for
> std::random_device, and the standard makes no guarantees about the
> cryptographic strength of values returned from std::random_device, using 
> RDRAND
> directly is a reasonable alternative.

How about falling back to the mersenne twister?  Or does that invoke
too much overhead in the fallback case?  At least it is reliably
there and cannot fail.

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Thu, 14 May 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
> 
> --- Comment #15 from H.J. Lu  ---
> (In reply to Jonathan Wakely from comment #13)
> > We could do this easily enough (which could be simplified if RDRAND is
> > guaranteed to be available when RDSEED is available):
> > 
> 
> All Intel processors with RDSEED supports RDRAND which requires checking
> of the CF bit in EFLAGS.

Note in virtualized environments support for RDRAND might be disabled
while RDSEED is enabled(?) even if no such hardware configuration
exists [by now].  If I were a chip manufacturer (hello VIA?) that
at the moment neither implements RDRAND nor RDSEED a good option
would be to only go for the stronger RDSEED and leave RDRAND 
unimplemented.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Ville Voutilainen from comment #12)
> It sure seems to me that a coroutine lambda's captures should be copied to
> the coroutine state. I don't think the standard says that anywhere.

Maybe I am missing your point (some of these things were decided long before I
joined the fray)



Well, the standard is pretty much silent on coros + lambdas.  However, the
implementors (Richard, Gor, me, et al) had a long discussion on the topic
before Prague - and took what we could from that to Core.

GCC does not comply with the (agreed in that discussion) intent that the
capture object should be treated in the same manner as 'this', and a reference
passed to the traits lookup, promise parms preview and allocator lookup.  I
have a patch for this (will post this week) - but the only implementation with
this correct so far is MSVC
clang passes a ref to the traits but does not pass anything for the closure
object pointer to promise param preview or allocator)
GCC currently passes the object pointer to all three.



The idea of bringing the lambda's captures into the coro frame was what I
originally implemented.  Richard pointed out that this is wrong when the lambda
is mutable (see gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)

so if one has

auto X = [...] () -> some_coro {};

X must exist for the duration of the lambda coro [it was pointed out by Lewis
that really this is only the same as saying that if you have a class with a
member function lambda, the instance of that class has to persist for the
duration of the coro].

We are, I believe, collectively agreed that this is a 'foot gun' (and rvalue
refs doubly so); however, making a better mousetrap here might require some
considerable thought.

I'm happy to be educated if there's some different consensus as to what to do,
and to amend the GCC impl. accordingly.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
If you mean the mersenne twister in the std::random_device object, that's a
union member and doesn't exist when a proper source (/dev/random, rdrand,
rdseed etc) is available. So we'd need to add *another* mersenne twister object
(which would double the size of std::random_device, changing ABI, or have to be
global and protected by a mutex, or thread-local) and we'd have to seed it so
it's not 100% deterministic, and MT has a state size of 19968 bits which needs
a lot of seeding. It's not a good choice for many reasons.

[Bug c/95126] Missed opportunity to turn static variables into immediates

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14

--- Comment #1 from Richard Biener  ---
Confirmed.  Only RTL expansion sees the aggregate copy involved with the
function
call and this, when folded from a constant initializer, is not subject to
clever things such as merging of stores.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:365e3cde4978c6a7dbfa50865720226254c016be

commit r11-386-g365e3cde4978c6a7dbfa50865720226254c016be
Author: Uros Bizjak 
Date:   Thu May 14 13:47:33 2020 +0200

i386: Add V2DFmode conversion functions [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/sse.md (sse2_cvtpi2pd): Add memory to alternative 1.

(floatv2siv2df2): New expander.
(floatunsv2siv2df2): New insn pattern.

(fix_truncv2dfv2si2): New expander.
(fixuns_truncv2dfv2si2): New insn pattern.

testsuite/ChangeLog:

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

[Bug target/94087] std::random_device often fails when used from multiple threads

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Thu, 14 May 2020, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
> 
> --- Comment #19 from Jonathan Wakely  ---
> If you mean the mersenne twister in the std::random_device object, that's a
> union member and doesn't exist when a proper source (/dev/random, rdrand,
> rdseed etc) is available. So we'd need to add *another* mersenne twister 
> object
> (which would double the size of std::random_device, changing ABI, or have to 
> be
> global and protected by a mutex, or thread-local) and we'd have to seed it so
> it's not 100% deterministic, and MT has a state size of 19968 bits which needs
> a lot of seeding. It's not a good choice for many reasons.

Doh.  OK, guess I'd set up the twister in all cases and make it 
programatically skip itself when rdrand/rdseed is available so we
could easily fall back to it.  Not sure what extra state there is
that warrants the union, but well ... I suppose simply calling
random() from the C library isn't an option ;)

[Bug tree-optimization/48998] ICE: verify_flow_info failed: Wrong frequency of block 227 -161996 with -O3 --param max-completely-peeled-insns=5000 --param max-predicted-iterations=1

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Arseny Solokha from comment #1)
> Is it still an issue?

I can't reproduce this with r11-385.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #15 from Avi Kivity  ---
I believe that my suggestion works for mutable lambdas (and for any coroutine
called as a member function):

 - if the object passeed to the member function is an lvalue, then the
coroutine captures a reference to the object
 - if the object passed to the member function is an rvalue, then the coroutine
captures the object by copying it (typically using it move constructor).

Examples:

   auto a = [blah] () mutable -> task<> { ... };
   a();   // a is captured by reference

   [blah] () mutable -> task<> { ... } (); // captured by value


   my_class a;
   a.some_coroutine();  // captured by reference


   my_class a;
   std::move(a).some_coroutine();   // captured by value


Currently, the "captured by value" cases are captured by reference, and cause a
use-after-free if the coroutine outlives the caller scope.

[Bug target/95125] Unoptimal code for vectorized conversions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14
 Target||x86_64-*-* i?86-*-*
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
ISTR I filed a duplicate 10 years ago or so.  The issue is the vectorizer
could not handle V4DFmode -> V4SFmode conversions.

Could, because for SVE we added the capability but this requires
additional instruction patterns (IIRC I filed a but about this last
year).  Yep.  PR92658 it is.

[Bug rtl-optimization/95123] [10/11 Regression] Wrong code w/ -O2 -fselective-scheduling2 -funroll-loops --param early-inlining-insns=5 --param loop-invariant-max-bbs-in-loop=3 --param max-jump-thread

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug c++/95111] coroutines use-after-free with lambdas

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #16 from Ville Voutilainen  ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Ville Voutilainen from comment #12)
> The idea of bringing the lambda's captures into the coro frame was what I
> originally implemented.  Richard pointed out that this is wrong when the
> lambda is mutable (see
> gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
> 
> so if one has
> 
> auto X = [...] () -> some_coro {};
> 
> X must exist for the duration of the lambda coro [it was pointed out by
> Lewis that really this is only the same as saying that if you have a class
> with a member function lambda, the instance of that class has to persist for
> the duration of the coro].

Ah. So the work-around for this problem is to copy the capture to a local
variable, and co_return that; then the local variable is in the coro-state.
Right?

[Bug c++/95111] coroutines use-after-free with lambdas

[ville.voutilainen at gmail dot com]

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

--- Comment #17 from Ville Voutilainen  ---
(In reply to Ville Voutilainen from comment #16)
> (In reply to Iain Sandoe from comment #14)
> > (In reply to Ville Voutilainen from comment #12)
> > The idea of bringing the lambda's captures into the coro frame was what I
> > originally implemented.  Richard pointed out that this is wrong when the
> > lambda is mutable (see
> > gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
> > 
> > so if one has
> > 
> > auto X = [...] () -> some_coro {};
> > 
> > X must exist for the duration of the lambda coro [it was pointed out by
> > Lewis that really this is only the same as saying that if you have a class
> > with a member function lambda, the instance of that class has to persist for
> > the duration of the coro].
> 
> Ah. So the work-around for this problem is to copy the capture to a local
> variable, and co_return that; then the local variable is in the coro-state.
> Right?

That is, instead of writing

[x] {co_return x;}

write

[x] {auto xx = x; co_return xx;}

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #18 from Avi Kivity  ---
The work-around works if initial_suspend() returns suspend_never or similar. If
the lambda is suspended before execution, the reference may dangle.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
(In reply to Ville Voutilainen from comment #17)
> (In reply to Ville Voutilainen from comment #16)
> > (In reply to Iain Sandoe from comment #14)
> > > (In reply to Ville Voutilainen from comment #12)
> > > The idea of bringing the lambda's captures into the coro frame was what I
> > > originally implemented.  Richard pointed out that this is wrong when the
> > > lambda is mutable (see
> > > gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
> > > 
> > > so if one has
> > > 
> > > auto X = [...] () -> some_coro {};
> > > 
> > > X must exist for the duration of the lambda coro [it was pointed out by
> > > Lewis that really this is only the same as saying that if you have a class
> > > with a member function lambda, the instance of that class has to persist 
> > > for
> > > the duration of the coro].
> > 
> > Ah. So the work-around for this problem is to copy the capture to a local
> > variable, and co_return that; then the local variable is in the coro-state.
> > Right?
> 
> That is, instead of writing
> 
> [x] {co_return x;}
> 
> write
> 
> [x] {auto xx = x; co_return xx;}

hmm I'm not sure this is sufficient; if the initial suspend is suspend-always,
and the closure object goes away before the initial resume, then xx will be
initialised with garbage.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to rguent...@suse.de from comment #18)
> Note in virtualized environments support for RDRAND might be disabled
> while RDSEED is enabled(?) even if no such hardware configuration
> exists [by now].  If I were a chip manufacturer (hello VIA?) that
> at the moment neither implements RDRAND nor RDSEED a good option
> would be to only go for the stronger RDSEED and leave RDRAND 
> unimplemented.

So we'd want something like this to check if RDRAND is usable:

--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -97,7 +97,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 #if USE_RDSEED
 unsigned int
 __attribute__ ((target("rdseed")))
-__x86_rdseed(void*)
+__x86_rdseed(void* fallback)
 {
   unsigned int retries = 100;
   unsigned int val;
@@ -105,12 +105,25 @@ namespace std _GLIBCXX_VISIBILITY(default)
   while (__builtin_ia32_rdseed_si_step(&val) == 0)
{
  if (--retries == 0)
-   std::__throw_runtime_error(__N("random_device: rdseed failed"));
+   {
+ if (auto f = reinterpret_cast(fallback))
+   return f(nullptr);
+ std::__throw_runtime_error(__N("random_device: rdseed failed"));
+   }
  __builtin_ia32_pause();
}

   return val;
 }
+
+#if USE_RDRAND
+unsigned int
+__attribute__ ((target("rdseed,rdrnd")))
+__x86_rdseed_rdrand(void*)
+{
+  return __x86_rdseed(reinterpret_cast(&__x86_rdrand));
+}
+#endif
 #endif

 #ifdef _GLIBCXX_USE_CRT_RAND_S
@@ -205,6 +218,15 @@ namespace std _GLIBCXX_VISIBILITY(default)
__cpuid_count(7, 0, eax, ebx, ecx, edx);
if (ebx & bit_RDSEED)
  {
+#ifdef USE_RDRAND
+   // CPUID.01H:ECX.RDRAND[bit 30]
+   __cpuid(1, eax, ebx, ecx, edx);
+   if (ecx & bit_RDRND)
+ {
+   _M_func = &__x86_rdseed_rdrand;
+   return;
+ }
+#endif
_M_func = &__x86_rdseed;
return;
  }

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to rguent...@suse.de from comment #20)
> Doh.  OK, guess I'd set up the twister in all cases and make it 
> programatically skip itself when rdrand/rdseed is available so we
> could easily fall back to it.  Not sure what extra state there is
> that warrants the union, but well ... I suppose simply calling
> random() from the C library isn't an option ;)

Mersenne twister is just a bad choice, period.

We could fit a linear_congruential_engine in the unused space of the union.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #20 from Avi Kivity  ---
My coroutines do return suspend_never from initial_suspend(); so thanks for the
workaround, I'll use it until we have a better fix.

[Bug target/94087] std::random_device often fails when used from multiple threads

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|9.2.1   |10.1.0
   Target Milestone|--- |10.2

--- Comment #23 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #22)
> We could fit a linear_congruential_engine in the unused space of the union.

But we'd still need to seed it on construction, even if we never use it.

Changing version to 10 since there's no bug in gcc 9 (comment 16 explains why
it was seen there).

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  ---
Avi, If we are agreed that there is no GCC bug here (the change from pointer to
reference is already in the queue)

I would suggest that new design discussion would be better by putting a paper
or suggestions to the WG21 evolution list (and certainly involving folks who
are not present 'here').  In which case the bug could be closed.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #22 from Avi Kivity  ---
Certainly, closing as invalid.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

Avi Kivity  changed:

   What|Removed |Added

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

--- Comment #23 from Avi Kivity  ---
The bug is in the C++ standard, not gcc.

[Bug target/95125] Unoptimal code for vectorized conversions

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> ISTR I filed a duplicate 10 years ago or so.  The issue is the vectorizer
> could not handle V4DFmode -> V4SFmode conversions.
> 
> Could, because for SVE we added the capability but this requires
> additional instruction patterns (IIRC I filed a but about this last
> year).  Yep.  PR92658 it is.

Oh... yes. And it is even assigned to me. And there is a patch... ;)

Anyway, I got surprised, since my soon-to-be committed v2sf-v2df conversion
patch was able to fully vectorize similar testcase involving double[2] and
float[2], while code involving [4] compiled to he mess below.

[Bug target/95125] Unoptimal code for vectorized conversions

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
It turns out that a bunch of patterns have to be renamed (and testcases added).

Easyhack, waiting for someone to show some love to conversion patterns in
sse.md.

[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 #21 from Bill Seurer  ---
We can't modify the spec code but we can add "compatibility" options.

Shouldn't the if test make the compiler ignore the statement with the divide by
zero?  It shouldn't ever be executed.

[Bug c++/95050] coroutine: no "mandatory copy elision" for prvalue await_resume expression.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Target Milestone|--- |10.2
   Last reconfirmed||2020-05-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/92658] x86 lacks vector extend / truncate

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
The patch is ready to be pushed, it is waiting for a decision what to do with
failed cases.

Richi, should this patch move forward (eventually XFAILing failed cases), or do
you plan to look at the fails from the generic vectorizer POV?

[Bug fortran/84007] [OOP] ICE with SAME_TYPE_AS and CLASS(*) entity

[arjen.markus895 at gmail dot com]

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

Arjen Markus  changed:

   What|Removed |Added

 CC||arjen.markus895 at gmail dot 
com

--- Comment #4 from Arjen Markus  ---
I encountered this problem with gfortran 9.3.0:

$ gfortran -c dictionary.f90
dictionary.f90:35:0:

   35 | if ( .not. same_type_as( key, dict%prototype ) ) then
  |
internal compiler error: in wide_int_to_tree_1, at tree.c:1561

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[chengcongxiu at huawei dot com]

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

--- Comment #5 from chengcongxiu at huawei dot com  ---
(In reply to Richard Earnshaw from comment #4)
> Don't use -mhard-float or -msoft-float.  Instead, you should be using
> -mfloat-abi=[hard|softfp|soft] as appropriate.  Also, rather than encoding
> this into various sets of flags you should configure the compiler with
> --with-float=[hard|softfp|soft] as your environment requires.  Then it
> should not be necessary to pass various flags into the library builds.
> 
> There's no such option as -mhardfloat.


thank you！ for GCC 4.9, compile gcc first ,gcc second and final with flags
--with-float=hard can compiler arm-linux-gnueabihf!!!

[Bug pch/95131] New: Instantiate templates at pch generation time

[trass3r at gmail dot com]

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

Bug ID: 95131
   Summary: Instantiate templates at pch generation time
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trass3r at gmail dot com
  Target Milestone: ---

Judging by the limited information -ftime-report provides it looks like gcc
still spends quite some time on things that could have been done at pch
generation time already like template instantiations.

This was already noted in
https://gcc.gnu.org/wiki/Speedup_areas#Improvements_to_PCH
The page should be updated if this is not true anymore.

Clang has a similar problem that is currently being addressed:
https://llunak.blogspot.com/2019/11/clang-precompiled-headers-and-improving.html
https://reviews.llvm.org/D69585

[Bug target/92658] x86 lacks vector extend / truncate

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 14 May 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> 
> --- Comment #10 from Uroš Bizjak  ---
> The patch is ready to be pushed, it is waiting for a decision what to do with
> failed cases.
> 
> Richi, should this patch move forward (eventually XFAILing failed cases), or 
> do
> you plan to look at the fails from the generic vectorizer POV?

I think we should go forward with the patch, either XFAILing the testcases
or splitting out the testcase (and backend patterns that do not get
exercised due to the issue).

I've already said in comment#8 that the issue here is optabs working
with modes and not vector types, so it's a bit hard to use the
same mechanism to deal with the currently failing cases.  One
possible route would be to add V4QImode similar to how we now
do V2SFmode with SSE but of course where do we stop ...

As said we can try to tackle this incrementally.  Maybe Richard also
has input here?

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

[chengcongxiu at huawei dot com]

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

chengcongxiu at huawei dot com  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

[Bug bootstrap/95122] Cross-compile arm32 toolchain with hard float, but Error in gcc final

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug pch/95131] Instantiate templates at pch generation time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Modules are the future, not sure how this applies there.

[Bug target/92658] x86 lacks vector extend / truncate

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #11)
> On Thu, 14 May 2020, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> > 
> > --- Comment #10 from Uroš Bizjak  ---
> > The patch is ready to be pushed, it is waiting for a decision what to do 
> > with
> > failed cases.
> > 
> > Richi, should this patch move forward (eventually XFAILing failed cases), 
> > or do
> > you plan to look at the fails from the generic vectorizer POV?
> 
> I think we should go forward with the patch, either XFAILing the testcases
> or splitting out the testcase (and backend patterns that do not get
> exercised due to the issue).
> 
> I've already said in comment#8 that the issue here is optabs working
> with modes and not vector types, so it's a bit hard to use the
> same mechanism to deal with the currently failing cases.  One
> possible route would be to add V4QImode similar to how we now
> do V2SFmode with SSE but of course where do we stop ...
> 
> As said we can try to tackle this incrementally.  Maybe Richard also
> has input here?
Nothing to add really, but: yeah, the idea was that the target
would provide smaller vector modes if it can efficiently load,
store and (at least) add them.  I think it would be good to do
that for aarch64 Advanced SIMD at some point.

There are three points behind using vector modes for this:

1. It gives the target the flexibility to decide how best to
   implement the operation (All at one end, and if so, which end?
   Or spread out evenly across the vector?)  On aarch64, the
   choice would differ between SVE and Advanced SIMD.

2. It means that __attribute__((vector_size)) vectors benefit.

3. The smaller modes can be used in conjunction with
   autovectorize_vector_modes to give the loop vectoriser
   a choice between operating on packed or unpacked vectors.
   This is mostly useful for VECT_COMPARE_COSTS but can help
   with low-trip-count loops even without.

So yeah, defining V4QI sounds like the way to go if the
architecture can process it efficiently.  I get the "where
do we stop" concern, but .md mode iterators should help.

[Bug pch/95131] Instantiate templates at pch generation time

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
1) The future is sooner than you think :)

2) template instantiation cannot be done speculatively -- only when language
constructs require it.  Otherwise you can change the meaning of well-formed
code.

[Bug c++/95132] New: Concept checked after auto return type deduction

[bluescarni at gmail dot com]

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

Bug ID: 95132
   Summary: Concept checked after auto return type deduction
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bluescarni at gmail dot com
  Target Milestone: ---

It seems like in GCC's implementation of C++20 concepts, concept checking is
done after the instantiation of the body of a function with auto return type
deduction.

See the godbolt link, where the same snippet of code is being compiled with
GCC, clang and MSVC:

https://godbolt.org/z/CMzZyV

As you see, the first GCC error comes from the failure in the instantiation of
the body of function bar(), and only later GCC complains about the concept
check failure. The other two compilers don't produce any error from the
instantiation of bar().

This is problematic because it means that another concept that would check
whether or not bar() can be called with a specific argument type would fail
with a hard compile time error, instead of marking the concept as not
satisfied.

[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768

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

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

G. Steinmetz  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |ICE in hash_operand, at
   |hash_operand, at|fold-const.c:3768
   |fold-const.c:3768   |

--- Comment #2 from G. Steinmetz  ---
> I see a Fortran FE ICE since at least 4.8.0:
Can confirm that with test versions too.

[Bug c/95133] New: [9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

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

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

Bug ID: 95133
   Summary: [9/10/11 Regression] ICE in
gimple_redirect_edge_and_branch_force, at
tree-cfg.c:6075
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8, needs option -O3 :


$ cat z1.c
extern int a[16];
void f (int *ip, int x)
{
  int *xp = a;
  for (int i=0; i<8; ++i)
  {
base: if (x) return;
  }
  *xp++ = *ip;
  goto *(&&base + *ip);
}


$ gcc-11-20200510 -c z1.c -O2
$ gcc-11-20200510 -c z1.c -O3
during GIMPLE pass: split-paths
z1.c: In function 'f':
z1.c:2:6: internal compiler error: in gimple_redirect_edge_and_branch_force, at
tree-cfg.c:6075
2 | void f (int *ip, int x)
  |  ^
0xd2de58 gimple_redirect_edge_and_branch_force
../../gcc/tree-cfg.c:6075
0x7d32a3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
../../gcc/cfghooks.c:490
0x7d509a duplicate_block(basic_block_def*, edge_def*, basic_block_def*,
copy_bb_data*)
../../gcc/cfghooks.c:1109
0xcddf05 transform_duplicate(basic_block_def*, basic_block_def*)
../../gcc/tracer.c:245
0x1697ae0 split_paths
../../gcc/gimple-ssa-split-paths.c:463
0x1697ae0 execute_split_paths
../../gcc/gimple-ssa-split-paths.c:503
0x1697ae0 execute
../../gcc/gimple-ssa-split-paths.c:540

[Bug target/95134] New: -ffreestanding should avoid libcall

[hjl.tools at gmail dot com]

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

Bug ID: 95134
   Summary: -ffreestanding should avoid libcall
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

[hjl@gnu-cfl-2 freestand]$ cat x.i 
struct foo
{
  char array[257];
};

extern struct foo x;

void
func (struct foo i)
{
  x = i;
}
[hjl@gnu-cfl-2 freestand]$ make x.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -W
-ffreestanding -mtune=pentium -m32 -S x.i
[hjl@gnu-cfl-2 freestand]$ cat x.s
.file   "x.i"
.text
.p2align 4
.globl  func
.type   func, @function
func:
.LFB0:
.cfi_startproc
subl$16, %esp
.cfi_def_cfa_offset 20
pushl   $257
.cfi_def_cfa_offset 24
leal24(%esp), %eax
pushl   %eax
.cfi_def_cfa_offset 28
pushl   $x
.cfi_def_cfa_offset 32
callmemcpy
addl$28, %esp
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE0:
.size   func, .-func
.ident  "GCC: (GNU) 11.0.0 20200514 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 freestand]$ 

x86 backend should avoid libcall if flag_hosted is false.

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

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #22 from Bill Schmidt  ---
Breaking legitimate code, even if "borderline," does not seem right to me.  
Zero division is generally a runtime exception because of such cases.

You write code for a general case, then later you discover "oh, well, we could
make this variable zero for our specific usage," and now the compiler throws a
fit?  Seems like this is warning-level stuff.

[Bug c/95133] [9/10/11 Regression] ICE in gimple_redirect_edge_and_branch_force, at tree-cfg.c:6075

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-14
 CC||jgreenhalgh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-2217-g0919ce3efe2a0d6a.

[Bug target/95134] -ffreestanding should avoid libcall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is documented this way and has been true for years and documented for
years.

[Bug c++/95135] New: Inconsistent CTAD behaviour with the "new" operator.

[gccbugreport at yandex dot com]

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

Bug ID: 95135
   Summary: Inconsistent CTAD behaviour with the "new" operator.
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugreport at yandex dot com
  Target Milestone: ---

Created attachment 48535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48535&action=edit
The preprocessed file.

This is my first bug report, I hope it includes all the necessary information.
In any case, this bug is very easy to replicate.
===
The code (main.cpp):

template
struct X {
X(T _t) {}
};

template
struct Y {
Y(T _t, U _u) {}
};

int main() {
X(1);
new X(1);

Y(1, 2);
new Y(1, 2); // This line causes the compilation error.

return 0;
}
===
Compiled with:

gcc -v -save-temps -std=c++17 main.cpp -lstdc++
===
Output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++1z
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -std=c++1z
-version -fstack-protector-strong -Wformat -Wformat-security -o main.s
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3eb3dc290cd5714c3e1c3ae751116f07
main.cpp: In function ‘int main()’:
main.cpp:16:15: error: class template argument deduction failed:
 new Y(1, 2); // This line causes the compilation error.
   ^
main.cpp:16:15: error: no matching function for call to ‘Y()’
main.cpp:8:5: note: candidate: template Y(T, U)-> Y
 Y(T _t, U _u) {}
 ^
main.cpp:8:5: note:   template argument deduction/substitution failed:
main.cpp:16:15: note:   candidate expects 2 arguments, 0 provided
 new Y(1, 2); // This line causes the compilation error.
===

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
So, in order for this to hang, two close statements
on the same unit are needed, the first one with an
error message.

Seems like the unit is not unlocked on the error return.

[Bug target/94697] aarch64: bti j at function start instead of bti c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :

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

commit r9-8594-gf6e42cdee5de2b3441afc88cc1166bdffe57
Author: Szabolcs Nagy 
Date:   Fri Apr 17 16:54:12 2020 +0100

aarch64: ensure bti c is emitted at function start [PR94697]

The bti pass currently first emits bti c at function start
if there is no paciasp (which also acts as indirect call
landing pad), then bti j is emitted at jump labels, however
if there is a label right before paciasp then the function
start can end up like

  foo:
  label:
bti j
paciasp
...

This patch is a minimal fix that just moves the bti c handling
after the bti j handling so we end up with

  foo:
bti c
  label:
bti j
paciasp
...

This could be improved by emitting bti jc in this case, or by
detecting that the label is not in fact an indirect jump target
and then this situation would be much less common.

Needs to be backported to gcc-9 branch.

Backported without the testcase because of missing infrastructure
for check-function-bodies.

gcc/ChangeLog:

Backport from mainline.
2020-04-23  Szabolcs Nagy  

PR target/94697
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap
bti c and bti j handling.

[Bug target/94748] aarch64: many unnecessary bti j emitted

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:9a1b74d49e2e25b29675fac4322bb7ba6cec5894

commit r9-8595-g9a1b74d49e2e25b29675fac4322bb7ba6cec5894
Author: Szabolcs Nagy 
Date:   Fri Apr 24 17:36:02 2020 +0100

aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]

It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html

Before the patch a bti j was inserted after the label in

  __attribute__((target("branch-protection=bti")))
  int foo (void)
  {
  label:
return 0;
  }

This is not necessary and weakens the security protection.

gcc/ChangeLog:

Backport from mainline.
2020-04-30  Szabolcs Nagy  

PR target/94748
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
the check for NOTE_INSN_DELETED_LABEL.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-30  Szabolcs Nagy  

PR target/94748
* gcc.target/aarch64/pr94748.c: New test.

[Bug target/94515] aarch64: broken unwind information for pac-ret

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:95833c34424f340a7e465ee38b6a41369bc7c90b

commit r9-8593-g95833c34424f340a7e465ee38b6a41369bc7c90b
Author: Szabolcs Nagy 
Date:   Mon Apr 27 09:07:15 2020 +0100

aarch64: Fix .cfi_window_save with pac-ret [PR94515]

On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.

This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.

Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.

This should be backported to gcc-9 and gcc-8 branches.

gcc/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.

gcc/testsuite/ChangeLog:

Backport from mainline.
2020-04-27  Szabolcs Nagy  

PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.