[Bug target/115148] [12/13/14/15 Regression][SH]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #15 from John Paul Adrian Glaubitz  ---
Created attachment 58258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58258=edit
Diff of generated assembly without and with changes from PR99531

I have generated a diff that shows the difference in the generated assembly
without and with the patch a7acb6dca941db2b1c135107dac3a34a20650d5c.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
I can even confirm that reverting a7acb6dca941db2b1c135107dac3a34a20650d5c
(with some minor merge adjustments) on current git master fixes the problem for
me.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #12 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > 
> > Yes, definitely. Will take a little longer though as I need to fix my setup
> > first.
> 
> Thanks in advance.  Wait for your update.

OK, done. Bisect lead me to the following commit:

commit a7acb6dca941db2b1c135107dac3a34a20650d5c
Author: Vladimir N. Makarov 
Date:   Mon Dec 13 13:48:12 2021 -0500

[PR99531] Modify pseudo class cost calculation when processing move
involving the pseudo and a hard register

Pseudo class calculated on the 1st iteration should not have a
special treatment in cost calculation when processing move involving
the pseudo and a hard register.

gcc/ChangeLog:

PR target/99531
* ira-costs.c (record_operand_costs): Do not take pseudo class
calculated on the 1st iteration into account when processing move
involving the pseudo and a hard register.

gcc/testsuite/ChangeLog:

PR target/99531
* gcc.target/i386/pr99531.c: New test.

 gcc/ira-costs.c | 22 +-
 gcc/testsuite/gcc.target/i386/pr99531.c |  7 +++
 2 files changed, 8 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr99531.c

I have double-checked that this commit introduces the regression.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #8)
> Adrian, if you have the means, can you bisect it to pinpoint the commit
> where this error starts occuring?

Yes, definitely. Will take a little longer though as I need to fix my setup
first.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
Created attachment 58245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58245=edit
Preprocessed source from building read-vorbis.c with gcc-11 and -fverbose-asm

