[google/4_8] Merged r200809 from gcc-4_8-branch to google/gcc-4_8
-- Paul Pluzhnikov
RFA: PATCH to get_inner_reference for c++/57793
This PR isn't really a C++ issue; it affects C as well, and presumably
all other languages. A comment a few lines down says
/* Avoid returning a negative bitpos as this may wreak havoc later. */
but we were failing to avoid that in this case.
Tested x86_64-pc-linux-gnu. OK for trunk/4.8?
commit 168f0f28cf3986d0e067b640031a8baaee2d09a4
Author: Jason Merrill
Date: Tue Jul 9 00:06:51 2013 -0400
PR c++/57793
* expr.c (get_inner_reference): Avoid returning a negative bitpos.
diff --git a/gcc/expr.c b/gcc/expr.c
index 923f59b..bbec492 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -6733,7 +6733,7 @@ get_inner_reference (tree exp, HOST_WIDE_INT *pbitsize,
tem = tem.sext (TYPE_PRECISION (sizetype));
tem = tem.lshift (BITS_PER_UNIT == 8 ? 3 : exact_log2 (BITS_PER_UNIT));
tem += bit_offset;
- if (tem.fits_shwi ())
+ if (tem.fits_shwi () && !tem.is_negative())
{
*pbitpos = tem.to_shwi ();
*poffset = offset = NULL_TREE;
diff --git a/gcc/testsuite/c-c++-common/pr57793.c b/gcc/testsuite/c-c++-common/pr57793.c
new file mode 100644
index 000..7858a27
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr57793.c
@@ -0,0 +1,23 @@
+/* PR c++/57793 */
+
+struct A { unsigned a : 1; unsigned b : 1; };
+struct B
+{
+ unsigned char c[0x4000];
+ unsigned char d[0x4ff0];
+ struct A e;
+};
+
+void *foo (struct B *p)
+{
+ if (p->e.a)
+return (void *) 0;
+ p->e.b = 1;
+ return p->c;
+}
+
+void
+bar (struct B *p)
+{
+ foo (p);
+}
Re: [Fortran] Patch ping**2
Hi Tobias, ** PING ** On July 01, Tobias Burnus wrote: The following patches are pending to be reviewed: * http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html OK if nobody else objects within 24 h. * http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html This one is OK. * http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html Also OK. Regards Thomas
Re: [PATCH] Fix the bug to check if lookup_stmt_eh_lp returns positive instead of non-zero
Is it possible to add a test case?
David
On Mon, Jul 8, 2013 at 5:55 PM, Dehao Chen wrote:
> In lookup_stmt_eh_lp, negative return value indicates a MUST_NOT_THROW
> region index. In this case, we should *not* add an EH edge during VPT.
>
> Bootstrapped and passed regression test.
>
> OK for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2013-07-08 Dehao Chen (de...@google.com)
>
> * value-prof.c (gimple_ic): Fix the bug of adding EH edge.
>
> Index: gcc/value-prof.c
> ===
> --- gcc/value-prof.c (revision 200375)
> +++ gcc/value-prof.c (working copy)
> @@ -1359,8 +1359,7 @@ gimple_ic (gimple icall_stmt, struct cgraph_node *
>
>/* Build an EH edge for the direct call if necessary. */
>lp_nr = lookup_stmt_eh_lp (icall_stmt);
> - if (lp_nr != 0
> - && stmt_could_throw_p (dcall_stmt))
> + if (lp_nr > 0 && stmt_could_throw_p (dcall_stmt))
> {
>edge e_eh, e;
>edge_iterator ei;
RFA: PATCH to restore old behavior of debug_vec_tree
Lawrence's overhaul of the debug() functions changed the behavior of the
pvt macro in gdbinit.in. Previously it used print_node to dump each of
the elements of the vector, but after the change it uses debug, which
both prints less information by default and fails to handle many C++
tree nodes.
Fixed by adding debug_raw for vec and changing
debug_vec_tree to use that.
OK for trunk?
commit 682cd181d980513bc1ecd30874c5c2aaceb3b725
Author: Jason Merrill
Date: Mon Jul 8 16:02:50 2013 -0400
* print-tree.c (debug_vec_tree): Use debug_raw.
(debug_raw (vec &)): New.
(debug_raw (vec *)): New.
* tree.h: Declare them.
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index 689eeb9..029c3a2 100644
--- a/gcc/print-tree.c
+++ b/gcc/print-tree.c
@@ -1097,26 +1097,37 @@ debug_body (const tree_node *ptr)
down to a depth of six. */
DEBUG_FUNCTION void
-debug_vec_tree (vec *vec)
+debug_raw (vec &ref)
{
tree elt;
unsigned ix;
/* Print the slot this node is in, and its code, and address. */
fprintf (stderr, "address ());
+ dump_addr (stderr, " ", ref.address ());
- FOR_EACH_VEC_ELT (*vec, ix, elt)
+ FOR_EACH_VEC_ELT (ref, ix, elt)
{
fprintf (stderr, "elt %d ", ix);
- debug (elt);
+ debug_raw (elt);
}
}
DEBUG_FUNCTION void
debug (vec &ref)
{
- debug_vec_tree (&ref);
+ tree elt;
+ unsigned ix;
+
+ /* Print the slot this node is in, and its code, and address. */
+ fprintf (stderr, " *ptr)
else
fprintf (stderr, "\n");
}
+
+DEBUG_FUNCTION void
+debug_raw (vec *ptr)
+{
+ if (ptr)
+debug_raw (*ptr);
+ else
+fprintf (stderr, "\n");
+}
+
+DEBUG_FUNCTION void
+debug_vec_tree (vec *vec)
+{
+ debug_raw (vec);
+}
diff --git a/gcc/tree.h b/gcc/tree.h
index 6297b49..0058a4b 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -6025,6 +6025,8 @@ extern void debug_body (const tree_node *ptr);
extern void debug_vec_tree (vec *);
extern void debug (vec &ref);
extern void debug (vec *ptr);
+extern void debug_raw (vec &ref);
+extern void debug_raw (vec *ptr);
#ifdef BUFSIZ
extern void dump_addr (FILE*, const char *, const void *);
extern void print_node (FILE *, const char *, tree, int);
Re: vector conditional expression with scalar arguments
On 07/08/2013 05:28 PM, Marc Glisse wrote: Perhaps the most conservative rule would be to only accept the case where the sizes match and reject the others for now, so whatever is decided later for other cases is unlikely to require a breaking change. Though I would like the general case to be accepted eventually, whatever it ends up meaning :) Makes sense to me. Jason
Re: [C++ Patch] PR 51786
On 07/08/2013 07:32 PM, Paolo Carlini wrote: + && (CLASS_TYPE_P (decl_specifiers.type) + || TREE_CODE (decl_specifiers.type) == ENUMERAL_TYPE)) You can use OVERLOAD_TYPE_P here if you want. OK either way. Jason
C++ PATCH for c++/57550 (wrong access error with templates)
Well, this has taken a lot of revisions to get right. In this testcase, in
MakeHandler(Wrapper >);
we need to check the access for Append in the context of the expression.
But we don't know which Append we want until we do template argument
deduction. In other testcases, we need to check the access of things
mentioned in default template arguments in the context of their
templates. But we need to instantiate default arguments during template
argument deduction. So during deduction we need to check access in both
contexts. In this patch I'm dealing with that by staying in the
expression context most of the time, and doing substitution in deferred
access context so that we can do those checks in the template context
later. For default arguments, I collect up any checks and pass them
back to the caller to handle.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 2baa70278509769abf4f4ed3c9796962fee44319
Author: Jason Merrill
Date: Mon Jul 8 17:03:05 2013 -0400
PR c++/57550
* pt.c (fn_type_unification): Only defer during substitution.
(type_unification_real): Defer during defarg substitution,
add checks parm to pass back deferred checks.
(unify, do_auto_deduction): Adjust.
* semantics.c (reopen_deferring_access_checks): New.
* cp-tree.h: Declare it.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1b0b243..1971bc5 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5637,6 +5637,7 @@ extern void resume_deferring_access_checks (void);
extern void stop_deferring_access_checks (void);
extern void pop_deferring_access_checks (void);
extern vec *get_deferred_access_checks (void);
+extern void reopen_deferring_access_checks (vec *);
extern void pop_to_parent_deferring_access_checks (void);
extern bool perform_access_checks (vec *,
tsubst_flags_t);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3847a1d..26d5a1c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -138,6 +138,7 @@ static int maybe_adjust_types_for_deduction (unification_kind_t, tree*, tree*,
tree);
static int type_unification_real (tree, tree, tree, const tree *,
unsigned int, int, unification_kind_t, int,
+ vec **,
bool);
static void note_template_header (int);
static tree convert_nontype_argument_function (tree, tree);
@@ -15052,7 +15053,6 @@ fn_type_unification (tree fn,
return error_mark_node;
tinst = build_tree_list (fn, NULL_TREE);
++deduction_depth;
- push_deferring_access_checks (dk_deferred);
gcc_assert (TREE_CODE (fn) == TEMPLATE_DECL);
@@ -15144,8 +15144,13 @@ fn_type_unification (tree fn,
}
processing_template_decl += incomplete;
input_location = DECL_SOURCE_LOCATION (fn);
+ /* Ignore any access checks; we'll see them again in
+ instantiate_template and they might have the wrong
+ access path at this point. */
+ push_deferring_access_checks (dk_deferred);
fntype = tsubst (TREE_TYPE (fn), explicit_targs,
complain | tf_partial, NULL_TREE);
+ pop_deferring_access_checks ();
input_location = loc;
processing_template_decl -= incomplete;
pop_tinst_level ();
@@ -15153,12 +15158,6 @@ fn_type_unification (tree fn,
if (fntype == error_mark_node)
goto fail;
- /* Throw away these access checks; we'll see them again in
- instantiate_template and they might have the wrong
- access path at this point. */
- pop_deferring_access_checks ();
- push_deferring_access_checks (dk_deferred);
-
/* Place the explicitly specified arguments in TARGS. */
for (i = NUM_TMPL_ARGS (explicit_targs); i--;)
TREE_VEC_ELT (targs, i) = TREE_VEC_ELT (explicit_targs, i);
@@ -15194,9 +15193,15 @@ fn_type_unification (tree fn,
excessive_deduction_depth = true;
goto fail;
}
+
+ /* type_unification_real will pass back any access checks from default
+ template argument substitution. */
+ vec *checks;
+ checks = NULL;
+
ok = !type_unification_real (DECL_INNERMOST_TEMPLATE_PARMS (fn),
targs, parms, args, nargs, /*subr=*/0,
- strict, flags, explain_p);
+ strict, flags, &checks, explain_p);
if (!explain_p)
pop_tinst_level ();
if (!ok)
@@ -15245,16 +15250,23 @@ fn_type_unification (tree fn,
excessive_deduction_depth = true;
goto fail;
}
+
+ /* Also collect access checks from the instantiation. */
+ reopen_deferring_access_checks (checks);
+
decl = instantiate_template (fn, targs, complain);
+
+ checks = get_deferred_access_checks ();
+ pop_deferring_access_checks ();
+
pop_tinst_level ();
if (decl == error_mark_node)
goto fail;
- /* Now perform any access checks encountered during deduction, such as
- for default template arguments. */
+ /* Now perform any access checks encountered during substitution. */
push_access_scope (decl);
- ok = perform_deferred_access_checks (complain);
+ ok = perform_access_checks (
Re: [PATCH] [libitm] Add --enable-werror.
On Mon, 1 Jul 2013 14:56:01 -0600 Ryan Hill wrote: Ping. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00033.html > libitm is currently unconditionally built with -Werror. This patch adds > --enable-werror to control it (enabled by default). Bootstrapped and tested > on x86_64, and inspected build logs to ensure it was doing what it should. > > I'm assuming copyright assignment isn't necessary for a small change like > this. I will also need someone to check this in for me please. > > > gcc/libitm/ > 2013-06-30 Ryan Hill > > * configure.ac: Add --enable-werror. > (XCFLAGS): Use it. > * configure: Regenerate. > > --- > libitm/configure.ac | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/libitm/configure.ac b/libitm/configure.ac > index ff41266..5a9400d 100644 > --- a/libitm/configure.ac > +++ b/libitm/configure.ac > @@ -252,9 +252,15 @@ GCC_CHECK_ELF_STYLE_WEAKREF > CFLAGS="$save_CFLAGS" > AC_CACHE_SAVE > > -# Add -Wall -Werror if we are using GCC. > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror], > + [turns on -Werror @<:@default=yes@:>@])]) > +# Add -Wall if we are using GCC. > if test "x$GCC" = "xyes"; then > - XCFLAGS="$XCFLAGS -Wall -Werror" > + XCFLAGS="$XCFLAGS -Wall" > + # Add -Werror if requested. > + if test "x$enable_werror" != "xno"; then > +XCFLAGS="$XCFLAGS -Werror" > + fi > fi > > XCFLAGS="$XCFLAGS $XPCFLAGS" -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [PATCH] [libatomic] Add --enable-werror.
On Mon, 1 Jul 2013 14:55:35 -0600 Ryan Hill wrote: Ping. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00032.html > libatomic is currently unconditionally built with -Werror. This patch adds > --enable-werror to control it (enabled by default). Bootstrapped and tested > on x86_64, and inspected build logs to ensure it was doing what it should. > > I'm assuming copyright assignment isn't necessary for a small change like > this. I will also need someone to check this in for me please. > > gcc/libatomic/ > 2013-06-30 Ryan Hill > > * configure.ac: Add --enable-werror. > (XCFLAGS): Use it. > * configure: Regenerate. > > --- > libatomic/configure.ac | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/libatomic/configure.ac b/libatomic/configure.ac > index 0dc4a98..4020d23 100644 > --- a/libatomic/configure.ac > +++ b/libatomic/configure.ac > @@ -226,9 +226,15 @@ LIBAT_ENABLE_SYMVERS > CFLAGS="$save_CFLAGS" > AC_CACHE_SAVE > > -# Add -Wall -Werror if we are using GCC. > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror], > + [turns on -Werror @<:@default=yes@:>@])]) > +# Add -Wall if we are using GCC. > if test "x$GCC" = "xyes"; then > - XCFLAGS="$XCFLAGS -Wall -Werror" > + XCFLAGS="$XCFLAGS -Wall" > + # Add -Werror if requested. > + if test "x$enable_werror" != "xno"; then > +XCFLAGS="$XCFLAGS -Werror" > + fi > fi > > XCFLAGS="$XCFLAGS $XPCFLAGS" -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[PATCH] Fix the bug to check if lookup_stmt_eh_lp returns positive instead of non-zero
In lookup_stmt_eh_lp, negative return value indicates a MUST_NOT_THROW
region index. In this case, we should *not* add an EH edge during VPT.
Bootstrapped and passed regression test.
OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-07-08 Dehao Chen (de...@google.com)
* value-prof.c (gimple_ic): Fix the bug of adding EH edge.
Index: gcc/value-prof.c
===
--- gcc/value-prof.c (revision 200375)
+++ gcc/value-prof.c (working copy)
@@ -1359,8 +1359,7 @@ gimple_ic (gimple icall_stmt, struct cgraph_node *
/* Build an EH edge for the direct call if necessary. */
lp_nr = lookup_stmt_eh_lp (icall_stmt);
- if (lp_nr != 0
- && stmt_could_throw_p (dcall_stmt))
+ if (lp_nr > 0 && stmt_could_throw_p (dcall_stmt))
{
edge e_eh, e;
edge_iterator ei;
Re: [C++ Patch] PR 51786
On 07/08/2013 08:01 PM, Jason Merrill wrote:
On 07/08/2013 01:49 PM, Paolo Carlini wrote:
Ah I see. I take your indication as meaning class *or enum*
Yes.
Thanks. Thus, as agreed, I tested the below. Ok?
Paolo.
///
Index: cp/parser.c
===
--- cp/parser.c (revision 200780)
+++ cp/parser.c (working copy)
@@ -11009,11 +11009,21 @@ cp_parser_simple_declaration (cp_parser* parser,
/* Issue an error message if no declarators are present, and the
decl-specifier-seq does not itself declare a class or
- enumeration. */
+ enumeration: [dcl.dcl]/3. */
if (!saw_declarator)
{
if (cp_parser_declares_only_class_p (parser))
- shadow_tag (&decl_specifiers);
+ {
+ if (!declares_class_or_enum
+ && decl_specifiers.type
+ && (CLASS_TYPE_P (decl_specifiers.type)
+ || TREE_CODE (decl_specifiers.type) == ENUMERAL_TYPE))
+ /* Ensure an error is issued anyway when finish_decltype_type,
+ called via cp_parser_decl_specifier_seq, returns a class or
+ an enumeration (c++/51786). */
+ decl_specifiers.type = NULL_TREE;
+ shadow_tag (&decl_specifiers);
+ }
/* Perform any deferred access checks. */
perform_deferred_access_checks (tf_warning_or_error);
}
Index: testsuite/g++.dg/cpp0x/pr51786.C
===
--- testsuite/g++.dg/cpp0x/pr51786.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51786.C(working copy)
@@ -0,0 +1,8 @@
+// PR c++/51786
+// { dg-do compile { target c++11 } }
+
+enum E {};
+struct A {};
+
+void foo() { decltype(E{}); } // { dg-error "does not declare anything" }
+void bar() { decltype(A{}); } // { dg-error "does not declare anything" }
Aw: Re: Re: [PATCH] FPU IEEE 754 for MIPS r5900
Hello,
> "Jürgen Urban" writes:
> >> "Jürgen Urban" writes:
> >> > I used the SPU code in GCC as example for creating an
> >> > r5900_single_format structure. The patch is attached to the e-mail. I
> >> > want to submit this patch.
> >>
> >> Thanks. Are there any real differences though? E.g. in your version
> >> you set has_sign_dependent_rounding, but that's not necessary when the
> >> only rounding mode is towards zero. has_sign_dependent_rounding says
> >> whether rounding X vs. -X can give numbers of different magnitude.
> >> (It was actually because of r5900 that this distinction was added.)
> >>
> >> I'm also not sure it makes sense to choose a different NaN encoding
> >> when NaNs aren't supported anyway.
> >>
> >> It would be good if we could reuse spu_single_format directly.
> >
> > I don't know what the effect of has_sign_dependent_rounding is.
>
> Like I say, it tells GCC whether -X can round to something other than -Y
> in cases where X would round to Y. This is true for IEEE when rounding
> towards +infinity or -infinity, but those modes aren't supported on the
> R5900.
>
> Some transformations are invalid when has_sign_dependent is true.
> E.g. -(X - Y) is not always equal to Y - X. We want it to be false
> when possible, so it looked like the spu_single_format version was right.
The manual says that the rounding differs in the least significant bit, so we
need to assume that this can happen any time and it also leads to a different
result when the sign is different. Currently I have problems testing it,
because the latest GCC which I use (svn r200583) is not able to build the Linux
kernel, because it has at least 2 bugs. The first is the bug 57698 introduced
between 17.06. and 26.06. It seems that no GCC developer is able to fix it. The
second bug affects the dvb_demux.c from Linux 2.6.34 when -Os and -mlong is
used. This triggers an sanity check in do_SUBST in file gcc/combine.c. The
first bugs happens on all architectures. The second also appears with normal
mipsel. There is also a bug which annoys me since years,
__attribute__((aligned(16))) is not working with local variables and doesn't
print a warning. This is particulary a problem when used in typedefs, because
the problem is not visible.
My native ps2sdk doesn't have an implementation of rounding. I don't have an
environment with a combination of the correct versions of the different
components for Linux. So I can't test it at the moment.
> > I also can't test it, because the GCC is already not correctly working
> > on SPU.
>
> Can you give an example?
I wanted to say that I don't know what is correct or not, because the GCC is
already not handling the other stuff correctly, e.g.:
inf - inf => 0
nan - nan => 0
nan == nan => true (this must be false according to IEEE 754)
but __builtin_nanf() == __builtin_nanf() => false (this is correct according to
IEEE 754, because this is already evaluted by GCC before creating the assembler
code)
nan == inf => true
__builtin_inff() is 0x7fff
__builtin_nanf() is 0x7fff
> > The EE Core User's Manual also says that the Guard, Round and Sticky
> > bits are ignored. So the rounding can differ from IEEE 754 in the least
> > significant bit.
> > Exceptions are not supported and must be emulated by trap instructions.
>
> But defining r5900_single_format doesn't change the way GCC handles that,
> does it?
At least I expected that exceptions are generated.
Rounding is something new which also needs to be added, but not now.
> I suppose my point is that we should only introduce another format if
> there is a testcase where r5900_single_format produces the right results
> and spu_single_format doesn't.
Currently I don't have a testsuite for this. So I also don't have any tests
which have these results.
> >> > To be able to use it, you need to use mipsr5900el and
> >> > "--with-float=single". "--with-float=hard" results in double float
> >> > because of MIPS ISA III.
> >>
> >> This isn't quite right as-is. The code that applies the --with-float
> >> setting is:
> >>
> >> #define OPTION_DEFAULT_SPECS \
> >> ... \
> >> {"float", "%{!msoft-float:%{!mhard-float:-m%(VALUE)-float}}" }, \
> >>
> >> in mips.h. So -mdouble-float wouldn't override --with-float=single, etc.
> >>
> >> single vs. double has traditionally been a separate choice from hard
> >> vs. soft (which is a bit unfortunate given that single vs. double makes
> >> no sense for soft float). Maybe we should have --with-fpu=single and
> >> --with-fpu=double instead.
> >
> > In my tests the parameter "--with-float=single" automatically selected
> > hard float as default.
> > I don't see a way to change the configure script to use "--with-fpu"
> > without changing the parameters of GCC also. This would make it
> > incompatible with old GCC versions.
>
> It should just be a case of adding:
>
> {"fpu", "%{!msingle-float:%{!mdouble-float:-m%(VALUE)-float}}" }, \
>
> to the macro above.
OK, I didn't know that.
Re: [PATCH] Enable non-complex math builtins from C99 for Bionic
On Thu, 28 Mar 2013, Alexander Ivchenko wrote: > Hi, > > 4.8 is now branched, lets come back to the discussion that we had > before. I updated the patch a little > bit since we now have linux-protos.h and linux-android.c files. > > I tried to preserve the avaiability of c99 for all targets, but it's > pretty difficult, because we are changing > the defaults. Passing an empty string as second argument doesn't look > very good, but on the other hand > the user has one clear way for checking the presence of a certain > function. But of course we can create > another function, that will call targetm.libc_has_function > (function_class, "") within itself. Observations on this patch version: * You still shouldn't be calling with "" as function name (or 0, in i386.md) unless there's a good reason the relevant function can't readily be identified. (Actually, the TARGET_C99_FUNCTIONS checks in i386.md seem wrong - the instruction patterns expand things inline and the semantics of an isinf insn pattern are nothing to do with whether the target library has C99 functions; C99 doesn't provide isinf as a function anyway, only as a macro.) If you don't yet need the name in any hook implementation, feel free to define the hooks without the name argument and it can be added later if needed. * I don't see how your change for Darwin preserves the existing semantics; you appear to make it use no_c99_libc_has_function, but the existing semantics are that it has C99 functions except for 32-bit powerpc Darwin versions older than 10.3. * I don't see how your change preserves semantics for Solaris either - you add a definition in sol2.h (for Solaris 9) but don't override it in sol2-10.h (for Solaris 10, which has the C99 functions). * I don't see anything to preserve semantics for AIX 4.3 and 5.1 (the AIX versions for which TARGET_C99_FUNCTIONS was not defined). * I don't see anything to preserve semantics for alpha*-dec-*vms*. * I don't see anything to preserve semantics for hppa*-*-hpux*. * I don't see anything to preserve semantics for i[34567]86-pc-msdosdjgpp*. * I don't see anything to preserve semantics for i[34567]86-*-cygwin*, or x86_64-*-cygwin*, or i[34567]86-*-mingw*, or x86_64-*-mingw*, or i[34567]86-*-interix[3-9]*. * It looks rather like microblaze*-*-* don't use elfos.h, so meaning semantics aren't preserved for those (non-Linux) targets either. Now, I don't know if there's a good reason for not using that file (ask the architecture maintainer), but in any case semantics should be preserved. * I don't see anything to preserve semantics for mmix-knuth-mmixware, or pdp11-*-*, or picochip-* (more non-ELF targets). * The patch is missing the poisoning of the removed target macros in system.h. Now, for verifying semantics are unchanged for existing targets, you might want to adapt contrib/config-list.mk to show in some way the TARGET_C99_FUNCTIONS setting resulting from tm.h (before your patch) or the new hook setting (after your patch), so you can compare for all the targets listed there. That's not perfect - the list of targets may not be complete - but if you fix all the issues listed above then before-and-after comparison for lots of targets using config-list.mk would be a good way of gaining confidence in the lack of unintended changes in the patch. -- Joseph S. Myers jos...@codesourcery.com
Re: vector conditional expression with scalar arguments
On Mon, 8 Jul 2013, Jason Merrill wrote: On 07/07/2013 08:02 AM, Marc Glisse wrote: + error_at (loc, "could not find an integer type " + "of the same size as %qT", ctype); Now that I think of it, if a?b:c fails for this reason, it would also fail later because it can't compute a!=0 (which is what the first argument is expanded to), so I could move the construction of a!=0 earlier instead, and re-use its type (modulo signed/unsigned). Why try to find a result element type the same size as the condition element type? For scalars the condition is bool and the result can be any type. It is a guess, so it may be wrong. My experience on x86 is that vectors have a fixed size (128 bits for SSE, 256 for AVX) and most operations act on vectors of the same size. Mixing vectors of different sizes is likely to result in operations not supported by the hardware and expanded to slow scalar code. Comparisons already return a signed integer vector type of the same size as the operands (so they fail for vectors of long double on x86). Now there are some exceptions on x86, and it may be that other architectures have more. The vectorizer even has code to handle these mixed sizes. We could also consider that selecting a better vector size is the role of a middle-end optimization and should not affect the language rules. Note that the VEC_COND_EXPR we currently have in gcc requires the 3 arguments to have the same size and number of elements, so we would need to use VEC_(UN)PACK_*_EXPR and CONSTRUCTOR/BIT_FIELD_REF (all our tree codes are for vectors of fixed size, so doubling the size of the elements also drops half the elements). Perhaps the most conservative rule would be to only accept the case where the sizes match and reject the others for now, so whatever is decided later for other cases is unlikely to require a breaking change. Though I would like the general case to be accepted eventually, whatever it ends up meaning ;-) -- Marc Glisse
Re: Fwd: Ping: [PATCH] Set $ac_aux_dir before use in libdecnumber/configure
This is fine, thanks. Ben signature.asc Description: Digital signature
Re: RFC: Add of type-demotion pass
On Mon, 8 Jul 2013, Kai Tietz wrote: These passes are implementing type-demotion (type sinking into statements) for some gimple statements. I limitted inital implementation to the set of multiply, addition, substraction, and binary-and/or/xor. Additional this pass adds some rules to sink type-cast sequences - eg. (int) (short) x; with char as type of x. This special handing in this pass of such type-sequence simplification is necessary to avoid too complex cast-sequences by type-unsigned conversion used by this pass to avoid undefined overflow behaviour. Hello, thanks for working on this. This seems like a nice chance for me to learn, so I am trying to understand your patch, and I would be glad if you could give me a couple hints. I wonder why you implemented this as a separate pass instead of adding it to tree-ssa-forwprop. demote_cast is (or should be) a special case of combine_conversions, so it would be nice to avoid the code duplication (there is also a version in fold-const.c). demote_into could be called from roughly the same place as simplify_conversion_from_bitmask. And you could reuse get_prop_source_stmt, can_propagate_from, remove_prop_source_from_use, etc. If I understand, the main reason is because you want to go through the statements in reverse order, since this is the way the casts are being propagated (would forwprop also work, just more slowly, or would it miss opportunities across basic blocks?). I have some trouble understanding why something as complicated as build_and_add_sum (which isn't restricted to additions by the way) is needed. Could you add a comment to the code explaining why you need to insert the statements precisely there and not for instance just before their use? Is that to try and help CSE? I have added an additional early pass "typedemote1" to this patch for simple cases types can be easily sunken into statement without special unsigned-cast for overflow-case. Jakub asked for it. Tests have shown that this pass does optimizations in pretty few cases. As example in testsuite see for example pr46867.c testcase. The second pass (I put it behind first vrp pass to avoid testcase-conflicts) uses 'unsigned'-type casts to avoid undefined overflow behavior. This pass has much more hits in standard code, I assume that, when the pass is done, we can consider removing the corresponding code from the front-ends? That would increase the hits ;-) -- Marc Glisse
Re: [PATCH] fix typos mandated by conventions.
On Mon, 8 Jul 2013, Ondrej Bilka wrote: > Hi now, when I have infrastructure ready I made another patch (its 500kb so > link not to overload list). It is here; > http://kam.mff.cuni.cz/~ondra/gcc_misspell_conventions.patch > > It uses dictionary made by reading gcc conventions. > http://gcc.gnu.org/codingconventions.html As explained on that page, certain files and directories come from upstream and so it is inappropriate to apply GCC-specific conventions to them, or to fix any typos locally rather than upstream. In particular, you should not be patching boehm-gc or zlib. intl is also externally maintained code so again should not be patched for this issue; likewise libdecnumber and libffi (libdecnumber and libffi may get local patches, but only when needed to fix bugs, not simply for GCC-specific conventions). libiberty is shared with other projects so it's not clear that GCC-specific conventions should apply there; you need to discuss changes there in conjunction with the other projects. libjava/classpath and libjava/libltdl are also externally maintained. libquadmath code comes from glibc so unless the code in question is GCC-specific, do not apply GCC conventions to it. It's possible that the changes do make sense for the other projects, in that the GCC conventions are supposed to have good reasons behind them. But, you should raise the issues with those projects separately and if patches are desired only then produce patches relative to current upstream versions of those projects. It is not generally desirable to apply such cleanups to testcases. -- Joseph S. Myers jos...@codesourcery.com
Re: fixincludes 2013-05-23
On Mon, Jul 8, 2013 at 11:42 AM, Alexander Ivchenko wrote: >> It sounds like it is better to fix the system headers instead. Via a >> fixincludes for older headers and have the android folks fix them for >> newer releases. > > Would that count for verifing? :) :) Indeed. I confess I didn't look past March. The patch is now in my inbox. I'll try to get to it next weekend.
Re: [testsuite] skip gcc.target/powerpc-tfmode_off.c for eabi
On Jul 8, 2013, at 12:48 PM, Janis Johnson wrote: > Test gcc.target/powerpc-tfmode_off.c fails for powerpc-eabi* targets, > which do not support TFmode. This patch skips the test for > powerpc-*-eabi*. > > OK for mainline and the 4.8 branch? Ok, but could you please add a comment why it is skipped. (No TFmode, for example)
Re: [testsuite] fix powerpc alignment tests for eabi
On Jul 8, 2013, at 12:47 PM, Janis Johnson wrote: > Tests gcc.target/powerpc/20020118-1.c and > gcc.c-torture/execute/nest-align-1.c sometimes fail because they expect > a stack alignment that is greater than that required for powerpc-eabi. > This patch forces stack alignment to 128 bits by passing "-mno-eabi". > > Is this OK for mainline and the 4.8 branch, or would it be better to > skip these tests for powerpc-*-eabi*? I don't have a strong preference either way, I'd defer to someone with an opinion. I have a weak preference for additional testing, so I like the patch.
[testsuite] skip gcc.target/powerpc-tfmode_off.c for eabi
Test gcc.target/powerpc-tfmode_off.c fails for powerpc-eabi* targets,
which do not support TFmode. This patch skips the test for
powerpc-*-eabi*.
OK for mainline and the 4.8 branch?
Janis
2013-07-08 Janis Johnson
* gcc.target/powerpc/tfmode_off.c: Skip for EABI targets.
Index: gcc.target/powerpc/tfmode_off.c
===
--- gcc.target/powerpc/tfmode_off.c (revision 200621)
+++ gcc.target/powerpc/tfmode_off.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do assemble } */
/* { dg-skip-if "" { powerpc-ibm-aix* } { "*" } { "" } } */
+/* { dg-skip-if "" { powerpc-*-eabi* } { "*" } { "" } } */
/* { dg-options "-O2 -fno-align-functions -mtraceback=no -save-temps" } */
typedef float TFmode __attribute__ ((mode (TF)));
[testsuite] fix powerpc alignment tests for eabi
Tests gcc.target/powerpc/20020118-1.c and
gcc.c-torture/execute/nest-align-1.c sometimes fail because they expect
a stack alignment that is greater than that required for powerpc-eabi.
This patch forces stack alignment to 128 bits by passing "-mno-eabi".
Is this OK for mainline and the 4.8 branch, or would it be better to
skip these tests for powerpc-*-eabi*?
Janis
2013-07-08 Janis Johnson
* gcc.target/powerpc/20020118-1.c: Force 128-bit stack alignment
for EABI targets.
* gcc.c-torture/execute/nest-align-1.x: Likewise.
Index: gcc.target/powerpc/20020118-1.c
===
--- gcc.target/powerpc/20020118-1.c (revision 200621)
+++ gcc.target/powerpc/20020118-1.c (working copy)
@@ -1,6 +1,8 @@
/* { dg-do run { target powerpc*-*-* } }*/
/* VxWorks only guarantees 64 bits of alignment (STACK_BOUNDARY == 64). */
/* { dg-skip-if "" { "powerpc*-*-vxworks*" } { "*" } { "" } } */
+/* Force 128-bit stack alignment for eabi targets. */
+/* { dg-options "-mno-eabi" { target powerpc*-*-eabi* } } */
/* Test local alignment. Test new target macro STARTING_FRAME_PHASE. */
/* Origin: Aldy Hernandez . */
Index: gcc.c-torture/execute/nest-align-1.x
===
--- gcc.c-torture/execute/nest-align-1.x(revision 0)
+++ gcc.c-torture/execute/nest-align-1.x(revision 0)
@@ -0,0 +1,5 @@
+# Force bigger stack alignment for PowerPC EABI targets.
+if { [istarget "powerpc-*-eabi*"] } {
+set additional_flags "-mno-eabi"
+}
+return 0
[testsuite] fix gcc.target/powerpc/ppc-spe64-1.c
The error message checked in gcc.target/powerpc/ppc-spe64-1.c changed
for GCC 4.8. This obvious patch fixes the test to expecte the current
message; checked in for mainline and the 4.8 branch.
Janis
2013-07-08 Janis Johnson
* gcc.target/powerpc/ppc-spe64-1.c: Update expected error message.
Index: gcc.target/powerpc/ppc-spe64-1.c
===
--- gcc.target/powerpc/ppc-spe64-1.c(revision 200621)
+++ gcc.target/powerpc/ppc-spe64-1.c(working copy)
@@ -4,4 +4,4 @@
/* { dg-options "-m64" } */
/* { dg-error "-m64 not supported in this configuration" "SPE not 64-bit" {
target *-*-* } 0 } */
-/* { dg-error "64-bit E500 not supported" "64-bit E500" { target *-*-* } 0 } */
+/* { dg-error "64-bit SPE not supported" "64-bit SPE" { target *-*-* } 0 } */
[testsuite] fix gcc.target/powerpc/pr47197.c
Test gcc.target/powerpc/pr47197.c passes "-maltivec" without first
checking that the option is allowed on the target, which is not the case
for powerpc-eabispe. This obvious patch fixes the problem by requiring
powerpc_altivec_ok; checked in on mainline and the 4.8 branch.
Janis
2013-07-08 Janis Johnson
* gcc.target/powerpc/pr47197.c: Require powerpc_altivec_ok.
Index: gcc.target/powerpc/pr47197.c
===
--- gcc.target/powerpc/pr47197.c(revision 200621)
+++ gcc.target/powerpc/pr47197.c(working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-maltivec" } */
/* Compile-only test to ensure that expressions can be passed to
[testsuite] fix gcc.target/powerpc/sd-vsx.c and sd-pwr6.c
Tests gcc.target/powerpc/sd-vsx.c and sd-pwr6.c assume that decimal
floating point is supported on the target, but this is not true for
powerpc-none-eabi. This obvious patch skips the test if dfp is
not supported; checked in for mainline.
Janis
2013-07-08 Janis Johnson
* gcc.target/powerpc/sd-vsx.c: Require dfp.
* gcc.target/powerpc/sd-pwr6.c: Likewise.
Index: gcc.target/powerpc/sd-pwr6.c
===
--- gcc.target/powerpc/sd-pwr6.c(revision 200789)
+++ gcc.target/powerpc/sd-pwr6.c(working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* powerpc-ibm-aix* } { "*" } { "" } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target dfp } */
/* { dg-options "-O2 -mcpu=power6 -mhard-dfp" } */
/* { dg-final { scan-assembler-not "lfiwzx" } } */
/* { dg-final { scan-assembler-times "lfd"2 } } */
Index: gcc.target/powerpc/sd-vsx.c
===
--- gcc.target/powerpc/sd-vsx.c (revision 200789)
+++ gcc.target/powerpc/sd-vsx.c (working copy)
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if "" { powerpc*-*-darwin* powerpc-ibm-aix* } { "*" } { "" } } */
/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target dfp } */
/* { dg-options "-O2 -mcpu=power7 -mhard-dfp" } */
/* { dg-final { scan-assembler-times "lfiwzx" 2 } } */
/* { dg-final { scan-assembler-times "stfiwx" 1 } } */
Re: List of typos.
On Mon, 2013-07-08 at 16:12 +0200, Ondřej Bílka wrote: > On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote: > > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote: > > > Ondrej Bilka schrieb: > > > > > > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch > > > > I fixed most comments, put it here so you can diff these two files. > http://kam.mff.cuni.cz/~ondra/gcc_misspell_fixed.patch > > > > > > > BASE must be either a declaration or a memory reference that has correct > > - alignment ifformation embeded in it (e.g. a pre-existing one in SRA). > > */ > > + alignment ifformation embedded in it (e.g. a pre-existing one in SRA). > > */ > > > > -> missed 'information' I guess... > > > > This fixes only a-e. These are probably incomplete as I needed to > exclude lot of names that are variable names etc. > > I did selectin based on following file: > http://kam.mff.cuni.cz/~ondra/gcc_misspells > > > > > > - http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algoritms > > + http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algorithms > > > > both links do 404 anyway ;) > > > could you find what this was? I need to add another filter not touch > html which I will do probably tomorrow. It seems the original article is gone. At least I can't find it easily (the patch that added the link is from 2001...). It's about Fibonacci Heaps so there's plenty of material out there on the net. The paper mentioned in the comment can be found rather easily: http://www.cs.princeton.edu/courses/archive/fall03/cs528/handouts/fibonacci%20heaps.pdf However, maybe it's better to replace the DDJ link with this http://en.wikipedia.org/wiki/Fibonacci_heap Cheers, Oleg
[Patch, Fortran, committed] PR57834 - Remove bogus c_f_pointer error
Committed as obvious (Rev. 200794) after regtesting on x86-64-gnu-linux.
Without the patch, the following bogus error was shown for -std=f2003/f2008:
call C_F_POINTER(cptr, str, [255])
1
Error: TS 29113: Noninteroperable array FPTR at (1) to C_F_POINTER: Only
explicit-size and assumed-size arrays are interoperable
Tobias
2013-07-08 Tobias Burnus
PR fortran/57834
* check.c (is_c_interoperable): Add special case for c_f_pointer.
(explicit-size, gfc_check_c_f_pointer, gfc_check_c_loc): Update
call.
2013-07-08 Tobias Burnus
PR fortran/57834
* gfortran.dg/c_f_pointer_tests_8.f90: New.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index e531deb..4024cd4 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3650,10 +3650,11 @@ gfc_check_sizeof (gfc_expr *arg)
otherwise, it is set to NULL. The msg string can be used in diagnostics.
If c_loc is true, character with len > 1 are allowed (cf. Fortran
2003corr5); additionally, assumed-shape/assumed-rank/deferred-shape
- arrays are permitted. */
+ arrays are permitted. And if c_f_ptr is true, deferred-shape arrays
+ are permitted. */
static bool
-is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc)
+is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc, bool c_f_ptr)
{
*msg = NULL;
@@ -3734,7 +3735,8 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc)
*msg = "Only whole-arrays are interoperable";
return false;
}
- if (ar->as->type != AS_EXPLICIT && ar->as->type != AS_ASSUMED_SIZE)
+ if (!c_f_ptr && ar->as->type != AS_EXPLICIT
+ && ar->as->type != AS_ASSUMED_SIZE)
{
*msg = "Only explicit-size and assumed-size arrays are interoperable";
return false;
@@ -3750,7 +3752,7 @@ gfc_check_c_sizeof (gfc_expr *arg)
{
const char *msg;
- if (!is_c_interoperable (arg, &msg, false))
+ if (!is_c_interoperable (arg, &msg, false, false))
{
gfc_error ("'%s' argument of '%s' intrinsic at %L must be an "
"interoperable data entity: %s",
@@ -3900,7 +3902,7 @@ gfc_check_c_f_pointer (gfc_expr *cptr, gfc_expr *fptr, gfc_expr *shape)
return false;
}
- if (!is_c_interoperable (fptr, &msg, false) && fptr->rank)
+ if (!is_c_interoperable (fptr, &msg, false, true))
return gfc_notify_std (GFC_STD_F2008_TS, "Noninteroperable array FPTR "
"at %L to C_F_POINTER: %s", &fptr->where, msg);
@@ -4029,7 +4031,7 @@ gfc_check_c_loc (gfc_expr *x)
return false;
}
- if (!is_c_interoperable (x, &msg, true))
+ if (!is_c_interoperable (x, &msg, true, false))
{
if (x->ts.type == BT_CLASS)
{
--- /dev/null 2013-07-08 12:26:00.282145465 +0200
+++ gcc/gcc/testsuite/gfortran.dg/c_f_pointer_tests_8.f90 2013-07-08 19:15:56.658470682 +0200
@@ -0,0 +1,37 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+!
+! PR fortran/57834
+!
+! (Gave a bogus warning before.)
+!
+program main
+
+use iso_c_binding
+use iso_fortran_env
+
+implicit none
+
+interface
+function strerror(errno) bind(C, NAME = 'strerror')
+import
+type(C_PTR) :: strerror
+integer(C_INT), value :: errno
+end function
+end interface
+
+integer :: i
+type(C_PTR) :: cptr
+character(KIND=C_CHAR), pointer :: str(:)
+
+cptr = strerror(INT(42, KIND = C_INT))
+call C_F_POINTER(cptr, str, [255])
+
+do i = 1, SIZE(str)
+if (str(i) == C_NULL_CHAR) exit
+write (ERROR_UNIT, '(A1)', ADVANCE = 'NO') str(i:i)
+enddo
+
+write (ERROR_UNIT, '(1X)')
+
+end program main
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
On Mon, Jul 08, 2013 at 11:44:04AM -0700, Janis Johnson wrote:
> >> @@ -0,0 +1,16 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
> >> -mfloat-abi=hard -S" } */
> >>
> >> dg-add-options arm_neon ?
> >> dg-require-effective-target arm_neon ?
> >
> > I will update it.
>
> Please skip the test for multilibs whose flags include -mfpu or -mcpu options,
> which would conflict with or override the options in the test.
Also the -S in dg-options looks wrong. That should be derived from dg-do.
Jakub
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
On 07/08/2013 08:32 AM, Zhenqiang Chen wrote:
> On 8 July 2013 20:57, Ramana Radhakrishnan wrote:
>> Not yet. Why is this not a problem in the LT / UNLT case ?
>
>>From the context, after the first switch, only GE/LE/EQ might have
> operands[5] which is not REG (CONST0_RTX). For others including
> LT/UNLT, operands[5] should be REG.
>
> if (!REG_P (operands[5]))
> operands[5] = force_reg (mode, operands[5]);
>
> For GE/LE/EQ, we only reverse LE. So only LE has issue.
>
>> The testcase is not correctly written.
>>
>>
>> @@ -0,0 +1,16 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
>> -mfloat-abi=hard -S" } */
>>
>> dg-add-options arm_neon ?
>> dg-require-effective-target arm_neon ?
>
> I will update it.
Please skip the test for multilibs whose flags include -mfpu or -mcpu options,
which would conflict with or override the options in the test.
Janis
> Thanks!
> -Zhenqiang
>
>> On Wed, Jun 26, 2013 at 9:01 AM, Zhenqiang Chen
>> wrote:
>>> On 18 June 2013 17:41, Ramana Radhakrishnan wrote:
On 06/18/13 09:50, Zhenqiang Chen wrote:
>
> Hi,
>
> During expand, function vcond inverses some CMP, e.g.
>
> a LE b -> b GE a
>
> But if "b" is "CONST0_RTX", "b GE a" will be an illegal insn.
>
> (insn 933 932 934 113 (set (reg:V4SI 1027)
> (unspec:V4SI [
> (const_vector:V4SI [
> (const_int 0 [0])
> (const_int 0 [0])
> (const_int 0 [0])
> (const_int 0 [0])
> ])
> (reg:V4SI 1023 [ vect_var_.49 ])
> (const_int 1 [0x1])
> ] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
> (nil))
>
> Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
> for more. And the bug also happens for FSF trunk.
>
> The similar issue
> (https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
> had fixed on AARCH64:
> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
>
> The patch is similar to the fix for aarch64.
>
> Bootstrap and no make check regression on Panda Board.
>
> Is it OK for trunk and 4.8?
No, not without an appropriate set of testcases that exercise these cases.
>>>
>>> Thanks for the comments. Patch is updated with a test case.
>>>
>>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>>> index 2761adb..6d9f604 100644
>>> --- a/gcc/config/arm/neon.md
>>> +++ b/gcc/config/arm/neon.md
>>> @@ -1710,6 +1710,9 @@
>>> case LE:
>>> case UNLE:
>>>inverse = 1;
>>> + /* Can not inverse "a LE 0" to "0 GE a". */
>>> + if (operands[5] == CONST0_RTX (mode))
>>> + inverse = 0;
>>>/* Fall through. */
>>> case GT:
>>> case UNGT:
>>> diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> b/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> new file mode 100644
>>> index 000..8ce4b97
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> @@ -0,0 +1,16 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
>>> -mfloat-abi=hard -S" } */
>>> +
>>> +int id;
>>> +int
>>> +test (const long int *data)
>>> +{
>>> + int i, retval;
>>> + retval = id;
>>> + for (i = 0; i < id; i++)
>>> +{
>>> + retval &= (data[i] <= 0);
>>> +}
>>> +
>>> + return (retval);
>>> +}
>
>
Re: fixincludes 2013-05-23
2013/7/8 Bruce Korb :
> Hi,
>
> On Mon, Jul 8, 2013 at 5:05 AM, Alexander Ivchenko wrote:
>> Hi Bruce,
>>
>> That was my original letter:
>>>Hi,
>>>
>>>Could you please take a look at the attached fixinclude patch
>>>that addresses the problem:
>>>
>>>" We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>>>reason for that is that
>>>-ftraditional-cpp is not expected to work on Android due to variadic
>>>macro (like #define __builtin_warning(x, y...))
>>>in standard headers and traditional preprocessor cannot handle them."
>>>
>>>is it ok for trunk?
>>>
>>>thanks,
>>>Alexander
>>
>> So I did ask whether it is ok or not. And then I got:
>>
>>> Be sure to ask, Ok? in your patch submittals.
>>>
>>> Ok.
>
> Oops. Wrong word. I said, "you didn't ask" and meant to say
> "you didn't get approval". I didn't see the original request because
> there was no hint about "fixincludes" in the subject and I was not
> on the to/cc line. So you asked, just not effectively enough for
> me to see it and you did _not_ get approval.
>
> Still:
>
>>> Also, I prefer that the hacks get inserted
>>> alphabetically. So, actually, there are a few small complaints.
>
>>> The patch looks pretty reasonable, but I think someone else
>>> should verify the obsolescence. I also think it should be renamed to
>>> something like "obsolete_builtin_warning" because the current
>>> name gives no clue about what it really is.
>>>
>>> /*
>>> * Old Linux kernel's header breaks Traditional CPP
>>> */
>>> fix = {
>>> hackname = complier_h_tradcpp;
>>> files = linux/compiler.h;
>>>
>>> select= "#define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\)";
>>> c_fix = format;
>>> c_fix_arg = "/* __builtin_warning(x, y...) is obsolete */";
>>>
>>> test_text = "#define __builtin_warning(x, y...) (1)";
>>> };
>
> Please be kind enough to belatedly finish up and we'll (I'll) reapply it.
I already renamed it and inserted alpabetically, as you said (the
patch is attached in my previous letter).
So the only thing left is "someone else should verify the obsolescence"..
When I firstly tried to disable the gcc.dg/cpp/trad/include.c for
Android, I got the following answer:
2013/1/9 Andrew Pinski :
> On Wed, Jan 9, 2013 at 7:14 AM, Alexander Ivchenko wrote:
>> Hi,
>>
>> We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>> reason for that is that
>> -ftraditional-cpp is not expected to work on Android due to variadic
>> macro (like #define __builtin_warning(x, y...))
>> in standard headers and traditional preprocessor cannot handle them.
>> The attached patch disables that test.
>
> It sounds like it is better to fix the system headers instead. Via a
> fixincludes for older headers and have the android folks fix them for
> newer releases.
Would that count for verifing? :)
thank you,
Alexander
Re: [C++ Patch] PR 51786
On 07/08/2013 01:49 PM, Paolo Carlini wrote: Ah I see. I take your indication as meaning class *or enum* Yes. Jason
Re: [c++-concepts] requires expression semantics
On 07/04/2013 11:30 AM, Andrew Sutton wrote: I ran through every test in the is_convertible unit test with __is_convertible. There are 2 cases it doesn't address. The conversion of a function type (int()) to its reference type (int(&)()), I looked into this a bit more; it seemed odd to consider any conversion from int() since there are no prvalues of function type. The is_convertible trait is defined in terms of a conversion from an xvalue of the first type, so your __is_convertible_to trait should wrap type1 in an rvalue reference. That seems to give the correct result. Looking at the other uses of can_convert, it seems like they mostly don't deal with those cases. So, can_convert *might* be extended to address these cases, but I'd rather be on the safe side and keep this as a separate function. I disagree. can_convert is not documented as only considering standard conversions, so it ought to handle user-defined conversions as well. My preference would be to rename the current function and any needed uses to can_convert_standard, and give the name can_convert the intuitive meaning. Jason
[i386] add unwinding via signal trampoline for kfreebsd*-gnu
Please add support for unwinding through signal handler for GNU/kFreeBSD.
The attached patch is tested on GNU/kFreeBSD, both 32-bit and 64-bit.
The i386/freebsd-unwind.h is probably also suitable for plain FreeBSD.
As suggested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57851
I am posting it here.
The patch mainly add new libgcc/config/i386/freebsd-unwind.h
based on linux one.
Thanks
Petr#
# unwinding via signal trampoline
#
--- a/src/libgcc/config.host
+++ b/src/libgcc/config.host
@@ -523,7 +523,12 @@
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
md_unwind_header=i386/linux-unwind.h
;;
-i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* |
i[34567]86-*-kopensolaris*-gnu)
+i[34567]86-*-kfreebsd*-gnu)
+ extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
+ tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
+ md_unwind_header=i386/freebsd-unwind.h
+ ;;
+i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
;;
@@ -532,7 +537,12 @@
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
md_unwind_header=i386/linux-unwind.h
;;
-x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
+x86_64-*-kfreebsd*-gnu)
+ extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
+ tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
+ md_unwind_header=i386/freebsd-unwind.h
+ ;;
+x86_64-*-knetbsd*-gnu)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff
t-dfprules"
;;
--- a/src/libgcc/config/i386/freebsd-unwind.h
+++ b/src/libgcc/config/i386/freebsd-unwind.h
@@ -0,0 +1,190 @@
+/* DWARF2 EH unwinding support for AMD x86-64 and x86.
+ Copyright (C) 2004-2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+
Re: [C++ Patch] PR 51786
Hi,
>On 07/07/2013 12:32 PM, Paolo Carlini wrote:
>> -auto int; // { dg-error "multiple types|can only be specified for
>variables" }
>> +auto int; // { dg-error "multiple types|does not declare anything" }
>
>This is a regression. Please limit the change to when the type is a
>class.
Ah I see. I take your indication as meaning class *or enum*: it seems to me
that like this we precisely 'undo' the effect of finish_decltype_type and we
cover the other half of the new testcase. I'll send something later today.
Thanks,
Paolo
RFC: Add of type-demotion pass
Hello,
These passes are implementing type-demotion (type sinking into statements) for
some gimple statements. I limitted inital implementation to the set of
multiply, addition, substraction, and binary-and/or/xor. Additional this pass
adds some rules to sink type-cast sequences - eg. (int) (short) x; with char as
type of x. This special handing in this pass of such type-sequence
simplification is necessary to avoid too complex cast-sequences by
type-unsigned conversion used by this pass to avoid undefined overflow
behaviour.
I will sent separate patch with some test-cases to demonstrate and verify
operation of this new optimization. Just one sample I will cite here to
demonstrate operation of type-demotion pass.
--start-
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
signed char a[1024], b[1024];
void
baz (void)
{
int i, s, t;
for (i = 0; i < 1024; i++)
{ s = a[i]; t = b[i]; s += t + 0x12345600; a[i] = s; }
}
/* { dg-final { scan-tree-dump-times "305419776" 0 "optimized" } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
--end--
You will notice that by typedemote2 pass the 's += t + 0x12345600;' expression
gets simplified to 's += t + 0;'.
I have added an additional early pass "typedemote1" to this patch for simple
cases types can be easily sunken into statement without special unsigned-cast
for overflow-case. Jakub asked for it. Tests have shown that this pass does
optimizations in pretty few cases. As example in testsuite see for example
pr46867.c testcase.
The second pass (I put it behind first vrp pass to avoid testcase-conflicts)
uses 'unsigned'-type casts to avoid undefined overflow behavior. This pass has
much more hits in standard code, but seems to trigger some regressions in vect
pass:
List of regi
FAIL: gcc.dg/vect/slp-cond-3.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c -flto scan-tree-dump-times vect
"vect_recog_widen_mult_pattern: detected" 1
FAIL: gcc.dg/vect/slp-cond-3.c -flto scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.target/i386/rotate-1.c scan-assembler ro[lr]b
2013-07-08 Kai Tietz
* Makefile.in (OBJS): Add tree-ssa-te.o
* passes.c (init_optimization_passes): Add
pass_type_demote1 and pass_type_demote2.
tree-pass.h (pass_type_demote1): Add declaration.
(pass_type_demote2): Likewise.
* tree-ssa-te.c: New implementation file.
Patch is tested for x86_64-unknown-linux-gnu, and x86_64-w64-mingw32. Ok for
apply?
Regards,
Kai
Index: gcc-trunk/gcc/Makefile.in
===
--- gcc-trunk.orig/gcc/Makefile.in
+++ gcc-trunk/gcc/Makefile.in
@@ -1442,6 +1442,7 @@ OBJS = \
tree-ssa-strlen.o \
tree-ssa-structalias.o \
tree-ssa-tail-merge.o \
+ tree-ssa-te.o \
tree-ssa-ter.o \
tree-ssa-threadedge.o \
tree-ssa-threadupdate.o \
Index: gcc-trunk/gcc/passes.c
===
--- gcc-trunk.orig/gcc/passes.c
+++ gcc-trunk/gcc/passes.c
@@ -1412,6 +1412,7 @@ init_optimization_passes (void)
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_merge_phi);
NEXT_PASS (pass_vrp);
+ NEXT_PASS (pass_type_demote1);
NEXT_PASS (pass_dce);
NEXT_PASS (pass_call_cdce);
NEXT_PASS (pass_cselim);
@@ -1437,6 +1438,7 @@ init_optimization_passes (void)
NEXT_PASS (pass_phi_only_cprop);
NEXT_PASS (pass_dse);
NEXT_PASS (pass_reassoc);
+ NEXT_PASS (pass_type_demote2);
NEXT_PASS (pass_dce);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_phiopt);
Index: gcc-trunk/gcc/tree-pass.h
===
--- gcc-trunk.orig/gcc/tree-pass.h
+++ gcc-trunk/gcc/tree-pass.h
@@ -365,6 +365,9 @@ extern struct gimple_opt_pass pass_tm_ed
extern struct gimple_opt_pass pass_split_functions;
extern struct gimple_opt_pass pass_feedback_split_functions;
extern struct gimple_opt_pass pass_strength_reduction;
+extern struct gimple_opt_pass pass_type_promote;
+extern struct gimple_opt_pass pass_type_demote1;
+extern struct gimple_opt_pass pass_type_demote2;
/* IPA Passes */
extern struct simple_ipa_opt_pass pass_ipa_lower_emutls;
Index: gcc-trunk/gcc/tree-ssa-te.c
===
--- /dev/null
+++ gcc-trunk/gcc/tree-ssa-te.c
@@ -0,0 +1,566 @@
+/* Type-elevation for trees
+ Copyright (C) 2013
+ Free Software Foundation, Inc.
+ Contributed by Kai Tietz
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; w
Re: Fwd: [PATCH] Attribute for unused warning for variables of non-trivial types
On 06/30/2013 04:21 AM, Lubos Lunak wrote:
Are you sure this should be covered by -Wunused-but-set-variable rather than
plain -Wunused-variable? While strictly technically speaking the variable is
set by the ctor, it's conceptually confusing (is "string s;" really set from
the developer's point of view?), and it's inconsistent with basic types:
$ echo "void f() { int a = 1; } " | g++ -x c++ -fsyntax-only -Wall -
: In function ‘void f()’:
:1:16: warning: unused variable ‘a’ [-Wunused-variable]
Ah, I didn't realize that we warn about unused variables with
initializers. OK, then.
+ { "warn_unused",0, 0, false, false, false,
+ handle_warn_unused_attribute, false },
Was it a deliberate decision to put this in the c-common attributes
rather than the C++-specific ones? I'm not saying it's wrong, just
interested in your thinking.
+ || lookup_attribute ("warn_unused", TYPE_ATTRIBUTES (TREE_TYPE
(decl)
Line longer than 80 characters.
+ if( !lookup_attribute ("warn_unused", TYPE_ATTRIBUTES (type)))
Space before paren, not after.
And your patch is missing a ChangeLog entry.
It looks like you don't have a copyright assignment on file with the
FSF; this patch is small enough not to need one, but we should take care
of that so that future patches don't get blocked.
Jason
Re: Preserve xvalues in ?:
OK. Jason
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
On Mon, Jul 08, 2013 at 04:32:13PM +0100, Zhenqiang Chen wrote:
> On 8 July 2013 20:57, Ramana Radhakrishnan wrote:
> > Not yet. Why is this not a problem in the LT / UNLT case ?
>
> From the context, after the first switch, only GE/LE/EQ might have
> operands[5] which is not REG (CONST0_RTX). For others including
> LT/UNLT, operands[5] should be REG.
This is true, but looks like an omission. My copy of the ARMARM
has immediate #0 instruction forms for CMLT, CMLE, CMGE, CMGT
and CMEQ. Perhaps it is beyond the scope of your bugfix
(though it was in your original patch?), but this should be
fixed in future so as not to force 0 to registers.
>
> if (!REG_P (operands[5]))
> operands[5] = force_reg (mode, operands[5]);
>
> For GE/LE/EQ, we only reverse LE. So only LE has issue.
>
For now, but as above - as soon as this code is fixed to generate
immediate #0 forms, it will be fragile again.
> >> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
> >> index 2761adb..6d9f604 100644
> >> --- a/gcc/config/arm/neon.md
> >> +++ b/gcc/config/arm/neon.md
> >> @@ -1710,6 +1710,9 @@
> >> case LE:
> >> case UNLE:
> >>inverse = 1;
> >> + /* Can not inverse "a LE 0" to "0 GE a". */
> >> + if (operands[5] == CONST0_RTX (mode))
> >> + inverse = 0;
> >>/* Fall through. */
> >> case GT:
> >> case UNGT:
Is this really what you mean? Surely now you will have:
inverse = 0
base_comparison = gen_neon_vcgt
Thus in the next switch you will call:
emit_insn (gen_neon_vcgt (mask, operands[4], operands[5], magic_rtx));
Which looks wrong. Would you not also have to set swap_bsl_operands
to get back to the correct semantics?
> >> diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
> >> b/gcc/testsuite/gcc.target/arm/lp1189445.c
> >> new file mode 100644
> >> index 000..8ce4b97
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/arm/lp1189445.c
> >> @@ -0,0 +1,16 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
> >> -mfloat-abi=hard -S" } */
> >> +
> >> +int id;
> >> +int
> >> +test (const long int *data)
> >> +{
> >> + int i, retval;
> >> + retval = id;
> >> + for (i = 0; i < id; i++)
> >> +{
> >> + retval &= (data[i] <= 0);
> >> +}
> >> +
> >> + return (retval);
> >> +}
>
This testcase is not much use. It may well compile, but won't catch
the wrong instruction generation issue I pointed out above.
I much prefer your original patch, with a more rigorous testcase.
Thanks,
James
Re: [Fortran] Patch ping**2
** PING ** On July 01, Tobias Burnus wrote: The following patches are pending to be reviewed: * http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html * http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html * http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html It would help me tremendously if my local patch queue would be shorter. I have another two unsubmitted patches in the queue - and some more half-ready patches. Alternately, I could start declaring more patches as obvious … (As I just did; but they really were simple.) Tobias
Re: constexpr vector indexing
On 07/07/2013 11:54 AM, Marc Glisse wrote: it turns out there wasn't much missing here. I got side-tracked because fold_unary_loc doesn't call fold_indirect_ref_1, and fold_indirect_ref_1 has a too strict comparison type == TREE_TYPE (optype) (should compare TYPE_MAIN_VARIANT instead?), but none of that was necessary so I'll leave it for another time. I think there should be a middle end type comparison function that allows a few differences, but that is definitely something for another time. Jason
Re: [patch, fortran] PR 50554 - redefinition of index variable with inquire(iolength=...)
Now committed as obvious (Rev. 200790). Tobias Tobias Burnus wrote: Tobias Burnus wrote: Actually, I wonder whether the following (untested) shouldn't be sufficient: Seems to work. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias
Re: [C++ Patch] PR 51786
On 07/07/2013 12:32 PM, Paolo Carlini wrote:
-auto int; // { dg-error "multiple types|can only be specified for variables" }
+auto int; // { dg-error "multiple types|does not declare anything" }
This is a regression. Please limit the change to when the type is a class.
Jason
Re: vector conditional expression with scalar arguments
On 07/07/2013 08:02 AM, Marc Glisse wrote: + error_at (loc, "could not find an integer type " + "of the same size as %qT", ctype); Why try to find a result element type the same size as the condition element type? For scalars the condition is bool and the result can be any type. Jason
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
On 8 July 2013 20:57, Ramana Radhakrishnan wrote:
> Not yet. Why is this not a problem in the LT / UNLT case ?
>From the context, after the first switch, only GE/LE/EQ might have
operands[5] which is not REG (CONST0_RTX). For others including
LT/UNLT, operands[5] should be REG.
if (!REG_P (operands[5]))
operands[5] = force_reg (mode, operands[5]);
For GE/LE/EQ, we only reverse LE. So only LE has issue.
> The testcase is not correctly written.
>
>
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
> -mfloat-abi=hard -S" } */
>
> dg-add-options arm_neon ?
> dg-require-effective-target arm_neon ?
I will update it.
Thanks!
-Zhenqiang
> On Wed, Jun 26, 2013 at 9:01 AM, Zhenqiang Chen
> wrote:
>> On 18 June 2013 17:41, Ramana Radhakrishnan wrote:
>>> On 06/18/13 09:50, Zhenqiang Chen wrote:
Hi,
During expand, function vcond inverses some CMP, e.g.
a LE b -> b GE a
But if "b" is "CONST0_RTX", "b GE a" will be an illegal insn.
(insn 933 932 934 113 (set (reg:V4SI 1027)
(unspec:V4SI [
(const_vector:V4SI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(reg:V4SI 1023 [ vect_var_.49 ])
(const_int 1 [0x1])
] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
(nil))
Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
for more. And the bug also happens for FSF trunk.
The similar issue
(https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
had fixed on AARCH64:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
The patch is similar to the fix for aarch64.
Bootstrap and no make check regression on Panda Board.
Is it OK for trunk and 4.8?
>>>
>>>
>>> No, not without an appropriate set of testcases that exercise these cases.
>>
>> Thanks for the comments. Patch is updated with a test case.
>>
>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>> index 2761adb..6d9f604 100644
>> --- a/gcc/config/arm/neon.md
>> +++ b/gcc/config/arm/neon.md
>> @@ -1710,6 +1710,9 @@
>> case LE:
>> case UNLE:
>>inverse = 1;
>> + /* Can not inverse "a LE 0" to "0 GE a". */
>> + if (operands[5] == CONST0_RTX (mode))
>> + inverse = 0;
>>/* Fall through. */
>> case GT:
>> case UNGT:
>> diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
>> b/gcc/testsuite/gcc.target/arm/lp1189445.c
>> new file mode 100644
>> index 000..8ce4b97
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/lp1189445.c
>> @@ -0,0 +1,16 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
>> -mfloat-abi=hard -S" } */
>> +
>> +int id;
>> +int
>> +test (const long int *data)
>> +{
>> + int i, retval;
>> + retval = id;
>> + for (i = 0; i < id; i++)
>> +{
>> + retval &= (data[i] <= 0);
>> +}
>> +
>> + return (retval);
>> +}
Re: fixincludes 2013-05-23
Hi,
On Mon, Jul 8, 2013 at 5:05 AM, Alexander Ivchenko wrote:
> Hi Bruce,
>
> That was my original letter:
>>Hi,
>>
>>Could you please take a look at the attached fixinclude patch
>>that addresses the problem:
>>
>>" We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>>reason for that is that
>>-ftraditional-cpp is not expected to work on Android due to variadic
>>macro (like #define __builtin_warning(x, y...))
>>in standard headers and traditional preprocessor cannot handle them."
>>
>>is it ok for trunk?
>>
>>thanks,
>>Alexander
>
> So I did ask whether it is ok or not. And then I got:
>
>> Be sure to ask, Ok? in your patch submittals.
>>
>> Ok.
Oops. Wrong word. I said, "you didn't ask" and meant to say
"you didn't get approval". I didn't see the original request because
there was no hint about "fixincludes" in the subject and I was not
on the to/cc line. So you asked, just not effectively enough for
me to see it and you did _not_ get approval.
Still:
>> Also, I prefer that the hacks get inserted
>> alphabetically. So, actually, there are a few small complaints.
>> The patch looks pretty reasonable, but I think someone else
>> should verify the obsolescence. I also think it should be renamed to
>> something like "obsolete_builtin_warning" because the current
>> name gives no clue about what it really is.
>>
>> /*
>> * Old Linux kernel's header breaks Traditional CPP
>> */
>> fix = {
>> hackname = complier_h_tradcpp;
>> files = linux/compiler.h;
>>
>> select= "#define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\)";
>> c_fix = format;
>> c_fix_arg = "/* __builtin_warning(x, y...) is obsolete */";
>>
>> test_text = "#define __builtin_warning(x, y...) (1)";
>> };
Please be kind enough to belatedly finish up and we'll (I'll) reapply it.
Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size
Hi Richard,
The problem was with adjusting to be more expansive the load imm + mul sequence
and
the shift + add sequence were the smake cost when optimizing for size so the
code in expmed.c
choose the MUL.
I also considered this version also I couldn't decide which was better just
went with the other
version on a toss of a coin.
I submit again with mips target testcase which use scan assember technique to
check that
we use the shift+add/sub sequence.
A simple testcase compiled with -Os
int foo(int x)
{
return x * 17;
}
will demonstrate that we currently use "LI + MUL" and after the patch we will
use "SLL + ADDU".
Gtraham
Re: List of typos.
On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote: > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote: > > Ondrej Bilka schrieb: > > > > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch > > I fixed most comments, put it here so you can diff these two files. http://kam.mff.cuni.cz/~ondra/gcc_misspell_fixed.patch > > BASE must be either a declaration or a memory reference that has correct > - alignment ifformation embeded in it (e.g. a pre-existing one in SRA). */ > + alignment ifformation embedded in it (e.g. a pre-existing one in SRA). */ > > -> missed 'information' I guess... > This fixes only a-e. These are probably incomplete as I needed to exclude lot of names that are variable names etc. I did selectin based on following file: http://kam.mff.cuni.cz/~ondra/gcc_misspells > > > - http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algoritms > + http://www.ddj.com/articles/1997/9701/9701o/9701o.htm?topic=algorithms > > both links do 404 anyway ;) > could you find what this was? I need to add another filter not touch html which I will do probably tomorrow. > > - // Randomize the colour, just for asthetics =) > + // Randomize the colour, just for aesthetics =) > > -> missed 'color' (in a couple of places actually) > Wa- not on my list because my aspell thinks its valid.
Re: [Patch, Fortran] PR57785 - Fix folding of dot_product for complex vars
Am 03.07.2013 14:05, schrieb Tobias Burnus:
Thanks goes to Dominique for debugging the issue!
Build and regtested on x86-64-gnu-linux.
OK for the trunk? I think one should also backport it to 4.7/4.8.
(Folding - and hence the bug - exist since GCC 4.5.)
For the trunk, committed as Rev. 200786 - using the attached test case
as replacement for the original one.
Dominique Dhumieres wrote:
(2) I don't like the scan-tree-dump: they are fragile and have a limited
coverage. I'ld prefer a test such as the following
! { dg-do run }
And I really dislike "dg-do run" tests for compile-time simplifications.
I think the attached test case should combine the best of the two worlds.
In general, I think one needs both: Many things aren't reliably testable
with run-time tests. Thus, dumps help a lot: They have a *better*
coverage of certain things and are usually quite robust. Having
compile-only tests is also a tad faster. On the other hand, run tests
are good to ensure that the interplay of different features works well.
Tobias
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! PR fortran/57785
!
! Contributed by Kontantinos Anagnostopoulos
!
! The implicit complex conjugate was missing for DOT_PRODUCT
! For the following, the compile-time simplification fails for SUM;
! see PR fortran/56342. Hence, a manually expanded SUM is used.
!if (DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /)) &
! /= SUM (CONJG ((/ (1.0, 2.0), (2.0, 3.0) /))*(/ (1.0, 1.0), (1.0, 4.0) /))) &
! call abort ()
!
!if (ANY (MATMUL ((/ (1.0, 2.0), (2.0, 3.0) /), &
! RESHAPE ((/ (1.0, 1.0), (1.0, 4.0) /),(/2, 1/))) /= &
! SUM ((/ (1.0, 2.0), (2.0, 3.0) /)*(/ (1.0, 1.0), (1.0, 4.0) / &
!call abort ()
if (DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /)) &
/= CONJG (cmplx(1.0, 2.0)) * cmplx(1.0, 1.0) &
+ CONJG (cmplx(2.0, 3.0)) * cmplx(1.0, 4.0)) &
call abort ()
if (ANY (MATMUL ((/ (1.0, 2.0), (2.0, 3.0) /),&
RESHAPE ((/ (1.0, 1.0), (1.0, 4.0) /),(/2, 1/))) &
/= cmplx(1.0, 2.0) * cmplx(1.0, 1.0) &
+ cmplx(2.0, 3.0) * cmplx(1.0, 4.0))) &
call abort ()
end
! { dg-final { scan-tree-dump-not "abort" "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Re: [patch i386]: RFC enable inlining for function with machine-attributes
On 07/04/2013 03:06 AM, Kai Tietz wrote: > Hi, > > here is the adjusted patch for this PR. > > 2013-07-04 Kai Tietz > > PR target/56892 > * config/i386/i386.c (TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P): Define as > hook_bool_const_tree_true. Ok. r~
Re: List of typos.
On Sun, Jul 07, 2013 at 07:54:34PM +0200, Georg-Johann Lay wrote:
> Ondrej Bilka schrieb:
>
> >http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
>
> This is wrong:
>
> @@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
> XOP[2] # Bytes to copy
>
> Return TRUE if the expansion is accomplished.
> - Return FALSE if the operand compination is not supported. */
> + Return FALSE if the operand compilation is not supported. */
>
> Should be "combination" not "compilation".
>
>
> index 406617f..c7a7f7b 100644
> --- a/gcc/config/frv/frv-opts.h
> +++ b/gcc/config/frv/frv-opts.h
> @@ -1,4 +1,4 @@
> -/* Frv option-handling defitions.
> +/* Frv option-handling deviations.
>
> Should be "definitions" instead of "deviations".
>
>
> -/* Expand SYMBOL into its corresponding far-addresse symbol.
> +/* Expand SYMBOL into its corresponding far-addressee symbol.
>
> Is this correct or should be "far-address"?
>
>
> @@ -5336,7 +5336,7 @@ pa_print_operand (FILE *file, rtx x, int code)
> && GET_CODE (XEXP (XEXP (x, 0), 1)) == REG)
> {
> /* Because the REG_POINTER flag can get lost during reload,
> - pa_legitimate_address_p canonicalizes the order of the
> + pa_legitimate_address_p canonizes the order of the
>
> I am not sure about this one and many others. "canonicalize" sounds
> ok to me, so does "canonicalization". "canonize" sounds odd to me.
> For example the following which should change none or both:
>
> -/* Canonicalize the filename NAME by canonicalizing directory
> +/* Canonicalize the filename NAME by canonizing directory
>
> - * Unique vinsn derivates from CALL, ASM, JUMP (for a while) and other
> + * Unique vinsn derivatives from CALL, ASM, JUMP (for a while) and other
>
> Shouldn't this be "derives"?
>
>
> - /* Merge c_expres found or unify live register sets from different
> + /* Merge c_express found or unify live register sets from different
>
> Some lines above in sel-sched.c there is "C_EXPRes". Again, change
> none or both (none seems fine here):
>
oops it was bug, fixed.
>
> - /* Test exponentials and their signs. A buggy lexer is more likely
> + /* Test exponential and their signs. A buggy lexer is more likely
>
> Should both be plural or singular. "exponents" sounds good to me.
>
it is also in string bellow so probably we need change or keep both.
>
> - Roger Sayle <...@eyesopen.com>
> + Roger Sayle <...@eyes open.com>
>
> Don't change email addresses!
bug, fixed
[PATCH] RTEMS: Use __cxa_atexit by default for RTEMS
The __cxa_atexit support is a reqirement for destructor registration of
thread-local objects.
For *-*-elf it is already enabled by default. See comment line 810 in
"gcc/config.gcc".
Define TARGET_LIBGCC_SDATA_SECTION on PowerPC for RTEMS to ".sdata" to
place the __dso_handle. The __dso_handle is referenced by application
code. In case this code uses the small data section, the __dso_handle
must be there.
This patch should be committed to GCC 4.8 and 4.9.
Test results:
http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00671.html
gcc/ChangeLog
2013-07-08 Sebastian Huber
* config.gcc (*-*-rtems*): Use __cxa_atexit by default.
* config/rs6000/rtems.h (TARGET_LIBGCC_SDATA_SECTION): Define.
---
gcc/config.gcc|1 +
gcc/config/rs6000/rtems.h |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index a927964..1648dfe 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -734,6 +734,7 @@ case ${target} in
yes) thread_file='rtems' ;;
esac
extra_options="${extra_options} rtems.opt"
+ default_use_cxa_atexit=yes
use_gcc_stdint=wrap
;;
*-*-uclinux*)
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index b910b5e..fb22be1 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -34,6 +34,9 @@
} \
while (0)
+#undef TARGET_LIBGCC_SDATA_SECTION
+#define TARGET_LIBGCC_SDATA_SECTION ".sdata"
+
#undef CPP_OS_DEFAULT_SPEC
#define CPP_OS_DEFAULT_SPEC "%(cpp_os_rtems)"
--
1.7.7
Re: [Committed] S/390: Use macros for the FPR register numbers in the backend
On Mon, Jul 08, 2013 at 01:03:38PM +0200, Uros Bizjak wrote:
> Hello!
>
> > the attached patch adds F0_REGNUM ... F15_REGNUM and uses these
> > throughout the s390.c file. The FPR numbering in the s390 backend is
> > not obvious and this hopefully makes it easier to get right for me.
>
> Index: gcc/config/s390/s390.h
> ===
> *** gcc/config/s390/s390.h.orig
> --- gcc/config/s390/s390.h
> *** enum reg_class
> *** 477,482
> --- 477,499
> { 0x, 0x003f }, /* ALL_REGS */ \
> }
>
> + #define F0_REGNUM 16
> + #define F1_REGNUM 20
> + #define F2_REGNUM 17
> + #define F3_REGNUM 21
> + #define F4_REGNUM 18
> + #define F5_REGNUM 22
> + #define F6_REGNUM 19
> + #define F7_REGNUM 23
> + #define F8_REGNUM 24
> + #define F9_REGNUM 25
> + #define F10_REGNUM 26
> + #define F11_REGNUM 27
> + #define F12_REGNUM 28
> + #define F13_REGNUM 29
> + #define F14_REGNUM 30
> + #define F15_REGNUM 31
>
> You can add these as define_constant in s390.md (see for example
> i386.md). There is already definition of FPR0_REGNUM and FPR2_REGNUM,
> which is now incostistent (18) with your new definitions (17).
Thanks. Now it probably became apparent that I need a vehicle to help
me with the S/390 FPR numbering.
The existing constant (FPR2_REGNUM) was wrong as well as my new macros
(>F8).
I'll commit the attached patch after successful testing.
Bye,
-Andreas-
2013-07-08 Andreas Krebbel
* config/s390/s390.c: Replace F*_REGNUM with FPR*_REGNUM.
* config/s390/s390.h: Remove F*_REGNUM macro definitions.
* config/s390/s390.md: Define FPR*_REGNUM constants.
Fix FPR2_REGNUM constant (18 -> 17).
("*trunc2")
("*trunc2")
("trunc2")
("trunc2")
("*extend2")
("*extend2")
("extend2")
("extend2"): Replace FPR2_REGNUM with
FPR4_REGNUM.
---
gcc/config/s390/s390.c | 74
gcc/config/s390/s390.h | 17 ---
gcc/config/s390/s390.md | 40 !
3 files changed, 17 deletions(-), 114 modifications(!)
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** struct GTY (()) s390_frame_layout
*** 333,341
/* Bits standing for floating point registers. Set, if the
respective register has to be saved. Starting with reg 16 (f0)
at the rightmost bit.
! Bit 15 - 8 7 6 5 4 3 2 1 0
! fpr 15 - 8 7 5 3 1 6 4 2 0
! reg 31 - 24 23 22 21 20 19 18 17 16 */
unsigned int fpr_bitmap;
/* Number of floating point registers f8-f15 which must be saved. */
--- 333,341
/* Bits standing for floating point registers. Set, if the
respective register has to be saved. Starting with reg 16 (f0)
at the rightmost bit.
! Bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
! fpr 15 13 11 9 14 12 10 8 7 5 3 1 6 4 2 0
! reg 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 */
unsigned int fpr_bitmap;
/* Number of floating point registers f8-f15 which must be saved. */
*** struct GTY(()) machine_function
*** 380,388
#define cfun_gprs_save_area_size ((cfun_frame_layout.last_save_gpr_slot -
\
cfun_frame_layout.first_save_gpr_slot + 1) * UNITS_PER_LONG)
#define cfun_set_fpr_save(REGNO) (cfun->machine->frame_layout.fpr_bitmap |=
\
! (1 << (REGNO - F0_REGNUM)))
#define cfun_fpr_save_p(REGNO) (!!(cfun->machine->frame_layout.fpr_bitmap &
\
! (1 << (REGNO - F0_REGNUM
/* Number of GPRs and FPRs used for argument passing. */
#define GP_ARG_NUM_REG 5
--- 380,388
#define cfun_gprs_save_area_size ((cfun_frame_layout.last_save_gpr_slot -
\
cfun_frame_layout.first_save_gpr_slot + 1) * UNITS_PER_LONG)
#define cfun_set_fpr_save(REGNO) (cfun->machine->frame_layout.fpr_bitmap |=
\
! (1 << (REGNO - FPR0_REGNUM)))
#define cfun_fpr_save_p(REGNO) (!!(cfun->machine->frame_layout.fpr_bitmap &
\
! (1 << (REGNO - FPR0_REGNUM
/* Number of GPRs and FPRs used for argument passing. */
#define GP_ARG_NUM_REG 5
*** s390_frame_area (int *area_bottom, int *
*** 7472,7483
if (!TARGET_64BIT)
{
! if (cfun_fpr_save_p (F4_REGNUM))
{
b = MIN (b, cfun_frame_layout.f4_offset);
t = MAX (t, cfun_frame_layout.f4_offset + 8);
}
! if (cfun_fpr_save_p (F6_REGNUM))
{
b = MIN (b, cfun_frame_layout.f4_offset + 8);
t = MAX (t, cfun_frame_layout.f4_offset + 16);
--- 7472,7483
if (!TARGET_64BIT)
{
! if (cfun_fpr_save_p (FPR4_REGNUM))
{
b = MIN (b, cfun_frame_layout.f4_offset);
t = MAX (t, cfun_frame_layout.f4_offset + 8);
}
! if (
Re: [PATCH, ARM] Fix unrecognizable vector comparisons
Not yet. Why is this not a problem in the LT / UNLT case ?
The testcase is not correctly written.
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
-mfloat-abi=hard -S" } */
dg-add-options arm_neon ?
dg-require-effective-target arm_neon ?
regards
Ramana
On Wed, Jun 26, 2013 at 9:01 AM, Zhenqiang Chen
wrote:
> On 18 June 2013 17:41, Ramana Radhakrishnan wrote:
>> On 06/18/13 09:50, Zhenqiang Chen wrote:
>>>
>>> Hi,
>>>
>>> During expand, function vcond inverses some CMP, e.g.
>>>
>>> a LE b -> b GE a
>>>
>>> But if "b" is "CONST0_RTX", "b GE a" will be an illegal insn.
>>>
>>> (insn 933 932 934 113 (set (reg:V4SI 1027)
>>> (unspec:V4SI [
>>> (const_vector:V4SI [
>>> (const_int 0 [0])
>>> (const_int 0 [0])
>>> (const_int 0 [0])
>>> (const_int 0 [0])
>>> ])
>>> (reg:V4SI 1023 [ vect_var_.49 ])
>>> (const_int 1 [0x1])
>>> ] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
>>> (nil))
>>>
>>> Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
>>> for more. And the bug also happens for FSF trunk.
>>>
>>> The similar issue
>>> (https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
>>> had fixed on AARCH64:
>>> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
>>>
>>> The patch is similar to the fix for aarch64.
>>>
>>> Bootstrap and no make check regression on Panda Board.
>>>
>>> Is it OK for trunk and 4.8?
>>
>>
>> No, not without an appropriate set of testcases that exercise these cases.
>
> Thanks for the comments. Patch is updated with a test case.
>
> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
> index 2761adb..6d9f604 100644
> --- a/gcc/config/arm/neon.md
> +++ b/gcc/config/arm/neon.md
> @@ -1710,6 +1710,9 @@
> case LE:
> case UNLE:
>inverse = 1;
> + /* Can not inverse "a LE 0" to "0 GE a". */
> + if (operands[5] == CONST0_RTX (mode))
> + inverse = 0;
>/* Fall through. */
> case GT:
> case UNGT:
> diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
> b/gcc/testsuite/gcc.target/arm/lp1189445.c
> new file mode 100644
> index 000..8ce4b97
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/lp1189445.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
> -mfloat-abi=hard -S" } */
> +
> +int id;
> +int
> +test (const long int *data)
> +{
> + int i, retval;
> + retval = id;
> + for (i = 0; i < id; i++)
> +{
> + retval &= (data[i] <= 0);
> +}
> +
> + return (retval);
> +}
Re: [testsuite] Adding target nonpic to certain tests part. 2
*Ping*
>>> Another bunch of tests that fails with -fpic.
>>>
>>> from here: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00539.html
>>> "Since -fpic option is turned on by default in Android we have certain test
>>> fails. The reason for that is that those tests rely on the
>>> availability of functions, defined in them
>>> and with -fpic compiler conservatively assumes that they are
>>> AVAIL_OVERWRITABLE."
>>>
>>> I added {target nonpic} to them as before.
Is the attached patch ok?
We already did that for some tests before here:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00975.html
So, considering that, it should be a pretty obvious fix.
thanks,
Alexander
2013/6/11 Alexander Ivchenko :
> Yep, that also works for us. I updated the patch. Is it ok for trunk?
>
> --Alexander
>
> 2013/6/5 Patrick Marlier :
>> Hi Alexander,
>>
>> At least for TM testcase, I would prefer to add 'transaction_safe'
>> attribute on foobar as in the attached patch.
>> Aldy and Richard H: What do you think?
>>
>> Thanks,
>> --
>> Patrick
>>
>> On Wed, Jun 5, 2013 at 1:13 PM, Alexander Ivchenko
>> wrote:
>>> Hi,
>>>
>>> Another bunch of tests that fails with -fpic.
>>>
>>> from here: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00539.html
>>> "Since -fpic option is turned on by default in Android we have certain test
>>> fails. The reason for that is that those tests rely on the
>>> availability of functions, defined in them
>>> and with -fpic compiler conservatively assumes that they are
>>> AVAIL_OVERWRITABLE."
>>>
>>> I added {target nonpic} to them as before.
>>>
>>>
>>> Is it ok for trunk?
>>>
>>>
>>> thanks,
>>> Alexander
add_target_nonpic_03.patch
Description: Binary data
Re: [Patch, Fortran] PR57469 - silence unused dummy arg warning, if it is used in a namelist
Tobias Burnus wrote: Built and regtested on x86-64-gnu-linux. OK for the trunk? Committed as obvious (Rev. 200785) with the test-case's grammar in the comment fixed. (Thanks Dominique for the review.) Tobias
[Patch, Fortran, committed] Re: testsuite: defined_assignment_7.f90 and finalize_10.f90
Manfred Schwarb wrote:
dg-compile, dg!final and missing parens protection.
Thanks for the patch! I committed it as Rev. 200784. (The dg!final was a
left-over from some testing; I should switch to something more visible
for commenting out those.)
Tobias
Index: defined_assignment_7.f90
===
--- defined_assignment_7.f90(revision 200697)
+++ defined_assignment_7.f90(working copy)
@@ -1,4 +1,4 @@
-! { dg-compile }
+! { dg-do compile }
!
! PR fortran/57508
!
Index: finalize_10.f90
===
--- finalize_10.f90 (revision 200697)
+++ finalize_10.f90 (working copy)
@@ -32,8 +32,8 @@
! FINALIZE TYPE:
! { dg-final { scan-tree-dump-times "parm.\[0-9\]+.data = \\(void
\\*\\) &\\(\\*aa.\[0-9\]+\\)\\\[0\\\];" 1 "original" } }
-! { dg!final { scan-tree-dump-times "__final_m_T2 (&parm.\[0-9\]+, 0,
0);" 1 "original" } }
-! { dg!final { scan-tree-dump-times "desc.\[0-9\]+.data = \\(void \\*
restrict\\) bb;" 1 "original" } }
-! { dg!final { scan-tree-dump-times "__final_m_T2 (&desc.\[0-9\]+, 0,
0);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "__final_m_T2 \\(&parm.\[0-9\]+,
0, 0\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "desc.\[0-9\]+.data = \\(void \\*
restrict\\) bb;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "__final_m_T2 \\(&desc.\[0-9\]+,
0, 0\\);" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Re: fixincludes 2013-05-23
Hi Bruce,
That was my original letter:
>Hi,
>
>Could you please take a look at the attached fixinclude patch
>that addresses the problem:
>
>" We have test fail for gcc.dg/cpp/trad/include.c on Android. The
>reason for that is that
>-ftraditional-cpp is not expected to work on Android due to variadic
>macro (like #define __builtin_warning(x, y...))
>in standard headers and traditional preprocessor cannot handle them."
>
>is it ok for trunk?
>
>thanks,
>Alexander
So I did ask whether it is ok or not. And then I got:
> Be sure to ask, Ok? in your patch submittals.
>
> Ok.
>From Mike Stump, which was pretty misleading. Anyway, I had to
double-check the real
maintainer of fixincludes and I'm sorry that I didn't do that.
I'm happily addressing your complaints. I've changed the name of the
fix and have put it on the correct place (also had to change the place
of obstack_lvalue_cast - it was not alphabetically correct).
is the attached patch ok? All fixinclude tests pass.
best regards,
Alexander
2013/7/6 Bruce Korb :
>> Alexander Ivchenko Mon, 29 Apr 2013 23:24:55 -0700
>>
>> 2013/4/29 Mike Stump :
>>>
>>> On Jan 9, 2013, at 7:14 AM, Alexander Ivchenko
>>> wrote:
We have test fail for gcc.dg/cpp/trad/include.c on Android. The
reason for that is that
-ftraditional-cpp is not expected to work on Android due to variadic
macro (like #define __builtin_warning(x, y...))
in standard headers and traditional preprocessor cannot handle them.
The attached patch disables that test.
>>>
>>>
>>> Be sure to ask, Ok? in your patch submittals.
>>>
>>> Ok.
>>
>>
>> thank you! I thought I did ask..
>>
>>> ...
>>> in standard headers and traditional preprocessor cannot handle them."
>>>
>>> is it ok for trunk?
>>
>>
>> could someone commit that patch please? I don't have commit access.
>
>
> Actually, Alexander, you did not ask. And Kirill, you didn't verify
> before applying the patch. Patches to fixincludes are generally safe,
> but it is protocol to ask. Also, I prefer that the hacks get inserted
> alphabetically. So, actually, there are a few small complaints.
>
>> $ fgrep -i fixincludes ../MAINTAINERS
>> fixincludes Bruce Korb bk...@gnu.org
>
>
> The patch looks pretty reasonable, but I think someone else
> should verify the obsolescence. I also think it should be renamed to
> something like "obsolete_builtin_warning" because the current
> name gives no clue about what it really is.
>
> /*
> * Old Linux kernel's header breaks Traditional CPP
> */
> fix = {
> hackname = complier_h_tradcpp;
> files = linux/compiler.h;
>
> select= "#define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\)";
> c_fix = format;
> c_fix_arg = "/* __builtin_warning(x, y...) is obsolete */";
>
> test_text = "#define __builtin_warning(x, y...) (1)";
> };
trad_cpp_fixincludes_03.patch
Description: Binary data
Re: Fix missing use of -Werror when compiling files in c-familty directory
I've fixed the issue with the warnings and have now comitted the patch with a corrected ChangeLog entry as revision 200783 Graham
[PATCH 0/6] Contributing new target port: Andes 'nds32'.
Hi, GCC Steering Committee, reviewers, and developers, On behalf of Andes Technology Corp., we are submitting a new port 'nds32' for GCC contribution. In this contribution, we use the design and strategy as modern as possible, such as having LRA enabled and taking soft-fp as our software floating point library. None of general gcc code is required to be changed for this nds32 port. We have already signed FSF agreement and are proposing Shiva Chen and myself (Chung-Ju Wu), both of Andes compiler engineers, as nds32 port maintainers: Index: MAINTAINERS === --- MAINTAINERS (revision 200655) +++ MAINTAINERS (working copy) @@ -87,6 +87,8 @@ mn10300 port Jeff Lawl...@redhat.com mn10300 port Alexandre Oliva aol...@redhat.com moxie port Anthony Green gr...@moxielogic.com +nds32 port Chung-Ju Wu jasonw...@gmail.com +nds32 port Shiva Chen shiva0...@gmail.com pdp11 port Paul Koning n...@arrl.net picochip port Daniel Towner d...@picochip.com rl78 port DJ Delorie d...@redhat.com A series of patches have been posted on gcc-patches: [PATCH 1/6] Andes nds32: configure settings for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00269.html [PATCH 2/6] Andes nds32: machine description of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00270.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00271.html http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00272.html [PATCH 3/6] Andes nds32: libgcc of nds32 porting. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00273.html [PATCH 4/6] Andes nds32: testsuite modifications for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00274.html [PATCH 5/6] Andes nds32: documentation for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00276.html [PATCH 6/6] Andes nds32: wwwdoc for nds32 target. http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00277.html A brief overview of changed files is as below: [gcc-svn: contrib/] * config-list.mk [gcc-svn: gcc/] * config.gcc * config/nds32/* * common/config/nds32/* * doc/invoke.texi * doc/md.texi * doc/install.texi * doc/extend.texi [gcc-svn: libgcc/] * config.host * config/nds32/* [gcc-svn: gcc/testsuite/] * g++.dg/other/PR23205.C * g++.dg/other/pr23205-2.C * gcc.dg/20020312-2.c * gcc.dg/builtin-apply2.c * gcc.dg/lower-subreg-1.c * gcc.dg/sibcall-3.c * gcc.dg/sibcall-4.c * gcc.dg/stack-usage-1.c * gcc.dg/torture/pr37868.c * gcc.dg/torture/stackalign/builtin-apply-2.c * gcc.dg/tree-ssa/20040204-1.c * gcc.dg/tree-ssa/forwprop-28.c * gcc.dg/tree-ssa/pr42585.c * gcc.dg/tree-ssa/sra-12.c * gcc.dg/ucnid-11.c * gcc.dg/ucnid-2.c * gcc.dg/ucnid-3.c * lib/target-supports.exp [wwwdoc-cvs: htdocs/] * backends.html * readings.html * gcc-4.9/changes.html In addition, here are some standard requirement we have made for contribution: 1. Add nds32le-elf and nds32be-elf into contrib/config-list.mk. 2. We follow the -2013 range convention in copyright description. 3. Using a native compiler from current GCC trunk (20130704, Rev.200655), the nds32 port can be built cleanly with --enable-werror-always on both 32-bit and 64-bit host. 4. The nds32 test results have been posted on gcc-testresults: 32-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00378.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00380.html 64-bit host: v2, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00379.html v3, http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg00381.html For completeness of Andes nds32 toolchain, we also proposed nds32 contribution for other packages [1]-[3] on corresponding mailing list. And the nds32 target for packages [4] and [5] are previously merged into master on 2011.10 and 2013.06, respectively. We sincerely hope that the nds32 target will be available in GCC 4.9. Your reviews and comments are very important to us for making this contribution better. Thanks for your time to review our contribution. Best regards, jasonwucj [1] binutils: http://sourceware.org/ml/binutils/2013-07/msg00062.html [2] gdb: http://sourceware.org/ml/gdb-patches/2013-07/msg00223.html [3] newlib: http://sourceware.org/ml/newlib/2013/msg00525.html [4] u-boot: http://lists.denx.de/pipermail/u-boot/2011-October/106467.html [5] openocd: http://openocd.zylin.com/1259
[PATCH 6/6] Andes nds32: wwwdoc for nds32 target.
Hi, This patch consists of webpage changes for describing a new 'nds32' target port and related information. The following is a brief overview of changes: htdocs/ 2013-07-08 Chung-Ju Wu Shiva Chen * backends.html: Add architecture characteristic key for nds32 target. * readings.html: Add related information for nds32 target. * gcc-4.9/changes.html: Add nds32 target support description. 6-nds32-wwwdoc.patch Description: Binary data
[PATCH 5/6] Andes nds32: documentation for nds32 target.
Hi, This patch consists of the nds32 specific content in documentation, including options, constraints, --with-nds32-lib configure option, and attributes for nds32 target. gcc/ 2013-07-08 Chung-Ju Wu Shiva Chen * doc/invoke.texi (NDS32 options): Document nds32 specific options. * doc/md.texi (NDS32 family): Document nds32 specific constraints. * doc/install.texi (Cross-Compiler-Specific Options): Document --with-nds32-lib for nds32 target. * doc/extend.texi (Function Attributes): Document nds32 specific attributes. 5-nds32-documentation.patch Description: Binary data
Re: [Committed] S/390: Use macros for the FPR register numbers in the backend
Hello!
> the attached patch adds F0_REGNUM ... F15_REGNUM and uses these
> throughout the s390.c file. The FPR numbering in the s390 backend is
> not obvious and this hopefully makes it easier to get right for me.
Index: gcc/config/s390/s390.h
===
*** gcc/config/s390/s390.h.orig
--- gcc/config/s390/s390.h
*** enum reg_class
*** 477,482
--- 477,499
{ 0x, 0x003f }, /* ALL_REGS */ \
}
+ #define F0_REGNUM 16
+ #define F1_REGNUM 20
+ #define F2_REGNUM 17
+ #define F3_REGNUM 21
+ #define F4_REGNUM 18
+ #define F5_REGNUM 22
+ #define F6_REGNUM 19
+ #define F7_REGNUM 23
+ #define F8_REGNUM 24
+ #define F9_REGNUM 25
+ #define F10_REGNUM 26
+ #define F11_REGNUM 27
+ #define F12_REGNUM 28
+ #define F13_REGNUM 29
+ #define F14_REGNUM 30
+ #define F15_REGNUM 31
You can add these as define_constant in s390.md (see for example
i386.md). There is already definition of FPR0_REGNUM and FPR2_REGNUM,
which is now incostistent (18) with your new definitions (17).
Uros.
[PATCH 4/6] Andes nds32: testsuite modifications for nds32 target.
Hi, This patch consists of testsuite changes, including skip cases, expected fail cases, and __nds32__ specific cases. In additon, we also add checking in lib/target-supports.exp because profiling is not available for nds32*-*-elf target. gcc/testsuite/ 2013-07-08 Chung-Ju Wu Shiva Chen * g++.dg/other/PR23205.C: Skip for nds32*-*-*. * g++.dg/other/pr23205-2.C: Skip for nds32*-*-*. * gcc.dg/20020312-2.c: Add __nds32__ case. * gcc.dg/builtin-apply2.c: Skip for nds32*-*-*. * gcc.dg/lower-subreg-1.c: Skip for nds32*-*-*. * gcc.dg/sibcall-3.c: Expected fail for nds32*-*-*. * gcc.dg/sibcall-4.c: Expected fail for nds32*-*-*. * gcc.dg/stack-usage-1.c (SIZE): Define case for __nds32__. * gcc.dg/torture/pr37868.c: Skip for nds32*-*-*. * gcc.dg/torture/stackalign/builtin-apply-2.c: Skip for nds32*-*-*. * gcc.dg/tree-ssa/20040204-1.c: Expected fail for nds32*-*-*. * gcc.dg/tree-ssa/forwprop-28.c: Skip for nds32*-*-*. * gcc.dg/tree-ssa/pr42585.c: Skip for nds32*-*-*. * gcc.dg/tree-ssa/sra-12.c: Skip for nds32*-*-*. * gcc.dg/ucnid-11.c: Skip for nds32*-*-*. * gcc.dg/ucnid-2.c: Skip for nds32*-*-*. * gcc.dg/ucnid-3.c: Skip for nds32*-*-*. * lib/target-supports.exp (check_profiling_available): Check for nds32*-*-elf. 4-nds32-testsuite.patch Description: Binary data
[PATCH 1/6] Andes nds32: configure settings for nds32 target.
Hi, This patch consists of the nds32 specific settings for configure process. Because there are two kinds of libgcc support (newlib/mculib) in nds32 target, we add --with-nds32-lib option in gcc/config.gcc and libgcc/config.host. The nds32*|nds32le*|nds32be* recognition in config.sub has already been applied previously: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01125.html contrib/ 2013-07-08 Chung-Ju Wu Shiva Chen * config-list.mk (nds32le-elf, nds32be-elf): Add nds32 target. gcc/ 2013-07-08 Chung-Ju Wu Shiva Chen * config.gcc (nds32*-*-*): Add nds32 target. libgcc/ 2013-07-08 Chung-Ju Wu Shiva Chen * config.host (nds32*-elf*): Add nds32 target. 1-nds32-config.patch Description: Binary data
Re: [Ping^2] [Patch, AArch64, ILP32] 3/5 Minor change in function.c:assign_parm_find_data_types()
Ping^2~ Thanks, Yufeng On 07/02/13 23:44, Yufeng Zhang wrote: Ping~ Can I get an OK please if there is no objection? Regards, Yufeng On 06/26/13 23:39, Yufeng Zhang wrote: This patch updates assign_parm_find_data_types to assign passed_mode and nominal_mode with the mode of the built pointer type instead of the hard-coded Pmode in the case of pass-by-reference. This is in line with the assignment to passed_mode and nominal_mode in other cases inside the function. assign_parm_find_data_types generally uses TYPE_MODE to calculate passed_mode and nominal_mode: /* Find mode of arg as it is passed, and mode of arg as it should be during execution of this function. */ passed_mode = TYPE_MODE (passed_type); nominal_mode = TYPE_MODE (nominal_type); this includes the case when the passed argument is a pointer by itself. However there is a discrepancy when it deals with argument passed by invisible reference; it builds the argument's corresponding pointer type, but sets passed_mode and nominal_mode with Pmode directly. This is OK for targets where Pmode == ptr_mode, but on AArch64 with ILP32 they are different with Pmode as DImode and ptr_mode as SImode. When such a reference is passed on stack, the reference is prepared by the caller in the lower 4 bytes of an 8-byte slot but is fetched by the callee as an 8-byte datum, of which the higher 4 bytes may contain junk. It is probably the combination of Pmode != ptr_mode and the particular ABI specification that make the AArch64 ILP32 the first target on which the issue manifests itself. Bootstrapped on x86_64-none-linux-gnu. OK for the trunk? Thanks, Yufeng gcc/ * function.c (assign_parm_find_data_types): Set passed_mode and nominal_mode to the TYPE_MODE of nominal_type for the built pointer type in case of the struct-pass-by-reference.
[Committed] S/390: Use macros for the FPR register numbers in the backend
Hi,
the attached patch adds F0_REGNUM ... F15_REGNUM and uses these
throughout the s390.c file. The FPR numbering in the s390 backend is
not obvious and this hopefully makes it easier to get right for me.
Committed to mainline after regtesting on s390 and s390x.
Bye,
-Andreas-
2013-07-08 Andreas Krebbel
* config/s390/s390.c: Rename cfun_set_fpr_bit to cfun_set_fpr_save
and cfun_fpr_bit_p to cfun_fpr_save_p.
(s390_frame_area, s390_register_info, s390_frame_info)
(s390_emit_prologue, s390_emit_epilogue)
(s390_conditional_register_usage): Use the *_REGNUM macros for FPR
register numbers.
* config/s390/s390.h: Define *_REGNUM macros for floating point
register numbers.
---
gcc/config/s390/s390.c | 106 !
gcc/config/s390/s390.h | 17 +++
2 files changed, 17 insertions(+), 1 deletion(-), 105 modifications(!)
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** struct GTY(()) machine_function
*** 379,388
#define cfun_save_high_fprs_p (!!cfun_frame_layout.high_fprs)
#define cfun_gprs_save_area_size ((cfun_frame_layout.last_save_gpr_slot -
\
cfun_frame_layout.first_save_gpr_slot + 1) * UNITS_PER_LONG)
! #define cfun_set_fpr_bit(BITNUM) (cfun->machine->frame_layout.fpr_bitmap |=
\
! (1 << (BITNUM)))
! #define cfun_fpr_bit_p(BITNUM) (!!(cfun->machine->frame_layout.fpr_bitmap &
\
! (1 << (BITNUM
/* Number of GPRs and FPRs used for argument passing. */
#define GP_ARG_NUM_REG 5
--- 379,388
#define cfun_save_high_fprs_p (!!cfun_frame_layout.high_fprs)
#define cfun_gprs_save_area_size ((cfun_frame_layout.last_save_gpr_slot -
\
cfun_frame_layout.first_save_gpr_slot + 1) * UNITS_PER_LONG)
! #define cfun_set_fpr_save(REGNO) (cfun->machine->frame_layout.fpr_bitmap |=
\
! (1 << (REGNO - F0_REGNUM)))
! #define cfun_fpr_save_p(REGNO) (!!(cfun->machine->frame_layout.fpr_bitmap &
\
! (1 << (REGNO - F0_REGNUM
/* Number of GPRs and FPRs used for argument passing. */
#define GP_ARG_NUM_REG 5
*** static void
*** 7451,7457
s390_frame_area (int *area_bottom, int *area_top)
{
int b, t;
- int i;
b = INT_MAX;
t = INT_MIN;
--- 7451,7456
*** s390_frame_area (int *area_bottom, int *
*** 7472,7484
}
if (!TARGET_64BIT)
! for (i = 2; i < 4; i++)
! if (cfun_fpr_bit_p (i))
{
! b = MIN (b, cfun_frame_layout.f4_offset + (i - 2) * 8);
! t = MAX (t, cfun_frame_layout.f4_offset + (i - 1) * 8);
}
!
*area_bottom = b;
*area_top = t;
}
--- 7471,7488
}
if (!TARGET_64BIT)
! {
! if (cfun_fpr_save_p (F4_REGNUM))
{
! b = MIN (b, cfun_frame_layout.f4_offset);
! t = MAX (t, cfun_frame_layout.f4_offset + 8);
}
! if (cfun_fpr_save_p (F6_REGNUM))
! {
! b = MIN (b, cfun_frame_layout.f4_offset + 8);
! t = MAX (t, cfun_frame_layout.f4_offset + 16);
! }
! }
*area_bottom = b;
*area_top = t;
}
*** s390_register_info (int clobbered_regs[]
*** 7505,7511
cfun_frame_layout.fpr_bitmap = 0;
cfun_frame_layout.high_fprs = 0;
if (TARGET_64BIT)
! for (i = 24; i < 32; i++)
/* During reload we have to use the df_regs_ever_live infos
since reload is marking FPRs used as spill slots there as
live before actually making the code changes. Without
--- 7509,7515
cfun_frame_layout.fpr_bitmap = 0;
cfun_frame_layout.high_fprs = 0;
if (TARGET_64BIT)
! for (i = F8_REGNUM; i <= F15_REGNUM; i++)
/* During reload we have to use the df_regs_ever_live infos
since reload is marking FPRs used as spill slots there as
live before actually making the code changes. Without
*** s390_register_info (int clobbered_regs[]
*** 7517,7523
|| crtl->saves_all_registers)))
&& !global_regs[i])
{
! cfun_set_fpr_bit (i - 16);
cfun_frame_layout.high_fprs++;
}
}
--- 7521,7527
|| crtl->saves_all_registers)))
&& !global_regs[i])
{
! cfun_set_fpr_save (i);
cfun_frame_layout.high_fprs++;
}
}
*** s390_register_info (int clobbered_regs[]
*** 7644,7657
min_fpr = 0;
for (i = min_fpr; i < max_fpr; i++)
! cfun_set_fpr_bit (i);
}
}
if (!TARGET_64BIT)
! for (i = 2; i < 4; i++)
! if (df_regs_ever_live_p (i + 16) && !global_regs[i + 16])
! cfun_set_fpr_bit (i);
}
/* Fill cfun->machine with info about frame of cur
Add missing dependency for tree-ssa-reassoc.o
This is a regression from the 4.6.x series. Tested on x86_64-suse-linux, applied on all active branches as obvious. 2013-07-08 Eric Botcazou * Makefile.in (tree-ssa-reassoc.o): Add dependency on $(PARAMS_H). -- Eric BotcazouIndex: Makefile.in === --- Makefile.in (revision 200635) +++ Makefile.in (working copy) @@ -2527,7 +2527,7 @@ tree-ssa-reassoc.o : tree-ssa-reassoc.c $(TM_H) coretypes.h $(TREE_PASS_H) $(FLAGS_H) \ tree-iterator.h $(BASIC_BLOCK_H) $(GIMPLE_H) $(TREE_INLINE_H) \ $(VEC_H) langhooks.h alloc-pool.h pointer-set.h $(CFGLOOP_H) \ - $(TARGET_H) $(GIMPLE_PRETTY_PRINT_H) $(DIAGNOSTIC_CORE_H) + $(TARGET_H) $(GIMPLE_PRETTY_PRINT_H) $(DIAGNOSTIC_CORE_H) $(PARAMS_H) tree-optimize.o : tree-optimize.c $(TREE_FLOW_H) $(CONFIG_H) $(SYSTEM_H) \ $(TREE_H) $(TM_P_H) $(GGC_H) \ $(DIAGNOSTIC_H) $(BASIC_BLOCK_H) $(FLAGS_H) $(TM_H) \
Fix PR rtl-optimization/57786
As spotted by Po-Chun Chang, we can add a break in the loop dealing with the
multi-hard registers case in the REG_DEAD case of distribute_notes.
Bootstrapped/regtested on x86_64-suse-linux, applied on the mainline.
2013-07-08 Po-Chun Chang
PR rtl-optimization/57786
* combine.c (distribute_notes) : Change all_used to bool
and break out of the loop when it is set to false.
--
Eric BotcazouIndex: combine.c
===
--- combine.c (revision 200635)
+++ combine.c (working copy)
@@ -13578,14 +13578,17 @@ distribute_notes (rtx notes, rtx from_in
&& hard_regno_nregs[regno][GET_MODE (XEXP (note, 0))] > 1)
{
unsigned int endregno = END_HARD_REGNO (XEXP (note, 0));
- int all_used = 1;
+ bool all_used = true;
unsigned int i;
for (i = regno; i < endregno; i++)
if ((! refers_to_regno_p (i, i + 1, PATTERN (place), 0)
&& ! find_regno_fusage (place, USE, i))
|| dead_or_set_regno_p (place, i))
- all_used = 0;
+ {
+ all_used = false;
+ break;
+ }
if (! all_used)
{
@@ -13629,7 +13632,6 @@ distribute_notes (rtx notes, rtx from_in
break;
}
}
-
}
place = 0;
Re: [PATCH] Improve btc (PR target/57819)
> So, my first approach was trying to simplify that, because nonzero_bits > on the subreg operand say that no bits outside of QImode may be non-zero, > both the zero_extend and subreg can be dropped. That is the simplify-rtx.c > change. Then I've figured out that combine.c doesn't actually attempt to > simplify this anyway, so that is the combine.c change. And lastly an i386 > pattern was needed anyway. I've also attempted to simplify: > (zero_extend:SI (subreg:QI (and:DI (const_int 63)) 0)) > into > (subreg:SI (and:DI (const_int 63)) 0) (very small change in > simplify-rtx.c, just drop the requirement that zero_extend mode is as wide > or wider than SUBREG_REG's mode, and when it is <= use gen_lowpart_no_emit > instead of just returning the SUBREG_REG, but that unfortunately regressed > the test1 case, we'd need some further i386.md tweaks. > While in theory this folding looks like a useful simplification, because > of this I'm wondering if other backends don't rely on those actually not > being simplified. > > So, I've as an alternative implemented also an i386.md only fix. > > Thus, do we want the first patch, or first patch + also the > above described further simplify-rtx.c change + some further i386.md tweaks, > or just the second patch instead? Given the look of the pattern in the second patch, I think we definitely want to simplify upstream. The first simplification looks very natural to me, the further tweaked one less so, so let's go for the first patch alone, with a small tweak: + /* (zero_extend:M (subreg:N )) is (for M == O) or +(zero_extend:M ), if X doesn't have any bits outside of N mode +non-zero. E.g. "if X doesn't have any non-zero bits outside of mode N." -- Eric Botcazou
[Ada] Consistency of aspect / pragma retrieval by compiler client tools
This patch modifies the processing of pre- and postconditions that apply to a body that acts as a spec to provide a uniform interface for compiler client tools. The patch also augments routine Get_Pragma to retrieve delayed pragmas stored in subprogram contracts. Tested on x86_64-pc-linux-gnu, committed on trunk 2013-07-08 Hristian Kirtchev * einfo.adb (Get_Pragma): Handle the retrieval of delayed pragmas stored in N_Contract nodes. * einfo.ads (Get_Pragma): Update the comment on usage. * sem_prag.adb (Check_Precondition_Postcondition): Retain a copy of the pragma when it applies to a body that acts as a spec. The copy is preanalyzed and chained on the contract of the body. Index: einfo.adb === --- einfo.adb (revision 200711) +++ einfo.adb (working copy) @@ -6280,19 +6280,58 @@ -- Get_Pragma -- - function Get_Pragma (E : Entity_Id; Id : Pragma_Id) return Node_Id - is - N : Node_Id; + function Get_Pragma (E : Entity_Id; Id : Pragma_Id) return Node_Id is + Is_CDG : constant Boolean := + Id = Pragma_Depends or else Id = Pragma_Global; + Is_CTC : constant Boolean := + Id = Pragma_Contract_Cases or else Id = Pragma_Test_Case; + Is_PPC : constant Boolean := + Id = Pragma_Precondition or else Id = Pragma_Postcondition; + Delayed : constant Boolean := Is_CDG or else Is_CTC or else Is_PPC; + Item: Node_Id; + Items : Node_Id; begin - N := First_Rep_Item (E); - while Present (N) loop - if Nkind (N) = N_Pragma - and then Get_Pragma_Id (Pragma_Name (N)) = Id + -- Handle delayed pragmas that appear in N_Contract nodes. Those have to + -- be extracted from their specialized list. + + if Delayed then + Items := Contract (E); + + if No (Items) then +return Empty; + + elsif Is_CDG then +Item := Classifications (Items); + + elsif Is_CTC then +Item := Contract_Test_Cases (Items); + + else +Item := Pre_Post_Conditions (Items); + end if; + + -- Regular pragmas + + else + Item := First_Rep_Item (E); + end if; + + while Present (Item) loop + if Nkind (Item) = N_Pragma + and then Get_Pragma_Id (Pragma_Name (Item)) = Id then -return N; +return Item; + + -- All nodes in N_Contract are chained using Next_Pragma + + elsif Delayed then +Item := Next_Pragma (Item); + + -- Regular pragmas + else -Next_Rep_Item (N); +Next_Rep_Item (Item); end if; end loop; Index: einfo.ads === --- einfo.ads (revision 200753) +++ einfo.ads (working copy) @@ -7375,7 +7375,9 @@ function Get_Pragma (E : Entity_Id; Id : Pragma_Id) return Node_Id; -- Searches the Rep_Item chain for a given entity E, for an instance of -- a pragma with the given pragma Id. If found, the value returned is the - -- N_Pragma node, otherwise Empty is returned. + -- N_Pragma node, otherwise Empty is returned. Delayed pragmas such as + -- Precondition, Postcondition, Contract_Cases, Depends and Global appear + -- in the N_Contract node of entity E and are also handled by this routine. function Get_Record_Representation_Clause (E : Entity_Id) return Node_Id; -- Searches the Rep_Item chain for a given entity E, for a record Index: sem_prag.adb === --- sem_prag.adb(revision 200771) +++ sem_prag.adb(working copy) @@ -3565,12 +3565,13 @@ -- If we fall through loop, pragma is at start of list, so see if it -- is at the start of declarations of a subprogram body. - if Nkind (Parent (N)) = N_Subprogram_Body - and then List_Containing (N) = Declarations (Parent (N)) + PO := Parent (N); + + if Nkind (PO) = N_Subprogram_Body + and then List_Containing (N) = Declarations (PO) then -if Operating_Mode /= Generate_Code - or else Inside_A_Generic -then +if Operating_Mode /= Generate_Code or else Inside_A_Generic then + -- Analyze pragma expression for correctness and for ASIS use Preanalyze_Assert_Expression @@ -3585,22 +3586,56 @@ end if; end if; +-- Retain a copy of the pre- or postcondition pragma for formal +-- verification purposes. The copy is needed because the pragma is +-- expanded into other constructs which are not acceptable in the +-- N_Contract node. + +if Acts_As_Spec (PO) + and
[Ada] Implement new attribute Restriction_Set
This attribute allows compile time testing of restrictions that
are currently in effect. It is primarily intended for specializing
code in the run-time based on restrictions that are active (e.g.
don't need to save fpt registers if restriction No_Floating_Point
is known to be in effect), but can be used anywhere.
There are two forms:
System'Restriction_Set (partition_boolean_restriction_NAME)
System'Restriction_Set (No_Dependence => library_unit_NAME);
In the case of the first form, the only restriction names
allowed are parameterless restrictions that are checked
for consistency at bind time. For a complete list see the
subtype System.Rident.Partition_Boolean_Restrictions.
The result returned is True if the restriction is known to
be in effect, and False if the restriction is known not to
be in effect. An important guarantee is that the value of
a Restriction_Set attribute is known to be consistent throughout
all the code of a partition.
This is trivially achieved if the entire partition is compiled
with a consistent set of restriction pragmas. However, the
compilation model does not require this. It is possible to
compile one set of units with one set of pragmas, and another
set of units with another set of pragmas. It is even possible
to compile a spec with one set of pragmas, and then WITH the
same spec with a different set of pragmas. Inconsistencies
in the actual use of the restriction are checked at bind time.
In order to achieve the guarantee of consistency for the
Restriction_Set pragma, we consider that a use of the pragma
that yields False is equivalent to a violation of the
restriction.
So for example if you write
if System'Restriction_Set (No_Floating_Point) then
...
else
...
end if;
And the result is False, so that the else branch is executed,
you can assume that this restriction is not set for any unit
in the partition. This is checked by considering this use of
the restriction pragma to be a violation of the restriction
No_Floating_Point. This means that no other unit can attempt
to set this restriction (if some unit does attempt to set it,
the binder will refuse to bind the partition).
Technical note: The restriction name and the unit name are
intepreted entirely syntactically, as in the corresponding
Restrictions pragma, they are not analyzed semantically,
so they do not have a type.
Notes:
We abandoned the three state model (known_set, known_not_set,
unknown) since it is just too difficult to reason about. It
does allow more flexibility, but our discussions indicated
that this flexibility was not worth the complexity.
We abandoned the requirement for WITHing System'Restrictions.
We no longer need it for the result, and it seems fine since
this is our own attribute to intepret the restriction names
purely syntactically.
We allow only the restrictions that are checked by the binder,
because those are the only ones for which we can make the
important guarantee of consistent evaluation throughout
the partition.
The following program compiles with the indicated errors
using the switch -gnatq:
1. with System;
2. package RSetBad is
3.X1 : Boolean := Standard'Restriction_Set (No_IO); -- ERR
|
>>> prefix of "Restriction_Set" attribute must be System
4.X2 : Boolean := System'Restriction_Set (No_IO); -- OK
5.X3 : Boolean := System'Restriction_Set (SPARK_05);-- ERR
|
>>> "SPARK_05" is not a boolean partition-wide restriction
6.X4 : Boolean := System'Restriction_Set ("No_IO"); -- ERR
|
>>> attribute "Restriction_Set" requires restriction identifier
7.X5 : Boolean := System'Restriction_Set (RSetBad); -- ERR
|
>>> invalid restriction identifier "RSetBad"
8.X6 : Boolean := System'Restriction_Set
9. (No_Dependence => Ada.Text_IO); -- OK
10.X7 : Boolean := System'Restriction_Set
11. (No_Dependence => "Ada.Text_IO"); -- ERR
|
>>> name expected
>>> wrong form for unit name for No_Dependence
12.X8 : Boolean := System'Restriction_Set
13. (No_IO => Ada.Text_IO); -- ERR
1 2
>>> named parameters not permitted for attributes
>>> attribute "Restriction_Set" requires restriction identifier
14. end;
The following program compiles without errors, and the resulting
binder files do not mention Calendar.
1. pragma Restrictions (No_Delay);
2. pragma Restrictions (No_Dependence => Ada.Text_IO);
3. with System;
4. with GNAT.IO; use GNAT.IO;
5. procedure RSetGood is
6. begin
7. if System'Restriction_Set (No_Floati
[Ada] Type conformance for access_to_subprogram types
Two anonymous_access_to_subprograsm types are type conformant if the designated type of one is protected and the other is not. Convention of the designated types only matters when checking subtype conformance. Previous to this patch, the compiler failed to recognize that the following declarations are illegal homonyms: --- package P is function F return access procedure (I : Integer); function F return access protected procedure (I : Integer); end P; --- Compiling the above with -gnatc must yield: p.ads:4:13: "F" conflicts with declaration at line 3 Tested on x86_64-pc-linux-gnu, committed on trunk 2013-07-08 Ed Schonberg * sem_ch6.adb (Conforming_Types): Anonymous_access_to_subprograsm types are type conformant if the designated type of one is protected and the other is not. Convention only matters when checking subtype conformance. Index: sem_ch6.adb === --- sem_ch6.adb (revision 200688) +++ sem_ch6.adb (working copy) @@ -2789,11 +2789,11 @@ and then (Nkind (Original_Node (Spec_Decl)) = N_Subprogram_Renaming_Declaration - or else (Present (Corresponding_Body (Spec_Decl)) - and then - Nkind (Unit_Declaration_Node -(Corresponding_Body (Spec_Decl))) = - N_Subprogram_Renaming_Declaration)) + or else (Present (Corresponding_Body (Spec_Decl)) +and then + Nkind (Unit_Declaration_Node + (Corresponding_Body (Spec_Decl))) = + N_Subprogram_Renaming_Declaration)) then Conformant := True; @@ -7663,13 +7663,16 @@ end if; -- Ada 2005 (AI-254): Anonymous access-to-subprogram types must be - -- treated recursively because they carry a signature. + -- treated recursively because they carry a signature. As far as + -- conformance is concerned, convention plays no role, and either + -- or both could be access to protected subprograms. Are_Anonymous_Access_To_Subprogram_Types := -Ekind (Type_1) = Ekind (Type_2) +Ekind_In (Type_1, E_Anonymous_Access_Subprogram_Type, + E_Anonymous_Access_Protected_Subprogram_Type) and then -Ekind_In (Type_1, E_Anonymous_Access_Subprogram_Type, - E_Anonymous_Access_Protected_Subprogram_Type); +Ekind_In (Type_2, E_Anonymous_Access_Subprogram_Type, + E_Anonymous_Access_Protected_Subprogram_Type); -- Test anonymous access type case. For this case, static subtype -- matching is required for mode conformance (RM 6.3.1(15)). We check
[Ada] Allow pragma Partition_Elaboration_Policy in system.ads
This patch allows pragma Partition_Elaboration_Policy to be recognized
in system.ads in a manner analogous to the other Policy pragmas.
Given a version of System to which the line
pragma Partition_Elaboration_Policy (Sequential);
has been added, compilation of the following program
with switch -gnatj60 yields the result:
1. pragma Partition_Elaboration_Policy (Concurrent);
|
>>> partition elaboration policy incompatible with
policy in package System
2. package pelab is end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Robert Dewar
* targparm.adb (Get_Target_Parameters): Recognize pragma
Partition_Elaboration_Policy.
Index: targparm.adb
===
--- targparm.adb(revision 200688)
+++ targparm.adb(working copy)
@@ -388,6 +388,16 @@
Opt.Init_Or_Norm_Scalars := True;
goto Line_Loop_Continue;
+ -- Partition_Elaboration_Policy
+
+ elsif System_Text (P .. P + 36) =
+ "pragma Partition_Elaboration_Policy ("
+ then
+P := P + 37;
+Opt.Partition_Elaboration_Policy := System_Text (P);
+Opt.Partition_Elaboration_Policy_Sloc := System_Location;
+goto Line_Loop_Continue;
+
-- Polling (On)
elsif System_Text (P .. P + 19) = "pragma Polling (On);" then
[Ada] Allow ! and !! insertions anywhere in compiler message
This patch relaxes the restriction that ! and !! must appear at the end
of a compiler message. They can now appear anywhere. This is only an
internal implementation change with no functional effect, so no test.
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Robert Dewar
* errout.adb (Set_Msg_Txt): No longer sets Is_Style_Msg,
Is_Warning_Msg, or Is_Unconditional_Msg (all are set elsewhere
now).
* errout.ads: Insertions ! and !! no longer have to be at the
end of the message, they can be anywhere in the message.
* erroutc.adb (Test_Style_Warning_Serious_Unconditional_Msg):
Replaces Test_Style_Warning_Serious_Msg
* erroutc.ads (Has_Double_Exclam): New flag New comments for
existing flags (Test_Style_Warning_Serious_Unconditional_Msg):
Replaces Test_Style_Warning_Serious_Msg
* errutil.adb (Test_Style_Warning_Serious_Unconditional_Msg):
Replaces Test_Style_Warning_Serious_Msg
Index: errout.adb
===
--- errout.adb (revision 200688)
+++ errout.adb (working copy)
@@ -153,8 +153,7 @@
-- be one of the special insertion characters (see documentation in spec).
-- Flag is the location at which the error is to be posted, which is used
-- to determine whether or not the # insertion needs a file name. The
- -- variables Msg_Buffer, Msglen, Is_Style_Msg, Is_Warning_Msg, and
- -- Is_Unconditional_Msg are set on return.
+ -- variables Msg_Buffer are set on return Msglen.
procedure Set_Posted (N : Node_Id);
-- Sets the Error_Posted flag on the given node, and all its parents
@@ -283,7 +282,7 @@
-- Start of processing for new message
Sindex := Get_Source_File_Index (Flag_Location);
- Test_Style_Warning_Serious_Msg (Msg);
+ Test_Style_Warning_Serious_Unconditional_Msg (Msg);
Orig_Loc := Original_Location (Flag_Location);
-- If the current location is in an instantiation, the issue arises of
@@ -726,7 +725,7 @@
if Suppress_Message
and then not All_Errors_Mode
and then not Is_Warning_Msg
-and then Msg (Msg'Last) /= '!'
+and then not Is_Unconditional_Msg
then
if not Continuation then
Last_Killed := True;
@@ -787,9 +786,9 @@
elsif Debug_Flag_GG then
null;
- -- Keep warning if message text ends in !!
+ -- Keep warning if message text contains !!
- elsif Msg (Msg'Last) = '!' and then Msg (Msg'Last - 1) = '!' then
+ elsif Has_Double_Exclam then
null;
-- Here is where we delete a warning from a with'ed unit
@@ -1123,7 +1122,7 @@
return;
end if;
- Test_Style_Warning_Serious_Msg (Msg);
+ Test_Style_Warning_Serious_Unconditional_Msg (Msg);
-- Special handling for warning messages
@@ -1163,7 +1162,7 @@
-- Test for message to be output
if All_Errors_Mode
-or else Msg (Msg'Last) = '!'
+or else Is_Unconditional_Msg
or else Is_Warning_Msg
or else OK_Node (N)
or else (Msg (Msg'First) = '\' and then not Last_Killed)
@@ -2711,7 +2710,6 @@
begin
Manual_Quote_Mode := False;
- Is_Unconditional_Msg := False;
Msglen := 0;
Flag_Source := Get_Source_File_Index (Flag);
@@ -2776,7 +2774,7 @@
Set_Msg_Char ('"');
when '!' =>
- Is_Unconditional_Msg := True;
+ null; -- already dealt with
when '?' =>
Set_Msg_Insertion_Warning;
Index: errout.ads
===
--- errout.ads (revision 200688)
+++ errout.ads (working copy)
@@ -101,10 +101,9 @@
--messages. Warning messages are only suppressed for case 1, and
--when they come from other than the main extended unit.
- -- This normal suppression action may be overridden in cases 2-5 (but not
- -- in case 1) by setting All_Errors mode, or by setting the special
- -- unconditional message insertion character (!) at the end of the message
- -- text as described below.
+ -- This normal suppression action may be overridden in cases 2-5 (but
+ -- not in case 1) by setting All_Errors mode, or by setting the special
+ -- unconditional message insertion character (!) as described below.
-
-- Error Message Text and Message Insertion Characters --
@@ -230,7 +229,7 @@
-- name is defined, this insertion character has no effect.
--Insertion character ! (Exclamation: unconditional message)
- -- The character ! appearing as the last character of a message makes
+ -- The character ! appearing anywhere in the text of a message makes
-- the message unconditional which means that it is output even
[Ada] Make sure hides works with SPARK and SPARK_05
This is a followup patch that ensures that the hides directives
work with both SPARK_05 and the obsolete synonym SPARK (the latter
was broken by the previous patch).
The following programs compile as shown:
1. pragma Restrictions (SPARK);
|
>>> warning: restriction identifier "Spark" is obsolescent
>>> warning: use restriction identifier "Spark_05" instead
2. procedure SparkRes1a (X : Integer) is
3.--# hide SparkRes1a
4.subtype R is Integer range 1 .. X;
5. begin
6.null;
7. end SparkRes1a;
1. pragma Restrictions (SPARK_05);
2. procedure SparkRes2a (X : Integer) is
3. --# hide SparkRes2a;
4.subtype R is Integer range 1 .. X;
5. begin
6.null;
7. end SparkRes2a;
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Robert Dewar
* par-prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Recognize SPARK_05 as synonym for SPARK in restrictions pragma.
* restrict.ads, restrict.adb (SPARK_Hides): Table moved to body, only
referenced there.
* scng.adb, sem_ch3.adb, sem_ch4.adb, sem_ch5.adb, sem_ch8.adb,
sem_res.adb, sem_util.adb: Use restriction SPARK_05 instead of SPARK.
* snames.ads-tmpl (Name_No_Obsolescent_Features): New entry.
Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 200705)
+++ sem_ch3.adb (working copy)
@@ -2077,7 +2077,7 @@
-- Start of processing for Analyze_Declarations
begin
- if Restriction_Check_Required (SPARK) then
+ if Restriction_Check_Required (SPARK_05) then
Check_Later_Vs_Basic_Declarations (L, During_Parsing => False);
end if;
@@ -3242,7 +3242,7 @@
-- Only call test if needed
- and then Restriction_Check_Required (SPARK)
+ and then Restriction_Check_Required (SPARK_05)
and then not Is_SPARK_Initialization_Expr (E)
then
Check_SPARK_Restriction
Index: sem_ch5.adb
===
--- sem_ch5.adb (revision 200688)
+++ sem_ch5.adb (working copy)
@@ -2867,7 +2867,7 @@
-- we are in formal mode where goto statements are not allowed.
if Nkind (Nxt) = N_Label
- and then not Restriction_Check_Required (SPARK)
+ and then not Restriction_Check_Required (SPARK_05)
then
return;
@@ -2924,7 +2924,7 @@
-- Now issue the warning (or error in formal mode)
- if Restriction_Check_Required (SPARK) then
+ if Restriction_Check_Required (SPARK_05) then
Check_SPARK_Restriction
("unreachable code is not allowed", Error_Node);
else
Index: scng.adb
===
--- scng.adb(revision 200688)
+++ scng.adb(working copy)
@@ -6,7 +6,7 @@
-- --
-- B o d y --
-- --
--- Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+-- Copyright (C) 1992-2013, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@@ -1796,7 +1796,7 @@
-- If the SPARK restriction is set for this unit, then generate
-- a token Tok_SPARK_Hide for a SPARK HIDE directive.
- if Restriction_Check_Required (SPARK)
+ if Restriction_Check_Required (SPARK_05)
and then Source (Start_Of_Comment) = '#'
then
declare
Index: sem_util.adb
===
--- sem_util.adb(revision 200756)
+++ sem_util.adb(working copy)
@@ -4582,7 +4582,7 @@
-- Declaring a homonym is not allowed in SPARK ...
if Present (C)
-and then Restriction_Check_Required (SPARK)
+and then Restriction_Check_Required (SPARK_05)
then
declare
Enclosing_Subp : constant Node_Id := Enclosing_Subprogram (Def_Id);
@@ -12982,7 +12982,7 @@
-- subprogram bodies. Detect those cases by testing whether
-- Process_End_Label was called for a body (Typ = 't') or a package.
- if Restriction_Check_Required (SPARK)
+ if Restriction_Check_Required (SPARK_05)
and then (Typ = 't' or else Ekind (Ent) = E_Package)
then
Error_Msg_Node_1 := Endl;
[Ada] Restriction SPARK replaced by SPARK_05
The restriction SPARK is replaced by SPARK_05 (since this restriction
is specifically about violating rules of SPARK 2005). The restriction
SPARK is retained for backward compatibility, but will generate a
warning that it is obsolescent if it is used.
The following program compiles giving the expected violation msg:
1. pragma Restrictions (SPARK_05);
2. procedure SparkRes2 (X : Integer) is
3.subtype R is Integer range 1 .. X;
|
>>> violation of restriction "SPARK_05" at line 1
>>> range should be static
4. begin
5.null;
6. end SparkRes2;
and this program compiles showing the additional warning from using
the obsolete form:
1. pragma Restrictions (SPARK);
|
>>> warning: restriction identifier "Spark" is obsolescent
>>> warning: use restriction identifier "Spark_05" instead
2. procedure SparkRes1 (X : Integer) is
3.subtype R is Integer range 1 .. X;
|
>>> violation of restriction "SPARK_05" at line 1
>>> range should be static
4. begin
5.null;
6. end SparkRes1;
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Robert Dewar
* gnat_rm.texi: Document SPARK_05 (replaces SPARK) Document
obsolete recognition of SPARK Document all other obsolete synonyms
for old restrictions.
* restrict.adb (Check_SPARK_Restriction): SPARK_05 replaces
SPARK (Process_Restriction_Synonyms): Handle SPARK as synonym
for SPARK_05.
* restrict.ads: Restriction SPARK_05 replaces SPARK.
* s-rident.ads: Replace restriction SPARK by SPARK_05 Add SPARK
as synonym for SPARK_05.
* sem_prag.adb: Minor reformatting.
* snames.ads-tmpl: Add entries for Name_SPARK and Name_SPARK_05.
Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 200762)
+++ gnat_rm.texi(working copy)
@@ -454,7 +454,7 @@
* No_Implicit_Aliasing::
* No_Obsolescent_Features::
* No_Wide_Characters::
-* SPARK::
+* SPARK_05::
The Implementation of Standard I/O
@@ -8951,6 +8951,12 @@
restriction results in the raising of Program_Error exception at the point of
the call.
+@findex Max_Entry_Queue_Depth
+The restriction @code{Max_Entry_Queue_Depth} is recognized as a
+synonym for @code{Max_Entry_Queue_Length}. This is retained for historical
+compatibility purposes (and a warning will be generated for its use if
+warnings on obsolescent features are activated).
+
@node Max_Protected_Entries
@unnumberedsubsec Max_Protected_Entries
@findex Max_Protected_Entries
@@ -9137,6 +9143,12 @@
(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
Detach_Handler, and Reference).
+@findex No_Dynamic_Interrupts
+The restriction @code{No_Dynamic_Interrupts} is recognized as a
+synonym for @code{No_Dynamic_Attachment}. This is retained for historical
+compatibility purposes (and a warning will be generated for its use if
+warnings on obsolescent features are activated).
+
@node No_Dynamic_Priorities
@unnumberedsubsec No_Dynamic_Priorities
@findex No_Dynamic_Priorities
@@ -9378,6 +9390,12 @@
are permitted and prevents keyword @code{requeue} from being used in source
code.
+@findex No_Requeue
+The restriction @code{No_Requeue} is recognized as a
+synonym for @code{No_Requeue_Statements}. This is retained for historical
+compatibility purposes (and a warning will be generated for its use if
+warnings on oNobsolescent features are activated).
+
@node No_Secondary_Stack
@unnumberedsubsec No_Secondary_Stack
@findex No_Secondary_Stack
@@ -9459,6 +9477,12 @@
[GNAT] This restriction ensures at compile time that there are no implicit or
explicit dependencies on the package @code{Ada.Task_Attributes}.
+@findex No_Task_Attributes
+The restriction @code{No_Task_Attributes} is recognized as a synonym
+for @code{No_Task_Attributes_Package}. This is retained for historical
+compatibility purposes (and a warning will be generated for its use if
+warnings on obsolescent features are activated).
+
@node No_Task_Hierarchy
@unnumberedsubsec No_Task_Hierarchy
@findex No_Task_Hierarchy
@@ -9498,6 +9522,12 @@
expressions or references to simple boolean variables defined in the private
part of the protected type. No other form of entry barriers is permitted.
+@findex Boolean_Entry_Barriers
+The restriction @code{Boolean_Entry_Barriers} is recognized as a
+synonym for @code{Simple_Barriers}. This is retained for historical
+compatibility purposes (and a warning will be generated for its use if
+warnings on obsolescent features are activated).
+
@node Static_Priorities
@unnumberedsubsec Static_Priorities
@findex Static_Priorities
@@ -9533,7 +9563,7 @@
* No_Implicit_Aliasing::
* No_Obsolescent_Features::
* No_Wide_Characters::
-* SPARK::
+* SPARK_05:
Re: [PATCH] Fix IOR RTL simplification (PR rtl-optimization/57829)
> 2013-07-05 Jakub Jelinek > > PR rtl-optimization/57829 > * simplify-rtx.c (simplify_binary_operation_1) : Ensure that > mask bits outside of mode are just sign-extension from mode to HWI. > > * gcc.c-torture/execute/pr57829.c: New test. OK everywhere, thanks. -- Eric Botcazou
[Ada] Transient controlled function results in if expressions
This patch corrects the expansion of if expressions to generate finalization
code for transient controlled function results that appear in the "then" or
"else" alternatives. The transient objects are now properly finalized after the
if expression is evaluated.
-- Source --
-- types.ads
with Ada.Finalization; use Ada.Finalization;
package Types is
type Ctrl_Typ is new Controlled with record
Id : Natural;
end record;
overriding procedure Adjust (Obj : in out Ctrl_Typ);
overriding procedure Finalize (Obj : in out Ctrl_Typ);
overriding procedure Initialize (Obj : in out Ctrl_Typ);
function Next_Id return Natural;
function Make_Ctrl return Ctrl_Typ;
function Make_Ctrl (Obj : Ctrl_Typ) return Ctrl_Typ;
end Types;
-- types.adb
with Ada.Text_IO; use Ada.Text_IO;
package body Types is
Id_Gen : Natural := 0;
overriding procedure Adjust (Obj : in out Ctrl_Typ) is
New_Id : constant Natural := Obj.Id * 10;
begin
Put_Line (" Adjust" & Obj.Id'Img & " ->" & New_Id'Img);
Obj.Id := New_Id;
end Adjust;
overriding procedure Finalize (Obj : in out Ctrl_Typ) is
begin
Put_Line (" Finalize " & Obj.Id'Img);
Obj.Id := 0;
end Finalize;
overriding procedure Initialize (Obj : in out Ctrl_Typ) is
begin
Obj.Id := Next_Id;
Put_Line (" Initialize" & Obj.Id'Img);
end Initialize;
function Make_Ctrl return Ctrl_Typ is
Result : Ctrl_Typ;
begin
return Result;
end Make_Ctrl;
function Make_Ctrl (Obj : Ctrl_Typ) return Ctrl_Typ is
begin
return Ctrl_Typ'(Controlled with Id => Obj.Id);
end Make_Ctrl;
function Next_Id return Natural is
begin
Id_Gen := Id_Gen + 1;
return Id_Gen;
end Next_Id;
end Types;
-- main.adb
with Ada.Text_IO; use Ada.Text_IO;
with Types; use Types;
procedure Main is
procedure Param (Obj : Ctrl_Typ) is
begin
Put_Line ("Param");
end Param;
Cond : Boolean := True;
Dummy : Ctrl_Typ;
begin
Put_Line ("== Assignment ==");
begin
Dummy := (if Cond then Make_Ctrl (Make_Ctrl) else Dummy);
end;
Put_Line ("== Actual parameter ==");
begin
Param (if Cond then Make_Ctrl (Make_Ctrl) else Dummy);
end;
Put_Line ("== End ==");
end Main;
-- Compilation and output --
$ gnatmake -q -gnat12 main.adb
$ ./main
Initialize 1
== Assignment ==
Initialize 2
Adjust 2 -> 20
Finalize 2
Adjust 20 -> 200
Finalize 20
Finalize 1
Adjust 200 -> 2000
Finalize 200
Finalize 20
== Actual parameter ==
Initialize 3
Adjust 3 -> 30
Finalize 3
Adjust 30 -> 300
Finalize 30
Param
Finalize 300
Finalize 30
== End ==
Finalize 2000
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Hristian Kirtchev
* exp_ch4.adb (Create_Alternative): Removed.
(Expand_N_If_Expression): Remove constant
In_Case_Or_If_Expression. Add local variable
Ptr_Typ. Inspect the "then" and "else" action lists
for transient controlled objects and generate code to
finalize them. (Is_Controlled_Function_Call): Removed.
(Process_Action): Update the comment on usage. Update the call
to Process_Transient_Object. There is no need to continue the
traversal of the object itself.
(Process_Actions): New routine.
(Process_Transient_Object): Moved to the top level of Exp_Ch4. Add
a new formal and update the related comment on usage.
* exp_util.adb (Within_Case_Or_If_Expression): Start the search
from the parent of the node.
Index: exp_util.adb
===
--- exp_util.adb(revision 200688)
+++ exp_util.adb(working copy)
@@ -8040,11 +8040,11 @@
Par : Node_Id;
begin
- -- Locate an enclosing case or if expression. Note: these constructs can
- -- get expanded into Expression_With_Actions, hence the need to test
- -- using the original node.
+ -- Locate an enclosing case or if expression. Note that these constructs
+ -- can be expanded into Expression_With_Actions, hence the test of the
+ -- original node.
- Par := N;
+ Par := Parent (N);
while Present (Par) loop
if Nkind_In (Original_Node (Par), N_Case_Expression,
N_If_Expression)
Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 200758)
+++ exp_ch4.adb (working copy)
@@ -233,6 +233,16 @@
-- simple entity, and op is a comparison operator, optimizes it into a
-- comparison of First and Last.
+ procedure Process_Transient_Object
+ (Decl : Node_Id;
+ Rel_Node : Node_Id);
+ -- Subsidiary routine to the expansion of expression_with_actions and if
+ -- expressions.
[Ada] Accessibility checks and profile Ravenscar
This patch prevents the generation of deallocation code in order to clean up an allocated object when it fails an accessibility check when profile Ravenscar is in effect. Tested on x86_64-pc-linux-gnu, committed on trunk 2013-07-08 Hristian Kirtchev * exp_ch4.adb (Apply_Accessibility_Check): Do not deallocate the object on targets that can't deallocate. Index: exp_ch4.adb === --- exp_ch4.adb (revision 200709) +++ exp_ch4.adb (working copy) @@ -751,47 +751,66 @@ Stmts := New_List; --- Create an explicit free statement to clean up the allocated --- object in case the accessibility check fails. Generate: +-- If the target does not support allocation/deallocation, simply +-- finalize the object (if applicable). Generate: ---Free (Obj_Ref); +--[Deep_]Finalize (Obj_Ref.all); -Free_Stmt := Make_Free_Statement (Loc, New_Copy (Obj_Ref)); -Set_Storage_Pool (Free_Stmt, Pool_Id); +if Restriction_Active (No_Implicit_Heap_Allocations) then + if Needs_Finalization (DesigT) then + Append_To (Stmts, +Make_Final_Call ( + Obj_Ref => +Make_Explicit_Dereference (Loc, New_Copy (Obj_Ref)), + Typ => DesigT)); + end if; -Append_To (Stmts, Free_Stmt); +-- Finalize (if applicable) and deallocate the object in case the +-- accessibility check fails. --- Finalize the object (if applicable), but wrap the call inside --- a block to ensure that the object would still be deallocated in --- case the finalization fails. Generate: +else + -- Create an explicit free statement to clean up the allocated + -- object in case the accessibility check fails. Generate: ---begin --- [Deep_]Finalize (Obj_Ref.all); ---exception --- when others => --- Free (Obj_Ref); --- raise; ---end; + --Free (Obj_Ref); -if Needs_Finalization (DesigT) then - Prepend_To (Stmts, - Make_Block_Statement (Loc, - Handled_Statement_Sequence => - Make_Handled_Sequence_Of_Statements (Loc, - Statements => New_List ( - Make_Final_Call ( - Obj_Ref => - Make_Explicit_Dereference (Loc, - Prefix => New_Copy (Obj_Ref)), - Typ => DesigT)), + Free_Stmt := Make_Free_Statement (Loc, New_Copy (Obj_Ref)); + Set_Storage_Pool (Free_Stmt, Pool_Id); - Exception_Handlers => New_List ( - Make_Exception_Handler (Loc, - Exception_Choices => New_List ( - Make_Others_Choice (Loc)), - Statements=> New_List ( - New_Copy_Tree (Free_Stmt), - Make_Raise_Statement (Loc))); + Append_To (Stmts, Free_Stmt); + + -- Finalize the object (if applicable), but wrap the call + -- inside a block to ensure that the object would still be + -- deallocated in case the finalization fails. Generate: + + --begin + -- [Deep_]Finalize (Obj_Ref.all); + --exception + -- when others => + -- Free (Obj_Ref); + -- raise; + --end; + + if Needs_Finalization (DesigT) then + Prepend_To (Stmts, +Make_Block_Statement (Loc, + Handled_Statement_Sequence => +Make_Handled_Sequence_Of_Statements (Loc, + Statements => New_List ( +Make_Final_Call ( + Obj_Ref => +Make_Explicit_Dereference (Loc, + Prefix => New_Copy (Obj_Ref)), + Typ => DesigT)), + +Exception_Handlers => New_List ( + Make_Exception_Handler (Loc, +Exception_Choices => New_List ( + Make_Others_Choice (Loc)), +Statements=> New_List ( + New_Copy_Tree (Free_Stmt), + Make_Raise_Statement (Loc))); + end if; end if; -
[Ada] The GNAT attribute 'Img can be renamed as a function.
This patch treats the GNAT-specific 'Img attribute as a callable entity which
therefore can be renamed as a function. The prefix of the attribute reference
is an object rather than a subtype, and it is not evaluated at the point of the
renaming declaration.
Executing the following :
gnatmake -q inst
inst
must yield:
12345
456
F2 = 456, Flag = TRUE
F2 = 789, Flag = FALSE
---
with Text_IO; use Text_IO;
procedure Inst is
generic
with function F return String;
procedure Gen;
procedure Gen is begin
Put_Line (F);
end Gen;
V : Integer;
procedure Inst_Img is new Gen (V'Img);
Table : array (Boolean) of Integer := (123, 456);
Flag : Boolean := False;
function F2 return String;
function F2 return String renames Table(Flag)'Img;
begin
V := 12345;
Inst_Img;
Table (False) := 789;
Flag := True;
Put_Line (Table (Flag)'Img);
Put_Line ("F2 = " & F2 & ", Flag = " & Boolean'Image (Flag));
Flag := False;
Put_Line ("F2 = " & F2 & ", Flag = " & Boolean'Image (Flag));
end Inst;
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Ed Schonberg
* sem_ch8.adb (Attribute_Renaming): Treat 'Img as an attribute
that can be renamed as a function.
Index: sem_ch8.adb
===
--- sem_ch8.adb (revision 200757)
+++ sem_ch8.adb (working copy)
@@ -3318,12 +3318,14 @@
-- This procedure is called in the context of subprogram renaming, and
-- thus the attribute must be one that is a subprogram. All of those
- -- have at least one formal parameter, with the singular exception of
- -- AST_Entry (which is a real oddity, it is odd that this can be renamed
- -- at all!)
+ -- have at least one formal parameter, with the exceptions of AST_Entry
+ -- (which is a real oddity, it is odd that this can be renamed at all!)
+ -- and the GNAT attribute 'Img, which GNAT treats as renameable.
if not Is_Non_Empty_List (Parameter_Specifications (Spec)) then
- if Aname /= Name_AST_Entry then
+ if Aname /= Name_AST_Entry
+ and then Aname /= Name_Img
+ then
Error_Msg_N
("subprogram renaming an attribute must have formals", N);
return;
@@ -3493,11 +3495,21 @@
and then Etype (Nam) /= RTE (RE_AST_Handler)
then
declare
-P : constant Entity_Id := Prefix (Nam);
+P : constant Node_Id := Prefix (Nam);
begin
-Find_Type (P);
+-- The prefix of 'Img is an object that is evaluated for
+-- each call of the function that renames it.
+if Aname = Name_Img then
+ Preanalyze_And_Resolve (P);
+
+-- For all other attribute renamings, the prefix is a subtype.
+
+else
+ Find_Type (P);
+end if;
+
if Is_Tagged_Type (Etype (P)) then
Ensure_Freeze_Node (Etype (P));
Append_Freeze_Action (Etype (P), Body_Node);
[Ada] Missing master for incomplete views
This patch fixes a compiler bug that caused the master of incomplete views to be missing, which caused a crash when allocating an object of the type, if the full type contains tasks. The following example must compile quietly: gcc -c -gnat05 lim_view_example.adb lim_view_example-child.adb limited with Lim_View_Example.Child; package Lim_View_Example is type Acc is access Child.Child_T; procedure P (X : out Acc); end Lim_View_Example; package Lim_View_Example.Child is task type Task_Type; type Child_T is record A_Task : Task_Type; end record; end Lim_View_Example.Child; with Lim_View_Example.Child; package body Lim_View_Example is procedure P (X : out Acc) is begin X := new Child.Child_T; end P; end Lim_View_Example; package body Lim_View_Example.Child is task body Task_Type is begin null; end Task_Type; end Lim_View_Example.Child; Tested on x86_64-pc-linux-gnu, committed on trunk 2013-07-08 Bob Duff * exp_ch3.adb (Build_Master): If Desig_Type is an incomplete view coming from a limited-with'ed package, use the nonlimited view in case it has tasks. Index: exp_ch3.adb === --- exp_ch3.adb (revision 200709) +++ exp_ch3.adb (working copy) @@ -4632,9 +4632,19 @@ -- procedure Build_Master (Ptr_Typ : Entity_Id) is - Desig_Typ : constant Entity_Id := Designated_Type (Ptr_Typ); + Desig_Typ : Entity_Id := Designated_Type (Ptr_Typ); begin + -- If the designated type is an incomplete view coming from a + -- limited-with'ed package, we need to use the nonlimited view in + -- case it has tasks. + + if Ekind (Desig_Typ) in Incomplete_Kind + and then Present (Non_Limited_View (Desig_Typ)) + then +Desig_Typ := Non_Limited_View (Desig_Typ); + end if; + -- Anonymous access types are created for the components of the -- record parameter for an entry declaration. No master is created -- for such a type.
[Ada] Avoid spurious error reported by the compiler
This patch modifies the approach taken by the compiler to save/restore the scope stack. The save routine now returns the list of entitites which have been temporarily removed from visibility, and that list is passed to the restore routine to restore their visibility. This approach consumes more memory than the previous approach but avoids latent problems caused by the previous approach. After this patch the following test compiles silently. package P is type Root_Type is abstract tagged limited record N : Natural; end record; type Child_Type is abstract limited new Root_Type with null record; type Interface_Type is limited interface; function F (N : Natural) return Interface_Type is abstract; end P; generic package P.Generic_Child_Package is type T is new P.Child_Type and P.Interface_Type with null record; overriding function F (N : in Natural) return T; end P.Generic_Child_Package; with P.Generic_Child_Package; package Q is package Instance_Package is new P.Generic_Child_Package; X : Instance_Package.T := Instance_Package.F (10); end Q; Command: gcc -c -gnat05 q.ads Tested on x86_64-pc-linux-gnu, committed on trunk 2013-07-08 Javier Miranda * sem_ch8.ad[sb] (Save_Scope_Stack): Modified to return the list of entities which have been temporarily removed from immediate visibility. (Restore_Scope_Stack): Modified to receive an additional parameter with the list of entities whose immediate visibility must be restored. * sem.adb (Do_Analyze): Use new version of Save_Scope_Stack/Restore_Scope_Stack * sem_ch12.adb (Inline_Instance_Body): Use new version of Save_Scope_Stack and Restore_Scope_Stack Index: sem_ch12.adb === --- sem_ch12.adb(revision 200704) +++ sem_ch12.adb(working copy) @@ -4084,6 +4084,7 @@ Use_Clauses : array (1 .. Scope_Stack_Depth) of Node_Id; Instances: array (1 .. Scope_Stack_Depth) of Entity_Id; Inner_Scopes : array (1 .. Scope_Stack_Depth) of Entity_Id; + List : Elist_Id; Num_Inner: Int := 0; N_Instances : Int := 0; S: Entity_Id; @@ -4187,7 +4188,7 @@ -- Remove entities in current scopes from visibility, so that -- instance body is compiled in a clean environment. - Save_Scope_Stack (Handle_Use => False); + List := Save_Scope_Stack (Handle_Use => False); if Is_Child_Unit (S) then @@ -4261,7 +4262,7 @@ end loop; end if; -Restore_Scope_Stack (Handle_Use => False); +Restore_Scope_Stack (List, Handle_Use => False); if Present (Curr_Scope) and then Index: sem.adb === --- sem.adb (revision 200688) +++ sem.adb (working copy) @@ -1340,8 +1340,10 @@ procedure Do_Analyze is + List : Elist_Id; + begin - Save_Scope_Stack; + List := Save_Scope_Stack; Push_Scope (Standard_Standard); Scope_Suppress := Suppress_Options; Scope_Stack.Table @@ -1362,7 +1364,7 @@ -- Then pop entry for Standard, and pop implicit types Pop_Scope; - Restore_Scope_Stack; + Restore_Scope_Stack (List); end Do_Analyze; Already_Analyzed : constant Boolean := Analyzed (Comp_Unit); Index: sem_ch8.adb === --- sem_ch8.adb (revision 200705) +++ sem_ch8.adb (working copy) @@ -7654,119 +7654,20 @@ -- Restore_Scope_Stack -- - - procedure Restore_Scope_Stack (Handle_Use : Boolean := True) is - E : Entity_Id; - S : Entity_Id; - Comp_Unit : Node_Id; - In_Child : Boolean := False; - Full_Vis : Boolean := True; - SS_Last : constant Int := Scope_Stack.Last; + procedure Restore_Scope_Stack + (List : Elist_Id; + Handle_Use : Boolean := True) + is + SS_Last : constant Int := Scope_Stack.Last; + Elmt: Elmt_Id; begin -- Restore visibility of previous scope stack, if any - for J in reverse 0 .. Scope_Stack.Last loop - exit when Scope_Stack.Table (J).Entity = Standard_Standard -or else No (Scope_Stack.Table (J).Entity); - - S := Scope_Stack.Table (J).Entity; - - if not Is_Hidden_Open_Scope (S) then - --- If the parent scope is hidden, its entities are hidden as --- well, unless the entity is the instantiation currently --- being analyzed. - -if not Is_Hidden_Open_Scope (Scope (S)) - or else not Analyzed (Parent (S)) - or else Scope (S) = Standard_Standard -then -
[Ada] Aspect / pragma SPARK_Mode
This patch removes the checks on mode duplication for the configuration form of
the pragma to keep the behavior in line with other configuration pragmas.
-- Source --
-- unit_spark_mode.ads
pragma SPARK_Mode (Auto);
pragma SPARK_Mode (On);
package Unit_SPARK_Mode is
end Unit_SPARK_Mode;
-
-- Compilation --
-
$ gcc -c unit_spark_mode.ads
Tested on x86_64-pc-linux-gnu, committed on trunk
2013-07-08 Hristian Kirtchev
* sem_prag.adb (Analyze_Pragma): Remove
variable Unit_Prag. Remove the check on duplicate mode for the
configuration form of the pragma.
(Redefinition_Error): Removed.
Index: sem_prag.adb
===
--- sem_prag.adb(revision 200752)
+++ sem_prag.adb(working copy)
@@ -16354,16 +16354,6 @@
function Get_SPARK_Mode_Name (Id : SPARK_Mode_Id) return Name_Id;
-- Convert a value of type SPARK_Mode_Id into a corresponding name
-procedure Redefinition_Error (Mode : SPARK_Mode_Id);
--- Emit an error on an attempt to redefine existing mode Mode. The
--- message is associated with the first argument of the current
--- pragma.
-
-procedure Redefinition_Error (Prag : Node_Id);
--- Emit an error on an attempt to redefine the mode of Prag. The
--- message is associated with the first argument of the current
--- pragma.
-
--
-- Chain_Pragma --
--
@@ -16474,41 +16464,14 @@
end if;
end Get_SPARK_Mode_Name;
-
--- Redefinition_Error --
-
-
-procedure Redefinition_Error (Mode : SPARK_Mode_Id) is
-begin
- Error_Msg_Name_1 := Get_SPARK_Mode_Name (Mode);
- Error_Msg_N
- ("cannot redefine 'S'P'A'R'K mode, already set to %", Arg1);
-end Redefinition_Error;
-
-
--- Redefinition_Error --
-
-
-procedure Redefinition_Error (Prag : Node_Id) is
- Mode : constant Name_Id :=
-Chars (Get_Pragma_Arg (First
- (Pragma_Argument_Associations (Prag;
-begin
- Error_Msg_Name_1 := Mode;
- Error_Msg_Sloc := Sloc (Prag);
- Error_Msg_N
- ("cannot redefine 'S'P'A'R'K mode, already set to % #", Arg1);
-end Redefinition_Error;
-
-- Local variables
-Body_Id : Entity_Id;
-Context : Node_Id;
-Mode : Name_Id;
-Mode_Id : SPARK_Mode_Id;
-Spec_Id : Entity_Id;
-Stmt : Node_Id;
-Unit_Prag : Node_Id;
+Body_Id : Entity_Id;
+Context : Node_Id;
+Mode: Name_Id;
+Mode_Id : SPARK_Mode_Id;
+Spec_Id : Entity_Id;
+Stmt: Node_Id;
-- Start of processing for SPARK_Mode
@@ -16536,39 +16499,15 @@
if No (Context) then
Check_Valid_Configuration_Pragma;
+ Global_SPARK_Mode := Mode_Id;
- -- Set the global mode
-
- if Global_SPARK_Mode = None then
- Global_SPARK_Mode := Mode_Id;
-
- -- Catch an attempt to redefine an existing global mode by
- -- using multiple configuration files.
-
- elsif Global_SPARK_Mode /= Mode_Id then
- Redefinition_Error (Global_SPARK_Mode);
- end if;
-
-- When the pragma is placed before the declaration of a unit, it
-- configures the whole unit.
elsif Nkind (Context) = N_Compilation_Unit then
Check_Valid_Configuration_Pragma;
+ Set_SPARK_Mode_Pragma (Current_Sem_Unit, N);
- Unit_Prag := SPARK_Mode_Pragma (Current_Sem_Unit);
-
- -- Set the unit mode
-
- if No (Unit_Prag) then
- Set_SPARK_Mode_Pragma (Current_Sem_Unit, N);
-
- -- Catch an attempt to redefine the unit mode by using multiple
- -- pragmas declared in the same region.
-
- else
- Redefinition_Error (Unit_Prag);
- end if;
-
-- The pragma applies to a [library unit] subprogram or package
else
