[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

--- Comment #15 from Richard Biener  ---
Created attachment 58023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58023&action=edit
patch

I'm testing this.

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 58022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58022&action=edit
Patch which I tested

I still need to add the testcases and finish up the commit message and
changelogs. I will do that tomorrow. Posting this here tonight so I don't lose
the patch.

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> here is a testcase for the fcsel usage for integer cmov:

A slightly better example where there is no use of inline-asm or forcing to
specific registers:
```
#define vector16 __attribute__((vector_size(16)))
void
foo (int a, int *b, vector16 int c, vector16 int d)
{
  int t = a ? c[0] : d[0];
  *b = t;
}

```
We should be able to produce:
```
foo:
cmp w0, 0
fcsel   s1, s1, s0, eq
str s1, [x1]
ret
```

And here is a decent one for float modes (-O2 -fno-ssa-phiopt is needed though,
otherwise the tree level does the VCE after the cmov):
```
#define vector8 __attribute__((vector_size(8)))
void
foo (int a, double *b, long long c, long long d)
{
  double ct;
  double dt;
  __builtin_memcpy(&ct, &c, sizeof(long long));
  __builtin_memcpy(&dt, &d, sizeof(long long));
  double t = a ? ct : dt;
  *b = t;
}
```

[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
(In reply to Jan Hubicka from comment #13)
> -fdump-tree-all-all  changing generated code is also bad.  We probably
> should avoid dumping loop bounds then they are not recorded. I added dumping
> of loop bounds and this may be unexpected side effect. WIll take a look.

I think consistently estimating the number of iterations here is correct.

I don't think the bug should be P1, it's latent and exposed only with an
artificial testcase.  We've likely had similar bugs before where we end up
associating estimates with a wrong loop after some CFG transform.

In this case we end up with the i-loop header being associated with a former
irreducible region.  The fix in the past was to release estimates/niters
on problematic transforms.  Let me have a look.

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

--- Comment #7 from Andrew Pinski  ---
here is a testcase for the fcsel usage for integer cmov:

```
void
foo (int a, int *b)
{
  int t = a ? 11 : 22;
  register int tt __asm__("s0");
  tt = t;
  asm("":"+w"(tt));
  *b = tt;
}

```

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

--- Comment #6 from Andrew Pinski  ---
here is a testcase for the fcsel usage for integer:
```
void
foo (int a, double *b)
{
  double t = a ? 1.0 : 200.0;
  register double tt __asm__("x0");
  tt = t;
  asm("":"+r"(tt));
  *b = tt;
}
```

[Bug tree-optimization/114833] New: --suggest-attribute=returns_nonnull misdiagnoses functions with __attribute__((nonnull))

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 114833
   Summary: --suggest-attribute=returns_nonnull misdiagnoses
functions with __attribute__((nonnull))
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

This is gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0) on Fedora 40 x86-64. Put
this code into the file t.i:

  extern char const *foo () __attribute__ ((returns_nonnull));
  char const *
  foo ()
  {
return "abc";
  }

and compile it with:

  gcc -S -O2 -Wsuggest-attribute=returns_nonnull t.i

The output is:

  t.i: In function ‘foo’:
  t.i:3:3: warning: function might be candidate for attribute ‘returns_nonnull’
[-Wsuggest-attribute=returns_nonnull]
  3 |   foo ()
|   ^~~

This diagnostic is obviously wrong, as foo is already declared with the
suggested attribute.

[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file

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

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

--- Comment #6 from Richard Biener  ---
I have no idea why the values differ but I suspect the copying since we seem to
use the file modification time at some point.  As a workaround I would suggest
to binary-patch one of the file to make the stamp match the other ...

[Bug demangler/114830] c++filt stack overflows in rust demangler

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
There was a GSoC project making the demangler non recursive in 2021, but it
unfortunately failed.  So with a recursive demangler this thing just happens...

[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
With the early break code we now allow multiple blocks in the loop body but
guess this only happens for blocks with exits.  In this case we have a simple
forwarder which seems to confuse the code.  Usually if-conversion gets rid of
those so -fno-tree-loop-if-convert is critical to trigger this.

If we want to fix this on the release branch I think we should reject loops
with this kind of CFG again.  In stage1 we should fix the real issue.

I think the fix is just

diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 8d9b533d50f..43c7881c640 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -1523,7 +1523,7 @@ slpeel_tree_duplicate_loop_to_edge_cfg (class loop *loop,
edge loop_exit,

   exit_dest = exit->dest;
   was_imm_dom = (get_immediate_dominator (CDI_DOMINATORS,
- exit_dest) == loop->header ?
+ exit_dest) == exit->src ?
 true : false);

   /* Also copy the pre-header, this avoids jumping through hoops to

[Bug libstdc++/114817] Wrong codegen for std::copy of "trivially copyable but not trivially assignable" type

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #2 from Jiang An  ---
Bug 106547 seems somehow related.

[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. ICE does not happen with -fno-checking so adding ice-checking.

Also GCC 13.2.0 didn't ICE with -fchecking either.

[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE at -O{2,3} with |[14 Regression] ICE at
   |"-fno-tree-loop-if-convert  |-O{2,3} with
   |-fno-tree-loop-distribute-p |"-fno-tree-loop-if-convert
   |atterns -ftree-vectorize"   |-fno-tree-loop-distribute-p
   |on x86_64-linux-gnu: in |atterns -ftree-vectorize"
   |verify_dominators, at   |on x86_64-linux-gnu: in
   |dominance.cc:1194   |verify_dominators, at
   ||dominance.cc:1194
   Target Milestone|--- |14.0
  Known to fail||14.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-24
  Known to work||13.2.0
   Keywords||ice-checking

--- Comment #1 from Andrew Pinski  ---
Confirmed. ICE does not happen with -fno-checking so adding ice-checking.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Have you tried configuring gcc with --enable-valgrind-annotations and see what
results this gives?

[Bug tree-optimization/114832] New: ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 114832
   Summary: ICE at -O{2,3} with "-fno-tree-loop-if-convert
-fno-tree-loop-distribute-patterns -ftree-vectorize"
on x86_64-linux-gnu: in verify_dominators, at
dominance.cc:1194
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression and does not reproduce with 13.2 and
earlier.

Compiler Explorer: https://godbolt.org/z/1do4bc9W7


[515] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240423 (experimental) (GCC) 
[516] % 
[516] % gcctk -c -O2 -fno-tree-loop-if-convert
-fno-tree-loop-distribute-patterns -ftree-vectorize small.c 
small.c: In function ‘e’:
small.c:2:6: error: dominator of 6 should be 13, not 5
2 | void e() {
  |  ^
during GIMPLE pass: vect
small.c:2:6: internal compiler error: in verify_dominators, at
dominance.cc:1194
0x7a1828 verify_dominators(cdi_direction)
../../gcc-trunk/gcc/dominance.cc:1194
0x145a0d0 checking_verify_dominators(cdi_direction)
../../gcc-trunk/gcc/dominance.h:76
0x145a0d0 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, edge_def*, loop*,
edge_def*, edge_def*, edge_def**, bool, vec*)
../../gcc-trunk/gcc/tree-vect-loop-manip.cc:1961
0x145d46c vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
../../gcc-trunk/gcc/tree-vect-loop-manip.cc:3444
0x144cd58 vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc-trunk/gcc/tree-vect-loop.cc:11910
0x149374e vect_transform_loops
../../gcc-trunk/gcc/tree-vectorizer.cc:1006
0x1493e53 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.cc:1152
0x1493e53 try_vectorize_loop
../../gcc-trunk/gcc/tree-vectorizer.cc:1182
0x149448c execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[517] % 
[517] % cat small.c
int a, b, c, d[3];
void e() {
  int f, g = 0;
  for (; g < 3; g++) {
if (f || a || b && c) {
  int h, *i = &h, **j = &i;
}
d[g] = 0;
  }
}

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

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

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

--- Comment #8 from Jerry DeLisle  ---
Martin or Matt,

Can you test the following variation to see if you get better results.

return st;
}

  retval = NULL;
  if (c <= 0)
retval = find_symbol (st->left, name, module, generic);

  if (c > 0 && retval == NULL)
retval = find_symbol (st->right, name, module, generic);

  if (c > 0 && retval == NULL)
retval = find_symbol (st->left, name, module, generic);

  if (c <= 0 && retval == NULL)
retval = find_symbol (st->right, name, module, generic);

  return retval;

This does pass regression testing but I do not think it guarantees better
results.  Apparently the value of c does not guarantee a find going left or
right.

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Halalaluyafail3 from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > Oh this is with `-g -std=c23`, godbolt has an implicit -g.
> 
> I was not aware of this, thanks for letting me know. Do you know of any way
> to disable it? Also it does seem to be quite related, so it is probably the
> same bug which caused an ICE here (though the context of that test case
> would require the types be the same so it's a little bit different).

To disable -g, you can add `-g0` .

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Halalaluyafail3  ---
(In reply to Andrew Pinski from comment #4)
> Oh this is with `-g -std=c23`, godbolt has an implicit -g.

I was not aware of this, thanks for letting me know. Do you know of any way to
disable it? Also it does seem to be quite related, so it is probably the same
bug which caused an ICE here (though the context of that test case would
require the types be the same so it's a little bit different).

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

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

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

Jerry DeLisle  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #7 from Jerry DeLisle  ---
With the proposed patch, the following test case fails.


! { dg-do compile }
! { dg-options "-fsecond-underscore" }
! PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

module m2345678901234567890123456789012345678901234567890123456789_123
  type t2345678901234567890123456789012345678901234567890123456789_123
   end type
   interface
  module subroutine
s2345678901234567890123456789012345678901234567890123456789_123 &  
   (x2345678901234567890123456789012345678901234567890123456789_123)
  end
   end interface
end
submodule(m2345678901234567890123456789012345678901234567890123456789_123) &
  t2345678901234567890123456789012345678901234567890123456789_123
end

$ gfc -c -fsecond-underscore pr95689.f90 
pr95689.f90:14:74:

   14 |
submodule(m2345678901234567890123456789012345678901234567890123456789_123) &
  |
 1
Error: Name ‘t2345678901234567890123456789012345678901234567890123456789_123’
at (1) is an ambiguous reference to
‘m2345678901234567890123456789012345678901234567890123456789_123.t2345678901234567890123456789012345678901234567890123456789_123’
from current program unit

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||114014

--- Comment #5 from Andrew Pinski  ---
Which I am almost positive this is a dup of bug 114014 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114014
[Bug 114014] ICE: 'verify_type' failed: 'TYPE_CANONICAL' is not compatible with
-g on gcc.dg/gnu23-tag-1.c

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

[luigighiron at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Halalaluyafail3  ---
Just tested on godbolt again and it cause an ICE, so perhaps something was
changed to cause an ICE again. Also upon thinking about the implications of
these types being compatible they probably shouldn't be compatible and it's
either a defect in the standard or I missed something that would make these
types incompatible.

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Halalaluyafail3 from comment #3)
> Just tested on godbolt again 

Oh this is with `-g -std=c23`, godbolt has an implicit -g.

Anyways here is the ICE:
: In function 'main':
:11:1: error: 'TYPE_CANONICAL' is not compatible
   11 | }
  | ^

[Bug c/114831] New: typeof doesn't evaluate expression when it has variably modified type in some cases

[mforney at mforney dot org via Gcc-bugs]

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

Bug ID: 114831
   Summary: typeof doesn't evaluate expression when it has
variably modified type in some cases
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mforney at mforney dot org
  Target Milestone: ---

C23 introduced typeof, and 6.7.2.5p4 says

> If the type of the operand is a variably modified type, the operand
> is evaluated; otherwise, the operand is not evaluated.

However, gcc doesn't evaluate the operand when it has variably modified type in
some cases.

Consider the following program:

#include 
int n = 1;
int main(void) {
int a[n], (*p)[n] = 0;
typeof(puts("&a is variably-modified"), &a) p1;
typeof(puts("p is variably-modified"), p) p2;
typeof(puts("p1 is variably-modified"), p1) p3;
typeof(puts("p2 is variably-modified"), p2) p4;
}

All four of the typeof operands have the same type, int (*)[n]. But when I run
this program it prints just:

p is variably-modified
p2 is variably-modified

[Bug demangler/114830] c++filt stack overflows in rust demangler

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Alan Modra  ---
Created attachment 58021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58021&action=edit
c++filt crash binaries

[Bug demangler/114830] c++filt stack overflows in rust demangler

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Alan Modra  ---
Created attachment 58020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58020&action=edit
asan report summary

[Bug demangler/114830] New: c++filt stack overflows in rust demangler

[amodra at gmail dot com via Gcc-bugs]

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

Bug ID: 114830
   Summary: c++filt stack overflows in rust demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

>From zhoug...@mail.zgclab.edu.cn and wan...@mail.zgclab.edu.cn:

Hi, we found several crashes in c++filt(Binutils 2.42), which is the latest
version.

In detail, it contains 12 stack-buffer-overflow triggering methods.


To assist in diagnosing and resolving these issues, we have attached the POC
files along with the gdb/asan logs.


Environment:

Linux 4f6b99b5cf37 6.2.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri
Oct  6 10:23:26 UTC 2 x86_64 x86_64 x86_64 GNU/Linux


Credit by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory.


Thanks for your time and attention to these matters.


Best regards,

Zhou Geng

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

--- Comment #5 from Andrew Pinski  ---
So adding the `r` alternative to *cmov_insn (GPF) works kinda of but then
we seem to have a register allocation issue.

Even this still causes FPREGS from being chosen:
```
void
foo (int a, double *b)
{
  double t = a ? 1.0 : 200.0;
  asm("":"+r"(t));
  *b = t;
}

```

Someone else will need to look into register allocator issue later on.

I did find a testcase where we don't get the fmovs though (which forces to use
x0).
```
void
foo (int a, double *b)
{
  double t = a ? 1.0 : 200.0;
  register double tt __asm__("x0");
  tt = t;
  asm("":"+r"(tt));
  *b = tt;
}

```

With that we now get:
```
cmp w0, 0
mov x0, 149533581377536
mov x2, 4641240890982006784
movkx0, 0x40c3, lsl 48
cselx0, x2, x0, eq
str x0, [x1]
ret
```

So at least I can write up a testcase ...

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
HI Matt, I can try your patch and if all tests clean I will request for it to
be approved and I can push it. We have all been rather busy and short handed.

[Bug target/114829] New: No fcsel produced for f16

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

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

Bug ID: 114829
   Summary: No fcsel produced for f16
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
void
foo (int a, _Float16 b1, _Float16 b2, _Float16 *b)
{
  *b = a ? b1 : b2;
}

```

This should produce:
```
foo:
cmp w0, #0
fcsel   h0, h1, h0, eq
str h0, [x1]
ret
```

Or :
```
foo:
cmp w0, #0
fcsel   s0, s1, s0, eq
str h0, [x1]
ret
```

Depending on if we have fp16 enabled or not.

Right now GCC produces branches instead.

Noticed while working on PR 98477 since *cmov_insn pattern uses GPF
iterator and not GPF_F16.

[Bug c++/113300] GCC rejects valid program involving copy list initialization A a = {} of a class with explicit and non explicit default constructors

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
This is CWG 2856 https://cplusplus.github.io/CWG/issues/2856.html

[Bug c++/84849] [DR1228] Ambiguous resolution of braze initializer list to a class with explicit constructors

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #11 from Marek Polacek  ---
DR1228 was closed as NAD.

[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:628c2221d38715a64f828e3635317293d150e001

commit r14-10099-g628c2221d38715a64f828e3635317293d150e001
Author: Jakub Jelinek 
Date:   Tue Apr 23 23:30:27 2024 +0200

i386: Avoid =&r,r,r andn double-word alternative for ia32 [PR114810]

As discussed in the PR, on ia32 with its 8 GPRs, where 1 is always fixed
and other 2 often are as well having an alternative which needs 3
double-word registers is just too much for RA.
The following patch splits that alternative into two, one with o is used
even on ia32, but one with the 3x r is used just for -m64/-mx32.
Tried to reduce the testcase further, but it wasn't easily possible.

2024-04-23  Jakub Jelinek  

PR target/114810
* config/i386/i386.md (*andn3_doubleword_bmi): Split the
=&r,r,ro
alternative into =&r,r,r enabled only for x64 and =&r,r,o.

* g++.target/i386/pr114810.C: New test.

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[matthew.thompson at nasa dot gov via Gcc-bugs]

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

Matt Thompson  changed:

   What|Removed |Added

 CC||matthew.thompson at nasa dot 
gov

--- Comment #5 from Matt Thompson  ---
I just wanted to come on here and say this is still an issue in GCC 13.2 (on
macOS). I did a profile of my code today and saw that this 56-line file of just
uses:

https://github.com/GEOS-ESM/MAPL/blob/main/base/Base.F90

is our second longest file to compile, see:

https://github.com/GEOS-ESM/MAPL/wiki/Profiling-MAPL-Builds#checking-the-build-times-on-cli

taking longer than a 5600 line (!) file of actual exciting Fortran:

https://github.com/GEOS-ESM/MAPL/blob/main/gridcomps/History/MAPL_HistoryGridComp.F90

Is there anyway I can help move this bug to "CONFIRMED"?

[Bug rtl-optimization/114828] [14 Regression] ICE on valid code at -O1 with "-ftree-pre -fselective-scheduling -fsel-sched-pipelining -fschedule-insns" on x86_64-linux-gnu: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #2 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #1)
> This is caused by r14-4089.

Nope, just exposed ...

[Bug rtl-optimization/114828] [14 Regression] ICE on valid code at -O1 with "-ftree-pre -fselective-scheduling -fsel-sched-pipelining -fschedule-insns" on x86_64-linux-gnu: Segmentation fault

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Version|unknown |14.0
 Status|UNCONFIRMED |NEW
Summary|ICE on valid code at -O1|[14 Regression] ICE on
   |with "-ftree-pre|valid code at -O1 with
   |-fselective-scheduling  |"-ftree-pre
   |-fsel-sched-pipelining  |-fselective-scheduling
   |-fschedule-insns" on|-fsel-sched-pipelining
   |x86_64-linux-gnu:   |-fschedule-insns" on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault
 CC||rguenther at suse dot de
   Last reconfirmed||2024-04-23

--- Comment #1 from H.J. Lu  ---
This is caused by r14-4089.

[Bug gcov-profile/114820] Gcov 11.4.0 .gcda:stamp mismatch with notes file

[gejoed at rediffmail dot com via Gcc-bugs]

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

--- Comment #2 from Gejoe  ---
(In reply to Andrew Pinski from comment #1)
> .
> 
> *** This bug has been marked as a duplicate of bug 114751 ***

OK, looks like that bug is not being looked at for further replies. Let me know
if any info is sought for.

Thanks.

[Bug libstdc++/114817] Wrong codegen for std::copy of "trivially copyable but not trivially assignable" type

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Arthur O'Dwyer  ---
Yes, vector reallocation has analogous trouble with types that are "trivial,
but not trivially copy constructible."
https://godbolt.org/z/Psboqf3MP

(libc++ happens to sidestep this pitfall *on Clang 15+,* because libc++ gates
their vector reallocation optimization differently depending on whether
`__has_builtin(__is_trivially_relocatable)`; but libc++ would have the same bug
as libstdc++ when compiled on GCC.)

[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Pushed testcase.  Closing.

[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-10097-g0bf94da59feab2c72a02c91df310a36d33dfd1f7
Author: Harald Anlauf 
Date:   Tue Apr 23 20:21:43 2024 +0200

Fortran: check C_SIZEOF on additions from TS29113/F2018 [PR103496]

gcc/testsuite/ChangeLog:

PR fortran/103496
* gfortran.dg/c_sizeof_8.f90: New test.

[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot

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

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

--- Comment #9 from Patrick Palka  ---
The "invalid conversion in return statement" error should hopefully be fixed
now.

[Bug rtl-optimization/114828] New: ICE on valid code at -O1 with "-ftree-pre -fselective-scheduling -fsel-sched-pipelining -fschedule-insns" on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 114828
   Summary: ICE on valid code at -O1 with "-ftree-pre
-fselective-scheduling -fsel-sched-pipelining
-fschedule-insns" on x86_64-linux-gnu: Segmentation
fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression and does not reproduce with 13.2 and
earlier.

Compiler Explorer: https://godbolt.org/z/9WdTv4qEe

[576] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240423 (experimental) (GCC)
[577] %
[577] % gcctk -c -O1 -ftree-pre -fselective-scheduling -fsel-sched-pipelining
-fschedule-insns small.c
during RTL pass: sched1
small.c: In function ‘f’:
small.c:14:1: internal compiler error: Segmentation fault
   14 | }
  | ^
0x116dc33 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x7f3e0a2c608f ???
   
/build/glibc-e2p3jK/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x110b3d4 init_expr
../../gcc-trunk/gcc/sel-sched-ir.cc:1642
0x110b3d4 copy_expr_onside(_expr*, _expr*)
../../gcc-trunk/gcc/sel-sched-ir.cc:1685
0x111b549 move_op_orig_expr_found
../../gcc-trunk/gcc/sel-sched.cc:5997
0x111f2e0 code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6551
0x11200fe code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6350
0x11200fe code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6616
0x11200fe code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.cc:6350
0x11200fe code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.cc:6616
0x11238e8 move_op
../../gcc-trunk/gcc/sel-sched.cc:6710
0x11238e8 move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5231
0x11238e8 schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5444
0x1125588 fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5586
0x1125588 schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7361
0x1125588 sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7499
0x1126c78 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7541
0x1128a19 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7642
0x1128a19 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7627
0x1129a21 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7728
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[578] %
[578] % cat small.c
char a, b;
int c, d, e;
void f() {
  char g = -1;
 L:
  if (e) {
e = b;
b = c % (d || ~g) && a % c;
c = c || a ^ d;
a = e || a + d + 1;
f();
goto L;
  }
}

[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-10096-g4f9401d1a802325e5dfa2db841945e1a9c59a980
Author: Patrick Palka 
Date:   Tue Apr 23 14:01:22 2024 -0400

c++/modules: deduced return type merging [PR114795]

When merging an imported function template specialization with an
existing one, if the existing one has an undeduced return type and the
imported one's is already deduced, we need to propagate the deduced type
since once we install the imported definition we won't get a chance to
deduce it by normal means.

So this patch makes is_matching_decl propagate the deduced return
type alongside our propagation of the exception specification.
Another option would be to propagate it later when installing the
imported definition from read_function_def, but it seems preferable
to do it sooner rather than later.

PR c++/114795

gcc/cp/ChangeLog:

* module.cc (trees_in::is_matching_decl): Propagate deduced
function return type.

gcc/testsuite/ChangeLog:

* g++.dg/modules/auto-4_a.H: New test.
* g++.dg/modules/auto-4_b.C: New test.

Reviewed-by: Jason Merrill 

[Bug tree-optimization/114826] [13 Regression] Bogus -Warray-bounds warning for 32-byte array with certain march flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-23
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
This was fixed for the trunk by r14-9203 .

[Bug tree-optimization/114826] [13 Regression] Bogus -Warray-bounds warning for 32-byte array with certain march flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Bogus -Warray-bounds|[13 Regression] Bogus
   |warning for 32-byte array   |-Warray-bounds warning for
   |with certain march flags|32-byte array with certain
   ||march flags
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113988
   Target Milestone|--- |13.3

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> Rather store merging I guess.

Or rather how memcpy was done.

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Neil Carlson  ---
I should add that I get the same results with gcc versions going back to at
least gcc 11.

[Bug fortran/114827] New: Valgrind reports errors with class(*) assignment

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

Bug ID: 114827
   Summary: Valgrind reports errors with class(*) assignment
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

I'm trying to pin down a malloc corruption error ("malloc(): corrupted top
size") that happens during finalization of a derived type object. I'm still
working on paring things down to a reportable reproducer, but the traceback
hinted at a possible problem with the assignment of a class(*) variable to
another allocatable class(*) variable when the dynamic type of the rhs is
character. I've turned that bit into the following example which compiles and
runs without error, but when run under valgrind it reports several invalid
writes, which suggests to me that the executable is doing something wrong.

Note that if the assignment to the allocatable class(*) variable is replaced by
a sourced-allocation, the valgrind output is completely clean.

$ cat foo.f90
program main
  call run
contains
  subroutine run
class(*), allocatable :: y
call foo('fubarfubarfubarfubarfubarfu', y)
  end subroutine 
  subroutine foo(a, b)
class(*), intent(in) :: a
class(*), allocatable :: b
b = a
!allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES 
  end subroutine
end program

$ gfortran -g -O0 foo.f90

$ valgrind -s ./a.out
==587107== Memcheck, a memory error detector
==587107== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==587107== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==587107== Command: ./a.out
==587107== 
==587107== Invalid write of size 2
==587107==at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==by 0x4012C2: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== 
==587107== Invalid write of size 1
==587107==at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107== 
==587107== 
==587107== HEAP SUMMARY:
==587107== in use at exit: 0 bytes in 0 blocks
==587107==   total heap usage: 22 allocs, 22 frees, 13,585 bytes allocated
==587107== 
==587107== All heap blocks were freed -- no leaks are possible
==587107== 
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)
==587107== 
==587107== 1 errors in context 1 of 2:
==587107== Invalid write of size 1
==587107==at 0x484F383: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ada is 10 bytes after a block of size 16 in arena
"client"
==587107== 
==587107== 
==587107== 26 errors in context 2 of 2:
==587107== Invalid write of size 2
==587107==at 0x484F353: memmove (vg_replace_strmem.c:1410)
==587107==by 0x401230: __copy_character_1.0 (foo.f90:1)
==587107==by 0x401368: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107==  Address 0x4e57ac0 is 0 bytes inside a block of size 1 alloc'd
==587107==at 0x484280F: malloc (vg_replace_malloc.c:442)
==587107==by 0x4012C2: foo.1 (foo.f90:11)
==587107==by 0x4013E1: run.2 (foo.f90:6)
==587107==by 0x401258: MAIN__ (foo.f90:2)
==587107==by 0x401485: main (foo.f90:2)
==587107== 
==587107== ERROR SUMMARY: 27 errors from 2 contexts (suppressed: 0 from 0)

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #7 from Rainer Orth  ---
A reghunt identified this patch as the culprit:

commit 55f6a7d949abc708d1c6ebc01eb3053f96d1472b
Author: benjamin priour 
Date:   Sun Aug 27 14:36:14 2023 +0200

analyzer: Move gcc.dg/analyzer tests to c-c++-common (1) [PR96395]

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #35 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

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

commit r12-10389-gd6c62e4fb9a6d395599b7c78c831bace4bc7ff8f
Author: Jakub Jelinek 
Date:   Fri Mar 22 09:23:44 2024 +0100

ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

On x86 and avr some address spaces allow 0 pointers (on avr actually
even generic as, but libsanitizer isn't ported to it and
I'm not convinced we should completely kill -fsanitize=null in that
case).
The following patch makes sure those aren't diagnosed for -fsanitize=null,
though they are still sanitized for -fsanitize=alignment.

2024-03-22  Jakub Jelinek  

PR sanitizer/111736
* ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
SANITIZE_NULL instrumentation for non-generic address spaces
for which targetm.addr_space.zero_address_valid (as) is true.

* gcc.dg/ubsan/pr111736.c: New test.

(cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #36 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:48fd1c5791b47717dcd4fa5615bc07cf54e964a7

commit r12-10390-g48fd1c5791b47717dcd4fa5615bc07cf54e964a7
Author: Jakub Jelinek 
Date:   Tue Mar 26 11:06:15 2024 +0100

tsan: Don't instrument non-generic AS accesses [PR111736]

Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so
they
can't handle anything else.

2024-03-26  Jakub Jelinek  

PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.

* gcc.dg/tsan/pr111736.c: New test.

(cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #34 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

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

commit r12-10388-ge89b5ed62a5a06fb8918ffa1616f0f37c8d359c3
Author: Richard Biener 
Date:   Thu Mar 21 08:30:39 2024 +0100

tree-optimization/111736 - avoid address sanitizing of __seg_gs

The following more thoroughly avoids address sanitizing accesses
to non-generic address-spaces.

PR tree-optimization/111736
* asan.cc (instrument_derefs): Do not instrument accesses
to non-generic address-spaces.

* gcc.target/i386/pr111736.c: New testcase.

(cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #33 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:61d1962e7c3c32da6962d9cb20f6fd996501f3f2

commit r12-10387-g61d1962e7c3c32da6962d9cb20f6fd996501f3f2
Author: Richard Biener 
Date:   Tue Dec 5 14:00:43 2023 +0100

sanitizer/111736 - skip ASAN for globals in alternate address-space

PR sanitizer/111736
* asan.cc (asan_protect_global): Do not protect globals
in non-generic address-space.

(cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)

[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-23
 CC||ppalka at gcc dot gnu.org

--- Comment #7 from Patrick Palka  ---
Reduced version of comment #6 testcase:

$ cat 114795_a.H
template
struct A {
  auto f() { return 0; }
};

template
inline void g() {
  A a;
  a.f();
}

$ cat 114795_b.C
template
struct A {
  auto f() { return 0; }
};

A a;

import "114795_a.H";

int main() {
  g();
}

$ g++ -fmodules-ts 114795_*
In module ./114795-2_a.H, imported at 114795_b.C:8:
114795_a.H: In instantiation of ‘void g() [with T = int]’:
114795_b.C:11:9:   required from here
   11 |   g();
  |   ~~^~
114795_a.H:9:6: error: use of ‘auto A::f() [with T = int]’ before deduction
of ‘auto’
9 |   a.f();
  |   ~~~^~
114795_a.H:9:6: error: use of ‘auto A::f() [with T = int]’ before deduction
of ‘auto’


I think I have a fix -- we need to propagate an already-deduced return type
during deduplication.

[Bug tree-optimization/114826] Bogus -Warray-bounds warning for 32-byte array with certain march flags

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

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

--- Comment #2 from Richard Biener  ---
Rather store merging I guess.

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #58015|0   |1
is obsolete||

--- Comment #12 from Jonathan Wakely  ---
Created attachment 58019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58019&action=edit
Make std::pair relocatable and simplify __relocate_a

More comprehensive patch.

With this, I see memcpy in the -fdump-tree-optimized dump.

[Bug tree-optimization/114823] Missed optimization of redundant loops

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-23

--- Comment #1 from Richard Biener  ---
Confirmed.  loop fusion would detect the redundancy.

[Bug tree-optimization/114826] Bogus -Warray-bounds warning for 32-byte array with certain march flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Blocks||56456
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Most likely the warning is due to the auto vectorizer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug c/114826] New: Bogus -Warray-bounds warning for 32-byte array with certain march flags

[adam at adamrosenfield dot com via Gcc-bugs]

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

Bug ID: 114826
   Summary: Bogus -Warray-bounds warning for 32-byte array with
certain march flags
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at adamrosenfield dot com
  Target Milestone: ---

Sample code:

== snip ==
typedef long unsigned int size_t;
extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
   size_t __n) __attribute__ ((__nothrow__ , __leaf__)) __attribute__
((__nonnull__ (1, 2)));
extern int memcmp (const void *__s1, const void *__s2, size_t __n)
 __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__pure__))
__attribute__ ((__nonnull__ (1, 2)));

int foo() {
char dest[32] = {0};
char src[32] = {0};

memcpy(dest, src, 32);

char expected[32] = {0};

return memcmp(expected, dest, 32);
}
== snip ==

Compile as:

gcc -c test.c -Wall -march=haswell -O3

Output:

test.c: In function ‘foo’:
test.c:9:10: warning: array subscript ‘[0]’ is partly
outside array bounds of ‘char[2]’ [-Warray-bounds=]
9 | char src[32] = {0};
  |  ^~~

This warning is clearly bogus, as there is no array of size 256 or size 2 here,
and there's no subscripting going on in this array declaration.

This occurs in GCC 13.2.0 and 13.1.0, but does not occur in GCC 12.x and
earlier.

This only occurs if the array size is exactly 32; other array sizes I've tried
do not trigger this.

This occurs with various different -march flags, including haswell, broadwell,
skylake, knl, knm, and many more of the *lake arches; it does not occur with
ivybridge and earlier.

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

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

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

--- Comment #3 from Jakub Jelinek  ---
Yes, and the reason for that is that while in
subroutine pr114825(b)
  type t
real, allocatable :: m(:)
  end type t
  type(t), allocatable, target :: b(:)
  type(t), pointer :: d
  !$omp parallel private(d)
  d => b(1)
  !$omp end parallel
contains
  subroutine sub
!d => b(1)
  end subroutine sub
end subroutine pr114825

the d in the private clause is the VAR_DECL created by the Fortran FE with
DECL_LANG_SPECIFIC, d in the private clause in the testcase without the d =>
b(1)
commented out is a VAR_DECL created by tree-nested.cc:
#5  0x0123a64b in build_decl (loc=21312, code=VAR_DECL,
name=, type=) at
../../gcc/tree.cc:5379
#6  0x00f4f39e in get_local_debug_decl (info=0x3b871d0, decl=, field=) at
../../gcc/tree-nested.cc:1895
#7  0x00f504c9 in convert_local_omp_clauses (pclauses=0x7fffea134780,
wi=0x7fffd9b0) at ../../gcc/tree-nested.cc:2157

Perhaps get_local_debug_decl should also copy DECL_LANG_SPECIFIC?  Of course,
perhaps it might need e.g. DECL_LANG_FLAG_* too.  If decl in there is just a
VAR_DECL, we might 
as well just copy_node it and tweak afterwards, but if it is e.g. a PARM_DECL,
that wouldn't be possible.

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

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

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

--- Comment #2 from Tobias Burnus  ---
The difference between the failing program and a working program
(pointer-assignment in 'sub' comment out) is:

failing:
  'type' in gfc_omp_clause_default_ctor is '

[Bug objc/101666] Objective-C frontend crashes with `-fobjc-nilcheck`

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #10 from Iain Sandoe  ---
now fixed on open branches (still needed on earlier 'vendor' branches)

[Bug objc/101666] Objective-C frontend crashes with `-fobjc-nilcheck`

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:87431b4a81e9dc5988509399704a7352800c6a77

commit r11-11339-g87431b4a81e9dc5988509399704a7352800c6a77
Author: Iain Sandoe 
Date:   Sat Aug 14 12:27:55 2021 +0100

Objective-C: fix crash with -fobjc-nilcheck

When -fobjc-nilcheck is enabled, messages that result in a struct type
should
yield a zero-initialized struct when sent to nil.  Currently, the frontend
crashes when it encounters this situation.  This patch fixes the crash by
generating the tree for the `{}` initializer.

Signed-off-by: Iain Sandoe 
Co-authored-by: Matt Jacobson  

PR objc/101666

gcc/objc/ChangeLog:

* objc-act.c (objc_build_constructor): Handle empty constructor
lists.
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call):
Handle nil receivers.
(build_v2_build_objc_method_call): Likewise.

gcc/testsuite/ChangeLog:

* obj-c++.dg/pr101666-0.mm: New test.
* obj-c++.dg/pr101666-1.mm: New test.
* obj-c++.dg/pr101666.inc: New.
* objc.dg/pr101666-0.m: New test.
* objc.dg/pr101666-1.m: New test.
* objc.dg/pr101666.inc: New.

(cherry picked from commit d2aa4e0b3b5053df8f5853d9ed29022ff0d3ecf6)

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-23
   Priority|P3  |P2
  Component|libgomp |fortran
 Ever confirmed|0   |1
   Target Milestone|--- |11.5
 CC||burnus at gcc dot gnu.org
Summary|Compiler error using|[11/12/13/14 Regression]
   |gfortran and OpenMP |Compiler error using
   ||gfortran and OpenMP since
   ||r5-1190

--- Comment #1 from Jakub Jelinek  ---
Started with r5-1190-g92d28cbb59cc5a611af41342c5b224fbf779a44d
Reduced testcase (just -fopenmp needed):
subroutine pr114825(b)
  type t
real, allocatable :: m(:)
  end type t
  type(t), allocatable, target :: b(:)
  type(t), pointer :: d
  !$omp parallel private(d)
  d => b(1)
  !$omp end parallel
contains
  subroutine sub
d => b(1)
  end subroutine sub
end subroutine pr114825

[Bug ipa/114790] [11/12/13/14 regression] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #13 from Sam James  ---
Created attachment 58018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58018&action=edit
tracing_copy_imp.cpp.ii-reduced

Attached another attempt...

[Bug ipa/114790] [11/12/13/14 regression] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #12 from Sam James  ---
Created attachment 58017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58017&action=edit
tracing_imp.cpp.ii-reduced

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

Summary|Many C++ analyzer tests |[14 regression] Many C++
   |FAIL|analyzer tests FAIL

--- Comment #6 from Rainer Orth  ---
This actually is a regression from GCC 13: with the as1-sol2.ii testcase,
GCC 13 cc1plus produces the same output as on Linux, while GCC 14 cc1plus
differs as described.

[Bug libgomp/114825] New: Compiler error using gfortran and OpenMP

[marcos.vanella at nist dot gov via Gcc-bugs]

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

Bug ID: 114825
   Summary: Compiler error using gfortran and OpenMP
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcos.vanella at nist dot gov
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58016&action=edit
Fortran Module source to reproduce described error.

Hi we have found a compiler error when compiling a fortran module with
gfortran.
In the following minimal reproducing code snippet, the module DIVG contains
some derived types (BOUNDARY_PROP1_TYPE,WALL_TYPE), a contained subroutine
called DIVERGENCE_PART_1 which also contains a subroutine called
ENTHALPY_ADVECTION.

In DIVERGENCE_PART_1 there is a WALL_LOOP that has an !$OMP PARALLEL construct
with three PRIVATE variables IW (counter), WC (a pointer to an array WALL of
type WALL_TYPE) and B1 (a pointer to an array BOUNDARY_PROP1 of type
BOUNDARY_PROP1_TYPE). 
A WALL_LOOP_2 loop is also used in the contained routine ENTHALPY_ADVECTION
called at the end of DIVERGENCE_PART_1. This loop does the same tasks as the
previous and is not instrumented with OpenMP.

Compiling the divg.f90 file with GCC 11.4 or 13.2 in both Pop-OS Linux and Mac
OSX 14 gives the following error:

$ gfortran -c -save-temps -freport-bug -m64 -O0 -std=f2018 -ggdb -Wall
-Wcharacter-truncation -Wno-target-lifetime -fcheck=all -fbacktrace
-ffpe-trap=invalid,zero,overflow -frecursive -ffpe-summary=none
-fall-intrinsics -cpp -fopenmp divg.f90
during GIMPLE pass: omplower
divg.f90:44:52:

   44 | !$OMP PARALLEL DO PRIVATE(IW,WC,B1) SCHEDULE(GUIDED)
  |^
internal compiler error: in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.cc:746
Please submit a full bug report, with preprocessed source.
See  for instructions.

If we comment the ALLOCATABLE field ZZ_G in the derived type
BOUNDARY_PROP1_TYPE the module compiles without error.

Thank you for your time and attention.
Marcos

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #58014|0   |1
is obsolete||

--- Comment #11 from Jonathan Wakely  ---
Created attachment 58015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58015&action=edit
Make std::pair relocatable and simplify __relocate_a

Fixed patch.

[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 58013 [details]
> gcc14-pr114810.patch
> 
> So like this?  Tried hard to reduce the testcase, but it didn't progress at
> all, so at least tried manually using cvise's clex to rename tokens a little
> bit.

LGTM.

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #7)
> Created attachment 58014 [details]
> Make std::pair relocatable and simplify __relocate_a
> 
> Does this help?

Oh hang on, that patch is wrong. I'll fix it and check the results myself ...

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #9 from Jan Hubicka  ---
Your patch gives me error compiling testcase

jh@ryzen3:/tmp> ~/trunk-install/bin/g++ -O3 ~/t.C 
In file included from /home/jh/trunk-install/include/c++/14.0.1/vector:65,
 from /home/jh/t.C:1:
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_uninitialized.h: In
instantiation of ‘_ForwardIterator std::__relocate_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = const
pair*; _ForwardIterator = pair*; _Allocator = allocator >;
_Traits = allocator_traits > >]’:
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_uninitialized.h:1127:31:  
required from ‘_Tp* std::__relocate_a(_Tp*, _Tp*, _Tp*, allocator<_T2>&) [with
_Tp = pair; _Up = pair]’
 1127 |   return std::__relocate_a(__cfirst, __clast, __result, __alloc);
  |  ~^~
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_vector.h:509:26:   required
from ‘static std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_S_relocate(pointer, pointer, pointer, _Tp_alloc_type&) [with _Tp =
std::pair; _Alloc =
std::allocator >; pointer =
std::pair*; _Tp_alloc_type =
std::vector >::_Tp_alloc_type]’
  509 | return std::__relocate_a(__first, __last, __result, __alloc);
  |~^~~~
/home/jh/trunk-install/include/c++/14.0.1/bits/vector.tcc:647:32:   required
from ‘void std::vector<_Tp, _Alloc>::_M_realloc_append(_Args&& ...) [with _Args
= {const std::pair&}; _Tp = std::pair; _Alloc = std::allocator
>]’
  647 | __new_finish = _S_relocate(__old_start, __old_finish,
  |~~~^~~
  648 |__new_start,
_M_get_Tp_allocator());
  |   
~~~
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_vector.h:1294:21:   required
from ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =
std::pair; _Alloc =
std::allocator >; value_type =
std::pair]’
 1294 |   _M_realloc_append(__x);
  |   ~^
/home/jh/t.C:8:25:   required from here
8 | stack.push_back (pair);
  | ^~
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_uninitialized.h:1084:56:
error: use of deleted function ‘const _Tp* std::addressof(const _Tp&&) [with
_Tp = pair]’
 1084 | 
std::addressof(std::move(*__first
  | 
~~^
In file included from
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_pair.h:61,
 from
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_algobase.h:64,
 from /home/jh/trunk-install/include/c++/14.0.1/vector:62:
/home/jh/trunk-install/include/c++/14.0.1/bits/move.h:168:16: note: declared
here
  168 | const _Tp* addressof(const _Tp&&) = delete;
  |^
/home/jh/trunk-install/include/c++/14.0.1/bits/stl_uninitialized.h:1084:56:
note: use ‘-fdiagnostics-all-candidates’ to display considered candidates
 1084 | 
std::addressof(std::move(*__first
  | 
~~^


It is easy to check if conversion happens - just compile it and see if there is
memcpy or memmove in the optimized dump file (or final assembly)

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #8 from Jan Hubicka  ---
I had wrong noexcept specifier.  This version works, but I still need to inline
relocate_object_a into the loop

diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 7f84da31578..f02d4fb878f 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1100,8 +1100,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "relocation is only possible for values of the same type");
   _ForwardIterator __cur = __result;
   for (; __first != __last; ++__first, (void)++__cur)
-   std::__relocate_object_a(std::__addressof(*__cur),
-std::__addressof(*__first), __alloc);
+   {
+ typedef std::allocator_traits<_Allocator> __traits;
+ __traits::construct(__alloc, std::__addressof(*__cur),
std::move(*std::__addressof(*__first)));
+ __traits::destroy(__alloc,
std::__addressof(*std::__addressof(*__first)));
+   }
   return __cur;
 }

@@ -1109,8 +1112,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template 
 _GLIBCXX20_CONSTEXPR
 inline __enable_if_t::value, _Tp*>
-__relocate_a_1(_Tp* __first, _Tp* __last,
-  _Tp* __result,
+__relocate_a_1(_Tp* __restrict __first, _Tp* __last,
+  _Tp* __restrict __result,
   [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
 {
   ptrdiff_t __count = __last - __first;
@@ -1147,6 +1150,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::__niter_base(__result), __alloc);
 }

+  template 
+_GLIBCXX20_CONSTEXPR
+inline _Tp*
+__relocate_a(_Tp* __restrict __first, _Tp* __last,
+_Tp* __restrict __result,
+allocator<_Up>& __alloc)
+noexcept(noexcept(__relocate_a_1(__first, __last, __result, __alloc)))
+{
+  return std::__relocate_a_1(__first, __last, __result, __alloc);
+}
+
   /// @endcond
 #endif // C++11

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #7 from Jonathan Wakely  ---
Created attachment 58014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58014&action=edit
Make std::pair relocatable and simplify __relocate_a

Does this help?

[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 58013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58013&action=edit
gcc14-pr114810.patch

So like this?  Tried hard to reduce the testcase, but it didn't progress at
all, so at least tried manually using cvise's clex to rename tokens a little
bit.

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #6 from Jan Hubicka  ---
Thanks. I though the relocate_a only cares about the fact if the pointed-to
type can be bitwise copied.  It would be nice to early produce memcpy from
libstdc++ for std::pair, so the second patch makes sense to me (I did not test
if it works)

I think it would be still nice to tell GCC that the copy loop never gets
overlapping memory locations so the cases which are not early optimized to
memcpy can still be optimized later (or vectorized if it does really something
non-trivial).

So i tried your second patch fixed so it compiles:
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 7f84da31578..0d2e588ae5e 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1109,8 +1109,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template 
 _GLIBCXX20_CONSTEXPR
 inline __enable_if_t::value, _Tp*>
-__relocate_a_1(_Tp* __first, _Tp* __last,
-  _Tp* __result,
+__relocate_a_1(_Tp* __restrict __first, _Tp* __last,
+  _Tp* __restrict __result,
   [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
 {
   ptrdiff_t __count = __last - __first;
@@ -1147,6 +1147,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::__niter_base(__result), __alloc);
 }

+  template 
+_GLIBCXX20_CONSTEXPR
+inline _Tp*
+__relocate_a(_Tp* __restrict __first, _Tp* __last,
+_Tp* __restrict __result,
+allocator<_Up>& __alloc)
+noexcept(std::__is_bitwise_relocatable<_Tp>::value)
+{
+  return std::__relocate_a_1(__first, __last, __result, __alloc);
+}
+
   /// @endcond
 #endif // C++11

it does not make ldist to hit, so the restrict info is still lost.  I think the
problem is that if you call relocate_object the restrict reduces scope, so we
only know that the elements are pairwise disjoint, not that the vectors are.
This is because restrict is interpreted early pre-inlining, but it is really
Richard's area.

It seems that the patch makes us to go through __uninitialized_copy_a instead
of __uninit_copy. I am not even sure how these are different, so I need to
stare at the code bit more to make sense of it :)

[Bug c/114816] Non-standard behavior with void arguments

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

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

--- Comment #1 from Joseph S. Myers  ---
Note that it's not possible to define a function with such parameters ("After
adjustment, the parameters in a parameter type list in a function declarator
that is part of a definition of that function shall not have incomplete
type.").

"register void" and "const void" (single unnamed parameter) are in the list of
undefined behavior in Annex J ("A storage-class specifier or type qualifier
modifies the keyword void as a function parameter type list") - presumably
implicitly undefined for lack of definition. As for named void parameters (or
more than one void parameter, etc.), the response to C99 DR#295 says "The
Committee agrees that there do not appear to be any constraints forbidding
constructions like void func(void parm); nor are any semantics provided for
this construction." (which would also be implicitly undefined behavior).

Given the desire to reduce undefined behavior in C2y it would be reasonable to
submit a paper tightening this up by making all the problem cases (any case of
a void parameter except for the special case of a single unnamed parameter of
type void, no storage class specifier, no ellipsis following) into constraint
violations for function declarators - or indeed to raise this through the issue
tracking process once we have the new issue tracker set up, with a view to
inviting WG14 to consider this a defect applicable to older standard versions.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Eric Botcazou  ---
> Rainer, what's your take on this?  Should we proceed and change the ABI on
> Solaris for GCC 14?

I think so, yes:

* Binary compatibility with the Studio compilers is pretty important IMO.

* Even though the SCD wording isn't really clear, the intent seems to
  match what Studio cc does according to the colleague on the spec group
  Jakub cited.

* There's no point in waiting beyond GCC 14, I believe: this will break
  compatiblity with GCC <= 13 no matter what.

* Besides, Solaris is pretty quick picking up new GCC releases these
  days, so they'll bundle GCC 14.1.0 not long after it's released, so
  the benefit will be immediate.

* I'm a tad uncertain about what to do on Linux/sparc64, though: while
  it mostly has followed the SCD, there are exceptions (e.g. sizeof
  (long double)) and no vendor compiler to be compatible with.  So
  making the same change there would only mean breaking compatibility
  with older GCCs (and clang) for little gain.

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #5 from Jonathan Wakely  ---
If the problem is simply that the __restrict qualifiers are not present because
we go through the generic function taking iterators, then we can just add:

--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1109,8 +1109,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template 
 _GLIBCXX20_CONSTEXPR
 inline __enable_if_t::value, _Tp*>
-__relocate_a_1(_Tp* __first, _Tp* __last,
-  _Tp* __result,
+__relocate_a_1(_Tp* __restrict __first, _Tp* __last,
+  _Tp* __restrict __result,
   [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
 {
   ptrdiff_t __count = __last - __first;
@@ -1147,6 +1147,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::__niter_base(__result), __alloc);
 }

+  template 
+_GLIBCXX20_CONSTEXPR
+inline _ForwardIterator
+__relocate_a(_Tp* __restrict __first, _Tp* __last,
+_Tp* __restrict __result,
+[[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
+noexcept(std::__is_bitwise_relocatable<_Tp>::value)
+{
+  return std::__relocate_a_1(__first, __last, __result, __alloc);
+}
+
   /// @endcond
 #endif // C++11


If the problem is that std::pair is not bitwise_relocatable, then we
could change that (as Marc suggested as a possible future enhancement):

--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1082,6 +1082,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct __is_bitwise_relocatable
 : is_trivial<_Tp> { };

+  template
+struct __is_bitwise_relocatable, void>
+: __and_, is_trivial<_Up>>
+{ };
+
   template 
 _GLIBCXX20_CONSTEXPR

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jan Hubicka from comment #2)
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1130,7 +1130,58 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> }
>return __result + __count;
>  }
> +
> +  template 
> +_GLIBCXX20_CONSTEXPR
> +inline __enable_if_t::value, _Tp*>
> +__relocate_a(_Tp * __restrict __first, _Tp *__last,
> +_Tp * __restrict __result, _Allocator& __alloc) noexcept

This is wrong, we can't optimize arbitrary allocators, only when the allocator
is std::allocator<_Tp>. That's what the existing code is doing with the
indirection from __relocate_a to __relocate_a_1.

> +{
> +  ptrdiff_t __count = __last - __first;
> +  if (__count > 0)
> +   {
> +#ifdef __cpp_lib_is_constant_evaluated
> + if (std::is_constant_evaluated())
> +   {
> + for (; __first != __last; ++__first, (void)++__result)

You don't need the (void) case here because __first and __result are both
pointers. That's only needed for the generic __relocate_a that deals with
arbitrary iterator types.

> +   {
> + // manually inline relocate_object_a to not lose restrict
> qualifiers

We don't care about restrict when is_constant_evaluated is true, we're not
optimizing this code. It just gets interpreted at compile time. There is no
reason to inline __relocate_object_a for the is_constant_evaluated case.


> + typedef std::allocator_traits<_Allocator> __traits;
> + __traits::construct(__alloc, __result,
> std::move(*__first));
> + __traits::destroy(__alloc, std::__addressof(*__first));
> +   }
> + return __result;
> +   }
>  #endif
> + __builtin_memcpy(__result, __first, __count * sizeof(_Tp));
> +   }
> +  return __result + __count;
> +}
> +#endif
> +
> +  template 
> +_GLIBCXX20_CONSTEXPR
> +#if _GLIBCXX_HOSTED
> +inline __enable_if_t::value, _Tp*>
> +#else
> +inline _Tp *
> +#endif
> +__relocate_a(_Tp * __restrict __first, _Tp *__last,
> +_Tp * __restrict __result, _Allocator& __alloc)
> +noexcept(noexcept(std::allocator_traits<_Allocator>::construct(__alloc,
> +__result, std::move(*__first)))
> +&& noexcept(std::allocator_traits<_Allocator>::destroy(
> +   __alloc, std::__addressof(*__first
> +{
> +  for (; __first != __last; ++__first, (void)++__result)
> +   {
> + // manually inline relocate_object_a to not lose restrict
> qualifiers
> + typedef std::allocator_traits<_Allocator> __traits;
> + __traits::construct(__alloc, __result, std::move(*__first));
> + __traits::destroy(__alloc, std::__addressof(*__first));
> +   }

I don't understand this overload at all. Is this overload the one that actually
gets used for your testcase? I think it should be, because std::pair
is not bitwise_relocatable.

Why does the restrict qualifier get lost if we don't inline relocate_object_a?
That function is restrict-qualified as well.


> +  return __result;
> +}
>  
>template  typename _Allocator>

[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file

[gejoed at rediffmail dot com via Gcc-bugs]

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

--- Comment #5 from Gejoe  ---
(In reply to Gejoe from comment #2)
> For me, it is like this (just keeping the sample filenames as such but the
> values are real ones shown while checking with gcov-dump) :
> 
> $gcov-dump ./obj-dir-path/src-file.gcda
> ./obj-dir-path/src-file.gcda:data:magic `gcda':version `B14*'
> ./obj-dir-path/src-file.gcda:stamp 2912455990
> :
> 
> 
> $ gcov-dump ./obj-dir-path/src-file.gcno
> ./obj-dir-path/src-file.gcno:note:magic `gcno':version `B14*'
> ./obj-dir-path/src-file.gcno:stamp 2912494680
> :
> 
> 
> Does this indicate something more to be checked ?
> 
> In the previous branch where gcc 10.3.0 is used, I could see same stamp
> value for the gcov-dump of same gcda and gcno files there - 3176078538.
> 
> Awaiting reply.
> 
> Thanks.

Hi team,
Can I expect any reply on my message posted above ?

Thanks,
Gejoe

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jan Hubicka from comment #2)
> This seems to do the trick, but for some reason I get memmove

What's the second overload for, and why does it depend on _GLIBCXX_HOSTED?

[Bug middle-end/114824] New: gcc doesn't respect __attribute__((zero_call_used_regs("used"))) when performing a tail call optimization

[mikulas at artax dot karlin.mff.cuni.cz via Gcc-bugs]

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

Bug ID: 114824
   Summary: gcc doesn't respect
__attribute__((zero_call_used_regs("used"))) when
performing a tail call optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---

If a function has the attribute __attribute__((zero_call_used_regs("used")))
and the function ends with a sibling call, the used registers are not zeroed.

See this function:
#include 
__attribute__((zero_call_used_regs("used"))) void f(void)
{
__asm__ volatile("" ::: "x0", "x1", "x2", "x3", "x4", "x5", "x6",
"x7");
printf("Hello World!\n");
}
Compile it with "gcc -S -o - -O2 call.c -Wall -Wextra" - the result is:
f:
adrpx0, .LC0
add x0, x0, :lo12:.LC0
b   puts

If we disable the tail call optimization, the registers x0 - x7 are cleared
properly:
gcc -S -o - -O2 call.c -Wall -Wextra -fno-optimize-sibling-calls
f:
stp x29, x30, [sp, -16]!
mov x29, sp
adrpx0, .LC0
add x0, x0, :lo12:.LC0
bl  puts
ldp x29, x30, [sp], 16
mov x0, 0
mov x1, 0
mov x2, 0
mov x3, 0
mov x4, 0
mov x5, 0
mov x6, 0
mov x7, 0
mov x16, 0
mov x17, 0
ret

I tested it on arm64 and x86-64 and both of them suffer from this problem.

[Bug tree-optimization/114823] New: Missed optimization of redundant loops

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 114823
   Summary: Missed optimization of redundant loops
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, for the reduced code below, its second loop is redundant. There seems to
be a missed optimization.

https://godbolt.org/z/McqeYdnfY

int a[1024];
int b[1024];

void func()
{
for (int i = 0; i < 1024; i+=1) {
a[i] = b[i] * 2;
}

for (int i = 0; i < 1024; i+=1) {
a[i] = b[i] * 2;
}
}

GCC -O3:
func:
xor eax, eax
.L2:
movdqa  xmm0, XMMWORD PTR b[rax]
add rax, 16
pslld   xmm0, 1
movaps  XMMWORD PTR a[rax-16], xmm0
cmp rax, 4096
jne .L2
xor eax, eax
.L3:
movdqa  xmm0, XMMWORD PTR b[rax]
add rax, 16
pslld   xmm0, 1
movaps  XMMWORD PTR a[rax-16], xmm0
cmp rax, 4096
jne .L3
ret

Expected code:
func:
xor eax, eax
.L2:
movdqa  xmm0, XMMWORD PTR b[rax]
add rax, 16
pslld   xmm0, 1
movaps  XMMWORD PTR a[rax-16], xmm0
cmp rax, 4096
jne .L2
ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug fortran/71703] [11 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488

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

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

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org

--- Comment #20 from Paul Thomas  ---
All the failing testcases posted in this PR now compile and run correctly.

Many thanks once again, Gerhard.

Paul

[Bug fortran/106999] [11/12/13 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
   |ICE tree check: expected|tree check: expected
   |record_type or union_type   |record_type or union_type
   |or qual_union_type, have|or qual_union_type, have
   |function_type in|function_type in
   |gfc_class_data_get, at  |gfc_class_data_get, at
   |fortran/trans-expr.cc:233   |fortran/trans-expr.cc:233

--- Comment #7 from Paul Thomas  ---
Needs backporting. Changed summary.

[Bug fortran/110987] [13 Regression] Segmentation fault after finalization of a temporary variable

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[13/14 Regression]  |[13 Regression]
   |Segmentation fault after|Segmentation fault after
   |finalization of a temporary |finalization of a temporary
   |variable|variable

--- Comment #10 from Paul Thomas  ---
Needs backporting. Summary changed.

[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[13/14 Regression] Fix for  |[13 Regression] Fix for
   |PR37336 triggers an ICE in  |PR37336 triggers an ICE in
   |gfc_format_decoder while|gfc_format_decoder while
   |constructing a vtab |constructing a vtab

--- Comment #11 from Paul Thomas  ---
Needs backporting. Summary changed.

[Bug middle-end/114822] New: ldist should produce memcpy/memset/memmove histograms based on loop information converted

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

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

Bug ID: 114822
   Summary: ldist should produce memcpy/memset/memmove histograms
based on loop information converted
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

When loop is converted to string builtin we lose information about its size.
This means that we won't expand it inline when the block size is expected to be
small.  This causes performance problem i.e. on std::vector and testcase from
PR114821  which at least with profile feedback runs significantly slower than
variant where memcpy is produced early


#include 
typedef unsigned int uint32_t;
int pair;
void
test()
{
std::vector stack;
stack.push_back (pair);
while (!stack.empty()) {
int cur = stack.back();
stack.pop_back();
if (true)
{
cur++;
stack.push_back (cur);
stack.push_back (cur);
}
if (cur > 1)
break;
}
}
int
main()
{
for (int i = 0; i < 1; i++)
  test();
}

[Bug fortran/114739] Ensure no IMPLICIT type errors appear when they should for inquiry references

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[14 Regression] ice in  |Ensure no IMPLICIT type
   |gfc_find_derived_types, at  |errors appear when they
   |fortran/symbol.cc:2458  |should for inquiry
   ||references

--- Comment #10 from Paul Thomas  ---
Changed the summary line

[Bug fortran/102597] ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 since r8-3365-gb89a63b916340ef2

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-10089-gca00bf02dcc37f9ff1028ca1d90e8b8d95d69683
Author: Paul Thomas 
Date:   Tue Apr 23 10:22:48 2024 +0100

Fortran: Check that the ICE does not reappear [PR102597]

2024-04-23  Paul Thomas  

gcc/testsuite/
PR fortran/102597
* gfortran.dg/pr102597.f90: New test.

[Bug target/105359] _Float128 expanders and builtins disabled on ppc targets with 64-bit long double

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-04-23
   Keywords||missed-optimization
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Kewen Lin  ---
Thanks for reporting, I'll have a look.

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #2 from Jan Hubicka  ---
What I am shooting for is to optimize it later in loop distribution. We can
recognize memcpy loop if we can figure out that source and destination memory
are different.

We can help here with restrict, but I was bit lost in how to get them done.

This seems to do the trick, but for some reason I get memmove

diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 7f84da31578..1a6223ea892 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1130,7 +1130,58 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
   return __result + __count;
 }
+
+  template 
+_GLIBCXX20_CONSTEXPR
+inline __enable_if_t::value, _Tp*>
+__relocate_a(_Tp * __restrict __first, _Tp *__last,
+_Tp * __restrict __result, _Allocator& __alloc) noexcept
+{
+  ptrdiff_t __count = __last - __first;
+  if (__count > 0)
+   {
+#ifdef __cpp_lib_is_constant_evaluated
+ if (std::is_constant_evaluated())
+   {
+ for (; __first != __last; ++__first, (void)++__result)
+   {
+ // manually inline relocate_object_a to not lose restrict
qualifiers
+ typedef std::allocator_traits<_Allocator> __traits;
+ __traits::construct(__alloc, __result, std::move(*__first));
+ __traits::destroy(__alloc, std::__addressof(*__first));
+   }
+ return __result;
+   }
 #endif
+ __builtin_memcpy(__result, __first, __count * sizeof(_Tp));
+   }
+  return __result + __count;
+}
+#endif
+
+  template 
+_GLIBCXX20_CONSTEXPR
+#if _GLIBCXX_HOSTED
+inline __enable_if_t::value, _Tp*>
+#else
+inline _Tp *
+#endif
+__relocate_a(_Tp * __restrict __first, _Tp *__last,
+_Tp * __restrict __result, _Allocator& __alloc)
+noexcept(noexcept(std::allocator_traits<_Allocator>::construct(__alloc,
+__result, std::move(*__first)))
+&& noexcept(std::allocator_traits<_Allocator>::destroy(
+   __alloc, std::__addressof(*__first
+{
+  for (; __first != __last; ++__first, (void)++__result)
+   {
+ // manually inline relocate_object_a to not lose restrict qualifiers
+ typedef std::allocator_traits<_Allocator> __traits;
+ __traits::construct(__alloc, __result, std::move(*__first));
+ __traits::destroy(__alloc, std::__addressof(*__first));
+   }
+  return __result;
+}

   template 

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

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

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

--- Comment #12 from Eric Botcazou  ---
Rainer, what's your take on this?  Should we proceed and change the ABI on
Solaris for GCC 14?

[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

--- Comment #1 from Jonathan Wakely  ---
Using memcpy on any std::pair is undefined behaviour because it's not trivially
copyable. 

That's not because it has a copy constructor, its copy constructor is defaulted
and so trivial if the data members are trivially copy constructible:
  constexpr pair(const pair&) = default;///< Copy constructor

It's because it has a non-trivial assignment operator:

  /// Copy assignment operator
  constexpr pair&
  operator=(const pair& __p)
  noexcept(_S_nothrow_assignable())
  requires (_S_assignable())
  {
first = __p.first;
second = __p.second;
return *this;
  }


I think this exact point was discussed when Marc introduced the relocate
optimizations. We could maybe cheat and say that we know it's safe to memcpy
std::pair even though the language says it's undefined, because we
know what our std::pair implementation looks like.

[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file

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

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

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

[Bug gcov-profile/114820] Gcov 11.4.0 .gcda:stamp mismatch with notes file

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

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

[Bug tree-optimization/114799] [13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|[14 Regression] ICE: tree   |[13 Regression] ICE: tree
   |check: expected class   |check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |useless_type_conversion_p,  |useless_type_conversion_p,
   |at gimple-expr.cc:85 with   |at gimple-expr.cc:85 with
   |-O2  -fno-vect-cost-model   |-O2  -fno-vect-cost-model
   |since r14-9316  |since r14-9316
  Known to work||14.0
   Target Milestone|14.0|13.3
  Known to fail|14.0|

--- Comment #9 from Richard Biener  ---
Will backport to 13 at least.

[Bug tree-optimization/114799] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:18e8e55487238237f37f621668fdee316624981a

commit r14-10088-g18e8e55487238237f37f621668fdee316624981a
Author: Richard Biener 
Date:   Tue Apr 23 08:39:03 2024 +0200

tree-optimization/114799 - SLP and patterns

The following plugs a hole with computing whether a SLP node has any
pattern stmts which is important to know when we want to replace it
by a CTOR from external defs.

PR tree-optimization/114799
* tree-vect-slp.cc (vect_get_and_check_slp_defs): Properly
update ->any_pattern when swapping operands.

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

[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Andreas Krebbel :

https://gcc.gnu.org/g:42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5

commit r14-10087-g42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5
Author: Andreas Krebbel 
Date:   Tue Apr 23 10:05:46 2024 +0200

s390x: Fix vec_xl/vec_xst type aliasing [PR114676]

The requirements of the vec_xl/vec_xst intrinsincs wrt aliasing of the
pointer argument are not really documented.  As it turns out, users
are likely to get it wrong.  With this patch we let the pointer
argument alias everything in order to make it more robust for users.

gcc/ChangeLog:

PR target/114676
* config/s390/s390-c.cc (s390_expand_overloaded_builtin): Use a
MEM_REF with an addend of type ptr_type_node.

gcc/testsuite/ChangeLog:

PR target/114676
* gcc.target/s390/zvector/pr114676.c: New test.

Suggested-by: Jakub Jelinek 

[Bug libstdc++/114821] New: _M_realloc_append should use memcpy instead of loop to copy data when possible

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

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

Bug ID: 114821
   Summary: _M_realloc_append should use memcpy instead of loop to
copy data when possible
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

In thestcase

#include 
typedef unsigned int uint32_t;
std::pair pair;
void
test()
{
std::vector> stack;
stack.push_back (pair);
while (!stack.empty()) {
std::pair cur = stack.back();
stack.pop_back();
if (!cur.first)
{
cur.second++;
stack.push_back (cur);
stack.push_back (cur);
}
if (cur.second > 1)
break;
}
}
int
main()
{
for (int i = 0; i < 1; i++)
  test();
}

We produce _M_reallloc_append which uses loop to copy data instead of memcpy.
This is bigger and slower.  The reason why __relocate_a does not use memcpy
seems to be fact that pair has copy constructor. It still can be pattern
matched by ldist but it fails with:

(compute_affine_dependence
  ref_a: *__first_1, stmt_a: *__cur_37 = *__first_1;
  ref_b: *__cur_37, stmt_b: *__cur_37 = *__first_1;
) -> dependence analysis failed

So we can not disambiguate old and new vector memory and prove that loop is
indeed memcpy loop. I think this is valid since operator new is not required to
return new memory, but I think adding __restrict should solve this.

Problem is that I got lost on where to add them, since relocate_a uses
iterators instead of pointers