[SH][committed] Fix PR 70416
Hi,
The attached patch fixes PR 70416. For details, please see the PR
audit trail.
Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
Committed to trunk as r234702. Backport to GCC 5 branch will follow
after a while.
Cheers,
Oleg
gcc/ChangeLog:
PR target/70416
PR target/67391
* config/sh/sh.md (*addsi3): Allow pattern when reload_in_progress is
set, but not for SP_REG operands.
gcc/testsuite/ChangeLog:
PR target/70416
PR target/67391
* gcc.target/sh/torture/pr70416.c: New.Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 234701)
+++ gcc/config/sh/sh.md (working copy)
@@ -2242,14 +2242,23 @@
[(set_attr "type" "arith")])
;; Old reload might generate add insns directly (not through the expander) for
-;; the memory address of complex insns like atomic insns when reloading.
+;; address register calculations when reloading, in which case it won't try
+;; the addsi_scr pattern. Because reload will sometimes try to validate
+;; the generated insns and their constraints, this pattern must be
+;; recognizable during and after reload. However, when reload generates
+;; address register calculations for the stack pointer, we don't allow this
+;; pattern. This will make reload prefer using indexed @(reg + reg) address
+;; modes when the displacement of a @(disp + reg) doesn't fit.
(define_insn_and_split "*addsi3"
[(set (match_operand:SI 0 "arith_reg_dest" "=r")
(plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
(match_operand:SI 2 "arith_or_int_operand" "rn")))]
"TARGET_SH1 && !sh_lra_p ()
- && reload_completed
- && !reg_overlap_mentioned_p (operands[0], operands[1])"
+ && (reload_completed || reload_in_progress)
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && (!reload_in_progress
+ || ((!REG_P (operands[1]) || REGNO (operands[1]) != SP_REG)
+ && (!REG_P (operands[2]) || REGNO (operands[2]) != SP_REG)))"
"#"
"&& 1"
[(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
Index: gcc/testsuite/gcc.target/sh/torture/pr70416.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr70416.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/pr70416.c (working copy)
@@ -0,0 +1,136 @@
+/* { dg-additional-options "-std=gnu99 -fpic" } */
+/* { dg-do compile } */
+
+typedef unsigned long VALUE;
+typedef unsigned long ID;
+
+typedef struct rb_callable_method_entry_struct
+{
+ ID called_id;
+ const VALUE owner;
+} rb_callable_method_entry_t;
+
+typedef struct rb_iseq_struct rb_iseq_t;
+
+struct __jmp_buf_tag { int xx; };
+typedef struct __jmp_buf_tag jmp_buf[1];
+
+struct rb_iseq_struct
+{
+ const struct iseq_catch_table *catch_table;
+};
+
+typedef struct rb_control_frame_struct
+{
+ const VALUE *pc;
+ VALUE *sp;
+ const rb_iseq_t *iseq;
+ VALUE flag;
+ VALUE *ep;
+} rb_control_frame_t;
+
+typedef jmp_buf rb_jmpbuf_t;
+struct rb_vm_tag
+{
+ rb_jmpbuf_t buf;
+}rb_ensure_list_t;
+
+typedef struct rb_thread_struct
+{
+ rb_control_frame_t *cfp;
+ struct rb_vm_tag *tag;
+} rb_thread_t;
+
+struct iseq_catch_table_entry
+{
+ const rb_iseq_t *iseq;
+};
+
+struct iseq_catch_table
+{
+ unsigned int size;
+};
+
+extern unsigned long long __sdt_unsp;
+extern unsigned short ruby_cmethod__return_semaphore;
+
+struct ruby_dtrace_method_hook_args
+{
+ const char *classname;
+ const char *methodname;
+ const char *filename;
+ int line_no;
+};
+
+int ruby_th_dtrace_setup(rb_thread_t *th, VALUE klass, ID id, struct ruby_dtrace_method_hook_args *args);
+int rb_threadptr_tag_state (rb_thread_t *th);
+VALUE vm_exec_core (rb_thread_t *th, VALUE initial);
+const rb_callable_method_entry_t *rb_vm_frame_method_entry (const rb_control_frame_t *cfp);
+
+struct vm_throw_data;
+const rb_control_frame_t * THROW_DATA_CATCH_FRAME(const struct vm_throw_data *obj);
+rb_control_frame_t * vm_push_frame(rb_thread_t *th, const rb_iseq_t *iseq, VALUE type, VALUE self, VALUE specval, VALUE cref_or_me, const VALUE *pc, VALUE *sp, int local_size, int stack_max);
+
+
+VALUE vm_exec(rb_thread_t *th)
+{
+ int state;
+ VALUE result;
+ VALUE initial = 0;
+ struct vm_throw_data *err;
+ rb_thread_t * const _th = (th);
+ struct rb_vm_tag _tag;
+
+ if ((state = (__builtin_setjmp((_tag.buf)) ? rb_threadptr_tag_state((_th)) : ((void)(_th->tag = &_tag), 0))) == 0)
+ {
+result = vm_exec_core(th, initial);
+ }
+ else
+ {
+unsigned int i;
+const struct iseq_catch_table_entry *entry;
+const struct iseq_catch_table *ct;
+unsigned long epc, cont_pc, cont_sp;
+const rb_iseq_t *catch_iseq;
+rb_control_frame_t *cfp;
+const rb_control_frame_t *escape_cfp;
+
+while (th->cfp->pc == 0 || th->cfp->iseq == 0)
+{
+ if (ruby_cmethod__return_semaphore)
+ {
[Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
Hi all,
attached patch fixes a segfault when allocating a coarray of a type
that has allocatable components. Before the patch the compiler tried
to ref the component to nullify from the coarray's base address and not
from its .data component. The proposed patch fixes this by preventing
the nullify of the components in the array_allocate() for coarrays,
because the components are nullified again afterwards by copying a
fully nullified copy of the type to the coarray's data component.
There albeit is an alternative to this patch:
trans-array.c: 5556+
- tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr,
+ tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, coarray ?
+ pointer : se->expr,
ref->u.ar.as->rank);
The above adds a second nullify to the generated code before the one
done the object copy mentioned above.
Because I am unsure which patch is best, I propose both. I do favor of
course the one without the duplicate nullify as attached.
Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for trunk?
The patch also applies (with a small delta) to gcc-5 w/o any
regressions. Ok for gcc-5-branch?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr65795_1.clog
Description: Binary data
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 649b80f..825dfb8 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -5550,8 +5550,8 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
else
gfc_add_expr_to_block (&se->pre, set_descriptor);
- if ((expr->ts.type == BT_DERIVED)
- && expr->ts.u.derived->attr.alloc_comp)
+ if (expr->ts.type == BT_DERIVED && expr->ts.u.derived->attr.alloc_comp
+ && !coarray)
{
tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr,
ref->u.ar.as->rank);
diff --git a/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08 b/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08
new file mode 100644
index 000..8394c30
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_allocate_6.f08
@@ -0,0 +1,27 @@
+! { dg-do run }
+! { dg-options "-fcoarray=single" }
+
+! Contributed by Tobias Burnus
+! Test fix for pr65795.
+
+implicit none
+
+type t2
+ integer, allocatable :: x
+end type t2
+
+type t3
+ type(t2), allocatable :: caf[:]
+end type t3
+
+!type(t3), save, target :: c, d
+type(t3), target :: c, d
+integer :: stat
+
+allocate(c%caf[*], stat=stat)
+end
+
+! Besides checking that the executable does not crash anymore, check
+! that the cause has been remove.
+! { dg-final { scan-tree-dump-not "c.caf.x = 0B" "original" } }
+
[Fortran, Patch, pr66911, gcc-5, v1] ICE on allocate character with source as a derived type component
Hi all,
attached patch fixes the ICE when using a deferred length char array as
source= expression in an allocate for complicated source= expressions.
Before the patch the compiler was relying on having the string length
available in the ts of the expression, but when the expression is
sufficiently complicated it is not set there. In trunk the problem does
not arise, because the source= expression is evaluated in more cases.
In gcc-5 this is not available without doing a major rewrite of the
allocate() statement's conv-routine. Therefore this small portion of
extra code reliably does the trick and takes the string_length from the
se.string_length now.
Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for
gcc-5-branch?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr66911_gcc-5_1.clog
Description: Binary data
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index b33bad7..25c2a0c 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5536,14 +5536,23 @@ gfc_trans_allocate (gfc_code * code)
if (expr3_len == NULL_TREE
&& code->expr3->ts.type == BT_CHARACTER)
{
+ gfc_init_se (&se, NULL);
if (code->expr3->ts.u.cl
&& code->expr3->ts.u.cl->length)
{
- gfc_init_se (&se, NULL);
gfc_conv_expr (&se, code->expr3->ts.u.cl->length);
gfc_add_block_to_block (&block, &se.pre);
expr3_len = gfc_evaluate_now (se.expr, &block);
}
+ else
+ {
+ /* The string_length is not set in the symbol, which prevents
+ it being set in the ts. Deduce it by converting expr3. */
+ gfc_conv_expr (&se, code->expr3);
+ gfc_add_block_to_block (&block, &se.pre);
+ gcc_assert (se.string_length);
+ expr3_len = gfc_evaluate_now (se.string_length, &block);
+ }
gcc_assert (expr3_len);
}
/* For character arrays only the kind's size is needed, because
diff --git a/gcc/testsuite/gfortran.dg/deferred_character_16.f90 b/gcc/testsuite/gfortran.dg/deferred_character_16.f90
new file mode 100644
index 000..27fb112
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/deferred_character_16.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+
+program truc
+implicit none
+
+type t_env_table
+character(len=:), allocatable :: key
+end type
+
+type(t_env_table), dimension(:), allocatable :: environment_table
+
+character(len=:), allocatable :: s
+
+allocate(environment_table(1))
+environment_table(1)%key='tt'
+
+allocate(s, source=environment_table(1)%key)
+
+if ( .not. allocated(s) ) call abort()
+if ( s /= "tt" ) call abort()
+if ( len(s) /= 2 ) call abort()
+!print *, 's:"', s, '" derived:"',environment_table(1)%key,'"'
+
+end program
[Fortran, Patch, pr67538, v1] ICE with invalid source allocation
Hi all,
the attached patch checks that for F2008-style allocate(arr1, source=s)
the expression in s is array valued, when arr1 has no array spec and
emits an error message saying:
Array specification or array-valued SOURCE= expression required in ALLOCATE
statement at (1)
This fixes the ICE.
Bootstrapped and regtests ok on x86_64-linux-gnu/F23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr67538_1.clog
Description: Binary data
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 55ab2ec..f5cd588 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -7217,7 +7217,15 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
if (!gfc_notify_std (GFC_STD_F2008, "Array specification required "
"in ALLOCATE statement at %L", &e->where))
goto failure;
- *array_alloc_wo_spec = true;
+ if (code->expr3->rank != 0)
+ *array_alloc_wo_spec = true;
+ else
+ {
+ gfc_error ("Array specification or array-valued SOURCE= "
+ "expression required in ALLOCATE statement at %L",
+ &e->where);
+ goto failure;
+ }
}
else
{
diff --git a/gcc/testsuite/gfortran.dg/allocate_with_source_19.f08 b/gcc/testsuite/gfortran.dg/allocate_with_source_19.f08
new file mode 100644
index 000..ff84510
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/allocate_with_source_19.f08
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options -std=f2008 }
+
+! Contributed by mreste...@gmail.com
+! Check that instead of an ICE the error message is emitted.
+
+module m
+ implicit none
+contains
+
+ subroutine s()
+ real, allocatable :: x(:)
+ real :: y
+
+ y = 5.0
+ ! x either needs an array spec, or y needs to be an array.
+ allocate( x , source=y ) ! { dg-error "Array specification or array-valued SOURCE= expression required in ALLOCATE statement" }
+
+ end subroutine s
+
+end module m
+
Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
On 04/03/2016 06:35 AM, Andre Vehreschild wrote: > Hi all, > > attached patch fixes a segfault when allocating a coarray of a type > that has allocatable components. Before the patch the compiler tried > to ref the component to nullify from the coarray's base address and not > from its .data component. The proposed patch fixes this by preventing > the nullify of the components in the array_allocate() for coarrays, > because the components are nullified again afterwards by copying a > fully nullified copy of the type to the coarray's data component. > > There albeit is an alternative to this patch: > > trans-array.c: 5556+ > > - tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr, > + tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, coarray ? > + pointer : se->expr, > ref->u.ar.as->rank); > > The above adds a second nullify to the generated code before the one > done the object copy mentioned above. > > Because I am unsure which patch is best, I propose both. I do favor of > course the one without the duplicate nullify as attached. > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for trunk? > > The patch also applies (with a small delta) to gcc-5 w/o any > regressions. Ok for gcc-5-branch? > > Regards, > Andre > OK for trunk and gcc-5. Go with your preferred. Jerry
Re: [Fortran, Patch, pr67538, v1] ICE with invalid source allocation
On 04/03/2016 09:13 AM, Andre Vehreschild wrote: > Hi all, > > the attached patch checks that for F2008-style allocate(arr1, source=s) > the expression in s is array valued, when arr1 has no array spec and > emits an error message saying: > > Array specification or array-valued SOURCE= expression required in ALLOCATE > statement at (1) > > This fixes the ICE. > > Bootstrapped and regtests ok on x86_64-linux-gnu/F23. Ok for trunk? > > Regards, > Andre > Yes, OK, thanks for patches. Jerry
Re: [Fortran, Patch, pr66911, gcc-5, v1] ICE on allocate character with source as a derived type component
On 04/03/2016 08:33 AM, Andre Vehreschild wrote: > Hi all, > > attached patch fixes the ICE when using a deferred length char array as > source= expression in an allocate for complicated source= expressions. > Before the patch the compiler was relying on having the string length > available in the ts of the expression, but when the expression is > sufficiently complicated it is not set there. In trunk the problem does > not arise, because the source= expression is evaluated in more cases. > In gcc-5 this is not available without doing a major rewrite of the > allocate() statement's conv-routine. Therefore this small portion of > extra code reliably does the trick and takes the string_length from the > se.string_length now. > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for > gcc-5-branch? > > Regards, > Andre > Yes, OK Thanks for your work. Jerry
Optimize weakrefs
Hi,
this patch fixes failure in lto/attr-weakref-1 with plugin disabled setup. The
issue is that currently
gas rejects .weakref referring to symbol defined in the same translation unit.
/tmp/cc0Zk0UZ.s: Assembler messages:
/tmp/cc0Zk0UZ.s:121: Error: symbol definition loop encountered at
`callmealias.lto_priv.0'
The message is wrong (there is no loop) and should be also fixed at gas side
https://sourceware.org/bugzilla/show_bug.cgi?id=19498
This patch makes weakref to turn into static alias when aliases are supported
and the
target binds to current def.
When alias target is defined in current unit and thus we know it will be
defined (possibly
to other definition) and there is no used attribute, we turn the weakref into
transparent
alias.
Both should result in slightly better code, but the only code that benefits is
code that
defines weakrefs target which in practice IMO means that you need to LTO glibc
itself in.
This is currently not supported (one can't LTO runtime libraries)
Bootstrapepd/regtested x86_64-linux, will commit it shortly.
Honza
PR ipa/68881
* cgraph.h (symtab_node::copy_visibility_from): New function.
* symtab.c (symtab_node::copy_visibility_from): New function.
* ipa-visibility.c (optimize_weakref): New function.
(function_and_variable_visibility): Use it.
Index: cgraph.h
===
--- cgraph.h(revision 234669)
+++ cgraph.h(working copy)
@@ -293,6 +293,9 @@ public:
/* Make DECL local. */
void make_decl_local (void);
+ /* Copy visibility from N. */
+ void copy_visibility_from (symtab_node *n);
+
/* Return desired alignment of the definition. This is NOT alignment useful
to access THIS, because THIS may be interposable and DECL_ALIGN should
be used instead. It however must be guaranteed when output definition
Index: ipa-visibility.c
===
--- ipa-visibility.c(revision 234669)
+++ ipa-visibility.c(working copy)
@@ -452,6 +452,84 @@ update_visibility_by_resolution_info (sy
}
}
+/* Try to get rid of weakref. */
+
+static void
+optimize_weakref (symtab_node *node)
+{
+#ifdef ASM_OUTPUT_DEF
+ bool aliases_supported = true;
+#else
+ bool aliases_supported = false;
+#endif
+ bool strip_weakref = false;
+ bool static_alias = false;
+
+ gcc_assert (node->weakref);
+
+ /* Weakrefs with no target defined can not be optimized. */
+ if (!node->analyzed)
+return;
+ symtab_node *target = node->get_alias_target ();
+
+ /* Weakrefs to weakrefs can be optimized only if target can be. */
+ if (target->weakref)
+optimize_weakref (target);
+ if (target->weakref)
+return;
+
+ /* If we have definition of weakref's target and we know it binds locally,
+ we can turn weakref to static alias. */
+ if (target->definition && decl_binds_to_current_def_p (target->decl)
+ && aliases_supported)
+strip_weakref = static_alias = true;
+ /* Otherwise we can turn weakref into transparent alias. This transformation
+ may break asm statements which directly refers to symbol name and expect
+ GNU as to translate it via .weakref directive. So do not optimize when
+ DECL_PRESERVED is set and .weakref is supported. */
+ else if ((!DECL_PRESERVE_P (target->decl)
+ || IDENTIFIER_TRANSPARENT_ALIAS (DECL_ASSEMBLER_NAME (node->decl)))
+ && !DECL_WEAK (target->decl)
+ && !DECL_EXTERNAL (target->decl)
+ && ((target->definition && !target->can_be_discarded_p ())
+ || target->resolution != LDPR_UNDEF))
+strip_weakref = true;
+ if (!strip_weakref)
+return;
+ node->weakref = false;
+ IDENTIFIER_TRANSPARENT_ALIAS (DECL_ASSEMBLER_NAME (node->decl)) = 0;
+ TREE_CHAIN (DECL_ASSEMBLER_NAME (node->decl)) = NULL_TREE;
+ DECL_ATTRIBUTES (node->decl) = remove_attribute ("weakref",
+ DECL_ATTRIBUTES
+(node->decl));
+
+ if (dump_file)
+fprintf (dump_file, "Optimizing weakref %s %s\n",
+node->name(),
+static_alias ? "as static alias" : "as transparent alias");
+
+ if (static_alias)
+{
+ /* make_decl_local will shortcircuit if it doesn't see TREE_PUBLIC.
+be sure it really clears the WEAK flag. */
+ TREE_PUBLIC (node->decl) = true;
+ node->make_decl_local ();
+ node->forced_by_abi = false;
+ node->resolution = LDPR_PREVAILING_DEF_IRONLY;
+ node->externally_visible = false;
+ gcc_assert (!DECL_WEAK (node->decl));
+ node->transparent_alias = false;
+}
+ else
+{
+ symtab->change_decl_assembler_name
+(node->decl, DECL_ASSEMBLER_NAME (node->get_alias_target ()->decl));
+ node->transparent_alias = true;
+ node->copy_visibility_from (target);
+}
+ gcc_assert (node->alias);
+}
+
/* Decide on visibility
Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
Andre, Does not the test gfortran.dg/coarray_allocate_6.f08 require a -fdump-tree-original in the dg-options list? Thanks for the patch, Dominique
Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
> Le 3 avr. 2016 à 23:38, Andre Vehreschild a écrit : > > Hi Dominique, > > I thought that was implicit, isn't it? I don’t think so and I see in the log files gcc/testsuite/gfortran4/gfortran.sum:UNRESOLVED: gfortran.dg/coarray_allocate_6.f08 -O0 scan-tree-dump-not original "c.caf.x = 0B" > Is only the removal of the file implicit? Yes, > I will add the option to be on the safe side. Thanks, Dominique > > - Andre > > Am 3. April 2016 22:57:48 MESZ, schrieb "Dominique d'Humières" > : > Andre, > > Does not the test gfortran.dg/coarray_allocate_6.f08 require a > -fdump-tree-original in the dg-options list? > > Thanks for the patch, > > Dominique > > > -- > Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen > Tel.: +49 241 929 10 18 * ve...@gmx.de
Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
Hi Andre, Thanks for submitting this patch . What can a program do with the object after it has been allocated? Below is a simplified version of the code submitted in pr65795 and the compile-time error that results from attempting accessing the co-indexed component of the allocated object. Does the patch address this error? Damian $ cat bug65795.f90 implicit none type t2 integer, allocatable :: x end type t2 type t3 type(t2), allocatable :: caf[:] end type t3 type(t3) :: c allocate(c%caf[*]) c%caf%x = this_image() c%caf = c%caf[1] end $ caf bug65795.f90 bug65795.f90:15:8: c%caf = c%caf[1] 1 Error: Sorry, coindexed coarray at (1) with allocatable component is not yet supported $ gfortran --version GNU Fortran (MacPorts gcc6 6-20160306_0) 6.0.0 20160306 (experimental) > On Apr 3, 2016, at 6:35 AM, Andre Vehreschild wrote: > > Hi all, > > attached patch fixes a segfault when allocating a coarray of a type > that has allocatable components. Before the patch the compiler tried > to ref the component to nullify from the coarray's base address and not > from its .data component. The proposed patch fixes this by preventing > the nullify of the components in the array_allocate() for coarrays, > because the components are nullified again afterwards by copying a > fully nullified copy of the type to the coarray's data component. > > There albeit is an alternative to this patch: > > trans-array.c: 5556+ > > - tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, se->expr, > + tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, coarray ? > + pointer : se->expr, > ref->u.ar.as->rank); > > The above adds a second nullify to the generated code before the one > done the object copy mentioned above. > > Because I am unsure which patch is best, I propose both. I do favor of > course the one without the duplicate nullify as attached. > > Bootstrapped and regtested ok on x86_64-linux-gnu/F23. Ok for trunk? > > The patch also applies (with a small delta) to gcc-5 w/o any > regressions. Ok for gcc-5-branch? > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de > Damian Rouson, Ph.D., P.E. President, Sourcery Institute http://www.sourceryinstitute.org +1-510-600-2992 (mobile)
Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)
On Sat, Apr 2, 2016 at 11:57 PM, Trevor Saunders wrote:
> On Sat, Apr 02, 2016 at 05:18:31PM -0400, Patrick Palka wrote:
>> On Fri, 1 Apr 2016, Jason Merrill wrote:
>>
>> > I like this approach a lot. One thing, though:
>> >
>> > On 04/01/2016 03:13 PM, Patrick Palka wrote:
>> > > +struct GTY((chain_next ("%h.prev"))) bpr_entry
>> > > +{
>> > > + tree body;
>> > > + tree parms;
>> > > + tree res;
>> > > + struct bpr_entry *prev;
>> > > +};
>> > > +
>> > > /* Representation of entries in the constexpr function definition
>> > > table.
>> > > */
>> > >
>> > > struct GTY((for_user)) constexpr_fundef {
>> > > tree decl;
>> > > tree body;
>> > > + /* A chain of unused copies of this function's body awaiting reuse for
>> > > + CALL_EXPR evaluation. */
>> > > + struct bpr_entry *bpr_freelist;
>> > > };
>> >
>> > The freelist should be discarded on GC. I think the way to achieve that
>> > is to
>> > put all the freelists into a separate deletable hash table rather than hang
>> > them off the fundefs.
>> >
>> > Jason
>> >
>> >
>>
>> Here's a version that uses a separate deletable table to cache the
>> function copies. For simplicity I used a hash_map instead of a
>> hash_table. Does this look OK to commit after bootstrap + regtest?
>>
>> On a related note, I noticed that the constexpr_call_table is not marked
>> deletable. Marking it deletable speeds up the test case in the PR by
>> about 10% and saves about 10MB. Do you think doing so is a good idea?
>>
>> On another related note, I noticed that marking something as both
>> GTY((deletable, cache)) doesn't work as intended, because the
>> gt_cleare_cache functions run _after_ all deletable roots get
>> zeroed out. So during GC the gt_cleare_cache function of a root
>> marked "deletable, cache" would always be a no-op. Concretely I think
>> this means that our cv_cache and fold_cache leak memory during GC
>> because their underlying hash_map (allocated by operator new) is zeroed
>> before gc_cleare_cache could clear it.
>
> yeah, I think that's true. I'm not really sure what the expected point
> of making something both cache and deletable is maybe we should just ban
> it? The way this ties in with the gc is... wierd ;) but I'm not really
> sure how I'd fix it.
>
> Trev
The intended effect can be achieved I think by marking the cache_map
as GTY((cache)) (so that the table can be cleared during GC) and then
marking the cache_map::map field as GTY((skip)) (so that PCH ignores
it).
>
>>
>> gcc/cp/ChangeLog:
>>
>> PR c++/70452
>> * constexpr.c (struct fun_copy): New struct.
>> (struct fundef_copies_t): New struct.
>> (fundef_copies_table): New static variable.
>> (maybe_initialize_fundef_copies_table): New static function.
>> (get_fun_copy): New static function.
>> (save_fun_copy): New static function.
>> (cxx_eval_call_expression): Use
>> maybe_initialize_fundef_copies_table, get_fun_copy, and
>> save_fun_copy.
>>
>> gcc/testsuite/ChangeLog:
>>
>> PR c++/70452
>> * g++.dg/ext/constexpr-vla4.C: New test.
>> ---
>> gcc/cp/constexpr.c| 96
>> +--
>> gcc/testsuite/g++.dg/ext/constexpr-vla4.C | 17 ++
>> 2 files changed, 109 insertions(+), 4 deletions(-)
>> create mode 100644 gcc/testsuite/g++.dg/ext/constexpr-vla4.C
>>
>> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
>> index ea605dc..e1a5a4e 100644
>> --- a/gcc/cp/constexpr.c
>> +++ b/gcc/cp/constexpr.c
>> @@ -965,6 +965,76 @@ maybe_initialize_constexpr_call_table (void)
>> constexpr_call_table = hash_table::create_ggc
>> (101);
>> }
>>
>> +/* The representation of a single node in the per-function freelist
>> maintained
>> + by FUNDEF_COPIES_TABLE. */
>> +
>> +struct fun_copy
>> +{
>> + tree body;
>> + tree parms;
>> + tree res;
>> + fun_copy *prev;
>> +};
>> +
>> +/* During constexpr CALL_EXPR evaluation, to avoid issues with sharing when
>> + a function happens to get called recursively, we unshare the callee
>> + function's body and evaluate this unshared copy instead of evaluating the
>> + original body.
>> +
>> + FUNDEF_COPIES_TABLE is a per-function freelist of these unshared function
>> + copies. The underlying data structure of FUNDEF_COPIES_TABLE is a
>> hash_map
>> + that's keyed off of the original FUNCTION_DECL and whose value is the
>> chain
>> + of this function's unused copies awaiting reuse. */
>> +
>> +struct fundef_copies_table_t
>> +{
>> + hash_map *map;
>> +};
>> +
>> +static GTY((deletable)) fundef_copies_table_t fundef_copies_table;
>> +
>> +/* Initialize FUNDEF_COPIES_TABLE if it's not initialized. */
>> +
>> +static void
>> +maybe_initialize_fundef_copies_table ()
>> +{
>> + if (fundef_copies_table.map == NULL)
>> +fundef_copies_table.map = hash_map::create_ggc (101);
>> +}
>> +
>> +/* Reuse or create a new unshared copy of the function FUN.
>> + Return this copy. */
>> +
>> +stat
Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS
> On Apr 3, 2016, at 3:04 PM, Andre Vehreschild wrote: > > Hi Damian, > > To say it quite bluntly, I don't know. I took care of the ICE only, but I > don't have a deeper understanding of the coarray usage, therefore I can't > answer your question. Hi Andre, No problem. Thanks for the quick reply. > What should the meaning of the line in question be? Doesn't it overwrite the > allocated reference with the one of image 1? And how would you expect to > continue from there? It’s just a check to see what the compiler will do. It could be thought of as a poorly written broadcast. To be a correct broadcast, it would require a “sync all” just after the first assignment. Then the second assignment would give every image a copy of the caf component that was on image 1, which has an x component with the value 1. Even with this correction, it would of course exhibit poor scaling due to network contention and it would be better to call co_broadcast. I just wrote it to see if there had been additional progress toward supporting derived type coarrays with allocatable or pointer components. If so, that will be of great interest to the users of OpenCoarrays and I would announce it on the OpenCoarrays mailing list. Damian
[PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)
Hi,
PR70457 shows that we ICE if a call to pow() has only one argument, or
more generally doesn't match its expected signature. This can happen
both during the widen-mult phase and the tree-inline phase. As
suggested by Jakub, this patch uses gimple_call_combined_fn to test for
this, similarly to what is done elsewhere in tree-ssa-math-opts.c.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu, with no
regressions. Is this ok for trunk, as well as for backport to 5 and
4.9?
Thanks,
Bill
[gcc]
2016-04-03 Bill Schmidt
Jakub Jelinek
* tree-inline.c (estimate_num_insn): Use gimple_call_combined_fn
to ensure a call statement is compatible with a built-in's
prototype.
* tree-ssa-math-opts.c (pass_optimize_windening_mul::execute):
Likewise.
[gcc/testsuite]
2016-04-03 Bill Schmidt
Jakub Jelinek
* gcc.dg/torture/pr70457.c: New.
Index: testsuite/gcc.dg/torture/pr70457.c
===
--- testsuite/gcc.dg/torture/pr70457.c (revision 0)
+++ testsuite/gcc.dg/torture/pr70457.c (working copy)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+
+/* This formerly ICEd when trying to expand pow as a built-in with
+ the wrong number of arguments. */
+
+extern double pow (double __x, double __y) __attribute__ ((__nothrow__ ,
__leaf__));
+extern double __pow (double __x, double __y) __attribute__ ((__nothrow__ ,
__leaf__));
+
+typedef int int64_t __attribute__ ((__mode__ (__DI__)));
+
+typedef struct {
+ int64_t data;
+ int tag;
+} Object;
+
+extern Object Make_Flonum (double);
+extern Object P_Pow (Object, Object);
+
+Object General_Function (Object x, Object y, double (*fun)()) {
+ double d, ret;
+
+ d = 1.0;
+
+ if (y.tag >> 1)
+ret = (*fun) (d);
+ else
+ret = (*fun) (d, 0.0);
+
+ return Make_Flonum (ret);
+}
+
+Object P_Pow (Object x, Object y) { return General_Function (x, y, pow); }
Index: tree-inline.c
===
--- tree-inline.c (revision 234702)
+++ tree-inline.c (working copy)
@@ -57,8 +57,8 @@ along with GCC; see the file COPYING3. If not see
#include "cfgloop.h"
#include "builtins.h"
#include "tree-chkp.h"
+#include "case-cfn-macros.h"
-
/* I'm not real happy about this, but we need to handle gimple and
non-gimple trees. */
@@ -4070,11 +4070,9 @@ estimate_num_insns (gimple *stmt, eni_weights *wei
/* We canonicalize x * x to pow (x, 2.0) with -ffast-math, so
specialize the cheap expansion we do here.
??? This asks for a more general solution. */
- switch (DECL_FUNCTION_CODE (decl))
+ switch (gimple_call_combined_fn (stmt))
{
- case BUILT_IN_POW:
- case BUILT_IN_POWF:
- case BUILT_IN_POWL:
+ CASE_CFN_POW:
if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
&& (real_equal
(&TREE_REAL_CST (gimple_call_arg (stmt, 1)),
Index: tree-ssa-math-opts.c
===
--- tree-ssa-math-opts.c(revision 234702)
+++ tree-ssa-math-opts.c(working copy)
@@ -3829,11 +3829,9 @@ pass_optimize_widening_mul::execute (function *fun
if (fndecl
&& DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
{
- switch (DECL_FUNCTION_CODE (fndecl))
+ switch (gimple_call_combined_fn (stmt))
{
- case BUILT_IN_POWF:
- case BUILT_IN_POW:
- case BUILT_IN_POWL:
+ CASE_CFN_POW:
if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
&& real_equal
(&TREE_REAL_CST (gimple_call_arg (stmt, 1)),
Re: [patch, fortran] PR68566 ICE on using unusable array in reshape
On 04/02/2016 07:40 AM, Jerry DeLisle wrote:
> On 04/02/2016 05:42 AM, Dominique d'Humières wrote:
>>
>>> Le 2 avr. 2016 à 11:44, Dominique d'Humières a écrit :
>>>
>>> Hi Jerry,
>>>
...
I will add an additional test case for the original posted problem in the
PR.
Two existing tests get exercised, changing the error message. Finding the
problems earlier in the matchers I think is the right way to go. I am
curious if
the old checks ever get triggered (I will look into that a little later.
>>>
>>> (2) Before your patch the errors were
>>>
>>> Error: Expression at (1) must be of INTEGER type, found REAL
>>>
>>> How difficult is it to restore the "found … « ?
>
> I like that idea and not too difficult to do. ;)
>
Here is an updated patch with Dominique's suggestion to tell what type was found
in the error message.
Patch includes a new test case fore the original test case in the PR and updates
of existing tests.
OK for trunk?
Jerry
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 2fc9dfaf..1430e802 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -421,10 +421,15 @@ match_array_element_spec (gfc_array_spec *as)
if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
return AS_UNKNOWN;
- if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
- && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
-{
- gfc_error ("Expecting a scalar INTEGER expression at %C");
+ if (((*upper)->expr_type == EXPR_CONSTANT
+ && (*upper)->ts.type != BT_INTEGER) ||
+ ((*upper)->expr_type == EXPR_FUNCTION
+ && (*upper)->ts.type == BT_UNKNOWN
+ && (*upper)->symtree
+ && strcmp ((*upper)->symtree->name, "null") == 0))
+{
+ gfc_error ("Expecting a scalar INTEGER expression at %C, found %s",
+ gfc_basic_typename ((*upper)->ts.type));
return AS_UNKNOWN;
}
@@ -448,10 +453,15 @@ match_array_element_spec (gfc_array_spec *as)
if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
return AS_UNKNOWN;
- if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
- && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
+ if (((*upper)->expr_type == EXPR_CONSTANT
+ && (*upper)->ts.type != BT_INTEGER) ||
+ ((*upper)->expr_type == EXPR_FUNCTION
+ && (*upper)->ts.type == BT_UNKNOWN
+ && (*upper)->symtree
+ && strcmp ((*upper)->symtree->name, "null") == 0))
{
- gfc_error ("Expecting a scalar INTEGER expression at %C");
+ gfc_error ("Expecting a scalar INTEGER expression at %C, found %s",
+ gfc_basic_typename ((*upper)->ts.type));
return AS_UNKNOWN;
}
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 12a8f32e..a6310107 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5163,6 +5163,9 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shape_exp,
|| !is_constant_array_expr (order_exp))
return NULL;
+ if (source->shape == NULL)
+return NULL;
+
/* Proceed with simplification, unpacking the array. */
mpz_init (index);
diff --git a/gcc/testsuite/gfortran.dg/pr36192.f90 b/gcc/testsuite/gfortran.dg/pr36192.f90
index df3bfd75..ebf95e35 100644
--- a/gcc/testsuite/gfortran.dg/pr36192.f90
+++ b/gcc/testsuite/gfortran.dg/pr36192.f90
@@ -3,7 +3,6 @@
!
program three_body
real, parameter :: n = 2, d = 2
- real, dimension(n,d) :: x ! { dg-error "of INTEGER type|of INTEGER type" }
- x(1,:) = (/ 1.0, 0.0 /)
+ real, dimension(n,d) :: x ! { dg-error "Expecting a scalar INTEGER" }
+ x(1,:) = (/ 1.0, 0.0 /)! { dg-error "Unclassifiable" }
end program three_body
-! { dg-prune-output "have constant shape" }
diff --git a/gcc/testsuite/gfortran.dg/pr36192_1.f90 b/gcc/testsuite/gfortran.dg/pr36192_1.f90
index 77df3176..687a465f 100644
--- a/gcc/testsuite/gfortran.dg/pr36192_1.f90
+++ b/gcc/testsuite/gfortran.dg/pr36192_1.f90
@@ -2,11 +2,11 @@
! PR fortran/36192
program three_body
real, parameter :: n = 2, d = 2
- real, dimension(n,d) :: x_hq ! { dg-error "of INTEGER type|of INTEGER type" }
+ real, dimension(n,d) :: x_hq ! { dg-error "Expecting a scalar INTEGER" }
call step(x_hq)
contains
subroutine step(x)
real, dimension(:,:), intent(in) :: x
end subroutine step
end program three_body
-! { dg-prune-output "must have constant shape" }
+! { dg-prune-output "Rank mismatch in argument" }
diff --git a/gcc/testsuite/gfortran.dg/real_dimension_1.f b/gcc/testsuite/gfortran.dg/real_dimension_1.f
index 73e9131a..3dd1a5af 100644
--- a/gcc/testsuite/gfortran.dg/real_dimension_1.f
+++ b/gcc/testsuite/gfortran.dg/real_dimension_1.f
@@ -1,7 +1,7 @@
! { dg-do compile }
-! PR 34305 - make sure there's an error message for specifying a
+! PR 34305 - Test for specifying a real as dimension
program test
- parameter (datasize = 1000)
- dimension idata (datasize) ! { dg-error "must be of INTEGER type|must have con
Re: [PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)
On Sun, 2016-04-03 at 18:43 -0500, Bill Schmidt wrote:
> Hi,
>
> PR70457 shows that we ICE if a call to pow() has only one argument, or
> more generally doesn't match its expected signature. This can happen
> both during the widen-mult phase and the tree-inline phase. As
> suggested by Jakub, this patch uses gimple_call_combined_fn to test for
> this, similarly to what is done elsewhere in tree-ssa-math-opts.c.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu, with no
> regressions. Is this ok for trunk, as well as for backport to 5 and
> 4.9?
For GCC 5 and GCC 4.9, a slightly different patch is required, since
gimple_call_combined_fn doesn't exist in previous releases. Also, the
sin, cos, etc., functions are also vulnerable:
[gcc]
2016-04-03 Bill Schmidt
Jakub Jelinek
* tree-inline.c (estimate_num_insn): Use gimple_call_builtin_p
to ensure a call statement is compatible with a built-in's
prototype.
* tree-ssa-math-opts.c (execute_cse_sincos): Likewise.
(pass_optimize_windening_mul::execute): Likewise.
[gcc/testsuite]
2016-04-03 Bill Schmidt
Jakub Jelinek
* gcc.dg/torture/pr70457.c: New.
Index: gcc/testsuite/gcc.dg/torture/pr70457.c
===
--- gcc/testsuite/gcc.dg/torture/pr70457.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr70457.c (working copy)
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+
+/* This formerly ICEd when trying to expand pow as a built-in with
+ the wrong number of arguments. */
+
+extern double pow (double __x, double __y) __attribute__ ((__nothrow__ ,
__leaf__));
+extern double __pow (double __x, double __y) __attribute__ ((__nothrow__ ,
__leaf__));
+
+typedef int int64_t __attribute__ ((__mode__ (__DI__)));
+
+typedef struct {
+ int64_t data;
+ int tag;
+} Object;
+
+extern Object Make_Flonum (double);
+extern Object P_Pow (Object, Object);
+
+Object General_Function (Object x, Object y, double (*fun)()) {
+ double d, ret;
+
+ d = 1.0;
+
+ if (y.tag >> 1)
+ret = (*fun) (d);
+ else
+ret = (*fun) (d, 0.0);
+
+ return Make_Flonum (ret);
+}
+
+Object P_Pow (Object x, Object y) { return General_Function (x, y, pow); }
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 234702)
+++ gcc/tree-inline.c (working copy)
@@ -3860,6 +3860,8 @@ estimate_num_insns (gimple stmt, eni_weights *weig
case BUILT_IN_POW:
case BUILT_IN_POWF:
case BUILT_IN_POWL:
+ if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
+ break;
if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
&& REAL_VALUES_EQUAL
(TREE_REAL_CST (gimple_call_arg (stmt, 1)), dconst2))
Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 234702)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -1437,7 +1437,7 @@ execute_cse_sincos (void)
if (is_gimple_call (stmt)
&& gimple_call_lhs (stmt)
&& (fndecl = gimple_call_fndecl (stmt))
- && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+ && gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
{
tree arg, arg0, arg1, result;
HOST_WIDE_INT n;
@@ -2867,6 +2867,8 @@ execute_optimize_widening_mul (void)
case BUILT_IN_POWF:
case BUILT_IN_POW:
case BUILT_IN_POWL:
+ if (!gimple_call_builtin_p (stmt))
+ break;
if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
&& REAL_VALUES_EQUAL
(TREE_REAL_CST (gimple_call_arg (stmt, 1)),
Re: [PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)
On Sun, Apr 03, 2016 at 06:43:47PM -0500, Bill Schmidt wrote:
> --- tree-inline.c (revision 234702)
> +++ tree-inline.c (working copy)
> @@ -57,8 +57,8 @@ along with GCC; see the file COPYING3. If not see
> #include "cfgloop.h"
> #include "builtins.h"
> #include "tree-chkp.h"
> +#include "case-cfn-macros.h"
>
> -
> /* I'm not real happy about this, but we need to handle gimple and
> non-gimple trees. */
>
Please keep the extra empty line above.
> @@ -4070,11 +4070,9 @@ estimate_num_insns (gimple *stmt, eni_weights *wei
> /* We canonicalize x * x to pow (x, 2.0) with -ffast-math, so
> specialize the cheap expansion we do here.
> ??? This asks for a more general solution. */
> - switch (DECL_FUNCTION_CODE (decl))
> + switch (gimple_call_combined_fn (stmt))
> {
> - case BUILT_IN_POW:
> - case BUILT_IN_POWF:
> - case BUILT_IN_POWL:
> + CASE_CFN_POW:
> if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
> && (real_equal
> (&TREE_REAL_CST (gimple_call_arg (stmt, 1)),
Actually, I haven't been suggesting to use gimple_call_combined_fn,
but gimple_call_builtin_p.
Here using gimple_call_combined_fn doesn't make much sense, because
it is in code guarded with:
if (gimple_call_internal_p (stmt))
return 0;
else if ((decl = gimple_call_fndecl (stmt))
&& DECL_BUILT_IN (decl))
{
...
else if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
{
Thus, internal functions don't make this spot at all.
So, either replace the DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL
with gimple_builtin_call_p (stmt, BUILT_IN_NORMAL); or call
gimple_builtin_call_types_compatible_p.
> Index: tree-ssa-math-opts.c
> ===
> --- tree-ssa-math-opts.c (revision 234702)
> +++ tree-ssa-math-opts.c (working copy)
> @@ -3829,11 +3829,9 @@ pass_optimize_widening_mul::execute (function *fun
> if (fndecl
> && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> {
> - switch (DECL_FUNCTION_CODE (fndecl))
> + switch (gimple_call_combined_fn (stmt))
> {
> - case BUILT_IN_POWF:
> - case BUILT_IN_POW:
> - case BUILT_IN_POWL:
> + CASE_CFN_POW:
> if (TREE_CODE (gimple_call_arg (stmt, 1)) == REAL_CST
> && real_equal
>(&TREE_REAL_CST (gimple_call_arg (stmt, 1)),
>
And similarly here.
Jakub
