[Bug libstdc++/101485] Calling std::equal with std::byte* does not use memcmp

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

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

--- Comment #13 from Jonathan Wakely  ---
Yes I've read it but it's not clear to me that it's SFINAE-friendly when the
expression resolves to a built-in like that.

[Bug tree-optimization/115707] [15 regression] FAIL in gcc.target/aarch64/sve/sad_1.c since r15-863-ga3aeff4ce95b

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #2 from Feng Xue  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.

This is known to be another new bug, and has been recorded in PR115060.

[Bug c++/115708] New: gcc fails to identify valid friend function declaration with deduced return type

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 115708
   Summary: gcc fails to identify valid friend function
declaration with deduced return type
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

Please consider the following code:

~~~
struct Base {
auto f(int) { return 1; }
};

struct A : Base {
friend auto Base::f(int) ;
};

int main() {
A instance;
auto ptr_1=&A::f;
}
~~~

GCC-13.2 rejects this by complaining that there's no matched function for the
friend declaration of "auto Base::f(int)":


~
:6:17: error: no declaration matches 'auto Base::f(int)'
6 | friend auto Base::f(int) ;
  | ^~~~
:2:10: note: candidate is: 'auto Base::f(int)'
2 | auto f(int) { return 1; }
  |  ^
:1:8: note: 'struct Base' defined here
1 | struct Base {
~

That's unusual because the code is apparently valid. Changing the return type
of "f" from "auto" to "int" can make the code compile.

Clang also accepts this code. Please check https://godbolt.org/z/z8PYK17n8

[Bug libstdc++/101485] Calling std::equal with std::byte* does not use memcmp

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

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

--- Comment #14 from Jonathan Wakely  ---
Gašper has confirmed that the intention is for it to be SFINAE-friendly, so
declcall would work here (and for [comparisons.general],
[comparisons.three.way], and [range.cmp], although P2434 might make it
unnecessary for those).

[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-29
 Status|UNCONFIRMED |NEW

[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode

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

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

--- Comment #5 from Jonathan Wakely  ---
P2825 would be very useful here.

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

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

https://gcc.gnu.org/g:378f50f4c32af5111893989bfc5a191d3aa27bb7

commit r11-11550-g378f50f4c32af5111893989bfc5a191d3aa27bb7
Author: Francois-Xavier Coudert 
Date:   Sat Mar 16 09:50:00 2024 +0100

libcc1: fix  include

Use INCLUDE_VECTOR before including system.h, instead of directly
including , to avoid running into poisoned identifiers.

Signed-off-by: Dimitry Andric 

libcc1/ChangeLog:

PR middle-end/111632
* libcc1plugin.cc: Fix include.
* libcp1plugin.cc: Fix include.

(cherry picked from commit 5213047b1d50af63dfabb5e5649821a6cb157e33)

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #37 from Iain Sandoe  ---
fixed on open branches

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #5 from Konstantin Kharlamov  ---
(In reply to Konstantin Kharlamov from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > It is included in -Wc++-compat .
> 
> Cool, thanks! I'll add the warning to the list we compile the project with,
> thank you!

FWIW, I tried that yesterday and I think the cons of -Wc++-compat far
overweight its pros. The immediate problem is that it starts to warn about
every `MyType* foo = malloc(…)` construction due to `MyType*` and `void*` being
different.

So basically -Wc++-compat warns about every heap memory allocation, of which
there are dozens and hundreds in every C file. This warning alone can't be
turned off. So apparently you're supposed to replace every memory allocation
with a custom macro that takes type of the variable as an additional parameter
just to shove in a cast.

This is such a huge and inconvenient task that I would be very surprised if
anybody uses -Wc++-compat at all.

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #6 from uecker at gcc dot gnu.org ---
Yes, -Wc++-compat is definitely not suitable or recommended for C code. I think
we should split this warning out.

[Bug c/115696] [15 regression] ICE on invalid repeated mixed declarations (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in comptypes_verify, at c/c-typeck.cc:1178)

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||uecker at gcc dot gnu.org
   Last reconfirmed||2024-06-29

--- Comment #1 from uecker at gcc dot gnu.org ---
confirmed.

[Bug c++/114573] -Wzero-as-null-pointer-constant complains on enum with explicit cast

[albertnetymk at gmail dot com via Gcc-bugs]

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

Albert Netymk  changed:

   What|Removed |Added

 CC||albertnetymk at gmail dot com

--- Comment #3 from Albert Netymk  ---
Maybe related. The first two invocations of `f` trigger a warning. Clang
doesn't complain.

```
static const int g_zero = 0;

void f(void* value);

void g() {
f(reinterpret_cast(0));

f(reinterpret_cast(g_zero));

int y = g_zero;
f(reinterpret_cast(y));
}
```

[Bug fortran/114019] allocation with source of deferred character length entity

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

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

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

https://gcc.gnu.org/g:7682d115402743090f20aca63a3b5e6c205dedff

commit r15-1722-g7682d115402743090f20aca63a3b5e6c205dedff
Author: Harald Anlauf 
Date:   Fri Jun 28 21:44:06 2024 +0200

Fortran: fix ALLOCATE with SOURCE of deferred character length [PR114019]

gcc/fortran/ChangeLog:

PR fortran/114019
* trans-stmt.cc (gfc_trans_allocate): Fix handling of case of
scalar character expression being used for SOURCE.

gcc/testsuite/ChangeLog:

PR fortran/114019
* gfortran.dg/allocate_with_source_33.f90: New test.

[Bug c/114727] ICE with c23 with aligned attribute and -g

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to Richard Biener from comment #2)
> Possibly type verification should be triggered from rest_of_type_compilation
> rather than from (only) gen_type_die_with_usage.

Yeah, it's a shame to have these occasional issues where they only show up with
-g. I don't routinely build everything with -g so I may well miss things.
(Maybe   I should start.)

[Bug c/114727] ICE with c23 with aligned attribute and -g

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #4 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/656021.html

[Bug c/114727] ICE with c23 with aligned attribute and -g

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

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

--- Comment #5 from uecker at gcc dot gnu.org ---

(In reply to Sam James from comment #3)
> (In reply to Richard Biener from comment #2)
> > Possibly type verification should be triggered from rest_of_type_compilation
> > rather than from (only) gen_type_die_with_usage.
> 
> Yeah, it's a shame to have these occasional issues where they only show up
> with -g. I don't routinely build everything with -g so I may well miss
> things. (Maybe   I should start.)

Note that I recently added some FE checking code which should catch some subset
of problems earlier.

[Bug c++/115007] [modules] ICE in maybe_clone_body when calling virtual destructor from instantiated template

[porten at kde dot org via Gcc-bugs]

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

porten at kde dot org changed:

   What|Removed |Added

 CC||porten at kde dot org

--- Comment #1 from porten at kde dot org ---
Getting the same for similar code with gcc 14.1.1 20240629

[Bug tree-optimization/115709] New: missed optimisation: vperms not reordered to eliminate

[mjr19 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 115709
   Summary: missed optimisation: vperms not reordered to eliminate
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

#include 
void foo(double complex *a, double *b, int n){
  int i;

  for(i=0;i

[Bug c/114727] ICE with c23 with aligned attribute and -g

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

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

--- Comment #6 from Sam James  ---
Ah, great, thank you!

[Bug c/115696] [15 regression] ICE on invalid repeated mixed declarations (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in comptypes_verify, at c/c-typeck.cc:1178)

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

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

--- Comment #2 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/656022.html

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

[alx at kernel dot org via Gcc-bugs]

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||alx at kernel dot org

--- Comment #7 from Alejandro Colomar  ---
(In reply to Konstantin Kharlamov from comment #5)
> So basically -Wc++-compat warns about every heap memory allocation, of which
> there are dozens and hundreds in every C file. This warning alone can't be
> turned off. So apparently you're supposed to replace every memory allocation
> with a custom macro that takes type of the variable as an additional
> parameter just to shove in a cast.

Off-topic, but "replac[ing] every memory allocation with a custom macro that
takes [the] type of the variable as an additional parameter just to shove in a
cast" is actually a good thing.  It improves the safety of such calls.  I found
and fixed several bugs in allocation calls in shadow utils thanks to these
macros.

See:







Anyway, I hope my patch to add -Wunterminated-string-initialization is merged
soon.  :)

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

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

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

--- Comment #8 from uecker at gcc dot gnu.org ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are dozens and hundreds in every C file. This warning alone can't be
> > turned off. So apparently you're supposed to replace every memory allocation
> > with a custom macro that takes type of the variable as an additional
> > parameter just to shove in a cast.
> 
> Off-topic, but "replac[ing] every memory allocation with a custom macro that
> takes [the] type of the variable as an additional parameter just to shove in
> a cast" is actually a good thing.  It improves the safety of such calls.  I
> found and fixed several bugs in allocation calls in shadow utils thanks to
> these macros.
> 
> See:
> 
>  d81506de1e8e2ba544a30e54e863fcafda9cde86>
>  191f04f7dcb92a2c7de99dbf1108563ea8832927>
>  6e58c1275252f3314d1aa5cc4d7e7f9068e3a902>
>  efbbcade43ff2dca2b7a271dcbd186be08ac1913>
>  09775d3718df216c75b62d73bbcc5aa060e0fc94>
> 
> Anyway, I hope my patch to add -Wunterminated-string-initialization is
> merged soon.  :)

Have you considered adding the alloc_size attribute to your allocation
functions?

[Bug fortran/115710] New: fortran complex abs does not vectorise

[mjr19 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 115710
   Summary: fortran complex abs does not vectorise
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

subroutine foo(a,b,n)
  complex(kind(1d0))::a(*)
  real(kind(1d0))::b(*)
  integer::i,n

  do i=1,n
 b(i)=abs(a(i))**2
  end do

end subroutine foo

fails to vectorise with "gfortran-14 -mavx2 -mfma -Ofast".

I am very impressed that the **2 simply removes the sqrt, so the above code is
simpler than the code without **2 (which also doesn't vectorise, and should). I
am also impressed that

  b(i)=a(i)*conjg(a(i))

and

  b(i)=real(a(i))*real(a(i))+aimag(a(i))*aimag(a(i))

produce identical, vectorised, assembler. But the abs example ought to be the
same too.

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #9 from Alejandro Colomar  ---
(In reply to uecker from comment #8)
> Have you considered adding the alloc_size attribute to your allocation
> functions?

I didn't know about it; I will do.  Thanks!  :-)

[Bug fortran/115710] fortran complex abs does not vectorise

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #1 from kargls at comcast dot net ---
Looks like a wrong component was chosen.  I get nearly identical assembly with

#include 
#include 

void
foo(double complex *a, double *b, int n)
{
  for (int i=0; i < n; i++)
 b[i] = cabs(a[i]) * cabs(a[i]);
}

~/work/bin/gcc  -S -mavx2 -mfma -Ofast -o zc.s a.c
~/work/bin/gfortran -S -mavx2 -mfma -Ofast -o zf.s -fno-underscore a.f90

[Bug tree-optimization/115274] Bogus -Wstringop-overread in SQLite source code

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #10 from Andi Kleen  ---
-fno-thread-jumps fixes it, so it's probably a dup of PR109071 (same problem
with a different warning)

[Bug fortran/115711] New: Fortran: extra malloc and copy with transfer

[mjr19 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 115711
   Summary: Fortran: extra malloc and copy with transfer
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

subroutine foo(a,b)
  complex(kind(1d0))::a
  real(kind(1d0))::b(2)

  b=transfer(a,b)
end subroutine foo

produces optimal code. But change the declarations to

  complex(kind(1d0))::a(2)
  real(kind(1d0))::b(4)

and "gfortran-14 -mavx2 -O3" calls malloc, copies a to a temporary location,
then copies into b, and calls free. Generalise to a(n) and b(2*n), passing n as
an extra integer argument, and it calls malloc, memcpy, memcpy, free.

I don't think this double copy is necessary -- just a single copy with no
temporary should suffice.

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #10 from Konstantin Kharlamov  ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are dozens and hundreds in every C file. This warning alone can't be
> > turned off. So apparently you're supposed to replace every memory allocation
> > with a custom macro that takes type of the variable as an additional
> > parameter just to shove in a cast.
> 
> Off-topic, but "replac[ing] every memory allocation with a custom macro that
> takes [the] type of the variable as an additional parameter just to shove in
> a cast" is actually a good thing.  It improves the safety of such calls.  I
> found and fixed several bugs in allocation calls in shadow utils thanks to
> these macros.
> 
> See:
> 
>  d81506de1e8e2ba544a30e54e863fcafda9cde86>
>  191f04f7dcb92a2c7de99dbf1108563ea8832927>
>  6e58c1275252f3314d1aa5cc4d7e7f9068e3a902>
>  efbbcade43ff2dca2b7a271dcbd186be08ac1913>
>  09775d3718df216c75b62d73bbcc5aa060e0fc94>
> 
> Anyway, I hope my patch to add -Wunterminated-string-initialization is
> merged soon.  :)

Thank you, these are interesting commits, but they just add the macros, don't
seem to fix any bugs. Or if they do, the fixes are lost among other changes. I
would rather be sold if you linked the fixes specifically 😊

[Bug c/115185] Missing "too long" warning when string-array size doesn't include NULL byte

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #11 from Alejandro Colomar  ---
(In reply to Konstantin Kharlamov from comment #10)
> (In reply to Alejandro Colomar from comment #7)
> > (In reply to Konstantin Kharlamov from comment #5)
> > > So basically -Wc++-compat warns about every heap memory allocation, of 
> > > which
> > > there are dozens and hundreds in every C file. This warning alone can't be
> > > turned off. So apparently you're supposed to replace every memory 
> > > allocation
> > > with a custom macro that takes type of the variable as an additional
> > > parameter just to shove in a cast.
> > 
> > Off-topic, but "replac[ing] every memory allocation with a custom macro that
> > takes [the] type of the variable as an additional parameter just to shove in
> > a cast" is actually a good thing.  It improves the safety of such calls.  I
> > found and fixed several bugs in allocation calls in shadow utils thanks to
> > these macros.
> > 
> > See:
> > 
> >  > d81506de1e8e2ba544a30e54e863fcafda9cde86>
> >  > 191f04f7dcb92a2c7de99dbf1108563ea8832927>
> >  > 6e58c1275252f3314d1aa5cc4d7e7f9068e3a902>
> >  > efbbcade43ff2dca2b7a271dcbd186be08ac1913>
> >  > 09775d3718df216c75b62d73bbcc5aa060e0fc94>
> > 
> > Anyway, I hope my patch to add -Wunterminated-string-initialization is
> > merged soon.  :)
> 
> Thank you, these are interesting commits, but they just add the macros,
> don't seem to fix any bugs. Or if they do, the fixes are lost among other
> changes. I would rather be sold if you linked the fixes specifically 😊

Ahh, no I was remembering slightly wrong.  It was in neomutt(1) where I found
bugs.  I have some work-in-progress to add the same macros to neomutt(1), and
while doing the change, I found (and fixed) this bug from 1999:



Luckily, the program worked correctly, since it was using a type with a
compatible size.

[Bug fortran/115689] Missed deallocation before exit

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #7 from Jerry DeLisle  ---
Thankyou for comments. I will close as not a bug.

[Bug tree-optimization/115060] Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||thiago.bauermann at linaro dot 
org

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

[Bug tree-optimization/115707] [15 regression] FAIL in gcc.target/aarch64/sve/sad_1.c since r15-863-ga3aeff4ce95b

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup then.

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 115707 Summary: [15 regression] FAIL in gcc.target/aarch64/sve/sad_1.c 
since r15-863-ga3aeff4ce95b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115707

   What|Removed |Added

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

[Bug tree-optimization/115060] [15 Regression] Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |15.0
Summary|Probable an issue around|[15 Regression] Probable an
   |usage of|issue around usage of
   |vect_look_through_possible_ |vect_look_through_possible_
   |promotion in|promotion in
   |tree-vect-patterns.cc   |tree-vect-patterns.cc
   See Also||https://linaro.atlassian.ne
   ||t/browse/GNU-1226

[Bug tree-optimization/115710] fortran complex abs does not vectorise

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
/app/example.cpp:7:19: note:   === vect_analyze_data_refs ===
/app/example.cpp:7:19: missed:   not vectorized: no vectype for stmt: _4 = *_3;
 scalar_type: complex doubleD.46
/app/example.cpp:8:13: missed:   not vectorized: no vectype for stmt: _4 = *_3;
 scalar_type: complex double


Confirmed.

[Bug tree-optimization/115710] [11/12/13/14/15 Regression] complex abs does not vectorise

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||5.5.0
Summary|fortran complex abs does|[11/12/13/14/15 Regression]
   |not vectorise   |complex abs does not
   ||vectorise
   Target Milestone|--- |11.5
   Keywords||needs-bisection
  Known to fail||6.1.0

--- Comment #3 from Andrew Pinski  ---
So before forwprop3 we have:
```
  _10 = REALPART_EXPR <*_3>;
  _9 = IMAGPART_EXPR <*_3>;
  _4 = COMPLEX_EXPR <_10, _9>;
  _5 = cabs (_4);
  _6 = _1 * 8;
  _7 = b_14(D) + _6;
  reassocpow_18 = __builtin_powi (_5, 2);

```

After we get:
```
  _10 = REALPART_EXPR <*_3>;
  _4 = *_3;
  _9 = IMAGPART_EXPR <*_3>;
  _5 = cabs (_4);
  _6 = _1 * 8;
  _7 = b_14(D) + _6;
  reassocpow_18 = __builtin_powi (_5, 2);
```
Which undoes complex lowering.

But then powcabs does:
```
  _10 = REALPART_EXPR <*_3>;
  _4 = *_3;
  _9 = IMAGPART_EXPR <*_3>;
  cabs_8 = REALPART_EXPR <_4>;
  cabs_17 = cabs_8 * cabs_8;
  cabs_22 = IMAGPART_EXPR <_4>;
  cabs_23 = cabs_22 * cabs_22;
  cabs_24 = cabs_17 + cabs_23;
  powroot_25 = __builtin_sqrt (cabs_24);
  _5 = powroot_25;
  _6 = _1 * 8;
  _7 = b_14(D) + _6;
  powmult_26 = _5 * _5;
  reassocpow_18 = powmult_26;
  *_7 = reassocpow_18;
```
Which redoes some of the complex lowering but misses undoing the undo of
COMPLEX_EXPR, IMAG<*3>> ...

This is a regression even as GCC 5 used to be able top vectorize it.

[Bug tree-optimization/115712] New: [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

Bug ID: 115712
   Summary: [15 regression] Binutils testsuite fails 2 tests
(libnew1a.so, libnew1b.so)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

When building binutils trunk (17c78a23491ce76fd6d21cdbf2db3c0cf02145e0) today,
I noticed:
```
ld.sum:1080:FAIL: Run with libnew1a.so
ld.sum:1081:FAIL: Run with libnew1b.so
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit 7760ff0bf2fd5fa05385fc11158cb7efd7a05cc5'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240627 (experimental)
9c56dc7f52a7c238c104cf9cc82d17a3703d970f (Gentoo Hardened 15.0. p, commit
7760ff0bf2fd5fa05385fc11158cb7efd7a05cc5)
```

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #1 from Sam James  ---
Created attachment 58540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58540&action=edit
gcc-binutils-PR115712.tar.xz

g++ -g -O2 -D_GNU_SOURCE -ansi -c dl5.cc -o dl5.o
g++ -g -O2 -D_GNU_SOURCE -ansi -fPIC -c del.cc -o del.o
g++ -g -O2 -D_GNU_SOURCE -ansi -fPIC -c new.cc -o new.o
g++ -o libnew1a.so -shared -Wl,-Bsymbolic-functions,--dynamic-list-cpp-new
del.o new.o
g++ o dl5a -Wl,--no-as-needed libnew1a.so dl5.o

# Prints "FAIL" if dl5.o is built with GCC 15, but "PASS" if dl5.o is built
with GCC 14
LD_LIBRARY_PATH=. ./dl5a

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #2 from Sam James  ---
Between 14 and 15, the main difference is:
```
│   :
│  main():
│  /tmp/gcc-binutils-PR115712/dl5.cc:45
│   sub$0x8,%rsp
│ -/tmp/gcc-binutils-PR115712/dl5.cc:46
│ - mov$0x58,%edi
│ - call   e 
│ - R_X86_64_PLT32  operator new[](unsigned long)-0x4
│ -/tmp/gcc-binutils-PR115712/dl5.cc:46 (discriminator 1)
│ - movq   $0xa,(%rax)
│ -/tmp/gcc-binutils-PR115712/dl5.cc:46
│ - mov%rax,%rdi
│ -/tmp/gcc-binutils-PR115712/dl5.cc:47
│ - call   1d 
│ - R_X86_64_PLT32  operator delete[](void*)-0x4
│  /tmp/gcc-binutils-PR115712/dl5.cc:48
│   lea0x0(%rip),%rsi
│   R_X86_64_PC32   std::nothrow-0x4
│   mov$0x58,%edi
│ - call   2e 
│ + call   15 
│   R_X86_64_PLT32  operator new[](unsigned long, std::nothrow_t
const&)-0x4
│  /tmp/gcc-binutils-PR115712/dl5.cc:48 (discriminator 1)
│   test   %rax,%rax
│ - je 42 
│ - movq   $0xa,(%rax)
│ -/tmp/gcc-binutils-PR115712/dl5.cc:48 (discriminator 4)
│ + je 22 
```

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #3 from Sam James  ---
In cgraph:
```
@@ -1222,16 +1222,7 @@ _ZdaPv/82 (void operator delete [](void*))
   Referring:
   Availability: not_available
   Function flags: replaceable_operator_delete
-  Called by: main/76 (1073312328 (estimated locally),1.00 per call) main/76
(1073741824 (estimated locally),1.00 per call)
-  Calls:
-_Znam/81 (void* operator new [](std::size_t))
-  Type: function
-  Visibility: semantic_interposition external public visibility_specified
-  References:
-  Referring:
-  Availability: not_available
-  Function flags: decl_is_malloc replaceable_operator_new
-  Called by: main/76 (1073741824 (estimated locally),1.00 per call) (can throw
external)
+  Called by: main/76 (1073312328 (estimated locally),1.00 per call)
[...]
```

[Bug c/115027] Missing warning: unused struct's with self-referential initialisers

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/656024.html

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #4 from Sam James  ---
I'm going to bisect it next as C++ semantics with new/delete isn't something
I'm yet very experienced with.

[Bug target/115691] [15 Regression] libgomp.c-c++-common/for -2.h:101:33: internal compiler error: in extract_insn, at recog.cc:2816

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

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

--- Comment #3 from John David Anglin  ---
Problem introduced by the following change:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0b27d5ddb2ce7353a168c60c9109b4ee01e481eb

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||pinskia at gcc dot gnu.org

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #5 from Andrew Pinski  ---
r15-571-g1e0ae1f52741f7 is my guess.

But this code is questionable.

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> r15-571-g1e0ae1f52741f7 is my guess.

The reason is the DSE is able to remove the store due to the clobbers and then
dce finally can remove the operator new/operator delete pair.

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104105

--- Comment #7 from Andrew Pinski  ---
Note the reason why the nothrow variant is not optimized away is recorded as PR
104105.

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78104

--- Comment #8 from Andrew Pinski  ---
operator new/delete pairs have been optimized since PR 78104 was fixed in GCC
10. Just in this case the array makes the mechanism confused until now.

[Bug tree-optimization/115709] missed optimisation: vperms not reordered to eliminate

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

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

--- Comment #1 from Andrew Pinski  ---
aarch64 is fine since it has load_lanes:
.L4:
ld2 {v30.2d - v31.2d}, [x4], 32
fmulv31.2d, v31.2d, v31.2d
fmlav31.2d, v30.2d, v30.2d
str q31, [x3], 16
cmp x3, x5
bne .L4

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] Binutils|[15 regression] Binutils
   |testsuite fails 2 tests |testsuite fails 2 tests
   |(libnew1a.so, libnew1b.so)  |(libnew1a.so, libnew1b.so)
   ||since
   ||r15-571-g1e0ae1f52741f7
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=3831
 CC||hjl.tools at gmail dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #9 from Sam James  ---
r15-571-g1e0ae1f52741f7

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #10 from Andrew Pinski  ---
Removing wrong-code since I don't think this is wrong code, I just think the
testcase is incorrect.

[Bug tree-optimization/82450] loop flattening should be done

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

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

--- Comment #6 from Andrew Pinski  ---
https://inbox.sourceware.org/gcc-patches/AANLkTikW8W=rjonaqigggtjkb-_2sp5zaztjcamzj...@mail.gmail.com/T/#m358ef4c2bef77b1942d29d0a5787591e754ec5bc

[Bug lto/91677] -fbuiltin (default) breaks static link against lto libc

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91287

--- Comment #3 from Sam James  ---
I think there's others as well, and then a bunch on the binutils side which H.J
fixed recently.

[Bug target/112109] Missing riscv vectorized strcmp (and other) expanders

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:42946aa9b3228262e413481a3193bda85c20ef4b

commit r15-1723-g42946aa9b3228262e413481a3193bda85c20ef4b
Author: Sergei Lewis 
Date:   Sat Jun 29 14:34:31 2024 -0600

[to-be-committed,RISC-V,V4] movmem for RISCV with V extension

I hadn't updated my repo on the host where I handle email, so it picked
up the older version of this patch without the testsuite fix.  So, V4
with the testsuite option for lmul fixed.

--

And Sergei's movmem patch.  Just trivial testsuite adjustment for an
option name change and a whitespace fix from me.

I've spun this in my tester for rv32 and rv64.  I'll wait for pre-commit
CI before taking further action.

Just a reminder, this patch is designed to handle the case where we can
issue a single vector load/store which avoids all the complexities of
determining which direction to copy.

--

gcc/ChangeLog

* config/riscv/riscv.md (movmem): New expander.

gcc/testsuite/ChangeLog

PR target/112109
* gcc.target/riscv/rvv/base/movmem-1.c: New test

[Bug bootstrap/65632] gcc-4.8.4 fails to build native gcc for Gentoo/FreeBSD using crosscompiler on Gentoo/Linux

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Sam James  ---
Long obsolete, I think. Gentoo/FreeBSD isn't a thing anymore and the machinery
for handling cross w/ poisoning has changed too.

[Bug tree-optimization/115694] [13/14/15 regression] ICE in forwprop (useless_type_conversion_p) when building scipy with LTO since r13-1762-gf9d4c3b45c5ed5

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

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

--- Comment #10 from Sam James  ---
r13-1762-gf9d4c3b45c5ed5

[Bug tree-optimization/115694] [13/14/15 regression] ICE in forwprop (useless_type_conversion_p) when building scipy with LTO since r13-1762-gf9d4c3b45c5ed5

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|lto |
 CC||pinskia at gcc dot gnu.org

--- Comment #11 from Andrew Pinski  ---
here is a valid C++ testcase where the ICE happens (I forgot about bit_cast
emitting a VCE):
```
_Complex a;
typedef struct {
  double a[2];
} b;
void c(b);
void d()
{
  _Complex b1 = a;
  b t = __builtin_bit_cast (b, b1);
  c(t);
}
```

[Bug rtl-optimization/115565] [11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong code

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Maciej W. Rozycki :

https://gcc.gnu.org/g:69bc5fb97dc3fada81869e00fa65d39f7def6acf

commit r15-1724-g69bc5fb97dc3fada81869e00fa65d39f7def6acf
Author: Maciej W. Rozycki 
Date:   Sat Jun 29 23:26:55 2024 +0100

[PR115565] cse: Don't use a valid regno for non-register in comparison_qty

Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.

Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.

This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.

The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore.  However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.

Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.

gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.

[Bug rtl-optimization/115565] [11/12/13/14/15 Regression] CSE: Comparison incorrectly evaluated as constant causing optimization to produce wrong code

[macro at orcam dot me.uk via Gcc-bugs]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |macro at orcam dot me.uk
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Maciej W. Rozycki  ---
Fix committed, closing bug.

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

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

[hjl@gnu-tgl-3 tmp]$ g++ -c -O2 x.cc -ansi
[hjl@gnu-tgl-3 tmp]$ readelf -rW x.o | c++filt | grep -E "(new|delete)"
000a  000c0004 R_X86_64_PLT32 
operator new[](unsigned long) - 4
0019  000d0004 R_X86_64_PLT32 
operator delete[](void*) - 4
0028  000f0004 R_X86_64_PLT32 
operator new[](unsigned long, std::nothrow_t const&) - 4
003c  000d0004 R_X86_64_PLT32 
operator delete[](void*) - 4
[hjl@gnu-tgl-3 tmp]$ /usr/gcc-15.0.0-x86-64/bin/g++ -c -O2 x.cc -ansi
[hjl@gnu-tgl-3 tmp]$ readelf -rW x.o | c++filt | grep -E "(new|delete)"
000f  000d0004 R_X86_64_PLT32 
operator new[](unsigned long, std::nothrow_t const&) - 4
001c  000e0004 R_X86_64_PLT32 
operator delete[](void*) - 4
[hjl@gnu-tgl-3 tmp]$ 

new and delete update "pass".  They can't be folded without updating "pass".

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-30

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110137

--- Comment #12 from Andrew Pinski  ---
See PR 110137 really.

[Bug driver/115698] @file invalidates -B in g++ command line

[yhdang at stu dot xjtu.edu.cn via Gcc-bugs]

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

--- Comment #3 from Yihan Dang  ---
Hello Andrew, thank you very much for your reply! I think I've found the catch:
Change the custom ld script to this:
```
#!/bin/bash

echo "hello from custom ld, arguments are: $*"

filename=$1
filename=${filename:1}
if [ -e "$filename" ]; then
cat "$filename"
fi

exit 0
```

The one that does NOT use `@file` syntax would print out all arguments right
here:

```
hello from custom ld, arguments are: -plugin
/usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper ...
```

But the one that DOES use it would output something like:
```
hello from custom ld, arguments are: @/tmp/ccMXQbBc
# /tmp/ccMXQbBC contains all arguments as above
```

Since `ld.libhugetlbfs` does not extract argument from `@file`, it cannot
consume the custom argument, and that is fed eventually to original `ld`, where
the arguments are finally extracted.

I wonder if it makes sense to extract the arguments earlier in the toolchain.
The users sometimes want to use custom `ld` script, and I don't think they
should handle `@file` themselves.

[Bug driver/115698] @file invalidates -B in g++ command line

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
> Since `ld.libhugetlbfs` does not extract argument from `@file`, it cannot
> consume the custom argument, and that is fed eventually to original `ld`,
> where the arguments are finally extracted.

That would be a bug in ld.libhugetlbfs then. Basically the @file is used so the
size of the options does not get too big. The original BFD Ld understands @file
and able to take all and all options there.
Basically ld.libhugetlbfs needs to support @ syntax to extract all options and
then create a new file to pass on to the real ld.

[Bug driver/115698] @file invalidates -B in g++ command line

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/libhuget
   ||lbfs/libhugetlbfs/issues/88

--- Comment #5 from Andrew Pinski  ---
Filed https://github.com/libhugetlbfs/libhugetlbfs/issues/88 for the
libhugetlbfs issue.

[Bug target/115713] New: rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

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

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

Bug ID: 115713
   Summary: rs6000: Miss warning for incompatible no-altivec and
vsx in target attribute
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

As Peter found in the PR115688, there isn't a warning for:

long __attribute__ ((target ("no-altivec,vsx")))
foo (void)
{
  return 0;
}

It's expected to see warning like:

warning: ‘-mvsx’ and ‘-mno-altivec’ are incompatible

[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-30
 Target||powerpc*
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |15.0
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||diagnostic

[Bug target/115688] [15 regression] ICE on simple test case from r15-703-gb390b011569635

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #7 from Kewen Lin  ---
(In reply to Segher Boessenkool from comment #3)
> Something like that.
> 
> But why would we want to disable generation of VSX or VMX insns at all?
> This is similar to disabling generation of popcntd insns if you do not like
> those!
> 
> Having generation of V*X insns enabled is completely independent of whether
> something special is done for them for inter-procedural things (ABI things
> or similar).  It sounds like the actual problem this code wants to tackle is
> one of those things, but instead it uses a heavy hammer?

This adjustment was added since target attribute/pragma support
(r0-104781-gfd438373cdd2a5), Mike may have more insightful comments on this.
According to the comments around, it aims to avoid the error message when users
specify a target attribute like cpu=power7 while the command line is being
specified like -m32 -mcpu=power6 etc. Without this adjustment, the following
check will raise error "target attribute or pragma changes AltiVec ABI".

  if (TARGET_ELF)
{
  if (!OPTION_SET_P (rs6000_altivec_abi)
  && (TARGET_64BIT || TARGET_ALTIVEC || TARGET_VSX))
{
  if (main_target_opt != NULL &&
  !main_target_opt->x_rs6000_altivec_abi)
error ("target attribute or pragma changes AltiVec ABI");
  else
rs6000_altivec_abi = 1;
}
}

This adjustment silently disable this as it mask off altivec and vsx when they
are not explicitly specified.

(In reply to Peter Bergner from comment #4)
> (In reply to Kewen Lin from comment #2)
> 
> > +  /* Don't mask off ALTIVEC if it is enabled by an explicit VSX.  */
> > +  if (!TARGET_VSX || !(rs6000_isa_flags_explicit & OPTION_MASK_VSX))
> 
> TARGET_VSX is only true here if it was explictly used, so I think you can
> drop the "|| !(rs6000_isa_flags_explicit & OPTION_MASK_VSX)" part of this
> test.

Good point, will adjust it accordingly.

> That said, how does your patch handle the following test case?
> 
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
>   return 0;
> }
> 
> ...currently, this compiles with with no error or warning message which
> seems wrong to me.

Good finding, but it is an separated issue, it shows one bug in our target
attribute handling, filed PR115713.

[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

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

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

--- Comment #1 from Kewen Lin  ---
There IS a warning for:

long __attribute__ ((target ("vsx,no-altivec")))
foo1 (void)
{
  return 0;
}

, interesting. :)

It's due to that we enable altivec when parsing vsx in target attribute, but
don't consider if it's explicit set, so the fix can be:

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 76bbb3a28ea..4638c34cc24 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -24638,8 +24638,11 @@ rs6000_inner_target_options (tree args, bool attr_p)
   {
 if (mask == OPTION_MASK_VSX)
   {
-mask |= OPTION_MASK_ALTIVEC;
-TARGET_AVOID_XFORM = 0;
+if (!(rs6000_isa_flags_explicit
+  & OPTION_MASK_ALTIVEC))
+  mask |= OPTION_MASK_ALTIVEC;
+if (!OPTION_SET_P (TARGET_AVOID_XFORM))
+  TARGET_AVOID_XFORM = 0;
   }
   }

[Bug target/115714] New: rs6000: Refine option -mabi={no-}altivec handlings with some related option

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

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

Bug ID: 115714
   Summary: rs6000: Refine option -mabi={no-}altivec handlings
with some related option
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

As Peter found in [1], even with altivec flag explicitly unset, we can still
have altivec_abi set, it's unexpected.

And we want to raise error when specify -mabi=no-altivec for linux 64 bit ABI
as Segher's comments in [2].

Besides, we need to sort out the combination between -mabi={no-}altivec and
-m{no-,}altivec (or -mvsx etc.) and raise warning/error if needed.

So filing this to track these.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654546.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688#c5

[Bug target/115714] rs6000: Refine option -mabi={no-}altivec handlings with some related option

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Last reconfirmed||2024-06-30
 Target||powerpc*
   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |15.0

[Bug target/115688] [15 regression] ICE on simple test case from r15-703-gb390b011569635

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

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

--- Comment #8 from Kewen Lin  ---
> > -mabi={no-,}altivec is only for the 32-bit ABIs.  All the 64-bit ABIs had
> > either only compatible changes to support VMX, or only ever had support for
> > it in the first place.
> In that case, -mabi=no-altivec should also be a hard error if -m64 is in
> effect.

Filed PR115714 to track.

[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute

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

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

--- Comment #2 from Peter Bergner  ---
(In reply to Kewen Lin from comment #0)
> As Peter found in the PR115688, there isn't a warning for:
> 
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
>   return 0;
> }
> 
> It's expected to see warning like:
> 
> warning: ‘-mvsx’ and ‘-mno-altivec’ are incompatible

I think Segher and I mentioned in the other bug, that conflicting options like
this should be an error, rather than a warning.

[Bug driver/115698] @file invalidates -B in g++ command line

[yhdang at stu dot xjtu.edu.cn via Gcc-bugs]

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

--- Comment #6 from Yihan Dang  ---
(In reply to Andrew Pinski from comment #5)
> Filed https://github.com/libhugetlbfs/libhugetlbfs/issues/88 for the
> libhugetlbfs issue.

Thank you very much for the help! I have submitted a pull request to this
issue.

[Bug tree-optimization/115712] [15 regression] Binutils testsuite fails 2 tests (libnew1a.so, libnew1b.so) since r15-571-g1e0ae1f52741f7

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

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

--- Comment #13 from H.J. Lu  ---
A binutils patch is posted at

https://sourceware.org/pipermail/binutils/2024-June/135259.html