Re: [PATCH] FPU IEEE 754 for MIPS r5900
"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.
> 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.
> I didn't changed the default in config.gcc. It is still soft float,
> because floating point doesn't behave as defined by IEEE 754. I don't
> see much improvement. This is the case on the PS2 and the PS3. For
> example inf minus inf should be NaN, but on both systems it is 0.
> I tested it on r5900 and the PS3 SPU. Both calculates the same result
> despite the MODE_HAS_* implementation. This means that there is a
> patch needed in the generic part (i.e. not mips) of the GCC.
But the format doesn't have an infinity representation, does it?
The IEEE infinity encoding is instead treated as a large number.
So it sounds like a bug if GCC is treating any (r5900|spu)_single_format
value as infinity to be begin with.
> @@ -989,7 +991,7 @@
> /* True if trunc.w.s and trunc.w.d are real (not synthetic)
> instructions. Both require TARGET_HARD_FLOAT, and trunc.w.d
> also requires TARGET_DOUBLE_FLOAT. */
> -#define ISA_HAS_TRUNC_W (!ISA_MIPS1)
> +#define ISA_HAS_TRUNC_W (!ISA_MIPS1 || TARGET_MIPS5900)
>
> /* ISA includes the MIPS32r2 seb and seh instructions. */
> #define ISA_HAS_SEB_SEH ((ISA_MIPS32R2 \
This part shouldn't be necessary. The ISA_* and TARGET_MIPS* macros are
kept in sync, so it can never be the case that ISA_MIPS1 && TARGET_MIPS5900.
(E.g. -mips1 -march=r5900 is rejected.)
Thanks,
Richard
vector conditional expression with scalar arguments
Hello,
this patch lets us write (vec<0)?-1:1 without having to manually construct
a vector of 1s. It seems preferable to the hacks we can currently use,
like (vec!=vec)+1. The patch also fixes a few bugs along the way.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2013-07-07 Marc Glisse
gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1 vector
and 2 scalars. Call save_expr before building a vector.
* typeck.c (cp_build_binary_op): Check complain before complaining.
gcc/testsuite/
* g++.dg/ext/vector19.C: Adapt.
* g++.dg/ext/vector23.C: New testcase.
--
Marc GlisseIndex: testsuite/g++.dg/ext/vector19.C
===
--- testsuite/g++.dg/ext/vector19.C (revision 200742)
+++ testsuite/g++.dg/ext/vector19.C (working copy)
@@ -30,22 +30,21 @@ void i2 (vec2 *x, vec2 *y, vec2u *z)
{
*x = *y ? *x : *y;
*y = *z ? *x : *y;
}
void j (vec2 *x, vec2 *y, vec2 *z, vec *t)
{
*x = (*y < *z) ? *x : 4.2; /* { dg-error "" } */
*y = (*x < *z) ? 2.5 : *y; /* { dg-error "" } */
*t = *t ? *t : *t; /* { dg-error "" } */
- *z = (*x < *z) ? '1' : '0'; /* { dg-error "" } */
- // The last one may eventually be accepted.
+ *z = (*x < *z) ? '1' : '0';
}
template
auto k (A *a, B b) -> decltype (*a ? *a : b);
void k (...) {}
void l (vec2 *v, double x)
{
k (v, x);
Index: testsuite/g++.dg/ext/vector23.C
===
--- testsuite/g++.dg/ext/vector23.C (revision 0)
+++ testsuite/g++.dg/ext/vector23.C (revision 0)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu++1y" } */
+
+typedef long vecl __attribute__((vector_size(4*sizeof(long;
+typedef short vecs __attribute__((vector_size(8*sizeof(short;
+typedef char vecc __attribute__((vector_size(16*sizeof(char;
+
+auto f(vecl*a,float d,char i){
+ return (*a<0)?d:i;
+}
+auto g(vecs*a){
+ return (*a<0)?3LL:42UL;
+}
+auto h(vecc*a){
+ return (*a<0)?1:0.; // { dg-error "could not find a floating point type" }
+}
Property changes on: testsuite/g++.dg/ext/vector23.C
___
Added: svn:eol-style
+ native
Added: svn:keywords
+ Author Date Id Revision URL
Index: cp/typeck.c
===
--- cp/typeck.c (revision 200742)
+++ cp/typeck.c (working copy)
@@ -4528,37 +4528,52 @@ cp_build_binary_op (location_t location,
warning (OPT_Waddress, "comparison with string literal results in
unspecified behaviour");
}
if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE)
{
vector_compare:
tree intt;
if (!same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (type0),
TREE_TYPE (type1)))
{
- error_at (location, "comparing vectors with different "
- "element types");
- inform (location, "operand types are %qT and %qT", type0, type1);
+ if (complain & tf_error)
+ {
+ error_at (location, "comparing vectors with different "
+ "element types");
+ inform (location, "operand types are %qT and %qT",
+ type0, type1);
+ }
return error_mark_node;
}
if (TYPE_VECTOR_SUBPARTS (type0) != TYPE_VECTOR_SUBPARTS (type1))
{
- error_at (location, "comparing vectors with different "
- "number of elements");
- inform (location, "operand types are %qT and %qT", type0, type1);
+ if (complain & tf_error)
+ {
+ error_at (location, "comparing vectors with different "
+ "number of elements");
+ inform (location, "operand types are %qT and %qT",
+ type0, type1);
+ }
return error_mark_node;
}
/* Always construct signed integer vector type. */
intt = c_common_type_for_size (GET_MODE_BITSIZE
(TYPE_MODE (TREE_TYPE (type0))), 0);
+ if (!intt)
+ {
+ if (complain & tf_error)
+ error_at (location, "could not find an integer type "
+ "of the same size as %qT", TREE_TYPE (type0));
+ return error_mark_node;
+ }
result_type = build_opaque_vector_type (intt,
TYPE_VECTOR_SUBPARTS (type0));
converted = 1;
break;
}
build_type = boolean_type_node;
if ((code0 == INTEGER_TYPE || code0 == REAL_TYPE
|| code0 == ENUMERAL_TYPE)
&& (code1
Preserve xvalues in ?:
Hello,
this patch gets us one line closer to implementing the proper C++11
semantics for ?: (there are still quite a few missing).
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2013-07-07 Marc Glisse
PR c++/53000
gcc/cp/
* call.c (build_conditional_expr_1): Preserve xvalues.
gcc/testsuite/
* g++.dg/cpp0x/decltype17.C: Adjust.
--
Marc GlisseIndex: testsuite/g++.dg/cpp0x/decltype17.C
===
--- testsuite/g++.dg/cpp0x/decltype17.C (revision 200742)
+++ testsuite/g++.dg/cpp0x/decltype17.C (working copy)
@@ -17,13 +17,13 @@ decltype(true ? lvalueref() : lvalueref(
decltype(true ? rvalueref() : rvalueref()) h()
{}
int main()
{
if (strcmp (typeid(f).name(), "FivE") != 0)
return 1;
if (strcmp (typeid(g).name(), "FRivE") != 0)
return 2;
- if (strcmp (typeid(h).name(), "FivE") != 0)
+ if (strcmp (typeid(h).name(), "FOivE") != 0)
return 3;
}
Index: cp/call.c
===
--- cp/call.c (revision 200742)
+++ cp/call.c (working copy)
@@ -4634,24 +4634,25 @@ build_conditional_expr_1 (location_t loc
&& CLASS_TYPE_P (arg2_type)
&& cp_type_quals (arg2_type) != cp_type_quals (arg3_type))
arg2_type = arg3_type =
cp_build_qualified_type (arg2_type,
cp_type_quals (arg2_type)
| cp_type_quals (arg3_type));
}
/* [expr.cond]
- If the second and third operands are lvalues and have the same
- type, the result is of that type and is an lvalue. */
- if (real_lvalue_p (arg2)
- && real_lvalue_p (arg3)
+ If the second and third operands are glvalues of the same value
+ category and have the same type, the result is of that type and
+ value category. */
+ if (((real_lvalue_p (arg2) && real_lvalue_p (arg3))
+ || (xvalue_p (arg2) && xvalue_p (arg3)))
&& same_type_p (arg2_type, arg3_type))
{
result_type = arg2_type;
arg2 = mark_lvalue_use (arg2);
arg3 = mark_lvalue_use (arg3);
goto valid_operands;
}
/* [expr.cond]
Re: List of typos.
On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote: > I decided to grep for all the misspelled words beginning with A from > your list and fix the ones that were real errors. That took me an hour > to produce this patch. It doesn't include changes to java or fortran, > as I don't have them checked out in my tree. After a bootstrap and > another review I'm going to commit most of these as obvious, but I > don't really want to spend another ~25 hours doing the rest of the > alphabet! :) I updated my list to be less noisy. I worked how to make this more efficient. I created patch with obvious cases in hour. (only comments in c files though.) http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch This approach would benefit from scaling. I could collect sources of more projects, then fix spelling mistakes repeated thousand times at once. Also I would like to find how easily share what we train aspell for usage in hooks. My original idea was to run aspell on file containing only comment which does not work yet as I do not know how make aspell read stdin (perhaps I will write custom frontend.). As alternative I created program on https://github.com/neleai/stylepp that changes comments in c files in current subtree based on file ./dictionary (content below). Now usage is bit complicated, in subtree you want to check you need do following PATH/script/stylepp_spellcheck # collect misspells into /tmp/misspells file cp /tmp/misspells /tmp/replace aspell /tmp/replace # Now replace misspellings. PATH/bin/stylepp_make_dictionary /tmp/misspells /tmp/replace > dictionary PATH/script/stylepp_skeleton stylepp_fix_comment # now fix source tree. dictionary used is below abiove above accceptedaccepted accees access acceses accesses accesor accessor accestor accessor accidently accidentally accomodate accommodate accompagning accompanying accordinly accordingly accout account accretingaccrediting accumlator accumulator accummulatingaccumulating accummulatorsaccumulators acessableaccessible acknowledgement acknowledgment actullay actually acualactual addesses addresses additionnal additional addreses addresses addresse addressee addressibility addressability addressings addressing adjusmentadjustment adjustement adjustment adjustements adjustments aggegate aggregate agggregate aggregate aggragateaggregate aggreagate aggregate aggreate aggregate aggreggate aggregate algoritmsalgorithms algorthm algorithm aligment alignment alignement alignment alignemntalignment allcoatedallocated allocatbale allocatable allocatoor allocator alltogether altogether allways always alocatable allocatable alocationallocation alogrithmalgorithm alrady already alreadh already alredy already alsoneedsalso_needs alwayalways amendement amendment amoutamount analagousanalogous analoguous analogous analysed analyzed analyser analyzer anwayanyway apilogue epilogue appearantly apparently apperances appearances appereance appearance applytingapplying appoximately approximately appplyingapplying approprite appropriate approriate appropriate arbitary arbitrary archtiecture architecture arguements arguments arguemtnsarguments argumet argument aribtraryarbitrary arithmatic arithmetic aritmeticarithmetic arugment argument arument argument assigmentassignment assigments assignments assignemnt assignment assignmenassignment assinmentassignment associatied associated assotiated associated asssume assume assumpation assumption assumtions assumptions astericesasterisks astheticsaesthetics aswell as_well atributesattributes atrributeattribute autmatically automatically avaiable available availablity availability avoidpaste avoid_paste awrning warning barrer barrier beacuse because becaause because becacdd because becase because becasue because becauae because becaue
constexpr vector indexing
Hello,
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. The new testcase is not that useful, but I didn't
remember there was already one with dg-bogus.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2013-07-07 Marc Glisse
PR c++/53094
gcc/cp/
* semantics.c (cxx_eval_bit_field_ref): Handle VECTOR_CST.
gcc/testsuite/
* g++.dg/cpp0x/constexpr-53094-1.C: Adjust.
* g++.dg/ext/vector24.C: New testcase.
--
Marc GlisseIndex: testsuite/g++.dg/cpp0x/constexpr-53094-1.C
===
--- testsuite/g++.dg/cpp0x/constexpr-53094-1.C (revision 200742)
+++ testsuite/g++.dg/cpp0x/constexpr-53094-1.C (working copy)
@@ -1,6 +1,6 @@
// { dg-do compile }
// { dg-options "-std=gnu++11" }
typedef float __attribute__ ((vector_size (4 * sizeof (float V4;
constexpr V4 v = { 1, 1, 1, 0 };
-constexpr V4 r = v[0] + v; // { dg-bogus "not a constant expression" "" {
xfail *-*-* } }
+constexpr V4 r = v[0] + v;
Index: testsuite/g++.dg/ext/vector24.C
===
--- testsuite/g++.dg/ext/vector24.C (revision 0)
+++ testsuite/g++.dg/ext/vector24.C (revision 0)
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++11 } }
+
+typedef long vec __attribute__((vector_size(2*sizeof(long;
+constexpr vec v = { 33, 42 };
+constexpr auto l0 = v[0];
+constexpr auto l1 = v[1];
+static_assert(l0==33,"Fail");
+static_assert(l1==42,"Fail");
Property changes on: testsuite/g++.dg/ext/vector24.C
___
Added: svn:eol-style
+ native
Added: svn:keywords
+ Author Date Id Revision URL
Index: cp/semantics.c
===
--- cp/semantics.c (revision 200742)
+++ cp/semantics.c (working copy)
@@ -7179,29 +7179,35 @@ cxx_eval_bit_field_ref (const constexpr_
tree whole = cxx_eval_constant_expression (call, orig_whole,
allow_non_constant, addr,
non_constant_p, overflow_p);
tree start, field, value;
unsigned HOST_WIDE_INT i;
if (whole == orig_whole)
return t;
/* Don't VERIFY_CONSTANT here; we only want to check that we got a
CONSTRUCTOR. */
- if (!*non_constant_p && TREE_CODE (whole) != CONSTRUCTOR)
+ if (!*non_constant_p
+ && TREE_CODE (whole) != VECTOR_CST
+ && TREE_CODE (whole) != CONSTRUCTOR)
{
if (!allow_non_constant)
error ("%qE is not a constant expression", orig_whole);
*non_constant_p = true;
}
if (*non_constant_p)
return t;
+ if (TREE_CODE (whole) == VECTOR_CST)
+return fold_ternary (BIT_FIELD_REF, TREE_TYPE (t), whole,
+TREE_OPERAND (t, 1), TREE_OPERAND (t, 2));
+
start = TREE_OPERAND (t, 2);
istart = tree_low_cst (start, 0);
isize = tree_low_cst (TREE_OPERAND (t, 1), 0);
utype = TREE_TYPE (t);
if (!TYPE_UNSIGNED (utype))
utype = build_nonstandard_integer_type (TYPE_PRECISION (utype), 1);
retval = build_int_cst (utype, 0);
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (whole), i, field, value)
{
tree bitpos = bit_position (field);
[C++ Patch] PR 51786
Hi,
we got a couple of duplicates of this. The issue is that things like:
struct A {};
void foo() { decltype(A()); }
are turned by finish_decltype_type, called by
cp_parser_simple_declaration via cp_parser_decl_specifier_seq, into
something like:
struct A {};
void foo() { struct A; }
and later check_tag_decl, called via shadow_tag, doesn't see anything
wrong wrt [dcl.dcl]/3, to wit doesn't see a declaration which doesn't
declare anything. "Luckily" we have declares_class_or_enum available and
we can query it to figure out whether a diagnostic is in fact in order.
Tested x86_64-linux.
Thanks,
Paolo.
PS: in fact we issue a permerror, not an error: I did some tests and I
don't think that unconditionally zeroing the type even if we end up only
emitting a warning can cause problems. But please double check, thanks!
//
/cp
2013-07-07 Paolo Carlini
PR c++/51786
* parser.c (cp_parser_simple_declaration): Before calling shadow_tag
also check declares_class_or_enum.
/testsuite
2013-07-07 Paolo Carlini
PR c++/51786
* g++.dg/cpp0x/pr51786.C: New.
* g++.dg/cpp0x/auto30.C: Update.
Index: cp/parser.c
===
--- cp/parser.c (revision 200742)
+++ cp/parser.c (working copy)
@@ -11009,11 +11009,19 @@ 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 != error_mark_node)
+ /* Ensure an error is issued anyway when finish_decltype_type,
+ called via cp_parser_decl_specifier_seq, returns something
+ sensible (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/auto30.C
===
--- testsuite/g++.dg/cpp0x/auto30.C (revision 200742)
+++ testsuite/g++.dg/cpp0x/auto30.C (working copy)
@@ -6,4 +6,4 @@ struct A
auto friend struct B; // { dg-error "multiple types|can only be
specified|friend" }
};
-auto int; // { dg-error "multiple types|can only be specified for variables" }
+auto int; // { dg-error "multiple types|does not declare anything" }
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: [PATCH] FPU IEEE 754 for MIPS r5900
Hello Richard,
> Gesendet: Sonntag, 07. Juli 2013 um 10:15 Uhr
> "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. I also can't
test it, because the GCC is already not correctly working on SPU.
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.
> > 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.
> > I didn't changed the default in config.gcc. It is still soft float,
> > because floating point doesn't behave as defined by IEEE 754. I don't
> > see much improvement. This is the case on the PS2 and the PS3. For
> > example inf minus inf should be NaN, but on both systems it is 0.
> > I tested it on r5900 and the PS3 SPU. Both calculates the same result
> > despite the MODE_HAS_* implementation. This means that there is a
> > patch needed in the generic part (i.e. not mips) of the GCC.
>
> But the format doesn't have an infinity representation, does it?
It doesn't have a representation for infinity, the calculation returns +Fmax or
-Fmax according to the manual. In my test I can see that +Fmax is 0x7fff.
> The IEEE infinity encoding is instead treated as a large number.
> So it sounds like a bug if GCC is treating any (r5900|spu)_single_format
> value as infinity to be begin with.
>
> > @@ -989,7 +991,7 @@
> > /* True if trunc.w.s and trunc.w.d are real (not synthetic)
> > instructions. Both require TARGET_HARD_FLOAT, and trunc.w.d
> > also requires TARGET_DOUBLE_FLOAT. */
> > -#define ISA_HAS_TRUNC_W(!ISA_MIPS1)
> > +#define ISA_HAS_TRUNC_W(!ISA_MIPS1 || TARGET_MIPS5900)
> >
> > /* ISA includes the MIPS32r2 seb and seh instructions. */
> > #define ISA_HAS_SEB_SEH((ISA_MIPS32R2 \
>
> This part shouldn't be necessary. The ISA_* and TARGET_MIPS* macros are
> kept in sync, so it can never be the case that ISA_MIPS1 && TARGET_MIPS5900.
> (E.g. -mips1 -march=r5900 is rejected.)
OK, I tested it again. You are right, it is working without this part of the
patch.
Best regards
Jürgen
Re: List of typos.
On 7 July 2013 15:21, Ondřej Bílka wrote: > > I worked how to make this more efficient. I created patch with obvious cases > in hour. (only comments in c files though.) > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch Some of the code fixed by that (boehm-gc, zlib, libsanitizer) is maintained outside GCC so your patches should go upstream. I'll apply some of the other fixes though, thanks for the patch.
Re: List of typos.
On 7 July 2013 15:21, Ondřej Bílka wrote: > > discontiguousdiscontinuous This one is incorrect - the libstdc++ header is talking about contiguous memory, not continuous memory (arguably it should be non-contiguous, but leaving it alone is better than changing it to discontinuous.)
Re: List of typos.
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):
- /* 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.
- Roger Sayle <...@eyesopen.com>
+ Roger Sayle <...@eyes open.com>
Don't change email addresses!
Johann
Re: Aw: Re: [PATCH] FPU IEEE 754 for MIPS r5900
"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.
> I also can't test it, because the GCC is already not correctly working
> on SPU.
Can you give an example?
> 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?
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.
>> > 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.
>> > I didn't changed the default in config.gcc. It is still soft float,
>> > because floating point doesn't behave as defined by IEEE 754. I don't
>> > see much improvement. This is the case on the PS2 and the PS3. For
>> > example inf minus inf should be NaN, but on both systems it is 0.
>> > I tested it on r5900 and the PS3 SPU. Both calculates the same result
>> > despite the MODE_HAS_* implementation. This means that there is a
>> > patch needed in the generic part (i.e. not mips) of the GCC.
>>
>> But the format doesn't have an infinity representation, does it?
>
> It doesn't have a representation for infinity, the calculation returns
> +Fmax or -Fmax according to the manual. In my test I can see that +Fmax
> is 0x7fff.
Right, that was my point:
>> The IEEE infinity encoding is instead treated as a large number.
>> So it sounds like a bug if GCC is treating any (r5900|spu)_single_format
>> value as infinity to be begin with.
You were saying that GCC produces the wrong result for "inf minus inf".
But you can't even do that calculation on r5900 floats, because there's
no infinity representation to begin with. Maybe it's just semantics,
but it sounded like the bug was that we assumed r5900 had inf in the
first place, not that "inf - inf" produced the wrong result.
Thanks,
Richard
[PATCH, i386]: Fix cache detection for -march=native
Hello!
I didn't notice that TM2 target has the same ebx signature as Intel
target, so detect_caches_amd was also used for Intel processors.
Attached patch fixes this problem by removing Transmeta signature.
2013-07-07 Uros Bizjak
* config/i386/driver-i386.c (host_detect_local_cpu): Do not check
signature_TM2_ebx, it interferes with signature_INTEL_ebx.
Tested on x86_64-pc-linux-gnu and committed to mainline SVN.
Uros.
Index: config/i386/driver-i386.c
===
--- config/i386/driver-i386.c (revision 200743)
+++ config/i386/driver-i386.c (working copy)
@@ -520,8 +520,7 @@ const char *host_detect_local_cpu (int argc, const
if (vendor == signature_AMD_ebx
|| vendor == signature_CENTAUR_ebx
|| vendor == signature_CYRIX_ebx
- || vendor == signature_NSC_ebx
- || vendor == signature_TM2_ebx)
+ || vendor == signature_NSC_ebx)
cache = detect_caches_amd (ext_level);
else if (vendor == signature_INTEL_ebx)
{
Re: List of typos.
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
>
Below are some other hunks that look suspicious...
(trying not to duplicate the things already mentioned by others)
- * 1) It means that finalizers, and all methods calle by them,
+ * 1) It means that finalizers, and all methods callee by them,
-> 'called'
- /* SET_ACCESS, we want to set an explicte set of permissions, do not
+ /* SET_ACCESS, we want to set an explicate set of permissions, do not
-> 'explicit'
In Objective-C, there are two additional variants:
foreach-statement:
- for ( expression in expresssion ) statement
+ for ( expression in expressions ) statement
for ( declaration in expression ) statement
Really? I'm not so sure.
- configury */
+ configure */
-> 'configury'
- calll#gettlsoff(ADDR)@(gr8, gr0)
+ call#gettlsoff(ADDR)@(gr8, gr0)
- calll #gettlsoff(ADDR)@(gr8, gr0)
+ call #gettlsoff(ADDR)@(gr8, gr0)
The original 'calll' is correct (see frv.md).
- have the same priority - candidate is best if its dependees were
+ have the same priority - candidate is best if its dependencies were
-> 'dependees'
- does not look at other present displacement addressings around it.
+ does not look at other present displacement addressing around it.
-> 'addressings' (as in addressing modes)
- CM_SMALL,/* Makes various assumpation about sizes of code and
+ CM_SMALL,/* Makes various assumption about sizes of code and
- CM_SMALL_PIC,/* Makes various assumpation about sizes of code and
+ CM_SMALL_PIC,/* Makes various assumption about sizes of code and
-> 'assumptions'
/* If we had fewer function args than explicit template args,
- just use the explicits. */
+ just use the explicit. */
-> 'explicit ones'
-array reference if the where and elswhere destinations
+array reference if the where and Elsinore destinations
-> 'elsewhere'
- We provide accestor to the inline_summary datastructure and
+ We provide accessor to the inline_summary datastructure and
-> probably 'ancestor'
-/* The array used to find duplications in conflict vectors of
+/* The array used to find duplication in conflict vectors of
-/* Remove duplications in conflict vector of OBJ. */
+/* Remove duplication in conflict vector of OBJ. */
-/* Process operator duplications in insn with ID. We do it after the
+/* Process operator duplication in insn with ID. We do it after the
-> 'duplicates' maybe?
- function we iterate decompressions until no data remains. */
+ function we iterate decompression's until no data remains. */
-> 'decompressions'
- TODO: Make into some kind of configury-generated table. */
+ TODO: Make into some kind of configure-generated table. */
-> 'configury-generated'
-point of view as prefetch withouth dependecies will have a
+point of view as prefetch withouth dependencies will have a
-> missed 'without'
- * Unique vinsn derivates from CALL, ASM, JUMP (for a while) and other
+ * Unique vinsn derivatives from CALL, ASM, JUMP (for a while) and other
-> maybe 'deviates' ?
-/* Find the set of registers that are unavailable for storing expres
+/* Find the set of registers that are unavailable for storing express
- that are not available for storing expres while moving ORIG_OPS up on the
+ that are not available for storing express while moving ORIG_OPS up on the
- /* Merge c_expres found or unify live register sets from different
+ /* Merge c_express found or unify live register sets from different
-> maybe 'expression' ?
-/* { dg-final { scan-assembler "calll.*#gettlsoff\\(0\\)" } } */
+/* { dg-final { scan-assembler "call.*#gettlsoff\\(0\\)" } } */
-> see above for the 'calll' frv case. This breaks the test case.
Do not change things inside /* { } */ comments in test cases.
-/* PR target/50749: Verify that subsequent post-increment addressings
+/* PR target/50749: Verify that subsequent post-increment addressing
-/* PR target/50749: Verify that subsequent pre-decrement addressings
+/* PR target/50749: Verify that subsequent pre-decrement addressing
-/* PR target/50749: Verify that subsequent post-increment addressings
+/* PR target/50749: Verify that subsequent post-increment addressing
-/* PR target/50749: Verify that subsequent pre-decrement addressings
+/* PR target/50749: Verify that subsequent pre-decrement addressing
-> 'addressings' (as in addressing modes)
- /* For buitins that are likely expanded to nothing or
+ /* For builtin's that are likely expanded to nothing or
-> 'builtins'
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.
Re: constexpr vector indexing
On Sun, Jul 7, 2013 at 10:54 AM, Marc Glisse wrote:
> Hello,
>
> 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?),
or same_type_p.
> but none of that was necessary so I'll leave it
> for another time. The new testcase is not that useful, but I didn't remember
> there was already one with dg-bogus.
>
>
> Bootstrap+testsuite on x86_64-unknown-linux-gnu.
>
> 2013-07-07 Marc Glisse
>
> PR c++/53094
> gcc/cp/
> * semantics.c (cxx_eval_bit_field_ref): Handle VECTOR_CST.
OK.
>
> gcc/testsuite/
> * g++.dg/cpp0x/constexpr-53094-1.C: Adjust.
> * g++.dg/ext/vector24.C: New testcase.
>
> --
> Marc Glisse
> Index: testsuite/g++.dg/cpp0x/constexpr-53094-1.C
> ===
> --- testsuite/g++.dg/cpp0x/constexpr-53094-1.C (revision 200742)
> +++ testsuite/g++.dg/cpp0x/constexpr-53094-1.C (working copy)
> @@ -1,6 +1,6 @@
> // { dg-do compile }
> // { dg-options "-std=gnu++11" }
>
> typedef float __attribute__ ((vector_size (4 * sizeof (float V4;
> constexpr V4 v = { 1, 1, 1, 0 };
> -constexpr V4 r = v[0] + v; // { dg-bogus "not a constant expression" "" {
> xfail *-*-* } }
> +constexpr V4 r = v[0] + v;
> Index: testsuite/g++.dg/ext/vector24.C
> ===
> --- testsuite/g++.dg/ext/vector24.C (revision 0)
> +++ testsuite/g++.dg/ext/vector24.C (revision 0)
> @@ -0,0 +1,8 @@
> +// { dg-do compile { target c++11 } }
> +
> +typedef long vec __attribute__((vector_size(2*sizeof(long;
> +constexpr vec v = { 33, 42 };
> +constexpr auto l0 = v[0];
> +constexpr auto l1 = v[1];
> +static_assert(l0==33,"Fail");
> +static_assert(l1==42,"Fail");
>
> Property changes on: testsuite/g++.dg/ext/vector24.C
> ___
> Added: svn:eol-style
>+ native
> Added: svn:keywords
>+ Author Date Id Revision URL
>
> Index: cp/semantics.c
> ===
> --- cp/semantics.c (revision 200742)
> +++ cp/semantics.c (working copy)
> @@ -7179,29 +7179,35 @@ cxx_eval_bit_field_ref (const constexpr_
>tree whole = cxx_eval_constant_expression (call, orig_whole,
> allow_non_constant, addr,
> non_constant_p, overflow_p);
>tree start, field, value;
>unsigned HOST_WIDE_INT i;
>
>if (whole == orig_whole)
> return t;
>/* Don't VERIFY_CONSTANT here; we only want to check that we got a
> CONSTRUCTOR. */
> - if (!*non_constant_p && TREE_CODE (whole) != CONSTRUCTOR)
> + if (!*non_constant_p
> + && TREE_CODE (whole) != VECTOR_CST
> + && TREE_CODE (whole) != CONSTRUCTOR)
> {
>if (!allow_non_constant)
> error ("%qE is not a constant expression", orig_whole);
>*non_constant_p = true;
> }
>if (*non_constant_p)
> return t;
>
> + if (TREE_CODE (whole) == VECTOR_CST)
> +return fold_ternary (BIT_FIELD_REF, TREE_TYPE (t), whole,
> +TREE_OPERAND (t, 1), TREE_OPERAND (t, 2));
> +
>start = TREE_OPERAND (t, 2);
>istart = tree_low_cst (start, 0);
>isize = tree_low_cst (TREE_OPERAND (t, 1), 0);
>utype = TREE_TYPE (t);
>if (!TYPE_UNSIGNED (utype))
> utype = build_nonstandard_integer_type (TYPE_PRECISION (utype), 1);
>retval = build_int_cst (utype, 0);
>FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (whole), i, field, value)
> {
>tree bitpos = bit_position (field);
>
Re: constexpr vector indexing
On Sun, 7 Jul 2013, Gabriel Dos Reis wrote: On Sun, Jul 7, 2013 at 10:54 AM, Marc Glisse wrote: Hello, 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?), or same_type_p. I thought of that, but it is a front-end interface, not accessible from fold-const. but none of that was necessary so I'll leave it for another time. The new testcase is not that useful, but I didn't remember there was already one with dg-bogus. Bootstrap+testsuite on x86_64-unknown-linux-gnu. 2013-07-07 Marc Glisse PR c++/53094 gcc/cp/ * semantics.c (cxx_eval_bit_field_ref): Handle VECTOR_CST. OK. Thanks. -- Marc Glisse
[PATCH] fix typos mandated by conventions.
On Sun, Jul 07, 2013 at 04:21:15PM +0200, Ondřej Bílka wrote: > On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote: > > I decided to grep for all the misspelled words beginning with A from > > your list and fix the ones that were real errors. That took me an hour > > to produce this patch. It doesn't include changes to java or fortran, > > as I don't have them checked out in my tree. After a bootstrap and > > another review I'm going to commit most of these as obvious, but I > > don't really want to spend another ~25 hours doing the rest of the > > alphabet! :) > 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 Only obvious cases are there I could add warning for cases that need decide if word is noun or adjective etc. This patch was generated by command script/stylepp_skeleton stylepp_fix_comment whose version is following https://github.com/neleai/stylepp/commit/23ddb7c5857964861abdb524971071488c1a83ba and following dictionary. 32_bit 32-bit alpha_numeric alphanumeric bitfield bit-field bit_field bit-field coldfire ColdFire Coldfire ColdFire command_line_option command-line_option enumeral enumerated epilog epilogue lower_case lowercase lower-case lowercase mips MIPS Mips MIPS non-zero nonzero non_zero nonzero Objective_C Objective-C prolog prologue powerpc PowerPC powerPC PowerPC PowerPc PowerPC Redhat Red_Hat RedHat Red_Hat sparc SPARC Sparc SPARC test_case testcase test-case testcase test_suite testsuite test-suite testsuite upper_case uppercase upper-case uppercase vax VAX Vax VAX vaxen VAXen microvax MicroWAX
Re: [PATCH, x86] Use vector moves in memmove expanding
Hello, > Yes, this patch is OK (I meant my previous mail as an approval). > There is a lot of things we can do about string operations, taking > incremental steps is good > plan. Changes were checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html Thanks, K
Re: [PATCH, x86] Use vector moves in memmove expanding
> Changes were checked into trunk: > http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html Thanks, Kirill >> There is a lot of things we can do about string operations, taking >> incremental steps is good >> plan. Then my next step will be implementation of vector_loop for memset with 0. Thanks for the feedback and review! Best regards, Michael On 8 July 2013 10:49, Kirill Yukhin wrote: > Hello, > >> Yes, this patch is OK (I meant my previous mail as an approval). >> There is a lot of things we can do about string operations, taking >> incremental steps is good >> plan. > > > Changes were checked into trunk: > http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00179.html > > Thanks, K -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
