Bug 1895612

Summary: Internal compiler error on several architectures building OpenMolcas-20.10
Product: [Fedora] Fedora Reporter: Susi Lehtola <susi.lehtola>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: ajax, aoliva, dmalcolm, ffesti, fweimer, igor.raits, jakub, jonathan, j, jwakely, law, mpolacek, msebor, nickc, pmatilai, sipoyare, torsava
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gcc-10.2.1-9.fc33 gcc-10.2.1-9.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-30 01:08:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Susi Lehtola 2020-11-07 18:12:52 UTC
Koji scratch builds of OpenMolcas-20.10-1.fc34 on the s390x architecture result in the error

[ 82%] Building Fortran object CMakeFiles/rasscf.dir/src/rasscf/proc_inp.f.o
/usr/bin/gfortran -D_I8_ -D_LINUX_ -D_MOLCAS_ -D_OPENBLAS_ -I/builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/src/Include -I/builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/s390x-redhat-linux-gnu/CMakeFiles/include -I/builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/s390x-redhat-linux-gnu/CMakeFiles/mod -I/builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/src/rasscf -I/builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/s390x-redhat-linux-gnu/CMakeFiles/mod/rasscf -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables -fstack-clash-protection -cpp -fopenmp -fdefault-integer-8 -fPIC -fallow-argument-mismatch  -fno-aggressive-loop-optimizations -JCMakeFiles/mod/rasscf -c /builddir/build/BUILD/OpenMolcas-v20.10-01fe7a2bdca51c51d183f3061b0ee9c631bf9bec/src/rasscf/proc_inp.f -o CMakeFiles/rasscf.dir/src/rasscf/proc_inp.f.o
f951: Warning: '-Werror=' argument '-Werror=format-security' is not valid for Fortran
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | annobin: Generate final annotations
PLUGIN_START_UNIT                | annobin: Generate global annotations
PLUGIN_ALL_PASSES_START          | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END            | annobin: Register per-function end symbol
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

Comment 3 Nick Clifton 2020-11-09 12:26:49 UTC
I suspect that the -Werror=format-security option is being added by this line from /usr/lib/rpm/redhat/macros:

  %__global_compiler_flags	-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches %{_hardened_cflags} %{_annotated_cflags}%{?_legacy_common_support: -fcommon}

It would be convenient if gfortran could silently accept the -Werror=format-security option as otherwise it will be necessary to update the redhat-rpm-config package, which could take a long time.

Comment 4 Jakub Jelinek 2020-11-09 12:33:25 UTC
-Werror=format-security (and -Wformat etc.) is not really meaningful for Fortran, it doesn't have printf style APIs at all.
So, this should be instead fixed in redhat-rpm-config, -Werror=format-security moved from __global_compiler_flags to C/C++ specific options.
I don't see why changing redhat-rpm-config would need to take a long time.

Comment 5 Nick Clifton 2020-11-09 12:52:41 UTC
OK, well I will reassign it and see what happens.

Comment 6 Susi Lehtola 2020-11-09 14:28:15 UTC
Is the internal compiler error really caused by -Werror=format-security? It has been around for years and hasn't caused problems before...

Comment 7 Jakub Jelinek 2020-11-09 15:46:41 UTC
My comment was just a response to Nick's comment, didn't comment about anything else.
The ICE boils down to:
module fortran_strings
  interface operator(.in.)
    module procedure substr_in_str
  end interface
contains
  pure function to_upper (in_str) result (string)
    character(len=*), intent(in) :: in_str
    character(len=len(in_str)) :: string
    string = in_str
  end function to_upper
  logical pure function substr_in_str(substring, string)
    character(len=*), intent(in) :: string, substring
    substr_in_str=.false.
  end function
end module
subroutine foo ()
  use fortran_strings, only : to_upper, operator(.in.)
  character(len=8) str
  logical l
  str = 'abcdefgh'
  l = 'I' .in. to_upper(str)
end subroutine foo
and ICEs somewhere in gmp:
#0  0xf7c3e6b5 in __gmpz_sizeinbase () from /lib/libgmp.so.10
#1  0x08fb09d0 in wi::from_mpz (type=0xf7ffb540, x=0x9bf0860, wrap=true) at ../../gcc/wide-int.cc:269
#2  0x08d721eb in gfc_mpz_get_hwi (op=<optimized out>) at ../../gcc/fortran/misc.c:426
#3  gfc_typename (ex=0x9bed0f0) at ../../gcc/fortran/misc.c:228
#4  0x08db293f in resolve_operator (e=e@entry=0x9bed180) at ../../gcc/fortran/resolve.c:4274
#5  0x08dad02f in gfc_resolve_expr (e=0x9bed180) at ../../gcc/fortran/resolve.c:7035
#6  0x08dbe487 in gfc_resolve_expr (e=<optimized out>) at ../../gcc/fortran/resolve.c:7009
#7  gfc_resolve_code (code=<optimized out>, ns=<optimized out>) at ../../gcc/fortran/resolve.c:11755
#8  0x08dc0685 in resolve_codes (ns=ns@entry=0x9bdb4f0) at ../../gcc/fortran/resolve.c:17283
#9  0x08dac845 in gfc_resolve (ns=0x9bdb4f0) at ../../gcc/fortran/resolve.c:17318
#10 gfc_resolve (ns=0x9bdb4f0) at ../../gcc/fortran/resolve.c:17297
#11 0x08d9e4fb in resolve_all_program_units (gfc_global_ns_list=<optimized out>) at ../../gcc/fortran/parse.c:6245
#12 gfc_parse_file () at ../../gcc/fortran/parse.c:6497
#13 0x08e0a04d in gfc_be_parse_file () at ../../gcc/fortran/f95-lang.c:210
#14 0x08f3f61e in compile_file () at ../../gcc/toplev.c:459
#15 0x089c8bdf in do_compile () at ../../gcc/toplev.c:2289
#16 toplev::main (this=0xffffd58e, argc=<optimized out>, argv=<optimized out>) at ../../gcc/toplev.c:2428
#17 0x089cb385 in main (argc=3, argv=0xffffd664) at ../../gcc/main.c:39

Comment 8 Florian Weimer 2020-11-09 16:06:32 UTC
I second Susis comment 6. How is this related to -Werror=format?

An ICE is an ICE and should be fixed in GCC.

Comment 9 Nick Clifton 2020-11-09 17:18:59 UTC
Sorry - that was my nad.  I was distracted by the -Werror-format-security message and I missed the ICE.

Comment 10 Panu Matilainen 2020-11-10 07:01:20 UTC
Moving format-security warning/error switches to C/C++ specific flags is a perfectly reasonable suggestion though :)

Comment 11 Fedora Update System 2020-11-27 09:52:53 UTC
FEDORA-2020-25659ed5b0 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-25659ed5b0

Comment 12 Fedora Update System 2020-11-27 09:54:16 UTC
FEDORA-2020-9e8ad5b507 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9e8ad5b507

Comment 13 Fedora Update System 2020-11-28 02:55:33 UTC
FEDORA-2020-25659ed5b0 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-25659ed5b0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-25659ed5b0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2020-11-28 03:04:15 UTC
FEDORA-2020-9e8ad5b507 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9e8ad5b507`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9e8ad5b507

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Fedora Update System 2020-11-30 01:08:55 UTC
FEDORA-2020-25659ed5b0 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2020-12-13 02:34:51 UTC
FEDORA-2020-9e8ad5b507 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.