[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Oops, autocorrect.

s/yesterday/testcase/

[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Not important for me. I don't remember where the yesterday came from.

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[luoxhu at gcc dot gnu.org]

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---
In expand, Power8 will emit two register permute instructions to byte swap the
contents by rs6000_emit_le_vsx_move.

P9:
5: NOTE_INSN_BASIC_BLOCK 2
2: r129:TF=%1:TF
3: r130:TF=%3:TF
4: NOTE_INSN_FUNCTION_BEG
7: r117:DF=unspec[r129:TF,0] 70
8: r131:V2DF=r121:V2DF
9: r133:DF=vec_select(r131:V2DF,parallel)
   10: r131:V2DF=vec_concat(r117:DF,r133:DF)
   11: r122:V2DF=r131:V2DF
   12: r118:DF=unspec[r129:TF,0x1] 70
   13: r119:DF=unspec[r130:TF,0] 70
   14: r134:V2DF=r124:V2DF
   15: r136:DF=vec_select(r134:V2DF,parallel)
   16: r134:V2DF=vec_concat(r119:DF,r136:DF)
   17: r125:V2DF=r134:V2DF
   18: r120:DF=unspec[r130:TF,0x1] 70
   19: r137:V2DF=r122:V2DF
   20: r139:DF=vec_select(r137:V2DF,parallel)
   21: r137:V2DF=vec_concat(r139:DF,r118:DF)
   22: [r112:DI]=r137:V2DF
   23: r140:V2DF=r125:V2DF
   24: r142:DF=vec_select(r140:V2DF,parallel)
   25: r140:V2DF=vec_concat(r142:DF,r120:DF)
   26: [r112:DI+0x10]=r140:V2DF
   27: r143:V4SI=[r112:DI]
   28: r144:V4SI=[r112:DI+0x10]
   29: r127:V4SI=r143:V4SI
   30: r128:V4SI=r144:V4SI
   34: %2:V4SI=r127:V4SI
   35: %3:V4SI=r128:V4SI
   36: use %2:V4SI
   37: use %3:V4SI

P8:
5: NOTE_INSN_BASIC_BLOCK 2
2: r129:TF=%1:TF
3: r130:TF=%3:TF
4: NOTE_INSN_FUNCTION_BEG
7: r117:DF=unspec[r129:TF,0] 70
8: r131:V2DF=r121:V2DF
9: r133:DF=vec_select(r131:V2DF,parallel)
   10: r131:V2DF=vec_concat(r117:DF,r133:DF)
   11: r122:V2DF=r131:V2DF
   12: r118:DF=unspec[r129:TF,0x1] 70
   13: r119:DF=unspec[r130:TF,0] 70
   14: r134:V2DF=r124:V2DF
   15: r136:DF=vec_select(r134:V2DF,parallel)
   16: r134:V2DF=vec_concat(r119:DF,r136:DF)
   17: r125:V2DF=r134:V2DF
   18: r120:DF=unspec[r130:TF,0x1] 70
   19: r137:V2DF=r122:V2DF
   20: r139:DF=vec_select(r137:V2DF,parallel)
   21: r137:V2DF=vec_concat(r139:DF,r118:DF)
   22: r140:V2DF=vec_select(r137:V2DF,parallel)
   23: [r112:DI]=vec_select(r140:V2DF,parallel)
   24: r141:V2DF=r125:V2DF
   25: r143:DF=vec_select(r141:V2DF,parallel)
   26: r141:V2DF=vec_concat(r143:DF,r120:DF)
   27: r144:V2DF=vec_select(r141:V2DF,parallel)
   28: [r112:DI+0x10]=vec_select(r144:V2DF,parallel)
   29: r146:V4SI=vec_select([r112:DI],parallel)
   30: r145:V4SI=vec_select(r146:V4SI,parallel)
   31: r148:V4SI=vec_select([r112:DI+0x10],parallel)
   32: r147:V4SI=vec_select(r148:V4SI,parallel)
   33: r127:V4SI=r145:V4SI
   34: r128:V4SI=r147:V4SI
   38: %2:V4SI=r127:V4SI
   39: %3:V4SI=r128:V4SI
   40: use %2:V4SI
   41: use %3:V4SI

Difference starts from #22. Power8 will emit two vec_select instructions for
stack store/load operations. But power9 needs only one.

[Bug tree-optimization/95327] New: [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3655

[marxin at gcc dot gnu.org]

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

Bug ID: 95327
   Summary: [11 Regression] ICE in vect_get_constant_vectors, at
tree-vect-slp.c:3655
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

I see the following ICE:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c
-mpower9-vector -O3 -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c: In function
‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/pr33369.c:12:1: internal
compiler error: in vect_get_constant_vectors, at tree-vect-slp.c:3655
   12 | f (POINT * ptBuf)
  | ^
0x152b405 vect_get_constant_vectors
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3655
0x152bfbf vect_get_slp_defs(vec_info*, _slp_tree*, vec, va_heap, vl_ptr>*, unsigned int)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:3887
0x14c0380 vect_get_vec_defs(vec_info*, tree_node*, tree_node*, _stmt_vec_info*,
vec*, vec*,
_slp_tree*)
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:1636
0x14d0405 vectorizable_shift
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:5894
0x14e359b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc2/gcc/tree-vect-stmts.c:11176
0x152d23f vect_schedule_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4235
0x152ca59 vect_schedule_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4127
0x152d843 vect_schedule_slp(vec_info*)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4359
0x150a989 vect_transform_loop(_loop_vec_info*, gimple*)
/home/marxin/Programming/gcc2/gcc/tree-vect-loop.c:8753
0x153639c try_vectorize_loop_1
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:988
0x1536638 try_vectorize_loop
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1044
0x1536812 vectorize_loops()
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1125
0x13aa111 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/95326] GCC can not detect signed-integer-overflow correctly

[haoxintu at gmail dot com]

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

Haoxin Tu  changed:

   What|Removed |Added

Version|11.0|10.0

--- Comment #1 from Haoxin Tu  ---
I also found another case example.cpp

#include 

unsigned short g_var_ushort = 52781U;
const unsigned int g_const_uint = 2331271054U;

int main () {
//test_function();
short l_var_short = -14674;
volatile unsigned char l_volatile_uchar = 151U;
long l_var_long = 572469544701421587L;

g_var_ushort = l_volatile_uchar - l_var_short % g_const_uint * l_var_long;
std::cout << "hello" << std::endl;
return 0;
}

$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello

$clang++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
example.cpp:12:66: runtime error: signed integer overflow: 1963681568 *
572469544701421587 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:12:66 in 
hello

My g++ version is
$g++ --version
g++ (GCC) 10.0.1 20200420 (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.

I have tested all GCC versions including GCC-8, GCC-9, GCC-10, and GCC-Trunk in
Godbolt, they can not detect this UB as well.

[Bug c++/95326] New: UBsan can not detect signed-integer-overflow correctly

[haoxintu at gmail dot com]

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

Bug ID: 95326
   Summary: UBsan can not detect signed-integer-overflow correctly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case example.cpp

#include 

volatile wchar_t g_volatile_wchar = 2082494266;
volatile unsigned short g_volatile_ushort = 31503U;

int main () {
unsigned long l_var_ulong = 526562505494506029UL;
const wchar_t l_const_wchar = 1188246531;
g_volatile_ushort = l_var_ulong + l_const_wchar * g_volatile_wchar;
std::cout << "hello" << std::endl;
return 0;
}

can not detect signed-integer-overflow runtime error in gcc-trunk

$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello

But in clang-trunk
$clang++ -fsanitize=signed-integer-overflow test.cc ; ./a.out
example.cpp:9:53: runtime error: signed integer overflow: 1188246531 *
2082494266 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:9:53 in 
hello

godbolt clang-trunk : https://godbolt.org/z/s4-AqW
godbolt gcc-trunk : https://godbolt.org/z/k7NhG6

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88
Author: liuhongt 
Date:   Tue May 26 11:14:31 2020 +0800

Fix non-comforming expander for
floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di.

2020-05-26  Hongtao Liu  
Uroš Bizjak  

gcc/ChangeLog:
PR target/95211
PR target/95256
* config/i386/sse.md (v2div2sf2): New expander.
(fix_truncv2sfv2di2): Ditto.
(avx512dq_floatv2div2sf2): Renaming from
floatv2div2sf2.
(avx512dq_fix_truncv2sfv2di2):
Renaming from fix_truncv2sfv2di2.
(vec_pack_float_): Adjust icode name.
(vec_unpack_fix_trunc_lo_): Ditto.
(vec_unpack_fix_trunc_hi_): Ditto.
* config/i386/i386-builtin.def: Ditto.
* emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector
subregs when both omode and imode are vector mode and
have the same inner mode.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr95211.c: New test.

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88
Author: liuhongt 
Date:   Tue May 26 11:14:31 2020 +0800

Fix non-comforming expander for
floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di.

2020-05-26  Hongtao Liu  
Uroš Bizjak  

gcc/ChangeLog:
PR target/95211
PR target/95256
* config/i386/sse.md (v2div2sf2): New expander.
(fix_truncv2sfv2di2): Ditto.
(avx512dq_floatv2div2sf2): Renaming from
floatv2div2sf2.
(avx512dq_fix_truncv2sfv2di2):
Renaming from fix_truncv2sfv2di2.
(vec_pack_float_): Adjust icode name.
(vec_unpack_fix_trunc_lo_): Ditto.
(vec_unpack_fix_trunc_hi_): Ditto.
* config/i386/i386-builtin.def: Ditto.
* emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector
subregs when both omode and imode are vector mode and
have the same inner mode.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr95211.c: New test.

[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"

[bouanto at zoho dot com]

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

--- Comment #1 from bouanto at zoho dot com ---
A similar error happens for the builtin "memcpy":

error: unimplemented primitive type for builtin: 38

[Bug jit/95325] New: Support 128-bit integers

[bouanto at zoho dot com]

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

Bug ID: 95325
   Summary: Support 128-bit integers
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
Would it be possible to add support for 128-bit integers in libgccjit?
Thanks.

[Bug c++/95324] New: Segmentation fault when using variadic lambda template in concept definition

[ivan.pogrebnyak at gmail dot com]

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

Bug ID: 95324
   Summary: Segmentation fault when using variadic lambda template
in concept definition
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.pogrebnyak at gmail dot com
  Target Milestone: ---

Created attachment 48600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48600&action=edit
gcc version, output, and -save-temps

Definition of the following concept (using C++20) causes segmentation fault in
GCC 10.1.0.

template 
concept Applyable =
  [](std::index_sequence) {
return std::is_invocable_v...>;
  }(std::make_index_sequence>{});

Refactoring the definition into a `constexpr bool` and using it in the concept
definition works.

See the attachment for details.

[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8 Regression] by-ref
   |by-ref capture of constexpr |capture of constexpr class
   |class object rejected   |object rejected

--- Comment #5 from Jason Merrill  ---
Fixed for 9.4/10.2/11.  Is this important to fix in GCC 8?

[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:487f16a7f2a6f849497a0d2f8fff61225e2270f6

commit r8-10272-g487f16a7f2a6f849497a0d2f8fff61225e2270f6
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

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

commit r8-10274-gbc721725161c6ee3813870a734c0b0c18429a922
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: Local class DMI using local static [PR90749]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/90749
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:09831707ce65606f951c97632d882f083ad3ed02

commit r8-10273-g09831707ce65606f951c97632d882f083ad3ed02
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

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

commit r9-8621-gf76202e096fc0be4db21761399b55f10cd09b20d
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:0296697cf9893dc9509cdcd8e3fd4ba9fe422527

commit r9-8623-g0296697cf9893dc9509cdcd8e3fd4ba9fe422527
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

gcc/cp/ChangeLog
2020-05-05  Jason Merrill  

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

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

commit r9-8622-ge153e0ef3a35c2c72e8bf89bd905fe27f8877852
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: Local class DMI using local static [PR90479]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:91664c43c0acf56fd86643530e4b0be78a06446c

commit r9-8620-g91664c43c0acf56fd86643530e4b0be78a06446c
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:4cee81365ad32ef947f500e4cf4b3514d88236c9

commit r10-8180-g4cee81365ad32ef947f500e4cf4b3514d88236c9
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-8182-gc79e664b153bd4cfdeec77b495d595e50b97c752
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: Local class DMI using local static [PR90749]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:01ff88c5619897198117b1a460d48774cfcdf396

commit r10-8181-g01ff88c5619897198117b1a460d48774cfcdf396
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

gcc/cp/ChangeLog
2020-05-01  Jason Merrill  

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-8183-gaa613a81831bdc044840a95a7a7803a235608503
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

gcc/cp/ChangeLog
2020-05-05  Jason Merrill  

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #1 from Jim Wilson  ---
It appears to be failing in the rename register (rnreg) pass.  This is because
the unspec patterns for the save/restore calls don't mention the registers that
they use/modify.  This confuses rename reg into thinking that live regs are
dead, and it accidentally clobbers them before the save call.  This worked OK
when save/restore calls could only be at the beginning or end of a function. 
But now that this works with tail calls and shrink wrapping, we can get them in
inner blocks.  Since the different save/restore calls use/modify different sets
of registers, fixing this gets a little complicated.  Maybe we can just use the
max list of registers because listing extra ones shouldn't matter?

Another solution is to disable the rename register pass when -msave-restore is
used.  This isn't doing any checking for whether regs can be used in compressed
instructions or not.  This is currently encoded in REG_ALLOC_ORDER which this
pass doesn't use.  The result is that this is probably increasing code size
which is undesirable when -msave-restore it used.  Disabling this would reduce
code size and fix the -msave-restore problem.

The rename register pass does use the PREFERRED_RENAME_CLASS hook that we
haven't defined.  We should try defining this to convert registers classes to
subsets that only include the regs that can be used in compressed instructions.
 This might result in a code size decrease.  If this works, then the rename reg
pass should not be disabled, and we should find a way to fix the save/restore
pattern register lists instead.

I need to do some builds and experiments to verify this info.

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Brett Neumeier from comment #9)
> Confirmed, the issue does not occur with 2.33.1. Thank you for your
> attention and help!

Please CC me on the binutils bug (just so I can keep track of it).

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

Brett Neumeier  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||bneumeier at gmail dot com
 Status|WAITING |RESOLVED

--- Comment #9 from Brett Neumeier  ---
Confirmed, the issue does not occur with 2.33.1. Thank you for your attention
and help!

[Bug tree-optimization/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
  Component|fortran |tree-optimization
 Status|WAITING |NEW

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to David Binderman from comment #3)
> (In reply to anlauf from comment #1)
> > local.f90:3: Error: Can't open included file 'SIZES'
> > 
> > Please include everything needed to reproduce.
> 
> Done.
> 
> > Are you sure this is a fortran bug, rather than tree-optimization?
> 
> Not using -O2 makes the code compile, so something in the optimiser
> is going wrong, triggered by Fortran source code.

OK, using -O0, -Og, or -Os makes the code compile, -O1, -O2 or higher ICEs.

This looks fishy.

I'd prefer someone with better middle-end knowledge to look at it.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch submmitted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054385.html

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Obvious fix:

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7712dc74d1..99844812505 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2836,9 +2836,10 @@ copy_derived_types:
  && (c->attr.allocatable || c->attr.pointer)
  && !derived->attr.is_class)
{
- char caf_name[GFC_MAX_SYMBOL_LEN];
+ /* Provide sufficient space to hold "_caf_symbol".  */
+ char caf_name[GFC_MAX_SYMBOL_LEN + 6];
  gfc_component *token;
- snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
+ snprintf (caf_name, sizeof (caf_name), "_caf_%s", c->name);
  token = gfc_find_component (derived, caf_name, true, true, NULL);
  gcc_assert (token);
  c->caf_token = token->backend_decl;

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to anlauf from comment #1)
> local.f90:3: Error: Can't open included file 'SIZES'
> 
> Please include everything needed to reproduce.

Done.

> Are you sure this is a fortran bug, rather than tree-optimization?

Not using -O2 makes the code compile, so something in the optimiser
is going wrong, triggered by Fortran source code.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE in  |[Coarray] ICE in
   |gfc_get_derived_type, at|gfc_get_derived_type, at
   |fortran/trans-types.c:2843  |fortran/trans-types.c:2843
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
All versions from 7 to 11 (master) ICE.

Confirmed.

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Created attachment 48599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48599&action=edit
Fortran header file

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
local.f90:3: Error: Can't open included file 'SIZES'

Please include everything needed to reproduce.

Are you sure this is a fortran bug, rather than tree-optimization?

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Note I think it is related to the fixes that was done for
https://sourceware.org/bugzilla/show_bug.cgi?id=2 which was fixed in 2.34.

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Brett Neumeier from comment #6)
> I can try again with 2.33.1 and see if I get different results, if that
> would help?

If it works with 2.33.1, can you report this directly to binutils:
https://sourceware.org/bugzilla ?  Since this is a bug in binutils as far as I
can tell.

[Bug fortran/95323] New: ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

Bug ID: 95323
   Summary: ice in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 48598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48598&action=edit
fortran source code

For the attached Fortran code, recent gfortran trunk does this:

$ gfortran -O2 -w  -c local.f
during GIMPLE pass: lim
local.f:1:0:

1 |   SUBROUTINE LOCAL(C,MDIM,NOCC,EIG)
  |
internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
0xef51a9 compute_live_loop_exits(bitmap_head*, bitmap_head*, bitmap_head**,
basic_block_def*)
../../trunk.git/gcc/tree-ssa-loop-manip.c:247
0xef51a9 add_exit_phis_var(tree_node*, bitmap_head*, bitmap_head**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:334
0xef51a9 add_exit_phis(bitmap_head*, bitmap_head**, bitmap_head**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:356
0xef51a9 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../trunk.git/gcc/tree-ssa-loop-manip.c:678

The bug first seems to occur sometime between 20200521 and 20200522

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #6 from Brett Neumeier  ---
The host binutils (used to compile the cross-toolchain):

$ as --version
GNU assembler (GNU Binutils) 2.34.0.20200507
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.

The cross-binutils is:

$ ./aarch64-cbl-linux-gnu-as --version
GNU assembler (GNU Binutils) 2.34.0.20200517
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `aarch64-cbl-linux-gnu'.

So, pretty much the same, the cross-toolchain has more updates from the
binutils 2.34 branch.

I can try again with 2.33.1 and see if I get different results, if that would
help?

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
The assembler code works for me with binutils 2.33.1.  So again which version
of binutils are you using for the cross compiler?

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|bootstrap   |middle-end
   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
   Keywords||assemble-failure, build

--- Comment #4 from Andrew Pinski  ---
What binutils version you are using?

orr x4, x4, x7
.LVL33:
.loc 1 170 12 view .LVU92
.LBE26:
.LBE25:
.LBE24:
.loc 1 263 7 is_stmt 1 view .LVU93
.p2align 3,,7
.L36:
.loc 1 281 4 view .LVU94
.loc 1 282 35 is_stmt 0 view .LVU95
and w6, w5, 112

This seems like a bug in binutils to me.
The only difference between with/without -fno-align-loops is the line marked
with .

[Bug libstdc++/95322] New: std::list | take | transform, expression does not work cbegin() == end()

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

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

Bug ID: 95322
   Summary: std::list | take | transform, expression does not work
cbegin() == end()
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hello gcc-team,

I'm not sure if this is intended behaviour, or if this is a defect in the
standard, or something that you should never write in a generic context.

ASFAIK you can use that expression on any container and on any view, but not on
some(?!) combinations of views? This is a bit unexpected.

```c++
#include 
#include 
#include 

int main()
{

std::list v{0,1 ,2, 3, 4, 5, 5, 6}; // works if std::vector

auto view1 = v | std::views::take(5);
auto view2 = v | std::views::transform([] (int i) { return i + 3;});
auto view3 = view1 | std::views::transform([] (int i) { return i + 3;});

std::ranges::cbegin(view1) == std::ranges::end(view1); // works
std::ranges::cbegin(view2) == std::ranges::end(view2); // works
std::ranges::cbegin(view3) == std::ranges::end(view3); // does not work
return 0;
}
```

https://godbolt.org/z/4Nzr69

[Bug c++/95321] Run-time crash on valid destructor code

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #3 from Francois-Xavier Coudert  ---
I don't have certainty it's not undefined behaviour, sorry. Closing.

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Uroš Bizjak from comment #5)
> This testcase is fixed by [1]
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546408.html

Interesting. I've done quite a bit of cooperlake specific testing and 
found some bugs in gcc trunk.

AFAIK cooperlake is recent Intel. Is there a newer -march
setting I could usefully test or is cooperlake recent enough ?

Also, AFAIK Zen version 2 is a recent AMD -march setting.
Is there a newer AMD -march setting I could usefully test ?

A complete compile of Fedora Linux, with about 6,700 packages,
seems to be a good testcase for recent gcc trunk.

[Bug c++/95321] Run-time crash on valid destructor code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is valid:
> BY the time operator delete gets called the deconstructor is called and
> therefor the object no longer exists therefor:
> void operator delete (void * ptr)
> {
> if (ptr != nullptr) static_cast(ptr)->Destroy();
> }
> 
> Is invalid code as the vtable in ptr is no longer valid.
s/invalid/undefined/

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
@egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC
patches mailing list.

[Bug c++/95321] Run-time crash on valid destructor code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I don't think this is valid:
BY the time operator delete gets called the deconstructor is called and
therefor the object no longer exists therefor:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}

Is invalid code as the vtable in ptr is no longer valid.

Where is this code from?

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
I see no conversion there?

But, why does it it store to memory at all?

[Bug c++/95321] New: Run-time crash on valid destructor code

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 95321
   Summary: Run-time crash on valid destructor code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

// Run-time crash with g++ >= 9 and -Ox, x > 1
// Works perfectly with g++ <= 8.3
class IDestroyable
{
protected:
virtual void  Destroy() = 0;

public:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}
};

class IToto
{
public:
virtual void  Toto() = 0;
};

class ITotoDestroyable : public IToto, public IDestroyable
{
public:
void operator delete (void * ptr)
{
if (ptr != nullptr) delete static_cast(static_cast(ptr));
}
};

template 
class DestroyableBase : public INTERFACE
{
protected:
virtual void  Destroy()
{
::delete this;
}

public:
virtual ~DestroyableBase()
{
}

void operator delete (void * ptr)
{
::operator delete (ptr);
}
};

#include 

class TotoDestroyable : public DestroyableBase
{
public:
~TotoDestroyable()
{
std::cout << "OK Destroyed !\n";
}

void  Toto()
{
std::cout << "Toto !\n";
}
};

int main()
{
ITotoDestroyable * foo = new TotoDestroyable();
// Uncomment to workaround the crash
// foo->Toto();
delete foo;
}



Segfaults at runtime when compiled with G++ >= 9 and -O1 or higher.

Process 52619 launched: '/tmp/a.out' (x86_64)
Process 52619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00010d44 a.out`main [inlined] IDestroyable::operator
delete(ptr=0x000100604858) at a.cpp:11:70
   8public:
   9void operator delete (void * ptr)
   10   {
-> 11   if (ptr != nullptr) static_cast(ptr)->Destroy();
   12   }
   13   };
   14

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Forgot to mention: That's still the cc1 compiler
(libexec/gcc/x86_64-none-linux-gnu/11.0.0/cc1) not yet an offloading LTO.

The problem seems to be the followingat ipa-utils.h:246:
  /* We do not have this information when not in LTO, but we do not need
 to care, since it is used only for type merging.  */
  gcc_checking_assert (in_lto_p || flag_lto);


Here, we do not compile with LTO but write LTO for offloading.

That code is called by local_tree_p which was added by
r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f , Honza's
  "Avoid SCC hashing on unmergeable trees"
patch of May 20, 2020.

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug ipa/95320] New: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

Bug ID: 95320
   Summary: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246,
during IPA pass: pure-const
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

For some reason, this only occurs when compiling for AMDGCN and it seems to be
a recent regression.

The issue seems to affect nearly all testcases in libgomp, I get 2500+ FAIL.

For instance
  gcc -fopenmp libgomp/testsuite/libgomp.c-c++-common/for-11.c
fails as:

during IPA pass: fnsummary
src/gcc-mainline/libgomp/testsuite/libgomp.c-c++-common/for-11.c:5: internal
compiler error: in odr_type_p, at ipa-utils.h:246
0x8b3ccf odr_type_p(tree_node const*)
gcc-mainline/gcc/ipa-utils.h:246
0x8b3ccf local_tree_p
gcc-mainline/gcc/lto-streamer-out.c:594
0x8b3ccf DFS::DFS(output_block*, tree_node*, bool, bool, bool)
gcc-mainline/gcc/lto-streamer-out.c:639


Breakpoint 1, DFS::DFS(output_block*, tree_node*, bool, bool, bool) () at
gcc-mainline/gcc/lto-streamer-out.c:639
639   if (ob->local_trees && local_tree_p (expr))
(gdb) p ob
$1 = 
(gdb) p expr
$2 = (tree) 0x7734ac78
(gdb) p debug_tree(expr)
 

[Bug c++/95319] New: Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class

[haldormnk at hotmail dot com]

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

Bug ID: 95319
   Summary: Regression from gcc9.3 when inserting into a vector
with an initializer list. Error: a GNU-style
designated initializer for class
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haldormnk at hotmail dot com
  Target Milestone: ---

https://godbolt.org/z/zZtP9z

#include 
#include 
#include 
int main() {
using Array = std::array;
using ArrayVector = std::vector;
auto vector = ArrayVector();
vector.emplace_back(Array({1,1,1})); // works
vector.insert(std::end(vector),{{2,2,2}}); // fails in gcc10.1
}

With gcc9.3 it compiles, but with gcc10.1, there is an error in the last line:

error: '[0] =' used in a GNU-style designated initializer for class
'std::array'

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #3 from Brett Neumeier  ---
Created attachment 48596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48596&action=edit
result of compilation with -fno-align-loop specified

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #2 from Brett Neumeier  ---
Created attachment 48595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48595&action=edit
result of compilation with default settings

[Bug bootstrap/95318] New: gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

Bug ID: 95318
   Summary: gcc 10.1 on x86_64 fails to build aarch64
cross-compiler when using default optimization
settings
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bneumeier at gmail dot com
  Target Milestone: ---

This issue is seen when building an X86_64-to-AArch64 cross-compiler
using GCC 10.1.

`gcc -v` on the host computer reports:
--
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cbl/cbltools/libexec/gcc/x86_64-pc-linux-gnu/10.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /path/to/gcc-10.1.0/configure
  --prefix=/home/cbl/cbltools --with-local-prefix=/home/cbl/cbltools
  --disable-multilib --disable-nls --enable-shared
  --enable-languages=c,c++ --enable-c99 --enable-long-long
  --enable-threads=posix --with-gmp=/home/cbl/cbltools
  --with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
  --with-isl=/home/cbl/cbltools
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.1 20200507 (GCC)
--

The cross-compiler build was configured with:

../gcc-10.1.0/configure --prefix=/home/cbl/work/cross-tools
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=aarch64-cbl-linux-gnu --with-sysroot=/home/cbl/work/sysroot
--with-build-sysroot=/home/cbl/work/sysroot --disable-decimal-float
--disable-libgomp --disable-libmudflap --disable-libssp --disable-multilib
--disable-nls --disable-shared --disable-threads --enable-languages=c,c++
--with-newlib --without-headers --with-gmp=/home/cbl/cbltools
--with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
--with-isl=/home/cbl/cbltools --enable-fix-cortex-a53-835769
--enable-fix-cortex-a53-843419 --with-cpu=cortex-a72.cortex-a53

The issue is encountered after successfully completing the `all-gcc` make
target, and running `make all-target-libgcc`. Compilation of libgcc/unwind-c.c
produces errors:

/home/cbl/work/build/build-gcc-2/./gcc/xgcc
-B/home/cbl/work/build/build-gcc-2/./gcc/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/bin/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/lib/ -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/include -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/sys-include
--sysroot=/home/cbl/work/sysroot   -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I.
-I. -I../.././gcc -I/home/cbl/work/build/gcc-10.1.0/libgcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/.
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../gcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../include  -DHAVE_CC_TLS  -o
unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c
/home/cbl/work/build/gcc-10.1.0/libgcc/unwind-c.c -fvisibility=hidden
-DHIDE_EXPORTS

/tmp/cc3usGId.s: Assembler messages:
/tmp/cc3usGId.s: Error: invalid operands (*ABS* and *GAS `expr' section*
sections) for `*' when setting `.LVU94'
/tmp/cc3usGId.s: Error: can't resolve value for symbol `.LVU94'

If I add the `-fno-align-loops` directive, this avoids the errors.

I'm attaching the preprocessed source `unwind-c.i`, and the compiled
`unwind-c.s` both with `-fno-align-loops` (working) and without (error).

After adding `-fno-align-loops` as a workaround, the cross-compiler build
completes without further issues. However, actually using the resulting
cross-compiler to build a target-native GCC (again, unless -fno-align-loops is
specified) fails with similar error messages on several other files, e.g.:

aarch64-cbl-linux-gnu-g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/home/cbl/work/build/gcc-10.1.0/gcc -I/home/cbl/work/build/gcc-10.1.0/gcc/.
-I/home/cbl/work/build/gcc-10.1.0/gcc/../include
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libcpp/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include 
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libbacktrace
-I/home/cbl/work/sysroot/scaffolding/include  -o gimple-low.o -MT gimple-low.o
-MMD -MP -MF ./.deps/gimple-low.TPo
/home/cbl/work/build/gcc-10.1.0/gcc/gimple-low.c
/tmp/ccMqyaI0.s: Assemb

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #1 from Brett Neumeier  ---
Created attachment 48594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48594&action=edit
preprocessed source

[Bug c++/95317] New: [7 regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 95317
   Summary: [7 regression] ICE on valid C++14 code, in
tsubst_copy, at cp/pt.c:15649
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

ICE on valid C++14 code:

$ cat b.C
#include 

template 
struct num
{
enum { value = I };
};

#define VALUEOFNUM(x) std::remove_reference_t::value


template 
void foo()
{
auto test = [&](auto i)
{
enum { VALUE = VALUEOFNUM(i) };
std::cout << VALUE;
};

test(num<0>());
test(num<1>());
}

int main()
{
foo();
}

$ g++-9 b.C 
b.C: In instantiation of 'void foo() [with TYPE = void]':
b.C:27:15:   required from here
b.C:18:22: internal compiler error: in tsubst_copy, at cp/pt.c:15649
   18 | std::cout << VALUE;
  |  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



Works fine with GCC up to version 6, but regresses at 7 and later.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Sorry about that; thanks for trying.  I think I can figure out a reproducer,
and will try tomorrow.

[Bug other/95316] New: [10 Regression] binary built with -fopenacc fails to run when not all offload compilers are installed that were configured

[doko at debian dot org]

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

Bug ID: 95316
   Summary: [10 Regression] binary built with -fopenacc fails to
run when not all offload compilers are installed that
were configured
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

This is usage regression; in gcc-9 building with

  gcc-9 -o mandel-accel mandel.c -Wall -O2 -fopenacc

and running the mandel-accel binary works, if the nvptx offload compiler is
installed.

Building that with gcc-10 leads to:

$ gcc-10 -o mandel-accel mandel.c -Wall -O3 -fopenacc
lto-wrapper: fatal error: could not find accel/amdgcn-amdhsa/mkoffload in
/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
(consider using ‘-B’)
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

because gcc-10 was configured with more than one offload target.  Installing
all configured offload compilers works around it, or building for the offload
targets explicitly (-foffload=nvptx-none).

Expected behavior:  Just print a warning when an offload compiler for a target
cannot be found.

Note: the packaged compilers for Debian/Ubuntu are gcc-10, gcc-10-offload-nvptx
and gcc-10-offload-amdgcn.

See https://launchpad.net/bugs/1878760

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #9 from Arseny Solokha  ---
Created attachment 48593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48593&action=edit
Diff between assembler output produced by gcc and g++ 11

Though there are no flexible array members in C++, is it expected for g++ to
behave differently w/ this testcase?

While compiling it w/ gcc yeilds the following, which is expected:

% gcc-11.0.0 -c gcc/testsuite/gcc.dg/builtin-object-size-21.c
gcc/testsuite/gcc.dg/builtin-object-size-21.c:29:14: error: size of variable
'xm3_4' is too large
   29 | struct Ax_m3 xm3_4 = { { 0 }, { 1, 2, 3, 3 } };   // { dg-error "too
large" }
  |  ^
gcc/testsuite/gcc.dg/builtin-object-size-21.c:43:14: error: size of variable
'xmx_1' is too large
   43 | struct Ax_mx xmx_1 = { { 0 }, { 1 } };// { dg-error "too
large" }
  |

W/ g++ I have

% g++-11.0.0 -c gcc/testsuite/gcc.dg/builtin-object-size-21.c
/tmp/ccPBumhF.s: Assembler messages:
/tmp/ccPBumhF.s: Fatal error: can't write 14 bytes to section .text of
/tmp/ccj6lymE.o: 'file truncated'
/usr/lib/gcc/x86_64-unknown-linux-gnu/11.0.0/../../../../x86_64-unknown-linux-gnu/bin/as:
BFD (Gentoo 2.34 p4) 2.34.0 assertion fail
/var/tmp/portage/sys-devel/binutils-2.34-r1/work/binutils-2.34/bfd/elf.c:3169
/tmp/ccPBumhF.s: Fatal error: can't close /tmp/ccj6lymE.o: file truncated

because of

[pid 1165642] openat(AT_FDCWD, "builtin-object-size-21.o",
O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
<…>
[pid 1165642] fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 1165642] lseek(3, -9223372036854775808, SEEK_SET) = -1 EINVAL (Invalid
argument)

Or, when writing to an "endless" file w/ -o /dev/null:

[pid 1164514] lseek(3, -9223372036854775808, SEEK_SET) = 0
[pid 1164514] read(3, "", 640)  = 0
[pid 1164514] lseek(3, 640, SEEK_CUR)   = 0
[pid 1164514] write(3, "\0builtin-object-size-21.c\0xm3_0\0"..., 96) = 96
[pid 1164514] lseek(3, 0, SEEK_SET) = 0
[pid 1164514] read(3, "", 4096) = 0
[pid 1164514] lseek(3, 64, SEEK_CUR)= 0
[pid 1164514] write(3, "UH\211\345\220]\303UH\211\345\220]\303", 14) = 14
[pid 1164514] lseek(3, 0, SEEK_SET) = 0
[pid 1164514] read(3, "", 4096) = 0
[pid 1164514] lseek(3, 96, SEEK_CUR)= 0
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[bouanto at zoho dot com]

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

--- Comment #5 from bouanto at zoho dot com ---
The reproducer generates a file where the function create_code only contains
this:

  /* Replay of API calls for ctxt_0x7f8079128680.  */

So, no code is actually generated and thus, does not reproduce this issue.

[Bug middle-end/95315] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||jakub at gcc dot gnu.org

[Bug middle-end/95315] New: [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry)

[asolokha at gmx dot com]

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

Bug ID: 95315
   Summary: [11 Regression] ICE: Segmentation fault (in
lookup_page_table_entry)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200524 snapshot (g:d176184d98a00ab379ae5959aed1908a79995e6b)
ICEs when compiling gcc/testsuite/c-c++-common/gomp/declare-variant-5.c w/ -O2
-fopenmp --param ggc-min-heapsize=0:

% gcc-11.0.0 -O2 -fopenmp --param ggc-min-heapsize=0 -c
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c: In function 'test':
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c:36:1: internal compiler
error: Segmentation fault
   36 | }
  | ^
0xd9fcff crash_signal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/toplev.c:328
0x8af45b lookup_page_table_entry
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:630
0x8af45b ggc_set_mark(void const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:1544
0xb0b331 gt_ggc_mx_symtab_node(void*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/build/gcc/gtype-desc.c:1300
0xc58316 gt_ggc_mx_omp_declare_variant_base_entry(void*)
./gt-omp-general.h:47
0xc58316 gt_ggc_mx_omp_declare_variant_base_entry(void*)
./gt-omp-general.h:41
0xc58316 gt_ggc_mx(omp_declare_variant_base_entry*&)
./gt-omp-general.h:65
0xc55121
ggc_remove::ggc_mx(omp_declare_variant_base_entry*&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-traits.h:237
0xc55121
ggc_remove::ggc_maybe_mx(omp_declare_variant_base_entry*&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-traits.h:244
0xc55121 gt_ggc_mx
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-table.h:1163
0xc55121 gt_ggc_mx_hash_table_omp_declare_variant_alt_hasher_(void*)
./gt-omp-general.h:90
0xc55121 gt_ggc_mx_hash_table_omp_declare_variant_alt_hasher_(void*)
./gt-omp-general.h:85
0xa93055 ggc_mark_root_tab
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-common.c:78
0xa9336c ggc_mark_roots()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-common.c:95
0x8afdc8 ggc_collect()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:2220

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:

// { dg-do link }

typedef __PTRDIFF_TYPE__ ptrdiff_t;

template 
class I
{
public:
  typedef ptrdiff_t difference_type;
  I ();
  ~I ();
  I (T *);
  I (const I &);
  T &operator * ();
  T *operator -> ();
  T &operator [] (const difference_type &) const;
  I &operator = (const I &);
  I &operator ++ ();
  I operator ++ (int);
  I &operator -- ();
  I operator -- (int);
  I &operator += (const difference_type &);
  I &operator -= (const difference_type &);
  I operator + (const difference_type &) const;
  I operator - (const difference_type &) const;
  template  friend bool operator == (I &, I &);
  template  friend bool operator == (const I &, const I &);
  template  friend bool operator < (I &, I &);
  template  friend bool operator < (const I &, const I &);
  template  friend bool operator <= (I &, I &);
  template  friend bool operator <= (const I &, const I &);
  template  friend bool operator > (I &, I &);
  template  friend bool operator > (const I &, const I &);
  template  friend bool operator >= (I &, I &);
  template  friend bool operator >= (const I &, const I &);
  template  friend typename I::difference_type operator - (I
&, I &);
  template  friend typename I::difference_type operator - (const
I &, const I &);
  template  friend I operator + (typename I::difference_type
, const I &);
private:
  T *p;
};
template  I::I () : p (0) {}
template  I::~I () {}
template  I::I (T *x) : p (x) {}
template  I::I (const I &x) : p (x.p) {}
template  T &I::operator * () { return *p; }
template  T *I::operator -> () { return p; }
template  T &I::operator [] (const difference_type &x) const {
return p[x]; }
template  I &I::operator = (const I &x) { p = x.p; return
*this; }
template  I &I::operator ++ () { ++p; return *this; }
template  I I::operator ++ (int) { return I (p++); }
template  I &I::operator -- () { --p; return *this; }
template  I I::operator -- (int) { return I (p--); }
template  I &I::operator += (const difference_type &x) { p +=
x; return *this; }
template  I &I::operator -= (const difference_type &x) { p -=
x; return *this; }
template  I I::operator + (const difference_type &x) const {
return I (p + x); }
template  I I::operator - (const difference_type &x) const {
return I (p - x); }
template  bool operator == (I &x, I &y) { return x.p == y.p;
}
template  bool operator == (const I &x, const I &y) { return
x.p == y.p; }
template  bool operator != (I &x, I &y) { return !(x == y); }
template  bool operator != (const I &x, const I &y) { return
!(x == y); }
template  bool operator < (I &x, I &y) { return x.p < y.p; }
template  bool operator < (const I &x, const I &y) { return
x.p < y.p; }
template  bool operator <= (I &x, I &y) { return x.p <= y.p;
}
template  bool operator <= (const I &x, const I &y) { return
x.p <= y.p; }
template  bool operator > (I &x, I &y) { return x.p > y.p; }
template  bool operator > (const I &x, const I &y) { return
x.p > y.p; }
template  bool operator >= (I &x, I &y) { return x.p >= y.p;
}
template  bool operator >= (const I &x, const I &y) { return
x.p >= y.p; }
template  typename I::difference_type operator - (I &x, I
&y) { return x.p - y.p; }
template  typename I::difference_type operator - (const I &x,
const I &y) { return x.p - y.p; }
template  I operator + (typename I::difference_type x, const
I &y) { return I (x + y.p); }

void
bar (I &a)
{
}

void
foo (const I &a, const I &b)
{
  I i;
  #pragma omp distribute parallel for
  for (i = a; i < b; i++)
bar (i);
}

int
main ()
{
  int a[64];
  foo (&a[0], &a[63]);
}

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
For e.g.
void bar (I &a);

void
foo (I &a)
{
  #pragma omp task //firstprivate (a)
  bar (a);
}
with the same templates this is handled by omp_cxx_notice_variable, which will
1068  get_copy_ctor (type, tf_none);
1069  get_dtor (type, tf_none);
because when it is done only during gimplification, we don't instantiate it
anymore.
So, I think I need to go through all the lang_hooks.decls.omp_finish_clause
calls in the gimplifier and deal with it similarly during genericization time.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
unshare_expr can handle that.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Thanks Jakub, that sounds like the problem: I'm creating a tree per
playback::rvalue (m_inner), and I need to unshare them.

[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

 Status|ASSIGNED|WAITING

--- Comment #8 from Richard Biener  ---
Can you check if the FAILs still occur after
g:dc0c0196340f7ac58b10d0042d7cea776d6f7864

[Bug target/95261] [11 regression] gcc.target/powerpc/pr80695-p8.c and gcc.target/powerpc/pr80695-p9.c fail starting with r11-478

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Richard Biener  ---
g:dc0c0196340f7ac58b10d0042d7cea776d6f7864 might have fixed this, can you
verify?

[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

--- Comment #7 from Richard Biener  ---
*** Bug 95266 has been marked as a duplicate of this bug. ***

[Bug target/95266] [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on power 7

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Richard Biener  ---
Dup.

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

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed (on ip2000-elf).

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-615-gdc0c0196340f7ac58b10d0042d7cea776d6f7864
Author: Richard Biener 
Date:   Mon May 25 13:06:03 2020 +0200

tree-optimization/95309 - fix invariant SLP node costing

This makes sure to compute SLP_TREE_NUMBER_OF_VEC_STMTS during SLP
analysis even for invariant / external nodes so costing properly
knows what to cost.

2020-05-25  Richard Biener  

PR tree-optimization/95309
* tree-vect-slp.c (vect_get_constant_vectors): Move number
of vector computation ...
(vect_slp_analyze_node_operations): ... to analysis phase.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Generally, most of the trees (with some exceptions) aren't shareable and
shouldn't be used by multiple different functions.  During gimplifications the
function body is unshared, but not sure what the JIT FE does exactly.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Paging language experts.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #10)
> 1 + (size_t) -1 give 0

It wasn't obvious to me that the operation was supposed to happen in some C/C++
type (they don't say which one) or in a mathematical, infinite-precision sense.
After all, they write 0≤i−j≤n which shouldn't be interpreted as C++ code. But
you have more experience with reading these things, I believe you.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for reporting it; this sounds like a bug.

Please can you use attach a reproducer (e.g. using
gcc_jit_context_dump_reproducer_to_file).

Looking at the backtrace, it looks like a bad interaction with inlining, FWIW.

[Bug jit/95314] New: Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[bouanto at zoho dot com]

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

Bug ID: 95314
   Summary: Sharing a local reference to a global variable in
multiple functions results in location references
block not in block tree
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
If a create, in a function, a reference (with gcc_jit_lvalue_get_address) to a
global and reuse this local reference in another function, it gives the
following error:

libgccjit.so: error: location references block not in block tree
…
during IPA pass: *free_lang_data
libgccjit.so: error: verify_gimple failed
0x7f83924b35c9 verify_gimple_in_cfg(function*, bool)
../../gcc-10.1.0/gcc/tree-cfg.c:5462
0x7f839236a819 execute_function_todo
../../gcc-10.1.0/gcc/passes.c:1985
0x7f839236add7 do_per_function
../../gcc-10.1.0/gcc/passes.c:1647
0x7f839236b06b do_per_function
../../gcc-10.1.0/gcc/passes.c:2050
0x7f839236b06b execute_todo
../../gcc-10.1.0/gcc/passes.c:2039

I can try to make an example to reproduce this issue if needed.

Is that the expected behavior or should libgccjit gives a proper error?

(Recreating the reference in every function fix this issue.)

Thanks.

[Bug fortran/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Likewise crashing is:
  !$omp target map(tofrom: i) map(i)

[Bug fortran/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
  Component|middle-end  |fortran

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
  integer :: i
  i = 1
!$omp target map(tofrom: i) firstprivate (i)
  i = i + 1
!$omp end target
end
For C/C++,
void
foo (int i)
{
#pragma omp target map(tofrom: i) firstprivate (i)
  i++;
}

void
bar (int i)
{
#pragma omp target firstprivate (i) map(tofrom: i)
  i++;
}
is rejected already in the FE, so I think we just miss rejecting it in the
Fortran FE.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
The libgfortran bug is now PR 95313 .

[Bug middle-end/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[john.donners at atos dot net]

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

--- Comment #2 from John Donners  ---
hmm, indeed I found the applicable text in the standard (2.14) as well:
"The effect of the firstprivate clause is as if it is applied to one or more
constructs as follows: To the target construct if it is among the constituent
constructs and the same list item does not appear in a lastprivate or map
clause."

Apologies for the invalid code. Splitting the two works without problems.

[Bug libfortran/95313] New: Possible overflow in itoa_buf

[tkoenig at gcc dot gnu.org]

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

Bug ID: 95313
   Summary: Possible overflow in itoa_buf
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For gcc 10 and 11, a possible overflow in itoa_buf is detected. The error
message is strange, see PR 95276 . This is about the buffer overflow
itself.

[Bug middle-end/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
  Component|libgomp |middle-end

--- Comment #1 from Jakub Jelinek  ---
The testcase is not valid, target construct accepts both map and firstprivate
clauses and specifying both mapping and data-sharing for the same list item is
invalid, you need to choose one.

[Bug tree-optimization/95308] [10 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:67bfbda18f4e6d0d30ad8f8790f1d0d4653131ed

commit r11-610-g67bfbda18f4e6d0d30ad8f8790f1d0d4653131ed
Author: Richard Biener 
Date:   Mon May 25 13:48:57 2020 +0200

tree-optimization/95308 - really avoid forward propagating of &TMR

This fixes a hole that still allowed forwarding of TARGET_MEM_REF
addresses.

2020-05-25  Richard Biener  

PR tree-optimization/95308
* tree-ssa-forwprop.c (pass_forwprop::execute): Generalize
test for TARGET_MEM_REFs.

* g++.dg/torture/pr95308.C: New testcase.

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4acca1c0635dfa43cd8c4bfe2b22e17909fc23a3

commit r11-609-g4acca1c0635dfa43cd8c4bfe2b22e17909fc23a3
Author: Richard Biener 
Date:   Mon May 25 10:09:44 2020 +0200

tree-optimization/95295 - fix wrong-code with SM

We failed to compare the rematerialized store values when merging
paths after walking PHIs.

2020-05-25  Richard Biener  

PR tree-optimization/95295
* tree-ssa-loop-im.c (sm_seq_valid_bb): Compare remat stores
RHSes and drop to full sm_other if they are not equal.

* gcc.dg/torture/pr95295-1.c: New testcase.
* gcc.dg/torture/pr95295-2.c: Likewise.
* gcc.dg/torture/pr95283.c: Likewise.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #9)
> pointer-overflow is a cheap check without any context, for ptr + off
> it will do
> uintptr_t res = (uintptr_t) ptr + off;
> if (((intptr_t) res) < 0 ? res > (uintptr_t) ptr : res < (uintptr_t) ptr)
> runtime_diagnostics ();

Mistyped, (intptr_t) off rather than (intptr_t) res obviously.

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
This testcase is fixed by [1]

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546408.html

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Adjusted testcase, so that there is no UB.

void bar (void);

void
foo (long int *x, int y, int *z, int v)
{
  int a[y];
  int b;
  for (b = 0; b < 3; ++b)
z[b] = x[b] + 1.0f;
  if (v)
return;
  bar ();
}

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/95271] ice in vect_get_constant_vectors, at tree-vect-slp.c:3638 since r11-564-g79f0451c67e8ed56

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
So SLP vectorization decides to vectorize the SImode stores with V1SImode
vector stores because the cited revision does not cost the constant as
SLP_TREE_NUMBER_OF_VEC_STMTS is zero for it.  That's because this wasn't
adjusted when changing what SLP node we pass in and we've never computed
SLP_TREE_NUMBER_OF_VEC_STMTS for invariants sofar.

[Bug tree-optimization/95271] ice in vect_get_constant_vectors, at tree-vect-slp.c:3638 since r11-564-g79f0451c67e8ed56

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-608-gc0e27f72358794692e367363940c6383e9ad1e45
Author: Richard Biener 
Date:   Mon May 25 10:36:39 2020 +0200

tree-optimization/95271 - fix bswap vectorization invariant SLP type

This properly updates invariant SLP nodes vector types for bswap
vectorization.

2020-05-25  Richard Biener  

PR tree-optimization/95271
* tree-vect-stmts.c (vectorizable_bswap): Update invariant SLP
children vector type.
(vectorizable_call): Pass down slp ops.

* gcc.dg/vect/bb-slp-pr95271.c: New testcase.

[Bug tree-optimization/95297] ICE: Segmentation fault

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-607-gd31694544d2d805151899ab0a0bc654767035ad6
Author: Richard Biener 
Date:   Mon May 25 11:14:03 2020 +0200

tree-optimization/95297 - handle scalar shift arg for SLP invariant vectype

This skips invariant vector type setting for a scalar shift argument.

2020-05-25  Richard Biener  

PR tree-optimization/95297
* tree-vect-stmts.c (vectorizable_shift): For scalar_shift_arg
skip updating operand 1 vector type.

* g++.dg/vect/pr95297.cc: New testcase.
* g++.dg/vect/pr95290.cc: Likewise.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #8)
> (In reply to Jakub Jelinek from comment #4)
> > There is nothing wrong on addition of -1, whether signed or cast to
> > size_t/uintptr_t, to a pointer,
> 
> Looking at the standard (I am not a pro at that), one could easily interpret
> that p+(size_t)(-1) means adding a huge number to p, not subtracting 1. It
> does not say that the integer is cast to ptrdiff_t or anything like that.

I don't read it that way.
Let's use e.g. the C++ wording:
"Otherwise, if P points to an array element i of an array object x with n
elements, the expressions P + J and J + P (where J has the value j) point to
the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the
expression P - J points to the (possibly-hypothetical) array element i−j of x
if 0≤i−j≤n.
In the (#c4 testcase with the s/p + 1/buf + 1/ fix), i is 1, and j is either
-1 or (size_t) -1.  For both, 1 + -1 or 1 + (size_t) -1 give 0 and thus the
pointer addition is well defined and points to the first element of the object.