[Bug middle-end/110069] [Perf] -finstrument-functions causes program size to double

[chipweinberger at jamcorder dot com via Gcc-bugs]

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

--- Comment #2 from Chip Weinberger  ---
The 35 bytes figure is from -O0. This is a debug feature.

[Bug middle-end/110069] [Perf] -finstrument-functions causes program size to double

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/110069] [Perf] -finstrument-functions causes program size to double

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

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

--- Comment #1 from Andrew Pinski  ---
In your backend you could implement all of this I think. 

Are you talking about -O0 code generation or -O2?

[Bug c/110069] New: [Perf] -finstrument-functions causes program size to double

[chipweinberger at jamcorder dot com via Gcc-bugs]

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

Bug ID: 110069
   Summary: [Perf] -finstrument-functions causes program size to
double
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chipweinberger at jamcorder dot com
  Target Milestone: ---

Created attachment 55228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55228=edit
Assembly comparison with and without finstrument functions

Hello,

First time issue filer here. 

First some context: I am using -finstrument-functions to implement a "stack
mirror" feature on the ESP32 microcontroller from Espressif. This mirror is
logged after detecting stack corruption, and it is incrediblly useful for
debugging.

Unfortunately, -finstrument-functions causes the program size to double, using
100KB extra of internal SRAM (over 20% of the entire MCUs memory), meaning most
people cannot even enable this feature because spare ram is usually very
scarce.

The main problem is the function signature of __cyg_profile_func_enter. ~35
bytes of instructions are needed to set up the 2 function arguments, and these
35 bytes need to be inserted into *every* function. This is a major cost for
both performance and memory.

void __cyg_profile_func_enter(void *func, void *callsite)

These arguments are not needed by us. We can traverse the stack ourself.

I am hoping we can consider a new flag, -function-entry-exit-hooks, with a much
simpler function signature:

void __func_hook_entry(void)
void __func_hook_exit(void)

Without the arguments, each function only needs a simple 'call' instruction.

This would be incredibly useful for us, and I imagine a lot of other people as
well.

Thanks,
Chip

[Bug tree-optimization/110068] missing min detection

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

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

--- Comment #1 from Andrew Pinski  ---
here is another one:
```
unsigned
f5 (unsigned  x)
{
  bool t = x >= 1U<<(sizeof(x)*8-1);
  if (!t)
;
  else
x = 1U<<(sizeof(x)*8-1);
  return x;
}
```

this time LLVM does not detect it either.

easy way to see that out is by using riscv and -march=rv32gc_zba_zbb_zbc_zbs.
You should get for all 5 functions:
li  a5,-2147483648
minua0,a0,a5
ret

Or:
lui a1, 524288
minua0, a0, a1
ret

Both are execute the same in the end.

[Bug target/110044] [10, 11, 12, 13, 14 Regression] #pragma pack(push, 1) may not force packing, while __attribute__((packed, aligned(1))) works

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #6)
> I'm going to test the following (which will take some time since the
> hardware is needed for testing releases too).
> 
> The test for AGGREGATE_TYPE_P() could actually be changed to
> RECORD_OR_UNION_TYPE_P () - since the case that we might have an array is
> handled for non-empty structs (but we do need to guard the empty struct
> case).  The problem seems to be we were ignoring that the field type could
> be packed or that there was a cap on the max alignment.
> 
> If it works as expected then I will apply to the open branches (hopefully
> before 10.5 is spun).
> 
> 
> 
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 5b3b8b52e7e..e1c038da305 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -8209,7 +8209,8 @@ darwin_rs6000_special_round_type_align (tree type,
> unsigned int computed,
>type = TREE_TYPE (type);
>} while (AGGREGATE_TYPE_P (type));
>  
> -  if (! AGGREGATE_TYPE_P (type) && type != error_mark_node)
> +  if (type != error_mark_node && ! AGGREGATE_TYPE_P (type)
> +  ! TYPE_PACKED(type) && maximum_field_alignment == 0)
>  align = MAX (align, TYPE_ALIGN (type));
>  
>return align;

Thank you for dealing with this!

[Bug tree-optimization/110068] New: missing min detection

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

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

Bug ID: 110068
   Summary: missing min detection
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#define min1(x,y) ((x) < (y) ? (x) : (y))
#define min2(x,y) ((x) <= (y) ? (x) : (y))
static inline unsigned
min3(unsigned x, unsigned y)
{
return min1(x, y);
}
static inline unsigned
min4(unsigned x, unsigned y)
{
return min3(x, y);
}
unsigned 
f1 (unsigned  x)
{
  return min1(x, 1U<<(sizeof(x)*8-1));
}
unsigned
f2 (unsigned  x)
{
  return min2(x, 1U<<(sizeof(x)*8-1));
}
unsigned
f3 (unsigned  x)
{
  return min3(x, 1U<<(sizeof(x)*8-1));
}
unsigned
f4 (unsigned  x)
{
  return min4(x, 1U<<(sizeof(x)*8-1));
}
```
f1,f2,f3, and f4 should all produce MIN_EXPRs but currently f1 does not.
I would have thought r11-1504-g2e0f4a18bc978  fixed this case but it does not.

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

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

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

--- Comment #10 from Jason Merrill  ---
(In reply to ensadc from comment #7)
> (In reply to Zhihao Yuan from comment #6)
> 
> I think this is a different bug. GCC thinks the implicitly-deleted move
> assignment operator `pair& pair::operator=(pair&&)` is a
> candidate for the assignment, which causes ambiguity with
> `operator=(value_type&&)` (where value_type = pair). But as part of
> resolution of CWG 1402, [class.copy.assign] specifies that "A defaulted move
> assignment operator that is defined as deleted is ignored by overload
> resolution".

Incidentally, no: GCC mentions it, but considers it worse than any other
candidate.  The real ambiguity is with
operator=(const pair&), the implicitly-deleted *copy* assignment.  I
don't think this is a bug; if you disagree, please open another PR for it.

[Bug tree-optimization/101024] Missed min expression at phiopt1

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

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

--- Comment #11 from Andrew Pinski  ---
A few testcases that have not been added to the testsuite yet.
Note it takes f1 to phiopt2 to optimize that because there is an extra
statement left behind because match does not deal with `(signed)a < 0` yet.

```
unsigned long long
f2 (unsigned long long x)
{
  if (x < 0x8000ULL)
x = 0x8000ULL;
  else
{
if (x >= 0x8023ULL)
  x = 0x8023ULL;
}
  return x;
}
unsigned long long
f1 (unsigned long long x)
{
  if (x >= 100)
{
if (x >= 0x8000ULL)
  x = 0x8000ULL;
}
  else
x = 100;
  return x;
}

