[Bug target/97891] [x86] Consider using registers on large initializations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> This problem is very similar to the one pass_rpad deals with.

We already have mov_xor for mov $0 to reg, so we only need to handle mov
$0 to mem.

and size for:

xorl --- 2 byte
$0 in movb - 1 byte
$0 in movw - 2 byte
$0 in mov{l,q} - 4 byte

   0:   31 d2   xor%edx,%edx
   2:   48 c7 07 00 00 00 00movq   $0x0,(%rdi)
   9:   48 89 37mov%rsi,(%rdi)
   c:   88 17   mov%dl,(%rdi)
   e:   c6 07 00movb   $0x0,(%rdi)
  11:   66 89 17mov%dx,(%rdi)
  14:   66 c7 07 00 00  movw   $0x0,(%rdi)
  19:   89 3f   mov%edi,(%rdi)
  1b:   c7 07 00 00 00 00   movl   $0x0,(%rdi)


As long as immediate $0 occupied more than 2 bytes, it would be codesize
beneficial to replace mov $0, mem with xor reg0, reg0 + mov reg0, mem.

[Bug tree-optimization/97897] ICE tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638

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

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

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

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

commit r11-5156-g0d8290959ecf2c5f1dd062e57782b5e91be0f8f6
Author: Richard Biener 
Date:   Thu Nov 19 09:06:50 2020 +0100

tree-optimization/97897 - complex lowering on abnormal edges

This fixes complex lowering to not put constants into abnormal
edge PHI values by making sure abnormally used SSA names are
VARYING in its propagation lattice.

2020-11-19  Richard Biener  

PR tree-optimization/97897
* tree-complex.c (complex_propagate::visit_stmt): Make sure
abnormally used SSA names are VARYING.
(complex_propagate::visit_phi): Likewise.
* tree-ssa.c (verify_phi_args): Verify PHI arguments on abnormal
edges are SSA names.

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

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/97901] ICE at -Os: verify_gimple failed

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 CC||guojiufu at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-11-19

--- Comment #1 from Richard Biener  ---
I will have a look, caused by g:d87ee7f1c9cd2ffa6302cdfd0686d72e5bb7463b for
sure.

[Bug tree-optimization/97897] ICE tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0

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

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Keywords|needs-bisection, ra |

--- Comment #8 from Richard Biener  ---
Fixed by

commit 50134189a434e638861f8bf27d5caab9622811c8
Author: Uros Bizjak 
Date:   Thu Nov 19 09:23:46 2020 +0100

i386: Disable *2_i387_1 for TARGET_SSE_MATH modes

This pattern interferes with *2_1 when TARGET_SSE_MATH
modes are active. Combine pass is able to remove (use) RTXes and transforms
*2_1 to *2_i387_1 where SSE
alternatives are not available.

2020-11-19  Uro305241 Bizjak  

gcc/
* config/i386/i386.md (*2_i387_1):
Disable for TARGET_SSE_MATH modes.

gcc/testsuite/
* gcc.target/i386/pr97887.c: New test.

[Bug target/97891] [x86] Consider using registers on large initializations

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #5 from andysem at mail dot ru ---
Using a register is beneficial even for bytes and words if there are multiple
of mov instructions. But there has to be a single reg0 for all movs.

I'm not very knowlegeable about gcc internals, but would it be beneficial to
implement this on a higher level than instruction transformation? I.e. so that
instead of this:

a = 0;
b = 0;
c = 0;

we have:

any reg0 = 0; // any represents a type compatible with any fundamental or
enum type
a = reg0;
b = reg0;
c = reg0;

This way, reg0 would be in a single register, and that xorl instruction could
be subject to other tree optimizations.

With tree-level optimization, another thing to note is vectorizer. I know gcc
can sometimes merge adjacent initializations without padding to a larger single
instruction initializazion. For example:

struct A
{
long a1;
long a2;

A() :
a1(0), a2(0)
{
}
};

void test(A* p, unsigned int count)
{
for (unsigned int i = 0; i < count; ++i)
{
p[i] = A();
}
}

test(A*, unsigned int):
testl   %esi, %esi
je  .L1
leal-1(%rsi), %eax
pxor%xmm0, %xmm0
salq$4, %rax
leaq16(%rdi,%rax), %rax
.L3:
movups  %xmm0, (%rdi)
addq$16, %rdi
cmpq%rax, %rdi
jne .L3
.L1:
ret

I would like this to still work.

[Bug c/97880] [8/9/10/11 Regression] [OpenACC] ICE in emit_library_call_value_1, at calls.c:5298

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

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression] ICE  |[8/9/10/11 Regression]
   |in  |[OpenACC] ICE in
   |emit_library_call_value_1,  |emit_library_call_value_1,
   |at calls.c:5298 |at calls.c:5298

--- Comment #3 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #2)
> +++ b/gcc/omp-expand.c
> @@ -7561 +7561,2 @@ expand_oacc_for (struct omp_region *region, struct

I think my draft patch is not quite right:

  expand_oacc_for (struct omp_region *region, struct omp_for_data *fd)

has:
  tree iter_type = TREE_TYPE (v);
  tree diff_type = iter_type;
and
  if (fd->collapse > 1 || fd->tiling)
  tree total = expand_oacc_collapse_init (fd, &gsi, counts,
  TREE_TYPE (fd->loop.n2), loc);
The called  expand_oacc_collapse_init  also extracts the types.
as does   expand_oacc_collapse_vars  .

At least for some of those loop *_type, the largest  TYPE_PRECISION has to be
used.

[Bug middle-end/97902] New: x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

Bug ID: 97902
   Summary: x86 frame pointer missing with -fno-omit-frame-pointer
(-mno-omit-leaf-frame-pointer)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

int strcmpTEST(
const char * s1,
const char * s2)
{
while (*s1++ == *s2++)
if (*(s1-1) == '\0')
return (0);

return (*(s1-1) - *(s2-1));
}

Target: x86_64-linux-gnu

GCC 6.5/7.5: OK 
GCC 8.1/8.4/9.3/10.2: Missing.

[Bug target/97903] New: [ARM NEON] Missed optimization in lowering test operation

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

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

Bug ID: 97903
   Summary: [ARM NEON] Missed optimization in lowering test
operation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

#include 

uint8x8_t f1(int8x8_t a, int8x8_t b) {
  return (uint8x8_t) ((a & b) != 0);
}

uint8x8_t f2(int8x8_t a, int8x8_t b) {
  return vtst_s8 (a, b);
}

Code-gen:

f2:
vtst.8  d0, d0, d1
bx  lr


f1:
vmov.i32d16, #0  @ v8qi
vandd1, d0, d1
vmov.i32d17, #0x  @ v8qi
vceq.i8 d1, d1, d16
vbsld1, d16, d17
vmovd0, d1  @ v8qi
bx  lr

The optimized dump for f1 shows:
  _1 = a_4(D) & b_5(D);
  _3 = .VCOND (_1, { 0, 0, 0, 0, 0, 0, 0, 0 }, { -1, -1, -1, -1, -1, -1, -1, -1
}, { 0, 0, 0, 0, 0, 0, 0, 0 }, 113);
  _6 = VIEW_CONVERT_EXPR(_3);

I think we miss opportunity to combine AND followed by VCOND into a vector test
instruction. Should we add a .VTEST internal function that expands to vtst ? Or
alternatively, add a peephole pattern in backend ?

Thanks,
Prathamesh

[Bug target/97903] [ARM NEON] Missed optimization in lowering test operation

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

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Host||x86_64-unknown-linux-gnu
  Build||x86_64-unknown-linux-gnu
 CC||clyon at gcc dot gnu.org,
   ||prathamesh3492 at gcc dot 
gnu.org
 Target||arm-linux-gnueabihf
   Assignee|unassigned at gcc dot gnu.org  |prathamesh3492 at gcc 
dot gnu.org
   Severity|normal  |enhancement

[Bug middle-end/97898] ICE in outermost_invariant_loop, at tree-ssa-loop-im.c:431

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
At least as old as GCC 4.8.0.

[Bug tree-optimization/97904] New: ICE with AArch64 SVE intrinsics

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

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

Bug ID: 97904
   Summary: ICE with AArch64 SVE intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase below ICEs for -march=armv8.2-a+sve

at -O0 the ICE is:
ice.c:19:1: internal compiler error: in tree_to_uhwi, at tree.c:7377
   19 | }
  | ^
0x136e268 tree_to_uhwi(tree_node const*)
$SRC/gcc/tree.c:7377
0x13ed7b2 assemble_noswitch_variable
$SRC/gcc/varasm.c:2104
0x13ed7b2 assemble_variable(tree_node*, int, int, int)
$SRC/gcc/varasm.c:2321
0x13f0af1 varpool_node::assemble_decl()
$SRC/gcc/varpool.c:587
0xb0a787 cgraph_order_sort::process()
$SRC/gcc/cgraphunit.c:2548
0xb0b658 output_in_order
$SRC/gcc/cgraphunit.c:2613
0xb0b658 symbol_table::compile()
$SRC/gcc/cgraphunit.c:2831
0xb0de34 symbol_table::finalize_compilation_unit()
$SRC/gcc/cgraphunit.c:3014
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

