[Bug c/116141] ICE with conditional operator

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116141

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 29970.

[Bug c/116141] ICE with conditional operator

2024-07-30 Thread uecker at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116141

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108931
 CC||uecker at gcc dot gnu.org

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

It is related, but PR29970 was already a series of different underlying
problems... Here, I suspect that has the same root cause as PR108931

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

2024-07-30 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116130

--- Comment #11 from Jakub Jelinek  ---
Created attachment 58774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58774&action=edit
gcc15-pr116130.patch

Untested patch.  This doesn't hook it up in the middle-end with the exception
of
the simple cases (no pointer/reference arguments), which are mapped to
ECF_CONST|ECF_LOOPING_CONST_OR_PURE resp. ECF_PURE|ECF_LOOPING_CONST_OR_PURE
(unless const or pure attributes are also present).
There is no warning for the ?: case, seems we've always behaved that way
(though
perhaps we want to add some warning for it incrementally).
And there is no diagnostics of unsuitable functions.  I guess the detection of
non-stateless functions with [[unsequenced]] attribute would be easy (but we
can't require all calls to be also [[unsequenced]], so it would be just partial
warning for one function), but the rest would be pretty hard and not really
sure
what we could actually diagnose.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread qinzhao at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #29 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #28)
> It would need to be a FE keyword where __builtin_get_counted_by would return
> some pointer, either e.g. (void *)0 if it doesn't have a count, or a pointer
> to the count (with type of the pointer dependent on what type the count has).

So, a RID_BUILTIN (i.e, FE keyword) like the following:

  (void *) __builtin_get_counted_by (ptr)

Then the user source code becomes the following:

If (__builtin_get_counted_by (P->FAM))
  *__builtin_get_counted_by (P->FAM) = COUNT;

> 
> Speaking of counted_by, I see support for it in c-family/ and c/, but not in
> cp/ at all, what is the attribute supposed to do in C++?
The initial plan is to support it in both C and C++ (since C++ can use flexible
array member too through GCC extension), but I didn't implement it in C++ in
the initial patch. 
> If it isn't supported, it should be documented that it doesn't apply to C++
> and should be rejected in C++.  If it is to be supported, the support
> (including support for templates) needs to be there before GCC 15.
I will try to support it in C++ too in GCC15. If not, I will update the
documentation to indicate this limitation.

