Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1397948 - method-to-ir.c miscompiled with -O2 -march=z10
Summary: method-to-ir.c miscompiled with -O2 -march=z10
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 28
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker
TreeView+ depends on / blocked
 
Reported: 2016-11-23 16:07 UTC by Dan Horák
Modified: 2020-07-22 07:13 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 20:32:40 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
script to reproduce the mdoc call outside the build system (376 bytes, text/plain)
2016-11-24 16:36 UTC, Dan Horák 		no flags Details
preprocessed source file (2.46 MB, text/plain)
2016-11-24 16:56 UTC, Dan Horák 		no flags Details
View All

Description Dan Horák 2016-11-23 16:07:30 UTC 
After switching the minimum architecture level for the C compiler (-mcpu in %__global_cflags, defined by redhat-rpm-config) from z9-109 to z10 (or anything newer - z196, zEC12) mdoc started to crash during the build.

from a local rebuild
...
MCS     [net_4_x] mono-symbolicate.exe
SymbolManager.cs(115,43): warning CS0168: The variable `e' is declared but never used
Compilation succeeded - 1 warning(s)
MCS     [net_4_x] linkeranalyzer.exe
MDOC    [net_4_x] cs-errors.tree
Stacktrace:

  at <unknown> <0xffffffff>
  at System.Configuration.ConfigurationElement.get_Properties () <0x0004c>
  at System.Configuration.ElementInformation..ctor (System.Configuration.ConfigurationElement,System.Configuration.PropertyInformation) <0x00114>
  at System.Configuration.ConfigurationElement.InitFromProperty (System.Configuration.PropertyInformation) <0x0005c>
  at System.Configuration.ConfigurationElementCollection.InitFromProperty (System.Configuration.PropertyInformation) <0x001ea>
  at System.Configuration.PropertyInformation.get_Value () <0x00114>
  at System.Configuration.ConfigurationElement.get_Item (string) <0x00098>
  at System.Configuration.ConfigurationElement.get_Item (System.Configuration.ConfigurationProperty) <0x00046>
  at System.Diagnostics.TraceSection.get_Listeners () <0x0003e>
  at System.Diagnostics.SystemDiagnosticsSection.InitializeDefault () <0x00042>
  at System.Configuration.ConfigurationElement.Reset (System.Configuration.ConfigurationElement) <0x000bc>
  at System.Configuration.Configuration.GetSectionInstance (System.Configuration.SectionInfo,bool) <0x00646>
  at System.Configuration.Configuration.GetSectionInstance (System.Configuration.SectionInfo,bool) <0x00430>
  at System.Configuration.ConfigurationSectionCollection.get_Item (string) <0x001e6>
  at System.Configuration.Configuration.GetSection (string) <0x00102>
  at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (string) <0x0004e>
  at System.Configuration.ConfigurationManager.GetSection (string) <0x0004a>
  at System.Configuration.PrivilegedConfigurationManager.GetSection (string) <0x00026>
  at System.Diagnostics.DiagnosticsConfiguration.GetConfigSection () <0x00036>
  at System.Diagnostics.DiagnosticsConfiguration.Initialize () <0x000d8>
  at System.Diagnostics.DiagnosticsConfiguration.get_SwitchSettings () <0x00020>
  at System.Diagnostics.Switch.InitializeConfigSettings () <0x00068>
  at System.Diagnostics.Switch.InitializeWithStatus () <0x0012a>
  at System.Diagnostics.Switch.get_SwitchSetting () <0x0003e>
  at System.Diagnostics.BooleanSwitch.get_Enabled () <0x00026>
  at System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly (System.Type,string,System.Xml.Serialization.XmlSerializerImplementation&) <0x0011e>
  at System.Xml.Serialization.XmlSerializer..ctor (System.Type,string) <0x003a8>
  at System.Xml.Serialization.XmlSerializer..ctor (System.Type) <0x00030>
  at Monodoc.Providers.ErrorProvider.ReadConfig (string) <0x00060>
  at Monodoc.Providers.ErrorProvider..ctor (string) <0x00040>
  at Mono.Documentation.MDocAssembler.<Run>m__1 (string) <0x00050>
  at System.Linq.Enumerable/WhereSelectListIterator`2<TSource_REF, TResult_REF>.MoveNext () <0x0023c>
  at System.Collections.Generic.List`1<T_REF>.InsertRange (int,System.Collections.Generic.IEnumerable`1<T_REF>) <0x0042c>
  at System.Collections.Generic.List`1<T_REF>.AddRange (System.Collections.Generic.IEnumerable`1<T_REF>) <0x0003c>
  at Mono.Documentation.MDocAssembler.Run (System.Collections.Generic.IEnumerable`1<string>) <0x00e9e>
  at Mono.Documentation.MDoc.Run (string[]) <0x00bb6>
  at Mono.Documentation.MDoc.Main (string[]) <0x00080>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0x0015c>

Native stacktrace:

	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0xd3a72) [0x2aa0a1d3a72]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x42f3a) [0x2aa0a142f3a]
	[0x3ffff0f9370]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(mono_metadata_get_inflated_signature+0x46) [0x2aa0a299c66]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x17314a) [0x2aa0a27314a]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x7e8be) [0x2aa0a17e8be]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x11b33e) [0x2aa0a21b33e]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x11d346) [0x2aa0a21d346]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0x41dca) [0x2aa0a141dca]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0xd588e) [0x2aa0a1d588e]
	/home/sharkcz/mono/mono-4.6.2/mono/mini/mono(+0xd5fbc) [0x2aa0a1d5fbc]
	[0x3ffb29660e2]

Debug info from gdb:

(lldb) command source -s 0 '/tmp/mono-lldb-commands.OxjGNR'
Executing commands in '/tmp/mono-lldb-commands.OxjGNR'.
(lldb) process attach --pid 13829
Process 13829 stopped
* thread #1: tid = 13829, 0x000003ffb2613b26 libpthread.so.0`__waitpid + 110, name = 'Main', stop reason = signal SIGSTOP
    frame #0: 0x000003ffb2613b26 libpthread.so.0`__waitpid + 110
libpthread.so.0`__waitpid:
->  0x3ffb2613b26 <+110>: clg    %r2, 0(%r13)
    0x3ffb2613b2c <+116>: jh     4396744260470             ; <+190>
    0x3ffb2613b30 <+120>: lr     %r11, %r2
    0x3ffb2613b32 <+122>: lgr    %r2, %r1
  thread #2: tid = 13844, 0x000003ffb260e3ea libpthread.so.0`__pthread_cond_wait + 402, name = 'SGen worker', stop reason = signal SIGSTOP
    frame #0: 0x000003ffb260e3ea libpthread.so.0`__pthread_cond_wait + 402
libpthread.so.0`__pthread_cond_wait:
->  0x3ffb260e3ea <+402>: lgr    %r6, %r2
    0x3ffb260e3ee <+406>: lgr    %r2, %r1
    0x3ffb260e3f2 <+410>: clg    %r6, 8(%r13)
    0x3ffb260e3f8 <+416>: jh     4396744238578             ; <+922>
  thread #3: tid = 13845, 0x000003ffb2611916 libpthread.so.0`do_futex_wait.constprop.1 + 70, name = 'Finalizer', stop reason = signal SIGSTOP
    frame #0: 0x000003ffb2611916 libpthread.so.0`do_futex_wait.constprop.1 + 70
libpthread.so.0`do_futex_wait.constprop.1:
->  0x3ffb2611916 <+70>: clg    %r2, 0(%r13)
    0x3ffb261191c <+76>: jh     4396744251712             ; <+112>
    0x3ffb2611920 <+80>: lgr    %r2, %r1
    0x3ffb2611924 <+84>: brasl  %r14, 4396744254912       ; __pthread_disable_asynccancel

Executable module set to "/home/sharkcz/mono/mono-4.6.2/mono/mini/mono-sgen".
Architecture set to: s390x-ibm-linux.
(lldb) thread list
Process 13829 stopped
* thread #1: tid = 13829, 0x000003ffb2613b26 libpthread.so.0`__waitpid + 110, name = 'Main', stop reason = signal SIGSTOP
  thread #2: tid = 13844, 0x000003ffb260e3ea libpthread.so.0`__pthread_cond_wait + 402, name = 'SGen worker', stop reason = signal SIGSTOP
  thread #3: tid = 13845, 0x000003ffb2611916 libpthread.so.0`do_futex_wait.constprop.1 + 70, name = 'Finalizer', stop reason = signal SIGSTOP
(lldb) thread backtrace all
* thread #1: tid = 13829, 0x000003ffb2613b26 libpthread.so.0`__waitpid + 110, name = 'Main', stop reason = signal SIGSTOP
  * frame #0: 0x000003ffb2613b26 libpthread.so.0`__waitpid + 110
    frame #1: 0x000002aa0a1d3b6a mono-sgen`mono_handle_native_sigsegv(signal=<unavailable>, ctx=<unavailable>, info=<unavailable>) + 546 at mini-exceptions.c:2427
    frame #2: 0x000002aa0a142f3a mono-sgen`mono_sigsegv_signal_handler(_dummy=<unavailable>, _info=0x000003ffff0f9378, context=0x000003ffff0f93f8) + 370 at mini-runtime.c:2873

  thread #2: tid = 13844, 0x000003ffb260e3ea libpthread.so.0`__pthread_cond_wait + 402, name = 'SGen worker', stop reason = signal SIGSTOP
    frame #0: 0x000003ffb260e3ea libpthread.so.0`__pthread_cond_wait + 402
    frame #1: 0x000002aa0a36519a mono-sgen`thread_func + 18 at mono-os-mutex.h:107
    frame #2: 0x000002aa0a365188 mono-sgen`thread_func(thread_data=0x0000000000000000) + 520 at sgen-thread-pool.c:110
    frame #3: 0x000003ffb2607f12 libpthread.so.0`start_thread + 210

  thread #3: tid = 13845, 0x000003ffb2611916 libpthread.so.0`do_futex_wait.constprop.1 + 70, name = 'Finalizer', stop reason = signal SIGSTOP
    frame #0: 0x000003ffb2611916 libpthread.so.0`do_futex_wait.constprop.1 + 70
    frame #1: 0x000003ffb2611a00 libpthread.so.0`__new_sem_wait_slow.constprop.0 + 136
    frame #2: 0x000002aa0a2e9f02 mono-sgen`finalizer_thread + 12 at mono-os-semaphore.h:166
    frame #3: 0x000002aa0a2e9ef6 mono-sgen`finalizer_thread + 14 at mono-coop-semaphore.h:40
    frame #4: 0x000002aa0a2e9ee8 mono-sgen`finalizer_thread(unused=<unavailable>) + 744 at gc.c:761
    frame #5: 0x000002aa0a2c5c7c mono-sgen`start_wrapper + 428 at threads.c:740
    frame #6: 0x000002aa0a2c5ad0 mono-sgen`start_wrapper(data=<unavailable>) + 64 at threads.c:788
    frame #7: 0x000002aa0a39b0a4 mono-sgen`inner_start_thread(arg=<unavailable>) + 228 at mono-threads-posix.c:92
    frame #8: 0x000003ffb2607f12 libpthread.so.0`start_thread + 210
(lldb) detach
Process 13829 detached
(lldb) (lldb) quit

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

/bin/sh: line 1: 13829 Aborted                 (core dumped) MONO_PATH="./../class/lib/net_4_x:$MONO_PATH" /home/sharkcz/mono/mono-4.6.2/runtime/mono-wrapper ./../class/lib/net_4_x/mdoc.exe --debug assemble -o cs-errors -f error cs-errors.config
make[7]: *** [Makefile:149: cs-errors.tree] Error 134
make[6]: *** [../build/rules.make:221: do-all] Error 2
make[5]: *** [build/rules.make:248: all-recursive] Error 1
make[4]: *** [Makefile:49: profile-do--net_4_x--all] Error 2
make[3]: *** [Makefile:45: profiles-do--all] Error 2
make[2]: *** [Makefile:543: all-local] Error 2
make[2]: Leaving directory '/home/sharkcz/mono/mono-4.6.2/runtime'
make[1]: *** [Makefile:512: all-recursive] Error 1
make[1]: Leaving directory '/home/sharkcz/mono/mono-4.6.2'
make: *** [Makefile:441: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.sU4ejs (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.sU4ejs (%build)
Could not execute local: Non zero exit


Build in koji fails the same way (eg. http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2409201). Also fails with both hardening enabled (our default) and disabled.

Version-Release number of selected component (if applicable):
mono-4.6.2-1.fc26

Build environment:
Fedora Rawhide - locally or koji chroot
Comment 1 Dan Horák 2016-11-23 16:58:52 UTC 
when running mdoc under gdb:

[sharkcz@devel11 docs]$ gdb /home/sharkcz/mono/mono-4.6.2/mono/mini/mono
GNU gdb (GDB) Fedora 7.12-29.fc26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/sharkcz/mono/mono-4.6.2/mono/mini/mono...done.
(gdb) set args ./../class/lib/net_4_x/mdoc.exe --debug assemble -o cs-errors -f error cs-errors.config
(gdb) run
Starting program: /home/sharkcz/mono/mono-4.6.2/mono/mini/mono ./../class/lib/net_4_x/mdoc.exe --debug assemble -o cs-errors -f error cs-errors.config
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.24.90-12.fc26.s390x glibc-2.24.90-13.fc26.s390x
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x3fff67ff910 (LWP 4443)]
[New Thread 0x3fff4bff910 (LWP 4444)]

Thread 1 "Main" received signal SIGSEGV, Segmentation fault.
mono_metadata_get_inflated_signature (sig=sig@entry=0x2aa0075e8b0, context=context@entry=0x3f3851ec00000000) at metadata.c:2837
2837		helper.context.class_inst = context->class_inst;
(gdb) where
#0  mono_metadata_get_inflated_signature (sig=sig@entry=0x2aa0075e8b0, context=context@entry=0x3f3851ec00000000) at metadata.c:2837
#1  0x000002aa0017314a in mono_method_get_signature_checked (method=method@entry=0x3ffffffcf80, image=0x2aa004e8250, image@entry=0x3ffda1fd368, token=token@entry=167772356, 
    context=context@entry=0x3f3851ec00000000, error=error@entry=0x2aa0084cc28) at loader.c:720
#2  0x000002aa0007e8be in mono_method_to_ir (cfg=cfg@entry=0x2aa0084c7a0, method=method@entry=0x2aa0073f7d8, start_bblock=<optimized out>, start_bblock@entry=0x0, end_bblock=0x2aa007f53b0, 
    end_bblock@entry=0x0, return_var=return_var@entry=0x0, inline_args=<optimized out>, inline_offset=<optimized out>, is_virtual_call=<optimized out>) at method-to-ir.c:9319
#3  0x000002aa0011b33e in mini_method_compile (method=method@entry=0x2aa0073f7d8, opts=opts@entry=370223487, domain=domain@entry=0x2aa004231e0, flags=flags@entry=JIT_FLAG_RUN_CCTORS, 
    parts=parts@entry=0, aot_method_index=<optimized out>) at mini.c:3516
#4  0x000002aa0011d346 in mono_jit_compile_method_inner (method=method@entry=0x2aa0073f7d8, target_domain=target_domain@entry=0x2aa004231e0, opt=opt@entry=370223487, 
    error=error@entry=0x3ffffffcf80) at mini.c:4197
#5  0x000002aa00041dca in mono_jit_compile_method_with_opt (method=method@entry=0x2aa0073f7d8, opt=370223487, error=error@entry=0x3ffffffcf80) at mini-runtime.c:1910
#6  0x000002aa00042662 in mono_jit_compile_method (method=method@entry=0x2aa0073f7d8, error=error@entry=0x3ffffffcf80) at mini-runtime.c:1954
#7  0x000002aa000d588e in common_call_trampoline (regs=regs@entry=0x3ffffffd0f0, code=code@entry=0x3fffddb033c "\247\t", m=m@entry=0x2aa0073f7d8, vt=vt@entry=0x0, 
    vtable_slot=<optimized out>, vtable_slot@entry=0x0, error=0x3ffffffcf80) at mini-trampolines.c:702
