Re: faster random number engine
Can this replace the current mersenne twister implementation in std:: once the endianness issue, etc, have been worked out? -miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen
Re: [PATCH, PR 54409] Remapping inlining predicates fix
> Hi, > > this patch fixes PR 54409. The condition for dealing with offset maps > when remapping predicates which I have added recently was wrong, > fortunately a subsequent assert caught this. We cannot shift stuff by > an offset when it is passed by value. > > Conversely, the condition was unnecessarily restrictive, we can still > happily use non-aggregate and by-value conditions when offset map is > negative, that only means that by-ref stuff is not guaranteed to > survive. Yeah, I wondered about this ;) > > Bootstrapped and tested on x86_64-linux. OK for trunk? > > Thanks, > > Martin > > > > 2012-08-30 Martin Jambor > > PR middle-end/54409 > * ipa-inline-analysis.c (remap_predicate): Fix the offset_map > checking condition. > > * gcc/testsuite/gcc.dg/torture/pr54409.c: New test. OK, thanks Honza
Re: [PATCH 3/3] Compute predicates for phi node results in ipa-inline-analysis.c
> Hi, > > this is a new version of the patch which makes ipa analysis produce > predicates for PHI node results, at least at the bottom of the > simplest diamond and semi-diamond CFG subgraphs. This time I also > analyze the conditions again rather than extracting information from > CFG edges, which means I can reason about substantially more PHI > nodes. > > This patch makes us produce loop bounds hint for the pr48636.f90 > testcase. > > Bootstrapped and tested on x86_64-linux. OK for trunk? OK, thanks! Do you think you can add testcase? I plan to reorg the analysis to work in dominator order (now we compute dominators anyway for lop analysis) that will make this also bit more strong across non-trivial CFGs. (originally I did not care much since inliner cares only about simple functions with simple CFG, but with inline hints and other stuff we need to be more careful to not throw away useful info. Honza
Re: [PATCH, PR 54394] Compute loops when generating inline summaries
> Hi, > > the patch below fixes PR 54394. The problem is that since revision > 190346 we depend on bb->loop_father being non-NULL to get loop_depth. > However, with loops not computed, the loop_father is NULL, loop_depth > is thus considered zero and call graph edges out of such BB can be > considered much cooler, leading to inlining regressions. > > This patch fixes that by recomputing loops whenever optimizing, not > only for loop bounds hints. We might put the computation elsewhere or > do it only under more restrictive circumstances, but I believe that > after rev. 190346 we have to do it. In particular, I am not sure > whether we had (semi)correct loop_depths when doing early inlining or > not, this patch re-calculates it for early inliner too. > > Bootstrapped and tested on x86_64-linux, fixes fatigue run-time on > an x86_64-linux and i686-linux for me. What do you think? > > Thanks, > > Martin > > > 2012-08-29 Martin Jambor > > PR middle-end/54394 > * ipa-inline-analysis.c (estimate_function_body_sizes): Compute > dominance info and loops whenever optimizing. > > > Index: src/gcc/ipa-inline-analysis.c > === > --- src.orig/gcc/ipa-inline-analysis.c > +++ src/gcc/ipa-inline-analysis.c > @@ -2102,6 +2102,11 @@ estimate_function_body_sizes (struct cgr >info->conds = 0; >info->entry = 0; > > + if (optimize) This is OK. I think you can also skip thi computation for early inlining where we don't do any hints, so probably if (optimize && !early) Honza
Re: Memset/memcpy patch
> On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka wrote: > >> Any update? > > > > I will look into it today, but anyway I think it is stage1 material, so we > > have some time to progress on it. > > > > Honza > > Hi Honza, > > The old patch was reverted and the new patch was posted at > > http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00336.html > > Have you got a chance to review it? I am in China till 5th, I will try to return to it shortly after returning. Ping me again if not - there seems to be a lot of work left on this patch... Honza
[PATCH ping, middle-end]: Introduce TARGET_LEGITIMATE_COMBINED_INSN target hook
On Sun, Aug 26, 2012 at 11:00 AM, Uros Bizjak wrote:
> Actually a v3 of TARGET_REJECT_COMBINED_INSN target hook.
>
> Changes:
> - rename the hook and reverse the return value
>
> 2012-08-25 Uros Bizjak
>
> * target.def (legitimate_combined_insn): New target hook.
> * doc/tm.texi.in (TARGET_LEGITIMATE_COMBINED_INSN): New hook.
> * doc/tm.texi: Regenerated.
> * combine.c (recog_for_combine): Call targetm.legitimate_combined_insn
> to allow targets to reject combined insn.
> * hooks.h (hook_bool_rtx_true): New.
> * hooks.c (hook_bool_rtx_true): Ditto.
>
> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32},
> also with target-dependant x86 patch that implements the hook.
Ping.
This pstch will really help reload for x86 and its dedicated registers [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01598.html
Uros.
Re: [PATCH, PR 54394] Compute loops when generating inline summaries
On Fri, Aug 31, 2012 at 10:53:32AM +0200, Jan Hubicka wrote: > > Hi, > > > > the patch below fixes PR 54394. The problem is that since revision > > 190346 we depend on bb->loop_father being non-NULL to get loop_depth. > > However, with loops not computed, the loop_father is NULL, loop_depth > > is thus considered zero and call graph edges out of such BB can be > > considered much cooler, leading to inlining regressions. > > > > This patch fixes that by recomputing loops whenever optimizing, not > > only for loop bounds hints. We might put the computation elsewhere or > > do it only under more restrictive circumstances, but I believe that > > after rev. 190346 we have to do it. In particular, I am not sure > > whether we had (semi)correct loop_depths when doing early inlining or > > not, this patch re-calculates it for early inliner too. > > > > Bootstrapped and tested on x86_64-linux, fixes fatigue run-time on > > an x86_64-linux and i686-linux for me. What do you think? > > > > Thanks, > > > > Martin > > > > > > 2012-08-29 Martin Jambor > > > > PR middle-end/54394 > > * ipa-inline-analysis.c (estimate_function_body_sizes): Compute > > dominance info and loops whenever optimizing. > > > > > > Index: src/gcc/ipa-inline-analysis.c > > === > > --- src.orig/gcc/ipa-inline-analysis.c > > +++ src/gcc/ipa-inline-analysis.c > > @@ -2102,6 +2102,11 @@ estimate_function_body_sizes (struct cgr > >info->conds = 0; > >info->entry = 0; > > > > + if (optimize) > > This is OK. I think you can also skip thi computation for early inlining > where we don't do any hints, so probably if (optimize && !early) > > Honza This is not required to make hints working, it is necessary because of the following line a in estimate_function_body_sizes: es->loop_depth = bb_loop_depth (bb); which always yields zero if we don't have loops computed. So I can skip the computation only if we don't care about loop depths in early inlining either. Should I skip it? Thanks, Martin
Re: [PATCH, PR 54394] Compute loops when generating inline summaries
> > This is not required to make hints working, it is necessary because of > the following line a in estimate_function_body_sizes: > > es->loop_depth = bb_loop_depth (bb); > > which always yields zero if we don't have loops computed. So I can > skip the computation only if we don't care about loop depths in early > inlining either. Should I skip it? Only place we care is the badness computation and only if profile guessing is off, so just initialize it to 0 for early inliner. Honza > > Thanks, > > Martin
RFA: libiberty: cope with integer overflow in _objalloc_alloc
Hi DJ, Hi Ian,
The _objalloc_alloc() function is currently vulnerable to an integer
overflow if it is passed a negative length. For example if called
with len = -3 and assuming that OBJALLOC_ALIGN is 4 then:
line 122: len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
So len = (-3 + 3) & ~ 3 = 0, and then the function returns a pointer
that will be reused the next time _objalloc_alloc is called.
Or suppose that len = -4, then:
line 122: len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
Which gives len = (-4 + 3) & ~3 = -4 and then:
line 136: ret = (char *) malloc (CHUNK_HEADER_SIZE + len);
So now the function returns a pointer to a memory block that is not
even big enough to contain the chunk header.
The proposed patch should take care of both of these scenarios. OK
to apply ?
Cheers
Nick
libiberty/ChangeLog
2012-08-31 Jan Lieskovsky
Nick Clifton
* objalloc.c (_objalloc_alloc): Align length before testing for
zero length. Refuse to allocate when length is so big that
integer overflow would occur during internal calculations.
Index: libiberty/objalloc.c
===
RCS file: /cvs/src/src/libiberty/objalloc.c,v
retrieving revision 1.8
diff -u -3 -p -r1.8 objalloc.c
--- libiberty/objalloc.c22 Jul 2005 03:26:05 - 1.8
+++ libiberty/objalloc.c31 Aug 2012 10:28:33 -
@@ -114,12 +114,12 @@ objalloc_create (void)
PTR
_objalloc_alloc (struct objalloc *o, unsigned long len)
{
+ len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
+
/* We avoid confusion from zero sized objects by always allocating
- at least 1 byte. */
+ at least OBJALLOC_ALIGN bytes. */
if (len == 0)
-len = 1;
-
- len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
+len = OBJALLOC_ALIGN;
if (len <= o->current_space)
{
@@ -133,6 +133,10 @@ _objalloc_alloc (struct objalloc *o, uns
char *ret;
struct objalloc_chunk *chunk;
+ /* Protect against integer overflow. */
+ if (len + CHUNK_HEADER_SIZE < len)
+return NULL;
+
ret = (char *) malloc (CHUNK_HEADER_SIZE + len);
if (ret == NULL)
return NULL;
Re: RFA: libiberty: cope with integer overflow in _objalloc_alloc
On 08/31/2012 12:33 PM, Nick Clifton wrote:
Hi DJ, Hi Ian,
The _objalloc_alloc() function is currently vulnerable to an integer
overflow if it is passed a negative length. For example if called
with len = -3 and assuming that OBJALLOC_ALIGN is 4 then:
line 122: len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
So len = (-3 + 3) & ~ 3 = 0, and then the function returns a pointer
that will be reused the next time _objalloc_alloc is called.
Or suppose that len = -4, then:
line 122: len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
Which gives len = (-4 + 3) & ~3 = -4 and then:
line 136: ret = (char *) malloc (CHUNK_HEADER_SIZE + len);
So now the function returns a pointer to a memory block that is not
even big enough to contain the chunk header.
The proposed patch should take care of both of these scenarios. OK
to apply ?
If I'm not mistaken, this doesn't cover the -3 case properly:
PTR
_objalloc_alloc (struct objalloc *o, unsigned long len)
{
len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
/* We avoid confusion from zero sized objects by always allocating
at least OBJALLOC_ALIGN bytes. */
if (len == 0)
len = OBJALLOC_ALIGN;
This still results in a pointer which is too small. And this code is
never called because the wraparound already happens in the
objalloc_alloc macro in the header file.
Here's a different patch which should not suffer from this problem:
--
Florian Weimer / Red Hat Product Security Team
Re: faster random number engine
On Fri, Aug 31, 2012 at 3:59 AM, Miles Bader wrote: > Can this replace the current mersenne twister implementation in > std:: once the endianness issue, etc, have been worked out? No, it produces different numbers.
[Patch ARM testsuite] fix 3 tests for big-endian
Hi, Tests gcc.target/arm/pr48252.c, gcc.target/arm/pr51835.c and gcc.target/arm/neon-vset_lanes8.c currently expect little-endian code and fail when compiled/executed in big-endian mode. The attached patch fixes them. Tested with qemu on armeb-none-linux-gnueabi and arm-none-linux-gnueabi. OK? Christophe 2012-08-31 Christophe Lyon gcc/testsuite/ * gcc.target/arm/neon-vset_lanes8.c, gcc.target/arm/pr51835.c, gcc.target/arm/pr48252.c: Fix for big-endian support. big-endian-tests.patch Description: Binary data
[google/integration] Add a configure option to disable system header canonicalizations (issue6489063)
Add a configure option to disable system header canonicalizations.
Libcpp may canonicalize system header paths with lrealpath() for diagnostics,
dependency output, and similar. If gcc is held in a symlink farm the
canonicalized paths may be meaningless to users, and will also conflict with
build frameworks that (for example) disallow absolute paths to header files.
Tested with bootstrap builds of C and C++, both with and without configure
--disable-canonical-system-headers. Okay for google/integration?
libcpp/ChangeLog.google-integration
2012-08-31 Simon Baldwin
* files.c (maybe_shorter_path): Suppress function definition if
ENABLE_CANONICAL_SYSTEM_HEADERS is not defined.
* (find_file_in_dir): Call maybe_shorter_path() only if
ENABLE_CANONICAL_SYSTEM_HEADERS is defined.
* configure.ac: Add new --enable-canonical-system-headers.
* configure: Regenerate.
* config.in: Regenerate.
gcc/ChangeLog.google-integration
2012-08-31 Simon Baldwin
* doc/install.texi: Document --enable-canonical-system-headers.
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 190830)
+++ gcc/doc/install.texi(working copy)
@@ -1747,6 +1747,14 @@ and may be disabled using @option{--disa
See @option{-canonical-prefixes} or @option{-no-canonical-prefixes} for
more details, including how to override this configuration option when
compiling.
+
+@item --enable-canonical-system-headers
+@itemx --disable-canonical-system-headers
+Enable system header path canonicalization for @file{libcpp}. This can
+produce shorter header file paths in diagnostics and dependency output
+files, but these changed header paths may conflict with some compilation
+environments. Enabled by default, and may be disabled using
+@option{--disable-canonical-system-headers}.
@end table
@subheading Cross-Compiler-Specific Options
Index: libcpp/configure
===
--- libcpp/configure(revision 190830)
+++ libcpp/configure(working copy)
@@ -703,6 +703,7 @@ enable_rpath
with_libiconv_prefix
enable_maintainer_mode
enable_checking
+enable_canonical_system_headers
'
ac_precious_vars='build_alias
host_alias
@@ -1337,6 +1338,8 @@ Optional Features:
--disable-rpath do not hardcode runtime library paths
--enable-maintainer-mode enable rules only needed by maintainers
--enable-checking enable expensive run-time checks
+ --enable-canonical-system-headers
+ enable or disable system headers canonicalization
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -7366,6 +7369,19 @@ $as_echo "#define ENABLE_CHECKING 1" >>c
fi
+# Check whether --enable-canonical-system-headers was given.
+if test "${enable_canonical_system_headers+set}" = set; then :
+ enableval=$enable_canonical_system_headers;
+else
+ enable_canonical_system_headers=yes
+fi
+
+if test $enable_canonical_system_headers != no; then
+
+$as_echo "#define ENABLE_CANONICAL_SYSTEM_HEADERS 1" >>confdefs.h
+
+fi
+
case $target in
alpha*-*-* | \
Index: libcpp/files.c
===
--- libcpp/files.c (revision 190830)
+++ libcpp/files.c (working copy)
@@ -345,6 +345,7 @@ pch_open_file (cpp_reader *pfile, _cpp_f
shorter, otherwise return NULL. This function does NOT free the
memory pointed by FILE. */
+#ifdef ENABLE_CANONICAL_SYSTEM_HEADERS
static char *
maybe_shorter_path (const char * file)
{
@@ -359,6 +360,7 @@ maybe_shorter_path (const char * file)
return NULL;
}
}
+#endif
/* Try to open the path FILE->name appended to FILE->dir. This is
where remap and PCH intercept the file lookup process. Return true
@@ -384,6 +386,7 @@ find_file_in_dir (cpp_reader *pfile, _cp
char *copy;
void **pp;
+#ifdef ENABLE_CANONICAL_SYSTEM_HEADERS
/* We try to canonicalize system headers. */
if (file->dir->sysp)
{
@@ -396,6 +399,7 @@ find_file_in_dir (cpp_reader *pfile, _cp
path = canonical_path;
}
}
+#endif
hv = htab_hash_string (path);
if (htab_find_with_hash (pfile->nonexistent_file_hash, path, hv) != NULL)
Index: libcpp/configure.ac
===
--- libcpp/configure.ac (revision 190830)
+++ libcpp/configure.ac (working copy)
@@ -146,6 +146,16 @@ if test $enable_checking != no ; then
[Define if you want more run-time sanity checks.])
fi
+AC_ARG_ENABLE(canonical-system-headers,
+[ --enable-canonical-system-headers
+ enable or disable system headers canonicalization],
+[],
+enable_canonical_system_headers=yes)
+if test $enable_canonical_system_headers != no; then
+ AC_DEFINE(ENABLE_CANONICAL_SYSTEM_HEADERS,
+1, [Define to enable
[C PATCH] Avoid ICEs due to save_expr instead of c_save_expr (PR c/54428)
Hi!
This is another case of the issue that save_expr shouldn't be called
when parsing C (except for in_late_binary_op), but c_save_expr must be
called instead.
I wonder if we shouldn't add a langhook, which would do
if (in_late_binary_op) save_expr_1 else c_save_expr
and ensure that when not parsing in_late_binary_op is set or something
similar, and if non-NULL, call the langhook from save_expr.
Anyway, this patch fixes this issue even without such changes,
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?
2012-08-31 Jakub Jelinek
PR c/54428
* c-convert.c (convert): Don't call fold_convert_loc if
TYPE_MAIN_VARIANT of a COMPLEX_TYPE is the same, unless e
is a COMPLEX_EXPR. Remove TYPE_MAIN_VARIANT check from
COMPLEX_TYPE -> COMPLEX_TYPE conversion.
* gcc.c-torture/compile/pr54428.c: New test.
--- gcc/c/c-convert.c.jj2012-06-29 21:22:02.0 +0200
+++ gcc/c/c-convert.c 2012-08-31 10:25:55.265821242 +0200
@@ -1,6 +1,6 @@
/* Language-level data type conversion for GNU C.
Copyright (C) 1987, 1988, 1991, 1998, 2002, 2003, 2004, 2005, 2007, 2008,
- 2009, 2010 Free Software Foundation, Inc.
+ 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -92,7 +92,9 @@ convert (tree type, tree expr)
STRIP_TYPE_NOPS (e);
- if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (TREE_TYPE (expr)))
+ if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (TREE_TYPE (expr))
+ && (TREE_CODE (TREE_TYPE (expr)) != COMPLEX_TYPE
+ || TREE_CODE (e) == COMPLEX_EXPR))
return fold_convert_loc (loc, type, expr);
if (TREE_CODE (TREE_TYPE (expr)) == ERROR_MARK)
return error_mark_node;
@@ -135,24 +137,23 @@ convert (tree type, tree expr)
but for the C FE c_save_expr needs to be called instead. */
if (TREE_CODE (TREE_TYPE (e)) == COMPLEX_TYPE)
{
- tree subtype = TREE_TYPE (type);
- tree elt_type = TREE_TYPE (TREE_TYPE (e));
-
- if (TYPE_MAIN_VARIANT (elt_type) != TYPE_MAIN_VARIANT (subtype)
- && TREE_CODE (e) != COMPLEX_EXPR)
+ if (TREE_CODE (e) != COMPLEX_EXPR)
{
+ tree subtype = TREE_TYPE (type);
+ tree elt_type = TREE_TYPE (TREE_TYPE (e));
+
if (in_late_binary_op)
e = save_expr (e);
else
e = c_save_expr (e);
ret
- = fold_build2 (COMPLEX_EXPR, type,
- convert (subtype,
- fold_build1 (REALPART_EXPR,
-elt_type, e)),
- convert (subtype,
- fold_build1 (IMAGPART_EXPR,
-elt_type, e)));
+ = fold_build2_loc (loc, COMPLEX_EXPR, type,
+ convert (subtype,
+ fold_build1 (REALPART_EXPR,
+elt_type, e)),
+ convert (subtype,
+ fold_build1 (IMAGPART_EXPR,
+elt_type, e)));
goto maybe_fold;
}
}
--- gcc/testsuite/gcc.c-torture/compile/pr54428.c.jj2012-08-31
10:27:51.941225923 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr54428.c 2012-08-31
10:27:09.0 +0200
@@ -0,0 +1,9 @@
+/* PR c/54428 */
+
+typedef double _Complex C;
+
+C
+foo (C x, C y, double z, C w)
+{
+ return y - z * __builtin_cpow (x, 75) * w;
+}
Jakub
[PING][Patch, ARM] Cleanup in arm_expand_epilogue
Ping http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01026.html From: Greta Yorsh [greta.yo...@arm.com] Sent: Friday, July 20, 2012 7:33 PM To: GCC Patches Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [Patch, ARM] Cleanup in arm_expand_epilogue The variable floats_from_frame in function arm_expand_epilogue became unused after removal of FPA support. This patch cleans it up and simplifies the initialization of num_regs variable. Ok for trunk? Thanks, Greta ChangeLog gcc/ 2012-07-20 Greta Yorsh * config/arm/arm.c (arm_expand_epilogue): Remove unused variable floats_from_frame.
[PING][Patch,ARM] unwind in epilogue ignore dwarf info
Ping http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01025.html From: Greta Yorsh [greta.yo...@arm.com] Sent: Friday, July 20, 2012 7:28 PM To: GCC Patches Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [Patch,ARM] unwind in epilogue ignore dwarf info The final pass of gcc uses dwarf information to generate unwind tables and directives (e.g., with command line option -fexceptions). Dwarf information generated for epilogues should be ignored when generating unwind info, because the ARM ABI only allows unwind at procedure boundaries. This patch adds a flag unwind_in_epilogue for it. It wasn't needed in the past, because there was no dwarf info generated for epilogues, but recent patches for epilogue generation in RTL added it. No regression on qemu. 2012-07-20 Greta Yorsh * config/arm/arm.c (arm_unwind_function_begin_epilogue): New function. (unwind_in_epilogue) New static variable. (arm_unwind_emit) Use unwind_in_epilogue flag. (arm_asm_emit_except_personality) Clear unwind_in_epilogue flag.
Re: [PATCH, ARM] Constant vector permute for the Neon vext insn
On 24 August 2012 10:54, Christophe Lyon wrote: > On 24 August 2012 10:40, Richard Earnshaw wrote: >> >> Has this been tested for big-endian? >> >> R. > > No. I'll give a look at it and let you know. > > Christophe. Here is an updated patch, which now does no optimization in the big-endian case. Given the current status of big-endian + neon support, I guess it is not a serious problem. I have also added runtime tests. I will later post an additional patch (on top of this one), which enhances the tests so that they can be run in big-endian mode too. Christophe. 2012-08-31 Christophe Lyon gcc/ * config/arm/arm.c (arm_evpc_neon_vext): New function. (arm_expand_vec_perm_const_1): Add call to arm_evpc_neon_vext. gcc/testsuite/ * gcc.target/arm/neon-vext.c gcc.target/arm/neon-vext-execute.c: New tests. gcc-vec-permute-vext.changelog Description: Binary data
Re: [PATCH, ARM] Constant vector permute for the Neon vext insn
This time with the actual patch attached. On 31 August 2012 15:23, Christophe Lyon wrote: > On 24 August 2012 10:54, Christophe Lyon wrote: >> On 24 August 2012 10:40, Richard Earnshaw wrote: >>> >>> Has this been tested for big-endian? >>> >>> R. >> >> No. I'll give a look at it and let you know. >> >> Christophe. > > Here is an updated patch, which now does no optimization in the > big-endian case. Given the current status of big-endian + neon > support, I guess it is not a serious problem. > > I have also added runtime tests. > > I will later post an additional patch (on top of this one), which > enhances the tests so that they can be run in big-endian mode too. > > Christophe. > > 2012-08-31 Christophe Lyon > > gcc/ > * config/arm/arm.c (arm_evpc_neon_vext): New > function. > (arm_expand_vec_perm_const_1): Add call to > arm_evpc_neon_vext. > > > gcc/testsuite/ > * gcc.target/arm/neon-vext.c > gcc.target/arm/neon-vext-execute.c: > New tests. gcc-vec-permute-vext.patch Description: Binary data
Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)
On Fri, Aug 31, 2012 at 7:20 AM, Simon Baldwin wrote: > Add a configure option to disable system header canonicalizations. > > Libcpp may canonicalize system header paths with lrealpath() for diagnostics, > dependency output, and similar. If gcc is held in a symlink farm the > canonicalized paths may be meaningless to users, and will also conflict with > build frameworks that (for example) disallow absolute paths to header files. > > Tested with bootstrap builds of C and C++, both with and without configure > --disable-canonical-system-headers. Okay for google/integration? Seems like a reasonable candidate for trunk, and I'd rather have fewer patches in google/integration than more. Can you send a copy of this patch for inclusion there? Let's at least see what people say. Ollie
Re: [PATCH, PR 54394] Compute loops when generating inline summaries
Hi,
On Fri, Aug 31, 2012 at 12:06:33PM +0200, Jan Hubicka wrote:
> >
> > This is not required to make hints working, it is necessary because of
> > the following line a in estimate_function_body_sizes:
> >
> > es->loop_depth = bb_loop_depth (bb);
> >
> > which always yields zero if we don't have loops computed. So I can
> > skip the computation only if we don't care about loop depths in early
> > inlining either. Should I skip it?
>
> Only place we care is the badness computation and only if profile guessing is
> off,
> so just initialize it to 0 for early inliner.
>
Thanks. For the record, this is what I have committed.
Martin
2012-08-31 Martin Jambor
PR middle-end/54394
* ipa-inline-analysis.c (estimate_function_body_sizes): Compute
dominance info and loops whenever optimizing.
Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -2102,6 +2102,11 @@ estimate_function_body_sizes (struct cgr
info->conds = 0;
info->entry = 0;
+ if (optimize && !early)
+{
+ calculate_dominance_info (CDI_DOMINATORS);
+ loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
+}
if (dump_file)
fprintf (dump_file, "\nAnalyzing function body size: %s\n",
@@ -2270,9 +2275,6 @@ estimate_function_body_sizes (struct cgr
loop_iterator li;
predicate loop_iterations = true_predicate ();
- calculate_dominance_info (CDI_DOMINATORS);
- loop_optimizer_init (LOOPS_NORMAL
- | LOOPS_HAVE_RECORDED_EXITS);
if (dump_file && (dump_flags & TDF_DETAILS))
flow_loops_dump (dump_file, NULL, 0);
scev_initialize ();
@@ -2305,12 +2307,15 @@ estimate_function_body_sizes (struct cgr
*inline_summary (node)->loop_iterations = loop_iterations;
}
scev_finalize ();
- loop_optimizer_finalize ();
- free_dominance_info (CDI_DOMINATORS);
}
inline_summary (node)->self_time = time;
inline_summary (node)->self_size = size;
VEC_free (predicate_t, heap, nonconstant_names);
+ if (optimize && !early)
+{
+ loop_optimizer_finalize ();
+ free_dominance_info (CDI_DOMINATORS);
+}
if (dump_file)
{
fprintf (dump_file, "\n");
[PATCH, AArch64] Allow symbol+offset even if not being used for memory access
Hi,
This patch builds on a previous one that allowed symbol+offset as symbol
references for memory accesses. It allows us to have symbol+offset even
when no memory access is apparent.
It reduces codesize for cases such as this one:
int arr[100];
uint64_t foo (uint64_t a) {
uint64_t const z = 1234567ll<<32+7;
uint64_t const y = (uint64_t) &arr[3];
return y + a + z;
}
Before the patch, the code looked like this:
adrpx2, arr
mov x1, 74217034874880
add x2, x2, :lo12:arr
add x2, x2, 12
movkx1, 2411, lsl 48
add x1, x2, x1
add x0, x1, x0
ret
Now, it looks like this:
adrpx1, arr+12
mov x2, 74217034874880
movkx2, 2411, lsl 48
add x1, x1, :lo12:arr+12
add x1, x1, x2
add x0, x1, x0
ret
Testing shows no regressions. OK to commit?
2012-08-31 Ian Bolton
* gcc/config/aarch64/aarch64.md: New pattern.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index a00d3f0..de9c927 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2795,7 +2795,7 @@
(lo_sum:DI (match_operand:DI 1 "register_operand" "r")
(match_operand 2 "aarch64_valid_symref" "S")))]
""
- "add\\t%0, %1, :lo12:%2"
+ "add\\t%0, %1, :lo12:%a2"
[(set_attr "v8type" "alu")
(set_attr "mode" "DI")]
@@ -2890,6 +2890,20 @@
[(set_attr "length" "0")]
)
+(define_split
+ [(set (match_operand:DI 0 "register_operand" "=r")
+ (const:DI (plus:DI (match_operand:DI 1 "aarch64_valid_symref" "S")
+ (match_operand:DI 2 "const_int_operand" "i"]
+ ""
+ [(set (match_dup 0) (high:DI (const:DI (plus:DI (match_dup 1)
+ (match_dup 2)
+ (set (match_dup 0) (lo_sum:DI (match_dup 0)
+(const:DI (plus:DI (match_dup 1)
+ (match_dup 2)]
+ ""
+)
+
+
;; AdvSIMD Stuff
(include "aarch64-simd.md")
Re: [C PATCH] Avoid ICEs due to save_expr instead of c_save_expr (PR c/54428)
On Fri, 31 Aug 2012, Jakub Jelinek wrote: > 2012-08-31 Jakub Jelinek > > PR c/54428 > * c-convert.c (convert): Don't call fold_convert_loc if > TYPE_MAIN_VARIANT of a COMPLEX_TYPE is the same, unless e > is a COMPLEX_EXPR. Remove TYPE_MAIN_VARIANT check from > COMPLEX_TYPE -> COMPLEX_TYPE conversion. > > * gcc.c-torture/compile/pr54428.c: New test. OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)
On 31 August 2012 16:31, Ollie Wild wrote: > > On Fri, Aug 31, 2012 at 7:20 AM, Simon Baldwin wrote: > > Add a configure option to disable system header canonicalizations. > > > > Libcpp may canonicalize system header paths with lrealpath() for > > diagnostics, > > dependency output, and similar. If gcc is held in a symlink farm the > > canonicalized paths may be meaningless to users, and will also conflict > > with > > build frameworks that (for example) disallow absolute paths to header > > files. > > > > Tested with bootstrap builds of C and C++, both with and without > > configure > > --disable-canonical-system-headers. Okay for google/integration? > > Seems like a reasonable candidate for trunk, and I'd rather have fewer > patches in google/integration than more. Can you send a copy of this > patch for inclusion there? Let's at least see what people say. The patch exactly meets the definition of google/integration only, which is that it fixes up something that affects only Google's use of gcc. --no-canonical-prefixes is similar. That too is only in our branches and not in trunk, for the same reason. I'd rather keep this out of trunk unless there are known external use cases where it's beneficial. That keeps both the review and the testing load to acceptable -- though still extremely high -- levels. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Re: [PATCH 3/3] Compute predicates for phi node results in ipa-inline-analysis.c
Hi,
On Fri, Aug 31, 2012 at 10:52:28AM +0200, Jan Hubicka wrote:
> > Hi,
> >
> > this is a new version of the patch which makes ipa analysis produce
> > predicates for PHI node results, at least at the bottom of the
> > simplest diamond and semi-diamond CFG subgraphs. This time I also
> > analyze the conditions again rather than extracting information from
> > CFG edges, which means I can reason about substantially more PHI
> > nodes.
> >
> > This patch makes us produce loop bounds hint for the pr48636.f90
> > testcase.
> >
> > Bootstrapped and tested on x86_64-linux. OK for trunk?
>
> OK,
> thanks! Do you think you can add testcase?
Thanks, I forgot to include the testcase in the email somehow, I have
committed the changes to pr48636.f90 below along with the patch.
> I plan to reorg the analysis to work in dominator order (now we compute
> dominators anyway for lop analysis) that will make this also bit more strong
> across non-trivial CFGs. (originally I did not care much since inliner cares
> only about simple functions with simple CFG, but with inline hints and other
> stuff we need to be more careful to not throw away useful info.
Well, evaluating the GIMPLE_COND rather than disecting the predicates
in an e->aux also makes for much nicer code. However, processing in
dominator order is certainly a good idea.
Martin
Index: src/gcc/testsuite/gfortran.dg/pr48636.f90
===
--- src.orig/gcc/testsuite/gfortran.dg/pr48636.f90
+++ src/gcc/testsuite/gfortran.dg/pr48636.f90
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options "-O3 -fdump-ipa-inline" }
+! { dg-options "-O3 -fdump-ipa-inline-details" }
module foo
implicit none
@@ -34,4 +34,6 @@ program main
end program main
! { dg-final { scan-ipa-dump "bar\[^\\n\]*inline copy in MAIN" "inline" } }
+! { dg-final { scan-ipa-dump-times "phi predicate:" 5 "inline" } }
+! { dg-final { scan-ipa-dump "inline hints: loop_iterations" "inline" } }
! { dg-final { cleanup-ipa-dump "inline" } }
Re: [PATCH, x86-Atom] Enabling look-ahead scheduling feature for Atom processors
On Tue, Aug 28, 2012 at 1:34 PM, Uros Bizjak wrote: > On Tue, Aug 28, 2012 at 11:24 AM, Igor Zamyatin wrote: > >> I'd like this patch (original version at the bottom) also to be >> backported into 4.7. >> >> Is it safe to backport? > > Looks safe to me. > > OK if there are no objections from RMs in the next 24h. All testing passed so following will be checked in 4.7. Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c (revision 190833) +++ gcc/config/i386/i386.c (working copy) @@ -23842,6 +23842,7 @@ case PROCESSOR_CORE2_64: case PROCESSOR_COREI7_32: case PROCESSOR_COREI7_64: +case PROCESSOR_ATOM: /* Generally, we want haifa-sched:max_issue() to look ahead as far as many instructions can be executed on a cycle, i.e., issue_rate. I wonder why tuning for many CPUs does not do this. */ Original Changelog: 2012-08-23 Yuri Rumyantsev * config/i386/i386.c (ia32_multipass_dfa_lookahead) : Add case for Atom processor. Thanks, Igor > > Thanks, > Uros.
Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)
On Fri, Aug 31, 2012 at 10:01 AM, Simon Baldwin wrote: > On 31 August 2012 16:31, Ollie Wild wrote: >> > > The patch exactly meets the definition of google/integration only, > which is that it fixes up something that affects only Google's use of > gcc. The criterion is more subtle than that. The google/integration branch is for things which: (a) cannot be submitted to trunk, and (b) are required for inter-operability with our build/test systems. The goal is to keep any changes relative to trunk as minimal as possible, and frankly, much of the stuff that's there now should be cleaned up and submitted upstream. > --no-canonical-prefixes is similar. That too is only in our > branches and not in trunk, for the same reason. But -no-canonical-prefixes *is* in trunk. Presumably the same people who benefit from that will also benefit from this. In fact, I think a reasonable case could be made that header canonicalization should be gated on the same flag. > > I'd rather keep this out of trunk unless there are known external use > cases where it's beneficial. That keeps both the review and the > testing load to acceptable -- though still extremely high -- levels. The same argument could be made about *any* patch we submit. Pushing upstream is always more work, but if we don't do it, we end up paying for it later. Ollie
Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)
On 31 August 2012 17:25, Ollie Wild wrote: > > On Fri, Aug 31, 2012 at 10:01 AM, Simon Baldwin wrote: > > On 31 August 2012 16:31, Ollie Wild wrote: > >> > > > > The patch exactly meets the definition of google/integration only, > > which is that it fixes up something that affects only Google's use of > > gcc. > > The criterion is more subtle than that. The google/integration branch > is for things which: (a) cannot be submitted to trunk, and (b) are > required for inter-operability with our build/test systems. The goal > is to keep any changes relative to trunk as minimal as possible, and > frankly, much of the stuff that's there now should be cleaned up and > submitted upstream. > > > --no-canonical-prefixes is similar. That too is only in our > > branches and not in trunk, for the same reason. > > But -no-canonical-prefixes *is* in trunk. Presumably the same people > who benefit from that will also benefit from this. In fact, I think a > reasonable case could be made that header canonicalization should be > gated on the same flag. Yes. I meant --disable-canonical-prefixes. That is a gcc configure flag that we use to control the default setting for -[no-]canonical-prefixes where neither flag is supplied on the gcc command line. --disable/enable-canonical-prefixes is only in google branches. > > > > > I'd rather keep this out of trunk unless there are known external use > > cases where it's beneficial. That keeps both the review and the > > testing load to acceptable -- though still extremely high -- levels. > > The same argument could be made about *any* patch we submit. Pushing > upstream is always more work, but if we don't do it, we end up paying > for it later. Not at all. An ICE that only occurred with Google code as gcc input is a perfect counterexample. -- Google UK Limited | Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Re: C++ PR 54197: lifetime of reference not properly extended
OK, sorry for the delay. Jason
Re: [PING][Patch, ARM] Cleanup in arm_expand_epilogue
On 08/31/12 13:49, Greta Yorsh wrote: Ping http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01026.html From: Greta Yorsh [greta.yo...@arm.com] Sent: Friday, July 20, 2012 7:33 PM To: GCC Patches Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [Patch, ARM] Cleanup in arm_expand_epilogue The variable floats_from_frame in function arm_expand_epilogue became unused after removal of FPA support. This patch cleans it up and simplifies the initialization of num_regs variable. Ok for trunk? This is OK - sorry for having missed this earlier. Ramana
Re: [PATCH, AArch64] Allow symbol+offset even if not being used for memory access
On 2012-08-31 07:49, Ian Bolton wrote:
> +(define_split
> + [(set (match_operand:DI 0 "register_operand" "=r")
> + (const:DI (plus:DI (match_operand:DI 1 "aarch64_valid_symref" "S")
> + (match_operand:DI 2 "const_int_operand" "i"]
> + ""
> + [(set (match_dup 0) (high:DI (const:DI (plus:DI (match_dup 1)
> + (match_dup 2)
> + (set (match_dup 0) (lo_sum:DI (match_dup 0)
> + (const:DI (plus:DI (match_dup 1)
> + (match_dup 2)]
> + ""
> +)
You ought not need this as a separate split, since (CONST ...) should
be handled exactly like (SYMBOL_REF).
Also note that constraints ("=r" etc) aren't used for splits.
r~
Re: [PATCH] New command line switch -fada-spec-parent
* Steven Bosscher, 2012-08-24 : > > * common.opt (-fada-spec-parent): Define new command line switch. > Why here instead of in c-family/c.opt? Makes sense indeed, I'll move the definition there. -- Thomas Quinot, Ph.D. ** qui...@adacore.com ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: [PATCH, ARM] Constant vector permute for the Neon vext insn
On 2012-08-31 07:25, Christophe Lyon wrote: > + offset = gen_rtx_CONST_INT (VOIDmode, location); Never call gen_rtx_CONST_INT directly. Use GEN_INT. r~
Re: [Patch ARM testsuite] fix 3 tests for big-endian
On 08/31/2012 05:05 AM, Christophe Lyon wrote:
> Hi,
>
> Tests gcc.target/arm/pr48252.c, gcc.target/arm/pr51835.c and
> gcc.target/arm/neon-vset_lanes8.c currently expect little-endian code
> and fail when compiled/executed in big-endian mode.
>
> The attached patch fixes them.
>
> Tested with qemu on armeb-none-linux-gnueabi and arm-none-linux-gnueabi.
>
> OK?
I'll let an ARM expert review the patch, but please don't use TCL
code in test directives. Instead of
+/* { dg-final { if [check_effective_target_arm_little_endian] \{ } } */
/* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t
\]*d0" 2 } } */
+/* { dg-final { \} else \{ } } */
+/* { dg-final {scan-assembler-times "fmrrd\[\\t \]+r1,\[\\t \]*r0,\[\\t
\]*d0" 2 } } */
+/* { dg-final { \}
do something like
/* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t \]*d0"
2 } { target arm_little_endian } } */
/* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r1,\[\\t \]*r0,\[\\t \]*d0"
2 } {target { ! arm_little_endian } } } */
That's untested, but you get the idea.
Janis
Re: [PING][Patch,ARM] unwind in epilogue ignore dwarf info
On 08/31/12 13:50, Greta Yorsh wrote: Ping http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01025.html From: Greta Yorsh [greta.yo...@arm.com] Sent: Friday, July 20, 2012 7:28 PM To: GCC Patches Cc: Richard Earnshaw; Ramana Radhakrishnan Subject: [Patch,ARM] unwind in epilogue ignore dwarf info The final pass of gcc uses dwarf information to generate unwind tables and directives (e.g., with command line option -fexceptions). Dwarf information generated for epilogues should be ignored when generating unwind info, because the ARM ABI only allows unwind at procedure boundaries. This patch adds a flag unwind_in_epilogue for it. It wasn't needed in the past, because there was no dwarf info generated for epilogues, but recent patches for epilogue generation in RTL added it. Hmmm, slightly uneasy about this patch. Is there a chance that for a particular function arm_unwind_function_begin_epilogue gets called but arm_asm_emit_except_personality is not for some reason ? I'm worried a bit about stale values of unwind_epilogue I suppose across functions. I'd prefer this to be in machine_function in arm.h . regards, Ramana
Re: [PATCH, x86-Atom] Enabling look-ahead scheduling feature for Atom processors
>> Looks safe to me. >> >> OK if there are no objections from RMs in the next 24h. > > All testing passed so following will be checked in 4.7. Checked in. http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00815.html Thanks, K
Re: C++ PR 54197: lifetime of reference not properly extended
On Fri, Aug 31, 2012 at 10:37 AM, Jason Merrill wrote: > OK, sorry for the delay. No worries. Thanks. Submitted to trunk and gcc-4_7-branch as r190834 and r190839. Ollie
Re: [PATCH 3/3] Compute predicates for phi node results in ipa-inline-analysis.c
Hi,
On Thu, Aug 30, 2012 at 05:11:35PM +0200, Martin Jambor wrote:
> this is a new version of the patch which makes ipa analysis produce
> predicates for PHI node results, at least at the bottom of the
> simplest diamond and semi-diamond CFG subgraphs. This time I also
> analyze the conditions again rather than extracting information from
> CFG edges, which means I can reason about substantially more PHI
> nodes.
>
> This patch makes us produce loop bounds hint for the pr48636.f90
> testcase.
>
> Bootstrapped and tested on x86_64-linux. OK for trunk?
>
> Thanks,
>
> Martin
>
>
> 2012-08-29 Martin Jambor
>
> * ipa-inline-analysis.c (phi_result_unknown_predicate): New function.
> (predicate_for_phi_result): Likewise.
> (estimate_function_body_sizes): Use the above two functions.
>
This patch, on top of the one doing loop calculations almost always,
introduces a number of testsuite failures which somehow I had not
caught during my testing. The problem is that either
calculate_dominance_info or loop_optimizer_init introduce new SSA
names for which there is no index in nonconstant_names which is
allocated before the dominance and loop computations. I'm currently
bootstrapping and testing the following fix which simply allocates the
vector after doing the two computations. If it passes I will commit
it straight away so that the regression is fixed before I leave for
the weekend, I hope it's obvious enough for that.
On the other hand, it would really be better if we did not change
function bodies during IPA summary generation phase...
Sorry for the breakage,
Martin
2012-08-31 Martin Jambor
* ipa-inline-analysis.c (estimate_function_body_sizes): Allocate
nonconstant_names after calculate_dominance_info and
loop_optimizer_init.
Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -2185,13 +2185,6 @@ estimate_function_body_sizes (struct cgr
struct ipa_node_params *parms_info = NULL;
VEC (predicate_t, heap) *nonconstant_names = NULL;
- if (ipa_node_params_vector && !early && optimize)
-{
- parms_info = IPA_NODE_REF (node);
- VEC_safe_grow_cleared (predicate_t, heap, nonconstant_names,
-VEC_length (tree, SSANAMES (my_function)));
-}
-
info->conds = 0;
info->entry = 0;
@@ -2199,6 +2192,13 @@ estimate_function_body_sizes (struct cgr
{
calculate_dominance_info (CDI_DOMINATORS);
loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
+
+ if (ipa_node_params_vector)
+ {
+ parms_info = IPA_NODE_REF (node);
+ VEC_safe_grow_cleared (predicate_t, heap, nonconstant_names,
+VEC_length (tree, SSANAMES (my_function)));
+ }
}
if (dump_file)
[Patch, PR 54128] ira.c change to fix mips bootstrap
Here is my patch to fix the bootstrap comparision failure (PR 54128) on
MIPS. The reason for the comparision failure was a difference in
register usage and I tracked it down to build_insn_chain which checked
all instructions for register usage in order to set the dead_or_set
and live_relevant_regs bitmaps instead of checking only non-debug
instructions. Changing INSN_P to NONDEBUG_INSN_P in build_insn_chain
allowed me to bootstrap and caused no regressions.
OK to checkin?
Steve Ellcey
sell...@mips.com
2012-08-31 Steve Ellcey
PR bootstrap/54128
* ira.c (build_insn_chain): Check only NONDEBUG instructions for
register usage.
diff --git a/gcc/ira.c b/gcc/ira.c
index 3825498..477c87b 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -3341,7 +3341,7 @@ build_insn_chain (void)
c->insn = insn;
c->block = bb->index;
- if (INSN_P (insn))
+ if (NONDEBUG_INSN_P (insn))
for (def_rec = DF_INSN_UID_DEFS (uid); *def_rec; def_rec++)
{
df_ref def = *def_rec;
@@ -3432,7 +3432,7 @@ build_insn_chain (void)
bitmap_and_compl_into (live_relevant_regs, elim_regset);
bitmap_copy (&c->live_throughout, live_relevant_regs);
- if (INSN_P (insn))
+ if (NONDEBUG_INSN_P (insn))
for (use_rec = DF_INSN_UID_USES (uid); *use_rec; use_rec++)
{
df_ref use = *use_rec;
Re: bug wrt gcc 4.7 and the C++11 memory model
On 2012-08-31 05:48, Andrew MacLeod wrote:
> On 08/30/2012 07:04 PM, Richard Henderson wrote:
>> Actually, we already have a memory barrier feature in rtl:
>>
>>ALIAS_SET_MEMORY_BARRIER
>>
>> but since we already set that in get_builtin_sync_mem, we'll need
>> to figure out why that's no longer working.
>>
>> As far as I can tell from reading alias.c, we should already be
>> indicating that such memories alias...
>>
>> What was the testcase again? I seem to have lost the top of the thread...
>>
>>
>
> #include
> using namespace std;
>
> atomic_uint a_8;
> int32_t g_70;
> int32_t g_141;
>
> int main (int, char *[]) {
>a_8.load () & a_8.load ();
>g_141 = g_70 != 0;
> }
>
> or equivalently
>
> int a_8;
> int g_70;
> int g_141;
>
> int main ()
> {
>__atomic_load_n (&a_8, __ATOMIC_SEQ_CST) & __atomic_load_n (&a_8,
> __ATOMIC_SEQ_CST);
>g_141 = g_70 != 0;
> }
Fixed as follows. This seems to be the only entry point in alias.c that didn't
take ALIAS_SET_MEMORY_BARRIER into account. Getting the above into a test case
is tricky, and I havn't figured out how to match it.
Full testing still underway, but I expect it to pass.
r~
* alias.c (read_dependence): Account for ALIAS_SET_MEMORY_BARRIER.
diff --git a/gcc/alias.c b/gcc/alias.c
index e9d701f..5848e75 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -2132,7 +2132,12 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y,
HOST_WIDE_INT c)
int
read_dependence (const_rtx mem, const_rtx x)
{
- return MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem);
+ if (MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem))
+return true;
+ if (MEM_ALIAS_SET (x) == ALIAS_SET_MEMORY_BARRIER
+ || MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER)
+return true;
+ return false;
}
/* Returns nonzero if something about the mode or address format MEM1
Re: bug wrt gcc 4.7 and the C++11 memory model
On Fri, Aug 31, 2012 at 6:51 PM, Richard Henderson wrote: > Fixed as follows. This seems to be the only entry point in alias.c that > didn't take ALIAS_SET_MEMORY_BARRIER into account. Getting the above into a > test case is tricky, and I havn't figured out how to match it. > > Full testing still underway, but I expect it to pass. Any reason to not add the (mem:BLK (scratch)) special case as well? Ciao! Steven
Re: bug wrt gcc 4.7 and the C++11 memory model
> Full testing still underway, but I expect it to pass. Can you also update the comment before the function, please? It now reads: /* Read dependence: X is read after read in MEM takes place. There can only be a dependence here if both reads are volatile. */ But that's no longer true after your patch. Ciao! Steven
Re: [patch] Make every GIMPLE switch have a default case, always
Ping! On Sat, Aug 25, 2012 at 1:14 AM, Steven Bosscher wrote: > Hello, > > This patch restores the old invariant that every GIMPLE switch has a > default case. This invariant is only broken by the SJLJ exception > dispatch code, and it's resulted in some code accepting a switch > without a default while others still assume there is _always_ a > default case. The patch enforces the invariant, fixes some fall-out, > and cleans up the code in a couple of places. It makes the follow-up > work on switch code generation that I still have planned a bit easier. > > Bootstrapped&tested on x86_64-unknown-linux-gnu (with Java to torture > the exception handling code) and did a non-bootstrap build (including > Java again) with --enable-sjlj-exceptions. OK for trunk? > > Ciao! > Steven
Re: [PATCH,mmix] convert to constraints.md
On Fri, 3 Aug 2012, Hans-Peter Nilsson wrote: > On Thu, 2 Aug 2012, Nathan Froyd wrote: > > H-P, if you'd like to test beforehand, that'd be great. > > ...yes, I'd like to test this before, please. Thanks for your > work. (Let's set a timeout at the end of August; ok to commit > Sep 1 have I not got back to you.) This is that call. Sorry, but I need more time to get test-results for a recent trunk revision to a state where testing patches makes sense. I'll test the patch and commit that or a variant. Thanks for your work. If you have general patches depending on this, e.g. that gets rid of the old constraint methods, don't let this hold you back. brgds, H-P
Re: [C++ Patch] PR 18747
Since you're traveling, I poked at this myself some more. The issue
here is that there are too many template headers for the declaration, so
we want to figure out what the right number is and give an appropriate
message.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7c8fead9f721b04227c6790a3dbe256e93144d46
Author: Jason Merrill
Date: Fri Aug 31 16:27:37 2012 -0400
PR c++/18747
* pt.c (check_template_variable): New.
(num_template_headers_for_class): Split out...
* decl.c (grokdeclarator): ...from here.
(start_decl): Remove redundant diagnostic.
* cp-tree.h: Declare them
* parser.c (cp_parser_single_declaration): Call check_template_variable.
.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@190830 138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1b085bd..bd57b92 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5316,6 +5316,8 @@ extern void end_specialization (void);
extern void begin_explicit_instantiation (void);
extern void end_explicit_instantiation (void);
extern tree check_explicit_specialization (tree, tree, int, int);
+extern int num_template_headers_for_class (tree);
+extern void check_template_variable (tree);
extern tree make_auto(void);
extern tree do_auto_deduction (tree, tree, tree);
extern tree type_uses_auto (tree);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c909dea..8b94e26 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4461,11 +4461,6 @@ start_decl (const cp_declarator *declarator,
context, DECL_NAME (decl));
DECL_CONTEXT (decl) = DECL_CONTEXT (field);
}
- if (processing_specialization
- && template_class_depth (context) == 0
- && CLASSTYPE_TEMPLATE_SPECIALIZATION (context))
- error ("template header not allowed in member definition "
- "of explicitly specialized class");
/* Static data member are tricky; an in-class initialization
still doesn't provide a definition, so the in-class
declaration will have DECL_EXTERNAL set, but will have an
@@ -9564,36 +9559,9 @@ grokdeclarator (const cp_declarator *declarator,
&& declarator->u.id.qualifying_scope
&& MAYBE_CLASS_TYPE_P (declarator->u.id.qualifying_scope))
{
- tree t;
-
ctype = declarator->u.id.qualifying_scope;
ctype = TYPE_MAIN_VARIANT (ctype);
- t = ctype;
- while (t != NULL_TREE && CLASS_TYPE_P (t))
- {
- /* You're supposed to have one `template <...>' for every
- template class, but you don't need one for a full
- specialization. For example:
-
- template struct S{};
- template <> struct S { void f(); };
- void S::f () {}
-
- is correct; there shouldn't be a `template <>' for the
- definition of `S::f'. */
- if (CLASSTYPE_TEMPLATE_SPECIALIZATION (t)
- && !any_dependent_template_arguments_p (CLASSTYPE_TI_ARGS (t)))
- /* T is an explicit (not partial) specialization. All
- containing classes must therefore also be explicitly
- specialized. */
- break;
- if ((CLASSTYPE_USE_TEMPLATE (t) || CLASSTYPE_IS_TEMPLATE (t))
- && PRIMARY_TEMPLATE_P (CLASSTYPE_TI_TEMPLATE (t)))
- template_count += 1;
-
- t = TYPE_MAIN_DECL (t);
- t = DECL_CONTEXT (t);
- }
+ template_count = num_template_headers_for_class (ctype);
if (ctype == current_class_type)
{
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 091a967..60ba380 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -21310,8 +21310,8 @@ cp_parser_perform_template_parameter_access_checks (VEC (deferred_access_check,g
}
/* Parse a `decl-specifier-seq [opt] init-declarator [opt] ;' or
- `function-definition' sequence. MEMBER_P is true, this declaration
- appears in a class scope.
+ `function-definition' sequence that follows a template header.
+ If MEMBER_P is true, this declaration appears in a class scope.
Returns the DECL for the declared entity. If FRIEND_P is non-NULL,
*FRIEND_P is set to TRUE iff the declaration is a friend. */
@@ -21431,6 +21431,9 @@ cp_parser_single_declaration (cp_parser* parser,
"explicit template specialization cannot have a storage class");
decl = error_mark_node;
}
+
+if (decl && TREE_CODE (decl) == VAR_DECL)
+ check_template_variable (decl);
}
/* Look for a trailing `;' after the declaration. */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5ce6e8a..4a39427 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2208,6 +2208,66 @@ copy_default_args_to_explicit_spec (tree decl)
TREE_TYPE (decl) = new_type;
}
+/* Return the number of template headers we expect to see for a definition
+ or specialization of CTYPE or one of its non-template members. */
+
+int
+num_template_headers_for_class (tree ctype)
+{
+ int template_count = 0;
+ tree t = ctype;
+ while (t != NULL_TREE && CLASS_TYPE_P (t))
+{
+ /* You're supposed to have one `template <...>'
Re: [middle-end] Add machine_mode to address_cost target hook
On Aug 29, 2012, Oleg Endo wrote: > * config/mn10300/mn10300.c (mn10300_address_cost): Add > machine_mode argument. Use GET_MODE (x) in recursive > invocation. > * config/sh/sh.c (sh_address_cost): Likewise. These are ok, thanks. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
vector comparisons in C++
Hello, this patch copies some more vector extensions from the C front-end to the C++ front-end. There seemed to be some reluctance to add those, but I guess a patch is the best way to ask. Note that I only added the vector x vector operations, not the vector x scalar ones. I have some issues with the vector-compare-2.c torture test. It passes a vector by value (argument and return type), which is likely to warn (although for some reason it doesn't for me, with today's compiler). And it takes -Wno-psabi through a .x file, but those are not read in c-c++-common, so I put it in dg-options. I would have changed the function to use pointers, but I don't know if it specifically wants to test passing by value... 2012-08-31 Marc Glisse PR c++/54427 cp/ChangeLog * typeck.c (cp_build_binary_op) [LSHIFT_EXPR, RSHIFT_EXPR, EQ_EXPR, NE_EXPR, LE_EXPR, GE_EXPR, LT_EXPR, GT_EXPR]: Handle VECTOR_TYPE. testsuite/ChangeLog * gcc.dg/vector-shift.c: Move ... * c-c++-common/vector-shift.c: ... here. * gcc.dg/vector-shift1.c: Move ... * c-c++-common/vector-shift1.c: ... here. * gcc.dg/vector-shift3.c: Move ... * c-c++-common/vector-shift3.c: ... here. * gcc.dg/vector-compare-1.c: Move ... * c-c++-common/vector-compare-1.c: ... here. * gcc.dg/vector-compare-2.c: Move ... * c-c++-common/vector-compare-2.c: ... here. * gcc.c-torture/execute/vector-compare-1.c: Move ... * c-c++-common/torture/vector-compare-1.c: ... here. * gcc.c-torture/execute/vector-compare-2.x: Delete. * gcc.c-torture/execute/vector-compare-2.c: Move ... * c-c++-common/torture/vector-compare-2.c: ... here. * gcc.c-torture/execute/vector-shift.c: Move ... * c-c++-common/torture/vector-shift.c: ... here. * gcc.c-torture/execute/vector-shift2.c: Move ... * c-c++-common/torture/vector-shift2.c: ... here. * gcc.c-torture/execute/vector-subscript-1.c: Move ... * c-c++-common/torture/vector-subscript-1.c: ... here. * gcc.c-torture/execute/vector-subscript-2.c: Move ... * c-c++-common/torture/vector-subscript-2.c: ... here. * gcc.c-torture/execute/vector-subscript-3.c: Move ... * c-c++-common/torture/vector-subscript-3.c: ... here. -- Marc Glisse
Re: vector comparisons in C++
With the patch...
On Sat, 1 Sep 2012, Marc Glisse wrote:
Hello,
this patch copies some more vector extensions from the C front-end to the C++
front-end. There seemed to be some reluctance to add those, but I guess a
patch is the best way to ask. Note that I only added the vector x vector
operations, not the vector x scalar ones.
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn (although
for some reason it doesn't for me, with today's compiler). And it takes
-Wno-psabi through a .x file, but those are not read in c-c++-common, so I
put it in dg-options. I would have changed the function to use pointers, but
I don't know if it specifically wants to test passing by value...
2012-08-31 Marc Glisse
PR c++/54427
cp/ChangeLog
* typeck.c (cp_build_binary_op) [LSHIFT_EXPR, RSHIFT_EXPR, EQ_EXPR,
NE_EXPR, LE_EXPR, GE_EXPR, LT_EXPR, GT_EXPR]: Handle VECTOR_TYPE.
testsuite/ChangeLog
* gcc.dg/vector-shift.c: Move ...
* c-c++-common/vector-shift.c: ... here.
* gcc.dg/vector-shift1.c: Move ...
* c-c++-common/vector-shift1.c: ... here.
* gcc.dg/vector-shift3.c: Move ...
* c-c++-common/vector-shift3.c: ... here.
* gcc.dg/vector-compare-1.c: Move ...
* c-c++-common/vector-compare-1.c: ... here.
* gcc.dg/vector-compare-2.c: Move ...
* c-c++-common/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-compare-1.c: Move ...
* c-c++-common/torture/vector-compare-1.c: ... here.
* gcc.c-torture/execute/vector-compare-2.x: Delete.
* gcc.c-torture/execute/vector-compare-2.c: Move ...
* c-c++-common/torture/vector-compare-2.c: ... here.
* gcc.c-torture/execute/vector-shift.c: Move ...
* c-c++-common/torture/vector-shift.c: ... here.
* gcc.c-torture/execute/vector-shift2.c: Move ...
* c-c++-common/torture/vector-shift2.c: ... here.
* gcc.c-torture/execute/vector-subscript-1.c: Move ...
* c-c++-common/torture/vector-subscript-1.c: ... here.
* gcc.c-torture/execute/vector-subscript-2.c: Move ...
* c-c++-common/torture/vector-subscript-2.c: ... here.
* gcc.c-torture/execute/vector-subscript-3.c: Move ...
* c-c++-common/torture/vector-subscript-3.c: ... here.
--
Marc GlisseIndex: cp/typeck.c
===
--- cp/typeck.c (revision 190842)
+++ cp/typeck.c (working copy)
@@ -3977,21 +3977,29 @@ cp_build_binary_op (location_t location,
case TRUTH_AND_EXPR:
case TRUTH_OR_EXPR:
result_type = boolean_type_node;
break;
/* Shift operations: result has same type as first operand;
always convert second operand to int.
Also set SHORT_SHIFT if shifting rightward. */
case RSHIFT_EXPR:
- if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
+ if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE
+ && TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+ && TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE
+ && TYPE_VECTOR_SUBPARTS (type0) == TYPE_VECTOR_SUBPARTS (type1))
+ {
+ result_type = type0;
+ converted = 1;
+ }
+ else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
{
result_type = type0;
if (TREE_CODE (op1) == INTEGER_CST)
{
if (tree_int_cst_lt (op1, integer_zero_node))
{
if ((complain & tf_warning)
&& c_inhibit_evaluation_warnings == 0)
warning (0, "right shift count is negative");
}
@@ -4006,21 +4014,29 @@ cp_build_binary_op (location_t location,
/* Convert the shift-count to an integer, regardless of
size of value being shifted. */
if (TYPE_MAIN_VARIANT (TREE_TYPE (op1)) != integer_type_node)
op1 = cp_convert (integer_type_node, op1, complain);
/* Avoid converting op1 to result_type later. */
converted = 1;
}
break;
case LSHIFT_EXPR:
- if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
+ if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE
+ && TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
+ && TREE_CODE (TREE_TYPE (type1)) == INTEGER_TYPE
+ && TYPE_VECTOR_SUBPARTS (type0) == TYPE_VECTOR_SUBPARTS (type1))
+ {
+ result_type = type0;
+ converted = 1;
+ }
+ else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
{
result_type = type0;
if (TREE_CODE (op1) == INTEGER_CST)
{
if (tree_int_cst_lt (op1, integer_zero_node))
{
if ((complain & tf_warning)
&& c_inhibit_evaluation_warnings == 0)
warning (0, "left shift count is
Re: [Jiří Paleček] [PATCH][C++] Fix constant reference in a lambda (PR c++/53488)
Thanks for the patch! The idea of the fix is to postpone the decision whether or not to capture later to the template instantiation. That makes sense. We might as well postpone all default captures to instantiation time, since we need to postpone some of them. +/* This is a hack: + + We absolutely need the capture list to be nonempty if the + template had it nonempty, otherwise, we will have the + conversion-to-function-pointer operator erroneously + added. We use a dummy list with a single element that we + can get rid of easily later +*/ + LAMBDA_EXPR_CAPTURE_LIST (r) + = LAMBDA_EXPR_CAPTURE_LIST (t) != NULL_TREE ? tree_cons(NULL_TREE, NULL_TREE, NULL_TREE) : NULL_TREE; I think rather than do this, we should set LAMBDA_EXPR_CAPTURE_LIST in instantiate_class_template_1. Jason
[google/gcc-4_7] Fix GDB test suite regression with -fdebug-types-section patch
This patch is for the google/gcc-4_7 branch.
This patch fixes a problem caused by the previous patch that removed
the code to copy children of a DIE referenced by a type unit.
> I don't believe that it's necessary to copy the children of the class
> declaration at all, and this patch simply removes the code that copies
> those children. If there's a reference in the type unit to one of the
> children of that class, that one child will get copied in as needed.
The problem was that it IS necessary to copy the children of a
non-declaration -- such as a DW_TAG_array_type. I've restored the
loop that calls clone_tree_partial, but placed it within a test
for is_declaration_die.
Bootstraps and passes regression tests. Also tested with parts of the
GDB testsuite, and is still able to build a large internal test case
that previously resulted in out-of-memory during compilation.
Google ref b/7041390.
2012-08-31 Cary Coutant
* gcc/dwarf2out.c (clone_tree_partial): Restore.
(copy_decls_walk): Call clone_tree_partial to copy children
of non-declaration DIEs.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 190842)
+++ gcc/dwarf2out.c (working copy)
@@ -7745,6 +7745,40 @@ copy_ancestor_tree (dw_die_ref unit, dw_
return copy;
}
+/* Like clone_tree, but copy DW_TAG_subprogram DIEs as declarations.
+ Enter all the cloned children into the hash table decl_table. */
+
+static dw_die_ref
+clone_tree_partial (dw_die_ref die, htab_t decl_table)
+{
+ dw_die_ref c;
+ dw_die_ref clone;
+ struct decl_table_entry *entry;
+ void **slot;
+
+ if (die->die_tag == DW_TAG_subprogram)
+clone = clone_as_declaration (die);
+ else
+clone = clone_die (die);
+
+ slot = htab_find_slot_with_hash (decl_table, die,
+ htab_hash_pointer (die), INSERT);
+ /* Assert that DIE isn't in the hash table yet. If it would be there
+ before, the ancestors would be necessarily there as well, therefore
+ clone_tree_partial wouldn't be called. */
+ gcc_assert (*slot == HTAB_EMPTY_ENTRY);
+ entry = XCNEW (struct decl_table_entry);
+ entry->orig = die;
+ entry->copy = clone;
+ *slot = entry;
+
+ if (die->die_tag != DW_TAG_subprogram)
+FOR_EACH_CHILD (die, c,
+ add_child_die (clone, clone_tree_partial (c, decl_table)));
+
+ return clone;
+}
+
/* Walk the DIE and its children, looking for references to incomplete
or trivial types that are unmarked (i.e., that are not in the current
type_unit). */
@@ -7792,6 +7826,16 @@ copy_decls_walk (dw_die_ref unit, dw_die
entry->copy = copy;
*slot = entry;
+ /* If TARG is not a declaration DIE, we need to copy its
+children. */
+ if (!is_declaration_die (targ))
+ {
+ FOR_EACH_CHILD (
+ targ, c,
+ add_child_die (copy,
+clone_tree_partial (c, decl_table)));
+ }
+
/* Make sure the cloned tree is marked as part of the
type unit. */
mark_dies (copy);
Re: [patch] Fix problems with -fdebug-types-section
> I don't believe that it's necessary to copy the children of the class > declaration at all, and this patch simply removes the code that copies > those children. If there's a reference in the type unit to one of the > children of that class, that one child will get copied in as needed. > > Bootstraps and passes regression tests. Also tested with a large > internal test case that previously resulted in out-of-memory during > compilation. Sorry, but GDB testing exposed a problem with this patch. It turns out that it IS necessary to copy children of a non-declaration DIE, such as DW_TAG_array_type, so my patch was a little too aggressive in completely removing that loop. I'll have a replacement patch on the way after a bit more GDB testing. -cary
Re: [Jiří Paleček] [PATCH][C++] Fix constant reference in a lambda (PR c++/53488)
On Fri, Aug 31, 2012 at 6:00 PM, Jason Merrill wrote: > Thanks for the patch! > >> The idea of the fix is to postpone the decision whether or not to capture >> later to the template instantiation. > > > That makes sense. We might as well postpone all default captures to > instantiation time, since we need to postpone some of them. Hmm, would we not run the risk of doing the "wrong" capture if everything is postponed? -- Gaby
[PATCH] Fix i?86 *mov*insv_1* patterns (PR target/54436)
Hi!
The following testcase results in an assembler warning on movb $700415, %ch
The problem is that the *mov*_insv_1* patterns use SImode or DImode for the
source operand, accept CONST_INTs in the constraints and nothing truncates
the constants to QImode. While the b modifier in %b1 handles changing the
printout of registers and memory (forcing it to be 8-bit low register or
in Intel syntax 8-bit memory), it doesn't handle CONST_INTs this way.
I've checked other such uses of b, w, k modifiers and usually they are used
either in widening of the operand (which is fine), or with constraints not
allowing integers.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.7?
2012-09-01 Jakub Jelinek
PR target/54436
* config/i386/i386.md (*mov_insv_1_rex64, *movsi_insv_1): If
operands[1] is CONST_INT_P, convert it to QImode before printing.
* gcc.dg/torture/pr54436.c: New test.
--- gcc/config/i386/i386.md.jj 2012-08-30 11:38:22.0 +0200
+++ gcc/config/i386/i386.md 2012-08-31 17:12:03.556906659 +0200
@@ -2690,7 +2690,11 @@ (define_insn "*mov_insv_1_rex64"
(const_int 8))
(match_operand:SWI48x 1 "nonmemory_operand" "Qn"))]
"TARGET_64BIT"
- "mov{b}\t{%b1, %h0|%h0, %b1}"
+{
+ if (CONST_INT_P (operands[1]))
+operands[1] = simplify_gen_subreg (QImode, operands[1], mode, 0);
+ return "mov{b}\t{%b1, %h0|%h0, %b1}";
+}
[(set_attr "type" "imov")
(set_attr "mode" "QI")])
@@ -2700,7 +2704,11 @@ (define_insn "*movsi_insv_1"
(const_int 8))
(match_operand:SI 1 "general_operand" "Qmn"))]
"!TARGET_64BIT"
- "mov{b}\t{%b1, %h0|%h0, %b1}"
+{
+ if (CONST_INT_P (operands[1]))
+operands[1] = simplify_gen_subreg (QImode, operands[1], SImode, 0);
+ return "mov{b}\t{%b1, %h0|%h0, %b1}";
+}
[(set_attr "type" "imov")
(set_attr "mode" "QI")])
--- gcc/testsuite/gcc.dg/torture/pr54436.c.jj 2012-08-31 18:30:22.131777543
+0200
+++ gcc/testsuite/gcc.dg/torture/pr54436.c 2012-08-31 18:32:27.994169836
+0200
@@ -0,0 +1,38 @@
+/* PR target/54436 */
+/* { dg-do assemble } */
+
+#if __SIZEOF_SHORT__ == 2 && __SIZEOF_LONG_LONG__ == 8
+static inline unsigned short
+baz (unsigned short *x)
+{
+ union U { unsigned short a; unsigned char b[2]; } u = { *x };
+ u.b[0] = ((u.b[0] * 0x0802ULL & 0x22110ULL)
+ | (u.b[0] * 0x8020ULL & 0x88440ULL)) * 0x10101ULL >> 16;
+ u.b[1] = ((u.b[1] * 0x0802ULL & 0x22110ULL)
+ | (u.b[1] * 0x8020ULL & 0x88440ULL)) * 0x10101ULL >> 16;
+ unsigned char t = u.b[0];
+ u.b[0] = u.b[1];
+ u.b[1] = t;
+ return u.a;
+}
+
+static inline unsigned long long
+bar (unsigned long long *x)
+{
+ union U { unsigned long long a; unsigned short b[4]; } u = { *x };
+ u.b[0] = baz (&u.b[0]);
+ return u.a;
+}
+
+void
+foo (void)
+{
+ unsigned long long l = -1ULL;
+ __asm volatile ("" : : "r" (bar (&l)));
+}
+#else
+void
+foo (void)
+{
+}
+#endif
Jakub