[Bug other/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently

2024-07-30 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143

--- Comment #1 from David Malcolm  ---
Sorry about this.

Demangling,
  _ZNK22simple_diagnostic_path10num_eventsEv
is
  simple_diagnostic_path::num_events() const

which is a vfunc implemented in gcc/simple-diagnostic-path.o

My guess is that nothing is using class simple_diagnostic_path in cc1, and thus
the code for simple_diagnostic_path is being dropped by the linker, so it's not
available to the plugin.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #30 from Jakub Jelinek  ---
(In reply to qinzhao from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > It would need to be a FE keyword where __builtin_get_counted_by would return
> > some pointer, either e.g. (void *)0 if it doesn't have a count, or a pointer
> > to the count (with type of the pointer dependent on what type the count 
> > has).
> 
> So, a RID_BUILTIN (i.e, FE keyword) like the following:
> 
>   (void *) __builtin_get_counted_by (ptr)

Well, without that void *.  I think the closest behavior match would be
something like
__builtin_shuffle (though that has 2 arguments rather than one).
Basically, parse the argument expression list, error if it isn't one, determine
if it is a FAM with counted_by, if yes, replace the call with &P->COUNT (note,
side-effects in the argument need to be evaluated exactly once), otherwise
return (void) (P->FAM), (void *) 0 (again, evaluate side-effects but return
NULL).

> The initial plan is to support it in both C and C++ (since C++ can use
> flexible array member too through GCC extension), but I didn't implement it
> in C++ in the initial patch. 
> > If it isn't supported, it should be documented that it doesn't apply to C++
> > and should be rejected in C++.  If it is to be supported, the support
> > (including support for templates) needs to be there before GCC 15.
> I will try to support it in C++ too in GCC15. If not, I will update the
> documentation to indicate this limitation.

Then perhaps we should ASAP change 
handle_counted_by_attribute so that it emits a sorry message if (c_dialect_cxx
()),
either as the first thing, or perhaps after doing the current diagnostics.

[Bug c++/106667] Diagnosing misuses of capturing lambda coroutines

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106667

Arsen Arsenović  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2024-07-30
 Ever confirmed|0   |1
 CC||arsen at gcc dot gnu.org

--- Comment #1 from Arsen Arsenović  ---
very reasonable diagnostic to do, confirming

[Bug c++/102363] source_location in await_transform has function_name referring to internal coroutine funclet rather than source-level function

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102363

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Arsen Arsenović  ---
fixed as of r15-2404-g265aa32062167a

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

[Bug c++/110855] std::source_location doesn't work with C++20 coroutine

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110855

Arsen Arsenović  changed:

   What|Removed |Added

 CC||redbeard0531 at gmail dot com

--- Comment #7 from Arsen Arsenović  ---
*** Bug 102363 has been marked as a duplicate of this bug. ***

[Bug c++/103358] what is the first constructor argument of lambda coroutine promise_type?

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103358

Arsen Arsenović  changed:

   What|Removed |Added

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

--- Comment #3 from Arsen Arsenović  ---
now I see: T = {const&, int&, char&, double&}, which
I think is reasonable.  what was being seen is a double-reference, so this is
probably a dupe of PR104981 which patrick fixed the other day

> T = {const&&, int&, char&, double&} here, what is 
> the type `const&&`?

it was a double reference (which was wrong)

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

[Bug c++/54367] [meta-bug] lambda expressions

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 103358, which changed state.

Bug 103358 Summary: what is the first constructor argument of lambda coroutine 
promise_type?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103358

   What|Removed |Added

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

[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981

Arsen Arsenović  changed:

   What|Removed |Added

 CC||netcan1996 at gmail dot com

--- Comment #9 from Arsen Arsenović  ---
*** Bug 103358 has been marked as a duplicate of this bug. ***

[Bug ipa/115309] Simple coroutine based generator is not optimized well

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115309

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org
   Last reconfirmed||2024-07-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Arsen Arsenović  ---
confirmed

[Bug rtl-optimization/48633] [4.7 regression] IRA causes ICE in compensate_edge

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug tree-optimization/83072] Late VRP optimization

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929

--- Comment #33 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug target/96562] Rather poor assembly generated for copy-list-initialization in return statement.

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug preprocessor/90581] provide an option to adjust the maximum depth of nested #include

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:7f1aa73bde0babde0ed3ff58d7226b86d25d075d

commit r15-2413-g7f1aa73bde0babde0ed3ff58d7226b86d25d075d
Author: Sam James 
Date:   Tue Jul 30 12:21:42 2024 +0100

testsuite: fix whitespace in dg-do preprocess directive

PR preprocessor/90581
* c-c++-common/cpp/fmax-include-depth.c: Fix whitespace in dg
directive.

[Bug target/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:2e662dedf84aa23fdff7bceca040432bf9f1ab72

commit r15-2412-g2e662dedf84aa23fdff7bceca040432bf9f1ab72
Author: Sam James 
Date:   Tue Jul 30 12:20:47 2024 +0100

testsuite: fix whitespace in dg-do compile directives

Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.

PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/96707
PR tree-optimization/97567
PR target/69225
PR target/89929
PR target/96562
* g++.dg/pr48633.C: Fix whitespace in dg directive.
* g++.dg/pr96707.C: Likewise.
* g++.target/i386/mv28.C: Likewise.
* gcc.dg/Warray-bounds-flex-arrays-1.c: Likewise.
* gcc.dg/pr83072-2.c: Likewise.
* gcc.dg/pr83073.c: Likewise.
* gcc.dg/pr96542.c: Likewise.
* gcc.dg/pr97567-2.c: Likewise.
* gcc.target/i386/avx512fp16-11a.c: Likewise.
* gcc.target/i386/avx512fp16-13.c: Likewise.
* gcc.target/i386/avx512fp16-14.c: Likewise.
* gcc.target/i386/avx512fp16-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-conjugation-1.c: Likewise.
* gcc.target/i386/avx512fp16vl-neg-1a.c: Likewise.
* gcc.target/i386/avx512fp16vl-set1-pch-1a.c: Likewise.
* gcc.target/i386/avx512vlfp16-11a.c: Likewise.
* gcc.target/i386/pr69225-1.c: Likewise.
* gcc.target/i386/pr69225-2.c: Likewise.
* gcc.target/i386/pr69225-3.c: Likewise.
* gcc.target/i386/pr69225-4.c: Likewise.
* gcc.target/i386/pr69225-5.c: Likewise.
* gcc.target/i386/pr69225-6.c: Likewise.
* gcc.target/i386/pr69225-7.c: Likewise.
* gcc.target/i386/pr96562-1.c: Likewise.
* gcc.target/riscv/rv32e_stack.c: Likewise.
* gfortran.dg/c-interop/removed-restrictions-3.f90: Likewise.
* gnat.dg/renaming1.adb: Likewise.

[Bug target/116131] [14/15 Regression] RISC-V: Unrecognizable insn with xtheadmemidx on rv32

2024-07-30 Thread cmuellner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116131

--- Comment #3 from Christoph Müllner  ---
After passing the tests, I've posted the patch on the mailing list:
  https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658726.html

[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773

Arsen Arsenović  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-30
 CC||arsen at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Arsen Arsenović  ---
still around

[Bug other/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently

2024-07-30 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-07-30

--- Comment #2 from Segher Boessenkool  ---
Yup, that sounds eminently plausible :-)  Thanks.

How will you fix this?  Add an  attribute ((used))  ?

[Bug middle-end/54400] recognize vector reductions

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2417-gee12a13d25778a1ad8a9b5dc63aadf9f4320088b
Author: Sam James 
Date:   Tue Jul 30 17:23:08 2024 +0100

testsuite: fix whitespace in dg-require-effective-target directives

PR middle-end/54400
PR target/98161
* gcc.dg/vect/bb-slp-layout-18.c: Fix whitespace in dg directive.
* gcc.dg/vect/bb-slp-pr54400.c: Likewise.
* gcc.target/i386/pr98161.c: Likewise.

[Bug target/98161] [11 Regression] Incorrect stack realignment on __force_align_arg_pointer__ with -msse4 by r11-446

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98161

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2417-gee12a13d25778a1ad8a9b5dc63aadf9f4320088b
Author: Sam James 
Date:   Tue Jul 30 17:23:08 2024 +0100

testsuite: fix whitespace in dg-require-effective-target directives

PR middle-end/54400
PR target/98161
* gcc.dg/vect/bb-slp-layout-18.c: Fix whitespace in dg directive.
* gcc.dg/vect/bb-slp-pr54400.c: Likewise.
* gcc.target/i386/pr98161.c: Likewise.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread kees at outflux dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #31 from Kees Cook  ---
(In reply to Qing Zhao from comment #25)
> The source code need to be:
> 
> If (__builtin_get_counted_by (P->FAM))
>   __builtin_get_counted_by (P->FAM) = COUNT;
> 
> Yes, I agree that this is good too for the original purpose. And also even
> simpler and more flexible.
> Kees might have more comments here. (Not sure any other impact on handling
> the original problem he had with the new __builtin_get_counted_by).

Yeah, I like this. It gives much more obvious semantics instead of hiding a
no-op, and this could be used for _reading_ as well as writing the value. This
means we could also write, for example, loop constructs with only the FAM:


  typeof(*__builtin_get_counted_by(P->FAM)) idx;

  for (idx = 0; idx < *__builtin_get_counted_by(P->FAM); idx++)
do_things(P->FAM[idx]);

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread kees at outflux dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #32 from Kees Cook  ---
(In reply to qinzhao from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > Speaking of counted_by, I see support for it in c-family/ and c/, but not in
> > cp/ at all, what is the attribute supposed to do in C++?
> The initial plan is to support it in both C and C++ (since C++ can use
> flexible array member too through GCC extension), but I didn't implement it
> in C++ in the initial patch. 
> > If it isn't supported, it should be documented that it doesn't apply to C++
> > and should be rejected in C++.  If it is to be supported, the support
> > (including support for templates) needs to be there before GCC 15.
> I will try to support it in C++ too in GCC15. If not, I will update the
> documentation to indicate this limitation.

FWIW, the Linux kernel only needs this for C (obviously), so if C++ support is
at all a burden, my vote would to be having these features be C-only. (But from
a completeness perspective, it would be nice to have it in C++ too.)

[Bug tree-optimization/116139] ICE with --param fully-pipelined-fma=1 since it was added in r14-6559-g8afdbcdd7abe1e

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116139

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|15.0|---
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|[15 Regression] ICE with|ICE with --param
   |--param |fully-pipelined-fma=1 since
   |fully-pipelined-fma=1   |it was added in
   ||r14-6559-g8afdbcdd7abe1e
  Known to work|14.1.0  |
   Last reconfirmed||2024-07-30

--- Comment #1 from Andrew Pinski  ---
Confirmed. This is NOT a regression since it ICEs with GCC 14 when configured
with --enable-checking=yes as this is a gcc_checking_assert assert (which is
disabled for --enable-checking=release :) ).

[Bug tree-optimization/116139] ICE with --param fully-pipelined-fma=1 since it was added in r14-6559-g8afdbcdd7abe1e

2024-07-30 Thread ktkachov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116139

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. This is NOT a regression since it ICEs with GCC 14 when
> configured with --enable-checking=yes as this is a gcc_checking_assert
> assert (which is disabled for --enable-checking=release :) ).

err yeah, I did think it was suspicious that 14 didn't ICE but I only used
godbolt to try older versions. You're right, it's a problem there as well.

[Bug target/116145] New: Suboptimal SVE immediate synthesis

2024-07-30 Thread ktkachov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145

Bug ID: 116145
   Summary: Suboptimal SVE immediate synthesis
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: aarch64-sve, missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

While optimising some string matching code I wanted to create a vector of
characters to match through an svdup and an svreinterpret but am getting
suboptimal codegen through the constant pool:
A minimised testcase:
#include 

svuint8_t
foo (void)
{
return svreinterpret_u8(svdup_u32(0x0a0d5c3f));
}

generates for -O2 -march=armv9-a:
foo:
ptrue   p3.b, all
adrpx0, .LC0
add x0, x0, :lo12:.LC0
ld1rw   z0.s, p3/z, [x0]
ret
.LC0:
.word   168647743

but LLVM can do it with:
foo:
mov w8, #23615
movkw8, #2573, lsl #16
mov z0.s, w8
ret

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492

--- Comment #24 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:8b737ec289da83e9e2a9672be0336980616e8932

commit r15-2419-g8b737ec289da83e9e2a9672be0336980616e8932
Author: Uros Bizjak 
Date:   Tue Jul 30 20:02:36 2024 +0200

i386/testsuite: Add testcase for fixed PR [PR51492]

PR target/51492

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr51492.c: New test.

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

2024-07-30 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0

--- Comment #25 from Uroš Bizjak  ---
Implemented for gcc-15.

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

2024-07-30 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 51492, which changed state.

Bug 51492 Summary: vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492

   What|Removed |Added

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

[Bug target/116145] Suboptimal SVE immediate synthesis

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-07-30

--- Comment #1 from Andrew Pinski  ---
Even simple as this GCC does the load:
```
#include 

svuint32_t
foo1 (void)
{
return svdup_u32(0x0a0d5c3f);
}
```

[Bug target/116145] Suboptimal SVE immediate synthesis

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #2 from Andrew Pinski  ---
```
/* We're duplicating a single value, but can't do better than
   force it to memory and load from there.  This handles things
   like symbolic constants.  */
elt_value = CONST_VECTOR_ENCODED_ELT (src, 0);

  if (elt_value)
{
  /* Load the element from memory if we can, otherwise move it into
 a register and use a DUP.  */
  rtx op = force_const_mem (elt_mode, elt_value);
  if (!op)
op = force_reg (elt_mode, elt_value);
  return expand_vector_broadcast (mode, op);
}
```

Seems like we are forcing to constant memory too early ...

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

2024-07-30 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #17 from Marek Polacek  ---
Unassigning, see the discussion at
.

[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression

2024-07-30 Thread mark at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600

--- Comment #35 from Mark Wielaard  ---
(In reply to GCC Commits from comment #28)
> The master branch has been updated by Robin Dapp :
> 
> https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810
> 
> commit r14-5034-g184378027e92f51e02d3649e0ca523f487fd2810
> Author: Robin Dapp 
> Date:   Thu Oct 12 11:23:26 2023 +0200
> 
> genemit: Split insn-emit.cc into several partitions.
> 
> On riscv insn-emit.cc has grown to over 1.2 mio lines of code and
> compiling it takes considerable time.
> Therefore, this patch adjust genemit to create several partitions
> (insn-emit-1.cc to insn-emit-n.cc).  The available patterns are
> written to the given files in a sequential fashion.
> 
> Similar to match.pd a configure option --with-emitinsn-partitions=num
> is introduced that makes the number of partition configurable.

The size of the partitions is a little uneven though. Using
--with-emitinsn-partitions=48 I get some empty partitions and some bigger than
2MB:

$ du -sb insn-emit-*cc | sort -n
814 insn-emit-12.cc
814 insn-emit-26.cc
814 insn-emit-27.cc
814 insn-emit-28.cc
113694  insn-emit-1.cc
168449  insn-emit-2.cc
197478  insn-emit-4.cc
231826  insn-emit-25.cc
264612  insn-emit-24.cc
269851  insn-emit-3.cc
273807  insn-emit-23.cc
309345  insn-emit-15.cc
354863  insn-emit-22.cc
399238  insn-emit-29.cc
469333  insn-emit-13.cc
494480  insn-emit-16.cc
529290  insn-emit-7.cc
548060  insn-emit-14.cc
587349  insn-emit-8.cc
605757  insn-emit-18.cc
654426  insn-emit-11.cc
674447  insn-emit-21.cc
715062  insn-emit-6.cc
719623  insn-emit-30.cc
722383  insn-emit-17.cc
739181  insn-emit-5.cc
740943  insn-emit-19.cc
752354  insn-emit-10.cc
775514  insn-emit-9.cc
798665  insn-emit-37.cc
864751  insn-emit-39.cc
880633  insn-emit-45.cc
898498  insn-emit-20.cc
921502  insn-emit-47.cc
927048  insn-emit-38.cc
940841  insn-emit-46.cc
954115  insn-emit-33.cc
979274  insn-emit-44.cc
1054316 insn-emit-32.cc
1133828 insn-emit-31.cc
1151717 insn-emit-40.cc
1190472 insn-emit-36.cc
1207434 insn-emit-41.cc
1218249 insn-emit-43.cc
1299464 insn-emit-42.cc
1887267 insn-emit-34.cc
1977532 insn-emit-35.cc
2935485 insn-emit-48.cc

Note that the last one (insn-emit-48.cc) is much larger than the rest.
Something similar happens with --with-emitinsn-partitions=20 where the smallest
one is just 120K but the biggest (and again the last one) is 4.3M.

$ du -sb insn-emit-*cc | sort -n
122643  insn-emit-11.cc
466445  insn-emit-12.cc
545997  insn-emit-1.cc
691176  insn-emit-10.cc
773776  insn-emit-2.cc
1027938 insn-emit-6.cc
1138222 insn-emit-5.cc
1524621 insn-emit-9.cc
1558328 insn-emit-3.cc
1730818 insn-emit-7.cc
1865168 insn-emit-4.cc
1893646 insn-emit-8.cc
2174548 insn-emit-16.cc
2378629 insn-emit-19.cc
2404572 insn-emit-13.cc
2840108 insn-emit-17.cc
2894107 insn-emit-14.cc
3030400 insn-emit-18.cc
4156366 insn-emit-15.cc
4486663 insn-emit-20.cc

Another problematic file is insn-recog.cc which is 19MB and takes 1 hour+ to
compile for me.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread isanbard at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #33 from Bill Wendling  ---
(In reply to Kees Cook from comment #31)
> (In reply to Qing Zhao from comment #25)
> > The source code need to be:
> > 
> > If (__builtin_get_counted_by (P->FAM))
> >   __builtin_get_counted_by (P->FAM) = COUNT;
> > 
> > Yes, I agree that this is good too for the original purpose. And also even
> > simpler and more flexible.
> > Kees might have more comments here. (Not sure any other impact on handling
> > the original problem he had with the new __builtin_get_counted_by).
> 
> Yeah, I like this. It gives much more obvious semantics instead of hiding a
> no-op, and this could be used for _reading_ as well as writing the value.
> This means we could also write, for example, loop constructs with only the
> FAM:
> 
> 
>   typeof(*__builtin_get_counted_by(P->FAM)) idx;
> 
>   for (idx = 0; idx < *__builtin_get_counted_by(P->FAM); idx++)
> do_things(P->FAM[idx]);

I have a rough version of __builtin_set_counted_by working in Clang. I'm not
happy with it because it hides no-ops. I think the suggestions here are going
in the correct direction. I'd like to throw out some alternatives so that the
builtins could be more general.

If we had a way of testing for an attribute, we could avoid the need to return
( void *)0 when the '__builtin_get' can't find the attribute:

  __builtin_has_attr (ptr, attr_name);

We could then have a builtin to get the attribute's argument:

  __builtin_get_attr_arg (ptr, attr_name)

This could have an optional argument to specify which argument to get if the
attr has more than one:

  __builtin_get_attr_arg (ptr, attr_name, pos)

If we do all of this, we could use it directly to set the value:

  if (__builtin_has_attr (ptr->FAM, counted_by))
ptr->__builtin_get_attr_arg (ptr-FAM, counted_by, 0) = count;

If the user requires the value be set, they could do something a bit more
drastic in the 'else' case:

  size_t *counted_by_field = NULL; /* size_t or whatever type */

  if (__builtin_has_attr (ptr->FAM, counted_by))
counted_by = &ptr->__builtin_get_attr_arg (ptr-FAM, counted_by, 0);

  if (!counted_by)
/* Do something horrible and slow */

It's more verbose, but it makes the programmer think about the case when either
the 'counted_by' attribute (or any other attribute) doesn't exist. It also
eases the burden on the compiler to look through arbitrary casts for the FAM /
count objects in a struct (this is probably more of an issue with Clang than
GCC). It's also generic which allows us to use it for any future expansions.

[Bug middle-end/116146] New: Split insn-recog.cc

2024-07-30 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146

Bug ID: 116146
   Summary: Split insn-recog.cc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: mark at gcc dot gnu.org, rdapp at gcc dot gnu.org,
tnfchris at gcc dot gnu.org
Blocks: 84402
  Target Milestone: ---

We've split insn-emit.cc (PR54179) as well as gimple-match.cc.

The remaining big beast is insn-recog.cc which comes up in PR111619, PR111600,
and elsewhere.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
[Bug 84402] [meta] GCC build system: parallelism bottleneck

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread qinzhao at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #34 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #33)
> 
> If we had a way of testing for an attribute, we could avoid the need to
> return ( void *)0 when the '__builtin_get' can't find the attribute:
> 
>   __builtin_has_attr (ptr, attr_name);

GCC currently supports such builtin already:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fhas_005fattribute

Built-in Function: bool __builtin_has_attribute (type-or-expression, attribute)

[Bug ada/116147] New: ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

Bug ID: 116147
   Summary: ADA Cross Compiler for ARM does not build
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dldudley at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Attempting to generate a cross-compiler for ada target=arm-rtems6_eabi.

Using git master download (current release, I think is 15?).

Compiler runs for a while, producing the c compiler successfully, then produces
a "unrecognized intrinsic subprogram" error.

Produces the same error for Sparc, MIPS, and msp430.  Native compilation works
with no error.

Can compile C, C++, and Fortran for the same machines.

David Dudley


[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-30
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What exact configure and make command did you run. Can you attach the log file?

This works for others just fine so I am suspecting just a configure/build issue
on your side.

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #2 from David Dudley  ---
Created attachment 58775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58775&action=edit
Configuration Log file

Configuration log file saved from configuration script

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #3 from David Dudley  ---
Created attachment 58776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58776&action=edit
config log file from compile

[Bug testsuite/116148] New: [15 regression] c-c++-common/fam-in-union-alone-in-struct-2.c fails after r15-2403-g136f364e26d9ad

2024-07-30 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148

Bug ID: 116148
   Summary: [15 regression]
c-c++-common/fam-in-union-alone-in-struct-2.c fails
after r15-2403-g136f364e26d9ad
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:136f364e26d9ad4f05e0005e480813cdc8f56c96, r15-2403-g136f364e26d9ad

This now fails on big endian systems on powerpc64.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg.exp=c-c++-common/fam-in-union-alone-in-struct-2.c"
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -Wc++-compat  execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -Wc++-compat  execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++17 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++98 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++26 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++17 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++98 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++26 execution
test


(gdb) run
Starting program:
/home/seurer/gcc/git/build/gcc-test/fam-in-union-alone-in-struct-2.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=6,
no_tid=) at pthread_kill.c:44
44  pthread_kill.c: No such file or directory.
(gdb) where
#0  __pthread_kill_implementation (threadid=, signo=6,
no_tid=) at pthread_kill.c:44
#1  0x77642504 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#2  0x7762633c in __GI_abort () at abort.c:79
#3  0x15f8 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c:35


commit 136f364e26d9ad4f05e0005e480813cdc8f56c96 (HEAD)
Author: Sam James 
Date:   Tue Jul 30 11:08:31 2024 +0100

testsuite: fix dg-do run whitespace

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #4 from Andrew Pinski  ---
So iirc for building a cross Ada compiler you need to first build a new native
one for the same version. Did you do that?

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #5 from Andrew Pinski  ---
Also the full build log would be useful rather than just the config logs.

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #6 from David Dudley  ---
Created attachment 58777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58777&action=edit
Building log

Heres the building log

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #7 from David Dudley  ---
Building a native compiler using this version may be the actual error.  There
isn't exactly a plethora of information on how to generate this.

I've generated a native compiler currently, but seem to have a problem with
getting gnat to use that version when I try to cross-compile.  Doesn't seem to
be able to find the native compiler I generated, even if it is at the beginning
of the path.

[Bug target/68015] ICE in s390_emit_compare

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68015

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2421-gacc70606c59e3f14072cc8a164362e728d8df5d6
Author: Sam James 
Date:   Tue Jul 30 20:04:40 2024 +0100

testsuite: fix 'dg-compile' typos

'dg-compile' is not a thing, replace it with 'dg-do compile'.

PR target/68015
PR c++/83979
* c-c++-common/goacc/loop-shape.c: Fix 'dg-compile' typo.
* g++.dg/pr83979.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/attributes_2.C: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-7.c: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-8.c: Likewise.
* gcc.target/riscv/amo/zabha-rvwmo-all-amo-ops-char.c: Likewise.
* gcc.target/riscv/amo/zabha-rvwmo-all-amo-ops-short.c: Likewise.
* gcc.target/s390/20181024-1.c: Likewise.
* gcc.target/s390/addr-constraints-1.c: Likewise.
* gcc.target/s390/arch12/aghsghmgh-1.c: Likewise.
* gcc.target/s390/arch12/mul-1.c: Likewise.
* gcc.target/s390/arch13/bitops-1.c: Likewise.
* gcc.target/s390/arch13/bitops-2.c: Likewise.
* gcc.target/s390/arch13/fp-signedint-convert-1.c: Likewise.
* gcc.target/s390/arch13/fp-unsignedint-convert-1.c: Likewise.
* gcc.target/s390/arch13/popcount-1.c: Likewise.
* gcc.target/s390/pr68015.c: Likewise.
* gcc.target/s390/vector/fp-signedint-convert-1.c: Likewise.
* gcc.target/s390/vector/fp-unsignedint-convert-1.c: Likewise.
* gcc.target/s390/vector/reverse-elements-1.c: Likewise.
* gcc.target/s390/vector/reverse-elements-2.c: Likewise.
* gcc.target/s390/vector/reverse-elements-3.c: Likewise.
* gcc.target/s390/vector/reverse-elements-4.c: Likewise.
* gcc.target/s390/vector/reverse-elements-5.c: Likewise.
* gcc.target/s390/vector/reverse-elements-6.c: Likewise.
* gcc.target/s390/vector/reverse-elements-7.c: Likewise.
* gnat.dg/alignment15.adb: Likewise.
* gnat.dg/debug4.adb: Likewise.
* gnat.dg/inline21.adb: Likewise.
* gnat.dg/inline22.adb: Likewise.
* gnat.dg/opt37.adb: Likewise.
* gnat.dg/warn13.adb: Likewise.

[Bug c++/83979] [8 Regression] ICE with pointer comparison

2024-07-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-2421-gacc70606c59e3f14072cc8a164362e728d8df5d6
Author: Sam James 
Date:   Tue Jul 30 20:04:40 2024 +0100

testsuite: fix 'dg-compile' typos

'dg-compile' is not a thing, replace it with 'dg-do compile'.

PR target/68015
PR c++/83979
* c-c++-common/goacc/loop-shape.c: Fix 'dg-compile' typo.
* g++.dg/pr83979.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/attributes_2.C: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-7.c: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-8.c: Likewise.
* gcc.target/riscv/amo/zabha-rvwmo-all-amo-ops-char.c: Likewise.
* gcc.target/riscv/amo/zabha-rvwmo-all-amo-ops-short.c: Likewise.
* gcc.target/s390/20181024-1.c: Likewise.
* gcc.target/s390/addr-constraints-1.c: Likewise.
* gcc.target/s390/arch12/aghsghmgh-1.c: Likewise.
* gcc.target/s390/arch12/mul-1.c: Likewise.
* gcc.target/s390/arch13/bitops-1.c: Likewise.
* gcc.target/s390/arch13/bitops-2.c: Likewise.
* gcc.target/s390/arch13/fp-signedint-convert-1.c: Likewise.
* gcc.target/s390/arch13/fp-unsignedint-convert-1.c: Likewise.
* gcc.target/s390/arch13/popcount-1.c: Likewise.
* gcc.target/s390/pr68015.c: Likewise.
* gcc.target/s390/vector/fp-signedint-convert-1.c: Likewise.
* gcc.target/s390/vector/fp-unsignedint-convert-1.c: Likewise.
* gcc.target/s390/vector/reverse-elements-1.c: Likewise.
* gcc.target/s390/vector/reverse-elements-2.c: Likewise.
* gcc.target/s390/vector/reverse-elements-3.c: Likewise.
* gcc.target/s390/vector/reverse-elements-4.c: Likewise.
* gcc.target/s390/vector/reverse-elements-5.c: Likewise.
* gcc.target/s390/vector/reverse-elements-6.c: Likewise.
* gcc.target/s390/vector/reverse-elements-7.c: Likewise.
* gnat.dg/alignment15.adb: Likewise.
* gnat.dg/debug4.adb: Likewise.
* gnat.dg/inline21.adb: Likewise.
* gnat.dg/inline22.adb: Likewise.
* gnat.dg/opt37.adb: Likewise.
* gnat.dg/warn13.adb: Likewise.

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread dldudley at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #8 from David Dudley  ---
Debian has version 12.2.0 that it installs.  Perhaps I need to backup and
checkout that version for a cross compiler?

Since this is an experimental project I'm working toward, I thought using the
"master" version might help in verifying the compilers operation for the
future.  I didn't see any reason to backup to a previous version instead of
figuring out what's wrong with my process.

[Bug rtl-optimization/116136] [15 Regression] ext-dce exposes latent subreg simplification bug (big-endian) on m68k

2024-07-30 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116136

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ada/116147] ADA Cross Compiler for ARM does not build

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116147

--- Comment #9 from Andrew Pinski  ---
What you need to do is build a native compiler first and install it somewhere
(does not matter where; maybe say using --prefix=${HOME}/native-build).
And then set PATH env to include ${HOME}/native-build/bin and then build the
cross compiler using that new compiler.

[Bug testsuite/116148] c-c++-common/fam-in-union-alone-in-struct-2.c fails on big-endian (finally tested starting with r15-2403-g136f364e26d9ad)

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148

Andrew Pinski  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53548

--- Comment #1 from Andrew Pinski  ---
This testcase was only designed for little-endian ...

[Bug testsuite/116148] c-c++-common/fam-in-union-alone-in-struct-2.c fails on big-endian (finally tested starting with r15-2403-g136f364e26d9ad)

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116148

Andrew Pinski  changed:

   What|Removed |Added

  Build|powerpc64-linux-gnu |
   Host|powerpc64-linux-gnu |
   Keywords||testsuite-fail
 Target|powerpc64-linux-gnu |powerpc*-linux-gnu
   ||aarch64_be-*-* mips*-*-*

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> This testcase was only designed for little-endian ...

That is it needs some changes to the checks to allow to run correctly on
big-endian.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread qinzhao at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #33)
> 
> We could then have a builtin to get the attribute's argument:
> 
>   __builtin_get_attr_arg (ptr, attr_name);

not sure whether it's worth the effort to provide this general builtin or not
for all the attributes. the main question is, what's the exact attribute's
argument for each of the attributes that the compiler provided.

But, I think it's a good idea to further simplify the functionality of the new
builtin __builtin_get_counted_by (P->FAM) by eliminating the check for whether
"P->FAM) has the counted_by attribute, instead, this new builtin assumes that
"P->FAM" has the counted_by attribute, just return the corresponding counted_by
field.

Then, the user needs to write the following:

if (__builtin_has_attribute (P->FAM, counted_by))
   *__builtin_get_counted_by (P->FAM) = COUNT

[Bug other/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently

2024-07-30 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> Yup, that sounds eminently plausible :-)  Thanks.

For the given that error message, yes, it seems plausible.  But I don't know
how an error like that can be intermittent.  I would expect if we pass the same
objects to the linker, the result should 100% be the same every time.

[Bug c/116130] Implement C23 N2956 paper - [[unsequenced]] and [[reproducible]] function type arguments

2024-07-30 Thread jsm28 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116130

--- Comment #12 from Joseph S. Myers  ---
N3096 is a very old draft with lots of mistakes. Use N3220 instead (it has no
technical changes relative to C23, though it's also missing many late editorial
fixes required by ISO).

Composite types for conditional expressions are as intended.  [[noreturn]] is
not a type attribute but a declaration attribute (and GNU noreturn on types
merges differently).  Accordingly, C23 deliberately does not add the new type
attributes to any existing functions that were in previous C standard versions,
precisely because that would invalidate existing code that used conditional
expressions and was valid with previous standard versions.  It *does* put
[[unsequenced]] on the  functions, as they are new in C23, and it
would be appropriate for glibc to do likewise (when building with a compiler
supporting [[__unsequenced__]]) - though as the out-of-line functions won't
normally be used, and already use __attribute_const__, the effects of doing so
would be small (and it's always OK not to have the attribute in the header,
since any program valid with it there is also valid without it).

[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org
   Last reconfirmed||2024-07-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Arsen Arsenović  ---
the sequencing rule is a bit annoying here, we determine the result of the
initial coroutine call only after the first suspend (which might not be the
initial suspend), but I think we can do this correctly anyway.  currently, we
use an intermediary variable called _Coro_gro in the case you showed, hence the
difference in behavior.  confirmed

[Bug middle-end/116138] [15 regression] profiledbootstrap broken on aarch64 since r15-2196-g88d16194d0c8a6

2024-07-30 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116138

Sam James  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Sam James  ---
https://inbox.sourceware.org/gcc-regression/2e1530e1-b970-4657-a773-f014f2fd5...@gmail.com/T/#t
too, I suppose?

[Bug c++/115207] [constexpr] constexpr assignment rejected as non const on self-assignment test

2024-07-30 Thread herring at lanl dot gov via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #1 from S. Davis Herring  ---
This looks like yet another duplicate of 85944.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #36 from Jakub Jelinek  ---
(In reply to Bill Wendling from comment #33)
>   __builtin_get_attr_arg (ptr, attr_name)
> 
> This could have an optional argument to specify which argument to get if the
> attr has more than one:
> 
>   __builtin_get_attr_arg (ptr, attr_name, pos)

This is a bad idea.  The first argument of counted_by attribute is an
identifier, that isn't really useful for anything and how you'd return that? 
And for other attributes which do have arguments, what exactly the argument is
is heavily dependent on the attribute and there is simply no way how to
represent those easily.
Consider
  [[omp::sequence (directive (parallel private (p)),
omp::directive (single copyprivate (p) firstprivate (f) allocate (f)))]]
or
  __attribute__((mode (DI)))
or
  __attribute__((vector_size (16)))
or
  __attribute__ ((__format__(__printf__, 1, 2)))
or
  [[gnu::alias ("foobar")]]
etc.
What would be the argument of some of these attributes for the return of the
builtin, what types it would have, ...?

[Bug middle-end/115637] gimple_regimplify_operands doesn't handle VALUE_EXPR inside a MEM_REF / OpenMP declare target link

2024-07-30 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637

--- Comment #2 from Tobias Burnus  ---
Patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658737.html

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

2024-07-30 Thread isanbard at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016

--- Comment #37 from Bill Wendling  ---
(In reply to Jakub Jelinek from comment #36)
> (In reply to Bill Wendling from comment #33)
> >   __builtin_get_attr_arg (ptr, attr_name)
> > 
> > This could have an optional argument to specify which argument to get if the
> > attr has more than one:
> > 
> >   __builtin_get_attr_arg (ptr, attr_name, pos)
> 
> This is a bad idea.  The first argument of counted_by attribute is an
> identifier, that isn't really useful for anything and how you'd return that?
> And for other attributes which do have arguments, what exactly the argument
> is is heavily dependent on the attribute and there is simply no way how to
> represent those easily.
> Consider
>   [[omp::sequence (directive (parallel private (p)),
> omp::directive (single copyprivate (p) firstprivate (f) allocate (f)))]]
> or
>   __attribute__((mode (DI)))
> or
>   __attribute__((vector_size (16)))
> or
>   __attribute__ ((__format__(__printf__, 1, 2)))
> or
>   [[gnu::alias ("foobar")]]
> etc.
> What would be the argument of some of these attributes for the return of the
> builtin, what types it would have, ...?

I realized my error after sending this. So yeah it's not going to work. I'm
okay with what's being discussed. I just want to make it clear to the
programmer that it's _possible_ that the builtin may become a no-op and they
need to handle that, which will be DCE'ed if the attribute exists, etc.

That does make me wonder at the usefulness of this feature. The user will need
to set the count whether or not this builtin is used (either because
'counted_by' wasn't specified or the compiler couldn't find the COUNT variable
for some reason (a compiler bug, but still...)). Isn't that basically creating
a feature useful for only this specific use case?

[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression

2024-07-30 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600

Sam James  changed:

   What|Removed |Added

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

--- Comment #36 from Sam James  ---
I filed PR116146 for insn-recog, but mjw's case seems to be something
pathological with jump threading.

[Bug target/116149] New: RISC-V: Miscompile at -O3 with zvl256b -mrvv-vector-bits=zvl

2024-07-30 Thread patrick at rivosinc dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116149

Bug ID: 116149
   Summary: RISC-V: Miscompile at -O3 with zvl256b
-mrvv-vector-bits=zvl
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
long a;
short b[6];
short c[20];
int main() {
  for (short d = 0; d < 20; d += 3) {
c[d] = 0;
for (int e = 0; e < 20; e += 2)
  for (int f = 1; f < 20; f += 2)
a += (unsigned)b[f + e];
  }
  __builtin_printf("%lu\n", a);
}

Commands:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl256b -O3 -mrvv-vector-bits=zvl red.c -o red.out
> QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 red.out
18446744073709551613

> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv_zvl256b -O2 -mrvv-vector-bits=zvl red.c -o red.out
> QEMU_CPU=rv64,vlen=256,rvv_ta_all_1s=true,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
>  timeout --verbose -k 0.1 4 
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 red.out
0

Still present when rvv_ta_all_1s=true is omitted.

Found via fuzzer

[Bug bootstrap/116146] Split insn-recog.cc

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||internal-improvement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|middle-end  |bootstrap
   Last reconfirmed||2024-07-30

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

[Bug c++/115207] [constexpr] constexpr assignment rejected as non const on self-assignment test

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yes it is a dup of bug 85944.

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

[Bug c++/85944] Address of temporary at global scope not considered constexpr

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944

Andrew Pinski  changed:

   What|Removed |Added

 CC||nov.ondrej at gmail dot com

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

[Bug c++/55004] [meta-bug] constexpr issues

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 115207, which changed state.

Bug 115207 Summary: [constexpr] constexpr assignment rejected as non const on 
self-assignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207

   What|Removed |Added

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

[Bug tree-optimization/15596] [12/13/14/15 Regression] Missed optimization with bitfields with return value

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #40 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/45274] __restrict__ type qualifier does not work on pointers to bitfields

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45274

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug target/116150] New: RISC-V: Differences between GCC/LLVM

2024-07-30 Thread patrick at rivosinc dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116150

Bug ID: 116150
   Summary: RISC-V: Differences between GCC/LLVM
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

A byproduct of my first sweep through the ISA strings with a random generator.
Extensions were seeded with -print-supported-exts from a few days ago. Ignored
profiles, experimental extensions, and extension versions. This isn't
guaranteed to be a complete list.

ilp32e 'd' extension handling:
https://inbox.sourceware.org/gcc-patches/20240730213254.199844-1-patr...@rivosinc.com/T/#u

Implied extensions:
LLVM zabha does not imply zaamo, gcc does: https://godbolt.org/z/nd6jz1vbc
LLVM all zvk* throw this error: "'zvk*' requires 'v' or 'zve*' extension to
also be specified" on GCC v is implied: https://godbolt.org/z/Pb9KWr9Y8

Unsupported (LLVM-only exts):
shcounterenw
shgatpa
shtvala
shvsatpa
shvstvala
shvstvecd
smcdeleg
smcsrind
ssccfg
ssccptr
sscounterenw
sscsrind
ssstrict
sstvala
sstvecd
ssu64xl
svade
svadu
svbare
xcvbitmanip
xcvmem
xsfvfnrclipxfqf
xsfvfwmaccqqq
xsfvqmaccdod
xsfvqmaccqoq
xsifivecdiscarddlone
xsifivecflushdlone
xtheadvdot
xwchc
zama16b
zcmop
zimop

Supported by GCC, unsupported by LLVM:
xtheadfmv
xtheadint
xtheadvector

[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/83784] Missed optimization with bitfield

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/95097] Missed optimization with bitfield value ranges

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95097

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/81161] poor code concatenating bitfields

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81161

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/96172] Failure to optimize direct assignment to bitfield through shifts

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96172

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/101705] Missed optimization opportunity when copying lots of bitfields

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/103457] boolean operations on bit-fields are not merged

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103457

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Target Milestone|13.4|---

--- Comment #6 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/106076] Sub-optimal code is generated for checking bitfields via proxy functions

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106076

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109637

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/45217] Tree optimizations do not recognize partial stores

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45217

--- Comment #4 from Andrew Pinski  ---
So I think isel should be able to recognize these. So I will be trying to
finish this up for GCC 15.

[Bug middle-end/107601] Change SLOW_BYTE_ACCESS into WIDEN_MODE_ACCESS_BITFIELD target hook

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107601

--- Comment #4 from Andrew Pinski  ---
Even though this is bitfield related, this is some cleanup I am still aiming on
working on during GCC 15.

[Bug middle-end/107047] load introduced of struct/union fields after assigning it to a local variable

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107047

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug middle-end/107047] load introduced of struct/union fields after assigning it to a local variable

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107047

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug tree-optimization/51428] Some code after SSA expand does nothing

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51428

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug c++/116151] New: [7.1 Regression] G++ fails to diagnose -Waggressive-loop-optimizations when going past the end of an array

