Bug 1895612 - Internal compiler error on several architectures building OpenMolcas-20.10
Summary: Internal compiler error on several architectures building OpenMolcas-20.10
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-07 18:12 UTC by Susi Lehtola
Modified: 2020-12-13 02:34 UTC (History)
17 users (show)

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:
Clone Of:
Environment:
Last Closed: 2020-11-30 01:08:55 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 97768 0 P3 UNCONFIRMED [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas 2020-11-09 16:43:03 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.