Hi,
this patch removes flag_strict_aliasing kludge in expanding debug locations and
instead it introduces explicit parameter DEBUG that makes
set_mem_attributes_minus_bitpos to not affect alias sets. This is sanity
checked by comparing number of alias sets before and after at a time we
originally
Hi,
this patch makes the type system to be unchanged by flag_strict_aliasing.
This is needed to prevent optimization loss in flag_strict_aliasing code where
some !flag_strict_aliasing code put alias set 0 into a type (this happens
in all cases I modified in my original patch). It is also necessary
On Tue, 1 Dec 2015, Jeff Law wrote:
> On 12/01/2015 11:33 AM, Alan Lawrence wrote:
> >
> > I was not able to reduce the testcase below about 30k characters, with e.g.
> > #define T_VOID 0
> > T_VOID
> > producing the ICE, but manually changing to
> > 0
> > preventing the ICE;
The problem in the testcase was that tree-complex.c was trying
to fold ABS_EXPRs of SSA names that didn't yet have a definition
(because the SSA names were real and imaginary parts of a complex
SSA name whose definition hadn't yet been visited by the pass).
tree-complex.c uses a straightforward wal
On Tue, 1 Dec 2015, Alan Lawrence wrote:
> This follows on from discussion at
> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03392.html
> To recap: Starting in r229479 and continuing until at least 229711, compiling
> polynom.c from spec2000 on aarch64-none-linux-gnu, with options
> -O3 -mcpu=cor
On Wed, 2 Dec 2015, Trevor Saunders wrote:
> On Tue, Dec 01, 2015 at 07:43:35PM +, Richard Sandiford wrote:
> > tbsaunde+...@tbsaunde.org writes:
> > > -template
> > > +template
> > > template
> > > inline void
> > > -simple_hashmap_traits ::remove (T &entry)
> > > +simple_hashmap_traits
On 11/30/2015 03:45 PM, Dominik Vogt wrote:
> On Mon, Nov 09, 2015 at 01:33:23PM +0100, Andreas Krebbel wrote:
>> On 11/04/2015 02:39 AM, Dominik Vogt wrote:
>>> On Tue, Nov 03, 2015 at 06:47:28PM +0100, Ulrich Weigand wrote:
Dominik Vogt wrote:
+++ b/gcc/testsuite/gcc.target/s390/md/movstr-1.
On Wed, 2 Dec 2015, Jan Hubicka wrote:
> Hi,
> this patch removes flag_strict_aliasing kludge in expanding debug locations
> and
> instead it introduces explicit parameter DEBUG that makes
> set_mem_attributes_minus_bitpos to not affect alias sets. This is sanity
> checked by comparing number of
This patch makes it a compile-time error for an internal-fn optab
to FAIL. There are certainly other optabs and patterns besides these
that aren't allowed to fail, but this at least deals with the immediate
point of controversy.
Tested normally on x86_64-linux-gnu. Also tested by building one
co
On Wed, Dec 02, 2015 at 09:59:10AM +0100, Andreas Krebbel wrote:
> On 11/30/2015 03:45 PM, Dominik Vogt wrote:
> > On Mon, Nov 09, 2015 at 01:33:23PM +0100, Andreas Krebbel wrote:
> >> On 11/04/2015 02:39 AM, Dominik Vogt wrote:
> >>> On Tue, Nov 03, 2015 at 06:47:28PM +0100, Ulrich Weigand wrote:
On Wed, 2 Dec 2015, Jan Hubicka wrote:
> Hi,
> this patch makes the type system to be unchanged by flag_strict_aliasing.
> This is needed to prevent optimization loss in flag_strict_aliasing code where
> some !flag_strict_aliasing code put alias set 0 into a type (this happens
> in all cases I mod
On Wed, Dec 02, 2015 at 10:05:13AM +0100, Richard Biener wrote:
> On Wed, 2 Dec 2015, Jan Hubicka wrote:
>
> > Hi,
> > this patch removes flag_strict_aliasing kludge in expanding debug locations
> > and
> > instead it introduces explicit parameter DEBUG that makes
> > set_mem_attributes_minus_bit
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> On Wed, Dec 02, 2015 at 10:05:13AM +0100, Richard Biener wrote:
> > On Wed, 2 Dec 2015, Jan Hubicka wrote:
> >
> > > Hi,
> > > this patch removes flag_strict_aliasing kludge in expanding debug
> > > locations and
> > > instead it introduces explicit par
Ping.
Hi Thomas, this is only for gomp4 ATM, okay to commit?
Thanks,
Chung-Lin
On 2015/11/23 7:09 PM, Chung-Lin Tang wrote:
> Hi Thomas,
> this fix adds more acc_wait's to libgomp.oacc-fortran/lib-1[13].f90.
>
> For lib-12.f90, it's sort of a fix before we can resolve the issue
> of intended se
Ping.
On 2015/11/23 9:15 PM, Chung-Lin Tang wrote:
> The OpenACC wait directive is represented as a call to the runtime
> function "GOACC_wait" instead of a tree code. I am seeing when
> '#pragma acc wait' is using inside a template function, the CALL_EXPR
> to GOACC_wait is being silently ignore
On Wed, Dec 02, 2015 at 12:46:47AM +0100, Tom de Vries wrote:
> Does this explanation address your concern?
Yeah, for now it is fine I hope.
Jakub
Richard Biener writes:
> On Wed, 2 Dec 2015, Trevor Saunders wrote:
>> On Tue, Dec 01, 2015 at 07:43:35PM +, Richard Sandiford wrote:
>> > tbsaunde+...@tbsaunde.org writes:
>> > > -template
>> > > +template
>> > > template
>> > > inline void
>> > > -simple_hashmap_traits ::remove (T &entr
On Tue, 1 Dec 2015, Gary Funck wrote:
> 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
On Tue, Dec 1, 2015 at 4:38 PM, 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 PR?
Ok f
On Fri, Nov 27, 2015 at 12:42:09PM +0100, Tom de Vries wrote:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -1366,10 +1366,12 @@ build_sender_ref (tree var, omp_context *ctx)
>return build_sender_ref ((splay_tree_key) var, ctx);
> }
>
> -/* Add a new field for VAR inside the structure CTX
On Tue, Dec 1, 2015 at 10:32 PM, Jeff Law wrote:
> On 10/09/2015 09:45 AM, Jeff Law wrote:
>>>
>>> Yes, but as you remove jump threading paths you could leave the CFG
>>> change to
>>> cfg-cleanup anyway? To get better behavior wrt loop fixup at least?
>>
>> So go ahead and detect, remove the thr
On Wed, Dec 2, 2015 at 2:28 AM, Ian Lance Taylor wrote:
> The Go frontend code that handled array dimensions when generating
> reflection and mangling assumed that an array dimension would fit in
> an unsigned long. That is of course not true when a 32-bit host is
> cross-compiling to a 64-bit ta
On Fri, Nov 27, 2015 at 01:03:52PM +0100, Tom de Vries wrote:
> Handle non-declared variables in kernels alias analysis
>
> 2015-11-27 Tom de Vries
>
> * gimplify.c (gimplify_scan_omp_clauses): Initialize
> OMP_CLAUSE_ORIG_DECL.
> * omp-low.c (install_var_field_1): Handle bas
On Wed, Dec 2, 2015 at 9:33 AM, Richard Sandiford
wrote:
> The problem in the testcase was that tree-complex.c was trying
> to fold ABS_EXPRs of SSA names that didn't yet have a definition
> (because the SSA names were real and imaginary parts of a complex
> SSA name whose definition hadn't yet be
On Wed, Dec 02, 2015 at 10:11:54AM +0100, Dominik Vogt wrote:
> On Wed, Dec 02, 2015 at 09:59:10AM +0100, Andreas Krebbel wrote:
> > On 11/30/2015 03:45 PM, Dominik Vogt wrote:
> > > On Mon, Nov 09, 2015 at 01:33:23PM +0100, Andreas Krebbel wrote:
> > >> On 11/04/2015 02:39 AM, Dominik Vogt wrote:
Hopefully, this is correct now; it does pass the functional test case
that's part of the patch. Unfortunately the define_insn patters
had to be duplicated because of the new subreg offsets. Not sure
whether I've missed any "use" patterns that should be added.
Ciao
Dominik ^_^ ^_^
--
Dominik
This PR got fixed along with PR68625, so I'd like to add the testcase and close
the bug.
Tested on x86_64-linux, ok for trunk?
2015-12-02 Marek Polacek
PR middle-end/68570
* gcc.dg/torture/pr68570.c: New test.
diff --git gcc/testsuite/gcc.dg/torture/pr68570.c
gcc/testsuite/g
On Wed, Dec 02, 2015 at 11:16:06AM +0100, Marek Polacek wrote:
> This PR got fixed along with PR68625, so I'd like to add the testcase and
> close
> the bug.
>
> Tested on x86_64-linux, ok for trunk?
>
> 2015-12-02 Marek Polacek
>
> PR middle-end/68570
> * gcc.dg/torture/pr68570.
Ping
2015-11-23 16:05 GMT+03:00 Ilya Enkovich :
> Ping
>
> 2015-11-13 16:17 GMT+03:00 Ilya Enkovich :
>> 2015-11-13 13:03 GMT+03:00 Richard Biener :
>>> On Thu, Nov 12, 2015 at 5:08 PM, Ilya Enkovich
>>> wrote:
Hi,
When we use LTO for fortran we may have a mix 32bit and 1bit scala
On Tue, Dec 01, 2015 at 06:28:20PM +0300, Alexander Monakov wrote:
> The approach in OpenACC is to, outside of "vector" loops, 1) make threads 1-31
> "slaves" which just follow branches without any computation -- that requires
> extra jumps and broadcasting branch predicates, -- and 2) broadcast re
On Tue, Dec 01, 2015 at 06:28:22PM +0300, Alexander Monakov wrote:
> 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
>
On Tue, Dec 01, 2015 at 09:39:30PM -0600, Segher Boessenkool wrote:
> On Wed, Dec 02, 2015 at 01:50:46PM +1030, Alan Modra wrote:
> > On Wed, Dec 02, 2015 at 01:55:17AM +, Segher Boessenkool wrote:
> > > + emit_insn (gen_subdi3 (tmp, op1, op2));
> > > + emit_insn (gen_lshrdi3 (tmp2, tmp, GEN_
On Tue, Dec 01, 2015 at 06:28:26PM +0300, Alexander Monakov wrote:
> +void
> +gomp_nvptx_main (void (*fn) (void *), void *fn_data)
> +{
> + int tid, ntids;
> + asm ("mov.u32 %0, %%tid.y;" : "=r" (tid));
> + asm ("mov.u32 %0, %%ntid.y;" : "=r"(ntids));
Formatting (missing space before ( ).
On 12/02/2015 11:12 AM, Dominik Vogt wrote:
> Hopefully, this is correct now; it does pass the functional test case
> that's part of the patch. Unfortunately the define_insn patters
> had to be duplicated because of the new subreg offsets.
The number of patterns could possibly be reduced using
Spotted by disabling init-regs.c (see PR61810).
Bah, parts of our testsuite should be -Wall clean, really.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-12-02 Richard Biener
* gcc.dg/vect/vect-strided-a-u8-i8-gap7-big-array.c: Fix uninitialized
y guarding a cal
On Tue, Dec 01, 2015 at 06:28:27PM +0300, Alexander Monakov wrote:
> @@ -10218,12 +10218,37 @@ expand_omp_simd (struct omp_region *region, struct
> omp_for_data *fd)
>
>n1 = fd->loop.n1;
>n2 = fd->loop.n2;
> + step = fd->loop.step;
> + bool do_simt_transform
> += (cgraph_node::get
On Tue, Dec 1, 2015 at 7:02 AM, 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
On Tue, Dec 1, 2015 at 7:02 AM, 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
On Tue, Dec 1, 2015 at 7:02 AM, 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
On Wed, Dec 02, 2015 at 01:10:44PM +0100, Richard Biener wrote:
> > UPC pointers-to-shared have an internal representation which is
> > defined as a 'struct' with three fields. Special logic is
> > needed in promote_mode() to handle this case.
>
> Errr - but how are 'struct's ever REFERENCE_TYPE
On Tue, Dec 01, 2015 at 04:34:01PM +, David Sherwood wrote:
> Hi,
>
> Thanks for the comments James, I've moved the patterns around
> and added new comments to them. Hope this is ok.
This is fine.
Thanks,
James
Hello Jakub,
On 13 Nov 13:16, Jakub Jelinek wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/attr-simd.c
>
> Similarly.
>
> Ok for trunk with those changes.
It turns out that current implementation of GLibC does not
contain masked variants of math routines. So, this attribute
is use
Andreas Krebbel wrote:
> On 12/02/2015 11:12 AM, Dominik Vogt wrote:
> > Hopefully, this is correct now; it does pass the functional test case
> > that's part of the patch. Unfortunately the define_insn patters
> > had to be duplicated because of the new subreg offsets.
>
> The number of patter
On 12/02/15 05:40, Jakub Jelinek wrote:
Don't know the HW good enough, is there any power consumption, heat etc.
difference between the two approaches? I mean does the HW consume different
amount of power if only one thread in a warp executes code and the other
threads in the same warp just jum
This partly reverts / implements differently a patch done to support
SLP reductions for SAD_EXPRs (gcc.dg/vect/slp-reduc-sad.c). Detecting
those patterns unconditionally causes missed vectorization opportunities
as we don't implement vectorizing them in non-reduction context.
Bootstrap / regtest
On Wed, Dec 02, 2015 at 08:02:47AM -0500, Nathan Sidwell wrote:
> On 12/02/15 05:40, Jakub Jelinek wrote:
> > Don't know the HW good enough, is there any power consumption, heat etc.
> >difference between the two approaches? I mean does the HW consume different
> >amount of power if only one threa
On 02/12/15 10:45, Jakub Jelinek wrote:
On Fri, Nov 27, 2015 at 12:42:09PM +0100, Tom de Vries wrote:
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -1366,10 +1366,12 @@ build_sender_ref (tree var, omp_context *ctx)
return build_sender_ref ((splay_tree_key) var, ctx);
}
-/* Add a new field fo
On 12/02/2015 01:51 PM, Ulrich Weigand wrote:
> Andreas Krebbel wrote:
>> On 12/02/2015 11:12 AM, Dominik Vogt wrote:
>>> Hopefully, this is correct now; it does pass the functional test case
>>> that's part of the patch. Unfortunately the define_insn patters
>>> had to be duplicated because of th
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
This should solve the generic-match.c part of the C_MAYBE_CONST_EXPR
issues.
Richard.
2015-12-02 Richard Biener
* tree.h (tree_invariant_p): Declare.
* tree.c (tree_invariant_p): Export.
* genmatch.c (dt_
On Fri, Nov 27, 2015 at 12:29:21PM +0100, Tom de Vries wrote:
> Fix oacc kernels default mapping for scalars
>
> 2015-11-27 Tom de Vries
>
> * gimplify.c (enum gimplify_omp_var_data): Add enum value
> GOVD_MAP_FORCE.
> (oacc_default_clause): Fix default for scalars in oacc ke
The testcase shows that we rely on consistently rejecting all group
members from vect_analyze_data_ref_access but that isn't done reliably
when they are not in the same loop level (and thus
nested_in_vect_loop_p doesn't return the same answer for all group
elements). Of course such groups are har
> I think this also shows that using a POINTER_TYPE for a non-pointer
> is bogus. POINTER_TYPE is not for "semantically a pointer" but
> for pointers. Just use RECORD_TYPE here (and of course lower
> things earlier).
FWIW that's what Ada does for its fat pointers.
--
Eric Botcazou
On 12/02/2015 02:11 PM, Andreas Krebbel wrote:
> On 12/02/2015 01:51 PM, Ulrich Weigand wrote:
>> Andreas Krebbel wrote:
>>> On 12/02/2015 11:12 AM, Dominik Vogt wrote:
Hopefully, this is correct now; it does pass the functional test case
that's part of the patch. Unfortunately the defin
Hi,
On Tue, 1 Dec 2015, Jeff Law wrote:
> > So, okay for trunk?
> -ENOPATCH
Sigh :)
Here it is.
Ciao,
Michael.
* common.opt (-fsplit-loops): New flag.
* passes.def (pass_loop_split): Add.
* opts.c (default_options_table): Add OPT_fsplit_loops entry at -O3.
(enab
On 27/11/15 14:13, Richard Biener wrote:
The following fixes the excessive peeling for gaps we do when doing
SLP now that I removed most of the restrictions on having gaps in
the first place.
This should make low-trip vectorized loops more efficient (sth
also the combine-epilogue-with-vectorize
On Wed, 2 Dec 2015, Alan Lawrence wrote:
> On 27/11/15 14:13, Richard Biener wrote:
> >
> > The following fixes the excessive peeling for gaps we do when doing
> > SLP now that I removed most of the restrictions on having gaps in
> > the first place.
> >
> > This should make low-trip vectorized
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
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 sm
On 01/12/15 16:33 -0500, Jason Merrill wrote:
On 11/25/2015 11:58 AM, Moore, Catherine wrote:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Friday, September 18, 2015 3:25 PM
To: Moore, Catherine; gcc-patches@gcc.gnu.org
Cc: ja...@redhat.com; Matthew Fortun
On 12/02/15 08:10, Jakub Jelinek wrote:
On Wed, Dec 02, 2015 at 08:02:47AM -0500, Nathan Sidwell wrote:
Always the whole stack, from the current stack pointer up to top of the
stack, so sometimes a few bytes, sometimes a few kilobytes or more each time?
The frame of the current function. No
On 11/24/2015 06:10 PM, Jakub Jelinek wrote:
The new pass is IMNSHO completely useless and undesirable, both for compile
time (another whole IL traversal) reasons and for the unnecessary creation
of memory allocations.
Understood. Thank you very much for explaining how you think it should
be!
On Wed, Dec 02, 2015 at 08:38:56AM -0500, Nathan Sidwell wrote:
> On 12/02/15 08:10, Jakub Jelinek wrote:
> >On Wed, Dec 02, 2015 at 08:02:47AM -0500, Nathan Sidwell wrote:
>
> >Always the whole stack, from the current stack pointer up to top of the
> >stack, so sometimes a few bytes, sometimes a
On 24/11/15 14:55, Andreas Arnez wrote:
Ping?
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html
I guess we want C and C++ behave the same here?
gcc/cp/ChangeLog:
* cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location
to start of loop body instead of start
Hi,
This patch fixes wrong alignment check in _store_mask
pattern. Currently we check a register operand instead of a memory
one. This fixes segfault on 481.wrf compiled at -O3 for KNL target.
I bootstrapped and tested this patch on x86_64-unknown-linux-gnu.
I got a bunch of new failures:
FAIL
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> expand_omp is depth-first expansion, so for the case where the simd
> region is in lexically (directly or indirectly) nested inside of a
> target region, the above will not trigger. You'd need to
> use cgraph_node::get (current_function_decl)->offloadable
On Wed, Dec 02, 2015 at 02:46:28PM +0100, Pierre-Marie de Rodat wrote:
> On 11/24/2015 06:10 PM, Jakub Jelinek wrote:
> >The new pass is IMNSHO completely useless and undesirable, both for compile
> >time (another whole IL traversal) reasons and for the unnecessary creation
> >of memory allocations
On 12/02/2015 02:46 PM, Jakub Jelinek wrote:
Or does the OpenACC execution model not allow anything like that, i.e.
have some function with an automatic variable pass the address of that
variable to some other function and that other function use #acc loop kind
that expects the caller to be at th
Hello.
Following patch add support for internal functions that are either expanded to
an HSAIL
instruction, or a function call is generated. Apart from that, utilizing bit
string instructions,
we support all builtins that are based on the type of instructions.
Patch set:
00c2bb6 HSA: reorder BU
On Wed, Dec 02, 2015 at 04:54:39PM +0300, Alexander Monakov wrote:
> On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> > expand_omp is depth-first expansion, so for the case where the simd
> > region is in lexically (directly or indirectly) nested inside of a
> > target region, the above will not trigger.
On 12/02/15 08:46, Jakub Jelinek wrote:
Or does the OpenACC execution model not allow anything like that, i.e.
have some function with an automatic variable pass the address of that
variable to some other function and that other function use #acc loop kind
that expects the caller to be at the wo
On 12/02/2015 01:36 AM, Richard Biener wrote:
This could also be a candidate for the 5.3 release; backporting depends only on
the (fairly trivial) r230357.
Looks good to me (for both, but backport only after 5.3 is released). But
please wait for the discussion with Jeff to settle down.
No ne
On 12/02/2015 01:33 AM, Richard Biener wrote:
Right. So the question I have is how/why did DOM leave anything in the map.
And if DOM is fixed to not leave stuff lying around, can we then assert that
nothing is ever left in those maps between passes? There's certainly no good
reason I'm aware of
*PING*
2015-11-26 17:51 GMT+01:00 Steve Kargl :
> On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo wrote:
>> Dear all,
>>
>> in attachment the previous patch compatible with the current trunk.
>> The patch also includes the changes introduced in the latest TS 18508.
>>
>> Built and
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> I thought the MULTILIB* vars allow you to multilib on none of
> -msoft-stack/-muniform-simt and both -msoft-stack/-muniform-simt, without
> building other variants, so you wouldn't need this.
The nice effect of having -mgomp is better factorization: if I
On 12/02/2015 02:58 AM, Eric Botcazou wrote:
DWARF-2 (debug info for Scalar_Storage_Order attribute):
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01659.html
It doesn't look to me like DW_AT_endianity is applicable to array types
or members in DWARF 3/4; instead, it should be applied to th
On Wed, Dec 02, 2015 at 09:14:03AM -0500, Nathan Sidwell wrote:
> On 12/02/15 08:46, Jakub Jelinek wrote:
>
> >Or does the OpenACC execution model not allow anything like that, i.e.
> >have some function with an automatic variable pass the address of that
> >variable to some other function and tha
On 12/02/15 09:22, Jakub Jelinek wrote:
I believe Alex' testing revealed that if you take address of the same .local
objects in several threads, the addresses are the same, and therefore you
refer to your own .local space rather than the other thread's.
Before or after applying cvta?
nathan
On Wed, Dec 02, 2015 at 09:23:11AM -0500, Nathan Sidwell wrote:
> On 12/02/15 09:22, Jakub Jelinek wrote:
>
> >I believe Alex' testing revealed that if you take address of the same .local
> >objects in several threads, the addresses are the same, and therefore you
> >refer to your own .local space
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> Just wanted to see -fdump-tree-ompexp dump say from the testcase I've
> posted. Does your patchset have any dependencies that aren't on the trunk?
> If not, I guess I just could apply the patchset and look at the results, but
> if there are, it would need
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> On Wed, Dec 02, 2015 at 09:23:11AM -0500, Nathan Sidwell wrote:
> > On 12/02/15 09:22, Jakub Jelinek wrote:
> >
> > >I believe Alex' testing revealed that if you take address of the same
> > >.local
> > >objects in several threads, the addresses are t
On 12/02/15 09:24, Jakub Jelinek wrote:
On Wed, Dec 02, 2015 at 09:23:11AM -0500, Nathan Sidwell wrote:
On 12/02/15 09:22, Jakub Jelinek wrote:
I believe Alex' testing revealed that if you take address of the same .local
objects in several threads, the addresses are the same, and therefore you
On Wed, 2 Dec 2015, Nathan Sidwell wrote:
> On 12/02/15 05:40, Jakub Jelinek wrote:
> > Don't know the HW good enough, is there any power consumption, heat etc.
> > difference between the two approaches? I mean does the HW consume different
> > amount of power if only one thread in a warp execute
On 12/02/15 09:41, Alexander Monakov wrote:
On Wed, 2 Dec 2015, Nathan Sidwell wrote:
On 12/02/15 05:40, Jakub Jelinek wrote:
Don't know the HW good enough, is there any power consumption, heat etc.
difference between the two approaches? I mean does the HW consume different
amount of power if
On Wed, Dec 02 2015, Alan Lawrence wrote:
[...]
> Since this, we've been seeing these tests fail natively on AArch64 and ARM:
>
> FAIL: g++.dg/gcov/gcov-1.C -std=gnu++11 gcov: 3 failures in line
> counts, 0 in branch percentages, 0 in return percentages, 0 in
> intermediate format
> FAIL: g++.d
On Thu, Nov 12, 2015 at 5:08 PM, Ilya Enkovich wrote:
> Hi,
>
> When we use LTO for fortran we may have a mix 32bit and 1bit scalar booleans.
> It means we may have conversion of one scalar type to another which confuses
> vectorizer because values with different scalar boolean type may get the
On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> On Wed, Dec 02, 2015 at 08:02:47AM -0500, Nathan Sidwell wrote:
> > On 12/02/15 05:40, Jakub Jelinek wrote:
> > > Don't know the HW good enough, is there any power consumption, heat etc.
> > >difference between the two approaches? I mean does the HW cons
The friend function defined in enable_shared_from_this did not match
the declaration at namespace scope, so instead of defining the
previously declared function it added a new overload, which was always
a better match than the declared (but never defined) one.
That worked fine for a single base c
The PTX md file goes to a lot of effort handling SC and DC movs, including for
unspecs to mov low and high parts around. However, these code paths are not
exercised in any gcc test or the build of newlib. The generic handling of these
movs deals with type punning, (using the stack frame, if ne
On Wed, Dec 02, 2015 at 05:54:51PM +0300, Alexander Monakov wrote:
> On Wed, 2 Dec 2015, Jakub Jelinek wrote:
>
> > On Wed, Dec 02, 2015 at 08:02:47AM -0500, Nathan Sidwell wrote:
> > > On 12/02/15 05:40, Jakub Jelinek wrote:
> > > > Don't know the HW good enough, is there any power consumption, h
This fixes the vectorizer part of PR66051 (a x86 target part remains
for the testcase in the PR - PR68655). The issue is again a
misplaced check for SLP detection:
/* Check that the size of interleaved loads group is not
greater than the SLP group size. */
On 12/02/15 10:12, Jakub Jelinek wrote:
If we have a reasonable IPA pass to discover which addressable variables can
be shared by multiple threads and which can't, then we could use soft-stack
for those that can be shared by multiple PTX threads (different warps, or
same warp, different threads
2015-12-02 17:52 GMT+03:00 Richard Biener :
> On Thu, Nov 12, 2015 at 5:08 PM, Ilya Enkovich wrote:
>> Hi,
>>
>> When we use LTO for fortran we may have a mix 32bit and 1bit scalar
>> booleans. It means we may have conversion of one scalar type to another
>> which confuses vectorizer because val
On Wed, Dec 2, 2015 at 4:24 PM, Ilya Enkovich wrote:
> 2015-12-02 17:52 GMT+03:00 Richard Biener :
>> On Thu, Nov 12, 2015 at 5:08 PM, Ilya Enkovich
>> wrote:
>>> Hi,
>>>
>>> When we use LTO for fortran we may have a mix 32bit and 1bit scalar
>>> booleans. It means we may have conversion of one
On 30/11/15 20:30, Julian Brown wrote:
libgomp/
* oacc-parallel.c (GOACC_host_data): New function.
* libgomp.map (GOACC_host_data): Add to GOACC_2.0.1.
* testsuite/libgomp.oacc-c-c++-common/host_data-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/host_data-2.c: New
On 12/02/2015 04:09 PM, Nathan Sidwell wrote:
The PTX md file goes to a lot of effort handling SC and DC movs,
including for unspecs to mov low and high parts around. However, these
code paths are not exercised in any gcc test or the build of newlib.
The generic handling of these movs deals with
On 12/02/2015 02:54 AM, Richard Biener wrote:
Deferring to cfg_cleanup works because if cfg_cleanup does anything, it sets
LOOPS_NEED_FIXUP (which we were trying to avoid in DOM). So it seems that
the gyrations we often do to avoid LOOPS_NEED_FIXUP are probably not all
that valuable in the end.
On Wed, Dec 2, 2015 at 4:31 PM, Jeff Law wrote:
> On 12/02/2015 02:54 AM, Richard Biener wrote:
>>>
>>> Deferring to cfg_cleanup works because if cfg_cleanup does anything, it
>>> sets
>>> LOOPS_NEED_FIXUP (which we were trying to avoid in DOM). So it seems
>>> that
>>> the gyrations we often do
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
> Sent: Thursday, November 12, 2015 4:51 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [mips] Rotate stack checking loop
>
> Hi,
>
> this patch rotates the loop
On 12/02/2015 02:57 PM, Jakub Jelinek wrote:
Ok, thanks.
Great, thank you! I’ve pushed the change.
--
Pierre-Marie de Rodat
Hi!
Cesar and Jim copied, for help with Fortran and generally testsuite
things.
On Mon, 30 Nov 2015 19:30:34 +, Julian Brown
wrote:
> [patch]
First, thanks!
> Tests look OK (libgomp/gcc/g++/libstdc++), and the new ones pass.
I see a regression (ICE) in gfortran.dg/goacc/coarray.f95 (done
ping
Number of bugs found with this coverage in kernel already crossed 40:
https://github.com/google/syzkaller/wiki/Found-Bugs
On Fri, Nov 27, 2015 at 3:30 PM, Dmitry Vyukov wrote:
> +syzkaller group
>
> On Fri, Nov 27, 2015 at 3:28 PM, Dmitry Vyukov wrote:
>> Hello,
>>
>> This patch adds su
1 - 100 of 193 matches
Mail list logo
