[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[edlinger at gcc dot gnu.org via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #10 from Bernd Edlinger  ---
fixed

[Bug tree-optimization/101856] New: match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101856
   Summary: match_arith_overflow checks only
mulv4_optab/umulv4_optab  tables when
smul_highpart_optab/umul_highpart_optab can produce
decent code too
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

While looking at 30314, I Noticed aarch64 was not producing MUL_OVERFLOW for
that test. I tested __builtin_umulll_overflow manually and got:
umulh   x8, x1, x0
cbz x8, 

Which is what I had expected.

Original testcase:
typedef __SIZE_TYPE__ size_t;
extern void *malloc(size_t), abort(void);
void *allocate(size_t num, size_t size) {
size_t total = num * size;

if (total / size != num) abort();
/* call malloc, whatever */
return 0;
}

The code does:

  || (code == MULT_EXPR
  && optab_handler (cast_stmt ? mulv4_optab : umulv4_optab,
TYPE_MODE (type)) == CODE_FOR_nothing))

Oh it seems like there could be caching of reading optab_handler in
match_arith_overflow too.

[Bug target/101849] MMA built-in dies with a verify_gimple failed error

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
If you are using build_simple_mem_ref then the pointer type has to be
"correct",
but you can simply build the MEM_REF with build2 giving it the desired
access type - the pointer type is irrelevant.  Note the TBAA relevant alias set
is represented in the offset operand.

[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug middle-end/30314] optimize multiply-by-constant overflow (wrap) test

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-08-11
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
starting in GCC 11, we produce:
movl$140, %edx
movq%rdi, %rax
mulq%rdx
jo  .L11

Which corresponds to this gimple:
  _7 = .MUL_OVERFLOW (num_3(D), 140);
  _8 = IMAGPART_EXPR <_7>;
  if (_8 != 0)

So it is definitely better than before.

BUT this is not the best code, clang produces (for 64bit):
movabsq $131762457669353941, %rax   # imm = 0x1D41D41D41D41D5
cmpq%rax, %rdi
jb  .LBB0_2

So basically ULONGMAX/140 as described.

So something like:
(simplify
 (imagpart (IFN_MUL_OVERFLOW:s @0 INTEGER_CST@1))
 (if (TREE_CODE (TYPE_MAX_VALUE (type)) == INTEGER_CST)
  (convert (le @0 (trunc_div { TYPE_MAX_VALUE (type); } @1

[Bug testsuite/101857] New: gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi

[clyon at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101857
   Summary: gfortran.dg/ieee/large_3.F90 fails on
arm-linux-gnueabi
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The new test gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi (but
passes on arm-linux-gnueabihf, so I think this is a testism, but I'm not sure 
- I am not fluent in fortran)

Flags at line 56:  
STOP 1
FAIL: gfortran.dg/ieee/large_3.F90   -O0  execution test

[Bug c/101858] New: [12 Regression] ICE: ‘verify_gimple’ failed

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 101858
   Summary: [12 Regression] ICE: ‘verify_gimple’ failed
   Product: gcc
   Version: 12.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 test.c 

int foo(a)
{
if ( a < (int*)(1LL << a))
a = 0;

return a;
}



$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210729 (experimental)
Copyright (C) 2021 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-sp12 test.c 
test.c: In function ‘foo’:
test.c:2:5: warning: type of ‘a’ defaults to ‘int’ [-Wimplicit-int]
2 | int foo(a)
  | ^~~
test.c:4:12: warning: comparison between pointer and integer
4 | if ( a < (int*)(1LL << a))
  |^
test.c:2:5: error: type mismatch in ‘rshift_expr’
2 | int foo(a)
  | ^~~
int *
int *
int
_3 = _2 >> a;
test.c:2:5: internal compiler error: ‘verify_gimple’ failed
0xecbccd verify_gimple_in_seq(gimple*)
../../gcc-12-20210801/gcc/tree-cfg.c:5183
0xbe644a gimplify_body(tree_node*, bool)
../../gcc-12-20210801/gcc/gimplify.c:15539
0xbe657d gimplify_function_tree(tree_node*)
../../gcc-12-20210801/gcc/gimplify.c:15610
0xa1ed77 cgraph_node::analyze()
../../gcc-12-20210801/gcc/cgraphunit.c:670
0xa218f7 analyze_functions
../../gcc-12-20210801/gcc/cgraphunit.c:1234
0xa225bd symbol_table::finalize_compilation_unit()
../../gcc-12-20210801/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210717
Copyright (C) 2021 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-sp11 test.c 
test.c: In function ‘foo’:
test.c:2:5: warning: type of ‘a’ defaults to ‘int’ [-Wimplicit-int]
2 | int foo(a)
  | ^~~
test.c:4:12: warning: comparison between pointer and integer
4 | if ( a < (int*)(1LL << a))
  |^
/usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status

[Bug c++/101818] Error message for the wrong name in designated initializers could be improved

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #2 from 康桓瑋  ---
(In reply to Andrew Pinski from comment #1)
> This is a dup of bug 95085.
> 
> *** This bug has been marked as a duplicate of bug 95085 ***

I don't think this is a dup of PR 95085. In 95085, Barry described the error
message for this case as "gcc's diagnostic is absolutely excellent", but it is
obviously misleading.

[Bug c++/101859] New: Misleading error message in designated initializers

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 101859
   Summary: Misleading error message in designated initializers
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

struct Cat { const char* name; };
struct Zoo { Cat cat; };

int cat;
Zoo zoo{.cat = cat};

Clang rejects it with:
:5:16: error: cannot initialize a member subobject of type 'const char
*' with an lvalue of type 'int'
Zoo zoo{.cat = cat};
   ^~~

MSVC rejects it with:
source>(5): error C2440: 'initializing': cannot convert from 'int' to 'const
char *'

However, GCC rejects it with:
:5:19: error: 'Cat' has no non-static data member named 'cat'
5 | Zoo zoo{.cat = cat};
  |   ^

[Bug fortran/101835] Fortran 128-bit float support, __float128/c_float128 / Supporting PowerPC's three 128-bit / 16-byte REAL data types

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-11
 Status|UNCONFIRMED |NEW
Summary|Fortran 128-bit float   |Fortran 128-bit float
   |support |support,
   ||__float128/c_float128  /
   ||Supporting PowerPC's three
   ||128-bit / 16-byte REAL data
   ||types
 CC||burnus at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
See linked thread for a longer description,
  https://gcc.gnu.org/pipermail/fortran/2021-August/thread.html#56315
  (the link in comment 0 is in the same thread)

However, the following issues exist:

* ISO_C_Binding's c_float128  (gfortran vendor extension)
  has to match __float128  (cf. also comment 0)

* ISO_Fortran_env provides:
  - REAL128 (whose storage size expressed in bits is 128)  [since Fortran 2008]
  - REAL_KINDS - array with supported real kinds (Fortran: no order
requirements)
  In gfortran, it is ordered; e.g. on x86-64 w/ libquadmath: [4,8,10,16]. 

* gfortran currently uses:
  – float, double and long double – which used
GCC's builtins, the 'f','','l' suffixes (sinf, sin, sinl) and uses in
libgfortran those data types
  - TFmode
  - Other real types are filtered out.

* If long double's mode != TFmode, the FE assumes that TFmode is for
  __float128 – and sets info->c_float128 / yield gfc_real16_is_float128() =
true
  However, this assumption is wrong in the general case, e.g. PowerPC has
  __float128 == KFmode and TFmode == 'long double'
  (There is currently no clash as KFmode is filtered out and TFmode == long
double's mode).

  If a real type is regarded as float128, the FE calls the functions with 'q'
  suffix (such as sinq), libgfortran uses __float128 for those and there is
some
  implicit assumption that libquadmath is available, which provides those 'q'
  functions.

* Kind values: Currently supported are
  4, 8, 10 (80bits; i387), 11 (82bits; IA-64, RFmode), 16
  However, kind=11 does not seem to be tested for (and could be better
documented)
  The kind value is generated as:
kind = (GET_MODE_PRECISION (mode) + 7) / 8;
  (The '+ 7' is for IA-64's RFmode to map to kind=11.)

  Fortran itself does not require IEEE support and the kind numbers are
arbitrary,
  albeit users expect that 4 and 8 exists (and match float/double), some expect
that
  16 exists and – only with gfortran – kind=10.
  The proper use is to use either the constants like:  REAL128, use REAL_KINDS
  and the function SELECTED_REAL_KIND
  [IEEE has to be supported for types where IEEE_SUPPORT_DATATYPE () returns
.true.]

* Plus PowerPC:
#define FLOAT_PRECISION_IFmode  128
#define FLOAT_PRECISION_TFmode  127
#define FLOAT_PRECISION_KFmode  126
  with IFmode (IBM 128-bit floating point),
   TFmode (long double mode),
   KFmode (explicit __float128).
  - The current 'kind =' calculation above has kind=16 for all of them.
(except that IFmode and TFmode are filtered out)
  - When adding support for IFmode/KFmode PowerPC mode, the proper library
function has to be called (suffix? ABI in libgfortran?)
  - PowerPC (rs6000) has the command line flags:
 -mfloat128
 Enable/disable the __float128 keyword for IEEE 128-bit floating point
and
 use either software emulation for IEEE 128-bit floating point or
hardware
 instructions.
 -mabi=ibmlongdouble
 Change the current ABI to use IBM extended-precision long double.
 This is not likely to work if your system defaults to using
 IEEE extended-precision long double.
 -mabi=ieeelongdouble
 Change the current ABI to use IEEE extended-precision long double.
 This is not likely to work if your system defaults to using
 IBM extended-precision long double.
  - As kind=16 is explicitly used, it should be supported but, otherwise,
the other kinds can be mapped to any kind value, e.g. 15,16,17.
There are ABI and compatibility issues – but they should be similar to
C/C++.

[Bug c/101858] [12 Regression] ICE: ‘verify_gimple’ failed

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, it's very old (at least 4.9.0+).

[Bug target/101860] New: [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101860
   Summary: [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199
since r12-2837-g50b5877925ef5ae8
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

The following fails:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c
-O1 -mavx5124vnniw -c
during GIMPLE pass: fre
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c: In
function ‘test_27’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c:12:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1199
0x69c2a8 gen_reg_rtx(machine_mode)
/home/marxin/Programming/gcc/gcc/emit-rtl.c:1199
0xafb406 force_reg(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/explow.c:686
0xafb406 force_reg(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/explow.c:666
0x12fe673 ix86_expand_vec_one_operand_perm_avx512
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18124
0x12fe673 expand_vec_perm_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18302
0x12fe820 expand_vec_perm_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18311
0x13007e8 ix86_expand_vec_perm_const_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:20702
0x1328bb2 ix86_vectorize_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
rtx_def*, vec_perm_indices const&)
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:21002
0x14db5ce gimple_simplify_VEC_PERM_EXPR
/dev/shm/objdir/gcc/gimple-match.c:154152
0x13405c8 gimple_resimplify3
/home/marxin/Programming/gcc/gcc/gimple-match-head.c:396
0x14dca97 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/marxin/Programming/gcc/gcc/gimple-match-head.c:1002
0xbb0f10 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
/home/marxin/Programming/gcc/gcc/gimple-fold.c:7330
0x10a1ab5 try_to_simplify
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5428
0x10a1ab5 visit_stmt
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5471
0x10a2d86 process_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7239
0x10a4642 do_rpo_vn
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7837
0x10a5e5a execute
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Last reconfirmed||2021-08-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Liška  ---
Similarly fails:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c
-Og -mavx512vp2intersect
during GIMPLE pass: fre
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c: In
function ‘test_27’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/vshuf-v32hi.c:12:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:1199
0x69c2a8 gen_reg_rtx(machine_mode)
/home/marxin/Programming/gcc/gcc/emit-rtl.c:1199
0xafb406 force_reg(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/explow.c:686
0xafb406 force_reg(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/explow.c:666
0x12fe673 ix86_expand_vec_one_operand_perm_avx512
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18124
0x12fe673 expand_vec_perm_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18302
0x12fe820 expand_vec_perm_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:18311
0x13007e8 ix86_expand_vec_perm_const_1
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:20702
0x1328bb2 ix86_vectorize_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
rtx_def*, vec_perm_indices const&)
/home/marxin/Programming/gcc/gcc/config/i386/i386-expand.c:21002
0x14db5ce gimple_simplify_VEC_PERM_EXPR
/dev/shm/objdir/gcc/gimple-match.c:154152
0x13405c8 gimple_resimplify3
/home/marxin/Programming/gcc/gcc/gimple-match-head.c:396
0x14dca97 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
/home/marxin/Programming/gcc/gcc/gimple-match-head.c:1002
0xbb0f10 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
/home/marxin/Programming/gcc/gcc/gimple-fold.c:7330
0x10a1ab5 try_to_simplify
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5428
0x10a1ab5 visit_stmt
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:5471
0x10a2d86 process_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7239
0x10a4642 do_rpo_vn
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7837
0x10a5e5a execute
/home/marxin/Programming/gcc/gcc/tree-ssa-sccvn.c:7991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug middle-end/101858] [12 Regression] ICE: ‘verify_gimple’ failed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|c   |middle-end
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
#0  build2 (code=RSHIFT_EXPR, tt=, 
arg0=, arg1=)
at /home/rguenther/src/gcc2/gcc/tree.c:4970
#1  0x00eb1bab in fold_binary_loc (loc=2147483651, code=LT_EXPR, 
type=, op0=, 
op1=)
at /home/rguenther/src/gcc2/gcc/fold-const.c:12510

  /* Similarly for X < (cast) (1 << Y).  But cast can't be narrowing,
 otherwise Y might be >= # of bits in X's type and thus e.g.
 (unsigned char) (1 << Y) for Y 15 might be 0.
 If the cast is widening, then 1 << Y should have unsigned type,
 otherwise if Y is number of bits in the signed shift type minus 1,
 we can't optimize this.  E.g. (unsigned long long) (1 << Y) for Y
 31 might be 0x8000.  */
  if ((code == LT_EXPR || code == GE_EXPR)
  && TYPE_UNSIGNED (TREE_TYPE (arg0))
  && CONVERT_EXPR_P (arg1)
  && TREE_CODE (TREE_OPERAND (arg1, 0)) == LSHIFT_EXPR
  && (element_precision (TREE_TYPE (arg1))
  >= element_precision (TREE_TYPE (TREE_OPERAND (arg1, 0
  && (TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (arg1, 0)))
  || (element_precision (TREE_TYPE (arg1))
  == element_precision (TREE_TYPE (TREE_OPERAND (arg1, 0)
  && integer_onep (TREE_OPERAND (TREE_OPERAND (arg1, 0), 0)))
{
  tem = build2 (RSHIFT_EXPR, TREE_TYPE (arg0), arg0,
TREE_OPERAND (TREE_OPERAND (arg1, 0), 1));
  return build2_loc (loc, code == LT_EXPR ? EQ_EXPR : NE_EXPR, type,
 fold_convert_loc (loc, TREE_TYPE (arg0), tem),
 build_zero_cst (TREE_TYPE (arg0)));
}

Mine.

[Bug testsuite/101857] gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Can you check whether that's a duplicate of PR 101847? I bet it is.

Or in other words: whether it still fails after the commit:


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

commit r12-2839-g2ba0376ac40447ce7ee09fcef00511c18db25dfa
Author: Tobias Burnus 
Date:   Tue Aug 10 17:26:32 2021 +0200

gfortran: Fix in-build-tree testing [PR101305, PR101660]

[Bug middle-end/101861] New: [12 Regression] ICE (segfault) via tree-vect-stmts.c:9495's vectorizable_load

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101861
   Summary: [12 Regression] ICE (segfault) via
tree-vect-stmts.c:9495's vectorizable_load
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---
Target: amdgcn-amdhsa

I see the following new ICE – it did work in yesterday's run:


amdgcn-amdhsa-gcc .../testsuite/gcc.dg/loop-versioning-6.c
-fdiagnostics-plain-output -O3 -fdump-tree-lversion-details -S -o
loop-versioning-6.s

during GIMPLE pass: vect
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/testsuite/gcc.dg/loop-versioning-6.c:
In function 'f1':
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/testsuite/gcc.dg/loop-versioning-6.c:12:1:
internal compiler error: Segmentation fault
0xedbd8f crash_signal
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/toplev.c:328
0x114c130 vec::operator[](unsigned int)
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/vec.h:889
0x114c130 vec::operator[](unsigned int)
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/vec.h:1495
0x114c130 vectorizable_load
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vect-stmts.c:9495
0x1157a28 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vect-stmts.c:11062
0x115c9ca vect_transform_loop_stmt
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vect-loop.c:9323
0x11745e5 vect_transform_loop(_loop_vec_info*, gimple*)
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vect-loop.c:9759
0x11a6f9e try_vectorize_loop_1
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vectorizer.c:1103
0x11a77c1 vectorize_loops()
   
/scratch/ci-cs/amdtest/upstream/src/gcc-mainline/gcc/tree-vectorizer.c:1242

 * * *

New FAIL: default/gcc.sum:gcc.dg/loop-versioning-6.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/torture/pr53390.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
New FAIL: default/gcc.sum:gcc.dg/torture/pr53390.c   -O3 -g  (internal compiler
error)
New FAIL: default/gcc.sum:gcc.dg/torture/pr91178-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
New FAIL: default/gcc.sum:gcc.dg/torture/pr91178-2.c   -O3 -g  (internal
compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/O3-pr85794.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/pr53185-2.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/pr53185.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/pr85793.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/pr91403.c (internal compiler error)
New FAIL: default/gcc.sum:gcc.dg/vect/vect-123.c (internal compiler error)
...

[Bug target/101788] [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857 since r12-2728-g2724d1bba6b36451404811fba3244f8897717ef3

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |extract_bit_field_1 at  |extract_bit_field_1 at
   |gcc/expmed.c:1857   |gcc/expmed.c:1857 since
   ||r12-2728-g2724d1bba6b364514
   ||04811fba3244f8897717ef3
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with Richi's r12-2728-g2724d1bba6b36451404811fba3244f8897717ef3.

[Bug middle-end/101861] [12 Regression] ICE (segfault) via tree-vect-stmts.c:9495's vectorizable_load

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-08-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

[Bug testsuite/101857] gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi

[clyon at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Christophe Lyon  ---
Yes I still see that with r12-2842. There were link errors before r12-2839, but
now only this test fails, at execution time. There might be something about
raising exception in soft floating-point mode?

[Bug middle-end/101861] [12 Regression] ICE (segfault) via tree-vect-stmts.c:9495's vectorizable_load

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
OK, so we're having memory_access_type == VMAT_GATHER_SCATTER, gs_info.ifn !=
IFN_LAST but STMT_VINFO_GATHER_SCATTER_P is false.  It looks like vec_offset is
set elsewhere in that case.  Likely here:

  else if (memory_access_type == VMAT_GATHER_SCATTER)
{
  aggr_type = elem_type;
  vect_get_strided_load_store_ops (stmt_info, loop_vinfo, &gs_info,
   &bump, &vec_offset);
}

so the fix is to re-instante the guard, doing

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index ab402b57fb4..cc6c091e41e 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9492,7 +9492,8 @@ vectorizable_load (vec_info *vinfo,
if (memory_access_type == VMAT_GATHER_SCATTER
&& gs_info.ifn != IFN_LAST)
  {
-   vec_offset = vec_offsets[j];
+   if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
+ vec_offset = vec_offsets[j];
tree zero = build_zero_cst (vectype);
tree scale = size_int (gs_info.scale);
gcall *call;

will push this as obvious.

[Bug target/101788] [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857 since r12-2728-g2724d1bba6b36451404811fba3244f8897717ef3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[jakub at gcc dot gnu.org via Gcc-bugs]

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

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

Untested fix.

[Bug middle-end/101862] New: [C, C++] Potential '?:' diagnostic for always-true expressions in boolean context

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101862
   Summary: [C, C++] Potential '?:' diagnostic for always-true
expressions in boolean context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51287&action=edit
'c-c++-common/goacc/prN.c'

Would it be possible for GCC to diagnose the "'?:' misuse" in the attached
C/C++ test case?  No matter what gets stored in 'arr', the 'assert' never
triggers, because what's actually meant here, is:

   for (int i = 0; i < 32; i++)
-assert (arr[i] == ((i % 2) != 0) ? i + 1 : i + 2);
+assert (arr[i] == (((i % 2) != 0) ? i + 1 : i + 2));

This is going to be more complicated than
'gcc/c-family/c-common.c:c_common_truthvalue_conversion', 'case COND_EXPR:',
which diagnoses "'?:' using integer constants in boolean context" for
'INTEGER_CST's -- which these are not, of course.  I suppose we'd need some
value range analysis (so, at some later stage in the pass pipeline?) to see
that 'i + 1'/'i + 2' are always-true expressions in boolean context?

Is this feasible or not?  (..., and if yes, if anybody got any pointers about
where/how to do this...)

[Bug c++/60932] make stdatomic.h compatible with C++

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Note, stdatomic.h is now in C++20.

[Bug target/66791] [ARM] Replace builtins with gcc vector extensions code

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Prathamesh Kulkarni
:

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

commit r12-2848-gb8f604da25bfe0fd4dadbc338293885819fe8018
Author: prathamesh.kulkarni 
Date:   Wed Aug 11 15:30:14 2021 +0530

arm/66791: Replace builtins for vdup_n and vmov_n intrinsics.

gcc/ChangeLog:

PR target/66791
* config/arm/arm_neon.h (vdup_n_s8): Replace call to builtin
with constructor.
(vdup_n_s16): Likewise.
(vdup_n_s32): Likewise.
(vdup_n_s64): Likewise.
(vdup_n_u8): Likewise.
(vdup_n_u16): Likewise.
(vdup_n_u32): Likewise.
(vdup_n_u64): Likewise.
(vdup_n_p8): Likewise.
(vdup_n_p16): Likewise.
(vdup_n_p64): Likewise.
(vdup_n_f16): Likewise.
(vdup_n_f32): Likewise.
(vdupq_n_s8): Likewise.
(vdupq_n_s16): Likewise.
(vdupq_n_s32): Likewise.
(vdupq_n_s64): Likewise.
(vdupq_n_u8): Likewise.
(vdupq_n_u16): Likewise.
(vdupq_n_u32): Likewise.
(vdupq_n_u64): Likewise.
(vdupq_n_p8): Likewise.
(vdupq_n_p16): Likewise.
(vdupq_n_p64): Likewise.
(vdupq_n_f16): Likewise.
(vdupq_n_f32): Likewise.
(vmov_n_s8): Replace call to builtin with call to corresponding
vdup_n intrinsic.
(vmov_n_s16): Likewise.
(vmov_n_s32): Likewise.
(vmov_n_s64): Likewise.
(vmov_n_u8): Likewise.
(vmov_n_u16): Likewise.
(vmov_n_u32): Likewise.
(vmov_n_u64): Likewise.
(vmov_n_p8): Likewise.
(vmov_n_p16): Likewise.
(vmov_n_f16): Likewise.
(vmov_n_f32): Likewise.
(vmovq_n_s8): Likewise.
(vmovq_n_s16): Likewise.
(vmovq_n_s32): Likewise.
(vmovq_n_s64): Likewise.
(vmovq_n_u8): Likewise.
(vmovq_n_u16): Likewise.
(vmovq_n_u32): Likewise.
(vmovq_n_u64): Likewise.
(vmovq_n_p8): Likewise.
(vmovq_n_p16): Likewise.
(vmovq_n_f16): Likewise.
(vmovq_n_f32): Likewise.
* config/arm/arm_neon_builtins.def: Remove entries for vdup_n.

gcc/testsuite/ChangeLog:

PR target/66791
* gcc.target/arm/pr51534.c: Adjust test.

[Bug target/101863] New: ICE: in expand_vec_perm_broadcast_1, at config/i386/i386-expand.c:20485 with -mavx512f

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101863
   Summary: ICE: in expand_vec_perm_broadcast_1, at
config/i386/i386-expand.c:20485 with -mavx512f
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 51288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51288&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512f testcase.c 
during GIMPLE pass: forwprop
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in expand_vec_perm_broadcast_1, at
config/i386/i386-expand.c:20485
5 | foo (V v)
  | ^~~
0x7ec0af expand_vec_perm_broadcast_1
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:20485
0x14e662f expand_vec_perm_broadcast
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:20505
0x14e662f ix86_expand_vec_perm_const_1
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:20716
0x14e662f ix86_expand_vec_perm_const_1
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:20699
0x150e3de ix86_vectorize_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
rtx_def*, vec_perm_indices const&)
/repo/gcc-trunk/gcc/config/i386/i386-expand.c:21002
0x11e68b4 simplify_vector_constructor
/repo/gcc-trunk/gcc/tree-ssa-forwprop.c:2670
0x11e68b4 execute
/repo/gcc-trunk/gcc/tree-ssa-forwprop.c:3405
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-2846-20210811072927-ga45918f8a74-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-2846-20210811072927-ga45918f8a74-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210811 (experimental) (GCC)

[Bug target/101863] ICE: in expand_vec_perm_broadcast_1, at config/i386/i386-expand.c:20485 with -mavx512f

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[Bug target/101860] [12 Regression] ICE in gen_reg_rtx, at emit-rtl.c:1199 since r12-2837-g50b5877925ef5ae8

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug middle-end/101861] [12 Regression] ICE (segfault) via tree-vect-stmts.c:9495's vectorizable_load

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r12-2849-gf19c70afa4aa2416c581484a6eb51c0ac46acd08
Author: Richard Biener 
Date:   Wed Aug 11 11:49:10 2021 +0200

tree-optimization/101861 - fix gather use for non-gather refs

My previous change broke the usage of gather for strided loads.
The following fixes it.

2021-08-11  Richard Biener  

PR tree-optimization/101861
* tree-vect-stmts.c (vectorizable_load): Fix error in
previous change with regard to gather vectorization.

[Bug middle-end/101861] [12 Regression] ICE (segfault) via tree-vect-stmts.c:9495's vectorizable_load

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Should be fixed now.

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Liška  ---
So the solution won't be so easy. We generally face the problem that:
voidfoo (void)  __attribute__  
((target_clones("avx512f,avx2,avx,default")));

is only a declaration. If we consider another TU with:

void
__attribute__   ((target_clones("avx512f,avx2,avx,default")))
foo (void)
{
}

we end up with:

/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx512f.0'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx2.1'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.avx.2'
/tmp/cc5grfLD.o:pr101726.c:foo: error: undefined reference to 'foo.default.3'

anyway. That's caused by the fact that target_clones are made local and so the
references are unresolved.
My suggestion would be simply doing a normal declaration:
void foo(void);

and doing target_clone definition in another TU. Doing that works would work.
That said, we should likely forbid target_clone declarations. Or do I miss
something?

[Bug target/101845] wrong code at -O1 on aarch64 with __builtin_shufflevector()

[belagod at gcc dot gnu.org via Gcc-bugs]

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

Tejas Belagod  changed:

   What|Removed |Added

   Last reconfirmed||2021-08-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||belagod at gcc dot gnu.org

--- Comment #1 from Tejas Belagod  ---
Confirmed.

(insn 11 10 12 2 (set (reg:V8QI 92 [ _1 ])
(mult:V8QI (reg:V8QI 100)
(reg/v:V8QI 97 [ v ]))) "shuf.c":11:35 -1
 (nil))
(insn 12 11 13 2 (set (reg:V8QI 102)
(const_vector:V8QI [
(const_int -1 [0x]) repeated x8
])) -1
 (nil))

// Overwriting 92 [_1] looks suspicious?!
(insn 13 12 14 2 (set (subreg:V4HI (reg:V8QI 92 [ _1 ]) 0)
(subreg:V4HI (reg:V8QI 102) 0)) -1
 (nil))

// Seems like merging 92 into itself leads to the wrong code...
(insn 14 13 15 2 (set (subreg:V4HI (reg:V8QI 92 [ _1 ]) 0)
(vec_merge:V4HI (vec_duplicate:V4HI (vec_select:HI (subreg:V4HI
(reg:V8QI 92 [ _1 ]) 0)
(parallel [
(const_int 0 [0])
])))
(subreg:V4HI (reg:V8QI 92 [ _1 ]) 0)
(const_int 1 [0x1]))) -1
 (nil))

[Bug middle-end/101858] [12 Regression] ICE: ‘verify_gimple’ failed

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r12-2850-gd7e91f4894f6a1a2daeec5cbe1e912bb896b9f7a
Author: Richard Biener 
Date:   Wed Aug 11 10:26:18 2021 +0200

middle-end/101858 - avoid shift of pointer in folding

This makes sure to not generate a shift of pointer types in
simplification of X < (cast) (1 << Y).

2021-08-11  Richard Biener  

PR middle-end/101858
* fold-const.c (fold_binary_loc): Guard simplification
of  X < (cast) (1 << Y) to integer types.

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

[Bug middle-end/101858] [12 Regression] ICE: ‘verify_gimple’ failed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Keywords||ice-checking,
   ||ice-on-valid-code
 Status|ASSIGNED|RESOLVED

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

[Bug target/101788] [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857 since r12-2728-g2724d1bba6b36451404811fba3244f8897717ef3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
What forwprop does is

[local count: 1073741824]:
   __asm__ __volatile__("" : "=w" y);
-  y.0_1 = y;
-  _6 = BIT_FIELD_REF ;
-  _7 = BIT_FIELD_REF ;
-  _8 = BIT_FIELD_REF ;
-  _9 = BIT_FIELD_REF ;
-  _10 = BIT_FIELD_REF ;
-  _11 = BIT_FIELD_REF ;
-  _12 = BIT_FIELD_REF ;
-  _13 = BIT_FIELD_REF ;
+  _13 = BIT_FIELD_REF ;
+  _12 = BIT_FIELD_REF ;
+  _11 = BIT_FIELD_REF ;
+  _10 = BIT_FIELD_REF ;
+  _9 = BIT_FIELD_REF ;
+  _8 = BIT_FIELD_REF ;
+  _7 = BIT_FIELD_REF ;
+  _6 = BIT_FIELD_REF ;
   _2 = {_6, _7, _8, _9, _10, _11, _12, _13};
   x = _2;

so we're processing a DECL_HARD_REGISTER here I think and we must avoid
touching / changing accesses to such.  I am testing a patch.

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||hjl.tools at gmail dot com
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #5 from Martin Liška  ---
Right now, the x86-64* are defined as aliases to k8:

  {"x86-64", PROCESSOR_K8, CPU_K8, PTA_X86_64_BASELINE, 0, P_NONE},
  {"x86-64-v2", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V2 | PTA_NO_TUNE,
   0, P_NONE},
  {"x86-64-v3", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V3 | PTA_NO_TUNE,
   0, P_NONE},
  {"x86-64-v4", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V4 | PTA_NO_TUNE,
   0, P_NONE},

and it has the corresponding pta info:

(gdb) p *arch_info
$10 = {
  name = 0x1f96cdc "x86-64",
  processor = PROCESSOR_K8,
  schedule = CPU_K8,
  flags = {
low = 0,
high = 137445326852
  },
  model = 0,
  priority = P_NONE
}

thus we end up with:
pr101696.c:16:5: error: no dispatcher found for the versioning attributes
   16 | int foo ()
  | ^~~

So first step that needs to be done is adding support for the march names in:
__builtin_cpu_is.
@H.J. Can you please add that?

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #19 from Tobias Burnus  ---
Created attachment 51289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51289&action=edit
Patch - Free memory in the callee

The attached patch frees the memory in the callee, however:

* integer, allocatable – those are passed as 'integer **dummy'
  I believe those should be passed as CFI descriptor
  -> runs into the assert.

* In the Fortran caller, the freeing is not needed if the the implementation is
in Fortran as the callee frees this. In principle, something like the following
should work (trans-expr; there is one case for scalar and one for arrays):
@@ -6541 +6548,3 @@ gfc_conv_procedure_call
- && fsym->attr.intent == INTENT_OUT)
+ && fsym->attr.intent == INTENT_OUT
+ && (!sym->attr.is_bind_c
+ || sym->attr.if_source != IFSRC_DECL))

However, that does not work – and shows that the gfortran → CFI conversion is
completely broken:
void * cfi.0;
if (cfi.0 != 0B)
  {
__builtin_free (cfi.0);
That's uninitialized memory :-(

* Also broken is that the data type for BIND(C) uses the Fortran array
descriptor and not the CFI one – it is currently only used as pointer and later
cast to void* but still that's pretty bad :-(

 * * *

I have still to look at José's patches.

 * * *

In any case, I think that the TYPE handling needs to be fixed first, followed
by moving _gfortran_gfc_desc_to_cfi_desc (and cfi→gfc) from libgfortran to the
front end to generate proper context-aware in-line code.

[Bug target/61810] init-regs.c papers over issues elsewhere

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
Re-running the experiment of disabling init-regs on x86_64 on trunk shows

+FAIL: gcc.dg/lto/pr48622 c_lto_pr48622_0.o-c_lto_pr48622_0.o link, -O -flto
-fi
nline-small-functions -fno-early-inlining
 FAIL: gcc.dg/tree-prof/20050826-2.c scan-tree-dump-not dom2 "Invalid sum"
+FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vmovd|
movd)[ t]+[^{\\n]*%xmm[0-9] 3
+FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vpinsr
d|pinsrd)[ t]+[^{\\n]*%xmm[0-9] 1

+FAIL: gnat.dg/sso8.adb execution test

with both -m64 and -m32

The gcc.dg/lto/pr48622 failure is a link-fail:

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/tmp/cc8guozm.ltrans0.ltrans.o: in function `main':^M
:(.text+0x18): undefined reference to `ashift_qi_1'^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1

I think the testcase is broken - with initregs likely the

int
main ()
{
  if (ashift_qi_0 (0xff) != (u8) ((u8) 0xff << 0))
abort ();

test directly resolved to abort (), leaving the rest of the code dead.

The gcc.target/i386/extract-insert-combining.c looks like a combine
missed optimization when facing uninitialized regs compared to all-zero.
We get

pinsrd  $0, %esi, %xmm0
pinsrd  $0, %edi, %xmm1
movl%esi, -12(%rsp)
paddd   %xmm0, %xmm1
pinsrd  $0, %esi, %xmm0
paddd   %xmm1, %xmm0
movd%xmm0, %eax
ret

preserving the "uninitialized" state of %xmm0 high, when initregs
explicitely zeros %xmm0 then this is matched to movd.

I cannot assess what goes wrong with gnat.dg/sso8.adb, but it might be
a testsuite bug as well.

[Bug target/101788] [12 Regression] ICE in extract_bit_field_1 at gcc/expmed.c:1857 since r12-2728-g2724d1bba6b36451404811fba3244f8897717ef3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.  With the following (I mistyped the PR number in the 2nd occurance...)

commit 2cb02e065ff015a69db918eb545a00cd6edf0194 (origin/master, origin/HEAD)
Author: Richard Biener 
Date:   Wed Aug 11 14:10:52 2021 +0200

target/101788 - avoid decomposing hard-register "loads"

This avoids decomposing hard-register accesses that masquerade as
loads.

2021-08-11  Richard Biener  

PR target/101877
* tree-ssa-forwprop.c (pass_forwprop::execute): Do not decompose
hard-register accesses.

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Martin Liška from comment #5)
> Right now, the x86-64* are defined as aliases to k8:
> 
>   {"x86-64", PROCESSOR_K8, CPU_K8, PTA_X86_64_BASELINE, 0, P_NONE},
>   {"x86-64-v2", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V2 | PTA_NO_TUNE,
>0, P_NONE},
>   {"x86-64-v3", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V3 | PTA_NO_TUNE,
>0, P_NONE},
>   {"x86-64-v4", PROCESSOR_K8, CPU_GENERIC, PTA_X86_64_V4 | PTA_NO_TUNE,
>0, P_NONE},
> 
> and it has the corresponding pta info:
> 
> (gdb) p *arch_info
> $10 = {
>   name = 0x1f96cdc "x86-64",
>   processor = PROCESSOR_K8,
>   schedule = CPU_K8,
>   flags = {
> low = 0,
> high = 137445326852
>   },
>   model = 0,
>   priority = P_NONE
> }
> 
> thus we end up with:
> pr101696.c:16:5: error: no dispatcher found for the versioning attributes
>16 | int foo ()
>   | ^~~
> 
> So first step that needs to be done is adding support for the march names in:
> __builtin_cpu_is.
> @H.J. Can you please add that?

It is very difficult to add them to __builtin_cpu_is since there are no
such processors.  However, add them to __builtin_cpu_supports is possible.

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Martin Liška  ---
> It is very difficult to add them to __builtin_cpu_is since there are no
> such processors.

I see!

> However, add them to __builtin_cpu_supports is possible.

Please do so we can then leverage that in the target attribute.

[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW

[nickc at gcc dot gnu.org via Gcc-bugs]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #4 from Nick Clifton  ---
Note - this bug has been reported and fixed in the binutils copy of the
libiberty sources:

  https://sourceware.org/bugzilla/show_bug.cgi?id=28207

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #8 from H.J. Lu  ---
Created attachment 51290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51290&action=edit
A patch

Try this.

[Bug demangler/99935] Stack exhaustion demangling rust mangled name

[nickc at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Nick Clifton  ---
(In reply to Jonathan Wakely from comment #2)
> This patch breaks MinGW, see PR 101779

But it can be fixed by:
  https://sourceware.org/bugzilla/show_bug.cgi?id=28207

[Bug libstdc++/101258] std ::is_integral_v is undocumented

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:63758bead0337b5225016711bf9d540cf7cc80b1

commit r11-8845-g63758bead0337b5225016711bf9d540cf7cc80b1
Author: Jonathan Wakely 
Date:   Wed Jun 30 16:00:58 2021 +0100

libstdc++: Improve Doxygen documentation groups [PR 101258]

This defines some new Doxygen groups for C++17 variable templates and
for the contents of . By documenting the group
as a whole and adding each template to a group we don't need to document
them individually.

Also mark more internals with "@cond undocumented" so that Doxygen
ignores them by default. Also make Doxygen process .

For some reason, many of the class templates in  do not
appear in the "Metaprogramming" group. For example, add_cv,
remove_extent, and all the is_xxx_constructible and is_xxx_assignable
traits. For some reason, Doxygen doesn't include them in the group,
despite doing it correctly for other traits in the same header.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101258
* doc/doxygen/user.cfg.in (INPUT): Add .
(COLS_IN_ALPHA_INDEX): Remove obsolete tag.
(PREDEFINED): Add/fix some more macros that need to be expanded.
* include/bits/random.h: Stop Doxygen from documenting internal
implementation details.
* include/bits/random.tcc: Likewise.
* include/bits/this_thread_sleep.h: Fix @file name.
* include/experimental/bits/simd.h: Add to Doxygen group. Do not
document internal implementation details.
* include/experimental/bits/simd_detail.h: Do not document
internal implementation details.
* include/experimental/simd: Define Doxygen groups.
* include/experimental/type_traits: Improve documentation for
the header file. Define groups. Use @since commands.
* include/std/scoped_allocator (scoped_allocator_adaptor): Move
declaration before undocumented region.
* include/std/type_traits (true_type, false_type): Use using
declaration instead of typedef.
(is_invocable_v, is_nothrow_invocable_v, is_invocable_r_v)
(is_nothrow_invocable_r_v): Move definitions next to other C++17
variable templates.
Do not document internal implementation details. Move misplaced
group-end command. Define group for variable templates.
* include/std/variant: Do not document internal implementation
details.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.

(cherry picked from commit 6963c3b9ed1308bf5d2d8877956e56fec92853a7)

[Bug libstdc++/97001] API documentation should mention the minimum dialect

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-8846-gea32f15d44e4f50f3eb9deb3135e0b6d50f7ec43
Author: Jonathan Wakely 
Date:   Thu Jul 1 00:30:54 2021 +0100

libstdc++: Improvements to Doxygen markup

This attempts to improve the doxygen output to work around what seems to
be some bugs in doxygen (issues 8635 and 8638).

The @addtogroup command doesn't work for entities inside a nested
namespace (see 8635) so we need to close and reopen groups on entering
and elaving nested namespaces. This fixes the problem that
chrono::duration and chrono::time_point were not documented in the
"Time" documentation group. I am unable to make the path classes appear
as part of their relevant groups (File System and Filesystem TS), nor
the contents of  or . I have made some minor
improvements to the docs for those types, including starting to address
PR 97001 by adding @since to the doxygen comments.

This change also excludes the  header from
Doxygen processing, so we don't get an unwanted "Networking-ts" group
in the documentation.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* doc/doxygen/doxygroups.cc: Fix docs for std::literals.
* doc/doxygen/user.cfg.in: Exclude the Networking TS header.
Add some more predefined macros.
* include/bits/fs_fwd.h: Move @addtogroup commands inside
namespaces. Add better documentation.
* include/bits/fs_path.h: Likewise.
* include/experimental/bits/fs_fwd.h: Likewise.
* include/experimental/bits/fs_path.h: Likewise.
* include/ext/throw_allocator.h: Fix typo and improve docs.
* include/std/chrono: Move @addtogroup commands.
* include/std/system_error: Move @addtogroup commands.
* libsupc++/exception: Improve documentation.
* libsupc++/exception.h: Add @since documentation.

(cherry picked from commit f2ce64b53fa76a4c192fe51b2f6c5a863a3b1241)

[Bug libstdc++/101056] std::compare_partial_order_fallback missing the constraint of "F < E is well-formed"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:546cf317558bfb178b7cadd346bb43cb963e9ce6

commit r11-8848-g546cf317558bfb178b7cadd346bb43cb963e9ce6
Author: Jonathan Wakely 
Date:   Mon Jun 14 12:30:52 2021 +0100

libstdc++: Implement LWG 3465 for std::compare_partial_order_fallback
[PR101056]

libstdc++-v3/ChangeLog:

PR libstdc++/101056
* libsupc++/compare (compare_partial_order_fallback): Add
constraint using reversed parameter order, as per LWG 3465.
* testsuite/18_support/comparisons/algorithms/fallback.cc:
Adjust expected result.

(cherry picked from commit b76a529c095f076c4780df0c913cf6d2391bcbc9)

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-8849-gc5f17274aabe61bb0193b8b68283c1f1da5ee699
Author: Jonathan Wakely 
Date:   Tue Jul 20 12:35:37 2021 +0100

libstdc++: Add more tests for filesystem::create_directory [PR101510]

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101510
* src/c++17/fs_ops.cc (create_dir): Adjust whitespace.
* testsuite/27_io/filesystem/operations/create_directory.cc:
Test creating directory with name of existing symlink to
directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Likewise.

(cherry picked from commit 0c4ae4ff46b1d7633f1e06f57d348b5817b8f640)

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-8850-gbde28c60c70079416dd2181f882c0694e019eaef
Author: Jonathan Wakely 
Date:   Tue Jul 20 18:15:48 2021 +0100

libstdc++: Fix create_directories to resolve symlinks [PR101510]

When filesystem__create_directories checks to see if the path already
exists and resolves to a directory, it uses filesystem::symlink_status,
which means it reports an error if the path is a symlink. It should use
filesystem::status, so that the target directory is detected, and no
error is reported.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101510
* src/c++17/fs_ops.cc (fs::create_directories): Use status
instead of symlink_status.
* src/filesystem/ops.cc (fs::create_directories): Likewise.
* testsuite/27_io/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/27_io/filesystem/operations/create_directory.cc: Do
not test with symlinks on Windows.
*
testsuite/experimental/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Do not test with symlinks on Windows.

(cherry picked from commit 124eaa50e0a34f5f89572c1aa812c50979da58fc)

[Bug libstdc++/101258] std ::is_integral_v is undocumented

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug c++/100828] Arbitrary limit on constraint complexity

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-8851-g90f3dd128bc709a76c52b5ae29b40903acb26f20
Author: Patrick Palka 
Date:   Mon Aug 2 09:59:56 2021 -0400

c++: Improve memory usage of subsumption [PR100828]

Constraint subsumption is implemented in two steps.  The first step
computes the disjunctive (or conjunctive) normal form of one of the
constraints, and the second step verifies that each clause in the
decomposed form implies the other constraint.   Performing these two
steps separately is problematic because in the first step the DNF/CNF
can be exponentially larger than the original constraint, and by
computing it ahead of time we'd have to keep all of it in memory.

This patch fixes this exponential blowup in memory usage by interleaving
the two steps, so that as soon as we decompose one clause we check
implication for it.  In turn, memory usage during subsumption is now
worst case linear in the size of the constraints rather than
exponential, and so we can safely remove the hard limit of 16 clauses
without introducing runaway memory usage on some inputs.  (Note the
_time_ complexity of subsumption is still exponential in the worst case.)

In order for this to work we need to make formula::branch() insert the
copy of the current clause directly after the current clause rather than
at the end of the list, so that we fully decompose a clause shortly
after creating it.  Otherwise we'd end up accumulating exponentially
many (partially decomposed) clauses in memory anyway.

PR c++/100828

gcc/cp/ChangeLog:

* logic.cc (formula::formula): Use emplace_back instead of
push_back.
(formula::branch): Insert a copy of m_current directly after
m_current instead of at the end of the list.
(formula::erase): Define.
(decompose_formula): Remove.
(decompose_antecedents): Remove.
(decompose_consequents): Remove.
(derive_proofs): Remove.
(max_problem_size): Remove.
(diagnose_constraint_size): Remove.
(subsumes_constraints_nonnull): Rewrite directly in terms of
decompose_clause and derive_proof, interleaving decomposition
with implication checking.  Remove limit on constraint complexity.
Use formula::erase to free the current clause before moving on to
the next one.

(cherry picked from commit f48c3cd2e3f9cd9e3c329eb2d3185bd26e7c7607)

[Bug c++/100828] Arbitrary limit on constraint complexity

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 11.3 and 12, thanks for the bug report!

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

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Bug 100828 Summary: Arbitrary limit on constraint complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100828

   What|Removed |Added

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

[Bug libstdc++/101056] std::compare_partial_order_fallback missing the constraint of "F < E is well-formed"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:452bfa3f41733eed6f07e5a8aae0bb8214cc6ce6

commit r10-10029-g452bfa3f41733eed6f07e5a8aae0bb8214cc6ce6
Author: Jonathan Wakely 
Date:   Mon Jun 14 12:30:52 2021 +0100

libstdc++: Implement LWG 3465 for std::compare_partial_order_fallback
[PR101056]

libstdc++-v3/ChangeLog:

PR libstdc++/101056
* libsupc++/compare (compare_partial_order_fallback): Add
constraint using reversed parameter order, as per LWG 3465.
* testsuite/18_support/comparisons/algorithms/fallback.cc:
Adjust expected result.

(cherry picked from commit b76a529c095f076c4780df0c913cf6d2391bcbc9)

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r10-10030-gf28d0e3a39246767b5fcdbe5c2bc005a45253246
Author: Jonathan Wakely 
Date:   Tue Jul 20 12:35:37 2021 +0100

libstdc++: Add more tests for filesystem::create_directory [PR101510]

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101510
* src/c++17/fs_ops.cc (create_dir): Adjust whitespace.
* testsuite/27_io/filesystem/operations/create_directory.cc:
Test creating directory with name of existing symlink to
directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Likewise.

(cherry picked from commit 0c4ae4ff46b1d7633f1e06f57d348b5817b8f640)

[Bug libstdc++/101510] std::filesystem::create_directory on an existing symlink to a directory

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:86bdcd21a1be008df28648b185c12221d917a166

commit r10-10031-g86bdcd21a1be008df28648b185c12221d917a166
Author: Jonathan Wakely 
Date:   Tue Jul 20 18:15:48 2021 +0100

libstdc++: Fix create_directories to resolve symlinks [PR101510]

When filesystem__create_directories checks to see if the path already
exists and resolves to a directory, it uses filesystem::symlink_status,
which means it reports an error if the path is a symlink. It should use
filesystem::status, so that the target directory is detected, and no
error is reported.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101510
* src/c++17/fs_ops.cc (fs::create_directories): Use status
instead of symlink_status.
* src/filesystem/ops.cc (fs::create_directories): Likewise.
* testsuite/27_io/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/27_io/filesystem/operations/create_directory.cc: Do
not test with symlinks on Windows.
*
testsuite/experimental/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Do not test with symlinks on Windows.

(cherry picked from commit 124eaa50e0a34f5f89572c1aa812c50979da58fc)

[Bug preprocessor/101864] New: Segmentation fault with -Wtraditional + glibc 2.34

[harald at gigawatt dot nl via Gcc-bugs]

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

Bug ID: 101864
   Summary: Segmentation fault with -Wtraditional + glibc 2.34
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: harald at gigawatt dot nl
  Target Milestone: ---

This testcase comes from glibc 2.34's sys/cdefs.h, so this is a problem showing
up for any program that uses any of glibc's headers with -Wtraditional.

$ cat test.c
#define __glibc_has_attribute(attr) __has_attribute(attr)
#if __glibc_has_attribute(__deprecated__)
#endif

$ gcc -Wtraditional -E test.c
# 0 "test.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "test.c"
test.c:1: internal compiler error: Segmentation fault
1 | #define __glibc_has_attribute(attr) __has_attribute(attr)
  | 
0x1542e3f internal_error(char const*, ...)
???:0
0x156fa80 cpp_sys_macro_p(cpp_reader*)
???:0
0x155f868 cpp_classify_number(cpp_reader*, cpp_token const*, char const**,
unsigned int)
???:0
0x1561509 _cpp_parse_expr
???:0
0x155bf8f _cpp_handle_directive
???:0
0x156ace1 _cpp_lex_token
???:0
0x6aece2 preprocess_file(cpp_reader*)
???:0
0x6ad33f c_common_init()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnux32/11.2.0/lto-wrapper
Target: x86_64-linux-gnux32
Configured with: /h/gcc-11.2.0/configure --prefix=/usr
--datadir=/usr/share/gcc-11.2.0 --infodir=/usr/share/info
--mandir=/usr/share/man --build=x86_64-linux-gnux32 --host=x86_64-linux-gnux32
--enable-languages=c,c++,d,objc,obj-c++,fortran,ada,go --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-abi=x32
--with-multilib-list=mx32,m64,m32 --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)

[Bug preprocessor/101864] Segmentation fault with -Wtraditional + glibc 2.34

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

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

--- Comment #1 from Harald van Dijk  ---
Thanks Bugzilla for only showing me this is a duplicate after submitting :)

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

[Bug preprocessor/101638] [11/12 Regression] ICE with -Wtraditional since r11-4953-g1d00f8c86324c40a

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk  ---
*** Bug 101864 has been marked as a duplicate of this bug. ***

[Bug middle-end/101862] [C, C++] Potential '?:' diagnostic for always-true expressions in boolean context

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  ---
I'm not sure exactly what you want to do.
When we go into SSA we see:

   :
  _8 = arr[i_15];
  i.1_9 = (unsigned int) i_15;
  _10 = i.1_9 & 1;
  _11 = _10 != 0;
  _12 = (int) _11;
  if (_8 == _12)
goto ; [INV]
  else
goto ; [INV]

   :
  iftmp.0_27 = i_15 != -1;
  goto ; [INV]

   :
  iftmp.0_26 = i_15 != -2;

   :
  # iftmp.0_16 = PHI 
  if (iftmp.0_16 != 0)
goto ; [INV]
  else
goto ; [INV]

The EVRP pass recognizes that i_15 has a range of int [0, 32], thus folds 
 # iftmp.0_16 = PHI 
into
# iftmp.0_16 = PHI <1, 1>
and continues to fold away the if that leads to the assert.

This seems to be too late to determine that a warning might be appropriate..
and I'm not sure how you would figure that out from this IL.

We have to go way back before gimple before we see the conditional expression.
I see the front end generates this is the .original file:
:;
{
  if (arr[i] == (((unsigned int) i & 1) != 0) ? i != -1 : i != -2)
{
  (void) 0;
}
  else
{
  __assert_fail ((const char *) "arr[i] == ((i % 2) != 0) ? i + 1 : i +
2", (const char *) "as.c", 17, (const char *) &__PRETTY_FUNCTION__);
}

but even by the .gimple listing the COND_EXPR is gone, replaced with the iftmp
sequence.  Im not sure how you would determine that this is not working as
intended.. ?  we usually rejoice when we can fold asserts away :-)

The range machinery knows what you want to know, but IM not sure how you could
use it. Its only available once we go into SSA.

[Bug preprocessor/101638] [11/12 Regression] ICE with -Wtraditional since r11-4953-g1d00f8c86324c40a

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/101845] wrong code at -O1 on aarch64 with __builtin_shufflevector()

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Tejas Belagod from comment #1)
> Confirmed.
> 
> (insn 11 10 12 2 (set (reg:V8QI 92 [ _1 ])
> (mult:V8QI (reg:V8QI 100)
> (reg/v:V8QI 97 [ v ]))) "shuf.c":11:35 -1
>  (nil))
> (insn 12 11 13 2 (set (reg:V8QI 102)
> (const_vector:V8QI [
> (const_int -1 [0x]) repeated x8
> ])) -1
>  (nil))
> 
> // Overwriting 92 [_1] looks suspicious?!

Yes so it is the same problem as PR 101529.

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

[Bug target/101529] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
*** Bug 101845 has been marked as a duplicate of this bug. ***

[Bug fortran/99351] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

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
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-August/056355.html

[Bug target/101865] New: _ARCH_PWR8 is not defined when using -mcpu=power8

[tuliom at ascii dot art.br via Gcc-bugs]

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

Bug ID: 101865
   Summary: _ARCH_PWR8 is not defined when using -mcpu=power8
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tuliom at ascii dot art.br
  Target Milestone: ---

When using -mcpu=power8, I expected that _ARCH_PWR8 would be defined, however
it isn't defined when used together with -mno-altivec -mno-vsx, e.g.

$ gcc-11 -mcpu=power8 -mno-altivec -mno-vsx -dM -E - < /dev/null | grep PWR
#define _ARCH_PWR5 1
#define _ARCH_PWR6 1
#define _ARCH_PWR7 1
#define _ARCH_PWR5X 1
#define _ARCH_PWR4 1

[Bug testsuite/101866] New: libstdc++-v3/testsuite/experimental/random/randint.cc fails

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 101866
   Summary: libstdc++-v3/testsuite/experimental/random/randint.cc
fails
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

libstdc++-v3/testsuite/experimental/random/randint.cc fails on rare occasions. 
I have only seen it happen twice now once after running it 1.9 million times to
try to spot it:

/home/seurer/gcc/git/gcc-9-test/libstdc++-v3/testsuite/experimental/random/randint.cc:61:
void test01(): Assertion '!(n3[0] == n1[0] && n3[1] == n1[1] && n3[2] ==
n1[2])' failed.
/home/seurer/bin/runmany.gcc: line 212: 39222 Aborted (core
dumped) ./randint.exe

While I spotted this with gcc 9 the test has not changed in current trunk anmd
I assume in gcc 10 and gcc 11 as well.

OK,

  std::experimental::reseed(99u);
  const long n1[] = {
std::experimental::randint(0, 100),
std::experimental::randint(0, 100),
std::experimental::randint(0, 100),
std::experimental::randint(0, 100),
std::experimental::randint(0, 100)
  };
. . .
  std::experimental::reseed();
  const long n3[] = {
std::experimental::randint(0, 100),
std::experimental::randint(0, 100),
std::experimental::randint(0, 100)
  };
  VERIFY( !(n3[0] == n1[0] && n3[1] == n1[1] && n3[2] == n1[2]) );

I don't think the above code from the test is correct.  There is a small chance
(1 in 100 for each) that the values in n3 will be the same as the values in n1.

[Bug testsuite/101866] libstdc++-v3/testsuite/experimental/random/randint.cc fails

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-08-11

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-8852-g4ee9e57684e27d27ff12e2b93ab7ae3d46861593
Author: Harald Anlauf 
Date:   Wed Jul 28 19:11:27 2021 +0200

Fortran: ICE in resolve_allocate_deallocate for invalid STAT argument

gcc/fortran/ChangeLog:

PR fortran/101564
* expr.c (gfc_check_vardef_context): Add check for KIND and LEN
parameter inquiries.
* match.c (gfc_match): Fix comment for %v code.
(gfc_match_allocate, gfc_match_deallocate): Replace use of %v code
by %e in gfc_match to allow for function references as STAT and
ERRMSG arguments.
* resolve.c (resolve_allocate_deallocate): Avoid NULL pointer
dereferences and shortcut for bad STAT and ERRMSG argument to
(DE)ALLOCATE.  Remove bogus parts of checks for STAT and ERRMSG.

gcc/testsuite/ChangeLog:

PR fortran/101564
* gfortran.dg/allocate_stat_3.f90: New test.
* gfortran.dg/allocate_stat.f90: Adjust error messages.
* gfortran.dg/implicit_11.f90: Likewise.
* gfortran.dg/inquiry_type_ref_3.f90: Likewise.

(cherry picked from commit 7bf582e6cfcef922a087b1b2b42aa04ea9cb2d94)

[Bug testsuite/101866] libstdc++-v3/testsuite/experimental/random/randint.cc fails

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
If the 32 bits read from /dev/random by reseed() happen to equal 99u then
there's a 100% chance that the values will be the same.

[Bug testsuite/101866] libstdc++-v3/testsuite/experimental/random/randint.cc fails

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed for gcc-12 and backported to 11-branch.  Closing.

Thanks for the report!

[Bug c++/89062] class template argument deduction failure with parentheses

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:6186708312780bb2139da01946abdde39667e985

commit r12-2859-g6186708312780bb2139da01946abdde39667e985
Author: Patrick Palka 
Date:   Wed Aug 11 15:58:30 2021 -0400

c++: most vexing parse and braced CTAD [PR89062]

Here grokdeclarator is emitting the error

  error: class template placeholder âFooâ not permitted in this context

during the tentative (and ultimately futile) parse of 'x' as a function
declaration.  This happens because when parsing 'Foo{1}',
cp_parser_parameter_declaration yields a parameter declaration with no
declarator and whose type is a CTAD placeholder, and stops short of
consuming the '{'.  The caller cp_parser_parameter_declaration_list then
calls grokdeclarator on this declarator, hence the error, and soon
thereafter we abort this tentative parse since the next token '{'
doesn't make sense in the context of a parameter list.

Note that we don't have this issue with parenthesized CTAD

  Foo x(Foo(1));

because in this case cp_parser_direct_declarator (called indirectly from
c_p_p_d) consumes the '(' and returns cp_error_declarator instead of a
NULL declarator (and also simulates a parse error), and grokdeclarator
exits early for this declarator without emitting any error.

Since grokdeclarator doesn't take a 'complain' parameter, to fix this we
need to avoid calling grokdeclarator in this situation.  To that end
this patch makes c_p_p_d simulate an error when a construct is a CTAD
expression and definitely not a parameter declaration, so that c_p_p_d_l
can avoid calling grokdeclarator by checking for this simulated error.
Alternatively we could keep all this logic inside c_p_p_d_l and not
touch c_p_p_d at all, but this approach seems slightly less adhoc.

PR c++/89062

gcc/cp/ChangeLog:

* parser.c (cp_parser_parameter_declaration_list): Don't call
grokdeclarator if cp_parser_error_occurred.
(cp_parser_parameter_declaration): Simulate an error if we see
the beginning of a CTAD form, i.e. if we see an opening brace
after the decl-specifier-seq and the type is a CTAD placeholder.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction97.C: New test.

[Bug c++/79501] member deduction guide not recognized

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:7e39d1a15f5276f72ee478a692445569bb646e65

commit r12-2860-g7e39d1a15f5276f72ee478a692445569bb646e65
Author: Patrick Palka 
Date:   Wed Aug 11 15:59:22 2021 -0400

c++: recognize class-scope non-template dguides [PR79501]

It looks like we still don't recognize class-scope non-template
deduction guides even after r12-2260.   This is because deduction guides
are tagged as such in cp_parser_init_declarator after calling
cp_parser_declarator, but in cp_parser_member_declaration we call
cp_parser_declarator directly.

So let's tag them in cp_parser_member_declaration as well.

PR c++/79501

gcc/cp/ChangeLog:

* parser.c (maybe_adjust_declarator_for_dguide): New, split
out from ...
(cp_parser_init_declarator): ... here.
(cp_parser_member_declaration): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction98.C: New test.

[Bug c++/101786] P1143R2 constinit implementation is incomplete (joining with thread_local)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r12-2861-gee8f9ff00d79998274c967ad0c23692be9dd3ada
Author: Jakub Jelinek 
Date:   Wed Aug 11 22:00:29 2021 +0200

c++: Optimize constinit thread_local vars [PR101786]

The paper that introduced constinit mentioned in rationale that constinit
can be used on externs as well and that it can be used to avoid the
thread_local initialization wrappers, because the standard requires that
if constinit is present on any declaration, it is also present on the
initialization declaration, even if it is in some other TU etc.

There is a small problem though, we use the tls wrappers not just if
the thread_local variable needs dynamic initialization, but also when
it has static initialization, but non-trivial destructor, as the
"dynamic initialization" in that case needs to register the destructor.

So, the following patch optimizes constinit thread_local vars only
if we can prove they will not have non-trivial destructors.  That includes
the case where we have incomplete type where we don't know and need to
conservatively assume the type will have non-trivial destructor at the
initializing declaration side.

2021-08-11  Jakub Jelinek  

PR c++/101786
* decl2.c (var_defined_without_dynamic_init): Return true for
DECL_DECLARED_CONSTINIT_P with complete type and trivial
destructor.

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

[Bug c++/101786] P1143R2 constinit implementation is incomplete (joining with thread_local)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 12+.

[Bug target/101726] target_clone resolver does not generate PIC despite -fPIC

[stefan.kneifel at bluewin dot ch via Gcc-bugs]

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

--- Comment #4 from Stefan Kneifel  ---
Yes, but a programmer might choose to implement target clones for a shared
library using another language, e.g. hand-optimized assembler code (this was
the actual problem I had).

Forbidding target_clone declarations would make that solution impossible, which
should IMHO not be the case. To my opinion, the original solution (if the
target_clone function declaration is public, then it should be regarded as
public) is the most consequent one.

[Bug c++/89062] class template argument deduction failure with parentheses

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #10 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/79501] member deduction guide not recognized

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |12.0

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/100983] Deduction guide for member template class rejected at class scope

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||segher at gcc dot gnu.org
   Last reconfirmed||2021-08-11

--- Comment #1 from Segher Boessenkool  ---
Confirmed.

[Bug c++/101853] [12 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

[seurer at gcc dot gnu.org via Gcc-bugs]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from seurer at gcc dot gnu.org ---
I am seeing something possibly related with xtreme-header-6.C and
xtreme-tr1_b.C

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/testsuite/g++19/../../xg++
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/testsuite/g++19/../../
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/g++.dg/modules/xtreme-header-6_b.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts
-fno-module-lazy -S -o xtreme-header-6_b.s^M
hash table checking failed: equal operator returns true for a pair of values
with a different hash value^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/g++.dg/modules/xtreme-header-6_b.C:4:30:
internal compiler error: in hashtab_chk_error, at hash-table.c:137^M
0x10270667 hashtab_chk_error()^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/hash-table.c:137^M
0x10634607 hash_table::verify(spec_entry*
const&, unsigned int)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/hash-table.h:1033^M
0x10634d5f hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/hash-table.h:968^M
0x105b40ff match_mergeable_specialization(bool, spec_entry*)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/pt.c:3^M
0x104be1bf trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:10678^M
0x104c512b trees_in::decl_value()^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:7911^M
0x104b7d27 trees_in::tree_node(bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:9161^M
0x104b81ab trees_in::tree_node(bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:9211^M
0x104b87a3 trees_in::tree_node(bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:9354^M
0x104bad9f trees_in::core_vals(tree_node*)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:6545^M
0x104c520b trees_in::tree_node_vals(tree_node*)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:7069^M
0x104c520b trees_in::decl_value()^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:7950^M
0x104b7d27 trees_in::tree_node(bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:9161^M
0x104c3c6b module_state::read_cluster(unsigned int)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:14819^M
0x104c4583 module_state::load_section(unsigned int, binding_slot*)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:18090^M
0x104c7eeb module_state::read_language(bool)^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:18019^M
0x104c8283 direct_import^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/module.cc:18885^M
0x1054ab33 cp_parser_import_declaration^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/parser.c:14486^M
0x1057eed7 cp_parser_translation_unit^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/parser.c:4943^M
0x1057eed7 c_parse_file()^M
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cp/parser.c:46558^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1
FAIL: g++.dg/modules/xtreme-header-6_b.C -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-6_b.C -std=c++2a (test for excess errors)
Excess errors:
hash table checking failed: equal operator returns true for a pair of values
with a different hash value

spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/testsuite/g++12/../../xg++
-B/home3/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/testsuite/g++12/../../
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/power

[Bug libstdc++/101867] New: avr libc build error for libstdc++

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 101867
   Summary: avr libc build error for libstdc++
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51292&action=edit
error message

[Bug c++/15269] __attribute__((deprecated)) broken with inline, ignored with pure virtual, misreported after definition

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2005-05-01 03:42:59 |2021-8-11

--- Comment #10 from Andrew Pinski  ---
So to summary here, the only problem left is the following testcase:
// { dg-do compile }
struct B { 
void foo() __attribute__((deprecated)); // { dg-message "note" }
}; 

void B::foo() {} // { dg-bogus "" }
void demo() { ((B*)0)->foo(); } // { dg-warning "" }

[Bug c++/100919] multiple -Wdeprecated-declarations on a call to a deprecated member function pointer

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-08-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/100919] multiple -Wdeprecated-declarations on a call to a deprecated member function pointer

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
4.1.2 issues a duplicated warning too.

[Bug c++/94492] no way to silence -Wdeprecated-copy for aggregates

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #3 from Andrew Pinski  ---
Fixed.

[Bug c++/48266] deprecated("message") fails to print message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 40075.

[Bug libstdc++/101867] avr libc build error for libstdc++

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-08-11

--- Comment #1 from Jonathan Wakely  ---
How did you run configure?

[Bug c++/48266] deprecated("message") fails to print message

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #3 from Andrew Pinski  ---


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

[Bug c++/40075] deprecated("xxx") doesn't work on function parameter

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gcc at magfr dot 
user.lysator.liu.
   ||se

--- Comment #4 from Andrew Pinski  ---
*** Bug 48266 has been marked as a duplicate of this bug. ***

[Bug c++/40075] deprecated("xxx") doesn't work on function parameter

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
The original testcase in comment #0 starts to have the message in GCC 9+.

[Bug libstdc++/101867] avr libc build error for libstdc++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #1)
> How did you run configure?

../gcc/configure --disable-nls --disable-werror --disable-libstdcxx-verbose
--enable-libstdc++ --disable-ssp --enable-languages=c,c++ --prefix=$PREFIX
--target=avr --disable-shared --with-newlib


But I guess since avr libc does not provide a full locale stub, libstdc++
cannot be built. 



no with-newlib:

checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.

../gcc/configure --disable-nls --disable-werror --disable-libstdcxx-verbose
--enable-libstdc++ --disable-ssp --enable-languages=c,c++ --prefix=$PREFIX
--target=avr --disable-shared

[Bug c++/101725] simple requirement of parameter in defaulted non-type template parameter considered non-dependent

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:9707d2e5dbb92d2bc990c922461a5a16ae652319

commit r12-2862-g9707d2e5dbb92d2bc990c922461a5a16ae652319
Author: Patrick Palka 
Date:   Wed Aug 11 16:53:53 2021 -0400

c++: parameterized requires-expr as default argument [PR101725]

Here we're rejecting the default template argument

  requires (T t) { x(t); }

because we consider the 't' in the requirement to be a local variable
(according to local_variable_p), and we generally forbid local variables
from appearing inside default arguments.  We can perhaps fix this by
giving special treatment to parameters introduced by requires-expressions,
but DR 2082 relaxed the restriction about local variables appearing within
default arguments to permit them inside unevaluated operands thereof.
So this patch just implements DR 2082 which also fixes this PR since a
requires-expression is an unevaluated context.

PR c++/101725
DR 2082

gcc/cp/ChangeLog:

* cp-tree.h (unevaluated_p): Return true for REQUIRES_EXPR.
* decl.c (local_variable_p_walkfn): Don't walk into unevaluated
operands.
* parser.c (cp_parser_primary_expression) : Never
reject uses of local variables in unevaluated contexts.
* tree.c (cp_walk_subtrees) : Increment
cp_unevaluated_operand.  Use cp_walk_tree directly instead of
WALK_SUBTREE to avoid the goto.  Use REQUIRES_EXPR_REQS instead
of TREE_OPERAND directly.

gcc/testsuite/ChangeLog:

* g++.dg/DRs/dr2082.C: New test.
* g++.dg/cpp2a/concepts-uneval4.C: New test.

[Bug c++/95302] function attributed to be deprecated cannot include a typedef/using

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||10.3.0, 11.1.0

--- Comment #3 from Andrew Pinski  ---
Seems fixed in GCC 10.3.0 and 11+.

[Bug c++/95302] function attributed to be deprecated cannot include a typedef/using

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 99318.

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

[Bug c++/99318] [10 Regression] -Wdeprecated-declarations where non-should be?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||shyou...@ruby-lang.org

--- Comment #6 from Andrew Pinski  ---
*** Bug 95302 has been marked as a duplicate of this bug. ***

[Bug libstdc++/101867] avr libc build error for libstdc++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Created attachment 51293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51293&action=edit
config file

[Bug libstdc++/101867] avr libc build error for libstdc++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
Created attachment 51294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51294&action=edit
end part of error messages