#8  0x000002aa000d5fbc in mono_magic_trampoline (regs=0x3ffffffd0f0, code=0x3fffddb033c "\247\t", arg=0x2aa0073f7d8, tramp=<optimized out>) at mini-trampolines.c:828
#9  0x000003fffdfe60e2 in ?? ()
#10 0x000003fffddb033c in ?? ()
#11 0x000003fffddcf0f8 in ?? ()
#12 0x000003fffddceeea in ?? ()
#13 0x000003fffddce874 in ?? ()
#14 0x000003fffddce6f2 in ?? ()
#15 0x000003fffddce416 in ?? ()
#16 0x000003fffdde4000 in ?? ()
#17 0x000003fffdde381a in ?? ()
#18 0x000003fffdde34ba in ?? ()
#19 0x000003fffdde32f2 in ?? ()
#20 0x000003fffdde323a in ?? ()
#21 0x000003fffdde2fce in ?? ()
#22 0x000003fffdde29ee in ?? ()
#23 0x000003fffdde254e in ?? ()
#24 0x000003fffddfd010 in ?? ()
#25 0x000003fffdfd4e30 in ?? ()
#26 0x000003fffdfd368a in ?? ()
PC not saved
Comment 2 Dan Horák 2016-11-23 18:45:20 UTC 
So it's more likely a gcc compiler issue than mono issue. After switching the default optimization for the build from -O2 to -O1 the build passes (no crash in mdoc).

