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

2024-10-07 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #386 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #374)
> Created attachment 59286 [details]
> a patch for c#367
> 
> We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> subreg in 59190.  Looks this confuses LRA with the SI mode scratch
> constrained to "y".
> 
> The patch uses a new pattern instead of movsf_ie.  It's a mini movsf_ie in a
> sense but with the SFmode scratch.
> 
> Tested only with target libgcc/libstdc++v3 build and c testsuite.

I can confirm that patch 59286 fixes the ICE from comment #367 for me.

Currently, I'm using the sh-lra-take3 branch with the patches 59216, 59219 and
59286 which works best so far for all my tests, including WebKit.

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

2024-10-06 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #380 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> Will test Kaz's patch seprately applied to sh-lra-take3.

This bootstraps fine (tested without Go and Rust). So, it's an issue with
Oleg's tree.

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

2024-10-06 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #378 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #375)
> (In reply to Kazumoto Kojima from comment #374)
> > Created attachment 59286 [details]
> > a patch for c#367
> > 
> > We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> > subreg in 59190.  Looks this confuses LRA with the SI mode scratch
> > constrained to "y".
> > 
> > The patch uses a new pattern instead of movsf_ie.  It's a mini movsf_ie in a
> > sense but with the SFmode scratch.
> > 
> > Tested only with target libgcc/libstdc++v3 build and c testsuite.
> 
> I've updated my branch https://github.com/olegendo/gcc/commits/devel/sh-lra/
> 
> * Merged the patch from comment #374 into the commit "SH: Try to workaround
> fp-reg related move insns pt.2".
> 
> * Tidied up the other patches on the stash a bit (add/fix commit messages,
> ..)
> 
> * The patch "SH: Tighten memory predicates and constraints" now seems to
> work without LRA.  At least the testsuite on sh-sim for the common variants
> shows no new failures.  My plan is to merge this commit into mainline soon,
> as a start.
> 
> Briefly confirmed that the previous problematic cases mentioned here still
> work with it (will add them to the testsuite eventually).  Also confirmed
> that sh-elf / newlib toolchain and target libs can build OK.  Testsuite
> results pending.  Hope I didn't miss anything, please re-confirm if you have
> a chance.

I just tried a full bootstrap using that tree with all languages but Rust and
Go enabled and it fails with:

during RTL pass: subreg3
../../gcc/ipa-sra.cc: In function 'void
{anonymous}::isra_read_edge_summary(lto_input_block*, cgraph_edge*)':
../../gcc/ipa-sra.cc:2933:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1731
 2933 | }
  | ^
/home/glaubitz/gcc-oleg/build/./prev-gcc/xg++
-B/home/glaubitz/gcc-oleg/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -nostdinc++
-B/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/include/sh4-unknown-linux-gnu

-I/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/include
 -I/home/glaubitz/gcc-oleg/libstdc++-v3/libsupc++
-L/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/glaubitz/gcc-oleg/build/prev-sh4-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fPIC -c   -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings  -DHAVE_CONFIG_H -fPIC -I. -Irtl-ssa -I../../gcc
-I../../gcc/rtl-ssa -I../../gcc/../include  -I../../gcc/../libcpp/include
-I../../gcc/../libcody  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
-o rtl-ssa/functions.o -MT rtl-ssa/functions.o -MMD -MP -MF
rtl-ssa/.deps/functions.TPo ../../gcc/rtl-ssa/functions.cc
0x3560f93 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x35261e3 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1512
0x32a5bcf decompose_multiword_subregs
../../gcc/lower-subreg.cc:1731
0x32a625f execute
../../gcc/lower-subreg.cc:1894
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

Will test Kaz's patch seprately applied to sh-lra-take3.

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

2024-10-03 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #370 from John Paul Adrian Glaubitz  ---
I can also confirm that Kaz' sh-lra-take3 branch fixes the build of Python 3.13
which fails to build with the usual register starving problem from PR81426:

> https://buildd.debian.org/status/fetch.php?pkg=python3.13&arch=sh4&ver=3.13.0%7Erc3-1&stamp=1727979616&raw=0

Shall I create a separate bug report for comment #367? Is that maybe a generic
problem with LRA and not SH-specific?

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

2024-10-01 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #368 from John Paul Adrian Glaubitz  ---
Created attachment 59264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59264&action=edit
Preprocessed source from from comment #367

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

2024-10-01 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #367 from John Paul Adrian Glaubitz  ---
I just tried building a slightly older version of WebKit and ran into a new ICE
with Kaz' sh-lra-take3 branch:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DBUILDING_WebCore -DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1
-DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 -DSTATICALLY_LINKED_WITH_PAL
-DUSE_SYSTEM_EGL -I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/build-soup3
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/build-soup3/WebCore/DerivedSources
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/ShapeDetection
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/ShapeDetection/Interfaces
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/WebGPU
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/WebGPU/InternalAPI
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/WebGPU/Implementation
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/airplay
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/applepay
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/applepay/paymentrequest
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/applicationmanifest
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/async-clipboard
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/audiosession
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/badge
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/beacon
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/cache
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/compression
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/contact-picker
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/cookie-consent
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/cookie-store
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/credentialmanagement
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/encryptedmedia
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/encryptedmedia/legacy
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/entriesapi
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/fetch
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/filesystemaccess
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/geolocation
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/highlight
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/indexeddb
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/indexeddb/client
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/indexeddb/server
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/indexeddb/shared
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediacapabilities
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediacontrols
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediarecorder
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediasession
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediasource
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/mediastream
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/model-element
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/model-element/dummy
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/navigatorcontentutils
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/notifications
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/paymentrequest
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/permissions
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/pictureinpicture
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/plugins
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/push-api
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/remoteplayback
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/reporting
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/screen-wake-lock
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/speech
-I/home/glaubitz/webkit-2.44.4/webkit2gtk-2.44.4/Source/WebCore/Modules/storage
-I/home/glaubitz/webkit-2.44.4/webkit

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #363 from John Paul Adrian Glaubitz  ---
I'm currently unable to continue with WebKit because GCC runs out of memory
trying to compile one of the larger source files. I am therefore going to pause
here.

Since there have been several branch updates now, can you point me to the
latest branch that is currently most likely to be merged upstream? Then I'll
give this another try and verify there are no regressions after the latest
changes.

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #358 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #357)
> (In reply to Andrew Pinski from comment #356)
> > Can you file a seperate bug for this since I think it is a generic IPA issue
> > ratehr than specific to sh?
> 
> I will file it seperately since I can reproduce it on x86_64 (with -m32).

Ah, you were faster than me, I just came back from the pub ;-).

Can you post the link?

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #355 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #352)
> I will try to figured out what optimization flag triggered the ICE. Also, I
> will provide the preprocessed source in the next comment as usual.

