> All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
> bootstrapped; no test suite regressions were introduced,
> relative to the GCC trunk.
That's not all languages though, Ada and Java are missing.
--
Eric Botcazou
On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote:
> Ok, but it doesn't solve the issue with doing it for the executable, because
> gomp_unmap_tgt (n->tgt) will want to run free_func on uninitialized device.
?? You mean that the
devicep->unload_image_func (devicep->target_id, version, ta
On 12/01/15 09:12:44, Eric Botcazou wrote:
> > All languages (c, c++, fortran, go, lto, objc, obj-c++) have been
> > bootstrapped; no test suite regressions were introduced,
> > relative to the GCC trunk.
>
> That's not all languages though, Ada and Java are missing.
OK. I'll bootstrap and run te
On Mon, Nov 30, 2015 at 07:30:34PM +, Julian Brown wrote:
> Julian Brown
> Cesar Philippidis
> James Norris
>
> gcc/
> * c-family/c-pragma.c (oacc_pragmas): Add PRAGMA_OACC_HOST_DATA.
> * c-family/c-pragma.h (pragma_kind): Add PRAGMA_OACC_HOST_DATA.
c-family/, c/
On Mon, Nov 30, 2015 at 10:00:06AM -0800, Cesar Philippidis wrote:
> This patch contains the following bug fixes:
>
> * Teaches gfortran to accept both num and static gang arguments inside
>same clause. E.g. gang(num:10, static:30). Currently, gfortran only
>allows one of those arguments
The changes are made in this patch for the instruction prefetch optimizations
for Microblaze.
Reg tested for Microblaze target.
The changes are made for instruction prefetch optimizations for Microblaze. The
"wic" microblaze instruction is the
instruction prefetch instruction. The instruction p
> On 01 Dec 2015, at 11:18, Jakub Jelinek wrote:
>
>> On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote:
>> Ok, but it doesn't solve the issue with doing it for the executable, because
>> gomp_unmap_tgt (n->tgt) will want to run free_func on uninitialized device.
>
> ?? You mean that
The following avoids PR68590 by merging two match.pd patterns.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2015-12-01 Richard Biener
PR middle-end/68590
* match.pd: Merge (eq @0 @0) and (ge/le @0 @0) patterns.
Index: gcc/match.pd
==
The patch to restructure builtin_reciprocals missed out an obvious ')'.
Adjusted thusly and applied as obvious to trunk.
regards
Ramana
2015-12-01 Ramana Radhakrishnan
* config/aarch64/aarch64.c (aarch64_builtin_reciprocal): Fix typo.
Moreover this patch is tested and run on hardware with Mibench/EEMBC benchmarks
for Microblaze target. The reconfigurable
design is enabled with the selection of "wic" instruction prefetch instruction
and above benchmarks compiled with -mxl-prefetch flags.
Thanks & Regards
Ajit
-Original Me
On Tue, Dec 01, 2015 at 08:58:53AM +, Ramana Radhakrishnan wrote:
> The patch to restructure builtin_reciprocals missed out an obvious ')'.
> Adjusted thusly and applied as obvious to trunk.
Sorry for that. Could you please also handle the gimple_call_internal_p
case, so that it actually ret
Hi!
On Thu, 09 Jul 2015 20:25:22 -0400, Nathan Sidwell wrote:
> This is the patch I committed. [...]
> 2015-07-09 Nathan Sidwell
> * omp-low.c (omp_region): [...]
> (enclosing_target_region, required_predication_mask,
> generate_vector_broadcast, generate_oacc_broadcast,
>
This patch adds support for simple cases where the a vector internal
function returns wider results than the scalar equivalent. It punts
on other cases.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
PR tree-optimization/68577
* tree-ve
Hi Christian,
On 30/11/15 10:16, Christian Bruel wrote:
Hi Kyrill,
Your fix (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01392.html) exposed new
FAILs with the macro testings in ftest-armv6[kz]-thumb.c.
From what I understood, only ARMv6T2 will have TARGET_32BIT set, and set
unaligned_acce
We'd call gen_shrink_wrap_conditions for functions that it can't handle
but edom_only_function can.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
PR tree-optimization/68474
* tree-call-cdce.c (use_internal_fn): Protect call to
gen_shrink_wrap_condition
The errors reported by check_attr_value weren't very helpful because
they always used the location of the define(_enum)_attr, even if the
error was in a define_insn. Also, the errors reported by
check_attr_test didn't say which attribute was faulty.
Although not technically a bug fix, it was real
Hi,
This patch fixes a way invariant boolean vector is generated. It makes sure
boolean vector consists of 0 and -1 values. Bootstrapped and tested on
x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-12-01 Ilya Enkovich
PR middle-end/68595
* tree-vect-st
On 01/12/15 09:04, Jakub Jelinek wrote:
> On Tue, Dec 01, 2015 at 08:58:53AM +, Ramana Radhakrishnan wrote:
>> The patch to restructure builtin_reciprocals missed out an obvious ')'.
>> Adjusted thusly and applied as obvious to trunk.
>
> Sorry for that. Could you please also handle the gi
On Mon, Nov 30, 2015 at 06:11:33PM +0100, Ulrich Weigand wrote:
> On 11/30/2015 04:11 PM, Dominik Vogt wrote:
> > The attached patch fixes some warnings generated by the setmem...
> > patterns in s390.md during build and add test cases for the
> > patterns. The patch is to be added on to p of the
On 01/12/15 03:19, Bin.Cheng wrote:
> On Tue, Nov 24, 2015 at 6:18 PM, Richard Earnshaw
> wrote:
>> On 24/11/15 09:56, Richard Earnshaw wrote:
>>> On 24/11/15 02:51, Bin.Cheng wrote:
>> The aarch64's problem is we don't define addptr3 pattern, and we don't
have direct insn pattern des
On Tue, 1 Dec 2015, Jan Hubicka wrote:
> Hi,
> this patch disables the streaming of alias 0 flag and adds a comment why.
>
> Bootstrapped/regtested x86_64-linux, OK?
Ok.
Thanks,
Richard.
> Honza
>
> * lto-streamer-out.c (hash_tree): Do not stream TYPE_ALIAS_SET.
> * tree-streamer-
On Tue, 1 Dec 2015, Jan Hubicka wrote:
> Hi,
> this is third part which enables us to change -fstrict-aliasing using
> optimize attribute. This ought to work safely now because inliner
> propagate the flag.
Ok.
Thanks,
Richard.
> Bootstrapped/regtested x86_64-linux.
>
> Honza
>
> * gcc
On Tue, 1 Dec 2015, Jan Hubicka wrote:
> Hi,
> memory attributes are currently optimized and attached to RTL even when not
> optimizing. This is obviously just a wasted effort.
Huh, are you sure? What about globals used from different optimize
contexts?
> Bootstrapped/regtested x86_64-linux, OK
On Tue, Dec 1, 2015 at 10:14 AM, Richard Sandiford
wrote:
> This patch adds support for simple cases where the a vector internal
> function returns wider results than the scalar equivalent. It punts
> on other cases.
>
> Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Than
On Tue, Dec 1, 2015 at 10:24 AM, Richard Sandiford
wrote:
> We'd call gen_shrink_wrap_conditions for functions that it can't handle
> but edom_only_function can.
>
> Tested on x86_64-linux-gnu. OK to install?
Ok.
Richard.
> Thanks,
> Richard
>
>
> gcc/
> PR tree-optimization/68474
>
On Tue, Dec 1, 2015 at 10:44 AM, Ilya Enkovich wrote:
> Hi,
>
> This patch fixes a way invariant boolean vector is generated. It makes sure
> boolean vector consists of 0 and -1 values. Bootstrapped and tested on
> x86_64-unknown-linux-gnu. OK for trunk?
Ok.
Richard.
> Thanks,
> Ilya
> --
On Mon, 30 Nov 2015, Gary Funck wrote:
>
> Some time ago, we submitted an RFC for the introduction of
> UPC support into GCC. During the intervening time period,
> we have continued to keep the 'gupc' (GNU UPC) branch in sync
> with the GCC trunk and have incorporated feedback and contributions
On 12/01/2015 06:31 AM, Gary Funck wrote:
At this time, we would like to re-submit the UPC patches for comment
with the goal of introducing these changes into GCC 6.0.
This has missed stage 1 by a few weeks, we'd have to make an exception
to include it at this late stage.
@@ -857,9 +875,14
On Mon, 30 Nov 2015, Gary Funck wrote:
>
> Background
> --
>
> An overview email, describing the UPC-related changes is here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
>
> The GUPC branch is described here:
> http://gcc.gnu.org/projects/gupc.html
>
> The UPC-relate
I got a report that Clang fails to compile the filesystem lib, with
the following error:
/home/jwakely/gcc/latest/include/c++/6.0.0/experimental/bits/fs_path.h:563:18: fatal
error: explicit specialization of
'std::experimental::filesystem::v1::path::__is_encoded_char' after
instantiation
st
On Mon, 30 Nov 2015, Gary Funck wrote:
>
> Background
> --
>
> An overview email, describing the UPC-related changes is here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
>
> The GUPC branch is described here:
> http://gcc.gnu.org/projects/gupc.html
>
> The UPC-relate
On Mon, 30 Nov 2015, Gary Funck wrote:
>
> Background
> --
>
> An overview email, describing the UPC-related changes is here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
>
> The GUPC branch is described here:
> http://gcc.gnu.org/projects/gupc.html
>
> The UPC-relate
On Mon, 30 Nov 2015, Gary Funck wrote:
>
> Background
> --
>
> An overview email, describing the UPC-related changes is here:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg5.html
>
> The GUPC branch is described here:
> http://gcc.gnu.org/projects/gupc.html
>
> The UPC-relate
On 11/26/2015 05:22 PM, Richard Sandiford wrote:
Bernd Schmidt writes:
I wish we'd taken some more time to think through the consequences of
the original internal_fn patchset.
I don't think this PR shows that the approach was wrong.
I think it does. Internal functions make a new assumption
Hi Christian,
On 01/12/15 09:18, Christian Bruel wrote:
Hi,
This patches fixes the PR my making the unaligned_access flag sensitive to the
attribute target, since some armv6 might use unaligned loads depending on the
TARGET_32BIT flag.
OK for stage3 ?
Index: gcc/testsuite/gcc.target/arm/a
On Tue, 24 Nov 2015 18:27:24 +0800
Chung-Lin Tang wrote:
> Hi, this patch reworks some of the way that asynchronous copyouts are
> implemented for OpenACC in libgomp.
>
> Before this patch, we had a somewhat confusing way of implementing
> this by having two refcounts for each mapping: refcount
On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt wrote:
> On 11/26/2015 05:22 PM, Richard Sandiford wrote:
>>
>> Bernd Schmidt writes:
>>
>>> I wish we'd taken some more time to think through the consequences of
>>> the original internal_fn patchset.
>>
>>
>> I don't think this PR shows that the ap
On 12/01/2015 01:16 PM, Richard Biener wrote:
On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt wrote:
On 11/26/2015 05:22 PM, Richard Sandiford wrote:
Bernd Schmidt writes:
I wish we'd taken some more time to think through the consequences of
the original internal_fn patchset.
I don't thi
Hello!
> 2015-11-29 Andreas Tobler
>
> * config/i386/i386.h: Define two new macros:
> SUBTARGET_SHADOW_OFFSET_64 and SUBTARGET_SHADOW_OFFSET_32.
> * config/i386/i386.c (ix86_asan_shadow_offset): Use these macros.
> * config/i386/darwin.h: Override the SUBTARGET_SHADOW_OFFSET_64
> macro.
> * con
On 30 November 2015 at 18:55, Tom de Vries wrote:
> On 30/11/15 17:48, Jakub Jelinek wrote:
>>
>> On Mon, Nov 30, 2015 at 05:36:25PM +0100, Tom de Vries wrote:
>>>
>>> +int
>>> +main (void)
>>> +{
>>> + unsigned results[nEvents];
>>> + unsigned pData[nEvents];
>>> + unsigned coeff = 2;
>>> +
>>
On 01/12/15 12:28, Christian Bruel wrote:
On 12/01/2015 12:57 PM, Kyrill Tkachov wrote:
Hi Christian,
On 01/12/15 09:18, Christian Bruel wrote:
Hi,
This patches fixes the PR my making the unaligned_access flag sensitive to the
attribute target, since some armv6 might use unaligned loads d
On Tue, Dec 01, 2015 at 01:27:32PM +0100, Christophe Lyon wrote:
> I've committed the attached patch as obvious: it adds
> dg-require-effective-target fopenmp to these new tests
> so that they are skipped e.g. on arm bare-metal targets
> (using newlib).
>
> Note that pr46032.c has some failures:
>
These three function used a hardcoded buffer of 100 but would be better
off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length of a
name in any of our supported standards (63 as of f2003 ff.).
Regstrapped without regressions, ok for trunk stage3 now / next stage1?
gcc/fortran/ChangeL
Regstrapped without regressions, ok for trunk stage3 now / next stage1?
gcc/fortran/ChangeLog
2015-11-29 Bernhard Reutner-Fischer
* trans-types.c (gfc_typenode_for_spec): Commentary typo fix.
Signed-off-by: Bernhard Reutner-Fischer
---
gcc/fortran/trans-types.c | 2 +-
1 file chang
gcc/fortran/ChangeLog
2015-11-29 Bernhard Reutner-Fischer
* gfortran.h (gfc_lookup_function_fuzzy): New declaration.
* resolve.c: Include spellcheck.h.
(lookup_function_fuzzy_find_candidates): New static function.
(lookup_uop_fuzzy_find_candidates): Likewise.
A couple of places used gfc_add_component_ref(expr, "string") instead of
the defines from gfortran.h
Regstrapped without regressions, ok for trunk stage3 now / next stage1?
gcc/fortran/ChangeLog
2015-11-29 Bernhard Reutner-Fischer
* class.c (gfc_add_class_array_ref): Call gfc_add_dat
On Tue, Dec 01, 2015 at 11:48:51AM +0300, Ilya Verbin wrote:
>
> > On 01 Dec 2015, at 11:18, Jakub Jelinek wrote:
> >
> >> On Mon, Nov 30, 2015 at 11:55:20PM +0300, Ilya Verbin wrote:
> >> Ok, but it doesn't solve the issue with doing it for the executable,
> >> because
> >> gomp_unmap_tgt (n->
(add gcc-patches)
On 12/01/2015 08:39 AM, Matthias Klose wrote:
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at
On Wed, 28 Oct 2015 at 18:14 PM, H.J. Lu wrote:
> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote:
>> On 10/29/2015 02:10 AM, H.J. Lu wrote:
>>>
>>> On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew did
n
Bernd Schmidt writes:
> On 11/26/2015 05:22 PM, Richard Sandiford wrote:
>> Bernd Schmidt writes:
>>
>>> I wish we'd taken some more time to think through the consequences of
>>> the original internal_fn patchset.
>>
>> I don't think this PR shows that the approach was wrong.
>
> I think it does.
On Tue, Dec 01, 2015 at 10:59:54AM +0100, Dominik Vogt wrote:
> @@ -3336,11 +3342,12 @@
> (set_attr "type" "vs")])
>
> (define_insn "*setmem_long_31z"
> - [(clobber (match_operand:TI 0 "register_operand" "=d"))
> - (set (mem:BLK (subreg:SI (match_operand:TI 3 "register_operand" "0") 4))
>
On 12/01/2015 04:12 AM, Richard Biener wrote:
On Mon, 30 Nov 2015, Gary Funck wrote:
Some time ago, we submitted an RFC for the introduction of
UPC support into GCC. During the intervening time period,
we have continued to keep the 'gupc' (GNU UPC) branch in sync
with the GCC trunk and have i
On 12/01/2015 02:43 PM, Richard Sandiford wrote:
I don't think what you say is an argument that the approach is wrong.
The C conditions for optabs have always been more restricted than
other define_expands and define_insns, since they cannot refer
to operands. When caching of optabs was added, t
This fixes the PR in another way as well, allowing as many capture
uses in the replacement expression as in the original one, avoiding
some spurious save_exprs that way (and not perform "CSE" within
the match-and-simplify framework).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to
The following fixes PR68379.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-11-30 Richard Biener
PR tree-optimization/68379
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
always base loads on the first used DR of a
[ was: Re: [PATCH, PR46032] Handle BUILT_IN_GOMP_PARALLEL in ipa-pta ]
On 30/11/15 17:36, Tom de Vries wrote:
On 30/11/15 14:24, Richard Biener wrote:
On Mon, 30 Nov 2015, Tom de Vries wrote:
On 30/11/15 10:16, Richard Biener wrote:
On Mon, 30 Nov 2015, Tom de Vries wrote:
Hi,
this patch
Hi,
Uli Weigand discovered that the gcc.target/powerpc/swaps-p8-21.c test
case fails when large and small code models are used, rather than the
default medium code model. This is because analyze_swaps is determining
whether the mask used for a vperm insn is loaded from the constant pool,
and ther
I am testing the following patch to avoid CFG cleanup calling merge-blocks
in dead regions thereby exposing that (in this case) copyprop propagates
a def from a dead region to another place in another dead region
(itself not realizing they are dead). The issue with that is that
if CFG cleanup fir
> Uli Weigand discovered that the gcc.target/powerpc/swaps-p8-21.c test
case fails when large and small code models are used, rather than the
default medium code model. This is because analyze_swaps is determining
whether the mask used for a vperm insn is loaded from the constant pool,
and there i
On Tue, 1 Dec 2015, Jan Hubicka wrote:
> > Hi,
> > this is polished version of the patch to implement IL level incremental
> > inking.
> > -flinker-output is now documented and can be specified to the GCC driver.
> > In this case plugin gets option -linker-output-known and it stops from
> > attem
On Tue, Dec 01, 2015 at 03:25:42PM +0100, Tom de Vries wrote:
> Handle BUILT_IN_GOACC_PARALLEL in ipa-pta
>
> 2015-12-01 Tom de Vries
>
> * tree-ssa-structalias.c (find_func_aliases_for_builtin_call)
> (find_func_clobbers, ipa_pta_execute): Handle BUILT_IN_GOACC_PARALLEL.
Isn't th
On Tue, 1 Dec 2015, Tom de Vries wrote:
> [ was: Re: [PATCH, PR46032] Handle BUILT_IN_GOMP_PARALLEL in ipa-pta ]
>
> On 30/11/15 17:36, Tom de Vries wrote:
> > On 30/11/15 14:24, Richard Biener wrote:
> > > On Mon, 30 Nov 2015, Tom de Vries wrote:
> > >
> > > > On 30/11/15 10:16, Richard Biener
We were failing to give "defined but not used" warning for functions marked
with the attribute noreturn/volatile. The problem is that for functions the
TREE_THIS_VOLATILE flag means something different than for decls. The fix is
to check the flag only for VAR_DECLs, as suggested by Richi in the P
Hi Cesar!
I noticed while working on other test cases:
On Wed, 18 Nov 2015 11:02:01 -0800, Cesar Philippidis
wrote:
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -1318,13 +1318,21 @@ cp_finalize_omp_declare_simd (cp_parser *parser, tree
> fndecl)
> }
> }
>
> -/* Diagnose if #pr
On 01/12/15 13:29, Jakub Jelinek wrote:
On Tue, Dec 01, 2015 at 01:27:32PM +0100, Christophe Lyon wrote:
>I've committed the attached patch as obvious: it adds
>dg-require-effective-target fopenmp to these new tests
>so that they are skipped e.g. on arm bare-metal targets
>(using newlib).
>
>Not
On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer
wrote:
> These three function used a hardcoded buffer of 100 but would be better
> off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length of a
> name in any of our supported standards (63 as of f2003 ff.).
Please use xasprintf(
On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote:
>
> David Malcolm nice Levenshtein distance spelling check helpers
> were used in some parts of other frontends. This proposed patch adds
> some spelling corrections to the fortran frontend.
>
> Suggestions are printed if w
On 12/01/2015 06:40 AM, Thomas Schwinge wrote:
> I noticed while working on other test cases:
>
> On Wed, 18 Nov 2015 11:02:01 -0800, Cesar Philippidis
> wrote:
>> --- a/gcc/cp/parser.c
>> +++ b/gcc/cp/parser.c
>
>> @@ -1318,13 +1318,21 @@ cp_finalize_omp_declare_simd (cp_parser *parser,
>> t
Bernd Schmidt writes:
> I'm worried we'll end up carrying
> something around as a burden that is of no practical use (considering
> we already support the more widespread OpenMP).
I'm not an expert on UPC, but from glancing over the description it
seems to target a distributed message passing pr
One problem I have whenever I try to edit i386.md is that I can't find
the patterns I'm looking for. Let's say I'm looking for lshrsi3, but
there's no pattern by this name, what I'm looking for is
"3". Even worse are things like "*xordi_2", which has
just "*_2" and can't reasonably be searched
This PR was fixed in r228767 (or went latent?), but this testcase has never
been added.
Tested on x86_64-linux, ok for trunk?
2015-12-01 Marek Polacek
PR tree-optimization/67916
* gcc.dg/torture/pr67916.c: New test.
diff --git gcc/testsuite/gcc.dg/torture/pr67916.c
gcc/tests
On Tue, Dec 1, 2015 at 3:47 PM, Marek Polacek wrote:
> We were failing to give "defined but not used" warning for functions marked
> with the attribute noreturn/volatile. The problem is that for functions the
> TREE_THIS_VOLATILE flag means something different than for decls. The fix is
> to che
On Tue, Dec 1, 2015 at 4:18 PM, Marek Polacek wrote:
> This PR was fixed in r228767 (or went latent?), but this testcase has never
> been added.
>
> Tested on x86_64-linux, ok for trunk?
Ok.
Richard.
> 2015-12-01 Marek Polacek
>
> PR tree-optimization/67916
> * gcc.dg/torture
This patch wires up use of alternative -mgomp multilib for OpenMP offloading
via nvptx mkoffload. It makes OpenACC and OpenMP incompatible for
simultaneous offloading compilation, so I've added a diagnostic for that.
* config/nvptx/mkoffload.c (main): Check that either OpenACC or OpenMP
Since OpenMP offloading requires both soft-stacks and "uniform SIMT", both
non-traditional codegen variants, I'm building a multilib variant with those
enabled. This patch adds option -mgomp which enables -msoft-stack plus
-muniform-simt, and builds a multilib with it.
* config/nvptx/nvpt
This patch introduces a code generation variant for NVPTX that I'm using for
SIMD work in OpenMP offloading. Let me try to explain the idea behind it...
In place of SIMD vectorization, NVPTX is using SIMT (single
instruction/multiple threads) execution: groups of 32 threads execute the same
instr
On Tue, 1 Dec 2015, Andi Kleen wrote:
> Bernd Schmidt writes:
>
> > I'm worried we'll end up carrying
> > something around as a burden that is of no practical use (considering
> > we already support the more widespread OpenMP).
>
> I'm not an expert on UPC, but from glancing over the descriptio
Here's how I've updated gomp_nvptx_main to set up shared memory arrays
__nvptx_stacks and __nvptx_uni for -mgomp. Since it makes sense only for
-mgomp multilib, I've wrapped the whole file under #ifdef that checks
corresponding built-in macros.
Reaching those shared memory arrays is awkward. I c
This patch adds a new target hook and implements it in a straightforward
manner on NVPTX to indicate that the target is running in SIMT fashion with 32
threads in a synchronous group ("warp"). For use in OpenMP transforms.
---
gcc/config/nvptx/nvptx.c | 12
gcc/doc/tm.texi |
Hello!
This patch series shows how I'm approaching OpenMP SIMD for NVPTX. It looks
good both in check-c testing and libgomp testing, including new target-3x.c
cases (but for-5.c fails to run with resource exhaustion, maybe it should be
split for NVPTX -- will investigate more later).
The previou
This is incomplete.
This handles OpenMP SIMD for NVPTX in simple cases, partly by punting on
anything unusual such as simduid loops, partly by getting lucky, as testcases
do not expose the missing bits.
What it currently does is transform SIMD loop
for (V = N1; V cmp N2; V + STEP) BODY;
into
Today, I ran 'gfortran -static-libfortran test.f90' and was very pleased with
the answer:
gfortran: error: unrecognized command line option ‘-static-libfortran’; did you
mean ‘-static-libgfortran’?
So thanks David, and hopefully we get this user experience for the FE as well.
Joost
To easily build libgcc for -mgomp multilib, I've rewritten libgcc routines
from asm to C.
En passant, I've fixed a bug in malloc and realloc wrappers where they failed
to handle out-of-memory conditions. I'm assuming it wasn't intentional.
I also use a patch for Newlib that rewrites its nvptx-sp
On Tue, Dec 01, 2015 at 04:14:21PM +0100, Bernd Schmidt wrote:
> One problem I have whenever I try to edit i386.md is that I can't find the
> patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no
> pattern by this name, what I'm looking for is "3". Even
> worse are things like
On 12/01/2015 04:23 PM, Jakub Jelinek wrote:
On Tue, Dec 01, 2015 at 04:14:21PM +0100, Bernd Schmidt wrote:
One problem I have whenever I try to edit i386.md is that I can't find the
patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no
pattern by this name, what I'm lookin
There's an open PR with -fopenmp-simd testcase that used to ICE but is now
fixed for 5/6, but not 4.9.
Should I commit this right away to trunk, wait for gcc-5 branch to open and
then commit it to 5 as well and then close the PR?
Or just to trunk and close the PR?
Tested on x86_64-linux.
2015-1
This allows to rewrite libgcc wrappers in C by adding back-maps
__nvptx_real_malloc -> malloc and __nvptx_real_free -> free. While at it,
I've made the implementation leaner.
* config/nvptx/nvptx.c (nvptx_name_replacement): Rewrite. Add
__nvptx_real_malloc -> malloc and __nvptx_r
This allows to use COND_EXEC patterns on nvptx. The backend is mostly ready
for that, although I had to slightly fix nvptx_print_operand. I've also opted
to make calls predicable to make the uniform-simt patch simpler, and to that
end I need a small fixup in nvptx_output_call_insn.
RTL optimizat
On Tue, Dec 01, 2015 at 04:38:03PM +0100, Marek Polacek wrote:
> There's an open PR with -fopenmp-simd testcase that used to ICE but is now
> fixed for 5/6, but not 4.9.
>
> Should I commit this right away to trunk, wait for gcc-5 branch to open and
> then commit it to 5 as well and then close the
On Tue, Dec 01, 2015 at 01:55:00PM +0100, Bernhard Reutner-Fischer wrote:
> Regstrapped without regressions, ok for trunk stage3 now / next stage1?
>
> gcc/fortran/ChangeLog
>
> 2015-11-29 Bernhard Reutner-Fischer
>
> * trans-types.c (gfc_typenode_for_spec): Commentary typo fix.
>
Pat
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
Bernd, is your position on exposing shared memory as first-class address space
on NVPTX subject to change? Do you remember what middle-end issues you've
encountered when trying that?
TYPE_ADDR_SPACE does not reliably contain the address space. P
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
I'm taking a different approach. I want to execute all insns in all warp
members, while ensuring that effect (on global and local state) is that same
as if any single thread was executing that instruction. Most instructions
automatically satisfy
On 1 December 2015 at 16:01, Steve Kargl
wrote:
> On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote:
>>
>> David Malcolm nice Levenshtein distance spelling check helpers
>> were used in some parts of other frontends. This proposed patch adds
>> some spelling corrections to t
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00937.html
This fell through the cracks for me.
Is this ok at this stage? Or should I leave it for GCC 7?
Thanks,
Kyrill
On 09/11/15 11:36, Kyrill Tkachov wrote:
Hi all,
Judging by the thread at
https://gcc.gnu.org/ml/gcc-patches/2015-10/ms
On Tue, 1 Dec 2015, Bernd Schmidt wrote:
>
> Didn't we also conclude that address-taking (let's say for stack addresses) is
> also an operation that does not result in the same state?
This is intended to be used with soft-stacks in OpenMP offloading, and
soft-stacks are per-warp outside of SIMD r
Hi,
Thanks for the comments James, I've moved the patterns around
and added new comments to them. Hope this is ok.
Regards,
David Sherwood.
ChangeLog:
2015-12-01 David Sherwood
gcc/
* config/aarch64/aarch64.md: New pattern.
* config/aarch64/aarch64-simd.md: Likewise.
On 12/01/15 12:12:29, Richard Biener wrote:
> On Mon, 30 Nov 2015, Gary Funck wrote:
> > At this time, we would like to re-submit the UPC patches for comment
> > with the goal of introducing these changes into GCC 6.0.
>
> First of all let me say that it is IMNSHO now too late for GCC 6.
I realiz
On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote:
> On 1 December 2015 at 16:01, Steve Kargl
> wrote:
> > On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote:
> >>
> >> David Malcolm nice Levenshtein distance spelling check helpers
> >> were used in som
Hi,
On Mon, 16 Nov 2015, Jeff Law wrote:
> OK, if you want to keep them, then have a consistent way to turn them
> on/off for future debugging. if0/if1 doesn't provide much of a clue to
> someone else what to turn on/off if they need to debug this stuff.
> > > I don't see any negative tests -
On 1 December 2015 at 15:52, Janne Blomqvist wrote:
> On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer
> wrote:
>> These three function used a hardcoded buffer of 100 but would be better
>> off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length of a
>> name in any of our supp
1 - 100 of 160 matches
Mail list logo
