On Fri, Nov 19, 2021 at 01:36:33PM -0600, Peter Bergner wrote:
> On 11/19/21 1:09 PM, Thomas Koenig wrote:
> >> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> >>> Sure, we can create an IBM vendor branch.
> >>
> >> It should not be an IBM branch, we should not mix that with com
On 11/19/21 1:09 PM, Thomas Koenig wrote:
>> On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
>>> Sure, we can create an IBM vendor branch.
>>
>> It should not be an IBM branch, we should not mix that with community
>> stuff. Instead it should be in devel/.
Agreed, this would be
Hi Segher,
On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
I assume we would to the development on a branch. My git fu
is extremely weak, so I would appreciate if somebody did that
for me.
Sure, we can create an IBM vendor branch.
It should not be an IBM branch, we should
On Mon, Nov 15, 2021 at 06:42:18PM -0500, Michael Meissner wrote:
> > I assume we would to the development on a branch. My git fu
> > is extremely weak, so I would appreciate if somebody did that
> > for me.
>
> Sure, we can create an IBM vendor branch.
It should not be an IBM branch, we should
On Tue, Nov 16, 2021 at 08:51:03AM +0100, Thomas Koenig wrote:
> If you could start working on the points above, that would be great.
Just small completely untested step, which IMHO should ensure that
on powerpc64le-*linux* (unless --with-long-double-64 configured)
we build libgfortran by default
On 16.11.21 00:42, Michael Meissner wrote:
On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote:
Hi,
is there an update on this? I am still waiting on a response for
the account on the development machine.
I assume we would to the development on a branch. My git fu
is extremely weak
On Mon, Nov 15, 2021 at 09:27:38PM +0100, Thomas Koenig wrote:
> Hi,
>
> is there an update on this? I am still waiting on a response for
> the account on the development machine.
>
> I assume we would to the development on a branch. My git fu
> is extremely weak, so I would appreciate if someb
On 11/15/21 2:27 PM, Thomas Koenig wrote:
> I am still waiting on a response for the account on the development machine.
I haven't heard anything about the P9 partition either.
I'll ping OSU about that now.
Peter
Hi,
is there an update on this? I am still waiting on a response for
the account on the development machine.
I assume we would to the development on a branch. My git fu
is extremely weak, so I would appreciate if somebody did that
for me.
Is it actually possible to implement what I wrote in t
On Tue, Nov 02, 2021 at 07:19:10AM +0100, Thomas Koenig wrote:
>
> On 01.11.21 18:45, Jakub Jelinek wrote:
> > Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
> > -mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
> > ABI compatible with both, then we don't need
On 01.11.21 18:45, Jakub Jelinek wrote:
Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs.
-mabi=ibmlongdouble choosing between the two ABIs and libgfortran being
ABI compatible with both, then we don't need to bump soname.
Sounds like one major pain solved. I think we should do i
On Mon, Nov 01, 2021 at 10:54:27AM -0500, Bill Schmidt wrote:
> Hi Thomas,
>
> To me this looks excellent. If you feel that support for both forms is
> achievable,
> that's certainly superior. We had previously been concerned about whether the
> necessary name mangling support would be possible
On Mon, Nov 01, 2021 at 06:32:51PM +0100, Thomas Koenig wrote:
> f->value.function.name
> = gfc_get_string (PREFIX ("matmul_%c%d"), gfc_type_letter (f->ts.type),
> f->ts.kind);
>
> Easy enough to add something there if ts.type is BT_REAL,
> ts.kind is 16 and the compiler
Hi Bill,
We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.
We can always add a letter to the kind number, or use a different
number in the encoding, or someting
This has to be done i
Hi Thomas,
To me this looks excellent. If you feel that support for both forms is
achievable,
that's certainly superior. We had previously been concerned about whether the
necessary name mangling support would be possible, but it sounds like you aren't
overly worried about that.
I'll let Mike
Hi,
I have put together a summary of what users should see
as a change. I've made this a diff against the current
documentation. This is an RFC, please feel free to
suggest any changes.
I have put in a few remarks among the diff.
If there is general agreement that this is the best way forward
16 matches
Mail list logo