2024-07-30 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116151

Bug ID: 116151
   Summary: [7.1 Regression] G++ fails to diagnose
-Waggressive-loop-optimizations when going past the
end of an array
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsen at gcc dot gnu.org
  Target Milestone: ---

The following code, in C++ mode since GCC 7.1 (works on 6.5), at -O3 creates an
infinite loop and fails to produce a diagnostic:

  void
  f ()
  {
  int arr[48];
  extern int g (int);
  for (int i = 0; i < 55; i++)
  arr[i] = g (arr[i]);
  }

... however, in C, the above produces a correct diagnostic (and a non-infinite
loop).

(reduced from https://bugs.gentoo.org/936237 )

[Bug tree-optimization/80770] suboptimal code negating a 1-bit _Bool field

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80770

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW
 Blocks||19466

--- Comment #4 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
[Bug 19466] [meta-bug] bit-fields are non optimal

[Bug middle-end/70871] questionable optimisation in fold-const.c

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
No longer working on bitfields optimization. Maybe in a few years I will be
again but not today.

[Bug middle-end/116151] [12/13/14/15 Regression] G++ fails to diagnose -Waggressive-loop-optimizations when going past the end of an array

2024-07-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116151

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||7.1.0
   Target Milestone|--- |12.5
  Component|c++ |middle-end
Summary|[7.1 Regression] G++ fails  |[12/13/14/15 Regression]
   |to diagnose |G++ fails to diagnose
   |-Waggressive-loop-optimizat |-Waggressive-loop-optimizat
   |ions when going past the|ions when going past the
   |end of an array |end of an array
   Keywords||diagnostic, needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2024-07-30
 Status|UNCONFIRMED |NEW
  Known to work||6.5.0

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

  1   2   >