date:20240426

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

2024-04-26 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #9 from Xi Ruoyao  ---
Fixed for 15 and 14.

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:3e04b6f6ba568e6183e8aa8223d4156234503843

commit r14-10142-g3e04b6f6ba568e6183e8aa8223d4156234503843
Author: Xi Ruoyao 
Date:   Fri Apr 26 15:59:11 2024 +0800

LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]

Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:

drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
  (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
   (and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
   (const_int -50331649 [0xfcff])))
  "drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
  {*bstrins_di_for_mask}
  (nil))

Add these constrants to fix the issue.

gcc/ChangeLog:

PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.

gcc/testsuite/ChangeLog:

PR target/114861
* gcc.target/loongarch/pr114861.c: New test.

(cherry picked from commit 140124ad54eef88ca87909f63aedc8aaeacefc65)

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:140124ad54eef88ca87909f63aedc8aaeacefc65

commit r15-11-g140124ad54eef88ca87909f63aedc8aaeacefc65
Author: Xi Ruoyao 
Date:   Fri Apr 26 15:59:11 2024 +0800

LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]

Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:

drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
  (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
   (and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
   (const_int -50331649 [0xfcff])))
  "drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
  {*bstrins_di_for_mask}
  (nil))

Add these constrants to fix the issue.

gcc/ChangeLog:

PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.

gcc/testsuite/ChangeLog:

PR target/114861
* gcc.target/loongarch/pr114861.c: New test.

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

