Hi Tobias,
> @All, Harald: Does the attached patch make sense?
first of all: sorry for the really badly designed testcase.
The best solution has already been discussed in this thread,
which is to replace
integer(16), parameter :: m1 = 9007199254740992_16!2**53
integer(16)
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>integer(16), parameter :: m2 = 103845937170696552570
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
component mappings of references-to-structures is already implemented
and working, and indi
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
https://gcc.gnu.org/pipermail/gcc-patch
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional benchm
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been done
This is a new series of patches for the og10 branch to rework how indirect
struct components are handled for offloaded OpenACC code regions. Compared
to the version posted previously here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570058.html
...the patches have been rebased to the cur
On 19.05.21 22:39, Bernhard Reutner-Fischer wrote:
On Wed, 19 May 2021 20:35:26 +0200
Tobias Burnus wrote:
As I like that patch and believe it is obvious, I intent to
/intent/s/tent/tend/
?
No real comment except that it sounds odd to arrive at 53 instead of
the quad bits precision on an arc
On Wed, 19 May 2021 22:39:13 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 19 May 2021 20:35:26 +0200
> Tobias Burnus wrote:
> > commit it as such – unless there are further comments.
>
> No real comment except ..
why don't we end up with IEEE binary128 quadruple precision here per
defaul
On Wed, 19 May 2021 20:35:26 +0200
Tobias Burnus wrote:
> Hi Segher,
>
> Quick version: Jump to the new patch, which I like much more.
> Namely, as the attached updated patch does.
>
> As I like that patch and believe it is obvious, I intent to
/intent/s/tent/tend/
> commit it as such – unle
Hi Segher,
Quick version: Jump to the new patch, which I like much more.
Longer version:
On 19.05.21 17:15, Segher Boessenkool wrote:
real(16) :: y ! 128bit REAL
integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
integer(16), parameter :: m2 = 10384593717
Hi All!
And yes I forgot the patch...
Sorry...
Best regards,
José Rui
On 19/05/21 17:09, José Rui Faustino de Sousa wrote:
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
Th
Hi all!
Proposed patch to:
Bug 93308 - bind(c) subroutine changes lower bound of array argument in
caller
Bug 93963 - Select rank mishandling allocatable and pointer arguments
with bind(c)
Bug 94327 - Bind(c) argument attributes are incorrectly set
Bug 94331 - Bind(C) corrupts array descripto
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
Thank you very much.
Best regards,
José Rui
Fortran: Fix bogus error
gcc/fortran/ChangeLog:
PR fortran/100683
On Wed, May 19, 2021 at 02:32:02PM +0200, Tobias Burnus wrote:
> Regarding gfortran.dg/pr96711.f90:
>
> On my x86-64-gnu-linux, it PASSes.
> On our powerpc64le-linux-gnu it FAILS with
> 'STOP 3' (→ also scan-dump count) and 'STOP 4'.
>
> Contrary to PR96983's bug summary, I don't get an ICE.
>
>
Regarding gfortran.dg/pr96711.f90:
On my x86-64-gnu-linux, it PASSes.
On our powerpc64le-linux-gnu it FAILS with
'STOP 3' (→ also scan-dump count) and 'STOP 4'.
Contrary to PR96983's bug summary, I don't get an ICE.
On powerpc64le-linux-gnu, the following condition evaluates true (→ 'STOP 3'):
FYI
Original Message
From: Richard Biener
Sent: 19 May 2021 10:06:26 CEST
To: g...@gcc.gnu.org
Cc: gcc-patc...@gcc.gnu.org
Subject: GCC 9.4 Status Report (2021-05-19), branch frozen for release
Status
==
The GCC 9 branch is now frozen for the upcoming GCC 9.4 release.
I
17 matches
Mail list logo
