Snapshot gcc-11-20211009 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20211009/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote:
> The question is still if we can avoid a new SONAME for >99% of our users
> for no gain at all for them. Is there a possibility of aliasing the
> SONAME somehow (grasping at straws here)?
I'd hope Debian can just
ln -sf libgfortran.s
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote:
>
>
> On 09.10.21 01:18, Iain Sandoe wrote:
>>> I meant the case where the user writes, with an old, KIND=16 is double
>>> double compiler,
>>>
>>> subroutine foo(a)
>>>real(kind=16) :: a
>>>a = a + 1._16
>>> end subroutine foo
>>>
>
On 09.10.21 01:18, Iain Sandoe wrote:
I meant the case where the user writes, with an old, KIND=16 is double
double compiler,
subroutine foo(a)
real(kind=16) :: a
a = a + 1._16
end subroutine foo
and puts it in a library or an old object file, and in new code with an
IEEE QP compi
On Okt 09 2021, Thomas Koenig via Fortran wrote:
> There is no choice - we need to make object code compiled by the user
> incompatible between the old and the new format on the systems where
> we make the switch.
If you link, but not recompile, object files compiled against different
versions of