whereas at -O3 it is:
during GIMPLE pass: ccp
ice.c: In function ‘int main()’:
ice.c:19:1: internal compiler error: in maybe_canonicalize_mem_ref_addr, at
gimple-fold.c:4906
   19 | }
  | ^
0xcafec9 maybe_canonicalize_mem_ref_addr
$SRC/gcc/gimple-fold.c:4906
0xcbaf32 fold_stmt_1
$SRC/gcc/gimple-fold.c:4988
0xcc0a1d fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
$SRC/gcc/gimple-fold.c:5329
0x121a859 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
$SRC/gcc/tree-ssa-propagate.c:1070
0x1a8d7d9 dom_walker::walk(basic_block_def*)
$SRC/gcc/domwalk.c:309
0x121b938 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
$SRC/gcc/tree-ssa-propagate.c:1199
0x1158927 ccp_finalize
$SRC/gcc/tree-ssa-ccp.c:1022
0x1158ec8 do_ssa_ccp
$SRC/gcc/tree-ssa-ccp.c:2586
0x1158ec8 execute
$SRC/gcc/tree-ssa-ccp.c:2629
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


#include 
#include 

const std::array log_tab =
{
{
svdup_n_f32(-2.29561495781f),
svdup_n_f32(-2.47071170807f),
}
 };

int main(void)
{
svbool_t pg;
svfloat32_t x;
auto A = svmla_f32_z(pg, log_tab[0], log_tab[1], x);

return 0;
}

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

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

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

--- Comment #9 from Martin Liška  ---
@Marek: Please do not forget to CC the author of a culprit revision ;)

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.2.1, 11.0
   Target Milestone|--- |10.3

[Bug tree-optimization/97901] ICE at -Os: verify_gimple failed

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
 CC||marxin at gcc dot gnu.org

