[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Laurence Marks
laurence.marks at gmail.com
Sun Oct 27 22:58:09 CET 2024
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
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241027/6abc4a93/attachment.htm>
More information about the Wien
mailing list