[Committed, trunk/6] Handle NULL def in build_cross_bb_scalars_def
Hi,
Attached patch fixes a graphite 6/7 regression.
[ found regression by doing an fgraphite-identity on-by-default
bootstrap and regtest on x86_64. ]
When compiling gcc.dg/tree-ssa/vrp66.c with -O2 fgraphite-identity, we
arrive at graphite_find_cross_bb_scalar_vars:
...
static void
graphite_find_cross_bb_scalar_vars (scop_p scop, gimple *stmt,
vec *reads, vec
*writes)
{
tree def;
if (gimple_code (stmt) == GIMPLE_ASSIGN)
def = gimple_assign_lhs (stmt);
else if (gimple_code (stmt) == GIMPLE_CALL)
def = gimple_call_lhs (stmt);
else if (gimple_code (stmt) == GIMPLE_PHI)
def = gimple_phi_result (stmt);
else
return;
build_cross_bb_scalars_def (scop, def, gimple_bb (stmt), writes);
...
...
with as stmt a resultless call:
...
(gdb) call debug_gimple_stmt (stmt)
# VUSE <.MEM_10(D)>
f2 (_1);
...
Consequently, def becomes NULL_TREE and we run into an assert at the
start of build_cross_bb_scalars_def that asserts that def is not NULL_TREE.
This patch fixes the ICE by handling a NULL_TREE def in
build_cross_bb_scalars_def.
Bootstrapped and reg-tested on x86_64.
Approved at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956#c2 .
Committed to trunk, backported to 6 branch.
Thanks,
- Tom
Handle NULL def in build_cross_bb_scalars_def
2016-05-07 Tom de Vries
PR tree-optimization/70956
* graphite-scop-detection.c (build_cross_bb_scalars_def): Handle NULL
def.
* gcc.dg/graphite/pr70956.c: New test.
---
gcc/graphite-scop-detection.c | 3 +--
gcc/testsuite/gcc.dg/graphite/pr70956.c | 4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index 7615842..dd50a1e 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -1722,8 +1722,7 @@ static void
build_cross_bb_scalars_def (scop_p scop, tree def, basic_block def_bb,
vec *writes)
{
- gcc_assert (def);
- if (!is_gimple_reg (def))
+ if (!def || !is_gimple_reg (def))
return;
/* Do not gather scalar variables that can be analyzed by SCEV as they can be
diff --git a/gcc/testsuite/gcc.dg/graphite/pr70956.c b/gcc/testsuite/gcc.dg/graphite/pr70956.c
new file mode 100644
index 000..31fc25f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/graphite/pr70956.c
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fgraphite-identity" } */
+
+#include "../tree-ssa/vrp66.c"
Re: [PATCH] Make basic asm implicitly clobber memory
On 05/07/16 01:33, David Wohlferd wrote:
>
>>> A few questions:
>>>
>>> 1) I'm not clear precisely what problem this patch fixes. It's true
>>> that some people have incorrectly assumed that basic asm clobbers memory
>>> and this change would fix their code. But some people also incorrectly
>>> assume it clobbers registers. I assume that's why Jeff Law proposed
>>> making basic asm "an opaque blob that read/write/clobber any register or
>>> memory location." Do we have enough problem reports from users to know
>>> which is the real solution here?
>>>
>> Whenever I do something for gcc I do it actually for myself, in my own
>> best interest. And this is no exception.
>
> Seems fair. You are the one putting the time in to change it.
>
> But do you have actual code that is affected by this? You can't really
> be planning to wait until v7 is released to have your projects work
> correctly?
>
No, I can wait.
This is a long term investment in overall software reliability.
>> The way I see it, is this: in simple cases a basic asm behaves as if
>> it would clobber memory, because of the way Jeff implemented the
>> asm handling in sched-deps.c some 20 years ago.
>>
>> Look for ASM_INPUT where we have this comment:
>> "Traditional and volatile asm instructions must be considered to use
>>and clobber all hard registers, all pseudo-registers and all of
>>memory."
>>
>> The assumption that it is OK to clobber memory in a basic asm will only
>> break if the asm statement is inlined in a loop, and that may happen
>> unexpectedly, when gcc rolls out new optimizations.
>> That's why I consider this to be security relevant.
>
> I'm not sure I follow. Do you fear that gcc could mistakenly move the
> asm into a nearby loop during optimization (resulting in who-knows-what
> results)? Or is there some way that any basic asm in a loop could have
> some kind of a problem?
>
It is a risk, that who-knows-what will happen, unexpectedly.
Bernd.
>> But OTOH you see immediately that all general registers are in use
>> by gcc, unless you declare a variable like
>> register int eax __asm__("rax");
>> then it is perfectly OK to use rax in a basic asm of course.
>
> According to the docs, that is only supported for global registers. The
> docs for local register variables explicitly say that it can't be used
> as input/outputs for basic asm.
>
>> And if we want to have implicitly clobbered registers, like the
>> diab compiler handles the basic asm, then this patch will
>> make it possible to add a target hook that clobbers additional
>> registers for basic asm.
>
> I think we should try to avoid changing the semantics in v7 for memory
> and then changing them again in v8 for registers.
>
> IOW, if I see some basic asm in a project (or on stack overflow/blog as
> a code fragment), should I assume it was intended for v6 semantics? v7?
> v8? People often copy this stuff without understanding what it does.
> The more often the semantics change, the harder it is to use correctly
> and maintain.
>
>>> 2) The -Wbasic-asm warning patch wasn't approved for v6. If we are
>>> going to change this behavior now, is it time?
>>>
>> Yes. We have stage1 for gcc-7 development, I can't think of a better
>> time for it.
>> I would even say, the -Wbasic-asm warning patch makes more sense now,
>> because we could warn, that the basich asm clobbers memory, which it
>> did not previously.
>
> After your patch has been checked in, I'll re-submit this.
>
>>> 4) There are more basic asm docs that need to change: "It also does not
>>> know about side effects of the assembler code, such as modifications to
>>> memory or registers. Unlike some compilers, GCC assumes that no changes
>>> to either memory or registers occur. This assumption may change in a
>>> future release."
>>>
>> Yes, I should change that sentence too.
>>
>> Maybe this way:
>>
>> "Unlike some compilers, GCC assumes that no changes to registers
>> occur. This assumption may change in a future release."
>
> Is it worth describing the fact that the semantics have changed here?
> Something like "Before v7, gcc assumed no changes were made to memory."
> I guess users can "figure it out" by reading the v6 docs and comparing
> it to v7. But if the semantic change has introduced a problem that
> someone is trying to debug, this could help them track it down.
>
> Also, I'm kind of hoping that v7 is the 'future release.' If we are
> going to change the clobbers, I'd hope that we'd do it all at one time,
> rather than spreading it out across several releases.
>
> If no one is prepared to step up and implement (or at least defend) the
> idea of clobbering registers, I'd like to see the "This assumption may
> change in a future release" part removed. Since (theoretically)
> anything can change at any time, the only reason this text made sense
> was because a change was imminent. If that's no longer true, it's time
> for it to go.
>
> dw
[PING] [PATCH] Make C++ honor the enum mode attribute
Ping.. For this patch: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg02069.html Thanks Bernd. On 04/30/16 07:54, Bernd Edlinger wrote: > Hi, > > this was already posted in february, but has not yet been reviewed, so I > thought > it is time now to post it again... > > As a follow-up for Jakub's c/69669 fix, I'd like to have the enum mode also > honored > in C++ code, because the mode attribute now finally really works in C, but it > is > completely and silently(!) ignored by C++ code, which results in incompatible > code. > > So I duplicated what is done in c/c-decl.c also in cp/decl.c. That worked > immediately, except that it is not possible to explicitly check the "mode" > attribute in the TYPE_ATTRIBUTES (enumtype) because that attribute > is never copied to the type, and the original attribute list is not available > here. That should be OK, as this check was added to fix pr52085 which > does not apply here, because C++ does not support enum forward > declarations. > > If that patch is not appropriate for stage 4, I would at least want to emit > an attribute directive ignored warning in c++ mode. I think that could > be done in handle_mode_attribute. But fixing that feature is cooler. > > > Boot-strapped and regression tested on x86_64-pc-linux-gnu. > Ok for trunk and gcc-6 branch? > > > Thanks > Bernd. >
Re: [PATCH][CilkPlus] Merge libcilkrts from upstream
On 02.05.2016 17:51, Jeff Law wrote:
On 04/29/2016 05:36 AM, Ilya Verbin wrote:
Hi!
This patch brings the latest libcilkrts from upstream.
Regtested on i686-linux and x86_64-linux.
Abidiff:
Functions changes summary: 0 Removed, 1 Changed (16 filtered out), 2 Added
functions
Variables changes summary: 0 Removed, 0 Changed (1 filtered out), 0 Added
variable
2 Added functions:
'function void __cilkrts_resume()'{__cilkrts_resume@@CILKABI1}
'function void __cilkrts_suspend()'{__cilkrts_suspend@@CILKABI1}
1 function with some indirect sub-type change:
[C]'function __cilkrts_worker_ptr __cilkrts_bind_thread_1()' at
cilk-abi.c:412:1 has some indirect sub-type changes:
Please note that the symbol of this function is
__cilkrts_bind_thread@@CILKABI0
and it aliases symbol: __cilkrts_bind_thread_1@@CILKABI1
return type changed:
underlying type '__cilkrts_worker*' changed:
in pointed to type 'struct __cilkrts_worker' at abi.h:161:1:
1 data member changes (8 filtered):
type of 'global_state_t* __cilkrts_worker::g' changed:
in pointed to type 'typedef global_state_t' at abi.h:113:1:
underlying type 'struct global_state_t' at global_state.h:119:1
changed:
[...]
OK for trunk?
libcilkrts/
* Makefile.am: Merge from upstream, version 2.0.4420.0
.
* README: Likewise.
* configure.ac: Likewise.
* configure.tgt: Likewise.
* include/cilk/cilk.h: Likewise.
* include/cilk/cilk_api.h: Likewise.
* include/cilk/cilk_api_linux.h: Likewise.
* include/cilk/cilk_stub.h: Likewise.
* include/cilk/cilk_undocumented.h: Likewise.
* include/cilk/common.h: Likewise.
* include/cilk/holder.h: Likewise.
* include/cilk/hyperobject_base.h: Likewise.
* include/cilk/metaprogramming.h: Likewise.
* include/cilk/reducer.h: Likewise.
* include/cilk/reducer_file.h: Likewise.
* include/cilk/reducer_list.h: Likewise.
* include/cilk/reducer_max.h: Likewise.
* include/cilk/reducer_min.h: Likewise.
* include/cilk/reducer_min_max.h: Likewise.
* include/cilk/reducer_opadd.h: Likewise.
* include/cilk/reducer_opand.h: Likewise.
* include/cilk/reducer_opmul.h: Likewise.
* include/cilk/reducer_opor.h: Likewise.
* include/cilk/reducer_opxor.h: Likewise.
* include/cilk/reducer_ostream.h: Likewise.
* include/cilk/reducer_string.h: Likewise.
* include/cilktools/cilkscreen.h: Likewise.
* include/cilktools/cilkview.h: Likewise.
* include/cilktools/fake_mutex.h: Likewise.
* include/cilktools/lock_guard.h: Likewise.
* include/internal/abi.h: Likewise.
* include/internal/cilk_fake.h: Likewise.
* include/internal/cilk_version.h: Likewise.
* include/internal/metacall.h: Likewise.
* include/internal/rev.mk: Likewise.
* mk/cilk-version.mk: Likewise.
* runtime/acknowledgements.dox: Likewise.
* runtime/bug.cpp: Likewise.
* runtime/bug.h: Likewise.
* runtime/c_reducers.c: Likewise.
* runtime/cilk-abi-cilk-for.cpp: Likewise.
* runtime/cilk-abi-vla-internal.c: Likewise.
* runtime/cilk-abi-vla-internal.h: Likewise.
* runtime/cilk-abi.c: Likewise.
* runtime/cilk-ittnotify.h: Likewise.
* runtime/cilk-tbb-interop.h: Likewise.
* runtime/cilk_api.c: Likewise.
* runtime/cilk_fiber-unix.cpp: Likewise.
* runtime/cilk_fiber-unix.h: Likewise.
* runtime/cilk_fiber.cpp: Likewise.
* runtime/cilk_fiber.h: Likewise.
* runtime/cilk_malloc.c: Likewise.
* runtime/cilk_malloc.h: Likewise.
* runtime/component.h: Likewise.
* runtime/config/generic/cilk-abi-vla.c: Likewise.
* runtime/config/generic/os-fence.h: Likewise.
* runtime/config/generic/os-unix-sysdep.c: Likewise.
* runtime/config/x86/cilk-abi-vla.c: Likewise.
* runtime/config/x86/os-fence.h: Likewise.
* runtime/config/x86/os-unix-sysdep.c: Likewise.
* runtime/doxygen-layout.xml: Likewise.
* runtime/doxygen.cfg: Likewise.
* runtime/except-gcc.cpp: Likewise.
* runtime/except-gcc.h: Likewise.
* runtime/except.h: Likewise.
* runtime/frame_malloc.c: Likewise.
* runtime/frame_malloc.h: Likewise.
* runtime/full_frame.c: Likewise.
* runtime/full_frame.h: Likewise.
* runtime/global_state.cpp: Likewise.
* runtime/global_state.h: Likewise.
* runtime/jmpbuf.c: Likewise.
* runtime/jmpbuf.h: Likewise.
* runtime/linux-symbols.ver: Likewise.
* runtime/local_state.c: Likewise.
* runtime/local_state.h: Likewise.
* runtime/mac-symbols.txt: Likewise.
* runtime/metacall_impl.c: Likewise.
* runtime/metacall_impl.h: Likewise.
* runtime/os-unix.c: Likewise.
* runtime/os.h: Likewise.
* runtime/os_mutex-unix.c: Likewise.
* runtime/os_mutex.h: Likewise.
* runtime/pedigrees.c: Likewise.
* runtime/pedigrees.h: Likewise.
* runtime/record-replay.cpp: Likewise.
* ru
[PATCH, i386]: Handle otential partial reg stall alternatives with preferred_for_speed attribute
Hello!
We have these long-standing comments in i386.md:
"%%% Potential partial reg stall on alternative X. What to do?"
Using preferred_for_speed attribute, we can disparage these
alternatives for TARGET_PARTIAL_REG_STALL targets, which seems the
correct thing to do.
2016-05-07 Uros Bizjak
* config/i386/i386.md (*addqi_1): Add preferred_for_speed attribute
to disparage alternatives 3 and 4 for TARGET_PARTIAL_REG_STALL targets.
(*andqi_1): Add preferred_for_speed attribute to disparage
alternative 2 for TARGET_PARTIAL_REG_STALL targets.
(*qi_1): Ditto.
(*one_cmplqi2_1): Add preferred_for_speed attribute to disparage
alternative 1 for TARGET_PARTIAL_REG_STALL targets.
(*ashlqi3_1): Ditto.
(*swap): Merge from *swap_1 and *swap_2 patterns.
Add preferred_for_size attribute to disparage alternative 0 and
preferred_for_speed attribute to disparage alternative 1 for
TARGET_PARTIAL_REG_STALL targets.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: i386.md
===
--- i386.md (revision 235995)
+++ i386.md (working copy)
@@ -2699,34 +2699,31 @@
(set_attr "amdfam10_decode" "double")
(set_attr "bdver1_decode" "double")])
-(define_insn "*swap_1"
- [(set (match_operand:SWI12 0 "register_operand" "+r")
- (match_operand:SWI12 1 "register_operand" "+r"))
+(define_insn "*swap"
+ [(set (match_operand:SWI12 0 "register_operand" "+,r")
+ (match_operand:SWI12 1 "register_operand" "+,r"))
(set (match_dup 1)
(match_dup 0))]
- "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
- "xchg{l}\t%k1, %k0"
+ ""
+ "@
+ xchg{}\t%1, %0
+ xchg{l}\t%k1, %k0"
[(set_attr "type" "imov")
- (set_attr "mode" "SI")
+ (set_attr "mode" ",SI")
+ (set (attr "preferred_for_size")
+ (cond [(eq_attr "alternative" "0")
+ (symbol_ref "false")]
+ (symbol_ref "true")))
+ ;; Potential partial reg stall on alternative 1.
+ (set (attr "preferred_for_speed")
+ (cond [(eq_attr "alternative" "1")
+ (symbol_ref "!TARGET_PARTIAL_REG_STALL")]
+ (symbol_ref "true")))
(set_attr "pent_pair" "np")
(set_attr "athlon_decode" "vector")
(set_attr "amdfam10_decode" "double")
(set_attr "bdver1_decode" "double")])
-;; Not added amdfam10_decode since TARGET_PARTIAL_REG_STALL
-;; is disabled for AMDFAM10
-(define_insn "*swap_2"
- [(set (match_operand:SWI12 0 "register_operand" "+")
- (match_operand:SWI12 1 "register_operand" "+"))
- (set (match_dup 1)
- (match_dup 0))]
- "TARGET_PARTIAL_REG_STALL"
- "xchg{}\t%1, %0"
- [(set_attr "type" "imov")
- (set_attr "mode" "")
- (set_attr "pent_pair" "np")
- (set_attr "athlon_decode" "vector")])
-
(define_expand "movstrict"
[(set (strict_low_part (match_operand:SWI12 0 "nonimmediate_operand"))
(match_operand:SWI12 1 "general_operand"))]
@@ -5607,7 +5604,6 @@
(const_string "*")))
(set_attr "mode" "HI,HI,HI,SI")])
-;; %%% Potential partial reg stall on alternatives 3 and 4. What to do?
(define_insn "*addqi_1"
[(set (match_operand:QI 0 "nonimmediate_operand" "=qm,q,q,r,r,Yp")
(plus:QI (match_operand:QI 1 "nonimmediate_operand" "%0,0,q,0,r,Yp")
@@ -5615,7 +5611,7 @@
(clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (PLUS, QImode, operands)"
{
- bool widen = (which_alternative == 3 || which_alternative == 4);
+ bool widen = (get_attr_mode (insn) != MODE_QI);
switch (get_attr_type (insn))
{
@@ -5664,7 +5660,12 @@
(and (eq_attr "type" "alu") (match_operand 2 "const128_operand"))
(const_string "1")
(const_string "*")))
- (set_attr "mode" "QI,QI,QI,SI,SI,SI")])
+ (set_attr "mode" "QI,QI,QI,SI,SI,SI")
+ ;; Potential partial reg stall on alternatives 3 and 4.
+ (set (attr "preferred_for_speed")
+ (cond [(eq_attr "alternative" "3,4")
+ (symbol_ref "!TARGET_PARTIAL_REG_STALL")]
+ (symbol_ref "true")))])
(define_insn "*addqi_1_slp"
[(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+qm,q"))
@@ -8215,7 +8216,6 @@
(const_string "*")))
(set_attr "mode" "HI,HI,SI,HI")])
-;; %%% Potential partial reg stall on alternative 2. What to do?
(define_insn "*andqi_1"
[(set (match_operand:QI 0 "nonimmediate_operand" "=qm,q,r,!k")
(and:QI (match_operand:QI 1 "nonimmediate_operand" "%0,0,0,k")
@@ -8238,7 +8238,12 @@
}
}
[(set_attr "type" "alu,alu,alu,msklog")
- (set_attr "mode" "QI,QI,SI,HI")])
+ (set_attr "mode" "QI,QI,SI,HI")
+ ;; Potential partial reg stall on alternative 2.
+ (set (attr "preferred_for_speed")
+ (cond [(eq_attr "alternative" "2")
+ (symbol_ref "!TARGET_PARTIAL_REG_STALL")]
+ (symbol_ref "true")))])
(define_insn "*andqi_1_slp"
[(set (strict_low_part (match_operand:QI 0 "nonimmediate_operan
Re: [PATCH] Make basic asm implicitly clobber memory
On 06/05/16 07:35, David Wohlferd wrote: > 1) I'm not clear precisely what problem this patch fixes. It's true > that some people have incorrectly assumed that basic asm clobbers > memory and this change would fix their code. But some people also > incorrectly assume it clobbers registers. I assume that's why Jeff > Law proposed making basic asm "an opaque blob that > read/write/clobber any register or memory location." A few more things: Jeff Law did propose this, but it's impossible to do because it inevitably causes reload failures. My argument in support of Bernd's proposal is that it makes sense from a *practical* software reliability point of view. It wouldn't hurt, and might fix some significant bugs. It's similar to the targets which always implicitly clobber "cc". It corresponds to what I always assumed basic asm did, and I'm sure that I'm not alone. This change might fix some real bugs and it is extremely unlikely to break anything. Andrew.
Re: [gomp4.5] Parsing of most of OpenMP 4.5 clauses
Dear Jakub,
As you might have noticed, I am forced to spend a couple of months out
from gfortran support in order to move from France back to the UK. I
am therefore dealing very sporadically with patches. Since we seem to
have entered a phase where all the other gfortran contributors have
gone quiet, I suggest that where omp patches are concerned you commit
when you are satisfied that all is well.
I have taken a rapid look through your patch and cannot see anything
to object to. OK by me for trunk.
Cheers
Paul
On 6 May 2016 at 21:32, Jakub Jelinek wrote:
> Hi!
>
> This patch adds parsing of most of the OpenMP 4.5 clause changes,
> though doesn't do anything during resolve or later with them yet.
> Missing is still depend clause parsing changes (sink and source) and
> link and to clause for declare target construct.
>
> 2016-05-06 Jakub Jelinek
>
> * gfortran.h (enum gfc_omp_map_op): Add OMP_MAP_RELEASE,
> OMP_MAP_ALWAYS_TO, OMP_MAP_ALWAYS_FROM and OMP_MAP_ALWAYS_TOFROM.
> (OMP_LIST_IS_DEVICE_PTR, OMP_LIST_USE_DEVICE_PTR): New.
> (enum gfc_omp_if_kind): New.
> (struct gfc_omp_clauses): Add orderedc, defaultmap, nogroup,
> sched_simd, sched_monotonic, sched_nonmonotonic, simd, threads,
> grainsize, hint, num_tasks, priority and if_exprs fields.
> * openmp.c (gfc_free_omp_clauses): Free grainsize, hint, num_tasks,
> priority and if_exprs.
> (enum omp_mask1): Add OMP_CLAUSE_DEFAULTMAP, OMP_CLAUSE_GRAINSIZE,
> OMP_CLAUSE_HINT, OMP_CLAUSE_IS_DEVICE_PTR, OMP_CLAUSE_LINK,
> OMP_CLAUSE_NOGROUP, OMP_CLAUSE_NUM_TASKS, OMP_CLAUSE_PRIORITY,
> OMP_CLAUSE_SIMD, OMP_CLAUSE_THREADS, OMP_CLAUSE_USE_DEVICE_PTR
> and OMP_CLAUSE_NOWAIT.
> (enum omp_mask2): Remove OMP_CLAUSE_OACC_DEVICE and OMP_CLAUSE_LINK.
> (gfc_match_omp_clauses): Move delete clause handling to where it
> alphabetically belongs. Parse defaultmap, grainsize, hint,
> is_device_ptr, nogroup, nowait, num_tasks, priority, simd, threads
> and use_device_ptr clauses. Parse if clause modifier. Parse map
> clause always modifier, and release and delete kinds. Parse ordered
> clause with argument. Parse schedule clause modifiers. Differentiate
> device clause parsing based on openacc flag. Guard link clause
> parsing with openacc flag.
> (OACC_UPDATE_CLAUSES): Replace OMP_CLAUSE_OACC_DEVICE with
> OMP_CLAUSE_DEVICE.
> (OMP_TASK_CLAUSES): Add OMP_CLAUSE_PRIORITY.
> (OMP_TARGET_CLAUSES): Add OMP_CLAUSE_DEPEND, OMP_CLAUSE_NOWAIT,
> OMP_CLAUSE_PRIVATE, OMP_CLAUSE_FIRSTPRIVATE, OMP_CLAUSE_DEFAULTMAP
> and OMP_CLAUSE_IS_DEVICE_PTR.
> (OMP_TARGET_DATA_CLAUSES): Add OMP_CLAUSE_USE_DEVICE_PTR.
> (OMP_TARGET_UPDATE_CLAUSES): Add OMP_CLAUSE_DEPEND and
> OMP_CLAUSE_NOWAIT.
> (resolve_omp_clauses): Add dummy OMP_LIST_IS_DEVICE_PTR and
> OMP_LIST_USE_DEVICE_PTR cases.
> * frontend-passes.c (gfc_code_walker): Handle new OpenMP 4.5
> expressions.
> * dump-parse-tree.c (show_omp_clauses): Adjust for OpenMP 4.5
> clause changes.
>
> --- gcc/fortran/gfortran.h.jj 2016-05-04 18:37:26.0 +0200
> +++ gcc/fortran/gfortran.h 2016-05-06 19:01:13.813857650 +0200
> @@ -1120,7 +1120,11 @@ enum gfc_omp_map_op
>OMP_MAP_FORCE_PRESENT,
>OMP_MAP_FORCE_DEVICEPTR,
>OMP_MAP_DEVICE_RESIDENT,
> - OMP_MAP_LINK
> + OMP_MAP_LINK,
> + OMP_MAP_RELEASE,
> + OMP_MAP_ALWAYS_TO,
> + OMP_MAP_ALWAYS_FROM,
> + OMP_MAP_ALWAYS_TOFROM
> };
>
> /* For use in OpenMP clauses in case we need extra information
> @@ -1165,6 +1169,8 @@ enum
>OMP_LIST_LINK,
>OMP_LIST_USE_DEVICE,
>OMP_LIST_CACHE,
> + OMP_LIST_IS_DEVICE_PTR,
> + OMP_LIST_USE_DEVICE_PTR,
>OMP_LIST_NUM
> };
>
> @@ -1207,6 +1213,19 @@ enum gfc_omp_cancel_kind
>OMP_CANCEL_TASKGROUP
> };
>
> +enum gfc_omp_if_kind
> +{
> + OMP_IF_PARALLEL,
> + OMP_IF_TASK,
> + OMP_IF_TASKLOOP,
> + OMP_IF_TARGET,
> + OMP_IF_TARGET_DATA,
> + OMP_IF_TARGET_UPDATE,
> + OMP_IF_TARGET_ENTER_DATA,
> + OMP_IF_TARGET_EXIT_DATA,
> + OMP_IF_LAST
> +};
> +
> typedef struct gfc_omp_clauses
> {
>struct gfc_expr *if_expr;
> @@ -1216,9 +1235,11 @@ typedef struct gfc_omp_clauses
>enum gfc_omp_sched_kind sched_kind;
>struct gfc_expr *chunk_size;
>enum gfc_omp_default_sharing default_sharing;
> - int collapse;
> + int collapse, orderedc;
>bool nowait, ordered, untied, mergeable;
> - bool inbranch, notinbranch;
> + bool inbranch, notinbranch, defaultmap, nogroup;
> + bool sched_simd, sched_monotonic, sched_nonmonotonic;
> + bool simd, threads;
>enum gfc_omp_cancel_kind cancel;
>enum gfc_omp_proc_bind_kind proc_bind;
>struct gfc_expr *safelen_expr;
> @@ -1226,6 +1247,11 @@ typedef struct gfc_omp_clauses
>struct gfc_expr *num_teams;
>struct gfc_expr *device;
>struct gfc_expr *
Re: [gomp4.5] Parsing of most of OpenMP 4.5 clauses
On Sat, May 07, 2016 at 08:42:44PM +0200, Paul Richard Thomas wrote: > As you might have noticed, I am forced to spend a couple of months out > from gfortran support in order to move from France back to the UK. I > am therefore dealing very sporadically with patches. Since we seem to > have entered a phase where all the other gfortran contributors have > gone quiet, I suggest that where omp patches are concerned you commit > when you are satisfied that all is well. > > I have taken a rapid look through your patch and cannot see anything > to object to. OK by me for trunk. The patch has been committed already to gomp-4_5-branch, where I want to get the OpenMP 4.5 Fortran support at least to a reasonable shape before pushing it back to trunk (I hope within 2 months or so). The patches fall into my OpenMP maintainership anyway, so I can commit them without waiting for approval, but of course will appreciate comments if somebody finds something. I've CCed fortran@ mailing list just because all this is Fortran FE. Jakub
[patch] Fix PR tree-optimization/70884
Hi,
this is a tentative fix for the regression introduced in SRA by the machinery
which deals with the constant pool. initialize_constant_pool_replacements is
supposed to issues new loads from the pool for scalarized variables, but it
fails to do so for variables that are only partially scalarized.
Tested on PowerPC/Linux and x86-64/Linux, OK for mainline and 6 branch?
2016-05-07 Eric Botcazou
PR tree-optimization/70884
* tree-sra.c (initialize_constant_pool_replacements): Process all the
candidate variables.
2016-05-07 Eric Botcazou
* gcc.dg/pr70884.c: New test.
--
Eric BotcazouIndex: tree-sra.c
===
--- tree-sra.c (revision 235544)
+++ tree-sra.c (working copy)
@@ -3559,8 +3559,6 @@ initialize_constant_pool_replacements (v
unsigned i;
EXECUTE_IF_SET_IN_BITMAP (candidate_bitmap, 0, i, bi)
-if (bitmap_bit_p (should_scalarize_away_bitmap, i)
- && !bitmap_bit_p (cannot_scalarize_away_bitmap, i))
{
tree var = candidate (i);
if (!constant_decl_p (var))
/* { dg-do run } */
/* { dg-options "-O -fno-tree-fre" } */
extern void abort (void);
typedef __UINTPTR_TYPE__ uintptr_t;
struct S { uintptr_t a; int i; };
static void __attribute__((noclone, noinline)) foo (struct S s)
{
if (!s.a)
abort ();
}
int i;
static void f1 (void)
{
struct S s1 = { (uintptr_t) &i, 1 };
foo (s1);
}
static void f2 (void)
{
struct S s2 = { (uintptr_t) &i, 1 };
foo (s2);
}
int main (void)
{
f1 ();
f2 ();
return 0;
}
Re: [PATCH, ARM] use vmov.i64 to load 0 into FP reg if neon enabled
On Fri, May 6, 2016 at 7:29 AM, Kyrill Tkachov wrote: > Since you're modifying the both the ARM and Thumb2 pattern > can you please do two bootstrap and tests, one with --with-mode=arm > and one with --with-mode=thumb. > Ok after adding the assert mentioned above, the arm/thumb testing and fixing > a minor nit below... > > Please add a tab before the "@float" comment i.e. "\\t%@ float". I updated the patch as requested, and remembered to test both arm and thumb mode this time, both passed without regression. I checked in the patch. Revised patch attached. Jim arm-vmov-i64.patch.2 Description: Binary data
Fortran patch committed [revision 235999]
I have committed a patch for PR fortran/56226. The diff is available as an attachment in the bugzilla PR. Details about the patch can be found here: https://gcc.gnu.org/ml/fortran/2016-03/msg2.html -- Steve
