Hi!
On 2020-04-29T16:01:56+0200, Tobias Burnus wrote:
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
>
> The problem is a generated static array variable in the
> device function:
>static integer(kind=4) A.12[3] = {1, 2, 3};
> used as
>_26 = A.12[S.13_67];
>
> [...]
..., and t
On 4/30/20 9:17 AM, Jakub Jelinek wrote:
I'll try to do something about that early in stage1 and
eventually backport, we need to follow OpenMP rules anyway and
those require auto-discovery of referenced functions (if they are
definitions rather than just declarations), and similarly in
some case
On Thu, Apr 30, 2020 at 08:24:02AM +0200, Richard Biener wrote:
> On Wed, Apr 29, 2020 at 5:05 PM Tobias Burnus wrote:
> > was a bit on the backburner but I now digged again.
> > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
> >
> > The problem is a generated static array variable in the
On Wed, Apr 29, 2020 at 5:05 PM Tobias Burnus wrote:
>
> Hi Thomas,
>
> was a bit on the backburner but I now digged again.
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
>
> The problem is a generated static array variable in the
> device function:
>static integer(kind=4) A.12[3] =
Hi Thomas,
was a bit on the backburner but I now digged again.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
The problem is a generated static array variable in the
device function:
static integer(kind=4) A.12[3] = {1, 2, 3};
used as
_26 = A.12[S.13_67];
With -ftree-pre, the expre
Hi Tobias!
Do you happen to have any update regarding this one:
On 2020-01-08T09:55:06+0100, Tobias Burnus wrote:
> On 1/8/20 9:33 AM, Thomas Schwinge wrote:
>> With 'dg-do run' added, on [...] x86_64-pc-linux-gnu with offloading I'm
>> seeing:
| PASS: libgomp.fortran/use_device_ptr-option
Hi Thomas,
On 1/8/20 9:33 AM, Thomas Schwinge wrote:
With 'dg-do run' added, on powerpc64le-unknown-linux-gnu
Have I already expressed that I started to hate that target arch?
I think we really should find out what goes wrong for the small example
of https://gcc.gnu.org/bugzilla/show_bug.cgi
Hi Tobias!
On 2019-12-10T18:54:19+0100, Tobias Burnus wrote:
> PS: Besides adding tons of test cases, [r279858] also fixes the transient
> issue
> (which does only occur with -O1 ?!?)
(I saw it with different/differing optimization levels.)
> with the existing
> use_device_addr-{3,4}.f90 tes
On Tue, Dec 10, 2019 at 06:54:19PM +0100, Tobias Burnus wrote:
> 2019-12-10 Tobias Burnus
>
> gcc/fortran/
> * trans-openmp.c (gfc_omp_check_optional_argument): Always return a
> Boolean expression; handle unallocated/disassociated actual arguments
> as absent if passed
Between Holidays and being short on people that understand this, I would
say commit it unless Jakub objects.
(When in doubt, make a decision and move forward principle, assuming one
is not stupid,)
Cheers,
Jerry
On 12/29/19 2:27 PM, Tobias Burnus wrote:
On 12/16/19 9:06 AM, Tobias Burnus
On 12/16/19 9:06 AM, Tobias Burnus wrote:
Ping.
On 12/10/19 6:54 PM, Tobias Burnus wrote:
Nonallocatable, nonpointer array arguments (of assumed shape) are
special as they get a get an array descriptor ('arg') as argument but
create a local variable which accesses the actual data ('arg.0 =
Ping.
On 12/10/19 6:54 PM, Tobias Burnus wrote:
Nonallocatable, nonpointer array arguments (of assumed shape) are
special as they get a get an array descriptor ('arg') as argument but
create a local variable which accesses the actual data ('arg.0 =
arg->data').
With OPTIONAL, there are/were
Nonallocatable, nonpointer array arguments (of assumed shape) are
special as they get a get an array descriptor ('arg') as argument but
create a local variable which accesses the actual data ('arg.0 =
arg->data').
With OPTIONAL, there are/were two outstanding issues:
(A) If the argument is no
13 matches
Mail list logo
