[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890

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

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

--- Comment #10 from John David Anglin  ---
(In reply to Andrew Pinski from comment #7)
> The way most other targets represent this is just (fix:SI (reg)) without the
> inner most `fix:DF/SF`

Thanks Andrew.  Will test.

[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

--- Comment #4 from John David Anglin  ---
(In reply to Andrew Pinski from comment #1)
>   convert_optab tab = unsignedp ? ufix_optab : sfix_optab;
>   libfunc = convert_optab_libfunc (tab, GET_MODE (to), GET_MODE (from));
>   gcc_assert (libfunc);

libfunc for sfix_optab for DFmode to DFmode is not found.  I think
this happens because target was NULL in first call to force_operand
and 'to' mode is taken from 'value'.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #26 from John David Anglin  ---
(In reply to Segher Boessenkool from comment #25)
> (In reply to John David Anglin from comment #24)
> > There are a couple of issues.  The pa backend only supports memory
> > accesses that load to a register or store from a register.  LRA was
> > creating insns like the following:
> > 
> > (insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
> > (subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
> > "/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15
> > 42 {*pa.md:2195}
> >  (nil))
> 
> That is a simple 32-bit register-to-register move, which is quite expected
> here?  It should work fine if your OImode datums are stored in 8 consecutive
> GPR regs.

Yes.  Problem arises if reg/v:OI 452 is spilled to memory.  Without
reg_equiv_mem, I don't see how pa backend can handle spill.  What happens
is pa_emit_move_sequence is called repeatedly with same arguments.

While there are 31 general registers, they are split between caller saves and
callee saves. Some registers have fixed functionality.  We have three 8
register block in non pic code and two in pic code.

> > There doesn't seem to be any good reason to allow register modes that
> > aren't supported in pa.md.
> 
> Obviously.  And LRA tries to use such modes?  That can never work, no?  So
> we should do something about that?

Yes, LRA used OI and TI modes with  gcc.c-torture/compile/pr92618.c.  It
defines the following types:

typedef long long __m128i __attribute__((__may_alias__, __vector_size__(2 *
sizeof (long long;
typedef long long __m256i __attribute__((__may_alias__, __vector_size__(4 *
sizeof (long long;
typedef long long __m512i __attribute__((__may_alias__, __vector_size__(8 *
sizeof (long long;

Maybe PA has enough registers but I don't know how to handle subreg spills in
backend with LRA.

I did wonder about doing the following:

@@ -2011,6 +2027,17 @@ pa_emit_move_sequence (rtx *operands, machine_mode mode,
rtx scratch_reg)
  != XEXP (operand1, 0)))
 operand1 = replace_equiv_address (operand1, tem);

+  if (scratch_reg
+  && !(REG_P (operand0)
+  || REG_P (operand1)
+  || operand1 == CONST0_RTX (GET_MODE (operands[0]
+{
+  scratch_reg = force_mode (GET_MODE (operand0), scratch_reg);
+  emit_move_insn (scratch_reg, operand1);
+  emit_move_insn (operand0, scratch_reg);
+  return 1;
+}
+
   /* Handle secondary reloads for loads/stores of FP registers from
  REG+D addresses where D does not fit in 5 or 14 bits, including
  (subreg (mem (addr))) cases, and reloads for other unsupported

Maybe LRA could handle spills then?

> > I debated whether to allow complex 16-byte
> > modes in the general registers.  There's one test that fails if I disallow
> > 16-byte modes in the general registers.  It uses an asm to load a complex
> > long long value to a register.  It is xfailed on a number of targets
> > because they don't have enough registers.
> 
> But it's just four hardware registers for you, and you have plenty?

I tried allowing all 16-byte types in the general registers but pr92618.c still
failed with LRA.

> If your ABI doesn't require this (for parameter passing), I don't think
> there is much benefit though (and if it does require it, of course you
> have to, no choice then :-) )

Types larger than 64-bits are passed by reference in 32-bit ABI. This is not
the case in the 64-bit ABI where all types and aggregates are passed by value. 
Test doesn't fail on 64-bit.

[Bug middle-end/117525] New: canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

Bug ID: 117525
   Summary: canvas.cc:1675:1: internal compiler error: in
expand_fix, at optabs.cc:5952
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59575&action=edit
Preprocessed source.

during RTL pass: ce1
../libs/canvas/canvas.cc: In member function ‘virtual void
ArdourCanvas::GtkCanvasViewport::on_size_request(Gtk::Requisition*)’:
../libs/canvas/canvas.cc:1675:1: internal compiler error: in expand_fix, at
optabs.cc:5952
 1675 | }
  | ^
0x19c6ab3 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x228b87 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1696
0x9f5027 expand_fix(rtx_def*, rtx_def*, int)
../../gcc/gcc/optabs.cc:5952
0x717093 force_operand(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:8723
0x716dcb force_operand(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:8710
0x6e8d4f copy_to_mode_reg(machine_mode, rtx_def*)
../../gcc/gcc/explow.cc:655
0x9e6777 maybe_legitimize_operand
../../gcc/gcc/optabs.cc:8045
0x9e6777 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../gcc/gcc/optabs.cc:8188
0x9e3e37 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.cc:8207
0x9e5b87 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.cc:8262
0x9e5b87 emit_conditional_move_1
../../gcc/gcc/optabs.cc:5233
0x9e6017 emit_conditional_move(rtx_def*, rtx_comparison, rtx_def*, rtx_def*,
machine_mode, int)
../../gcc/gcc/optabs.cc:5146
0x17ffb17 noce_emit_cmove
../../gcc/gcc/ifcvt.cc:1773
0x180719f try_emit_cmove_seq
../../gcc/gcc/ifcvt.cc:3406
0x180719f noce_convert_multiple_sets_1
../../gcc/gcc/ifcvt.cc:3701
0x18076cf noce_convert_multiple_sets
../../gcc/gcc/ifcvt.cc:3492
0x180ad2f noce_process_if_block
../../gcc/gcc/ifcvt.cc:4041
0x180ad2f noce_find_if_block
../../gcc/gcc/ifcvt.cc:4722
0x180ad2f find_if_header
../../gcc/gcc/ifcvt.cc:4927
0x180ad2f if_convert
../../gcc/gcc/ifcvt.cc:6074
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.
['/home/dave/opt/gnu/gcc/gcc-15/bin/g++',
'-I/home/dave/debian/ardour/ardour-8.10.0+ds', '-g', '-O2',
'-ffile-prefix-map=/home/dave/debian/ardour/ardour-8.10.0+ds=.', '-Wformat',
'-Werror=format-security', '--param', 'ggc-min-expand=10',
'-I/usr/include/qm-dsp', '-DHAVE_RF64_RIFF', '-DWAF_BUILD', '-DNDEBUG',
'-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math',
'-fstrength-reduce', '-pipe', '-DLXVST_32BIT', '-Wall', '-Wpointer-arith',
'-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter',
'-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS',
'-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64',
'-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-std=c++11',
'-DBOOST_NO_AUTO_PTR', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS',
'-Woverloaded-virtual', '-Wno-unused-local-typedefs', '-Wno-deprecated-copy',
'-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_DEBUG',
'-DBOOST_ERROR_CODE_HEADER_ONLY', '-fPIC', '-fPIC', '-pthread', '-pthread',
'-pthread', '-Ilibs/canvas', '-I../libs/canvas', '-Ilibs/gtkmm2ext',
'-I../libs/gtkmm2ext', '-Ilibs/pbd', '-I../libs/pbd', '-Ilibs/tk/ytkmm/ytkmm',
'-I../libs/tk/ytkmm/ytkmm', '-Ilibs/tk/ydkmm/ydkmm',
'-I../libs/tk/ydkmm/ydkmm', '-Ilibs/tk/ytk/ytk', '-I../libs/tk/ytk/ytk',
'-Ilibs/tk/ydk/ydk', '-I../libs/tk/ydk/ydk', '-Ilibs/tk/ydk/ydk/gdk',
'-I../libs/tk/ydk/ydk/gdk', '-Ilibs/tk/ydk/ydk/x11',
'-I../libs/tk/ydk/ydk/x11', '-Ilibs/tk/ztkmm/ztkmm',
'-I../libs/tk/ztkmm/ztkmm', '-Ilibs/tk/ztk/ztk', '-I../libs/tk/ztk/ztk',
'-Ilibs/tk/ydk-pixbuf/ydk-pixbuf', '-I../libs/tk/ydk-pixbuf/ydk-pixbuf',
'-I/usr/include/sigc++-2.0', '-I/usr/lib/hppa-linux-gnu/sigc++-2.0/include',
'-I/usr/include/cairomm-1.0', '-I/usr/lib/hppa-linux-gnu/cairomm-1.0/include',
'-I/usr/include/cairo', '-I/usr/include/libpng16', '-I/usr/include/freetype2',
'-I/usr/include/pixman-1', '-I/usr/include/pangomm-1.4',
'-I/usr/lib/hppa-linux-gnu/pangomm-1.4/include', '-I/usr/include/glibmm-2.4',
'-I/usr/lib/hppa-linux-gnu/glibmm-2.4/include', '-I/usr/include/glib-2.0',
'-I/usr/lib/hppa-linux-gnu/glib-2.0/include', '-I/usr/include/sysprof-6',
'-I/usr/include/pango-1.0', '-I/usr/include/harfbuzz',
'-I/usr/include/libmount', '-I/usr/include/blkid', '-I/usr/include/fribidi',
'-I/usr/include/libxml2', '-I/usr/include/giomm-2.4',
'-I/

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #24 from John David Anglin  ---
There are a couple of issues.  The pa backend only supports memory
accesses that load to a register or store from a register.  LRA was
creating insns like the following:

(insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))

LRA can not handle spill for reg/v:OI 132.

The code in pa_emit_move_sequence to handle subreg spills doesn't
work with LRA.

  if (scratch_reg
  && reload_in_progress
  && GET_CODE (operand0) == REG
  && REGNO (operand0) >= FIRST_PSEUDO_REGISTER)
operand0 = reg_equiv_mem (REGNO (operand0));
  else if (scratch_reg
   && reload_in_progress
   && GET_CODE (operand0) == SUBREG
   && GET_CODE (SUBREG_REG (operand0)) == REG
   && REGNO (SUBREG_REG (operand0)) >= FIRST_PSEUDO_REGISTER)
{
 /* We must not alter SUBREG_BYTE (operand0) since that would confuse
the code which tracks sets/uses for delete_output_reload.  */
  rtx temp = gen_rtx_SUBREG (GET_MODE (operand0),
 reg_equiv_mem (REGNO (SUBREG_REG (operand0))),
 SUBREG_BYTE (operand0));
  operand0 = alter_subreg (&temp, true);
}

As far as I can tell, reg_equiv_mem always return NULL_RTX when LRA
is used.  Thus, LRA has to handle spills itself.

There doesn't seem to be any good reason to allow register modes that
aren't supported in pa.md.  I debated whether to allow complex 16-byte
modes in the general registers.  There's one test that fails if I disallow
16-byte modes in the general registers.  It uses an asm to load a complex
long long value to a register.  It is xfailed on a number of targets
because they don't have enough registers.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #22 from John David Anglin  ---
As of commit 440be01b07941506d1c8819448bd17c8717d55f5, we have the following
additional fails on hppa64-hp-hpux11.11 with LRA:

+FAIL: gcc.dg/graphite/interchange-15.c execution test
+FAIL: gcc.dg/graphite/pr29581-2.c execution test
+FAIL: gcc.dg/graphite/pr29581-3.c execution test
+FAIL: gcc.dg/graphite/pr29581-4.c execution test
+FAIL: gcc.dg/graphite/uns-interchange-15.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-14.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-3.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-6.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-14.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-15.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-6.c execution test
+FAIL: libgomp.c/loop-23.c execution test

Excluding guality tests, we have the following additional fails on
hppa-unknown-linux-gnu with LRA:

+FAIL: g++.dg/torture/pr37922.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel
-loops -ftracer -finline-functions  execution test
+FAIL: libgomp.c/doacross-6.c execution test
+FAIL: libgomp.c/loop-1.c execution test
+FAIL: libgomp.c/loop-2.c execution test
+FAIL: libgomp.c/ordered-1.c execution test
+FAIL: libgomp.c/pr29947-2.c execution test
+FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)
+UNRESOLVED: 20_util/variant/run.cc  -std=gnu++17 compilation failed to produce
executable
+FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 (test for excess errors)
+UNRESOLVED:
23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 compilation failed to produce executable
+FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess errors)
+UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++23 compilation failed
to produce executable
+FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess errors)
+UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++26 compilation failed
to produce executable

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #21 from John David Anglin  ---
(In reply to Segher Boessenkool from comment #20)
> (In reply to John David Anglin from comment #19)
> > (In reply to Segher Boessenkool from comment #17)
> > > (In reply to John David Anglin from comment #15)
> > > > While bootstrap is okay, there are some new test fails:
> > > > 
> > > > AIL: gcc.c-torture/compile/pr92618.c   -O1  (internal compiler error:
> > > > maximum number of generated reload insns per insn achieved (90))
> > > 
> > > (And all failures are like this.  Are they all caused buy the same thing,
> > > too?)
> > > 
> > > > I think the maximum number of generated reloads per insn may need 
> > > > increasing
> > > > to fix above.
> > > 
> > > No, no finite number will fix it.  The problem is that LRA sees some
> > > problematic insn for which it needs some reloading, but one of the insns
> > > it comes up with is the same exact shape as the original problematic insn,
> > > so we are in an infinite loop here.
> > 
> > There were some problems like this that I managed to fix by changing
> > pa_secondary_reload.
> 
> Almost all target problems that manifest during LRA manifest like this.  If
> you can figure out a way to make such things easier to debug for the next
> fellow sufferer, that would be super useful, people will love you!
> 
> > > The maximum used to be 30 btw, but apparently there were cases where we
> > > actually needed that many reloads.  But we never need anything close to 
> > > 90,
> > > on any target.  So far, anyway.
> > The above test generates a large number of reload insns with SUBREGs.
> > Doesn't appear to be an infinite loop.  Test only fails on 32-bit hppa.
> > That's why I thought it was caused by triggering limit.
> 
> Oh, it is *possible* increasing the limit will help, but 90 already was
> chosen as infeasibly high (and 30 before that as well, so certainly it is
> possible we need another increment, but not very likely).
> 
> > > > FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)
> > > > UNRESOLVED: 20_util/variant/run.cc  -std=gnu++17 compilation failed to
> > > > produce executable
> > > > FAIL: 
> > > > 23_containers/vector/requirements/exception/generation_prohibited.cc 
> > > > -std=gnu++17 (test for excess errors)
> > > > UNRESOLVED:
> > > > 23_containers/vector/requirements/exception/generation_prohibited.cc 
> > > > -std=gnu++17 compilation failed to produce executable
> > > > FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess
> > > > errors)
> > > > UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++23 compilation
> > > > failed to produce executable
> > > > FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess
> > > > errors)
> > > > UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++26 compilation
> > > > failed to produce executable
> > > > 
> > > > These appear caused by incorrect selection of class R1_REGS.  Not sure
> > > > why or what to do about it.
> > > 
> > > Chosen by LRA?  Chosen for new insns generated by LRA?
> > 
> > I think so based on looking at the dump for the reload pass but I'm
> > not sure.
> > 
> > I believe the insn was not generated by LRA.  LRA was unable to find
> > hard registers for a (set (MEM (REG1)) (REG2)) insn in the above test
> > failures.  This is a very common pattern.  Need to look at what happened
> > to the sets for REG1 and REG2.
> > 
> > Register r1 is somewhat special in that it is the only register that
> > can be used as the destination of addil instructions.
> 
> Maybe some constraint modifier thing is needed?  I don't know pa all that
> well, sorry :-/
> 
> > I will open bug reports when I have more information.
> 
> Thanks!  And good luck.  Debugging LRA is hard because of LRA itself, as well
> as simply hard from what it does in the first place, *and* the art of
> debugging
> it a whole separate world anyway!
> 
> So again, anything that can make it easier for the next poor sod who will
> find him/herself in the same position, is more than welcome :-)

This bug was fixed by changing PA_HARD_REGNO_MODE_OK.  On the 32-bit
target we no longer allow TI and OI mode in the hard registers.  I only
allowed complex 16 byte modes in the general registers.  It's possible
this is problematic but there isn't much testing.

I removed 32 byte modes from the 64-bit targets.

[Bug target/117238] FAIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: maximum number of generated reload insns per insn achieved (90))

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Should be fixed on both 32 and 64-bit targets.

[Bug target/117443] lo.c:1462:1: ICE: in change_address_1, at emit-rtl.cc:2299

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #4 from John David Anglin  ---
Fixed.

[Bug target/117443] lo.c:1462:1: ICE: in change_address_1, at emit-rtl.cc:2299

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

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

--- Comment #1 from John David Anglin  ---
It looks like pa_legitimate_address_p should accept any reloading pseudo.

[Bug target/117443] New: lo.c:1462:1: ICE: in change_address_1, at emit-rtl.cc:2299

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

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

Bug ID: 117443
   Summary: lo.c:1462:1: ICE: in change_address_1, at
emit-rtl.cc:2299
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

Created attachment 59537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59537&action=edit
Preproccessed source

The symmetrica-3.0.1+ds build fails on hppa-linux:
https://buildd.debian.org/status/fetch.php?pkg=symmetrica&arch=hppa&ver=3.0.1%2Bds-3%2Bb1&stamp=1730534309&raw=0

(gdb) r
Starting program:
/home/dave/opt/gnu/gcc/gcc-15/libexec/gcc/hppa-linux-gnu/15.0.0/cc1
-fpreprocessed .libs/libsymmetrica_la-lo.i -quiet -dumpdir .libs/ -dumpbase
libsymmetrica_la-lo.c -dumpbase-ext .c -g -O2 -Wdate-time -Wno-unused-result
-Werror=implicit-function-declaration -Wformat=1 -Werror=format-security
-version -ffile-prefix-map=/home/dave/debian/symmetrica/symmetrica-3.0.1+ds=.
-fPIC -o .libs/libsymmetrica_la-lo.s
Python Exception : Missing parentheses in call to 'print'.
Did you mean print(...)? (libisl.so.15.3.0-gdb.py, line 67)
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
GNU C17 (GCC) version 15.0.0 20241103 (experimental) [master
r15-4868-g7f67acf60c5] (hppa-linux-gnu)
compiled by GNU C version 15.0.0 20241103 (experimental) [master
r15-4868-g7f67acf60c5], GMP version 6.3.0, MPFR version 4.2.1, MPC version
1.3.1, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b343f61a9e9fc3ab1886ea2fcf5f434a
../../src/lo.c: In function ‘objectwrite_longint’:
../../src/lo.c:4307:15: warning: format ‘%ld’ expects argument of type ‘long
int’, but argument 3 has type ‘int’ [-Wformat=]
 4307 | fprintf(f," %ld ",LONGINT);
  |   ^~~ ~
  |   |
  |   int
../../src/lo.c: In function ‘ganzfziffer.part.0’:
../../src/lo.c:1592:40: warning: ‘__builtin___sprintf_chk’ may write a
terminating nul past the end of the destination [-Wformat-overflow=]
 1592 | sprintf(zd->ziffer,"%s%c",zd->ziffer,' ');
  |^~
In file included from /usr/include/stdio.h:970,
 from ../../src/def.h:16,
 from ../../src/lo.c:2:
In function ‘sprintf’,
inlined from ‘ganzfziffer.part.0’ at ../../src/lo.c:1592:7:
/usr/include/hppa-linux-gnu/bits/stdio2.h:30:10: note:
‘__builtin___sprintf_chk’ output between 2 and 14 bytes into a destination of
size 13
   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  |  ^~
   31 |   __glibc_objsize (__s), __fmt,
  |   ~
   32 |   __va_arg_pack ());
  |   ~~
../../src/lo.c: In function ‘ganzfziffer.part.0’:
../../src/lo.c:1585:36: warning: ‘__builtin___sprintf_chk’ may write a
terminating nul past the end of the destination [-Wformat-overflow=]
 1585 | sprintf(zd->ziffer,"%s%c", zd->ziffer,gd.folgezeichen);
  |^~
In function ‘sprintf’,
inlined from ‘ganzfziffer.part.0’ at ../../src/lo.c:1585:17:
/usr/include/hppa-linux-gnu/bits/stdio2.h:30:10: note:
‘__builtin___sprintf_chk’ output between 2 and 14 bytes into a destination of
size 13
   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  |  ^~
   31 |   __glibc_objsize (__s), __fmt,
  |   ~
   32 |   __va_arg_pack ());
  |   ~~
../../src/lo.c: In function ‘ganz1ziffer.isra’:
../../src/lo.c:1653:39: warning: ‘%c’ directive writing 1 byte into a region of
size between 0 and 12 [-Wformat-overflow=]
 1653 |   sprintf(zd->ziffer, "%s%" PRIINT "%c"
,zd->ziffer,z,gd.folgezeichen);
  |   ^
In function ‘sprintf’,
inlined from ‘ganz1ziffer.isra’ at ../../src/lo.c:1653:5:
/usr/include/hppa-linux-gnu/bits/stdio2.h:30:10: note:
‘__builtin___sprintf_chk’ output between 3 and 25 bytes into a destination of
size 13
   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
  |  ^~
   31 |   

[Bug testsuite/117428] New: pr55153.c:11:3: warning: invalid thi rd argument to '__builtin_prefetch'; using zero

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

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

Bug ID: 117428
   Summary: pr55153.c:11:3: warning: invalid thi rd argument to
'__builtin_prefetch'; using zero
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c
-fdiagnostics-pla
in-output -O -fsched2-use-superblocks -fschedule-insns2 -S -o pr55153.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c: In function 'foo':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c:11:3: warning: invalid
sec
ond argument to '__builtin_prefetch'; using zero
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c:11:3: warning: invalid
thi
rd argument to '__builtin_prefetch'; using zero
FAIL: gcc.dg/pr55153.c (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c:11:3: warning: invalid
second argument to '__builtin_prefetch'; using zero
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr55153.c:11:3: warning: invalid
third argument to '__builtin_prefetch'; using zero

Similar fails:
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 31)
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 32)
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 33)
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 34)
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 35)
FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 36)
FAIL: gcc.dg/builtin-prefetch-1.c (test for excess errors)
FAIL: gcc.dg/pr56117.c (test for excess errors)
FAIL: gcc.dg/torture/pr58079.c

[Bug middle-end/55369] expmed.c is miscompiled in stage1 bootstrap at -O1

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed.  Don't know when.

[Bug middle-end/117348] New: genmatch.cc:597:13: error: 'fmemopen' was not declared in this sco pe; did you mean 'freopen'?

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

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

Bug ID: 117348
   Summary: genmatch.cc:597:13: error: 'fmemopen' was not declared
in this sco pe; did you mean 'freopen'?
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

/home/dave/gnu/gcc/objdir64/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir64/./prev
-gcc/ -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/ -nostdinc++
-B/home/dave/
gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/home/dave/gn
u/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs 
-I/home/da
ve/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux
11.11 
-I/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/inclu
de  -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir6
4/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/
prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -c   -g -O2 -fno-checking
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno
-error=narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wcondit
ionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-ma
cros -Wno-overlength-strings -Werror  -DHAVE_CONFIG_H  -DGENERATOR_FILE -I.
-Ibu
ild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include 
-I../../gc
c/gcc/../libcpp/include  -DGENMATCH_SELFTESTS \
-o build/genmatch.o ../../gcc/gcc/genmatch.cc
../../gcc/gcc/genmatch.cc: In function 'void test_diag_vfprintf(const char*,
const char*, ...)':
../../gcc/gcc/genmatch.cc:597:13: error: 'fmemopen' was not declared in this
scope; did you mean 'freopen'?
  597 |   FILE *f = fmemopen (buf, 256, "w");
  | ^~~~
  | freopen

In autohost.h, we have:

/* Define to 1 if we found a declaration for 'fmemopen', otherwise define to
   0. */
#ifndef USED_FOR_TARGET
#define HAVE_DECL_FMEMOPEN 0
#endif

Check for fmemopen is wrong:

#if defined(GENMATCH_SELFTESTS) && defined(HAVE_DECL_FMEMOPEN)

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Seems to have been fixed between r15-3043-g64028d626a5 and
r15-3205-g9522fc8bb78.

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

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

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

Bug 99175 Summary: FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17  (test for 
errors, line )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99175

   What|Removed |Added

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

[Bug target/117248] gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception

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

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

--- Comment #4 from John David Anglin  ---
The trap doesn't occur with the following change:

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 53f5400a961..112679f8701 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -10573,6 +10573,7 @@ vectorizable_slp_permutation_1 (vec_info *vinfo,
gimple_stmt_iterator *gsi,
  unsigned vnunits = TYPE_VECTOR_SUBPARTS (vtype)
.to_constant ();
  unsigned lane = active_lane[p.first].to_constant ();
+ gcc_assert (vnunits != 0);
  unsigned vi = (lane + p.second) / vnunits;
  unsigned vl = (lane + p.second) % vnunits;
  vperm.quick_push ({{p.first, vi}, vl});

Need to find out why vnunits is mishandled prior to call to
$$divU.  It's calculated and put into $r19 in the instruction
at 0x414dae44 but the value isn't copied to $r25 for
the call.

[Bug target/117238] FAIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: maximum number of generated reload insns per insn achieved (90))

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

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

--- Comment #3 from John David Anglin  ---
Not quite.  As things currently stand, it's theoretically possible
to hold up to two OI mode values in registers.

As far as I can tell, it doesn't seem possible to handle SUBREG spills
in pa_emit_move_sequence.  There is some code to replace a SUBREG with
equivalent memory.  But with LRA, the MEM always seems to be NULL.  This
code was effectively disabled with legacy reload as pa_secondary_reload
returns NO_REGS when it is passed rclass GENERAL_REGS and a SUBREG.
Thus, it appears LRA has to handle SUBREG spills itself.

I tried revising PA_HARD_REGNO_MODE_OK so OImode isn't allowed.  This
seems to help but it looks as if I may also have to drop TImode on this 
target.

[Bug target/117248] gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception

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

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

--- Comment #3 from John David Anglin  ---
Stage1 cc1 compiles the file without problems.  So yes, it seems stage2
cc1 is miscompiled.

At commit 04b4a5e4866daa7b6f4a4a3e7ed1a23f7787841d, the fault occurs
on this statement:

Start it from the beginning? (y or n) y
Starting program: /home/dave/gnu/gcc/objdir64/gcc/cc1 -fpreprocessed
_umoddi3_di.i -quiet -dumpbase _umoddi3_di.c -dumpbase-ext .c -mlong-calls -g
-g -g -O2 -O2 -O2 -Wextra -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-version -fno-checking -frandom-seed=fixed-seed -fbuilding-libgcc
-fno-stack-protector -frandom-seed=fixed-seed -fexceptions
-fnon-call-exceptions -fvisibility=hidden -o _umoddi3_di.s
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
GNU C17 (GCC) version 15.0.0 20241019 (experimental) [remotes/origin/HEAD
r15-4493-g04b4a5e4866] (hppa64-hp-hpux11.11)
compiled by GNU C version 15.0.0 20241019 (experimental)
[remotes/origin/HEAD r15-4493-g04b4a5e4866], GMP version 6.2.1, MPFR version
4.1.1, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 233c0872571a4ebc9f36108fd2718ccf

Breakpoint 1, 0x414dae64 in vectorizable_slp_permutation_1 (
vinfo=0x80010049aa28, gsi=0x0, node=0x8001005adf00, perm=...,
children=..., dump_p=false) at ../../gcc/gcc/tree-vect-slp.cc:10576
10576 unsigned vi = (lane + p.second) / vnunits;
(gdb) c
Continuing.

Program received signal SIGFPE, Arithmetic exception.
0x425f47a8 in $$divU () at ../../gcc/gcc/tree.h:3787
3787  tree_contains_struct_check_failed (__t, __s, __f, __l, __g);
(gdb) bt
#0  0x425f47a8 in $$divU () at ../../gcc/gcc/tree.h:3787
#1  0x8001004c6320 in ?? ()
#2  0x414dae68 in vectorizable_slp_permutation_1 (
vinfo=0x80010049aa28, gsi=0x0, node=0x8001005adf00, perm=...,
children=..., dump_p=false) at ../../gcc/gcc/tree-vect-slp.cc:10576
#3  0x414f3d08 in vectorizable_slp_permutation (
vinfo=0x83ffbf913738, gsi=0x0, node=0x80010048c0f0, cost_vec=0x1)
at ../../gcc/gcc/dumpfile.h:534
#4  vect_slp_analyze_node_operations_1 (vinfo=0x83ffbf913738,
node=0x80010048c0f0, node_instance=0x8001005adf00, cost_vec=0x1)
at ../../gcc/gcc/tree-vect-slp.cc:7556
#5  vect_slp_analyze_node_operations (vinfo=0x83ffbf913738,
node=, node_instance=0x8001005adf00, visited_set=...,
visited_vec=..., cost_vec=0x1) at ../../gcc/gcc/tree-vect-slp.cc:7779
#6  0x414f3498 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf913738, node=,
node_instance=0x8001005adf00, visited_set=..., visited_vec=...,
cost_vec=0x1) at ../../gcc/gcc/tree-vect-slp.cc:7756
#7  0x414f3498 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf913738, node=,
node_instance=0x8001005adf00, visited_set=..., visited_vec=...,
cost_vec=0x1) at ../../gcc/gcc/tree-vect-slp.cc:7756
#8  0x414f59ac in vect_slp_analyze_operations (vinfo=0x2)
---Type  to continue, or q  to quit---
at ../../gcc/gcc/tree-vect-slp.cc:8174
#9  0x414fde3c in vect_slp_analyze_bb_1 (bb_vinfo=0x80010049d180,
n_stmts=, fatal=,
dataref_groups=0x83ffbfff1958) at ../../gcc/gcc/tree-vect-slp.cc:9214
#10 vect_slp_region (bbs=..., datarefs=...,
dataref_groups=0x83ffbfff1958, n_stmts=,
orig_loop=) at ../../gcc/gcc/tree-vect-slp.cc:9261
#11 vect_slp_bbs (bbs=..., orig_loop=)
at ../../gcc/gcc/tree-vect-slp.cc:9484
#12 0x4150014c in vect_slp_function (fun=0x83ffbf913738)
at ../../gcc/gcc/tree-vect-slp.cc:9606
#13 0x415073a0 in (anonymous namespace)::pass_slp_vectorize::execute (
this=, fun=0x80010049d180)
at ../../gcc/gcc/tree-vectorizer.cc:1540
#14 0x40f576cc in execute_one_pass (pass=0x80010049d180)
at ../../gcc/gcc/passes.cc:2659
#15 0x40f5840c in execute_pass_list_1 (pass=0x80010049d180)
at ../../gcc/gcc/passes.cc:2768
#16 0x40f58428 in execute_pass_list_1 (pass=0x80010049d180)
at ../../gcc/gcc/passes.cc:2769
#17 0x40f58428 in execute_pass_list_1 (pass=0x80010049d180)
at ../../gcc/gcc/passes.cc:2769
#18 0x40f584a0 in execute_pass_list (fn=,
---Type  to continue, or q  to quit---
pass=) at ../../gcc/gcc/passes.cc:2779
#19 0x40a2d8d0 in expand (this=0x80010049d180)
at ../../gcc/gcc/context.h:48
#20 cgraph_node::expand (this=0x80010049d180)
at ../../gcc/gcc/cgraphunit.cc:1798
#21 0x40a3047c in expand_all_functions ()
at ../../gcc/gcc/cgraphunit.cc:2028
#22 symbol_table::com

