[Bug target/101276] [i386] Keylocker output should be cleared when instruction reports runtime error.

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
Note this is not a bug, but a re-implementation of the keylocker intrinsic from
a security perspective.

[Bug tree-optimization/101145] niter analysis fails for until-wrap condition

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

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

--- Comment #8 from Jiu Fu Guo  ---
Reference the code of adjust_cond_for_loop_until_wrap, add code for non-const
cases.  Code was added in adjust_cond_for_loop_until_wrap at beginning, to set
may_be_zero and no_overflow, the code was moved to number_of_iterations_lt at
last.

The patch was submitted as: 
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574110.html

[Bug target/101276] New: [i386] Keylocker output should be cleared when instruction reports runtime error.

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 101276
   Summary: [i386] Keylocker output should be cleared when
instruction reports runtime error.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

Some keylocker instruction will set ZF when runtime occurs, and the output data
should be invalid. 

Current intrinsic just copy the input data to output regardless of the ZF, like

 movdqa  k2(%rip), %xmm0
 aesdec128kl h1(%rip), %xmm0
 sete%al
 movups  %xmm0, k1(%rip)

It could bring safety issue that return the unencrypted data when runtime error
occurs. So the code should be like

movdqa  k2(%rip), %xmm0
aesdec128kl h1(%rip), %xmm0
je  .L4
.L2:
sete%al
movups  %xmm0, k1(%rip)
ret
.L4:
pxor%xmm0, %xmm0
jmp .L2

To clear the output data.

[Bug tree-optimization/101097] Vectorizer is too eager to use vec_unpack

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #12)
> (In reply to rsand...@gcc.gnu.org from comment #11)
> > FWIW, you could try something similar to how aarch64 handles this
> > for Advanced SIMD, with a combination of:
> > 
> > - TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES
> > - TARGET_VECTORIZE_RELATED_MODE.
> I added a target_hook to return vector mode with same element number for
> i386 backend.
> It works for this case, but regresses many testcases which are related to
> gather/scatter instructions, because gather/scatter instructions accept same
> vector size but not same element number.
> 
>   /* AVX2 */
>   def_builtin_pure (OPTION_MASK_ISA_AVX2, 0, "__builtin_ia32_gathersiv2df",
>   V2DF_FTYPE_V2DF_PCDOUBLE_V4SI_V2DF_INT,
>   IX86_BUILTIN_GATHERSIV2DF);

It hits the gcc_assert in tree-vect-stmts.c:vect_build_gather_load_calls

  if (!useless_type_conversion_p (idxtype, TREE_TYPE (op)))
{
  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (op)),
TYPE_VECTOR_SUBPARTS (idxtype)));