```

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
For 
br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);

n->n is  0x300200.
n->range is 32.
n->type is uint64.

Currently the code assumes n->range is same as TYPE PRECISION(n->type), and
tries to rotate the mask with below code and get new mask as 0x20300 which is
incorrect. 
tmp_n = tmp_n >> count | tmp_n << (range - count)

--- Comment #5 from Hongtao.liu  ---
For 
br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);

n->n is  0x300200.
n->range is 32.
n->type is uint64.

Currently the code assumes n->range is same as TYPE PRECISION(n->type), and
tries to rotate the mask with below code and get new mask as 0x20300 which is
incorrect. 
tmp_n = tmp_n >> count | tmp_n << (range - count)

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
For 
br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);

n->n is  0x300200.
n->range is 32.
n->type is uint64.

Currently the code assumes n->range is same as TYPE PRECISION(n->type), and
tries to rotate the mask with below code and get new mask as 0x20300 which is
incorrect. 
tmp_n = tmp_n >> count | tmp_n << (range - count)

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Sergei Trofimovich from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am suspecting it was caused by r14-1402-gd8545fb2c71683f407bfd9670 .
> 
> I did not bisect and tested only a revert on top of
> r14-1423-gfefa7db2c31fee. The revert does indeed restore pixman-0.42.2 test
> suite passing!

I'll take a look.

[Bug rtl-optimization/109930] transform atomic exchange to unconditional store when old value is unused?

[Simon.Richter at hogyros dot de via Gcc-bugs]

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

--- Comment #5 from Simon Richter  ---
> Btw if you know the old state then there is presumably no concurrent access 
> here and so you don't need atomic, let alone sequential consistency.

I know it in some, but not all cases.

Basically, what I do is

auto old_x = x.load();

retry:
switch(old_x) {
case 1:
if(!x.compare_exchange_weak(old_x, 2))
 goto retry;
stop_timer();
old_x = x.exchange(4);
assert(old_x == 2);
break;
case 2:
// we must have preempted another instance of this function
// do nothing
break;
case 3:
// handle timeout
...
break;
case 4:
// handle operation complete
...
}

This is in code for timeout handling in a realtime system, the timer interrupt
can preempt this. State 1 is "operation in progress", state 2 is "operation
finished", state 3 is "operation timed out", and state 4 is "operation finished
and timer stopped", and the timer interrupt will try to switch from 1 to 3.

The transient state 2 then solves the race between the timer expiring and
stopping the timer (which is asynchronous because the interrupt controller has
a few cycles delay).

So the switch from state 2 to state 4 has release semantics.

[Bug c/110047] RFE: Add a warning for use of bare "unsigned" (possibly under -Wimplicit-int?)

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

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

--- Comment #2 from Eric Gallager  ---
Oh, one other thing I'd note here is that gcc/README.portability contains a
part about this, too; I'm copying and pasting it here:

Implicit int


In C, the 'int' keyword can often be omitted from type declarations.
For instance, you can write

  unsigned variable;

as shorthand for

  unsigned int variable;

There are several places where this can cause trouble.  First, suppose
'variable' is a long; then you might think

  (unsigned) variable

would convert it to unsigned long.  It does not.  It converts to
unsigned int.  This mostly causes problems on 64-bit platforms, where
long and int are not the same size.

Ref:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/README.Portability;h=af6904728833193ba57e74ec5bdd4070992efe42;hb=HEAD#l93

[Bug ipa/110057] Missed devirtualization opportunities

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

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

--- Comment #2 from Andrew Pinski  ---
I am not 100% sure the all of the objects in the vector has to be in type of
C. Because you could do some tricks dealing with inplacement new.

>if this applies to raw arrays

It does applies to raw arrays.

[Bug ipa/110057] Missed devirtualization opportunities

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

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

--- Comment #1 from Andrew Pinski  ---
I don't think it should be checking ssa dump (which is the output right after
going into ssa mode) but rather optimized.

[Bug c++/99242] [modules] ICE in lookup_mark, at cp/tree.c:2403

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||saifi.khan at nishan dot io

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 110056 Summary: ICE on trying to generate header unit for 'execution'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110056

   What|Removed |Added

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

[Bug c++/110056] ICE on trying to generate header unit for 'execution'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/110055] Dangling pointer warning inside std::vector on RISC-V

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> >  C.0 ={v} {CLOBBER(eol)};
> 
> 
> Should never have been emitted from the gimplifier.
> 
> 
> Confirmed, I have not reduced the testcase yet.
> But I can also confirm it on aarch64-linux-gnu with -O3 -mstrict-align
> -fno-exceptions .

So what is happening is we emitting the clobber and then changing it to be a
static variable.

This part happens even for x86_64 though the memcpy here can be removed.


  C.0 = {CLOBBER(eol)};

[Bug middle-end/110055] Dangling pointer warning inside std::vector on RISC-V

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-linux-gnu
   |riscv*-linux-gnu|riscv*-linux-gnu
   ||mips64-linux-gnu

--- Comment #4 from Andrew Pinski  ---
>This bug can only be reproduce on RISC-V platform.


No it can reproduced on mips and aarch64 (with -mstrict-align) too.

[Bug middle-end/110055] Dangling pointer warning inside std::vector on RISC-V

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-31
 Ever confirmed|0   |1
 Target||aarch64-linux-gnu
   ||riscv*-linux-gnu
  Component|c++ |middle-end

--- Comment #3 from Andrew Pinski  ---
>  C.0 ={v} {CLOBBER(eol)};


Should never have been emitted from the gimplifier.


Confirmed, I have not reduced the testcase yet.
But I can also confirm it on aarch64-linux-gnu with -O3 -mstrict-align
-fno-exceptions .

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

--- Comment #6 from Andrew Pinski  ---
Note you can reduce main to just:
```
int main()
{
  std::vector v(5);
  const std::vector w(1);

  v.resize(1);
//  v.insert(v.begin(), 0);
  //v.insert(v.begin(), 1, 0);
//  v.insert(v.begin(), w.begin(), w.end());
  v = w;

  return 0;
}
```
And get the warning still at -O2.

With the above main in .optimized we get:
```
  MEM[(struct _Vector_base *)]._M_impl.D.25239._M_start = _53;
  _46 = _53 + 4;
  MEM[(struct _Vector_base *)]._M_impl.D.25239._M_end_of_storage = _46;
  *_53 = 0;
  w.D.25935._M_impl.D.25239._M_finish = _46;
  v.D.25935._M_impl.D.25239._M_finish = __first_33;
  __xlen_82 = std::vector::size ();
  if (__xlen_82 > 5)
goto ; [33.00%]
  else
goto ; [67.00%]
```

std::vector::size is literally just:
```
movq8(%rdi), %rax
subq(%rdi), %rax
sarq$2, %rax
ret
```

So that is definitely an issue there.

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

--- Comment #5 from Jonathan Wakely  ---
Ugh, that's not good - maybe I should revert it then. Or make _M_invariant much
smaller.

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

--- Comment #4 from Andrew Pinski  ---
So the other thing that is going wrong is the addition of the optimizer hints
is causing things like std::vector::size no longer to be inlined. because
the TU size has increased and we start hitting the TU size limit.
This is why -O3 does not warn either.

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #2 from Sergei Trofimovich  ---
(In reply to Andrew Pinski from comment #1)
> I am suspecting it was caused by r14-1402-gd8545fb2c71683f407bfd9670 .

I did not bisect and tested only a revert on top of r14-1423-gfefa7db2c31fee.
The revert does indeed restore pixman-0.42.2 test suite passing!

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> Anything I can do in std::vector to make it optimize better?

I don't think in this case there is but I could be wrong.
it has to do with the v.insert call saving the end value and then loading from
it and doing a comparison and it is iterative on it (with a few v.insert).

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

--- Comment #2 from Jonathan Wakely  ---
Anything I can do in std::vector to make it optimize better?

[Bug tree-optimization/110053] csmith: problems with -O1 and -O2 in same file

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||wrong-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110067

--- Comment #2 from Andrew Pinski  ---
Maybe related to PR 110067 (which has a shorter testcase).

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Janez Zemva  ---
I resolved this issue by porting openlibm over to djgpp (some hacks and typedef
float float_t;, ... were necessary). The fix on the side of gcc might have been
a more thorough analysis of what is available in math.h and then making a
suitable  based on that analysis. For me, this issue is resolved, but
the problem of how gcc handles non-compliant standard c library implementations
will probably pop up again.

[Bug tree-optimization/110060] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Hmm:
```
  MEM[(struct _Vector_base *)]._M_impl.D.25239._M_start = _73;
  _66 = _73 + 1;
  MEM[(struct _Vector_base *)]._M_impl.D.25239._M_end_of_storage = _66;
  MEM[(struct vector *)].D.25935._M_impl.D.25239._M_finish = _66;
  _486 = _63 + 2;
  v.D.25935._M_impl.D.25239._M_finish = _486;
  _154 = _63 + 3;
  v.D.25935._M_impl.D.25239._M_finish = _154;
  _138 = MEM[(struct X * const &)];
  _215 = v.D.25935._M_impl.D.25239._M_end_of_storage;
  _216 = v.D.25935._M_impl.D.25239._M_finish;
  if (_215 != _216)