It's -findirect-inlining, removing the flag from an otherwise -O1 command line
causes the ICE.

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #353 from John Paul Adrian Glaubitz  ---
Created attachment 59235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59235&action=edit
Preprocessed source from from comment #352

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #352 from John Paul Adrian Glaubitz  ---
Since I'm unable to build WebKit with -O2 due to memory constraints, I'm
building with -O1 now. This unfortunately triggered another ICE which does not
show with -O2:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-real/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g0 -O1 -ffile-prefix-map=/home/glaubitz/webkit2gtk-real/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 --param ggc-min-expand=10
-DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/gpu/ganesh/ops/GrOvalOpFactory.cpp.o
-MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/gpu/ganesh/ops/GrOvalOpFactory.cpp.o.d
-o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/gpu/ganesh/ops/GrOvalOpFactory.cpp.o
-c
/home/glaubitz/webkit2gtk-real/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/gpu/ganesh/ops/GrOvalOpFactory.cpp
/home/glaubitz/webkit2gtk-real/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/gpu/ganesh/ops/GrOvalOpFactory.cpp:
In member function 'virtual void
EllipticalRRectOp::onPrepareDraws(GrMeshDrawTarget*)':
/home/glaubitz/webkit2gtk-real/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/gpu/ganesh/ops/GrOvalOpFactory.cpp:3046:10:
error: invalid calls_comdat_local flag
 3046 | void onPrepareDraws(GrMeshDrawTarget* target) override {
  |  ^~
_ZN17EllipticalRRectOp14onPrepareDrawsEP16GrMeshDrawTarget/8902 (virtual void
EllipticalRRectOp::onPrepareDraws(GrMeshDrawTarget*))
  Type: function definition analyzed
  Visibility: externally_visible semantic_interposition public weak comdat
comdat_group:_ZN17EllipticalRRectOp14onPrepareDrawsEP16GrMeshDrawTarget
one_only visibility:hidden virtual
  Same comdat group as:
_ZN5skgpuL33skgpu_init_static_unique_key_onceEP18SkAlignedSTStorageILi1ENS_9UniqueKeyEE/4008
  Address is taken.
  References: 
  Referring: _ZTV17EllipticalRRectOp/13231 (addr) 
  Availability: available
  Function flags: count:37098082 (estimated locally) body
  Called by: 
  Calls: __builtin_unreachable/15832 (18579353 (estimated locally),0.50 per
call) __memcpy_chk/14913 (858993456 (estimated locally),23.15 per call)
__builtin_object_size/14912 (858993456 (estimated locally),23.15 per call)
__memcpy_chk/14913 (283467839 (estimated locally),7.64 per call)
__builtin_object_size/14912 (283467839 (estimated locally),7.64 per call)
__memcpy_chk/14913 (283467839 (estimated locally),7.64 per call)
__builtin_object_size/14912 (283467839 (estimated locally),7.64 per call)
__memcpy_chk/14913 (283467839 (estimated locally),7.64 per call)
__builtin_object_size/14912 (283467839 (estimated locally),7.64 per call)
__memcpy_chk/14913 (283467839 (estimated locally),7.64 per call)
__builtin_object_size/14912 (283467839 (estimated locally),7.64 per call)
__memcpy_chk/14913 (858993456 (estimated locally),23.15 per call)
__builtin_object_size/14912 (858993456 (estimated locally),23.15 per call)
__memcpy_chk/14913 (858993456 (estimated locally),23.15 per call)
__builtin_object_size/14912 (858993456 (estimated locally),23.15 per call)
__memcpy_chk/14913 (858993456 (estimated locally),23.15 per call)
__builtin_object_size/14912 (858993456 (estimated locally),23.15 per call)
__memcpy_chk/14913 (858993456 (estimated locally),23.15 per call)
__builtin_object_size/14912 (858993456 (estimated locally),23.15 per call)
__memcpy_chk/14913 (858993456 (estimated locally),23.15 per

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

2024-09-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #351 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #344)
> Created attachment 59219 [details]
> a patch for c#339
> 
> This adds checks if the address register of the memory displacement is
> general or pseudo.  Tested target libgcc and libstdc++v3 build and c
> testsuilte.

Thanks, this patch fixes the problem for me and also doesn't introduce any new
regressions although I have not tested Go yet.

I am currently test-building WebKit with this GCC and it's taking quite long,
so please don't be surprised that I'm taking a little longer to report back.

I ran into an out-of-memory issue in the mean time, so I'll have to start from
scratch with reduced debug settings.

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

2024-09-28 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #340 from John Paul Adrian Glaubitz  ---
The compressed preprocessed source is larger than usual and the complete
archive exceeds the maximum file limit for Bugzilla, so I have uploaded the
preprocessed source for comment #339 here:

> http://people.debian.org/~glaubitz/pr-55212-339.tgz

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

2024-09-28 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #339 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #335)
> (In reply to Kazumoto Kojima from comment #334)
> > Created attachment 59216 [details]
> > a patch to fix ICE in c#331
> > 
> > The patch preallocates R0 for those Sid memory patterns so as to shorten the
> > live range of R0.  Tested target libgcc and libstdc++v3 build and c
> > testsuilte only.
> 
> Thanks a lot. I'll give it a try.
> 
> FWIW, the backend has improved quite a lot over the past weeks. The
> Dreamcast people reported good results as well!

I can confirm that the patch from comment #334 fixes the problem and the build
of WebKit now proceeds much further than it used to in the past for a long
time.

I have not observed any more issues with register spilling, but it seems that I
have uncovered a miscompilation bug which leads to the generation of invalid
assembler:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKitGTK-4.1\"
-DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS
-DPAS_BMALLOC=1 -DSTATICALLY_LINKED_WITH_WTF
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/Headers
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/API
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/assembler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/b3
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/b3/air
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bindings
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/builtins
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bytecode
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/bytecompiler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/dfg
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler/ARM64
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/disassembler/zydis/Zydis
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/domjit
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/ftl
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/fuzzilli
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/heap
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/debugger
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/agents
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/augmentable
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/inspector/remote
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/interpreter
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/jit
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/llint
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/parser
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/profiler
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/runtime
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/tools
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/wasm
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/wasm/js
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/yarr
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/inspector
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/runtime
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCore/DerivedSources/yarr
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/Source/JavaScriptCore/API/glib
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCoreGLib/DerivedSources
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/JavaScriptCoreGLib/DerivedSources/jsc
-I/home/glaubitz/webkit2gtk-sh4-new-new/webkit2gt

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

2024-09-27 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #335 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #334)
> Created attachment 59216 [details]
> a patch to fix ICE in c#331
> 
> The patch preallocates R0 for those Sid memory patterns so as to shorten the
> live range of R0.  Tested target libgcc and libstdc++v3 build and c
> testsuilte only.

Thanks a lot. I'll give it a try.

FWIW, the backend has improved quite a lot over the past weeks. The Dreamcast
people reported good results as well!

[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra

2024-09-27 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464

--- Comment #9 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #8)
> (In reply to John Paul Adrian Glaubitz from comment #6)
> > (In reply to Oleg Endo from comment #5)
> > > I'm not sure this is an acceptable solution.  It disables various other
> > > optimizations and reduces in worse code than normally should be.  When you
> > > rebuild all of debian with LRA enabled, please make sure to take out any
> > > such hacks.
> > 
> > It's not a solution, it was a work-around.
> > 
> > FWIW, I have tried to build the package with the gcc-10 package from Debian
> > (which is a recent snapshot) and -mlra, but so far cmake doesn't want to
> > accept gcc-10 as the build compiler when set with export CC/CXX, so I have
> > to poke around what the problem is.
> > 
> > I will report back once I have a result.
> 
> Adrian, could you please re-check this issue with latest version of
> https://github.com/olegendo/gcc/tree/devel/sh-lra ?

I just gave it a quick try and I can no longer reproduce the issue. qtwebkit
builds fine with a LRA-enabled gcc-15 using Kaz' sh-lra-take3 branch.

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

2024-09-27 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #332 from John Paul Adrian Glaubitz  ---
Created attachment 59212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59212&action=edit
Preprocessed source from from comment #331

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

2024-09-26 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #331 from John Paul Adrian Glaubitz  ---
I found another failure when building webkit2gtk with the branch sh-lra-take3:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 --param ggc-min-expand=10
-DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkDistanceFieldGen.cpp.o
-MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkDistanceFieldGen.cpp.o.d
-o Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkDistanceFieldGen.cpp.o
-c
/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp
/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp:
In function 'bool generate_distance_field_from_image(unsigned char*, const
unsigned char*, int, int ':
/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp:476:1:
error: unable to find a register to spill
  476 | }
  | ^
/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp:476:1:
error: this is the insn:
(insn 483 2240 2241 63 (parallel [
(set (mem:SF (plus:SI (reg/f:SI 1177 [orig:903 _693 ] [903])
(reg:SI 1312 [orig:498 ivtmp.265 ] [498])) [70
MEM[(float *)_693 + ivtmp.265_674 * 1]+0 S4 A32])
(reg:SF 1313))
(use (reg:SI 154 fpscr0))
])
"/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp":197:35
222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 1313)
(expr_list:REG_DEAD (reg:SI 1312 [orig:498 ivtmp.265 ] [498])
(nil
during RTL pass: reload
/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkDistanceFieldGen.cpp:476:1:
internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868
0x2b7c113f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x2b7c1223 __libc_start_main_impl
./csu/libc-start.c:360
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.

Interestingly, it does not fail with -mno-lra:

(unstable-sh4-sbuild)glaubitz@adams:~/webkitg2k-vanilla/webkit2gtk-2.46.0/build-soup3$
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkitg2k-vanilla/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-over

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

2024-09-25 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #328 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
> 
> This also reverts the change in c#312 and gives another fix for that issue.
> Tested only with target libgcc/libstdc++v3 build and c testsuite.
> I've updated sh-lra-take3 branch with this change.

I can confirm that this patch fixes the problem reported in comment #318.

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #327 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
> 
> This also reverts the change in c#312 and gives another fix for that issue.
> Tested only with target libgcc/libstdc++v3 build and c testsuite.
> I've updated sh-lra-take3 branch with this change.

Thanks, testing this now.

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #321 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #320)
> Full command line is:
> 
> /home/glaubitz/gcc-kaz/build/./gcc/xgcc
> -B/home/glaubitz/gcc-kaz/build/./gcc/
> -B/usr/local/sh4-unknown-linux-gnu/bin/
> -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
> /usr/local/sh4-unknown-linux-gnu/include -isystem
> /usr/local/sh4-unknown-linux-gnu/sys-include-c -g -O2  -fpic -fno-lto 
> -W -Wall -gnatpg -nostdinc   a-nscefu.ads -o a-nscefu.o
> 
> which is run from the build/gcc/ada/rts subfolder. The problem goes away
> with -O0 or -mno-lra.

Adding -fno-split-wide-types to the command line fixes the problem.

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #320 from John Paul Adrian Glaubitz  ---
Full command line is:

/home/glaubitz/gcc-kaz/build/./gcc/xgcc -B/home/glaubitz/gcc-kaz/build/./gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/
-isystem /usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include-c -g -O2  -fpic -fno-lto  -W
-Wall -gnatpg -nostdinc   a-nscefu.ads -o a-nscefu.o

which is run from the build/gcc/ada/rts subfolder. The problem goes away with
-O0 or -mno-lra.

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #319 from John Paul Adrian Glaubitz  ---
Created attachment 59188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59188&action=edit
Preprocessed source from from comment #318

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #318 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #317)
> Thanks. I'm going to test this now. It seems that the untested patch from
> comment #312 didn't fix the Ada bootstrap for me.

The issue unfortunately persists:

a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 499 [orig:184 _24 ] [184])
(reg:SF 513))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 513)
(nil)))
during RTL pass: reload

I'll try to get the preprocessed source.

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

2024-09-24 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #317 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks to try and test the GCC LRA branch
> > with some bigger real-world software.  For that we need to have a "known
> > good state" of a branch on github.
> 
> I've pushed the sfunc patch with lengthy sfunc patterns using
> hard_reg_r[456] + the patch in c#312 on the top of
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git.  Hope this
> helps.

Thanks. I'm going to test this now. It seems that the untested patch from
comment #312 didn't fix the Ada bootstrap for me.

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

2024-09-23 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #313 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #312)
> (In reply to John Paul Adrian Glaubitz from comment #298)
> > Here is one ICE I have run into while building webkit2gtk with the latest
> > patches on top of an older GCC snapshot:
> 
> Although not tested well,
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index a2b2130d166..d9e7e67cba6 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -11465,11 +11462,15 @@ sh_movsf_ie_y_split_p (rtx op0, rtx op1)
>  {
>/* f, r */
>if (REG_P (op0)
> -  && (SUBREG_P (op1) && GET_MODE (SUBREG_REG (op1)) == SImode))
> +  && (SUBREG_P (op1)
> +   && (GET_MODE (SUBREG_REG (op1)) == SImode
> +   || GET_MODE (SUBREG_REG (op1)) == DImode)))
>  return true;
>/* r, f */
>if (REG_P (op1)
> -  && (SUBREG_P (op0) && GET_MODE (SUBREG_REG (op0)) == SImode))
> +  && (SUBREG_P (op0)
> +   && (GET_MODE (SUBREG_REG (op0)) == SImode
> +   || GET_MODE (SUBREG_REG (op0)) == DImode)))
>  return true;
>  
>return false;
> 
> fixes the ICE for the original and reduced test case 59185 here.

Thanks, trying this now. FWIW, all the other languages are not affected by this
ICE.

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

2024-09-23 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #310 from John Paul Adrian Glaubitz  ---
Hmm, I just realized I performed the tests without enabling LRA by default. I
just noticed that because with LRA enabled, Ada actually fails with:

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-teioed.adb -o a-teioed.o
/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-textio.adb -o a-textio.o
/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-tgdico.ads -o a-tgdico.o
/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fchecking=1 -c -g -O2  -fpic
-fno-lto  -W -Wall -gnatpg -nostdinc   a-tiboio.adb -o a-tiboio.o
a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 499 [orig:184 _24 ] [184])
(reg:SF 513))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 513)
(nil)))
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 15.0.0 20240922 (experimental) (sh4-linux-gnu) GCC error:|
| in lra_split_hard_reg_for, at lra-assigns.cc:1868|
| Error detected around a-ngcefu.adb:177:8 |
| Compiling a-ncelfu.ads   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

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