[Bug target/117238] FAIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: maximum number of generated reload insns per insn achieved (90))

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

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

--- Comment #1 from John David Anglin  ---
This is caused by infinite loop in LRA.

We have a problem handling OImode:

(insn 385 384 386 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 20)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 20))
"/home/dave/gnu/gcc/g
cc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42 {*pa.md:2195}
 (nil))
(insn 386 385 387 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 24)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 24))
"/home/dave/gnu/gcc/g
cc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42 {*pa.md:2195}
 (nil))
(insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))
(insn 35 387 36 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 4)
(mem:SI (plus:SI (reg/f:SI 173)
(const_int 4 [0x4])) [1  S4 A32]))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))

The insns generated by LRA aren't valid. OImode can't fit in a set of
registers on this target, so the subreg:SI operations shown above can
never be simplified to a general registers.  e has to be in memory.
The pa architecture does not support moving data directly between two
memory locations.

[Bug target/117248] New: gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception

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

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

Bug ID: 117248
   Summary: gcc/libgcc/libgcc2.h:232:25: internal compiler error:
Arithmetic exception
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

While working on changes to support LRA, the following bug was
introduced.  It only occurs when LRA is used.  It doesn't occur with
legacy reload.

It occurs building libgcc in stage 2.

/home/dave/gnu/gcc/objdir64/./gcc/xgcc -B/home/dave/gnu/gcc/objdir64/./gcc/
-B/o
pt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-15/hppa64-hp-h
pux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/include
-isyste
m /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-include   -fno-checking -O2 -g
-
O2  -O2 -g -DIN_GCC   -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./incl
ude  -frandom-seed=fixed-seed -Dpa64=1 -DELF=1 -mlong-calls  -g -DIN_LIBGCC2
-fb
uilding-libgcc -fno-stack-protector  -frandom-seed=fixed-seed -Dpa64=1 -DELF=1
-
mlong-calls  -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/.
 -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS
-D
USE_EMUTLS  -o _umoddi3_di.o -MT _umoddi3_di.o -MD -MP -MF _umoddi3_di.dep
-DLIB
GCC2_UNITS_PER_WORD=4 -DL_umoddi3 -c ../../../gcc/libgcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc/libgcc/libgcc2.c:56:
../../../gcc/libgcc/libgcc2.c: In function '__umoddi3':
../../../gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic
except
ion
  232 | #define __NDW(a,b)  __ ## a ## di ## b
  | ^~
../../../gcc/libgcc/libgcc2.h:290:25: note: in expansion of macro '__NDW'
  290 | #define __umoddi3   __NDW(umod,3)
  | ^
../../../gcc/libgcc/libgcc2.c:1286:1: note: in expansion of macro '__umoddi3'
 1286 | __umoddi3 (UDWtype u, UDWtype v)
  | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[3]: *** [../../../gcc/libgcc/config/pa/t-dimode:23: _umoddi3_di.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
'/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libgcc'
make[2]: *** [Makefile:18835: all-stage2-target-libgcc] Error 2

Program received signal SIGFPE, Arithmetic exception.
0x425cede8 in $$divU () at ../../gcc/gcc/gimple-expr.h:66
66return (type1 == type2
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   
breakpoint already hit 27704 times
ignore next 281 hits
1.1 y 0x414f4e24 in
vect_slp_function(function*) at ../../gcc/gcc/gimple-iterator.h:168
1.2 y 0x83ffbfc349a0 <$$divU>
1.3 y 0x83ffbfe3f9cc <$$divU>
(gdb) bt
#0  0x425cede8 in $$divU () at ../../gcc/gcc/gimple-expr.h:66
#1  0x8001004c1f58 in ?? ()
#2  0x414d007c in vectorizable_slp_permutation_1 (
vinfo=0x800100496ff0, gsi=0x0, node=0x8001005aa3d8, perm=...,
children=..., dump_p=false) at ../../gcc/gcc/tree-vect-slp.cc:10435
#3  0x414e8928 in vectorizable_slp_permutation (
vinfo=0x83ffbf480540, gsi=0x0, node=0x8001004886e8,
cost_vec=0x8001005aa400) at ../../gcc/gcc/dumpfile.h:534
#4  vect_slp_analyze_node_operations_1 (vinfo=0x83ffbf480540,
node=0x8001004886e8, node_instance=0x2, cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7433
#5  vect_slp_analyze_node_operations (vinfo=0x83ffbf480540,
node=, node_instance=0x2, visited_set=...,
visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7656
#6  0x414e80c8 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf480540, node=, node_instance=0x2,
visited_set=..., visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7633
#7  0x414e80c8 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf480540, node=, node_instance=0x2,
visited_set=..., visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7633
---Type  to continue, or q  to quit---
#8  0x414ea594 in vect_slp_analyze_operations (vinfo=0x0)
at ../../gcc/gcc/tree-vect-slp.cc:8051
#9  0x414f26a0 in vect_sl

[Bug target/117242] New: FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors)

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

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

Bug ID: 117242
   Summary: FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for
excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

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

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/home
/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux-gn
u/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.
libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/
home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-15
/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/sys-include
-fchecking=
1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-
length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOUR
CE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd
c++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc
++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests
uite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/variant/run.cc
-
std=gnu++17 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a
-Wl
,--gc-sections
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/files
ystem/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/experime
ntal/.libs -lm -o ./run.exe
In file included from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/vector:67,
 from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/functional:66,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/include/precompiled/st
dc++.h:53:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h: In destructor 'std::_UninitDestroyGuard<_ForwardIterator,
_Alloc>::~_Uni
nitDestroyGuard() [with _ForwardIterator = int*; _Alloc =
__gnu_cxx::throw_alloc
ator_limit]':
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: error: unable to find a register to spill
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: error: this is the insn:
(insn 95 950 96 6 (set (mem/f/c:SI (reg/f:SI 315) [152 MEM[(struct
_Rb_tree_head
er *)&_S_map + 4B]._M_header._M_right+0 S4 A32])
(reg/f:SI 316))
"/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/i
nclude/bits/stl_tree.h":208:26 42 {*pa.md:2195}
 (expr_list:REG_DEAD (reg/f:SI 316)
(expr_list:REG_DEAD (reg/f:SI 315)
(nil
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: confused by earlier errors, bailing out
compiler exited with status 1
FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)

Similar fails:
FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 (test for excess errors)
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess errors)
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess errors)

[Bug target/117238] New: FAIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: maximum number of generated reload insns per insn achieved (90))

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

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

Bug ID: 117238
   Summary: FAIL: gcc.c-torture/compile/pr92618.c   -O1  (internal
compiler error: maximum number of generated reload
insns per insn achieved (90))
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

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

gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ -fdiagnostics-plain-output -O1 -w -c -o pr92618.o
/home/dave/gnu/gcc/gc
c/gcc/testsuite/gcc.c-torture/compile/pr92618.c
during RTL pass: reload
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c: In
functio
n 'foo':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c:38:1:
inter
nal compiler error: maximum number of generated reload insns per insn achieved
(
90)
0x16bda9b internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x739a47 lra_constraints(bool)
../../gcc/gcc/lra-constraints.cc:5405
0x7247cb lra(_IO_FILE*, int)
../../gcc/gcc/lra.cc:2445
0x6d406f do_reload
../../gcc/gcc/ira.cc:5977
0x6d406f execute
../../gcc/gcc/ira.cc:6165
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.
compiler exited with status 1
FAIL: gcc.c-torture/compile/pr92618.c   -O1  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #18 from John David Anglin  ---
For test LRA, it is probably easiest to change the "Init(0)" in
the mlra option.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #19 from John David Anglin  ---
(In reply to Segher Boessenkool from comment #17)
> (In reply to John David Anglin from comment #15)
> > While bootstrap is okay, there are some new test fails:
> > 
> > AIL: gcc.c-torture/compile/pr92618.c   -O1  (internal compiler error:
> > maximum number of generated reload insns per insn achieved (90))
> 
> (And all failures are like this.  Are they all caused buy the same thing,
> too?)
> 
> > I think the maximum number of generated reloads per insn may need increasing
> > to fix above.
> 
> No, no finite number will fix it.  The problem is that LRA sees some
> problematic insn for which it needs some reloading, but one of the insns
> it comes up with is the same exact shape as the original problematic insn,
> so we are in an infinite loop here.

There were some problems like this that I managed to fix by changing
pa_secondary_reload.
> 
> The maximum used to be 30 btw, but apparently there were cases where we
> actually needed that many reloads.  But we never need anything close to 90,
> on any target.  So far, anyway.
The above test generates a large number of reload insns with SUBREGs.
Doesn't appear to be an infinite loop.  Test only fails on 32-bit hppa.
That's why I thought it was caused by triggering limit.
> 
> > FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)
> > UNRESOLVED: 20_util/variant/run.cc  -std=gnu++17 compilation failed to
> > produce executable
> > FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
> > -std=gnu++17 (test for excess errors)
> > UNRESOLVED:
> > 23_containers/vector/requirements/exception/generation_prohibited.cc 
> > -std=gnu++17 compilation failed to produce executable
> > FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess
> > errors)
> > UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++23 compilation
> > failed to produce executable
> > FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess
> > errors)
> > UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++26 compilation
> > failed to produce executable
> > 
> > These appear caused by incorrect selection of class R1_REGS.  Not sure
> > why or what to do about it.
> 
> Chosen by LRA?  Chosen for new insns generated by LRA?

I think so based on looking at the dump for the reload pass but I'm
not sure.

I believe the insn was not generated by LRA.  LRA was unable to find
hard registers for a (set (MEM (REG1)) (REG2)) insn in the above test
failures.  This is a very common pattern.  Need to look at what happened
to the sets for REG1 and REG2.

Register r1 is somewhat special in that it is the only register that
can be used as the destination of addil instructions.

I will open bug reports when I have more information.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #15 from John David Anglin  ---
While bootstrap is okay, there are some new test fails:

AIL: gcc.c-torture/compile/pr92618.c   -O1  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/compile/pr92618.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr92618.c   -O2  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/compile/pr92618.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr92618.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: maximum number of generated
reload insns per insn achieved (90))
FAIL: gcc.c-torture/compile/pr92618.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/compile/pr92618.c   -O3 -g  (internal compiler error:
maximum number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/compile/pr92618.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr92618.c   -Os  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/compile/pr92618.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr92618.c   -O1  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -O1  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -O1  compilation failed to
produce executable
FAIL: gcc.c-torture/execute/pr92618.c   -O2  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -O2  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -O2  compilation failed to
produce executable
FAIL: gcc.c-torture/execute/pr92618.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: maximum number of generated
reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr92618.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error: maximum number of generated
reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr92618.c   -O3 -g  (internal compiler error:
maximum number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -O3 -g  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -O3 -g  compilation failed to
produce executable
FAIL: gcc.c-torture/execute/pr92618.c   -Os  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))
FAIL: gcc.c-torture/execute/pr92618.c   -Os  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr92618.c   -Os  compilation failed to
produce executable

I think the maximum number of generated reloads per insn may need increasing to
fix above.

FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)
UNRESOLVED: 20_util/variant/run.cc  -std=gnu++17 compilation failed to produce
executable
FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 (test for excess errors)
UNRESOLVED:
23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 compilation failed to produce executable
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess errors)
UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++23 compilation failed
to produce executable
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess errors)
UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++26 compilation failed
to produce executable

These appear caused by incorrect selection of class R1_REGS.  Not sure
why or what to do about it.

[Bug testsuite/115545] [15 regression] missing/excess errors after r15-1394 for targets where sizeof(int)==sizeof(long)

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

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

--- Comment #8 from John David Anglin  ---
Adapted tests don't fail on hppa-unknown-linux-gnu.  sizeof(long) ==
sizeof(int)
on this target.

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

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

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

--- Comment #18 from John David Anglin  ---
As of my last build on Oct. 9, the following tests still fail:
FAIL: math/test-double-fma
FAIL: math/test-double-ldouble-fma
FAIL: math/test-float32x-float64-fma
FAIL: math/test-float32x-fma
FAIL: math/test-float64-fma
FAIL: math/test-ldouble-fma

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #12 from John David Anglin  ---
See comment #3 in glibc bug.

[Bug target/113933] Switch pa to LRA

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

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

John David Anglin  changed:

   What|Removed |Added

  Attachment #59178|0   |1
is obsolete||

--- Comment #12 from John David Anglin  ---
Created attachment 59288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59288&action=edit
Patch

LRA patch as of commit 220402bfc03cf6a6c5bff11da8497b5374dccfe0.

Need to check compatibility of changes with reload, and add "-mlra"
option.  We need to be able to fallback to reload for a period of time.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #11 from John David Anglin  ---
This commit fixes the secondary memory needed issue mentioned comment 7.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=220402bfc03cf6a6c5bff11da8497b5374dccfe0

[Bug libstdc++/116993] New: FAIL: g++.dg/tm/pr46270.C -std=gnu++17 (test for excess errors)

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

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

Bug ID: 116993
   Summary: FAIL: g++.dg/tm/pr46270.C  -std=gnu++17 (test for
excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../xg++
-
B/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++1/../../
/home/dave/gnu/gcc/gcc/gc
c/testsuite/g++.dg/tm/pr46270.C -fdiagnostics-plain-output -nostdinc++
-I/home/d
ave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.1
1 -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home
/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/i
nclude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fmessage-l
ength=0 -std=gnu++17 -fgnu-tm -S -o pr46270.s
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/bits/new_allocator.h:34,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/hppa64-hp-hpux11.11/bits/c++allocator.h:33,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/bits/allocator.h:46,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/list:65,
 from
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/tm/pr46270.C:5
:
/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:168:26: warning: new
declarati
on 'void* operator new(std::size_t, std::align_val_t)' ambiguates built-in
decla
ration 'void* operator new(long unsigned int, std::align_val_t)
transaction_safe
' [-Wbuiltin-declaration-mismatch]
/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:179:26: warning: new
declarati
on 'void* operator new [](std::size_t, std::align_val_t)' ambiguates built-in
de
claration 'void* operator new [](long unsigned int, std::align_val_t)
transactio
n_safe' [-Wbuiltin-declaration-mismatch]
FAIL: g++.dg/tm/pr46270.C  -std=gnu++17 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:168:26: warning: new
declaration 'void* operator new(std::size_t, std::align_val_t)' ambiguates
built-in declaration 'void* operator new(long unsigned int, std::align_val_t)
transaction_safe' [-Wbuiltin-declaration-mismatch]
/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++/new:179:26: warning: new
declaration 'void* operator new [](std::size_t, std::align_val_t)' ambiguates
built-in declaration 'void* operator new [](long unsigned int,
std::align_val_t) transaction_safe' [-Wbuiltin-declaration-mismatch]

Similar fail:
FAIL: g++.dg/tm/pr46270.C  -std=gnu++26 (test for excess errors)

[Bug libstdc++/116992] New: FAIL: 30_threads/semaphore/platform_try_acquire_for.cc -std=gnu++20 (test for excess errors)

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

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

Bug ID: 116992
   Summary: FAIL: 30_threads/semaphore/platform_try_acquire_for.cc
 -std=gnu++20 (test for excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/30_threads/semaphore/platform_try_acquire_for.cc -std=gnu++20
-D_GLIBCXX_USE_PO
SIX_SEMAPHORE -pthread
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libat
omic/ -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs
-latom
ic -fdiagnostics-plain-output ./libtestc++.a
-L/home/dave/gnu/gcc/objdir64/hppa6
4-hp-hpux11.11/libstdc++-v3/src/experimental/.libs -lm -o
./platform_try_acquire
_for.exe
In file included from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/s
emaphore/try_acquire_for.cc:23,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/s
emaphore/platform_try_acquire_for.cc:7:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:4
9: error: '__semaphore_impl' has not been declared
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5
3: error: '__semaphore_impl' has not been declared [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5
5: error: '__semaphore_impl' does not name a type [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7
2: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7
6: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8
0: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:
In constructor
'std::counting_semaphore<__least_max_value>::counting_semaphore(s
td::ptrdiff_t)':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:5
9: error: class 'std::counting_semaphore<__least_max_value>' does not have any
f
ield named '_M_sem' [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:
In member function 'void
std::counting_semaphore<__least_max_value>::release(std
::ptrdiff_t)':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7
3: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:
In member function 'void
std::counting_semaphore<__least_max_value>::acquire()':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:7
7: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:
In member function 'bool
std::counting_semaphore<__least_max_value>::try_acquire
()':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8
1: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:
In member function 'bool
std::counting_semaphore<__least_max_value>::try_acquire
_for(const std::chrono::duration<_Rep, _Period>&)':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/semaphore:8
6: error: '_M_sem' was not declared in this scope [-Wtemplate-body]
/home/dave/gnu/gcc/objdir64/hppa

[Bug libstdc++/116991] New: FAIL: 26_numerics/complex/ext_c++23.cc -std=gnu++23 (test for excess errors)

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

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

Bug ID: 116991
   Summary: FAIL: 26_numerics/complex/ext_c++23.cc  -std=gnu++23
(test for excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/26_numerics/complex/ext_c++23.cc -std=gnu++23 -include bits/stdc++.h
-fdiagnost
ics-plain-output ./libtestc++.a
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.1
1/libstdc++-v3/src/experimental/.libs -lm -o ./ext_c++23.exe
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/ccomplex:41,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/hppa64-hp-hpux11.11/bits/stdc++.h:127,
 from :
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:
In
 instantiation of 'std::complex<_Tp> std::__complex_acos(const complex<_Tp>&)
[w
ith _Tp = _Float32]':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:222
7:   required from 'std::complex<_Tp> std::acos(const complex<_Tp>&) [with _Tp
=
 _Float32]'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:3
9:   required from 'void test_functions(T*, std::complex<_Tp>*) [with T =
_Float
32]'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:6
2:   required from here
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:204
3: warning: ISO C++ does not allow converting to '_Float32' from 'long double'
w
ith greater conversion rank [-Wnarrowing]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:
In
 instantiation of 'std::complex<_Tp> std::__complex_acos(const complex<_Tp>&)
[w
ith _Tp = _Float64]':
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2227:
  required from 'std::complex<_Tp> std::acos(const complex<_Tp>&) [with _Tp =
_Float64]'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:39:
  required from 'void test_functions(T*, std::complex<_Tp>*) [with T =
_Float64]'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/complex/ext_c++23.cc:69:
  required from here
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043:
warning: ISO C++ does not allow converting to '_Float64' from 'long double'
with greater conversion rank [-Wnarrowing]
FAIL: 26_numerics/complex/ext_c++23.cc  -std=gnu++23 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043:
warning: ISO C++ does not allow converting to '_Float32' from 'long double'
with greater conversion rank [-Wnarrowing]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/complex:2043:
warning: ISO C++ does not allow converting to '_Float64' from 'long double'
with greater conversion rank [-Wnarrowing]

Similar fail:
FAIL: 26_numerics/complex/ext_c++23.cc  -std=gnu++26 (test for excess errors)

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #11 from John David Anglin  ---
glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=32245

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #10 from John David Anglin  ---
This commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=29f47b0929e00ef9b880e9157f156c78ff924f5b
fixes an ICE in add_stores.  The clobbers of the frame_pointer_rtx
in the nonlocal_goto and builtin_setjmp patterns don't get hard
registers with LRA.  Fixed by removing them.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #9 from John David Anglin  ---
Noticed in LRA testing - the label operand in the indirect_goto pattern
is an input, not an output.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f6539107b8804bcc3532e748f3f596c5a8b29b44

[Bug testsuite/116986] New: FAIL: gcc.dg/torture/pr115387-2.c -O0 (test for excess errors)

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

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