[Bug tree-optimization/101097] Vectorizer is too eager to use vec_unpack

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Hongtao.liu  ---
(In reply to rsand...@gcc.gnu.org from comment #11)
> FWIW, you could try something similar to how aarch64 handles this
> for Advanced SIMD, with a combination of:
> 
> - TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES
> - TARGET_VECTORIZE_RELATED_MODE.
I added a target_hook to return vector mode with same element number for i386
backend.
It works for this case, but regresses many testcases which are related to
gather/scatter instructions, because gather/scatter instructions accept same
vector size but not same element number.

  /* AVX2 */
  def_builtin_pure (OPTION_MASK_ISA_AVX2, 0, "__builtin_ia32_gathersiv2df",
V2DF_FTYPE_V2DF_PCDOUBLE_V4SI_V2DF_INT,
IX86_BUILTIN_GATHERSIV2DF);

[Bug c++/101194] [9/10/11/12 Regression] aggregate init requires default constructor

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

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

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

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

commit r12-1946-ga688c284dd3848b6c4ea553035f0f9769fb4fbc9
Author: Patrick Palka 
Date:   Wed Jun 30 20:44:52 2021 -0400

c++: cxx_eval_array_reference and empty elem type [PR101194]

Here the initializer for x is represented as an empty CONSTRUCTOR due to
its empty element type.  So during constexpr evaluation of the ARRAY_REF
x[0], we end up trying to value initialize the omitted element at index 0,
which fails because the element type is not default constructible.

This patch makes cxx_eval_array_reference specifically handle the case
where the element type is an empty type.

PR c++/101194

gcc/cp/ChangeLog:

* constexpr.c (cxx_eval_array_reference): When the element type
is an empty type and the corresponding element is omitted, just
return an empty CONSTRUCTOR instead of attempting value
initialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty16.C: New test.

[Bug c++/96204] gcc complains about private member access in SFINAE context

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

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

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

https://gcc.gnu.org/g:613497aa6e28ca009d8498002424019d2a8a9ca5

commit r12-1945-g613497aa6e28ca009d8498002424019d2a8a9ca5
Author: Patrick Palka 
Date:   Wed Jun 30 20:21:16 2021 -0400

c++: Extend the PR96204 fix to variable templates too

r12-1829 corrected the access scope during partial specialization
matching of class templates, but overlooked the variable template case.
This patch moves the access scope adjustment to within
most_specialized_partial_spec so that all callers can benefit.

This patch also adjusts a couple of these callers to avoid always
passing the most general template of a variable template specialization,
since that'd cause us to push the wrong access scope for e.g. the second
testcase below (we'd push A instead of A/A).  We ought to
be passing the partially instantiated template instead.

PR c++/96204

gcc/cp/ChangeLog:

* pt.c (finish_template_variable): Pass the partially
instantiated template and its args to instantiate_template.
(instantiate_class_template_1): No need to call
push_nested_class and pop_nested_class around the call to
most_specialized_partial_spec.
(instantiate_template_1): Pass the partially instantiated
template to lookup_template_variable.
(most_specialized_partial_spec):  Use push_access_scope_guard
to set the access scope appropriately.  Use
deferring_access_check_sentinel to force access to get checked
immediately.
(instantiate_decl): Just pass the VAR_DECL to
most_specialized_partial_spec.

gcc/testsuite/ChangeLog:

* g++.dg/template/access41.C: New test.
* g++.dg/template/access41a.C: New test.

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #17 from Jonathan Wakely  ---
Fixed now anyway

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

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

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

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

https://gcc.gnu.org/g:6963c3b9ed1308bf5d2d8877956e56fec92853a7

commit r12-1943-g6963c3b9ed1308bf5d2d8877956e56fec92853a7
Author: Jonathan Wakely 
Date:   Wed Jun 30 16:00:58 2021 +0100

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

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

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

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

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

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

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

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

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

--- Comment #15 from Jonathan Wakely  ---
Yes, what I said was:

(In reply to Jonathan Wakely from comment #6)
> So unless we suddenly run out of new features to implement and bugs to fix,
> I don't think anybody is going to add documentation for everything like that.

[Bug c/101275] New: [RISCV] Document the machine constraint 'S' and make it non-internal

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 101275
   Summary: [RISCV] Document the machine constraint 'S' and make
it non-internal
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

An absolute symbolic operand is useful in inline asm. In aarch64 and x86-64,
there is a documented (supported) approach.

// aarch64
// 'S' is documented on
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
extern int var;
void *addr() { return &var; }
void *addr_via_asm() {
  void *ret;
  asm("adrp %0, %1\nadd %0, %0, :lo12:%1" : "=r"(ret) : "S"(&var));
  return ret;
}
// x86-64
// https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86-Operand-Modifiers
// 'P' is useful in some cases.
extern int var;
void *addr() { return &var; }
void *addr_via_asm() {
  void *ret;
  asm("movl %1, %k0" : "=r"(ret) : "i"(&var));
  return ret;
}

For riscv there is no supported approach. The following code works

// riscv
extern int var;
void *addr() { return &var; }
void *addr_via_asm() {
  void *ret;
  asm("lui %0, %%hi(%1)\naddi %0,%0,%%lo(%1)" : "=r"(ret) : "S"(&var));
  return ret;
}

but it uses the internal/undocumented constraint "S"

  // gcc/config/riscv/constraints.md
  (define_constraint "S"
"@internal
 A constant call address."
(match_operand 0 "absolute_symbolic_operand"))

I hope this can made supported/documented/non-internal.

---

Why do I want this?

In the Linux kernel, arch/riscv/include/asm/vdso.h defines

  /*
   * The VDSO symbols are mapped into Linux so we can just use regular symbol
   * addressing to get their offsets in userspace.  The symbols are mapped at
an
   * offset of 0, but since the linker must support setting weak undefined
   * symbols to the absolute address 0 it also happens to support other low
   * addresses even when the code model suggests those low addresses would not
   * otherwise be availiable.
   */
  #define VDSO_SYMBOL(base, name)  
 \
  ({   
 \
  extern const char __vdso_##name[];   
 \
  (void __user *)((unsigned long)(base) + __vdso_##name);  
 \
  })

arch/riscv/kernel/signal.c has

  regs->ra = (unsigned long)VDSO_SYMBOL(
  current->mm->context.vdso, rt_sigreturn);

The file is compiled with -fno-PIE -mcmodel=medany. Because of medany, auipc is
generated:

 36e:   0697auipc   a3,0x0
36e: R_RISCV_PCREL_HI20 __vdso_rt_sigreturn
36e: R_RISCV_RELAX  *ABS*
 372:   00068693mv  a3,a3

At link time, auipc/mv (PC-relative) is rewritten as lui/addi (absolute):

  ffe000201880:   16b7lui a3,0x1
  ffe000201884:   80068693addia3,a3,-2048 # 800
<__vdso_rt_sigreturn>

The absolute address is needed for correctness. With PC-relative insns, the
runtime address will be different from its link-time address and
current->mm->context.vdso + __vdso_rt_sigreturn will be wrong.

It is fragile to rely on linker instruction rewritting (part of linker
relaxation) to do this correctness related stuff!

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Wed, 30 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote:

> > [[attr1]] int [[attr2]] a[10] [[attr3]], b [[attr4]];
> > attr1 appertains to the variable declarations a and b, attr2
> > appertains to the type int, attr3 appertains to the variable
> > declaration a, and attr4 appertains to the variable declaration b.

That looks like an error in introductory text describing that proposal 
(not text that was proposed for addition to the standard itself).  I at 
least mainly concentrate on the proposed changes to the standard text when 
reviewing the details of C standards proposals; mistakes of detail outside 
those changes aren't really important.  The current working draft is 
N2596, which has plenty of attributes-related changes that postdate the 
original proposal for attributes support; you should search for the word 
"appertain" there and disregard the older proposal.

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

[gcc at alanwu dot email via Gcc-bugs]

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

--- Comment #2 from Alan Wu  ---
> int thisdoesnt[1] [[maybe_unused]];
> Whereas that one appertains to the array type

This seems to contradict the latest document I could find about the attribute
syntax proposal. From N2335
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2335.pdf:


> [[attr1]] int [[attr2]] a[10] [[attr3]], b [[attr4]];
> attr1 appertains to the variable declarations a and b, attr2
> appertains to the type int, attr3 appertains to the variable
> declaration a, and attr4 appertains to the variable declaration b.

GCC warns about a and b for the following:

void foo(void) {
int a[10] [[maybe_unused]], b;
}

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

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #14 from Christopher Yeleighton  ---
Will you accept an improvement regarding an issue RESOLVED WONTFIX?

[Bug libstdc++/101268] Refer manual readers to cppreference.com for API details

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Christopher Yeleighton from comment #0)
> (I mean patches are not welcome)

Have you actually tried submitting any? I only see bug reports from you, not
patches.

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

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

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

--- Comment #13 from Jonathan Wakely  ---
I never said to read the standard though. I said to use cppreference.com

I repeat, cppreference.com is not the standard. What you are looking for is
cppreference.com.

(In reply to Christopher Yeleighton from comment #12)
> can still hardly accept that we are such a failure in this area (I believe
> that if we have time to implement things, we should also dedicate some to
> describe them).

Why don't you contribute improvements then?

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

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #12 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #10)
> Lots of things in our API docs are not in the standard, and lots of things
> in the standard are not in our API docs. If you're trying to use it for
> that, no wonder it's painful. Stop it.

The difference between compiler documentation and the standard is that compiler
documentation is easier to use and to understand and more task-oriented,
although it may be incomplete.  I understand the difference.  I understand that
compiler documentation may sacrifice precision for clarity here and there.  The
sacrifice must not go too far though---hence my patches to MSDN for example.  I
still prefer reading the vendor documentation to reading the standard, except
in some special cases.

I promise I shall stop using GCC documentation if said documentation tells me
what I should use instead.  I have reported a request regarding that.  I can
still hardly accept that we are such a failure in this area (I believe that if
we have time to implement things, we should also dedicate some to describe
them).

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

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

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

--- Comment #11 from Andrew Pinski  ---
Note the v in is_integral_v stands for value :).

GCC's job is also not to teach you C++, though the documentation and warnings
can help.

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

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

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

--- Comment #10 from Jonathan Wakely  ---
Lots of things in our API docs are not in the standard, and lots of things in
the standard are not in our API docs. If you're trying to use it for that, no
wonder it's painful. Stop it.

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

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Christopher Yeleighton from comment #8)
> reply from the API doc was negative.

Stop trying to use it to check what is in the standard. It's not meant for
that.

[Bug c++/101181] [11/12 Regression] ICE when using an alias template

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-30
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Summary|ICE when using an alias |[11/12 Regression] ICE when
   |template|using an alias template
   Target Milestone|--- |11.2
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r11-3261.

[Bug testsuite/101269] new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852

[ibhagatgnu at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Indu Bhagat  ---
Confirmed. This is reproducible with -m32.

[Bug c++/100459] [10/11/12 regression] constexpr decltype(auto) variable declaration bogus cv qual error

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Closing as invalid.

[Bug tree-optimization/101260] [10/11 Regression] Backport 27381e78925 to GCC 11

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

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
I had a look at the optimized tree output which looks good to me. However, I
see that split2 transforms

(insn 218 222 114 15 (set (reg/v:TI 10 %r10 [orig:87 a ] [87])
(reg/v:TI 18 %f4 [orig:87 a ] [87])) 1466 {movti}
 (nil))

into

(insn 234 222 235 15 (set (reg:DI 10 %r10 [ a ])
(reg:DI 18 %f4)) 1467 {*movdi_64}
 (nil))
(insn 235 234 114 15 (set (reg:DI 11 %r11 [orig:87 a+8 ] [87])
(unspec:DI [
(reg:V2DI 18 %f4)
(const_int 1 [0x1])
] UNSPEC_VEC_EXTRACT)) 495 {*vec_extractv2di}
 (nil))

which might be wrong. If I swap r10 by r11 via

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 7faf775fbf2..0319934062a 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -1747,8 +1747,8 @@
(set (match_dup 3) (unspec:DI [(match_dup 5) (const_int 1)]
 UNSPEC_VEC_EXTRACT))]
 {
-  operands[2] = operand_subword (operands[0], 0, 0, TImode);
-  operands[3] = operand_subword (operands[0], 1, 0, TImode);
+  operands[2] = operand_subword (operands[0], 1, 0, TImode);
+  operands[3] = operand_subword (operands[0], 0, 0, TImode);
   operands[4] = gen_rtx_REG (DImode, REGNO (operands[1]));
   operands[5] = gen_rtx_REG (V2DImode, REGNO (operands[1]));
 })

then the compiled program just runs fine. However, I'm not sure whether this
fixes the problem or just the symptoms. I will come back to this tomorrow.

[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |MOVED

[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/101260] [10/11 Regression] Backport 27381e78925 to GCC 11

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

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

--- Comment #6 from Jakub Jelinek  ---
I've reproduced it with -O1 -march=z14 and it started with
r10-7093-g5dc1390b41db5c1765e25fd21dad1a930a015aac
So, I think it is much more likely some RA issue or RTL optimization issue and
the r12-145 change just makes it latent.

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Tue, 29 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote:

> [[maybe_unused]] int thisworks[1];

That attribute appertains to the declared entity.

> int thisdoesnt[1] [[maybe_unused]];

Whereas that one appertains to the array type (that position after an 
array declarator can also be used for e.g. a pointer to an array, an array 
of arrays, etc., and an attribute there appertains to the specific array 
given by that declarator - not the declared entity as a whole).

It's not clear what it would mean to declare that some particular part of 
the type of an entity is possibly unused like that.  Appropriate places in 
a declaration are either at the start as in the first example, or after 
the identifier where an attribute specifier sequence appertains to the 
declared entity.

In general you need to be a lot more careful about the positioning of [[]] 
attributes than __attribute__.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 100975 Summary: [C++23] Allow pointer to array of auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100975

   What|Removed |Added

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

[Bug c++/100975] [C++23] Allow pointer to array of auto

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Implemented in GCC 12.

[Bug c++/100975] [C++23] Allow pointer to array of auto

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

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

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

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

commit r12-1933-ge66d0b7b87d105d24da8c4784a0b907fb6b2c095
Author: Marek Polacek 
Date:   Tue Jun 29 14:30:51 2021 -0400

c++: DR2397 - auto specifier for * and & to arrays [PR100975]

This patch implements DR2397, which removes the restriction in
[dcl.array]p4 that the array element type may not be a placeholder
type.  We don't need to worry about decltype(auto) here, so this
allows code like

  int a[3];
  auto (*p)[3] = &a;
  auto (&r)[3] = a;

However, note that

  auto (&&r)[2] = { 1, 2 };
  auto arr[2] = { 1, 2 };

still doesn't work (although one day it might) and neither does

  int arr[5];
  auto x[5] = arr;

given that auto deduction is performed in terms of function template
argument deduction, so the array decays to *.

PR c++/100975
DR 2397

gcc/cp/ChangeLog:

* decl.c (create_array_type_for_decl): Allow array of auto.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/auto24.C: Remove dg-error.
* g++.dg/cpp0x/auto3.C: Adjust dg-error.
* g++.dg/cpp0x/auto42.C: Likewise.
* g++.dg/cpp0x/initlist75.C: Likewise.
* g++.dg/cpp0x/initlist80.C: Likewise.
* g++.dg/diagnostic/auto1.C: Remove dg-error.
* g++.dg/cpp23/auto-array.C: New test.

[Bug c++/101274] std::execution::seq has incorrect behaviour under GCC 11.1.0

[general at yhf8377 dot me via Gcc-bugs]

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

--- Comment #1 from yhf8377  ---
Sorry, forgot to list the compiler options we used.

g++ -std=c++17 -g -m64 -O0 -Wall -fmessage-length=0 -pthread -o gcc_test
src/main.cpp

[Bug c++/101274] New: std::execution::seq has incorrect behaviour under GCC 11.1.0

[general at yhf8377 dot me via Gcc-bugs]

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

Bug ID: 101274
   Summary: std::execution::seq has incorrect behaviour under GCC
11.1.0
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: general at yhf8377 dot me
  Target Milestone: ---

Created attachment 51091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51091&action=edit
Minimal code to reproduce the error

We have a unit test that passes when compiled with GCC 10 but fails when
compiled with GCC 11. Further digging shows that calling `std::reduce()` with
execution policy `std::execution::seq` does not execute the provided function
object in sequential order.

Attached is the minimal test case that shows the different behaviour under GCC
10 and GCC 11.

Under GCC 10 (10.3.0) the output is:

plus_squared_ignore_nan: a = nan, b = 336.88
plus_squared_ignore_nan: a = 113488, b = nan
plus_squared_ignore_nan: a = 113488, b = 818.6
plus_squared_ignore_nan: a = 783594, b = nan
plus_squared_ignore_nan: a = 783594, b = 521.16
plus_squared_ignore_nan: a = 1.0552e+06, b = 451.78
plus_squared_ignore_nan: a = 1.25931e+06, b = 601.78
plus_squared_ignore_nan: a = 1.62145e+06, b = 709.2
plus_squared_ignore_nan: a = 2.12441e+06, b = 262.55
plus_squared_ignore_nan: a = 2.19334e+06, b = 659.67
plus_squared_ignore_nan: a = 2.62851e+06, b = 56.6
plus_squared_ignore_nan: a = 2.63171e+06, b = 780.31
plus_squared_ignore_nan: a = 3.2406e+06, b = 398.74

Correct! sum_squared == 3399588.6719

Under GCC 11 (11.1.0) the output is:

plus_squared_ignore_nan: a = 336.88, b = nan
plus_squared_ignore_nan: a = 818.6, b = nan
plus_squared_ignore_nan: a = 336.88, b = 818.6
plus_squared_ignore_nan: a = nan, b = 670443
plus_squared_ignore_nan: a = 521.16, b = 451.78
plus_squared_ignore_nan: a = 601.78, b = 709.2
plus_squared_ignore_nan: a = 204626, b = 503566
plus_squared_ignore_nan: a = 4.49494e+11, b = 2.53579e+11
plus_squared_ignore_nan: a = 262.55, b = 659.67
plus_squared_ignore_nan: a = 56.6, b = 780.31
plus_squared_ignore_nan: a = 435427, b = 608940
plus_squared_ignore_nan: a = 6.43025e+22, b = 3.70809e+11
plus_squared_ignore_nan: a = 2.01802e+23, b = 398.74
gcc_test: src/main.cpp:24: int main(int, char**): Assertion `sum_squared ==
3399588.6719' failed.
Aborted

[Bug libstdc++/101271] [12 Regression] error: ‘static constexpr decltype ... used before its definition

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

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

--- Comment #1 from Jonathan Wakely  ---
This is the workaround for the undefined llvm code, but I don't understand the
error.

[Bug tree-optimization/101272] [12 Regression] error: ‘nonnull’ argument ‘message’ compared to NULL [-Werror=nonnull-compare] since r12-1805

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

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[12 Regression] error:  |[12 Regression] error:
   |‘nonnull’ argument  |‘nonnull’ argument
   |‘message’ compared to NULL  |‘message’ compared to NULL
   |[-Werror=nonnull-compare]   |[-Werror=nonnull-compare]
   |since   |since r12-1805
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
The warning is valid and expected.  It started to be issued with r12-1805. 
Prior to that, the parentheses around the inequality expression suppressed it,
like so:

$ cat t.C && cc1plus.r12-1804 -quiet -Wall -Werror -o/dev/null t.C
__attribute__ ((nonnull)) void
f (int *p) { p == 0 ? __builtin_abort () : (void)0; }

__attribute__ ((nonnull)) void
g (int *p) { (p == 0) ? __builtin_abort () : (void)0; }

t.C: In function ‘void f(int*)’:
t.C:2:21: error: ‘nonnull’ argument ‘p’ compared to NULL
[-Werror=nonnull-compare]
2 | f (int *p) { p == 0 ? __builtin_abort () : (void)0; }
  |  ~~~^~
cc1plus.r12-1804: all warnings being treated as errors

[Bug d/101273] New: d: missed RVO optimization with non-pod structs

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 101273
   Summary: d: missed RVO optimization with non-pod structs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

It looks like fixing PR d/100882 introduced a small regression:
---
struct S
{
int x;
S *impl;
this(int x)
{
this.x = x;
this.impl = &this;
}
~this() { }
}

S makeS()
{
return S(42);
}

S nrvo()
{
S ret = S(2);
return ret; 
}

S rvo()
{
return makeS(); 
}

void main()
{
auto a1 = nrvo();
assert(&a1 is a1.impl);
auto b1 = rvo();
assert(&b1 is b1.impl);
return;
}

[Bug tree-optimization/101272] New: [12 Regression] error: ‘nonnull’ argument ‘message’ compared to NULL [-Werror=nonnull-compare] since

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

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

Bug ID: 101272
   Summary: [12 Regression] error: ‘nonnull’ argument ‘message’
compared to NULL [-Werror=nonnull-compare] since
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Seen in gdb package, the error is likely fine, but I'm curious why is it
visible since the mentioned revision?

$ cat gdb.ii
void internal_error(char);
struct compiled_regex {
  compiled_regex(const char *) __attribute__((__nonnull__));
};
compiled_regex::compiled_regex(const char *message) {
  (message != __null) ? 0 : (internal_error(0), 0);
}

$ g++ gdb.ii -c -Werror=nonnull-compare
gdb.ii: In constructor ‘compiled_regex::compiled_regex(const char*)’:
gdb.ii:6:23: error: ‘nonnull’ argument ‘message’ compared to NULL
[-Werror=nonnull-compare]
6 |   (message != __null) ? 0 : (internal_error(0), 0);
  |   ^~~~
cc1plus: some warnings being treated as errors

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

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

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

commit r12-1932-ga075350ee7bffa6c90d9d233de78515f498b5149
Author: Richard Biener 
Date:   Wed Jun 30 12:35:45 2021 +0200

tree-optimization/101267 - fix SLP vect with masked operations

This fixes the missed handling of external/constant mask SLP
operations, for the testcase in particular masked loads.  The
patch adjusts the vect_check_scalar_mask API to reflect the
required vect_is_simple_use SLP compatible API plus adjusts
for the special handling of masked loads in SLP discovery.

The issue is likely latent.

2021-06-30  Richard Biener  

PR tree-optimization/101267
* tree-vect-stmts.c (vect_check_scalar_mask): Adjust
API and use SLP compatible interface of vect_is_simple_use.
Reject not vectorized SLP defs for callers that do not support
that.
(vect_check_store_rhs): Handle masked stores and pass down
the appropriate operator index.
(vectorizable_call): Adjust.
(vectorizable_store): Likewise.
(vectorizable_load): Likewise.  Handle SLP pecularity of
masked loads.
(vect_is_simple_use): Remove special-casing of masked stores.

* gfortran.dg/pr101267.f90: New testcase.

[Bug ada/100488] [12 Regression] trunk 20210508 fails to build ada on x86_64-linux-gnux32

[doko at debian dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Klose  ---
just retried with trunk 20210630, the issue is still there.

[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-1931-ge61ffa201403e3814a43b176883e176716b1492f
Author: David Malcolm 
Date:   Wed Jun 30 09:39:04 2021 -0400

analyzer: eliminate enum binding_key [PR95006]

I rewrote the way the analyzer's region_model tracks the state of memory
in GCC 11 (in 808f4dfeb3a95f50f15e71148e5c1067f90a126d), which
introduced a store with a binding_map class, mapping binding keys to
symbolic values.

The GCC 11 implementation of binding keys has an enum binding_kind,
which can be "default" vs "direct"; the idea being that direct
bindings take priority over default bindings, where the latter could
be used to represent e.g. a zero-fill of a buffer, and the former
expresses those subregions that have since been touched.

This doesn't work well: it doesn't express the idea of filling
different subregions with different values, or a memset that only
touches part of a buffer, leading to numerous XFAILs in the memset
test cases (and elsewhere).

As preparatory work towards tracking uninitialized values, this patch
eliminates the enum binding_kind, so that all bindings have
equal weight; the order in which they happen is all that matters.
If a write happens which partially overwrites an existing binding,
the new code can partially overwrite a binding, potentially punching a
hole so that an existing binding is split into two parts.

The patch adds some new classes:
- a new "bits_within_svalue" symbolic value to support extracting
  parts of an existing value when its binding is partially clobbered
- a new "repeated_svalue" symbolic value to better express filling
  a region with repeated copies of a symbolic value (e.g. constant
  zero)
- a new "sized_region" region to express accessing a subregion
  with a symbolic size in bytes
and it rewrites e.g. how memset is implemented, so that we can precisely
track which bits in a region have not been touched.

That said, the patch doesn't actually implement "uninitialized" values;
I'm saving that for a followup.

gcc/analyzer/ChangeLog:
PR analyzer/95006
* analyzer.h (class repeated_svalue): New forward decl.
(class bits_within_svalue): New forward decl.
(class sized_region): New forward decl.
(get_field_at_bit_offset): New forward decl.
* engine.cc (exploded_graph::get_or_create_node): Validate the
merged state.
(exploded_graph::maybe_process_run_of_before_supernode_enodes):
Validate the states at each stage.
* program-state.cc (program_state::validate): Validate
m_region_model.
* region-model-impl-calls.cc (region_model::impl_call_memset):
Replace special-case logic for handling constant sizes with
a call to fill_region of a sized_region with the given fill value.
* region-model-manager.cc (maybe_undo_optimize_bit_field_compare):
Drop DK_direct.
(region_model_manager::maybe_fold_sub_svalue):  Fold element-based
subregions of an initial value into initial values of an element.
Fold subvalues of repeated svalues.
(region_model_manager::maybe_fold_repeated_svalue): New.
(region_model_manager::get_or_create_repeated_svalue): New.
(get_bit_range_for_field): New.
(get_byte_range_for_field): New.
(get_field_at_byte_range): New.
(region_model_manager::maybe_fold_bits_within_svalue): New.
(region_model_manager::get_or_create_bits_within): New.
(region_model_manager::get_sized_region): New.
(region_model_manager::log_stats): Update for addition of
m_repeated_values_map, m_bits_within_values_map, and
m_sized_regions.
* region-model.cc (region_model::validate): New.
(region_model::on_assignment): Drop enum binding_kind.
(region_model::get_initial_value_for_global): Likewise.
(region_model::get_rvalue_for_bits): Replace body with call to
get_or_create_bits_within.
(region_model::get_capacity): Handle RK_SIZED.
(region_model::set_value): Drop enum binding_kind.
(region_model::fill_region): New.
(region_model::get_representative_path_var_1): Handle RK_SIZED.
* region-model.h (visitor::visit_repeated_svalue): New.
(visitor::visit_bits_within_svalue): New.
(region_model_manager::get_or_create_repeated_svalue): New decl.
(region_model_manager::get_or_create_bits_within): New decl.
(region_model_manager::get_sized_region): New decl.
(reg

[Bug libstdc++/101271] New: [12 Regression] error: ‘static constexpr decltype ... used before its definition

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

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

Bug ID: 101271
   Summary: [12 Regression] error: ‘static constexpr decltype ...
used before its definition
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51090&action=edit
test-case

It's a recent regression. The test-case comes from blender package:

$ g++ blender.ii -c
In file included from /usr/include/openvdb/tree/LeafBuffer.h:10,
 from /usr/include/openvdb/tree/LeafNode.h:11,
 from /usr/include/openvdb/tree/Tree.h:18,
 from /usr/include/openvdb/Grid.h:12,
 from /usr/include/openvdb/openvdb.h:12,
 from
/home/abuild/rpmbuild/BUILD/blender-2.92.0/extern/mantaflow/preprocessed/fileio/iovdb.cpp:31:
/usr/include/tbb/atomic.h:21:141: note: ‘#pragma message: TBB Warning:
tbb/atomic.h is deprecated. For details, please see Deprecated Features
appendix in the TBB reference manual.’
In file included from /usr/include/openvdb/tools/PointPartitioner.h:26,
 from /usr/include/openvdb/tools/PointIndexGrid.h:19,
 from /usr/include/openvdb/points/PointConversion.h:15,
 from
/home/abuild/rpmbuild/BUILD/blender-2.92.0/extern/mantaflow/preprocessed/fileio/iovdb.cpp:32:
/usr/include/tbb/task_scheduler_init.h:21:154: note: ‘#pragma message: TBB
Warning: tbb/task_scheduler_init.h is deprecated. For details, please see
Deprecated Features appendix in the TBB reference manual.’
In file included from /usr/include/c++/12/memory:76,
 from /usr/include/tbb/tbb_stddef.h:452,
 from /usr/include/tbb/blocked_range3d.h:20,
 from
/home/abuild/rpmbuild/BUILD/blender-2.92.0/extern/mantaflow/preprocessed/kernel.h:23,
 from
/home/abuild/rpmbuild/BUILD/blender-2.92.0/extern/mantaflow/preprocessed/grid.h:26,
 from
/home/abuild/rpmbuild/BUILD/blender-2.92.0/extern/mantaflow/preprocessed/fileio/iovdb.cpp:25:
/usr/include/c++/12/bits/unique_ptr.h: In instantiation of ‘typename
std::add_lvalue_reference<_Tp>::type std::unique_ptr<_Tp [],
_Dp>::operator[](std::size_t) const [with _Tp = unsigned int; _Dp =
std::default_delete; typename
std::add_lvalue_reference<_Tp>::type = unsigned int&; std::size_t = long
unsigned int]’:
/usr/include/openvdb/tools/PointIndexGrid.h:447:20:   required from here
/usr/include/c++/12/bits/unique_ptr.h:672:55: error: ‘static constexpr decltype
((sizeof (_Elt) != 0)) std::unique_ptr<_Tp [],
_Dp>::_S_nothrow_deref(std::size_t) [with _Ptr = unsigned int*; _Elt = unsigned
int; _Tp = unsigned int; _Dp = std::default_delete; decltype
((sizeof (_Elt) != 0)) = bool; std::size_t = long unsigned int]’ used before
its definition

[Bug tree-optimization/101260] [10/11 Regression] Backport 27381e78925 to GCC 11

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Yes, I'm already looking into this.

[Bug ipa/101270] error: inlining failed in call to ‘always_inline’ ‘open.localalias’: function not inlinable with -fPIC -fno-semantic-interposition

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Last reconfirmed||2021-06-30
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
mine.

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Richard Earnshaw  ---
Moved to binutils bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=28031

[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced

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

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-06-30
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
mine.

[Bug ipa/101270] New: error: inlining failed in call to ‘always_inline’ ‘open.localalias’: function not inlinable with -fPIC -fno-semantic-interposition

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

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

Bug ID: 101270
   Summary: error: inlining failed in call to ‘always_inline’
‘open.localalias’: function not inlinable with -fPIC
-fno-semantic-interposition
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The following code snipped is rejected:

$ cat large_mounts.i
typedef struct {
} __fpos_t;
extern __inline __attribute__((__always_inline__))
__attribute__((__gnu_inline__)) __attribute__((__artificial__)) int
open(const char *__path, int __oflag, ...) { return 0; }
int open(const char *path, int flags, ...) {
  int mounts_fd;
  mounts_fd = open("/proc/mounts", 00);
  return mounts_fd;
}

$ gcc large_mounts.i -c -O2 -fPIC -fno-semantic-interposition 
large_mounts.i: In function ‘open’:
large_mounts.i:6:5: error: inlining failed in call to ‘always_inline’
‘open.localalias’: function not inlinable
6 | int open(const char *path, int flags, ...) {
  | ^~~~
large_mounts.i:8:15: note: called from here
8 |   mounts_fd = open("/proc/mounts", 00);
  |   ^~~~

while clang accepts it:
$ clang large_mounts.i -c -O2 -fPIC -fno-semantic-interposition

Moreover, we reject also with:

gcc large_mounts.i -c -O2 -fPIC
large_mounts.i: In function ‘open’:
large_mounts.i:6:5: error: inlining failed in call to ‘always_inline’
‘open.localalias’: redefined extern inline functions are not considered for
inlining
6 | int open(const char *path, int flags, ...) {
  | ^~~~
large_mounts.i:8:15: note: called from here
8 |   mounts_fd = open("/proc/mounts", 00);
  |   ^~~~

this one is rejected since r8-2126-g325fe81618c822b8.

[Bug testsuite/101269] New: new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852

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

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

Bug ID: 101269
   Summary: new test case gcc.dg/debug/btf/btf-datasec-1.c fails
with its introduction in r12-1852
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:c1f76af469388d3df815c82de566387da5ae000f, r12-1852

FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times 0[\t
]+[^\n]*bts_offset 7
FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times 0xf03[\t
]+[^\n]*btt_info 2
FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times ascii ".data.0"[\t
]+[^\n]*btf_aux_string 1
FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times ascii
".rodata.0"[\t ]+[^\n]*btf_aux_string 1

It looks like the failing ones are compiled for 32 bits.  The 64 bits ones work
fine.

commit c1f76af469388d3df815c82de566387da5ae000f
Author: Indu Bhagat 
Date:   Thu May 20 11:19:04 2021 -0700

CTF/BTF testsuites

This commit adds a new testsuite for the CTF debug format.

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

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

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

--- Comment #2 from Richard Earnshaw  ---
Was broken by the binutils commit f439988037a589de3798f44e7268301adaec21a9

[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
Not a GCC bug.

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

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #8 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #6)
> While it would be nice if the libstdc++ API docs were 100% complete and
> described every piece of the library, that is never going to happen. If you
> are trying to use those docs to learn C++ you should stop, and look
> elsewhere.

I am trying to read somebody else’s code and that developer is using things
that I would never use and I think should never make it to the standard in the
first place.  The ugliness of these things compares only with sbumpc.  So I
wanted to check whether this is a standard thing he used---and the reply from
the API doc was negative.  Thank you for making this problem a bit less
painful.

[Bug libstdc++/101268] New: Refer manual readers to cppreference.com for API details

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

Bug ID: 101268
   Summary: Refer manual readers to cppreference.com for API
details
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giecrilj at stegny dot 2a.pl
  Target Milestone: ---

Since we have given up on documenting all standard library features we have
implemented (I mean patches are not welcome), we should add a reference to
cppreference.com to the product manual.

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

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #7 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Christopher Yeleighton from comment #3)
> > It should at least be present on the API page.  The standard is not for
> > developers.
> 
> cppreference.com is not the standard, it's a reference for developers.
> 
> (In reply to Christopher Yeleighton from comment #4)
> > What is self-explanatory in is_integral_v?
> 
> If you don't know what the xxx_v variables in  do, you should
> get a good (modern) tutorial on C++.

"Self-explanatory" implies that no tutorial is needed.

[Bug target/101220] arm: iwmmxt2: generating bad assembler ?

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

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

--- Comment #1 from Richard Earnshaw  ---
The same problem exists in gcc-10 and gcc-11 (gcc-9 does not generate the
wldrd/wstrd insructions), but I think this is a gas bug rather than a bug in
gcc.  The output from the gcc-12 compiler does assemble without problems with
binutils-2.32, but fails with 2.36 (I haven't built intervening versions to
narrow it down yet).

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

--- Comment #6 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> (In reply to Richard Biener from comment #4)
> > So we're having
> > 
> > (gdb) p debug (slp_node)
> > t.f90:1:21: note: node 0x39fbbc0 (max_nunits=2, refcnt=1)
> > t.f90:1:21: note: op template: _144 = .MASK_LOAD (_143, 32B, _142);
> > t.f90:1:21: note:   stmt 0 _144 = .MASK_LOAD (_143, 32B, _142);
> > t.f90:1:21: note:   stmt 1 _146 = .MASK_LOAD (_145, 32B, _142);
> > t.f90:1:21: note:   children 0x39fbc48
> > 
> > where vectorizable_load invokes
> > 
> > 8500  if (!vect_check_scalar_mask (vinfo, stmt_info, mask,
> > &mask_dt,
> > 8501   &mask_vectype))
> > 8502return false;
> > 
> > but the SLP child is
> > 
> > (gdb) p debug ((slp_tree)0x39fbc48)
> > t.f90:1:21: note: node (external) 0x39fbc48 (max_nunits=1, refcnt=1)
> > t.f90:1:21: note:   { _142, _142 }
> > 
> > so it won't have a vector type set.  In fact vect_check_scalar_mask doesn't
> > seem to be prepared for SLP at all - we're lucky it "works" but then most
> > definitely it won't for externals.  You'll note that the SLP variant for
> > vect_is_simple_use won't be applicable here since we only have SLP
> > representations for the mask operand which isn't even the first one.
> Seems like we should have a way of representing this kind of situation
> though.  It doesn't seem unreasonable to have some operands (and especially
> call arguments) that don't need to be vectorised.
> 
> Maybe a “fix” for now might be to pass separate SLP and non-SLP operand
> numbers to vect_is_simple_use.

Yes, I'm doing that for the single localized place where it should matter now,
see the patch posted.  There's always the possibility to fill SLP operands
with NULL (as we do for PHIs in some cases).  But then we do likely expect
the "missing" operands to be code-generated.

[Bug debug/101266] ICE with -g: in loc_list_from_tree_1, at dwarf2out.c:19421

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

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

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

Untested fix.

[Bug debug/101266] ICE with -g: in loc_list_from_tree_1, at dwarf2out.c:19421

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
  Component|c   |debug
 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
As dwarf2out.c is called on pre-gimplification GENERIC in that case, it should
handle GENERIC trees.

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #4)
> So we're having
> 
> (gdb) p debug (slp_node)
> t.f90:1:21: note: node 0x39fbbc0 (max_nunits=2, refcnt=1)
> t.f90:1:21: note: op template: _144 = .MASK_LOAD (_143, 32B, _142);
> t.f90:1:21: note:   stmt 0 _144 = .MASK_LOAD (_143, 32B, _142);
> t.f90:1:21: note:   stmt 1 _146 = .MASK_LOAD (_145, 32B, _142);
> t.f90:1:21: note:   children 0x39fbc48
> 
> where vectorizable_load invokes
> 
> 8500  if (!vect_check_scalar_mask (vinfo, stmt_info, mask,
> &mask_dt,
> 8501   &mask_vectype))
> 8502return false;
> 
> but the SLP child is
> 
> (gdb) p debug ((slp_tree)0x39fbc48)
> t.f90:1:21: note: node (external) 0x39fbc48 (max_nunits=1, refcnt=1)
> t.f90:1:21: note:   { _142, _142 }
> 
> so it won't have a vector type set.  In fact vect_check_scalar_mask doesn't
> seem to be prepared for SLP at all - we're lucky it "works" but then most
> definitely it won't for externals.  You'll note that the SLP variant for
> vect_is_simple_use won't be applicable here since we only have SLP
> representations for the mask operand which isn't even the first one.
Seems like we should have a way of representing this kind of situation
though.  It doesn't seem unreasonable to have some operands (and especially
call arguments) that don't need to be vectorised.

Maybe a “fix” for now might be to pass separate SLP and non-SLP operand
numbers to vect_is_simple_use.

[Bug middle-end/94366] OpenMP Parallel Reduction with "&&" operator does not compute correct result

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-06-30

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

Untested fix.

[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|11.2|---

--- Comment #8 from Jonathan Wakely  ---
Nope.

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

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

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

--- Comment #6 from Jonathan Wakely  ---
While it would be nice if the libstdc++ API docs were 100% complete and
described every piece of the library, that is never going to happen. If you are
trying to use those docs to learn C++ you should stop, and look elsewhere.

The API of libstdc++ is what is described in the standard, and cppreference.com
does a better job of documenting it than we ever will.

So unless we suddenly run out of new features to implement and bugs to fix, I
don't think anybody is going to add documentation for everything like that.

I have regenerated the latest-doxygen docs to include C++17 features:
https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html
No is_integral_v is listed (with no description) at:
https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01625.html#a824c5eb1a7e8aafa382dc9af3329a9e8

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Christopher Yeleighton from comment #3)
> It should at least be present on the API page.  The standard is not for
> developers.

cppreference.com is not the standard, it's a reference for developers.

(In reply to Christopher Yeleighton from comment #4)
> What is self-explanatory in is_integral_v?

If you don't know what the xxx_v variables in  do, you should get
a good (modern) tutorial on C++.

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
So we're having

(gdb) p debug (slp_node)
t.f90:1:21: note: node 0x39fbbc0 (max_nunits=2, refcnt=1)
t.f90:1:21: note: op template: _144 = .MASK_LOAD (_143, 32B, _142);
t.f90:1:21: note:   stmt 0 _144 = .MASK_LOAD (_143, 32B, _142);
t.f90:1:21: note:   stmt 1 _146 = .MASK_LOAD (_145, 32B, _142);
t.f90:1:21: note:   children 0x39fbc48

where vectorizable_load invokes

8500  if (!vect_check_scalar_mask (vinfo, stmt_info, mask,
&mask_dt,
8501   &mask_vectype))
8502return false;

but the SLP child is

(gdb) p debug ((slp_tree)0x39fbc48)
t.f90:1:21: note: node (external) 0x39fbc48 (max_nunits=1, refcnt=1)
t.f90:1:21: note:   { _142, _142 }

so it won't have a vector type set.  In fact vect_check_scalar_mask doesn't
seem to be prepared for SLP at all - we're lucky it "works" but then most
definitely it won't for externals.  You'll note that the SLP variant for
vect_is_simple_use won't be applicable here since we only have SLP
representations for the mask operand which isn't even the first one.

The SLP "support" for masked loads was added by Alejandro Martinez it seems,
CCing other ARM folks.

A possible fix is to simply give up for external SLP defs above, the internal
def case was probably working by chance.  I'm testing such a fix.

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

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

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

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

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

commit r12-1927-g0a9d038ec10aa0d109ca965cc435934bfea92d14
Author: prathamesh.kulkarni 
Date:   Wed Jun 30 15:12:06 2021 +0530

arm/66791: Gate comparison in vca intrinsics on __FAST_MATH__.

gcc/ChangeLog:

PR target/66791
* config/arm/arm_neon.h: Move vabs intrinsics before vcage_f32.
(vcage_f32): Gate comparison on __FAST_MATH__.
(vcageq_f32): Likewise.
(vcale_f32): Likewise.
(vcaleq_f32): Likewise.
(vcagt_f32): Likewise.
(vcagtq_f32): Likewise.
(vcalt_f32): Likewise.
(vcaltq_f32): Likewise.
(vcage_f16): Likewise.
(vcageq_f16): Likewise.
(vcale_f16): Likewise.
(vcaleq_f16): Likewise.
(vcagt_f16): Likewise.
(vcagtq_f16): Likewise.
(vcalt_f16): Likewise.
(vcaltq_f16): Likewise.

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

--- Comment #3 from Martin Liška  ---
Started with r12-1551-g3dfa4fe9f1a089b2.

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

--- Comment #2 from Richard Biener  ---
   SUBROUTINE sfddagd( regime, znt,ite ,jte )
   REAL, DIMENSION( ime, IN) :: regime, znt
   REAL, DIMENSION( ite, jte) :: wndcor_u 
   LOGICAL wrf_dm_on_monitor
   IF( int4 == 1 ) THEN
 DO j=jts,jtf
  DO i=itsu,itf
   reg =   regime(i,  j) 
   IF( reg > 10.0 ) THEN
 znt0 = znt(i-1,  j) + znt(i,  j) 
 IF( znt0 <= 0.2) THEN
   wndcor_u(i,j) = 0.2
 ENDIF
   ENDIF
  ENDDO
 ENDDO
 IF ( wrf_dm_on_monitor()) THEN
 ENDIF
   ENDIF
   END

[Bug ada/101094] [11/12 regression] 'Enum_Rep returns a unsigned value for the negative representation in gcc-11

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug tree-optimization/101267] [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I'm reducing a testcase right now.

[Bug ada/101094] [11/12 regression] 'Enum_Rep returns a unsigned value for the negative representation in gcc-11

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
> In gcc-10 or older, it always returns just a representation value.
> Is this intentional changed or not?

No, it's an oversight.

[Bug tree-optimization/101267] New: [12 Regression] ICE in vect_is_simple_use when building 521.wrf_r with -Ofast -march=znver2

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

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

Bug ID: 101267
   Summary: [12 Regression] ICE in vect_is_simple_use when
building 521.wrf_r with -Ofast -march=znver2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gfortran -c -o module_fdda_psufddagd.fppized.o -I. -I./netcdf/include -I./inc
-Ofast -march=znver2 -fdump-statistics-stats -std=legacy -fconvert=big-endian
-fno-openmp -g0 module_fdda_psufddagd.fppized.f90
during GIMPLE pass: slp
module_fdda_psufddagd.fppized.f90:553:21:

  553 |SUBROUTINE sfddagd(itimestep,dx,dt,xtime,  &
  | ^
internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:11422
0x75f7e4 vect_is_simple_use(tree_node*, vec_info*, vect_def_type*, tree_node**,
_stmt_vec_info**, gimple**)
/home/rguenther/src/trunk/gcc/tree-vect-stmts.c:11422
0x110c3a7 vect_check_scalar_mask
/home/rguenther/src/trunk/gcc/tree-vect-stmts.c:2470
0x110ed97 vectorizable_load
/home/rguenther/src/trunk/gcc/tree-vect-stmts.c:8500
0x111d53a vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/rguenther/src/trunk/gcc/tree-vect-stmts.c:10836
0x115a60b vect_slp_analyze_node_operations_1
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:4430
0x115a60b vect_slp_analyze_node_operations
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:4589
0x115c818 vect_slp_analyze_operations(vec_info*)
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:4824
0x1160470 vect_slp_analyze_bb_1
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:5702
0x1160470 vect_slp_region
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:5748
0x11619b8 vect_slp_bbs
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:5898
0x1161db4 vect_slp_function(function*)
/home/rguenther/src/trunk/gcc/tree-vect-slp.c:5984
0x1167e02 execute
/home/rguenther/src/trunk/gcc/tree-vectorizer.c:1445
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/101264] [12 Regression] ICE in vect_optimize_slp, at tree-vect-slp.c:3880

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/101264] [12 Regression] ICE in vect_optimize_slp, at tree-vect-slp.c:3880

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

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

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

https://gcc.gnu.org/g:39da8a7ba9a3a643e6318a5534d5d7c85a3bedfa

commit r12-1926-g39da8a7ba9a3a643e6318a5534d5d7c85a3bedfa
Author: Richard Biener 
Date:   Wed Jun 30 09:48:37 2021 +0200

tree-optimization/101264 - rework SLP "any" permute forward prop

This integrates the forward propagation of SLP "any" permutes into
the main propagation stage as a separate single-pass propagation
didn't work out.

2021-06-30  Richard Biener  

PR tree-optimization/101264
* tree-vect-slp.c (vect_optimize_slp): Propagate the
computed perm_in to all "any" permute successors
we cannot de-duplicate immediately.

* gfortran.dg/pr101264.f90: New testcase.

[Bug target/101241] Internal compiler error from MathFunctions.h in the eigen library

[r.langer at itv dot rwth-aachen.de via Gcc-bugs]

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

--- Comment #10 from Raymond Langer  ---
I've reported the bug here:

https://github.com/clearlinux/distribution/issues/2393

The problem seems to be a Clear Linux patch.

Thanks for your support!

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Martin Liška from comment #7)
> Fixed on master with r11-1245-g3dcea658c9e2ac84.

OK, so that's target specific then, thus aarch64 could still be broken.
assemble_start_function is the one invoking the target hook (and eventually
its default implementation) that emits the patchable area.

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #7 from Martin Liška  ---
Fixed on master with r11-1245-g3dcea658c9e2ac84.

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Martin Liška from comment #5)
> (In reply to Richard Biener from comment #4)
> > Martin, can you bisect what fixed it?
> 
> Sure. Please help me how to verify what is a correct output? Isn't that
> related to DWARF 5 change done in GCC 11?

It's consistent with -gdwarf-2 -gstrict-dwarf as well, so no.

A broken executable will output a short disassembly from gdb:


> gcc-10 t.c -g -O -fpatchable-function-entry=16
> gdb -ex 'disassemble foo' -batch ./a.out | wc -l
3

actual output is

Dump of assembler code for function foo:
   0x004004a6 <+0>: ret
End of assembler dump.

where a correctly working one is

> gdb -ex 'disassemble foo' -batch ./a.out | wc -l
19

with output

Dump of assembler code for function foo:
   0x00400476 <+0>: nop
   0x00400477 <+1>: nop
   0x00400478 <+2>: nop
   0x00400479 <+3>: nop
   0x0040047a <+4>: nop
   0x0040047b <+5>: nop
   0x0040047c <+6>: nop
   0x0040047d <+7>: nop
   0x0040047e <+8>: nop
   0x0040047f <+9>: nop
   0x00400480 <+10>:nop
   0x00400481 <+11>:nop
   0x00400482 <+12>:nop
   0x00400483 <+13>:nop
   0x00400484 <+14>:nop
   0x00400485 <+15>:nop
   0x00400486 <+16>:ret
End of assembler dump.

[Bug tree-optimization/101260] [10/11 Regression] Backport 27381e78925 to GCC 11

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.1, 11.1.1
   Target Milestone|--- |10.4
Summary|Backport 27381e78925 to GCC |[10/11 Regression] Backport
   |11  |27381e78925 to GCC 11
  Known to work||12.0, 9.4.1

--- Comment #4 from Richard Biener  ---
OK, can you try to pin-point the wrong transform?  If GCC 10 is affected then
my store-motion comment can be ignored.

[Bug c/94366] OpenMP Parallel Reduction with "&&" operator does not compute correct result

[pal0009 at uah dot edu via Gcc-bugs]

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

Phillip Lane  changed:

   What|Removed |Added

 CC||pal0009 at uah dot edu

--- Comment #1 from Phillip Lane  ---
I have reproduced this bug using gcc/9.3.0 on Ubuntu 20.04. A preliminary look
shows that it appears to be in the backend and isn't an issue with the parser.
I'll look at this more closely in the following week to see if I can't resolve
this.

[Bug tree-optimization/101260] Backport 27381e78925 to GCC 11

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
The problem shows up for option -O1 (options -O{0,2,3} are fine) and GCC 10 and
11 (mainline and GCC 9 are fine).

[Bug c/101266] ICE with -g: in loc_list_from_tree_1, at dwarf2out.c:19421

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Started with r8-6733-gd74641bdd752306a.

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #5 from Martin Liška  ---
(In reply to Richard Biener from comment #4)
> Martin, can you bisect what fixed it?

Sure. Please help me how to verify what is a correct output? Isn't that related
to DWARF 5 change done in GCC 11?