[Bug middle-end/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can't reproduce that with GCC 10.2.1 with -fno-omit-frame-pointer:

strcmpTEST:
.LFB0:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
...
.L3:
popq%rbp
.cfi_def_cfa 7, 8
ret

What problem exactly do you see?

[Bug middle-end/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

--- Comment #2 from Jan Smets  ---
Apologies, I omitted the -O1 / -O2 

$ docker run --privileged --rm -it -v /tmp:/tmp gcc:10.2 bash -c "gcc -c
/tmp/test4.c -S -o - -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
| grep rbp"

$ docker run --privileged --rm -it -v /tmp:/tmp gcc:7.5 bash -c "gcc -c
/tmp/test4.c -S -o - -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
| grep rbp"
pushq   %rbp
movq%rsp, %rbp
popq%rbp
popq%rbp

[Bug target/97903] [ARM NEON] Missed optimization in lowering test operation

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

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

--- Comment #1 from Richard Biener  ---
.VCONDEQ (aka vcondeq) should be that, no?  Just special case NE/EQ against
zero?

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Known to work||7.5.0
 Status|WAITING |NEW
   Last reconfirmed|2020-11-19 00:00:00 |
  Known to fail||10.2.1
  Component|middle-end  |target

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

[Bug tree-optimization/97901] ICE at -Os: verify_gimple failed

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

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

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

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

commit r11-5158-gec383f0bdb4077b744d493d02afff5f13f33029e
Author: Richard Biener 
Date:   Thu Nov 19 10:43:35 2020 +0100

tree-optimization/97901 - ICE propagating out LC PHIs

We need to fold the stmt to canonicalize MEM_REFs which means
we're back to using replace_uses_by.  Which means we need dominators
to not require a CFG cleanup upthread.

2020-11-19  Richard Biener  

PR tree-optimization/97901
* tree-ssa-propagate.c (clean_up_loop_closed_phi): Compute
dominators and use replace_uses_by.

* gcc.dg/torture/pr97901.c: New testcase.

[Bug tree-optimization/97901] ICE at -Os: verify_gimple failed

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

--- Comment #4 from Martin Liška  ---
Started with r8-2488-g8e941ae950ddce17

i386: Don't use frame pointer without stack access

When there is no stack access, there is no need to use frame pointer
even if -fno-omit-frame-pointer is used and caller's frame pointer is
unchanged.

which seems as a reasonable explanation to not emit stack pointer?

[Bug c++/97905] New: ice in duplicate_decls, at cp/decl.c:2754

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97905
   Summary: ice in duplicate_decls, at cp/decl.c:2754
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 49594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49594&action=edit
gzipped C++ source code

For the attached C++ code, recent gcc trunk does this:

route.cc:37:12: internal compiler error: in duplicate_decls, at cp/decl.c:2754
0x6f5168 duplicate_decls(tree_node*, tree_node*, bool, bool)
../../trunk.git/gcc/cp/decl.c:2752
0x79cf73 do_pushdecl(tree_node*, bool)
../../trunk.git/gcc/cp/name-lookup.c:2970
0x79fed5 pushdecl(tree_node*, bool)
../../trunk.git/gcc/cp/name-lookup.c:3109
0x79fed5 maybe_push_decl(tree_node*)
../../trunk.git/gcc/cp/name-lookup.c:3140

The bug seems to exist sometime between git hash ecf65330c11544eb,
dated 20201117 and hash cb1a4876a0e724ca, dated 20201118.

Flag -march=bdver2 required.

Since I now understand git bisect, I will have a go at finding a broken
commit.

I will also have my usual go at reducing the code.

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Martin Liška  ---
The documentation mentions that as well:

Note that -fno-omit-frame-pointer doesn't force a new stack
frame for all functions if it isn't otherwise needed, and hence doesn't
guarantee a new frame pointer for all functions.

[Bug target/97730] [10 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

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

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

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

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

commit r10-9053-gd452a386b82ad364e86a3d5e970db8561ce3cb49
Author: Alex Coplan 
Date:   Thu Nov 12 10:03:21 2020 +

aarch64: Fix SVE2 BCAX pattern [PR97730]

This patch adds a missing not to the SVE2 BCAX (Bitwise clear and
exclusive or) pattern, fixing the PR. Since SVE doesn't have an
unpredicated not instruction, we need to use a (vacuously) predicated
not here.

To ensure that the predicate is instantiated correctly (to all 1s) for
the intrinsics, we pull out a separate expander from the define_insn.

From the ISA reference [1]:
> Bitwise AND elements of the second source vector with the
> corresponding inverted elements of the third source vector, then
> exclusive OR the results with corresponding elements of the first
> source vector.

[1] :
https://developer.arm.com/docs/ddi0602/g/a64-sve-instructions-alphabetic-order/bcax-bitwise-clear-and-exclusive-or

gcc/ChangeLog:

PR target/97730
* config/aarch64/aarch64-sve2.md (@aarch64_sve2_bcax):
Change to define_expand, add missing (trivially-predicated) not
rtx to fix wrong code bug.
(*aarch64_sve2_bcax): New.

gcc/testsuite/ChangeLog:

PR target/97730
* gcc.target/aarch64/sve2/bcax_1.c (OP): Add missing bitwise not
to match correct bcax semantics.
* gcc.dg/vect/pr97730.c: New test.

(cherry picked from commit 7f445b5d6116000f1a6527f2164836cbc7c01dee)

[Bug target/97730] [10 Regression] aarch64, SVE2: Wrong code since r10-5853-g0a09a948 (wrong pattern for BCAX)

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #4 from Alex Coplan  ---
Fixed.

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

[jan.smets at nokia dot com via Gcc-bugs]

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

Jan Smets  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #6 from Jan Smets  ---
As discussed on IRC, Martin asked to reopen:  The frame pointer is required for
backtracing on some embedded platforms.

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|VERIFIED|NEW
 Resolution|INVALID |---

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

--- Comment #7 from Martin Liška  ---
Can you please H.J. take a look?
Maybe we can add a param that will drive the beviour?

[Bug target/97865] libtool needs to be updated for Darwin20.

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #16 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #15)
> (In reply to Jürgen Reuter from comment #14)
> > If there is a git branch or so, I could also test it on my system with our
> > code whether this works as expected.
> 
> Here you go - this is config.{sub, guess}, libtool and a small patch to
> enable libsanitizer for darwin20 (which I'll likely push soon).
> 
> https://github.com/iains/gcc-git/tree/master-wip-config-darwin20

I tested your branch. Several observations: 
(1) make worked, (I used gmp, mpfr and mpc without patches for them, there 
 libtool is also outdated, but I'm not sure whether it has any influence)
(2) make check did not work because of the first error below.
(3) make install did produce an error, strangely enough, as make worked without 
 problem.
(4) I checked that on my system there is an older version of libasan installed.
 I thought this comes with every gcc installation, but apparently it 
 doesn't. Or do I have to build with a special sanitizer flag? 
(5) Your branch does NOT solve the problems in our codes, I do see the same 
failures in our test suite like with the gcc trunk/master. 

The test-suite for the gcc itself did not work because
of this:
sys/types.h
/usr/local/packages/iains_gcc_git/fixincludes/tests/base/sys/types.h differ:
char 243, line 12
*** sys/types.h 2020-11-19 08:29:08.0 +0100
--- /usr/local/packages/iains_gcc_git/fixincludes/tests/base/sys/types.h   
2020-11-18 22:28:10.0 +0100
***
*** 9,19 


- #if defined( AIX_PHYSADR_T_CHECK )
- typedef struct __physadr_s {
- #endif  /* AIX_PHYSADR_T_CHECK */
- 
- 
  #if defined( GNU_TYPES_CHECK )
  #if !defined(_GCC_PTRDIFF_T)
  #define _GCC_PTRDIFF_T
--- 9,14 

There were fixinclude test FAILURES
make[2]: *** [check] Error 1
make[1]: *** [check-fixincludes] Error 2
make: *** [do-check] Error 2


Also `make install` did not work properly due to the following error (which is
strange, as make worked without problems). 



 -L/usr/local//lib -lmpc -lmpfr -lgmp   -L./../zlib -lz 
clang: error: argument unused during compilation: '-no-pie'
[-Werror,-Wunused-command-line-argument]
make[2]: [cc1plus] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o f951 \
fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o
fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o
fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o
fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o
fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o
fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o
fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o
fortran/frontend-passes.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L./../zlib -lz libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  attribs.o \
 -L/usr/local//lib -L/usr/local//lib -lmpc -lmpfr -lgmp  
-L./../zlib -lz 
clang: error: argument unused during compilation: '-no-pie'
[-Werror,-Wunused-command-line-argument]
make[2]: [f951] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o
lto/lto-partition.o lto/lto-symtab.o lto/lto-common.o libbackend.a main.o
libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a  -L/usr/local//lib -L/usr/local//lib -lmpc
-lmpfr -lgmp   -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a
./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
clang: error: argument unused during compilation: '-no-pie'
[-Werror,-Wunused-command-line-argument]
make[2]: [lto1] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasyn

[Bug rtl-optimization/92294] alias attribute generates incorrect code

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #7 from Marius Hillenbrand  ---
A simpler example derived from alias-2.c reproduces this issue on aarch64,
ppc64, and s390x. 

int a;
extern int b __attribute__ ((alias("a")));
int off;

int foo()
{
  /* make sure off is ahead of a and b in .bss, so that a has a non-negative
   * offset relative to the anchor. */
  return off;
}

main()
{
  b=1;
  a=2;
  if (b!=2)
   __builtin_abort ();
  return 0;
}

Note that gcc.c-torture/execute/alias-2.c did not reproduce this issue on
ppc64(le) for me. Removing the array indexing reduces the complexity of the RTL
dumps somewhat.

[Bug c++/97905] ice in duplicate_decls, at cp/decl.c:2754

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C++ test case seems to be:

template  void a() { extern int *b; }
int *b;

git bisect proceeds in other window. 

If all I am interested in is the performance of cc1plus, which 
make target should I use to build only this binary and not all 
the C and C++ libraries ?

[Bug target/97906] New: [ARM NEON] Missed optimization in lowering to vcage

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

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

Bug ID: 97906
   Summary: [ARM NEON] Missed optimization in lowering to vcage
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
Similar to PR97872 and PR97903, for following test-case:

#include 

uint32x2_t f1(float32x2_t a, float32x2_t b)
{
  return vabs_f32 (a) >= vabs_f32 (b);
}

uint32x2_t f2(float32x2_t a, float32x2_t b)
{
  return (uint32x2_t) __builtin_neon_vcagev2sf (a, b);
}

Code-gen:

f2:
vacge.f32  d0, d0, d1
bx lr

f1:
vabs.f32d0, d0
vabs.f32d1, d1
sub sp, sp, #8
vmov.32 r3, d0[0]
vmovs13, r3
vmov.32 r3, d1[0]
vmovs12, r3
vmov.32 r3, d1[1]
vcmpe.f32   s12, s13
vmovs14, r3
vmov.32 r3, d0[1]
vmrsAPSR_nzcv, FPSCR
vmovs15, r3
ite ls
movls   r3, #-1
movhi   r3, #0
vcmpe.f32   s14, s15
str r3, [sp]
vmrsAPSR_nzcv, FPSCR
ite ls
movls   r3, #-1
movhi   r3, #0
str r3, [sp, #4]
vldrd0, [sp]
add sp, sp, #8
@ sp needed
bx  lr

For f1, it is initially lowered to:

f1 (float32x2_t a, float32x2_t b)
{
  vector(2)  _1;
  vector(2) int _2;
  uint32x2_t _6;
  __simd64_float32_t _7;
  __simd64_float32_t _8;

   [local count: 1073741824]:
  _8 = __builtin_neon_vabsv2sf (a_4(D));
  _7 = __builtin_neon_vabsv2sf (b_5(D));
  _1 = _7 <= _8;
  _2 = VEC_COND_EXPR <_1, { -1, -1 }, { 0, 0 }>;
  _6 = VIEW_CONVERT_EXPR(_2);
  return _6;
}

and veclower seems to "scalarize" the cond_expr op:

f1 (float32x2_t a, float32x2_t b)
{
  vector(2) int _2;
  uint32x2_t _6;
  __simd64_float32_t _7;
  __simd64_float32_t _8;
  float _11;
  float _12;
  int _13;
  float _14;
  float _15;
  int _16;

   [local count: 1073741824]:
  _8 = __builtin_neon_vabsv2sf (a_4(D));
  _7 = __builtin_neon_vabsv2sf (b_5(D));
  _11 = BIT_FIELD_REF <_7, 32, 0>;
  _12 = BIT_FIELD_REF <_8, 32, 0>;
  _13 = _11 <= _12 ? -1 : 0;
  _14 = BIT_FIELD_REF <_7, 32, 32>;
  _15 = BIT_FIELD_REF <_8, 32, 32>;
  _16 = _14 <= _15 ? -1 : 0;
  _2 = {_13, _16};
  _6 = VIEW_CONVERT_EXPR(_2);
  return _6;

}

Thanks,
Prathamesh

[Bug target/97865] libtool needs to be updated for Darwin20.

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #17 from Jürgen Reuter  ---
Iain, as I wrote below your changes seem not sufficient, I will recheck when I
build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it seems
that there are some things where you missed the dynamic_lookup.

[Bug c++/97905] ice in duplicate_decls, at cp/decl.c:2754

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I am getting git bisect results which indicate either commit
cb1a4876a0e724ca3962ec14dce9e7819fa72ea5 or commit
ba97b532604815333848ee30e069dde6e36ce4c9 is at fault.

Neither seem anything to do with C++ or the optimizer, so I must 
have made a mistake somewhere.

Assistance sought.

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

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

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

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

Untested patch implementing the op1 rules.  Dunno what to do for op2, one needs
to create a union of two ranges and I have no idea how to create that.

[Bug c++/97907] New: error when compiling with optimization

[gustavo at ugr dot es via Gcc-bugs]

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

Bug ID: 97907
   Summary: error when compiling with optimization
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gustavo at ugr dot es
  Target Milestone: ---

Created attachment 49596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49596&action=edit
source code and makefile, also available at https://pccito.ugr.es/bug/ and
https://pccito.ugr.es/bug.tgz

3(5) should return 2 but it only works when no optimization level is applied.
f1 and f2 are two dumb functions not intended to work.

// g++ -O1 -save-temps -std=c11 -v -Wallpopcount.cc   -o popcount

#include 

unsigned f1(unsigned u)
{
unsigned c;
asm("popcnt %0, %1":"+r"(c):"r"(u));
return c;
}

unsigned f2(unsigned u)
{
unsigned c;
asm("popcnt %0, %1":"=r"(c),"=r"(u));
return c;
}

unsigned f3(unsigned u)
{
unsigned c;
asm("popcnt %1, %0":"=r"(c):"r"(u));
return c;
}

int main()
{
std::cout << "f1(5) = " << f1(5) << std::endl
  << "f2(5) = " << f2(5) << std::endl
  << "f3(5) = " << f3(5) << std::endl;
}

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from H.J. Lu  ---
(In reply to Martin Liška from comment #7)
> Can you please H.J. take a look?
> Maybe we can add a param that will drive the beviour?

I consider this optimization similar inlining or tail call. Should
-fno-omit-frame-pointer disable them?

[Bug target/97865] libtool needs to be updated for Darwin20.

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

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

--- Comment #18 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #17)
> Iain, as I wrote below your changes seem not sufficient, I will recheck when
> I build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it
> seems that there are some things where you missed the dynamic_lookup.

OK - we need to figure out what's different in the setups (I don't get the same
result)

-

* I found that there was one incorrect case in libgfortran (where there is a
direct reference to **environ from the dylib, which is not allowed) - this was
being hidden by the 'global dynamic_lookup' -- the master-wip-config-darwin20
branch has a patch now for that too.

My test setup

clean install of macOS11.0.1
master-wip-config-darwin20
command line install of XC12.2RC
GMP/MPFR/PMC/ISL are built in-tree (the sources are symlinked into the root
dir)

/src-local/gcc-master/configure
--prefix=/opt/iains/x86_64-apple-darwin20/gcc-11-0-0
--target=x86_64-apple-darwin20 --host=x86_64-apple-darwin20
--build=x86_64-apple-darwin20
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--enable-languages=all CC=x86_64-apple-darwin19-gcc
CXX=x86_64-apple-darwin19-g++

^^^ My bootstrap compiler is x86_64-apple-darwin19 gcc-7.5 (with Ada because of
enable-languages=all)

I have build logs, install logs and test logs, none of these are showing any
error.


=== gfortran tests ===


Running target unix

=== gfortran Summary ===

# of expected passes55631
# of expected failures  232
# of unsupported tests  82
/scratch/11-0-sur/gcc-master/gcc/gfortran  version 11.0.0 20201118
(experimental) [master-wip-config-darwin20 revision r11-5152-gb57eea8b1d7d]
(GCC) 



The effort of testing a top-level configuration change across multiple
platforms is quite significant - so I'd rather not hack a minimal change and
then have to go back and fix it properly later - so let's get to the bottom of
what's happening and find the correct solution.

[Bug target/97865] libtool needs to be updated for Darwin20.

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

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

--- Comment #19 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)


> clang: error: argument unused during compilation: '-no-pie'
> [-Werror,-Wunused-command-line-argument]
> make[2]: [lto-dump] Error 1 (ignored)

I saw this issue on i686-darwin9 when trying the branch, it seems that the
configuration is using the built compiler for this test - but then using the
build system c++ for the install ... it's not obvious that my changes could
cause this - I am investigating (it's not a problem if the bootstrap / build
system c++ support no-pie, which is the case for the gcc-7.5 bootstrap).

[Bug c++/97907] error when compiling with optimization

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
f1 invokes undefined behaviour by modifying an input-only asm operand.

[Bug target/97865] libtool needs to be updated for Darwin20.

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

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

--- Comment #20 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)


> - #if defined( AIX_PHYSADR_T_CHECK )
> - typedef struct __physadr_s {
> - #endif  /* AIX_PHYSADR_T_CHECK */
> - 
> - 

this is a recently-applied patch from the modules series, perhaps I don't have
that yet in my testing.

[Bug rtl-optimization/92294] alias attribute generates incorrect code

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from Marius Hillenbrand  ---
>From my current understanding, gcc addresses a and b in two different ways,
which is not handled correctly by the dependency analysis / alias analysis
while employed by the cse1 pass, and then causes cse1 to incorrectly eliminate
the read from b (reusing the const 1 from b=1).

the rtl addresses a via the section anchor yet b via its symbol reference:

b = 1 becomes
(set (reg/f:DI 62) (symbol_ref:DI ("b") [flags 0x602]  ))
(set (mem/c:SI (reg/f:DI 62) [1 b+0 S4 A32]) (const_int 1 [0x1]))

vs

a=2 becomes
(set (reg/f:DI 64) (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]))
(set (mem/c:SI (plus:DI (reg/f:DI 64) (const_int 4 [0x4])) [1 a+0 S4 A32])
(const_int 2 [0x2]))

when visiting the write to a, cse1 should identify the aliasing and thus drop
the "remembered" b. for that, cse iterates its hash table and compares all
present MEM rtx to the new address (cse.c:invalidate()).

that step compares (canonicalized) addresses
(const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) (const_int 4
[0x4])))
and (symbol_ref:DI ("b") [flags 0x602]  )

the comparison of these two (in alias.c:write_dependence_p()) falsely claims
that there is no anti-dependence between the two.

I am not certain yet how that comparison is supposed to work with section
anchors. It looks like we either fail to reconnect (anchor + 4) to the
symbol_ref of "a" (so we could identify both symbol_refs as equivalent) or lose
the offset relative to the anchor (so we could see that both have the same
offset relative to the anchor).

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-19
 Ever confirmed|0   |1
 CC||acoplan at gcc dot gnu.org,
   ||richard.sandiford at arm dot 
com
 Status|UNCONFIRMED |NEW

--- Comment #1 from Alex Coplan  ---
Confirmed. Here is a simpler testcase for the -O0 ICE:

#include 
template  struct d { b x[c]; };
d a;

Note that, without the template:

#include 
svfloat32_t a[2];

is just rejected:

test.cc:2:13: error: array elements cannot have SVE type 'svfloat32_t'
2 | svfloat32_t a[2];
  | ^

as is:

#include 
struct d {
  svfloat32_t a[2];
};

with the same error message.

[Bug target/97865] libtool needs to be updated for Darwin20.

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

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

--- Comment #21 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)

> (4) I checked that on my system there is an older version of libasan
> installed.
>  I thought this comes with every gcc installation, but apparently it 
>  doesn't. Or do I have to build with a special sanitizer flag? 

The branch contains a patch to enable libsanitizer for darwin20 (libsanitizer
*is* built with dynamic_lookup, because it uses undefined weak symbols).

So long as the initial configure says that libsanitizer is being built (or
rather it doesn't say it's disabled) then it should be present.

** Perhaps the problem are coming primarily from the failed install because of
the no-pie issue.  I am going to investigate this next.

With the last patch on the branch, it would be academic for libgfortran to be
built with "undefined, dynamic_lookup" since there are *no* undefined symbols.

since DYLD_LIBRARY_PATH no longer works for Darwin, a failed install will no
doubt produce a failed test.

Will post more when I figure out what's happening with the no-pie issue.  In
the meantime - you could try a bootstrap with CC/CXX set to a darwin19 gcc 7 or
newer (if it's possible).

[Bug c++/97907] error when compiling with optimization

[gustavo at ugr dot es via Gcc-bugs]

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

--- Comment #2 from gustavo  ---
(In reply to Andreas Schwab from comment #1)
> f1 invokes undefined behaviour by modifying an input-only asm operand.

as expected... this is a test for students.

only f3 matters.

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

--- Comment #2 from Alex Coplan  ---
Here is a simple testcase that hits both ICEs.

#include 
template  struct a {
  b x[c];
  b &operator[](int i) { return x[i]; }
};
a x;
int main() {
  svbool_t l;
  svfloat32_t m = svmla_f32_z(l, x[0], x[1], m);
}

[Bug libstdc++/83938] Speed up inplace_merge() algorithm & fix inefficient logic

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.4 |11.0

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

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

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

--- Comment #16 from H.J. Lu  ---
FWIW, I cherry-picked the fix onto vendors/redhat/gcc-10-branch branch.
I can build 5.10 kernel with the fixed GCC.

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-5167-gb108faa9400e13a3d00dd7f71cff0ac45e29c5c9
Author: Jonathan Wakely 
Date:   Thu Nov 19 13:33:11 2020 +

libstdc++: Fix overflow checks to use the correct "time_t" [PR 93456]

I recently added overflow checks to src/c++11/futex.cc for PR 93456, but
then changed the type of the timespec for PR 93421. This meant the
overflow checks were no longer using the right range, because the
variable being written to might be smaller than time_t.

This introduces new typedef that corresponds to the tv_sec member of the
struct being passed to the syscall, and uses that typedef in the range
checks.

libstdc++-v3/ChangeLog:

PR libstdc++/93421
PR libstdc++/93456
* src/c++11/futex.cc (syscall_time_t): New typedef for
the type of the syscall_timespec::tv_sec member.
(relative_timespec, _M_futex_wait_until)
(_M_futex_wait_until_steady): Use syscall_time_t in overflow
checks, not time_t.

[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-5167-gb108faa9400e13a3d00dd7f71cff0ac45e29c5c9
Author: Jonathan Wakely 
Date:   Thu Nov 19 13:33:11 2020 +

libstdc++: Fix overflow checks to use the correct "time_t" [PR 93456]

I recently added overflow checks to src/c++11/futex.cc for PR 93456, but
then changed the type of the timespec for PR 93421. This meant the
overflow checks were no longer using the right range, because the
variable being written to might be smaller than time_t.

This introduces new typedef that corresponds to the tv_sec member of the
struct being passed to the syscall, and uses that typedef in the range
checks.

libstdc++-v3/ChangeLog:

PR libstdc++/93421
PR libstdc++/93456
* src/c++11/futex.cc (syscall_time_t): New typedef for
the type of the syscall_timespec::tv_sec member.
(relative_timespec, _M_futex_wait_until)
(_M_futex_wait_until_steady): Use syscall_time_t in overflow
checks, not time_t.

[Bug libstdc++/92546] [10/11 Regression] Large increase in preprocessed file sizes in C++2a mode

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-5168-gb204d7722d30f44281dea3341070223475f1cff9
Author: Jonathan Wakely 
Date:   Thu Nov 19 13:36:15 2020 +

libstdc++: Move std::thread to a new header

This makes it possible to use std::thread without including the whole of
. It also makes this_thread::get_id() and this_thread::yield()
available even when there is no gthreads support (e.g. when GCC is built
with --disable-threads or --enable-threads=single).

In order for the std::thread::id return type of this_thread::get_id() to
be defined, std:thread itself is defined unconditionally. However the
constructor that creates new threads is not defined for single-threaded
builds. The thread::join() and thread::detach() member functions are
defined inline for single-threaded builds and just throw an exception
(because we know the thread cannot be joinable if the constructor that
creates joinable threads doesn't exit).

The thread::hardware_concurrency() member function is also defined
inline and returns 0 (as suggested by the standard when the value "is
not computable or well-defined").

The main benefit for most targets is that other headers such as 
do not need to include the whole of  just to be able to create a
std::thread. That avoids including  and std::jthread where
not required. This is another partial fix for PR 92546.

This also means we can use this_thread::get_id() and this_thread::yield()
in  instead of using the gthread functions directly. This
removes some preprocessor conditionals, simplifying the code.

libstdc++-v3/ChangeLog:

PR libstdc++/92546
* include/Makefile.am: Add new  header.
* include/Makefile.in: Regenerate.
* include/std/future: Include new header instead of .
* include/std/stop_token: Include new header instead of
.
(stop_token::_S_yield()): Use this_thread::yield().
(_Stop_state_t::_M_requester): Change type to std::thread::id.
(_Stop_state_t::_M_request_stop()): Use this_thread::get_id().
(_Stop_state_t::_M_remove_callback(_Stop_cb*)): Likewise.
Use __is_single_threaded() to decide whether to synchronize.
* include/std/thread (thread, operator==, this_thread::get_id)
(this_thread::yield): Move to new header.
(operator<=>, operator!=, operator<, operator<=, operator>)
(operator>=, hash, operator<<): Define even when
gthreads not available.
* src/c++11/thread.cc: Include .
* include/bits/std_thread.h: New file.
(thread, operator==, this_thread::get_id, this_thread::yield):
Define even when gthreads not available.
[!_GLIBCXX_HAS_GTHREADS] (thread::join, thread::detach)
(thread::hardware_concurrency): Define inline.

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

--- Comment #3 from Alex Coplan  ---
FWIW, clang (trunk) rejects that last testcase with:

:3:6: error: array has sizeless element type '__SVFloat32_t'
  b x[c];
 ^
:6:19: note: in instantiation of template class 'a<__SVFloat32_t, 2>'
requested here
a x;

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Keywords||ice-on-valid-code
Summary|ice in duplicate_decls, at  |[11 Regression] ice in
   |cp/decl.c:2754  |duplicate_decls, at
   ||cp/decl.c:2754
   Target Milestone|--- |11.0

[Bug target/97906] [ARM NEON] Missed optimization in lowering to vcage

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

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

--- Comment #1 from Richard Biener  ---
That means the initial lowering is "bad" or the target doesn't have a way to
do this compare.

[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective

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

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

--- Comment #14 from Jan Hubicka  ---
I fixed some issues
 1) merging of OBJ_TYPE_REF was broken
 2) last version of my COMPONENT_REF patch clears incorrectly OEP_ADDRESS_OF
 3) gimple clobbers mismatches for no good reason
 4) volatile memory references can are never considered equal
 5) alignment of memory accesses is not hashed and may cause late mismatch
(common in vector code)

With this I get
141   false returned: 'Declaration mismatch' in equals at
../../gcc/ipa-icf.c:1817
162   false returned: 'DECL_CXX_DESTRUCTOR mismatch' in equals_wpa at
../../gcc/ipa-icf.c:565
169   false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:162
246   false returned: 'final flag mismatch' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:401
380   false returned: '' in compare_phi_node at ../../gcc/ipa-icf.c:1595
380   false returned: 'PHI node comparison returns false' in equals_private
at ../../gcc/ipa-icf.c:916
513   false returned: 'different decl attributes' in equals_wpa at
../../gcc/ipa-icf.c:662
571   false returned: 'compare_ao_refs failed (dependence clique
difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:368
811   false returned: 'GIMPLE call operands are different' in
compare_gimple_call at ../../gcc/ipa-icf-gimple.c:676
912   false returned: 'different references' in compare_symbol_references
at ../../gcc/ipa-icf.c:465
961   false returned: 'size mismatch' in equals_wpa at
../../gcc/ipa-icf.c:1666
   1125   false returned: 'variables types are different' in equals at
../../gcc/ipa-icf.c:1712
   1129   false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at
../../gcc/ipa-icf.c:562
   1453   false returned: 'operand_equal_p failed' in compare_operand at
../../gcc/ipa-icf-gimple.c:376
   2917   false returned: 'compare_ao_refs failed (semantic difference)' in
compare_operand at ../../gcc/ipa-icf-gimple.c:356
   3362   false returned: 'ctor polymorphic type mismatch' in equals_wpa at
../../gcc/ipa-icf.c:585
   3527   false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:157
   3535   false returned: '' in compare_variable_decl at
../../gcc/ipa-icf-gimple.c:442
   3535   false returned: '' in operand_equal_p at
../../gcc/ipa-icf-gimple.c:307
   3563   false returned: 'GIMPLE assignment operands are different' in
compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:719
   4604   false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign
at ../../gcc/ipa-icf-gimple.c:715
   6577   false returned: 'parameter type is not compatible' in
compatible_parm_types_p at ../../gcc/ipa-icf.c:512
   8441   false returned: 'inline attributes are different' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350
  11259   false returned: 'parameter types are not compatible' in equals_wpa at
../../gcc/ipa-icf.c:639
  25276   false returned: 'different tree types' in compatible_types_p at
../../gcc/ipa-icf-gimple.c:206
  26073   false returned: 'references to virtual tables cannot be merged' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373
  26693   false returned: 'decl_or_type flags are different' in equals_wpa at
../../gcc/ipa-icf.c:572
  61657   false returned: 'call function types are not compatible' in
compare_gimple_call at ../../gcc/ipa-icf-gimple.c:655
  70880   false returned: '' in equals_private at ../../gcc/ipa-icf.c:881
 104034   false returned: 'types are not compatible' in compatible_types_p at
../../gcc/ipa-icf-gimple.c:212
 113477   false returned: 'result types are different' in equals_wpa at
../../gcc/ipa-icf.c:621
 410680   false returned: 'THIS pointer ODR type of cdtor mismatch' in
equals_wpa at ../../gcc/ipa-icf.c:673
 414222   false returned: 'types are not same for ODR' in
compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197

and more code size savings
 VM SIZE  FILE SIZE
 ++ GROWING++
  [ = ]   0 .strtab +439Ki  +1.0%
  [ = ]   0 .symtab+73.4Ki  +0.4%
  +0.0% +32 .data  +32  +0.0%

 -- SHRINKING  --
  -2.9% -2.67Mi .text  -2.67Mi  -2.9%
  -6.3%  -555Ki .eh_frame   -555Ki  -6.3%
  -7.8%  -148Ki .eh_frame_hdr   -148Ki  -7.8%
  -0.4% -78.2Ki .rodata-78.2Ki  -0.4%
  -0.5% -58.8Ki .rela.dyn  -58.8Ki  -0.5%
  -0.4% -15.0Ki .data.rel.ro.local -15.0Ki  -0.4%
  -1.0% -10.4Ki .data.rel.ro   -10.4Ki  -1.0%
  -0.0% -64 .bss 0  [ = ]
  -0.4% -32 .gcc_except_table  -32  -0.4%

 -+-+-+-+-+-+-+ MIXED  +-+-+-+-+-+-+-
   +14% +40 [Unmapped] -1.40Ki -42.6%

  -2.3% -3.51Mi TOTAL  -3.01Mi  -1.4%

ICF still take quite some memory:
 ipa lto gimple in  :   5.82 (  4%)   2.10 ( 15%)   8.05 (  5%)
  776M ( 12%)
 ipa lto gimple out :   1.

[Bug c++/97907] error when compiling with optimization

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Schwab  ---
No, everything matters.  The call to f1 overwrites the argument that is passed
to f3.

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

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

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

--- Comment #7 from John David Anglin  ---
Fix #2 works for me.

But then we hit:

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc
-11/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/lib/
-isystem /opt/gnu/gcc/gcc-11/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc
/gcc-11/hppa2.0w-hp-hpux11.11/sys-include   -fchecking=1 -c -g -O2  -fPIC  -W
-W
all -gnatpg -nostdinc   a-nallfl.ads -o a-nallfl.o
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it
binds
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:51:13: warning: profile of "Cos" doesn't match the builtin it
binds
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:54:13: warning: profile of "Tan" doesn't match the builtin it
binds
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:57:13: warning: profile of "Exp" doesn't match the builtin it
binds
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:60:13: warning: profile of "Sqrt" doesn't match the builtin it
binds
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:63:13: warning: profile of "Log" doesn't match the builtin it
binds
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:66:13: warning: profile of "Acos" doesn't match the builtin it
binds
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:69:13: warning: profile of "Asin" doesn't match the builtin it
binds
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:72:13: warning: profile of "Atan" doesn't match the builtin it
binds
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:75:13: warning: profile of "Sinh" doesn't match the builtin it
binds
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:78:13: warning: profile of "Cosh" doesn't match the builtin it
binds
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:81:13: warning: profile of "Tanh" doesn't match the builtin it
binds
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:84:13: warning: profile of "Pow" doesn't match the builtin it
binds
make[7]: *** [../gcc-interface/Makefile:302: a-nallfl.o] Error 1
make[7]: Leaving directory '/test/gnu/gcc/objdir/gcc/ada/rts'
make[6]: *** [gcc-interface/Makefile:620: gnatlib] Error 2

Probably, should be new PR.

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

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

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

--- Comment #8 from Eric Botcazou  ---
> Fix #2 works for me.

OK, thanks.

> Probably, should be new PR.

Nope, it's PR ada/97504, please follow up there.

[Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 97908
   Summary: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

» cat libx.cpp
#include 
class Foobar {};
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
» cat m.cpp
#include 
#include 
int main()
{
auto hnd = dlopen("./libx.so", RTLD_NOW);
auto f = reinterpret_cast(dlsym(hnd, "makename"));
auto name = f();
printf("%s\n", name);
dlclose(hnd);
printf("%s\n", name);
}
» g++-11 libx.cpp -shared -fPIC -ggdb3 -o libx.so; g++ m.cpp -fPIC -ggdb3 -Wall
-ldl
» ./a.out 
6Foobar
Segmentation fault (core dumped)
» g++-11 -v
gcc version 11.0.0 20201112 (experimental) [revision
876b45db81a708616d70b1ab66b71bd503809c21] (SUSE Linux) 


I do not know if this is even supposed to work. dlopen/dlclose is outside the
scope of the C++ standard, and POSIX (where dlopen comes from) does not mention
C++ during dlopen. However, this _alternate_ libx.cpp makes the program work:

#include 
struct Foobar { static constexpr char __tag[sizeof(std::type_info)] = { }; };
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
const char *helperfunc() { Foobar f; return f.__tag; }

__tag is emitted into the object file as a STB_GNU_UNIQUE symbol, which happens
to implicate RTLD_NODELETE for dlopen.

So, if __tag is getting the "unique" treatment to fulfill some guarantee,
should typeinfo variables (_ZTS* and _ZTI*) not get the same treatment, for the
same reasons?

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Last reconfirmed||2020-11-19
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Confirmed, started with r11-5108.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #33 from John David Anglin  ---
Also affects hppa*-*-hpux11*.

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
discussion on cwg leads me to conclude part of the error in the original
problem is believing the block-scope extern is matching the one found by the
using decl.

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

--- Comment #5 from Nathan Sidwell  ---
David, to build just cc1plus: 'make -C gcc cc1plus -j$how_many_cpus_available'

pass 'CXXFLAGS=$whatever' to override the default (usually -O2 -g)

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de via Gcc-bugs]

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

--- Comment #1 from Jan Engelhardt  ---
On second thought, this is practically the same issue as functions going away
(like example below), so wontfix seems appropriate.

-- main
#include 
struct base { virtual ~base() {}; };
int main()
{
auto hnd = dlopen("./libx.so", RTLD_NOW);
auto f = reinterpret_cast(dlsym(hnd, "makederiv"));
auto deriv = f();
dlclose(hnd);
delete deriv;
}
-- libx
#include 
struct base { virtual ~base() {}; }
struct deriv : base { virtual ~deriv() {}; }
extern "C" { base *makederiv(); }
base *makederiv() { return new deriv; }

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Nathan Sidwell from comment #5)
> David, to build just cc1plus: 'make -C gcc cc1plus
> -j$how_many_cpus_available'
> 
> pass 'CXXFLAGS=$whatever' to override the default (usually -O2 -g)

$ cd /home/dcb/gcc/
$ mkdir working
$ cd working
$ ../trunk.git/configure --whatever
$ ls -l gcc
ls: cannot access 'gcc': No such file or directory

Thanks for the tip, but after a configure, there is no gcc directory
available.

Does your tip only apply if there is a previous build available 
or have I misunderstood ?

[Bug libstdc++/97841] [C++17] is_invocable handling of incomplete return type is wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2020-11-19
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

[Bug debug/97713] [gsplit-dwarf] label generated for .debug_abbrev.dwo offset, corresponding relocation ignored by objcopy --extract-dwo

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

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Tom de Vries from comment #0)
> > Now, should objcopy implement the relocation?
> 
> Nick proposed a patch that errors out on current gcc output.
> 
> > Note that llvm emits a '0' as abbrev offset instead of a label.
> 
> And gcc would have to emit a 0, like llvm.  It that ok from gcc perspective?

Ping.

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Andrew Macleod  ---
Created attachment 49597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49597&action=edit
op2_range implementation

I think this does what you want for op2_range.

I tried it with:

void f1 (int i, int j)
{
  if ((i % j) == 3)
{
  xx = ((j <= 3) && (j >= -3));
  if (xx)
kill ();
}
}

and it eliminates the call. the listing shows:
if (_1 == 3)
  goto ; [INV]
else
  goto ; [INV]

_1 : int [-2147483647, +INF]
2->3  (T) _1 :  int [3, 3]
2->3  (T) i_8(D) :  int [3, +INF]
2->3  (T) j_9(D) :  int [-INF, -4][4, +INF]
2->5  (F) _1 :  int [-2147483647, 2][4, +INF]

so its got int [-INF, -4][4, +INF] for the range which I think is correct?

I got a headache trying to write a testcase for the different cases, and I'd
probably get it wrong like I did with the initial implementation..  So I leave
this with you to do what you will :-) 

I get all tangled up with the negatives.

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

[nathan at acm dot org via Gcc-bugs]

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

--- Comment #7 from Nathan Sidwell  ---
On 11/19/20 10:18 AM, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97905
> 
> --- Comment #6 from David Binderman  ---
> (In reply to Nathan Sidwell from comment #5)
>> David, to build just cc1plus: 'make -C gcc cc1plus
>> -j$how_many_cpus_available'
>>
>> pass 'CXXFLAGS=$whatever' to override the default (usually -O2 -g)
> 
> $ cd /home/dcb/gcc/
> $ mkdir working
> $ cd working
> $ ../trunk.git/configure --whatever
> $ ls -l gcc
> ls: cannot access 'gcc': No such file or directory
> 
> Thanks for the tip, but after a configure, there is no gcc directory
> available.
> 
> Does your tip only apply if there is a previous build available
> or have I misunderstood ?

sorry, yes, to just 'rebuild' cc1plus.  You can't just build cc1plus in 
a clean build

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:2729378d0905a04e476a8bdcaaf0288f417810ec

commit r11-5170-g2729378d0905a04e476a8bdcaaf0288f417810ec
Author: Eric Botcazou 
Date:   Thu Nov 19 16:39:34 2020 +0100

Fix PR ada/97805

We need to include limits.h (or ) in adaint.c because of
LLONG_MIN.

gcc/ada/ChangeLog:
PR ada/97805
* adaint.c: Include climits in C++ and limits.h otherwise.

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug target/97865] libtool needs to be updated for Darwin20.

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

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

--- Comment #22 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #19)
> (In reply to Jürgen Reuter from comment #16)
> > (In reply to Iain Sandoe from comment #15)
> > > (In reply to Jürgen Reuter from comment #14)
> 
> 
> > clang: error: argument unused during compilation: '-no-pie'
> > [-Werror,-Wunused-command-line-argument]
> > make[2]: [lto-dump] Error 1 (ignored)
> 
> I saw this issue on i686-darwin9 when trying the branch, it seems that the
> configuration is using the built compiler for this test - but then using the
> build system c++ for the install ... it's not obvious that my changes could
> cause this - I am investigating (it's not a problem if the bootstrap / build
> system c++ support no-pie, which is the case for the gcc-7.5 bootstrap).

I see this error with r11-5147 and no patches applied (so it's pre-existing -
somewhere between r11-5028 and r11-5147).

e.g. i686-darwin9:

make install gives .. 
g++: error: unrecognized command line option '-no-pie'
make[2]: *** [gnat1] Error 1
make[1]: *** [install-gcc] Error 2
make: *** [install] Error 2

x86_64-darwin20 (no configure changes) 

clang: error: argument unused during compilation: '-no-pie'
[-Werror,-Wunused-command-line-argument]
make[2]: *** [cc1plus] Error 1
make[1]: *** [install-gcc] Error 2
make: *** [install] Error 2

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #16 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Andrew Macleod from comment #12)
> > Maybe I'm a little dense.
> > 
> > if we are presuming that  
> >   &x + (a + b) 
> > implies a + b == 0, then we also should assume that
> 
> &x + (a + b) for scalar x doesn't imply a + b == 0, it implies a + b <= 1.
> Only when it is dereferenced, i.e. (&x)[a + b] is accessed a + b has to be 0.

OK. certain things about this still confuse me, but thats OK for now. we'll
come back to them.

There seems to be 2 things at play here:
1) lhs = ptr + X
has certain implications on X, it ptr is &scalar then X = [0, 1] * sizeof
(&scalar)?  
2) if lhs is later de-referenced, then X is known to have been [0,0]?

We're ignoring the nonscalar cases of ptr for now, but Im guessing they are
similar just the values for X are determined differently. 

1) a) could be handled with something like a previously mentioned
range_after_stmt() API for operands which are affected by statements. 
   b)  It can also be impacted by op2_range() during a wind back, but would
likely require some tweaking of gimple_range_calc_op2() to determine that 'ptr'
satisfied the criteria of this scalar condition.   the a) solution would
eliminate the necessity of this.

2) This one is a bit trickier.  We cant use the non-null property since &x +
blah  will already make it non-null... so you are looking for an actual
dereference of itself or an equivalence?   I can probably tweak the non-null
property manager to indicate whether the non-null property also contains a
dereference.. but I guess you would need to know that ALL paths contain a
dereference.

We'd probably get most of what we're looking for if we simply check for a
dereference of LHS in the same block?  and then assert that X is 0.

Is that he basic gist? 
Regardless, I'll come back to this eventually and get someone to clarify all
the intricacies for me, IM just trying to understand the general requirements.

[Bug tree-optimization/97909] New: expr_not_equal_to (mainly in match.pd) vs. ranger

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

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

Bug ID: 97909
   Summary: expr_not_equal_to (mainly in match.pd) vs. ranger
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Something I've noticed today and filing this so that it isn't forgotten.
Various places in match.pd use expr_not_equal_to to decide based on value
ranges whether to perform something or not.
This uses just SSA_NAME_RANGE_INFO under the hood right now.
Would be nice to use range for this; bet we'd need a way for match.pd to
provide
extra information on where it is, so either a gimple *, or perhaps for match.pd
it would be easier to provide a tree, which would be usually SSA_NAME of the
lhs of the statement we want to query the range at, and then the function would
check if the tree is an SSA_NAME and in that case talk to ranger and ask about
range at the start of the SSA_NAME_DEF_STMT.
E.g. we have:
/* X % -Y is the same as X % Y.  */
(simplify
 (trunc_mod @0 (convert? (negate @1)))
 (if (INTEGRAL_TYPE_P (type)
  && !TYPE_UNSIGNED (type)
  && !TYPE_OVERFLOW_TRAPS (type)
  && tree_nop_conversion_p (type, TREE_TYPE (@1))
  /* Avoid this transformation if X might be INT_MIN or
 Y might be -1, because we would then change valid
 INT_MIN % -(-1) into invalid INT_MIN % -1.  */
  && (expr_not_equal_to (@0, wi::to_wide (TYPE_MIN_VALUE (type)))
  || expr_not_equal_to (@1, wi::minus_one (TYPE_PRECISION
(TREE_TYPE (@1))
  (trunc_mod @0 (convert @1
so if expr_not_equal_to has a defaulted = NULL_TREE extra argument, the second
expr_not_equal_to could pass as the third argument @2 where it would be
(negate@2 @1).  Unclear if we have something to pass for the trunc_mod's LHS or
how to identify that statement.

Testcase for exactly this could be:
  int x = foo (), y;
  if (x != -1)
y = z % -x;
  else
y = -1; 
where we could optimize the y = z % -x; to y = z % x; but don't currently,
because we know that x is not -1 only in certain paths and SSA_NAME_RANGE_INFO
can't reflect that.

[Bug gcov-profile/97910] New: [GCOV]"&&" lead to incorrect code coverage when multiple expressions of a single statement fall in different lines

[yangyibiao at outlook dot com via Gcc-bugs]

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

Bug ID: 97910
   Summary: [GCOV]"&&" lead to incorrect code coverage when
multiple expressions of a single statement fall in
different lines
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at outlook dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ cat test.c
struct hx {
  int a, b, c;
} __attribute__ ((aligned));

static struct hx x = {0xc11f, 0xc22f, ~1};
static struct hx y = {0xfd10, 0xfe20, ~2};

int f()
{
  return ((x.a & 0x3ff0) == (y.a & 0x03ff) && 
   (x.b & 0x3ff0) == (y.b & 0x03ff));
}

int main() { f(); }

$ gcc -O0 --coverage test.c; ./a.out; gcov test.c; cat test.c.gcov
File 'test.c'
Lines executed:100.00% of 4
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:struct hx {
-:2:  int a, b, c;
-:3:} __attribute__ ((aligned));
-:4:
-:5:static struct hx x = {0xc11f, 0xc22f, ~1};
-:6:static struct hx y = {0xfd10, 0xfe20, ~2};
-:7:
1:8:int f()
-:9:{
   2*:   10:  return ((x.a & 0x3ff0) == (y.a & 0x03ff) && 
1:   11:   (x.b & 0x3ff0) == (y.b & 0x03ff));
-:   12:}
-:   13:
1:   14:int main() { f(); }


We can found that Line #10 is wrongly marked as executed twice. 
When debug this program in debugger, Line 10 is only hit once.
Note that: When Line 10 and Line 11 in the same line, the result will be
correct. 


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

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

[Bug other/97911] New: [11 regression] make install issue undefined reference to std::__throw_bad_array_new_length after r11-5142

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

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

Bug ID: 97911
   Summary: [11 regression] make install issue undefined reference
to std::__throw_bad_array_new_length after r11-5142
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d326ebc94f3b2b0d962fb9e253564b39106a10da, r11-5142 


commit d326ebc94f3b2b0d962fb9e253564b39106a10da (HEAD)
Author: Jakub Jelinek 
Date:   Wed Nov 18 20:11:37 2020 +0100

configury: --enable-link-serialization support


make install
. . .
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o go1 \
  go/ast-dump.o go/escape.o go/export.o go/expressions.o go/go-backend.o
go/go-diagnostics.o go/go-encode-id.o go/go-dump.o go/go-gcc.o
go/go-gcc-diagnostics.o go/go-lang.o go/go-linemap.o go/go-optimize.o
go/go-sha1.o go/go.o go/gogo.o go/import.o go/import-archive.o go/lex.o
go/names.o go/parse.o go/runtime.o go/statements.o go/types.o go/unsafe.o
go/wb.o attribs.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
-L/home/seurer/gcc/git/build/gcc-test/./isl/.libs  -lisl
-L/home/seurer/gcc/git/build/gcc-test/./gmp/.libs
-L/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs -lmpc -lmpfr -lgmp
-rdynamic -ldl  -L./../zlib -lz 
go/escape.o: In function `Node::make_node(Named_object*)':
/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
undefined reference to `std::__throw_bad_array_new_length()'
go/escape.o: In function `Node::make_node(Expression*)':
/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
undefined reference to `std::__throw_bad_array_new_length()'
go/escape.o: In function `Node::make_node(Statement*)':
/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
undefined reference to `std::__throw_bad_array_new_length()'
go/escape.o: In function `Escape_analysis_discover::visit(Named_object*)':
/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
undefined reference to `std::__throw_bad_array_new_length()'
go/escape.o: In function `Gogo::analyze_escape()':
/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
undefined reference to `std::__throw_bad_array_new_length()'
go/escape.o:/home/seurer/gcc/git/build/gcc-test/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:110:
more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: error: ld returned 1 exit status
/home/seurer/gcc/git/gcc-test/gcc/go/Make-lang.in:83: recipe for target 'go1'
failed
make[2]: *** [go1] Error 1
make[2]: Leaving directory '/home3/seurer/gcc/git/build/gcc-test/gcc'
Makefile:5132: recipe for target 'install-gcc' failed
make[1]: *** [install-gcc] Error 2
make[1]: Leaving directory '/home3/seurer/gcc/git/build/gcc-test'
Makefile:2445: recipe for target 'install' failed
make: *** [install] Error 2

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
(In reply to Jan Engelhardt from comment #0)
> dlclose(hnd);
> printf("%s\n", name);

This is just a user bug, don't dlclose a library when you are using anything
from it.

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #49588|0   |1
is obsolete||

--- Comment #8 from Uroš Bizjak  ---
Created attachment 49598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49598&action=edit
Proposed v2 patch

This patch implements different approach, where we expand ABS to an ABS RTX. 
The patch introduces STV handling of ABS insn and splits to optimal sequence if
STV isn't profitable. The patch also fixes various issues with existing minmax,
neg and abs patterns.

[Bug libstdc++/97912] New: Get rid of location-invariant requirement in std::function small object optimisation

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

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

Bug ID: 97912
   Summary: Get rid of location-invariant requirement in
std::function small object optimisation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: barry.revzin at gmail dot com
  Target Milestone: ---

std::function will only store the target object in an internal buffer (rather
than on the heap) if it is "location invariant", which means trivially
copyable.

It would be good to remove the trivially copyable requirement, and store any
type of suitable size and alignment to fit in the buffer.

The difficulty is that std::function::swap does a byte-wise copy of the
_Any_data buffer, which is why we require trivially copyable. Changing that
might be an ABI break (existing code will have inlined that function::swap
definition, and will still do a byte-wise copy rather than whatever the new
code does to support non-trivially copyable types).

This testcase fails if we remove the trivially copyable requirement:

#include 
#include 

struct selfobsessed
{
  selfobsessed() : me(this) { }

  selfobsessed(const selfobsessed&) : me(this) { }
  selfobsessed& operator=(const selfobsessed&) { return *this; }

  void operator()() const { assert(me == this); }

  selfobsessed* me;
};

int main()
{
  std::function f1( selfobsessed{} );
  std::function f2;
  swap(f1, f2);
  f2();
}

[Bug libstdc++/97912] Get rid of location-invariant requirement in std::function small object optimisation

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> It would be good to remove the trivially copyable requirement, and store any
> type of suitable size and alignment to fit in the buffer.

Well, we'd still require nothrow move constructible. So not *any* type.

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC|richard.sandiford at arm dot com   |rsandifo at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Hmm, could have sworn I'd added a test for this, but obviously
I didn't…

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

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

https://gcc.gnu.org/g:255483e5b70beade63efdf1f3efa6b814831da08

commit r11-5176-g255483e5b70beade63efdf1f3efa6b814831da08
Author: Nathan Sidwell 
Date:   Thu Nov 19 08:00:49 2020 -0800

c++: Relax new assert [PR 97905]

It turns out there are legitimate cases for the new decl to not have
lang-specific.

PR c++/97905
gcc/cp/
* decl.c (duplicate_decls): Relax new assert.
gcc/testsuite/
* g++.dg/lookup/pr97905.C: New.

[Bug c++/97905] [11 Regression] ice in duplicate_decls, at cp/decl.c:2754

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #9 from Nathan Sidwell  ---
fixed 255483e5b70

[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
With current trunk I'm seeing:

FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tadd\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tadd\\tz[0-9]+\\.h, z[0-9]+\\.h, z[0-9]+\\.h\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tadd\\tz[0-9]+\\.s, z[0-9]+\\.s, z[0-9]+\\.s\\n 10
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecd\\tz[0-9]+\\.d, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecd\\tz[0-9]+\\.d, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecd\\tz[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdech\\tz[0-9]+\\.h, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdech\\tz[0-9]+\\.h, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdech\\tz[0-9]+\\.h\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecw\\tz[0-9]+\\.s, all, mul #15\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecw\\tz[0-9]+\\.s, all, mul #16\\n 1
FAIL: gcc.target/aarch64/sve/loop_add_4.c -march=armv8.2-a+sve 
scan-assembler-times \\tdecw\\tz[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve 
scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_2.c -march=armv8.2-a+sve 
scan-assembler-times \\trevb\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_3.c -march=armv8.2-a+sve 
scan-assembler-times \\trevb\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1
FAIL: gcc.target/aarch64/sve/slp_perm_6.c -march=armv8.2-a+sve 
scan-assembler-times \\ttbl\\tz[0-9]+\\.b, z[0-9]+\\.b, z[0-9]+\\.b\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #-32768\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #256\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #2\\n 3
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #-128\\n 1
FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve 
scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #2\\n 1

Christophe, does that match your results?

[Bug tree-optimization/97909] expr_not_equal_to (mainly in match.pd) vs. ranger

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
Yeah, I'm planning as one of the next steps to replace the
SSA_NAME_RANGE_INFO/get_range_info interface with the new range_query interface
from value-query.h

Then we can wire that into the Ranger instance that a pass is using, if there
is one.

Then any of these components, like this or the gimple-folder can make use of
better range info if they know anything about the context in which they are
working.

Once I finish going through these PRs, I plan to produce a work-list of all the
mini-projects to complete each thing.  We can use this PR for the global range
availability part.

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-19
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r11-2774, before that we compiled the code.  clang++ compiles it
fine too.

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective

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

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

--- Comment #15 from Jan Hubicka  ---
Current  mainline with 
 1) fix to COMPONENT_REFs described above
 2) improvement of ODR type having for THIS pointers
 3) gimple_clobber fix (already approved)
 4) compare_ao_refs fix for volatile accesses
 5) compare_decs change so it does not test type compatibility of automatic
vars (since these types have little meaning)

  1   false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:163 
   
1   false returned: 'replaceable operator flags
are different' in compare_referenced_symbol_properties at
../../gcc/ipa-icf.c:359
4   false returned: '' in compare_bb at ../../gcc/ipa-icf-gimple.c:606 
   
  7   false returned: 'Mismatched number of parameters'
in equals_wpa at ../../gcc/ipa-icf.c:651   
9   false returned: '' in
compare_variable_decl at ../../gcc/ipa-icf-gimple.c:447
   
9   false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:312
   
 10   false returned: 'INTEGER_CST precision mismatch'
in equals at ../../gcc/ipa-icf.c:1807  
11   false returned: 'case
low values are different' in compare_gimple_switch at
../../gcc/ipa-icf-gimple.c:808 
 23   false returned: '' in operand_equal_p at
../../gcc/ipa-icf-gimple.c:303 
23   false
returned: 'one type is not polymorphic' in compatible_polymorphic_types_p at
../../gcc/ipa-icf-gimple.c:208 
  23   false returned: 'THIS pointer ODR type mismatch' in
equals_wpa at ../../gcc/ipa-icf.c:678  
 29   false returned: 'ASM
strings are different' in compare_gimple_asm at ../../gcc/ipa-icf-gimple.c:909
 46   false returned: 'GIMPLE call operands are different' in
compare_gimple_call at ../../gcc/ipa-icf-gimple.c:681
141   false returned: 'Declaration mismatch' in equals at
../../gcc/ipa-icf.c:1803
169   false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:175
182   false returned: 'DECL_CXX_DESTRUCTOR mismatch' in equals_wpa at
../../gcc/ipa-icf.c:565
246   false returned: 'final flag mismatch' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:401
391   false returned: '' in compare_phi_node at ../../gcc/ipa-icf.c:1581
391   false returned: 'PHI node comparison returns false' in equals_private
at ../../gcc/ipa-icf.c:922
571   false returned: 'compare_ao_refs failed (dependence clique
difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:373
676   false returned: 'compare_ao_refs failed (semantic difference)' in
compare_operand at ../../gcc/ipa-icf-gimple.c:361
676   false returned: 'METHOD_TYPE and FUNCTION_TYPE mismatch' in
equals_wpa at ../../gcc/ipa-icf.c:674
707   false returned: 'operand_equal_p failed' in compare_operand at
../../gcc/ipa-icf-gimple.c:381
957   false returned: 'different references' in compare_symbol_references
at ../../gcc/ipa-icf.c:465
961   false returned: 'size mismatch' in equals_wpa at
../../gcc/ipa-icf.c:1652
   1125   false returned: 'variables types are different' in equals at
../../gcc/ipa-icf.c:1698
   1171   false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at
../../gcc/ipa-icf.c:562
   1321   false returned: 'GIMPLE assignment operands are different' in
compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:724
   2209   false returned: 'different decl attributes' in equals_wpa at
../../gcc/ipa-icf.c:663
   4643   false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign
at ../../gcc/ipa-icf-gimple.c:720
   8400   false returned: 'parameter type is not compatible' in
compatible_parm_types_p at ../../gcc/ipa-icf.c:512
  10187   false returned: 'inline attributes are different' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350
  16210   false returned: 'parameter types are not compatible' in equals_wpa at
../../gcc/ipa-icf.c:640
  26071   false returned: 'references to virtual tables cannot be merged' in
compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373
  28810   false returned: 'decl_or_type flags are different' i

[Bug c++/97296] [10/11 Regression] g++ accepts-invalid after DR2352 fix

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-19

[Bug c++/97913] New: -fno-delete-null-pointer-checks not working properly with constexpr

[mfarazma.ext at gmail dot com via Gcc-bugs]

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

Bug ID: 97913
   Summary: -fno-delete-null-pointer-checks not working properly
with constexpr
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mfarazma.ext at gmail dot com
  Target Milestone: ---

Compiling this code:

```
constexpr int test(const int *arr) {
  if(arr == 0){
 //
   }
  return 5;
}

int main(){
  static constexpr int arr[] = {1,2,3};
  static constexpr int b =  test(arr);
  return 0;
}

```
With "g++ -fno-delete-null-pointer-check test.cc" generates this error:

error '(((const int*)(& arr)) == 0u)' is not a constant expression.  

Seems like an odd behaviour as clang++ is able to compile this successfully.
I have tested it on gcc 6, 7, 9 as well has "HEAD 11.0.0".

[Bug c++/97914] New: -fno-delete-null-pointer-checks not working properly with constexpr

[mfarazma.ext at gmail dot com via Gcc-bugs]

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

Bug ID: 97914
   Summary: -fno-delete-null-pointer-checks not working properly
with constexpr
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mfarazma.ext at gmail dot com
  Target Milestone: ---

Compiling this code:

```
constexpr int test(const int *arr) {
  if(arr == 0){
 //
   }
  return 5;
}

int main(){
  static constexpr int arr[] = {1,2,3};
  static constexpr int b =  test(arr);
  return 0;
}

```
With "g++ -fno-delete-null-pointer-check test.cc" generates this error:

error '(((const int*)(& arr)) == 0u)' is not a constant expression.  

Seems like an odd behaviour as clang++ is able to compile this successfully.
I have tested it on gcc 6, 7, 9 as well has "HEAD 11.0.0".

[Bug c++/97883] [C++20] Segmentation fault on template with braced initializer list A<{}>

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
This is actually PR97895 for which I already posted a patch and should be fixed
before long.

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

[Bug c++/97895] [11 Regression] ICE in do_auto_deduction, at cp/pt.c:29255

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

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

[Bug c++/97914] -fno-delete-null-pointer-checks not working properly with constexpr

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
.

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

[Bug c++/97913] -fno-delete-null-pointer-checks not working properly with constexpr

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

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

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

[Bug c++/97913] -fno-delete-null-pointer-checks not working properly with constexpr

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-11-19

--- Comment #2 from Marek Polacek  ---
Confirmed, but could be a dup of one of the other constexpr issues we've
accrued .

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Looks invalid.

[Bug c++/97852] Parameter pack not found

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Reduced.  Not sure if valid.

template  struct S;
template  auto foo(T t) -> S;