Bug ID: 116986
   Summary: FAIL: gcc.dg/torture/pr115387-2.c   -O0  (test for
excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: law at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

Executing on host: /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir64/gcc/  /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr115387-2.c
-fdiagnostics-plain-output-O0   -S -o pr115387-2.s(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr115387-2.c
-f
diagnostics-plain-output -O0 -S -o pr115387-2.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr115387-2.c:5:10: fatal
err
or: stdint-gcc.h: No such file or directory
compilation terminated.
compiler exited with status 1
FAIL: gcc.dg/torture/pr115387-2.c   -O0  (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr115387-2.c:5:10: fatal
err
or: stdint-gcc.h: No such file or directory
compilation terminated.

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #10 from John David Anglin  ---
The following patch also fixes the warning/error.

diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
index 449302eda3..b18a1b209d 100644
--- a/elf/dl-find_object.c
+++ b/elf/dl-find_object.c
@@ -683,8 +683,12 @@ _dl_find_object_update_1 (struct link_map **loaded, size_t
count)
 atomic_store_release (&_dlfo_loaded_mappings[!active_idx],
target_seg);
   }
 else
-  /* Start update cycle without allocation.  */
-  _dlfo_mappings_begin_update ();
+  {
+   assert (target_seg != NULL);
+
+   /* Start update cycle without allocation.  */
+   _dlfo_mappings_begin_update ();
+  }
   }

   size_t target_seg_index1 = _dlfo_update_init_seg (target_seg,

The assert never causes an abort abort in glibc build and check, so I
believe the warning/error is a false positive.

_dl_find_object_update_1 is sometimes called when target_seg is NULL,
but in that case, new_allocated is less than remaining_to_add.

[Bug libstdc++/116964] FAIL: 18_support/comparisons/algorithms/fallback.cc -std=gnu++20 (test for excess errors)

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

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

--- Comment #2 from John David Anglin  ---
This occurred at revision r15-4033-g1f619fe2592.

[Bug libstdc++/116964] New: FAIL: 18_support/comparisons/algorithms/fallback.cc -std=gnu++20 (test for excess errors)

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

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

Bug ID: 116964
   Summary: FAIL: 18_support/comparisons/algorithms/fallback.cc
-std=gnu++20 (test for excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/18_support/comparisons/algorithms/fallback.cc -std=gnu++20 -include
bits/stdc++
.h -fdiagnostics-plain-output -S -o fallback.s
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-
v3/include/hppa64-hp-hpux11.11/bits/stdc++.h:193,
 from :
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x: In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x:335: warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wd
eprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x:335: note: add explicit 'this' or '*this' capture
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x: In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x:338: warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wd
eprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x:338: note: add explicit 'this' or '*this' capture
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x: In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mute
x:370: warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:370:
note: add explicit 'this' or '*this' capture
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:
In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:693:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:693:
note: add explicit 'this' or '*this' capture
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:
In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:699:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:699:
note: add explicit 'this' or '*this' capture
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:
In lambda function:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:719:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:719:
note: add explicit 'this' or '*this' capture
FAIL: 18_support/comparisons/algorithms/fallback.cc  -std=gnu++20 (test for
excess errors)
Excess errors:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:335:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:338:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/shared_mutex:370:
warning: implicit capture of 'this' via '[=]' is deprecated in C++20
[-Wdeprecated]
/home/dave/gnu/gcc/objdi

[Bug libstdc++/116963] New: FAIL: 17_intro/headers/c++2011/parallel_mode.cc (test for excess errors)

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

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

Bug ID: 116963
   Summary: FAIL: 17_intro/headers/c++2011/parallel_mode.cc
(test for excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-include -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -O2 -g
-DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2011/parallel_mode.cc
-std=gnu++11 -fdiagnostics-plain-output -S -o parallel_mode.s
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/parallel/algobase.h:40,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_algobase.h:2324,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/algorithm:62,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11/bits/stdc++.h:51,
 from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11/bits/extc++.h:32,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2011/parallel_mode.cc:24:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/parallel/base.h:157:
warning: 'template struct
std::binary_function' is deprecated [-Wdeprecated-declarations]
In file included from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/parallel/base.h:36:
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_function.h:131:
note: declared here
FAIL: 17_intro/headers/c++2011/parallel_mode.cc   (test for excess errors)
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/parallel/base.h:157:
warning: 'template struct
std::binary_function' is deprecated [-Wdeprecated-declarations]

There are lots of similar errors.

[Bug ada/52280] FAIL: c974013 -- C974013 Abortable part did not execute

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Target removed.

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #9 from John David Anglin  ---
This change suppresses warning:

diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
index 449302eda3..a2ba667dd4 100644
--- a/elf/dl-find_object.c
+++ b/elf/dl-find_object.c
@@ -662,6 +662,9 @@ _dl_find_object_update_1 (struct link_map **loaded, size_t
count)
 = _dlfo_loaded_mappings[!active_idx];
   size_t remaining_to_add = current_used + count;

+  if (target_seg == NULL)
+return false;
+
   /* Ensure that the new segment chain has enough space.  */
   {
 size_t new_allocated

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #8 from John David Anglin  ---
Looks like there is a typo in the indirect_goto constraints and that
causes the insn which loads "lab" to be deleted.

[Bug target/113933] Switch pa to LRA

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

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

John David Anglin  changed:

   What|Removed |Added

  Attachment #59163|0   |1
is obsolete||

--- Comment #7 from John David Anglin  ---
Created attachment 59178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59178&action=edit
Patch

This patch gets us to bootstrap on hppa-unknown-linux-gnu and
hppa64-hp-hpux11.11.

For the most part, I fixed the LRA crashes by adjusting pa_secondary_reload
to prevent pa_emit_move_sequence from being called in situations where it
just emitted an unmodified set.  Without reg_equiv_mem, the operands were
not being adjusted and the reload failed.

I was not able to get SECONDARY_MEMORY_NEEDED to work properly on hppa64
target with lra.  It never did copy via memory between general and
floating-point registers.  We ended up with an unrecognized insn if I allowed
reloading
pseudos during LRA.  If I didn't allow them, we got a secondary reload
overflow.  So, I modified 64-bit SImode, SFmode, DImode and DFmode to do
copy using the SP-40 slot in the frame marker.

We have a bunch of regressions.  For example,
FAIL: gcc.dg/enum-alias-3.c (test for excess errors)
FAIL: gcc.dg/non-local-goto-1.c execution test
FAIL: gcc.dg/non-local-goto-2.c execution test
FAIL: gcc.dg/pr49994-1.c (internal compiler error: in add_stores, at
var-tracking.cc:5966)
FAIL: gcc.dg/pr49994-1.c (test for excess errors)

Don't know if the changes to pa_secondary_reload will work with legacy reload.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #6 from John David Anglin  ---
lra crashes on this insn:

(insn 524 38 523 5 (set (reg:DI 106 [ _16 ])
(reg:DI 321 [orig:106 _16 ] [106]))
"../../../gcc/libgcc/libgcc2.c":276:4 81 {*pa.md:4260}
 (nil))

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #5 from John David Anglin  ---
Created attachment 59164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59164&action=edit
Preproccessed source

We have lra crash with this source.

/home/dave/gnu/gcc/objdir/./gcc/cc1 -fpreprocessed _mulvdi3.i -quiet -dumpbase
_mulvdi3.c -dumpbase-ext .c -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wformat=0 -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -version -fno-checking -fbuilding-libgcc
-fno-stack-protector -fPIC -fvisibility=hidden -o _mulvdi3.s

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #4 from John David Anglin  ---
Created attachment 59163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59163&action=edit
Initial patch to enable lra

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #3 from John David Anglin  ---
This code in pa_emit_move_sequence is reload specific (reg_equiv_mem):

  if (scratch_reg
  && reload_in_progress
  && GET_CODE (operand0) == REG
  && REGNO (operand0) >= FIRST_PSEUDO_REGISTER)
operand0 = reg_equiv_mem (REGNO (operand0));
  else if (scratch_reg
   && reload_in_progress
   && GET_CODE (operand0) == SUBREG
   && GET_CODE (SUBREG_REG (operand0)) == REG
   && REGNO (SUBREG_REG (operand0)) >= FIRST_PSEUDO_REGISTER)
{
 /* We must not alter SUBREG_BYTE (operand0) since that would confuse
the code which tracks sets/uses for delete_output_reload.  */
  rtx temp = gen_rtx_SUBREG (GET_MODE (operand0),
 reg_equiv_mem (REGNO (SUBREG_REG (operand0))),
 SUBREG_BYTE (operand0));
  operand0 = alter_subreg (&temp, true);
}

We need something similar for lra.  Otherwise, we hit following error:

dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libgcc$ sh xx.sh
GNU C17 (GCC) version 15.0.0 20240918 (experimental) [master
r15-3695-gcc62b2c3da1] (hppa-linux-gnu)
compiled by GNU C version 13.3.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 07d108a61db93a2471fe8e13f11689df
during RTL pass: reload
../../../gcc/libgcc/libgcc2.c: In function ‘__mulvdi3’:
../../../gcc/libgcc/libgcc2.c:376:1: internal compiler error: maximum number of
generated reload insns per insn achieved (90)
  376 | }
  | ^
0x335fd73 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x12b9e43 lra_constraints(bool)
../../gcc/gcc/lra-constraints.cc:5404
0x1291b63 lra(_IO_FILE*, int)
../../gcc/gcc/lra.cc:2445
0x11f4d43 do_reload
../../gcc/gcc/ira.cc:5976
0x11f5663 execute
../../gcc/gcc/ira.cc:6164

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

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

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

John David Anglin  changed:

   What|Removed |Added

  Attachment #57529|0   |1
is obsolete||

--- Comment #14 from John David Anglin  ---
Created attachment 59141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59141&action=edit
Patch

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

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

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

John David Anglin  changed:

   What|Removed |Added

 Target|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-linux-gnu
 CC||danglin at gcc dot gnu.org
   Host|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-linux-gnu
  Build|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-linux-gnu

--- Comment #8 from John David Anglin  ---
Same fails on hppa-linux-gnu:

cc1: error: cannot load plugin ./diagnostic_plugin_test_paths.so:
./diagnostic_p
lugin_test_paths.so: undefined symbol:
_ZNK22simple_diagnostic_path10num_eventsE
v

[Bug c++/111075] [13/14/15 Regression] ICE on g++.dg/torture/tail-padding1.C on darwin

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org
  Build|*-apple-darwin* |*-apple-darwin*
   ||hppa64-hp-hpux11.11
   Host|*-apple-darwin* |*-apple-darwin*
   ||hppa64-hp-hpux11.11
 Target|*-apple-darwin* |*-apple-darwin*
   ||hppa64-hp-hpux11.11

--- Comment #7 from John David Anglin  ---
Same on hppa64-hpux with 15.0:

Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/tail-padding1.C:6:8:
interna
l compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3032

[Bug c++/116524] New: FAIL: g++.dg/modules/permissive-error-1.C -std=c++17 (internal compiler error: Segmentation fault)

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

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

Bug ID: 116524
   Summary: FAIL: g++.dg/modules/permissive-error-1.C -std=c++17
(internal compiler error: Segmentation fault)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: nshead at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++2/../../xg++
-
B/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++2/../../
/home/dave/gnu/gcc/gcc/gc
c/testsuite/g++.dg/modules/permissive-error-1.C -fdiagnostics-plain-output
-nost
dinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hp
pa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3
/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gc
c/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/
util -fmessage-length=0 -std=c++17 -pedantic-errors -Wno-long-long -fmodules-ts
-fpermissive -S -o permissive-error-1.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C: In
fun
ction 'void f()':
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:8:5:
warning: increment of read-only variable 'n' [-Wtemplate-body]
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C: At
global scope:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:4:8:
error: not writing module 'M' due to errors in template bodies
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:8:5:
note: first error in 'template void f()' appeared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:10:1:
internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
compiler exited with status 1
FAIL: g++.dg/modules/permissive-error-1.C -std=c++17 (internal compiler error:
Segmentation fault)
PASS: g++.dg/modules/permissive-error-1.C -std=c++17  (test for errors, line 4)
PASS: g++.dg/modules/permissive-error-1.C -std=c++17  (test for warnings, line
8)
PASS: g++.dg/modules/permissive-error-1.C -std=c++17  at line 9 (test for
warnings, line 8)
FAIL: g++.dg/modules/permissive-error-1.C -std=c++17 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:10:1:
internal compiler error: Segmentation fault

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/dave/gnu/gcc/objdir64/gcc/cc1plus -fpreprocessed
permissive-error-1.ii -quiet -dumpbase permissive-error-1.C -dumpbase-ext .C
-pedantic-errors -Wno-long-long -std=c++17 -version -fdiagnostics-color=never
-fdiagnostics-urls=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-path-format=separate-events
-fdiagnostics-text-art-charset=none -fno-diagnostics-show-event-links
-fmessage-length=0 -fmodules-ts -fpermissive -o permissive-error-1.s
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
GNU C++17 (GCC) version 15.0.0 20240826 (experimental) [remotes/origin/trunk
r15-3205-g9522fc8bb78] (hppa64-hp-hpux11.11)
compiled by GNU C version 15.0.0 20240826 (experimental)
[remotes/origin/trunk r15-3205-g9522fc8bb78], GMP version 6.2.1, MPFR version
4.1.1, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: aab754e141e33017aaf168953b0e8a55
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C: In
function 'void f()':
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:8:5:
warning: increment of read-only variable 'n' [-Wtemplate-body]
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C: At
global scope:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:4:9:
error: not writing module 'M' due to errors in template bodies
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/permissive-error-1.C:8:5:
note: first error in 'template void f()' appeared here

Program received signal SIGSEGV, Segmentation fault.
elf_out::end (this=0x8001004a99d0) at ../../gcc/gcc/cp/module.cc:2254
2254  h->ident.osabi = OSABI_NONE;
(gdb) p h
$12 = (elf::header *) 0x0
(gdb) p hdr
$13 = {b

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #6 from John David Anglin  ---
This note seems bogus:

In function '_dl_find_object_update':
cc1: note: destination object is likely at address zero

bool
_dl_find_object_update (struct link_map *new_map)
{
  /* Copy the newly-loaded link maps into an array for sorting.  */
  size_t count = 0;
  for (struct link_map *l = new_map; l != NULL; l = l->l_next)
/* Skip proxy maps and already-processed maps.  */
count += l == l->l_real && !l->l_find_object_processed;
  if (count == 0)
return true;

  struct link_map **map_array = malloc (count * sizeof (*map_array));
  if (map_array == NULL)
return false;
  {
size_t i = 0;
for (struct link_map *l = new_map; l != NULL; l = l->l_next)
  if (l == l->l_real && !l->l_find_object_processed)
map_array[i++] = l;
  }

  _dl_find_object_link_map_sort (map_array, count);
  bool ok = _dl_find_object_update_1 (map_array, count);
  free (map_array);
  return ok;
}

If map_array is NULL, _dl_find_object_update returns and
_dl_find_object_update_1 isn't called.

[Bug fortran/116254] new test case gfortran.dg/class_transformational_2.f90 from r15-2739-g4cb07a38233aad fails

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #7 from John David Anglin  ---
Also fails at -O1 on hppa-linux-gnu:
STOP 12
FAIL: gfortran.dg/class_transformational_2.f90   -O1  execution test

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

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

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

--- Comment #12 from John David Anglin  ---
Adding -funsigned-char fixes test.  Posted change also fixes test.

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

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

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

--- Comment #9 from John David Anglin  ---
These two are reversed:
Breakpoint 2 at 0x105a8: file
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/fam-in-union-alone-in-struct-2.c,
line 49.
(gdb) p/x with_fam_3_v.a[0]
$13 = 0x1f
(gdb) p/x with_fam_3_v.a[7]
$14 = 0x8f

[Bug target/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #13 from John David Anglin  ---
Fixed.

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

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org
 Target|powerpc*-linux-gnu  |powerpc*-linux-gnu
   |aarch64_be-*-* mips*-*-*|aarch64_be-*-* mips*-*-*
   |sparc*-*-*  |sparc*-*-* hppa*-*-*
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #7 from John David Anglin  ---
Fails on hppa-unknown-linux-gnu at master r15-2710-gcfeb994d647:
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++17 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++98 execution
test
FAIL: c-c++-common/fam-in-union-alone-in-struct-2.c  -std=gnu++26 execution
test

[Bug target/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

John David Anglin  changed:

   What|Removed |Added

  Component|fortran |target

--- Comment #8 from John David Anglin  ---
Problem is in hppa_legitimize_address.

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed|2023-11-03 00:00:00 |2024-8-4

--- Comment #5 from John David Anglin  ---
James, maybe remove --disable-werror from your configure command?

I still see this warning.

[Bug fortran/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
This bug was exposed by the following change:

commit d2934eb6ae92471484469d8ddd039eb34ef400b1
Author: John David Anglin 
Date:   Thu Nov 16 17:42:26 2023 +

hppa: Revise REG+D address support to allow long displacements before
reload

When generating PA 2.0 code, the above change allows long immediate
displacements in integer loads and stores before reload.  This indirectly
affects the RTL expansion of bb 18 and 19 of simplified test:

   :
  _13 = S.7_34 + _96;
  _14 = IMAGPART_EXPR ;
  _15 = S.7_34 + _97;
  _16 = _14 - 5.0e-1;
  IMAGPART_EXPR  = _16;
  S.7_100 = S.7_34 + 1;
  goto ; [INV]

   :
  S.6_101 = S.6_33 + 1;
  goto ; [INV]

;; basic block 18, loop depth 2, maybe hot
;;  prev block 17, next block 19, flags: (NEW, REACHABLE, RTL, VISITED)
;;  pred:   17 (FALLTHRU)
;;  19 (DFS_BACK) dependency_58.f90:15:19
(code_label 224 203 204 18 12 (nil) [1 uses])
(note 204 224 207 18 [bb 18] NOTE_INSN_BASIC_BLOCK)
(jump_insn 207 204 208 18 (set (pc)
(if_then_else (gt (reg:SI 131 [ S.7_34 ])
(const_int 10 [0xa]))
(label_ref 227)
(pc))) "dependency_58.f90":15:19 discrim 6 30 {*pa.md:1423}
 (nil)
 -> 227)
;;  succ:   20 dependency_58.f90:15:19
;;  19 (FALLTHRU)

;; basic block 19, loop depth 2, maybe hot
;;  prev block 18, next block 20, flags: (NEW, REACHABLE, RTL, VISITED)
;;  pred:   18 (FALLTHRU)
(note 208 207 209 19 [bb 19] NOTE_INSN_BASIC_BLOCK)
(insn 209 208 210 19 (set (reg:SI 108 [ _13 ])
(plus:SI (reg:SI 131 [ S.7_34 ])
(reg:SI 141 [ _96 ]))) "dependency_58.f90":15:19 discrim 5 120
{adds
i3}
 (nil))
(insn 210 209 384 19 (set (reg:SI 220)
(ashift:SI (reg:SI 108 [ _13 ])
(const_int 3 [0x3]))) "dependency_58.f90":15:19 discrim 5 177
{*pa.m
d:6558}
 (nil))
(insn 384 210 211 19 (set (reg:SI 261)
(plus:SI (reg/f:SI 89 sfp)
(const_int 8 [0x8]))) "dependency_58.f90":15:19 discrim 5 -1
 (nil))
(insn 211 384 212 19 (set (reg/f:SI 221)
(plus:SI (reg:SI 261)
(reg:SI 220))) "dependency_58.f90":15:19 discrim 5 120 {addsi3}
 (nil))
(insn 212 211 213 19 (set (reg:SF 109 [ _14 ])
(mem:SF (plus:SI (reg/f:SI 221)
(const_int 4 [0x4])) [6 a[_13]+4 S4 A32]))
"dependency_58.f90":1
5:19 discrim 5 86 {*pa.md:4440}
 (nil))
(insn 213 212 214 19 (set (reg:SI 110 [ _15 ])
(plus:SI (reg:SI 131 [ S.7_34 ])
(reg:SI 142 [ _97 ]))) "dependency_58.f90":15:19 discrim 5 120
{adds
i3}
 (nil))
(insn 214 213 215 19 (set (reg/f:SI 224)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2])))
"dependency_58.f90":15:19 discrim 5 59 {*pa.md:2753}
 (nil))
(insn 215 214 216 19 (set (reg/f:SI 223)
(lo_sum:SI (reg/f:SI 224)
(symbol_ref/u:SI ("*.LC0") [flags 0x2]))) "dependency_58.f90":15:19
discrim 5 60 {*pa.md:2785}
 (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil)))
(insn 216 215 217 19 (set (reg:SF 222)
(mem/u/c:SF (reg/f:SI 223) [0  S4 A32])) "dependency_58.f90":15:19
discrim 5 86 {*pa.md:4440}
 (expr_list:REG_EQUAL (const_double:SF 5.0e-1 [0x0.8p+0])
(nil)))
(insn 217 216 218 19 (set (reg:SF 111 [ _16 ])
(minus:SF (reg:SF 109 [ _14 ])
(reg:SF 222))) "dependency_58.f90":15:19 discrim 5 148 {subsf3}
 (nil))
(insn 218 217 219 19 (set (reg:SI 225)
(const_int 804 [0x324])) "dependency_58.f90":15:19 discrim 5 42
{*pa.md:2195}
 (nil))
(insn 219 218 220 19 (set (reg:SI 226)
(plus:SI (reg:SI 110 [ _15 ])
(const_int 100 [0x64]))) "dependency_58.f90":15:19 discrim 5 120
{addsi3}
 (nil))
(insn 220 219 385 19 (set (reg:SI 227)
(ashift:SI (reg:SI 226)
(const_int 3 [0x3]))) "dependency_58.f90":15:19 discrim 5 177
{*pa.md:6558}
 (nil))
(insn 385 220 221 19 (set (reg:SI 262)
(plus:SI (reg/f:SI 89 sfp)
(const_int 8 [0x8]))) "dependency_58.f90":15:19 discrim 5 -1
 (nil))
(insn 221 385 222 19 (set (reg/f:SI 228)
(plus:SI (reg:SI 262)
(reg:SI 227))) "dependency_58.f90":15:19 discrim 5 120 {addsi3}
 (nil))
(insn 222 221 223 19 (set (mem:SF (reg/f:SI 228) [7 IMAGPART_EXPR +0 S4
A32])
(reg:SF 111 [ _16 ])) "dependency_58.f90":15:19 discrim 5 86
{*pa.md:4440}
 (nil))
(insn 223 222 225 19 (set (reg:SI 131 [ S.7_34 ])
(plus:SI (reg:SI 131 [ S.7_34 ])
(const_int 1 [0x1]))) "dependency_58.f90":15:19 discrim 5 120
{addsi3}
 (nil))
(jump_insn 225 223 226 19 (set (pc)
(label

[Bug fortran/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

--- Comment #5 from John David Anglin  ---
Created attachment 58788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58788&action=edit
Simplified testcase

[Bug testsuite/92550] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test on strict-align targets

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #15 from John David Anglin  ---
Fixed on trunk.

[Bug testsuite/92550] FAIL: gcc.dg/ipa/ipa-sra-8.c execution test on strict-align targets

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

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

--- Comment #13 from John David Anglin  ---
Does this issue affect you?

I didn't commit or send change to list as this mainly affects
32-bit hpux target which has been disabled.

[Bug fortran/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

--- Comment #4 from John David Anglin  ---
gcc-13 is okay:
fsub,sgl %fr23L,%fr22L,%fr22L
ldo 8(%r3),%r20
ldo 800(%r20),%r20
ldo 4(%r20),%r20
depw,z %r21,28,29,%r21
add,l %r21,%r20,%r20
fstw %fr22L,0(%r20)

[Bug fortran/113384] [14/15 Regression] FAIL: gfortran.dg/array_reference_1.f90 -O0 execution test

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

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

--- Comment #3 from John David Anglin  ---
These fails only when generating PA 2.0 code.  The fails don't occur when
generating the default PA 1.1 code.

Wrong code is generated for this line in dependency_58.f90:
b%im = a%im - 0.5

b%re is set instead of b%im.

We have the following PA 1.1 assembly code:
   0x00010ab0 : fsub,sgl fr23,fr22,fr22
   0x00010ab4 : ldo 64(r20),r20
   0x00010ab8 : depw,z r20,28,29,r20
   0x00010abc : ldo 8(r3),r21
   0x00010ac0 : add,l r21,r20,r20
   0x00010ac4 : fstw fr22,0(r20)

This is PA 1.1 code:
fsub,sgl %fr23L,%fr22L,%fr22L
ldo 8(%r3),%r20
ldo 800(%r20),%r20
ldo 4(%r20),%r20
zdep %r21,28,29,%r21
addl %r21,%r20,%r20
fstws %fr22L,0(%r20)

We miss this ldo instruction in PA 2.0:
ldo 4(%r20),%r20

It adds 4 to the address to access the imaginary part of b.

[Bug other/115958] New: varasm.cc:8546:27: error: comparison of integer expressions of different signedness

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

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

Bug ID: 115958
   Summary: varasm.cc:8546:27: error: comparison of integer
expressions of different signedness
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/g
nu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/ob
jdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c   -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -fno-PIE -I. -I.
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o varasm.o -MT varasm.o
-MMD -MP -MF ./.deps/varasm.TPo ../../gcc/gcc/varasm.cc
../../gcc/gcc/varasm.cc: In function ‘void default_elf_asm_output_ascii(FILE*,
const char*, unsigned int)’:
../../gcc/gcc/varasm.cc:8546:27: error: comparison of integer expressions of
different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare]
 8546 |   if (cnt <= (t - s + 1 + 2) / 3 * 4
  |   ^~
../../gcc/gcc/varasm.cc:8572:19: error: comparison of integer expressions of
different signedness: ‘unsigned int’ and ‘int’ [-Werror=sign-compare]
 8572 |   if (cnt > (t - s + 2) / 3 * 4 && (t - s) >= 3)
  |   ^

This is for commit 5e1d530da87a6d2aa7e719744cb278e7e54a6623.

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

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

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

--- Comment #8 from John David Anglin  ---
I think get_field_by_name needs updating to handle the struct layout
changes.  DECL_NAME(field) is null for the unnamed union and it causes
a segmentation fault when dereferenced by IDENTIFIER_POINTER.  I think
get_field_by_name needs to search inside unions and structs for the
field.  If field isn't found, TREE_NULL is returned and there are no
checks for this in the current code.

The tests will be fragile if they have to check Python version.  Test is
probably broken now on all systems using Python 3.12.

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

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

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

--- Comment #6 from John David Anglin  ---
Created attachment 58675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58675&action=edit
Patch to fix various segmentation faults caused by analyzer_cpython_plugin.c

With this change, we have the following FAILs on hppa-unknown-linux-gnu:

Running /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  at line 18 (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 28)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 36)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 39)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 41)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 42)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_Append.c
-fplugin=./analyzer_cpython_plugin.so  at line 43 (test for warnings, line 42)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c
-fplugin=./analyzer_cpython_plugin.so  at line 37 (test for warnings, line 36)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyList_New.c
-fplugin=./analyzer_cpython_plugin.so (test for excess errors)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 17)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 18)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c
-fplugin=./analyzer_cpython_plugin.so  (test for warnings, line 29)
FAIL: gcc.dg/plugin/cpython-plugin-test-PyLong_FromLong.c
-fplugin=./analyzer_cpython_plugin.so  at line 37 (test for warnings, line 36)

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

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

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

--- Comment #5 from John David Anglin  ---
Likely caused by a NULL argument passed to strcmp in get_field_by_name.

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

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
Same error occurs on hppa-unknown-linux-gnu:

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-
PyList_Append.c -fdiagnostics-plain-output
-fplugin=./analyzer_cpython_plugin.so
 -fanalyzer -I/usr/include/python3.12 -I/usr/include/python3.12 -S -o
cpython-pl
ugin-test-PyList_Append.s
*** WARNING *** there are active plugins, do not report this as a bug unless
you
 can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_ANALYZER_INIT | analyzer_cpython_plugin
during IPA pass: analyzer
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-PyList_Ap
pend.c: In function 'test_PyListAppend_6':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-PyList_Ap
pend.c:76:3: internal compiler error: Segmentation fault
0x8a3a73 crash_signal
../../gcc/gcc/toplev.cc:319
0xf77bb0ac get_field_by_name
   
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plug
in.c:75
0xf77bb0ac ana::kf_PyList_Append::impl_call_pre(ana::call_details const&) const
   
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plug
in.c:609
0xc6c57f ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*
)
../../gcc/gcc/analyzer/region-model.cc:1718
0xc6de27 ana::region_model::on_stmt_pre(gimple const*, bool*,
ana::region_model_
context*)
../../gcc/gcc/analyzer/region-model.cc:1355
0xc39f97 ana::exploded_node::on_stmt_pre(ana::exploded_graph&, gimple const*,
ana::program_state*, bool*, bool*, ana::region_model_context*)
../../gcc/gcc/analyzer/engine.cc:1593
0xc3a1f7 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*,
ana::path_context*)
../../gcc/gcc/analyzer/engine.cc:1515
0xc3c953 ana::exploded_graph::process_node(ana::exploded_node*)
../../gcc/gcc/analyzer/engine.cc:4125
0xc3d9c7 ana::exploded_graph::process_worklist()
../../gcc/gcc/analyzer/engine.cc:3516
0xc3fd6b ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:6210
0xc4104b ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:6308
0xc2fb7b execute
../../gcc/gcc/analyzer/analyzer-pass.cc:87
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.
compiler exited with status 1

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

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

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

--- Comment #16 from John David Anglin  ---
Correct.  I recently did a couple of updates to the test ulps and now
only the fma tests fail when building glibc with PA 1.1 code.  Don't
know about PA 2.0.

I noticed that some RISCV processors have problems with underflow.  I
adapted fdiv test to test glibc fma function:

dave@atlas:~$ cat fma-repro.c
#include 
#include 
#include 

int main(void) {
  if (fesetround (FE_DOWNWARD)) {
printf("ERROR: Failed to set rounding mode!\n");
return 1;
  }
  fma(-0x7.p-1024, 0x8.8p-4, -0x4p-1076);
  if(fetestexcept (FE_UNDERFLOW)) {
printf("Failure: Exception Underflow is set!\n");
  } else {
printf("Success: Exception Underflow is not set!!!\n");
  }
}

dave@atlas:~$ gcc fma-repro.c  -lm -std=c2x -o fma-repro -fno-builtin
dave@atlas:~$ ./fma-repro
Failure: Exception Underflow is set!

Option -fno-builtin is needed to ensure fma call isn't optimized away.
Test passes if it is optimized away.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #8 from John David Anglin  ---
The issue with https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ee3266b3dec4d
is that it causes emacs to reallocate malloc'd data that's not 16-byte
aligned. This doesn't happen when MALLOC_ABI_ALIGNMENT is 128 bits. There
might be a bug in mremap causing the memory exhaustion.

MALLOC_ABI_ALIGNMENT should be set to 64 when we actually need 16-byte
alignment for the pthread lock. Since we no longer need 16-byte alignment
of the pthread lock structure other than for ABI compatibility, commit
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ee3266b3dec4d should by
reverted.

Here are reverts:
Trunk:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ad2206d576603c94b0c1778c84b7f43fbf8a13b4

gcc-14:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6e1fb1f9db3b722598a7332b92f4470a7bbc9c95

Should be fixed.

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

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #9 from John David Anglin  ---
Fixed on all active branches.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #7 from John David Anglin  ---
Created attachment 58576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58576&action=edit
emacs patch to adjust lisp alignment on hppa

Full build in progress.  We will have to see if ignoring 14-byte pthread lock
alignment causes issues.

I don't think this is a gcc bug.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||helge.deller at sap dot com

--- Comment #6 from John David Anglin  ---
gdb temacs:

(gdb) p (int)MALLOC_ALIGNMENT
$2 = 8
(gdb) p (int)LISP_ALIGNMENT
$3 = 16
(gdb) p (int)MALLOC_IS_LISP_ALIGNED
$4 = 0

See src/alloc.c in emacs source.

I think LISP_ALIGNMENT is 16 because of the pthread lock alignment issue.
Since MALLOC_IS_LISP_ALIGNED is 0, we run out of memory.

Either we change the malloc alignment to 16 and put MALLOC_ABI_ALIGNMENT
back to 128, or I reinstall the lock alignment patch.  We might still run
out of memory with a malloc alignment of 16.  It not good to lie
about the malloc ABI alignment.  The lock alignment patch breaks ABI
and who know what.  It's probably best fix...

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #5 from John David Anglin  ---
I did a build with gcc-14.  It fails here:
./temacs --batch  -l loadup --temacs=pbootstrap \
--bin-dest /usr/bin/ --eln-dest /usr/lib/emacs/29.4/
Memory exhausted--use M-x save-some-buffers then exit and restart Emacs
make[4]: *** [Makefile:923: bootstrap-emacs.pdmp] Error 255

I see the following with strace running temacs:
mremap(0x623c6000, 2145378304, 2145382400, MREMAP_MAYMOVE) = 0x623c6000
mremap(0x623c6000, 2145382400, 2145386496, MREMAP_MAYMOVE) = -1 ENOMEM (Cannot
a
llocate memory)
mmap2(NULL, 2145386496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
brk(0x80544000) = 0x745000
mmap2(NULL, 2145517568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
write(2, "M", 1)= 1

There are 523740 calls to mremap starting here:

mremap(0xf9a5c000, 147456, 151552, MREMAP_MAYMOVE) = 0xf99fc000
mremap(0xf99fc000, 151552, 155648, MREMAP_MAYMOVE) = 0xf9a5a000
mremap(0xf9a5a000, 155648, 159744, MREMAP_MAYMOVE) = 0xf99fa000

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #4 from John David Anglin  ---
Debian builds are all with gcc-13 or earlier. So, it's probably
not a PA 2.0 issue.

[Bug target/115750] [14/15 regression] Emacs fails to build on HPPA since r14-4426-g0ee3266b3dec4d

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

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

--- Comment #2 from John David Anglin  ---
The bisection result is puzzling.  The linux MALLOC_ABI_ALIGNMENT define
in pa32-linux.h is replaced by the one in pa.h by the commit.  As far as
I know, the malloc alignment for hppa-linux has always been 8 bytes.  It was
never 16 bytes.  As a result, malloc'd data is insufficiently aligned for
pthreads.

I removed the define from pa32-linux.h because it didn't reflect the
actual alignment provided by malloc in glibc.

Although emacs doesn't build in Debian,
https://buildd.debian.org/status/logs.php?pkg=emacs&arch=hppa
the issue is a couple of testsuite fails.  The main difference is
Debian builds using PA 1.1 code.  The Memory exhausted error doesn't
occur there.

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

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

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

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

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

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

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

--- Comment #2 from John David Anglin  ---
The xmpy patterns using uint32_operand have been there for ever.  I think they
should be removed.

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

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

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

Bug ID: 115691
   Summary: libgomp.c-c++-common/for -2.h:101:33: internal
compiler error: in extract_insn, at recog.cc:2816
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xg++
-B/home/dave/gnu/gcc/obj
dir/gcc/
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-c
ommon/for-15.c -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/
-B/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs
-I/home/dave/gnu/gcc/objdir/hppa
-linux-gnu/./libgomp -I/home/dave/gnu/gcc/gcc/libgomp/testsuite/../../include
-I
/home/dave/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-
show-caret -fdiagnostics-color=never -fopenmp -O2 -nostdinc++
-I/home/dave/gnu/g
cc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gc
c/objdir/hppa-linux-gnu/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-
v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave
/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-B/home/dave/gnu/gcc/objdir/hppa-linux-
gnu/./libgomp/../libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-g
nu/./libgomp/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libst
dc++-v3/src/.libs -lm -o ./for-15.exe
In file included from
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../li
bgomp.c-c++-common/for-1.h:8,
 from
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../li
bgomp.c-c++-common/for-15.c:76:
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for
-2.h: In function '_Z17f6_tdpfs_static32xxiix._omp_fn.1':
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for
-2.h:101:33: error: unrecognizable insn:
(insn 32 486 481 2 (set (reg:DI 68 %fr22)
(mult:DI (zero_extend:DI (reg:SI 70 %fr23))
(reg:DI 68 %fr22))) -1
 (expr_list:REG_DEAD (reg:SI 70 %fr23)
(expr_list:REG_EQUAL (ashift:DI (zero_extend:DI (reg:SI 28 %r28 [343]))
(const_int 5 [0x5]))
(nil
during RTL pass: cprop_hardreg
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c++-common/for
-2.h:101:33: internal compiler error: in extract_insn, at recog.cc:2816
0x1845463 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:491
0x217c0f fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1725
0x215b3b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.cc:108
0x215b73 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.cc:116
0xab7087 extract_insn(rtx_insn*)
../../gcc/gcc/recog.cc:2816
0xaba947 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.cc:2715
0xabe10b copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.cc:836
0xabf40b execute
../../gcc/gcc/regcprop.cc:1423
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.
compiler exited with status 1
FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c (internal compiler error: in
extract_insn, at recog.cc:2816)
FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c (test for excess errors)

There is no hardware support for multiplying by an arbitrary 64-bit value.

There are other similar errors in libgomp testsuite.

This is at commit: e65b6627a36869b01bbe128a5324e4b415b28880.
Revision r15-1567-geb647daa87b was okay.

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

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

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

John David Anglin  changed:

   What|Removed |Added

  Attachment #58500|0   |1
is obsolete||

--- Comment #13 from John David Anglin  ---
Created attachment 58515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58515&action=edit
Really fix poll.cc on hppa-linux

hppa-linux doesn't have high resolution timer support.  Timer resolutions
range from 1 to 10ms depending on CONFIG_HZ.  The ready loop takes about
5ns per call.  As a result, we need a lot of iterations to obtain reasonable
accuracy in the ready loop.  I reduced the number of iteration in the
wait_until_sys_epoch and wait_until_steady_epoch loops to 1000 so test
would run in a reasonable time.  The results for these two loops are
currently not checked.

Here is output on 1GHz c8000 with HZ=250:
dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
wait_for(0s): 4919957362ns for 1 calls, avg 49.1996ns per call
wait_until(system_clock minimum): 22053828859ns for 1 calls, avg
220.538ns per call
wait_until(steady_clock minimum): 22277782883ns for 1 calls, avg
222.778ns per call
wait_until(system_clock epoch): 365336ns for 1000 calls, avg 3.7e+06ns
per call
wait_until(steady_clock epoch: 365335ns for 1000 calls, avg 3.7e+06ns
per call
wait_for when ready: 519995494ns for 1 calls, avg 5.19995ns per call

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

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

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

--- Comment #12 from John David Anglin  ---
Created attachment 58500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58500&action=edit
Hack to fix failure of poll.cc on hppa-unknown-linux-gnu

The number of iterations is specific to my current kernel configuration.  The
code to determine the number of iterations returned inconsistent results.

Current kernel config is 1000 Hz (to reduce test time) and stable clock.

Here is a typical run:
dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
wait_for(0s): 92ns for 19500 calls, avg 51.2816ns per call
wait_until(system_clock minimum): 369ns for 19500 calls, avg 205.127ns per
call
wait_until(steady_clock minimum): 461ns for 19500 calls, avg 256.408ns per
call
wait_until(system_clock epoch): 19499847791ns for 19500 calls, avg 92ns per
call
wait_until(steady_clock epoch: 19498848587ns for 19500 calls, avg 41ns per
call
wait_for when ready: 92ns for 19500 calls, avg 51.2816ns per call
missed 9 ticks

For some reason, I never see missed ticks in "wait_for(0s)".  But we almost
always miss ticks in "wait_for when ready" (usually 7 to 9).  I turned off
ntp but this didn't make any significant difference.  CLOCK_MONOTONIC behaves
similarly to CLOCK_REALTIME with regard to missing ticks..

dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./ntime
CLOCK_REALTIME - "Systemwide realtime clock.":
precision: 100ns
value: -112725112.1719177549
CLOCK_MONOTONIC - "Represents monotonic time. Cannot be set.":
precision: 100ns
value: -112725112.68986

Didn't need to adjust VERIFY conditions.

Test times get much longer at 250 and 100 HZ since clock tick depends on HZ.

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

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

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

--- Comment #11 from John David Anglin  ---
(In reply to John David Anglin from comment #10)
> On hppa-linux, we have:
> 
> dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
> wait_for(0s): 363ns for 81820 calls, avg 48.8874ns per call
> wait_until(system_clock minimum): 15999855ns for 81820 calls, avg 195.549ns
> per call
> wait_until(steady_clock minimum): 1817ns for 81820 calls, avg 244.437ns
> per call
> wait_until(system_clock epoch): 327345016058ns for 81820 calls, avg
> 4.00079e+06ns per call
> wait_until(steady_clock epoch: 327417023513ns for 81820 calls, avg
> 4.00167e+06ns per call
> wait_for when ready: 0ns for 81820 calls, avg 0ns per call
> /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.
> cc:129: int main(): Assertion 'wait_for_0 < (ready * 30)' failed.
> Aborted (core dumped)

HZ is 250.

[Bug libstdc++/98678] 30_threads/future/members/poll.cc execution test FAILs

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

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

--- Comment #10 from John David Anglin  ---
On hppa-linux, we have:

dave@atlas:~/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/testsuite$ ./poll.exe
wait_for(0s): 363ns for 81820 calls, avg 48.8874ns per call
wait_until(system_clock minimum): 15999855ns for 81820 calls, avg 195.549ns per
call
wait_until(steady_clock minimum): 1817ns for 81820 calls, avg 244.437ns per
call
wait_until(system_clock epoch): 327345016058ns for 81820 calls, avg
4.00079e+06ns per call
wait_until(steady_clock epoch: 327417023513ns for 81820 calls, avg
4.00167e+06ns per call
wait_for when ready: 0ns for 81820 calls, avg 0ns per call
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/30_threads/future/members/poll.cc:129:
int main(): Assertion 'wait_for_0 < (ready * 30)' failed.
Aborted (core dumped)

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

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

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

John David Anglin  changed:

   What|Removed |Added

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

[Bug target/53392] dwfl-bug-fd-leak.c:110:1: internal compiler error: in extract_insn, at recog.c:2109

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #1 from John David Anglin  ---
Compiles okay with gcc-13 and trunk.

[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning

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

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

--- Comment #5 from John David Anglin  ---
Created attachment 57800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57800&action=edit
Patch

Don't include  on hpux to avoid conflicting type declarations
for mode_t.   This fixes test on houx.

[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #18 from John David Anglin  ---
Fixed.

[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)

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

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

--- Comment #9 from John David Anglin  ---
These two fails are different and not addressed by patch:

FAIL: std/text_encoding/cons.cc  -std=gnu++26 (test for excess errors)
UNRESOLVED: std/text_encoding/cons.cc  -std=gnu++26 compilation failed to
produce executable
FAIL: std/text_encoding/requirements.cc  -std=gnu++26 (test for excess errors)

FAIL: std/text_encoding/cons.cc  -std=gnu++26 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:12:
erro
r: 'text_encoding' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:13:
erro
r: 'e0' was not declared in this scope; did you mean 'y0'?
[...]

[Bug libstdc++/114368] FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Not reproducible.

[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94

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

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

--- Comment #54 from John David Anglin  ---
The f-m-o issue is probably fixed.

[Bug libstdc++/114368] New: FAIL: 25_algorithms/pstl/alg_sorting/set_symmetric_difference.cc -std=gnu++17 execution test

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

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

Bug ID: 114368
   Summary: FAIL:
25_algorithms/pstl/alg_sorting/set_symmetric_differenc
e.cc  -std=gnu++17 execution test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/home
/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux-gn
u/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.
libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/
home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-14
/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include
-fchecking=
1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-
length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOUR
CE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd
c++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc
++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests
uite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithms/pstl/alg_s
orting/set_symmetric_difference.cc -std=gnu++17 -ltbb
-fdiagnostics-plain-output
 ./libtestc++.a -Wl,--gc-sections
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/lib
stdc++-v3/src/filesystem/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd
c++-v3/src/experimental/.libs -lm -o ./set_symmetric_difference.exe
In file included from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/hppa-linux-gnu/bits/c++config.h:887,
 from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/bits/requires_hosted.h:31,
 from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/execution:30,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithm
s/pstl/alg_sorting/set_symmetric_difference.cc:28:
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
func
tion '_RandomAccessIterator
__pstl::__internal::__brick_unique(_RandomAccessIter
ator, _RandomAccessIterator, _BinaryPredicate, std::true_type)':
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:1219:
no
te: '#pragma message:  [Parallel STL message]: "Vectorized algorithm
unimplement
ed, redirected to serial"'
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
func
tion '_RandomAccessIterator
__pstl::__internal::__brick_partition(_RandomAccessI
terator, _RandomAccessIterator, _UnaryPredicate, std::true_type)':
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:1929:
no
te: '#pragma message:  [Parallel STL message]: "Vectorized algorithm
unimplement
ed, redirected to serial"'
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
func
tion '_RandomAccessIterator
__pstl::__internal::__brick_stable_partition(_Random
AccessIterator, _RandomAccessIterator, _UnaryPredicate, std::true_type)':
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2029:
no
te: '#pragma message:  [Parallel STL message]: "Vectorized algorithm
unimplement
ed, redirected to serial"'
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
func
tion '_RandomAccessIterator3
__pstl::__internal::__brick_merge(_RandomAccessIter
ator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2,
_
RandomAccessIterator3, _Compare, std::true_type)':
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2715:
no
te: '#pragma message:  [Parallel STL message]: "Vectorized algorithm
unimplement
ed, redirected to serial"'
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
function 'void __pstl::__internal::__brick_inplace_merge(_RandomAccessIterator,
_RandomAccessIterator, _RandomAccessIterator, _Compare, std::true_type)':
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h:2764:
note: '#pragma message:  [Parallel STL message]: "Vectorized algorithm
unimplemented, redirected to serial"'
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/pstl/algorithm_impl.h: In
function '_OutputIterator
__pstl::__internal::__brick_set_union(_RandomAccessIterator1,
_RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2,
_OutputIterator, _Compare, std::true_type)':
/home/dave/gnu/gcc/gcc-tru

[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #15 from John David Anglin  ---
Should be fixed.

[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

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

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

--- Comment #7 from John David Anglin  ---
Created attachment 57658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57658&action=edit
Patch

This change works around the reload issue for alpha.i and the reduced
test case.

In principle, this could also occur for SI and DI mode floating-point
loads and stores but limiting them to 5-bit offsets is a big compromise.
It probably would also break python builds as PR rtl-optimization/112415
still isn't fixed.

[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

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

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

--- Comment #6 from John David Anglin  ---
It looks to me like a bug in reload.  Reload generates bogus reloads for
insn 14 and deletes insn 10 which sets (reg/f:SI 146).

But the bug was probably exposed by the change I made a few months ago
to pa_legitimate_address_p.  insn 14 needs reloading because the offset
doesn't fit in 5 bits.

The code in pa_emit_move_sequence to fix up invalid offsets in floating
point loads and stores is not used.

This backtrace points to the broken area of reload.

(gdb) bt
#0  pa_emit_move_sequence (operands=0xf7b02e08, mode=E_SImode, scratch_reg=0x0)
at ../../gcc/gcc/config/pa/pa.cc:1924
#1  0x011366a8 in gen_movsi (operand0=0xf98f35e8, operand1=0xf98276a0)
at ../../gcc/gcc/config/pa/pa.md:2141
#2  0x004a7070 in insn_gen_fn::operator() (
this=) at ../../gcc/gcc/recog.h:441
#3  emit_move_insn_1 (x=0xf98276a0, y=0xf98276a0) at ../../gcc/gcc/expr.cc:4551
#4  0x004b229c in gen_move_insn (x=0xf98276a0, y=0xf98f35e8)
at ../../gcc/gcc/expr.cc:4741
#5  0x00843fe4 in gen_reload (out=, in=,
opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS)
at ../../gcc/gcc/reload1.cc:8637
#6  0x008442f0 in gen_reload (out=, in=,
opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS)
at ../../gcc/gcc/reload1.cc:8550
#7  0x00848914 in emit_input_reload_insns (chain=,
rl=0x192ddf8 , old=, j=-108890464)
at ../../gcc/gcc/reload1.cc:7527
#8  do_input_reload (chain=, rl=0xf98f35e8, j=-108890464)
at ../../gcc/gcc/reload1.cc:7814
#9  0x00850698 in emit_reload_insns (chain=)
at ../../gcc/gcc/reload1.cc:8002
#10 reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.cc:4543
--Type  for more, q to quit, c to continue without paging--
#11 reload (first=, global=1) at ../../gcc/gcc/reload1.cc:1047
#12 0x0067c508 in do_reload () at ../../gcc/gcc/ira.cc:5985
#13 (anonymous namespace)::pass_reload::execute (this=)
at ../../gcc/gcc/ira.cc:6161
#14 0x0079ef7c in execute_one_pass (pass=0xf98276a0)
at ../../gcc/gcc/passes.cc:2646
#15 0x0079f894 in execute_pass_list_1 (pass=0xf98276a0)
at ../../gcc/gcc/passes.cc:2755
#16 0x0079f8ac in execute_pass_list_1 (pass=0xf98276a0)
at ../../gcc/gcc/passes.cc:2756
#17 0x0079f90c in execute_pass_list (fn=, pass=)
at ../../gcc/gcc/passes.cc:2766
#18 0x003b9a8c in cgraph_node::expand (this=0xf98276a0)
at ../../gcc/gcc/context.h:48
#19 cgraph_node::expand (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:1798
#20 0x003bbaa8 in expand_all_functions () at ../../gcc/gcc/cgraphunit.cc:2028
#21 symbol_table::compile (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:2402
#22 0x003bdc4c in symbol_table::compile (this=0x7)
at ../../gcc/gcc/cgraphunit.cc:2315
#23 symbol_table::finalize_compilation_unit (this=0x7)
at ../../gcc/gcc/cgraphunit.cc:2587
#24 0x008d137c in compile_file () at ../../gcc/gcc/toplev.cc:476

Will try to work around issue in pa_legitimate_address_p.

[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)

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

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

--- Comment #5 from John David Anglin  ---
This is what we have from reload with Sam's reduced test case:

(insn 9 103 123 2 (set (reg/f:SI 1 %r1)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child")   "beta.c":18:32 53 {*pa.md:2656}
 (nil))
(insn 123 9 11 2 (set (reg:SI 20 %r20 [113])
(reg/f:SI 1 %r1)) "beta.c":18:32 42 {*pa.md:2195}
 (nil))
(insn 11 123 10 2 (set (reg:SI 1 %r1 [115])
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
 (nil))
(note 10 11 12 2 NOTE_INSN_DELETED)
(insn 12 10 13 2 (set (reg/f:SI 20 %r20 [114])
(mem/u/c:SI (lo_sum:SI (reg:SI 1 %r1 [115])
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0  S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
 (expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil)))
(insn 13 12 125 2 (set (reg:DF 68 %fr22 [116])
(mem/u/c:DF (reg/f:SI 20 %r20 [114]) [0  S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
 (expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil)))
(insn 125 13 127 2 (set (reg:SI 20 %r20)
(const_int 32 [0x20])) "beta.c":18:32 42 {*pa.md:2195}
 (nil))
(insn 127 125 128 2 (set (reg:SI 20 %r20)
(reg/f:SI 146)) "beta.c":18:32 42 {*pa.md:2195}
 (nil))
(insn 128 127 14 2 (set (reg:SI 20 %r20)
(plus:SI (reg:SI 20 %r20)
(const_int 32 [0x20]))) "beta.c":18:32 120 {addsi3}
 (expr_list:REG_EQUIV (plus:SI (reg/f:SI 146)
(const_int 32 [0x20]))
(nil)))
(insn 14 128 116 2 (set (mem/c:DF (plus:SI (reg:SI 20 %r20)
(const_int -16 [0xfff0])) [1
indirect_child.cg.prop.fract+0 S8 A64])
(reg:DF 68 %fr22 [116])) "beta.c":18:32 75 {*pa.md:3866}
 (nil))

In ira, we had:

(insn 9 103 11 2 (set (reg:SI 113)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child")   "beta.c":18:32 53 {*pa.md:2656}
 (nil))
(insn 11 9 10 2 (set (reg:SI 115)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
 (nil))
(insn 10 11 12 2 (set (reg/f:SI 146)
(mem/u/c:SI (lo_sum:SI (reg:SI 113)
(unspec:SI [
(symbol_ref:SI ("indirect_child")  )
] UNSPEC_DLTIND14R)) [0  S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
 (expr_list:REG_DEAD (reg:SI 113)
(expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child")  )
(nil
(insn 12 10 13 2 (set (reg/f:SI 114)
(mem/u/c:SI (lo_sum:SI (reg:SI 115)
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0  S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
 (expr_list:REG_DEAD (reg:SI 115)
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil
(insn 13 12 14 2 (set (reg:DF 116)
(mem/u/c:DF (reg/f:SI 114) [0  S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
 (expr_list:REG_DEAD (reg/f:SI 114)
(expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil
(insn 14 13 110 2 (set (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(reg:DF 116)) "beta.c":18:32 75 {*pa.md:3866}
 (expr_list:REG_DEAD (reg:DF 116)
(nil)))