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
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a 1-liner. :-)
That fix is available on mainline and on 11-branc
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
Ping.
On 2021/11/4 4:23 PM, Chung-Lin Tang wrote:
Hi Jakub,
As Thomas reported and submitted a patch a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519932.html
https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522738.html
There's an issue with the Fortran front-end when mapp
Hi Jakub,
attached is a rebased version of this "OpenMP fixes/adjustments" patch.
This version removes some of the (ort == C_ORT_OMP || ort == C_ORT_ACC) stuff
that's not needed
in handle_omp_array_sections_1 and [c_]finish_omp_clauses.
Note that this is meant to be patched atop of the recent a
Hi!
For DW_AT_rank we were emitting
.uleb128 0x4# DW_AT_rank
.byte 0x97# DW_OP_push_object_address
.byte 0x23# DW_OP_plus_uconst
.uleb128 0x1c
.byte 0x6 # DW_OP_deref
on 64-bit and
.uleb128 0x4# DW_AT_rank
.byte 0x
