[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #15 from Stefan Schulze Frielinghaus  
---
Hi Sam, thanks for the pointer. Taking it now.

[Bug target/116245] [15 regression] gcc.dg/torture/pr116037.c fails on s390x

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Thanks for the ping.  The test is skipped for -m31 and fails for -m64.  Maybe
this is some sort of endianness thingy?

typedef __attribute__((__vector_size__ (64))) unsigned __int128 VV;

__attribute__ ((noipa))
unsigned char
foo (VV vv)
{
  return ((VC) vv)[0];
}

int
main (void)
{
  unsigned char x = foo ((VV) { -0xff });
  __builtin_printf ("%u\n", x);
}

prints 255 on s390 and 1 on x86_64.  At start of function foo we have

(gdb) x/16xb $r2
0x3ff9450:  0xff0xff0xff0xff0xff0xff0xff0xff
0x3ff9458:  0xff0xff0xff0xff0xff0xff0xff0x01

In foo we then load the most significant byte:

 llgc%r2,0(%r2)
   br  %r14

and zero extend it.

[Bug target/116245] [15 regression] gcc.dg/torture/pr116037.c fails on s390x

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

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
I gave it a quick try on s390 and test passes, now. Thanks!

[Bug middle-end/111821] [12/13/14 Regression] OOM with packed struct and stack variable with copy

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 CC||stefansf at gcc dot gnu.org

--- Comment #8 from Stefan Schulze Frielinghaus  
---
Tests gcc.dg/torture/pr111821.c are failing for s390 which looks like a bug in
the back end.  I will have a look at this.

[Bug rtl-optimization/116372] New: [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

Bug ID: 116372
   Summary: [15 Regression] Ada bootstrap failure
ada/gcc-interface/trans.cc:6423 since
r15-2890-g72c9b5f438f22c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

Bootstrap fails while using --with-arch=z13 (probably any somewhat recent
machine) --disable-multilib --enable-languages=c,ada with

/devel/build/./prev-gcc/xgcc -B/devel/build/./prev-gcc/
-B/devel/dst/s390x-ibm-linux-gnu/bin/ -B/devel/dst/s390x-ibm-linux-gnu/bin/
-B/devel/dst/s390x-ibm-linux-gnu/lib/ -isystem
/devel/dst/s390x-ibm-linux-gnu/include -isystem
/devel/dst/s390x-ibm-linux-gnu/sys-include   -fchecking=1 -c -g -O2
-fchecking=1  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I/devel/src/gcc/ada -Iada/libgnat
-I/devel/src/gcc/ada/libgnat -Iada/gcc-interface
-I/devel/src/gcc/ada/gcc-interface /devel/src/gcc/ada/spark_xrefs.adb -o
ada/spark_xrefs.o
+===GNAT BUG DETECTED==+
| 15.0.0 20240814 (experimental) (s390x-ibm-linux-gnu) GCC error:  |
| in gnat_to_gnu, at ada/gcc-interface/trans.cc:6423   |
| Error detected at spark_xrefs.ads:31:9   |
| Compiling /devel/src/gcc/ada/spark_xrefs.adb |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/devel/src/gcc/ada/gcc-interface/system.ads
/devel/src/gcc/ada/spark_xrefs.adb
/devel/src/gcc/ada/spark_xrefs.ads
/devel/src/gcc/ada/types.ads
/devel/src/gcc/ada/libgnat/ada.ads
/devel/src/gcc/ada/libgnat/a-unccon.ads
/devel/src/gcc/ada/libgnat/a-uncdea.ads
/devel/src/gcc/ada/lib.ads
/devel/src/gcc/ada/alloc.ads
/devel/src/gcc/ada/namet.ads
/devel/src/gcc/ada/hostparm.ads
/devel/src/gcc/ada/table.ads
ada/gnat.ads
/devel/src/gcc/ada/libgnat/g-htable.ads
/devel/src/gcc/ada/libgnat/s-htable.ads
/devel/src/gcc/ada/lib-xref.ads
/devel/src/gcc/ada/einfo.ads
ada/snames.ads
/devel/src/gcc/ada/stand.ads
/devel/src/gcc/ada/uintp.ads
/devel/src/gcc/ada/urealp.ads
ada/einfo-entities.ads
/devel/src/gcc/ada/sinfo.ads
ada/sinfo-nodes.ads
ada/seinfo.ads
/devel/src/gcc/ada/output.ads
/devel/src/gcc/ada/libgnat/s-os_lib.ads
/devel/src/gcc/ada/libgnat/s-string.ads
/devel/src/gcc/ada/sem_util.ads
/devel/src/gcc/ada/aspects.ads
/devel/src/gcc/ada/atree.ads
/devel/src/gcc/ada/einfo-utils.ads
/devel/src/gcc/ada/exp_tss.ads
/devel/src/gcc/ada/opt.ads
/devel/src/gcc/ada/libgnat/s-wchcon.ads
/devel/src/gcc/ada/libgnat/s-exctab.ads
/devel/src/gcc/ada/libgnat/s-stalib.ads
/devel/src/gcc/ada/libgnat/s-unstyp.ads
/devel/src/gcc/ada/libgnat/s-conca2.ads
/devel/src/gcc/ada/libgnat/s-assert.ads
/devel/src/gcc/ada/libgnat/a-assert.ads
/devel/src/gcc/ada/libgnat/s-secsta.ads
/devel/src/gcc/ada/libgnat/s-parame.ads
/devel/src/gcc/ada/libgnat/s-stoele.ads
/devel/src/gcc/ada/lib-xref.adb
/devel/src/gcc/ada/csets.ads
/devel/src/gcc/ada/elists.ads
/devel/src/gcc/ada/errout.ads
/devel/src/gcc/ada/err_vars.ads
/devel/src/gcc/ada/erroutc.ads
/devel/src/gcc/ada/lib-util.ads
/devel/src/gcc/ada/nlists.ads
/devel/src/gcc/ada/restrict.ads
/devel/src/gcc/ada/rident.ads
ada/s-rident.ads
/devel/src/gcc/ada/sem.ads
/devel/src/gcc/ada/sem_aux.ads
/devel/src/gcc/ada/sem_prag.ads
/devel/src/gcc/ada/sem_warn.ads
/devel/src/gcc/ada/sinfo-utils.ads
/devel/src/gcc/ada/sinput.ads
/devel/src/gcc/ada/casing.ads
/devel/src/gcc/ada/stringt.ads
/devel/src/gcc/ada/warnsw.ads
/devel/src/gcc/ada/libgnat/g-hesorg.ads
/devel/src/gcc/ada/lib-xref-spark_specific.adb
ada/nmake.ads

compilation abandoned
make[3]: *** [/devel/src/gcc/ada/gcc-interface/Make-lang.in:166:
ada/spark_xrefs.o] Error 1
make[3]: Leaving directory '/devel/build/gcc'
make[2]: *** [Makefile:5136: all-stage3-gcc] Error 2
make[2]: Leaving directory '/devel/build'
make[1]: *** [Makefile:24622: stage3-bubble] Error 2
make[1]: Leaving directory '/devel/build'
make: *** [Makefile:1101: all] Error 2

Bisect stops at r15-2890-g72c9b5f438f22c
Tested against r15-2910-gbb2324769c5a03 which includes
r15-2903-gcc00a737e84098. So maybe this is not re

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Finally a more manageable reproducer:

long x = -0x7fff - 1;
int main (void)
{
  long y = x % (-0xf - 1);
  if (-0x7fff - 1 + y == x == 0)
__builtin_abort ();
}

If compiled with -O1 -march=z13 and r15-2889 execution is successful and fails
with r15-2890 with r15-2903 manually applied on top.  I haven't looked much
into it but at least they deviate in ce1 where I see

if-conversion succeeded through noce_convert_multiple_sets

Of course, might be still a latent bug/something else.

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Created attachment 58936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58936&action=edit
Dump from r15-2890

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Created attachment 58937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58937&action=edit
Dump from r15-2890 with r15-2903

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
(In reply to Stefan Schulze Frielinghaus from comment #3)
> Created attachment 58936 [details]
> Dump from r15-2890

Ups, I actually meant "Dump from r15-2889" of course.

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #9 from Stefan Schulze Frielinghaus  
---
FYI: bootstrap is restored with the patch.  Thanks!

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #11 from Stefan Schulze Frielinghaus  
---
Closing since bootstrap is resolved:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-August/823187.html

[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
(In reply to Michael Matz from comment #1)
> If you're interested you might want to test a patch from
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116650
> which came up during m68k vs LRA.

Thanks for the ping.  I think this bug is about that subregs survive register
allocation.  With the new approach those are replaced properly and regrename
doesn't interfere.

[Bug tree-optimization/114678] New: FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

Bug ID: 114678
   Summary: FAIL: gcc.dg/tree-ssa/range-sincos.c
scan-tree-dump-not evrp "link_error" on s390
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error"

I assume this is due to the case that on s390 we have an isinf optab.  Thus,
prior evrp we end up with

void bar (double x)
{
  int _1;
  double _5;

   :
  _5 = sin (x_4(D));
  if (_5 ord _5)
goto ; [INV]
  else
goto ; [INV]

   :
  _1 = __builtin_isinf (x_4(D));
  if (_1 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  link_error ();

   :
  return;

}

whereas, e.g., on x86-64 we have

void bar (double x)
{
  double _1;
  double _7;

   :
  _7 = sin (x_6(D));
  if (_7 ord _7)
goto ; [INV]
  else
goto ; [INV]

   :
  if (x_6(D) unord x_6(D))
goto ; [INV]
  else
goto ; [INV]

   :
  link_error ();

   :
  _1 = ABS_EXPR ;
  if (_1 u<= 1.79769313486231570814527423731704356798070567525844996599e+308)
goto ; [INV]
  else
goto ; [INV]

   :
  link_error ();

   :
  return;

}

If this optimization is all about ABS_EXPR the following patch would work on
s390x and x86-64:

@@ -24,20 +24,20 @@ bar (double x)
 {
   if (__builtin_isnan (x))
link_error ();
-  if (__builtin_isinf (x))
+  if (__builtin_fabs (x) == __builtin_inf ())
link_error ();
 }
 }

However, I'm not sure whether this is not also a missed optimization in case of
an isinf optab?

[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Thanks for the pointer.  I can confirm that the patch fixes this PR and also
fixes

FAIL: gcc.dg/tree-ssa/vrp-float-abs-1.c scan-tree-dump-not evrp "link_error"

[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Ok, done in https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649367.html

[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

   Last reconfirmed||2024-4-17
 CC||stefansf at gcc dot gnu.org

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Reproducible via

$ wget https://www.codelabs.ch/download/libalog-0.6.2.tar.bz2
$ tar xf libalog-0.6.2.tar.bz2
$ gcc -c -x ada -gnatA -gnatygAdISuxo -gnatVa -gnatwal -gnatf -fstack-check
-gnato -g -O2 -fno-omit-frame-pointer -mbackchain -gnatwe -fPIC
libalog-0.6.2/src/alog-active_logger.adb

Started with r12-4926-g79fe28d2c4b785
Confirmed on trunk r14--g9c7cf5d71f0716

@Doko does Debian use -mbackchain? I can reproduce this on Ubuntu even for z196
but -mbackchain and -fstack-check are required in order to fail. For me 12.3 is
failing, too, which matches with my bisect. How did you test 12.3?

[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Fails for function alog.active_logger.logging_taskT and trace 2 whose heads are

(gdb) call debug(ti->head)
(code_label 48 573 49 152 (nil) [2 uses])

(gdb) call debug(ti->eh_head)
(insn 57 765 58 (set (reg/f:DI 14 %r14 [orig:74 _39 ] [74])
(mem/f:DI (reg/f:DI 10 %r10 [orig:123 _task ] [123]) [0
_task_25(D)->parent+0 S8 A64]))
"libalog-0.6.2/src/alog-active_logger.adb":252:33 discrim 2 1477 {*movdi_64}
 (expr_list:REG_EH_REGION (const_int 6 [0x6])
(nil)))

Looking at the trace there exists no insn with a ARGS_SIZE note which is why

gcc_assert (!ti->args_size_undefined || ti->args_size_defined_for_eh);

fails.

[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Created attachment 57971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57971&action=edit
dwarf2cfi dump for alog-active_logger.adb

[Bug middle-end/114802] New: FAIL: gcc.dg/tree-ssa/forwprop-40.c and forwprop-41.c on s390

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

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

Bug ID: 114802
   Summary: FAIL: gcc.dg/tree-ssa/forwprop-40.c and forwprop-41.c
on s390
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 1

Originating from PR93080 the tests fail on s390 since can_vec_perm_const_p
fails which r14-3381-g27de9aa152141e aims for and therefore the bit insert/ref
survive. Thus, currently for forwprop-40.c we emit:

g:
vlgvf   %r1,%v24,0  
vlvgf   %v24,%r1,0
br  %r14

and for forwprop-41.c:

g:
vlgvf   %r1,%v24,2
vlvgf   %v24,%r1,2
vlvgf   %v24,%r2,1
br  %r14

[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Ignore the previous comment.  With -fstack-check and -mbackchain we have for
trace 2 an incoming edge from trace 1 (fallthrough) where
cur_trace->end_true_args_size == 48 and from further incoming edges as e.g.
from trace 7 where cur_trace->end_true_args_size == 0 which is why the
args_size is supposed to be undefined.

Interestingly, trace 2 resides in the function body whereas trace 7 resides in
the epilogue, i.e., we have a jump from the epilogue into the function body:

(note 597 810 634 NOTE_INSN_PROLOGUE_END)
...
(insn 635 677 566 (set (reg/f:DI 15 %r15)
(plus:DI (reg/f:DI 15 %r15)
(const_int 8216 [0x2018])))
"libalog-0.6.2/src/alog-active_logger.adb":244:4 1481 {*la_64}
 (expr_list:REG_ARGS_SIZE (const_int 48 [0x30])
(nil)))
...
(code_label 48 573 49 152 (nil) [2 uses])
...
(note 673 768 599 NOTE_INSN_EPILOGUE_BEG)
...
(insn 159 163 160 (set (reg/f:DI 15 %r15)
(reg/f:DI 6 %r6 [orig:79 saved_stack.186_50 ] [79]))
"libalog-0.6.2/src/alog-active_logger.adb":260:0 discrim 10 1477 {*movdi_64}
 (expr_list:REG_DEAD (reg/f:DI 6 %r6 [orig:79 saved_stack.186_50 ] [79])
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
...
(jump_insn 645 644 646 (set (pc)
(label_ref 48)) 2170 {*jump64}
 (nil)
 -> 48)

This is also the case when -fno-shrink-wrap is used.

[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)

[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 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)

[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

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug rtl-optimization/115261] New: FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c

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

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

Bug ID: 115261
   Summary: FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

After r11-5821-gebdfd1606da6b5 multiple BIT_INSERT_EXPRs are vectorized which
as a side-effect leads to the usage of V2SI which seems to be the culprit of an
extra stack slot.  For s390/vector/vec-abi-vararg-1.c we end up with

(insn 11 10 12 2 (set (subreg:V2SI (reg:V4SI 73 [ _3 ]) 0)
(plus:V2SI (mem:V2SI (plus:DI (reg/f:DI 32 %ap)
(const_int 16 [0x10])) [0 MEM[(v2si * {ref-all})_26 +
16B]+0 S8 A64])
(mem:V2SI (plus:DI (reg/f:DI 32 %ap)
(const_int 40 [0x28])) [0 MEM[(v2si * {ref-all})_26 +
40B]+0 S8 A64]))) "vec-abi-vararg-1.c":44:16 581 {addv2si3}
 (nil))

which reload needs to fix

11: r79:V2SI=r80:V2SI+r81:V2SI
 Inserting insn reload before:
26: r80:V2SI=[%ap:DI+0x170]
27: r81:V2SI=[%ap:DI+0x188]
 Inserting insn reload after:
25: r73:V4SI#0=r79:V2SI
...
12: r74:V2DI=sign_extend(vec_select(r82:V4SI,parallel))
   REG_DEAD r73:V4SI
 Inserting insn reload before:
28: r82:V4SI=r73:V4SI

which materializes as:

(insn 10 14 24 2 (set (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])) "vec-abi-vararg-1.c":44:16 410 {movv4si}
  (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(nil)))
(insn 24 10 26 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S16 A64])
(reg:V4SI 16 %f0 [orig:73 _3 ] [73])) "vec-abi-vararg-1.c":44:16 410
{movv4si}
 (nil))
(insn 26 24 27 2 (set (reg:V2SI 16 %f0 [80])
(mem:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 384 [0x180])) [0 MEM[(v2si * {ref-all})_26 + 16B]+0
S8 A64])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 27 26 11 2 (set (reg:V2SI 17 %f2 [81])
(mem:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 408 [0x198])) [0 MEM[(v2si * {ref-all})_26 + 40B]+0
S8 A64])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 11 27 25 2 (set (reg:V2SI 16 %f0 [79])
(plus:V2SI (reg:V2SI 16 %f0 [80])
(reg:V2SI 17 %f2 [81]))) "vec-abi-vararg-1.c":44:16 581 {addv2si3}
 (nil))
(insn 25 11 28 2 (set (mem/c:V2SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S8 A64])
(reg:V2SI 16 %f0 [79])) "vec-abi-vararg-1.c":44:16 426 {movv2si}
 (nil))
(insn 28 25 12 2 (set (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(mem/c:V4SI (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [4 %sfp+-48 S16 A64]))
"vec-abi-vararg-1.c":44:16 410 {movv4si}
 (nil))
(insn 12 28 29 2 (set (reg:V2DI 16 %f0 [orig:74 _29 ] [74])
(sign_extend:V2DI (vec_select:V2SI (reg:V4SI 16 %f0 [orig:73 _3 ] [73])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
] "vec-abi-vararg-1.c":44:16 1345 {vec_unpacks_hi_v4si}
 (nil))

Insn 25 and 28 convert a V2SI into a V4SI via stack.  It is a bit unfortunate
since the resulting V4SI vector is used for unpacking which ignores the
rightmost half, i.e., zeroing out the rightmost half by going over the stack is
unnecessary.

[Bug rtl-optimization/115261] [11/12/13/14/15 regression] FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Thanks for the pointer. Indeed, adding an extendv2siv2di pattern solves this
and the code looks optimal then. I will come up with a patch.

[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

--- Comment #21 from Stefan Schulze Frielinghaus  
---
Fixed for GCC 14 and 15 for s390.

[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #22 from Stefan Schulze Frielinghaus  
---
Changing state to fixed.  Feel free to reopen if this has to be fixed for a
different target.

[Bug middle-end/85559] [meta-bug] Improve conditional move

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

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

Bug 109549 Summary: [14/15 Regression] Conditional move regressions after 
r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549

   What|Removed |Added

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

[Bug target/115519] New: s390 fallout from removing vcond{,u,eq} patterns

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

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

Bug ID: 115519
   Summary: s390 fallout from removing vcond{,u,eq} patterns
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
Blocks: 114189
  Target Milestone: ---
Target: s390*-*-*

When applying the patch from PR114189 testing reveals

gcc.target/s390/vector/vcond-shift.c scan-assembler-not vzero\t*
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrab\t%v.?,%v.?,7 6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesraf\t%v.?,%v.?,31
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrah\t%v.?,%v.?,15
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlb\t%v.?,%v.?,7 4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlf\t%v.?,%v.?,31
4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlh\t%v.?,%v.?,15
4
gcc.target/s390/zvector/autovec-long-double-signaling-ge.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-gt.c scan-assembler
\\n\\twfkhxb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-le.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-lt.c scan-assembler
\\n\\twfkhxb\\t


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
For example, for function vesrlf_ge from vcond-shift.c we do not end up with

vl  %v2,0(%r2),3
vl  %v0,16(%r2),3
lgr %r1,%r2
vesrlf  %v4,%v2,31
vesrlf  %v6,%v0,31
vst %v4,0(%r1),3
vst %v6,16(%r1),3
br  %r14

anymore but

vl  %v0,0(%r2),3
vl  %v4,16(%r2),3
vgmf%v6,31,31
vzero   %v2
vesraf  %v1,%v0,31
vesraf  %v3,%v4,31
vsel%v5,%v6,%v2,%v1
vsel%v7,%v6,%v2,%v3
lgr %r1,%r2
vst %v5,0(%r1),3
vst %v7,16(%r1),3
br  %r14

During a vcond expand we optimized x < 0 ? 1 : 0 into x >> 31 which we fail to
do, now.  Doing it late in combine fails, too, since we never come up with a
combination of insn 7, 8, 9, and 10:

(insn 7 6 8 2 (set (reg:V4SI 69 [ mask__5.8_4 ])
(ashiftrt:V4SI (reg:V4SI 68 [ MEM  [(int *)xx_10] ])
(const_int 31 [0x1f]))) "vcond-shift.c":155:28 905 {*ashrv4si3}
 (expr_list:REG_DEAD (reg:V4SI 68 [ MEM  [(int *)xx_10] ])
(nil)))
(insn 8 7 9 2 (set (reg:V4SI 70)
(const_vector:V4SI [
(const_int 1 [0x1]) repeated x4
])) 410 {movv4si}
 (nil))
(insn 9 8 10 2 (set (reg:V4SI 71)
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])) 410 {movv4si}
 (nil))
(insn 10 9 11 2 (set (reg:V4SI 62 [ vect_patt_18.9 ])
(if_then_else:V4SI (eq (reg:V4SI 69 [ mask__5.8_4 ])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
]))
(reg:V4SI 71)
(reg:V4SI 70))) 1265 {*vec_sel0v4si}
 (expr_list:REG_DEAD (reg:V4SI 69 [ mask__5.8_4 ])
(expr_list:REG_EQUAL (if_then_else:V4SI (eq (reg:V4SI 69 [ mask__5.8_4
])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_vector:V4SI [
(const_int 1 [0x1]) repeated x4
]))
(nil

So maybe this is something for match.pd?

[Bug rtl-optimization/115261] [11/12/13/14/15 regression] FAIL: gcc.target/s390/vector/vec-abi-vararg-1.c

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Fixed on mainline.

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Just saw on the ML that a match.pd fix already exists
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655484.html

A quick test shows that this fixes vcond-shift.c where we now emit

  ((int) ((unsigned int) xx >> 31) + xx) >> 1

and previously

  (xx - (xx >> 31)) >> 1

which is basically the same.  We just have to adapt the times for
scan-assembler w.r.t. signed/unsigned shifts:

diff --git a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
index a6b4e97aa50..b942f44039d 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
@@ -3,13 +3,13 @@
 /* { dg-do compile { target { s390*-*-* } } } */
 /* { dg-options "-O3 -march=z13 -mzarch" } */

-/* { dg-final { scan-assembler-times "vesraf\t%v.?,%v.?,31" 6 } } */
-/* { dg-final { scan-assembler-times "vesrah\t%v.?,%v.?,15" 6 } } */
-/* { dg-final { scan-assembler-times "vesrab\t%v.?,%v.?,7" 6 } } */
+/* { dg-final { scan-assembler-times "vesraf\t%v.?,%v.?,31" 4 } } */
+/* { dg-final { scan-assembler-times "vesrah\t%v.?,%v.?,15" 4 } } */
+/* { dg-final { scan-assembler-times "vesrab\t%v.?,%v.?,7" 4 } } */
 /* { dg-final { scan-assembler-not "vzero\t*" } } */
-/* { dg-final { scan-assembler-times "vesrlf\t%v.?,%v.?,31" 4 } } */
-/* { dg-final { scan-assembler-times "vesrlh\t%v.?,%v.?,15" 4 } } */
-/* { dg-final { scan-assembler-times "vesrlb\t%v.?,%v.?,7" 4 } } */
+/* { dg-final { scan-assembler-times "vesrlf\t%v.?,%v.?,31" 6 } } */
+/* { dg-final { scan-assembler-times "vesrlh\t%v.?,%v.?,15" 6 } } */
+/* { dg-final { scan-assembler-times "vesrlb\t%v.?,%v.?,7" 6 } } */

 /* Make it expand to two vector operations.  */
 #define ITER(X) (2 * (16 / sizeof (X[1])))

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
The failing autovec-long-double-signaling-*.c tests stem from the fact that
vcond_mask_mn is not implemented for V1TF which can be easily done by simply
switching to VT mode iterator and extending TOINTVEC/tointvec.

[Bug rtl-optimization/115634] New: s390 bootstrap failure since r15-1579-g792f97b44ffc5e

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

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

Bug ID: 115634
   Summary: s390 bootstrap failure since r15-1579-g792f97b44ffc5e
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

during RTL pass: final
/devel/src/gcc/rtlanal.cc: In function 'long unsigned int
nonzero_bits1(const_rtx, scalar_int_mode, const_rtx, machine_mode, long
unsigned int)':
/devel/src/gcc/rtlanal.cc:5242:1: internal compiler error: in
print_addrstyle_operand, at config/s390/s390.cc:8143
 5242 | }
  | ^
0x307b07b print_addrstyle_operand
/devel/src/gcc/config/s390/s390.cc:8143
0x307b1c5 print_shift_count_operand
/devel/src/gcc/config/s390/s390.cc:8170
0x307d0f3 print_operand(_IO_FILE*, rtx_def*, int)
/devel/src/gcc/config/s390/s390.cc:8637
0x2a1f2cf default_print_operand(_IO_FILE*, rtx_def*, int)
/devel/src/gcc/targhooks.cc:366
0x22ede79 output_operand(rtx_def*, int)
/devel/src/gcc/final.cc:3631
0x22ed847 output_asm_insn(char const*, rtx_def**)
/devel/src/gcc/final.cc:3524
0x22ebaf9 final_scan_insn_1
/devel/src/gcc/final.cc:2840
0x22ebd83 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/devel/src/gcc/final.cc:2886
0x22e9377 final_1
/devel/src/gcc/final.cc:1977
0x22ef45d rest_of_handle_final
/devel/src/gcc/final.cc:4239
0x22ef8c1 execute
/devel/src/gcc/final.cc:4317
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.

Prior late-combine we have

(insn 180 1798 182 21 (set (reg:DI 1 %r1 [orig:250 _319 ] [250])
(ashift:DI (reg:DI 1 %r1 [346])
(plus:QI (reg:QI 2 %r2 [orig:61 _2 ] [61])
(const_int -51 [0xffcd] 2148 {*ashldi3}
 (nil))

and afterwards

(insn 180 179 182 21 (set (reg:DI 1 %r1 [orig:250 _319 ] [250])
(ashift:DI (reg:DI 1 %r1 [346])
(plus:QI (reg:QI 0 %r0 [orig:61 _2 ] [61])
(const_int -51 [0xffcd] 2148 {*ashldi3}
 (nil))

The culprit is that hreg %r0 is not allowed for shift amounts where if the
address operand has a base register, then it must be a register 1 to 15.  I
guess this is coming from

trying to combine definition of r2 in:
 1798: %r2:QI=%r0:QI
into:
  180: %r1:DI=%r1:DI<<%r2:QI-0x33
successfully matched this instruction to *ashldi3:
(set (reg:DI 1 %r1 [orig:250 _319 ] [250])
(ashift:DI (reg:DI 1 %r1 [346])
(plus:QI (reg:QI 0 %r0 [orig:61 _2 ] [61])
(const_int -51 [0xffcd]
original cost = 4 + 8 (weighted: 0.241703), replacement cost = 8 (weighted:
0.161135); keeping replacement
rescanning insn with uid = 180.
updating insn 180 in-place
verify found no changes in insn with uid = 180.

[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
I gave

if (op && (!REG_P (op)
   || (reload_completed
   && HARD_REGISTER_P (op)
   && REGNO_REG_CLASS (REGNO (op)) != ADDR_REGS)))
  return false;

a quick try and bootstrap was successful.  I will do a further bootstrap with
all languages enabled and run regtest, too.

[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Sent a slightly adapted patch
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655705.html

Thanks for your quick help in fixing this.  Very much appreciated!

[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
Fixed https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/818288.html

[Bug modula2/115804] New: ICE during gimplification with new isfinite optab

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

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

Bug ID: 115804
   Summary: ICE during gimplification with new isfinite optab
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---

Adding isfinitedf2 optab to the s390 backend results in ICEs already during
gimplification when running the gm2 testsuite:

FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -O -g }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -O }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=300 (internal compiler error:
in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=300 (internal compiler error: in decompose, at
wide-int.h:1049)
FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -Os }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/constructor2.mod compilation, {additional_flags= -g }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -O
-g } timeout=300
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -O
} timeout=300
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=300
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=300
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -Os
} timeout=300
UNRESOLVED: gm2/iso/run/pass/constructor2.mod execution, {additional_flags= -g
} timeout=300
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -O -g }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -O }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=300 (internal compiler error:
in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=300 (internal compiler error: in decompose, at
wide-int.h:1049)
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -Os }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/iso/run/pass/unbounded4.mod compilation, {additional_flags= -g }
timeout=300 (internal compiler error: in decompose, at wide-int.h:1049)
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -O -g
} timeout=300
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -O }
timeout=300
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=300
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=300
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -Os }
timeout=300
UNRESOLVED: gm2/iso/run/pass/unbounded4.mod execution, {additional_flags= -g }
timeout=300
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -O -g } timeout=300 (internal compiler error: in decompose,
at wide-int.h:1049)
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -O } timeout=300 (internal compiler error: in decompose, at
wide-int.h:1049)
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -O3 -fomit-frame-pointer -finline-functions } timeout=300
(internal compiler error: in decompose, at wide-int.h:1049)
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -O3 -fomit-frame-pointer } timeout=300 (internal compiler
error: in decompose, at wide-int.h:1049)
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -Os } timeout=300 (internal compiler error: in decompose, at
wide-int.h:1049)
FAIL: gm2/switches/check-all/run/fail/realrange.mod compilation,
{additional_flags= -g } timeout=300 (internal compiler error: in decompose, at
wide-int.h:1049)
UNRESOLVED: gm2/switches/check-all/run/fail/realrange.mod execution,
{additional_flags= -O -g } timeout=300
UNRESOLVED: gm2/switches/check-all/run/fail/realrange.mod execution,
{additional_flags= -O } timeout=300
UNRESOLVED: gm2/switches/check-all/run/fail/realran

[Bug modula2/115804] ICE during gimplification with new isfinite optab

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Created attachment 58596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58596&action=edit
New optab isfinitedf2 for s390

[Bug modula2/115804] ICE during gimplification with new isfinite optab

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Breakpoint 12, gimplify_stmt (stmt_p=0x3fff76306c0, seq_p=0x3ff7f50) at
/devel/src/gcc/gimplify.cc:7590
7590  last = gimple_seq_last (*seq_p);
(gdb) call debug(*stmt_p)
{
  a = 1.0e+0;
  b = 0.0;
  if (__builtin_isfinite (a / b) == 0)
{
  m2pim_M2RTS_RealValueException ((PROC *)
"/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod", 26,
11, (PROC *) "procedure \'_M2_realrange_init\'", (PROC *) "floating point / has
caused an overflow");
}
  else
{

}
  _T28 = a / b;
  if (__builtin_isfinite (_T28) == 0)
{
  m2pim_M2RTS_AssignmentException ((PROC *)
"/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod", 26,
4, (PROC *) "program module realrange", (PROC *) "assignment will cause a range
error, as the runtime instance value of \'REAL\' does not overlap with the type
\'REAL\'");
}
  else
{

}
  c = _T28;
}

(gdb) call debug_tree (*stmt_p)
...
stmt 
side-effects
arg:0 
side-effects
arg:0 
side-effects
fn 
constant arg:0 >
arg:0 
used arg:0  arg:1 
   
/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod:26:11
start: /devel/src/gcc/testsuite/g
m2/switches/check-all/run/fail/realrange.mod:26:9 finish:
/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod:26:13>
   
/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod:26:11
start: /devel/src/gcc/testsuite/gm2/s
witches/check-all/run/fail/realrange.mod:26:9 finish:
/devel/src/gcc/testsuite/gm2/switches/check-all/run/fail/realrange.mod:26:13>
arg:1 
...

(gdb) call debug_tree((tree)0x3fff7607000)
 >
sizes-gimplified public unsigned DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:1023 alias-set 1 canonical-type
0x3fff7607000
pointer_to_this >

So the void* type is already set prior gimplify_stmt

[Bug modula2/115804] ICE during gimplification with new isfinite optab

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
I did a quick test and with

diff --git a/gcc/m2/gm2-gcc/m2builtins.cc b/gcc/m2/gm2-gcc/m2builtins.cc
index cfb4751e15a..4263a4e297f 100644
--- a/gcc/m2/gm2-gcc/m2builtins.cc
+++ b/gcc/m2/gm2-gcc/m2builtins.cc
@@ -1031,7 +1031,8 @@ DoBuiltinIsfinite (location_t location, tree value)
   tree functype = TREE_TYPE (gm2_isfinite_node);
   tree funcptr
   = build1 (ADDR_EXPR, build_pointer_type (functype), gm2_isfinite_node);
-  tree call = m2treelib_DoCall1 (location, ptr_type_node, funcptr, value);
+  tree rettype = TREE_TYPE (functype);
+  tree call = m2treelib_DoCall1 (location, rettype, funcptr, value);

   return call;
 }

it seems to work just fine.  Skimming over the code other builtins as e.g.
DoBuiltinIsnan need to be changed, too.

[Bug modula2/115823] New: Wrong expansion of isnormal optab

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

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

Bug ID: 115823
   Summary: Wrong expansion of isnormal optab
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---

Implementing isnormal optab for s390 results in

FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -O
FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -O -g
FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -O3
-fomit-frame-pointer
FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -O3
-fomit-frame-pointer -finline-functions
FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -Os
FAIL: gm2/builtins/run/pass/testisnormal.mod compilation,  -g
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -O  (link
failed)
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -O -g  (link
failed)
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -O3
-fomit-frame-pointer  (link failed)
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -O3
-fomit-frame-pointer -finline-functions  (link failed)
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -Os  (link
failed)
UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution,  -g  (link
failed)

All tests output

/usr/bin/ld: /tmp/ccFZtxN6.o: in function `test':
testisnormal.mod:(.text+0x2d4): undefined reference to `__builtin_isnormal'
collect2: error: ld returned 1 exit status

In math.h we have

#  define isnormal(x) __builtin_isnormal (x)

which means for C code in expand_builtin

  if (!optimize
  && !called_as_built_in (fndecl)
  && fcode != BUILT_IN_FORK
  && fcode != BUILT_IN_EXECL
  && fcode != BUILT_IN_EXECV
  && fcode != BUILT_IN_EXECLP
  && fcode != BUILT_IN_EXECLE
  && fcode != BUILT_IN_EXECVP
  && fcode != BUILT_IN_EXECVE
  && fcode != BUILT_IN_CLEAR_CACHE
  && !ALLOCA_FUNCTION_CODE_P (fcode)
  && fcode != BUILT_IN_FREE
  && (fcode != BUILT_IN_MEMSET
  || !(flag_inline_stringops & ILSOP_MEMSET))
  && (fcode != BUILT_IN_MEMCPY
  || !(flag_inline_stringops & ILSOP_MEMCPY))
  && (fcode != BUILT_IN_MEMMOVE
  || !(flag_inline_stringops & ILSOP_MEMMOVE))
  && (fcode != BUILT_IN_MEMCMP
  || !(flag_inline_stringops & ILSOP_MEMCMP)))
return expand_call (exp, target, ignore);

`called_as_built_in (fndecl)` is always true whereas for gm2 it evaluates to
false due to the call side being

  isnormal (1.0e+0)

However, in rtx_for_function_call the symbol reference

  funexp = XEXP (DECL_RTL (fndecl), 0);

is actually __builtin_isnormal which leads to a linker error.

Out of curiosity, the test output indicates that this error also happens e.g.
for -O3.  However, looking into the logs, those tests where never executed with
-O3.  Kinda surprised me.

[Bug rtl-optimization/115835] New: [15 regression] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

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

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

Bug ID: 115835
   Summary: [15 regression] FAIL:
gcc.target/s390/section-anchors.c since
r15-1579-g792f97b44ffc5e
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

Prior r15-1579-g792f97b44ffc5e we emitted for

int a = 1, b = 2;

void
f ()
{
  a = 1234;
  b = 5678;
}

a single load address

f:
larl%r1,.LANCHOR0
mvhi0(%r1),1234
mvhi4(%r2),5678
br  %r14

whereas afterwards we emit two

f:
larl%r1,.LANCHOR0
larl%r2,.LANCHOR0+4
mvhi0(%r1),1234
mvhi0(%r2),5678
br  %r14

This is due to late_combine1 merging larl with the move resulting in

(insn 6 2 8 2 (set (mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1
a+0 S4 A32])
(const_int 1234 [0x4d2])) "section-anchors.c":11:5 1495 {*movsi_zarch}
 (nil))
(insn 8 6 0 2 (set (mem/c:SI (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0")
[flags 0x182])
(const_int 4 [0x4]))) [1 b+0 S4 A32])
(const_int 5678 [0x162e])) "section-anchors.c":12:5 1495 {*movsi_zarch}
 (nil))

which get split by late_combine2 again

(insn 13 2 6 2 (set (reg:DI 1 %r1 [65])
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])) "section-anchors.c":11:5
1489 {*movdi_64}
 (nil))
(insn 6 13 14 2 (set (mem/c:SI (reg:DI 1 %r1 [65]) [1 a+0 S4 A32])
(const_int 1234 [0x4d2])) "section-anchors.c":11:5 1495 {*movsi_zarch}
 (nil))
(insn 14 6 8 2 (set (reg:DI 1 %r1 [67])
(const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(const_int 4 [0x4] "section-anchors.c":12:5 1489
{*movdi_64}
 (nil))
(insn 8 14 11 2 (set (mem/c:SI (reg:DI 1 %r1 [67]) [1 b+0 S4 A32])
(const_int 5678 [0x162e])) "section-anchors.c":12:5 1495 {*movsi_zarch}
 (nil))

[Bug rtl-optimization/115835] [15 regression] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Created attachment 58614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58614&action=edit
late_combine1

[Bug rtl-optimization/115835] [15 regression] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Created attachment 58615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58615&action=edit
late_combine2

[Bug rtl-optimization/115860] New: Register pairs and regrename

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

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

Bug ID: 115860
   Summary: Register pairs and regrename
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

Although bisect stops at r15-1579-g792f97b44ffc5e this does not seem to be
directly related but rather shows a latent bug.

Reduced example:

__attribute__ ((noinline))
signed long cvt_sl_ld (long double x)
{
  return x;
}

int main ()
{
  if (cvt_sl_ld (0x7fffL) != 0x7fffL)
__builtin_abort ();
  return 0;
}

Prior pass rnreg we have

(insn 91 38 36 5 (set (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(const_double:FPRX2 0.0 [0x0.0p+0]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1507 {*movfprx2_64}
 (expr_list:REG_EQUAL (const_double:FPRX2 0.0 [0x0.0p+0])
(nil)))
(insn 36 91 37 5 (set (subreg:DF (reg:FPRX2 16 %f0 [orig:76 x ] [76]) 0)
(mem/c:DF (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [7 %sfp+-32 S8 A64]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1512 {*movdf_64dfp}
 (nil))
(insn 37 36 43 5 (set (subreg:DF (reg:FPRX2 16 %f0 [orig:76 x ] [76]) 8)
(mem/c:DF (plus:DI (reg/f:DI 15 %r15)
(const_int 168 [0xa8])) [7 %sfp+-24 S8 A64]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1512 {*movdf_64dfp}
 (nil))
(insn 43 37 44 5 (parallel [
(set (reg/i:DI 2 %r2)
(fix:DI (reg:FPRX2 16 %f0 [orig:76 x ] [76])))
(unspec:DI [
(const_int 5 [0x5])
] UNSPEC_ROUND)
(clobber (reg:CC 33 %cc))
]) "float-cast-overflow-7-reduced.c":5:58 1702 {*fix_truncfprx2di2_bfp}
 (expr_list:REG_DEAD (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil

and afterwards:

(insn 91 38 36 5 (set (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(const_double:FPRX2 0.0 [0x0.0p+0]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1507 {*movfprx2_64}
 (expr_list:REG_EQUAL (const_double:FPRX2 0.0 [0x0.0p+0])
(nil)))
(insn 36 91 37 5 (set (subreg:DF (reg:FPRX2 16 %f0 [orig:76 x ] [76]) 0)
(mem/c:DF (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [7 %sfp+-32 S8 A64]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1512 {*movdf_64dfp}
 (nil))
(insn 37 36 43 5 (set (subreg:DF (reg:FPRX2 20 %f1 [orig:76 x ] [76]) 8)
(mem/c:DF (plus:DI (reg/f:DI 15 %r15)
(const_int 168 [0xa8])) [7 %sfp+-24 S8 A64]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1512 {*movdf_64dfp}
 (nil))
(insn 43 37 44 5 (parallel [
(set (reg/i:DI 2 %r2)
(fix:DI (reg:FPRX2 20 %f1 [orig:76 x ] [76])))
(unspec:DI [
(const_int 5 [0x5])
] UNSPEC_ROUND)
(clobber (reg:CC 33 %cc))
]) "float-cast-overflow-7-reduced.c":5:58 1702 {*fix_truncfprx2di2_bfp}
 (expr_list:REG_DEAD (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil

For insn 37 and 43 register f0 is renamed to f1 which is wrong, i.e., in
expressions

  (subreg:DF (reg:FPRX2 20 %f1 [orig:76 x ] [76]) 8)

and

  (fix:DI (reg:FPRX2 20 %f1 [orig:76 x ] [76]))

it should be f0 since this is a register pair.

Creating chain %f0 (12) at insn 91
Closing chain %f0 (12) at insn 36 (terminate_write, superset)
Creating chain %f0 (13) at insn 36
Closing chain %f0 (13) at insn 37 (terminate_write, superset)
Creating chain %f0 (14) at insn 37
Closing chain %f0 (14) at insn 43 (terminate_dead, superset)
...
Register %f0 in insn 37deferring rescan insn with uid = 37.
deferring rescan insn with uid = 43.
, renamed as %f1

The chain for f0 is prematurely terminated due to writes into one register of a
register pair resulting in a chain containing only insn 37 and 43 for f0.

[Bug modula2/115823] Wrong expansion of isnormal optab

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #5 from Stefan Schulze Frielinghaus  
---
I gave the patch a try and I'm still ending up with

  brasl   %r14,__builtin_isnormal@PLT

The call m2builtins_BuiltinExists ("__builtin_isnormal") returns true because
builtin_macro_match is true.  However, called_as_built_in (fndecl) is still
false.

[Bug modula2/115823] Wrong expansion of isnormal optab

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

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
I probably missed something but shouldn't FoldBuiltinFunction emit a call to
__builtin_isnormal whereas currently after gimplification we end up with:

_T50 = isnormal (1.0e+0);

[Bug plugins/112520] gcc.dg/plugin/cpython-plugin-test-PyList_Append.c -fplugin=./analyzer_cpython_plugin.so ICE (segmentation fault) with Python 3.12+

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

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
As noted by Xi struct layouts have changed in Python 3.12.  If I understand the
plugin correctly, then it should actually track those values.  In order to do
so an implementation would need to follow the new types instead of bailing out.
 Of course, an implementation would need to check at runtime, which Python
version and therefore which object layout is used.

[Bug modula2/115823] Wrong expansion of isnormal optab

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

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
Created attachment 58689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58689&action=edit
isnormal optab for s390

[Bug modula2/115823] Wrong expansion of isnormal optab

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

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

--- Comment #9 from Stefan Schulze Frielinghaus  
---
Argh I forgot to add the isnormal optab for this PR. Just attached it. With
this I get for an unoptimized run

gm2 testisnormal.mod -O0 -S -c -fdump-tree-optimized

grep brasl testisnormal.s
brasl   %r14,test@PLT
brasl   %r14,printf@PLT
brasl   %r14,printf@PLT
brasl   %r14,exit@PLT
brasl   %r14,memcpy@PLT
brasl   %r14,memcpy@PLT
brasl   %r14,printf@PLT
brasl   %r14,__builtin_isnormal@PLT
brasl   %r14,printf@PLT
brasl   %r14,assert@PLT
brasl   %r14,m2pim_M2RTS_RegisterModule@PLT
brasl   %r14,m2pim_M2RTS_RequestDependant@PLT
brasl   %r14,m2pim_M2RTS_RequestDependant@PLT
brasl   %r14,m2pim_M2RTS_RequestDependant@PLT
brasl   %r14,m2pim_M2RTS_RequestDependant@PLT

because the call side doesn't match a builtin call:

   :
  _T42_3 = isnormal (1.0e+0);
  result_4 = _T42_3;
  _T43_5 = "isnormal (1.0) = %d\n";
  _8 = printf (_T43_5, result_4);
  _T44_9 = _8;
  if (result_4 != 1)
goto ; [INV]
  else
goto ; [INV]

[Bug modula2/115823] Wrong expansion of isnormal optab

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

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

--- Comment #11 from Stefan Schulze Frielinghaus  
---
I gave the new patch a try and can confirm that it works, now.  Thanks for
taking care of this!

[Bug middle-end/116997] [13/14/15 Regression] Wrong bitfield accesses since r13-3219-g25413fdb2ac249

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

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
I gave it a try on s390 and I also end up with

MEM  [(void *)Ptr.0_1] = { 7, 6291456 };

Thanks for the very fast fix :)

[Bug target/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Calling cse_insn() for

(insn 99 98 100 12 (set (reg:SI 138)
(const_int 1 [0x1])) "t.c":9:31 1507 {*movsi_zarch}
 (nil))

results in a call to insert_regs() where we have

(gdb) call debug_rtx(x)
(reg:SI 138)
(gdb) call dump_class(classp)
Equivalence chain for (const_int 1 [0x1]): 
(const_int 1 [0x1])
(reg:SI 165)

So indeed cse2 decided that pseudo 165 holds constant 1.  I didn't spot the
point where cse2 decides this.  Any idea where to start?

[Bug target/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Created attachment 59331
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59331&action=edit
cse2 dump

[Bug tree-optimization/117119] New: [12/13/14/15 Regression] ICE in int_cst_value, at tree.cc:11115

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

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

Bug ID: 117119
   Summary: [12/13/14/15 Regression] ICE in int_cst_value, at
tree.cc:5
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

unsigned __int128 g_728;
int func_1_l_5011[8];
void func_1() {
  for (;; g_728 += 1)
func_1_l_5011[g_728] ^= func_1_l_5011[g_728 + 5];
}
void main() {}

$ gcc -march=z16 -O3 tt.c
during GIMPLE pass: pcom
tt.c: In function 'func_1':
tt.c:1:51: internal compiler error: in int_cst_value, at tree.cc:5
1 | unsigned __int128 g_728;int func_1_l_5011[8];void func_1() {for (;;
g_728 += 1)func_1_l_5011[g_728] ^= func_1_l_5011[g_728 + 5];}void main() {}
  |   ^~
0x3ea3829 internal_error(char const*, ...)
/devel/gcc-0-vanilla/src/gcc/diagnostic-global-context.cc:517
0x3e65ae5 fancy_abort(char const*, int, char const*)
/devel/gcc-0-vanilla/src/gcc/diagnostic.cc:1533
0x2af3a6d int_cst_value(tree_node const*)
/devel/gcc-0-vanilla/src/gcc/tree.cc:5
0x3ceca59 analyze_subscript_affine_affine
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:4508
0x3cee1f5 analyze_siv_subscript
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:4837
0x3cef013 analyze_overlapping_iterations
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:5067
0x3cf0acd subscript_dependence_tester_1
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:5604
0x3cf0ccd subscript_dependence_tester
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:5654
0x3cf11f9 compute_affine_dependence(data_dependence_relation*, loop*)
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:5731
0x3cf1577 compute_all_dependences(vec const&,
vec*, vec
const&, bool)
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:5798
0x3cf2f6b compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
/devel/gcc-0-vanilla/src/gcc/tree-data-ref.cc:6282
0x26df4ad pcom_worker::tree_predictive_commoning_loop(bool)
/devel/gcc-0-vanilla/src/gcc/tree-predcom.cc:3397
0x26dfb81 tree_predictive_commoning(bool)
/devel/gcc-0-vanilla/src/gcc/tree-predcom.cc:3505
0x26dfcc7 run_tree_predictive_commoning
/devel/gcc-0-vanilla/src/gcc/tree-predcom.cc:3540
0x26dfe01 execute
/devel/gcc-0-vanilla/src/gcc/tree-predcom.cc:3585
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.

In initialize_matrix_A() for case POLYNOMIAL_CHREC the right-hand side is
checked whether it fits a HWI but in the recursive call for the left-hand side
where we hit case INTEGER_CST no check is done which means we ICE afterwards.

The following fixes it for me, though, I'm not sure whether there is a better
solution for this:

diff --git a/gcc/tree-data-ref.cc b/gcc/tree-data-ref.cc
index de234c65e94..82858cca68f 100644
--- a/gcc/tree-data-ref.cc
+++ b/gcc/tree-data-ref.cc
@@ -4087,7 +4087,7 @@ initialize_matrix_A (lambda_matrix A, tree chrec,
unsigned index, int mult)
   }

 case INTEGER_CST:
-  return chrec;
+  return cst_and_fits_in_hwi (chrec) ? chrec : chrec_dont_know;

 default:
   gcc_unreachable ();

[Bug target/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
For the outcome basically only

  b = fn3(q == &l);
  *h = b;
  if (c != 1)
__builtin_abort();

matters.  The optimized tree output for that part looks good to me (using -O2
of course):

a.1_34 = a;
a.2_35 = (unsigned short) a.1_34;
_36 = 1 - a.2_35;
_37 = (short int) _36;
b = _37;
h.13_15 = h;
_16 = (int) _37;
*h.13_15 = _16;
c.14_17 = c;
if (c.14_17 != 1)
  goto ; [0.00%]
else
  goto ; [100.00%]

 [count: 0]:
__builtin_abort ();

 [local count: 14598063]:
return 0;

[Bug ada/117087] New: [15 Regression] Ada bootstrap failure in validate_size since r15-4166-g9fd38cc5d63612

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

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

Bug ID: 117087
   Summary: [15 Regression] Ada bootstrap failure in validate_size
since r15-4166-g9fd38cc5d63612
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---
Target: s390-*-*

Bootstrapping on s390 for 31 bit fails with

$ ./gcc/xgcc -B/devel/gcc-0-vanilla/build/./gcc/
-B/devel/gcc-0-vanilla/dst/s390x-ibm-linux-gnu/bin/
-B/devel/gcc-0-vanilla/dst/s390x-ibm-linux-gnu/lib/ -isystem
/devel/gcc-0-vanilla/dst/s390x-ibm-linux-gnu/include -isystem
/devel/gcc-0-vanilla/dst/s390x-ibm-linux-gnu/sys-include-c -g -O2 -m31
-fPIC -fno-lto  -W -Wall -gnatpg -nostdinc -m31  a-assert.adb -o a-assert.o

system.ads:1:01: error: size for "Access_Character" too small, minimum allowed
is 35

Bisect stops at r15-4166-g9fd38cc5d63612

With the following fix, bootstrap is restored for me.

diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index 79d60c0c221..f22dea0d2cf 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -9604,7 +9604,7 @@ validate_size (Uint uint_size, tree gnu_type, Entity_Id
gnat_object,
   /* If this is an access type or a fat pointer, the minimum size is that
given
  by the default pointer mode.  */
   if (TREE_CODE (gnu_type) == POINTER_TYPE || TYPE_IS_FAT_POINTER_P
(gnu_type))
-old_size = bitsize_int (ptr_mode);
+old_size = bitsize_int (GET_MODE_BITSIZE (ptr_mode));

   /* Issue an error either if the default size of the object isn't a constant
  or if the new size is smaller than it.  */

[Bug target/117095] New: [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

Bug ID: 117095
   Summary: [13/14/15 Regression] Wrong code since
r13-5103-g7c9f20fcfdc2d8
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

short a, b;
int c, e, main_r;
long f, g;
int *h = &c, *i;
volatile __int128 j;
char k, l;
char m(char n, char o) { return n + o; }
char p(char n, char o) { return o == 0 ? n : n / o; }
short fn3(short n) { return n - a; }
int main() {
  char *q = &l;
  int **s = &i;
  *s = &main_r;
  for (e = 0; e <= 5; e++) {
for (g = 1; g <= 5; g++) {
  k = m(9, *i);
  **s = p(f > 1, (1 && j) ^ k);
}
  }
  b = fn3(q == &l);
  *h = b;
  if (c != 1)
__builtin_abort();
}

If compiled using -march=z15 -O2 the program aborts and succeeds with -O{0,1}.

Bisection stops at r13-5103-g7c9f20fcfdc2d8 which itself is probably not the
culprit.

[Bug middle-end/116997] New: [13/14/15 Regression] Wrong bitfield accesses since r13-3219-g25413fdb2ac249

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

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

Bug ID: 116997
   Summary: [13/14/15 Regression] Wrong bitfield accesses since
r13-3219-g25413fdb2ac249
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390x-*-*

struct S0
{
  unsigned f0;
  signed f2 : 11;
  signed : 6;
} GlobS, *Ptr = &GlobS;

const struct S0 Initializer = {7, 3};

int main (void)
{
  for (unsigned i = 0; i <= 2; i++)
*Ptr = Initializer;
  if (GlobS.f2 != 3)
__builtin_abort ();
  return 0;
}

gcc -march=z13 -O2 t.c
(should fail for any arch which supports vector extensions)

During ifcvt we have

Start lowering bitfields
Lowering:
Ptr.0_1->f2 = 3;
to:
_ifc__24 = Ptr.0_1->D.2918;
_ifc__25 = BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)>;
Ptr.0_1->D.2918 = _ifc__25;
Done lowering bitfields
...
Match-and-simplified BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)> to 3
RHS BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)> simplified to 3
Setting value number of _ifc__25 to 3 (changed)
Replaced BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)> with 3 in all uses of
_ifc__25 = BIT_INSERT_EXPR <_ifc__24, 3, 0 (11 bits)>;
Value numbering stmt = Ptr.0_1->D.2918 = _ifc__25;

which in the end leads to the optimized tree output

int main ()
{
  struct S0 * Ptr.0_1;
  unsigned int _2;
  unsigned int _3;

   [local count: 268435458]:
  Ptr.0_1 = Ptr;
  MEM  [(void *)Ptr.0_1] = { 7, 3 };
  _2 = BIT_FIELD_REF ;
  _3 = _2 & 4292870144;
  if (_3 != 6291456)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 268435456]:
  return 0;

}

Since bitfields are left aligned on s390, constant 3 is wrong and should rather
be 0x60.

[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
Fixed on master,14,13,12 -> closing

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 114678 Summary: FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not 
evrp "link_error" on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678

   What|Removed |Added

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

[Bug tree-optimization/114678] FAIL: gcc.dg/tree-ssa/range-sincos.c scan-tree-dump-not evrp "link_error" on s390

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug target/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Prior cse2 we have

(jump_insn 217 78 216 10 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 165)
(const_int 1 [0x1]))
(label_ref 216)
(pc)))
(set (reg:SI 165)
(plus:SI (reg:SI 165)
(const_int -1 [0x])))
(clobber (scratch:SI))
(clobber (reg:CC 33 %cc))
]) "t.c":14:17 discrim 1 2192 {doloop_si64}
 (int_list:REG_BR_PROB 955630228 (nil))
 -> 216)
...
(insn 99 98 100 12 (set (reg:SI 138)
(const_int 1 [0x1])) "t.c":9:31 1507 {*movsi_zarch}
 (nil))
(insn 100 99 103 12 (parallel [
(set (reg:SI 137)
(minus:SI (reg:SI 138)
(subreg:SI (reg:HI 135 [ a ]) 0)))
(clobber (reg:CC 33 %cc))
]) "t.c":9:31 1904 {*subsi3}
 (expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:HI 135 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

where insn 100 computes 1-a. After cse2 insn 99 is removed and pseudo 138 is
replaced with the branch-on-count pseudo 165 from jump_insn 217:

(insn 100 98 103 12 (parallel [
(set (reg:SI 137)
(minus:SI (reg:SI 165)
(subreg:SI (reg:HI 135 [ a ]) 0)))
(clobber (reg:CC 33 %cc))
]) "t.c":9:31 1904 {*subsi3}
 (expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:HI 135 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

However, pseudo 165 is always 0 which means the result of the subtraction is
also always 0 since variable `a` is always 0.  Looks like cse2 missed that in
the parallel pseudo 165 is decreased.

[Bug target/112274] Bug due to unused expressions on s390x

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Closing as worksforme => please reopen if it still fails for you

[Bug target/112274] Bug due to unused expressions on s390x

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
I cannot reproduce the problem, i.e., I tried it on Ubuntu 22.04 natively and
also via a cross+qemu and in both cases a zero is printed while using -O2 or
-O3.  The generated assembly also looks good to me:

lhrl%r1,.LANCHOR0
chrl%r1,.LANCHOR0+2   // g_4 < g_8
lghi%r4,0
locghil %r4,1
larl%r3,.LC0
lghi%r2,1
brasl   %r14,__printf_chk@PLT

[Bug target/116799] [14/15 Regression] Miscompiled code on s390x at -O2 since r14-2675-gef28aadad6e

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
It looks like we are increasing pat once too often, i.e., the loop body

while (pat[0] == '*' && pat < pat_end - 1)
pat++;

is executed twice instead of only once. Prior loop2, IL looks good to me. If
I'm exiting early in unroll_loop_runtime_iterations() in case max_unroll is
less or equal to 1, then it also works for me TM. Of course, this has nothing
to say for a latent bug.

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
(In reply to Segher Boessenkool from comment #4)
> Heh, I thought you forgot the manual, but -mlra apparently never was
> mentioned
> in there anyway :-)

Uff you almost had me there, i.e., if it had been documented I
might/probably/maybe have missed it ;-)  Thanks for double checking!

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

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

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

Bug 113953 Summary: Finish LRA transition for s390 by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

   What|Removed |Added

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

[Bug sanitizer/117725] New: [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

Bug ID: 117725
   Summary: [15 Regression] s390 -m31 bootstrap failure in
interception.h since r15-5164-gfa321004f3f628
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
Target: s390-*-*

Issue is reported to upstream in pull request
https://github.com/llvm/llvm-project/pull/116957

FYI: for the moment I have disabled libsanitizer for the daily testresults. As
soon as this is resolved I will enable it again.

[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
I cherry picked those and found some left overs which are handled by
https://github.com/llvm/llvm-project/pull/119248

[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

--- Comment #12 from Stefan Schulze Frielinghaus  
---
Since https://github.com/llvm/llvm-project/pull/119248 is merged I created
backports of all four commits in
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672627.html

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Created attachment 60070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60070&action=edit
loop2_unroll dump

[Bug rtl-optimization/118350] New: [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

Bug ID: 118350
   Summary: [12/13/14/15 Regression] Wrong number of loop
iterations starting with r7-3839-gde0a3fa38e2ad8
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*

static volatile unsigned long x = 0;
static unsigned int y = 0;
int main (void)
{
  {
  l:
++x;
--y;
if (y)
  goto l;
  }
  if (x != 0x1ul)
__builtin_abort ();
}

On s390x compiling this e.g. via gcc -O2 -funroll-loops leads to wrong code. 
At the end of doloop2 we have:

(insn 6 2 75 2 (set (reg:SI 62 [ y_lsm.6 ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [1 y+0 S4 A32]))
1507 {*movsi_zarch}
 (nil))
(note 75 6 72 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 72 75 73 9 (parallel [
(set (reg:SI 78)
(plus:SI (reg:SI 62 [ y_lsm.6 ])
(const_int -1 [0x])))
(clobber (reg:CC 33 %cc))
]) -1
 (nil))
(insn 73 72 74 9 (parallel [
(set (reg:SI 79)
(plus:SI (reg:SI 78)
(const_int 1 [0x1])))
(clobber (reg:CC 33 %cc))
]) -1
 (nil))

That means reg 79 contains the initial value of y which is zero.  During
doloop2 we substitute the newly computed niter which is

(insn 281 184 196 37 (set (reg:SI 82)
(lshiftrt:SI (reg:SI 79)
(const_int 3 [0x3]))) -1
 (nil))

wich resulted from unroll2

desc->niter_expr =
  simplify_gen_binary (UDIV, desc->mode, old_niter,
   gen_int_mode (max_unroll + 1, desc->mode));

Since old_niter is just y which is initially zero, dividing it by the number of
loop unrollings (in this case 8) leads to wrong code, i.e., the loop is
executed 8 times more which means the final value of x is not 0x1 but
0x8.

Although bisection stops at r7-3839-gde0a3fa38e2ad8 this doesn't seem to be the
culprit to me since it is not affecting the computation of niters.

[Bug rtl-optimization/118350] [12/13/14/15 Regression] Wrong number of loop iterations starting with r7-3839-gde0a3fa38e2ad8

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

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Created attachment 60071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60071&action=edit
loop2_doloop dump

[Bug target/118835] New: [12/13/14/15 Regression] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b

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

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

Bug ID: 118835
   Summary: [12/13/14/15 Regression] ICE in s390_valid_shift_count
since r10-1731-ge2839e47894f0b
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
  Host: s390*-*-*

long
test (long x, int y)
{
  __int128 z = 0xAABF;
  z &= y;
  return x << z;
}

$ gcc t.c -O2 -S
during RTL pass: combine
t.c: In function 'test':
t.c:7:1: internal compiler error: RTL check: expected code 'const_int', have
'const_wide_int' in s390_valid_shift_count, at config/s390/s390.cc:3526

Fails while extracting the immediate

HOST_WIDE_INT val = INTVAL (imm);
if (implicit_mask > 0
&& (val & implicit_mask) != implicit_mask)
  return false;

which is in this case a const_wide_int.

I will come up with a fix.

[Bug target/118696] [15 Regression] qemu miscompilation on s390x since r15-7053

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

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
(In reply to Stefan Schulze Frielinghaus from comment #6)
> Patch LGTM and I started a bootstrap+regtest which will finish approximately
> in 4 hours.  Sorry for the hassle and thanks for fixing this so quickly!

Bootstrap and regtest finished successfully.

(In reply to Jakub Jelinek from comment #7)
> BTW, I was surprised that only MIN_EXPR/MAX_EXPR (and likely ABS_EXPR) is
> optimized, while
> __attribute__((noipa)) __int128
> bar (__int128 x, __int128 y, __int128 z, __int128 w)
> {
>   return x < y ? z : w;
> }
> is not.  That could be done with the same comparison code and just using
> different vectors for the vector select.

I agree that this somewhat similar, however, when I was experimenting with
this, during expand, I always ended up with DI mode and never made it back to
TI mode because cc-compares where missing.  Do you have a particular pattern in
mind?

[Bug rtl-optimization/117095] [13/14/15 Regression] Wrong code since r13-5103-g7c9f20fcfdc2d8

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

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
Bootstrap and regtest are successful on s390.

[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
(In reply to Matthias Klose from comment #5)
> even with the changes from comment 3, it still fails with:
> 
> In file included from
> ../../../../../src/libsanitizer/interception/interception.h:18,
>  from
> ../../../../../src/libsanitizer/interception/interception_type_test.cpp:14:
> ../../../../../src/libsanitizer/interception/interception_type_test.cpp:30:
> 61: error: static assertion failed
>30 | COMPILER_CHECK((__sanitizer::is_same<::SSIZE_T, ::ssize_t>::value));
>   |~^~
> ../../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:
> 363:44: note: in definition of macro 'COMPILER_CHECK'
>   363 | #define COMPILER_CHECK(pred) static_assert(pred, "")
>   |^~~~
> make[10]: *** [Makefile:469: interception_type_test.lo] Error 1
> make[10]: Leaving directory
> '/<>/build/s390x-linux-gnu/32/libsanitizer/interception'
> make[9]: *** [Makefile:533: all-recursive] Error 1

Hmm strange. Cherry picking those 3 commits plus the pull request from comment
3 works for me. Can you share your setup?

[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

--- Comment #10 from Stefan Schulze Frielinghaus  
---
Created attachment 59924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59924&action=edit
all patches so far

[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002

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

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Thanks for clarification.  I'm way to unfamiliar with the vectorizer.  At some
point, when I was skimming over the code, I got the impression that also other
modes than those defined by the backend may appear in intermediate expressions.

Anyhow, bootstrap and regtest are running.

[Bug rtl-optimization/115835] [15 regression] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Yeah you are right, I somehow missed that. Will take care of it.

[Bug target/118696] [15 Regression] qemu miscompilation on s390x since r15-7053

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

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Patch LGTM and I started a bootstrap+regtest which will finish approximately in
4 hours.  Sorry for the hassle and thanks for fixing this so quickly!

I think what is missing is to adapt the existing tests:

diff --git a/gcc/testsuite/gcc.target/s390/vector/vec-abs-emu.c
b/gcc/testsuite/gcc.target/s390/vector/vec-abs-emu.c
index 8c1038a13d7..e0dd222e62c 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vec-abs-emu.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vec-abs-emu.c
@@ -18,7 +18,7 @@ typedef __attribute__ ((vector_size (16))) signed __int128
v1ti;
 ** vchg%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vn  %v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vo  %v[0-9]+,%v[0-9]+,%v[0-9]+
-** vrepg   %v[0-9]+,%v[0-9]+,1
+** vrepg   %v[0-9]+,%v[0-9]+,0
 ** vsq %v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vsel%v[0-9]+,%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** br  %r14
diff --git a/gcc/testsuite/gcc.target/s390/vector/vec-max-emu.c
b/gcc/testsuite/gcc.target/s390/vector/vec-max-emu.c
index 1c4451b19c1..12c7e76edc1 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vec-max-emu.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vec-max-emu.c
@@ -17,7 +17,7 @@ typedef __attribute__ ((vector_size (16))) signed __int128
v1ti;
 ** vchg%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vn  %v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vo  %v[0-9]+,%v[0-9]+,%v[0-9]+
-** vrepg   %v[0-9]+,%v[0-9]+,1
+** vrepg   %v[0-9]+,%v[0-9]+,0
 ** vsel%v[0-9]+,%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** br  %r14
 */
diff --git a/gcc/testsuite/gcc.target/s390/vector/vec-min-emu.c
b/gcc/testsuite/gcc.target/s390/vector/vec-min-emu.c
index 89f4dff542d..a9bcba39e22 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vec-min-emu.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vec-min-emu.c
@@ -17,7 +17,7 @@ typedef __attribute__ ((vector_size (16))) signed __int128
v1ti;
 ** vchg%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vn  %v[0-9]+,%v[0-9]+,%v[0-9]+
 ** vo  %v[0-9]+,%v[0-9]+,%v[0-9]+
-** vrepg   %v[0-9]+,%v[0-9]+,1
+** vrepg   %v[0-9]+,%v[0-9]+,0
 ** vsel%v[0-9]+,%v[0-9]+,%v[0-9]+,%v[0-9]+
 ** br  %r14
 */

[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002

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

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Yikes, the optimization should only apply for constant vectors which are
supported by the hardware.  That means vectors up to 16 byte.  For
s390_constant_via_vgm_p() and s390_constant_via_vrepi_p() we utilize
s390_constant_via_vgm_vrepi_1() and bail out for any constant vector larger
than 16 byte.  For s390_constant_via_vgbm_p() I have been missing this. 
Something along the lines

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 918a2cd6c6d..08acb69de3e 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -2818,7 +2818,7 @@ s390_constant_via_vgbm_p (rtx op, unsigned *mask)
   unsigned tmp_mask = 0;
   int nunit, unit_size;

-  if (GET_CODE (op) == CONST_VECTOR)
+  if (GET_CODE (op) == CONST_VECTOR && GET_MODE_SIZE (GET_MODE (op)) <= 16)
 {
   if (GET_MODE_INNER (GET_MODE (op)) == TImode
  || GET_MODE_INNER (GET_MODE (op)) == TFmode)

should fix it (maybe a power-of-two check should be added, too).  I will
revisit this tomorrow.  Sorry for the hassle.

[Bug target/118362] [15 Regression] ICE in require, at machmode.h:313 since r15-2002

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

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
I wasn't sure whether also other vector modes may appear there.  If only vector
modes defined by the backend can appear there, then it should be sufficient to
check for the size only.

[Bug sanitizer/117725] [15 Regression] s390 -m31 bootstrap failure in interception.h since r15-5164-gfa321004f3f628

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #17 from Stefan Schulze Frielinghaus  
---
Fixed and enabled libsanitizer for the daily testresults:
https://gcc.gnu.org/pipermail/gcc-testresults/2025-January/834442.html

[Bug d/118248] [15 Regression] gdc ICE (segfault) building a riscv64 cross compiler on s390x-linux-gnu

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

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

--- Comment #15 from Stefan Schulze Frielinghaus  
---
So my reproducer looks like

FROM ubuntu:plucky
RUN sed -i 's/^Types: deb$/Types: deb deb-src/' \
  /etc/apt/sources.list.d/ubuntu.sources
RUN apt-get update \
  && apt-get -y upgrade \
  && DEBIAN_FRONTEND=noninteractive apt-get install -y \
gdc \
libc6-dev-riscv64-cross \
binutils-multiarch \
binutils-riscv64-linux-gnu \
git \
  && apt build-dep -y gcc \
  && apt install -y libgmp3-dev libmpfr-dev libmpc-dev flex zlib1g-dev \
  && rm -rf /var/lib/apt/lists/*
RUN git clone --depth 1 https://gcc.gnu.org/git/gcc.git
RUN mkdir /build \
  && cd /build \
  && /gcc/configure \
  --enable-languages=d \
  --prefix=/usr \
  --enable-shared \
  --without-included-gettext \
  --enable-threads=posix \
  --enable-nls \
  --with-sysroot=/ \
  --enable-clocale=gnu \
  --disable-libquadmath \
  --disable-libquadmath-support \
  --enable-default-pie \
  --with-system-zlib \
  --enable-libphobos-checking=all \
  --without-target-system-zlib \
  --disable-multilib \
  --with-arch=rv64gc \
  --with-abi=lp64d \
  --enable-checking=all \
  --build=s390x-linux-gnu \
  --host=s390x-linux-gnu \
  --target=riscv64-linux-gnu \
  --includedir=/usr/riscv64-linux-gnu/include
RUN cd /build && make -j16

Which fails when entering /build/riscv64-linux-gnu/libphobos/libdruntime and
executing

/build/./gcc/gdc -B/build/./gcc/ -B/usr/riscv64-linux-gnu/bin/
-B/usr/riscv64-linux-gnu/lib/ -isystem /usr/riscv64-linux-gnu/include -isystem
/usr/riscv64-linux-gnu/sys-include -fversion=Shared -Wall -fno-release
-ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000
-fpreview=fieldwise -fpreview=dtorfields -nostdinc -I
/gcc/libphobos/libdruntime -I . -c /gcc/libphobos/libdruntime/core/exception.d 
-fPIC -fversion=Shared -o core/.libs/exception.o

The booting GDC version is: gdc (Ubuntu 14.2.0-16ubuntu1) 14.2.0

Since the cross compiled GDC is already broken, I'm not sure how to reproduce
this without s390x involvement.

[Bug d/118248] [15 Regression] gdc ICE (segfault) building a riscv64 cross compiler on s390x-linux-gnu

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

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

--- Comment #17 from Stefan Schulze Frielinghaus  
---
Meanwhile bisect stopped at r15-508-gad22c607f3e17f

Prior that commit we have for a call riscv_block_move_straight() with length=4
that

regs = XALLOCAVEC (rtx, length / delta);

is not called with a negative size but zero, the remaining two for-loops are
jumped over and the mop-up-if kicks in.

If there is anything I can help with, just let me know.  I will happily proxy
"any" command you pass over ;-)

[Bug d/118248] [15 Regression] gdc ICE (segfault) building a riscv64 cross compiler on s390x-linux-gnu

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

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

--- Comment #12 from Stefan Schulze Frielinghaus  
---
Confirmed.

Function riscv_block_move_straight() is called to copy 4 bytes. bits equals 64
which means delta equals 8. This in turn renders

regs = XALLOCAVEC (rtx, length / delta - 1);

into an alloca() call with a negative argument which segfaults.

I guess something along the lines is required:

diff --git a/gcc/config/riscv/riscv-string.cc
b/gcc/config/riscv/riscv-string.cc
index 408eb07e87f..8d37cdea114 100644
--- a/gcc/config/riscv/riscv-string.cc
+++ b/gcc/config/riscv/riscv-string.cc
@@ -814,6 +814,8 @@ riscv_block_move_straight (rtx dest, rtx src, unsigned
HOST_WIDE_INT length,

   mode = mode_for_size (bits, MODE_INT, 0).require ();
   delta = bits / BITS_PER_UNIT;
+  if (delta > length)
+delta = length;

   /* Allocate a buffer for the temporary registers.  */
   regs = XALLOCAVEC (rtx, length / delta - 1);

[Bug target/118835] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Fixed on trunk and release branches {12,13,14}.

[Bug c/119014] Extending _Float16 constant at compile and run time differs

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Thanks for pointing this out.  I was fearing that this is valid but wasn't
sure.  Especially the difference between (_Float16) 42.42f16 and just the
constant without the cast, I didn't have on my radar.

[Bug c/119014] New: Extending _Float16 constant at compile and run time differs

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

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

Bug ID: 119014
   Summary: Extending _Float16 constant at compile and run time
differs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---

__attribute__ ((noipa)) _Float16
test (void)
{
  return 42.42f16;
}

int
main (void)
{
  _Float16 x = test ();
  if (x != 42.42f16)
__builtin_abort ();
  return 0;
}

Naively I would expect that the condition evaluates to true.  However, on
x86_64 with -mno-avx512fp16 this evaluates to false.  It seems to me that the
front end chose to statically extend 42.42f16 to a float which differs from
extending the result of test() at runtime.  Optimized tree dump:

__attribute__((noipa, noinline, noclone, no_icf))
_Float16 test ()
{
   [local count: 1073741824]:
  return 4.240625e+1;

}

int main ()
{
  _Float16 x;
  float _1;

   [local count: 1073741824]:
  x_4 = test ();
  _1 = (float) x_4;
  if (_1 != 4.24199981689453125e+1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return 0;

}

The float cast results in a call to __extendhfsf2 where the result is unequal
to 4.24199981689453125e+1.

Changing the initial example slightly by not comparing directly with a constant
but assigning it first to variable y:

__attribute__ ((noipa)) _Float16
test (void)
{
  return 42.42f16;
}

int
main (void)
{
  _Float16 x = test ();
  _Float16 y = 42.42f16;
  if (x != y)
__builtin_abort ();
  return 0;
}

gives us the expected result:

__attribute__((noipa, noinline, noclone, no_icf))
_Float16 test ()
{
   [local count: 1073741824]:
  return 4.240625e+1;

}

int main ()
{
  _Float16 x;

   [local count: 1073741824]:
  x_3 = test ();
  if (x_3 != 4.240625e+1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return 0;

}

I'm not sure whether this is "expected" and is covered by some C/IEEE-754
rules.  Maybe someone can shed some light on it?

[Bug rtl-optimization/115835] FAIL: gcc.target/s390/section-anchors.c since r15-1579-g792f97b44ffc5e

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

Summary|[15 regression] FAIL:   |FAIL:
   |gcc.target/s390/section-anc |gcc.target/s390/section-anc
   |hors.c since|hors.c since
   |r15-1579-g792f97b44ffc5e|r15-1579-g792f97b44ffc5e
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug target/119235] New: Argument pointer survives LRA with -m31 -mzarch

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

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

Bug ID: 119235
   Summary: Argument pointer survives LRA with -m31 -mzarch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: stefansf at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390-*-*

Building gcc with Ada support for -m31 -mzarch -march={zEC12,z10} fails with

Entering /gcc/build/gcc/ada/rts_32
...
/gcc/build/./gcc/xgcc -B/gcc/build/./gcc/ -B/gcc/dst/s390x-ibm-linux-gnu/bin/
-B/gcc/dst/s390x-ibm-linux-gnu/lib/ -isystem
/gcc/dst/s390x-ibm-linux-gnu/include -isystem
/gcc/dst/s390x-ibm-linux-gnu/sys-include-c -g -O2 -m31  -W -Wall -gnatpg
-nostdinc -m31  a-textio.adb -o a-textio.o
/tmp/cckRZsAA.s: Assembler messages:
/tmp/cckRZsAA.s:7015: Error: bad expression
/tmp/cckRZsAA.s:7015: Error: junk at end of line: `ap'

The file contains

lgr %r0,%ap

This all boils down to the fact that during combine we accept an insn where %ap
is accessed in a mode different than Pmode which in turn lra cannot eliminate.

Trying 12, 13 -> 14:
   12: zero_extract(r75:DI,0x20,0)=r60:SI#0
  REG_DEAD r60:SI
   13: strict_low_part(r75:DI#4)=%ap:SI
   14: [%fp:SI-0x8]=r75:DI
  REG_DEAD r75:DI
Failed to match this instruction:
(set (mem/c:DI (plus:SI (reg/f:SI 34 %fp)
(const_int -8 [0xfff8])) [0 MEM 
[(void *)&FRAME.222]+0 S8 A64])
(ior:DI (ashift:DI (subreg:DI (reg/f:SI 60 [ ada__text_io__current_in.224_1
]) 0)
(const_int 32 [0x20]))
(zero_extend:DI (reg/f:SI 32 %ap
Successfully matched this instruction:
(set (mem/c:DI (plus:SI (reg/f:SI 34 %fp)
(const_int -8 [0xfff8])) [0 MEM 
[(void *)&FRAME.222]+0 S8 A64])
(ior:DI (and:DI (reg:DI 32 %ap)
(const_int 4294967295 [0x]))
(ashift:DI (subreg:DI (reg/f:SI 60 [ ada__text_io__current_in.224_1 ])
0)
(const_int 32 [0x20]
allowing combination of insns 12, 13 and 14

I don't see a reason why we should access a virtual FP/AP/RA register in modes
different than Pmode.  Thus, I will give the following patch a try:

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 29aef501fdd..3e8d7cfffd8 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -11138,8 +11138,8 @@ s390_hard_regno_mode_ok (unsigned int regno,
machine_mode mode)
}
   break;
 case ADDR_REGS:
-  if (FRAME_REGNO_P (regno) && mode == Pmode)
-   return true;
+  if (FRAME_REGNO_P (regno))
+   return mode == Pmode;

   /* fallthrough */
 case GENERAL_REGS:

[Bug tree-optimization/119293] New: [15 Regression] gcc.dg/vect/vect-121.c fails since r15-6811-g086031c0585985

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

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

Bug ID: 119293
   Summary: [15 Regression] gcc.dg/vect/vect-121.c fails since
r15-6811-g086031c0585985
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*, powerpc64le-*-*, x86_64-*-*

Created attachment 60753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60753&action=edit
dump

FAIL: gcc.dg/vect/vect-121.c scan-tree-dump-not optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-121.c -flto -ffat-lto-objects  scan-tree-dump-not
optimized "Invalid sum"

Bisect stopped at r15-6811-g086031c0585985

Tests do not only fail for s390x [1] but also for powerpc64le [2] and x86_64
[3].

[1] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840821.html
[2] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840872.html
[3] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840862.html

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

Bug 115519 Summary: s390 fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115519

   What|Removed |Added

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

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-16
 Ever confirmed|0   |1

--- Comment #13 from Stefan Schulze Frielinghaus  
---
Confirmed while using default arch z900 (doesn't manifest for me for newer
machines like z16).

I also gave Jakubs patch a try and that fixes the ICE for me.  Thanks for
spotting this so quickly!

[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x

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

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

--- Comment #20 from Stefan Schulze Frielinghaus  
---
Created attachment 61141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61141&action=edit
preprocessed

[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x

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

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

--- Comment #22 from Stefan Schulze Frielinghaus  
---
I started a bootstrap+regtest, too, for targets z900,z10,z13,z16.  Each run
will take around 5 hours.  I will report back once they finished or if some
fail on the go.

I have attached a preprocessed input which fails if gcc was build for z900
using command line:

c++ -std=c++11 -fno-exceptions -O2 -fno-rtti -fno-threadsafe-statics
-fvisibility-inlines-hidden -fPIC hb-subset.ii -c -o foo.o

In the meantime I will reduce, too.