2024-04-26 Thread jvdelisle at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from Jerry DeLisle  ---
(In reply to Matt Thompson from comment #14)
> Never mind. I'll send attachment to Jerry offline. It's too big for here.

Got it. It works quite well for our purposes.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #13 from Peter Dimov  ---
(In reply to Andrew Pinski from comment #10)
> #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
>   __builtin_clear_padding(std::__addressof(_M_i));
> #endif
> 
> So yes it is definitely dependent on C++ level ...
> That is for C++14+ it is working correctly.

Oh, that's the constructor of `atomic`. I thought it was the compiler
initializing the padding in C++14 and above.

I wonder why `__cplusplus >= 201402L` is here.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #11)
> So, basically, C++14 and above initialize the padding of
> 
> ```
> std::atomic state{{ 0, 0x }};
> ```
> 
> in `main` to zero, which masks the problem in `generate`. (The problem in
> `generate` still exists because the assembly is identical - it just doesn't
> trigger because the padding is zero. If we manually poke something nonzero
> into the padding, it would (ought to) still break.)

No there is no problem in generate for C++14+ because there is no way to get
the padding non-zero for that variable.

The problem is only with C++11's std::atomic ...
See PR 111077 and such.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #11 from Peter Dimov  ---
So, basically, C++14 and above initialize the padding of

```
std::atomic state{{ 0, 0x }};
```

in `main` to zero, which masks the problem in `generate`. (The problem in
`generate` still exists because the assembly is identical - it just doesn't
trigger because the padding is zero. If we manually poke something nonzero into
the padding, it would (ought to) still break.)

Static variables work for the same reason - the padding is guaranteed zero.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13/14/15 Regression]   |[13/14/15 Regression]
   |std::atomic::compare_exc |std::atomic::compare_exc
   |hange_strong seems to hang  |hange_strong seems to hang
   |under GCC 13 on Ubuntu  |under GCC 13  for C++11
   |23.04   |

--- Comment #10 from Andrew Pinski  ---
#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
  __builtin_clear_padding(std::__addressof(_M_i));
#endif

So yes it is definitely dependent on C++ level ...
That is for C++14+ it is working correctly.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #9 from Peter Dimov  ---
Oh, my mistake. C++14 does mov QWORD, and C++11 does mov WORD.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #8 from Peter Dimov  ---
(In reply to Andrew Pinski from comment #6)
> No it is dependent on the standard level. C++11 fails but C++14, C++17 and
> C++20 all pass.

That's interesting because I see basically no difference in the generated code
on CE between 11 and 14:

--- "C++-x86-64 gcc 13.2-1 (1).asm" 2024-04-27 03:25:11.149385400 +0300
+++ "C++-x86-64 gcc 13.2-1.asm" 2024-04-27 03:24:59.207244400 +0300
@@ -76,10 +76,11 @@
 jmp .L8
 main:
 pushrbx
+mov eax, 8738
 mov ebx, 1024
 sub rsp, 16
 mov QWORD PTR [rsp], 0
-mov QWORD PTR [rsp+8], 8738
+mov WORD PTR [rsp+8], ax
 .L14:
 mov rdi, rsp
 callgenerate(std::atomic*)

(https://godbolt.org/z/nexn5W4Ph)

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Andrew Pinski  ---
The problem is only with auto atomic variables. Looks like the padding there is
not being zeroed for -std=c++11 ...

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #4)
>  but I believe it's independent of standard level and address model.

No it is dependent on the standard level. C++11 fails but C++14, C++17 and
C++20 all pass.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 58053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58053=edit
testcase

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #4 from Peter Dimov  ---
This

https://raw.githubusercontent.com/boostorg/uuid/feature/gcc_pr_114865/test/test_gcc_pr114865.cpp

exhibits the problem for me on GCC 13/14. I'm only seeing the hang with
-std=c++11 -m32 in the CI run because this combination is tested first, but I
believe it's independent of standard level and address model.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-26
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Can you provide a full runable testcase which shows the issue rather than just
code snippets? 

And not just link to godbolt. You can attach it. In this case we don't need the
preprocesed source since it is about the library that is having issue. Please
make sure it only depends on the libstdc++/libc headers too.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|std::atomic::compare_exc |[13/14/15 Regression]
   |hange_strong seems to hang  |std::atomic::compare_exc
   |under GCC 13 on Ubuntu  |hange_strong seems to hang
   |23.04   |under GCC 13 on Ubuntu
   ||23.04
   Target Milestone|--- |13.3

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Christophe Lyon  ---
Thanks for the suggestion, this works.
I've posted the patch + testcase:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Andrew Pinski  ---
Patches posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650085.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650084.html

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58043|0   |1
is obsolete||

--- Comment #19 from Andrew Pinski  ---
Created attachment 58052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58052=edit
v2 of the patch

I am attaching this here just so I don't lose it; it includes the fix for the
case mentioned. I am not going to post this version to the list. I will be
doing a v3 which I will post which contains the rewrite part.

[Bug tree-optimization/113673] [12/13/14/15 Regression] ICE: verify_flow_info failed: BB 5 cannot throw but has an EH edge with -Os -finstrument-functions -fnon-call-exceptions -ftrapv

2024-04-26 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED

--- Comment #6 from Roger Sayle  ---
Created attachment 58051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58051=edit
proposed patch

Bootstrapping and regression testing the attached patch.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from Jakub Jelinek  ---
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
suggests that it is a UB if all the bits for a single element aren't the same
(i.e. false is all 0s, true is all 1s aka -1, anything else UB).
So the testcase is invalid at runtime, right?
It probably shouldn't error because it can be in dead code, and it certainly
shouldn't ICE, it could emit __builtin_trap or it can just canonicalize it any
way it likes it.

Seems you are canonicalizing that to 1s, given the HW behavior I think it would
be more correct to canonicalize to -1s.

I think you could simply canonicalize on the CONST_INT, so
   else if (VALID_MVE_PRED_MODE (mode))
 {
   if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
 {
   /* In V8BI or V4BI each element has 2 or 4 bits, if those
  bits aren't all the same, it is UB and gen_lowpart might
  ICE.  Canonicalize all the 2 or 4 bits to all ones if
  any of them is non-zero.  */
   unsigned HOST_WIDE_INT xi = UINTVAL (xi);
   xi |= ((xi & 0x) << 1) | ((xi & 0x) >> 1);
   if (mode == V4BImode)
 xi |= ((xi & 0x) << 2) | ((xi & 0x) >> 2);
   x = gen_int_mode (xi, HImode);
 }
   else if (SUBREG_P (x))
 /* gen_lowpart on a SUBREG can ICE.  */
 x = force_reg (GET_MODE (x), x);
   x = gen_lowpart (mode, x);
 }

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from Christophe Lyon  ---
Created attachment 58050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050=edit
patch proposal

Here is the patch I propose.

[Bug c++/114685] [modules] ICE when exporting a type through a different alias then one declared in GMF

2024-04-26 Thread m.cencora at gmail dot com via Gcc-bugs

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

--- Comment #4 from m.cencora at gmail dot com ---
I've stumbled upon a related error when trying to export std::vector after
inclusion of  in GMF:

module;

namespace std
{
class vector;
namespace __format {
using std::vector;
}
}

export module std;

export namespace std {
#ifdef WORKAROUND
namespace __format {}
#endif
using std::vector;
}

[Bug c/114870] New: stddef.h problem with -Wsystem-headers on Fedora 40

2024-04-26 Thread eggert at cs dot ucla.edu via Gcc-bugs

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

Bug ID: 114870
   Summary: stddef.h problem with -Wsystem-headers on Fedora 40
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 58049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58049=edit
fix stddef.h to survive multiple includes, some with __need_size_t etc.

I found this when trying to build GNU diffutils on Fedora 40. This is gcc (GCC)
14.0.1 20240411 (Red Hat 14.0.1-0) on x86-64. Compile the following two-line
program t.c with 'gcc -std=gnu23  -Wsystem-headers -E t.c >t.i':

  #include 
  #include 

GCC issues the following diagnostics:

  In file included from /usr/include/time.h:29,
   from t.c:2:
  /usr/lib/gcc/x86_64-redhat-linux/14/include/stddef.h:457:9: warning:
"__STDC_VERSION_STDDEF_H__" redefined
457 | #define __STDC_VERSION_STDDEF_H__   202311L
| ^
  In file included from t.c:1:
  /usr/lib/gcc/x86_64-redhat-linux/14/include/stddef.h:457:9: note: this is the
location of the previous definition
457 | #define __STDC_VERSION_STDDEF_H__   202311L
| ^

It seems that  is not properly protected against multiple includes,
some with __need_size_t and __need_NULL and some without.

The attached patch to stddef.h worked around the problem for me.

[Bug c/114869] New: GCC says nullptr_t is a C built in but it should be in

2024-04-26 Thread eggert at cs dot ucla.edu via Gcc-bugs

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

Bug ID: 114869
   Summary: GCC says nullptr_t is a C built in but it should be in

   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

This is gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0) on x86-64. Compile the
following one-line program with 'gcc -S t.c':

   nullptr_t x;

GCC fails to issue a diagnostic that is required because nullptr_t is used
without being defined.

Conversely, compile the following program with 'gcc -std=gnu23 -Wshadow
-Wsystem-headers -S t.c':

   #include 
   nullptr_t x;

GCC issues the following incorrect diagnostic:

  In file included from t.c:1:
  /usr/lib/gcc/x86_64-redhat-linux/14/include/stddef.h:450:31: warning:
declaration of ‘nullptr_t’ shadows a global declaration [-Wshadow]
450 |   typedef __typeof__(nullptr) nullptr_t;
|   ^
  cc1: note: shadowed declaration is here

It seems that gcc defines nullptr_t as a built in identifier, which is
incorrect; nullptr_t should be defined by  just like ptrdiff_t is.

[Bug middle-end/114855] ICE: Segfault

2024-04-26 Thread jeremy.rutman at gmail dot com via Gcc-bugs

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

--- Comment #5 from jeremy rutman  ---
Using gcc 14.0.1 20240117 (experimental) [master r14-8187-gb00be6f1576] I was
able to compile when not using any flags:

$ /usr/lib/gcc-snapshot/bin/cc -c aesDecrypt.c -o aesDecrypt.o

But when using the flags as before 

$  /usr/lib/gcc-snapshot/bin/cc -Wall -O3 -DNDEBUG -fomit-frame-pointer -c
aesDecrypt.c -o aesDecrypt.o

the compile kept going for at least one hour on my machine before I aborted.

[Bug libstdc++/114865] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #2 from Peter Dimov  ---
The issue is also present for GCC 14 on Ubuntu 24.04:

https://github.com/boostorg/uuid/actions/runs/8853249656/job/24313667955

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

2024-04-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 58048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58048=edit
Partial patch

This patch fixes the scalar case in comment#0 by computing _size*_len
and regtests cleanly.  It does not cover the array case.

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

2024-04-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #13 from anlauf at gcc dot gnu.org ---
Also fixed on 12-branch:

commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a
Author: Paul Thomas 
Date:   Tue May 23 06:46:37 2023 +0100

Fortran: Fix assumed length chars and len inquiry [PR103716]

2023-05-23  Paul Thomas  

gcc/fortran
PR fortran/103716
* resolve.cc (gfc_resolve_ref): Conversion of array_ref into an
element should be done for all characters without a len expr,
not just deferred lens, and for integer expressions.
* trans-expr.cc (conv_inquiry): For len and kind inquiry refs,
set the se string_length to NULL_TREE.

gcc/testsuite/
PR fortran/103716
* gfortran.dg/pr103716.f90 : New test.

(cherry picked from commit 842a432b02238361ecc601d301ac400a7f30f4fa)


The ICE is gone.  A remaining accepts-invalid on 11-branch could be fixed
by backporting the above if needed.

Thanks for the report to Gerhard, and to Paul for the above patch.  Closing.

[Bug c++/114868] New: [modules] func declared in GMF and exported via using-decl in module partition is not actually exported

2024-04-26 Thread m.cencora at gmail dot com via Gcc-bugs

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

Bug ID: 114868
   Summary: [modules] func declared in GMF and exported via
using-decl in module partition is not actually
exported
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

$ cat mod.cpp 
export module mod;
export import :part;

export void foo()
{
}

$ cat mod-part.cpp 
module;

#include "bar.hpp"

export module mod:part;

export using ::bar;

export void bar_non_gmf()
{
}

$ cat usage.cpp 
import mod;

int main()
{
foo();
bar();
bar_non_gmf();
}

$ g++ -std=c++2b -fmodules-ts mod-part.cpp mod.cpp usage.cpp
usage.cpp: In function ‘int main()’:
usage.cpp:6:5: error: ‘bar’ was not declared in this scope
6 | bar();
  | ^~~

When I compile mod-part.cpp on its own, it seems that bar symbol is not emitted
in the object file:
$ g++ -std=c++2b -fmodules-ts mod-part.cpp -c -o mod-part.o
$ readelf -s mod-part.o | c++filt

Symbol table '.symtab' contains 5 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS mod-part.cpp
 2:  0 SECTION LOCAL  DEFAULT1 .text
 3: 11 FUNCGLOBAL DEFAULT1 bar_non_gmf@mod()
 4: 000b11 FUNCGLOBAL DEFAULT1 initializer for
module mod:part

[Bug fortran/103716] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15964 since r9-3803-ga5fbc2f36a291cbe

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a
Author: Paul Thomas 
Date:   Tue May 23 06:46:37 2023 +0100

Fortran: Fix assumed length chars and len inquiry [PR103716]

2023-05-23  Paul Thomas  

gcc/fortran
PR fortran/103716
* resolve.cc (gfc_resolve_ref): Conversion of array_ref into an
element should be done for all characters without a len expr,
not just deferred lens, and for integer expressions.
* trans-expr.cc (conv_inquiry): For len and kind inquiry refs,
set the se string_length to NULL_TREE.

gcc/testsuite/
PR fortran/103716
* gfortran.dg/pr103716.f90 : New test.

(cherry picked from commit 842a432b02238361ecc601d301ac400a7f30f4fa)

[Bug c++/114867] New: [modules] name lookup issues when a function overload set is exported from GMF

2024-04-26 Thread m.cencora at gmail dot com via Gcc-bugs

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

Bug ID: 114867
   Summary: [modules] name lookup issues when a function overload
set is exported from GMF
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

$ cat future.cpp 
module;

namespace std {
template
void swap(_Tp& a, _Tp& b);

namespace __exception_ptr {
class exception_ptr
{};
void swap(exception_ptr&, exception_ptr&);
}
using __exception_ptr::swap;

template < typename _Tp> struct shared_ptr {
  void swap(shared_ptr& other) { std::swap(_M_ptr, other._M_ptr); }
  _Tp *_M_ptr;
};

struct future {
  shared_ptr< void > _M_state;
  void operator=(future& other) { _M_state.swap(other._M_state); }
};
} // std

export module std;
namespace std {
using std::swap;
}

$ g++ -std=c++2b -fmodules-ts -Wno-global-module future.cpp

: In instantiation of 'void
std::shared_ptr<_Tp>::swap(std::shared_ptr<_Tp>&) [with _Tp = void]':
:23:48:   required from here
   23 |   void operator=(future& other) { _M_state.swap(other._M_state); }
  |   ~^~~~
:17:44: error: invalid initialization of reference of type
'std::__exception_ptr::exception_ptr&' from expression of type 'void*'
   17 |   void swap(shared_ptr& other) { std::swap(_M_ptr, other._M_ptr); }
  |^~
:10:11: note: in passing argument 1 of 'void
std::__exception_ptr::swap(exception_ptr&, exception_ptr&)'
   10 | void swap(exception_ptr&, exception_ptr&);
  |   ^~
:27:8: warning: not writing module 'std' due to errors
   27 | export module std;
  |^~

This is reduced code from an issue found when creating std
module(https://gcc.gnu.org/PR114600#c10)
module;

#include 

export module std;

export namespace std
{
using std::swap;
}



The problem seems to be that using __exception_ptr::swap; hides any other
previous declaration of swap function.
The workarounds is to move decl of template swap after the using
__exception_ptr::swap;

Also this compiles fine if we change shared_ptr::_M_ptr to not become a
template dependent type.

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

2024-04-26 Thread arthur.j.odwyer at gmail dot com via Gcc-bugs

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

--- Comment #3 from Arthur O'Dwyer  ---
https://github.com/boostorg/container/issues/153 , from 2020, is another
similar issue. There, boost::container::vector had assumed that if
__has_trivial_copy(T) and is_copy_constructible_v, then T could be relocated
via memcpy; but in fact __has_trivial_copy(T) is also true for move-only types.
So it was possible to create a type such that (__has_trivial_copy(T) &&
__is_constructible(T, T&)) and yet not __is_trivially_constructible(T, T&).

// https://godbolt.org/z/x5Wda1M6E
struct T {
template T(U&&);
T(T&&);
~T();
};
static_assert(__has_trivial_copy(T) && __is_constructible(T, T&));
  // ...and yet...
static_assert(not __is_trivially_constructible(T, T&));

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Wilco from comment #17)
> So I don't believe you should change aarch64_pop_regs at all - it's too late
> to change things and just adds unnecessary complexity and more bugs. The
> best option would be to handle eh_return explicitly and insert the extra
> push/pops rather than treating them like a generic callee-save (because
> clearly they are not anymore).

Thinking about this I think you are right, I will work on an incremental patch
to change them to be in seperate array. Note I do have a fix for the issue in
comment #17, I had a premature optimization thinking only if regno1 was an
eh_handler data register, then regno2 could be one; rather they should be
checked independently. I will attach that patch to this bug once my testing is
finished. And then will work on splitting out the eh_handler data register
load/stores.

[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68

2024-04-26 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #11)
> It would be splendid if you would backport the patch. In the last week or
> so, I have built up quite a list of backports to do, which I will attend to
> over the weekend.

Hi Paul,

I've checked and found that your r14-1082-g842a432b022383 also needs to
be backported to get all testcases here fixed on 12-branch.

When regtesting completes successfully, I will push it.

Re: for discussion: should we close all the Java-related bugs?

2024-04-26 Thread Andrew Pinski via Gcc-bugs

On Fri, Apr 26, 2024 at 11:28 AM Abe Skolnik via Gcc-bugs
 wrote:
>
> Dear all,
>
> AFAIK, GCJ has been dead for _years_...  quoting 
> : "As of GCC 7, the GCC Java frontend and 
> associated libjava runtime library have been removed from GCC. The 
> information on this page is kept here for reference but only applies to GCC 6 
> and earlier."
>
> ... yet we still have at least...
>
> 67 bugs open against the component "awt":  
> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=awt
>
> ... and at least...
>
> 479 bugs open against the product "classpath":  
> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=classpath
>
>
>
> For discussion: why not close _all_ Java-related bugs in the GCC bugzilla, 
> perhaps with a nicely-granular status such as 
> "CLOSED_WONTFIX___WONTFIX_BECAUSE_FEATURE_IS_DEPRECATED", or at least "good" 
> old "CLOSED_WONTFIX"?
>
>
>
> With all due respect to whoever [if anybody] is unhappily still responsible 
> for backporting bug-fixes to pre-7 GCC re e.g. the C or C++ or Fortran 
> compiler[s], I think the chances of _anybody_ *ever* fixing those old 
> Java-in-GCC bugs is _extremely_ tiny.

Note the classpath component is not about GCJ (and GCC) but rather it
is for the GNU classpath project which is not really active but it is
still a project and might become more active in the future. So closing
these as won't fix is NOT the correct thing to do unless the classpath
project itself has decided it no longer wants to use the GCC's
bugzilla instance or has decided it is no longer being a project.

Thanks,
Andrew Pinski

>
> Sincerely,
>
> Abe

for discussion: should we close all the Java-related bugs?

2024-04-26 Thread Abe Skolnik via Gcc-bugs

Dear all,

AFAIK, GCJ has been dead for _years_...  quoting 
: "As of GCC 7, the GCC Java frontend and 
associated libjava runtime library have been removed from GCC. The information 
on this page is kept here for reference but only applies to GCC 6 and earlier."

... yet we still have at least...

67 bugs open against the component "awt":  
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=awt

... and at least...

479 bugs open against the product "classpath":  
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__=classpath



For discussion: why not close _all_ Java-related bugs in the GCC bugzilla, 
perhaps with a nicely-granular status such as 
"CLOSED_WONTFIX___WONTFIX_BECAUSE_FEATURE_IS_DEPRECATED", or at least "good" 
old "CLOSED_WONTFIX"?



With all due respect to whoever [if anybody] is unhappily still responsible for 
backporting bug-fixes to pre-7 GCC re e.g. the C or C++ or Fortran compiler[s], 
I think the chances of _anybody_ *ever* fixing those old Java-in-GCC bugs is 
_extremely_ tiny.

Sincerely,

Abe

[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Jakub Jelinek  ---
Ah, the following shows what is happening and shows similar IL changes in the
*.optimized dump:
module m1
  type  amg_d_base_solver_type
  contains
procedure, pass(sv) :: free => amg_d_base_solver_free
  end type amg_d_base_solver_type
  interface
subroutine amg_d_base_solver_free(sv,x)
  import :: amg_d_base_solver_type
  implicit none
  class(amg_d_base_solver_type), intent(inout) :: sv
  integer,intent(inout)  :: x
end subroutine amg_d_base_solver_free
  end interface
end module m1
module m2
  use m1
  type  amg_d_base_smoother_type
class(amg_d_base_solver_type), allocatable :: sv
  contains
procedure, pass(sm) :: free => amg_d_base_smoother_free
  end type amg_d_base_smoother_type
  interface
subroutine amg_d_base_smoother_free(sm,x)
  import :: amg_d_base_smoother_type, amg_d_base_solver_type
  implicit none
  class(amg_d_base_smoother_type), intent(inout) :: sm
  integer,intent(inout)  :: x
end subroutine amg_d_base_smoother_free
  end interface
end module m2
module m3
  use m2
  type amg_d_onelev_type
class(amg_d_base_smoother_type), allocatable   :: sm
  end type amg_d_onelev_type
end module m3
subroutine foo (level, save1, info)
  use m1
  use m2
  use m3
  type(amg_d_onelev_type), intent(inout) :: level
  class(amg_d_base_smoother_type), allocatable , intent(inout) :: save1
  integer,intent(out) :: info
  info = 0
  if (allocated(save1)) then
call save1%free(info)
if (info  == 0) deallocate(save1,stat=info)
if (info /= 0) return
  end if
  allocate(save1, mold=level%sm,stat=info)
end subroutine

[Bug tree-optimization/99475] [11 Regression] bogus -Warray-bounds accessing an array element of empty structs

2024-04-26 Thread siddhesh at gcc dot gnu.org via Gcc-bugs

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gcc dot gnu.org

--- Comment #7 from Siddhesh Poyarekar  ---
This doesn't appear to be reproducible on trunk anymore, should we close it?

[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Jakub Jelinek  ---
I see there roughly
module m1
  type  amg_d_base_solver_type
  contains
procedure, pass(sv) :: apply_v => amg_d_base_solver_apply_vect
procedure, pass(sv) :: apply_a => amg_d_base_solver_apply
  end type amg_d_base_solver_type

  interface
subroutine amg_d_base_solver_apply_vect(alpha,sv,x)
  implicit none
  class(amg_d_base_solver_type), intent(inout) :: sv
  integer,intent(inout)  :: x
  real,intent(in) :: alpha
end subroutine amg_d_base_solver_apply_vect
  end interface

  interface
subroutine amg_d_base_solver_apply(alpha,sv,x)
  implicit none
  class(amg_d_base_solver_type), intent(inout) :: sv
  integer,intent(inout)  :: x
  real,intent(in) :: alpha
end subroutine amg_d_base_solver_apply
  end interface
end module m1
module m2
  use m1
  type  amg_d_base_smoother_type
class(amg_d_base_solver_type), allocatable :: sv
  contains
procedure, pass(sm) :: apply_v => amg_d_base_smoother_apply_vect
procedure, pass(sm) :: apply_a => amg_d_base_smoother_apply
  end type amg_d_base_smoother_type

  interface
subroutine amg_d_base_smoother_apply_vect(alpha,sm,x)
  implicit none
  class(amg_s_base_smoother_type), intent(inout) :: sm
  integer,intent(inout)  :: x
  real,intent(in) :: alpha
end subroutine amg_d_base_smoother_apply_vect
  end interface

  interface
subroutine amg_d_base_smoother_apply(alpha,sm,x)
  implicit none
  class(amg_s_base_smoother_type), intent(inout) :: sm
  integer,intent(inout)  :: x
  real,intent(in) :: alpha
end subroutine amg_d_base_smoother_apply
  end interface
end module m2
subroutine foo (save1)
  use m1, m2
  class(amg_d_base_smoother_type), allocatable , intent(inout) :: save1
  allocate(save1)
end subroutine

except that this doesn't compile.

[Bug libstdc++/114866] New: & out_ptr in freestanding

2024-04-26 Thread weidmann at acm dot org via Gcc-bugs

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

Bug ID: 114866
   Summary:  & out_ptr in freestanding
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weidmann at acm dot org
  Target Milestone: ---

With gcc version 14.0.1 20240411 (Red Hat 14.0.1-0) (GCC) on x86_64 GNU/Linux.

Using the following command options:

g++ -std=c++23 -fno-rtti -fno-exceptions -fno-non-call-exceptions
-fno-unwind-tables -fno-use-cxa-atexit -fno-enforce-eh-specs -faligned-new
-fsized-deallocation -fpermissive   -m32 -ffreestanding -fomit-frame-pointer
-Os -fno-asynchronous-unwind-tables -fno-builtin -Wall -fanalyzer

I get the following error:

In file included from /usr/include/c++/14/memory:95,
...
/usr/include/c++/14/bits/out_ptr.h:57:22: error: ‘__is_shared_ptr’ was not
declared in this scope
   57 |   static_assert(!__is_shared_ptr<_Smart> || sizeof...(_Args) != 0,

Is #if _GLIBCXX_HOSTED missing around 

#if __cplusplus > 202002L
#  include 
#endif

> As a quick workaround for building my project, I define #define 
> _GLIBCXX_OUT_PTR_H before including

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > So, tried this under the debugger.  All VALID_MVE_PRED_MODE modes have the
> > same size, 2 bytes, so I'd go with
> >   else if (VALID_MVE_PRED_MODE (mode))
> > {
> >   /* unsigned short arguments to functions get promoted to int, undo
> > that.  */
> >   if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
> > x = gen_lowpart (HImode, x);
> >   if (GET_MODE (x) != mode)
> > {
> >   /* Nested SUBREGs are invalid.  */
> >   if (SUBREG_P (x))
> > x = force_reg (GET_MODE (x), x);
> >   x = lowpart_subreg (mode, x,
> >   GET_MODE (x) == VOIDmode ? HImode : GET_MODE
> > (x));
> 
> This still crashes with mode == V*BI, because we reach
> rtx_vector_builder::find_cached_value() where elt is not a supported
> constant.

Ah, I was testing just V16BImode and V8BImode, with V16BImode even just
gen_lowpart
on
(const_int -13108 [0x]) works and gives
(const_vector:V16BI [
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
(const_int 0 [0]) repeated x2
(const_int 1 [0x1]) repeated x2
])
while for V8BImode it gives
(const_vector:V8BI [
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
(const_int 0 [0])
(const_int -1 [0x])
])
Now, the question is what these weird B2Imode and B4Imode modes are about.
Are they really 2bit and 4bit booleans, with 0 being false, some value (1 or
all ones?) true, everything else UB?  Something else?
The 0x when it is 1 bit per element indeed is what the above V16BImode
CONST_VECTOR is, the 0x with 2 bits per element is 0 or -1 (but, shouldn't
that be UB?),
but with 0x with 4 bits per element it is element 0xc, that doesn't feel
right
for a boolean in any case.
native_decode_vector_rtx for the bool vectors does:
  unsigned int bit_index = first_byte * BITS_PER_UNIT + i * elt_bits;
  unsigned int byte_index = bit_index / BITS_PER_UNIT;
  unsigned int lsb = bit_index % BITS_PER_UNIT;
  unsigned int value = bytes[byte_index] >> lsb;
  builder.quick_push (gen_int_mode (value, GET_MODE_INNER (mode)));
and kind of expects that gen_int_mode canonicalizes it to some boolean value
(apparently it can handle both all ones and 1 as true, but not other values).
93if (elt == const1_rtx)
94  return CONST1_RTX (m_mode);
95else if (elt == constm1_rtx)
96  return CONSTM1_RTX (m_mode);
97else if (elt == const0_rtx)
98  return CONST0_RTX (m_mode);
99else
100 gcc_unreachable ();
Guess you can get similar ICE for V8BImode if some 2 bit pair is 2 (3 and 1 are
considered true, one of them -1, another 1) and 0 is false;
and for V4BImode obviously far more invalid values.
If the CPU somehow canonicalizes, say any non-zero 2-bit pair (or 4-bit pair)
is considered true (or say decide just based on most significant or least
significant bit), then perhaps you need to do that canonicalization by hand.

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

2024-04-26 Thread wilco at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from Wilco  ---
(In reply to Andrew Pinski from comment #16)
> Patch posted with all of the testcases included:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650080.html

Not nearly enough testcases... What about:

void g(void);
int f(long offset, void *handler)
{
  g();
  if (offset > 5)
return arr[offset];
  __builtin_eh_return (offset, handler);
}

With -O2 -fomit-frame-pointer:

f:
.LFB0:
.cfi_startproc
stp x30, x0, [sp, -64]!
.cfi_def_cfa_offset 64
.cfi_offset 30, -64
.cfi_offset 0, -56
stp x1, x2, [sp, 16]
stp x3, x19, [sp, 32]
.cfi_offset 1, -48
.cfi_offset 2, -40
.cfi_offset 3, -32
.cfi_offset 19, -24
mov x19, x0
str x20, [sp, 48]
.cfi_offset 20, -16
mov x20, x1
bl  g
cmp x19, 5
ble .L8
mov w0, w19
ldp x19, x20, [sp, 40]
ldp x30, x0, [sp], 64** oops
.cfi_remember_state
.cfi_restore 0
.cfi_restore 30
.cfi_restore 19
.cfi_restore 20
.cfi_def_cfa_offset 0
ret
.L8:
.cfi_restore_state
mov x5, x19
ldp x1, x2, [sp, 16]
mov x6, x20
ldp x3, x19, [sp, 32]
ldr x20, [sp, 48]
ldp x30, x0, [sp], 64
.cfi_restore 0
.cfi_restore 30
.cfi_restore 20
.cfi_restore 3
.cfi_restore 19
.cfi_restore 1
.cfi_restore 2
.cfi_def_cfa_offset 0
add sp, sp, x5
br  x6
.cfi_endproc

So I don't believe you should change aarch64_pop_regs at all - it's too late to
change things and just adds unnecessary complexity and more bugs. The best
option would be to handle eh_return explicitly and insert the extra push/pops
rather than treating them like a generic callee-save (because clearly they are
not anymore).

[Bug libstdc++/114865] std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

--- Comment #1 from Peter Dimov  ---
> The problem may well be inside libatomic, of course; I have no way to tell.

Narrator: but he did, in fact, have a way to tell.

This is a GHA run with GCC 9 to 13 tested on both Ubuntu 23.04 and Ubuntu
23.10, and only GCC 13 hangs.

https://github.com/boostorg/uuid/actions/runs/8852038822/job/24309866206

And indeed, the codegen from GCC 12 (https://godbolt.org/z/xc7oT76fn) is
radically different from (and much simpler than) the GCC 13 one
(https://godbolt.org/z/eP48xv3Mr).

I think that the problem has been introduced with this commit:

https://github.com/gcc-mirror/gcc/commit/157236dbd621644b3cec50b6cf38811959f3e78c

which, ironically enough, was supposed to improve the handling of types with
padding bits, but broke them entirely.

(I told the committee there was nothing wrong with compare_exchange as
specified, but did they listen to me? To ask the question is to answer it.)

[Bug target/112304] cinc is not being used for (small) constant

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-April/6
   ||50081.html

--- Comment #6 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650081.html

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Christophe Lyon  ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger.  All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
>   else if (VALID_MVE_PRED_MODE (mode))
> {
>   /* unsigned short arguments to functions get promoted to int, undo
> that.  */
>   if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
> x = gen_lowpart (HImode, x);
>   if (GET_MODE (x) != mode)
> {
>   /* Nested SUBREGs are invalid.  */
>   if (SUBREG_P (x))
> x = force_reg (GET_MODE (x), x);
>   x = lowpart_subreg (mode, x,
>   GET_MODE (x) == VOIDmode ? HImode : GET_MODE
> (x));

This still crashes with mode == V*BI, because we reach
rtx_vector_builder::find_cached_value() where elt is not a supported constant.

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

2024-04-26 Thread ricbal02 at gcc dot gnu.org via Gcc-bugs

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

Richard Ball  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Ball  ---
Fixed on Trunk for both and backported Cortex-A510 fix to gcc-12 and gcc-13

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Ball
:

https://gcc.gnu.org/g:751a0f54345b7e037db7f0389c19c1f87e0ae4de

commit r12-10397-g751a0f54345b7e037db7f0389c19c1f87e0ae4de
Author: Richard Ball 
Date:   Fri Apr 26 18:21:07 2024 +0100

aarch64: Fix SCHEDULER_IDENT for Cortex-A510

The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55. This can cause
sub-optimal asm to be generated.

gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to cortexa53
for Cortex-A510.

[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Ball
:

https://gcc.gnu.org/g:28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03

commit r13-8654-g28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03
Author: Richard Ball 
Date:   Fri Apr 26 18:15:23 2024 +0100

aarch64: Fix SCHEDULER_IDENT for Cortex-A510

The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55. This can cause
sub-optimal asm to be generated.

gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to cortexa53
for Cortex-A510.

[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression

2024-04-26 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Patrick Palka  ---
Many of these testcases (from here and the related PRs) are now accepted by GCC
14 after r14-10134.

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Jakub Jelinek  ---
The upstream sources are:
https://github.com/sfilippone/amg4psblas/archive/refs/tags/v1.1.2.tar.gz
https://github.com/sfilippone/psblas3/archive/refs/tags/v3.8.1-2.tar.gz

[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return

2024-04-26 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Andrew Pinski  ---
Patch posted with all of the testcases included:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650080.html

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2024-04-26 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Patrick Palka  ---
(In reply to Nathaniel Shead from comment #5)
> That said, my version doesn't actually solve the underlying issue: my
> adjustment of your testcase to put instantiations into the module purview
> (and force emission there) still gives the same error for me.  So it sounds
> like there's something else being affected by DECL_MODULE_PURVIEW_P being
> set when maybe it shouldn't for an explicit specialisation.
Interesting, I guess one difference with your approach is that for 114630_b.C
we'll still end up installing the imported instantiations of
_M_do_parse()::A/B instead of instantiating them ourselves (within the
GMF), and so DECL_MODULE_IMPORT_P will be set on these local type
instantiations, and yet not on _M_do_parse() because this function
specialization was formed (but not instantiated) within the GMF.

That seems like a weird inconsistency, that DECL_MODULE_IMPORT_P is set on the
local types but not on the containing function..

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 58047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58047=edit
pr114859-1.tar.xz

Another module.

Unfortunately, the last module is too large for the 1M limit.
It can be grabbed from
wget
https://kojipkgs.fedoraproject.org/packages/psblas3/3.8.1/5.post2.fc40/x86_64/psblas3-openmpi-devel-3.8.1-5.post2.fc40.x86_64.rpm
rpm2cpio psblas3-openmpi-devel-3.8.1-5.post2.fc40.x86_64.rpm | cpio -id
it is the
usr/lib64/gfortran/modules/openmpi/psblas3/psb_base_mod.mod
file.

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

2024-04-26 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Eric Botcazou  ---
Another instance is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 58046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58046=edit
pr114859.tar.xz

Testcase + one module.
I was using
./f951 -quiet -I . amg_d_hierarchy_bld.f90 -m64 -march=x86-64 -mtune=generic
-mno-omit-leaf-frame-pointer -O2 -fexceptions -fstack-protector-strong
-fno-asynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full
-fno-omit-frame-pointer -fPIC  -o amg_d_hierarchy_bld.s
-fdump-tree-{original,gimple}

[Bug fortran/102003] [PDT] Length of character component not simplified

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-10396-g8ad460ca8824f7e29e38a63f9cb4a9a3b96d506f
Author: Andre Vehreschild 
Date:   Wed Jul 12 12:51:30 2023 +0200

gfortran: Allow ref'ing PDT's len() in parameter-initializer.

Fix declaring a parameter initialized using a pdt_len reference
not simplifying the reference to a constant.

2023-07-12  Andre Vehreschild  

gcc/fortran/ChangeLog:

PR fortran/102003
* expr.cc (find_inquiry_ref): Replace len of pdt_string by
constant.
(simplify_ref_chain): Ensure input to find_inquiry_ref is
NULL.
(gfc_match_init_expr): Prevent PDT analysis for function calls.
(gfc_pdt_find_component_copy_initializer): Get the initializer
value for given component.
* gfortran.h (gfc_pdt_find_component_copy_initializer): New
function.
* simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt
component ref or constant.

gcc/testsuite/ChangeLog:

* gfortran.dg/pdt_33.f03: New test.

(cherry picked from commit f9182da3213aa57c16dd0b52862126de4a259f6a)

[Bug fortran/114859] [14 Regression] Seeing new segmentation fault in same_type_as since r14-9752

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||pault at gcc dot gnu.org
   Priority|P3  |P2
   Last reconfirmed||2024-04-26
   Target Milestone|--- |14.0
Summary|Seeing new segmentation |[14 Regression] Seeing new
   |fault in same_type_as   |segmentation fault in
   ||same_type_as since r14-9752

--- Comment #5 from Jakub Jelinek  ---
Bisection shows the only change on that CU in that range is
r14-9752-g35408b3669fac104cd380582b32e32c64a603d8b
and the changes are mostly in the save_smoothers subroutine.
diff -upb on the original dump between r14-9751 and r14-9752 is:
--- amg_d_hierarchy_bld.f90.005t.original_  2024-04-26 12:41:01.40711
-0400
+++ amg_d_hierarchy_bld.f90.005t.original   2024-04-26 12:42:21.511060046
-0400
@@ -211,9 +211,6 @@ void restore_smoothers (struct amg_d_one
 __attribute__((fn spec (". . w w w ")))
 void save_smoothers (struct amg_d_onelev_type & restrict level, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict save1,
struct __class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict
save2, integer(kind=4) & restrict info)
 {
-  {
-integer(kind=4) stat.18;
-
 *info = 0;
 if (save1->_data != 0B)
   {
@@ -328,7 +325,6 @@ void save_smoothers (struct amg_d_onelev
   }
 if (__builtin_expect ((integer(kind=8)) (stat.18 != 0), 0, 44)) goto L.34;
 (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type *)
save1->_vptr = (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type
*) level->sm._vptr;
-(void) __builtin_memcpy ((void *) save1->_data, (void *)
save1->_vptr->_def_init, (unsigned long) save1->_vptr->_size);
 L.34:;
 *info = stat.18;
 if (*info == 0)
@@ -344,11 +340,11 @@ void save_smoothers (struct amg_d_onelev
 }
   }
 L.36:;
-if (*info == 0 && level->sm2a._data != 0B)
-  {
 {
   integer(kind=4) stat.21;

+if (*info == 0 && level->sm2a._data != 0B)
+  {
   if (__builtin_expect ((integer(kind=8)) (save2->_data != 0B), 0,
45))
 {
   stat.21 = 5014;
@@ -364,7 +360,6 @@ void save_smoothers (struct amg_d_onelev
 }
   if (__builtin_expect ((integer(kind=8)) (stat.21 != 0), 0, 44)) goto
L.38;
   (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type *)
save2->_vptr = (struct __vtype_amg_d_base_smoother_mod_Amg_d_base_smoother_type
*) level->sm2a._vptr;
-  (void) __builtin_memcpy ((void *) save2->_data, (void *)
save2->_vptr->_def_init, (unsigned long) save2->_vptr->_size);
   L.38:;
   *info = stat.21;
   if (*info == 0)
@@ -384,15 +379,13 @@ void save_smoothers (struct amg_d_onelev
   }
 L.37:;
 return;
-  }
 }


 __attribute__((fn spec (". . . . w ")))
 void amg_d_hierarchy_bld (struct psb_dspmat_type & a, struct psb_desc_type &
desc_a, struct __class_amg_d_prec_type_Amg_dprec_type_t & prec, integer(kind=4)
& restrict info)
 {
-  static void restore_smoothers (struct amg_d_onelev_type &, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict,
integer(kind=4) & restrict);
-  static void save_smoothers (struct amg_d_onelev_type & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict, struct
__class_amg_d_base_smoother_mod_Amg_d_base_smoother_type_a & restrict,
integer(kind=4) & restrict);
+  integer(kind=4) stat.18;
   integer(kind=8) D.9689;
   integer(kind=8) D.9690;
   integer(kind=8) D.9691;

so guess the only significant change is the removal of the two __builtin_memcpy
calls.

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

2024-04-26 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-26
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |xry111 at gcc dot 
gnu.org

--- Comment #6 from Xi Ruoyao  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650077.html

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

2024-04-26 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Eric Botcazou  ---
Yes, this is a known issue in SRA, see PR optimization/111873, but it
apparently shows up only with nonsensical combinations of switches so, well...

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

2024-04-26 Thread matthew.thompson at nasa dot gov via Gcc-bugs

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

--- Comment #14 from Matt Thompson  ---
Never mind. I'll send attachment to Jerry offline. It's too big for here.

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

2024-04-26 Thread matthew.thompson at nasa dot gov via Gcc-bugs

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

--- Comment #13 from Matt Thompson  ---
Okay I have a new reproducer that I'll attach here. It uses the random names.

I see the same behavior:

IFX 2024.1:

Number of Modules | Build Time
- | --
   10 |   0.100479
   20 |0.15462
   30 |   0.209833
   40 |   0.259712
   50 |   0.314469

GCC 13.2:

Number of Modules | Build Time
- | --
   10 |1.55647
   20 |6.41986
   30 |12.7215
   40 |25.4188
   50 |36.3083

[Bug libstdc++/114865] New: std::atomic::compare_exchange_strong seems to hang under GCC 13 on Ubuntu 23.04

2024-04-26 Thread pdimov at gmail dot com via Gcc-bugs

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

Bug ID: 114865
   Summary: std::atomic::compare_exchange_strong seems to hang
under GCC 13 on Ubuntu 23.04
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

I'm getting weird hangs on Github Actions when using
`std::atomic::compare_exchange_strong` under GCC 13 on Ubuntu 23.04
(only; GCC 12 and earlier on Ubuntu 22.04 and earlier work). `state_type` is
defined as

```
struct state_type
{
std::uint64_t timestamp;
std::uint16_t clock_seq;
};
```

and the code doing the CAS is

```
auto oldst = ps_->load( std::memory_order_relaxed );

for( ;; )
{
auto newst = get_new_state( oldst );

if( ps_->compare_exchange_strong( oldst, newst, std::memory_order_relaxed,
std::memory_order_relaxed ) )
{
state_ = newst;
break;
}
}
```

where `ps` is of type `std::atomic*`.

At a glance, I see nothing immediately wrong with the generated code
(https://godbolt.org/z/8Ee3hrTz8).

However, when I change `state_type` to

```
struct state_type
{
std::uint64_t timestamp;
std::uint16_t clock_seq;
std::uint16_t padding[ 3 ];
};
```
the hangs disappear. This leads me to think that the problem is caused by the
original struct having padding, which isn't being handled correctly for some
reason.

As we know, `std::atomic::compare_exchange_strong` is carefully specified to
take and return `expected` by reference, such that it can both compare the
entire object as if via `memcmp` (including the padding), and return it as if
by `memcpy`, again including the padding. Even though the padding bits of the
initial value returned by the atomic load are unspecified, at most one
iteration of the loop would be required for the padding bits to converge and
for the CAS to succeed.

However, going by the symptoms alone, this doesn't seem to be the case here.

The problem may well be inside libatomic, of course; I have no way to tell.

One GHA run showing the issue is
https://github.com/boostorg/uuid/actions/runs/8821753835, where only the GCC 13
job times out.

[Bug fortran/114859] Seeing new segmentation fault in same_type_as

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Jakub Jelinek  ---
LTO doesn't seem to make a difference.  And without LTO bisection points at
openmpi-build/amgprec/impl/amg_d_hierarchy_bld.o
when this is compiled with r14-9704 even when all other sources are compiled
with
the newer compiler, the testcase works, while when this is compiled with
r14-9924
and all other sources with the older compiler, it crashes.

[Bug tree-optimization/110490] tree-ssa/clz-* and tree-ssa/ctz-* fail on s390x with arch14 (expression_expensive_p not handling if there is wider clz/ctz/popcount optab)

2024-04-26 Thread stefansf at gcc dot gnu.org via Gcc-bugs

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 CC||stefansf at gcc dot gnu.org

--- Comment #4 from Stefan Schulze Frielinghaus  
---
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650001.html

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

2024-04-26 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-5-ga0bc71e480132a528a4869c1cd7863f709768c53
Author: Jonathan Wakely 
Date:   Fri Apr 26 11:42:26 2024 +0100

libstdc++: Do not apply localized formatting to NaN and inf [PR114863]

We don't want to add grouping to strings like "-inf", and there is no
radix character to replace either.

libstdc++-v3/ChangeLog:

PR libstdc++/114863
* include/std/format (__formatter_fp::format): Only use
_M_localized for finite values.
* testsuite/std/format/functions/format.cc: Check localized
formatting of NaN and initiny.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Jakub Jelinek  ---
So, tried this under the debugger.  All VALID_MVE_PRED_MODE modes have the same
size, 2 bytes, so I'd go with
  else if (VALID_MVE_PRED_MODE (mode))
{
  /* unsigned short arguments to functions get promoted to int, undo that. 
*/
  if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
x = gen_lowpart (HImode, x);
  if (GET_MODE (x) != mode)
{
  /* Nested SUBREGs are invalid.  */
  if (SUBREG_P (x))
x = force_reg (GET_MODE (x), x);
  x = lowpart_subreg (mode, x,
  GET_MODE (x) == VOIDmode ? HImode : GET_MODE
(x));
}
}
It would surprise me if (subreg:V4BI (reg:SI 116 [ _3 ]) 0) gets through
validation given the differences in sizes, but if you really want to handle
that as before, then just:
  else if (VALID_MVE_PRED_MODE (mode))
{
  if (GET_CODE (x) == CONST_INT)
x = lowpart_subreg (mode, gen_lowpart (HImode, x), HImode);
  else if (GET_MODE (x) != mode)
{
  if (SUBREG_P (x))
x = force_reg (GET_MODE (x), x);
  x = gen_lowpart (mode, x);
}
}
i.e. use lowpart_subreg on gen_lowpart on CONST_INTs (gen_lowpart effectively
does
lowpart_subreg (HImode, x, DImode) in that case), the force_reg case to avoid
ICEs if say (subreg:SI (reg:DI ...) 0) is passed and gen_lowpart as before.

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

2024-04-26 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Tamar Christina  ---
There's no change in the binaries aside from an alignment change in one of the
lesser hot functions.

I guess you recompile libc? In which case you need to compare against GCC 13.

As mentioned in the quoted commit this reverts the general case for GCC 14.

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2024-04-26 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Nathaniel Shead  ---
I've been testing a patch series that tries to solve this from the other end
(by remembering whether we were in the module purview when we deferred the
instantiation and restoring that state within reopen_tinst_level, similarly to
how e.g. input_location is handled for error messages).

AFAICT, DECL_MODULE_PURVIEW_P on template instantiations should only matter for
determining whether it might be discarded (i.e. applying DB_UNREACHED_BIT);
otherwise, in general purviewness and attachment should be determined by the
base template, as implemented in 'get_originating_module_decl'.

That said, my version doesn't actually solve the underlying issue: my
adjustment of your testcase to put instantiations into the module purview (and
force emission there) still gives the same error for me.  So it sounds like
there's something else being affected by DECL_MODULE_PURVIEW_P being set when
maybe it shouldn't for an explicit specialisation.

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

2024-04-26 Thread hjl.tools at gmail dot com via Gcc-bugs

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from H.J. Lu  ---
It is caused by r12-434.

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-26
   Priority|P3  |P2
Version|unknown |14.0
   Target Milestone|--- |12.4
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
int main ()
{
   [local count: 1073741824]:
  c.b = 0;
  return 0;

}


Confirmed.  It seems we are confused during inlining and substitute
'c' for 'f' because both are readonly.  But the write to f is to an
automatic var and thus not readonly memory.

Note the write to f is introduced by SRA so I think it's SRAs fault:

void e (const struct a f)
 {
+  const int f$b;
   int _1;
   int iftmp.0_4;

:
-  _1 = f.b;
+  f$b_3 = f.b;
+  _1 = f$b_3;
   if (_1 != 0)
 goto ; [INV]
   else
 goto ; [INV]

:
-  iftmp.0_4 = f.b;
+  iftmp.0_4 = f$b_3;

:
+  f.b = f$b_3;
   d (f);

The store is broken.  I think a readonly aggegate never needs to be
re-materialized as it cannot be changed (do we track possible writes?)

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2024-04-26 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Patrick Palka  ---
(In reply to Patrick Palka from comment #3)
> And in 114630_c.C we no longer try to stream in the definition
> of _M_do_parse() twice, for some reason.
Oops, looks like we still stream in the definition twice with the fix but the
local types therein get deduplicated correctly now.

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

2024-04-26 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Tamar Christina  ---
Hmm

I Am unable to reproduce this with -O3 - flto -mcpu=neoverse-v2 on a
neoverse-v2 machine.

Is any other option required?

Also that code was new in gcc 14 and was partially reverted due to register
allocation issue.

So if there is a performance difference it's a miss optimization and not a
regression

[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/114856] [14/15 regression][modules] ICE (segfault)

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/114855] ICE: Segfault

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-26

--- Comment #4 from Richard Biener  ---
Trunk at -O1:

dominator optimization : 495.14 ( 82%)   0.20 (  5%) 495.44 ( 81%) 
 113M (  5%)

I can confirm the segfault with the 13.2 release.  It segfaults in

#0  0x009a8603 in (anonymous
namespace)::pass_waccess::check_dangling_stores (this=this@entry=0x2866fc0,
bb=0x75277480, stores=..., bbs=...)
at /space/rguenther/src/gcc-13-branch/gcc/gimple-ssa-warn-access.cc:4535

with too deep recursion.  That was fixed by r14-4308-gf194c684a28a5d for
PR111600 and could be backported, leaving the compile-time hog.  I'll do
that next week.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Jakub Jelinek  ---
(mode == HImode || mode == V16BImode) could be GET_MODE_SIZE (mode) == 2 too.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #7)
> This fails because down the call chain from lowpart_subreg, we reach
> gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode ==
> V4BImode (so is MODE_VECTOR_BOOL), but is not a valid expected boolean
> constant vector.

Ah, so the builtin prototype says the argument is unsigned short (or unsigned
char?)
but mode (as the insn predicate mode) is V*BImode in that case?
Then it would still be passed as SImode, so one would need
if (GET_MODE (x) == SImode || GET_MODE (x) == VOIDmode)
  {
x = lowpart_subreg ((mode == HImode || mode == V16BImode) ? HImode :
QImode, x, SImode);
if (mode != HImode)
  x = lowpart_subreg (mode, x, mode == V16BImode ? HImode : QImode);
  }
Does that second lowpart_subreg create CONST_VECTOR you are looking for?

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

2024-04-26 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
The following hack which forces instantiations induced from the GMF to actually
get instantiated within the GMF seems to fix the underlying issue:

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 1339f210dde..dab98c02a63 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -2549,7 +2549,7 @@ decl_needed_p (tree decl)
 /* If necessary, write out the vtables for the dynamic class CTYPE.
Returns true if any vtables were emitted.  */

-static bool
+bool
 maybe_emit_vtables (tree ctype, vec _vtables)
 {
   tree vtbl;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 50d3ad35b61..7b91e2b6499 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -15173,6 +15173,23 @@ cp_parser_module_declaration (cp_parser *parser,
module_parse mp_state,
 }
   else
 {
+  if (mp_state == MP_GLOBAL)
+   /* ??? Make sure used specializations and vtables used within the
+  GMF are instantiated before starting the module purview.  */
+   for (int i = 0; i < 10; i++)
+ {
+   instantiate_pending_templates (0);
+   extern bool maybe_emit_vtables (tree, vec &);
+   tree t;
+   auto_vec consteval_vtables;
+   at_eof = 1;
+   for (int i = keyed_classes->length ();
+keyed_classes->iterate (--i, );)
+ if (maybe_emit_vtables (t, consteval_vtables))
+   keyed_classes->unordered_remove (i);
+   at_eof = 0;
+ }
+
   module_state *mod = cp_parser_module_name (parser);
   if (mod && cp_lexer_peek_token (parser->lexer)->type == CPP_COLON)
mod = cp_parser_module_partition (parser, mod);


But I don't really understand why..  What changes is that for 114630_b.C we now
instantiate the local types _M_do_parse()::A/B locally at the end of the
GMF rather than at EOF, and later when doing the import we deduplicate their
imported definition rather than installing their imported definition.  And in
114630_c.C we no longer try to stream in the definition of _M_do_parse()
twice, for some reason.

Maybe related, but I noticed that for

module;
template int f() { return 42; }
inline int x = f();
export module foo;

without the above fix we instantiate f() at EOF time and so
set_instantiating_module sets DECL_MODULE_PURVIEW_P for it, even though the
instantiation was induced from the GMF not the module purview.  With the above
fix we now instantiate f() while still within the GMF and no longer set
DECL_MODULE_PURVIEW_P for f().  I wonder to what extent
DECL_MODULE_PURVIEW_P matters on implicit instantiations?

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Christophe Lyon  ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the builtins, with the exception that gcc likes to promote QImode/HImode
> arguments of calls to SImode, so is the intent in that case to just narrow
> down SImode back to HImode (seems VALID_MVE_PRED_MODE is only true for
> HImode from scalar MODE_INT modes)?
> 
We have mode == V4BImode (could be V16BI or V8BI, it depends on the intrinsic
being expanded)
and x is HImode.
The intent is to generate:
(set (reg:V4BI 122)
   (subreg:V4BI (reg:SI 116 [ _3 ]) 0))

This works if x is not a constant (this is what we have in trunk)

> If so, best would be to limit the call to just that case.
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194 
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc2024-04-26 15:49:55.380344060 
> +0200
> @@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
>mode = GET_MODE (x);
>  }
>else if (VALID_MVE_PRED_MODE (mode))
> -x = gen_lowpart (mode, x);
> +{
> +  if (mode == HImode && GET_MODE (x) != HImode)
> + /* GCC promotes QI/HImode arguments to int, undo that
> +here.  */
> + x = lowpart_subreg (mode, x, SImode);

So we won't enter the 'if' since mode != HImode

> +}
>  
>m_ops.safe_grow (m_ops.length () + 1, true);
>create_input_operand (_ops.last (), x, mode);
> 
> I'd hope if the argument is a vector mode x already has that mode...

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Christophe Lyon  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > lowpart_subreg does not work either.
> > 
> > If we put the predicates in a variable in the testcase, then in
> > function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
> > 116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to
> > get the 16 bits of predicates).
> 
> If x could be e.g. (subreg:SI (reg:DI ...) ...), then one needs to use for
> GET_CODE (x) == SUBREG && GET_MODE (x) != mode do a force_reg first.
> 

No sure I got this right:
if (GET_CODE (x) == SUBREG && GET_MODE (x) != mode)
  x = force_reg (mode, x);
breaks the assert in emit_move_insn because mode is V4BImode and 'y' is HImode.

> > But when predicates are passed as a constant as in the testcase, we have
> > x = (const_int -13108 [0x])
> > and gen_lowpart (HImode, x) fails on that.
> 
> Why doesn't lowpart_subreg (mode, x, GET_MODE (x) == VOIDmode ? DImode :
> GET_MODE (x));
> work?
> I.e. for CONST_INTs assume it is some constant in a mode equal or wider than
> mode.
> Unless mode can be TImode or x can be __int128 constants, that is.
>
This fails because down the call chain from lowpart_subreg, we reach
gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode ==
V4BImode (so is MODE_VECTOR_BOOL), but is not a valid expected boolean constant
vector.

[Bug target/114734] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Richard Biener  ---
posted the patch so the arm CI picks it up.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #5)
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194 
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc2024-04-26 15:49:55.380344060 
> +0200
> @@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
>mode = GET_MODE (x);
>  }
>else if (VALID_MVE_PRED_MODE (mode))
> -x = gen_lowpart (mode, x);
> +{
> +  if (mode == HImode && GET_MODE (x) != HImode)
> + /* GCC promotes QI/HImode arguments to int, undo that
> +here.  */
> + x = lowpart_subreg (mode, x, SImode);

Perhaps even
  else
gcc_assert (GET_MODE (x) == mode);
here?

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jakub Jelinek  ---
Guess the primary question is why there is the gen_lowpart call at all.
Is it that normally the mode of x is already right due to the prototypes of the
builtins, with the exception that gcc likes to promote QImode/HImode arguments
of calls to SImode, so is the intent in that case to just narrow down SImode
back to HImode (seems VALID_MVE_PRED_MODE is only true for HImode from scalar
MODE_INT modes)?

If so, best would be to limit the call to just that case.
So (completely untested):
--- gcc/config/arm/arm-mve-builtins.cc.jj   2024-03-19 09:51:05.203631194
+0100
+++ gcc/config/arm/arm-mve-builtins.cc  2024-04-26 15:49:55.380344060 +0200
@@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
   mode = GET_MODE (x);
 }
   else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+  if (mode == HImode && GET_MODE (x) != HImode)
+   /* GCC promotes QI/HImode arguments to int, undo that
+  here.  */
+   x = lowpart_subreg (mode, x, SImode);
+}

   m_ops.safe_grow (m_ops.length () + 1, true);
   create_input_operand (_ops.last (), x, mode);

I'd hope if the argument is a vector mode x already has that mode...

[Bug target/114734] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5

2024-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

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

2024-04-26 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from David Malcolm  ---
> Sorry about this.
>
> Is there a machine in the compile farm I can test this on?

Sure, both cfarm215 (Solaris/x86) and cfarm216 (Solaris/SPARC).  With
the attached Solaris testcase, you can reproduce it even on Linux.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Christophe Lyon from comment #3)
> lowpart_subreg does not work either.
> 
> If we put the predicates in a variable in the testcase, then in
> function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
> 116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to
> get the 16 bits of predicates).

If x could be e.g. (subreg:SI (reg:DI ...) ...), then one needs to use for
GET_CODE (x) == SUBREG && GET_MODE (x) != mode do a force_reg first.

> But when predicates are passed as a constant as in the testcase, we have
> x = (const_int -13108 [0x])
> and gen_lowpart (HImode, x) fails on that.

Why doesn't lowpart_subreg (mode, x, GET_MODE (x) == VOIDmode ? DImode :
GET_MODE (x));
work?
I.e. for CONST_INTs assume it is some constant in a mode equal or wider than
mode.
Unless mode can be TImode or x can be __int128 constants, that is.

> I'm trying an approach to convert the constant into a vector of constants
> whose mode will V4BImode in this case.

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

2024-04-26 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

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

Is there a machine in the compile farm I can test this on?

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

2024-04-26 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Christophe Lyon  ---
lowpart_subreg does not work either.

If we put the predicates in a variable in the testcase, then in
function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI
116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to get
the 16 bits of predicates).

But when predicates are passed as a constant as in the testcase, we have
x = (const_int -13108 [0x])
and gen_lowpart (HImode, x) fails on that.

I'm trying an approach to convert the constant into a vector of constants whose
mode will V4BImode in this case.

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

2024-04-26 Thread ro at gcc dot gnu.org via Gcc-bugs

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

Rainer Orth  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #8 from Rainer Orth  ---
I wonder what to do about this PR for GCC 14:

* It increased analyzer failures from 92 on the gcc-13 branch to 1482 on trunk.

* This is a massive regression for sparc-sun-solaris2.11, a primary target.

* I never got any response from either the patch author or David as analyzer
  maintainer.

In the worst case, I guess it's better to disable the analyzer testsuite on
Solaris rather than having this insane amount of noise.

Thoughts?

[Bug target/43644] __uint128_t missed optimizations.

2024-04-26 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0

--- Comment #6 from Roger Sayle  ---
This is now fixed on mainline (for GCC 14 and GCC 15).

[Bug rtl-optimization/97756] [11/12/13 Regression] Inefficient handling of 128-bit arguments

2024-04-26 Thread roger at nextmovesoftware dot com via Gcc-bugs

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

Roger Sayle  changed:

   What|Removed |Added

  Known to work||14.0
Summary|[11/12/13/14/15 Regression] |[11/12/13 Regression]
   |Inefficient handling of |Inefficient handling of
   |128-bit arguments   |128-bit arguments

--- Comment #17 from Roger Sayle  ---
I believe this issue is now fixed on mainline (i.e. for both GCC 14 and GCC
15).
Firstly, many thanks to Jakub for correcting the error in my patch. We now
generate optimal code sequences for the code in comments #3 and #5, and use
generate fewer instructions than described in the original description.

The final remaining issue is that with -O3 GCC still uses more instructions
than clang and icc (see Thomas' comments in comments #12 and #13).  The good
news is that this is intentional, compiling with -Os (to optimize for size)
generates the same number of instructions as clang and icc [in fact, using icc
-Os generates larger code!?].  So when optimizing for performance, GCC is
taking the opportunity to use more (cheap) instructions to execute faster (or
that's the theory).

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

2024-04-26 Thread matthew.thompson at nasa dot gov via Gcc-bugs

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

--- Comment #12 from Matt Thompson  ---
Jerry,

Actually, I took a look at my reproducer and it's not quite what I was wanting
(I made a mistake in the Jinja templates). I'm going to work on it now to fix
this up. And I'll look at adding the random name option as well. Back soon...

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

2024-04-26 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 58045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58045=edit
gcc15-pr114456.patch

Untested implementation.

[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's

2024-04-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jonathan Wakely  ---
Libc++ has tests for "INF" (although only for long double, not float or
double), so it's apparently not accidental. The relevant code is:

  if (floatfield == ios_base::fixed) {
if (uppercase)
  *__fmtp = 'F';
else
  *__fmtp = 'f';

That's been there since the initial commit in 2010.

MSVC behaves the same as libstdc++.

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

2024-04-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jonathan Wakely  ---
Maybe we could also make _M_localize more efficient for finite values by not
even attempting to use grouping for scientific format.

[Bug libstdc++/114863] std::format applying grouping to nan's and inf's

2024-04-26 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
 #endif

- if (_M_spec._M_localized)
+ if (_M_spec._M_localized && __builtin_isfinite(__v))
{
  __wstr = _M_localize(__str, __expc, __fc.locale());
  if (!__wstr.empty())

1 2 >

1 - 100 of 128 matches

Mail list logo