system.ads
a-ncelfu.ads
a-numeri.ads
ada.ads
a-nucoty.ads
a-ngcoty.ads
a-ngcefu.ads
s-exctab.ads
s-stalib.ads
a-unccon.ads
a-ngcefu.adb
a-ngelfu.ads
a-except.ads
s-parame.ads
s-traent.ads
s-fatflt.ads
s-fatgen.ads
a-ngelfu.adb
a-nagefl.ads
a-nallfl.ads
a-naliop.ads
a-nalofl.ads
a-nuaufl.ads
a-nashfl.ads
s-exnflt.ads
s-exponr.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412
make[9]: *** [../gcc-interface/Makefile:303: a-ncelfu.o] Error 1
make[9]: *** Waiting for unfinished jobs
a-ngcefu.adb: In function
'Ada.Numerics.Short_Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 499 [orig:184 _24 ] [184])
(reg:SF 513))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 513)
(nil)))
during RTL pass: reload
+===GNAT BUG DETECTED==+
| 15.0.0 20240922 (experimental) (sh4-linux-gnu) GCC error:|
| in lra_split_hard_reg_for, at lra-assigns.cc:1868|
| Error detected around a-ngcefu.adb:177:8 |
| Compiling a-nscefu.ads   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files wi

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

2024-09-22 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #307 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #306)
> (In reply to John Paul Adrian Glaubitz from comment #301)
> > I can confirm that I can successfully perform a full native bootstrap with
> > the following languages enabled:
> > 
> > - c,c++,fortran,objc,obj-c++,m2
> > 
> > There were no segfaults or comparison failures either.
> > 
> > I can also confirm that this branch fixes the problems reported in comment
> > #271, comment #273 and comment #298.
> > 
> > Last will be verifying that Go and Ada still work.
> > 
> > This is a huge step forward so far. Congratulations!
> 
> Ada and Go work fine, too. Let me test lto and jit.

LTO and JIT build without issues, too.

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

2024-09-22 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #306 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #301)
> I can confirm that I can successfully perform a full native bootstrap with
> the following languages enabled:
> 
> - c,c++,fortran,objc,obj-c++,m2
> 
> There were no segfaults or comparison failures either.
> 
> I can also confirm that this branch fixes the problems reported in comment
> #271, comment #273 and comment #298.
> 
> Last will be verifying that Go and Ada still work.
> 
> This is a huge step forward so far. Congratulations!

Ada and Go work fine, too. Let me test lto and jit.

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

2024-09-21 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #301 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #292)
> (In reply to Kazumoto Kojima from comment #289)
> > I've reconstructed patches as follows:
> > 
> > [59157] a revised patch to movsf issue which splits movesf_ie_ra
> > [59158] a revised patch to QIHI extend/move
> > [59159] a revised workaround sfunc issue
> > [59153] Alex's patch works magically for call_pcrel* issue.
> > 
> > I've also created sh-lra-take2 branch of 
> > https://github.com/kazkojima/gcc.git
> > with these patches for the reference.
> 
> OK, I'm trying this branch now. I assume I won't need any other patches.

I can confirm that I can successfully perform a full native bootstrap with the
following languages enabled:

- c,c++,fortran,objc,obj-c++,m2

There were no segfaults or comparison failures either.

I can also confirm that this branch fixes the problems reported in comment
#271, comment #273 and comment #298.

Last will be verifying that Go and Ada still work.

This is a huge step forward so far. Congratulations!

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

2024-09-21 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #299 from John Paul Adrian Glaubitz  ---
Created attachment 59169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59169&action=edit
Preprocessed source from from comment #298

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

2024-09-21 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #298 from John Paul Adrian Glaubitz  ---
Here is one ICE I have run into while building webkit2gtk with the latest
patches on top of an older GCC snapshot:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o.d -o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkCubicMap.cpp.o -c
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp
 
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:
In constructor 'SkCubicMap::SkCubicMap(SkPoint, SkPoint)':
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: unable to find a register to spill
  106 | }
  | ^
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
error: this is the insn:
(insn 34 307 35 8 (parallel [
(set (reg:SF 170 [ prephitmp_18 ])
(reg:SF 335))
(use (reg:SI 154 fpscr0))
]) "/usr/lib/gcc-snapshot/include/c++/15/bits/stl_algobase.h":262:15
222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 335)
(nil)))
during RTL pass: reload
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkCubicMap.cpp:106:1:
internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868
0x2b7c113f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x2b7c1223 __libc_start_main_impl
./csu/libc-start.c:360
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.

I am going to retest this with Kaz's tree which I am currently building.

While provide the preprocessed source in a follow-up comment.

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

2024-09-20 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #292 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #289)
> I've reconstructed patches as follows:
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59159] a revised workaround sfunc issue
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
> with these patches for the reference.

OK, I'm trying this branch now. I assume I won't need any other patches.

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