The system compiler is gcc-6.2.1-2.fc26.s390x
Comment 3 Dan Horák 2016-11-23 18:45:48 UTC 
And the fun now begins ...
Comment 4 Dan Horák 2016-11-24 11:02:19 UTC 
next step - method-to-ir.c is miscompiled with -O2 -mcpu=z10
Comment 5 Dan Horák 2016-11-24 16:31:51 UTC 
3 places were identified as requiring -O1 for the mdoc tool to function correctly, the ir-emit.h header with a number of inline functions and macros and the mini_emit_inst_for_method() + link_bblock() functions

--- method-to-ir.c.orig	2016-11-14 09:48:51.000000000 +0100
+++ method-to-ir.c	2016-11-24 16:56:19.742489485 +0100
@@ -68,7 +68,9 @@
 
 #include "trace.h"
 
+#pragma GCC optimize("O1")
 #include "ir-emit.h"
+#pragma GCC optimize("O2")
 
 #include "jit-icalls.h"
 #include "jit.h"
@@ -547,6 +549,7 @@
 		MONO_ADD_INS (cfg->cbb, ins);	\
 	} while (0)
 
+#pragma GCC optimize("O1")
 /* *
  * link_bblock: Links two basic blocks
  *
@@ -609,6 +612,7 @@
 	}
 }
 
+#pragma GCC optimize("O2")
 void
 mono_link_bblock (MonoCompile *cfg, MonoBasicBlock *from, MonoBasicBlock* to)
 {
@@ -5969,6 +5973,7 @@
 	return NULL;
 }
 
+#pragma GCC optimize("O1")
 static MonoInst*
 mini_emit_inst_for_method (MonoCompile *cfg, MonoMethod *cmethod, MonoMethodSignature *fsig, MonoInst **args)
 {
@@ -6869,6 +6874,7 @@
 	return mono_arch_emit_inst_for_method (cfg, cmethod, fsig, args);
 }
 
+#pragma GCC optimize("O2")
 /*
  * This entry point could be used later for arbitrary method
  * redirection.
Comment 6 Dan Horák 2016-11-24 16:36:09 UTC 
Created attachment 1223934 [details]
script to reproduce the mdoc call outside the build system
Comment 7 Dan Horák 2016-11-24 16:52:21 UTC 
the full command line for the source file should be
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libgc/include -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value -Wno-attributes -DUSE_COMPILER_TLS -I../.. -I../../eglib/src -I../../eglib/src -fvisibility=hidden -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -march=z10 -mtune=z10 -fno-strict-aliasing -std=gnu99 -fno-strict-aliasing -fwrapv -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value -Wno-attributes -mbackchain -D__USE_STRING_INLINES -Werror-implicit-function-declaration -c method-to-ir.c  -fPIC -DPIC -o .libs/libmini_la-method-to-ir.o
Comment 8 Dan Horák 2016-11-24 16:56:38 UTC 
Created attachment 1223936 [details]
preprocessed source file
Comment 9 Dan Horák 2016-11-29 16:54:33 UTC 
for the record - using -mno-lra doesn't help when compiling the method-to-ir.c file
Comment 10 Dan Horák 2017-02-20 15:14:24 UTC 
building with gcc7 and the new defaults (-march=zEC12 -mtune=z13) gives same error, the mono package is back on -march=z9-109 -mtune=z10 to be buildable, using -march=z9-109 -mtune=z13 gives even more interesting results
Comment 11 Fedora End Of Life 2017-02-28 10:39:42 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 12 Dan Horák 2017-10-30 12:11:41 UTC 
The problem is still here, rechecked with gcc-7.2.1-2.fc26.s390x building mono-4.8.0-12.fc28
Comment 13 Fedora End Of Life 2018-02-20 15:38:21 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
Comment 14 Dan Horák 2018-06-07 08:24:04 UTC 
Starting with F-28 (gcc8?) Mono is broken even more on s390x, the workaround is to built with -O1 globally until we know more.
Comment 15 Ben Cotton 2019-05-02 21:38:11 UTC 
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 16 Ben Cotton 2019-05-28 20:32:40 UTC 
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 17 Dan Horák 2020-07-22 07:13:47 UTC 
For the record - not sure if there was a change in GCC (>=9) or in Mono (more likely), but the problem went away.
Note You need to log in before you can comment on or make changes to this bug.