[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Michael Fechtelkord
Michael.Fechtelkord at ruhr-uni-bochum.de
Mon Oct 28 08:39:17 CET 2024
Dear Laurence,
you are absolutely right. I have overseen the functions following the
KSum3 subroutine. They all fail. The compilation of charge.f does only
succeed with no optimization using (-O0). I will also report this to
Intel, hoping they will find the bug and publish a new compiler version.
The -O0 flag narrows down the number of errors significantly and only a
few still remain:
Compile time errors (if any) were:
SRC_lapw5/compile.msg:SearchZ_tmp_.F(114): error #5623: **Internal
compiler error: internal abort** Please report this error along with the
circumstances in which it occurred in a Software Problem Report. Note:
File and line given may not be explicit cause of this error.
SRC_lapw5/compile.msg:SearchZ_tmp_.F(114): error #5623: **Internal
compiler error: internal abort** Please report this error along with the
circumstances in which it occurred in a Software Problem Report. Note:
File and line given may not be explicit cause of this error.
SRC_3ddens/compile.msg:make: *** [Makefile:65: 3ddens] Fehler 1
SRC_dstart/compile.msg:make[1]: *** [Makefile:99: dstart] Fehler 1
SRC_dstart/compile.msg:make: *** [Makefile:90: seq] Fehler 2
SRC_lapw5/compile.msg:make[1]: *** [Makefile:122: SearchZ.o] Fehler 3
SRC_lapw5/compile.msg:make: *** [Makefile:74: real] Fehler 2
SRC_lapw5/compile.msg:make[1]: *** [Makefile:122: SearchZ.o] Fehler 3
SRC_lapw5/compile.msg:make: *** [Makefile:77: complex] Fehler 2
I will look up the compile.msg files, if I can find something helpful.
Also still an Internal compiler error remains for SearchZ_tmp_.F. Errors
are CPU independent (tried it on a 14900k as well as a 9900k).
Best regards,
Michael
Am 27.10.2024 um 22:58 schrieb Laurence Marks:
> Ksum3.f is short, please recheck.
>
> Note, these are not coding errors. The message from Intel indicates
> that their compiler messed up. How...unclear. It would be good to
> report the issue to Intel.
>
> Try -O1, in other words reduce the optimization until the issue goes away.
>
> ---
> Emeritus Professor Laurence Marks (Laurie)
> www.numis.northwestern.edu <http://www.numis.northwestern.edu>
> https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en
> <https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en>
> "Research is to see what everybody else has seen, and to think what
> nobody else has thought" Albert Szent-Györgyi
>
> On Sun, Oct 27, 2024, 16:12 Michael Fechtelkord via Wien
> <wien at zeus.theochem.tuwien.ac.at> wrote:
>
> Hello Peter,
>
>
> I isolated the two subroutines causing the error.
>
>
> Those are SUBROUTINE CHARGEF and subroutine KSum3, which are the two
> longest subroutines ( 106 and 122 lines). All others are quite
> short and
> compile without errors. I assume the length leads to the crashes.
>
> I will try also another computer to exclude hardware issues.
>
>
> Best regards,
>
> Michael
>
>
>
> Am 27.10.2024 um 20:04 schrieb Peter Blaha:
> > charge.f is in SRC_Globals (in the other SRC_* dirs there
> should only
> > be a softlink to it.
> >
> > charge.f contains several subroutines/functions. Maybe this fact or
> > that there are too many may cause the problem.
> >
> > The way to debug is to split this charge.f into several files
> (maybe
> > use "bisection") and compile each part individually until the
> problem
> > can be located (or is gone).
> >
> > In SRC_Globals split it into two parts and
> >
> > mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> > traceback -assume buffered_io
> -I/opt/intel/oneapi/mkl/2025.0/include -
> > qopenmp -DParallel -c c1.f
> >
> > and
> >
> > mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> > traceback -assume buffered_io
> -I/opt/intel/oneapi/mkl/2025.0/include -
> > qopenmp -DParallel -c c2.f
> >
> >
> > If a problem occurs, split further ...
> > ---------------------------------------------
> > SearchZ.F (was added by L. Marks)
> >
> > maybe one needs a "external RHOSTM" statement at the beginning.
> >
> > > call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)
> > > ---------------------------^
> >
> > Rhostm is a function, passed into a subroutine ....
> >
> >
> > Am 27.10.2024 um 19:17 schrieb Michael Fechtelkord via Wien:
> >> Dear all,
> >>
> >>
> >> the libxc problem does not longer exist. I used the newest ifx
> >> version now. Most parts of WIEN2k compile without problems. Two
> >> source files still make problems.
> >>
> >>
> >> 1) charge.f (in different source directories, same error always)
> >>
> >> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip
> -DINTEL_VML -
> >> traceback -assume buffered_io
> -I/opt/intel/oneapi/mkl/2025.0/include
> >> - qopenmp -DParallel -c charge.f
> >> #0 0x000000000310cce1
> >> #1 0x00000000031715d7
> >> #2 0x0000000003171705
> >> #3 0x0000148436a57980
> >> #4 0x0000000002291d60
> >> #5 0x00000000044a6048
> >> #6 0x0000000002a7aa37
> >> #7 0x0000000002a7a57c
> >> #8 0x0000000002c4c4ca
> >> #9 0x00000000029b8173
> >> #10 0x00000000028743b2
> >> #11 0x000000000260103c
> >> #12 0x000000000260022d
> >> #13 0x0000000002600181
> >> #14 0x00000000029ddd62
> >> #15 0x00000000025a617c
> >> #16 0x00000000022e8064
> >> #17 0x00000000022e7e89
> >> #18 0x000000000225e401
> >> #19 0x000000000225e131
> >> #20 0x000000000237461a
> >> #21 0x00000000023743f1
> >> #22 0x00000000028924e9
> >> #23 0x00000000030a9e9a
> >> #24 0x00000000030a7bd7
> >> #25 0x00000000030537eb
> >> #26 0x000000000322f884
> >> #27 0x0000148436a40eec
> >> #28 0x0000148436a40fb5 __libc_start_main + 135
> >> #29 0x0000000002e8a34e
> >>
> >> charge.f: error #5633: **Internal compiler error: segmentation
> >> violation signal raised** Please report this error along with the
> >> circumstances in which it occurred in a So
> >> ftware Problem Report. Note: File and line given may not be
> explicit
> >> cause of this error.
> >> compilation aborted for charge.f (code 3)
> >>
> >> 2) SearchZ_tmp_.F
> >>
> >> ifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> >> traceback -assume buffered_io
> -I/opt/intel/oneapi/mkl/2025.0/include
> >> -c SearchZ_tmp_.F
> >> #0 0x000000000310cce1
> >> #1 0x00000000031715d7
> >> #2 0x000000000315cfda
> >> #3 0x0000000003073fb6
> >> #4 0x00000000030c411e
> >> #5 0x00000000031063e6
> >> #6 0x000000000310002f
> >> #7 0x00000000030fe080
> >> #8 0x00000000030fd24d
> >> #9 0x00000000031bf819
> >> #10 0x00000000031bfe05
> >> #11 0x00000000031bcff8
> >> #12 0x00000000031bf819
> >> #13 0x00000000031bfe05
> >> #14 0x00000000031c2909
> >> #15 0x00000000031bf819
> >> #16 0x00000000031bcc3e
> >> #17 0x00000000031bf819
> >> #18 0x000000000305397b
> >> #19 0x0000000003053317
> >> #20 0x000000000322f884
> >> #21 0x000015481a240eec
> >> #22 0x000015481a240fb5 __libc_start_main + 135
> >> #23 0x0000000002e8a34e
> >>
> >> SearchZ_tmp_.F(114): error #5623: **Internal compiler error:
> internal
> >> abort** Please report this error along with the circumstances in
> >> which it occurred in a Software Prob
> >> lem Report. Note: File and line given may not be explicit
> cause of
> >> this error.
> >> call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)
> >> ---------------------------^
> >> compilation aborted for SearchZ_tmp_.F (code 3)
> >>
> >>
> >> Best regards,
> >>
> >> Michael
> >>
> >>
> >>
> >>
> >> Am 27.10.2024 um 15:21 schrieb Michael Fechtelkord via Wien:
> >>> Dear all,
> >>>
> >>>
> >>> just a few new results and informatuion using the Intel ifx
> >>> compiler. ELPA, FFTW, LIBXC and MPICH compile fine and also check
> >>> procedure shows no errors.
> >>>
> >>>
> >>> WIEN2k seems to have problems when using no explicit types for
> >>> variables. A short summary of the errors all in libxc_mod.F:
> >>>
> >>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in
> opening
> >>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This
> derived type
> >>> name has not been declared. [XC_F03_FUNC_T]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived
> >>> type name has not been declared. [XC_F03_FUNC_INFO_T]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_FUNC_X]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_FUNC_C]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_POLARIZED]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_INFO_C]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name
> does
> >>> not have a type, and must have an explicit type.
> [XC_F03_FUNC_GET_INFO]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(39): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_INFO_X]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name
> does
> >>> not have a type, and must have an explicit type.
> >>> [XC_F03_FUNC_INFO_GET_FLAGS]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in
> opening
> >>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This
> derived type
> >>> name has not been declared. [XC_F03_FUNC_T]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived
> >>> type name has not been declared. [XC_F03_FUNC_INFO_T]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_FUNC_X]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_FUNC_C]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_POLARIZED]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name
> does
> >>> not have a type, and must have an explicit type. [XC_INFO_C]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name
> does
> >>> not have a type, and must have an explicit type.
> [XC_F03_FUNC_GET_INFO]
> >>> SRC_lapw0/compile.msg:l
> <https://www.google.com/maps/search/C_lapw0%2Fcompile.msg:l?entry=gmail&source=g>ibxc_mod.F(39):
> error #6404: This name does
> >>> not have a type, and must have an explicit type. [XC_INFO_X]
> >>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name
> does
> >>> not have a type, and must have an explicit type.
> >>> [XC_F03_FUNC_INFO_GET_FLAGS]
> >>>
> >>> In addition Segmenation violation signals occur in several
> modules.
> >>>
> >>>
> >>> Best regards
> >>>
> >>> Michael
> >>>
> >
> --
> Dr. Michael Fechtelkord
>
> Institut für Geologie, Mineralogie und Geophysik
> Ruhr-Universität Bochum
> Universitätsstr. 150
> D-44780 Bochum
>
> Phone: +49 (234) 32-24380
> Fax: +49 (234) 32-04380
> Email: Michael.Fechtelkord at ruhr-uni-bochum.de
> Web Page:
> https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
--
Dr. Michael Fechtelkord
Institut für Geologie, Mineralogie und Geophysik
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum
Phone: +49 (234) 32-24380
Fax: +49 (234) 32-04380
Email:Michael.Fechtelkord at ruhr-uni-bochum.de
Web Page:https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241028/050f8c76/attachment.htm>
More information about the Wien
mailing list