[Bug fortran/96033] New: error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 Bug ID: 96033 Summary: error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: skorzennik at cfa dot harvard.edu Target Milestone: --- Failed to configure to build mvapich2-2.3.[14] (both versions) using GCC 10.1.0. I have no problem building mvapich2 w/ GCC pre-10.x (9.3, 9.2, etc...) Boils down to trying to compile conftest.f :: program main integer a real b character c call foo1(a) call foo1(b) call foo1(c) end This test code compiles fine w/ 9.3.0, or older GCC I have installed and tried (9.2.0, 7.3.0 or 4.8.5).
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 --- Comment #2 from Sylvain Korzennik --- Merci Dominique. Will transmit info to MVAPICH2 ppl. The configuration script needs to be changed, this is not "faulty code", it is a test code part of the package configuration specifically to test if the "Fortran compiler gfortran will compile files that call the same routine with arguments of different types". I ran the configurator ok by setting env vars FFLAGS and FCFLAGS to -std=legacy - hopefully it will build fine. These kind of changes make GCC harder and harder to use/maintain in a professional setting, IM(H)O. Backward compatibility of gfortran is dismal (legacy code that builds fine w/ plethora of other fortran compiler fails to build w/ gfortran - ppl were writing fortran code for quite a wile, like one big scientific package started 60+ years ago, yet gfortran is the one that can't handle it - ifort and pgfortran do fine, it was written/developed on a VAX/VMS back when - author have long retired - desn't make the code obsolete, tho). A bien entendeur.
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 --- Comment #5 from Sylvain Korzennik --- Hi Kargl, I am not interested in a protracted religious discussion, I simply do not use gfortran for my work (research), but need to provides it form my users (Smithsonian HPC cluster) as part of my duties. I've been doing HPC for 30+ years, and have used a long list of fortran compilers, all with their own extensions (SUN, VAX/VMS, CRAY, you name it) and idiosyncrasies. Most/all vendors recognize that legacy code exists, so they incorporated other's extensions and use a flexible approach to enforcing rules. GCC is the single one that decides that old code is trash and needs to be rewritten. When 64b was introduced, gfortran decided that the UNIX record integer embedded in the binary files ought to be 64b, making it impossible to use existing binary files. That's simply shooting yourself in the foot. As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the PANDORA radiative transfer code is made up of 4,559 routines. It was not well designed, but it was started in 1959, with computers and compilers that had many limitations, yet I can build it w/ Intel's and PGI's F77 compilers. It needed minor one or two tweaks for runtime errors when moved from VMS to Linux. Yet by writing parameter (MSHLNG=50) integer MSHCNO,MSHLNG dimension MSHCLR(MSHLNG) data MSHCLR,MSHCNO /MSHLNG*' ', 0/ gfortran imposes a rule that did not exist -or wasn't enforced- back when: the integer declaration must be before the parameter one. The developer used VAX/VMS tools and saw no reasons to code differently (GNU did not exists). PGI and Intel do accept this order. I would have to reorder zillions of lines of code, going thru 4,000+ routines, and re-validate this complex code... unless there is a magic/hidden flag (-std=legacy isn't helping). At the end, you get what you paid for, hence we pay for PGI and Intel's compilers. I stay away from gfortran, because I have things to get done... Best, Sylvain.
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 --- Comment #7 from Sylvain Korzennik --- Thanks for following up, Steve. I gave up on gfortran when the 64b record marker made it unusable for me. I'm not surprised it was fixed, but this pointed to poor decision making and ignoring the need to backward compatibility. When you don't need to sell your product, your "customers" needs might not be your highest priority. Backward compatibility is a wide spread problem, in commercial products (trust me, some have hear mn more than once) and in 'free' ones (the Python 2.x vs 3.x debacle comes to mind). When you've been at it for 3 decades, it matters. PANDORA can be downloaded, and it is ugly coding (I know the author, he retired a while back and I was for a while helping maintain the code), but it may be a good example why you can't easily all a sudden switch to new rules, and why we maintain multiple versions of multiple compilers. Have a great 4th of July, stay sane, safe and healthy, 6+ft away! Cheers, Sylvain
[Bug c++/92514] New: limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
Bug ID: 92514
Summary: limits:1668:7: internal compiler error: Illegal
instruction
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: skorzennik at cfa dot harvard.edu
Target Milestone: ---
Created attachment 47266
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47266&action=edit
.ii and .log files
In file included from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/bits/uniform_int_dist.h:35,
from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/bits/stl_algo.h:66,
from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/algorithm:62,
from test-array.cpp:4:
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/limits:1668:7: internal compiler
error: Illegal instruction
1668 | max() _GLIBCXX_USE_NOEXCEPT { return __FLT_MAX__; }
| ^~~
0xb5775f crash_signal
../.././gcc/toplev.c:326
attached is the output of
g++ -v -std=c++11 -save-temps test-array.cpp -o test-array
and the resulting
test-array.ii
the test code (test-array.cpp) is measly 17 lines long.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 --- Comment #2 from Sylvain Korzennik --- ==> gcc-9.2.0/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/9.2.0 \ --enable-shared \ --disable-multilib \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-bootstrap \ --with-mpc=/share/apps/tools/gcc/mpc-1.0.3 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ --with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \ |& tee do-configure.log ==> gmp-6.1.0/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/gmp-6.1.0 \ |& tee do-configure.log ==> mpc-1.0.3/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/mpc-1.0.3 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ --with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \ |& tee do-configure.log ==> mpfr-3.1.4/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/mpfr-3.1.4 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ |& tee do-configure.log I used my build of gcc 8.2.0 - compiling the same test code works w/ 8.2.0. Cheers, Sylvain -- On Thu, Nov 14, 2019 at 12:43 PM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 > > Andrew Pinski changed: > >What|Removed |Added > > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2019-11-14 > Ever confirmed|0 |1 > > --- Comment #1 from Andrew Pinski --- > Usually this crash is a sign that MPFR/GMP was compiled for the wrong CPU. > > How did you compile GCC here? How was MPFR/GMP compiled too? > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 --- Comment #3 from Sylvain Korzennik --- => gcc-9.2.0/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/9.2.0 \ --enable-shared \ --disable-multilib \ --enable-threads=posix \ --enable-__cxa_atexit \ --disable-bootstrap \ --with-mpc=/share/apps/tools/gcc/mpc-1.0.3 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ --with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \ |& tee do-configure.log ==> gmp-6.1.0/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/gmp-6.1.0 \ |& tee do-configure.log ==> mpc-1.0.3/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/mpc-1.0.3 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ --with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \ |& tee do-configure.log ==> mpfr-3.1.4/do-configure.sou <== module load gcc/8.2.0 ./configure --prefix=/share/apps/tools/gcc/mpfr-3.1.4 \ --with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \ |& tee do-configure.log I used my build of gcc 8.2.0 - compiling the same test code works w/ 8.2.0. Cheers, Sylvain -- Cheers, Sylvain -- On Thu, Nov 14, 2019 at 12:43 PM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2019-11-14 > Ever confirmed|0 |1 > > --- Comment #1 from Andrew Pinski --- > Usually this crash is a sign that MPFR/GMP was compiled for the wrong CPU. > > How did you compile GCC here? How was MPFR/GMP compiled too? > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 --- Comment #5 from Sylvain Korzennik --- Thanks for your prompt replies! 1- we use a NSF mounted disk to serve ~90 servers (~4100 cores), w/ a set of diff CPUs. It does compile fine on the server the code was built on. 2- what flags do I use to built it for all the servers pn my system? Do I need to redo this for all 4 (gcc/gmp/mpc/mpfr)? This cluster hosts the following CPUs bulldozer,haswell,piledriver,sandybridge,skylake Cheers, Sylvain -- On Thu, Nov 14, 2019 at 1:17 PM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 > > --- Comment #4 from Andrew Pinski --- > Is your MPFR/GMP/MPC compiled on a different computer and then copied > over? If > so you need an extra configure flag to them; otherwise they will be > compiled > for that computer (CPU) and will not always work on all x86_64 processors. > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 --- Comment #6 from Sylvain Korzennik --- Thanks for your prompt replies! 1- we use a NSF mounted disk to serve ~90 servers (~4100 cores), w/ a set of diff CPUs. It does compile fine on the server the code was built on. 2- what flags do I use to built it for all the servers pn my system? Do I need to redo this for all 4 (gcc/gmp/mpc/mpfr)? This cluster hosts the following CPUs bulldozer,haswell,piledriver,sandybridge,skylake Cheers, Sylvain -- Cheers, Sylvain -- On Thu, Nov 14, 2019 at 1:17 PM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 > > --- Comment #4 from Andrew Pinski --- > Is your MPFR/GMP/MPC compiled on a different computer and then copied over? > If > so you need an extra configure flag to them; otherwise they will be compiled > for that computer (CPU) and will not always work on all x86_64 processors. > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 --- Comment #9 from Sylvain Korzennik --- 1- that page does not tell me how to build a generic version ./config.guess returns the same value on ea machine, as does gcc -dumpmachine x86_64-pc-linux-gnu do I add --build=XX --host-XX or --target=XX and what XX to use? The doc is quite thin. 2- you're not telling me if I need to rebuild all 4 components. Cheers, Sylvain -- On Thu, Nov 14, 2019 at 1:39 PM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514 > > --- Comment #8 from Andrew Pinski --- > (In reply to Andrew Pinski from comment #7) > > Please read: > > https://gmplib.org/manual/Build-Options.html > > NOTE also if you compile GMP/MPF/MPC as part of the GCC build, it will do the > correct thing and compile it for a generic cpu. > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
--- Comment #11 from Sylvain Korzennik ---
Thx - for GMP, /config.guess returns
skylake-pc-linux-gnu
not
x86_64-pc-linux-gnu
hence the mess... I'll try rebuilding it w/ ./configure
--host=x86_64-pc-linux-gnu
Cheers,
Sylvain
--
On Thu, Nov 14, 2019 at 2:00 PM pinskia at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> --- Comment #10 from Andrew Pinski ---
> (In reply to Sylvain Korzennik from comment #9)
> > 1- that page does not tell me how to build a generic version
> >./config.guess returns the same value on ea machine, as does gcc
> > -dumpmachine
> > x86_64-pc-linux-gnu
> >
> > do I add --build=XX --host-XX or --target=XX and what XX to use? The
> > doc is quite thin.
>
> Well this is no longer a GCC question but rather a GMP question and you should
> ask in their mailing list. But when built inside GCC, the following configure
> options are passed to GMP:
> --build=${build_alias} --host=none-${host_vendor}-${host_os} \
> --target=none-${host_vendor}-${host_os}
>
>
>
> > 2- you're not telling me if I need to rebuild all 4 components.
>
>
> It depends on if you built them as shared libraries are static libraries. If
> as shared, 99% sure you don't need to rebuild all 4, just GMP.
>
> --
> You are receiving this mail because:
> You reported the bug.
