This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][fortran] Rework allocator library interface
On Thu, 14 Dec 2006, Tobias Burnus wrote:
> Hi all,
>
> Richard Guenther wrote:
> >> The patch is OK for trunk and 4.2. Please wait a week or so before
> >> committing to 4.2, to catch regressions that might still occur.
> >>
> > Committed to trunk. I have omitted the hunk bumping the shared library
> > version as this will be not necessary if we backport to 4.2.
> >
>
> I only want to point out that this change breaks the AMD Core Math
> Library 3.6.
> That library contains:
>
> /opt/acml3.6.0/gfortran64/lib/libacml_mv.so
> /opt/acml3.6.0/gfortran64/lib/libacml.so
>
> /opt/acml3.6.0/gfortran64_mp/lib/libacml_mp.so
> /opt/acml3.6.0/gfortran64_mp/lib/libacml_mv.so
>
> The first two are the serial version, compiled with gfortran 4.1.0;
> the second pair is the OpenMP version, compiled with "4.2.0 20061114".
>
> Due to the allocate change, gfortran 4.3 programs linked to the OpenMP
> version of ACML crash with:
>
> #0 allocate_size (size=<value optimized out>, stat=0x500010) at /gcc/libgfortran/runtime/memory.c:187
> 187 *stat = 1;
> #0 allocate_size (size=<value optimized out>, stat=0x500010) at /gcc/libgfortran/runtime/memory.c:187
> #1 0x00002ba64ed18acd in zungtr8z_ () from /opt/acml3.6.0/gfortran64_mp/lib/libacml_mp.so
>
>
> That their is no link-time error but a crash is rather bad :-(
>
> Solutions:
>
> - Simply wait - there will be surely a new ACML libraries and for
> non-vendor libraries one can recompile oneself
> (if one has figured out that the crash is due to the compiler update and
> too old libraries.)
>
> - Bump the library version number (we did this already recently in the
> 4.2-experimental version, which also broke the ACML. Upon request, one
> could then get a semi-official version compiled with a newer 4.2 compiler.)
>
> - Use other names for the new functions (= manual symbol versioning)
>
> - Use (real) symbol versioning (unlikely to happen before 4.2.0 is released)
I don't think symbol versioning will help retro-actively here, so to
keep unreleased 4.2 libgfortran working we need to either bump the library
version number or use new names and continue providing the old ones.
We can change the function names without providing the old ones which
will result in linker errors rather than crashes.
Until the change is backported to the 4.2 branch we have the (bad)
situation that the two libgfortrans claim to be compatible but are not.
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs