On Fri, Oct 16, 2015 at 11:44:17AM +0200, Thomas Schwinge wrote:
> But: working on getting our changes into trunk, for example, when we make
> an effort to extract from gomp-4_0-branch self-contained, individual
> patches, but it then takes weeks to get commit approval or review
> comments, I
Hi!
On Tue, 13 Oct 2015 21:12:14 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> I've bootstrapped/regtested on x86_64-linux and i686-linux following
> merge from gomp-4_1-branch to trunk, which brings in most of the OpenMP 4.5
> support for C and C++
With nvptx offload
On 14/10/15 10:04, Jakub Jelinek wrote:
No, both the above changes are wrong. There is not a single int32_t
written, but could be many more, it is an array of 32-bit integers.
I'd say you just want to cast explicitly,
omp_get_place_proc_ids (*place_num, (int *) ids);
and
On 14/10/15 10:04, Jakub Jelinek wrote:
On Wed, Oct 14, 2015 at 09:34:48AM +0200, Sebastian Huber wrote:
>/home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:28:0:
>/home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:73:18: note: expected
>'int *' but argument is of type 'int32_t * {aka
Hello,
I get now the following error:
libtool: compile: /scratch/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc
-B/scratch/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc
-B/scratch/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/
-isystem
On Wed, Oct 14, 2015 at 09:34:48AM +0200, Sebastian Huber wrote:
> /home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:28:0:
> /home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:73:18: note: expected
> 'int *' but argument is of type 'int32_t * {aka long int *}'
Ugh, wasn't aware that some
