Re: [Patch, fortran] Use BUILT_IN_IROUND
On Thu, Mar 15, 2012 at 22:28, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Thu, Mar 15, 2012 at 22:14, Tobias Burnus bur...@net-b.de wrote:
Janne Blomqvist wrote:
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
OK. Thanks for the patch! Nit: Could you check mathbuiltins.def - at least
in the diff, iround seems to be misaligned (one missing).
Ah, a tab had sneaked in, fixed. Committed the fixed patch as r185442.
Thanks for the quick review!
--
Janne Blomqvist
I realized there was a bug in the patch, and testing revealed my
suspicion as true. Namely as there is no library fallback for iround,
and the middle-end machinery takes care of converting it to lround
only for float, double, and long double, it doesn't work for
__float128. In the testcase in my original patch mail, changing x to
real(16) generated a call to iroundq, which doesn't exist. Committed
the patch below as obvious.
Index: ChangeLog
===
--- ChangeLog (revision 185452)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-03-16 Janne Blomqvist j...@gcc.gnu.org
+
+ * trans-intrinsic.c (build_round_expr): Don't use BUILT_IN_IROUND
+ for __float128.
+
2012-03-15 Janne Blomqvist j...@gcc.gnu.org
* f95-lang.c (gfc_init_builtin_functions): Initialize
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 185452)
+++ trans-intrinsic.c (working copy)
@@ -383,10 +383,11 @@ build_round_expr (tree arg, tree restype
resprec = TYPE_PRECISION (restype);
/* Depending on the type of the result, choose the int intrinsic
- (iround, available only as a builtin), long int intrinsic
(lround
- family) or long long intrinsic (llround). We might also need to
- convert the result afterwards. */
- if (resprec = INT_TYPE_SIZE)
+ (iround, available only as a builtin, therefore cannot use it
for
+ __float128), long int intrinsic (lround family) or long long
+ intrinsic (llround). We might also need to convert the result
+ afterwards. */
+ if (resprec = INT_TYPE_SIZE argprec = LONG_DOUBLE_TYPE_SIZE)
fn = builtin_decl_for_precision (BUILT_IN_IROUND, argprec);
else if (resprec = LONG_TYPE_SIZE)
fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
--
Janne Blomqvist
[VMS/committed]: Consolidate config.host VMS entries
Hi,
all the three VMS entries are consolidated into one with this patch.
Committed on trunk.
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* config.host (alpha64-dec-*vms*, alpha*-dec-*vms*)
(ia64-hp-*vms*): Replaced by ...
(*-*-*vms*): ... This new entry.
Index: gcc/config.host
===
--- gcc/config.host (revision 185454)
+++ gcc/config.host (working copy)
@@ -185,22 +185,6 @@
# Machine-specific settings.
case ${host} in
- alpha64-dec-*vms*)
-host_xm_file=vms/xm-vms.h vms/xm-vms64.h
-host_xmake_file=vms/x-vms
-host_exeext=.exe
-host_can_use_collect2=no
-prefix=/gnu
-local_prefix=/gnu/local
-;;
- alpha*-dec-*vms*)
-host_xm_file=vms/xm-vms.h
-host_xmake_file=vms/x-vms
-host_exeext=.exe
-host_can_use_collect2=no
-prefix=/gnu
-local_prefix=/gnu/local
-;;
hppa1.0-*-hpux10* | hppa1.1-*-hpux10* | hppa2*-*-hpux10*)
out_host_hook_obj=host-hpux.o
host_xmake_file=${host_xmake_file} x-hpux
@@ -262,14 +246,6 @@
out_host_hook_obj=${out_host_hook_obj} host-i386-darwin.o
host_xmake_file=${host_xmake_file} i386/x-darwin
;;
- ia64-hp-*vms*)
-host_xm_file=vms/xm-vms.h vms/xm-vms64.h
-host_xmake_file=vms/x-vms
-host_exeext=.exe
-host_can_use_collect2=no
-prefix=/gnu
-local_prefix=/gnu/local
-;;
powerpc-*-beos*)
host_can_use_collect2=no
;;
@@ -297,4 +273,10 @@
out_host_hook_obj=host-hpux.o
host_xmake_file=${host_xmake_file} x-hpux
;;
+ *-*-*vms*)
+host_xm_file=vms/xm-vms.h
+host_xmake_file=vms/x-vms
+host_exeext=.exe
+host_can_use_collect2=no
+;;
esac
[VMS/committed]: Provide C99 stdint.h
Hi,
this patch makes gcc provide the C99 compliant stdint.h header.
(required by libquadmath).
Committed on trunk.
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* config.gcc (*-*-*vms*): Define use_gcc_stdint and tm_file.
* config/vms/vms-stdint.h: New file.
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 185454)
+++ gcc/config.gcc (working copy)
@@ -740,6 +740,8 @@
xm_file=vms/xm-vms.h
c_target_objs=vms-c.o
cxx_target_objs=vms-c.o
+ use_gcc_stdint=provide
+ tm_file=${tm_file} vms/vms-stdint.h
if test x$gnu_ld != xyes; then
# Build wrappers for native case.
extra_programs=ld\$(exeext) ar\$(exeext)
Index: gcc/config/vms/vms-stdint.h
===
--- gcc/config/vms/vms-stdint.h (revision 0)
+++ gcc/config/vms/vms-stdint.h (revision 0)
@@ -0,0 +1,50 @@
+/* Definitions for stdint.h types on VMS systems.
+ Copyright (C) 2012 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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+http://www.gnu.org/licenses/. */
+
+#define SIG_ATOMIC_TYPE int
+
+#define INT8_TYPE signed char
+#define INT16_TYPE short int
+#define INT32_TYPE int
+#define INT64_TYPE long long int
+#define UINT8_TYPE unsigned char
+#define UINT16_TYPE short unsigned int
+#define UINT32_TYPE unsigned int
+#define UINT64_TYPE long long unsigned int
+
+#define INT_LEAST8_TYPE signed char
+#define INT_LEAST16_TYPE short int
+#define INT_LEAST32_TYPE int
+#define INT_LEAST64_TYPE long long int
+#define UINT_LEAST8_TYPE unsigned char
+#define UINT_LEAST16_TYPE short unsigned int
+#define UINT_LEAST32_TYPE unsigned int
+#define UINT_LEAST64_TYPE long long unsigned int
+
+#define INT_FAST8_TYPE signed char
+#define INT_FAST16_TYPE short int
+#define INT_FAST32_TYPE int
+#define INT_FAST64_TYPE long long int
+#define UINT_FAST8_TYPE unsigned char
+#define UINT_FAST16_TYPE short unsigned int
+#define UINT_FAST32_TYPE unsigned int
+#define UINT_FAST64_TYPE long long unsigned int
+
+#define INTPTR_TYPE long long int
+#define UINTPTR_TYPE long long unsigned int
Re: [doc] GCC 4.7 Solaris updates to install.texi
On Thu, 15 Mar 2012, Rainer Orth wrote:
Gerald Pfeifer ger...@pfeifer.com writes:
On Mon, 12 Mar 2012, Rainer Orth wrote:
Tested with make doc/gccinstall.info doc/gccinstall.pdf, ok for mainline
and 4.7 branch?
+Sun does not ship a C compiler with Solaris 2 before Solaris 10, though
+you can download the Sun Studio compilers for free. In Solaris 10 and
+11, GCC 3.4.3 is available in @command{/usr/sfw/bin/gcc}. Solaris 11
+also provides GCC 4.5.2 in @command{/usr/gcc/4.5/bin/gcc}. Alternatively,
I see Richi has approved, just wonder whether as @command would
be more appropriate than in @command, twice?
I think so. Ok for mainline and 4.7 branch?
Ok.
Thanks,
Richard.
Rainer
2012-03-15 Rainer Orth r...@cebitec.uni-bielefeld.de
* doc/install.texi (Specific, *-*-solaris2*): Improve wording.
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Thu, 15 Mar 2012, Eric Botcazou wrote: Computing the offset in stor-layout.c and storing it in DECL_INITIAL? Ugh. I just realized that the DECL_BIT_FIELD_REPRESENTATIVE is built during layout... but is overloaded with DECL_QUALIFIER. That's probably the source of the miscompilation I talked about earlier. But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is unused. Can we delay it until after gimplification ? Then we could use DECL_INITIAL. No, I don't think so. We can store the bit-offset relative to the start of the group in tree_base.address_space (ugh), if 8 bits are enough for that (ugh). For now giving up seems to be easiest (just give up when DECL_FIELD_OFFSET is not equal for all of the bitfield members). That will at most get you the miscompiles for the PRs back, for languages with funny structure layout. Well. I'll think about this some more and in the meantime install the fix for the easy problem. Richard.
[PATCH] Cleanup some vector cst/constructor generations
Noticed during the VECTOR_CST representation change.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
* tree-vect-loop.c (get_initial_def_for_induction): Use
build_constructor directly.
* tree-vect-stmts.c (vect_get_vec_def_for_operand): Use
build_vector_from_val.
* tree.c (build_vector_from_val): Avoid creating a constructor
first when we want a constant vector.
Index: trunk/gcc/tree-vect-loop.c
===
*** trunk.orig/gcc/tree-vect-loop.c 2012-03-15 14:55:24.0 +0100
--- trunk/gcc/tree-vect-loop.c 2012-03-15 14:55:47.0 +0100
*** get_initial_def_for_induction (gimple iv
*** 3041,3046
--- 3041,3048
}
else
{
+ VEC(constructor_elt,gc) *v;
+
/* iv_loop is the loop to be vectorized. Create:
vec_init = [X, X+S, X+2*S, X+3*S] (S = step_expr, X = init_expr) */
new_var = vect_get_new_vect_var (scalar_type, vect_scalar_var, var_);
*** get_initial_def_for_induction (gimple iv
*** 3053,3060
gcc_assert (!new_bb);
}
! t = NULL_TREE;
! t = tree_cons (NULL_TREE, new_name, t);
for (i = 1; i nunits; i++)
{
/* Create: new_name_i = new_name + step_expr */
--- 3055,3062
gcc_assert (!new_bb);
}
! v = VEC_alloc (constructor_elt, gc, nunits);
! CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, new_name);
for (i = 1; i nunits; i++)
{
/* Create: new_name_i = new_name + step_expr */
*** get_initial_def_for_induction (gimple iv
*** 3073,3082
fprintf (vect_dump, created new init_stmt: );
print_gimple_stmt (vect_dump, init_stmt, 0, TDF_SLIM);
}
! t = tree_cons (NULL_TREE, new_name, t);
}
/* Create a vector from [new_name_0, new_name_1, ...,
new_name_nunits-1] */
! vec = build_constructor_from_list (vectype, nreverse (t));
vec_init = vect_init_vector (iv_phi, vec, vectype, NULL);
}
--- 3075,3084
fprintf (vect_dump, created new init_stmt: );
print_gimple_stmt (vect_dump, init_stmt, 0, TDF_SLIM);
}
! CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, new_name);
}
/* Create a vector from [new_name_0, new_name_1, ...,
new_name_nunits-1] */
! vec = build_constructor (vectype, v);
vec_init = vect_init_vector (iv_phi, vec, vectype, NULL);
}
Index: trunk/gcc/tree-vect-stmts.c
===
*** trunk.orig/gcc/tree-vect-stmts.c2012-03-15 14:55:24.0 +0100
--- trunk/gcc/tree-vect-stmts.c 2012-03-15 14:55:47.0 +0100
*** vect_get_vec_def_for_operand (tree op, g
*** 1227,1235
loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
tree vec_inv;
tree vec_cst;
- tree t = NULL_TREE;
tree def;
- int i;
enum vect_def_type dt;
bool is_simple_use;
tree vector_type;
--- 1227,1233
*** vect_get_vec_def_for_operand (tree op, g
*** 1284,1290
{
vector_type = get_vectype_for_scalar_type (TREE_TYPE (def));
gcc_assert (vector_type);
- nunits = TYPE_VECTOR_SUBPARTS (vector_type);
if (scalar_def)
*scalar_def = def;
--- 1282,1287
*** vect_get_vec_def_for_operand (tree op, g
*** 1293,1305
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Create vector_inv.);
! for (i = nunits - 1; i = 0; --i)
! {
! t = tree_cons (NULL_TREE, def, t);
! }
!
! /* FIXME: use build_constructor directly. */
! vec_inv = build_constructor_from_list (vector_type, t);
return vect_init_vector (stmt, vec_inv, vector_type, NULL);
}
--- 1290,1296
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Create vector_inv.);
! vec_inv = build_vector_from_val (vector_type, def);
return vect_init_vector (stmt, vec_inv, vector_type, NULL);
}
Index: trunk/gcc/tree.c
===
*** trunk.orig/gcc/tree.c 2012-03-15 14:55:24.0 +0100
--- trunk/gcc/tree.c2012-03-15 14:58:12.0 +0100
*** tree
*** 1372,1378
build_vector_from_val (tree vectype, tree sc)
{
int i, nunits = TYPE_VECTOR_SUBPARTS (vectype);
- VEC(constructor_elt, gc) *v = NULL;
if (sc == error_mark_node)
return sc;
--- 1372,1377
*** build_vector_from_val (tree vectype, tre
*** 1386,1399
gcc_checking_assert (types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE (sc)),
TREE_TYPE
[VMS/committed]: Define __VMS_VER and __CRTL_VER
Hi,
these two macros are used by system headers to enable some features.
If they aren't defined, the headers assume the system is the most recent one,
and may use some functions that aren't present in the libraries.
Let's be conservative for cross compiler (and even for native one).
Committed on trunk.
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* config/vms/vms.h (TARGET_OS_CPP_BUILTINS): Define
__CRTL_VER and __VMS_VER.
* config/vms/vms-protos.h: Declare vms_c_get_crtl_ver
and vms_c_get_vms_ver.
* config/vms/vms-c.c (vms_c_get_crtl_ver, vms_c_get_vms_ver): New
functions.
* config/alpha/vms.h (VMS_DEFAULT_CRTL_VER)
(VMS_DEFAULT_VMS_VER): Define.
* config/ia64/vms.h (VMS_DEFAULT_CRTL_VER)
(VMS_DEFAULT_VMS_VER): Define.
Index: gcc/config/alpha/vms.h
===
--- gcc/config/alpha/vms.h (revision 185454)
+++ gcc/config/alpha/vms.h (working copy)
@@ -289,3 +289,7 @@
#undef TARGET_VALID_POINTER_MODE
#define TARGET_VALID_POINTER_MODE vms_valid_pointer_mode
+
+/* Default values for _CRTL_VER and _VMS_VER. */
+#define VMS_DEFAULT_CRTL_VER 7032
+#define VMS_DEFAULT_VMS_VER 7032
Index: gcc/config/vms/vms-protos.h
===
--- gcc/config/vms/vms-protos.h (revision 185454)
+++ gcc/config/vms/vms-protos.h (working copy)
@@ -20,6 +20,8 @@
/* vms-c.c */
extern void vms_c_register_pragma (void);
extern void vms_c_common_override_options (void);
+extern int vms_c_get_crtl_ver (void);
+extern int vms_c_get_vms_ver (void);
/* vms.c */
void vms_patch_builtins (void);
Index: gcc/config/vms/vms.h
===
--- gcc/config/vms/vms.h(revision 185454)
+++ gcc/config/vms/vms.h(working copy)
@@ -21,19 +21,21 @@
#define TARGET_OBJECT_SUFFIX .obj
#define TARGET_EXECUTABLE_SUFFIX .exe
-#define TARGET_OS_CPP_BUILTINS()\
- do { \
-builtin_define_std (vms); \
-builtin_define_std (VMS); \
-builtin_assert (system=vms); \
-SUBTARGET_OS_CPP_BUILTINS();\
-builtin_define (__int64=long long); \
-if (flag_vms_pointer_size == VMS_POINTER_SIZE_32) \
- builtin_define (__INITIAL_POINTER_SIZE=32); \
-else if (flag_vms_pointer_size == VMS_POINTER_SIZE_64) \
- builtin_define (__INITIAL_POINTER_SIZE=64); \
-if (POINTER_SIZE == 64) \
- builtin_define (__LONG_POINTERS=1); \
+#define TARGET_OS_CPP_BUILTINS()\
+ do { \
+builtin_define_std (vms);
\
+builtin_define_std (VMS);
\
+builtin_assert (system=vms); \
+SUBTARGET_OS_CPP_BUILTINS();\
+builtin_define (__int64=long long); \
+if (flag_vms_pointer_size == VMS_POINTER_SIZE_32) \
+ builtin_define (__INITIAL_POINTER_SIZE=32); \
+else if (flag_vms_pointer_size == VMS_POINTER_SIZE_64) \
+ builtin_define (__INITIAL_POINTER_SIZE=64); \
+if (POINTER_SIZE == 64) \
+ builtin_define (__LONG_POINTERS=1); \
+builtin_define_with_int_value (__CRTL_VER, vms_c_get_crtl_ver ()); \
+builtin_define_with_int_value (__VMS_VER, vms_c_get_vms_ver ()); \
} while (0)
extern void vms_c_register_includes (const char *, const char *, int);
Index: gcc/config/vms/vms-c.c
===
--- gcc/config/vms/vms-c.c (revision 185454)
+++ gcc/config/vms/vms-c.c (working copy)
@@ -466,3 +466,19 @@
break;
}
}
+
+/* The default value for _CRTL_VER macro. */
+
+int
+vms_c_get_crtl_ver (void)
+{
+ return VMS_DEFAULT_CRTL_VER;
+}
+
+/* The default value for _VMS_VER macro. */
+
+int
+vms_c_get_vms_ver (void)
+{
+ return VMS_DEFAULT_VMS_VER;
+}
Index: gcc/config/ia64/vms.h
===
--- gcc/config/ia64/vms.h (revision 185454)
+++ gcc/config/ia64/vms.h (working copy)
@@ -157,3 +157,7 @@
/* IA64 VMS doesn't fully support COMDAT sections. */
#define SUPPORTS_ONE_ONLY 0
+
+/* Default values for _CRTL_VER and _VMS_VER. */
+#define VMS_DEFAULT_CRTL_VER 8030
+#define VMS_DEFAULT_VMS_VER 8030
Re: [PATCH] gfortran testsuite: implicitly cleanup-modules
On Thu, Mar 15, 2012 at 08:35:47PM +0100, Jakub Jelinek wrote: On Thu, Mar 15, 2012 at 05:56:32PM +0100, Bernhard Reutner-Fischer wrote: On Thu, Mar 15, 2012 at 04:57:12PM +0100, Richard Guenther wrote: On Thu, Mar 15, 2012 at 1:39 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: committed as r185430. You forgot to add fortran-modules.exp :( committed as r185439. I am very sorry for that.. Even with that file in, libgomp and libitm make check still fail, can't find fortran-modules.exp. I have committed the attached as r185460. The underlying problem is that dejagnu's runtest.exp only allows for a single libdir where it searches for includes -- see comment in libgomp.exp and libitm.exp While just adding more and more load_gcc_lib calls to users outside of gcc/ is the easy way out, it is (IMHO) error prone (i ran make check just in gcc and not in toplevel, fixed my script now). It would be desirable if dejagnu would just find all the currently load_gcc_lib'ed files on its own, via load_lib. One could - teach dejagnu to treat libdir as a list of paths - symlink gcc/testsuite/lib/* into */testsuite/config (ugly) for reference, dejagnu's load_lib currently searches in ../lib $libdir $libdir/lib [file dirname [file dirname $srcdir]]/dejagnu/lib $srcdir/lib $execpath/lib . [file dirname [file dirname [file dirname $srcdir]]]/dejagnu/lib Index: libitm/ChangeLog === --- libitm/ChangeLog (revision 185459) +++ libitm/ChangeLog (revision 185460) @@ -1,3 +1,7 @@ +2012-03-16 Bernhard Reutner-Fischer al...@gcc.gnu.org + + * testsuite/lib/libitm.exp: load fortran-modules.exp + 2012-03-14 Rainer Orth r...@cebitec.uni-bielefeld.de * configure.tgt (*-*-irix6*): Remove. Index: libitm/testsuite/lib/libitm.exp === --- libitm/testsuite/lib/libitm.exp (revision 185459) +++ libitm/testsuite/lib/libitm.exp (revision 185460) @@ -38,6 +38,7 @@ load_gcc_lib torture-options.exp load_gcc_lib timeout.exp load_gcc_lib timeout-dg.exp +load_gcc_lib fortran-modules.exp load_gcc_lib gcc-dg.exp set dg-do-what-default run Index: libgomp/ChangeLog === --- libgomp/ChangeLog (revision 185459) +++ libgomp/ChangeLog (revision 185460) @@ -1,3 +1,7 @@ +2012-03-16 Bernhard Reutner-Fischer al...@gcc.gnu.org + + * testsuite/lib/libgomp.exp: load fortran-modules.exp + 2012-03-14 Rainer Orth r...@cebitec.uni-bielefeld.de * configure.tgt (mips-sgi-irix6*): Remove. Index: libgomp/testsuite/lib/libgomp.exp === --- libgomp/testsuite/lib/libgomp.exp (revision 185459) +++ libgomp/testsuite/lib/libgomp.exp (revision 185460) @@ -24,6 +24,7 @@ load_gcc_lib torture-options.exp load_gcc_lib timeout.exp load_gcc_lib timeout-dg.exp +load_gcc_lib fortran-modules.exp load_gcc_lib gcc-dg.exp load_gcc_lib gfortran-dg.exp
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 1:13 AM, Andrew Pinski pins...@gmail.com wrote: On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt ber...@codesourcery.com wrote: On 03/16/2012 12:44 AM, Jakub Jelinek wrote: For pointer arithmetics in the IL we assume the C requirements, pointer arithmetics can be performed only within the same object, so for int a[10]; both of the following are invalid, even in the IL: int *p = a - 1; int *q = a + 11; Ok, so what's the solution? Add a second POINTER_PLUS_EXPR code with defined overflow behaviour, or add a flag to it? We should have one for PLUS_EXPR also. There was some movement on that on a branch that Richard Guenther did but I don't know if he is going to work on it further. I have been noticing more and more the need for this feature while working on my tree combiner branch, that I might try to see if Richard's branch can be revisited. The branch was a too big task at one time, so presently I'm trying to get rid of the speciality of sizetypes first and then plan to revisit the branch. To recap - on the branch we have an explicit notion on whether a operation can overflow or not (where not overflowing is equivalent to undefined behavior if overflow happens). Operations are marked either way by choosing different tree codes. See http://gcc.gnu.org/wiki/NoUndefinedOverflow Unfortunately updating the branch stopped before tuplification (heh ...). So I guess it will need to be re-done from start. And yes, it's a massive effort. But in theory you can do the massaging incrementally - so, in your case add only POINTER_PLUSNV_EXPR and make sure to drop that to POINTER_PLUS_EXPR whenever you are no longer sure that the operation follows the C language constraints of pointer arithmetic (and change all folders that assume that semantic to work only on POINTER_PLUSNV_EXPRs). Or do it the other way around (which of course will be less conservatively correct - something I'm no longer 100% sure about). Your patch as-is is not safe at the moment. But why is casting a pointer to an integer prohibitly expensive? That fact should be an implementation detail of GIMPLE. Or is it the issue that IVOPTs chooses an integer type that does not necessarily match the mode we'll use on RTL? (thus, ptr_mode vs. Pmode issues, and/or sizeof (sizetype) != sizeof (void *) issues?) Richard.
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
On Fri, Mar 16, 2012 at 1:29 AM, Jonathan Wakely jwakely@gmail.com wrote: On 15 March 2012 15:40, Richard Guenther wrote: On Thu, Mar 15, 2012 at 4:22 PM, Kai Tietz ktiet...@googlemail.com wrote: Richard, ping. I think now could be a good time for applying the patch you have for this issue as we are in stage 1. It will still regress the two libstdc++ testcases (well, I guess so at least). Jonathan - you didn't answer my reply to your question? Would it be ok to apply this patch with leaving the regressions in-place, to be investigated by libstdc++ folks? Sorry, I've either forgotten or missed the reply - but if you think the problem is in libstdc++ then certainly go ahead and apply it, I'll investigate the libstdc++ problems (and ask for help if they defeat me!) Ok. I'll do so after re-testing the patch. Richard.
[Patch]: Uncouple size_t and sizetype
Hi,
currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the
same as size_t.
This is an issue on VMS, where size_t is 'unsigned int', but we'd like to have
a 64 bit sizetype
for Ada. My understanding is that ISO-C doesn't require size_t precision to
match the one of
void *.
We can't really lie about size_t because it is exposed in API (such as writev).
I don't see any reason (other than historic one) to have an exact match between
sizetype and size_t.
So this patch adds an hook to allow targets to define sizetype.
I initially thought about using Pmode precision for sizetype precision, but
there are a few machines
(m32c, sh, h8300) where the precisions aren't the same. I don't know wether
this is on purpose or
unintentional.
Manually tested on ia64 and alpha vms.
Not yet regression tested on a more common machine.
Comments are welcome,
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* target.def (sizetype_cdecl): New hook.
* stor-layout.c (initialize_sizetypes): Use sizetype_cdecl hook
to get sizetype name.
* targhooks.c (default_sizetype_cdecl): New function.
* targhooks.h (default_sizetype_cdecl): New prototype.
* doc/tm.texi.in (Type Layout): Add TARGET_SIZETYPE_CDECL hook.
* doc/tm.texi: Regenerate.
* config/vms/vms.h (SIZE_TYPE): Always unsigned int.
diff --git a/gcc/config/vms/vms.h b/gcc/config/vms/vms.h
index e11b1bf..dc1 100644
--- a/gcc/config/vms/vms.h
+++ b/gcc/config/vms/vms.h
@@ -58,14 +58,12 @@ extern void vms_c_register_includes (const char *, const
char *, int);
#define POINTER_SIZE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? 32 : 64)
#define POINTERS_EXTEND_UNSIGNED 0
-/* FIXME: It should always be a 32 bit type. */
+/* Always 32 bits. */
#undef SIZE_TYPE
-#define SIZE_TYPE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? \
- unsigned int : long long unsigned int)
-/* ???: Defined as a 'int' by dec-c, but obstack.h doesn't like it. */
+#define SIZE_TYPE unsigned int
#undef PTRDIFF_TYPE
#define PTRDIFF_TYPE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? \
int : long long int)
#define C_COMMON_OVERRIDE_OPTIONS vms_c_common_override_options ()
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 69f8aba..48d7b60 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1651,6 +1651,12 @@ for the result of subtracting two pointers. The typedef
name
If you don't define this macro, the default is @code{long int}.
@end defmac
+@deftypefn {Target Hook} {const char *} TARGET_SIZETYPE_CDECL (void)
+This hooks should return the corresponding C declaration for the
internal@code{sizetype} type, from which are also derived @code{bitsizetype}
and thesigned variant.
+
+If you don't define it, the default is @code{SIZE_TYPE}.
+@end deftypefn
+
@defmac WCHAR_TYPE
A C expression for a string describing the name of the data type to use
for wide characters. The typedef name @code{wchar_t} is defined using
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index c24cf1e..0028b76 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -1639,6 +1639,8 @@ for the result of subtracting two pointers. The typedef
name
If you don't define this macro, the default is @code{long int}.
@end defmac
+@hook TARGET_SIZETYPE_CDECL
+
@defmac WCHAR_TYPE
A C expression for a string describing the name of the data type to use
for wide characters. The typedef name @code{wchar_t} is defined using
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 264edd7..d77abc2 100644
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 7c7fabc..5ed0f12 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2383,15 +2383,16 @@ void
initialize_sizetypes (void)
{
int precision, bprecision;
+ const char *sizetype_name = targetm.sizetype_cdecl ();
/* Get sizetypes precision from the SIZE_TYPE target macro. */
- if (strcmp (SIZE_TYPE, unsigned int) == 0)
+ if (strcmp (sizetype_name, unsigned int) == 0)
precision = INT_TYPE_SIZE;
- else if (strcmp (SIZE_TYPE, long unsigned int) == 0)
+ else if (strcmp (sizetype_name, long unsigned int) == 0)
precision = LONG_TYPE_SIZE;
- else if (strcmp (SIZE_TYPE, long long unsigned int) == 0)
+ else if (strcmp (sizetype_name, long long unsigned int) == 0)
precision = LONG_LONG_TYPE_SIZE;
- else if (strcmp (SIZE_TYPE, short unsigned int) == 0)
+ else if (strcmp (sizetype_name, short unsigned int) == 0)
precision = SHORT_TYPE_SIZE;
else
gcc_unreachable ();
diff --git a/gcc/target.def b/gcc/target.def
index d658b11..bde3388 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -2674,6 +2674,19 @@ DEFHOOKPOD
@code{bool} @code{true}.,
unsigned char, 1)
+/* The corresponding C declaration for the internal 'sizetype' type, from which
+ are also derived 'bitsizetype' and the signed variant. The default is
+ SIZE_TYPE. */
+DEFHOOK
+(sizetype_cdecl,
+ This
[VMS/committed]: Do not use long in vms-unwind.h
Hi,
use of 'long' in vms-unwind.h for registers isn't correct as 'long' should be a
32 bit type on vms.
Let replace it with unw_reg, now defined as unsigned __int64.
Manually tested on ia64-hp-openvms.
Committed on trunk.
Tristan.
libgcc/
2012-03-16 Tristan Gingold ging...@adacore.com
* config/ia64/vms-unwind.h: Remove ulong (and replace
it by unw_reg where used). Define unw_reg with __int64.
Index: libgcc/config/ia64/vms-unwind.h
===
--- libgcc/config/ia64/vms-unwind.h (revision 185454)
+++ libgcc/config/ia64/vms-unwind.h (working copy)
@@ -49,9 +49,8 @@
extern int LIB$I64_GET_CURR_INVO_CONTEXT (INVO_CONTEXT_BLK *);
extern int LIB$I64_GET_PREV_INVO_CONTEXT (INVO_CONTEXT_BLK *);
-typedef unsigned long ulong;
typedef unsigned int uint;
-typedef unsigned long uw_reg;
+typedef unsigned __int64 uw_reg;
typedef uw_reg * uw_loc;
typedef char fp_reg[16];
@@ -179,8 +178,8 @@
if (eh_debug)
printf (User frame,
- chfmech @ 0x%lx, chfsig64 @ 0x%lx, intstk @ 0x%lx\n,
- (ulong)chfmech, (ulong)chfsig64, (ulong)intstk);
+ chfmech @ 0x%p, chfsig64 @ 0x%p, intstk @ 0x%p\n,
+ chfmech, chfsig64, intstk);
/* Step 2 :
@@ -239,10 +238,10 @@
trick already) and how this would be handled. Blind alpha tentative
below for experimentation purposes in malfunctioning cases. */
{
-ulong q_bsp = (ulong) intstk-intstk$q_bsp;
-ulong q_bspstore = (ulong) intstk-intstk$q_bspstore;
-ulong q_bspbase = (ulong) intstk-intstk$q_bspbase;
-ulong ih_bspbase = (ulong) icb-libicb$ih_bspbase;
+uw_reg q_bsp = (uw_reg) intstk-intstk$q_bsp;
+uw_reg q_bspstore = (uw_reg) intstk-intstk$q_bspstore;
+uw_reg q_bspbase = (uw_reg) intstk-intstk$q_bspbase;
+uw_reg ih_bspbase = (uw_reg) icb-libicb$ih_bspbase;
if (eh_debug)
printf (q_bspstore = 0x%lx, q_bsp = 0x%lx, q_bspbase = 0x%lx\n
@@ -254,8 +253,8 @@
nothing resulted in proper behavior. */
if (q_bspstore q_bsp ih_bspbase try_bs_copy)
{
- ulong dirty_size = q_bsp - q_bspstore;
- ulong q_rnat = (ulong) intstk-intstk$q_rnat;
+ uw_reg dirty_size = q_bsp - q_bspstore;
+ uw_reg q_rnat = (uw_reg) intstk-intstk$q_rnat;
if (eh_debug)
printf (Attempting an alternate backing store copy ...\n);
Re: [Patch]: Uncouple size_t and sizetype
On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold ging...@adacore.com wrote:
Hi,
currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the
same as size_t.
This is an issue on VMS, where size_t is 'unsigned int', but we'd like to
have a 64 bit sizetype
for Ada. My understanding is that ISO-C doesn't require size_t precision to
match the one of
void *.
We can't really lie about size_t because it is exposed in API (such as
writev).
I don't see any reason (other than historic one) to have an exact match
between sizetype and size_t.
So this patch adds an hook to allow targets to define sizetype.
Well, there is at least common sense that couples size_t and sizetype.
As you can at most allocate size_t memory via malloc (due to its size_t
use for the size) sizes larger than what fits into size_t do not make much
sense. Thus, a sizetype larger than size_t does not make much sense.
The middle-end of course would not care much what you use for sizetype.
But be warned - if the mode for sizetype is different of ptr_mode things
are going to be interesting for you (yes, ptr_mode, not Pmode).
I initially thought about using Pmode precision for sizetype precision, but
there are a few machines
(m32c, sh, h8300) where the precisions aren't the same. I don't know wether
this is on purpose or
unintentional.
At least for m32c it is IIRC because 24bit computations are soo expensive
on that target, so HImode is chosen for sizetype.
So - why do you need a 64bit sizetype again? ;)
Can it be that you don't really need 64bit sizes but you hit issues with
sizetype != ptr_mode size?
Btw, while we are transitioning to target hooks in this case I'd prefer
a target macro alongside the existing SIZE_TYPE, etc. ones.
Richard.
Manually tested on ia64 and alpha vms.
Not yet regression tested on a more common machine.
Comments are welcome,
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* target.def (sizetype_cdecl): New hook.
* stor-layout.c (initialize_sizetypes): Use sizetype_cdecl hook
to get sizetype name.
* targhooks.c (default_sizetype_cdecl): New function.
* targhooks.h (default_sizetype_cdecl): New prototype.
* doc/tm.texi.in (Type Layout): Add TARGET_SIZETYPE_CDECL hook.
* doc/tm.texi: Regenerate.
* config/vms/vms.h (SIZE_TYPE): Always unsigned int.
diff --git a/gcc/config/vms/vms.h b/gcc/config/vms/vms.h
index e11b1bf..dc1 100644
--- a/gcc/config/vms/vms.h
+++ b/gcc/config/vms/vms.h
@@ -58,14 +58,12 @@ extern void vms_c_register_includes (const char *, const
char *, int);
#define POINTER_SIZE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? 32 :
64)
#define POINTERS_EXTEND_UNSIGNED 0
-/* FIXME: It should always be a 32 bit type. */
+/* Always 32 bits. */
#undef SIZE_TYPE
-#define SIZE_TYPE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? \
- unsigned int : long long unsigned int)
-/* ???: Defined as a 'int' by dec-c, but obstack.h doesn't like it. */
+#define SIZE_TYPE unsigned int
#undef PTRDIFF_TYPE
#define PTRDIFF_TYPE (flag_vms_pointer_size == VMS_POINTER_SIZE_NONE ? \
int : long long int)
#define C_COMMON_OVERRIDE_OPTIONS vms_c_common_override_options ()
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 69f8aba..48d7b60 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1651,6 +1651,12 @@ for the result of subtracting two pointers. The
typedef name
If you don't define this macro, the default is @code{long int}.
@end defmac
+@deftypefn {Target Hook} {const char *} TARGET_SIZETYPE_CDECL (void)
+This hooks should return the corresponding C declaration for the
internal@code{sizetype} type, from which are also derived @code{bitsizetype}
and thesigned variant.
+
+If you don't define it, the default is @code{SIZE_TYPE}.
+@end deftypefn
+
@defmac WCHAR_TYPE
A C expression for a string describing the name of the data type to use
for wide characters. The typedef name @code{wchar_t} is defined using
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index c24cf1e..0028b76 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -1639,6 +1639,8 @@ for the result of subtracting two pointers. The
typedef name
If you don't define this macro, the default is @code{long int}.
@end defmac
+@hook TARGET_SIZETYPE_CDECL
+
@defmac WCHAR_TYPE
A C expression for a string describing the name of the data type to use
for wide characters. The typedef name @code{wchar_t} is defined using
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 264edd7..d77abc2 100644
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 7c7fabc..5ed0f12 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2383,15 +2383,16 @@ void
initialize_sizetypes (void)
{
int precision, bprecision;
+ const char *sizetype_name = targetm.sizetype_cdecl ();
/* Get sizetypes precision
Re: [Patch, fortran] Use BUILT_IN_IROUND
On Fri, Mar 16, 2012 at 9:17 AM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Thu, Mar 15, 2012 at 22:28, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Thu, Mar 15, 2012 at 22:14, Tobias Burnus bur...@net-b.de wrote:
Janne Blomqvist wrote:
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
OK. Thanks for the patch! Nit: Could you check mathbuiltins.def - at least
in the diff, iround seems to be misaligned (one missing).
Ah, a tab had sneaked in, fixed. Committed the fixed patch as r185442.
Thanks for the quick review!
--
Janne Blomqvist
I realized there was a bug in the patch, and testing revealed my
suspicion as true. Namely as there is no library fallback for iround,
and the middle-end machinery takes care of converting it to lround
only for float, double, and long double, it doesn't work for
__float128. In the testcase in my original patch mail, changing x to
real(16) generated a call to iroundq, which doesn't exist. Committed
the patch below as obvious.
This seems to have broken SPEC 2000 FPU quite a lot as we now get
/gcc/spec/sb-vangelis-head-64/x86_64/install-201203152354/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libgfortran.so:
undefined reference to `iroundq'
collect2: error: ld returned 1 exit status
specmake: *** [apsi] Error 1
though maybe it was Jakubs patch as libgfortran has the reference?
Jakub?
Richard.
Index: ChangeLog
===
--- ChangeLog (revision 185452)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-03-16 Janne Blomqvist j...@gcc.gnu.org
+
+ * trans-intrinsic.c (build_round_expr): Don't use BUILT_IN_IROUND
+ for __float128.
+
2012-03-15 Janne Blomqvist j...@gcc.gnu.org
* f95-lang.c (gfc_init_builtin_functions): Initialize
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 185452)
+++ trans-intrinsic.c (working copy)
@@ -383,10 +383,11 @@ build_round_expr (tree arg, tree restype
resprec = TYPE_PRECISION (restype);
/* Depending on the type of the result, choose the int intrinsic
- (iround, available only as a builtin), long int intrinsic
(lround
- family) or long long intrinsic (llround). We might also need to
- convert the result afterwards. */
- if (resprec = INT_TYPE_SIZE)
+ (iround, available only as a builtin, therefore cannot use it
for
+ __float128), long int intrinsic (lround family) or long long
+ intrinsic (llround). We might also need to convert the result
+ afterwards. */
+ if (resprec = INT_TYPE_SIZE argprec = LONG_DOUBLE_TYPE_SIZE)
fn = builtin_decl_for_precision (BUILT_IN_IROUND, argprec);
else if (resprec = LONG_TYPE_SIZE)
fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
--
Janne Blomqvist
Re: [Patch]: Uncouple size_t and sizetype
On Mar 16, 2012, at 12:02 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold ging...@adacore.com wrote: Hi, currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the same as size_t. This is an issue on VMS, where size_t is 'unsigned int', but we'd like to have a 64 bit sizetype for Ada. My understanding is that ISO-C doesn't require size_t precision to match the one of void *. We can't really lie about size_t because it is exposed in API (such as writev). I don't see any reason (other than historic one) to have an exact match between sizetype and size_t. So this patch adds an hook to allow targets to define sizetype. Well, there is at least common sense that couples size_t and sizetype. As you can at most allocate size_t memory via malloc (due to its size_t use for the size) sizes larger than what fits into size_t do not make much sense. Thus, a sizetype larger than size_t does not make much sense. Agreed, but malloc() is not the only way to get memory. At least on VMS, there are some syscalls to allocate memory with a 64 bit length argument. The middle-end of course would not care much what you use for sizetype. But be warned - if the mode for sizetype is different of ptr_mode things are going to be interesting for you (yes, ptr_mode, not Pmode). That's the issue. POINTER_SIZE is 64 bits (when -mpointer-size=64) but size_t should always be 32 bit. I initially thought about using Pmode precision for sizetype precision, but there are a few machines (m32c, sh, h8300) where the precisions aren't the same. I don't know wether this is on purpose or unintentional. At least for m32c it is IIRC because 24bit computations are soo expensive on that target, so HImode is chosen for sizetype. That's a good reason! So - why do you need a 64bit sizetype again? ;) Can it be that you don't really need 64bit sizes but you hit issues with sizetype != ptr_mode size? I don't have an urgent need for 64bit sizes (although would be nice to have them). I remember that the first build with sizetype=32 but ptr_mode =DImode was a failure. Maybe I should first investigate this path, as m32c could use unsigned int (16 bits) for size_type alongside 32 for POINTER_SIZE ? Btw, while we are transitioning to target hooks in this case I'd prefer a target macro alongside the existing SIZE_TYPE, etc. ones. Ok. Tristan.
Re: [patch tree-optimization]: Fix for PR 45397 part 1 of 2
On Thu, Mar 15, 2012 at 3:34 PM, Kai Tietz ktiet...@googlemail.com wrote: 2012/3/15 Richard Guenther richard.guent...@gmail.com: On Thu, Mar 15, 2012 at 3:00 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Mar 15, 2012 at 02:53:10PM +0100, Kai Tietz wrote: This looks like to match unbound pattern sizes and thus does not fit into the forwprop machinery. Instead it was suggested elsewhere that promoting / demoting registers should be done in a separate pass where you can compute a lattice of used bits and apply a transform based on that lattice and target information (according to PROMOTE_MODE for example). Well, the integer truncation part might be something for a separate pass. It could then also take care that within single-use gimple-statements the integral-constant is always on right-hand-side of first statement of an +, -, |, ^, , and mul. But the cast-hoisting code itself is not unbound AFAICS and has fixed pattern size. Can you split that part out then please? I can do. In fact just the part of calling Sure, it would be the removal of the function truncate_integers and its call. The type demotion is PR45397/PR47477 among other PRs. I'd just walk from the narrowing integer conversion stmts recursively through the def stmts, see if they can be narrowed, note it, and finally if everything or significant portion of the stmts can be demoted (if not all, with some narrowing integer conversion stmt inserted), do it all together. Jakub, this might be something good to have it in separate pass. Right now I need to avoid some type-hoisting in forward-propagation, as otherwise it would loop endless caused by type-sinking code in forward-propagation. Well, that sounds like either of it is not applying costs properly. We should have a total ordering cost-wise on both forms. Which forms do we iterate on? Only question would be where such pass would be best placed. After or before forward-propagation pass? Somewhere before loop optimizations (especially IVOPTs). Generally it might help SCEV analysis, so I'd do it before PRE, after the CCP/copy-prop passes. For PROMOTE_MODE targets you'd promote but properly mask out constants (to make them cheaper to generate, for example). You'd also take advantate of targets that can do zero/sign-extending loads without extra cost (ISTR that's quite important for some SPEC 2k6 benchmark on x86_64). Hmm, as we are talking about truncation-casts here, what is the reaons for PROMOTE_MODE here? You mean to generate for a PROMOTE_MODE target explicit something like: D1 = 0x80 D2 = (int) D1 instead of having D1 = 0xff80. Isn't that a decision done on RTL level? PROMOTE_MODE is about targets only having basic operations in the mode PROMOTE_MODE promotes to. For example (IIRC) powerpc can only do arithmetic on full register width, not on arbitrarily sub-regs as i386. Which means that if you need sub-reg precision values we have to insert truncataions after every operation on RTL. Thus, if you artificially lower precision of computations on the tree level this will pessimize things on RTL. So, you never should narrow operations below what PROMOTE_MODE would do. In fact, you might as well expose the PROMOTE_MODE fact on the tree level. Another interesting type-hoisting part is to check if a type-sign change might be profitable. Eg: signed char D0, D1, D5; int D2,D3,D4 ... D2 = (int) D0 D3 = (int) D1 D4 = D2 + D3 D5 = (signed char) D4 D6 = D5 == 0x8f to signed char D0, D1, D5; unsigned char D2,D3,D4 ... D2 = (unsigned char) D0 D3 = (unsigned char) D1 D4 = D2 + D3 D5 = D4 == 0x7fu You need to watch for undefined overflow issues on the narrowed expressions anyway (thus, have to resort to unsigned arithmetic in nearly all cases). Richard. Richard. Jakub Regards, Kai
Re: [Patch]: Uncouple size_t and sizetype
On Fri, Mar 16, 2012 at 12:33 PM, Tristan Gingold ging...@adacore.com wrote: On Mar 16, 2012, at 12:02 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold ging...@adacore.com wrote: Hi, currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the same as size_t. This is an issue on VMS, where size_t is 'unsigned int', but we'd like to have a 64 bit sizetype for Ada. My understanding is that ISO-C doesn't require size_t precision to match the one of void *. We can't really lie about size_t because it is exposed in API (such as writev). I don't see any reason (other than historic one) to have an exact match between sizetype and size_t. So this patch adds an hook to allow targets to define sizetype. Well, there is at least common sense that couples size_t and sizetype. As you can at most allocate size_t memory via malloc (due to its size_t use for the size) sizes larger than what fits into size_t do not make much sense. Thus, a sizetype larger than size_t does not make much sense. Agreed, but malloc() is not the only way to get memory. At least on VMS, there are some syscalls to allocate memory with a 64 bit length argument. The middle-end of course would not care much what you use for sizetype. But be warned - if the mode for sizetype is different of ptr_mode things are going to be interesting for you (yes, ptr_mode, not Pmode). That's the issue. POINTER_SIZE is 64 bits (when -mpointer-size=64) but size_t should always be 32 bit. Ok. I initially thought about using Pmode precision for sizetype precision, but there are a few machines (m32c, sh, h8300) where the precisions aren't the same. I don't know wether this is on purpose or unintentional. At least for m32c it is IIRC because 24bit computations are soo expensive on that target, so HImode is chosen for sizetype. That's a good reason! So - why do you need a 64bit sizetype again? ;) Can it be that you don't really need 64bit sizes but you hit issues with sizetype != ptr_mode size? I don't have an urgent need for 64bit sizes (although would be nice to have them). I remember that the first build with sizetype=32 but ptr_mode =DImode was a failure. Maybe I should first investigate this path, as m32c could use unsigned int (16 bits) for size_type alongside 32 for POINTER_SIZE ? Well, this setup is not well supported by the middle-end (and indeed m32c has existing issues with that). So in your case decoupling sizetype from size_t sounds like the more appropriate solution. Btw, while we are transitioning to target hooks in this case I'd prefer a target macro alongside the existing SIZE_TYPE, etc. ones. Ok. I'd choose SIZETYPE (for confusion, heh), defaulting to SIZE_TYPE. Richard. Tristan.
[PATCH] Fix Ada bitfield issue No. 1
This fixes issue No. 1, easy.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
* stor-layout.c (finish_bitfield_representative): Fall back
to the conservative maximum size if we cannot compute the
size of the tail padding.
* gnat.dg/specs/pack7.ads: New testcase.
Index: gcc/stor-layout.c
===
--- gcc/stor-layout.c (revision 185461)
+++ gcc/stor-layout.c (working copy)
@@ -1765,6 +1765,9 @@ finish_bitfield_representative (tree rep
- tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1)
+ tree_low_cst (DECL_SIZE (field), 1));
+ /* Round up bitsize to multiples of BITS_PER_UNIT. */
+ bitsize = (bitsize + BITS_PER_UNIT - 1) ~(BITS_PER_UNIT - 1);
+
/* Now nothing tells us how to pad out bitsize ... */
nextf = DECL_CHAIN (field);
while (nextf TREE_CODE (nextf) != FIELD_DECL)
@@ -1787,12 +1790,16 @@ finish_bitfield_representative (tree rep
{
/* ??? If you consider that tail-padding of this struct might be
re-used when deriving from it we cannot really do the following
-and thus need to set maxsize to bitsize? */
+and thus need to set maxsize to bitsize? Also we cannot
+generally rely on maxsize to fold to an integer constant, so
+use bitsize as fallback for this case. */
tree maxsize = size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)),
DECL_FIELD_OFFSET (repr));
- gcc_assert (host_integerp (maxsize, 1));
- maxbitsize = (tree_low_cst (maxsize, 1) * BITS_PER_UNIT
- - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
+ if (host_integerp (maxsize, 1))
+ maxbitsize = (tree_low_cst (maxsize, 1) * BITS_PER_UNIT
+ - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
+ else
+ maxbitsize = bitsize;
}
/* Only if we don't artificially break up the representative in
@@ -1801,9 +1808,6 @@ finish_bitfield_representative (tree rep
at byte offset. */
gcc_assert (maxbitsize % BITS_PER_UNIT == 0);
- /* Round up bitsize to multiples of BITS_PER_UNIT. */
- bitsize = (bitsize + BITS_PER_UNIT - 1) ~(BITS_PER_UNIT - 1);
-
/* Find the smallest nice mode to use. */
for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode;
mode = GET_MODE_WIDER_MODE (mode))
Index: gcc/testsuite/gnat.dg/specs/pack7.ads
===
--- gcc/testsuite/gnat.dg/specs/pack7.ads (revision 0)
+++ gcc/testsuite/gnat.dg/specs/pack7.ads (revision 0)
@@ -0,0 +1,13 @@
+-- { dg-do compile }
+
+package Pack7 is
+
+ type R (D : Natural) is record
+ S : String (1 .. D);
+ N : Natural;
+ B : Boolean;
+ end record;
+ for R'Alignment use 4;
+ pragma Pack (R);
+
+end Pack7;
[Patch IA64]: Fix 32 bits tablejump
Hi,
I wanted to use 32 bit jump tables for VMS on ia64 (just to reduce executable
size), as
we know 64 offsets aren't necessary.
I override CASE_VECTOR_MODE in vms.h, I had to adjust ASM_OUTPUT_ADDR_DIFF_ELT.
I also adjust ADDR_VEC_ALIGN to reduce the alignment in the SImode case.
But this resulted in broken binaries because expand_simple_binop in 'tablejump'
description
was zero-extended its operand. But table jump vectors aren't unsigned (there
could be backward branches).
I also removed the :DI mode in the template although this is for documentation
only, because this pattern
is emitted directly via gen_tablejump in expr.c
Tested by running a canadian gcc on ia64-hp-openvms.
Ok for trunk ?
Tristan.
2012-03-16 Tristan Gingold ging...@adacore.com
* config/ia64/vms.h (CASE_VECTOR_MODE): Define.
* config/ia64/ia64.md: Remove mode in template.
Sign extend operand in expand_simple_binop.
* config/ia64/ia64.h (ASM_OUTPUT_ADDR_DIFF_ELT): Use
CASE_VECTOR_MODE instead of TARGET_ILP32.
(ADDR_VEC_ALIGN): Make it depends on CASE_VECTOR_MODE.
diff --git a/gcc/config/ia64/ia64.h b/gcc/config/ia64/ia64.h
index a3ccd6f..7794573 100644
--- a/gcc/config/ia64/ia64.h
+++ b/gcc/config/ia64/ia64.h
@@ -1480,19 +1480,17 @@ do {
\
/* This macro should be provided on machines where the addresses in a dispatch
table are relative to the table's own address. */
-/* ??? Depends on the pointer size. */
-
#define ASM_OUTPUT_ADDR_DIFF_ELT(STREAM, BODY, VALUE, REL) \
do { \
- if (TARGET_ILP32)\
+ if (CASE_VECTOR_MODE == SImode) \
fprintf (STREAM, \tdata4 @pcrel(.L%d)\n, VALUE); \
else \
fprintf (STREAM, \tdata8 @pcrel(.L%d)\n, VALUE); \
} while (0)
-/* Jump tables only need 8 byte alignment. */
+/* Jump tables only need 4 or 8 byte alignment. */
-#define ADDR_VEC_ALIGN(ADDR_VEC) 3
+#define ADDR_VEC_ALIGN(ADDR_VEC) (CASE_VECTOR_MODE == SImode ? 2 : 3)
/* Assembler Commands for Exception Regions. */
diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md
index 129cec8..349da7b 100644
--- a/gcc/config/ia64/ia64.md
+++ b/gcc/config/ia64/ia64.md
@@ -4578,7 +4578,7 @@
[(set_attr itanium_class br)])
(define_expand tablejump
- [(parallel [(set (pc) (match_operand:DI 0 memory_operand ))
+ [(parallel [(set (pc) (match_operand 0 memory_operand ))
(use (label_ref (match_operand 1 )))])]
{
@@ -4614,7 +4614,7 @@
from the entry to the label. Thus to convert to an absolute address
we add the address of the memory from which the value is loaded. */
operands[0] = expand_simple_binop (DImode, PLUS, op0, addr,
-NULL_RTX, 1, OPTAB_DIRECT);
+NULL_RTX, 0, OPTAB_DIRECT);
})
(define_insn *tablejump_internal
diff --git a/gcc/config/ia64/vms.h b/gcc/config/ia64/vms.h
index 0c02f8a..d4cc03b 100644
--- a/gcc/config/ia64/vms.h
+++ b/gcc/config/ia64/vms.h
@@ -154,6 +154,10 @@ STATIC func_ptr __CTOR_LIST__[1]
\
#undef TARGET_PROMOTE_FUNCTION_MODE
#define TARGET_PROMOTE_FUNCTION_MODE
default_promote_function_mode_always_promote
+/* Code is always in P0 (lower 31 bit addresses) on VMS. */
+#undef CASE_VECTOR_MODE
+#define CASE_VECTOR_MODE SImode
+
/* IA64 VMS doesn't fully support COMDAT sections. */
#define SUPPORTS_ONE_ONLY 0
Re: [Patch]: Uncouple size_t and sizetype
On Mar 16, 2012, at 12:38 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 12:33 PM, Tristan Gingold ging...@adacore.com wrote: On Mar 16, 2012, at 12:02 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold ging...@adacore.com wrote: Hi, currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the same as size_t. This is an issue on VMS, where size_t is 'unsigned int', but we'd like to have a 64 bit sizetype for Ada. My understanding is that ISO-C doesn't require size_t precision to match the one of void *. We can't really lie about size_t because it is exposed in API (such as writev). I don't see any reason (other than historic one) to have an exact match between sizetype and size_t. So this patch adds an hook to allow targets to define sizetype. Well, there is at least common sense that couples size_t and sizetype. As you can at most allocate size_t memory via malloc (due to its size_t use for the size) sizes larger than what fits into size_t do not make much sense. Thus, a sizetype larger than size_t does not make much sense. Agreed, but malloc() is not the only way to get memory. At least on VMS, there are some syscalls to allocate memory with a 64 bit length argument. The middle-end of course would not care much what you use for sizetype. But be warned - if the mode for sizetype is different of ptr_mode things are going to be interesting for you (yes, ptr_mode, not Pmode). That's the issue. POINTER_SIZE is 64 bits (when -mpointer-size=64) but size_t should always be 32 bit. Ok. I initially thought about using Pmode precision for sizetype precision, but there are a few machines (m32c, sh, h8300) where the precisions aren't the same. I don't know wether this is on purpose or unintentional. At least for m32c it is IIRC because 24bit computations are soo expensive on that target, so HImode is chosen for sizetype. That's a good reason! So - why do you need a 64bit sizetype again? ;) Can it be that you don't really need 64bit sizes but you hit issues with sizetype != ptr_mode size? I don't have an urgent need for 64bit sizes (although would be nice to have them). I remember that the first build with sizetype=32 but ptr_mode =DImode was a failure. Maybe I should first investigate this path, as m32c could use unsigned int (16 bits) for size_type alongside 32 for POINTER_SIZE ? Well, this setup is not well supported by the middle-end (and indeed m32c has existing issues with that). So in your case decoupling sizetype from size_t sounds like the more appropriate solution. Btw, while we are transitioning to target hooks in this case I'd prefer a target macro alongside the existing SIZE_TYPE, etc. ones. Ok. I'd choose SIZETYPE (for confusion, heh), defaulting to SIZE_TYPE. Ok, thank you for your comments. Tristan.
Re: Preserve pointer types in ivopts
On 03/16/2012 11:08 AM, Richard Guenther wrote: Your patch as-is is not safe at the moment. But why is casting a pointer to an integer prohibitly expensive? That fact should be an implementation detail of GIMPLE. Or is it the issue that IVOPTs chooses an integer type that does not necessarily match the mode we'll use on RTL? (thus, ptr_mode vs. Pmode issues, and/or sizeof (sizetype) != sizeof (void *) issues?) The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Bernd
[PATCH] Fix PR52584, fold sub-vector selects with BIT_FIELD_REF
At least generic vector lowering can end up using BIT_FIELD_REF
to generate sub-vector selects such as low/high part of vector
constants/constructors. We do not fold these currently, leading
to quite absymal code. Thus the following patch which teaches
fold to do this.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
PR middle-end/52584
* fold-const.c (fold_ternary_loc): Fold vector typed BIT_FIELD_REFs
of vector constants and constructors.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 185465)
+++ gcc/fold-const.c(working copy)
@@ -13920,22 +13946,55 @@ fold_ternary_loc (location_t loc, enum t
case BIT_FIELD_REF:
if ((TREE_CODE (arg0) == VECTOR_CST
|| TREE_CODE (arg0) == CONSTRUCTOR)
- type == TREE_TYPE (TREE_TYPE (arg0)))
- {
- unsigned HOST_WIDE_INT width = tree_low_cst (arg1, 1);
+ (type == TREE_TYPE (TREE_TYPE (arg0
+ || (TREE_CODE (type) == VECTOR_TYPE
+ TREE_TYPE (type) == TREE_TYPE (TREE_TYPE (arg0)
+ {
+ tree eltype = TREE_TYPE (TREE_TYPE (arg0));
+ unsigned HOST_WIDE_INT width = tree_low_cst (TYPE_SIZE (eltype), 1);
+ unsigned HOST_WIDE_INT n = tree_low_cst (arg1, 1);
unsigned HOST_WIDE_INT idx = tree_low_cst (op2, 1);
- if (width != 0
- simple_cst_equal (arg1, TYPE_SIZE (type)) == 1
+ if (n != 0
(idx % width) == 0
- (idx = idx / width)
- TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)))
+ (n % width) == 0
+ ((idx + n) / width) = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)))
{
- if (TREE_CODE (arg0) == VECTOR_CST)
- return VECTOR_CST_ELT (arg0, idx);
- else if (idx CONSTRUCTOR_NELTS (arg0))
- return CONSTRUCTOR_ELT (arg0, idx)-value;
- return build_zero_cst (type);
+ idx = idx / width;
+ n = n / width;
+ if (TREE_CODE (type) == VECTOR_TYPE)
+ {
+ if (TREE_CODE (arg0) == VECTOR_CST)
+ {
+ tree *vals = XALLOCAVEC (tree, n);
+ unsigned i;
+ for (i = 0; i n; ++i)
+ vals[i] = VECTOR_CST_ELT (arg0, idx + i);
+ return build_vector (type, vals);
+ }
+ else
+ {
+ VEC(constructor_elt, gc) *vals;
+ unsigned i;
+ if (CONSTRUCTOR_NELTS (arg0) == 0)
+ return build_constructor (type, NULL);
+ vals = VEC_alloc (constructor_elt, gc, n);
+ for (i = 0; i n idx + i CONSTRUCTOR_NELTS (arg0);
+ ++i)
+ CONSTRUCTOR_APPEND_ELT (vals, NULL_TREE,
+ CONSTRUCTOR_ELT
+ (arg0, idx + i)-value);
+ return build_constructor (type, vals);
+ }
+ }
+ else if (n == 1)
+ {
+ if (TREE_CODE (arg0) == VECTOR_CST)
+ return VECTOR_CST_ELT (arg0, idx);
+ else if (idx CONSTRUCTOR_NELTS (arg0))
+ return CONSTRUCTOR_ELT (arg0, idx)-value;
+ return build_zero_cst (type);
+ }
}
}
[PATCH] Constant-fold (nearly) all BIT_FIELD_REFs of constants
This makes use of native_encode/interpret_expr to do $subject.
Pretty straight-forward and something value-numbering already
does. Not sure what a good upper bound for the encode buffer
size should be - I suppose at some point we should teach
encode to skip uninteresting start bytes (and teach it to
interpret CONSTRUCTORs - the single major missing feature).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
* fold-const.c (native_interpret_expr): Also support POINTER_TYPE
and REFERENCE_TYPE interpretations.
(can_native_interpret_type_p): New function.
(fold_ternary_loc): Use native encode/interpret to fold
BIT_FIELD_REFs of constants.
Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 185465)
--- gcc/fold-const.c(working copy)
*** native_interpret_expr (tree type, const
*** 7530,7535
--- 7530,7537
case INTEGER_TYPE:
case ENUMERAL_TYPE:
case BOOLEAN_TYPE:
+ case POINTER_TYPE:
+ case REFERENCE_TYPE:
return native_interpret_int (type, ptr, len);
case REAL_TYPE:
*** native_interpret_expr (tree type, const
*** 7546,7551
--- 7548,7574
}
}
+ /* Returns true if we can interpret the contents of a native encoding
+as TYPE. */
+
+ static bool
+ can_native_interpret_type_p (tree type)
+ {
+ switch (TREE_CODE (type))
+ {
+ case INTEGER_TYPE:
+ case ENUMERAL_TYPE:
+ case BOOLEAN_TYPE:
+ case POINTER_TYPE:
+ case REFERENCE_TYPE:
+ case REAL_TYPE:
+ case COMPLEX_TYPE:
+ case VECTOR_TYPE:
+ return true;
+ default:
+ return false;
+ }
+ }
/* Fold a VIEW_CONVERT_EXPR of a constant expression EXPR to type
TYPE at compile-time. If we're unable to perform the conversion
*** fold_ternary_loc (location_t loc, enum t
*** 13945,13950
--- 14004,14043
integer_zerop (op2))
return fold_convert_loc (loc, type, arg0);
+ /* On constants we can use native encode/interpret to constant
+ fold (nearly) all BIT_FIELD_REFs. */
+ if (CONSTANT_CLASS_P (arg0)
+ can_native_interpret_type_p (type)
+ host_integerp (TYPE_SIZE_UNIT (TREE_TYPE (arg0)), 1)
+ /* This limitation should not be necessary, we just need to
+round this up to mode size. */
+ tree_low_cst (op1, 1) % BITS_PER_UNIT == 0
+ /* Need bit-shifting of the buffer to relax the following. */
+ tree_low_cst (op2, 1) % BITS_PER_UNIT == 0)
+ {
+ unsigned HOST_WIDE_INT bitpos = tree_low_cst (op1, 2);
+ unsigned HOST_WIDE_INT bitsize = tree_low_cst (op1, 1);
+ unsigned HOST_WIDE_INT clen;
+ clen = tree_low_cst (TYPE_SIZE_UNIT (TREE_TYPE (arg0)), 1);
+ /* ??? We cannot tell native_encode_expr to start at
+some random byte only. So limit us to a reasonable amount
+of work. */
+ if (clen = 4096)
+ {
+ unsigned char *b = XALLOCAVEC (unsigned char, clen);
+ int len = native_encode_expr (arg0, b, clen);
+ if (len 0
+ len * BITS_PER_UNIT = bitpos + bitsize)
+ {
+ tree v = native_interpret_expr (type,
+ b + bitpos / BITS_PER_UNIT,
+ bitsize / BITS_PER_UNIT);
+ if (v)
+ return v;
+ }
+ }
+ }
+
return NULL_TREE;
case FMA_EXPR:
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt ber...@codesourcery.com wrote: On 03/16/2012 11:08 AM, Richard Guenther wrote: Your patch as-is is not safe at the moment. But why is casting a pointer to an integer prohibitly expensive? That fact should be an implementation detail of GIMPLE. Or is it the issue that IVOPTs chooses an integer type that does not necessarily match the mode we'll use on RTL? (thus, ptr_mode vs. Pmode issues, and/or sizeof (sizetype) != sizeof (void *) issues?) The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Hm, I see. On RTL would you get away with using REG_POINTER and paradoxical subregs for the offset operand? Sth like (add (reg:DI ptr) (subreg:DI (reg:SI off)))? Or even use a plain sign/zero_extend which is what expansion would generate at the moment I think. I suppose the HW either sign- or zero-extends that offset operand anyway. Basically your issue on trees is that pointer information is lost and (wide) integer operations appear? Note that IVOPTs at the moment does not try to generate lea-style pointer arithmetic while it could use TARGET_MEM_REF for this. We still assume that those addresses are within the object of operand zero (but if you use a literal zero as that operand and put the base somewhere else you might use that as a vehicle for telling GCC the arithmetic is not within C language scope). Richard.
Re: Preserve pointer types in ivopts
On 03/16/2012 01:55 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt ber...@codesourcery.com wrote: The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Hm, I see. On RTL would you get away with using REG_POINTER and paradoxical subregs for the offset operand? Sth like (add (reg:DI ptr) (subreg:DI (reg:SI off)))? No, because (reg:DI ptr) is the wrong representation. Pointers only take a single reg, and besides such subreg games would be extremely nasty. There's also the problem that this really isn't an arithmetic plus, since the top bits of the pointer are unaffected. Hence it doesn't commute: lea is a different operation than add. There is no other arithmetic that operates on Pmode, so it is impossible to use that mode for integer types. Well, not impossible - I have existence proof in the form of the port I inherited - but you have to lie pretty heavily to the compiler to even just make it limp along. Basically your issue on trees is that pointer information is lost and (wide) integer operations appear? That's the main issue, yes. Note that IVOPTs at the moment does not try to generate lea-style pointer arithmetic while it could use TARGET_MEM_REF for this. We still assume that those addresses are within the object of operand zero (but if you use a literal zero as that operand and put the base somewhere else you might use that as a vehicle for telling GCC the arithmetic is not within C language scope). Oh, ok. So IIUC maybe I can simply adjust the patch to still create POINTER_PLUS_EXPR in memory addresses, but use TARGET_MEM_REF for the arithmetic in initializing the ivs? Bernd
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 2:05 PM, Bernd Schmidt ber...@codesourcery.com wrote: On 03/16/2012 01:55 PM, Richard Guenther wrote: On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt ber...@codesourcery.com wrote: The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Hm, I see. On RTL would you get away with using REG_POINTER and paradoxical subregs for the offset operand? Sth like (add (reg:DI ptr) (subreg:DI (reg:SI off)))? No, because (reg:DI ptr) is the wrong representation. Pointers only take a single reg, and besides such subreg games would be extremely nasty. There's also the problem that this really isn't an arithmetic plus, since the top bits of the pointer are unaffected. Hence it doesn't commute: lea is a different operation than add. There is no other arithmetic that operates on Pmode, so it is impossible to use that mode for integer types. Well, not impossible - I have existence proof in the form of the port I inherited - but you have to lie pretty heavily to the compiler to even just make it limp along. Hmm, ok. So to have your lea represented on RTL you cannot use a fancy pattern using add because it would not be an add. Hmm. If it merely does not affect upper bits then (set (reg:SI ptr) (add (reg:SI ptr) (reg:SI off)) might work (if Pmode aka DImode is word_mode of course - otherwise the upper bits would be lost ...). Or of course an UNSPEC generated during address legitimization. Do we even have sth like address legitimization for pointer arithmetic? I suppose we should, when expanding POINTER_PLUS_EXPRs. Maybe simply dispatching through a two-mode optab for expanding POINTER_PLUS_EXPRs would suit you? Basically your issue on trees is that pointer information is lost and (wide) integer operations appear? That's the main issue, yes. Note that IVOPTs at the moment does not try to generate lea-style pointer arithmetic while it could use TARGET_MEM_REF for this. We still assume that those addresses are within the object of operand zero (but if you use a literal zero as that operand and put the base somewhere else you might use that as a vehicle for telling GCC the arithmetic is not within C language scope). Oh, ok. So IIUC maybe I can simply adjust the patch to still create POINTER_PLUS_EXPR in memory addresses, but use TARGET_MEM_REF for the arithmetic in initializing the ivs? Yes, that could work. Though it might end up being incredibly ugly ;) Richard. Bernd
[PATCH] Fix gfortran.dg/pr46259.f FAIL
With recent disturbed testing this FAIL got unnoticed. Fixed as follows
(we have a constantthat we'd like to replicate in a vector).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
* tree-vect-stmts.c (vect_get_vec_def_for_operand): Use
VIEW_CONVERT_EXPR to convert constants.
(vect_is_simple_use): Treat all constants as vec_constant_def.
Index: gcc/tree-vect-stmts.c
===
*** gcc/tree-vect-stmts.c (revision 185465)
--- gcc/tree-vect-stmts.c (working copy)
*** vect_get_vec_def_for_operand (tree op, g
*** 1271,1279
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Create vector_cst. nunits = %d, nunits);
! vec_cst = build_vector_from_val (vector_type,
!fold_convert (TREE_TYPE (vector_type),
! op));
return vect_init_vector (stmt, vec_cst, vector_type, NULL);
}
--- 1271,1283
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Create vector_cst. nunits = %d, nunits);
! if (!types_compatible_p (TREE_TYPE (vector_type), TREE_TYPE (op)))
! {
! op = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (vector_type), op);
! gcc_assert (op CONSTANT_CLASS_P (op));
! }
!
! vec_cst = build_vector_from_val (vector_type, op);
return vect_init_vector (stmt, vec_cst, vector_type, NULL);
}
*** vect_is_simple_use (tree operand, gimple
*** 5909,5915
print_generic_expr (vect_dump, operand, TDF_SLIM);
}
! if (TREE_CODE (operand) == INTEGER_CST || TREE_CODE (operand) == REAL_CST)
{
*dt = vect_constant_def;
return true;
--- 5913,5919
print_generic_expr (vect_dump, operand, TDF_SLIM);
}
! if (CONSTANT_CLASS_P (operand))
{
*dt = vect_constant_def;
return true;
Re: Preserve pointer types in ivopts
On 03/16/2012 02:15 PM, Richard Guenther wrote: Hmm, ok. So to have your lea represented on RTL you cannot use a fancy pattern using add because it would not be an add. Hmm. If it merely does not affect upper bits then (set (reg:SI ptr) (add (reg:SI ptr) (reg:SI off)) might work (if Pmode aka DImode is word_mode of course - otherwise the upper bits would be lost ...). It's not. Really, this isn't a problem right now. I already have a patch which makes a ptr_plus RTX code and handles it everywhere. Maybe simply dispatching through a two-mode optab for expanding POINTER_PLUS_EXPRs would suit you? padd_optab, yes. Yes, that could work. Though it might end up being incredibly ugly ;) In the code? Should really only change a few lines in the patch I would have thought. I'll get back to you when I have a new version - thanks for the tip. Bernd
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 2:18 PM, Bernd Schmidt ber...@codesourcery.com wrote: On 03/16/2012 02:15 PM, Richard Guenther wrote: Hmm, ok. So to have your lea represented on RTL you cannot use a fancy pattern using add because it would not be an add. Hmm. If it merely does not affect upper bits then (set (reg:SI ptr) (add (reg:SI ptr) (reg:SI off)) might work (if Pmode aka DImode is word_mode of course - otherwise the upper bits would be lost ...). It's not. Really, this isn't a problem right now. I already have a patch which makes a ptr_plus RTX code and handles it everywhere. Fair enough. Maybe simply dispatching through a two-mode optab for expanding POINTER_PLUS_EXPRs would suit you? padd_optab, yes. Yes, that could work. Though it might end up being incredibly ugly ;) In the code? Should really only change a few lines in the patch I would have thought. I'll get back to you when I have a new version - thanks for the tip. No, in the GIMPLE IL. Richard. Bernd
[PATCH] eh_personality.cc: unwinding on ARM
Hi,
I noticed a bug in the __ARM_EABI_UNWINDER__ case that shows up
as a loop in backtrace():
=== Backtrace: =
/lib/libc.so.6[0x4c8c11cc]
/lib/libc.so.6[0x4c8c62a8]
/lib/libc.so.6(cfree+0x38)[0x4c8c63a8]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
[.. and so on]
while a proper callstack (with demangled names and libunwind) looks like:
== backtrace (libunwind):
./bt( libunwind_backtrace +0x30)[0xb4a4]
./bt( eh_stack_unwind +0xe0)[0xb3c0]
./bt[0xc704]
/lib/libc.so.6( __default_rt_sa_restorer_v2 +0x0)[0x4c883770]
/lib/libc.so.6( gsignal +0x40)[0x4c88241c]
/lib/libc.so.6( abort +0x1c0)[0x4c88680c]
/lib/libc.so.6[0x4c8b726c]
/lib/libc.so.6[0x4c8c11cc]
/lib/libc.so.6[0x4c8c62a8]
/lib/libc.so.6( cfree +0x38)[0x4c8c63a8]
./bt( nqueen(int*, int, int) +0xf0)[0xa8e0]
./bt( main +0x230)[0xac6c]
/lib/libc.so.6( __libc_start_main +0x120)[0x4c86d104]
./bt[0xa510]
The CodeSourcery toolchain contains a fix like the following,
please consider for adding it.
Best regards
Peter Wächtler
--- eh_personality.cc.orig 2012-02-28 16:35:20.0 +0100
+++ eh_personality.cc 2012-02-28 18:12:03.0 +0100
@@ -387,6 +386,9 @@
switch (state _US_ACTION_MASK)
{
case _US_VIRTUAL_UNWIND_FRAME:
+ if (state _US_FORCE_UNWIND)
+ CONTINUE_UNWINDING;
+
actions = _UA_SEARCH_PHASE;
break;
[PATCH] eh_personality.cc: unwinding on ARM
Sorry this is a resend with corrected email addresses,
I noticed a bug in the __ARM_EABI_UNWINDER__ case that shows up
as a loop in backtrace():
=== Backtrace: =
/lib/libc.so.6[0x4c8c11cc]
/lib/libc.so.6[0x4c8c62a8]
/lib/libc.so.6(cfree+0x38)[0x4c8c63a8]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
./bt(_Z6nqueenPiii+0xf0)[0xa8e0]
[.. and so on]
while a proper callstack (with demangled names and libunwind) looks like:
== backtrace (libunwind):
./bt( libunwind_backtrace +0x30)[0xb4a4]
./bt( eh_stack_unwind +0xe0)[0xb3c0]
./bt[0xc704]
/lib/libc.so.6( __default_rt_sa_restorer_v2 +0x0)[0x4c883770]
/lib/libc.so.6( gsignal +0x40)[0x4c88241c]
/lib/libc.so.6( abort +0x1c0)[0x4c88680c]
/lib/libc.so.6[0x4c8b726c]
/lib/libc.so.6[0x4c8c11cc]
/lib/libc.so.6[0x4c8c62a8]
/lib/libc.so.6( cfree +0x38)[0x4c8c63a8]
./bt( nqueen(int*, int, int) +0xf0)[0xa8e0]
./bt( main +0x230)[0xac6c]
/lib/libc.so.6( __libc_start_main +0x120)[0x4c86d104]
./bt[0xa510]
The CodeSourcery toolchain contains a fix like the following,
please consider for adding it.
Best regards
Peter Wächtler
--- eh_personality.cc.orig 2012-02-28 16:35:20.0 +0100
+++ eh_personality.cc 2012-02-28 18:12:03.0 +0100
@@ -387,6 +386,9 @@
switch (state _US_ACTION_MASK)
{
case _US_VIRTUAL_UNWIND_FRAME:
+ if (state _US_FORCE_UNWIND)
+ CONTINUE_UNWINDING;
+
actions = _UA_SEARCH_PHASE;
break;
Re: Preserve pointer types in ivopts
Yes, that could work. ?Though it might end up being incredibly ugly ;) In the code? Should really only change a few lines in the patch I would have thought. I'll get back to you when I have a new version - thanks for the tip. No, in the GIMPLE IL. Richard. And I can just imagine how happy would other optimizations be about such a change. Are we speaking about something that you would like to get into mainline? All of this looks like a lot of hacks to deal with a rather weird target. Zdenek
Re: Preserve pointer types in ivopts
On 03/16/2012 02:33 PM, Zdenek Dvorak wrote: Yes, that could work. ?Though it might end up being incredibly ugly ;) In the code? Should really only change a few lines in the patch I would have thought. I'll get back to you when I have a new version - thanks for the tip. No, in the GIMPLE IL. Richard. And I can just imagine how happy would other optimizations be about such a change. Are we speaking about something that you would like to get into mainline? All of this looks like a lot of hacks to deal with a rather weird target. The final piece - using TARGET_MEM_REF rather than POINTER_PLUS_EXPR to avoid overflow issues - is clearly a bit of a hack. But otherwise, keeping around the proper types rather than casting everything to unsigned int is IMO much less ugly and hackish than what we have now. Certainly the gimple IL is much less cluttered after the patch than before. Bernd
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 2:37 PM, Bernd Schmidt ber...@codesourcery.com wrote: On 03/16/2012 02:33 PM, Zdenek Dvorak wrote: Yes, that could work. ?Though it might end up being incredibly ugly ;) In the code? Should really only change a few lines in the patch I would have thought. I'll get back to you when I have a new version - thanks for the tip. No, in the GIMPLE IL. Richard. And I can just imagine how happy would other optimizations be about such a change. Are we speaking about something that you would like to get into mainline? All of this looks like a lot of hacks to deal with a rather weird target. The final piece - using TARGET_MEM_REF rather than POINTER_PLUS_EXPR to avoid overflow issues - is clearly a bit of a hack. But otherwise, keeping around the proper types rather than casting everything to unsigned int is IMO much less ugly and hackish than what we have now. Certainly the gimple IL is much less cluttered after the patch than before. Btw, at one point I thought we might use Pmode integer types as base pointer types for [TARGET_]MEM_REF. But of course your target shows that this might not be a good idea. We do have three pointer offsetting operations at the moment, POINTER_PLUS_EXPR, MEM_REF and TARGET_MEM_REF. All of which expect C pointer semantics (if they can see the base pointer, which is why I suggested to create a TARGET_MEM_REF with a NULL pointer TMR_BASE and shove the base pointer to TMR_INDEX2 (which incidentially needs to be an integer type ...). In the end what we want is a POINTER_PLUS_EXPR variant that does not make alias-analysis assume the result still points to within the objects the pointer pointed to before the increment/decrement. Btw, how do you handle pointer differences? The frontend already lowers them to (intptr_t)ptr1 - (intptr_t)ptr2. Richard. Bernd
Re: Preserve pointer types in ivopts
On 03/16/2012 02:46 PM, Richard Guenther wrote: We do have three pointer offsetting operations at the moment, POINTER_PLUS_EXPR, MEM_REF and TARGET_MEM_REF. All of which expect C pointer semantics (if they can see the base pointer, which is why I suggested to create a TARGET_MEM_REF with a NULL pointer TMR_BASE and shove the base pointer to TMR_INDEX2 (which incidentially needs to be an integer type ...). Oh; looks like misunderstood your suggestion about TARGET_MEM_REF. Maybe I'll just have to bite the bullet and make a new tree code. Btw, how do you handle pointer differences? The frontend already lowers them to (intptr_t)ptr1 - (intptr_t)ptr2. More new stuff: targetm.pointer_mode_real_precision. Also, modifications in tree-ssa-loop-niter to use the new baseptr capability in tree-affine and subtract just the offsets in sizetype if possible. Bernd
Re: [PATCH 3/3] Misaligned MEM_REF reads
On Wed, 14 Mar 2012, Martin Jambor wrote:
Hi,
On Mon, Mar 12, 2012 at 03:09:04PM +0100, Martin Jambor wrote:
Hi,
this patch is very similar to the one I posted before
(http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01377.html) except that
it is now adjusted to sit on top of the new one before this and does
not ignore complex numbers...
This is the same patch updated to apply on top of the new version of
the previous one (which I have committed a moment ago). Again,
bootstrapped and tested on x86_64-linux (all languages including Ada
and Java), usparc64-linux (without Java) and ia64-linux (without
Ada), the i686 compile farm machine was not accessible yesterday so I
don't have any results from it but will start a test right now.
OK for trunk?
Ok.
Thanks,
Richard.
Thanks,
Martin
2012-03-12 Martin Jambor mjam...@suse.cz
* expr.c (expand_expr_real_1): handle misaligned scalar reads from
memory through MEM_REFs by calling extract_bit_field.
* testsuite/gcc.dg/misaligned-expand-1.c: New test.
* testsuite/gcc.dg/misaligned-expand-3.c: Likewise.
Index: src/gcc/expr.c
===
--- src.orig/gcc/expr.c
+++ src/gcc/expr.c
@@ -9411,21 +9411,27 @@ expand_expr_real_1 (tree exp, rtx target
MEM_VOLATILE_P (temp) = 1;
if (modifier != EXPAND_WRITE
mode != BLKmode
- align GET_MODE_ALIGNMENT (mode)
- /* If the target does not have special handling for unaligned
-loads of mode then it can use regular moves for them. */
- ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
+ align GET_MODE_ALIGNMENT (mode))
{
- struct expand_operand ops[2];
+ if ((icode = optab_handler (movmisalign_optab, mode))
+ != CODE_FOR_nothing)
+ {
+ struct expand_operand ops[2];
- /* We've already validated the memory, and we're creating a
-new pseudo destination. The predicates really can't fail,
-nor can the generator. */
- create_output_operand (ops[0], NULL_RTX, mode);
- create_fixed_operand (ops[1], temp);
- expand_insn (icode, 2, ops);
- return ops[0].value;
+ /* We've already validated the memory, and we're creating a
+new pseudo destination. The predicates really can't fail,
+nor can the generator. */
+ create_output_operand (ops[0], NULL_RTX, mode);
+ create_fixed_operand (ops[1], temp);
+ expand_insn (icode, 2, ops);
+ return ops[0].value;
+ }
+ else if (SLOW_UNALIGNED_ACCESS (mode, align))
+ temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
+ 0, TYPE_UNSIGNED (TREE_TYPE (exp)),
+ true, (modifier == EXPAND_STACK_PARM
+? NULL_RTX : target),
+ mode, mode);
}
return temp;
}
Index: src/gcc/testsuite/gcc.dg/misaligned-expand-1.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/misaligned-expand-1.c
@@ -0,0 +1,41 @@
+/* Test that expand can generate correct loads of misaligned data even on
+ strict alignment platforms. */
+
+/* { dg-do run } */
+/* { dg-options -O0 } */
+
+extern void abort ();
+
+typedef unsigned int myint __attribute__((aligned(1)));
+
+unsigned int
+foo (myint *p)
+{
+ return *p;
+}
+
+#define cst 0xdeadbeef
+#define NUM 8
+
+struct blah
+{
+ char c;
+ myint i[NUM];
+};
+
+struct blah g;
+
+int
+main (int argc, char **argv)
+{
+ int i, k;
+ for (k = 0; k NUM; k++)
+{
+ g.i[k] = cst;
+ i = foo (g.i[k]);
+
+ if (i != cst)
+ abort ();
+}
+ return 0;
+}
Index: src/gcc/testsuite/gcc.dg/misaligned-expand-3.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/misaligned-expand-3.c
@@ -0,0 +1,43 @@
+/* Test that expand can generate correct stores to misaligned data of complex
+ type even on strict alignment platforms. */
+
+/* { dg-do run } */
+/* { dg-options -O0 } */
+
+extern void abort ();
+
+typedef _Complex float mycmplx __attribute__((aligned(1)));
+
+void
+foo (mycmplx *p, float r, float i)
+{
+ __real__ *p = r;
+ __imag__ *p = i;
+}
+
+#define cvr 3.2f
+#define cvi 2.5f
+#define NUM 8
+
+struct blah
+{
+ char c;
+ mycmplx x[NUM];
+} __attribute__((packed));
+
+struct blah g;
+
+int
+main (int argc, char **argv)
+{
+ int k;
+
+ for (k = 0; k NUM; k++)
+{
+ foo (g.x[k], cvr, cvi);
+ if (__real__ g.x[k] != cvr
+ || __imag__ g.x[k] != cvi)
+
Re: [debug/profile-mode] broken c++config.h
2012/3/16 Paweł Sikora:
Hi,
during gcc build process there's some sed magic
(libstdc++-v3/include/Makefile.{am,in}) in action
which modifies libstdc++/include/bits/c++config.h (replaces '#define
_GLIBCXX_EXTERN_TEMPLATE'
according to --enable-extern-template=yes/no settings). in fact, this sed
rule also produces
a wrong '#define _GLIBCXX_EXTERN_TEMPLATE 1 -1' in line 293:
#if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE)
# define _GLIBCXX_STD_C __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
namespace _GLIBCXX_STD_C { _GLIBCXX_BEGIN_NAMESPACE_VERSION
# define _GLIBCXX_END_NAMESPACE_CONTAINER \
} _GLIBCXX_END_NAMESPACE_VERSION
# undef _GLIBCXX_EXTERN_TEMPLATE
# define _GLIBCXX_EXTERN_TEMPLATE 1 -1 here
#endif
this broken macro causes runtime errors on mingw (see PR52540).
attached small patch fixes all weird runtime errors for me.
Should the addition be \$$ to escape it for the shell as well as for make?
(I know it works, but that might not be true for all shells.)
The diff for Makefile.in is unnecessary, as it should be regenerated
from Makefile.am
Apart from that the patch looks good, I've CC'd gcc-patches, could you
provide a changelog entry?
Thanks.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 1e9b144..b099580 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1105,7 +1105,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
sed -e s,define __GLIBCXX__,define __GLIBCXX__ $$date, \
-e s,define _GLIBCXX_INLINE_VERSION, define _GLIBCXX_INLINE_VERSION $$ns_version, \
-e s,define _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY, define _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY $$visibility, \
- -e s,define _GLIBCXX_EXTERN_TEMPLATE, define _GLIBCXX_EXTERN_TEMPLATE $$externtemplate, \
+ -e s,define _GLIBCXX_EXTERN_TEMPLATE$$, define _GLIBCXX_EXTERN_TEMPLATE $$externtemplate, \
-e $$ldbl_compat \
${glibcxx_srcdir}/include/bits/c++config $@ ;\
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 19a7c0e..9344d46 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1497,7 +1497,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
sed -e s,define __GLIBCXX__,define __GLIBCXX__ $$date, \
-e s,define _GLIBCXX_INLINE_VERSION, define _GLIBCXX_INLINE_VERSION $$ns_version, \
-e s,define _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY, define _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY $$visibility, \
- -e s,define _GLIBCXX_EXTERN_TEMPLATE, define _GLIBCXX_EXTERN_TEMPLATE $$externtemplate, \
+ -e s,define _GLIBCXX_EXTERN_TEMPLATE$$, define _GLIBCXX_EXTERN_TEMPLATE $$externtemplate, \
-e $$ldbl_compat \
${glibcxx_srcdir}/include/bits/c++config $@ ;\
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
[wwwdocs] Fix some nits in GCC 4.7 changes.html
While reading through the GCC 4.7 changes.html, I noticed a couple of
nits that this patch fixes. It's mostly wording and grammar changes (so
I may well be wrong and would appreciate a native speaker having a look ;-)
Ok to install?
Beyond what I've changed, two items could perhaps do with better
explanations, especially since the document is intended to be directed
at compiler users, not compiler developers:
* LTO improvements:
Streaming performance (both outbound and inbound) has been improved.
What is this and why should I care?
* IA-32/x86-64:
Support for new Intel processor codename IvyBridge with RDRND,
FSGSBASE and F16C
Support for the new Intel processor codename Haswell with AVX2, FMA,
BMI, BMI2, LZCNT
Better: with the ... extensions? Add links?
Rainer
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.96
diff -u -p -r1.96 changes.html
--- changes.html 7 Mar 2012 14:15:35 - 1.96
+++ changes.html 16 Mar 2012 14:47:44 -
@@ -126,7 +126,7 @@
pre
void foo(int a)
{
- if (agt;10)
+ if (a gt; 10)
... huge code ...
}
void bar (void)
@@ -166,7 +166,7 @@ void bar (void)
GCC will now produce two copies of codefoo/code. One with codeflag/code being
codetrue/code, while other with codeflag/code being
codefalse/code. This leads to performance improvements previously
- possibly only by inlining all calls. Cloning causes a lot less code size
+ possible only by inlining all calls. Cloning causes a lot less code size
growth./li
/ul/li
@@ -242,20 +242,21 @@ void foo (char *a, const char *b, const
li
p
Experimental support for transactional memory has been added.
- It includes support for the compiler, as well as a supporting
+ It includes support in the compiler, as well as a supporting
runtime library called codelibitm/code. To compile code
with transactional memory constructs, use
the code-fgnu-tm/code option.
/p
p
- Support is currently available for the x86-32, x86-64, and Alpha
- platforms.
+ Support is currently available for Alpha, ARM, PowerPC, SH, SPARC,
+ and 32-bit/64-bit x86 platforms.
/p
p
For more details on transactional memory
- see a href=http://gcc.gnu.org/wiki/TransactionalMemory;here/a.
+ see a href=http://gcc.gnu.org/wiki/TransactionalMemory;the GCC
+ WiKi/a.
/p
/li
@@ -266,11 +267,11 @@ void foo (char *a, const char *b, const
existing code__sync/code built-in routines.
/p
p
- Atomic support is also available for memory blocks. Lock free
+ Atomic support is also available for memory blocks. Lock-free
instructions will be used if a memory block is the same size and
alignment as a supported integer type. Atomic operations which do not
- have lock free support are left as function calls. A set of library
- functions are available on the GCC atomic wiki in the External
+ have lock-free support are left as function calls. A set of library
+ functions is available on the GCC atomic wiki in the External
Atomics Library section.
/p
p
@@ -279,8 +280,8 @@ void foo (char *a, const char *b, const
/p
/li
- liWhen a binary operation performed on vector types and one of the operands
- is a uniform vector it is possible to replace the vector with the
+ liWhen a binary operation is performed on vector types and one of the operands
+ is a uniform vector, it is possible to replace the vector with the
generating element. For example:
pre
typedef int v4si __attribute__ ((vector_size (16)));
@@ -352,7 +353,7 @@ struct B {
};
struct D : B {
- void f() const;// error: D::f attempts to override final B::f
+ void f() const;// error: D::f attempts to override final B::f
void f(long) override; // error: doesn't override anything
void f(int) override; // ok
};
@@ -499,7 +500,7 @@ well./p/li
/li
liAdded code--enable-clocale=newlib/code configure option. /li
liDebug Mode iterators for unordered associative containers. /li
- liAvoid polluting the global namespace by inclusion of codelt;unistd.hgt;/code. /li
+ liDon't include codelt;unistd.hgt;/code to avoid polluting the global namespace./li
/ul
@@ -509,7 +510,7 @@ well./p/li
liThe compile flag a
href=http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack_002darrays_007d-254;
code-fstack-arrays/code/a has been added, which causes
- that all local arrays are put on stack memory. For some
+ all local arrays to be put on stack memory. For some
programs this will improve the performance significantly. If your
program uses very large local arrays, it is possible
Re: [PATCH] gfortran testsuite: implicitly cleanup-modules
On Fri, Mar 16, 2012 at 11:04:45AM +0100, Bernhard Reutner-Fischer wrote:
The underlying problem is that dejagnu's runtest.exp only allows for a
single libdir where it searches for includes -- see comment in
libgomp.exp and libitm.exp
While just adding more and more load_gcc_lib calls to users outside of
gcc/ is the easy way out, it is (IMHO) error prone (i ran make check
just in gcc and not in toplevel, fixed my script now).
It would be desirable if dejagnu would just find all the currently
load_gcc_lib'ed files on its own, via load_lib.
One could
- teach dejagnu to treat libdir as a list of paths
The attached works for me for a toplevel make -k check (double-checked
with individual make check in lib{gomp,itm}). I do not intend to pursue
this any further.
runtest.exp: add libdirs list for load_lib()
libgomp wants to load .exp files from ../gcc/testsuite/lib.
Instrument load_lib to be able to find the files.
Previously we used to have a helper proc that had to first load all
dependent .exp manually and then, again manually, the desired .exp.
2012-03-16 Bernhard Reutner-Fischer al...@gcc.gnu.org
* runtest.exp (libdirs): New global list.
(load_lib): Append libdirs to search_and_load_files directories.
diff --git a/runtest.exp b/runtest.exp
index 4bfed83..8e6a7de 100644
--- a/runtest.exp
+++ b/runtest.exp
@@ -589,7 +589,7 @@ proc lookfor_file { dir name } {
# source tree, (up one or two levels), then in the current dir.
#
proc load_lib { file } {
-global verbose libdir srcdir base_dir execpath tool
+global verbose libdir libdirs srcdir base_dir execpath tool
global loaded_libs
if {[info exists loaded_libs($file)]} {
@@ -597,8 +597,11 @@ proc load_lib { file } {
}
set loaded_libs($file)
-
-if { [search_and_load_file library file $file [list ../lib $libdir $libdir/lib [file dirname [file dirname $srcdir]]/dejagnu/lib $srcdir/lib $execpath/lib . [file dirname [file dirname [file dirname $srcdir]]]/dejagnu/lib]] == 0 } {
+set search_dirs [list ../lib $libdir $libdir/lib [file dirname [file dirname $srcdir]]/dejagnu/lib $srcdir/lib $execpath/lib . [file dirname [file dirname [file dirname $srcdir]]]/dejagnu/lib]
+if {[info exists libdirs]} {
+lappend search_dirs $libdirs
+}
+if { [search_and_load_file library file $file $search_dirs ] == 0 } {
send_error ERROR: Couldn't find library file $file.\n
exit 1
}
@@ -652,6 +655,8 @@ set libdir [file dirname $execpath]/dejagnu
if {[info exists env(DEJAGNULIBS)]} {
set libdir $env(DEJAGNULIBS)
}
+# list of extra directories for load_lib
+set libdirs {}
verbose Using $libdir to find libraries
libgomp/ChangeLog
2012-03-16 Bernhard Reutner-Fischer al...@gcc.gnu.org
* testsuite/lib/libgomp.exp: Set libdirs. Remove now redundant
manual inclusion of gfortran-dg's dependencies.
libitm/ChangeLog
2012-03-16 Bernhard Reutner-Fischer al...@gcc.gnu.org
* testsuite/lib/libitm.exp: Set libdirs. Remove now redundant
manual inclusion of gcc-dg's dependencies.
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 02909f8..54e1e652 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -1,32 +1,12 @@
-# Damn dejagnu for not having proper library search paths for load_lib.
-# We have to explicitly load everything that gcc-dg.exp wants to load.
+global libdirs
+lappend libdirs $srcdir/../../gcc/testsuite/lib
-proc load_gcc_lib { filename } {
-global srcdir loaded_libs
+load_lib dg.exp
-load_file $srcdir/../../gcc/testsuite/lib/$filename
-set loaded_libs($filename)
-}
+# BUG: gcc-dg calls gcc-set-multilib-library-path but does not load gcc-defs!
+load_lib gcc-defs.exp
-load_lib dg.exp
-load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
-load_gcc_lib target-supports-dg.exp
-load_gcc_lib scanasm.exp
-load_gcc_lib scandump.exp
-load_gcc_lib scanrtl.exp
-load_gcc_lib scantree.exp
-load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
-load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
-load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
-load_gcc_lib gfortran-dg.exp
+load_lib gfortran-dg.exp
set dg-do-what-default run
diff --git a/libitm/testsuite/lib/libitm.exp b/libitm/testsuite/lib/libitm.exp
index f322ed5..1ac8f31 100644
--- a/libitm/testsuite/lib/libitm.exp
+++ b/libitm/testsuite/lib/libitm.exp
@@ -12,34 +12,15 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# Damn dejagnu for not having proper library search paths for load_lib.
-# We have to explicitly load everything that gcc-dg.exp wants to load.
+global libdirs
+lappend libdirs $srcdir/../../gcc/testsuite/lib
-proc load_gcc_lib { filename } {
-global srcdir loaded_libs
+load_lib dg.exp
-
Re: [Patch IA64]: Fix 32 bits tablejump
On 03/16/12 04:56, Tristan Gingold wrote: 2012-03-16 Tristan Gingold ging...@adacore.com * config/ia64/vms.h (CASE_VECTOR_MODE): Define. * config/ia64/ia64.md: Remove mode in template. Sign extend operand in expand_simple_binop. * config/ia64/ia64.h (ASM_OUTPUT_ADDR_DIFF_ELT): Use CASE_VECTOR_MODE instead of TARGET_ILP32. (ADDR_VEC_ALIGN): Make it depends on CASE_VECTOR_MODE. Ok. r~
Re: [debug/profile-mode] broken c++config.h
On 03/16/2012 03:29 PM, Jonathan Wakely wrote: Apart from that the patch looks good, I've CC'd gcc-patches, could you provide a changelog entry? If this kind of change to the makefile turns out to be applied I think should go essentially everywhere, at least 4.6 and 4.7(.1) besides mainline. Paolo.
Re: [google/4.6] Fix problems with -gfission (issue 5844043)
On 2012/03/16 02:07:02, Cary wrote: For google/gcc-4_6 branch. This patch fixes several problems with -gfission: - Bad index for range list in the compile unit DIE. - DW_AT_ranges attribute for compile unit in the wrong file. - Incorrect size for skeleton type unit DIEs. - Wrote location expression using DW_OP_addr to DWO file. - Emitted skeleton debug section even when there is no debug info. Tested: bootstrap, gcc regression tests, hand testing on -gfission test cases. These are OK for google 4_6. http://codereview.appspot.com/5844043/
Re: Preserve pointer types in ivopts
On 03/16/2012 02:46 PM, Richard Guenther wrote: In the end what we want is a POINTER_PLUS_EXPR variant that does not make alias-analysis assume the result still points to within the objects the pointer pointed to before the increment/decrement. Hold on, is alias analysis really affected by this? Sure, we create temporary pointers that point outside their base object, but we don't dereference them. Anything value that ends up in a MEM_REF can only point into that object again. I would have thought that it's mainly in fold-const where a POINTER_PLUSV would be handled differently from POINTER_PLUS (e.g. in pointer comparisons). Bernd
Re: [debug/profile-mode] broken c++config.h
On Friday 16 of March 2012 14:29:21 Jonathan Wakely wrote:
2012/3/16 Paweł Sikora:
Hi,
during gcc build process there's some sed magic
(libstdc++-v3/include/Makefile.{am,in}) in action
which modifies libstdc++/include/bits/c++config.h (replaces '#define
_GLIBCXX_EXTERN_TEMPLATE'
according to --enable-extern-template=yes/no settings). in fact, this sed
rule also produces
a wrong '#define _GLIBCXX_EXTERN_TEMPLATE 1 -1' in line 293:
#if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE)
# define _GLIBCXX_STD_C __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
namespace _GLIBCXX_STD_C { _GLIBCXX_BEGIN_NAMESPACE_VERSION
# define _GLIBCXX_END_NAMESPACE_CONTAINER \
} _GLIBCXX_END_NAMESPACE_VERSION
# undef _GLIBCXX_EXTERN_TEMPLATE
# define _GLIBCXX_EXTERN_TEMPLATE 1 -1 here
#endif
this broken macro causes runtime errors on mingw (see PR52540).
attached small patch fixes all weird runtime errors for me.
Should the addition be \$$ to escape it for the shell as well as for make?
(I know it works, but that might not be true for all shells.)
i don't think that $, could be expaneded by any shell.
The diff for Makefile.in is unnecessary, as it should be regenerated
from Makefile.am
Apart from that the patch looks good, I've CC'd gcc-patches, could you
provide a changelog entry?
attached. i hope it's correct :)
2012-03-16 Paweł Sikora pawel.sik...@agmk.net
PR libstdc++/52540
* include/Makefile.am (c++config.h): Fix sed rule to not break
the _GLIBCXX_EXTERN_TEMPLATE redefinition.
* include/Makefile.in: Regenerated.
Re: Preserve pointer types in ivopts
Hello, On 03/16/2012 02:46 PM, Richard Guenther wrote: In the end what we want is a POINTER_PLUS_EXPR variant that does not make alias-analysis assume the result still points to within the objects the pointer pointed to before the increment/decrement. Hold on, is alias analysis really affected by this? Sure, we create temporary pointers that point outside their base object, but we don't dereference them. Anything value that ends up in a MEM_REF can only point into that object again. it can be affected; by standard pointer arithmetics rules, you cannot create a pointer that would be outside of an object (unless you convert it from an integer). Thus, alias analysis may deduce that if we have something like int a[100]; int *p = a + 10; int *q = p - i; *(q + 5) = 1; a[1] = 2; then q points inside a, and consequently q + 5 = a + 5, hence the assignments do not alias. Ivopts may however produce this (in an equivalent form with casts to unsigned) even if i 10. Zdenek
Re: [PATCH] Proper use of decl_function_context in dwar2out.c
Hi, On Mon, Mar 12, 2012 at 11:51:05AM +0100, Richard Guenther wrote: On Thu, Mar 8, 2012 at 12:18 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Mar 08, 2012 at 12:06:46PM +0100, Martin Jambor wrote: /* For local statics lookup proper context die. */ - if (TREE_STATIC (decl) decl_function_context (decl)) - context_die = lookup_decl_die (DECL_CONTEXT (decl)); + if (TREE_STATIC (decl) + (ctx_fndecl = decl_function_context (decl)) != NULL_TREE) + context_die = lookup_decl_die (ctx_fndecl); The formatting is wrong, shouldn't be at the end of line. For the rest I'll defer to Jason, not sure what exactly we want to do there. This hunk has been added by Honza: I don't think the patch is right. Suppose you have a function-local class declaration with a static member. Surely the context DIE you want to use is still the class one, not the function one. That is not what happens, though. The problem is that we attempt to generate debug info for VMTs of classes defined within functions. I have filed PR 52605 with a small testcase to track the issue. I have not yet had a look at how this code treats (or should treat) static members of classes defined within a function. Thanks, Martin
Re: Preserve pointer types in ivopts
On Fri, Mar 16, 2012 at 4:49 PM, Zdenek Dvorak rakd...@iuuk.mff.cuni.cz wrote:
Hello,
On 03/16/2012 02:46 PM, Richard Guenther wrote:
In the end what we want is a POINTER_PLUS_EXPR variant
that does not make alias-analysis assume the result still points
to within the objects the pointer pointed to before the
increment/decrement.
Hold on, is alias analysis really affected by this? Sure, we create
temporary pointers that point outside their base object, but we don't
dereference them. Anything value that ends up in a MEM_REF can only
point into that object again.
it can be affected; by standard pointer arithmetics rules, you cannot
create a pointer that would be outside of an object (unless you convert
it from an integer). Thus, alias analysis may deduce that if we have
something like
int a[100];
int *p = a + 10;
int *q = p - i;
*(q + 5) = 1;
a[1] = 2;
then q points inside a, and consequently q + 5 = a + 5, hence the
assignments do not alias. Ivopts may however produce this (in an equivalent
form with casts to unsigned) even if i 10.
See also the various invalid PRs that essentially do
foo (int *q)
{
int i;
int *p = i;
long x = q - p;
*(p + x) = 1;
}
thus, cleverly encode address-space differences relative to an unrelated
object (seen in Boost, for cross-shmem pointers for example). C obviously
does not allow the q - p operation, and points-to analysis thinks that
p + x points to i and thus we remove the unused store to the local variable.
Another alias assumption is in offset-based analysis which assumes you
cannot have a pointer to before the object, so *(T *)(p + 1) may not
alias a global of type 'T' (because by seeing p + 1 and the access of type
T we conclude that the object pointed to is at least of size sizeof (T) + 1).
Richard.
Zdenek
Re: LIPO based on LTO IR streaming (issue 5746044)
ok for google-46 after the minor changes below. Make sure default lipo testing is well covered too. David http://codereview.appspot.com/5746044/diff/11001/cgraph.c File cgraph.c (right): http://codereview.appspot.com/5746044/diff/11001/cgraph.c#newcode2887 cgraph.c:2887: !(L_IPO_STREAM_IN_LTO_P cgraph_is_auxiliary(node-decl))) Missing space http://codereview.appspot.com/5746044/diff/11001/coverage.c File coverage.c (right): http://codereview.appspot.com/5746044/diff/11001/coverage.c#newcode396 coverage.c:396: warning (0, error in opening %s, exiting, 0 - UNKNOWN_LOCATION http://codereview.appspot.com/5746044/diff/11001/coverage.c#newcode724 coverage.c:724: module_infos, num_in_fnames); Identation http://codereview.appspot.com/5746044/diff/11001/ipa.c File ipa.c (right): http://codereview.appspot.com/5746044/diff/11001/ipa.c#newcode678 ipa.c:678: Return true will make this symbol externally visible. Returning http://codereview.appspot.com/5746044/diff/11001/ipa.c#newcode679 ipa.c:679: Refurn false will continue current visibiliity logic. */ Returning http://codereview.appspot.com/5746044/
[PATCH] Fix PR52603
The comment before the hunk I moved wasn't helpful, so I moved the
flag_section_anchor check in error. Fixed by reverting that change
and clarifying the comment.
Richard.
2012-03-16 Richard Guenther rguent...@suse.de
PR tree-optimization/52603
* tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Clarify
comment.
Revert
2012-03-14 Richard Guenther rguent...@suse.de
PR tree-optimization/52571
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move
flag_section_anchors check ...
(vect_can_force_dr_alignment_p): ... here.
Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c (revision 185469)
--- gcc/tree-vect-data-refs.c (working copy)
*** vect_compute_data_ref_alignment (struct
*** 872,878
if (!base_aligned)
{
! if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype)))
{
if (vect_print_dump_info (REPORT_DETAILS))
{
--- 872,883
if (!base_aligned)
{
! /* Do not change the alignment of global variables here if
!flag_section_anchors is enabled as we already generated
!RTL for other functions. Most global variables should
!have been aligned during the IPA increase_alignment pass. */
! if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype))
! || (TREE_STATIC (base) flag_section_anchors)
{
if (vect_print_dump_info (REPORT_DETAILS))
{
*** vect_can_force_dr_alignment_p (const_tre
*** 4554,4564
if (TREE_ASM_WRITTEN (decl))
return false;
- /* Do not change the alignment of global variables if flag_section_anchors
- is enabled. */
- if (TREE_STATIC (decl) flag_section_anchors)
- return false;
-
if (TREE_STATIC (decl))
return (alignment = MAX_OFILE_ALIGNMENT);
else
--- 4559,4564
[PING*2][PATCH, 4.5, 4.6] Fix PR50181 by backporting mainline reload.c patches
I'd like to re-ping this patch backport: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01428.html Peter
Re: [debug/profile-mode] broken c++config.h
2012/3/16 Paweł Sikora: Should the addition be \$$ to escape it for the shell as well as for make? (I know it works, but that might not be true for all shells.) i don't think that $, could be expaneded by any shell. I'm not worried about it not expanding, but rather being rejected as invalid syntax - but maybe it's fine. It certainly works OK with bash and ksh. The diff for Makefile.in is unnecessary, as it should be regenerated from Makefile.am Apart from that the patch looks good, I've CC'd gcc-patches, could you provide a changelog entry? attached. i hope it's correct :) Looks great, thanks.
Re: LIPO based on LTO IR streaming (issue 5746044)
One spelling nit. May also want to explain the 'ripa' term more clearly somewhere. http://codereview.appspot.com/5746044/diff/11001/ipa.c File ipa.c (right): http://codereview.appspot.com/5746044/diff/11001/ipa.c#newcode811 ipa.c:811: (2) the VNODE is neede, and s/neede/needed/ http://codereview.appspot.com/5746044/
Re: [wwwdocs] Fix some nits in GCC 4.7 changes.html
On Fri, 16 Mar 2012, Rainer Orth wrote: While reading through the GCC 4.7 changes.html, I noticed a couple of nits that this patch fixes. It's mostly wording and grammar changes (so I may well be wrong and would appreciate a native speaker having a look This looks good in general, thanks. Instead of the change around pollution I would prefer Avoid polluting the global namespace and do not include... instead of either the old or the proposed version, though I'll admit I do not have a strong rationale. I am not sure about The powerpc vs The PowerPC vs powerpc, please pass that part by David Edelsohn. Similarly, are you sure code#pragma GCC target attribute/code change is incorrect. Isn't that a function attribute? Gerald
Re: Remove obsolete IRIX 6.5 support
Rainer == Rainer Orth r...@cebitec.uni-bielefeld.de writes: Rainer Continuing with the patches to remove obsolete ports, here's the Rainer IRIX 6.5 removal patch. Rainer * libjava/gnu/classpath/natSystemProperties.cc (getpwuid_adaptor) claims Rainer to be for IRIX, too, but I cannot tell for certain. It doesn't really hurt to leave it in; but if you want to remove it, that is fine by me as well. It is easy to resurrect on the off chance it breaks some obscure build. Rainer libjava: [...] The libjava parts are ok. Tom
Re: [PATCH] Proper use of decl_function_context in dwar2out.c
Hi, On Fri, Mar 16, 2012 at 05:14:38PM +0100, Martin Jambor wrote: On Mon, Mar 12, 2012 at 11:51:05AM +0100, Richard Guenther wrote: On Thu, Mar 8, 2012 at 12:18 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Mar 08, 2012 at 12:06:46PM +0100, Martin Jambor wrote: /* For local statics lookup proper context die. */ - if (TREE_STATIC (decl) decl_function_context (decl)) - context_die = lookup_decl_die (DECL_CONTEXT (decl)); + if (TREE_STATIC (decl) + (ctx_fndecl = decl_function_context (decl)) != NULL_TREE) + context_die = lookup_decl_die (ctx_fndecl); The formatting is wrong, shouldn't be at the end of line. For the rest I'll defer to Jason, not sure what exactly we want to do there. This hunk has been added by Honza: I don't think the patch is right. Suppose you have a function-local class declaration with a static member. Surely the context DIE you want to use is still the class one, not the function one. That is not what happens, though. The problem is that we attempt to generate debug info for VMTs of classes defined within functions. I have filed PR 52605 with a small testcase to track the issue. I have not yet had a look at how this code treats (or should treat) static members of classes defined within a function. It turs out that local classes are not allowed to have static data members. GCC will compile such class with -fpermissive but then the linker fails with an undefined reference because the data member is not defined anywhere and I did not manage to figure out or google how to define it. Therefore I think this is not an issue. It seems to me that dwarf2out_decl was intended to supply either comp_unit_die or a function decl die as the context to gen_decl_die (which detects memberr-ness by decl_class_context) and thus I still tend to think my patch (with adjusted formatting) is a correct and simple fix. Nevertheless I'll be happy to learn more if I am wrong. Martin
Re: Preserve pointer types in ivopts
On 03/16/12 05:36, Bernd Schmidt wrote: The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Surely the least amount of work is to not use sizetype/intptr_t, but a custom type that has the same bit-width as a pointer? r~
Re: [v3] fix libstdc++/52476
Attached patch applied.
2012-03-16 François Dumont fdum...@gcc.gnu.org
PR libstdc++/52476
* include/bits/hashtable.h (_Hashtable::_M_rehash_aux): Add.
(_Hashtable::_M_rehash): Use the latter.
* testsuite/23_containers/unordered_multimap/insert/52476.cc: New.
* testsuite/23_containers/unordered_multiset/insert/52476.cc: New.
Regards
On 03/16/2012 10:19 AM, Paolo Carlini wrote:
Hi,
Regarding the testcase, the code in the ticket is showing the problem but
is not a test. The test might seem a little bit complicated but I try to make
it independent to how elements are inserted into the container which is not
defined by the Standard. Even if we change implementation and store
0-3,0-2,0-1,0-0 rather than 0-0,0-1,0-2,0-3 the test will still work and only
check the Standard point which is that the order of those elements should be
preserve on rehash.
Understood, thanks for adding a second testcase for multiset.
Tested under Linux x86_64.
Ok for mainline ?
Yes, thanks a lot. Please keep in mind that barring special issues we want the
fix for 4.7.1 too.
Thanks
Paolo
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h (revision 185475)
+++ include/bits/hashtable.h (working copy)
@@ -596,6 +596,12 @@
// reserve, if present, comes from _Rehash_base.
private:
+ // Helper rehash method used when keys are unique.
+ void _M_rehash_aux(size_type __n, std::true_type);
+
+ // Helper rehash method used when keys can be non-unique.
+ void _M_rehash_aux(size_type __n, std::false_type);
+
// Unconditionally change size of bucket array to n, restore hash policy
// state to __state on exception.
void _M_rehash(size_type __n, const _RehashPolicyState __state);
@@ -1592,41 +1598,145 @@
{
__try
{
- _Bucket* __new_buckets = _M_allocate_buckets(__n);
- _Node* __p = _M_begin();
- _M_before_begin._M_nxt = nullptr;
- std::size_t __cur_bbegin_bkt;
- while (__p)
+ _M_rehash_aux(__n, integral_constantbool, __uk());
+ }
+ __catch(...)
+ {
+ // A failure here means that buckets allocation failed. We only
+ // have to restore hash policy previous state.
+ _M_rehash_policy._M_reset(__state);
+ __throw_exception_again;
+ }
+}
+
+ // Rehash when there is no equivalent elements.
+ templatetypename _Key, typename _Value,
+ typename _Allocator, typename _ExtractKey, typename _Equal,
+ typename _H1, typename _H2, typename _Hash, typename _RehashPolicy,
+ bool __chc, bool __cit, bool __uk
+void
+_Hashtable_Key, _Value, _Allocator, _ExtractKey, _Equal,
+ _H1, _H2, _Hash, _RehashPolicy, __chc, __cit, __uk::
+_M_rehash_aux(size_type __n, std::true_type)
+{
+ _Bucket* __new_buckets = _M_allocate_buckets(__n);
+ _Node* __p = _M_begin();
+ _M_before_begin._M_nxt = nullptr;
+ std::size_t __bbegin_bkt;
+ while (__p)
+ {
+ _Node* __next = __p-_M_next();
+ std::size_t __bkt = _HCBase::_M_bucket_index(__p, __n);
+ if (!__new_buckets[__bkt])
{
- _Node* __next = __p-_M_next();
- std::size_t __new_index = _HCBase::_M_bucket_index(__p, __n);
- if (!__new_buckets[__new_index])
+ __p-_M_nxt = _M_before_begin._M_nxt;
+ _M_before_begin._M_nxt = __p;
+ __new_buckets[__bkt] = _M_before_begin;
+ if (__p-_M_nxt)
+ __new_buckets[__bbegin_bkt] = __p;
+ __bbegin_bkt = __bkt;
+ }
+ else
+ {
+ __p-_M_nxt = __new_buckets[__bkt]-_M_nxt;
+ __new_buckets[__bkt]-_M_nxt = __p;
+ }
+ __p = __next;
+ }
+ _M_deallocate_buckets(_M_buckets, _M_bucket_count);
+ _M_bucket_count = __n;
+ _M_buckets = __new_buckets;
+}
+
+ // Rehash when there can be equivalent elements, preserve their relative
+ // order.
+ templatetypename _Key, typename _Value,
+ typename _Allocator, typename _ExtractKey, typename _Equal,
+ typename _H1, typename _H2, typename _Hash, typename _RehashPolicy,
+ bool __chc, bool __cit, bool __uk
+void
+_Hashtable_Key, _Value, _Allocator, _ExtractKey, _Equal,
+ _H1, _H2, _Hash, _RehashPolicy, __chc, __cit, __uk::
+_M_rehash_aux(size_type __n, std::false_type)
+{
+ _Bucket* __new_buckets = _M_allocate_buckets(__n);
+
+ _Node* __p = _M_begin();
+ _M_before_begin._M_nxt = nullptr;
+ std::size_t __bbegin_bkt;
+ std::size_t __prev_bkt;
+ _Node* __prev_p = nullptr;
+ bool __check_bucket = false;
+
+ while (__p)
+ {
+ bool __check_now = true;
+ _Node* __next = __p-_M_next();
+ std::size_t __bkt = _HCBase::_M_bucket_index(__p, __n);
+
+ if (!__new_buckets[__bkt])
+ {
+ __p-_M_nxt = _M_before_begin._M_nxt;
+ _M_before_begin._M_nxt = __p;
+ __new_buckets[__bkt] = _M_before_begin;
+ if (__p-_M_nxt)
+ __new_buckets[__bbegin_bkt] = __p;
+ __bbegin_bkt = __bkt;
+ }
+
PING [RFA] PowerPC e5500 and e6500 cores support
I am pinging this post: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00430.html Thanks Edmar
Re: RFA: consolidate DWARF strings into libiberty
On 03/15/12 12:29, Tom Tromey wrote: 2012-03-15 Tom Tromey tro...@redhat.com * dwarf2out.c (dwarf_stack_op_name): Use get_DW_OP_name. (dwarf_tag_name): Use get_DW_TAG_name. (dwarf_attr_name): Use get_DW_AT_name. (dwarf_form_name): Use get_DW_FORM_name. * dwarf2cfi.c (dwarf_cfi_name): Use get_DW_CFA_name. Gcc parts ok. r~
[C++ Patch] PR 14710 (add -Wuseless-cast)
Hi,
this is what I did to add the warning requested in the PR. Among the
slightly less trivial bits:
1- In order not to risk warning *before* an hard error is produced by
build_*_cast_1 code, I'm warning only if the cast is actually
successful, thus at the end of each build_*_cast function.
2- In order not to warn when the useless cast shows up upon template
instantiation I'm using here too the c_inhibit_evaluation_warnings trick
(as we do already for warn_sign_compare, I believe).
3- References can be easily missed because wrapped in INDIRECT_REF: as
explained at the beginning of tree.c and already used in many places, a
REFERENCE_REF_P check (and in case a TREE_OPERAND (expr, 0)) takes care
of that. I'm not 100% sure the solution is fully general, though.
4- I'm naming the function implementing the warning itself
maybe_warn_about_useless_cast, which seems consistent with the name of
at least another warning in typeck.c but other options are possible, of
course...
Booted and tested x86_64-linux.
Thanks,
Paolo.
//
2012-03-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/14710
* doc/invoke.texi: Document -Wuseless-cast.
/c-family
2012-03-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/14710
* c.opt ([Wuseless-cast]): Add.
/cp
2012-03-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/14710
* cp-tree.h (maybe_warn_about_useless_cast): Declare.
* typeck.c (maybe_warn_about_useless_cast): Define.
(build_reinterpret_cast, build_const_cast,
build_static_cast, cp_build_c_cast): Use it.
* rtti.c (build_dynamic_cast): Likewise.
* pt.c (tsubst_copy_and_build, case CAST_EXPR): Increment/decrement
c_inhibit_evaluation_warnings before/after the build_* calls.
/testsuite
2012-03-16 Paolo Carlini paolo.carl...@oracle.com
PR c++/14710
* g++.dg/warn/Wuseless-cast.C: New.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 185462)
+++ doc/invoke.texi (working copy)
@@ -274,8 +274,8 @@ Objective-C and Objective-C++ Dialects}.
-Wunused-label -Wunused-local-typedefs -Wunused-parameter @gol
-Wno-unused-result -Wunused-value @gol -Wunused-variable @gol
-Wunused-but-set-parameter -Wunused-but-set-variable @gol
--Wvariadic-macros -Wvector-operation-performance -Wvla
--Wvolatile-register-var -Wwrite-strings -Wzero-as-null-pointer-constant}
+-Wuseless-cast -Wvariadic-macros -Wvector-operation-performance @gol
+-Wvla -Wvolatile-register-var -Wwrite-strings -Wzero-as-null-pointer-constant}
@item C and Objective-C-only Warning Options
@gccoptlist{-Wbad-function-cast -Wmissing-declarations @gol
@@ -4199,6 +4199,11 @@ types. @option{-Wconversion-null} is enabled by de
Warn when a literal '0' is used as null pointer constant. This can
be useful to facilitate the conversion to @code{nullptr} in C++11.
+@item -Wuseless-cast @r{(C++ and Objective-C++ only)}
+@opindex Wuseless-cast
+@opindex Wno-useless-cast
+Warn when an expression is casted to its own type.
+
@item -Wempty-body
@opindex Wempty-body
@opindex Wno-empty-body
Index: c-family/c.opt
===
--- c-family/c.opt (revision 185462)
+++ c-family/c.opt (working copy)
@@ -697,6 +697,10 @@ Wzero-as-null-pointer-constant
C++ ObjC++ Var(warn_zero_as_null_pointer_constant) Warning
Warn when a literal '0' is used as null pointer
+Wuseless-cast
+C++ ObjC++ Var(warn_useless_cast) Warning
+Warn about useless casts
+
ansi
C ObjC C++ ObjC++
A synonym for -std=c89 (for C) or -std=c++98 (for C++)
Index: testsuite/g++.dg/warn/Wuseless-cast.C
===
--- testsuite/g++.dg/warn/Wuseless-cast.C (revision 0)
+++ testsuite/g++.dg/warn/Wuseless-cast.C (revision 0)
@@ -0,0 +1,62 @@
+// { dg-options -Wuseless-cast }
+
+templatetypename T
+ void tmpl_f1(T t)
+ {
+(int)(t);
+static_castint(t);
+reinterpret_castint(t);
+ }
+
+struct A { };
+
+templatetypename T
+ void tmpl_f2(T t)
+ {
+(A*)(t);
+const_castA*(t);
+static_castA*(t);
+reinterpret_castA*(t);
+dynamic_castA*(t);
+ }
+
+templatetypename T
+ void tmpl_f3(T t)
+ {
+(A)(t);
+const_castA(t);
+static_castA(t);
+reinterpret_castA(t);
+dynamic_castA(t);
+ }
+
+void f()
+{
+ int n;
+
+ (int)(n); // { dg-warning useless cast }
+ static_castint(n);// { dg-warning useless cast }
+ reinterpret_castint(n); // { dg-warning useless cast }
+
+ tmpl_f1(n);
+
+ A a;
+
+ (A*)(a); // { dg-warning useless cast }
+ const_castA*(a); // { dg-warning useless cast }
+ static_castA*(a);// { dg-warning useless cast }
+ reinterpret_castA*(a); // { dg-warning useless cast }
+ dynamic_castA*(a); // { dg-warning useless cast }
+
+
remove wrong code in immed_double_const
This removes some wrong code. Ok? Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 184563) +++ gcc/emit-rtl.c (working copy) @@ -540,8 +540,6 @@ immed_double_const (HOST_WIDE_INT i0, HO if (GET_MODE_BITSIZE (mode) = HOST_BITS_PER_WIDE_INT) return gen_int_mode (i0, mode); - - gcc_assert (GET_MODE_BITSIZE (mode) == 2 * HOST_BITS_PER_WIDE_INT); } /* If this integer fits in one word, return a CONST_INT. */
Re: remove wrong code in immed_double_const
On Fri, Mar 16, 2012 at 10:54 PM, Mike Stump mikest...@comcast.net wrote: This removes some wrong code. Ok? ChangeLog is missing. Tested how? And why is this wrong anyway? Ciao! Steven Index: gcc/emit-rtl.c === --- gcc/emit-rtl.c (revision 184563) +++ gcc/emit-rtl.c (working copy) @@ -540,8 +540,6 @@ immed_double_const (HOST_WIDE_INT i0, HO if (GET_MODE_BITSIZE (mode) = HOST_BITS_PER_WIDE_INT) return gen_int_mode (i0, mode); - - gcc_assert (GET_MODE_BITSIZE (mode) == 2 * HOST_BITS_PER_WIDE_INT); } /* If this integer fits in one word, return a CONST_INT. */
Re: [Patch, i386] Limit unroll factor for certain loops on Corei7
Ping - now that stage 1 is open, could someone review?
Thanks,
Teresa
On Sun, Dec 4, 2011 at 10:26 PM, Teresa Johnson tejohn...@google.com wrote:
Latest patch which improves the efficiency as described below is
included here. Boostrapped and checked again with
x86_64-unknown-linux-gnu. Could someone review?
Thanks,
Teresa
2011-12-04 Teresa Johnson tejohn...@google.com
* loop-unroll.c (decide_unroll_constant_iterations): Call loop
unroll target hook.
* config/i386/i386.c (ix86_loop_unroll_adjust): New function.
(TARGET_LOOP_UNROLL_ADJUST): Define hook for x86.
===
--- loop-unroll.c (revision 181902)
+++ loop-unroll.c (working copy)
@@ -547,6 +547,9 @@ decide_unroll_constant_iterations (struc
if (nunroll (unsigned) PARAM_VALUE (PARAM_MAX_UNROLL_TIMES))
nunroll = PARAM_VALUE (PARAM_MAX_UNROLL_TIMES);
+ if (targetm.loop_unroll_adjust)
+ nunroll = targetm.loop_unroll_adjust (nunroll, loop);
+
/* Skip big loops. */
if (nunroll = 1)
{
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 181902)
+++ config/i386/i386.c (working copy)
@@ -60,6 +60,7 @@ along with GCC; see the file COPYING3.
#include fibheap.h
#include opts.h
#include diagnostic.h
+#include cfgloop.h
enum upper_128bits_state
{
@@ -38370,6 +38371,82 @@ ix86_autovectorize_vector_sizes (void)
return (TARGET_AVX !TARGET_PREFER_AVX128) ? 32 | 16 : 0;
}
+/* If LOOP contains a possible LCP stalling instruction on corei7,
+ calculate new number of times to unroll instead of NUNROLL so that
+ the unrolled loop will still likely fit into the loop stream detector. */
+static unsigned
+ix86_loop_unroll_adjust (unsigned nunroll, struct loop *loop)
+{
+ basic_block *body, bb;
+ unsigned i;
+ rtx insn;
+ bool found = false;
+ unsigned newunroll;
+
+ if (ix86_tune != PROCESSOR_COREI7_64
+ ix86_tune != PROCESSOR_COREI7_32)
+ return nunroll;
+
+ /* Look for instructions that store a constant into HImode (16-bit)
+ memory. These require a length-changing prefix and on corei7 are
+ prone to LCP stalls. These stalls can be avoided if the loop
+ is streamed from the loop stream detector. */
+ body = get_loop_body (loop);
+ for (i = 0; i loop-num_nodes; i++)
+ {
+ bb = body[i];
+
+ FOR_BB_INSNS (bb, insn)
+ {
+ rtx set_expr, dest;
+ set_expr = single_set (insn);
+ if (!set_expr)
+ continue;
+
+ dest = SET_DEST (set_expr);
+
+ /* Don't reduce unroll factor in loops with floating point
+ computation, which tend to benefit more heavily from
+ larger unroll factors and are less likely to bottleneck
+ at the decoder. */
+ if (FLOAT_MODE_P (GET_MODE (dest)))
+ {
+ free (body);
+ return nunroll;
+ }
+
+ if (!found
+ GET_MODE (dest) == HImode
+ CONST_INT_P (SET_SRC (set_expr))
+ MEM_P (dest))
+ {
+ found = true;
+ /* Keep walking loop body to look for FP computations above. */
+ }
+ }
+ }
+ free (body);
+
+ if (!found)
+ return nunroll;
+
+ if (dump_file)
+ {
+ fprintf (dump_file,
+ ;; Loop contains HImode store of const (possible LCP
stalls),\n);
+ fprintf (dump_file,
+ reduce unroll factor to fit into Loop Stream Detector\n);
+ }
+
+ /* On corei7 the loop stream detector can hold 28 uops, so
+ don't allow unrolling to exceed that many instructions. */
+ newunroll = 28 / loop-av_ninsns;
+ if (newunroll nunroll)
+ return newunroll;
+
+ return nunroll;
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_RETURN_IN_MEMORY
#define TARGET_RETURN_IN_MEMORY ix86_return_in_memory
@@ -38685,6 +38762,9 @@ ix86_autovectorize_vector_sizes (void)
#define TARGET_INIT_LIBFUNCS darwin_rename_builtins
#endif
+#undef TARGET_LOOP_UNROLL_ADJUST
+#define TARGET_LOOP_UNROLL_ADJUST ix86_loop_unroll_adjust
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include gt-i386.h
On Fri, Dec 2, 2011 at 12:11 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Dec 2, 2011 at 11:36 AM, Andi Kleen a...@firstfloor.org wrote:
Teresa Johnson tejohn...@google.com writes:
Interesting optimization. I would be concerned a little bit
about compile time, does it make a measurable difference?
I haven't measured compile time explicitly, but I don't it should,
especially after I address your efficiency suggestion (see below),
since it will just have one pass over the instructions in innermost
loops.
The attached patch detects loops containing instructions that tend to
incur high LCP
[PATCH][Cilkplus] Patch to fix spawn bug in templates
Hello Everyone, This patch is for the Cilkplus branch, mainly affecting the C++ compiler. This patch will fix a bug when spawn is used inside template functions. Thanks, Balaji V. Iyer. diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk index 3667c75..f1935d2 100644 --- a/gcc/ChangeLog.cilk +++ b/gcc/ChangeLog.cilk @@ -1,3 +1,13 @@ +2012-03-16 Balaji V. Iyer balaji.v.i...@intel.com + + * cilk-spawn.c (cilk_valid_spawn): Unwrapped the call_expr from expr + and cleanup point statements. + (gimplify_cilk_spawn): Likewise. + * function.c (allocate_struct_function): Initialized calls_spawns + correctly. + * tree.h: Removed cilk_hyper_flag and replaced with cilk_has_spawn. + Also added DECL_HAS_SPAWN_P and removed DECL_HYPER_LOOKUP_P. + 2012-03-12 Balaji V. Iyer balaji.v.i...@intel.com * c-typeck.c (convert_arguments): Added array notation check for diff --git a/gcc/cilk-spawn.c b/gcc/cilk-spawn.c index 3ba1051..3a29250 100644 --- a/gcc/cilk-spawn.c +++ b/gcc/cilk-spawn.c @@ -295,6 +295,10 @@ cilk_valid_spawn (tree exp0) if (exp == NULL_TREE) return false; /* happens with C++ TARGET_EXPR */ + while (TREE_CODE (exp) == CLEANUP_POINT_EXPR +|| TREE_CODE (exp) == EXPR_STMT) +exp = TREE_OPERAND (exp, 0); + /* Now we have a call, or this isn't a valid spawn. */ /* XXX This will reject any outer non-spawn AGGR_INIT_EXPR that is valid because of a spawn inside. Are there any @@ -394,7 +398,11 @@ gimplify_cilk_spawn (tree *spawn_p, gimple_seq *before ATTRIBUTE_UNUSED, *spawn_p = build_empty_stmt (UNKNOWN_LOCATION); return; } - + /* Remove cleanup point expr and expr stmt from *spawn_p */ + while (TREE_CODE (expr) == CLEANUP_POINT_EXPR +|| TREE_CODE (expr) == EXPR_STMT) +expr = TREE_OPERAND (expr, 0); + new_args = NULL; function = build_cilk_wrapper (expr, new_args); diff --git a/gcc/cp/ChangeLog.cilk b/gcc/cp/ChangeLog.cilk index 28bd0e1..0970089 100644 --- a/gcc/cp/ChangeLog.cilk +++ b/gcc/cp/ChangeLog.cilk @@ -1,3 +1,11 @@ +2012-03-16 Balaji V. Iyer balaji.v.i...@intel.com + + * decl.c (finish_function_body): called DECL_HAS_SPAWN_P and set it to + calls_spawns. + * pt.c (tsubst_copy): Carried the spawn call information from one + call expression to another. + (tsubst_copy_and_build): Likewise. + 2012-02-14 Balaji V. Iyer balaji.v.i...@intel.com * parser.c (cp_parser_compound_stmt): Added a check to see if the diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 5b67c6d..71dfc8e 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -13402,6 +13402,7 @@ finish_function_body (tree compstmt) if (cfun-calls_spawn) cfun-cilk_frame_decl = cp_make_cilk_frame (); + DECL_HAS_SPAWN_P (cfun-decl) = cfun-calls_spawn; /* Close the block. */ finish_compound_stmt (compstmt); diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 9fb8573..5ca8aa7 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -12383,6 +12383,7 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl) for (i = 0; i n; i++) TREE_OPERAND (t, i) = tsubst_copy (TREE_OPERAND (t, i), args, complain, in_decl); + SPAWN_CALL_P (result) = SPAWN_CALL_P (t); return result; } @@ -13901,7 +13902,7 @@ tsubst_copy_and_build (tree t, in_decl, !qualified_p, integral_constant_expression_p); - + SPAWN_CALL_P (function) = SPAWN_CALL_P (t); if (BASELINK_P (function)) qualified_p = true; } diff --git a/gcc/function.c b/gcc/function.c index ed07a83..a8acd39 100644 --- a/gcc/function.c +++ b/gcc/function.c @@ -4420,6 +4420,7 @@ allocate_struct_function (tree fndecl, bool abstract_p) cfun-can_throw_non_call_exceptions = flag_non_call_exceptions; cfun-elem_fn_already_cloned = false; + cfun-calls_spawn = DECL_HAS_SPAWN_P (fndecl); } } diff --git a/gcc/tree.h b/gcc/tree.h index 1d4b18c..b204e30 100644 --- a/gcc/tree.h +++ b/gcc/tree.h @@ -3564,8 +3564,8 @@ struct GTY(()) /* In a FUNCTION_DECL for a Cilk function, indicates that the function is a hyperobject lookup. */ -#define DECL_HYPER_LOOKUP_P(NODE) \ - (FUNCTION_DECL_CHECK (NODE)-function_decl.cilk_hyper_flag) +#define DECL_HAS_SPAWN_P(NODE) \ + (FUNCTION_DECL_CHECK (NODE)-function_decl.cilk_has_spawn) /* In a FUNCTION_DECL with a nonzero DECL_CONTEXT, indicates that the static chain is an explicit argument. */ @@ -3573,8 +3573,6 @@ struct GTY(()) (FUNCTION_DECL_CHECK (NODE)-function_decl.explicit_static_chain_flag) - - /* In a FUNCTION_DECL indicates that a static chain is needed. */ #define DECL_STATIC_CHAIN(NODE) \ (FUNCTION_DECL_CHECK (NODE)-function_decl.regdecl_flag) @@
Re: Preserve pointer types in ivopts
On 03/16/2012 09:49 PM, Richard Henderson wrote: On 03/16/12 05:36, Bernd Schmidt wrote: The machine is special. Pointer addition is a different operation than integer addition. It'll also need a new ptr_plus rtx code which takes a Pmode and an SImode operand. Pmode is larger than SImode but fits in a single register; intptr_t (which is what we'd need to use if we freely cast between pointers and integers is DImode - that requires two regs and can't be used for memory addressing. Surely the least amount of work is to not use sizetype/intptr_t, but a custom type that has the same bit-width as a pointer? See some of the later mails in this thread for more details - the pointer add instruction isn't commutative. There is no true Pmode add, only a Pmode lea; in fact there is no normal arithmetic in Pmode at all. So you can't afford to lose information about which operand is the pointer. Making Pmode integer types would mean lying to the compiler very heavily about what operations are available, and it becomes way too hackish very quickly. Bernd
Re: remove wrong code in immed_double_const
On Mar 16, 2012, at 3:03 PM, Steven Bosscher wrote: On Fri, Mar 16, 2012 at 10:54 PM, Mike Stump mikest...@comcast.net wrote: This removes some wrong code. Ok? ChangeLog is missing. * emit-rtl.c (immed_double_const): Remove bogus assert. Tested how? Compiles a user program for my port. And why is this wrong anyway? It is wrong because it can assert. The code can generate a constant for every inbound value that it asserts for, so trivially, it is wrong. If it were correct, it would not assert for values it can handle. For it to be correct, there would have to exist a value for which the code fails. The value that failed for me was 0, not a terribly uncommon value.
[pph] Tagless Types; Macro Redefines (issue5846054)
This patch addresses two main problems.
(1) We were mishandling tagless types. The root of the problem was that
tagless types were given tags based on a sequence number. Two different PPH
files would thus have the same manufactured tag name for different types,
leading to inappropriate collisions in lookup. The solution is to manufacture
the tag from the source location rather than from a sequence number. All of
this construction must match the pattern when the name is later strcmp'ed to
see if it is actually tagless.
Tests c1anonymous1.h and c1anonymous2.h are now passing. Added tests
p0anonretag.h and p1anonretag.cc to ensure that the pattern matcher works.
(2) We were getting macro redefinition errors when two PPH files textually
included the same #defines because each PPH file replays its definitions.
The applied fix is to not do idempotent defines.
Test c7features.cc is now passing. Test x7rtti.cc does not have as many
errors.
This patch also addresses a minor problem.
(3) Debugging test x0tmpldfltparm.h was difficult because the same template
parameter identifier was used in different places. Instead, use unique names.
(4) Some debug/dump/print routines were missing null pointer checks. Add them.
Tested on x64.
Index: gcc/testsuite/ChangeLog.pph
2012-03-16 Lawrence Crowl cr...@google.com
* g++.dg/pph/README: Clarify p category.
* g++.dg/pph/c1anonymous1.h: Mark passing.
* g++.dg/pph/c1anonymous2.h: Mark passing.
* g++.dg/pph/c7features.cc: Mark passing.
* g++.dg/pph/p0anonretag.h: New.
* g++.dg/pph/p1anonretag.cc: New.
* g++.dg/pph/x0tmpldfltparm.h: Disambiguate template param names.
* g++.dg/pph/x7rtti.cc: Remove some xfails.
Index: gcc/cp/ChangeLog.pph
2012-03-16 Lawrence Crowl cr...@google.com
* cp-tree.h (make_anon_name): Add location parameter.
* name-lookup.c (static const char anon_char): New.
(static const char anon_prefix): New.
(edit_anon_name): New.
(make_anon_name): Add location parameter. Use location in creating
names for anonymous (tagless) types when using PPH.
(make_lambda_name): Fix comment for later.
* class.c (layout_class_type): Pass location to make_anon_name.
* decl.c (start_enum): Pass location to make_anon_name.
* semantics.c (finish_compound_literal): Pass location to
make_anon_name.
(begin_class_definition): Pass location to make_anon_name.
* error.c (dump_type): Protect call against null pointer.
* parser.c (cp_lexer_print_token): Protect against null values.
(cp_parser_enum_specifier): Pass location to make_anon_name.
(cp_parser_class_head): Pass location to make_anon_name.
Index: libcpp/ChangeLog.pph
2012-03-16 Lawrence Crowl cr...@google.com
* symtab.c (cpp_lt_already_done): New.
(cpp_lt_replay): Avoid idempotent macro defines.
Index: gcc/testsuite/g++.dg/pph/c1anonymous1.h
===
--- gcc/testsuite/g++.dg/pph/c1anonymous1.h (revision 185481)
+++ gcc/testsuite/g++.dg/pph/c1anonymous1.h (working copy)
@@ -1,11 +1,8 @@
-// {xfail-if ANONYMOUS MERGING { *-*-* } { -fpph-map=pph.map } }
-// { dg-bogus c0anonymous.h:4:16: error: 'anon_t' has a previous declaration
here { xfail *-*-* } 0 }
-
#ifndefC1ANONYMOUS
#defineC1ANONYMOUS
#include c0anonymous.h
-enum { first, second }; // { dg-bogus 'anon_t' referred to as enum {
xfail *-*-* } }
+enum { first, second };
#endif
Index: gcc/testsuite/g++.dg/pph/c1anonymous2.h
===
--- gcc/testsuite/g++.dg/pph/c1anonymous2.h (revision 185481)
+++ gcc/testsuite/g++.dg/pph/c1anonymous2.h (working copy)
@@ -1,14 +1,11 @@
-// {xfail-if ANONYMOUS MERGING { *-*-* } { -fpph-map=pph.map } }
-// { dg-bogus c0anonymous.h:4:16: error: 'struct anon_t' has a previous
declaration as 'struct anon_t' { xfail *-*-* } 0 }
-
#ifndef C1ANONYMOUS2_H
#define C1ANONYMOUS2_H
#include c0anonymous.h
-typedef struct { // { dg-bogus conflicting declaration 'structanonymous'
{ xfail *-*-* } }
+typedef struct {
char *field;
-} anon2_t; // { dg-bogus invalid type in declaration before ';' token {
xfail *-*-* } }
+} anon2_t;
#endif
Index: gcc/testsuite/g++.dg/pph/README
===
--- gcc/testsuite/g++.dg/pph/README (revision 185481)
+++ gcc/testsuite/g++.dg/pph/README (working copy)
@@ -7,9 +7,10 @@ names.
c - positive tests for C-level headers and sources
d - negative tests for C-level headers and sources
e - C-level tests for non-sharable headers
-p - positive tests for what would be c-level code, but which
-due to C++ standard namespace games are not quite C level
-tests
+p - positive tests for what would be c-level code, but
Re: [PATCH, i386] RTM support
On Tue, 13 Mar 2012, Uros Bizjak wrote: A small no-op change - there is no need for a constraint in an expand pattern. Plus some formatting. If you want to remove it, then remove it, don't just empty it. ;) 2012-03-13 Uros Bizjak ubiz...@gmail.com * config/i386/i386.md (xbegin): Remove constraint from expander. Tested on x86_64-pc-linux-gnu, committed to mainline SVN. Uros. Index: i386.md === --- i386.md (revision 185350) +++ i386.md (working copy) @@ -18206,7 +18206,7 @@ (set_attr memory unknown)]) (define_expand xbegin - [(set (match_operand:SI 0 register_operand =a) + [(set (match_operand:SI 0 register_operand ) + [(set (match_operand:SI 0 register_operand) brgds, H-P