```

There is huge missed optimizations here.
I noticed that the last fre is not iterative and we have the case where many of
the ifs are removed due to fre and forwprop at the end.

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection, wrong-code
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
I am suspecting it was caused by r14-1402-gd8545fb2c71683f407bfd9670 .

[Bug tree-optimization/110067] New: [14 Regression] Wrong code on pixman-0.42.2

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

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

Bug ID: 110067
   Summary: [14 Regression] Wrong code on pixman-0.42.2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

This week's gcc r14-1423-gfefa7db2c31fee started failing pixman-0.42.2 test
suite:

pixman> FAIL: scaling-crash-test
pixman> FAIL: cover-test
pixman> FAIL: affine-test
pixman> FAIL: filter-reduction-test
pixman> FAIL: scaling-test

I think it's a gcc bug.

Extracted example from scaling-test:

// $ cat bug.c
#include 
#include 

#define BILINEAR_INTERPOLATION_BITS 7

#define force_inline __inline__ __attribute__ ((__always_inline__))

__attribute__((noipa))
static void
fetch_pixel_no_alpha_32_bug (void *out)
{
uint32_t *ret = out;

*ret = 0xff499baf;
}


static force_inline uint32_t
bilinear_interpolation_local (uint32_t tl, uint32_t tr,
uint32_t bl, uint32_t br,
int distx, int disty)
{
uint64_t distxy, distxiy, distixy, distixiy;
uint64_t tl64, tr64, bl64, br64;
uint64_t f, r;

distx <<= (8 - BILINEAR_INTERPOLATION_BITS);
disty <<= (8 - BILINEAR_INTERPOLATION_BITS);

distxy = distx * disty;
distxiy = distx * (256 - disty);
distixy = (256 - distx) * disty;
distixiy = (256 - distx) * (256 - disty);

/* Alpha and Blue */
tl64 = tl & 0xffff;
tr64 = tr & 0xffff;
bl64 = bl & 0xffff;
br64 = br & 0xffff;

f = tl64 * distixiy + tr64 * distxiy + bl64 * distixy + br64 * distxy;
r = f & 0xffffull;

/* Red and Green */
tl64 = tl;
tl64 = ((tl64 << 16) & 0x00ffull) | (tl64 & 0xff00ull);

tr64 = tr;
tr64 = ((tr64 << 16) & 0x00ffull) | (tr64 & 0xff00ull);

bl64 = bl;
bl64 = ((bl64 << 16) & 0x00ffull) | (bl64 & 0xff00ull);

br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);

f = tl64 * distixiy + tr64 * distxiy + bl64 * distixy + br64 * distxy;
r |= ((f >> 16) & 0x00ffull) | (f & 0xff00ull);

return (uint32_t)(r >> 16);
}

__attribute__((noipa))
static void
bits_image_fetch_pixel_bilinear_32_bug (void *out)
{
uint32_t br;
uint32_t *ret = out;

fetch_pixel_no_alpha_32_bug ();

*ret = bilinear_interpolation_local (0, 0, 0, br, 0x41, 0x42);
}

int main() {
uint32_t r;
bits_image_fetch_pixel_bilinear_32_bug ();
printf("r=%08x\n", r);
}

Triggering:

  $ gcc-14 -O2 -fno-strict-aliasing bug.c -o bug14 && ./bug14
  r=4200282d

  $ gcc-13 -O2 -fno-strict-aliasing bug.c -o bug13 && ./bug13
  r=4213282d

Note that returned values are not identical.

$ gcc-14 -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #3 from rvalue  ---
(In reply to Andrew Pinski from comment #1)
> This also could be a glibc issue.

I tried gcc 12.2.1 and 13.1.1 with exactly the same glibc and binutils
environments, the 12.2.1 version works while 13.1.1 doesn't. So I decide to
report it here.

Further analysis found that the identifier __EH_FRAME_BEGIN__ is different from
the address of .eh_frame section by 0x10, which is unexpected. I suspect the
linker might fail but that didn't change between the two runs.

[Bug target/109541] [12/13/14 regression] ICE in extract_constrain_insn on when building rhash-1.4.3

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

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

--- Comment #12 from Sam James  ---
(Vladimir (and anyone else interested): For bugs like this, you're welcome to
use gentoo's testing hardware if desired. Just email me an SSH key.)

[Bug target/109541] [12/13/14 regression] ICE in extract_constrain_insn on when building rhash-1.4.3

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #54880|0   |1
is obsolete||

--- Comment #11 from Eric Botcazou  ---
Created attachment 55227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55227=edit
Reduced testcase

[Bug target/109541] [12/13/14 regression] ICE in extract_constrain_insn on when building rhash-1.4.3

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

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

--- Comment #10 from Eric Botcazou  ---
> Sorry, I can not reproduce it on gcc-11, gcc-12, and master using -O1
> -mcpu=niagara4 -fpic -c a-sha512.i.

You need a properly configured cross-compiler, which means that you need to
build and install binutils first.  Then the most reduced testcase is the one
I'm going to attach:

eric@fomalhaut:~/build/gcc/sparc64-linux> gcc/xgcc -Bgcc -S a-sha512.c -O
-mcpu=niagara4 -fpic
a-sha512.c: In function 'rhash_sha512_process_block':
a-sha512.c:15:9: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   15 | F = (unsigned) 
  | ^
a-sha512.c:16:10: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   16 | T1 = (unsigned) ( + (W_3 += rhash_sha512_process_block_block > 9
> W_4));
  |  ^
a-sha512.c:17:9: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   17 | C = (unsigned) (T1 + );
  | ^
a-sha512.c:20:1: error: insn does not satisfy its constraints:
   20 | }
  | ^
(insn 8 107 9 2 (set (reg/f:DI 3 %g3 [165])
(mem/u/c:DI (plus:DI (reg:DI 3 %g3 [109])
(symbol_ref:DI ("rhash_sha512_process_block_i") )) [0  S8 A64])) "a-sha512.c":10:10
discrim 1 125 {*movdi_insn_sp64}
 (expr_list:REG_EQUIV (symbol_ref:DI ("rhash_sha512_process_block_i")
)
(nil)))
during RTL pass: reload
a-sha512.c:20:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x620dd7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/eric/cvs/gcc/gcc/rtl-error.cc:108
0x620e63 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/eric/cvs/gcc/gcc/rtl-error.cc:118
0xd3dadd extract_constrain_insn(rtx_insn*)
/home/eric/cvs/gcc/gcc/recog.cc:2692
0xbb9c37 check_rtl
/home/eric/cvs/gcc/gcc/lra.cc:2126
0xbc08db lra(_IO_FILE*)
/home/eric/cvs/gcc/gcc/lra.cc:2544
0xb5d889 do_reload
/home/eric/cvs/gcc/gcc/ira.cc:5967
0xb5d889 execute
/home/eric/cvs/gcc/gcc/ira.cc:6153

> Fortunately, I can reproduce
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703.  So I'll start on
> PR108703 first.

This one is pathological though, so of a lower priority IMO.

[Bug c++/110065] [11/12/13/14 Regression] [C++20/2b] auto in template argument causes ICE, also accepts-invalid

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.3.0, 12.1.0
Summary|[C++20/2b] auto in template |[11/12/13/14 Regression]
   |argument causes ICE, also   |[C++20/2b] auto in template
   |accepts-invalid |argument causes ICE, also
   ||accepts-invalid
  Known to work||11.1.0, 11.2.0
   Target Milestone|--- |12.4

[Bug target/108703] insn does not satisfy its constraints: movhi_insn at -O1

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

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Vladimir Makarov  ---
Here is my analysis of the problem/

Before IRA we already have:

(insn 10 7 11 2 (set (reg:HI 33 %f1)
(reg:HI 35 %f3)) "/home/vmakarov/testcase.c":8:3 114 {*movhi_insn}
 (expr_list:REG_EQUAL (const_int 13107 [0x])
(nil)))

LRA considers the insn is correct and does not check constraints as it
is simple move and its cost is 2.  This is standard convention for ignoring
constraints since the very early versions of reload pass.  And as I remember,
it is described somewhere in GCC documentation.

I think we should avoid to generate such insn from the start because
ignoring the reload convention will result in many unexpected
consequences where LRA speed slowdown probably would be a minor negative
consequence.

[Bug c++/110065] auto in template argument causes ICE, also accepts-invalid

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-31
   Keywords||accepts-invalid,
   ||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
template 
inline constexpr bool t = false;

int main()
{
return t auto&>;
}
```
If we `s/return//` we get the accept invalid too.

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2018-12-19 00:00:00 |2023-5-31
 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
I'm testing the following patch:

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 1de2b231242..2162b62608a 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -3366,6 +3372,7 @@ close_brackets:
   else
gfc_error ("Missing right parenthesis at %C");
   m = MATCH_ERROR;
+  goto no_match;
 }
   else
  /* All tests passed.  */
@@ -4716,6 +4723,9 @@ get_kind:
   return MATCH_ERROR;
 }