2024-09-20 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #290 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #263)
> Created attachment 59132 [details]
> a patch rewriting movsh_ie_ra
> 
> This patch splits movsf_ie_ra into several new patterns to remove
> match_scratch.  Also define a new sub-pattern of movdf for constant loads.
> 
> * gcc/config/sh/predicates.md (pc_relative_load_operand):
> New predicate.
> * gcc/config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): Remove.
> (sh_movsf_ie_y_split_p): New proto.
> * gcc/config/sh/sh.cc: (sh_movsf_ie_ra_split_p): Remove.
> (sh_movsf_ie_y_split_p): New function.
> * gcc/config/sh/sh.md (movdf_i4_F_z): New insn pattern.
> (movdf): Use it.
> (movsf_ie_ra): Use define_insn instead of define_insn_and_split.
> (movsf_ie_F_z): Rename from movsf_ie_const_ra.
> (movsf_ie_Q_z, movsf_ie_y): New insn pattern.
> (movsf): Use new patterns.
> (movdf_i4_F_z+7): New splitter.
> 
> With it, now "make check-gcc" has no new ICEs with unix/-m4/-mlra when
> comparing unix/-m4.

I have added this patch on top of the other patches and got an ICE when
bootstrapping Ada natively:

a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 449 [orig:184 _24 ] [184])
(reg:SF 463))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 463)
(nil)))
during RTL pass: reload

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #282 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #281)
> (In reply to John Paul Adrian Glaubitz from comment #280)
> > (In reply to Kazumoto Kojima from comment #279)
> > > (In reply to John Paul Adrian Glaubitz from comment #275)
> > > > Created attachment 59152 [details]
> > > > Preprocessed source from from comment #273
> > > 
> > > Thanks for test cases.  Both .ii are compiled successfully with the WIP
> > > cross compiler here, though I could use wrong flags.
> > 
> > The flags look correct to me.
> > 
> > Could you tell me what patches you were testing? Then I'll rebuild my local
> > GCC and retry building webkit2gtk with the updated compiler.
> 
> I can't show the complete patch set as it's still WIP.  Could you please
> give me a little more time?

Sure, no problem. I wasn't aware the patch is WIP. Sorry for that

> However, c#273 seems very similar to the error resolved with the patch 59132.

OK, thanks. But I'll wait. Let me know when you want me to retest.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #280 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #279)
> (In reply to John Paul Adrian Glaubitz from comment #275)
> > Created attachment 59152 [details]
> > Preprocessed source from from comment #273
> 
> Thanks for test cases.  Both .ii are compiled successfully with the WIP
> cross compiler here, though I could use wrong flags.

The flags look correct to me.

Could you tell me what patches you were testing? Then I'll rebuild my local GCC
and retry building webkit2gtk with the updated compiler.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #275 from John Paul Adrian Glaubitz  ---
Created attachment 59152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59152&action=edit
Preprocessed source from from comment #273

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #274 from John Paul Adrian Glaubitz  ---
Created attachment 59151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59151&action=edit
Preprocessed source from from comment #271

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #273 from John Paul Adrian Glaubitz  ---
Ran into another one:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g1 -O2 -ffile-prefix-map=/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o.d
-o Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/pathops/SkPathOpsCubic.cpp.o
-c
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:
In member function 'bool SkDCubic::isLinear(int, int) const':
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:239:1:
error: unrecognizable insn:
  239 | }
  | ^
(insn 6 1028 1030 (parallel [
(set (reg:DF 1 r1 [orig:248 lineParameters$fC ] [248])
(mem/u/c:DF (label_ref 1298) [0  S8 A32]))
(use (reg:SI 154 fpscr0))
(clobber (mem/c:SI (plus:SI (reg:SI 1 r1 [694])
(const_int 24 [0x18])) [187 %sfp+-40 S4 A32]))
])
"/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkLineParameters.h":128:26
-1
 (nil))
during RTL pass: mach
/home/glaubitz/webkit2gtk-sh4/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/pathops/SkPathOpsCubic.cpp:239:1:
internal compiler error: in insn_min_length, at config/sh/sh.md:4190
0x1b489eb diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag*, diagnostic_t)
???:0
0x1b561e7 internal_error(char const*, ...)
???:0
0x66af4f fancy_abort(char const*, int, char const*)
???:0
0x6502f7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x650325 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0x184692b insn_min_length(rtx_insn*)
???:0
0xb9eaab shorten_branches(rtx_insn*)
???:0
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.
Preprocessed source stored into /tmp/ccpQI6hF.out file, please attach this to
your bugreport.

Will attach the pre-processed source, also for comment #271.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #272 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #271)
> I just did some testing with the LRA-enabled gcc-15 to see which bugs would
> be fixed and while I can confirm that both PR target/81426 and PR
> target/115148 no longer occur, another ICE has just popped up:

Ah, it doesn't occur with -O2. I happed to still build with -O1 due to earlier
issues when building with Reload instead of LRA.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #271 from John Paul Adrian Glaubitz  ---
I just did some testing with the LRA-enabled gcc-15 to see which bugs would be
fixed and while I can confirm that both PR target/81426 and PR target/115148 no
longer occur, another ICE has just popped up:

/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1 -DSKCMS_DISABLE_HSW -DSKCMS_DISABLE_SKX -DSKIA_IMPLEMENTATION=1
-DSK_ASSUME_GL=0 -DSK_ASSUME_GL_ES=1 -DSK_ASSUME_WEBGL=0 -DSK_CODEC_DECODES_PNG
-DSK_DISABLE_LEGACY_GL_MAKE_NATIVE_INTERFACE
-DSK_DISABLE_LEGACY_IMAGE_READBUFFER -DSK_DISABLE_LEGACY_INIT_DECODERS
-DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_DISABLE_TRACING
-DSK_DISABLE_WEBGL_INTERFACE -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8
-DSK_GANESH -DSK_GL -DSK_R32_SHIFT=16 -DSK_RELEASE
-DSK_TYPEFACE_FACTORY_FREETYPE
-I/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia
-isystem /usr/include/freetype2 -fdiagnostics-color=always -Wextra -Wall -pipe
-fmax-errors=20 -Wno-odr -Wno-stringop-overread -Wno-stringop-overflow
-Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined -Wno-noexcept-type
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align
-Wno-tautological-compare -fasynchronous-unwind-tables -fdebug-types-section
-g0 -O1 -ffile-prefix-map=/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 --param ggc-min-expand=10
-DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti
-fcoroutines -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden
-ffp-contract=off -fstrict-aliasing -Wno-attributes -Wno-cast-align
-Wno-dangling-reference -Wno-deprecated -Wno-psabi
-Wno-suggest-attribute=format -Wno-undef -Wno-uninitialized
-Wno-unused-parameter -std=c++23 -MD -MT
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o -MF
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o.d -o
Source/ThirdParty/skia/CMakeFiles/Skia.dir/src/core/SkGeometry.cpp.o -c
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp
during RTL pass: postreload
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp:
In member function 'SkPoint SkConic::evalAt(SkScalar) const':
/home/glaubitz/webkit2gtk-2.46/webkit2gtk-2.46.0/Source/ThirdParty/skia/src/core/SkGeometry.cpp:1362:1:
internal compiler error: in reload_combine_note_use, at postreload.cc:1524
 1362 | }
  | ^
0x1b489eb diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag*, diagnostic_t)
???:0
0x1b561e7 internal_error(char const*, ...)
???:0
0x66af4f fancy_abort(char const*, int, char const*)
???:0
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.
Preprocessed source stored into /tmp/ccYWv2JM.out file, please attach this to
your bugreport.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426

