[Bug c/114927] [14/15 Regression] ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from uecker at gcc dot gnu.org ---
Seems something still needs to be done regarding function types when the
TYPE_CANONICAL is set when completing the struct, see PR114574

[Bug tree-optimization/114932] New: Improvement in CHREC can give large performance gains

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

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

Bug ID: 114932
   Summary: Improvement in CHREC can give large performance gains
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

With the original fix from PR114074 applied (e.g.
g:a0b1798042d033fd2cc2c806afbb77875dd2909b) we not only saw regressions but saw
big improvements.

The following testcase:

---
  module brute_force
integer, parameter :: r=9
 integer  block(r, r, r)
contains
  subroutine brute
  k = 1
call digits_2(k)
  end
   recursive subroutine digits_2(row)
  integer, intent(in) :: row
  logical OK
 do i1 = 0, 1
  do i2 = 1, 1
  do i3 = 1, 1
   do i4 = 0, 1
do i5 = 1, select
 do i6 = 0, 1
 do i7 = l0, u0
   select case(1 )
   case(1)
   block(:2, 7:, i7) = block(:2, 7:, i7) - 1
   end select
do i8 = 1, 1
   do i9 = 1, 1
if(row == 5) then
  elseif(OK)then
call digits_2(row + 1)
end if
end do
  end do
   block(:, 1, i7) =   select
end do
end do
  end do
  end do
   end do
block = 1
 end do
 block = 1
 block = block0 + select
  end do
 end
  end
---

compiled with: -mcpu=neoverse-v1 -Ofast -fomit-frame-pointer foo.f90

gets vectorized after sra and constprop.  But the final addressing modes are so
complicated that IVopts generates a register offset mode:

  4c:   2f00041dmvniv29.2s, #0x0
  50:   fc666842ldr d2, [x2, x6]
  54:   fc656841ldr d1, [x2, x5]
  58:   fc646840ldr d0, [x2, x4]
  5c:   0ebd8442add v2.2s, v2.2s, v29.2s
  60:   0ebd8421add v1.2s, v1.2s, v29.2s
  64:   0ebd8400add v0.2s, v0.2s, v29.2s