(In reply to Oleg Endo from comment #5)> 
> Can you please attach the .s file when compiled with GCC 11, just for
> comparison/reference.

Sure, see attached.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
Created attachment 58244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58244=edit
Preprocessed source from building read-vorbis.c with gcc-14 and -fverbose-asm

(In reply to Oleg Endo from comment #3)
> Can you please try to compile with -fverbose-asm  maybe it will give a
> first hint as to where the problematic code comes from.

Done. See attached pr115148-preprocessed-source-verbose.tgz.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
It will succeed, if any of the following optimizations are removed:

-fcrossjumping
-finline-functions
-finline-small-functions
-freorder-blocks-algorithm=stc
-ftree-pre
-ftree-tail-merge
-ftree-vrp

Consequently, it always fails when these flags are present at the same time.

[Bug target/115148] [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Created attachment 58234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58234=edit
Preprocessed source from building read-vorbis.c with gcc-14

[Bug target/115148] New: [SH] [12/13/14 Regression]: libcanberra fails with 'unaligned opcodes detected in executable segment'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 115148
   Summary: [SH] [12/13/14 Regression]: libcanberra fails with
'unaligned opcodes detected in executable segment'
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Since gcc 12, building libcanberra on sh4 fails with:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$

This goes away when reducing the optimization to -O1:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-12 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O1
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$

or switching to gcc 11:

(unstable-sh4-sbuild)glaubitz@z6:/build/libcanberra-x2Sqti/libcanberra-0.30/src$
gcc-11 -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall -W -Wextra -Winline
-Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security
-Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition
-Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result
-Wunsafe-loop-optimizations -Wpacked -Werror=overflow -Wp,-D_FORTIFY_SOURCE=2
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing
-ffunction-sections -fdata-sections
-DCA_PLUGIN_PATH=\"/usr/lib/sh4-linux-gnu/libcanberra-0.30\"
-DCA_MACHINE_ID=\"/var/lib/dbus/machine-id\" -g -O2
-Werror=implicit-function-declaration
-ffile-prefix-map=/build/libcanberra-x2Sqti/libcanberra-0.30/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -c read-vorbis.c  -fPIC -DPIC -o
.libs/libcanberra_la-read-vorbis.o
(unstable-sh4-sbuild)glaubitz@z6:/build/lib

[Bug target/111898] [12/13/14 Regression][SH] internal compiler error: Segmentation fault when building PostgreSQL 16

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Looks like that the issue no longer shows and postgresql-16 builds fine [1].

So, we can probably close this.

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-16=sh4=16.2-1=1707416240=0

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #128 from John Paul Adrian Glaubitz  ---
Created attachment 57498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57498=edit
Build log including preprocessed source for building gcc-14 (20240221) natively
with LRA

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #127 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #126)
> I'm retesting a native build with LRA enabled by default now and report back.
> 
> If that works, I will try to build and boot a kernel.

OK, that fails with:

../../../src/libgcc/libgcc2.c: In function '__addvsi3':
../../../src/libgcc/libgcc2.c:84:1: error: unable to generate reloads for:
   84 | }
  | ^
(call_insn 29 28 30 4 (parallel [
(call (mem:SI (symbol_ref:SI ("abort") [flags 0x41] ) [0 __builtin_abort S4 A32])
(const_int 0 [0]))
(use (reg:SI 154 fpscr0))
(use (reg:SI 12 r12))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 176))
]) "../../../src/libgcc/libgcc2.c":81:5 228 {call_pcrel}
 (expr_list:REG_DEAD (reg:SI 154 fpscr0)
(expr_list:REG_CALL_DECL (symbol_ref:SI ("abort") [flags 0x41]
)
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(nil))
during RTL pass: reload

Attaching the full build log which also contains the intermediate source.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #126 from John Paul Adrian Glaubitz  ---
I'm retesting a native build with LRA enabled by default now and report back.

If that works, I will try to build and boot a kernel.

[Bug rust/113553] rust fails to build on sparc64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #14 from John Paul Adrian Glaubitz  ---
The posix_spawn() issue on sparc64 is explained in more detail, including a
reproducer, here:
https://lore.kernel.org/sparclinux/3ae4130c-c5aa-428e-b819-44cf2daf2...@mkarcher.dialup.fu-berlin.de/

[Bug rust/113553] rust fails to build on sparc64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #9)
> oh look at this a memset issue on sparc glibc:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31068 .

Hmm, but this would be sparc32. Are you sure that this applies here?

[Bug rust/113553] rust fails to build on sparc64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #6)
> Let me look that seems like an unitialized variable. If it is obvious one, I
> will apply a patch.

Thanks. I was actually researching the above error message and one explanation
was that variables passed to the posix_spawn() API might uninitialized when
triggering this error message.

[Bug rust/113553] rust fails to build on sparc64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Rainer Orth from comment #1)
> The build works for me just fine on sparc-sun-solaris2.11.
> 
> I've also fired one off on sparc64-unknown-linux-gnu which worked just as
> well.
> It was a rough ride, however, with the build aborting with
> 
> xgcc: fatal error: cannot execute
> '/var/gcc/regression/master/6.4.0-gcc-gas-gld/build/./gcc/cc1plus':
> posix_spawn: Bad address
> 
> several times.  When I ran make under strace -f, however, the build worked
> just
> fine.  Quite ugly, actually.

It seems that this can be avoided by building with one job, i.e. with "make
-j1".

Some playing around showed that this fixes the problem for me:

diff --git a/libiberty/pex-unix.c b/libiberty/pex-unix.c
index af98062a94c..a1d35820181 100644
--- a/libiberty/pex-unix.c
+++ b/libiberty/pex-unix.c
@@ -574,8 +574,8 @@ pex_unix_exec_child (struct pex_obj *obj ATTRIBUTE_UNUSED,
 {
   int ret;
   pid_t pid = -1;
-  posix_spawnattr_t attr;
-  posix_spawn_file_actions_t actions;
+  static posix_spawnattr_t attr;
+  static posix_spawn_file_actions_t actions;
   int attr_initialized = 0, actions_initialized = 0;

   *err = 0;

[Bug other/112836] gcc fails when job control is used

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
I tried this patch but it does not address the issue with posix_spawn that I am
seeing.

Trying to build gcc from git on Linux sparc64 with glibc 2.37 with the
following configuration:

./configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
--disable-nls --host=sparc64-unknown-linux-gnu

fails with:

xgcc: fatal error: cannot execute '/home/glaubitz/gcc/build/./gcc/cc1plus':
posix_spawn: Bad address
compilation terminated.

This can be worked around when building with one parallel job (make -j1).

[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> (In reply to Sam James from comment #6)
> > As far as upstream is concerned, < 11 is EOL, but if you file a bug on the
> > suse side, maybe they'd be willing to do it.
> 
> That's what I'm already doing. gcc-7 is the default compiler in SLE-15.

Update is on the way, although it'll take a little longer until SLE-15 picks it
up.

See:
https://build.opensuse.org/package/rdiff/devel:gcc/gcc7?linkrev=base=243

[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Sam James from comment #6)
> As far as upstream is concerned, < 11 is EOL, but if you file a bug on the
> suse side, maybe they'd be willing to do it.

That's what I'm already doing. gcc-7 is the default compiler in SLE-15.

[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #5 from John Paul Adrian Glaubitz  ---
I am seeing this with gcc-7 on SUSE Linux Enterprise 15. Can this fix be
backported to gcc-7 and gcc-8 as well?

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #1)
> This could still be a bug in LLVM too.
> 
> Without much more information, it is hard to decide.

I fully agree. I filed this bug report to broaden the audience looking for
suggestions how to debug this.

(In reply to Segher Boessenkool from comment #2)
> We need a reduced testcase.

Any suggestion on how to proceed here?

[Bug target/113341] New: Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 113341
   Summary: Using GCC as the bootstrap compiler breaks LLVM on
32-bit PowerPC
   Product: gcc
   Version: 13.2.1
   URL: https://github.com/llvm/llvm-project/issues/72279
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, segher at gcc dot gnu.org,
sjames at gcc dot gnu.org
  Target Milestone: ---

Using GCC on 32-bit PowerPC as the bootstrap compiler to build LLVM leads to
clang crashing during stage 2 with a backtrace. This does not happen when LLVM
is used as the bootstrap compiler.

The backtrace that clang generates can be found in the LLVM bug report [1].

The problem was observed with LLVM 17, so I initially suspected a regression in
LLVM. I was able to bisect issue which lead to the following commit in LLVM:

bc73ef0031b50f7443615fef614fb4ecaaa4bd11 is the first bad commit
commit bc73ef0031b50f7443615fef614fb4ecaaa4bd11
Author: Richard Smith 
Date:   Thu Mar 30 14:21:31 2023 -0700

PR60985: Fix merging of lambda closure types across modules.

However, since the problem does not show when using LLVM as the bootstrap
compiler instead of GCC, I'm suspecting that GCC is miscompiling the code.

> [1] https://github.com/llvm/llvm-project/issues/72279

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to John Paul Adrian Glaubitz from comment #8)
> > (In reply to Segher Boessenkool from comment #7)
> > > This PR is for the sysv ABI, while most discussion was about the "ELFv1" 
> > > ABI.
> > 
> > Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"?
> 
> Yes.  And most of the discussion (via the gentoo link) is about
> powerpc64-linux.
> 
> So things were confusing, for me at least.

OK, yeah. That's confusing. I haven't seen any issues on 64-bit targets.

> > I am trying -O3 now.
> 
> That almost always runs out of space easier, not less easily.  O3 prioritises
> possible speed wins over anything else (*possible* speed wins).

This actually worked for me and allowed me to build an unregisterised GHC
compiler. So, thanks for the hint!

> > > If you get an error at line 577996 of a source file, changes are your code
> > > is just
> > > completely unreasonably large, esp. on a smaller target like this :-)
> > 
> > I understand. But it's not always possible to change the code size,
> > especially when the code is not mine but some random upstream code.
> > 
> > What I don't understand is that other 32-bit architectures don't seem to be
> > affected. For example, hppa-unknown-linux-gnu is not affected.
> 
> None of the HPPA ABIs are affected by peculiarities of a particular PowerPC
> ABI.

OK, I see.

> The bug report does noty give enough information to see what is really going
> on,
> so I have no further advice.

Your pointer towards -O3 did the trick, so no worries!

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #7)
> This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.

Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"?

> Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-*
> configurations.
> Some other architectures have it for more things, and some for fewer, or
> even none.

I am trying -O3 now.

> If you get an error at line 577996 of a source file, changes are your code
> is just
> completely unreasonably large, esp. on a smaller target like this :-)

I understand. But it's not always possible to change the code size, especially
when the code is not mine but some random upstream code.

What I don't understand is that other 32-bit architectures don't seem to be
affected. For example, hppa-unknown-linux-gnu is not affected.

And, secondly, using LLVM as the bootstrap compiler resolves the issue with
LLVM for me.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > See my previous comment?
> > 
> > You can either write better code, or use -mcmodel=large or similar, 
> > accepting
> > the not-so-stellar generated code you get then.
> 
> I'm already testing -mcmodel=large now. I'm just surprised it just affects
> GCC on PowerPC but not LLVM, for example.

Doesn't seem to be supported, unfortunately, build fails with:

'-mcmodel' not supported in this configuration

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #4)
> See my previous comment?
> 
> You can either write better code, or use -mcmodel=large or similar, accepting
> the not-so-stellar generated code you get then.

I'm already testing -mcmodel=large now. I'm just surprised it just affects GCC
on PowerPC but not LLVM, for example.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #3 from John Paul Adrian Glaubitz  ---
I am seeing this when building LLVM and GHC on 32-bit PowerPC as well. It does
not affect other 32-bit architectures and using LLVM as the bootstrap compiler
resolves this issue.

What's the proper way of addressing this?

[Bug target/113140] [SPARC] [13 Regression] Segmentation fault during RTL pass: dbr

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
Created attachment 56940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56940=edit
Preprocessed source from building qt6-declarative with gcc-13

Sure, see attached.

[Bug target/113140] New: [SPARC] [13 Regression] Segmentation fault during RTL pass: dbr

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 113140
   Summary: [SPARC] [13 Regression] Segmentation fault during RTL
pass: dbr
   Product: gcc
   Version: 13.2.1
   URL: https://buildd.debian.org/status/fetch.php?pkg=qt6-dec
larative=sparc64=6.6.1%2Bdfsg-1=1702262
113=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, matorola at gmail dot com, ro at 
gcc dot gnu.org,
sjames at gcc dot gnu.org, sumbera at volny dot cz
  Target Milestone: ---
Target: sparc64-linux-gnu

When building qt6-declarative on 64-bit Linux SPARC, gcc-13 crashes with the
following error message:

(experimental_sparc64-dchroot)glaubitz@stadler:~/qt6-declarative/qt6-declarative-6.6.1+dfsg$
/usr/bin/c++ -DBUILDING_QT__ -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DENABLE_DFG_JIT=0 -DENABLE_DFG_JIT_UTILITY_METHODS=1
 -DENABLE_JIT_CONSTANT_BLINDING=0 -DENABLE_LLINT=0 -DJS_EXPORT_PRIVATE=""
-DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_QML_LIB -DQT_CORE_LIB
-DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x050
000 -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1
-DQT_MOC_COMPAT -DQT_NETWORK_LIB -DQT_NO_AS_CONST -DQT_NO_AS_CONST=1
-DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -D
QT_NO_INTEGER_EVENT_COORDINATES -DQT_NO_JAVA_STYLE_ITERATORS
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_QEXCHANGE
-DQT_NO_URL_CAST_FROM_STRING -DQT_QMLINTEGRATION_LIB -DQT_USE_QSTRINGBUILDER
-DQT_WARN_DE
PRECATED_UP_TO=0x07 -DQml_EXPORTS
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportAssertionFailureWithMessage=qmlWTFReportAssertionFailureWith
Message -DWTFReportBacktrace=qmlWTFReportBacktrace -DWTF_EXPORT_PRIVATE=""
-DWTF_USE_UDIS86=0 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-l
inux-gnu/src/qml/Qml_autogen/include
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/include
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/
include/QtQml
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qml
-I/home/glaubitz/qt6-declarative/qt6-
declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qml/.generated
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qml/compiler
-I/home/glaubitz/qt6-declarative/qt6-declarati
ve-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qml/jsruntime
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qml/memory
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfs
g/obj-sparc64-linux-gnu/src/qml/qmldirparser
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty
/masm/assembler
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/disassembler
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/disassembl
er/udis86
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/jit
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/runtime
-I/home/glaubitz/
qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/stubs
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/stubs/runtime
-I/home/glaubitz/qt6-declarative/qt6
-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/stubs/wtf
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/../3rdparty/masm/wtf
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/s
rc/qml/compiler
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/debugger
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/jsruntime
-I/home/glaubitz/qt6-declarative/qt6-d
eclarative-6.6.1+dfsg/src/qml/memory
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qml/qmldirparser
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/include/Q
tQml/6.6.1
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/include/QtQml/6.6.1/QtQml
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/include/
QtQmlIntegration
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/src/qmlintegration
-I/home/glaubitz/qt6-declarative/qt6-declarative-6.6.1+dfsg/obj-sparc64-linux-gnu/src/qmlintegration
-I/home/glau
bitz/qt6-declarative/qt6-declarativ

[Bug target/93808] [11/12/13/14 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #38 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #37)
> (In reply to John Paul Adrian Glaubitz from comment #32)
> > (In reply to John Paul Adrian Glaubitz from comment #31)
> > > Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS.
> > > 
> > > Are the builtin_traps() optimized out for -O2?
> > > 
> > > I'm building with the correct flags now.
> > 
> > Traps also didn't trigger with -O1 and -fno-cross-jumping.
> 
> Adrian, what happened to this issue in the end?  Do you remember?

Ruby is still being built with -fno-crossjumping on sh4. Let me check, whether
we can drop the flag nowadays with Ruby 3.1 and gcc-13.

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #22 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #21)
> (In reply to John Paul Adrian Glaubitz from comment #20)
> > I don't think this is a duplicate. This one is supposed to be without -mlra.
> 
> All of the comments here talk about -mlra and even that one all of the
> comments talk about using -mlra .

I should probably recheck all the issues I reported whether they still affect
gcc-13 or trunk. Some of my reports are quite old.

[Bug target/93877] [11/12/13/14 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #20 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #19)
> Dup of bug 83464.
> 
> *** This bug has been marked as a duplicate of bug 83464 ***

I don't think this is a duplicate. This one is supposed to be without -mlra.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #16 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #15)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > 
> > Do we need anything else before the fix can be merged?
> 
> No, should be fine.  I'll leave this PR open for a while in case anything
> else related pops up.  Thanks for testing.

Just saw the branch updates, thanks! FWIW, I did observe this issue in gcc-13
only but not gcc-11 or gcc-12. But that might be owed to the fact that Debian's
gcc-11 and gcc-12 packages had not received the latest branch updates yet.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #9)
> (In reply to John Paul Adrian Glaubitz from comment #8)
> > 
> > I built gcc-13 natively with the patch applied with a full bootstrap
> > including stage2 and stage3. Full build log available in [1].
> > 
> > > [1] https://people.debian.org/~glaubitz/gcc-13_13.2.0-2+sh4_sh4.build.gz
> 
> Perfect! Thanks!

Do we need anything else before the fix can be merged?

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #7)
> (In reply to John Paul Adrian Glaubitz from comment #5)
> > 
> > I can confirm that this patch fixes the build of e2fsprogs with gcc-13 for
> > me.
> 
> Great, thanks!  Do you have an option to run a compiler bootstrap or other
> runtime test on sh4-linux with this?

I built gcc-13 natively with the patch applied with a full bootstrap including
stage2 and stage3. Full build log available in [1].

> [1] https://people.debian.org/~glaubitz/gcc-13_13.2.0-2+sh4_sh4.build.gz

[Bug target/111892] [SH] [13 Regression] internal compiler error: Illegal instruction when building e2fsprogs

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> (In reply to Oleg Endo from comment #5)
> > Adrian, can you please give it another go with the patch I've posted in PR
> > 111001 ?
> > 
> > https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164
> 
> I'll rebuild gcc-13 with the patch now and report back. Could take 1-2 days.

I can confirm that this patch fixes the e2fsprogs build for me.

Also, marking this as duplicate of PR111001.

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

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
*** Bug 111892 has been marked as a duplicate of this bug. ***

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #4)
> Created attachment 56164 [details]
> sh_pr11001_fix.patch
> 
> Can you please try this patch?  It should solve the problem, but not sure if
> there could be any unexpected side effects.

I can confirm that this patch fixes the build of e2fsprogs with gcc-13 for me.

[Bug target/111892] [SH] [13 Regression] internal compiler error: Illegal instruction when building e2fsprogs

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #5)
> Adrian, can you please give it another go with the patch I've posted in PR
> 111001 ?
> 
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164

I'll rebuild gcc-13 with the patch now and report back. Could take 1-2 days.

[Bug target/111898] New: [SH] [12 13 Regression] internal compiler error: Segmentation fault when building PostgreSQL 16

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 111898
   Summary: [SH] [12 13 Regression] internal compiler error:
Segmentation fault when building PostgreSQL 16
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: olegendo at gcc dot gnu.org, ysato at users dot 
sourceforge.jp
  Target Milestone: ---
Target: sh-*-*-*

Created attachment 56158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56158=edit
Preprocessed source from building PostgreSQL 16 with gcc-13

Trying to build PostgreSQL 16 on Debian unstable sh4 with gcc-12 or gcc-13
results in the compiler crashing with a segmentation fault:

root@tirpitz:..backend/access> /usr/bin/sh4-linux-gnu-gcc-12 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla
-Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -g -g -O2
-ffile-prefix-map=/build/postgresql-16-T1yJxb/postgresql-16-16.0/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -I../../../../src/include
-I/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/src/include  -Wdate-time
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2   -c -o heapam.o
/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/../src/backend/access/heap/heapam.c
-save-temps
sh4-linux-gnu-gcc-12: internal compiler error: Segmentation fault signal
terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
root@tirpitz:..backend/access> /usr/bin/sh4-linux-gnu-gcc-13 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla
-Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -g -g -O2
-ffile-prefix-map=/build/postgresql-16-T1yJxb/postgresql-16-16.0/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -I../../../../src/include
-I/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/src/include  -Wdate-time
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2   -c -o heapam.o
/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/../src/backend/access/heap/heapam.c
-save-temps
sh4-linux-gnu-gcc-13: internal compiler error: Segmentation fault signal
terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
root@tirpitz:..backend/access>

Both gcc-10 and gcc-11 work fine:

root@tirpitz:..backend/access> /usr/bin/sh4-linux-gnu-gcc-10 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla
-Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -g -g -O2
-ffile-prefix-map=/build/postgresql-16-T1yJxb/postgresql-16-16.0/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -I../../../../src/include
-I/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/src/include  -Wdate-time
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2   -c -o heapam.o
/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/../src/backend/access/heap/heapam.c
-save-temps
root@tirpitz:..backend/access> /usr/bin/sh4-linux-gnu-gcc-11 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla
-Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation
-Wno-stringop-truncation -g -g -O2
-ffile-prefix-map=/build/postgresql-16-T1yJxb/postgresql-16-16.0/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -I../../../../src/include
-I/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/src/include  -Wdate-time
-D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2   -c -o heapam.o
/build/postgresql-16-T1yJxb/postgresql-16-16.0/build/../src/backend/access/heap/heapam.c
-save-temps
root@tirpitz:..backend/access>

Attaching the preprocessed source generated with "-save-temps".

[Bug target/111892] [SH] [13 Regression] internal compiler error: Illegal instruction when building e2fsprogs

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #2)
> Is that on a native sh system or are you cross-compiling?  From which host?

Yes, building on a native system (SH7785LCR) running Debian unstable on kernel
6.5.0. Host is sh4-linux-gnu.

> Do you build GCC with --disable-checking by chance?

No, it's built with "--enable-checking=release", see:

> https://buildd.debian.org/status/fetch.php?pkg=gcc-13=sh4=13.2.0-2=1691861588=0

It's Debian's distribution gcc.

> Can you provide a backtrace?

So, just run the above gcc command inside gdb and print the backtrace?

[Bug target/101177] sh3: internal compiler error: Illegal instruction

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #12 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #5)
> > (In reply to Segher Boessenkool from comment #4)
> > > (In reply to Harold Gutch from comment #1)
> > > > I cannot claim to understand the details of this patch, but note that 
> > > > in the
> > > > second part of the diff the condition gets inverted.
> > > 
> > > Yes, that looks like a clear mistake.  I don't know why I did that, 
> > > perhaps
> > > at first I flipped the control flow there?  Who knows.  Sorry for it 
> > > anyway!
> > 
> > Was this ever fixed?
> 
> It should be now.

That was super-fast! Thanks a lot!

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #12)
> > This is still present in gcc-13, I just ran into it while cross-building the
> > Haskell compiler GHC for sh4:
> > 
> 
> Have you tried using the -mlra option for this build?

I have, but for some reason GHC doesn't seem to pass -mlra to the C compiler.

Needs more investigation.

[Bug target/101177] sh3: internal compiler error: Illegal instruction

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
@Segher: In case it's trivial to fix, could you get this fixed or revert the
patch?

[Bug target/111892] [SH] [13 Regression] internal compiler error: Illegal instruction when building e2fsprogs

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Full source code tree available here:
https://people.debian.org/~glaubitz/e2fsprogs-5VkWTa.tgz

[Bug target/111892] New: [SH] [13 Regression] internal compiler error: Illegal instruction when building e2fsprogs

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 111892
   Summary: [SH] [13 Regression] internal compiler error: Illegal
instruction when building e2fsprogs
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: olegendo at gcc dot gnu.org, ysato at users dot 
sourceforge.jp
  Target Milestone: ---
Target: sh-*-*-*

Created attachment 56156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56156=edit
Preprocessed source from building rw_bitmaps.c with gcc-13

Since gcc-13, there is a regression in the SH backend which results in an
internal compiler error with the error message "Illegal instruction":

root@tirpitz:..lib/ext2fs> gcc-13 -I. -I../../lib -I../../../../lib -Wdate-time
-D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=$(pwd)=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -pthread  -DHAVE_CONFIG_H  -c
../../../../lib/ext2fs/rw_bitmaps.c -o rw_bitmaps.o
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
during RTL pass: sh_treg_combine2
../../../../lib/ext2fs/rw_bitmaps.c: In function ‘read_bitmaps_range_start’:
../../../../lib/ext2fs/rw_bitmaps.c:447:1: internal compiler error: Illegal
instruction
  447 | }
  | ^
0x29a738e0 __GI_abort
./stdlib/abort.c:107
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.
root@tirpitz:..lib/ext2fs>

gcc-12 works fine:

root@tirpitz:..lib/ext2fs> gcc-12 -I. -I../../lib -I../../../../lib -Wdate-time
-D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=$(pwd)=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -pthread  -DHAVE_CONFIG_H  -c
../../../../lib/ext2fs/rw_bitmaps.c -o rw_bitmaps.o
root@tirpitz:..lib/ext2fs>

Attaching the pre-processed source generated with -save-temps.

[Bug target/101177] sh3: internal compiler error: Illegal instruction

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Harold Gutch from comment #1)
> > I cannot claim to understand the details of this patch, but note that in the
> > second part of the diff the condition gets inverted.
> 
> Yes, that looks like a clear mistake.  I don't know why I did that, perhaps
> at first I flipped the control flow there?  Who knows.  Sorry for it anyway!

Was this ever fixed?

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
Created attachment 56123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56123=edit
Preprocessed source from building GHC with gcc-13

This is still present in gcc-13, I just ran into it while cross-building the
Haskell compiler GHC for sh4:

"inplace/bin/ghc-stage1" -optc-Wall -optc-Wall -optc-Wextra
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations
-optc-Winline -optc-Wpointer-ari
th -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
-optc-Wno-aggregate-return -optc-Wno-unused-label -optc-DNOSMP
-optc-fno-strict-aliasing -optc-fno-
common -optc-Irts/dist-install/build/./autogen
-optc-Irts/include/../dist-install/build/include -optc-Irts/include/.
-optc-Irts/. -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=
rts -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2
-optc-fomit-frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-O0
-optc-g3 -optc-DRtsWay=\"r
ts_thr_debug\" -optc-ffunction-sections -optc-fdata-sections -static
-optc-DTHREADED_RTS -optc-DDEBUG  -H32m -O -lffi -optl-pthread -O0 -H64m -Wall 
-this-unit-id rts -opt
c-DNOSMP -dcmm-lint -package-env - -i -irts -irts/dist-install/build
-Irts/dist-install/build -irts/dist-install/build/./autogen
-Irts/dist-install/build/./autogen -Ir
ts/include/../dist-install/build/include -Irts/include/. -Irts/.
-optP-DCOMPILING_RTS -optP-DFS_NAMESPACE=rts-O2 -Wcpp-undef -O0  
-Wnoncanonical-monad-instances  
-c rts/ProfilerReport.c -o rts/dist-install/build/ProfilerReport.thr_debug_o
rts/sm/NonMovingMark.c: In function ‘mark_closure’:

rts/sm/NonMovingMark.c:1763:1: error:
 error: unable to find a register to spill in class ‘R0_REGS’
 1763 | }
  | ^
 |
1763 | }
 | ^

rts/sm/NonMovingMark.c:1763:1: error:  error: this is the insn:
 |
1763 | }
 | ^
(insn 1553 3768 1554 115 (parallel [
(set (subreg:SI (reg:QI 7 r7 [803]) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 3 r3 [orig:299 _160 ] [299]) [-1 
S1 A8])
(reg:QI 800 [ MEM[(struct StgStack *)_313].marking ])
(reg:QI 5 r5 [orig:802 nonmovingMarkEpoch ] [802])
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 3 r3 [orig:299 _160 ] [299]) [-1  S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))

]) "rts/include/stg/SMP.h":325:0: error:
5 405 {atomic_compare_and_swapqi_soft_gusa}
 (expr_list:REG_DEAD (reg:QI 5 r5 [orig:802 nonmovingMarkEpoch ] [802])
(expr_list:REG_DEAD (reg:QI 800 [ MEM[(struct StgStack
*)_313].marking ])
(expr_list:REG_DEAD (reg/f:SI 3 r3 [orig:299 _160 ] [299])
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil

rts/sm/NonMovingMark.c:1763:0: error:
 confused by earlier errors, bailing out
 |
1763 | }
 | ^

Attaching the preprocessed source for that.

[Bug other/93090] RFE: Add a frontend for the Rust programming language

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Jonathan Wakely from comment #6)
> Can this be closed now?

Yes.

I think there is still some money in the Bountysource campaign, not sure what
will happen with it. I'll contact them and make sure the money doesn't go to
waste.

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #9)
> > Program received signal SIGBUS, Bus error.
> > 0x010ceda4 in mdb_node_add (mc=0x14327b8, indx=,
> > key=0x7fee0a0, data=0x7fee090, pgno=0, flags=0) at
> > ./../../../libraries/liblmdb/mdb.c:7366
> > 7366mp->mp_lower += sizeof(indx_t);
> > (gdb) p mp
> > $1 = (MDB_page *) 0x1463caa
> 
> Thanks.  So that's definitely *not* a compiler bug but a programming error
> as per the 6.5.3.2(4) clause of the ISO C standard:

FWIW, the issue does not show when compiling with clang.

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #5)
> Can anyone print the value of mp in the debugger?

glaubitz@gcc202:~/openldap/tests$ gdb --args
/home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/glaubitz/openldap/servers/slapd/slapd...
(gdb) r
Starting program: /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif

Program received signal SIGILL, Illegal instruction.
0xfff8000100e44320 in ?? ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x010ceda4 in mdb_node_add (mc=0x14327b8, indx=,
key=0x7fee0a0, data=0x7fee090, pgno=0, flags=0) at
./../../../libraries/liblmdb/mdb.c:7366
7366mp->mp_lower += sizeof(indx_t);
(gdb) p mp
$1 = (MDB_page *) 0x1463caa
(gdb)

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
Created attachment 53818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53818=edit
Pre-processed source of unmodified mdb.c (gzip-compressed)

Here's the preprocessed source for mdb.c without marking the variables as
volatile.

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #5)
> Note that the fields are marked volatile in the source:
> 
>  union {
>   struct {
>volatile indx_t pb_lower;
>volatile indx_t pb_upper;
>   } pb;
>   uint32_t pb_pages;
>  } mp_pb;

My bad. I actually modified the source to see whether marking them "volatile"
would alleviate the issue as suggested by Howard in the OpenLDAP bug report.

I'll attach the preprocessed source again, this time from the unmodified
»mdb.c«.

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
Created attachment 53814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53814=edit
Pre-processed source of mdb.c (gzip-compressed)

Source code file in OpenLDAP git tree is »libraries/liblmdb/mdb.c« and was
compiled with:

$ /bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2
-I../../../include-I../../../include -I.. -I./..
-I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c

from the sub-directory »servers/slapd/back-mdb«.

Attaching the preprocessed source.

[Bug c/107498] New: Wrong optimization leads to unaligned access when compiling OpenLDAP

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 107498
   Summary: Wrong optimization leads to unaligned access when
compiling OpenLDAP
   Product: gcc
   Version: 12.2.0
   URL: https://bugs.openldap.org/show_bug.cgi?id=9916
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com, slyfox at gcc dot gnu.org
  Target Milestone: ---
Target: sparc64-*-*

Building OpenLDAP on sparc64-linux-gnu using gcc-12 results in a slapd binary
that crashes with unaligned access ("Bus error").

After investigation, it turned out that this is not a bug in the OpenLDAP code
but gcc-12 which tries to optimize a access to two 2-byte fields in a struct
using a 4-byte store instruction. This fails because the 2-byte fields have
only 2-byte alignment.

More details on the issue can be obtained from the corresponding OpenLDAP bug
report, in particular comment #10 [1].

> [1] https://bugs.openldap.org/show_bug.cgi?id=9916#c10

[Bug target/95381] [11/12/13 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #20 from John Paul Adrian Glaubitz  ---
JIT definitely works with 12 on m68k again - and probably 13. So, the title is
misleading.

[Bug ada/88200] [9/10/11/12/13 Regression] ada bootstrap failure on alpha-linux-gnu (aised STORAGE_ERROR : stack overflow or erroneous memory access)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
This has been fixed on 12 and presumably also on 13. So, the title is
misleading.

[Bug target/98341] [11/12/13 Regression] Ada bootstrap fails with erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #21 from John Paul Adrian Glaubitz  ---
This issue is fixed in 12 and presumably also in version 13. So the title is
misleading.

[Bug jit/65884] libgccjit fails to link on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> (In reply to Sergei Trofimovich from comment #3)
> > Created attachment 52765 [details]
> > ia64-disable-sdata-by-default.patch
> > 
> > We can try a radical thing: make -mno-sdata a default:
> > ia64-disable-sdata-by-default.patch . That allows me to link libgccjit on
> > ia64 cross-compiler.
> 
> I'll give it a try.

By the way, wouldn't it be possible to patch the GCC sources so that just
libgccjit is built with -mno-sdata?

[Bug jit/65884] libgccjit fails to link on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Sergei Trofimovich from comment #3)
> Created attachment 52765 [details]
> ia64-disable-sdata-by-default.patch
> 
> We can try a radical thing: make -mno-sdata a default:
> ia64-disable-sdata-by-default.patch . That allows me to link libgccjit on
> ia64 cross-compiler.

I'll give it a try.

> It might break boot loader, kernel and glibc. Worth a test on real hardware.

Oh, that would be a dealbreaker :D. I'll test that as well.

[Bug jit/65884] libgccjit fails to link on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
The problem is still present in gcc-12:

/usr/bin/time -v /home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/xg++
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/src/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -DIN_GCC -fPIC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o libgccjit.so.0.0.1 -shared
\
 attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o
jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o
jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a
libcommon.a \
 ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a  libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -lz -lzstd  \
  \
  -Wl,--version-script,../../src/gcc/jit/libgccjit.map 
-Wl,-soname,libgccjit.so.0
/usr/bin/ia64-linux-gnu-ld: libgccjit.so.0.0.1: short data segment overflowed
(0x400a68 >= 0x40)
collect2: error: ld returned 1 exit status
Command exited with non-zero status 1
Command being timed:
"/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/xg++
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/gcc/
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
-I/home/glaubitz/gcc-12-new/gcc-12-12-20220319/src/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libatomic/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-12-new/gcc-12-12-20220319/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -fPIC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -o libgccjit.so.0.0.1 -shared attribs.o
jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o jit/jit-recording.o
jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o jit/jit-builtins.o
jit/jit-spec.o gcc.o libbackend.a libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl -lz -lzstd
-Wl,--version-script,../../src/gcc/jit/libgccjit.map
-Wl,-soname,libgccjit.so.0"
User time (seconds): 24.17
System time (seconds): 0.71
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:24.89
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 662704
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 50658
Voluntary context switches: 13
Involuntary context switches: 59
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 16384
Exit status: 1

[Bug target/98341] [11/12 Regression] Ada bootstrap fails with erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #19 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> The git snapshot 20220130 from the gcc-11 branch still fails. However, since
> Matthias just uploaded 20220222, I can try that as well and report back.

gcc-11 is still affected.

[Bug target/98341] [11/12 Regression] Ada bootstrap fails with erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #18 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #17)
> > Just as a heads-up: This has been fixed for me with gcc-12. I can
> > successfully bootstrap Ada in gcc-12 with gnat-10.
> 
> Great.  What about gcc-11?

The git snapshot 20220130 from the gcc-11 branch still fails. However, since
Matthias just uploaded 20220222, I can try that as well and report back.

[Bug target/98341] [11/12 Regression] Ada bootstrap fails with erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #16 from John Paul Adrian Glaubitz  ---
Just as a heads-up: This has been fixed for me with gcc-12. I can successfully
bootstrap Ada in gcc-12 with gnat-10.

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #10)
> Applied on the mainline only since not appropriate for release branches.

OK, thanks! I will ask Matthias for including the patch in gcc-11 on Debian.

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
Any updates on this?

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
FWIW, I also asked David Miller regarding the register preservation and here is
his answer:

> The full 64-bit registers of the out and global registers are saved at trap 
> time.
> But only 32-bits of the register window registers will be saved.  I'm pretty 
> sure
> this is what Solaris does too.

> We have a mechanism for doing 64-bit register saves for 32-bit tasks.  We 
> needed
> this for some crypto assembler.  The process has to request 64-bit saves and
> allocate a suitable stack frame (64-bit aligned and biased like 64-bit).

He also agrees that defaulting to V8+ in this case should be fine.

So, I guess we can go ahead and make this change!

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #5)
> > The function init_sparc64_elf_hwcap(void) [1] unconditionally enables it
> > with:
> > 
> > cap |= (AV_SPARC_MUL32 | AV_SPARC_DIV32 | AV_SPARC_V8PLUS);
> > 
> > So, I think it should be safe and enable V8+ on sparc64 for 32-bit targets
> > the same way it is done on Solaris.
> 
> OK, thanks, running the testsuite of the modified compiler with -m32 does
> not exhibit anything suspicious either, so I'm going to make the change on
> mainline.

Awesome, thanks! Can we get a backport for gcc-11 as well?

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> I think that should be the case given that the 32-bit SPARC port in Debian
> has been based on the SPARCV8+ baseline since 2007 [1].
> 
> Is there any way to verify this?

Looking at the kernel setup code for sparc64, support for V8+ seems to be a
standard capability that is available on all 64-bit SPARC targets.

The function init_sparc64_elf_hwcap(void) [1] unconditionally enables it with:

cap |= (AV_SPARC_MUL32 | AV_SPARC_DIV32 | AV_SPARC_V8PLUS);

So, I think it should be safe and enable V8+ on sparc64 for 32-bit targets the
same way it is done on Solaris.

> [1] 
> https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/arch/sparc/kernel/setup_64.c#L531

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #2)
> Created attachment 52272 [details]
> Tentative fix

Thanks a lot for the quick fix.

> This requires that the kernel preserves the full 64-bit registers even in
> 32-bit mode, like on Solaris.

I think that should be the case given that the 32-bit SPARC port in Debian has
been based on the SPARCV8+ baseline since 2007 [1].

Is there any way to verify this?

> [1] https://lists.debian.org/debian-devel-announce/2007/07/msg6.html

[Bug target/104189] New: [sparc] Inconsistent behavior for -mcpu=v9 -m32 on Linux and Solaris

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 104189
   Summary: [sparc] Inconsistent behavior for -mcpu=v9 -m32 on
Linux and Solaris
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
  Target Milestone: ---
Target: sparc-*-*-*

On Solaris and Linux, 32-bit V9 behave differently in regards to what size of
atomic operations are supported.

On Linux, the maximum size for an atomic operation on 32-bit V9 is 32 bits, on
Solaris it is 64 bits. Moreover, setting -mcpu=ultrasparc3 makes the two match
again.

Linux:

glaubitz@gcc202:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
glaubitz@gcc202:~$ echo | gcc -m32 -mcpu=ultrasparc3 -E -dM -|grep -i SWAP
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
glaubitz@gcc202:~$

Solaris:

sysadmin@deimos:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
sysadmin@deimos:~$ echo | gcc -m32 -mcpu=ultrasparc3 -E -dM -|grep -i SWAP
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
sysadmin@deimos:~$

Unless there is a specific reason, it would nice if the behavior was consistent
for both Linux and Solaris such that code that wants to use 64-bit atomics
would behave the same on the two platforms.

[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #12)
> But, of course, you shouldn't have to.  A "make install" should put fmt.gox
> in the right place by default.  I don't know why you are seeing a problem
> there.

I gave it a try again. Compiling works, but the program crashes:

glaubitz@yttrium:~$ gccgo hello.go -o hello
glaubitz@yttrium:~$ ./hello 
Aborted
glaubitz@yttrium:~$

[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Richard Biener from comment #9)
> > Any update on the status on current trunk?
> 
> I can give it a try later this week. We have a new shiny ia64 porterbox in
> Debian now :-).

So, I just did a bootstrap build with

$ ../configure --prefix=$HOME/gcc-install --enable-multilib
--enable-languages=c,c++,go --with-system-libunwind

and it built fine without any issues.

Trying to build a simple Go program failed however due to an unrelated error:

(sid_ia64-dchroot)glaubitz@yttrium:~/gcc-install/bin$ ./gccgo ~/hello.go 
/home/glaubitz/hello.go:5:11: error: import file 'fmt' not found
5 | import "fmt"
  |   ^
/home/glaubitz/hello.go:10:5: error: reference to undefined name 'fmt'
   10 | fmt.Println("hello world")
  | ^
(sid_ia64-dchroot)glaubitz@yttrium:~/gcc-install/bin$

I'm not a GO expert, so no idea how to tell the Go compiler where the libraries
are located.

[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #9)
> Any update on the status on current trunk?

I can give it a try later this week. We have a new shiny ia64 porterbox in
Debian now :-).

[Bug target/102588] ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Created attachment 51545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51545=edit
Preprocessed source.

[Bug target/102588] New: ICE: in smallest_mode_for_size, at stor-layout.c:356 when building openorienteering-mapper

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 102588
   Summary: ICE: in smallest_mode_for_size, at stor-layout.c:356
when building openorienteering-mapper
   Product: gcc
   Version: 10.3.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=openori
enteering-mapper=sparc64=0.9.5-1=163312
0814=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com,
matorola at gmail dot com
  Target Milestone: ---
Target: sparc64-*-*-*

Trying to build openorienteering-mapper on sparc64 fails on Debian unstable
with:

[ 68%] Building CXX object
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o
cd /<>/obj-sparc64-linux-gnu/src && /usr/bin/c++
-DMAPPER_BIG_ENDIAN -DMAPPER_COMMON_LIB -DMAPPER_USE_GDAL
-DMAPPER_USE_NMEA_POSITION_PLUGIN -DMAPPER_USE_POWERSHELL_POSITION_PLUGIN
-DMAPPER_USE_SENSORS -DNDEBUG -DQT_CONCURRENT_LIB -DQT_CORE_LIB
-DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG
-DQT_NO_DEBUG_OUTPUT -DQT_NO_WARNING_OUTPUT -DQT_PRINTSUPPORT_LIB
-DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DSCALING_ICON_ENGINE_PLUGIN -DUNICODE
-DWITH_COVE -D_USE_MATH_DEFINES
-I/<>/obj-sparc64-linux-gnu/src/Mapper_Common_autogen/include
-I/<>/src -I/<>/3rd-party/cove
-I/<>/obj-sparc64-linux-gnu/src -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore/5.15.2/QtCore -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui/5.15.2/QtGui -isystem
/usr/include/polyclipping -isystem /usr/include/sparc64-linux-gnu/qt5 -isystem
/usr/include/sparc64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/sparc64-linux-gnu/qt5/QtGui -isystem
/usr/include/sparc64-linux-gnu/qt5/QtCore -isystem
/usr/lib/sparc64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/sparc64-linux-gnu/qt5/QtConcurrent -isystem
/<>/src/printsupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/sparc64-linux-gnu/qt5/QtNetwork -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wpedantic
-Wextra -O3 -DNDEBUG -fPIC -std=gnu++14 -MD -MT
src/CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -MF
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o.d -o
CMakeFiles/Mapper_Common.dir/tools/edit_line_tool.cpp.o -c
/<>/src/tools/edit_line_tool.cpp
during RTL pass: expand
In file included from /<>/src/tools/cut_tool.h:34,
 from /<>/src/tools/cut_tool.cpp:22:
/<>/src/core/objects/object.h: In member function
‘OpenOrienteering::ObjectPathCoord
OpenOrienteering::CutTool::findEditPoint(const OpenOrienteering::MapCoordF&,
int, int) const’:
/<>/src/core/objects/object.h:1275:50: internal compiler error: in
smallest_mode_for_size, at stor-layout.c:356
 1275 | : PathCoord { object->findPathCoordForIndex(index) }
  |  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Attaching preprocessed source.

Full log in:
https://buildd.debian.org/status/fetch.php?pkg=openorienteering-mapper=sparc64=0.9.5-1=1633120814=0

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #15 from John Paul Adrian Glaubitz  ---
(In reply to Giulio Benetti from comment #14)
> This bug still shows up in gcc version 9.x and 11.x. But not on version 10.x
> I've found the simple work-around to disable the optimization(override
> CFLAGS with -O0) and it works.

That removes too many optimizations. As explained in comment 5 [1], it should
be enough to add "-freorder-blocks-algorithm=simple" instead of just removing
all optimizations.

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143#c5

[Bug other/93090] RFE: Add a frontend for the Rust programming language

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
(In reply to David Malcolm from comment #4)
> FWIW there's also:
>   https://github.com/antoyo/rustc_codegen_gcc
> which isn't a GCC Rust frontend per se, but uses libgccjit to embed GCC as a
> code generation backend inside the existing rustc compiler (I'm the
> author/maintainer of libgccjit, and a fan of both approaches).

Yes, it's being merged here: https://github.com/rust-lang/rust/pull/87260

The frontend that will most likely make it into GCC is probably gccrs given the
fact that it's receiving commercial backing.

> https://github.com/Rust-GCC/gccrs

[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
FWIW, it seems the situation seems to be the same on 32-bit SPARC:

> https://reviews.llvm.org/D98575#2947973

So, I guess the suggested solution would be the one from Comment 7.

[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #32 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #31)
> Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS.
> 
> Are the builtin_traps() optimized out for -O2?
> 
> I'm building with the correct flags now.

Traps also didn't trigger with -O1 and -fno-cross-jumping.

[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #31 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #30)
> Created attachment 50717 [details]
> Build log for ruby 2.5 with Oleg's patch applied

Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS.

Are the builtin_traps() optimized out for -O2?

I'm building with the correct flags now.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #55 from John Paul Adrian Glaubitz  ---
(In reply to abebeos from comment #54)
> Now, there is a strange tendency within this project to completely ignore my
> work on this issue/bounty and my person, see e.g. here:

You have no claim in this whole effort. You just tried to copy someone else's
work.

[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #30 from John Paul Adrian Glaubitz  ---
Created attachment 50717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50717=edit
Build log for ruby 2.5 with Oleg's patch applied

[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #29 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #28)
> Adrian, could please apply the following patch to the original string.c file
> and try building & running the whole thing again with the original compiler
> flags, with -fno-cross-jumping and with -O1.  Does one of the added traps go
> off?
> 
> 
> --- "orig ng/string.c.orig"   2019-10-01 20:02:30.0 +0900
> +++ "orig ng/string.c"2020-02-22 18:29:54.904783490 +0900
> @@ -446,13 +446,15 @@
>  # define NONASCII_MASK 0x80808080UL
>  #endif
>  
> +if ( (intptr_t)(e-p) < 0) __builtin_trap ();
> +
>  if (UNALIGNED_WORD_ACCESS || e - p >= SIZEOF_VOIDP) {
>  #if !UNALIGNED_WORD_ACCESS
>   if ((uintptr_t)p % SIZEOF_VOIDP) {
>   int l = SIZEOF_VOIDP - (uintptr_t)p % SIZEOF_VOIDP;
>   p += l;
>   switch (l) {
> -   default: UNREACHABLE;
> +   default: __builtin_trap ();
>  #if SIZEOF_VOIDP > 4
> case 7: if (p[-7]&0x80) return p-7;
> case 6: if (p[-6]&0x80) return p-6;
> @@ -481,7 +483,7 @@
>  }
>  
>  switch (e - p) {
> -  default: UNREACHABLE;
> +  default: __builtin_trap ();
>  #if SIZEOF_VOIDP > 4
>case 7: if (e[-7]&0x80) return e-7;
>case 6: if (e[-6]&0x80) return e-6;

I did not see any of the traps fire. With the patch applied, it builds fine and
the Ruby interpreter doesn't crash. I'll attach the full build log.

Without the patch, Ruby crashes, even with the latest gcc-10 version (didn't
test gcc-11 yet as gcc-10 is currently the default for Debian unstable).

[Bug target/93808] [9/10/11/12 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #28 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #27)
> Adrian, any results?  (I just assume GCC 11 and trunk are affected now)

Not yet. I'll try to remember it this weekend.

[Bug lto/98504] [11 Regression] bootstrap broken in libgo on ia64-linux-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #5)
> Matthias, what's the state on current trunk?

I can test this for Matthias on my own machine as the new ia64 porterbox that
we set up in Debian is currently having connection issues with the LDAP
database.

I will try to get the machine fixed over the weekend.

[Bug other/93090] RFE: Add a frontend for the Rust programming language

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
It seems that the gccrs frontend is now sponsored by two companies, so I think
it's fine to stop the Bountysource campaign [1] and move the money to other
Bountysource campaigns.

> [1] https://rust-gcc.github.io/

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to Arnaud Charlet from comment #9)
> The problem is somehow specific to m68k, for some unknown reason. There is
> nothing target specific in the change, no assumption is made on the
> underlying target.
> 
> What we need now is a debugging session from someone who has a setup to
> reproduce.

See here on how to set up a qemu environment:
https://wiki.debian.org/M68k/QemuSystemM68k

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Arnaud Charlet from comment #7)
> In other words, the bisect result isn't very useful here and I'd recommend
> investigating this change from scratch, getting a useful backtrace from gdb
> and understanding where this is crashing and then why.

I can certainly generate a backtrace in GDB, but I'm not an Ada expert which is
why I reported the issue and hoped that the author of the change would be able
to understand what the problem is.

It could also be possible that the change makes some assumptions of the
underlying ABI that may well be true for x86_64 but not m68k.

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
(In reply to Mikael Pettersson from comment #5)
> My git bisect landed on this commit too.

I just pinged Justin again. He unfortunately doesn't seem to have a Bugzilla
account, so we can't add him in the CC list of this bug report.

[Bug go/98511] [11 Regression]: Go build fails on sparc64 with "error: reference to undefined name 'SYS_SETRESGID'"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Andreas Schwab from comment #1)
> dup
> 
> *** This bug has been marked as a duplicate of bug 98510 ***

Odd, I even searched for the error message before reporting.

[Bug go/98511] New: [11 Regression]: Go build fails on sparc64 with "error: reference to undefined name 'SYS_SETRESGID'"

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 98511
   Summary: [11 Regression]: Go build fails on sparc64 with
"error: reference to undefined name 'SYS_SETRESGID'"
   Product: gcc
   Version: 11.0
   URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna
pshot=sparc64=1%3A20210102-1=1609701438
=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: glaubitz at physik dot fu-berlin.de
CC: cmang at google dot com, ian at airs dot com, jrtc27 at 
jrtc27 dot com,
matorola at gmail dot com
  Target Milestone: ---

Building trunk on Linux/sparc64 with Go enabled fails with:

libtool: compile:  /<>/build/./gcc/gccgo
-B/<>/build/./gcc/ -B/usr/lib/gcc-snapshot/sparc64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sparc64-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sparc64-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sparc64-linux-gnu/sys-include -O2 -g -m32 -I . -c
-fgo-pkgpath=syscall ../../../../src/libgo/go/syscall/dirent.go
../../../../src/libgo/go/syscall/endian_big.go
../../../../src/libgo/go/syscall/env_unix.go
../../../../src/libgo/go/syscall/errstr_glibc.go
../../../../src/libgo/go/syscall/exec_linux.go
../../../../src/libgo/go/syscall/exec_unix.go
../../../../src/libgo/go/syscall/libcall_glibc.go
../../../../src/libgo/go/syscall/libcall_linux.go
../../../../src/libgo/go/syscall/libcall_linux_utimesnano.go
../../../../src/libgo/go/syscall/libcall_posix.go
../../../../src/libgo/go/syscall/libcall_posix_largefile.go
../../../../src/libgo/go/syscall/libcall_posix_nonhurd.go
../../../../src/libgo/go/syscall/libcall_support.go
../../../../src/libgo/go/syscall/libcall_uname.go
../../../../src/libgo/go/syscall/libcall_wait4.go
../../../../src/libgo/go/syscall/lsf_linux.go
../../../../src/libgo/go/syscall/msan0.go
../../../../src/libgo/go/syscall/net.go
../../../../src/libgo/go/syscall/netlink_linux.go
../../../../src/libgo/go/syscall/setuidgid_linux.go
../../../../src/libgo/go/syscall/sleep_select.go
../../../../src/libgo/go/syscall/sock_cloexec_linux.go
../../../../src/libgo/go/syscall/sockcmsg_linux.go
../../../../src/libgo/go/syscall/sockcmsg_unix.go
../../../../src/libgo/go/syscall/sockcmsg_unix_other.go
../../../../src/libgo/go/syscall/socket.go
../../../../src/libgo/go/syscall/socket_linux.go
../../../../src/libgo/go/syscall/socket_linux_type.go
../../../../src/libgo/go/syscall/socket_posix.go
../../../../src/libgo/go/syscall/str.go
../../../../src/libgo/go/syscall/syscall.go
../../../../src/libgo/go/syscall/syscall_errno.go
../../../../src/libgo/go/syscall/syscall_funcs.go
../../../../src/libgo/go/syscall/syscall_glibc.go
../../../../src/libgo/go/syscall/syscall_linux.go
../../../../src/libgo/go/syscall/syscall_unix.go
../../../../src/libgo/go/syscall/time_nofake.go
../../../../src/libgo/go/syscall/timestruct.go libcalls.go sysinfo.go
syscall_arch.go syscall_linknames.go epoll.go  -fPIC -o .libs/syscall.o
../../../../src/libgo/go/syscall/setuidgid_linux.go:19:25: error: reference to
undefined name 'SYS_SETRESGID'
   19 | sys_SETRESGID = SYS_SETRESGID
  | ^
../../../../src/libgo/go/syscall/setuidgid_linux.go:20:25: error: reference to
undefined name 'SYS_SETRESUID'
   20 | sys_SETRESUID = SYS_SETRESUID
  | ^

Full log in:
https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=sparc64=1%3A20210102-1=1609701438=0

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #14 from John Paul Adrian Glaubitz  ---
Quick update. The bug actually occurs with "--disable-bootstrap" which is how
Matthias Klose configures gcc when building the gcc-snapshot package. Removing
the configure flag makes the bootstrap succeed.

So my guess is that the system compiler is miscompiling stage1 which then fails
to build libstdc++ and only the stage2(3?) compiler works properly.

Guess we can mark this PR as invalid then?

PS: Happy New Year!

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Jeffrey A. Law from comment #12)
> On 12/30/20 10:30 AM, glaubitz at physik dot fu-berlin.de wrote:
> > Is that a native bootstrap on qemu with "jit" enabled?
>
> native bootstrap with qemu.  Don't offhand remember if jit is enabled. 
> If not I can probably turn that on for the next one.

Yes, that would be very helpful. I'll check whether enabling jit is actually
triggering it.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to Jeffrey A. Law from comment #10)
> So if that bisection is accurate, the only way this could be failing would
> be if something with a deprecated attribute is being used.
> 
> Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised
> by the bisection results.

I have verified it. I checked out eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3,
reproduced the problem. Then reverted the change and it worked again.

I honestly don't understand either how that commit could break the build.

> http://3.14.90.209:8080/job/m68k-linux-gnu/
> 
> Has the most recent build results from my tester.  As you can see everything
> built and regression tested on Dec 9.  Dec 15 had a successful bootstrap,
> but glibc failed due to a relatively minor bug in glibc.

Is that a native bootstrap on qemu with "jit" enabled?

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
I have bisected this now and it turns out, the regression was introduced by:

commit eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3
Author: Nick Clifton 
Date:   Mon Jun 18 10:39:01 2018 +

Ensure that control characters in user supplied error and warning messages
are escaped.

PR 84195
* tree.c (escaped_string): New class.  Converts an unescaped
string into its escaped equivalent.
(warn_deprecated_use): Use the new class to convert the
deprecation message, if present.
(test_escaped_strings): New self test.
(test_c_tests): Add test_escaped_strings.

From-SVN: r261697

Interestingly, later SVN/git revisions still built fine, with 20191130 being
the last good one:

> https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot=m68k

I am building with the following command line:

../configure --with-gcc-major-version-only --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --enable-clocale=gnu
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto
--enable-multiarch --disable-werror --disable-werror --disable-multilib
--enable-checking=yes --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu --enable-languages=c++,jit --enable-host-shared
--disable-bootstrap && make -j64

from git. No local Debian patches applied.

My suspicion is that either this change triggers a bug in some external library
or a change in an external library made this bug visible.

Any suggestions? The only thing that it's odd on m68k is the 16-bit native
alignment, but I'm not sure whether that's relevant here.

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
This regression was introduced by:

commit d7e20130650fb46d71e0403652e4e07bc14f9775 (refs/bisect/bad)
Author: Justin Squirek 
Date:   Mon Aug 10 12:05:07 2020 -0400

[Ada] Reimplementation of accessibility checking

[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
I have started to bisect this now. aa80d0650ce612d88a62d072b63c2523d547fca8 is
still good while HEAD is broken.

It will take a while until I have a result as I have to perform this bisecting
on qemu-user.

[Bug target/98382] [m68k] ICE: in output_move_qimode, at config/m68k/m68k.c:3284 when building webkit2gtk

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to Mikael Pettersson from comment #2)
> Are you sure about the "recently"? I get ICEs with crosses based on
> gcc-11-20201213, gcc-10.2.0, gcc-10.1.0, and gcc-9-20201218 (so pre-CC0
> conversion).

webkit2gtk buildt fine with gcc-10_10.2.0 on Debian:

> https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=m68k=2.28.4-1=1597349482=0

> A reduced test case would help.

I have been asked to do that for another PR as well but I haven't done this
before so it'll take some time until I will be able to provide reduced
testcases.