--- Comment #16 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #15)
> (In reply to John Paul Adrian Glaubitz from comment #14)
> > This particular bug is resolved when building with an LRA-enabled gcc-15.
> > 
> > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
> 
> That's great!  Is there a way to find out whether the generated code is
> correct?  Does it have a runtime testsuite or something like that?

It does. However, I'm currently having unreleated problems with CMake which
means I cannot build the whole project at the moment. I need to debug that
first, but I'm currently busy with my dayjob.

But at least we're seeing some progress here.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932

--- Comment #2 from John Paul Adrian Glaubitz  ---
I'm not sure it makes sense to have this bug report depend on arch-specific
bugs such as 116778 and 116779.

This meta-bug should depend only on the LRA tracker bugs for each architecture
which itself depend on the various LRA issues.

We're otherwise going to lose track over the long list of bugs.

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

2024-09-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426

--- Comment #14 from John Paul Adrian Glaubitz  ---
This particular bug is resolved when building with an LRA-enabled gcc-15.

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

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

2024-09-18 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #270 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #269)
> (In reply to Kazumoto Kojima from comment #267)
> > (In reply to Oleg Endo from comment #264)
> > > Very nice!  So it seems indeed, splitting up the "mega move patterns" into
> > > simpler ones where predicates are more closer to the actual constraints 
> > > give
> > > better results (if I'm not mistaken).  Have you also tried using these
> > > patterns without LRA?  I'm just wondering if we need to distinguish 
> > > between
> > > LRA/non-LRA case at all.
> > 
> > I'll give it a try and report back.
> 
> Unfortunately, it doesn't seem to work.  It can build target
> libgcc/libstdc++v3 libs, but I got the our old friend when compiling
> gcc.c-torture/compile/20031220-2.c with -O2

OK, I'll wait with testing further patches then. In the mean time, I will use
an LRA-enabled GCC 15 to test against older bug reports against the SH backend.

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

2024-09-17 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148

--- Comment #18 from John Paul Adrian Glaubitz  ---
This particular bug is resolved when building with an LRA-enabled gcc-15.

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

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

2024-09-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #258 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #250)
> This builds fine. I will try to build Kaz's tree now as it is.

So, for Kaz's tree, I'm getting the comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/gimple-lower-bitint.o differs
make[2]: *** [Makefile:25560: compare] Error 1
make[2]: Leaving directory '/srv/glaubitz/gcc-sh/build'
make[1]: *** [Makefile:25540: stage3-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc-sh/build'
make: *** [Makefile:1098: all] Error 2

Thus, the best result for me so far is with the following patches:

- 58832
- 58833
- 58883
- 58905
- 59034
- 59044
- 59061
- 59062
- 58995

Will try to build a Debian package next and use that to test-compile various
packages.

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

2024-09-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #256 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #255)
> (In reply to John Paul Adrian Glaubitz from comment #254)
> 
> > OK, thanks for the clarification. I'd suggest then to upstream everything
> > that has been tested to work and is also fine to merge as-is.
> 
> Having the compiler bootstrapping is already a big step, but how about
> building other packages?  With the patched up and bootstrapping compiler,
> can you start building packages and collect some data, like how many build /
> fail and so on?

I'm planning to do that next. It takes just a little time with QEMU.

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

2024-09-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #254 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #253)
> (In reply to John Paul Adrian Glaubitz from comment #252)
> > (In reply to John Paul Adrian Glaubitz from comment #250)
> > > This builds fine. I will try to build Kaz's tree now as it is.
> > 
> > I suggest, once this is verified to work, that we start upstreaming the
> > patches and perform potentially needed bug fixing later.
> 
> Some of the patches could be merged in master as-is.  However, some of them
> are clearly quick hacks to get it to work somehow right now and get the
> overall picture of the problem, like Kaz said himself before.
> 
> For some of the issues the actual reason should be investigated first. 
> Otherwise this "we will fix it later" will never happen and we'll have an
> even bigger mess of hacks to maintain further down the line -- like with
> some of the > 20 year old issues in the backend.

OK, thanks for the clarification. I'd suggest then to upstream everything that
has been tested to work and is also fine to merge as-is.

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

2024-09-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #252 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #250)
> This builds fine. I will try to build Kaz's tree now as it is.

I suggest, once this is verified to work, that we start upstreaming the patches
and perform potentially needed bug fixing later.

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

2024-09-11 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #250 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #247)
> Applying all necessary patches except 59000 makes the stack overflow with
> reload go away.
> 
> Will try an LRA build now with the following patches and Ada enabled:
> 
> - 58832
> - 58833
> - 58883
> - 58905
> - 59034
> - 59044
> - 59061
> - 59062
> - 58995

This builds fine. I will try to build Kaz's tree now as it is.

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

2024-09-11 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #247 from John Paul Adrian Glaubitz  ---
Applying all necessary patches except 59000 makes the stack overflow with
reload go away.

Will try an LRA build now with the following patches and Ada enabled:

- 58832
- 58833
- 58883
- 58905
- 59034
- 59044
- 59061
- 59062
- 58995

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

2024-09-11 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #245 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #244)
> (In reply to John Paul Adrian Glaubitz from comment #243)
> > Is that with qemu-user or qemu-system? I tried multiple times and I always
> > got a stack overflow with 59000. Trying without now.
> 
> qemu-user.  I'm using the default stack size.
> Of course that is not the real sh4-linux environment, so there could be
> differences.

Hmm, I'm on qemu-user as well building inside a current Debian unstable sh4
chroot.

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

2024-09-10 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #243 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #242)
> (In reply to John Paul Adrian Glaubitz from comment #241)
> > (In reply to Kazumoto Kojima from comment #240)
> > Did that include patch 59000?
> 
> Yes.

Is that with qemu-user or qemu-system? I tried multiple times and I always got
a stack overflow with 59000. Trying without now.

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

2024-09-10 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #241 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #240)
> My trial of the 3-stage bootstrap of gcc with enabling c,c++,lto,ada on qemu
> has been done successfully with "-g -O2 -m4 -mlra" flags.  I'm using the gcc
> master commit 592a335de563a3a9e36d362c5b9f3fb0a990c1d8  + LRA patch series
> which is equal to sh-lra branch to https://github.com/kazkojima/gcc.git.

Did that include patch 59000?

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

2024-09-10 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #239 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #238)
> (In reply to John Paul Adrian Glaubitz from comment #237)
> > Let me try to bisect the stack overflow bug. Will report back once I know
> > more.
> 
> It's one of the other LRA patches, but it takes me longer than expected to
> bisect this.

My suspicion is that it is caused by patch 59000 which I am leaving out now.

Luckily, we have patch 58895 as a workaround.

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

2024-09-10 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #238 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #237)
> Let me try to bisect the stack overflow bug. Will report back once I know
> more.

It's one of the other LRA patches, but it takes me longer than expected to
bisect this.

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

2024-09-08 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #237 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #236)
> (In reply to John Paul Adrian Glaubitz from comment #235)
> > Not sure though whether this is related at all. Will go back to the known
> > working version and retry with all patches.
> 
> OK, the stack overflow issue is reproducible. Will try with LRA disabled now
> to see if it's a side-effect or LRA or the patches 59061 and 59062.

Turns out the stack overflow is unrelated to 59061 and 59062, and indeed, the
two patches fix the problem with previous problem with Ada. So the two patches
are fine.

Let me try to bisect the stack overflow bug. Will report back once I know more.

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

2024-09-07 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #236 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #235)
> Not sure though whether this is related at all. Will go back to the known
> working version and retry with all patches.

OK, the stack overflow issue is reproducible. Will try with LRA disabled now to
see if it's a side-effect or LRA or the patches 59061 and 59062.

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

2024-09-06 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #235 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #234)
> OK, I'll add both patch 59061 and patch 59062 and give it a try with all
> languages enabled except for D which requires a working libphobos which I
> don't have.

Seems like the original problem with Ada is fixed, but it still fails with a
stack overflow error:

/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fchecking=1 -c -g -O2
-fchecking=1  -gnatpg -gnata -W -Wall -fPIC -nostdinc -I- -I. -Iada/generated
-Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat -Iada/gcc-interface
-I../../gcc/ada/gcc-interface ../../gcc/ada/sem_smem.adb -o ada/sem_smem.o

raised STORAG
E_ERROR : stack overflow or errronaeiosuesd  memory acScTeOsRsAGE_ERROR
 :
stack overflow or erroneous memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access


rraaiisseedd  SSTTOORRAAGGEE__EEOORR  ::  ssttaacckk  oovveerrffllooww 
oorr  eeoonneeoouuss  mmeemmoorryy  aaee


raised STORAGE_ERROR : stack
overflow or erroneous memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_case.o]
Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:171: ada/seinfo.o] Error
1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem.o] Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_attr.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_aggr.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_cat.o]
Error 1


raised raSTORiAGsEe_dE RRORSTORAGE_ERRO R:  : stack overflow or errsonteaocuks 
omveemrofrlyo wa cocre sesrroneous memory access

make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch11.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch12.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch13.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch10.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_aux.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166:
ada/accessibility.o] Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous
memory access
raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : make[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch4.o] Error 1
stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch7.o]
Error 1

raised STORAGE_ERROR : make[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch3.o] Error 1
stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflowmake[3]: ***
[../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch2.o] Error 1
 or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch6.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch8.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_eval.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_disp.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_ch5.o]
Error 1

raised STORAGE_ERROR : stack overflow or erroneous memory access

raised STORAGE_ERROR : stack overflow or erroneous memory access


raised STORAGE_ERROR
 : raised STsOtRaAcGkE_ EoRvReOrRflow or erroneous m er:m oariys eadc
cessSTORAGE_ERROR
stac k:  overflow or erroneous memory accessstack ov
erflow or erroneous memory access

raised STORAGE_ERROR

 : stack overflow or erroneous memory access
rraaiisseedd  SSTTOORRAAGGEE__EEOORR  ::  ssttaacckk  oovveerrffllooww 
oorr  eeoonneeoouuss  mmeemmoorryy  aaee

make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_mech.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_elim.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:166: ada/sem_prag.o]
Error 1
make[3]: *** [../../gcc/ada/gcc-interface/Make-la

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

2024-09-06 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #234 from John Paul Adrian Glaubitz  ---
OK, I'll add both patch 59061 and patch 59062 and give it a try with all
languages enabled except for D which requires a working libphobos which I don't
have.

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

2024-09-05 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #231 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #230)
> (In reply to John Paul Adrian Glaubitz from comment #229)
> > Will try other languages now.
> 
> Building with Fortran, Objective-C and Objective-C++ enabled works fine.
> 
> Will test D and M2 now.

Couldn't test D yet due to limitations of the frontend, but I tried JIT and M2
and both built fine although I had to fix a minor unrelated bug in the JIT code
to get the build to finish. Will post the patch on gcc-patches.

Will try to build D now.

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

2024-09-04 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #230 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #229)
> Will try other languages now.

Building with Fortran, Objective-C and Objective-C++ enabled works fine.

Will test D and M2 now.

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

2024-09-03 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #229 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #228)
> I'll have a go at Ada now.

Ada still fails in subreg1:

mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface ada/libgnat/s-excmac.adb -o
ada/libgnat/s-excmac.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-htable.adb -o ada/libgnat/s-htable.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad32.ads -o ada/libgnat/s-imad32.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad64.ads -o ada/libgnat/s-imad64.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imgint.adb -o ada/libgnat/s-imgint.o
during RTL pass: subreg1
+===GNAT BUG DETECTED==+
| 15.0.0 20240818 (experimental) (sh4-unknown-linux-gnu) GCC error:|
| in decompose_multiword_subregs, at lower-subreg.cc:1728  |
| Error detected around ../../gcc/ada/libgnat/a-exexda.adb:312:8   |
| Compiling ../../gcc/ada/libgnat/a-except.adb |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject 

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

2024-09-03 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #228 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #227)
> (In reply to Kazumoto Kojima from comment #226)
> > Created attachment 59044 [details]
> > a patch to fix patch 59034
> > 
> > Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis
> > and RA.
> > I guess it could be the cause of the segfault in c#225.
> 
> Thanks, I'll add that patch and try again.

I can confirm that the patch 59044 fixes the patch 59034 and both patches
together fix gccgo. I'll have a go at Ada now.

Great to see that we're making so much progress!

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

2024-09-03 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #227 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #226)
> Created attachment 59044 [details]
> a patch to fix patch 59034
> 
> Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis
> and RA.
> I guess it could be the cause of the segfault in c#225.

Thanks, I'll add that patch and try again.

[Bug go/107992] m68k-linux-gnu bootstap error in gofrontend

2024-09-03 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107992

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #1)
> Thanks.  This is happening because the data structures that Go's garbage
> collector uses require that all pointers be aligned on their natural
> boundaries.  Unfortunately m68k only provides 2-byte alignment for 4-byte
> pointers, not 4-byte alignment.  I don't know if there will be a simple fix.
> We could probably adjust the alignment for data structures defined in Go,
> which would fix this case, but that wouldn't help with C interoperability.

We're planning to switch the default alignment on m68k in both Debian and
Gentoo to 4-byte alignment as the unusual 2-byte alignment causes many other
projects such Qt, OpenJDK, LLVM, Mold and many more to fail on m68k.

I don't think it's a feasible option to port all upstream projects to support
2-byte alignment, so we should just switch the default alignment on m68k to use
the common 4-byte alignment.

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

2024-09-02 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #225 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #224)
> (In reply to John Paul Adrian Glaubitz from comment #223)
> > 
> > I had run into some issues with my build environment, so my results are a
> > little delayed. Apologies.
> 
> No problem.
> 
> After further testing, it appears that there may be some wrong code issue. 
> Not sure if this is due to the patch 59034 or not, but I'm looking into it. 
> So there is no hurry to do the bootstrap test in your environment.  I will
> report back once the problem is clear.

It seems that I have run into this issue after 59034 as well since the compiler
segfaults for me with the patch applied:

/srv/glaubitz/gcc/build/./gcc/xgcc -B/srv/glaubitz/gcc/build/./gcc/
-fno-checking -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
0x2b7a0f9f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x2b7a1083 __libc_start_main_impl
./csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

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

2024-09-02 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #223 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #218)
> (In reply to Kazumoto Kojima from comment #216)
> > This patch is assumed to be applied to the top of  58832, 58833, 58883,
> > 58905 and 59000, though it could be reconstructed as the revised 58905.
> > 
> > It's tested only with the target libgcc/libstdc++v3/libgo builds and
> > check-gcc excecute.exp on the cross compilers. I plan to do more tests.
> 
> Testing this now and see if that fixes the issue with gccgo.

I had run into some issues with my build environment, so my results are a
little delayed. Apologies.

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

2024-09-01 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #218 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #216)
> This patch is assumed to be applied to the top of  58832, 58833, 58883,
> 58905 and 59000, though it could be reconstructed as the revised 58905.
> 
> It's tested only with the target libgcc/libstdc++v3/libgo builds and
> check-gcc excecute.exp on the cross compilers. I plan to do more tests.

Testing this now and see if that fixes the issue with gccgo.

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

2024-09-01 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #215 from John Paul Adrian Glaubitz  ---
OK, thanks a lot for looking at the Go problem. In the meantime, I will try to
get a more usable backtrace from Ada.

On a sidenote, gccgo doesn't work 100% properly on qemu-user while it works
perfectly fine on real hardware. But the crash above is not related to
qemu-user.

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

2024-08-31 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #212 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #210)
> Unfortunately, it's difficult to investigate in my environment.

We could maybe ask one of the Ada or Go developers. If you have any other idea
how I can help here, please let me know.

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

2024-08-31 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #211 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #209)
> OK, I can confirm that the Ada problem is a regression due to the LRA switch.
> 
> Not sure about the Go problem yet.

Confirmed that Go has regressed due to LRA as well.

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

2024-08-30 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #209 from John Paul Adrian Glaubitz  ---
OK, I can confirm that the Ada problem is a regression due to the LRA switch.

Not sure about the Go problem yet.

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

2024-08-29 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #208 from John Paul Adrian Glaubitz  ---
Building with Go enabled, fails with:

during RTL pass: subreg3
../../../libgo/go/unicode/utf16/utf16.go: In function 'unicode/utf16.Encode':
../../../libgo/go/unicode/utf16/utf16.go:56:1: internal compiler error: in
decompose_multiword_subregs, at lower-subreg.cc:1728
   56 | func Encode(s []rune) []uint16 {
  | ^
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=internal/itoa ../../../libgo/go/internal/itoa/itoa.go -o
internal/itoa.o >/dev/null 2>&1
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=sync/atomic ../../../libgo/go/sync/atomic/doc.go
../../../libgo/go/sync/atomic/unaligned.go
../../../libgo/go/sync/atomic/value.go -o sync/atomic.o >/dev/null 2>&1
libtool: compile:  /srv/glaubitz/gcc/build/./gcc/gccgo
-B/srv/glaubitz/gcc/build/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=container/ring ../../../libgo/go/container/ring/ring.go -o
container/ring.o >/dev/null 2>&1
0x1872ddb internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:491
0x67aca7 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1772
0x173af73 decompose_multiword_subregs
../../gcc/lower-subreg.cc:1728
0x173b8bf execute
../../gcc/lower-subreg.cc:1849
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.

Not sure whether this is an old bug though.

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

2024-08-28 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #207 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #206)
> Next I'm going to test with Ada enabled which had some issues in previous
> tests.

Enabling Ada fails with:

/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface ada/libgnat/s-excmac.adb -o
ada/libgnat/s-excmac.o
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-htable.adb -o ada/libgnat/s-htable.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad32.ads -o ada/libgnat/s-imad32.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imad64.ads -o ada/libgnat/s-imad64.o
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I../../gcc/ada -Iada/libgnat -I../../gcc/ada/libgnat
-Iada/gcc-interface -I../../gcc/ada/gcc-interface
../../gcc/ada/libgnat/s-imgint.adb -o ada/libgnat/s-imgint.o
mkdir -p ada/libgnat/
mkdir -p ada/libgnat/
/srv/glaubitz/gcc/build/./prev-gcc/xgcc -B/srv/glaubitz/gcc/build/./prev-gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg -gnata -W -Wall -fno-PIE -nostdinc -I- -I.
-Iada/generated -Iada -I.

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

2024-08-28 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #206 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #205)
> Confirmed. The above configuration builds fine for me with a full bootstrap
> with C and C++ as the enabled languages.
> 
> Will now try with patch 58995 instead of patch 59000.

Even with patch 58995 instead of patch 59000, a full bootstrap builds fine.

Next I'm going to test with Ada enabled which had some issues in previous
tests.

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

2024-08-27 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #205 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #204)
> Yeah, I'm pretty sure that's because I disabled late combine as one of the
> measures trying to mitigate the segfault.
> 
> I am testing now with the following patches applied:
> 
> - 58832
> - 58833
> - 58883
> - 58905
> - 59000
> 
> as well as LRA enabled by default and late combine enabled as well.
> 
> Will report back as soon as the build finishes.

Confirmed. The above configuration builds fine for me with a full bootstrap
with C and C++ as the enabled languages.

Will now try with patch 58995 instead of patch 59000.

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

2024-08-27 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #204 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #203)
> (In reply to John Paul Adrian Glaubitz from comment #201)
> > Created attachment 59006 [details]
> > Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c
> 
> I tried to build the stage3 gcc on qemu with the stage2 gcc which was built
> with the cross comiler.   Interestingly, stage2 gcc/gimple-lower-bitint.o
> and stage3 gcc/gimple-lower-bitint.o were exactly the same.  Perhaps the
> problem cannot be reproduced because my qemu environment is not the real
> sh4-linux and my build process of the stage3 compiler was not the same with
> the true bootstrapping.

It actually seems that the bootstrap comparison failure that I have run into
was a result of disabling late combine. I am retesting this now just to make
sure.

> FYI, your stage2 gcc/gimple-lower-bitint.o already seems to be slightly
> different from my stage2 gcc/gimple-lower-bitint.o. It may be due to the
> difference in codebase.  I'm using gcc master commit
> 7f65c38ac1b18773d55c08d6ba920a798462b871 (origin/master, master).

Yeah, I'm pretty sure that's because I disabled late combine as one of the
measures trying to mitigate the segfault.

I am testing now with the following patches applied:

- 58832
- 58833
- 58883
- 58905
- 59000

as well as LRA enabled by default and late combine enabled as well.

Will report back as soon as the build finishes.

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

2024-08-26 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #202 from John Paul Adrian Glaubitz  ---
Adding "gcc/gimple-lower-bitint*" to "compare_exclusions" in configure.ac makes
the build pass the bootstrap comparison and completely succeed with LRA enabled
with the following patches applied:

- 58832
- 58833
- 58883
- 58905
- 59000

This is with late-combine disabled which I will enable now for the next test
build.

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

2024-08-26 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #201 from John Paul Adrian Glaubitz  ---
Created attachment 59006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59006&action=edit
Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c

(In reply to John Paul Adrian Glaubitz from comment #200)
> (In reply to Kazumoto Kojima from comment #199)
> > Created attachment 59000 [details]
> > a patch for an experiment
> > 
> > I added explicit register clobbers after all s-function calls as an
> > experiment, although it is not the right way to fix the issue.
> 
> OK, I'll add that patch and retest.

Comparison failure is still present with 59000 applied instead of 58995.

Attaching the disassembled diff for gcc/gimple-lower-bitint.c.

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

2024-08-26 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #200 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #199)
> Created attachment 59000 [details]
> a patch for an experiment
> 
> I added explicit register clobbers after all s-function calls as an
> experiment, although it is not the right way to fix the issue.

OK, I'll add that patch and retest.

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

2024-08-25 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #198 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #194)
> Created attachment 58995 [details]
> simply a trial patch, not a real fix
> 
> With this explicit emit_clobber, all the segfaults I reported are gone.  I'm
> a bit confused.

This fixes the segmentation fault for me as well, I'm just left with a single
bootstrap comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/gimple-lower-bitint.o differs
make[2]: *** [Makefile:24837: compare] Error 1
make[2]: Leaving directory '/srv/glaubitz/gcc/build'
make[1]: *** [Makefile:24817: stage3-bubble] Error 2
make[1]: Leaving directory '/srv/glaubitz/gcc/build'
make: *** [Makefile:1101: all] Error 2

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

2024-08-23 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #186 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #185)
> It is not at all clear what is causing the wrong value or code, though.  We
> are still at the starting point of the bugfix.

That's still great progress in any case. Thanks a lot!

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

2024-08-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #184 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #183)
> I'm trying with late-combine disabled now:
> 
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index 280588268ae..dca27893536 100644
> --- a/gcc/config/sh/sh.cc
> +++ b/gcc/config/sh/sh.cc
> @@ -1047,6 +1047,9 @@ sh_override_options_after_change (void)
>   str_align_functions = r;
> }
>  }
> +
> +if (!OPTION_SET_P (flag_late_combine_instructions))
> +  flag_late_combine_instructions = 0;
>  }
>  ^L
>  /* Print the operand address in x to the stream.  */

Segfault is still present.

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

2024-08-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #183 from John Paul Adrian Glaubitz  ---
I'm trying with late-combine disabled now:

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 280588268ae..dca27893536 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -1047,6 +1047,9 @@ sh_override_options_after_change (void)
  str_align_functions = r;
}
 }
+
+if (!OPTION_SET_P (flag_late_combine_instructions))
+  flag_late_combine_instructions = 0;
 }
 ^L
 /* Print the operand address in x to the stream.  */

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

2024-08-19 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #182 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #181)
> Just as a heads-up: I am currently performing extensive testing to be able
> to generate anything useful from testsuite results to a usable backtrace.
> For that, I am building GCC natively with various options on sh4.
> 
> Will report back as soon as I have something.

With the following patches applied

- 58832
- 58833
- 58883
- 58905

and LRA enabled by default, I am seeing the same segfault on git master with:

"../configure --disable-multilib --enable-multiarch --enable-bootstrap
--enable-languages=c,c++"

but not with

./configure --disable-multilib --enable-multiarch --disable-bootstrap
--enable-languages=c,c++

I wonder whether this is related to "[committed] Fix m68k bootstrap segfault
with late-combine" for m68k. I will revert the late combine change and see if
that helps.

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

2024-08-18 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #181 from John Paul Adrian Glaubitz  ---
Just as a heads-up: I am currently performing extensive testing to be able to
generate anything useful from testsuite results to a usable backtrace. For
that, I am building GCC natively with various options on sh4.

Will report back as soon as I have something.

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

2024-08-16 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #178 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #177)
> As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> compiler on a regular basis, see also
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660457.html

I assume he is doing cross-compiled bootstraps which is why he is never running
the miscompiled code, is he?

Also, did he try with LRA enabled?

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

2024-08-16 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #176 from John Paul Adrian Glaubitz  ---
I am trying a full bootstrap with the patches applied now but with LRA disabled
by default.

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

2024-08-16 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #173 from John Paul Adrian Glaubitz  ---
Here's what I got from gdb:

(gdb) bt
#0  0x0109fee4 in wi::add_large(long long*, long long const*, unsigned int,
long long const*, unsigned int, unsigned int, signop, wi::overflow_type*) ()
#1  0x00bdbc10 in
access_ref::add_offset(generic_wide_int > const&,
generic_wide_int > const&) ()
#2  0x00bdd0e8 in compute_objsize_r(tree_node*, gimple*, bool, int,
access_ref*, ssa_name_limit_t&, pointer_query*) ()
#3  0x in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x109fee4 <_ZN2wi9add_largeEPxPKxjS2_jj6signopPNS_13overflow_typeE+84>: 
mov.l   @r2,r3
(gdb) x/wx $r2
0x7c07eaa0: Cannot access memory at address 0x7c07eaa0
(gdb)

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

2024-08-16 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #172 from John Paul Adrian Glaubitz  ---
Interesting, it's showing an illegal instruction now:

root@tirpitz:..sh4-linux-gnu/libgcc>
/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/xgcc
-B/srv/gcc-snapshot-3YBWb3/gcc-snapshot-20240715/build/./gcc/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sh4-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/sh4-linux-gnu/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w
-Wno-sync-nand -I. -I. -I../.././gcc -I../../../src/libgcc
-I../../../src/libgcc/. -I../../../src/libgcc/../gcc
-I../../../src/libgcc/../include  -DHAVE_CC_TLS   -o _muldi3.o -MT _muldi3.o
-MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../src/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: waccess
../../../src/libgcc/libgcc2.c: In function '__muldi3':
../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Segmentation
fault
  538 | }
  | ^

../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
instruction
root@tirpitz:..sh4-linux-gnu/libgcc>

Could this be just an issue of the compiler generating invalid code?

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

2024-08-16 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #171 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #170)
> (In reply to John Paul Adrian Glaubitz from comment #168)
> > I am getting a segmentation fault when building libgcc2.c now:
> > (...) 
> > Trying with gcc-15 now.
> 
> gcc-15 from July segfaults the same way when building libgcc2.c. Will try a
> gcc-15 snapshot from 7 August now.

I'm going to try to obtain a backtrace now. This may take a little while
though.

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

2024-08-15 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #170 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #168)
> I am getting a segmentation fault when building libgcc2.c now:
> (...) 
> Trying with gcc-15 now.

gcc-15 from July segfaults the same way when building libgcc2.c. Will try a
gcc-15 snapshot from 7 August now.

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

2024-08-13 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #168 from John Paul Adrian Glaubitz  ---
I am getting a segmentation fault when building libgcc2.c now:

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
/usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<>/build/sys-include   -fno-checking -g -O2 -O2  -g -O2 -DIN_GCC 
 -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fpic
-DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -I. -I.
-I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/.
-I../../../src/libgcc/../gcc -I../../../src/libgcc/../include  -DHAVE_CC_TLS  
-o __gcc_bcmp.o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c
../../../src/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
during GIMPLE pass: evrp
../../../src/libgcc/libgcc2.c: In function '__clrsbsi2':
../../../src/libgcc/libgcc2.c:760:1: internal compiler error: Segmentation
fault
  760 | }
  | ^
Unhandled trap: 0x180
pc=0x2b7e4c40 sr=0x0001 pr=0x2b7e4c32 fpscr=0x00080004
spc=0x ssr=0x gbr=0x2b2f3c20 vbr=0x
sgr=0x dbr=0x delayed_pc=0x2b7e4c32 fpul=0x0064
r0=0x0004 r1=0x2b9410c8 r2=0x0005 r3=0x
r4=0x001fdb3e r5=0x001fdb3e r6=0x0006 r7=0x011c
r8=0x2b9410bc r9=0x0468 r10=0x2b2f3760 r11=0x01480400
r12=0x2b940c60 r13=0x2b2a5c8c r14=0x2b2a5ccc r15=0x2b2a5634
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x
make[5]: *** [Makefile:508: _clrsbsi2.o] Error 1
make[5]: *** Waiting for unfinished jobs
make[5]: Leaving directory '/<>/build/sh4-linux-gnu/libgcc'
make[4]: *** [Makefile:18852: all-stage2-target-libgcc] Error 2
make[4]: Leaving directory '/<>/build'
make[3]: *** [Makefile:24459: stage2-bubble] Error 2
make[3]: Leaving directory '/<>/build'
make[2]: *** [Makefile:24663: bootstrap] Error 2
make[2]: Leaving directory '/<>/build'

This is with the following patches applied on top of gcc-14:

- 58832
- 58833
- 58883
- 58905

I also had to disable Ada for the time being which failed with:

/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface
../../src/gcc/ada/libgnat/s-except.adb -o ada/libgnat/s-except.o
mkdir -p ada/libgnat/
/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface ada/libgnat/s-excmac.adb
-o ada/libgnat/s-excmac.o
mkdir -p ada/libgnat/
/<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/
-isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include
-isystem /<>/build/sys-include   -fno-checking -c -g -O2
-fno-checking -gtoggle  -gnatpg  -W -Wall -fno-PIE -nostdinc -I- -I. -Iada/gen
erated -Iada -I../../src/gcc/ada -Iada/libgnat -I../../src/gcc/ada/libgnat
-Iada/gcc-interface -I../../src/gcc/ada/gcc-interface
../../src/gcc/ada/libgnat/s-exctab.adb -o ada/libgnat/s-exctab.o
during RTL pass: subreg1
+===GNAT BUG DETECTED==+
| 14.2.0 (sh4-linux-gnu) GCC error:|
| in decompose_multiword_subregs, at lower-subreg.cc:1728  |
| Error detected around ../../src/gcc/ada/libgnat/a-exexda.adb:312:8   |
| Compiling ../../src/gcc/ada/libgnat/a-except.adb |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the

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

2024-08-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #160 from John Paul Adrian Glaubitz  ---
Created attachment 58910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58910&action=edit
Preprocessed source from from comment #159

[Bug rtl-optimization/29349] mode switching is inefficient both at compile time and at run time

2024-08-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

  Attachment #58909|0   |1
is obsolete||

--- Comment #5 from John Paul Adrian Glaubitz  ---
Comment on attachment 58909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58909
Preprocessed source from from comment #159

Wrong bug report as Bugzilla just jumped to the next bug.

[Bug rtl-optimization/29349] mode switching is inefficient both at compile time and at run time

2024-08-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
Created attachment 58909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58909&action=edit
Preprocessed source from from comment #159

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

2024-08-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #159 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #157)
> Created attachment 58905 [details]
> a revised patch for c#135, c#139 and c#154

This now fails when compiling libstdc++-v3 with:

libtool: compile:  /<>/build/./gcc/xgcc -shared-libgcc
-B/<>/build/./gcc -nostdinc++
-L/<>/build/sh4-linux-gnu/libstdc++-v3/src
-L/<>/build/sh4-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/sh4-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem
/usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem
/<>/build/sys-include -fno-checking
-I/<>/src/libstdc++-v3/../libgcc
-I/<>/build/sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu
-I/<>/build/sh4-linux-gnu/libstdc++-v3/include
-I/<>/src/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=c++locale.lo -g -O2 -D_GNU_SOURCE -fimplicit-templates -c
c++locale.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o c++locale.o
../../../../../src/libstdc++-v3/src/c++98/strstream.cc: In member function
'virtual void std::strstream::_ZTv0_n12_NSt9strstreamD1Ev()':
../../../../../src/libstdc++-v3/src/c++98/strstream.cc:417:1: error:
unrecognizable insn:
  417 | } // namespace
  | ^
(call_insn/j 6 5 7 (parallel [
(call (mem:SI (symbol_ref:SI ("*.LTHUNK4") [flags 0x3]
) [0  S4 A32])
(const_int 0 [0]))
(use (reg:SI 154 fpscr0))
(clobber (reg:SI 3 r3))
(return)
])
"/<>/build/sh4-linux-gnu/libstdc++-v3/include/backward/strstream":217:13
-1
 (nil)
(expr_list (use (reg:SI 4 r4))
(nil)))
../../../../../src/libstdc++-v3/src/c++98/strstream.cc:417:1: internal compiler
error: in insn_min_length, at config/sh/sh.md:4190
0x17cf86f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.cc:108
0x17cf8d9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.cc:116
0x23ac109 insn_min_length(rtx_insn*)
../../src/gcc/config/sh/sh.md:4190
0x12b3d5f shorten_branches(rtx_insn*)
../../src/gcc/final.cc:1089
0x1d33865 sh_reorg
../../src/gcc/config/sh/sh.cc:6113
0x1d46f39 sh_output_mi_thunk
../../src/gcc/config/sh/sh.cc:10947
0x1114f9d expand_thunk(cgraph_node*, bool, bool)
../../src/gcc/symtab-thunks.cc:388
0x1131b1d cgraph_node::assemble_thunks_and_aliases()
../../src/gcc/cgraphunit.cc:1767
0x1131c0d cgraph_node::assemble_thunks_and_aliases()
../../src/gcc/cgraphunit.cc:1789
0x1132101 cgraph_node::expand()
../../src/gcc/cgraphunit.cc:1918
0x11325bf expand_all_functions
../../src/gcc/cgraphunit.cc:2028
0x113323f symbol_table::compile()
../../src/gcc/cgraphunit.cc:2404
0x11337ab symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.cc:2589
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.
Preprocessed source stored into /tmp/ccHVpWhQ.out file, please attach this to
your bugreport.

Will attach the preprocessed source from /tmp/ccHVpWhQ.out as well.

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

2024-08-11 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #155 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #154)
> Managed to reproduce the error with an error message:
> 
> (unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/
> sh4-linux-gnu/libgomp$ /build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/xgcc
> -B/build/gcc-14-7reYr0/gcc-14-14.2.0/build/./gcc/ -B/usr/sh4-linux-gnu/bin/
> -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem
> /usr/sh4-linux-gnu/sys-include -isystem
> /build/gcc-14-7reYr0/gcc-14-14.2.0/build/sys-include -fno-checking
> -DHAVE_CONFIG_H -I. -I../../../src/libgomp
> -I../../../src/libgomp/config/posix -I../../../src/libgomp
> -I../../../src/libgomp/../include -Wall -ftls-model=initial-exec -pthread
> -DUSING_INITIAL_EXEC_TLS -g -O2 -MT affinity-fmt.lo -MD -MP -MF
> .deps/affinity-fmt.Tpo -c ../../../src/libgomp/affinity-fmt.c -o
> affinity-fmt.o
> ../../../src/libgomp/affinity-fmt.c: In function 'gomp_display_affinity':
> ../../../src/libgomp/affinity-fmt.c:437:1: error: unable to find a register
> to spill
>   437 | }
>   | ^
> ../../../src/libgomp/affinity-fmt.c:437:1: error: this is the insn:
> (insn 1939 564 567 70 (set (reg:SI 537 [orig:214 _146 ] [214])
> (reg:SI 214 [ _146 ])) "../../../src/libgomp/affinity-fmt.c":203:13
> 191 {movsi_ie}
>  (nil))
> ../../../src/libgomp/affinity-fmt.c:437: confused by earlier errors, bailing
> out
> (unstable-sh4-sbuild)glaubitz@acrux:/build/gcc-14-7reYr0/gcc-14-14.2.0/build/
> sh4-linux-gnu/libgomp$

This goes away with "-fno-inline-functions -fno-thread-jumps
-fno-rerun-cse-after-loop".

  1   2   3   >