which is harder for prefetchers to follow.  When the patch was applied it was
able to correctly lower these to the immediate offset loads that the scalar
code was using:

  38:   2f00041dmvniv29.2s, #0x0
  34:   fc594002ldurd2, [x0, #-108]
  40:   fc5b8001ldurd1, [x0, #-72]
  44:   fc5dc000ldurd0, [x0, #-36]
  48:   0ebd8442add v2.2s, v2.2s, v29.2s
  4c:   0ebd8421add v1.2s, v1.2s, v29.2s
  50:   0ebd8400add v0.2s, v0.2s, v29.2s

and also removes all the additional instructions to keep x6,x5 and x4 up to
date.

This gave 10%+ improvements on various workloads.

(ps I'm looking at the __brute_force_MOD_digits_2.constprop.3.isra.0
specialization).

I will try to reduce it more, but am filing this so we can keep track and
hopefully fix.

[Bug c/114931] ICE in get_alias_set when building tcl with -std=c23

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

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

--- Comment #4 from Sam James  ---
```
struct Tcl_Obj;
void(Tcl_FreeInternalRepProc)(struct Tcl_Obj *);
typedef struct Tcl_Obj {
} Tcl_Obj;
struct {
  void (*tclFreeObj)(Tcl_Obj *);
} Tcl_InitStubs;
```

[Bug ipa/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE in  |[14/15 regression] ICE in
   |fld_incomplete_type_of when |fld_incomplete_type_of when
   |building libwebp with   |building libwebp with
   |-std=c23 -flto  |-std=c23 -flto

--- Comment #3 from Sam James  ---
c2x in GCC 13 was fine

[Bug c/114931] ICE in get_alias_set when building tcl with -std=c23

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

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

--- Comment #3 from Andrew Pinski  ---
It will involve the struct TclStubs too. I suspect it does not have its
aliasing set correctly.

[Bug c/114931] ICE in get_alias_set when building tcl with -std=c23

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I suspect you find it is a similar pattern as the reduced testcase of pr 114927
...

[Bug rtl-optimization/114931] ICE in get_alias_set when building tcl with -std=c23

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

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

--- Comment #1 from Sam James  ---
With -Wuninitialized, it dies in an earlier pass:
```
# gcc -c tclStubLib.i -std=c23 -Wuninitialized
during GIMPLE pass: early_uninit
/var/tmp/portage/dev-lang/tcl-8.6.14/work/tcl8.6.14/generic/tclStubLib.c: In
function ‘Tcl_InitStubs’:
/var/tmp/portage/dev-lang/tcl-8.6.14/work/tcl8.6.14/generic/tclStubLib.c:119:1:
internal compiler error: in get_alias_set, at alias.cc:954
  119 | }
  | ^
[...]
```

[Bug rtl-optimization/114931] New: ICE in get_alias_set when building tcl with -std=c23

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

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

Bug ID: 114931
   Summary: ICE in get_alias_set when building tcl with -std=c23
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58094=edit
tclStubLib.i.xz

```
# gcc -c tclStubLib.i -std=c23
during RTL pass: expand
/var/tmp/portage/dev-lang/tcl-8.6.14/work/tcl8.6.14/generic/tclStubLib.c: In
function ‘Tcl_InitStubs’:
/var/tmp/portage/dev-lang/tcl-8.6.14/work/tcl8.6.14/generic/tclStubLib.c:70:31:
internal compiler error: in get_alias_set, at alias.cc:954
   70 | if (!stubsPtr || (stubsPtr->magic != TCL_STUB_MAGIC)) {
  |   ^~~
0x55a6e9af0586 get_alias_set(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/alias.cc:954
0x55a6eb2865eb record_component_aliases(tree_node*, int)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/alias.cc:1306
0x55a6eb26bcdc record_component_aliases(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/alias.cc:1346
0x55a6eb26bcdc get_alias_set(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/alias.cc:1151
0x55a6eb28ee06 set_mem_attributes_minus_bitpos(rtx_def*, tree_node*, int,
poly_int<1u, long>)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/emit-rtl.cc:1976
0x55a6eb63832b set_mem_attributes(rtx_def*, tree_node*, int)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/emit-rtl.cc:2181
0x55a6eb63832b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:11731
0x55a6eb638c29 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:9443
0x55a6eb638c29 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:11949
0x55a6eb63ba80 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:9443
0x55a6eb63ba80 store_expr(tree_node*, rtx_def*, int, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:6743
0x55a6eb6368a2 expand_assignment(tree_node*, tree_node*, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/expr.cc:6464
0x55a6eb631a1c expand_gimple_stmt
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/cfgexpand.cc:4077
0x55a6eb631a1c expand_gimple_basic_block
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/cfgexpand.cc:6133
0x55a6eb5daf76 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/cfgexpand.cc:6872
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Sam James from comment #1)
> reduced:
> ```
> typedef struct WebPPicture WebPPicture;
> typedef int (*WebPProgressHook)(const WebPPicture *);
> WebPProgressHook progress_hook;
> struct WebPPicture {
> } WebPGetColorPalette(const struct WebPPicture *);
> ```

This looks almost the same issue as PR 114927.

[Bug ipa/114930] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

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

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

--- Comment #1 from Sam James  ---
reduced:
```
typedef struct WebPPicture WebPPicture;
typedef int (*WebPProgressHook)(const WebPPicture *);
WebPProgressHook progress_hook;
struct WebPPicture {
} WebPGetColorPalette(const struct WebPPicture *);
```

[Bug ipa/114930] New: ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

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

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

Bug ID: 114930
   Summary: ICE in fld_incomplete_type_of when building libwebp
with -std=c23 -flto
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58093=edit
libwebpdecode_la-vp8l_dec.i.xz

```
$ gcc -c libwebpdecode_la-vp8l_dec.i -std=c23 -flto
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopySmallPattern8b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:908:10:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  908 |   while ((uintptr_t)dst & 3) {
  |  ^
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopySmallPattern32b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:977:7:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  977 |   if ((uintptr_t)dst & 4) {   // Align 'dst' to 8-bytes
boundary.
  |   ^
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
In function ‘CopyBlock32b’:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:994:36:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  994 |   if (dist <= 2 && length >= 4 && ((uintptr_t)dst & 3) == 0) {
  |^
during IPA pass: *free_lang_data
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:
At top level:
/var/tmp/portage/media-libs/libwebp-1.3.2/work/libwebp-1.3.2/src/dec/vp8l_dec.c:1744:1:
internal compiler error: in fld_incomplete_type_of, at
ipa-free-lang-data.cc:257
 1744 | }
  | ^
0x5564762f6448 fld_incomplete_type_of
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:257
0x5564778ff8fd fld_simplified_type
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:344
0x5564778ff8fd free_lang_data_in_type
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:439
0x556477fd53b0 free_lang_data_in_cgraph
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1072
0x556477fd53b0 free_lang_data
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1109
0x556477fd53b0 execute
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug c/114927] [14/15 Regression] ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|ICE when building Emacs |[14/15 Regression] ICE when
   |with -std=c23 -flto (error: |building Emacs with
   |‘TYPE_CANONICAL’ has|-std=c23 -flto (error:
   |different ‘TYPE_CANONICAL’) |‘TYPE_CANONICAL’ has
   ||different ‘TYPE_CANONICAL’)
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2024-05-03

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

[Bug c/114927] ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

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

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

Sam James  changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #1 from Sam James  ---
Reduced:
```
typedef int pid_t;
struct Lisp_Process;
int gnutls_try_handshake(struct Lisp_Process *);
struct Lisp_Process {
} Sprocess_send_string;
pid_t emacs_get_tty_pgrp(struct Lisp_Process *);
```

[Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization

[nfxjfg at googlemail dot com via Gcc-bugs]

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

--- Comment #9 from nfxjfg at googlemail dot com ---
Oh, I completely missed that your statement was restricted to "in HW". Normally
there are mechanisms in place that make all CPU-level memory accesses to
registers strictly ordered. (In our hardware that is also the case.) I panicked
because you seemed to imply that even the compiler can reorder accesses to reg1
and reg2, but this isn't the case according to you, the gcc docs, and maybe the
standard. Sorry about that.

I suppose it's regrettable that C and gcc do not consider the possibility that
passing an address to a register (which volatile is pretty much the only useful
thing for) does not imply that the memory at that address may change. But that
seems to be the conclusion here.

[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.

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

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

Gaius Mulley  changed:

   What|Removed |Added

Version|14.0|15.0

--- Comment #4 from Gaius Mulley  ---
For completeness the test code at the top of the PR passes:

$ gm2 testforloopzero.mod 
$ ./a.out 
i = 5, count = 0
i = 4, count = 1
i = 3, count = 2
i = 2, count = 3
i = 1, count = 4
i = 0, count = 5
for loop counting down passed

[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r15-122-ga561dc0f6c7085e102fe9e9b6abd7f2138512576
Author: Gaius Mulley 
Date:   Fri May 3 01:22:10 2024 +0100

PR modula2/114929 for loop fails to iterate down to zero when using a
cardinal type

There is a bug in the for loop control code which is exposed when an
unsigned type is used in the iterator variable.  See
gm2/pim/run/pass/testforloopzero[234].mod.  The bug is in the
calculation of the last iterator value.  The bug fix is to avoid using
negative expressions when calculating the last iterator value with a
negative step value.  This patch detects if e1, e2, step value are all
constant, in which case the ztype is used internally and there is no
overflow.  If the last iterator value is held in a variable then it
uses a different method to calculate the last iterator depending upon
the sign of the step value.

gcc/m2/ChangeLog:

PR modula2/114929
* gm2-compiler/M2LangDump.mod (GenQualidentSymString): Add
missing return result into identstr.
* gm2-compiler/M2Quads.mod (ForLoopLastIteratorVariable): New
procedure.
(ForLoopLastIteratorConstant): Ditto.
(ForLoopLastIterator): Ditto.
(BuildForToByDo): Remove LastIterator calculation and call
ForLoopLastIterator instead.
(FinalValue): Replace with ...
(LastIterator): ... this.

gcc/testsuite/ChangeLog:

PR modula2/114929
* gm2/pim/run/pass/testforloopzero.mod: New test.
* gm2/pim/run/pass/testforloopzero2.mod: New test.
* gm2/pim/run/pass/testforloopzero3.mod: New test.
* gm2/pim/run/pass/testforloopzero4.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 58092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58092=edit
Proposed fix

Here is a proposed bug fix with 6 for loop regression tests.

[Bug modula2/114929] for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-02
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/114929] New: for loop fails to iterate down to zero if a cardinal type (unsigned type) is used with a step of -1.

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

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

Bug ID: 114929
   Summary: for loop fails to iterate down to zero if a cardinal
type (unsigned type) is used with a step of -1.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

An example of the bug follows:

MODULE testforloopzero ;

FROM libc IMPORT printf, exit ;


(*
   test -
*)

PROCEDURE test ;
VAR
   i, n,
   count: CARDINAL ;
BEGIN
   n := 5 ;
   count := 0 ;
   FOR i := n TO 0 BY -1 DO
  printf ("i = %d, count = %d\n", i, count);
  INC (count)
   END ;
   IF count = 6
   THEN
  printf ("for loop counting down passed\n")
   ELSE
  printf ("for loop counting down failed\n") ;
  exit (1)
   END
END test ;


BEGIN
   test
END testforloopzero.

$ gm2 testforloopzero.mod
$ ./a.out

i = 5, count = 0
for loop counting down failed

[Bug target/114910] can't build a c6x cross compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #7 from Mikael Pettersson  ---
(In reply to Marc Poulhiès from comment #6)
> It fails with -Os.
> It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.
> 
> Mikael, is it possible that you're not using -Os for target libs?

I'm not adding -Os anywhere, just taking defaults.
Confirmed that adding --enable-target-optspace triggers the assembler error.

[Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to nfxjfg from comment #7)
> > Note also the order of the writes to reg1 and reg2 might happen in a 
> > different order in HW so you need to have a full (HW) write barrier between 
> > them to make sure the write is done in the correct order.
> 
> Seriously? That breaks literally all code that uses volatile for register
> access (which, in our firmwares, is ALL code). This just fuels my belief
> that gcc and C compiler developers in general turned C into a useless,
> fragile language that can't do anything correctly.
> 
> Is there a way to prevent reordering of volatile accesses?

Yes you need to use inline-asm to get a hw write barrier.
This has been this way for the last 20+ years even when it comes to out of
order processors. 

https://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf should be
very useful. Basically volatile means the compiler not to remove the store/load
from it but it does not mean the HW will reorder the stores/loads. 

Oh and GCC even documents part of this:
https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

"Accesses to non-volatile objects are not ordered with respect to volatile
accesses. You cannot use a volatile object as a memory barrier to order a
sequence of writes to non-volatile memory. "

The documentation does not mention hw memory barriers since that is outside of
the compiler view really. This has been standard behavior with GCC and hardware
with weak memory systems for over 20 years.

That is even if GCC outputs the writes in order in the assembly the hardware
(or future hardware depending on the definition of the hardware) might reorder
the writes. RISCV IIRC has both a weak and strong memory consistency models.
https://riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTutorial.pdf
for more details on it. GCC will never output the needed instructions directly.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #28 from Peter Bergner  ---
Fixed everywhere.

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #27 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

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

commit r11-11413-gf8f02fd0bfeeb733a044a120b394eeac48de318a
Author: Peter Bergner 
Date:   Thu May 2 18:07:05 2024 -0500

rs6000: Add OPTION_MASK_POWER8 [PR101865]

The bug in PR101865 is the _ARCH_PWR8 predefine macro is conditional upon
TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if
the
-mno-altivec or -mno-vsx options are used.  The solution here is to create
a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
Altivec or VSX enablement.

Unfortunately, the only way to create an OPTION_MASK_* mask is to create
a new option, which we have done here, but marked it as WarnRemoved since
we do not want users using it.  For stage1, we will look into how we can
create ISA mask flags for use in the compiler without the need for explicit
options.

2024-04-12  Will Schmidt  
Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Use
OPTION_MASK_POWER8.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add
OPTION_MASK_POWER8.
(ISA_2_7_MASKS_SERVER): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Update
comment.  Use OPTION_MASK_POWER8 and TARGET_POWER8.
* config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
* config/rs6000/rs6000.md (define_attr "isa"): Add p8.
(define_attr "enabled"): Handle it.
(define_insn "prefetch"): Use TARGET_POWER8.
* config/rs6000/rs6000.opt (mpower8-internal): New.

gcc/testsuite/
PR target/101865
* gcc.target/powerpc/predefine-p7-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec.c: New test.
* gcc.target/powerpc/predefine-p8-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-pragma-vsx.c: New test.
* gcc.target/powerpc/predefine-p9-novsx.c: New test.

(cherry picked from commit aa57af93ba22865be747f926e4e5f219e7f8758a)

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #26 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:26d48b6d3e2d07583f25f0769d0c005864760aee

commit r11-11412-g26d48b6d3e2d07583f25f0769d0c005864760aee
Author: Peter Bergner 
Date:   Tue Apr 9 15:24:39 2024 -0500

rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
[PR101865]

This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with
OPTION_MASK_P8_VECTOR
and delete the now dead mask.

2024-04-09  Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete
redundant
OPTION_MASK_DIRECT_MOVE usage.  Delete TARGET_DIRECT_MOVE dead
code.
(rs6000_opt_masks): Neuter the "direct-move" option.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete useless
comment.
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
OPTION_MASK_DIRECT_MOVE.
(OTHER_P8_VECTOR_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var.

(cherry picked from commit 7924e352523b37155ed9d76dc426701de9d11a22)

[Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization

[nfxjfg at googlemail dot com via Gcc-bugs]

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

--- Comment #7 from nfxjfg at googlemail dot com ---
> Note also the order of the writes to reg1 and reg2 might happen in a 
> different order in HW so you need to have a full (HW) write barrier between 
> them to make sure the write is done in the correct order.

Seriously? That breaks literally all code that uses volatile for register
access (which, in our firmwares, is ALL code). This just fuels my belief that
gcc and C compiler developers in general turned C into a useless, fragile
language that can't do anything correctly.

Is there a way to prevent reordering of volatile accesses?

[Bug c++/114928] New: #pragma packed(push,1) should give the same warning as __attribute__((packed))

[dhylands at gmail dot com via Gcc-bugs]

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

Bug ID: 114928
   Summary: #pragma packed(push,1) should give the same warning as
__attribute__((packed))
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhylands at gmail dot com
  Target Milestone: ---

Created attachment 58091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58091=edit
File that compiles with no warnings

I'm using the ARM Toolchain
arm-gnu-toolchain-13.2.Rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-g++

running on Ubuntu 20.04

If I delcare my structure using:

struct Foo {
char y;
int x;
} __attribute__((packed));

then the compiler correctly gives me a warning about taking the address of a
packed member:

warning: taking address of packed member of ‘Foo’ may result in an unaligned
pointer value [-Waddress-of-packed-member]

However, if I change the structure to use #pragma pack(push, 1) 

#pragma pack(push, 1)
struct Foo {
char y;
int x;
};
#pragma pack(pop)

then I don't get the warning (and my bug is that it should give the same
warning).

In either case the member offsets and structure size are the same.

[Bug c/114927] New: ICE when building Emacs with -std=c23 -flto (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

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

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

Bug ID: 114927
   Summary: ICE when building Emacs with -std=c23 -flto (error:
‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58090=edit
process.i.xz

Hit this when building Emacs with -std=c23 (which bleeding-edge autoconf now
defaults to).

(Calling this an FE issue for now unless proven otherwise, given richi's
comments on my other bug wrt where the checking is done.)

```
$ gcc -c ./process.i -std=c23 -flto
process.c:8920:1: error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’
 8920 | }
  | ^
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 11 canonical-type
0x7f39a98235e8 precision:32 min  max

pointer_to_this >
QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
arg-types 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f39a9852d20>
chain >>
pointer_to_this >
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f39a98235e8 precision:32 min  max

pointer_to_this >
QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f39a8324d20
arg-types 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f39a9852d20>
chain >>
pointer_to_this >
during IPA pass: *free_lang_data
process.c:8920:1: internal compiler error: ‘verify_type’ failed
0x55d8b1cdf912 verify_type(tree_node const*)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/tree.cc:14395
0x55d8b3c5b46b free_lang_data
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1134
0x55d8b3c5b46b execute
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240430/gcc-14.1.0-RC-20240430/gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #34 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #22)
> Without load/store handling, here are the following optimizations that
> either can move to match.pd already or need some extra work to do it:
> 
> * value_replacement: need to handle !single_non_singleton_phi_for_edges case
> and more than one feeder statement (2 max according to the current
> definition)

There is a secondary part to value_replacement which requires more work than
just working on the phi. I have to think of how to handle that.


> * cond_removal_in_popcount_clz_ctz_pattern: need 2 feeder statements and
> builtin call handling for feeder statements



> 
> 
> * two_value_replacement: recored as PR 100958, it can move already

Handled.

> * abs_replacement: needs PROP_gimple_lswitch so we don't change if
> statements early enough
> ** I think majority of the abs handling is already in match.pd.

This is handled.

> * minmax_replacement: has some handling of comparisions which might not be
> in the match.pd patterns already.  needs PROP_gimple_lswitch also.
> ** The handling of:
>if (a <= u)
>  b = MAX (a, d);
>x = PHI 
>needs to moved too.
> 
> 
> For the ones which cannot move

There is a new part of minmax which I have a patch for but there is one part
missing still (recorded in PR 101024)

> * factor_out_conditional_conversion: will never move, though it needs
> improvement and moved already (PR 56223 and PR 13563)

I have an implementation which moves this over to using gimple_match_op (which
I need to a few testcases for it). Though some of this maybe should move over
to match ...

> * spaceship_replacement: cannot move to match.pd depends on use afterwards
> which is not hard to deal with in a match pattern.

I have to look at what is done for spaceship and maybe merge it in with what is
done for value_replacement (comparison after the phi) since they implement a
similar optimization.

[Bug tree-optimization/61110] Simplify value_replacement in phiopt

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 58089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58089=edit
Start of rewriting value_replacement to use match-and-simplify

This is a start and does not remove the old code. It has a few small
regressions due to not being able to merge the bb when doing the replacement.
this is something which I am working on but I am posting it here as I stopping
to work on this for a month or so but will come back to it.

[Bug middle-end/23872] .original dump weirdness

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

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

--- Comment #10 from Andrew Pinski  ---
Patches submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650586.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650587.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650585.html

[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

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

[Bug middle-end/106928] 500.perlbench_r fail(VE) since r13-1933

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

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

--- Comment #5 from Andrew Pinski  ---


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

[Bug middle-end/106928] 500.perlbench_r fail(VE) since r13-1933

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #4 from Andrew Pinski  ---


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

[Bug regression/103318] Spec 2017 benchmark perlbench_r fails on PowerPC for -Ofast and -O3, passes with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

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

[Bug middle-end/97263] For -ffinite-math-only -OFast is not mentioned.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I will modify the documentation next week to be more specific on this since
-Ofast is a hot topic right now including in LLVM.

e.g. https://discourse.llvm.org/t/rfc-deprecate-ofast/78687/36

[Bug tree-optimization/111882] [13 Regression] : internal compiler error: in get_expr_operand in ifcvt with Variable length arrays and bitfields inside a struct

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

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

Richard Ball  changed:

   What|Removed |Added

 CC||ricbal02 at gcc dot gnu.org

--- Comment #6 from Richard Ball  ---
Confirmed error exists on gcc-13. Backport applies cleanly and fixes the error.
Will request permission to backport on the mailing list.

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #11 from Martin Jambor  ---
It seems that clang is hitting the same problem now:
https://discourse.llvm.org/t/fast-math-spec-2017-fp-failure-for-povray/74959

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

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

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Andrew Pinski  ---
> If Aldy does not fix it by Saturday, I will give the union a try then. I will

Great, thanks.  Your alignas patch also worked fine btw.

> also try out the solaris machine on the compile farm if possible.

Otherwise, you can just send it my way and I'll give it a whirl.

[Bug libstdc++/77704] Data race on std::ctype

[rustamabd at gmail dot com via Gcc-bugs]

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

Rustam Abdullaev  changed:

   What|Removed |Added

 CC||rustamabd at gmail dot com

--- Comment #8 from Rustam Abdullaev  ---
Still an issue in GCC 12.3.0.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

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

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

--- Comment #10 from Andrew Pinski  ---
If Aldy does not fix it by Saturday, I will give the union a try then. I will
also try out the solaris machine on the compile farm if possible.

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com via Gcc-bugs]

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

--- Comment #3 from Ian Lance Taylor  ---
*** Bug 114583 has been marked as a duplicate of this bug. ***

[Bug go/114583] go.test/test/fixedbugs/issue4562.go FAILs

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Appears to be the same problem at PR 114582.

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

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com via Gcc-bugs]

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

--- Comment #4 from Ian Lance Taylor  ---
*** Bug 114584 has been marked as a duplicate of this bug. ***

[Bug go/114584] go.test/test/nil.go FAILs

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Appears to be the same as PR 114582.

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

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com via Gcc-bugs]

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

--- Comment #2 from Ian Lance Taylor  ---
*** Bug 114581 has been marked as a duplicate of this bug. ***

[Bug go/114581] go.test/test/fixedbugs/issue22881.go FAILs

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
I wrote a long explanation of the problem in PR 114582, so closing this one in
favor of that one.

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

[Bug go/114582] go.test/test/fixedbugs/issue34123.go FAILs

[ian at airs dot com via Gcc-bugs]

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

--- Comment #1 from Ian Lance Taylor  ---
The bug here, and also with PR 114581, is in unwinding from a signal call.  A
simplified version of the code for this issue is:

func main() {
defer func() { recover() }()
f()
}

func f() { *p = 0 }

The *p = 0 in f will raise a SIGSEGV.  The Go runtime will turn that into a
panic.  The recover in main will prevent that panic from killing the program.

The unwind code works by walking up the stack until it finds a recover.  When
it finds a recover, it records that stack frame as the end of the unwind.  It
runs the recover, then walks up the stack again to unwind it.  In the second
walk, it checks that it does not walk past the stack frame that calls recover.

Recording the stack frame is done based on what the signal handler calls the
CFA, which is, basically, the frame pointer.  It is also based on whether a
signal occurred in that frame.

In this test case, the function f is so simple that it has no frame.  That
turns out to mean that f's CFA is the same as main's CFA.  In the first stack
walk, we find main, and record main's CFA as the point where the second unwind
should stop.  In the second stack walk, when we get to f, we think we have
reached the end.  But we haven't, because we haven't reached main yet.  This
causes an assert, which shows up as a SIGABRT.

That is what happens today.  But it would work fine if we knew that a signal
occurred in f, as in fact it did.  However, we don't, because of this code in
libgcc/config/sol2-unwind.h:

  /* SIGFPE for IEEE-754 exceptions is delivered after the faulting insn
 rather than before it, so don't set fs->signal_frame in that case.
 We test whether the cexc field of the FSR is zero.  */
  if ((mctx->fpregs.fpu_fsr & 0x1f) == 0)
fs->signal_frame = 1;

If we unconditionally set fs->signal_frame, as is done on Linux, this would
work.  And it works on 64-bit SPARC, because those flags turn out to be zero. 
But on 32-bit SPARC, they are not zero.  Specifically, bit 0 is set, indicating
that an inexact operation occurred.  I don't know why.

That code was added by
https://gcc.gnu.org/legacy-ml/gcc-patches/2013-05/msg01390.html.  If I undo
that change, so that fs->signal_frame is set unconditionally as it was before,
then the Go test passes.

I don't know why it is reasonable to assume that if the floating-point inexact
flag is set then the signal is a floating-point signal.  In this case that is
clearly incorrect.

Because the problem here appears to be a Solaris-specific problem with
Solaris-specific code, I don't plan to work any further on it.

[Bug tree-optimization/114672] during GIMPLE pass: widening_mul ICE: verify_gimple failed: type mismatch in 'widen_mult_plus_expr' at -O2

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

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

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

https://gcc.gnu.org/g:87e37c72cfb153d65ac8b26d6f2d1fe155818318

commit r12-10410-g87e37c72cfb153d65ac8b26d6f2d1fe155818318
Author: Richard Biener 
Date:   Wed Apr 10 10:33:40 2024 +0200

tree-optimization/114672 - WIDEN_MULT_PLUS_EXPR type mismatch

The following makes sure to restrict WIDEN_MULT*_EXPR to a mode
precision final compute type as the mode is used to find the optab
and type checking chokes when seeing bit-precisions later which
would likely also not properly expanded to RTL.

PR tree-optimization/114672
* tree-ssa-math-opts.cc (convert_plusminus_to_widen): Only
allow mode-precision results.

* gcc.dg/torture/pr114672.c: New testcase.

(cherry picked from commit 912753cc5f18d786e334dd425469fa7f93155661)

[Bug tree-optimization/114672] during GIMPLE pass: widening_mul ICE: verify_gimple failed: type mismatch in 'widen_mult_plus_expr' at -O2

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

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

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

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

commit r13-8676-g0d625dc1bffd885b04eb90ff48a6d34acacc3e0b
Author: Richard Biener 
Date:   Wed Apr 10 10:33:40 2024 +0200

tree-optimization/114672 - WIDEN_MULT_PLUS_EXPR type mismatch

The following makes sure to restrict WIDEN_MULT*_EXPR to a mode
precision final compute type as the mode is used to find the optab
and type checking chokes when seeing bit-precisions later which
would likely also not properly expanded to RTL.

PR tree-optimization/114672
* tree-ssa-math-opts.cc (convert_plusminus_to_widen): Only
allow mode-precision results.

* gcc.dg/torture/pr114672.c: New testcase.

(cherry picked from commit 912753cc5f18d786e334dd425469fa7f93155661)

[Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization

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

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

--- Comment #6 from Andrew Pinski  ---
Some resources about memory barriers and why they are needed here (for both HW
and SW):
https://en.wikipedia.org/wiki/Memory_barrier

https://www.kernel.org/doc/Documentation/memory-barriers.txt
https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch09.html

And many more.

[Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Escape means something different from memory being written.

In C (and C++), memory writes to some variable is modeled such that it is not
known to write to another location
So you need to add a compiler barrier here.
Note `atomic_signal_fence (memory_order_relaxed)` might be enough. Note also
the order of the writes to reg1 and reg2 might happen in a different order in
HW so you need to have a full (HW) write barrier between them to make sure the
write is done in the correct order.

[Bug analyzer/114920] null_terminated_string_arg attribute does not warn for non-nul-terminated strings

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-02

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug report.

Confirmed with trunk; see e.g.:
  https://godbolt.org/z/5x5fqe4Td

I'm taking a look.

[Bug fortran/114922] fsyntax-only need the modules

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #2 from kargls at comcast dot net ---
While Harald gave one reason, consider the simply program

   use foo, only bar
   x = bar(1.)
   end

gfortran needs information about 'bar'.  Is it an array,
function, or subroutine?

[Bug target/114910] can't build a c6x cross compiler

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

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

--- Comment #6 from Marc Poulhiès  ---
It fails with -Os.
It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.

Mikael, is it possible that you're not using -Os for target libs?

[Bug libstdc++/114925] include/bits/fs_path.h#L841 deprecation note suggests UB

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
The suggestion is wrong anyway because _Source doesn't have to be a contiguous
iterator, or any kind of iterator at all.

[Bug fortran/114922] fsyntax-only need the modules

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
The documentation says:

-fsyntax-only

Check the code for syntax errors, but do not actually compile it. This will
generate module files for each module present in the code, but no other output
file.


So if you do not provide the needed modules, you should get exactly the same
errors as when compiling without -fsyntax-only.

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

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Patrick O'Neill :

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

commit r15-116-gff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2
Author: Patrick O'Neill 
Date:   Tue Apr 30 13:26:45 2024 -0700

RISC-V: Add testcase for pr114734

gcc/testsuite/ChangeLog:

PR middle-end/114734

* gcc.target/riscv/rvv/autovec/pr114734.c: New test.

Signed-off-by: Patrick O'Neill 

[Bug libstdc++/114925] include/bits/fs_path.h#L841 deprecation note suggests UB

[fabian_kessler at gmx dot de via Gcc-bugs]

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

--- Comment #2 from fabian_kessler at gmx dot de  
---
(In reply to Andrew Pinski from comment #1)
> I thought char8_t is still a character type so aliasing wise it falls under
> that rule.

Actually no. They are distinct types and only 4 types are allowed to alias
everything. That's char, signed/unsigned char and std::byte.

Consider the following function:

```
void cringe(char*& a, char8_t*& b){
b = u8"Hello There!"
print(a);
}
```

```
int main(){
   char8_t* obiwan = u8"Kenobi"; 
   cringe((char*&)obiwan, obiwan); // Might output "Kenobi" instead of "Hello
There!"   
}
```

That is, because the compiler is allowed to assume, that b can't alias a and no
change can't happen to a in that function.

[Bug libstdc++/114926] New: Add way to silence deprecation warning for fs::u8path

[fabian_kessler at gmx dot de via Gcc-bugs]

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

Bug ID: 114926
   Summary: Add way to silence deprecation warning for fs::u8path
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian_kessler at gmx dot de
  Target Milestone: ---

The deprecation of fs::u8path is in my eyes too early for c++20, since there is
no way to reinterpret a char sequence a char8_t sequence without UB.
Without having a capability to do this like suggested in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2626r0.pdf , people
have to use fs::u8path and since it is not removed in c++23 and 26, those want
to just silence the warning.

MSVC-STL has the _SILENCE_CXX20_U8PATH_DEPRECATION_WARNING definition.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #25 from Nicolas Boulenguez  ---
The suggested changes for libgnat slightly affect gprbuild.
https://salsa.debian.org/debian/gprbuild/-/blob/debian/master/debian/patches/adapt-to-private-time-t.diff
https://salsa.debian.org/debian/gprbuild/-/blob/debian/master/debian/patches/adapt-to-private-timeval.diff

[Bug regression/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
PR110822 rather seems closely related if not a dup.

[Bug libstdc++/114925] include/bits/fs_path.h#L841 deprecation note suggests UB

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

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

--- Comment #1 from Andrew Pinski  ---
I thought char8_t is still a character type so aliasing wise it falls under
that rule.

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

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Peter Dimov  ---
This should work.

I still don't understand why JF so insisted on all these padding shenanigans.

[Bug libstdc++/114925] New: include/bits/fs_path.h#L841 deprecation note suggests UB

[fabian_kessler at gmx dot de via Gcc-bugs]

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

Bug ID: 114925
   Summary: include/bits/fs_path.h#L841 deprecation note suggests
UB
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian_kessler at gmx dot de
  Target Milestone: ---

```
template,
   typename _CharT =
__detail::__value_type_is_char_or_char8_t<_Source>>
_GLIBCXX20_DEPRECATED_SUGGEST("path((const char8_t*)&*source)")
inline path
u8path(const _Source& __source)
```

This is clearly undefined behavior, since it breaks aliasing rules. Even if
it's implementation vise ok, it might not be correct with other compilers.

[Bug libstdc++/93672] [11/12 Regression] std::basic_istream::ignore hangs if delim MSB is set

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||13.2.1, 14.0
Summary|[11/12/13 Regression]   |[11/12 Regression]
   |std::basic_istream::ignore  |std::basic_istream::ignore
   |hangs if delim MSB is set   |hangs if delim MSB is set

--- Comment #8 from Jonathan Wakely  ---
Fixed for 13.3 and 14.1 so far.

[Bug libstdc++/104606] [11/12 Regression] comparison operator resolution with std::optional and -std=c++20

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||13.2.1, 14.0
Summary|[11/12/13 Regression]   |[11/12 Regression]
   |comparison operator |comparison operator
   |resolution with |resolution with
   |std::optional and   |std::optional and
   |-std=c++20  |-std=c++20

--- Comment #16 from Jonathan Wakely  ---
Fixed for 13.3 and 14.1 so far.

[Bug libstdc++/93672] [11/12/13 Regression] std::basic_istream::ignore hangs if delim MSB is set

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-8675-gfcf60d0baafa1245f768ac375dc60a07e92e9673
Author: Jonathan Wakely 
Date:   Thu Apr 4 10:33:33 2024 +0100

libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

A negative delim value passed to std::istream::ignore can never match
any character in the stream, because the comparison is done using
traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never returns
negative values (except at EOF). The optimized version of ignore for the
std::istream specialization uses traits_type::find to locate the delim
character in the streambuf, which _can_ match a negative delim on
platforms where char is signed, but then we do another comparison using
eq_int_type which fails. The code then keeps looping forever, with
traits_type::find locating the character and traits_type::eq_int_type
saying it's not a match, so traits_type::find is used again and finds
the same character again.

A possible fix would be to check with eq_int_type after a successful
find, to see whether we really have a match. However, that would be
suboptimal since we know that a negative delimiter will never match
using eq_int_type. So a better fix is to adjust the check at the top of
the function that handles delim==eof(), so that we treat all negative
delim values as equivalent to EOF. That way we don't bother using find
to search for something that will never match with eq_int_type.

The version of ignore in the primary template doesn't need a change,
because it doesn't use traits_type::find, instead characters are
extracted one-by-one and always matched using eq_int_type. That avoids
the inconsistency between find and eq_int_type. The specialization for
std::wistream does use traits_type::find, but traits_type::to_int_type
is equivalent to an implicit conversion from wchar_t to wint_t, so
passing a wchar_t directly to ignore without using to_int_type works.

libstdc++-v3/ChangeLog:

PR libstdc++/93672
* src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
Treat all negative delimiter values as eof().
* testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
* testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc: New
test.

(cherry picked from commit 2d694414ada8e3b58f504c1b175d31088529632e)

[Bug libstdc++/104606] [11/12/13 Regression] comparison operator resolution with std::optional and -std=c++20

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-8674-g3d16f8f2aec9583422d00c531732ca9d33e6ef26
Author: Jonathan Wakely 
Date:   Wed Mar 27 21:51:13 2024 +

libstdc++: Reverse arguments in constraint for std::optional's <=>
[PR104606]

This is a workaround for a possible compiler bug that causes constraint
recursion in the operator<=>(const optional&, const U&) overload.

libstdc++-v3/ChangeLog:

PR libstdc++/104606
* include/std/optional (operator<=>(const optional&, const U&)):
Reverse order of three_way_comparable_with template arguments.
* testsuite/20_util/optional/relops/104606.cc: New test.

(cherry picked from commit 7f65d8267fbfd19cf21a3dc71d27e989e75044a3)

[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
PR110802

[Bug c/114923] gcc ignores escaping pointer and applies invalid optimization

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

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

--- Comment #4 from Alexander Monakov  ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:

  asm volatile("" : "=m"(buf));

This cannot be reordered against accesses to volatile variables and doesn't
imply modification of anything except 'buf'.

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

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

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

Bug 114917 Summary: [modules] Explicit specialisations in export namespace not 
permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917

   What|Removed |Added

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

[Bug c++/114917] [modules] Explicit specialisations in export namespace not permitted

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #2 from Nathaniel Shead  ---
Fixed for GCC 15.

[Bug c++/114917] [modules] Explicit specialisations in export namespace not permitted

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:7317d62a1200dbd3685015e5d6b811497a27fe5f

commit r15-114-g7317d62a1200dbd3685015e5d6b811497a27fe5f
Author: Nathaniel Shead 
Date:   Thu May 2 12:55:24 2024 +1000

c++: Clear is_unbraced_* when parsing declaration_seq_opt [PR114917]

Currently we incorrectly retain "in_unbraced_linkage_specification_p"
and "in_unbraced_export_declaration_p" when parsing a (braced)
declaration-seq.  This patch ensures that we clear these flags before
parsing the toplevel declarations.

Strictly speaking we don't need to save and restore the flags around the
parsing because there's currently no way to provide new declarations
within the unbraced context after the closing brace, but this patch does
it anyway in case this ever changes and for consistency with other
places that these flags are adjusted.

PR c++/114917

gcc/cp/ChangeLog:

* parser.cc (cp_parser_declaration_seq_opt): Clear
parser->in_unbraced_* flags when parsing toplevel declarations.

gcc/testsuite/ChangeLog:

* g++.dg/modules/export-5_a.C: New test.
* g++.dg/modules/export-5_b.C: New test.
* g++.dg/parse/linkage4.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c/114923] gcc ignores escaping pointer and applies invalid optimization

[nfxjfg at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from nfxjfg at googlemail dot com ---
I'm expecting gcc to realize that the pointer escaped into the unknown, and
that it can't assume that the memory won't change. This is just causality, not
any vague made up viralyness.

Anyway, a 'asm volatile("":::"memory")' is too radical and increased code size
too much in my case (but it's a good suggestion). Making the buffer volatile
will inhibit optimizations before or after the DMA.

[Bug c/114923] gcc ignores escaping pointer and applies invalid optimization

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov  ---
'volatile' is not viral like that. If 'buf' can be accessed outside of the
abstract machine, it needs to be volatile itself. Alternatively, an empty asm
with a memory clobber, asm("":::"memory"), will imply a possible access to
'buf' via its escaped address.

[Bug target/114910] can't build a c6x cross compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1.0.47
experiences some problems not seen with gcc-13.2.0, but those are
compiler-warnings-that-now-are-errors rather than the assembler errors you
cited.)

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #25 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:04ca18ff5e2592ac88a5b72248332f519a17184b

commit r12-10409-g04ca18ff5e2592ac88a5b72248332f519a17184b
Author: Will Schmidt 
Date:   Fri Apr 12 14:55:16 2024 -0500

rs6000: Add OPTION_MASK_POWER8 [PR101865]

The bug in PR101865 is the _ARCH_PWR8 predefine macro is conditional upon
TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if
the
-mno-altivec or -mno-vsx options are used.  The solution here is to create
a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
Altivec or VSX enablement.

Unfortunately, the only way to create an OPTION_MASK_* mask is to create
a new option, which we have done here, but marked it as WarnRemoved since
we do not want users using it.  For stage1, we will look into how we can
create ISA mask flags for use in the compiler without the need for explicit
options.

2024-04-12  Will Schmidt  
Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported):
Use
TARGET_POWER8.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Use
OPTION_MASK_POWER8.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add
OPTION_MASK_POWER8.
(ISA_2_7_MASKS_SERVER): Likewise.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Update
comment.  Use OPTION_MASK_POWER8 and TARGET_POWER8.
* config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
* config/rs6000/rs6000.md (define_attr "isa"): Add p8.
(define_attr "enabled"): Handle it.
(define_insn "prefetch"): Use TARGET_POWER8.
* config/rs6000/rs6000.opt (mpower8-internal): New.

gcc/testsuite/
PR target/101865
* gcc.target/powerpc/predefine-p7-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-noaltivec.c: New test.
* gcc.target/powerpc/predefine-p8-novsx.c: New test.
* gcc.target/powerpc/predefine-p8-pragma-vsx.c: New test.
* gcc.target/powerpc/predefine-p9-novsx.c: New test.

(cherry picked from commit aa57af93ba22865be747f926e4e5f219e7f8758a)

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:135402288a1b1b082d2e71ff2ee5c63b7dafed9f

commit r12-10408-g135402288a1b1b082d2e71ff2ee5c63b7dafed9f
Author: Peter Bergner 
Date:   Tue Apr 9 15:24:39 2024 -0500

rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
[PR101865]

This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with
OPTION_MASK_P8_VECTOR
and delete the now dead mask.

2024-04-09  Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete
redundant
OPTION_MASK_DIRECT_MOVE usage.  Delete TARGET_DIRECT_MOVE dead
code.
(rs6000_opt_masks): Neuter the "direct-move" option.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR.  Delete useless
comment.
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
OPTION_MASK_DIRECT_MOVE.
(OTHER_P8_VECTOR_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var.

(cherry picked from commit 7924e352523b37155ed9d76dc426701de9d11a22)

[Bug rtl-optimization/114924] [11/12/13/14/15 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71

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

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

Alex Coplan  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
   Last reconfirmed||2024-05-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug rtl-optimization/114924] New: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71

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

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

Bug ID: 114924
   Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
by RTL loop unrolling since r11-2963-gd6a05b494b4b71
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase is reduced from
libgomp/testsuite/libgomp.fortran/imperfect-destructor.f90:

module m
  type t
contains
  final fini
  end type
  integer ccount(3)
  contains
subroutine init(x, n)
  type(t) x
  xi = n
  ccount = 1
end
subroutine fini(x)
  type(t) x
  dcount= s1 (a3)
  do i = 1, 1
block
  do j = 1, 2
block
  do k = 1, a3
block
  type (t) local3
  call init (local3, 3)
end block
  end do
end block
  end do
end block
  end do
end
end

compiling with -O2 -funroll-loops -da and looking at the RTL dumps, I see the
following insn in 284r.loop2_invariant:

(insn 44 40 45 8 (set (mem/c:SI (plus:DI (reg/f:DI 121)
(const_int 8 [0x8])) [3 ccount[2]+0 S4 A64])
(subreg:SI (reg:V2SI 111) 0)) "t.f90":11:16 discrim 2 69
{*movsi_aarch64}
 (expr_list:REG_DEAD (reg:V2SI 111)
(nil)))

then in 285r.loop2_unroll, I see:

(insn 44 40 45 8 (set (mem/c:SI (plus:DI (reg/f:DI 121)
(const_int 8 [0x8])) [3 ccount+0 S4 A64])
(subreg:SI (reg:V2SI 111) 0)) "t.f90":11:16 discrim 2 69
{*movsi_aarch64}
 (expr_list:REG_DEAD (reg/f:DI 121)
(expr_list:REG_DEAD (reg:V2SI 111)
(nil

notably the MEM_EXPR has been changed from ccount[2] to ccount, without a
corresponding change in offset.  This is incorrect.  Setting a watchpoint on
the
MEM_ATTRS of the relevant MEM showed that the update happens in
cfgrtl.cc:duplicate_insn_chain, which does the following:

/* We cannot adjust MR_DEPENDENCE_CLIQUE in-place
   since MEM_EXPR is shared so make a copy and
   walk to the subtree again.  */
tree new_expr = unshare_expr (MEM_EXPR (*iter));
if (TREE_CODE (new_expr) == WITH_SIZE_EXPR)
  new_expr = TREE_OPERAND (new_expr, 0);
while (handled_component_p (new_expr))
  new_expr = TREE_OPERAND (new_expr, 0);
MR_DEPENDENCE_CLIQUE (new_expr) = newc;
set_mem_expr (const_cast  (*iter), new_expr);

so the code (correctly) looks through the ARRAY_REF in this case to find
the underlying MEM_REF and updates MR_DEPENDENCE_CLIQUE for that
MEM_REF, but then proceeds to pass the MEM_REF to set_mem_expr, thereby
incorrectly dropping the ARRAY_REF in this case.

The code above was introduced in
r11-2963-gd6a05b494b4b714e996a5ca09c5a4a1c41dbd648 so I assume this is a
regression in GCC 11 and beyond.

I have a straightforward patch to fix this which passes bootstrap on
aarch64-linux-gnu, I will post that shortly.

While I don't have a wrong-code reproducer at the moment, we may want to
consider backporting the fix as incorrect MEM_EXPR information could
lead to wrong code.  I found the issue while working on a patch series
that has the side effect of introducing some consistency checking of the
MEM_EXPR information.

[Bug c/114923] gcc ignores escaping pointer and applies invalid optimization

[nfxjfg at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from nfxjfg at googlemail dot com ---
To make this explicitly clear: I expect that gcc reads back the buf value from
memory and returns that.

[Bug c/114923] New: gcc ignores escaping pointer and applies invalid optimization

[nfxjfg at googlemail dot com via Gcc-bugs]

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

Bug ID: 114923
   Summary: gcc ignores escaping pointer and applies invalid
optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nfxjfg at googlemail dot com
  Target Milestone: ---

Created attachment 58088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58088=edit
Test case

In this test case, the pointer to a stack-allocated variable is passed to a
volatile variable. That means the pointer definitely escapes. But the compiler
seems to assume that the memory can't change, and returns the initialization
value of the buf variable.

I tried multiple variations of this. Sometimes it generates the correct code,
even though the situation is exactly the same. A call to an external function
often fixes it, but sometimes not (could not produce a reduced test case of the
latter).

This is reduced from some real-word code. The first register access passes the
memory pointer to the hardware, the second access starts the DMA. In the
real-world code there was some more stuff such as waiting for the DMA to
finish, but it doesn't matter for code generation. The code started to fail
after a DMA buffer was moved from a global variable to the stack.

Originally experienced on 12.2.0 / riscv32-unknown-elf, but on godlbolt I can
reproduce it with trunk and some other architectures.

[Bug fortran/114922] New: fsyntax-only need the modules

[axel.ehrich--- via Gcc-bugs]

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

Bug ID: 114922
   Summary: fsyntax-only need the modules
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: axel.ehr...@tu-clausthal.de
  Target Milestone: ---

Created attachment 58087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58087=edit
Short Example for this problem

I encounter the following problem with gfortran: When I try to compile a file
(such as the one attached) with the options -c -fsyntax-only,
that is

"gfortran -c -fsyntax-only syntax-only_test.f90"

I receive the following error message:
--
syntax-only_test.f90:2:5:

2 | use module
  | 1
Fatal Error: Cannot open module file 'module.mod' for reading at (1): No such
file or directory
compilation terminated.
---

One purpose of the option "-fsyntax-only" is to create the module files (.mod),
however, without doing the compilation that would require module files. The
observed behaviour appears like a bug in gfortran.

I used 
https://aoterodelaroza.github.io/devnotes/modern-fortran-makefiles/
to look how i can solve the problem with the depends of mod files.

Best regards,
Axel

[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++

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

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #13 from Jason Merrill  ---
> Should be fixed now.

It is indeed.  Thanks a lot.

[Bug tree-optimization/114672] during GIMPLE pass: widening_mul ICE: verify_gimple failed: type mismatch in 'widen_mult_plus_expr' at -O2

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

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

Richard Ball  changed:

   What|Removed |Added

 CC||ricbal02 at gcc dot gnu.org

--- Comment #4 from Richard Ball  ---
Confirmed bug exists in gcc-12 and gcc-13. Backport applies cleanly and fixes
the issue. I'll request a backport on the mailing list

[Bug modula2/113836] gm2 does not dump gimple or quadruples to a file

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #11 from Gaius Mulley  ---
Closing now the patch has been applied.

[Bug modula2/113836] gm2 does not dump gimple or quadruples to a file

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:43dc4302b4181535d24e83759514b774ae4dbfcc

commit r15-110-g43dc4302b4181535d24e83759514b774ae4dbfcc
Author: Gaius Mulley 
Date:   Thu May 2 13:16:07 2024 +0100

PR modula2/113836 gm2 does not dump gimple or quadruples to a file

This patch completes the implementation of dumping the intermediate forms
to file.  It implements the filtering on symbol rules.  Filtering can be
performed through the full text name (given to the GCC tree) or qualified
modula-2 symbol or filename:qualident.

gcc/ChangeLog:

PR modula2/113836
* doc/gm2.texi (Compiler options): Add -fm2-debug-trace=,
-fm2-dump, -fm2-dump-decl=, -fm2-dump-gimple=, -fm2-dump-quad=
and -fm2-dump-filter=.

gcc/m2/ChangeLog:

PR modula2/113836
* gm2-compiler/M2AsmUtil.def: Remove export qualified and
unused import.
* gm2-compiler/M2LangDump.mod (AddRuleTextDump): New procedure.
(AddRuleScopeQualidentDump): Add warning check against unmatched
rule.
(GenQualidentSymString): New procedure function.
(IdentQualidentMatch): New procedure function.
(IsRuleFilenameMatch): New procedure function.
(CheckRuleMatch): New procedure function.
(AddRuleFilenameDump): New procedure function.
* gm2-gcc/m2misc.cc (m2misc_warning_m2_dump_filter): New function.
* gm2-gcc/m2misc.def (warning_m2_dump_filter): New procedure.
* gm2-gcc/m2misc.h (m2misc_warning_m2_dump_filter): New prototype.
* gm2-gcc/m2pp.cc (VERBOSE_TYPE_DESC): New define.
(m2pp_identifier): Define out verbose type info.
(m2pp_constructor): Define out verbose type info.
(m2pp_assignment): Define out verbose type info.
* gm2-lang.cc (ENABLE_M2DUMP_ALL): Remove.
* lang.opt (fm2-dump): Add.
(fm2-dump-decl=): Add.
(fm2-dump-gimple=): Add.
(fm2-dump-quad=): Add.
(fm2-dump-filter=): Add.

Signed-off-by: Gaius Mulley 

[Bug ada/112958] [12/13/14/15 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86

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

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Gerald Pfeifer  ---
> FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting
> it; FreeBSD 15 is dropping support for it.

Ah, I wasn't aware of that (and was particularly interested in i386 for
comparison with Solaris/i386 asan).

> Can we disable libgnat (or GNAT) support during configure time?

Sure: --disable-libasan should work for every toplevel library, although
there's little point in building GNAT without the runtime libs.  Given
that there's no --disable-languages (I've filed a PR for that ages ago,
I believe), you have to use

--enable-languages=

instead of

--enable-languages=all --disable-languages=ada

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

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

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

--- Comment #18 from Jonathan Wakely  ---
So maybe:

diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index aa7374bb252..662cff39df5 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -956,7 +956,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr bool
   __maybe_has_padding()
   {
-#if ! __has_builtin(__builtin_clear_padding)
+   // We cannot clear padding in the constructor for C++11,
+   // so return false here to disable all code for zeroing padding.
+#if __cplusplus < 201402L || ! __has_builtin(__builtin_clear_padding)
return false;
 #elif __has_builtin(__has_unique_object_representations)
return !__has_unique_object_representations(_Tp)
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 36ff89a146c..336f27832fc 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,6 +238,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr atomic(_Tp __i) noexcept : _M_i(__i)
   {
+   // A constexpr constructor must be empty in C++11,
+   // so we can only clear padding for C++14 and later.
 #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
  __builtin_clear_padding(std::__addressof(_M_i));

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

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

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  
>constexpr atomic(_Tp __i) noexcept : _M_i(__i)
>{
> -#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> +#if __has_builtin(__builtin_clear_padding)
> +#if __cplusplus >= 201402L
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
> +#endif
>   __builtin_clear_padding(std::__addressof(_M_i));
>  #endif
>}

Oh right, that still doesn't work in C++11:

/home/jwakely/gcc/15/include/c++/15.0.0/atomic: In constructor
'std::atomic<_Tp>::atomic(_Tp)':
/home/jwakely/gcc/15/include/c++/15.0.0/atomic:247:7: error: 'constexpr'
constructor does not have empty body

I remember hitting this when I implemented the padding stuff.

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

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

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

--- Comment #16 from Jonathan Wakely  ---
Alternatively, we could skip all the padding cope in compare_exchange for
C++11, since that was a C++20 change and not a DR.

[Bug c++/114921] Optimization flags cause _Float16 to __bf16 casting to do nothing

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||wrong-code
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-02
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Confirmed.  We vectorize the loop to

   [local count: 119292720]:
  vect_temp_9.6_3 = MEM  [(_Float16 *)f_7(D)];
  vect__4.7_9 = VIEW_CONVERT_EXPR(vect_temp_9.6_3);
  MEM  [(__bf16 *)f_7(D)] = vect__4.7_9;
  vect_temp_9.6_17 = MEM  [(_Float16 *)f_7(D) + 8B];
  vect__4.7_18 = VIEW_CONVERT_EXPR(vect_temp_9.6_17);
  MEM  [(__bf16 *)f_7(D) + 8B] = vect__4.7_18;

likely because the vectorizer thinks this is a noop conversion, it handles
it via vectorizable_assignment.

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

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

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

--- Comment #15 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr atomic(_Tp __i) noexcept : _M_i(__i)
   {
-#if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
+#if __has_builtin(__builtin_clear_padding)
+#if __cplusplus >= 201402L
if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
+#endif
  __builtin_clear_padding(std::__addressof(_M_i));
 #endif
   }

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

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

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

--- Comment #14 from Jonathan Wakely  ---
Because a constexpr function can't have an if statement in C++11.

But maybe we should just clear padding unconditionally for C++11.

[Bug middle-end/114579] RTL expansion add_scope_conflicts is slow

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed for GCC 15, I don't have a testcase that's slow here anymore.

[Bug lto/114918] ICE when building gcl with LTO

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-02
 Status|UNCONFIRMED |NEW

--- Comment #5 from Richard Biener  ---
Note this requires -flto only because we don't reliably call verify_type on all
types.  -g doesn't help (dwarf2out also calls verify_type).

Confirmed.

[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/650
   ||419.html
   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650419.html

[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |c++

--- Comment #6 from Richard Biener  ---
#4  0x016da304 in fold_ctor_reference (
type=, ctor=, 
poly_offset=..., poly_size=..., 
from_decl=, suboff=0x7fffcbb8)
at /space/rguenther/src/gcc/gcc/gimple-fold.cc:8236
8236return canonicalize_constructor_val (unshare_expr (ctor),
from_decl);

'ctor' is the ADDR_EXPR that doesn't have TREE_CONSTANT set correctly.  The
tree is probably mangled after the ADDR_EXPR is built.  This looks like a
bug in the C++ frontend to me.

[Bug tree-optimization/114912] [15 regression] SIGBUS in wi::copy<> on SPARC since r15-88-gc60b3e211c5557 since char array is not aligned to what it needs to be

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Andrew Pinski from comment #8)
> The other way of fixing this is to use an union and I think since we are
> using C++11, it might work correctly.
> 
> I do think we should prefer the union rather than having it as a char array
> too ...

If a union works then indeed that's what we should use.