On 07.10.21 17:33, Jakub Jelinek wrote:
It will also be a compatibility issue if users have code compiled on a LE
system with GCC 11 and earlier with KIND=16, it will not link with GCC 12.
libgfortran ABI changed multiple times in the past already, e.g. the
so.1 -> so.2 transition in 4.2
so.2
On Thu, Oct 07, 2021 at 09:59:00PM +0800, Chung-Lin Tang wrote:
> this patch add support for "strictly-structured blocks" introduced in OpenMP
> 5.1,
> basically allowing BLOCK constructs to serve as the body for directives:
>
> !$omp target
> block
> ...
> end block
> [!$omp end target] !! en
Hi Chung-Lin,
On 07.10.21 15:59, Chung-Lin Tang wrote:
this patch add support for "strictly-structured blocks" introduced in
OpenMP 5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote:
> On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> > On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > > I tried this at one point. There are a lot of hidden assumptions that
> > > the kind
> > > number is
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy arg
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem i
Hi all,
this patch add support for "strictly-structured blocks" introduced in OpenMP
5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
!$omp parallel
block
...
end block
...
!$omp e
On 07/10/2021 11:01, Jakub Jelinek wrote:
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
On Okt 07 2021, Alastair McKinstry wrote:
I strongly advise against this -- identical SONAMEs for the libraries on
all architectures is a key assumption on all Debian-based distributions
On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote:
> On Okt 07 2021, Alastair McKinstry wrote:
>
> > I strongly advise against this -- identical SONAMEs for the libraries on
> > all architectures is a key assumption on all Debian-based distributions
> > and designs
>
> Even glibc ha
On Okt 07 2021, Alastair McKinstry wrote:
> I strongly advise against this -- identical SONAMEs for the libraries on
> all architectures is a key assumption on all Debian-based distributions
> and designs
Even glibc has differing sonames on some architectures. And libgcc_s,
too.
Andreas.
--
On 06/10/2021 07:59, Thomas Koenig via Fortran wrote:
On 05.10.21 23:54, Segher Boessenkool wrote:
Hi!
On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
Based on some IRC discussion, yet another option would be bump
libgfortra
On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote:
> On 07.10.21 05:35, Michael Meissner via Fortran wrote:
> > I tried this at one point. There are a lot of hidden assumptions that the
> > kind
> > number is the number of bytes. I'm sure it can be tracked down, but the
> > problem i
12 matches
Mail list logo