+  if (m == MATCH_ERROR)
+return MATCH_ERROR;
+
   /* Defer association of the KIND expression of function results
  until after USE and IMPORT statements.  */
   if ((gfc_current_state () == COMP_NONE && gfc_error_flag_test ())

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #16 from Jason Merrill  ---
(In reply to Jason Merrill from comment #15)
> Discussion in CWG led to this more specific rule that only affects the
> copy/move special member functions, and so doesn't affect the 84849
> testcases:

Correction: it does fix the first three 84849 testcases, which are non-template
forms of the same issue.

[Bug target/109541] [12/13/14 regression] ICE in extract_constrain_insn on when building rhash-1.4.3

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

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for it.
> 
> Vladimir, would it be feasible to prevent this from happening?

Sorry, I can not reproduce it on gcc-11, gcc-12, and master using -O1
-mcpu=niagara4 -fpic -c a-sha512.i.

Fortunately, I can reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703.  So I'll start on PR108703
first.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
I cannot reproduce that with glibc 2.37 and binutils 2.40 on openSUSE.  I've
also tried with -profile which links against -lc_p, no issue either.

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

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|Ambiguous resolution of |[DR1228] Ambiguous
   |braze initializer list to a |resolution of braze
   |class with explicit |initializer list to a class
   |constructors|with explicit constructors
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=cwg1228
 Status|ASSIGNED|SUSPENDED
   Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 CC||jason at gcc dot gnu.org

--- Comment #9 from Jason Merrill  ---
I'm not marking this as a dup of PR60027 because of the specific case of
copy/move constructors, which cannot be constrained to avoid this problem.  The
patch in PR109247 fixes the first three testcases, which fall into that
category, but not the testcase in #5, which does not.

The testcase in #6 is unrelated; there is no "explicit".

Unassigning from Marek.

[Bug target/110066] [RISC-V] Segment fault if compiled with -static -pg

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||riscv64-unknown-linux-gnu

--- Comment #1 from Andrew Pinski  ---
This also could be a glibc issue.

[Bug driver/93019] memory leak in gcc -O2 reported by Valgrind

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> I think this is known for the driver and we're too lazy to fix

For the driver, it is not much a deal but since JIT uses the driver code also,
it becomes an issue.

[Bug driver/93019] memory leak in gcc -O2 reported by Valgrind

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-31
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||memory-hog

--- Comment #3 from Andrew Pinski  ---
Confirmed via the dup.

[Bug target/110066] New: [RISC-V] Segment fault if compiled with -static -pg

[i at rvalue dot moe via Gcc-bugs]

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

Bug ID: 110066
   Summary: [RISC-V] Segment fault if compiled with -static -pg
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at rvalue dot moe
  Target Milestone: ---

When compile the code with option -static and -pg, the compiled program will
fail with segfault before entering main().

Reproduce:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-linux-gnu/13.1.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-multilib --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230429 (GCC)
$ cat > test.c
int main(){}
$ gcc test.c -o test -static -pg
$ ./test
Segmentation fault (core dumped)

gdb backtrace:
#0 classify_object_over_fdes ()
#1 __register_frame_info ()
#2 frame_dummy ()
#3 __libc_start_main_impl ()
#4 _start ()

[Bug driver/93019] memory leak in gcc -O2 reported by Valgrind

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eliaz.pitavy at obspm dot fr

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

[Bug jit/110063] Leaks from gcc driver accumulate when calling gcc_jit_context_compile

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #31 from Jonathan Wakely  ---
Using openlibm should work now.

I'm inclined to close this as WONTFIX, since the problem is in djgpp.

I don't think it's worth doing more work here. If there is interest in making
 work better for djgpp then improving djgpp's  would be the
place to start.

[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP

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

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

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

https://gcc.gnu.org/g:49f59826c66bcaa3531429381b4aed944c332e5b

commit r14-1454-g49f59826c66bcaa3531429381b4aed944c332e5b
Author: Jonathan Wakely 
Date:   Wed May 31 12:22:06 2023 +0100

libstdc++: Add separate autoconf macro for std::float_t and std::double_t
[PR109818]

This should make it possible to use openlibm with djgpp (and other
targets with missing C99  functions). The  from openlibm
provides all the functions, but not the float_t and double_t typedefs.
By separating the autoconf checks for the functionsand the typedefs, we
don't disable support for all the functions just because those typedefs
are not present.

libstdc++-v3/ChangeLog:

PR libstdc++/109818
* acinclude.m4 (GLIBCXX_ENABLE_C99): Add separate check for
float_t and double_t and define HAVE_C99_FLT_EVAL_TYPES.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/c_global/cmath (float_t, double_t): Guard using new
_GLIBCXX_HAVE_C99_FLT_EVAL_TYPES macro.

[Bug libstdc++/109921] c++17/floating_from_chars.cc: compile error: ‘from_chars_strtod’ was not declared in this scope

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

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

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

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

commit r14-1451-ga239a35075ffd8b34f1db72c22998a625ff962b5
Author: Jonathan Wakely 
Date:   Wed May 31 18:01:13 2023 +0100

libstdc++: Fix build for targets without _Float128 [PR109921]

My r14-1431-g7037e7b6e4ac41 change caused the _Float128 overload to be
compiled unconditionally, by moving the USE_STRTOF128_FOR_FROM_CHARS
check into the function body. That function should still only be
compiled if the target actually supports _Float128.

libstdc++-v3/ChangeLog:

PR libstdc++/109921
* src/c++17/floating_from_chars.cc: Check __FLT128_MANT_DIG__ is
defined before trying to use _Float128.

[Bug c++/60027] [DR1228] Problem with braced-init-lists and explicit ctors

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||dmatthews at utexas dot edu

--- Comment #9 from Jason Merrill  ---
*** Bug 109864 has been marked as a duplicate of this bug. ***

[Bug c++/109864] explicit constructor considered during overload resolution leads to ambiguity

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Dup.

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

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

--- Comment #17 from Mikael Morin  ---
(In reply to anlauf from comment #16)
> (In reply to Paul Thomas from comment #15)
> > Created attachment 55225 [details]
> > Fix for this PR
> > 
> > The attached patch substantially tidies up parse_associate and fixes:
> 
> LGTM!
> 
Yes, nice work.  I didn't expect such a simple fix.

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Jason Merrill  changed:

   What|Removed |Added

  Attachment #54739|0   |1
is obsolete||

--- Comment #15 from Jason Merrill  ---
Created attachment 55226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55226=edit
more targeted patch

Discussion in CWG led to this more specific rule that only affects the
copy/move special member functions, and so doesn't affect the 84849 testcases:

[Bug ipa/109983] [12/13 regression] Wireshark compilation hangs with -O2 -fipa-pta

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

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

--- Comment #16 from Sam James  ---
(In reply to Richard Biener from comment #9)
> My suggestion is to not enable -fipa-pta if you hit such issue or in general
> if you don't know it pays off with a good runtime performance boost.

Many thanks richi. I've been telling people this informally but I'll try to
make it a bit clearer somewhere as well. We don't recommend using -fipa-pta but
some adventurous users pick it up.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #15)
> Created attachment 55225 [details]
> Fix for this PR
> 
> The attached patch substantially tidies up parse_associate and fixes:

LGTM!

I was close to proposing a hack for gfc_expression_rank that checks
whether the variable's select_type_temporary, select_rank_temporary and
associate_var attributes to decide which ref to evaluate.  But your
patch seems to be a much better approach.

BTW: after your patch, the attribute assoc->rankguessed is no longer set.
It is tested in two locations in resolve_assoc_var(resolve.cc), where
it might be removed after your fix.

[Bug middle-end/110052] useless local variable not optimized away

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

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

--- Comment #4 from Bernhard Reutner-Fischer  ---
(In reply to Bernhard Reutner-Fischer from comment #3)
> Note that in this particular case myrealloc() is static, maybe i should have
> omitted the noipa attribute for it was only meant to simplify analysis and
> there is no such attribute in the original code.
> Furthermore, i would have hoped that given the placement of the definition
> of myrealloc() before the typedef foo_t, it should be unlikely that the
> usage of *foo would invalidate such an optimisation _in this particular
> case_. While the original code unfortunately does not mark *foo as restrict,
> adding restrict would hopefully make it clear that myrealloc() has no
> business in comparing foo's struct members, i'd hope?
> 
> When i drop the noipa attribute in the v1 testcase to make it similar to the
> motivating case, i get:

Correction: When i replace noipa with noinline,noclone (and drop
-ffunction-sections -fdata-sections to improve readability), i get:
10: 003052 FUNCGLOBAL DEFAULT1 bloat
10: 003021 FUNCGLOBAL DEFAULT1 ok

0030 :
  30:   53  push   %rbx
  31:   48 89 fbmov%rdi,%rbx
  34:   48 83 ec 10 sub$0x10,%rsp
  38:   8b 47 14mov0x14(%rdi),%eax
  3b:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
  40:   89 44 24 0c mov%eax,0xc(%rsp)
  44:   75 11   jne57 
  46:   48 8d 54 24 0c  lea0xc(%rsp),%rdx
  4b:   be 00 01 00 00  mov$0x100,%esi
  50:   31 ff   xor%edi,%edi
  52:   e8 a9 ff ff ff  callq  0 
  57:   8b 44 24 0c mov0xc(%rsp),%eax
  5b:   89 43 14mov%eax,0x14(%rbx)
  5e:   48 83 c4 10 add$0x10,%rsp
  62:   5b  pop%rbx
  63:   c3  retq   

0030 :
  30:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
  35:   75 0d   jne44 
  37:   48 8d 57 14 lea0x14(%rdi),%rdx
  3b:   be 00 01 00 00  mov$0x100,%esi
  40:   31 ff   xor%edi,%edi
  42:   eb bc   jmp0 
  44:   c3  retq

[Bug c++/110065] New: auto in template argument causes ICE, also accepts-invalid

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

Bug ID: 110065
   Summary: auto in template argument causes ICE, also
accepts-invalid
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following program produces internal compiler error: Segmentation fault.
Tested on GCC-trunk

To quickly reproduce: https://gcc.godbolt.org/z/noY1qxK91
```
#include 
#include 
auto main() -> int
{
std::cout << std::is_scoped_enum_v auto&>;
return EXIT_SUCCESS;
}
```

Note, if we remove the std::cout and produce the following code:
```
#include 
#include 
auto main() -> int
{
std::is_scoped_enum_v auto&>;
return EXIT_SUCCESS;
}
```
gcc compiles without any error, however this code is rejected by Clang (tested
on Clang-trunk)

[Bug middle-end/110052] useless local variable not optimized away

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

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

--- Comment #3 from Bernhard Reutner-Fischer  ---
Note that in this particular case myrealloc() is static, maybe i should have
omitted the noipa attribute for it was only meant to simplify analysis and
there is no such attribute in the original code.
Furthermore, i would have hoped that given the placement of the definition of
myrealloc() before the typedef foo_t, it should be unlikely that the usage of
*foo would invalidate such an optimisation _in this particular case_. While the
original code unfortunately does not mark *foo as restrict, adding restrict
would hopefully make it clear that myrealloc() has no business in comparing
foo's struct members, i'd hope?

When i drop the noipa attribute in the v1 testcase to make it similar to the
motivating case, i get:
9: 44 FUNCGLOBAL DEFAULT4 bloat
   12: 38 FUNCGLOBAL DEFAULT6 ok


 :
   0:   53  push   %rbx
   1:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
   6:   48 89 fbmov%rdi,%rbx
   9:   8b 47 14mov0x14(%rdi),%eax
   c:   75 19   jne27 
   e:   bf d0 01 00 00  mov$0x1d0,%edi
  13:   e8 00 00 00 00  callq  18 
  18:   48 85 c0test   %rax,%rax
  1b:   75 05   jne22 
  1d:   e8 00 00 00 00  callq  22 
  22:   b8 d0 01 00 00  mov$0x1d0,%eax
  27:   89 43 14mov%eax,0x14(%rbx)
  2a:   5b  pop%rbx
  2b:   c3  retq   

Disassembly of section .text.ok:

 :
   0:   48 83 7f 08 00  cmpq   $0x0,0x8(%rdi)
   5:   75 1e   jne25 
   7:   52  push   %rdx
   8:   c7 47 14 d0 01 00 00movl   $0x1d0,0x14(%rdi)
   f:   bf d0 01 00 00  mov$0x1d0,%edi
  14:   e8 00 00 00 00  callq  19 
  19:   48 85 c0test   %rax,%rax
  1c:   75 05   jne23 
  1e:   e8 00 00 00 00  callq  23 
  23:   58  pop%rax
  24:   c3  retq   
  25:   c3  retq

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

[nikolasklauser at berlin dot de via Gcc-bugs]

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

--- Comment #12 from Nikolas Klauser  ---
(In reply to Jonathan Wakely from comment #10)
> Using always_inline on everything is simply wrong: GCC will refuse to inline
> some functions and the user gets an error that they cannot avoid. There's no
> command-line option or pragma that can be used to compile the code anyway,
> it's just un-compilable.
Yes, that is one of the many problems with `always_inline` which we want to
avoid.
> I don't really understand the aim here. You're trying to avoid the user's
> program ever containing a symbol generated from any libc++ code? So that
> they can't ever have a dependency on those symbols, and the definitions can
> change?
Depends on what you mean by "never have a dependency on those symbols". It's
fine to emit the symbol and link against it, as long as every TU that relies on
it will also have a weak definition.
> Honestly, the cure seems worse than the disease.
> 
> Just because code is inlined, it doesn't mean it's immune from ABI
> incompatibilities (it avoids some kinds of problems, but doesn't help with
> others).
Could you elaborate on the other problems?
> And if all libc++ functions have an abi_tag courtesy of the HIDE_FROM_ABI
> macro, why does it matter whether explicit instantiations include them
> anyway?
It becomes a problem when people try to have an explicit instantiation in a
shared library, since all the symbols also have visibility("hidden"). The
result are linker errors.
> Your include/__config says:
> 
> The symbol is given an ABI tag that changes with each version of libc++.
> This ensures
> that no ODR violation can arise from mixing two TUs compiled with different
> versions
> of libc++ where we would have changed the definition of a symbol. If the
> symbols shared
> the same name, the ODR would require that their definitions be
> token-by-token equivalent,
> which basically prevents us from being able to make any change to any
> function in our
> headers.
> 
> Again, the cure seems worse than the disease.
> 
> Your compiler and/or linker and/or dynamic loader can define what happens
> here, so the ODR violation doesn't lead to nasal demons. If your definitions
> are not token-by-token identical then what happens in practice is that you
> get two definitions emitted in different TUs and the linker picks one.
> There's no actual UB here. Applying this to every single function in the
> library just in case you want to change it some day seems like major
> overkill.
> 
> But on the topic of this enhancement request, I don't see why functions
> should be excluded from explicit instantiation if they're already
> abi-tagged. Do you want to be able to change these functions in
> ABI-incompatible ways between major revisions of the library?

(In reply to Jonathan Wakely from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Do you want to be able to change these functions in
> > ABI-incompatible ways between major revisions of the library?
> 
> Sorry, that was unclear, I meant to ask if you want to change them in
> ABI-incompatible ways without bumping the version in the abi_tag?
No. Being able to change the implementation in ABI-incompatible ways between
versions is the whole point of the tag.
> e.g. change std::__1::vector
> >::__clear[abi:v15007]() in an ABI-incompatible way, without changing the
> tag to [abi:v15008]?
> 
> Because if the tag is going to change anyway, what does it matter if the
> user has instantiations of the old [abi:v15007] symbol in their lib?
That's completely fine (and in fact the goal of adding
`exclude_from_explicit_instantiation`). The idea is that the library contains
the symbols it uses, and we can remove functions, change the ABI of functions,
or whatever else. Everything that a TU relies upon will be part of that TU.
When linking, the symbols will be deduplicated, and most people will have just
one version of a given function in their binary. If you ever have multiple
versions for whatever reason, it's fine because the ABI tags +
exclude_from_explicit_instantiation make sure the symbol exists somewhere and
has it's own name.

[Bug rtl-optimization/109930] transform atomic exchange to unconditional store when old value is unused?

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---
(In reply to Simon Richter from comment #3)
> I was looking at ARMv7 initially.
> 
> If I understood the implementation correctly, this can be a generic
> optimization.

This optimization is only valid for release or relaxed semantics, otherwise you
remove the acquire semantics of the exchange (without proof this is 100% safe,
this will likely allow an illegal reordering).

Btw if you know the old state then there is presumably no concurrent access
here and so you don't need atomic, let alone sequential consistency.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #15 from Paul Thomas  ---
Created attachment 55225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55225=edit
Fix for this PR

The attached patch substantially tidies up parse_associate and fixes:

! { dg-do run }
!
! Tests the fix for PR109948
!
module mm
  implicit none
  interface operator(==)
module procedure eq_1_2
  end interface operator(==)
  private :: eq_1_2
contains
  logical function eq_1_2 (x, y)
integer, intent(in) :: x(:)
real,intent(in) :: y(:,:)
eq_1_2 = .true.
  end function eq_1_2
end module mm

program pr109948
  use mm
  implicit none
  type tlap
integer,allocatable :: z(:)
  end type tlap
  type ulap
type(tlap) :: u(2)
  end type ulap
  integer :: pid = 1
  call comment0 ! Original problem
  call comment1
  call comment3 ([5,4,3,2,1])
  call comment10
  call comment11 ([5,4,3,2,1])
contains
  subroutine comment0
type(tlap) :: y_in
integer :: x_out(3) =[0.0,0.0,0.0]
y_in%z = [1,-2,3]
call foo(y_in, x_out)
if (any (x_out .ne. [0, -2, 0])) stop 1
call foo(y_in, x_out)
if (any (x_out .ne. [1, -2, 3])) stop 2
  end subroutine comment0

  subroutine foo(y, x)
type(tlap) :: y
integer :: x(:)
associate(z=>y%z)
  if (pid == 1) then
where ( z < 0 ) x(:) = z(:)
  else
where ( z > 0 ) x(:) = z(:)
endif
pid = pid + 1
end associate
  end subroutine foo

  subroutine comment1
type(tlap) :: grib
integer :: i
grib%z = [3,2,1]
associate(k=>grib%z)
  i = k(1)
  if (any(k==1)) i = 1
end associate
if (i .eq. 3) stop 3
  end subroutine comment1

  subroutine comment3(k_2d)
implicit none
integer :: k_2d(:)
integer :: i
associate(k=>k_2d)
  i = k(1)
  if (any(k==1)) i = 1
end associate
if (i .eq. 3) stop 4
  end subroutine comment3

  subroutine comment11(k_2d)
implicit none
integer :: k_2d(:)
integer :: m(1) = 42
real:: r(1,1) = 3.0
if ((m == r) .neqv. .true.) stop 5
associate (k=>k_2d)
  if ((k == r) .neqv. .true.) stop 6  ! failed to find user defined
operator
end associate
associate (k=>k_2d(:))
  if ((k == r) .neqv. .true.) stop 7
end associate
  end subroutine comment11

  subroutine comment10
implicit none
type(ulap) :: z(2)
integer :: i
real:: r(1,1) = 3.0
z(1)%u = [tlap([1,2,3]),tlap([4,5,6])]
z(2)%u = [tlap([7,8,9]),tlap([10,11,12])]
associate (k=>z(2)%u(1)%z)
  i = k(1)
  if (any(k==8)) i = 1
end associate
if (i .ne. 1) stop 8
associate (k=>z(1)%u(2)%z)
  if ((k == r) .neqv. .true.) stop 9
  if (any (k .ne. [4,5,6])) stop 10
end associate
  end subroutine comment10
end program pr109948

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #10)
> Do you want to be able to change these functions in
> ABI-incompatible ways between major revisions of the library?

Sorry, that was unclear, I meant to ask if you want to change them in
ABI-incompatible ways without bumping the version in the abi_tag?

e.g. change std::__1::vector
>::__clear[abi:v15007]() in an ABI-incompatible way, without changing the tag
to [abi:v15008]?

Because if the tag is going to change anyway, what does it matter if the user
has instantiations of the old [abi:v15007] symbol in their lib?

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

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

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

--- Comment #14 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #13)
> The only difference between slp vectorization is:
> 
> -  # _68 = PHI <_5(3)>
> -  # _67 = PHI <_11(3)>
> -  # _66 = PHI <_16(3)>
> -  .r = _68;
> -  .g = _67;
> -  .b = _66;
> +  # _70 = PHI <_5(3)>
> +  # _69 = PHI <_11(3)>
> +  # _68 = PHI <_16(3)>
> +  .r = _70;
> +  .g = _69;
> +  .b = _68;
> +  .o = r$o_33(D);
> 
> so SRA invents r$o_33(D) even if that variable is undefined.

Is this the testcase from comment #10 ?  I don't see r$o in my dumps.

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #10 from Jonathan Wakely  ---
Using always_inline on everything is simply wrong: GCC will refuse to inline
some functions and the user gets an error that they cannot avoid. There's no
command-line option or pragma that can be used to compile the code anyway, it's
just un-compilable.

I don't really understand the aim here. You're trying to avoid the user's
program ever containing a symbol generated from any libc++ code? So that they
can't ever have a dependency on those symbols, and the definitions can change?

Honestly, the cure seems worse than the disease.

Just because code is inlined, it doesn't mean it's immune from ABI
incompatibilities (it avoids some kinds of problems, but doesn't help with
others).

And if all libc++ functions have an abi_tag courtesy of the HIDE_FROM_ABI
macro, why does it matter whether explicit instantiations include them anyway?

Your include/__config says:

The symbol is given an ABI tag that changes with each version of libc++. This
ensures
that no ODR violation can arise from mixing two TUs compiled with different
versions
of libc++ where we would have changed the definition of a symbol. If the
symbols shared
the same name, the ODR would require that their definitions be token-by-token
equivalent,
which basically prevents us from being able to make any change to any function
in our
headers.

Again, the cure seems worse than the disease.

Your compiler and/or linker and/or dynamic loader can define what happens here,
so the ODR violation doesn't lead to nasal demons. If your definitions are not
token-by-token identical then what happens in practice is that you get two
definitions emitted in different TUs and the linker picks one. There's no
actual UB here. Applying this to every single function in the library just in
case you want to change it some day seems like major overkill.

But on the topic of this enhancement request, I don't see why functions should
be excluded from explicit instantiation if they're already abi-tagged. Do you
want to be able to change these functions in ABI-incompatible ways between
major revisions of the library?

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

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

commit r14-1448-gd0c064c3eabc75cf83df296ebcd1db19b4a68851
Author: Kyrylo Tkachov 
Date:   Wed May 31 17:46:19 2023 +0100

aarch64: PR target/99195 Annotate dot-product patterns for vec-concat-zero

This straightforward patch annotates the dotproduct instructions, including
the i8mm ones.
Tests included.
Nothing unexpected here.

Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.

gcc/ChangeLog:

PR target/99195
* config/aarch64/aarch64-simd.md (dot_prod): Rename
to...
(dot_prod): ... This.
(usdot_prod): Rename to...
(usdot_prod): ... This.
(aarch64_dot_lane): Rename to...
(aarch64_dot_lane): ... This.
(aarch64_dot_laneq): Rename to...
(aarch64_dot_laneq): ... This.
(aarch64_dot_lane):
Rename to...
   
(aarch64_dot_lane):
... This.

gcc/testsuite/ChangeLog:

PR target/99195
* gcc.target/aarch64/simd/pr99195_11.c: New test.

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

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

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:547d3bce0c02dbcbb6f62d9469a71eedf17bd688

commit r14-1447-g547d3bce0c02dbcbb6f62d9469a71eedf17bd688
Author: Kyrylo Tkachov 
Date:   Wed May 31 17:43:20 2023 +0100

aarch64: PR target/99195 Annotate saturating mult patterns for
vec-concat-zero

This patch goes through the various alphabet soup saturating multiplication
patterns, including those in TARGET_RDMA
and annotates them with . Many other patterns are widening
and always write the full 128-bit vectors
so this annotation doesn't apply to them. Nothing out of the ordinary in
this patch.

Bootstrapped and tested on aarch64-none-linux and aarch64_be-none-elf.

gcc/ChangeLog:

PR target/99195
* config/aarch64/aarch64-simd.md (aarch64_sqdmulh): Rename
to...
(aarch64_sqdmulh): ... This.
(aarch64_sqdmulh_n): Rename to...
(aarch64_sqdmulh_n): ... This.
(aarch64_sqdmulh_lane): Rename to...
(aarch64_sqdmulh_lane): ... This.
(aarch64_sqdmulh_laneq): Rename to...
(aarch64_sqdmulh_laneq): ... This.
(aarch64_sqrdmlh): Rename to...
(aarch64_sqrdmlh): ...
This.
(aarch64_sqrdmlh_lane): Rename to...
(aarch64_sqrdmlh_lane): ...
This.
(aarch64_sqrdmlh_laneq): Rename to...
(aarch64_sqrdmlh_laneq):
... This.

gcc/testsuite/ChangeLog:

PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add tests for qdmulh,
qrdmulh.
* gcc.target/aarch64/simd/pr99195_10.c: New test.

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rguenther at suse dot de
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110062

--- Comment #13 from Jan Hubicka  ---
The only difference between slp vectorization is:

-  # _68 = PHI <_5(3)>
-  # _67 = PHI <_11(3)>
-  # _66 = PHI <_16(3)>
-  .r = _68;
-  .g = _67;
-  .b = _66;
+  # _70 = PHI <_5(3)>
+  # _69 = PHI <_11(3)>
+  # _68 = PHI <_16(3)>
+  .r = _70;
+  .g = _69;
+  .b = _68;
+  .o = r$o_33(D);

so SRA invents r$o_33(D) even if that variable is undefined.

SLP vectorizer then sees it as interleaving stores:

-t.c:19:16: note:   _1 = rgbs[i_35].r;
-t.c:19:16: note:   _7 = rgbs[i_35].g;
-t.c:19:16: note:   _12 = rgbs[i_35].b;
-t.c:19:16: note:   Detected interleaving store of size 3
-t.c:19:16: note:   .r = _68;
-t.c:19:16: note:   .g = _67;
-t.c:19:16: note:   .b = _66;
+t.c:19:16: note:   _1 = rgbs[i_37].r;
+t.c:19:16: note:   _7 = rgbs[i_37].g;
+t.c:19:16: note:   _12 = rgbs[i_37].b;
+t.c:19:16: note:   Detected interleaving store of size 4
+t.c:19:16: note:   .r = _70;
+t.c:19:16: note:   .g = _69;
+t.c:19:16: note:   .b = _68;
+t.c:19:16: note:   .o = r$o_33(D);

For first case it first tries to vectorize for vector of 3 doubles and fails:

-t.c:19:16: note: .r = _68;
-t.c:19:16: note: .g = _67;
-t.c:19:16: note: .b = _66;
-t.c:19:16: note:   starting SLP discovery for node 0x2cb4fe8
-t.c:19:16: note:   Build SLP for .r = _68;
-t.c:19:16: note:   get vectype for scalar type (group size 3): double
-t.c:19:16: note:   vectype: vector(2) double
-t.c:19:16: note:   nunits = 2
-t.c:19:16: missed:   Build SLP failed: unrolling required in basic block SLP
-t.c:19:16: note:   Build SLP for .g = _67;
-t.c:19:16: note:   get vectype for scalar type (group size 3): double
-t.c:19:16: note:   vectype: vector(2) double
-t.c:19:16: note:   nunits = 2
-t.c:19:16: missed:   Build SLP failed: unrolling required in basic block SLP
-t.c:19:16: note:   Build SLP for .b = _66;
-t.c:19:16: note:   get vectype for scalar type (group size 3): double
-t.c:19:16: note:   vectype: vector(2) double
-t.c:19:16: note:   nunits = 2
-t.c:19:16: missed:   Build SLP failed: unrolling required in basic block SLP
-t.c:19:16: note:   SLP discovery for node 0x2cb4fe8 failed

And later it tries to vectorize first 2 items:

-t.c:19:16: note:   Splitting SLP group at stmt 2
-t.c:19:16: note:   Split group into 2 and 1
-t.c:19:16: note:   Starting SLP discovery for
-t.c:19:16: note: .r = _68;
-t.c:19:16: note: .g = _67;
-t.c:19:16

... and after a lot of blablabla succeeds.

If opaque field is present we start with vector of size 4:
+t.c:19:16: note: .r = _70;
+t.c:19:16: note: .g = _69;
+t.c:19:16: note: .b = _68;
+t.c:19:16: note: .o = r$o_33(D);


+t.c:19:16: note:   vect_is_simple_use: operand _70 = PHI <_5(3)>, type of def:
internal
+t.c:19:16: note:   vect_is_simple_use: operand _69 = PHI <_11(3)>, type of
def: internal
+t.c:19:16: note:   vect_is_simple_use: operand _68 = PHI <_16(3)>, type of
def: internal
+t.c:19:16: note:   vect_is_simple_use: operand r$o_33(D), type of def:
external
+t.c:19:16: missed:   treating operand as external
+t.c:19:16: note:   SLP discovery for node 0x2e80058 succeeded
+t.c:19:16: note:   SLP size 1 vs. limit 23.
+t.c:19:16: note:   Final SLP tree for instance 0x2def840:
+t.c:19:16: note:   node 0x2e80058 (max_nunits=4, refcnt=2) vector(4) double
+t.c:19:16: note:   op template: .r = _70;
+t.c:19:16: note:   stmt 0 .r = _70;
+t.c:19:16: note:   stmt 1 .g = _69;
+t.c:19:16: note:   stmt 2 .b = _68;
+t.c:19:16: note:   stmt 3 .o = r$o_33(D);
+t.c:19:16: note:   children 0x2e800d8
+t.c:19:16: note:   node (external) 0x2e800d8 (max_nunits=1, refcnt=1)
+t.c:19:16: note:   { _70, _69, _68, r$o_33(D) }

So it seems to succeed vectorizing with 4 entries but it does so for the single
return statement:

   [local count: 1063004409]:
  # i_37 = PHI 
  # r$r_40 = PHI <_5(5), r$r_25(D)(2)>
  # r$g_42 = PHI <_11(5), r$g_26(D)(2)>
  # r$b_44 = PHI <_16(5), r$b_27(D)(2)>
  # ivtmp_67 = PHI 
  _1 = rgbs[i_37].r;
  _2 = (int) _1;
  _3 = (double) _2;
  _4 = _3 * w_21(D);
  _5 = _4 + r$r_40;
  _7 = rgbs[i_37].g;
  _8 = (int) _7;
  _9 = (double) _8;
  _10 = _9 * w_21(D);
  _11 = _10 + r$g_42;
  _12 = rgbs[i_37].b;
  _13 = (int) _12;
  _14 = (double) _13;
  _15 = _14 * w_21(D);
  _16 = _15 + r$b_44;
  i_22 = i_37 + 1;
  ivtmp_66 = ivtmp_67 - 1;
  if (ivtmp_66 != 0)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 1052374367]:
  goto ; [100.00%]

   [local count: 10737416]:
  # _70 = PHI <_5(3)>
  # _69 = PHI <_11(3)>
  # _68 = PHI <_16(3)>
  _65 = 

[Bug c++/92707] type alias on type alias on lambda in unevaluated context does not work

[f.heckenbach--- via Gcc-bugs]

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

Frank Heckenbach  changed:

   What|Removed |Added

 CC||f.heckenb...@fh-soft.de

--- Comment #1 from Frank Heckenbach  ---
Probably the same bug in a slightly different form:

% cat test.cpp
template  struct S { };
template  using A = S ;
template  using B = A ;
B <0> a;
% g++ -std=c++20 -Wall -Wextra test.cpp
test.cpp:4:1: error: 'B' does not name a type
4 | B <0> a;
  | ^

It works when using A instead of B.
It works when using an alias for "decltype ([] { })".
Other compilers accept it as is.

Also, I find the message confusing (even if it was rightly rejected): Of
course, 'B' does not name a type. It's followed by template arguments, so 'B'
shouldn't be a type, but a template or template alias, or 'B <0>' should be a
type.

[Bug c++/110064] New: spurious missing initializer for member for anonymous

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 110064
   Summary: spurious missing initializer for member for anonymous
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This program (reduced from StackOverflow:
https://stackoverflow.com/q/76375145/2069064):

struct B { };
struct D : B {
int x;
int y;
};

int main(int, char**) {
D d = {.x=1, .y=2};
(void)d;
}

with -Wall -Wextra gives a warning on:

:8:22: warning: missing initializer for member 'D::'
[-Wmissing-field-initializers]
8 | D d = {.x=1, .y=2};
  |  

But there's... no member here that isn't initialized.

[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory

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

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

--- Comment #5 from Thomas Schwinge  ---
With the latter hunk applied (plus manual 'rm gcc/s-mlib gcc/multilib.h' to
regenerate the latter file), I find that this apparently does only address the
'--disable-multilib' case, but not my '--enable-multilib'?

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

[ldionne.2 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Louis Dionne  ---
(In reply to Andrew Pinski from comment #3)
> I am getting a feeling this attribute is well defined enough.
> 
> Is it really just supposed to block explicit instantiation of templates?
> Is there a decent set of testcases that can be used to match up the
> implementations here? Because I suspect without those it will be implemented
> slightly different.

Is there anything specific you're thinking about that would be insufficiently
defined? It's possible that that's the case, and if so then we can define it
properly and make sure Clang/GCC are aligned on the semantics.

This is quite a painful issue for libc++ on GCC since the current solution is
to use `always_inline`, which has too many downsides. It used to be just an
annoyance, but with the addition of libraries like `std::format`, using
`always_inline` leads to a library that is literally unusable in some cases
(compile times and code size just skyrockets). So yeah, we're much willing to
collaborate in order to make this work.

[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f

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

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

--- Comment #3 from Christophe Lyon  ---
So we have a different behavior in
libstdc++-v3/include/experimental/bits/simd_detail.h:
#if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__)
#define _GLIBCXX_SIMD_HAVE_NEON_A32 1
#else
#define _GLIBCXX_SIMD_HAVE_NEON_A32 0
#endif

[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
..., and then I wondered: but how, then, are Debian/Ubuntu building GCC?

Per ,
,
there is a 'debian/patches/gcc-multiarch.diff' file, which contains "Remaining
multiarch patches, not yet submitted upstream", which (amongst others)
includes:

--- a/src/gcc/config/riscv/t-linux
+++ b/src/gcc/config/riscv/t-linux
@@ -1,3 +1,5 @@
 # Only XLEN and ABI affect Linux multilib dir names, e.g. /lib32/ilp32d/
 MULTILIB_DIRNAMES := $(patsubst rv32%,lib32,$(patsubst
rv64%,lib64,$(MULTILIB_DIRNAMES)))
 MULTILIB_OSDIRNAMES := $(patsubst lib%,../lib%,$(MULTILIB_DIRNAMES))
+
+MULTIARCH_DIRNAME := $(call if_multiarch,$(firstword $(subst -,
,$(target)))-linux-gnu)

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

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

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

--- Comment #18 from Georg-Johann Lay  ---
(In reply to Francois-Xavier Coudert from comment #11)
> As far as I can say, the targets with this problem are: avr, bfin, h8300,
> picochip and sh (for some subtargets of sh).
> 
> On avr, bfin, h8300 and picochip, we're doomed anyway because there is no
> double-sized type at all. On sh, we could use long double math calls.
> 
> I'm making this into an enhancement; it will probably be very painful,
> because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and
> DOUBLE_TYPE_SIZE == 64.

At least for AVR, the situation changed with v10, see
https://gcc.gnu.org/gcc-10/changes.html#avr
https://gcc.gnu.org/install/configure.html#avr

In order to keep v10 compatible with older versions of avr-gcc, double still
defaults to 32 bits, though.  To get 64-bit double, you'll have to configure
using --with-double=64 (or use --with-double=64,32 so you can which to 32-bit
double with -mdouble=32 at compile-time).

The default for this option is --with-double=32,64; hence what's also possible
is to use default configuraton, but provide -mdouble=64 for every translation
unit.

FYI, the 64-bit double support is provided by LibF7, which is a part of
avr-libgcc.  For details and shortcomings, see
https://gcc.gnu.org/wiki/avr-gcc#Libf7
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgcc/config/avr/libf7

[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f

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

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

--- Comment #2 from Christophe Lyon  ---
Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but
fails when forcing -march=armv8-a

[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
Gah, I ran into the same issue on gcc92.

I 'configure'd '--with-arch=rv64imafdc --with-abi=lp64d --enable-multilib'.

(In reply to Andrew Pinski from comment #1)
> OR multi-arch support is not in the riscv backend yet.

That seems to be the case indeed; at least I'm not seeing any 'if_multiarch'
etc. in 'gcc/config/riscv/'.


$ find /usr/include/ -name libc-header-start.h
/usr/include/riscv64-linux-gnu/bits/libc-header-start.h

Also, do potentially further distribution packages have to be installed, for
additional multilibs?  Like I have on an Ubuntu x86_64 GN/Linux system:

$ find /usr/include/ -name libc-header-start.h
/usr/include/i386-linux-gnu/bits/libc-header-start.h
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h
$ dpkg -S /usr/include/i386-linux-gnu/bits/libc-header-start.h
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h
libc6-dev:i386: /usr/include/i386-linux-gnu/bits/libc-header-start.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #7 from Wilco  ---
I don't see the issue you have here. GCC for x86/x86_64 has been using compare
exchange for atomic load (which always does a write even if the compare fails)
for many years. LLVM does the same for AArch64/x86/x86_64.

If you believe this is incorrect/invalid, do you have any evidence this causes
crashes in real applications?

As a result of GCC's bad choice of using locking atomics on AArch64, many
applications are forced to implement 128-bit atomics themselves using hacky
inline assembler. Just one example for reference:

https://github.com/boostorg/atomic/blob/08bd4e20338c503d2acfdddfdaa8f5e0bcf9006c/include/boost/atomic/detail/core_arch_ops_gcc_aarch64.hpp#L1635

The question is, do you believe compilers should provide users with fast and
efficient atomics they need? Or do you want to force every application to
implement their own version of 128-bit atomics?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #6 from Andrew Pinski  ---
bug 70814 comment #3 explains why this should not be done. As I mentioned it
can be improved for armv8.4-a maybe using an ifunc but it cannot be done for
before that.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

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

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

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

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Still a dup. Reopen the old one instead if you think gcc should be broken for
loads.

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

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

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

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

--- Comment #10 from Jakub Jelinek  ---
And the reason for the helper functions is C++11 which would not like
temporaries in constexpr functions.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

Wilco  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-31
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80878
   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #4 from Wilco  ---
Reopened. Please don't close bugs without allowing for discussion first. I'll
send a patch soon that shows it's possible and valid.

And if there is a better solution that results in the same benefits (fast
lock-free atomics, allowing inlining and use of latest instructions without ABI
issues) then I would love to hear ideas and suggestions.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

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

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

--- Comment #9 from Jakub Jelinek  ---
Sorry, 0x1.0p-1016 * 0x1.0p-1016 * 0x1.0p-1016 obviously should have been
0x1.0p+1016 * 0x1.0p+1016 * 0x1.0p+1016, I tested it on a testcase where I used
different names etc.

[Bug target/110059] When SPEC is used to test the GCC (10.3.1), the test result of subitem 548 fluctuates abnormally.

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

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

--- Comment #4 from Jakub Jelinek  ---
I'd like to point out that doing performance testing for GCC 10 at this point
isn't a very good idea, GCC 10 is going out of support within a month or two,
and while some important wrong-code generation bugs can be still fixed there,
it is very unlikely any performance related bugs would be fixed there.  Of
course, if you find a performance problem with GCC 13 or even better trunk
compared to GCC 9 or older and then bisect it to a particular change, it is
helpful.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

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

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

--- Comment #8 from Jakub Jelinek  ---
Dunno.
I think you can add support even without any compiler changes, at least if
_GLIBCXX_DOUBLE_IS_IEEE_BINARY64:

#ifdef __STRICT_ANSI__
  static _GLIBCXX_CONSTEXPR __float128
  min() _GLIBCXX_USE_NOEXCEPT
  { return __extension__ 3.36210314311209350626267781732175260e-4932Q; }

  static _GLIBCXX_CONSTEXPR __float128
  max() _GLIBCXX_USE_NOEXCEPT
  { return __extension__ 1.18973149535723176508575932662800702e+4932Q; }

  static _GLIBCXX_CONSTEXPR __float128
  epsilon() _GLIBCXX_USE_NOEXCEPT
  { return __extension__ 1.92592994438723585305597794258492732e-34Q; }

  static _GLIBCXX_CONSTEXPR __float128
  denorm_min() _GLIBCXX_USE_NOEXCEPT
  { return __extension__ 6.47517511943802511092443895822764655e-4966Q; }
#else
  static _GLIBCXX_CONSTEXPR __float128
  _S_1pm4088 () _GLIBCXX_USE_NOEXCEPT
  { return __float128 (0x1.0p-1022) * 0x1.0p-1022 * 0x1.0p-1022 *
0x1.0p-1022; }

  static _GLIBCXX_CONSTEXPR __float128
  _S_1pm16352 () _GLIBCXX_USE_NOEXCEPT
  { return _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 (); }

  static _GLIBCXX_CONSTEXPR __float128
  _S_1p4064 () _GLIBCXX_USE_NOEXCEPT
  { return __float128 (0x1.0p+1016) * 0x1.0p-1016 * 0x1.0p-1016 *
0x1.0p-1016; }

  static _GLIBCXX_CONSTEXPR __float128
  _S_1p16256 () _GLIBCXX_USE_NOEXCEPT
  { return _S_1p4064 () * _S_1p4064 () * _S_1p4064 () * _S_1p4064 (); }

  static _GLIBCXX_CONSTEXPR __float128
  min() _GLIBCXX_USE_NOEXCEPT
  { return /* 0x1.0p-16382Q */ 0x1.0p-30 * _S_1pm16352 (); }

  static _GLIBCXX_CONSTEXPR __float128
  max() _GLIBCXX_USE_NOEXCEPT
  { return /* 0x1.p+16383Q */
   (__float128 (0x1.fp+127) + 0x0.fp+75
+ 0x0.ffp+23) * _S_1p16256 (); }

  static _GLIBCXX_CONSTEXPR __float128
  epsilon() _GLIBCXX_USE_NOEXCEPT
  { return 0x1.0p-112; }

  static _GLIBCXX_CONSTEXPR __float128
  denorm_min() _GLIBCXX_USE_NOEXCEPT
  { return /* 0x1.0p-16494Q */ 0x1.0p-142 * _S_1pm16352 (); }
#endif

Except that the FE errors in C++98/11/14 modes on the hexadecimal constants.
I guess one could replace them with decimal constants (except those in comments
of course), but better use explicit double(whatever) to make sure they aren't
evaluated in higher precision.  Anyway, I think the above computations should
(at least assuming the decimal constants map to those hexadecimal ones) always
be exact and so should produce such results in all rounding modes.

[Bug jit/110063] Leaks from gcc driver accumulate when calling gcc_jit_context_compile

[eliaz.pitavy at obspm dot fr via Gcc-bugs]

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

--- Comment #1 from Eliaz Pitavy  ---
Adding ctx.set_bool_option(GCC_JIT_BOOL_OPTION_SELFCHECK_GC, 1);
reduces the memory leak to 733302 bytes leaked in 5589 allocations.

Adding ctx.set_bool_use_external_driver(1);
reduces the memory leak to 171512 bytes leaked in 1191 allocations.

The combination of both lines end up to strongly reduce the leak to 49544 bytes
leaked in 894 allocations.

[Bug target/110059] When SPEC is used to test the GCC (10.3.1), the test result of subitem 548 fluctuates abnormally.

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
548.exchange2_r was improved in GCC 12 after PR98782 was fixed. I'd suggest you
try out a later version of GCC

[Bug target/110044] [10, 11, 12, 13, 14 Regression] #pragma pack(push, 1) may not force packing, while __attribute__((packed, aligned(1))) works

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

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

--- Comment #6 from Iain Sandoe  ---
I'm going to test the following (which will take some time since the hardware
is needed for testing releases too).

The test for AGGREGATE_TYPE_P() could actually be changed to
RECORD_OR_UNION_TYPE_P () - since the case that we might have an array is
handled for non-empty structs (but we do need to guard the empty struct case). 
The problem seems to be we were ignoring that the field type could be packed or
that there was a cap on the max alignment.

If it works as expected then I will apply to the open branches (hopefully
before 10.5 is spun).



diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 5b3b8b52e7e..e1c038da305 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -8209,7 +8209,8 @@ darwin_rs6000_special_round_type_align (tree type,
unsigned int computed,
   type = TREE_TYPE (type);
   } while (AGGREGATE_TYPE_P (type));

-  if (! AGGREGATE_TYPE_P (type) && type != error_mark_node)
+  if (type != error_mark_node && ! AGGREGATE_TYPE_P (type)
+  ! TYPE_PACKED(type) && maximum_field_alignment == 0)
 align = MAX (align, TYPE_ALIGN (type));

   return align;

[Bug c++/110055] Dangling pointer warning inside std::vector on RISC-V

[spriteovo at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Sprite  ---
Note that the error is raised only on the second and subsequent variables, the
first variable works fine.

[Bug target/110039] [14 Regression] FAIL: gcc.target/aarch64/rev16_2.c scan-assembler-times rev16\\tw[0-9]+ 2

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #3 from Christophe Lyon  ---
Fixed.

[Bug target/110039] [14 Regression] FAIL: gcc.target/aarch64/rev16_2.c scan-assembler-times rev16\\tw[0-9]+ 2

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:070d651c6db37c3658be0a5274f44265045428e6

commit r14-1437-g070d651c6db37c3658be0a5274f44265045428e6
Author: Christophe Lyon 
Date:   Wed May 31 09:23:16 2023 +

aarch64: Add pattern for bswap + rotate [PR 110039]

After commit g:d8545fb2c71683f407bfd96706103297d4d6e27b, we missed a
pattern to match the new GIMPLE form.

With this patch, gcc.target/aarch64/rev16_2.c passes again.

2023-05-31  Christophe Lyon  

PR target/110039
gcc/
* config/aarch64/aarch64.md (aarch64_rev16si2_alt3): New
pattern.

[Bug target/108659] Suboptimal 128 bit atomics codegen x64

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Suboptimal 128 bit atomics  |Suboptimal 128 bit atomics
   |codegen on AArch64 and x64  |codegen x64
 Target|aarch64 x86_64  |x86_64
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70814

--- Comment #12 from Andrew Pinski  ---
aarch64 was recorded in PR 70814 before.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

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

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 70814. Basically 128bit atomics CANNOT be lock free with ARMv8-a.

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

[Bug jit/110063] New: Leaks in gcc driver accumulate when calling gcc_jit_context_compile

[eliaz.pitavy at obspm dot fr via Gcc-bugs]

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

Bug ID: 110063
   Summary: Leaks in gcc driver accumulate when calling
gcc_jit_context_compile
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eliaz.pitavy at obspm dot fr
  Target Milestone: ---

Created attachment 55224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55224=edit
Full output of ASan with -fsanitize=address

Local build of gcc 13.1.0
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-13.1.0/configure --prefix=/home/epitavy/.local/
--disable-multilib --enable-host-shared --enable-languages=all

The following code is compiled with these options:
g++ --std=c++2a -fsanitize=address -I ~/.local leak.cc -lgccjit -L ~/.local -o
leak

The content of the file (leak.cc):
#include 

int main(){
gccjit::context ctx = gccjit::context::acquire();
gcc_jit_result *result;

for (int i = 0; i < 100; i++) {
result = ctx.compile();
gcc_jit_result_release(result);
}

ctx.release();
}


Here a truncated ASan report, the full report is in attachment:
SUMMARY: AddressSanitizer: 855270 byte(s) leaked in 5886 allocation(s)
   xmalloc ../../gcc-13.1.0/libiberty/xmalloc.c:149
   make_temp_file_with_prefix ../../gcc-13.1.0/libiberty/make-temp-file.c:213
   ...
   handle_braces ../../gcc-13.1.0/gcc/gcc.cc:7252
   do_spec_1 ../../gcc-13.1.0/gcc/gcc.cc:6659
   do_spec_2 ../../gcc-13.1.0/gcc/gcc.cc:5713
   do_spec(char const*) ../../gcc-13.1.0/gcc/gcc.cc:5677
   driver::do_spec_on_infiles() const ../../gcc-13.1.0/gcc/gcc.cc:8903
   driver::main(int, char**) ../../gcc-13.1.0/gcc/gcc.cc:8131

When using gcc as a standalone program, the memory leaks of the driver are not
important, but when integrated into a program with jit compilation, each
compilation triggers new memory leaks, independently of the user code.

The leak is not related directly with libgccjit but matters for its use case.