Re: patch to fix constant math
On Mon, Oct 8, 2012 at 9:55 PM, Richard Sandiford wrote: > Robert Dewar writes: >> On 10/8/2012 11:01 AM, Nathan Froyd wrote: >>> - Original Message - Btw, as for Richards idea of conditionally placing the length field in rtx_def looks like overkill to me. These days we'd merely want to optimize for 64bit hosts, thus unconditionally adding a 32 bit field to rtx_def looks ok to me (you can wrap that inside a union to allow both descriptive names and eventual different use - see what I've done to tree_base) >>> >>> IMHO, unconditionally adding that field isn't "optimize for 64-bit >>> hosts", but "gratuitously make one of the major compiler data >>> structures bigger on 32-bit hosts". Not everybody can cross-compile >>> from a 64-bit host. And even those people who can don't necessarily >>> want to. Please try to consider what's best for all the people who >>> use GCC, not just the cases you happen to be working with every day. >> >> I think that's rasonable in general, but as time goes on, and every >> $300 laptop is 64-bit capable, one should not go TOO far out of the >> way trying to make sure we can compile everything on a 32-bit machine. > > It's not 64-bit machine vs. 32-bit machine. It's an LP64 ABI vs. > an ILP32 ABI. HJ & co. have put considerable effort into developing > the x32 ABI for x86_64 precisely because ILP32 is still useful for > 64-bit machines. Just as it was for MIPS when SGI invented n32 > (which is still useful now). I believe 64-bit SPARC has a similar > thing, and no doubt other architectures do too. > > After all, there shouldn't be much need for more than 2GB of virtual > address space in an AVR cross compiler. So why pay the cache penalty > of 64-bit pointers and longs (GCC generally tries to avoid using "long" > directly) when a 32-bit pointer will do? > > Many years ago, I moved the HOST_WIDE_INT fields out of rtunion > and into the main rtx_def union because it produced a significant > speed-up on n32 IRIX. That was before tree-level optimisation, But of course that doesn't change the alignment requirement of that union which is the issue on lp64 hosts. Also as HOST_WIDE_INT is 64bits for most ilp32 targets as well it doesn't necessarily save ilp32 hosts from having this issue (unless long long isn't aligned to 8 bytes for them). So what I said is that arranging for the 32bit hole to contain useful data for most RTXen should be possible. Richard. > but I don't think we've really pruned that much RTL optimisation > since then, so I'd be surprised if much has changed.
[v3] Fix PR 54754: use atomic built-ins for libstdc++ parallel mode
2012-10-09 Jonathan Wakely
PR libstdc++/54754
* include/parallel/compatibility.h: Use atomic built-ins when they are
lock-free.
Tested x86_64-linux, i386-linux, powerpc64-linux. There are some
time-outs when running the 'check-parallel' testsuite on ppc64 which
can be investigated later.
Committed to trunk.
commit c1827f0c56dfbffc5e760b2fa4421bbd6b5f3da2
Author: Jonathan Wakely
Date: Mon Oct 8 22:32:31 2012 +0100
PR libstdc++/54754
* include/parallel/compatibility.h: Use atomic built-ins when they are
lock-free.
diff --git a/libstdc++-v3/include/parallel/compatibility.h
b/libstdc++-v3/include/parallel/compatibility.h
index 03506d8..a58e65f 100644
--- a/libstdc++-v3/include/parallel/compatibility.h
+++ b/libstdc++-v3/include/parallel/compatibility.h
@@ -51,154 +51,70 @@ __attribute((dllimport)) void __attribute__((stdcall))
Sleep (unsigned long);
namespace __gnu_parallel
{
- // These atomic functions only work on integers
-
- /** @brief Add a value to a variable, atomically.
- *
- * Implementation is heavily platform-dependent.
- * @param __ptr Pointer to a 32-bit signed integer.
- * @param __addend Value to add.
- */
- inline int32_t
- __fetch_and_add_32(volatile int32_t* __ptr, int32_t __addend)
- {
-return __atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
- }
-
- /** @brief Add a value to a variable, atomically.
- *
- * Implementation is heavily platform-dependent.
- * @param __ptr Pointer to a 64-bit signed integer.
- * @param __addend Value to add.
- */
- inline int64_t
- __fetch_and_add_64(volatile int64_t* __ptr, int64_t __addend)
- {
-#if defined(__x86_64)
-return __atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
-#elif defined(__i386) && \
- (defined(__i686) || defined(__pentium4) || defined(__athlon) \
- || defined(__k8) || defined(__core2))
-return __atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
-#else //fallback, slow
-#if defined(__i386)
-// XXX doesn'__t work with -march=native
-//#warning "please compile with -march=i686 or better"
-#endif
-#pragma message("slow __fetch_and_add_64")
-int64_t __res;
-#pragma omp critical
+ template
+inline _Tp
+__add_omp(volatile _Tp* __ptr, _Tp __addend)
{
- __res = *__ptr;
- *(__ptr) += __addend;
+ int64_t __res;
+#pragma omp critical
+ {
+ __res = *__ptr;
+ *(__ptr) += __addend;
+ }
+ return __res;
}
-return __res;
-#endif
- }
/** @brief Add a value to a variable, atomically.
*
- * Implementation is heavily platform-dependent.
* @param __ptr Pointer to a signed integer.
* @param __addend Value to add.
*/
template
- inline _Tp
- __fetch_and_add(volatile _Tp* __ptr, _Tp __addend)
- {
-if (sizeof(_Tp) == sizeof(int32_t))
- return
-(_Tp)__fetch_and_add_32((volatile int32_t*) __ptr, (int32_t)__addend);
-else if (sizeof(_Tp) == sizeof(int64_t))
- return
-(_Tp)__fetch_and_add_64((volatile int64_t*) __ptr, (int64_t)__addend);
-else
- _GLIBCXX_PARALLEL_ASSERT(false);
- }
-
- /** @brief Compare @c *__ptr and @c __comparand. If equal, let @c
- * *__ptr=__replacement and return @c true, return @c false otherwise.
- *
- * Implementation is heavily platform-dependent.
- * @param __ptr Pointer to 32-bit signed integer.
- * @param __comparand Compare value.
- * @param __replacement Replacement value.
- */
- inline bool
- __compare_and_swap_32(volatile int32_t* __ptr, int32_t __comparand,
-int32_t __replacement)
- {
-return __atomic_compare_exchange_n(__ptr, &__comparand, __replacement,
- false, __ATOMIC_ACQ_REL,
- __ATOMIC_RELAXED);
- }
+inline _Tp
+__fetch_and_add(volatile _Tp* __ptr, _Tp __addend)
+{
+ if (__atomic_always_lock_free(sizeof(_Tp), __ptr))
+ return __atomic_fetch_add(__ptr, __addend, __ATOMIC_ACQ_REL);
+ return __add_omp(__ptr, __addend);
+}
- /** @brief Compare @c *__ptr and @c __comparand. If equal, let @c
- * *__ptr=__replacement and return @c true, return @c false otherwise.
- *
- * Implementation is heavily platform-dependent.
- * @param __ptr Pointer to 64-bit signed integer.
- * @param __comparand Compare value.
- * @param __replacement Replacement value.
- */
- inline bool
- __compare_and_swap_64(volatile int64_t* __ptr, int64_t __comparand,
-int64_t __replacement)
- {
-#if defined(__x86_64)
-return __atomic_compare_exchange_n(__ptr, &__comparand, __replacement,
- false, __ATOMIC_ACQ_REL,
- __ATOMIC_RELAXED);
-#elif defined(__i386) && \
- (defined(__i686) || defined(__pentium4) || defined(__athlon) \
- || defined(__k8) || defined(__core2))
-ret
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
On 9 October 2012 01:39, Jack Howarth wrote: >The --enable-libstdcxx-time=yes configure option fails to validate the > presence of a usable nanosleep() call on darwin due to its use of pre-2008 > POSIX timers. As both nanosleep() and sched_yield() have always been available > on darwin, the attached patch simply defines _GLIBCXX_USE_NANOSLEEP and > _GLIBCXX_USE_SCHED_YIELD in config/os/bsd/darwin/os_defines.h. This also has > the advantage of effectively making --enable-libstdcxx-time=yes the default > on darwin. Regression tested on x86_64-apple-darwin12. >Okay for gcc trunk as well as gcc-4_7-branch/gcc-4_6-branch/gcc-4_5-branch? The 4.5 branch is closed, so definitely not alright there. I don't like the sched_yield macro being set there because it's detected correctly by configure anyway, but I'm not going to labour that point any more. OK for trunk, it's not a regression so I'm not sure about the branches. If it doesn't cause problems on the trunk we can decide whether to apply it to the 4.7 branch later.
Fix my change to unroll_loop_constant_iterations
H, I hope this change is responsible for today misoptimizations of SPEC at -O3. While updating unroll_loop_constant_iterations and fighting with double_int operations I made two trivial mistakes. I am bootstrapping/regtesting the following and will commit it as obvious if it passes. Honza * loop-unroll.c (unroll_loop_constant_iterations): Fix previous patch. Index: loop-unroll.c === --- loop-unroll.c (revision 192239) +++ loop-unroll.c (working copy) @@ -740,6 +740,7 @@ unroll_loop_constant_iterations (struct apply_opt_in_copies (opt_info, exit_mod + 1, false, false); desc->niter -= exit_mod + 1; + loop->nb_iterations_upper_bound -= double_int::from_uhwi (exit_mod + 1); if (loop->any_estimate && double_int::from_uhwi (exit_mod + 1).ule (loop->nb_iterations_estimate)) @@ -795,12 +796,12 @@ unroll_loop_constant_iterations (struct desc->niter /= max_unroll + 1; loop->nb_iterations_upper_bound -= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (exit_mod += loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (max_unroll + 1), FLOOR_DIV_EXPR); if (loop->any_estimate) loop->nb_iterations_estimate - = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (exit_mod + = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (max_unroll + 1), FLOOR_DIV_EXPR); desc->niter_expr = GEN_INT (desc->niter);
Re: [PATCH 0/7] s390 improvements with r[ioxn]sbg
On 10/08/12 04:31, Richard Henderson wrote: > Only "tested" visually, by examining assembly diffs of the > runtime libraries between successive patches. All told it > would appear to be some remarkable code size improvements. > > Please test. Thanks a lot for looking into this! I'll test the patches and try to fix the remaining issues. Bye, -Andreas-
Re: Profile housekeeping 6/n (-fprofile-consistency-report)
> On Sat, Oct 6, 2012 at 5:56 PM, Jan Hubicka wrote: > > Hi, > > does this look better? Moving to cfg.c would importing tree-pass.h and rtl.h > > that is not cool either. predict.c does all of these. > > Obviously can also go to a separate file, if preferred. > > Attached is how I would do it. What do you think about this? > > Ciao! > Steven > > * basic-block. (profile_record): New struct, moved from passes.c. > * cfghooks.h (struct cfg_hooks) : New hook. > (account_profile_record): New prototype. > * cfghooks.c (account_profile_record): New function. > * tree-cfg.c (gimple_account_profile_record): New function > (gimple_cfg_hooks): Add it. > * cfgrtl.c (rtl_account_profile_record): New function > (rtl_cfg_hooks, cfg_layout_rtl_cfg_hooks): Add it. > * passes.c (check_profile_consistency): Simplify. Move IR-dependent > code around using cfghooks machinery. OK, I did not wanted to go as far as adding a hook, but why not. Patch approved. Thanks for looking into it! Honza
[AARCH64-4.7] Merge from upstream gcc-4_7-branch r192191
Hi, I have just merged upstream gcc-4_7-branch on the aarch64-4.7-branch up to r192191. Thanks Sofiane
[AARCH64] Merge from upstream trunk r192192
Hi, I have just merged upstream trunk on the aarch64-branch up to r192192. Thanks Sofiane
[PATCH] Rename target arm-rtemseabi to arm-rtems
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite results for arm-rtems4.11:
http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02507.html
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From d3688bd82c85e0c3bb9302e1235a168e4207cbd1 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Mon, 24 Sep 2012 17:49:36 +0200
Subject: [PATCH] Rename target arm-rtemseabi to arm-rtems
---
gcc/config.gcc |6 +++---
libgcc/config.host |8 ++--
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d6c8153..2400b3c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -270,7 +270,6 @@ case ${target} in
| arm*-*-elf\
| arm*-*-freebsd* \
| arm*-*-linux* \
- | arm*-*-rtems* \
| arm*-*-uclinux* \
| i[34567]86-go32-* \
| i[34567]86-*-go32* \
@@ -858,7 +857,7 @@ arm*-*-uclinux*eabi*) # ARM ucLinux
# The EABI requires the use of __cxa_atexit.
default_use_cxa_atexit=yes
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3. Correctly modeling that requires the use of
# TImode.
@@ -872,9 +871,10 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="${tmake_file} arm/t-bpabi"
use_gcc_stdint=wrap
;;
- arm*-*-rtemseabi*)
+ arm*-*-rtems*)
tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
+ use_gcc_stdint=provide
;;
arm*-*-symbianelf*)
tm_file="${tm_file} arm/symbian.h"
diff --git a/libgcc/config.host b/libgcc/config.host
index 3689024..a93e0de 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -343,11 +343,11 @@ arm*-*-ecos-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
tm_file="$tm_file arm/bpabi-lib.h"
case ${host} in
- arm*-*-eabi* | arm*-*-rtemseabi*)
+ arm*-*-eabi* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-bpabi"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
;;
@@ -360,10 +360,6 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
unwind_header=config/arm/unwind-arm.h
;;
-arm*-*-rtems*)
- tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
- extra_parts="$extra_parts crti.o crtn.o"
- ;;
arm*-*-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
--
1.6.4.2
Re: [PATCH] Rename target arm-rtemseabi to arm-rtems
On 10/09/2012 11:08 AM, Sebastian Huber wrote: Hello, this is an updated patch for the GCC 4.8. It renames the target "arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard RTEMS target pattern "$ARCH-rtems". GCC test suite results for arm-rtems4.11: http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02507.html Sorry, change log was missing: 2012-09-25 Sebastian Huber * config.gcc (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename "arm*-*-rtemseabi*" to "arm*-*-rtems*". 2012-09-25 Sebastian Huber * config.host (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename "arm*-*-rtemseabi*" to "arm*-*-rtems*". -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Small cleanup/memory leak plugs for lto
On Mon, Oct 8, 2012 at 10:05 PM, Tobias Burnus wrote:
> Some more issues found by Coverity scanner.
>
> lto-cgraph.c: The code seems to be unused, besides, it's a zero-trip loop as
> parm_num is set to 0 and then checked non nonzeroness.
>
> lto-opts: The check whether first_p is non NULL is always false: All calls
> have a variable ref as argument - and first_p is unconditionally
> dereferenced.
>
> lto_obj_file_open: One could check additionally check "lo" is NULL, but that
> has then to be directly after the XCNEW as already lto_file_init
> dereferences "lo".
static void
append_to_collect_gcc_options (struct obstack *ob,
bool *first_p, const char *opt)
{
const char *p, *q = opt;
- if (!first_p)
-obstack_grow (ob, " ", 1);
bogus change. It should be
if (!*first_p)
obstack_grow (ob, " ", 1);
The rest looks ok. Please re-test with the above change.
Thanks,
Richard.
> Build and regtested on x86-64-gnu-linux
>
> Tobias
Re: [SH] PR 54760 - Document new thread pointer built-ins
Oleg Endo wrote: > This adds documentation on the new thread pointer built-ins that were > added recently to the SH target. > Tested with 'make info dvi pdf'. > OK? OK. Regards, kaz
Re: [SH] PR 34777 - Add test case
Oleg Endo wrote:
> This adds the reduced test case as mentioned by Kaz in the PR to the
> test suite.
> Tested with
> make -k check-gcc RUNTESTFLAGS="compile.exp=pr34777*
> --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> OK?
It should be put into gcc.target/sh instead of gcc.c-torture/compile
and tested with -Os -fschedule-insns -fPIC -mprefergot, shouldn't it?
Regards,
kaz
Re: [wwwdocs] SH 4.8 changes - document thread pointer built-ins
Oleg Endo wrote: > This documents the new thread pointer built-ins in the SH www changes > for 4.8. > OK? Looks OK to me. Regards, kaz
Re: Fix my change to unroll_loop_constant_iterations
> H,
> I hope this change is responsible for today misoptimizations of SPEC at -O3.
> While updating unroll_loop_constant_iterations and fighting with double_int
> operations I made two trivial mistakes.
>
> I am bootstrapping/regtesting the following and will commit it as obvious if
> it passes.
>
> Honza
>
> * loop-unroll.c (unroll_loop_constant_iterations): Fix previous patch.
Unforutnately there is one other case where one has to be extra cureful about
overflows.
This is in fact latent bug in the unroller, but it now reproduce with -O3
-fpeel-loops
bootstrap because estimates tends to be close to maximum of the integer types.
I am re-starting testing with the following patch and will commit if passes
(but i will be till 2pm on bus).
My apologizes for the breakage.
Honza
Index: loop-unroll.c
===
--- loop-unroll.c (revision 192240)
+++ loop-unroll.c (working copy)
@@ -740,6 +740,7 @@ unroll_loop_constant_iterations (struct
apply_opt_in_copies (opt_info, exit_mod + 1, false, false);
desc->niter -= exit_mod + 1;
+ loop->nb_iterations_upper_bound -= double_int::from_uhwi (exit_mod +
1);
if (loop->any_estimate
&& double_int::from_uhwi (exit_mod + 1).ule
(loop->nb_iterations_estimate))
@@ -795,12 +796,12 @@ unroll_loop_constant_iterations (struct
desc->niter /= max_unroll + 1;
loop->nb_iterations_upper_bound
-= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (exit_mod
+= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (max_unroll
+ 1),
FLOOR_DIV_EXPR);
if (loop->any_estimate)
loop->nb_iterations_estimate
- = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (exit_mod
+ = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (max_unroll
+ 1),
FLOOR_DIV_EXPR);
desc->niter_expr = GEN_INT (desc->niter);
@@ -879,8 +880,7 @@ decide_unroll_runtime_iterations (struct
/* If we have profile feedback, check whether the loop rolls. */
if ((estimated_loop_iterations (loop, &iterations)
|| max_loop_iterations (loop, &iterations))
- && iterations.fits_shwi ()
- && iterations.to_shwi () <= 2 * nunroll)
+ && iterations.ule (double_int::from_shwi (2 * nunroll)))
{
if (dump_file)
fprintf (dump_file, ";; Not unrolling loop, doesn't roll\n");
@@ -1280,8 +1280,7 @@ decide_peel_simple (struct loop *loop, i
/* If we have realistic estimate on number of iterations, use it. */
if (estimated_loop_iterations (loop, &iterations))
{
- if (!iterations.fits_shwi ()
- || iterations.to_shwi () + 1 > npeel)
+ if (double_int::from_shwi (npeel).ule (iterations))
{
if (dump_file)
{
@@ -1298,8 +1297,7 @@ decide_peel_simple (struct loop *loop, i
/* If we have small enough bound on iterations, we can still peel (completely
unroll). */
else if (max_loop_iterations (loop, &iterations)
- && iterations.fits_shwi ()
- && iterations.to_shwi () + 1 <= npeel)
+ && iterations.ult (double_int::from_shwi (npeel)))
npeel = iterations.to_shwi () + 1;
else
{
@@ -1449,8 +1447,7 @@ decide_unroll_stupid (struct loop *loop,
/* If we have profile feedback, check whether the loop rolls. */
if ((estimated_loop_iterations (loop, &iterations)
|| max_loop_iterations (loop, &iterations))
- && iterations.fits_shwi ()
- && iterations.to_shwi () <= 2 * nunroll)
+ && iterations.ule (double_int::from_shwi (2 * nunroll)))
{
if (dump_file)
fprintf (dump_file, ";; Not unrolling loop, doesn't roll\n");
Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure
I'd like to know if my direction is ok. I can look into other issues releated to this and fix them, but it doesn't make much sense if separate build is not supported and can be easily broken in the future. This patch is enough for 4.7 to have build working (at least in Android environment). Is it ok for release it into trunk and 4.7? I'll take care of remaining trunk issues with other patches if necessary. 2012/10/9 Benjamin De Kosnik : > >> On Android NDK libstdc++ is configured, built and packaged separately. >> The problem is not dependency on libgcc sources but rather dependency >> on the symlink which is generated during libgcc build and cannot be >> found if libstdc++ is configured and built separately. >> It was working fine for 4.4 and 4.6. This issue has been introduced >> in 4.7. > > I can verify that building this way works for 4.6. > > This style of build, building separately, has not been known to work > before. In fact, it was explicitly broken for years. I am quite > surprised (but delighted) to see it working in 4.6. > > Separate builds not mentioned here: > http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html > > This patch is fine. Alone, it's not enough to get you were you want to > go, as the build then dies in AC_OUTPUT, and libtool is not generated. > > > -benjamin -- Pavel Chupin Software Engineer Intel Corporation
Re: RFC: LRA for x86/x86-64 [7/9]
Thanks for the updates.
Vladimir Makarov writes:
>>> + a change in the offset between the eliminable register and its
>>> + substitution if UPDATE_P, or the full offset if FULL_P, or
>>> + otherwise zero.
>> I wonder if an enum would be better than two booleans?
>> It avoids invalid combinations like UPDATE_P && FULL_P
>> and might make the arguments more obvious too.
> IMHO, It is matter of choice. I don't like to introduce a new enum just
> for the function. It is pretty standard situation. I usually introduce
> enum when there are a few combinations prohibited.
OK. I agree this is probably personal preference.
>>> + /* The only time we want to replace a PLUS with a REG
>>> +(this occurs when the constant operand of the PLUS is
>>> +the negative of the offset) is when we are inside a
>>> +MEM. We won't want to do so at other times because
>>> +that would change the structure of the insn in a way
>>> +that reload can't handle. We special-case the
>>> +commonest situation in eliminate_regs_in_insn, so
>>> +just replace a PLUS with a PLUS here, unless inside a
>>> +MEM. */
>> Reload reference. Does this restriction still apply? The later comment:
> I don't think so. I removed the comment.
Well, the question was about the code as much as the comment.
The comment did describe what the code did:
if (mem_mode != 0
&& CONST_INT_P (XEXP (x, 1))
&& INTVAL (XEXP (x, 1)) == -offset)
return to;
else
return gen_rtx_PLUS (Pmode, to,
plus_constant (Pmode,
XEXP (x, 1), offset));
If the restriction doesn't apply any more then the mem_mode condition
should be removed. If does apply then we should have some sort of
comment to explain why.
I suppose the question is: what happens for PLUS match_operators?
If elimination changes a (plus (reg X) (const_int Y)) into (reg X'),
and the (plus ...) is matched via a match_operator, will LRA cope
correctly? Or does LRA require a plus matched via a match_operator
to remain a plus? Or shouldn't we eliminate match_operators at all,
and just process true operands?
I wasn't sure at this point (and still haven't read through everything,
so am still not sure now).
>>> +Note that there is no risk of modifying the structure of the insn,
>>> +since we only get called for its operands, thus we are either
>>> +modifying the address inside a MEM, or something like an address
>>> +operand of a load-address insn. */
> I removed this too.
I think that's still accurate and should be kept. I was just using
it to emphasise a point (probably badly, sorry).
>> makes it sound on face value like the MEM restriction above is a
>> reload-specific
>> thing. Same question for:
>>
>>> + /* As above, if we are not inside a MEM we do not want to
>>> + turn a PLUS into something else. We might try to do so here
>>> + for an addition of 0 if we aren't optimizing. */
It looks like your follow-up patch left this alone FWIW.
>>> +#ifdef WORD_REGISTER_OPERATIONS
>>> + /* On these machines, combine can create RTL of the form
>>> + (set (subreg:m1 (reg:m2 R) 0) ...)
>>> + where m1 < m2, and expects something interesting to
>>> + happen to the entire word. Moreover, it will use the
>>> + (reg:m2 R) later, expecting all bits to be preserved.
>>> + So if the number of words is the same, preserve the
>>> + subreg so that push_reload can see it. */
>>> + && ! ((x_size - 1) / UNITS_PER_WORD
>>> +== (new_size -1 ) / UNITS_PER_WORD)
>>> +#endif
>> Reload reference (push_reload). Do we still need this for LRA?
> It is hard me to say. So I would not touch this code at least for now.
> I changed push reload to LRA.
Could I ask you to reconsider? The situation that the comment describes
sounds like a bug to me. Removing it shouldn't affect the 4.8 submission.
It just seems to me that LRA is our big chance of getting rid of some
of this cruft. If we're too scared to touch code like this even on
a big change like reload to LRA, we'll never be able to touch it.
>>> +static void
>>> +eliminate_regs_in_insn (rtx insn, bool replace_p)
>>> +{
>>> + int icode = recog_memoized (insn);
>>> + rtx old_set = single_set (insn);
>>> + bool val;
>> "validate_p" might be a better name.
>>
> Done.
Sorry for being too terse. I see you've changed "replace_p" to
"validate_p", but I actually meant that _"val"_ should be changed
to "validate_p". Elsewhere you use "val" to mean "value number",
and "val" could equally mean "validate_p" or "validated_p".
"replace_p" was a good name. :-)
>>> + /* If an output operand changed from a REG
[PATCH] [AArch64] Add vcond, vcondu support.
Hi,
This patch adds support for vcond and vcondu to the AArch64
backend.
Tested with no regressions on aarch64-none-elf.
OK for aarch64-branch?
(If so, someone will have to commit for me, as I do not
have commit rights.)
Thanks
James Greenhalgh
---
2012-09-11 James Greenhalgh
Tejas Belagod
* config/aarch64/aarch64-simd.md
(aarch64_simd_bsl_internal): New pattern.
(aarch64_simd_bsl): Likewise.
(aarch64_vcond_internal): Likewise.
(vcondu): Likewise.
(vcond): Likewise.
* config/aarch64/iterators.md (UNSPEC_BSL): Add to define_constants.
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index a7ddfb1..c9b5e17 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1467,6 +1467,150 @@
(set_attr "simd_mode" "V2SI")]
)
+;; vbsl_* intrinsics may compile to any of vbsl/vbif/vbit depending on register
+;; allocation. For an intrinsic of form:
+;; vD = bsl_* (vS, vN, vM)
+;; We can use any of:
+;; bsl vS, vN, vM (if D = S)
+;; bit vD, vN, vS (if D = M, so 1-bits in vS choose bits from vN, else vM)
+;; bif vD, vM, vS (if D = N, so 0-bits in vS choose bits from vM, else vN)
+
+(define_insn "aarch64_simd_bsl_internal"
+ [(set (match_operand:VDQ 0 "register_operand" "=w,w,w")
+ (unspec:VDQ [(match_operand:VDQ 1 "register_operand" " 0,w,w")
+ (match_operand:VDQ 2 "register_operand" " w,w,0")
+ (match_operand:VDQ 3 "register_operand" " w,0,w")]
+UNSPEC_BSL))]
+ "TARGET_SIMD"
+ "@
+ bsl\\t%0., %2., %3.
+ bit\\t%0., %2., %1.
+ bif\\t%0., %3., %1."
+)
+
+(define_expand "aarch64_simd_bsl"
+ [(set (match_operand:VDQ 0 "register_operand")
+(unspec:VDQ [(match_operand: 1 "register_operand")
+ (match_operand:VDQ 2 "register_operand")
+ (match_operand:VDQ 3 "register_operand")]
+ UNSPEC_BSL))]
+ "TARGET_SIMD"
+{
+ /* We can't alias operands together if they have different modes. */
+ operands[1] = gen_lowpart (mode, operands[1]);
+})
+
+(define_expand "aarch64_vcond_internal"
+ [(set (match_operand:VDQ 0 "register_operand")
+ (if_then_else:VDQ
+ (match_operator 3 "comparison_operator"
+ [(match_operand:VDQ 4 "register_operand")
+ (match_operand:VDQ 5 "nonmemory_operand")])
+ (match_operand:VDQ 1 "register_operand")
+ (match_operand:VDQ 2 "register_operand")))]
+ "TARGET_SIMD"
+{
+ int inverse = 0, has_zero_imm_form = 0;
+ rtx mask = gen_reg_rtx (mode);
+
+ switch (GET_CODE (operands[3]))
+{
+case LE:
+case LT:
+case NE:
+ inverse = 1;
+ /* Fall through. */
+case GE:
+case GT:
+case EQ:
+ has_zero_imm_form = 1;
+ break;
+case LEU:
+case LTU:
+ inverse = 1;
+ break;
+default:
+ break;
+}
+
+ if (!REG_P (operands[5])
+ && (operands[5] != CONST0_RTX (mode) || !has_zero_imm_form))
+operands[5] = force_reg (mode, operands[5]);
+
+ switch (GET_CODE (operands[3]))
+{
+case LT:
+case GE:
+ emit_insn (gen_aarch64_cmge (mask, operands[4], operands[5]));
+ break;
+
+case LE:
+case GT:
+ emit_insn (gen_aarch64_cmgt (mask, operands[4], operands[5]));
+ break;
+
+case LTU:
+case GEU:
+ emit_insn (gen_aarch64_cmhs (mask, operands[4], operands[5]));
+ break;
+
+case LEU:
+case GTU:
+ emit_insn (gen_aarch64_cmhi (mask, operands[4], operands[5]));
+ break;
+
+case NE:
+case EQ:
+ emit_insn (gen_aarch64_cmeq (mask, operands[4], operands[5]));
+ break;
+
+default:
+ gcc_unreachable ();
+}
+
+ if (inverse)
+emit_insn (gen_aarch64_simd_bsl (operands[0], mask, operands[2],
+operands[1]));
+ else
+emit_insn (gen_aarch64_simd_bsl (operands[0], mask, operands[1],
+operands[2]));
+
+ DONE;
+})
+
+(define_expand "vcond"
+ [(set (match_operand:VDQ 0 "register_operand")
+ (if_then_else:VDQ
+ (match_operator 3 "comparison_operator"
+ [(match_operand:VDQ 4 "register_operand")
+ (match_operand:VDQ 5 "nonmemory_operand")])
+ (match_operand:VDQ 1 "register_operand")
+ (match_operand:VDQ 2 "register_operand")))]
+ "TARGET_SIMD"
+{
+ emit_insn (gen_aarch64_vcond_internal (operands[0], operands[1],
+ operands[2], operands[3],
+ operands[4], operands[5]));
+ DONE;
+})
+
+
+(define_expand "vcondu"
+ [(set (match_operand:VDQ 0 "register_operand")
+ (if_then_else:VDQ
+ (match_operator 3 "comparison_operator"
+ [(match_operand:VDQ 4 "register_operand")
+ (match_operand:VDQ 5 "nonmemory_operand")])
+ (match_operand:VDQ 1 "register_operand")
+ (match_operand:VDQ 2 "register_operand")))]
+ "TARGET_SIMD"
+{
+ emit_insn (gen_aarch64_vcond_internal (operands[0], operands[1],
+ operands[2], operands[3],
+ operands[4], operands[5]));
+ DONE;
+})
+
;; Patterns fo
[c-family] Small tweak to -fdump-ada-spec
Hi,
we noticed that we dump TEMPLATE_DECLs that are built for template friend
declarations in the current file, which doesn't really make sense.
Tested on x86_64-suse-linux, OK for the mainline?
2012-10-09 Eric Botcazou
* c-ada-spec.c (dump_ada_template): Bail out for template declarations
declaring something coming from another file.
--
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c (revision 192137)
+++ c-ada-spec.c (working copy)
@@ -1700,10 +1700,18 @@ static int
dump_ada_template (pretty_printer *buffer, tree t,
int (*cpp_check)(tree, cpp_operation), int spc)
{
- tree inst = DECL_VINDEX (t);
/* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context. */
+ tree inst = DECL_VINDEX (t);
+ /* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context. */
+ tree result = DECL_RESULT_FLD (t);
int num_inst = 0;
+ /* Don't look at template declarations declaring something coming from
+ another file. This can occur for template friend declarations. */
+ if (LOCATION_FILE (decl_sloc (result, false))
+ != LOCATION_FILE (decl_sloc (t, false)))
+return 0;
+
while (inst && inst != error_mark_node)
{
tree types = TREE_PURPOSE (inst);
Re: [PATCH] Rename target arm-rtemseabi to arm-rtems
On 09/10/12 10:13, Sebastian Huber wrote: On 10/09/2012 11:08 AM, Sebastian Huber wrote: Hello, this is an updated patch for the GCC 4.8. It renames the target "arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard RTEMS target pattern "$ARCH-rtems". GCC test suite results for arm-rtems4.11: http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02507.html Sorry, change log was missing: 2012-09-25 Sebastian Huber * config.gcc (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename "arm*-*-rtemseabi*" to "arm*-*-rtems*". 2012-09-25 Sebastian Huber * config.host (arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename "arm*-*-rtemseabi*" to "arm*-*-rtems*". + use_gcc_stdint=provide This isn't mentioned in your changelogs and appears to be orthogonal to the rest of the patch. Please separate this out and re-submit separately. OK with that change. R.
[PATCH] Inline streamer_tree_cache_get
Not doing that appearantly keeps us avoiding this abstraction
in most places. All asserts in its implementation are overzealous
as well as VEC already has all required checking.
Committed as obvious (LTO bootstrap is broken for other reasons
right now).
Richard.
2012-10-09 Richard Guenther
* tree-streamer.c (streamer_tree_cache_get): Move ...
* tree-streamer.h (streamer_tree_cache_get): ... here as inline.
Index: gcc/tree-streamer.c
===
*** gcc/tree-streamer.c (revision 192247)
--- gcc/tree-streamer.c (working copy)
*** streamer_tree_cache_lookup (struct strea
*** 232,251
}
- /* Return the tree node at slot IX in CACHE. */
-
- tree
- streamer_tree_cache_get (struct streamer_tree_cache_d *cache, unsigned ix)
- {
- gcc_assert (cache);
-
- /* Make sure we're not requesting something we don't have. */
- gcc_assert (ix < VEC_length (tree, cache->nodes));
-
- return VEC_index (tree, cache->nodes, ix);
- }
-
-
/* Record NODE in CACHE. */
static void
--- 232,237
Index: gcc/tree-streamer.h
===
*** gcc/tree-streamer.h (revision 192247)
--- gcc/tree-streamer.h (working copy)
*** bool streamer_tree_cache_insert_at (stru
*** 93,100
void streamer_tree_cache_append (struct streamer_tree_cache_d *, tree);
bool streamer_tree_cache_lookup (struct streamer_tree_cache_d *, tree,
unsigned *);
- tree streamer_tree_cache_get (struct streamer_tree_cache_d *, unsigned);
struct streamer_tree_cache_d *streamer_tree_cache_create (void);
void streamer_tree_cache_delete (struct streamer_tree_cache_d *);
#endif /* GCC_TREE_STREAMER_H */
--- 93,108
void streamer_tree_cache_append (struct streamer_tree_cache_d *, tree);
bool streamer_tree_cache_lookup (struct streamer_tree_cache_d *, tree,
unsigned *);
struct streamer_tree_cache_d *streamer_tree_cache_create (void);
void streamer_tree_cache_delete (struct streamer_tree_cache_d *);
+ /* Return the tree node at slot IX in CACHE. */
+
+ static inline tree
+ streamer_tree_cache_get (struct streamer_tree_cache_d *cache, unsigned ix)
+ {
+ return VEC_index (tree, cache->nodes, ix);
+ }
+
+
#endif /* GCC_TREE_STREAMER_H */
Re: [PATCH] PR 53528 c++/ C++11 Generalized Attribute support
Dodji, The following tests are failing (with -m32): FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9) FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors) FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors) FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5) FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for excess errors) TIA Dominique
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote: > On 9 October 2012 01:39, Jack Howarth wrote: > >The --enable-libstdcxx-time=yes configure option fails to validate the > > presence of a usable nanosleep() call on darwin due to its use of pre-2008 > > POSIX timers. As both nanosleep() and sched_yield() have always been > > available > > on darwin, the attached patch simply defines _GLIBCXX_USE_NANOSLEEP and > > _GLIBCXX_USE_SCHED_YIELD in config/os/bsd/darwin/os_defines.h. This also has > > the advantage of effectively making --enable-libstdcxx-time=yes the default > > on darwin. Regression tested on x86_64-apple-darwin12. > >Okay for gcc trunk as well as > > gcc-4_7-branch/gcc-4_6-branch/gcc-4_5-branch? > > The 4.5 branch is closed, so definitely not alright there. > > I don't like the sched_yield macro being set there because it's > detected correctly by configure anyway, but I'm not going to labour > that point any more. Since we are defining _GLIBCXX_USE_NANOSLEEP in os_defines.h and effectively implementing half of the behavior of --enable-libstdcxx-time=yes, it seemed odd to not complete the process and define _GLIBCXX_USE_SCHED_YIELD as well. The usage is not as straight-forward as many other configure options (especially in light of the absence of rt timer support on darwin). > > OK for trunk, it's not a regression so I'm not sure about the > branches. If it doesn't cause problems on the trunk we can decide > whether to apply it to the 4.7 branch later. I guess the question is which branches have enough C++11 standard support to make the change meaningful to the end user.
Re: Fix my change to unroll_loop_constant_iterations
Hi,
this is patch I comitted after checking, double checking and tripple checking.
I tested the patch on x86_64-linux. Unfortunately -O3 -fpeel-loops
-funroll-loops bootstrap still fails for me (-O3 bootstrap works), but it seems
independent problem - i.e. it fails with the change reverted, too. I am
looking into it now.
I apologize for the breakage, I got completely sidetracked with the double_int
changes since I sort of missed the point that double_int has not signed nor
unsigned.
The patch fixes existing bug in overflow while computing iterations + 1 in
peeling decision. This exists on quite few releases and can trigger pointless
peeling of loops that iterate HOST_WIDE_INT_MAX times.
Honza
* loop-unroll.c (unroll_loop_constant_iterations): Add
update of loop->nb_iterations_upper_bound I missed in my previous
commit; use TRUNC_DIV_EXPR instead of FLOOR_DIV_EXPR to divide
iteration count.
(decide_unroll_runtime_iterations): Avoid overflow.
(unroll_loop_runtime_iterations): Use TRUNC_DIV_EXPR instead of
FLOOR_DIV_EXPR to update iteration bounds.
(decide_peel_simple): Avoid integer overflow when deciding
on number of peelings.
(decide_unroll_stupid): Likewise.
Index: loop-unroll.c
===
--- loop-unroll.c (revision 192240)
+++ loop-unroll.c (working copy)
@@ -740,6 +740,7 @@ unroll_loop_constant_iterations (struct
apply_opt_in_copies (opt_info, exit_mod + 1, false, false);
desc->niter -= exit_mod + 1;
+ loop->nb_iterations_upper_bound -= double_int::from_uhwi (exit_mod +
1);
if (loop->any_estimate
&& double_int::from_uhwi (exit_mod + 1).ule
(loop->nb_iterations_estimate))
@@ -795,14 +796,14 @@ unroll_loop_constant_iterations (struct
desc->niter /= max_unroll + 1;
loop->nb_iterations_upper_bound
-= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (exit_mod
+= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (max_unroll
+ 1),
- FLOOR_DIV_EXPR);
+ TRUNC_DIV_EXPR);
if (loop->any_estimate)
loop->nb_iterations_estimate
- = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (exit_mod
+ = loop->nb_iterations_estimate.udiv (double_int::from_uhwi (max_unroll
+ 1),
- FLOOR_DIV_EXPR);
+ TRUNC_DIV_EXPR);
desc->niter_expr = GEN_INT (desc->niter);
/* Remove the edges. */
@@ -876,11 +877,10 @@ decide_unroll_runtime_iterations (struct
return;
}
- /* If we have profile feedback, check whether the loop rolls. */
+ /* Check whether the loop rolls. */
if ((estimated_loop_iterations (loop, &iterations)
|| max_loop_iterations (loop, &iterations))
- && iterations.fits_shwi ()
- && iterations.to_shwi () <= 2 * nunroll)
+ && iterations.ult (double_int::from_shwi (2 * nunroll)))
{
if (dump_file)
fprintf (dump_file, ";; Not unrolling loop, doesn't roll\n");
@@ -1199,12 +1199,12 @@ unroll_loop_runtime_iterations (struct l
loop->nb_iterations_upper_bound
= loop->nb_iterations_upper_bound.udiv (double_int::from_uhwi (max_unroll
+ 1),
- FLOOR_DIV_EXPR);
+ TRUNC_DIV_EXPR);
if (loop->any_estimate)
loop->nb_iterations_estimate
= loop->nb_iterations_estimate.udiv (double_int::from_uhwi (max_unroll
+ 1),
- FLOOR_DIV_EXPR);
+ TRUNC_DIV_EXPR);
if (exit_at_end)
{
desc->niter_expr =
@@ -1280,8 +1280,7 @@ decide_peel_simple (struct loop *loop, i
/* If we have realistic estimate on number of iterations, use it. */
if (estimated_loop_iterations (loop, &iterations))
{
- if (!iterations.fits_shwi ()
- || iterations.to_shwi () + 1 > npeel)
+ if (double_int::from_shwi (npeel).ule (iterations))
{
if (dump_file)
{
@@ -1298,8 +1297,7 @@ decide_peel_simple (struct loop *loop, i
/* If we have small enough bound on iterations, we can still peel (completely
unroll). */
else if (max_loop_iterations (loop, &iterations)
- && iterations.fits_shwi ()
- && iterations.to_shwi () + 1 <= npeel)
+ && iterations.ult (double_int::from_shwi (npeel)))
npeel = iterations.to_shwi () + 1;
else
{
@@ -1446,11 +1444,10 @@ decide_unroll_stupid (struct loop *loop,
return;
[PING] Re: [RFA 1/n] Fix if conversion interactions with block partitioning
PING. On 24 September 2012 11:34, Matthew Gretton-Dann wrote: > On Wednesday 05 September 2012 13:47:19 Steven Bosscher wrote: >> On Wed, Sep 5, 2012 at 1:25 PM, Matthew Gretton-Dann wrote: >> > + /* If the two blocks are in different partitions we do not want to mark >> > + this as a fallthru edge. */ >> > + if (BB_PARTITION (b) != BB_PARTITION (c)) >> > +return; >> > + >> >> I think you should look for a REG_CROSSING_JUMP note on BB_END instead >> of comparing BB_PARTITION. > > Sorry for the delay in getting back to this. > > Anyway, I had a look at how other parts of cfgrtl.c handled this and it seems > as if they do both your suggestion and the check against different partitions. > > So this is what I have implemented in the attached patch. > > Cross tested arm-none-linux-gnueabi with QEmu. > > OK for trunk? > > Thanks, > > Matt > > gcc/ChangeLog: > > 2012-09-24 Matthew Gretton-Dann > > * cfgrtl.c (rtl_tidy_fallthru_edge): Don't tidy edges which > cross partitions. > > -- > Matthew Gretton-Dann > Linaro Toolchain Working Group > matthew.gretton-d...@linaro.org -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c index c62b5bc..8fcf7e4 100644 --- a/gcc/cfgrtl.c +++ b/gcc/cfgrtl.c @@ -1572,6 +1572,12 @@ rtl_tidy_fallthru_edge (edge e) if (INSN_P (q)) return; + /* If the two blocks are in different partitions we do not want to mark + this as a fallthru edge. */ + if (find_reg_note (BB_END (b), REG_CROSSING_JUMP, NULL_RTX) + || BB_PARTITION (b) != BB_PARTITION (c)) +return; + /* Remove what will soon cease being the jump insn from the source block. If block B consisted only of this single jump, turn it into a deleted note. */
[testsuite] Fix gcc.target/i386/long-double-80-7.c (PR target/54866)
As described in the PR, gcc.target/i386/long-double-80-7.c FAILs on
Solaris 9/x86 and 32-bit Linux/x86. The following patch fixes this.
Tested with the appropriate runtest invocation on i386-pc-solaris2.9,
i386-pc-solaris2.10, i686-unknown-linux-gnu and
x86_64-unknown-linux-gnu, installed on mainline as preapproved by Uros
in the PR.
Rainer
2012-10-09 Rainer Orth
PR target/54866
* gcc.target/i386/long-double-80-7.c: Add -msse2 to dg-options.
# HG changeset patch
# Parent 63ba1e90f1c71c5d7dff8f4f4f43f3fe4e54e84b
Fix gcc.target/i386/long-double-80-7.c (PR target/54866)
diff --git a/gcc/testsuite/gcc.target/i386/long-double-80-7.c b/gcc/testsuite/gcc.target/i386/long-double-80-7.c
--- a/gcc/testsuite/gcc.target/i386/long-double-80-7.c
+++ b/gcc/testsuite/gcc.target/i386/long-double-80-7.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O0 -mlong-double-64 -mfpmath=sse" } */
+/* { dg-options "-O0 -mlong-double-64 -mfpmath=sse -msse2" } */
/* { dg-require-effective-target sse2 } */
#include "sse2-check.h"
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Rename target arm-rtemseabi to arm-rtems
Updated patch.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From b338cd309306c1540b2519188e83f76950755cc5 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Mon, 24 Sep 2012 17:49:36 +0200
Subject: [PATCH] Rename target arm-rtemseabi to arm-rtems
2012-10-09 Sebastian Huber
* config.gcc
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".
2012-10-09 Sebastian Huber
* config.host
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".
---
gcc/config.gcc |5 ++---
libgcc/config.host |8 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d6c8153..014b837 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -270,7 +270,6 @@ case ${target} in
| arm*-*-elf\
| arm*-*-freebsd* \
| arm*-*-linux* \
- | arm*-*-rtems* \
| arm*-*-uclinux* \
| i[34567]86-go32-* \
| i[34567]86-*-go32* \
@@ -858,7 +857,7 @@ arm*-*-uclinux*eabi*) # ARM ucLinux
# The EABI requires the use of __cxa_atexit.
default_use_cxa_atexit=yes
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3. Correctly modeling that requires the use of
# TImode.
@@ -872,7 +871,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="${tmake_file} arm/t-bpabi"
use_gcc_stdint=wrap
;;
- arm*-*-rtemseabi*)
+ arm*-*-rtems*)
tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
;;
diff --git a/libgcc/config.host b/libgcc/config.host
index 3689024..a93e0de 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -343,11 +343,11 @@ arm*-*-ecos-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
tm_file="$tm_file arm/bpabi-lib.h"
case ${host} in
- arm*-*-eabi* | arm*-*-rtemseabi*)
+ arm*-*-eabi* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-bpabi"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
;;
@@ -360,10 +360,6 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
unwind_header=config/arm/unwind-arm.h
;;
-arm*-*-rtems*)
- tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
- extra_parts="$extra_parts crti.o crtn.o"
- ;;
arm*-*-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
--
1.7.7
Re: [PATCH] Rename target arm-rtemseabi to arm-rtems
On 09/10/12 14:23, Sebastian Huber wrote:
Updated patch.
OK.
R.
0001-Rename-target-arm-rtemseabi-to-arm-rtems.patch
From b338cd309306c1540b2519188e83f76950755cc5 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Mon, 24 Sep 2012 17:49:36 +0200
Subject: [PATCH] Rename target arm-rtemseabi to arm-rtems
2012-10-09 Sebastian Huber
* config.gcc
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".
2012-10-09 Sebastian Huber
* config.host
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*): Rename
"arm*-*-rtemseabi*" to "arm*-*-rtems*".
---
gcc/config.gcc |5 ++---
libgcc/config.host |8 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index d6c8153..014b837 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -270,7 +270,6 @@ case ${target} in
| arm*-*-elf \
| arm*-*-freebsd*\
| arm*-*-linux* \
- | arm*-*-rtems* \
| arm*-*-uclinux*\
| i[34567]86-go32-* \
| i[34567]86-*-go32* \
@@ -858,7 +857,7 @@ arm*-*-uclinux*eabi*) # ARM ucLinux
# The EABI requires the use of __cxa_atexit.
default_use_cxa_atexit=yes
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3. Correctly modeling that requires the use of
# TImode.
@@ -872,7 +871,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="${tmake_file} arm/t-bpabi"
use_gcc_stdint=wrap
;;
- arm*-*-rtemseabi*)
+ arm*-*-rtems*)
tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
;;
diff --git a/libgcc/config.host b/libgcc/config.host
index 3689024..a93e0de 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -343,11 +343,11 @@ arm*-*-ecos-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl
arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
-arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
+arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
tm_file="$tm_file arm/bpabi-lib.h"
case ${host} in
- arm*-*-eabi* | arm*-*-rtemseabi*)
+ arm*-*-eabi* | arm*-*-rtems*)
tmake_file="${tmake_file} arm/t-bpabi"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
;;
@@ -360,10 +360,6 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtemseabi*)
tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl arm/t-softfp
t-softfp"
unwind_header=config/arm/unwind-arm.h
;;
-arm*-*-rtems*)
- tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl
arm/t-softfp t-softfp"
- extra_parts="$extra_parts crti.o crtn.o"
- ;;
arm*-*-elf)
tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf t-softfp-excl
arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
Re: [PATCH] PR 53528 c++/ C++11 Generalized Attribute support
Hello Dominique, domi...@lps.ens.fr (Dominique Dhumieres) writes: > The following tests are failing (with -m32): > > FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9) > FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors) > FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors) > FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5) > FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for excess errors) Thank you for the heads-up. I am currently testing a patch for these. Sorry for the inconvenience. -- Dodji
Re: RFA: darwin PATCH to fix build, internal visibility
> > These tests are still failing on darwin. I think tha
> > target { ! *-*-solaris2* } { ! *-*-darwin* }
> > sould be replaced with
> > target { ! { *-*-solaris2* *-*-darwin* } }
>
> Could someone with a darwin box handy make the appropriate change?
I have never really understood the logic of the "target" syntax,
so IMO the problem with the proposed change is not with darwin,
but with other platforms I don't have access to.
Indeed I have checked on x86_64-apple-darwin10 and powerpc-apple-darwin9
that the failures go away with the following patch:
diff -up ../_clean/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
--- ../_clean/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
2012-10-04 19:50:52.0 +0200
+++ gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C 2012-10-08
10:29:40.0 +0200
@@ -1,7 +1,7 @@
/* Test that #pragma GCC visibility does not override class member specific
settings. */
/* { dg-do compile } */
/* { dg-require-visibility "internal" } */
-/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { !
*-*-solaris2* } { ! *-*-darwin* } } } }*/
+/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! {
*-*-solaris2* *-*-darwin* } } } } }*/
/* { dg-final { scan-assembler "\\.(internal|hidden).*Foo.methodEv" { target
*-*-solaris2* } } } */
#pragma GCC visibility push(hidden)
diff -up ../_clean/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
--- ../_clean/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
2012-10-04 19:50:52.0 +0200
+++ gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C 2012-10-08
10:30:32.0 +0200
@@ -1,7 +1,7 @@
/* Test that #pragma GCC visibility does not override class member specific
settings. */
/* { dg-do compile } */
/* { dg-require-visibility "internal" } */
-/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { !
*-*-solaris2* } { ! *-*-darwin* } } } } */
+/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! {
*-*-solaris2* *-*-darwin* } } } } } */
/* { dg-final { scan-assembler "\\.(internal|hidden).*Foo.methodEv" { target
*-*-solaris2* } } } */
#pragma GCC visibility push(hidden)
Dominique
Re: [Patch ARM] Fix that miss DMB instruction for ARMv6-M
On 08/10/12 08:29, Terry Guo wrote: Hi, When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails with error message: /tmp/ccMqZdgc.o: In function `std::atomic::load(std::memory_order) const':^M /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/ libstdc++-v3/include/atomic:202: undefined reference to `__sync_synchronize'^M /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/ libstdc++-v3/include/atomic:202: undefined reference to `__sync_synchronize'^M /tmp/ccMqZdgc.o: In function `std::atomic::load(std::memory_order) const':^M /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/ libstdc++-v3/include/atomic:202: undefined reference to `__sync_synchronize'^M /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/ libstdc++-v3/include/atomic:202: undefined reference to `__sync_synchronize'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 After investigation, the reason is current gcc doesn't think armv6-m has DMB instruction. While according to ARM manuals, it has. With this wrong assumption, the expand_mem_thread_fence will generate a call to library function __sync_synchronize rather than DMB instruction. While no code to implement this library function, so the error generates. The attached patch intends to fix this issue by letting gcc also think armv6-m has DMB instruction. Is it OK to trunk? BR, Terry 2012-10-08 Terry Guo * config/arm/arm.c (arm_arch6m): New variable to denote armv6-m architecture. * config/arm/arm.h (TARGET_HAVE_DMB): The armv6-m also has DMB instruction. Ok. R.
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
On x86_64-apple-darwin10 The following tests: g++.dg/gomp/tls-5.C g++.dg/tls/thread_local-cse.C g++.dg/tls/thread_local-order*.C g++.dg/tls/thread_local*g.C fail with sorry, unimplemented: dynamic initialization of non-function-local thread_local variables not supported on this target In addition, I see FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local7.C scan-assembler-not \\.data and FAIL: g++.dg/tls/static-1.C * for the latter, the error is Undefined symbols: "TLS init function for A::i", referenced from: test()in ccNTapVf.o test()in ccNTapVf.o __ZTHN1A1iE$non_lazy_ptr in ccNTapVf.o TIA Dominique
[PATCH] Fix PR54837
This should fix PR54837, LTO is not yet prepared for
debug source stmts. The following moves checking code that
triggers to a place where it hopefully does not trigger.
LTO bootstrap is broken in other ways though :(
Will commit after non-LTO bootstrap finished to make progress.
Richard.
2012-10-09 Richard Guenther
PR middle-end/54837
* cfgexpand.c (expand_debug_source_expr): Move checking
code conditional on a found decl_debug_args vector.
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 192253)
+++ gcc/cfgexpand.c (working copy)
@@ -3521,25 +3521,23 @@ expand_debug_source_expr (tree exp)
&& !DECL_INCOMING_RTL (exp)
&& DECL_ABSTRACT_ORIGIN (current_function_decl))
{
- tree aexp = exp;
- if (DECL_ABSTRACT_ORIGIN (exp))
- aexp = DECL_ABSTRACT_ORIGIN (exp);
+ tree aexp = DECL_ORIGIN (exp);
if (DECL_CONTEXT (aexp)
== DECL_ABSTRACT_ORIGIN (current_function_decl))
{
VEC(tree, gc) **debug_args;
unsigned int ix;
tree ddecl;
-#ifdef ENABLE_CHECKING
- tree parm;
- for (parm = DECL_ARGUMENTS (current_function_decl);
-parm; parm = DECL_CHAIN (parm))
- gcc_assert (parm != exp
- && DECL_ABSTRACT_ORIGIN (parm) != aexp);
-#endif
debug_args = decl_debug_args_lookup (current_function_decl);
if (debug_args != NULL)
{
+#ifdef ENABLE_CHECKING
+ tree parm;
+ for (parm = DECL_ARGUMENTS (current_function_decl);
+parm; parm = DECL_CHAIN (parm))
+ gcc_assert (parm != exp
+ && DECL_ABSTRACT_ORIGIN (parm) != aexp);
+#endif
for (ix = 0; VEC_iterate (tree, *debug_args, ix, ddecl);
ix += 2)
if (ddecl == aexp)
Re: [PATCH] Fix PR54837
On Tue, 9 Oct 2012, Richard Biener wrote:
>
> This should fix PR54837, LTO is not yet prepared for
> debug source stmts. The following moves checking code that
> triggers to a place where it hopefully does not trigger.
>
> LTO bootstrap is broken in other ways though :(
>
> Will commit after non-LTO bootstrap finished to make progress.
As Jakub says the checking doesn't add much so I am installing
the following instead, as obvious.
Richard.
2012-10-09 Richard Guenther
PR middle-end/54837
* cfgexpand.c (expand_debug_source_expr): Move checking
code conditional on a found decl_debug_args vector.
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 192253)
+++ gcc/cfgexpand.c (working copy)
@@ -3521,22 +3521,13 @@ expand_debug_source_expr (tree exp)
&& !DECL_INCOMING_RTL (exp)
&& DECL_ABSTRACT_ORIGIN (current_function_decl))
{
- tree aexp = exp;
- if (DECL_ABSTRACT_ORIGIN (exp))
- aexp = DECL_ABSTRACT_ORIGIN (exp);
+ tree aexp = DECL_ORIGIN (exp);
if (DECL_CONTEXT (aexp)
== DECL_ABSTRACT_ORIGIN (current_function_decl))
{
VEC(tree, gc) **debug_args;
unsigned int ix;
tree ddecl;
-#ifdef ENABLE_CHECKING
- tree parm;
- for (parm = DECL_ARGUMENTS (current_function_decl);
-parm; parm = DECL_CHAIN (parm))
- gcc_assert (parm != exp
- && DECL_ABSTRACT_ORIGIN (parm) != aexp);
-#endif
debug_args = decl_debug_args_lookup (current_function_decl);
if (debug_args != NULL)
{
Re: [PATCH] Fix PR54837
On Tue, Oct 09, 2012 at 04:35:16PM +0200, Richard Biener wrote: > As Jakub says the checking doesn't add much so I am installing > the following instead, as obvious. > > Richard. > > 2012-10-09 Richard Guenther > > PR middle-end/54837 > * cfgexpand.c (expand_debug_source_expr): Move checking > code conditional on a found decl_debug_args vector. Thanks. Jakub
Re: [testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux
On 27/09/12 01:02, Janis Johnson wrote:
Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
targets, as described in PR54732. This patch adds an XFAIL.
Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
Janis
gcc-20120926-5
2012-09-26 Janis Johnson
* gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.
Index: gcc.target/arm/div64-unwinding.c
===
--- gcc.target/arm/div64-unwinding.c(revision 191765)
+++ gcc.target/arm/div64-unwinding.c(working copy)
@@ -1,6 +1,7 @@
/* Performing a 64-bit division should not pull in the unwinder. */
-/* { dg-do run } */
+/* The test is expected to fail for GNU/Linux; see PR54723. */
+/* { dg-do run { xfail *-*-linux* } } */
/* { dg-options "-O0" } */
#include
I don't like this. To me, XFAIL means "there's a bug here, but we're
not too worried about it". The behaviour on linux targets is correct,
so this test should either PASS or be skipped.
R.
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote: > On x86_64-apple-darwin10 The following tests: > > g++.dg/gomp/tls-5.C > g++.dg/tls/thread_local-cse.C > g++.dg/tls/thread_local-order*.C > g++.dg/tls/thread_local*g.C > > fail with > > sorry, unimplemented: dynamic initialization of non-function-local > thread_local variables not supported on this target > > In addition, I see > > FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test > FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test > FAIL: g++.dg/tls/thread_local7.C scan-assembler-not \\.data > > and > > FAIL: g++.dg/tls/static-1.C * > > for the latter, the error is > > Undefined symbols: > "TLS init function for A::i", referenced from: > test()in ccNTapVf.o > test()in ccNTapVf.o > __ZTHN1A1iE$non_lazy_ptr in ccNTapVf.o > > TIA > > Dominique This patch was probably never tested on any targets that use emutls for tls support. I assume there is a way to switch the standard linux build from tls to emutls so this regression can be tested on targets other than darwin. Perhaps with gcc_cv_use_emutls?. Jack
Re: Build failure with "[PATCH] PR 53528 c++/ C++11 Generalized Attribute support"
Hans-Peter Nilsson writes: > This caused a build failure, see PR54860. I am on it. Sorry for the inconvenience. -- Dodji
[v3] libstdc++/54869
HI,
apparently simd_fast_mersenne_twister_engine is designed (so far) for
little endian targets only.
Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ ==
__ORDER_LITTLE_ENDIAN__ checks artificially altered to return false too)
Thanks,
Paolo.
///
2012-10-09 Paolo Carlini
PR libstdc++/54869
* include/ext/random (simd_fast_mersenne_twister_engine): Provide
only for little endian targets.
* include/ext/random.tcc: Likewise.
* config/cpu/i486/opt/ext/opt_random.h: Likewise.
* testsuite/lib/libstdc++.exp (check_v3_target_little_endian): Add.
* testsuite/lib/dg-options.exp (dg-require-little-endian): Add.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
operators/equal.cc: Use the latter.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
operators/serialize.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
operators/inequal.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
cons/copy.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
cons/seed1.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
cons/seed2.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
cons/default.cc: Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/
cons/seed_seq.cc: Likewise.
Index: testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/equal.cc
===
--- testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/equal.cc
(revision 192245)
+++ testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/equal.cc
(working copy)
@@ -1,10 +1,11 @@
// { dg-options "-std=c++0x" }
// { dg-require-cstdint "" }
+// { dg-require-little-endian "" }
//
// 2008-11-24 Edward M. Smith-Rowland <3dw...@verizon.net>
// 2012-08-28 Ulrich Drepper , adapted for SFMT
//
-// Copyright (C) 2008, 2009, 2012 Free Software Foundation, Inc.
+// Copyright (C) 2008-2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
Index:
testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/serialize.cc
===
---
testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/serialize.cc
(revision 192245)
+++
testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/serialize.cc
(working copy)
@@ -1,10 +1,11 @@
// { dg-options "-std=c++0x" }
// { dg-require-cstdint "" }
+// { dg-require-little-endian "" }
//
// 2008-11-24 Edward M. Smith-Rowland <3dw...@verizon.net>
// 2012-08-28 Ulrich Drepper , adapted for SFMT
//
-// Copyright (C) 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
+// Copyright (C) 2008-2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
Index:
testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/inequal.cc
===
--- testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/inequal.cc
(revision 192245)
+++ testsuite/ext/random/simd_fast_mersenne_twister_engine/operators/inequal.cc
(working copy)
@@ -1,10 +1,11 @@
// { dg-options "-std=c++0x" }
// { dg-require-cstdint "" }
+// { dg-require-little-endian "" }
//
// 2010-03-16 Paolo Carlini
// 2012-08-28 Ulrich Drepper , adapted for SFMT
//
-// Copyright (C) 2010, 2012 Free Software Foundation, Inc.
+// Copyright (C) 2010-2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
Index: testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/copy.cc
===
--- testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/copy.cc
(revision 192245)
+++ testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/copy.cc
(working copy)
@@ -1,10 +1,11 @@
// { dg-options "-std=c++0x" }
// { dg-require-cstdint "" }
+// { dg-require-little-endian "" }
//
// 2010-02-16 Paolo Carlini
// 2012-08-28 Ulrich Drepper , adapted for SFMT
//
-// Copyright (C) 2010, 2012 Free Software Foundation, Inc.
+// Copyright (C) 2010-2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
Index: testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed1.cc
=
Re: [v3] libstdc++/54869
Paolo Carlini writes: > apparently simd_fast_mersenne_twister_engine is designed (so far) for > little endian targets only. > > Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ == > __ORDER_LITTLE_ENDIAN__ checks artificially altered to return false too) Isn't this too much? As described in the PR, only ext/random/simd_fast_mersenne_twister_engine/cons/default.cc was failing. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] libstdc++/54869
On 10/09/2012 05:04 PM, Rainer Orth wrote: Paolo Carlini writes: apparently simd_fast_mersenne_twister_engine is designed (so far) for little endian targets only. Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ checks artificially altered to return false too) Isn't this too much? As described in the PR, only ext/random/simd_fast_mersenne_twister_engine/cons/default.cc was failing. Isn't. Uli clearly explained that the engine is designed for little endian. Indeed, if default.cc fails, it means something is very, very, seriously broken. Paolo.
Re: [PATCH] PR c++/53540 - using fails to be equivalent to typedef
Jason Merrill writes:
> Let's move the alias template case from
> primary_template_instantiation_p into alias_template_specialization_p
> and call the latter from the former. And also call it from tsubst.
Like the below?
Note that I have changed the type of the argument of
alias_template_specialization_p to const_tree to comply with the
constness of the argument of primary_template_instantiation_p.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
* cp-tree.h (TYPE_TEMPLATE_INFO): For an alias that is not an
instance of alias template, don't look for its TEMPLATE_INFO in
its declaration.
(alias_template_specialization_p): Take const_tree.
* pt.c (alias_template_specialization_p): Take a const_tree.
Don't call primary_template_instantiation_p.
(primary_template_instantiation_p): Call
alias_template_specialization_p.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-24.C: New test.
---
gcc/cp/cp-tree.h | 6 +++---
gcc/cp/pt.c| 17 +++--
gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C | 24
3 files changed, 34 insertions(+), 13 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 370f072..35819ed 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2646,8 +2646,8 @@ extern void decl_shadowed_for_var_insert (tree, tree);
template info for the alias template, not the one (if any) for the
template of the underlying type. */
#define TYPE_TEMPLATE_INFO(NODE) \
- (TYPE_ALIAS_P (NODE) \
- ? ((TYPE_NAME (NODE) && DECL_LANG_SPECIFIC (TYPE_NAME (NODE))) \
+ ((TYPE_ALIAS_P (NODE) && DECL_LANG_SPECIFIC (TYPE_NAME (NODE))) \
+ ? (DECL_LANG_SPECIFIC (TYPE_NAME (NODE))\
? DECL_TEMPLATE_INFO (TYPE_NAME (NODE)) \
: NULL_TREE) \
: ((TREE_CODE (NODE) == ENUMERAL_TYPE) \
@@ -5437,7 +5437,7 @@ extern bool reregister_specialization (tree,
tree, tree);
extern tree fold_non_dependent_expr(tree);
extern tree fold_non_dependent_expr_sfinae (tree, tsubst_flags_t);
extern bool alias_type_or_template_p(tree);
-extern bool alias_template_specialization_p (tree);
+extern bool alias_template_specialization_p (const_tree);
extern bool explicit_class_specialization_p (tree);
extern int push_tinst_level (tree);
extern void pop_tinst_level (void);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1377b3e..d81626c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2929,10 +2929,7 @@ primary_template_instantiation_p (const_tree t)
else if (CLASS_TYPE_P (t) && !TYPE_DECL_ALIAS_P (TYPE_NAME (t)))
return CLASSTYPE_TEMPLATE_INSTANTIATION (t)
&& PRIMARY_TEMPLATE_P (CLASSTYPE_TI_TEMPLATE (t));
- else if (TYPE_P (t)
- && TYPE_TEMPLATE_INFO (t)
- && PRIMARY_TEMPLATE_P (TYPE_TI_TEMPLATE (t))
- && DECL_TEMPLATE_INSTANTIATION (TYPE_NAME (t)))
+ else if (alias_template_specialization_p (t))
return true;
return false;
}
@@ -5077,11 +5074,14 @@ alias_type_or_template_p (tree t)
/* Return TRUE iff is a specialization of an alias template. */
bool
-alias_template_specialization_p (tree t)
+alias_template_specialization_p (const_tree t)
{
if (t == NULL_TREE)
return false;
- return (primary_template_instantiation_p (t)
+
+ return (TYPE_P (t)
+ && TYPE_TEMPLATE_INFO (t)
+ && PRIMARY_TEMPLATE_P (TYPE_TI_TEMPLATE (t))
&& DECL_ALIAS_TEMPLATE_P (TYPE_TI_TEMPLATE (t)));
}
@@ -10945,10 +10945,7 @@ tsubst (tree t, tree args, tsubst_flags_t complain,
tree in_decl)
{
tree decl = TYPE_NAME (t);
- if (TYPE_DECL_ALIAS_P (decl)
- && DECL_LANG_SPECIFIC (decl)
- && DECL_TEMPLATE_INFO (decl)
- && PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (decl)))
+ if (alias_template_specialization_p (t))
{
/* DECL represents an alias template and we want to
instantiate it. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C
new file mode 100644
index 000..b68fa93
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-24.C
@@ -0,0 +1,24 @@
+// Origin: PR c++/53540
+// { dg-do compile { target c++11 } }
+
+template
+struct context
+{
+ typedef int type;
+};
+
+template
+void function()
+{
+ using ctx1 = context;
+ typename ctx1::type f1;
+
+ typedef context ctx2;
+ typename ctx2::type f2;
+}
+
+int main()
+{
+ function();
+}
+
--
Dodji
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
On 10/09/2012 10:43 AM, Jack Howarth wrote: On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote: On x86_64-apple-darwin10 The following tests: g++.dg/gomp/tls-5.C g++.dg/tls/thread_local-cse.C g++.dg/tls/thread_local-order*.C g++.dg/tls/thread_local*g.C fail with sorry, unimplemented: dynamic initialization of non-function-local thread_local variables not supported on this target These don't work because of the lack of alias support; that's why I put dg-require-alias in the tests. Do I need a different magic incantation? In addition, I see FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test These ought to work. Can you debug the problem? FAIL: g++.dg/tls/thread_local7.C scan-assembler-not \\.data FAIL: g++.dg/tls/static-1.C * I'll take a look at these. Jason
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
On 9 October 2012 14:11, Jack Howarth wrote: > On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote: >> I don't like the sched_yield macro being set there because it's >> detected correctly by configure anyway, but I'm not going to labour >> that point any more. > > Since we are defining _GLIBCXX_USE_NANOSLEEP in os_defines.h and effectively > implementing half of the behavior of --enable-libstdcxx-time=yes, it seemed > odd to not complete the process and define _GLIBCXX_USE_SCHED_YIELD as well. > The usage is not as straight-forward as many other configure options > (especially in light of the absence of rt timer support on darwin). Why does that absence affect the usage of the option? For darwin there is no difference between --enable-libstdcxx-time=yes and --enable-libstdcxx-time=rt, which should make it easier to use, not harder, because there's no need to choose between the two. >> >> OK for trunk, it's not a regression so I'm not sure about the >> branches. If it doesn't cause problems on the trunk we can decide >> whether to apply it to the 4.7 branch later. > > I guess the question is which branches have enough C++11 standard support to > make the change meaningful to the end user. Surely the question is the usual one of whether to make a change to a release branch if it doesn't fix a regression.
Re: [PATCH] PR c++/53540 - using fails to be equivalent to typedef
OK. Jason
[C++ testcase] PR 53763
Hi,
I'm adding the testcase and closing the PR as fixed for 4.8.0.
Thanks,
Paolo.
/
2012-10-09 Paolo Carlini
PR c++/53763
* g++.dg/cpp0x/decltype43.C: New.
Index: g++.dg/cpp0x/decltype43.C
===
--- g++.dg/cpp0x/decltype43.C (revision 0)
+++ g++.dg/cpp0x/decltype43.C (working copy)
@@ -0,0 +1,27 @@
+// PR c++/53763
+// { dg-do compile { target c++11 } }
+
+template
+struct A
+{
+ static int a(TYPE value)
+ {
+return value;
+ }
+};
+
+template
+struct B
+{
+ static int b(ARGS...)
+ {
+return 0;
+ }
+};
+
+int main()
+{
+ int x = B::a(1))>::b(A::a(1));
+ int y = B::b(A::a(2)); // { dg-error "template
argument" }
+ return x + y;
+}
[lra] patch for speeding up elimination pass for PR54146
I committed the following patch to speed up the elimination patch (rev.
192262).
The patch was successfully bootstrapped on x86/x86-64.
2012-10-09 Vladimir Makarov
* lra-eliminations.c (lra_eliminate): Use direct access to insns
through lra_insn_recog_data for process_insn_for_elimination.
Index: lra-eliminations.c
===
--- lra-eliminations.c (revision 192169)
+++ lra-eliminations.c (working copy)
@@ -1291,9 +1291,10 @@ void
lra_eliminate (bool final_p)
{
int i;
- basic_block bb;
- rtx insn, temp, mem_loc, invariant;
+ unsigned int uid;
+ rtx mem_loc, invariant;
bitmap_head insns_with_changed_offsets;
+ bitmap_iterator bi;
struct elim_table *ep;
int regs_num = max_reg_num ();
@@ -1344,12 +1345,8 @@ lra_eliminate (bool final_p)
fprintf (lra_dump_file,
"Updating elimination of equiv for reg %d\n", i);
}
- FOR_EACH_BB (bb)
-FOR_BB_INSNS_SAFE (bb, insn, temp)
- {
- if (bitmap_bit_p (&insns_with_changed_offsets, INSN_UID (insn)))
- process_insn_for_elimination (insn, final_p);
- }
+ EXECUTE_IF_SET_IN_BITMAP (&insns_with_changed_offsets, 0, uid, bi)
+process_insn_for_elimination (lra_insn_recog_data[uid]->insn, final_p);
bitmap_clear (&insns_with_changed_offsets);
lra_eliminate_done:
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
> These don't work because of the lack of alias support; that's why I put
> dg-require-alias in the tests. Do I need a different magic incantation?
I understand nothing about alias, weak, ... stuff, but from pr52945, if you need
weak-alias, then you have also to use
/* { dg-require-weak "" } */
Dominique
Re: [lra] 3rd patch to speed more compilation of PR54146
On 10/08/2012 05:14 PM, Steven Bosscher wrote:
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov wrote:
So I checked it on big file with > hundred functionson Intel machine and got
before a part of the patch implementing the insn stack as sbitmap
real=243.40 user=241.61 system=1.00
after the part of the patch:
real=244.89 user=243.02 system=0.96
Is that more than just noise, you think? A ~1.5s difference on ~240
total isn't very much. I measured the timings on my set of cc1-i
files, and sometimes the without-patch compiler was faster by a tiny
amount, and sometimes it was slower. Even on an average of 10 runs I
really couldn't say that the patch was a win or loss on the whole.
I measured this on a mostly idle machine at home, not gcc17, which
seems to be even more busy than usual lately, thanks to you and me :-)
Sorry, Steven. It was a noise. I ran it again now 3 times and found
that was a noise.
After some thinking, I realized that sbitmap is really the best
representation for this particular case. That is because at the 1st
constraint pass we have all bits are set as we process *all* insns on
the 1st pass. So sbitmap (at least before the extension and if we have
pretty compact UIDs) will be always smaller than bitmap.
I committed the following your patch to the branch (as rev. 192264).
And again, sorry for the false conclusions.
2012-10-09 Steven Bosscher
* lra-int.h (lra_constraint_insn_stack_bitmap,
lra_constraint_insn_stack): Remove.
(lra_pop_insn, lra_insn_stack_length): New prototypes.
* lra.c (lra_constraint_insn_stack_bitmap): Make static sbitmap.
(lra_constraint_insn_stack): Make static.
(lra_push_insn_1): New function.
(lra_push_insn): Rewrite using lra_push_insn_1.
(lra_push_insn_and_update_insn_regno_info): Likewise.
(lra_pop_insn, lra_insn_stack_length): New functions.
* lra_constraints.c (lra_constraints): Use new interface to
insns stack instead of manipulating in-place.
Index: lra-int.h
===
--- lra-int.h (revision 192183)
+++ lra-int.h (working copy)
@@ -249,14 +243,13 @@ extern HARD_REG_SET lra_no_alloc_regs;
extern int lra_insn_recog_data_len;
extern lra_insn_recog_data_t *lra_insn_recog_data;
-extern bitmap_head lra_constraint_insn_stack_bitmap;
-extern VEC (rtx, heap) *lra_constraint_insn_stack;
-
extern int lra_curr_reload_num;
extern void lra_push_insn (rtx);
extern void lra_push_insn_by_uid (unsigned int);
extern void lra_push_insn_and_update_insn_regno_info (rtx);
+extern rtx lra_pop_insn (void);
+extern unsigned int lra_insn_stack_length (void);
extern rtx lra_create_new_reg_with_unique_value (enum machine_mode, rtx,
enum reg_class, const char *);
Index: lra.c
===
--- lra.c (revision 192183)
+++ lra.c (working copy)
@@ -1736,19 +1736,43 @@ lra_get_insn_regs (int uid)
should be processed by the next constraint pass. */
/* Bitmap used to put an insn on the stack only in one exemplar. */
-bitmap_head lra_constraint_insn_stack_bitmap;
+static sbitmap lra_constraint_insn_stack_bitmap;
/* The stack itself. */
VEC (rtx, heap) *lra_constraint_insn_stack;
+/* Put INSN on the stack. If ALWAYS_UPDATE is true, always update the reg
+ info for INSN, otherwise only update it if INSN is not already on the
+ stack. */
+static inline void
+lra_push_insn_1 (rtx insn, bool always_update)
+{
+ unsigned int uid = INSN_UID (insn);
+ if (always_update)
+lra_update_insn_regno_info (insn);
+ if (uid >= SBITMAP_SIZE (lra_constraint_insn_stack_bitmap))
+lra_constraint_insn_stack_bitmap =
+ sbitmap_resize (lra_constraint_insn_stack_bitmap, 3 * uid / 2, 0);
+ if (TEST_BIT (lra_constraint_insn_stack_bitmap, uid))
+return;
+ SET_BIT (lra_constraint_insn_stack_bitmap, uid);
+ if (! always_update)
+lra_update_insn_regno_info (insn);
+ VEC_safe_push (rtx, heap, lra_constraint_insn_stack, insn);
+}
+
/* Put INSN on the stack. */
void
lra_push_insn (rtx insn)
{
- if (! bitmap_set_bit (&lra_constraint_insn_stack_bitmap, INSN_UID (insn)))
-return;
- lra_update_insn_regno_info (insn);
- VEC_safe_push (rtx, heap, lra_constraint_insn_stack, insn);
+ lra_push_insn_1 (insn, false);
+}
+
+/* Put INSN on the stack and update its reg info. */
+void
+lra_push_insn_and_update_insn_regno_info (rtx insn)
+{
+ lra_push_insn_1 (insn, true);
}
/* Put insn with UID on the stack. */
@@ -1758,14 +1782,20 @@ lra_push_insn_by_uid (unsigned int uid)
lra_push_insn (lra_insn_recog_data[uid]->insn);
}
-/* Put INSN on the stack and update its reg info. */
-void
-lra_push_insn_and_update_insn_regno_info (rtx insn)
+/* Take the last-inserted insns off the stack and return it. */
+rtx
+lra_pop_insn (void)
{
- lra_update_insn_regno_info (insn);
- if (! bitmap_set_bit (&lra_constraint_insn_stack_bitmap,
Re: [lra] 3rd patch to speed more compilation of PR54146
On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote: > On 10/08/2012 05:14 PM, Steven Bosscher wrote: >> >> On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov >> wrote: >> >>> So I checked it on big file with > hundred functionson Intel machine and >>> got >>> >>> before a part of the patch implementing the insn stack as sbitmap >>> real=243.40 user=241.61 system=1.00 >>> >>> after the part of the patch: >>> real=244.89 user=243.02 system=0.96 >> >> Is that more than just noise, you think? A ~1.5s difference on ~240 >> total isn't very much. I measured the timings on my set of cc1-i >> files, and sometimes the without-patch compiler was faster by a tiny >> amount, and sometimes it was slower. Even on an average of 10 runs I >> really couldn't say that the patch was a win or loss on the whole. >> >> I measured this on a mostly idle machine at home, not gcc17, which >> seems to be even more busy than usual lately, thanks to you and me :-) >> >> > Sorry, Steven. It was a noise. I ran it again now 3 times and found that > was a noise. > > After some thinking, I realized that sbitmap is really the best > representation for this particular case. That is because at the 1st > constraint pass we have all bits are set as we process *all* insns on the > 1st pass. So sbitmap (at least before the extension and if we have pretty > compact UIDs) will be always smaller than bitmap. > > I committed the following your patch to the branch (as rev. 192264). > > And again, sorry for the false conclusions. Btw, congratulations for all the speedups (even though they probably are noise for "regular" programs?)! I'm looking forward to the merge of LRA for x86 now. Richard. > 2012-10-09 Steven Bosscher > > > * lra-int.h (lra_constraint_insn_stack_bitmap, > lra_constraint_insn_stack): Remove. > (lra_pop_insn, lra_insn_stack_length): New prototypes. > * lra.c (lra_constraint_insn_stack_bitmap): Make static sbitmap. > (lra_constraint_insn_stack): Make static. > (lra_push_insn_1): New function. > (lra_push_insn): Rewrite using lra_push_insn_1. > (lra_push_insn_and_update_insn_regno_info): Likewise. > (lra_pop_insn, lra_insn_stack_length): New functions. > * lra_constraints.c (lra_constraints): Use new interface to > insns stack instead of manipulating in-place. >
Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure
> I'd like to know if my direction is ok. I can look into other issues > releated to this and fix them, but it doesn't make much sense if > separate build is not supported and can be easily broken in the > future. I like your direction here. > This patch is enough for 4.7 to have build working (at least in > Android environment). Confirmed. > Is it ok for release it into trunk and 4.7? Yes, please do so. > I'll take care of remaining trunk issues with other patches if > necessary. Great. I just tested your patch on trunk, and despite what I said yesterday, it seems to work. -benjamin
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
> I don't like the sched_yield macro being set there because it's > detected correctly by configure anyway, but I'm not going to labour > that point any more. Indeed. Then somebody will waste hours in the future wondering why configure says no but their TU says yes. At least a comment in the configure bits admitting defeat, people. -benjamin
[v3] testsuite patchlet
Small fix for 32 bit targets.
-benjamin2012-10-09 Benjamin Kosnik
* testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc:
Fix constant value.
diff --git a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
index 7ccd8da..c86f430 100644
--- a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
+++ b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc
@@ -27,7 +27,7 @@ struct c
c(const c &r) : m(r.m) {}
template
-explicit c(T &o) : m((void*)0xdeadfbeef) { }
+explicit c(T &o) : m((void*)0xdeadbeef) { }
};
int main()
Re: [SH] PR 34777 - Add test case
On Tue, 2012-10-09 at 18:33 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > This adds the reduced test case as mentioned by Kaz in the PR to the
> > test suite.
> > Tested with
> > make -k check-gcc RUNTESTFLAGS="compile.exp=pr34777*
> > --target_board=sh-sim
> > \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
> >
> > OK?
>
> It should be put into gcc.target/sh instead of gcc.c-torture/compile
> and tested with -Os -fschedule-insns -fPIC -mprefergot, shouldn't it?
>
Uhm, yes, I forgot to add the -fschedule-insns and -mprefergot options.
Regarding the -Os option, I think it's better to test this one at
multiple optimization levels, just in case. I've looked through
gcc.c-torture/compile and found some target specific test cases there,
so I thought it would be OK to do the same :)
Some targets also have their own torture subdir. If it's better, I
could also create gcc.target/sh/torture.
Cheers,
Oleg
libbacktrace patch committed: Trace through shared libraries
This patch to libbacktrace adds support for tracing through shared
libraries. The libraries are found by calling dl_iterate_phdr, when it
is available.
This patch has some preliminary support for tracing through libaries
opened via dlopen, but there is no code for actually finding such
libraries. It would require keeping track of the modules that have been
read, and, when some PC is found with no definition, calling
dl_iterate_phdr again to see if any libraries have been dlopen'ed.
I do not know how to support dlclose.
Patch bootstrapped and ran libbacktrace and Go testsuites on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2012-10-09 Ian Lance Taylor
Add support for tracing through shared libraries.
* configure.ac: Check for link.h and dl_iterate_phdr.
* elf.c: #include if system has dl_iterate_phdr. #undef
ELF macros before #defining them.
(dl_phdr_info, dl_iterate_phdr): Define if system does not have
dl_iterate_phdr.
(struct elf_syminfo_data): Add next field.
(elf_initialize_syminfo): Initialize next field.
(elf_add_syminfo_data): New static function.
(elf_add): New static function, broken out of
backtrace_initialize. Call backtrace_dwarf_add instead of
backtrace_dwarf_initialize.
(struct phdr_data): Define.
(phdr_callback): New static function.
(backtrace_initialize): Call elf_add.
* dwarf.c (struct dwarf_data): Add next and base_address fields.
(add_unit_addr): Add base_address parameter. Change all callers.
(add_unit_ranges, build_address_map): Likewise.
(add_line): Add ddata parameter. Change all callers.
(read_line_program, add_function_range): Likewise.
(dwarf_lookup_pc): New static function, broken out of
dwarf_fileline.
(dwarf_fileline): Call dwarf_lookup_pc.
(build_dwarf_data): New static function.
(backtrace_dwarf_add): New function.
(backtrace_dwarf_initialize): Remove.
* internal.h (backtrace_dwarf_initialize): Don't declare.
(backtrace_dwarf_add): Declare.
* configure, config.h.in: Rebuild.
Index: dwarf.c
===
--- dwarf.c (revision 192266)
+++ dwarf.c (working copy)
@@ -333,6 +333,10 @@ struct unit_addrs_vector
struct dwarf_data
{
+ /* The data for the next file we know about. */
+ struct dwarf_data *next;
+ /* The base address for this file. */
+ uintptr_t base_address;
/* A sorted list of address ranges. */
struct unit_addrs *addrs;
/* Number of address ranges in list. */
@@ -831,12 +835,18 @@ function_addrs_search (const void *vkey,
success, 0 on failure. */
static int
-add_unit_addr (struct backtrace_state *state, struct unit_addrs addrs,
+add_unit_addr (struct backtrace_state *state, uintptr_t base_address,
+ struct unit_addrs addrs,
backtrace_error_callback error_callback, void *data,
struct unit_addrs_vector *vec)
{
struct unit_addrs *p;
+ /* Add in the base address of the module here, so that we can look
+ up the PC directly. */
+ addrs.low += base_address;
+ addrs.high += base_address;
+
/* Try to merge with the last entry. */
if (vec->count > 0)
{
@@ -1156,9 +1166,10 @@ lookup_abbrev (struct abbrevs *abbrevs,
1 on success, 0 on failure. */
static int
-add_unit_ranges (struct backtrace_state *state, struct unit *u,
- uint64_t ranges, uint64_t base, int is_bigendian,
- const unsigned char *dwarf_ranges, size_t dwarf_ranges_size,
+add_unit_ranges (struct backtrace_state *state, uintptr_t base_address,
+ struct unit *u, uint64_t ranges, uint64_t base,
+ int is_bigendian, const unsigned char *dwarf_ranges,
+ size_t dwarf_ranges_size,
backtrace_error_callback error_callback, void *data,
struct unit_addrs_vector *addrs)
{
@@ -1202,7 +1213,8 @@ add_unit_ranges (struct backtrace_state
a.low = low + base;
a.high = high + base;
a.u = u;
- if (!add_unit_addr (state, a, error_callback, data, addrs))
+ if (!add_unit_addr (state, base_address, a, error_callback, data,
+ addrs))
return 0;
}
}
@@ -1218,7 +1230,7 @@ add_unit_ranges (struct backtrace_state
on success, 0 on failure. */
static int
-build_address_map (struct backtrace_state *state,
+build_address_map (struct backtrace_state *state, uintptr_t base_address,
const unsigned char *dwarf_info, size_t dwarf_info_size,
const unsigned char *dwarf_abbrev, size_t dwarf_abbrev_size,
const unsigned char *dwarf_ranges, size_t dwarf_ranges_size,
@@ -1417,9 +1429,10 @@ build_address_map (struct backtrace_stat
if (have_ranges)
{
- if (!add_unit_ranges (state, u, ranges, lowpc, is_bigendian,
-dwarf_ranges, dwarf_ranges_size,
-error_callback, data, addrs))
+ if (!add_unit_ranges (state, base_address, u, ranges, lowpc,
+i
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
On Tue, Oct 09, 2012 at 10:49:28AM -0700, Benjamin De Kosnik wrote: > > > I don't like the sched_yield macro being set there because it's > > detected correctly by configure anyway, but I'm not going to labour > > that point any more. > > Indeed. Then somebody will waste hours in the future wondering why > configure says no but their TU says yes. Since darwin has always supported nanosleep() and sched_yield() and the atypical behavior of the -enable-libstdcxx-time configure option obviously confuses some end-users, it seems rational to just default to --enable-libstdcxx-time=yes on for darwin. Is there another way to achieve this short of defining both _GLIBCXX_USE_NANOSLEEP and _GLIBCXX_USE_SCHED_YIELD in config/os/bsd/darwin/os_defines.h? If so, I'll revise the patch to use that approach. Jack > > At least a comment in the configure bits admitting defeat, people. > > -benjamin
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 09, 2012 at 11:20:48AM -0700, Ian Lance Taylor wrote:
> This patch to libbacktrace adds support for tracing through shared
> libraries. The libraries are found by calling dl_iterate_phdr, when it
> is available.
This functionality is definitely useful for meta-plugins like MELT
(since melt.so is dlopen-ing things)
>
> This patch has some preliminary support for tracing through libaries
> opened via dlopen, but there is no code for actually finding such
> libraries.
Perhaps you might use dladdr, on the few systems (notably GNU/Libc on Linux)
which have it?
>From man dlsym output:
int dladdr(void *addr, Dl_info *info);
The function dladdr() takes a function pointer and tries to resolve
name and file where it is located. Information is stored in the
Dl_info structure:
typedef struct {
const char *dli_fname; /* Pathname of shared object that
contains address */
void *dli_fbase; /* Address at which shared object
is loaded */
const char *dli_sname; /* Name of nearest symbol with address
lower than addr */
void *dli_saddr; /* Exact address of symbol named
in dli_sname */
} Dl_info;
If no symbol matching addr could be found, then dli_sname and dli_saddr
are set to NULL.
dladdr() returns 0 on error, and nonzero on success.
Or maybe I misunderstood libbacktrace and my comment is irrelevant. If it is
the case, sorry for the noise.
You could provide an extra API to register dlopen & dlclose to libbacktrace, if
that helps you
(of course, I would prefer avoiding that)
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
PR 54861 - libstdc++ header file typo
There is a typo in the header files for libstdc++ where the
atomic_signal_fence() method is actually calling __atomic_thread_fence()
instead of __atomic_signal_fence(). This results in extra barriers in
the executable that don't need to be there.
fixed as trivial and checked into mainline. Is it OK to check this into
the 4.7 branch once I've verified it there as well? ie, it's not frozen
or anything right now is it?
Thanks
Andrew
2012-10-09 Andrew MacLeod
PR libstdc++/54861
* include/bits/atomic_base.h (atomic_signal_fence): Call
__atomic_signal_fence instead of __atomic_thread_fence.
Index: include/bits/atomic_base.h
===
*** include/bits/atomic_base.h (revision 192254)
--- include/bits/atomic_base.h (working copy)
*** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 74,80
inline void
atomic_signal_fence(memory_order __m) noexcept
! { __atomic_thread_fence(__m); }
/// kill_dependency
template
--- 74,80
inline void
atomic_signal_fence(memory_order __m) noexcept
! { __atomic_signal_fence(__m); }
/// kill_dependency
template
[SH] PR 52480 - fix movua.l for big endian
Hello,
This is the same patch I posted in the PR. It seems to fix the issue.
Tested on rev 192200 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK?
Cheers,
Oleg
gcc/ChangeLog:
PR target/52480
* config/sh/sh.md (extv, extzv): Check that operands[3] is zero,
regardless of the endianness.
testsuite/ChangeLog:
PR target/52480
* gcc.target/sh/sh4a-bitmovua.c: Compact skip-if list. Add
runtime tests.
Index: gcc/testsuite/gcc.target/sh/sh4a-bitmovua.c
===
--- gcc/testsuite/gcc.target/sh/sh4a-bitmovua.c (revision 192200)
+++ gcc/testsuite/gcc.target/sh/sh4a-bitmovua.c (working copy)
@@ -1,7 +1,7 @@
/* Verify that we generate movua to load unaligned 32-bit values on SH4A. */
-/* { dg-do compile { target "sh*-*-*" } } */
-/* { dg-options "-O" } */
-/* { dg-skip-if "" { "sh*-*-*" } { "*" } { "-m4a" "-m4a-single" "-m4a-single-only" "-m4a-nofpu" } } */
+/* { dg-do run { target "sh*-*-*" } } */
+/* { dg-options "-O1 -save-temps -fno-inline" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "*" } { "-m4a*" } } */
/* { dg-final { scan-assembler-times "movua.l" 6 } } */
/* Aligned. */
@@ -64,4 +64,28 @@
return y4.d;
}
+#include
+int
+main (void)
+{
+ x1.d = 0x12345678;
+ assert (f1 () == 0x12345678);
+
+ x2.d = 0x12345678;
+ assert (f2 () == 0x12345678);
+
+ x3.d = 0x12345678;
+ assert (f3 () == 0x12345678);
+
+ y_1.d = 0x12345678;
+ assert (g1 () == 0x12345678);
+
+ y2.d = 0x12345678;
+ assert (g2 () == 0x12345678);
+
+ y3.d = 0x12345678;
+ assert (g3 () == 0x12345678);
+
+ return 0;
+}
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 192200)
+++ gcc/config/sh/sh.md (working copy)
@@ -12706,7 +12706,7 @@
}
if (TARGET_SH4A_ARCH
&& INTVAL (operands[2]) == 32
- && INTVAL (operands[3]) == -24 * (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
+ && INTVAL (operands[3]) == 0
&& MEM_P (operands[1]) && MEM_ALIGN (operands[1]) < 32)
{
rtx src = adjust_address (operands[1], BLKmode, 0);
@@ -12738,7 +12738,7 @@
}
if (TARGET_SH4A_ARCH
&& INTVAL (operands[2]) == 32
- && INTVAL (operands[3]) == -24 * (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
+ && INTVAL (operands[3]) == 0
&& MEM_P (operands[1]) && MEM_ALIGN (operands[1]) < 32)
{
rtx src = adjust_address (operands[1], BLKmode, 0);
Re: [lra] 3rd patch to speed more compilation of PR54146
On 10/09/2012 01:06 PM, Richard Guenther wrote: On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote: On 10/08/2012 05:14 PM, Steven Bosscher wrote: On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov wrote: So I checked it on big file with > hundred functionson Intel machine and got before a part of the patch implementing the insn stack as sbitmap real=243.40 user=241.61 system=1.00 after the part of the patch: real=244.89 user=243.02 system=0.96 Is that more than just noise, you think? A ~1.5s difference on ~240 total isn't very much. I measured the timings on my set of cc1-i files, and sometimes the without-patch compiler was faster by a tiny amount, and sometimes it was slower. Even on an average of 10 runs I really couldn't say that the patch was a win or loss on the whole. I measured this on a mostly idle machine at home, not gcc17, which seems to be even more busy than usual lately, thanks to you and me :-) Sorry, Steven. It was a noise. I ran it again now 3 times and found that was a noise. After some thinking, I realized that sbitmap is really the best representation for this particular case. That is because at the 1st constraint pass we have all bits are set as we process *all* insns on the 1st pass. So sbitmap (at least before the extension and if we have pretty compact UIDs) will be always smaller than bitmap. I committed the following your patch to the branch (as rev. 192264). And again, sorry for the false conclusions. Btw, congratulations for all the speedups (even though they probably are noise for "regular" programs?)! I'm looking forward to the merge of LRA for x86 now. Thanks, Richard. Many thanks to Steven too. I think I'll do merging in a week as I need to address proposals from the reviews (some of them needs good testing).
Re: [PATCH] Assigning correct source location for deallocator
On 10/07/2012 08:38 PM, Dehao Chen wrote: +*stmt_p = build2_loc (input_location, I think input_location in cp_genericize_r will always be the closing brace of the function, which might be right for a variable in the outermost block of the function, but not for variables in inner scopes. Jason
Re: [PATCH, libstdc++] Add proper OpenBSD support
> Date: Mon, 8 Oct 2012 20:52:22 +0100 > From: Jonathan Wakely > > On 8 October 2012 20:45, Mark Kettenis wrote: > > Jonathan, > > > > Any further thoughts about this? I've attached a diff that combines > > my origional diff with the change to use the "newlib" locale model on > > OpenBSD since they probably should be committed together. > > Hi, > > Sorry for the delay, I realised over the weekend this never went in. > > I'm happy to apply the combined diff if you think using newlib is the > right option for OpenBSD. I think it is. The newlib ctype classification is identical to the traditional BSD scheme that OpenBSD uses. Thanks, Mark
Re: RFA: darwin PATCH to fix build, internal visibility
On Oct 9, 2012, at 6:48 AM, Dominique Dhumieres wrote:
>>> These tests are still failing on darwin. I think tha
>>> target { ! *-*-solaris2* } { ! *-*-darwin* }
>>> sould be replaced with
>>> target { ! { *-*-solaris2* *-*-darwin* } }
>>
>> Could someone with a darwin box handy make the appropriate change?
>
> I have never really understood the logic of the "target" syntax,
> so IMO the problem with the proposed change is not with darwin,
> but with other platforms I don't have access to.
Ok. I think it is pretty safe, if darwin works.
Re: [PATCH] Assigning correct source location for deallocator
Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location.
New patch attached, testing is on-going.
Thanks,
Dehao
On Tue, Oct 9, 2012 at 12:35 PM, Jason Merrill wrote:
> On 10/07/2012 08:38 PM, Dehao Chen wrote:
>>
>> +*stmt_p = build2_loc (input_location,
>
>
> I think input_location in cp_genericize_r will always be the closing brace
> of the function, which might be right for a variable in the outermost block
> of the function, but not for variables in inner scopes.
>
> Jason
>
Index: gcc/testsuite/g++.dg/debug/dwarf2/deallocator.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/deallocator.C (revision 192168)
+++ gcc/testsuite/g++.dg/debug/dwarf2/deallocator.C (working copy)
@@ -18,6 +18,7 @@ int bar();
void foo(int i)
{
+ t test_outside;
for (int j = 0; j < 10; j++)
{
t test;
@@ -28,6 +29,18 @@ void foo(int i)
return;
}
}
+ if (i)
+{
+ t test;
+ if (i == 10)
+ {
+ test.bar();
+ }
+}
+ test_outside.foo();
return;
}
-// { dg-final { scan-assembler "deallocator.C:28" } }
+// { dg-final { scan-assembler "deallocator.C:29" } }
+// { dg-final { scan-assembler "deallocator.C:31" } }
+// { dg-final { scan-assembler "deallocator.C:38" } }
+// { dg-final { scan-assembler "deallocator.C:41" } }
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 192168)
+++ gcc/gimplify.c (working copy)
@@ -7475,6 +7475,10 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, gi
TREE_CODE (*expr_p) == TRY_FINALLY_EXPR
? GIMPLE_TRY_FINALLY
: GIMPLE_TRY_CATCH);
+ if (LOCATION_LOCUS (saved_location) != UNKNOWN_LOCATION)
+ gimple_set_location (try_, saved_location);
+ else
+ gimple_set_location (try_, EXPR_LOCATION (save_expr));
if (TREE_CODE (*expr_p) == TRY_CATCH_EXPR)
gimple_try_set_catch_is_cleanup (try_,
TRY_CATCH_IS_CLEANUP (*expr_p));
Index: gcc/tree-eh.c
===
--- gcc/tree-eh.c (revision 192168)
+++ gcc/tree-eh.c (working copy)
@@ -1100,6 +1100,7 @@ lower_try_finally_onedest (struct leh_state *state
struct goto_queue_node *q, *qe;
gimple x;
gimple_seq finally;
+ gimple_stmt_iterator gsi;
tree finally_label;
location_t loc = gimple_location (tf->try_finally_expr);
@@ -1120,6 +1121,17 @@ lower_try_finally_onedest (struct leh_state *state
lower_eh_constructs_1 (state, &finally);
+ for (gsi = gsi_start (finally); !gsi_end_p (gsi); gsi_next (&gsi))
+{
+ gimple stmt = gsi_stmt (gsi);
+ if (LOCATION_LOCUS (gimple_location (stmt)) == UNKNOWN_LOCATION)
+ {
+ tree block = gimple_block (stmt);
+ gimple_set_location (stmt, gimple_location (tf->try_finally_expr));
+ gimple_set_block (stmt, block);
+ }
+}
+
if (tf->may_throw)
{
/* Only reachable via the exception edge. Add the given label to
Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 192168)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -948,11 +948,12 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees,
to lower this construct before scanning it, so we need to lower these
before doing anything else. */
else if (TREE_CODE (stmt) == CLEANUP_STMT)
-*stmt_p = build2 (CLEANUP_EH_ONLY (stmt) ? TRY_CATCH_EXPR
-: TRY_FINALLY_EXPR,
- void_type_node,
- CLEANUP_BODY (stmt),
- CLEANUP_EXPR (stmt));
+*stmt_p = build2_loc (EXPR_LOCATION (stmt),
+ CLEANUP_EH_ONLY (stmt) ? TRY_CATCH_EXPR
+: TRY_FINALLY_EXPR,
+ void_type_node,
+ CLEANUP_BODY (stmt),
+ CLEANUP_EXPR (stmt));
else if (TREE_CODE (stmt) == IF_STMT)
{
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
> >> FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test > >> FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test > > These ought to work. Can you debug the problem? Backtrace for thread_local4.C Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x1503 of process 36991] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00015424 in __mini_vector::_Alloc_block*, __gnu_cxx::bitmap_allocator::_Alloc_block*> >::insert (this=, __pos=, __x=) at /opt/gcc/p_build/x86_64-apple-darwin10.8.0/libstdc++-v3/include/ext/bitmap_allocator.h:158 #2 0x0001 in ?? () #3 0x000100381000 in ?? () #4 0x00010cea in f () at /opt/gcc/work/gcc/testsuite/g++.dg/tls/thread_local4.C:23 #5 0x000100380ed0 in ?? () #6 0x7fff8297e39c in _pthread_exit () from /usr/lib/libSystem.B.dylib Backtrace stopped: previous frame inner to this frame (corrupt stack?) valgrind gives --36994:0:schedule VG_(sema_down): read returned -4 ==36994== Thread 2: ==36994== Invalid read of size 4 ==36994==at 0x100021400: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) ==36994==by 0xFF: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10084DFFF: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== ==36994== Invalid read of size 8 ==36994==at 0x10002141D: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== Address 0x1003cd2e8 is 24 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) ==36994==by 0xFF: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10084DFFF: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== ==36994== Invalid read of size 8 ==36994==at 0x100021421: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== Address 0x1003cd2f0 is 32 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) ==36994==by 0xFF: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10084DFFF: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== ==36994== Invalid read of size 8 ==36994==at 0x100021429: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== Address 0x1003cd2d8 is 8 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) ==36994==by 0xFF: ??? ==36994==by 0x10084DD9F: ??? ==36994==by 0x10084DFFF: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== --36994:0:schedule VG_(sema_down): read returned -4 ==36994== Invalid read of size 4 ==36994==at 0x100021400: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x1008CED9F: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== Address 0x1003cd800 is 16 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) ==36994==by 0xFF: ??? ==36994==by 0x1008CED9F: ??? ==36994==by 0x1008CEFFF: ??? ==36994==by 0x10018C6E7: _pthread_tsd_cleanup (in /usr/lib/libSystem.B.dylib) ==36994== ==36994== Invalid read of size 8 ==36994==at 0x10002141D: (anonymous namespace)::list::run() (in /opt/gcc/gcc4.8p-192219/lib/libstdc++.6.dylib) ==36994==by 0xFF: ??? ==36994==by 0x100: ??? ==36994==by 0x1008CE
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch wrote: > > You could provide an extra API to register dlopen & dlclose to libbacktrace, > if that helps you > (of course, I would prefer avoiding that) I would prefer avoiding that as well. Calling dl_iterate_phdr can tell libbacktrace reliably the set of shared libraries that are currently loaded. The trick is knowing when to call it. It may simply be OK to call it every time we look up a PC value, in which case we can look at the dlpi_adds and dlpi_subs field. I'm not sure. Ian
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 09, 2012 at 01:43:06PM -0700, Ian Lance Taylor wrote: > On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch > wrote: > > > > You could provide an extra API to register dlopen & dlclose to > > libbacktrace, if that helps you > > (of course, I would prefer avoiding that) > > I would prefer avoiding that as well. > > Calling dl_iterate_phdr can tell libbacktrace reliably the set of > shared libraries that are currently loaded. The trick is knowing when > to call it. It may simply be OK to call it every time we look up a PC > value, in which case we can look at the dlpi_adds and dlpi_subs field. > I'm not sure. See unwind-dw2-fde-dip.c how it uses it. I think for all PC queries from one backtrace you should get away with using a cache of last looked up library even without calling dl_iterate_phdr. PCs in the backtrace can't go away from under you in a properly written application (but only those, not others). In between different backtrace calls you need to call dl_iterate_phdr (primarily to lock the ld.so lock and prevent dlopen/dlclose from other threads), but can use a cache there and use dlpi_adds/dlpi_subs to find out when to invalidate the cache. Jakub
Re: [PATCH, libstdc++] Add proper OpenBSD support
On 9 October 2012 20:48, Mark Kettenis wrote: > > I think it is. The newlib ctype classification is identical to the > traditional BSD scheme that OpenBSD uses. OK, I'll commit your patch tomorrow, thanks.
Re: [PATCH] Assigning correct source location for deallocator
The patch bootstrapped and passed gcc regression tests. Thanks, Dehao On Tue, Oct 9, 2012 at 1:16 PM, Dehao Chen wrote: > Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location. > > New patch attached, testing is on-going. > > Thanks, > Dehao > > On Tue, Oct 9, 2012 at 12:35 PM, Jason Merrill wrote: >> On 10/07/2012 08:38 PM, Dehao Chen wrote: >>> >>> +*stmt_p = build2_loc (input_location, >> >> >> I think input_location in cp_genericize_r will always be the closing brace >> of the function, which might be right for a variable in the outermost block >> of the function, but not for variables in inner scopes. >> >> Jason >>
[PATCH 0/3] Fix fallouts from c++11 attributes work
Hello,
The three patches following this messages fix fallouts from my c++11
attributes patch that I committed earlier.
Here is their summary:
Disambiguate nested objc-message-expressions and c++11 attributes
Update g++.dg/cpp0x/gen-attrs-{8,36,37}.C as c++11 attributes to
types are ignored
PR middle-end/54860 - Make sure attributes hash table is created
gcc/attribs.c | 6 +++---
gcc/cp/parser.c | 15 ++-
gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C | 10 ++
gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C | 4 +++-
gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C | 2 +-
5 files changed, 27 insertions(+), 10 deletions(-)
--
Dodji
Re: Convert more non-GTY htab_t to hash_table.
On 10/5/12, Diego Novillo wrote: > On Oct 3, 2012 Lawrence Crowl wrote: > > Change more non-GTY hash tables to use the new type-safe > > template hash table. Constify member function parameters that > > can be const. Correct a couple of expressions in formerly > > uninstantiated templates. > > > > The new code is 0.362% faster in bootstrap, with a 99.5% > > confidence of being faster. > > > > Tested on x86-64. > > > > Okay for trunk? > > Given that the changes to the front ends are mechanical and a > side-effect of the main hash table changes, I think they should > be OK without further review (provided tests pass of course). > > The changes look fine to me. To be extra safe, let's wait a couple > more days to give the FE maintainers a chance to look at the patch. Committed. -- Lawrence Crowl
[PATCH 1/3] Disambiguate nested objc-message-expressions and c++11 attributes
Hello,
A couple of obj-c++ tests were failing[1] because the tokens '[[' can
either be the beginning of a c++11 attribute (that is itself at the
beginning of a statement), or the beginning of a nested
objc-message-expression. This patch resolves the ambiguity by
tentatively parsing the c++11 attribute and if it fails, then consider
the objc-message-expression.
I missed this initially because it didn't occur to me that
--enable-languages=all,ada does not include obj-c++. Shame on me. I
have now updated my compile farm scripts to use
--enable-language=all,ada,obj-c++,go and I
[1]:
FAIL: obj-c++.dg/syntax-error-6.mm -fgnu-runtime (test for errors, line 11)
FAIL: obj-c++.dg/syntax-error-6.mm -fgnu-runtime (test for excess errors)
FAIL: obj-c++.dg/template-8.mm -fgnu-runtime (test for excess errors)
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* parser (cp_parser_statement): Parse c++11 attributes tentatively.
(cp_parser_std_attribute_spec_seq): Do not warn too early about
using c++11 attributes in non c++11 mode.
---
gcc/cp/parser.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 52a152d..0f950db 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8716,7 +8716,17 @@ cp_parser_statement (cp_parser* parser, tree
in_statement_expr,
cp_lexer_save_tokens (parser->lexer);
attrs_location = cp_lexer_peek_token (parser->lexer)->location;
+ if (c_dialect_objc ())
+/* In obj-c++, seing '[[' might be the either the beginning of
+ c++11 attributes, or a nested objc-message-expression. So
+ let's parse the c++11 attributes tentatively. */
+cp_parser_parse_tentatively (parser);
std_attrs = cp_parser_std_attribute_spec_seq (parser);
+ if (c_dialect_objc ())
+{
+ if (!cp_parser_parse_definitely (parser))
+ std_attrs = NULL_TREE;
+}
/* Peek at the next token. */
token = cp_lexer_peek_token (parser->lexer);
@@ -20701,7 +20711,6 @@ cp_parser_std_attribute_spec (cp_parser *parser)
&& cp_lexer_peek_nth_token (parser->lexer, 2)->type == CPP_OPEN_SQUARE)
{
cp_lexer_consume_token (parser->lexer);
- maybe_warn_cpp0x (CPP0X_ATTRIBUTES);
cp_lexer_consume_token (parser->lexer);
attributes = cp_parser_std_attribute_list (parser);
@@ -20709,6 +20718,10 @@ cp_parser_std_attribute_spec (cp_parser *parser)
if (!cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE)
|| !cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE))
cp_parser_skip_to_end_of_statement (parser);
+ else
+ /* Warn about parsing c++11 attribute in non-c++1 mode, only
+ when we are sure that we have actually parsed them. */
+ maybe_warn_cpp0x (CPP0X_ATTRIBUTES);
}
else
{
--
Dodji
[PATCH 2/3] Update g++.dg/cpp0x/gen-attrs-{8,36,37}.C as c++11 attributes to types are ignored
Hello,
The current implementation of C++11 attributes forbids them from being
applied to a type unless the type is being declared. I forgot to
adjust g++.dg/cpp0x/gen-attrs-{8,36,37}.C that was being run only on
ia32.
Fixed thus, tested on i386-unknown-linux-gnu and
x86_64-unknown-linux-gnu against trunk.
gcc/testsuite/
* g++.dg/cpp0x/gen-attrs-8.C: Update the test to reflect the fact
that c++11 attributes to types are ignored for now.
* g++.dg/cpp0x/gen-attrs-36.C: Likewise.
* g++.dg/cpp0x/gen-attrs-37.C: Likewise
---
gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C | 10 ++
gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C | 4 +++-
gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C
index 2665188..0a28354 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C
@@ -2,20 +2,22 @@
// { dg-options "-std=c++11 -pedantic" }
// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
+// c++11 attributes that apply to types are ignored for now
+
class T;
class L { };
class P : public L
{
- typedef void (T::* [[gnu::__stdcall__]] F2) (L*); // { dg-warning "only
applies to function types" }
- typedef void (T::*F) (L*) [[gnu::__stdcall__]];
+ typedef void (T::* [[gnu::__stdcall__]] F2) (L*); // { dg-warning "ignored" }
+ typedef void (T::*F) (L*) [[gnu::__stdcall__]]; // { dg-warning "ignored" }
void f(bool aAdd);
};
class T
{
public:
- virtual void A(L *listener) [[gnu::__stdcall__]] = 0;
- virtual void R(L *listener) [[gnu::__stdcall__]] = 0;
+ virtual void A(L *listener) [[gnu::__stdcall__]] = 0; // { dg-warning
"ignored" }
+ virtual void R(L *listener) [[gnu::__stdcall__]] = 0; // { dg-warning
"ignored" }
};
void P::f(bool aAdd)
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C
index 15d69e8..9b76942 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-37.C
@@ -2,12 +2,14 @@
// { dg-options "-std=c++11 -pedantic" }
// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
+// c++11 attributes that apply to types are ignored for now
+
struct S {
int x;
S(const S &s) {}
};
-S getS() [[gnu::__stdcall__]];
+S getS() [[gnu::__stdcall__]]; // { dg-warning "ignored" }
void test()
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C
index a842b53..aa1491a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C
@@ -2,5 +2,5 @@
// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
extern int * ([[gnu::stdcall]] *fooPtr)( void); // { dg-error "expected" }
-int * [[gnu::stdcall]] myFn01( void) { return 0; }// { dg-warning "attribute
only applies to function types" }
+int * [[gnu::stdcall]] myFn01( void) { return 0; }// { dg-warning "ignored" }
--
1.7.11.4
--
Dodji
[patch][IRA] Apply LRA lessons-learned to IRA
Hello, For LRA, compressing the live range chains proved to be quite helpful. The same can be done for IRA, as in the attached patch. For the test case of PR54146 the effect is time spent in IRA cut in half: without patch: integrated RA : 206.35 (28%) with patch: integrated RA : 106.96 (16%) The peak memory usage also drops a few 100MB. There is a slight measurable effect on my collection of cc1-i files, mostly due to small speed-ups on the big generated insn-* files. I'm going to bootstrap&test this on x86_64-unknown-linux-gnu and powerpc64-unknown-linux-gnu. OK if that passes? Ciao! Steven ira-speedup-1.diff Description: Binary data
[PATCH 3/3] PR middle-end/54860 - Make sure attributes hash table is created
Hello, On targets cris-elf, alpha and sparc (for instance) it can happen that the attribute_tables variable is empty for fortran. So register_scoped_attributes (called by init_attributes) won't call register_scoped_attributes, so the hash table member of scoped_attributes is not created. Later when we try to e.g, lookup an attribute by calling lookup_scoped_attribute_spec, that NULL member hash table members comes to byte us and htab_find_with_hash crashes. This patch fixes this by ensuring in register_scoped_attributes that the hash table is created. Tested on cris-elf against trunk and some commenters on the bug bootstrapped it on alpha and sparc. gcc/ * attribs.c (register_scoped_attributes): Ensure the attribute hash table is created. --- gcc/attribs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/attribs.c b/gcc/attribs.c index b330f27..d167c1f 100644 --- a/gcc/attribs.c +++ b/gcc/attribs.c @@ -146,7 +146,8 @@ register_scoped_attributes (const struct attribute_spec * attributes, memset (&sa, 0, sizeof (sa)); sa.ns = ns; sa.attributes = VEC_alloc (attribute_spec, heap, 64); - result = VEC_safe_push (scoped_attributes, heap, attributes_table, sa); + result = VEC_safe_push (scoped_attributes, heap, attributes_table, sa); + result->attribute_hash = htab_create (200, hash_attr, eq_attr, NULL); } /* Really add the attributes to their namespace now. */ @@ -284,8 +285,7 @@ register_scoped_attribute (const struct attribute_spec *attr, gcc_assert (attr != NULL && name_space != NULL); - if (name_space->attribute_hash == NULL) - name_space->attribute_hash = htab_create (200, hash_attr, eq_attr, NULL); + gcc_assert (name_space->attribute_hash != NULL); str.str = attr->name; str.length = strlen (str.str); -- Dodji
[v3] "SFINAE-friendly" std::common_type and more
Hi,
more great stuff from Daniel. Tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
//
2012-10-09 Daniel Krugler
* include/std/type_traits (common_time): Provide "SFINAE-friendly"
implementation.
(__success_type, __failure_type): Fix.
* include/std/chrono (common_type): Likewise for the chrono::time_point
specialization.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: New.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Likewise.
* testsuite/20_util/duration/requirements/sfinae_friendly_1.cc:
Likewise.
* testsuite/20_util/common_type/requirements/typedefs-1.cc: Adjust wrt
LWG 2141.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc: Adjust
dg-error line numbers.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg3.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Likewise.
* testsuite/20_util/result_of/sfinae_friendly_1.cc: Trivial stylistic
tweaks.
* testsuite/20_util/result_of/sfinae_friendly_2.cc: Likewise.
Index: include/std/chrono
===
--- include/std/chrono (revision 192262)
+++ include/std/chrono (working copy)
@@ -69,33 +69,53 @@
}
_GLIBCXX_BEGIN_NAMESPACE_VERSION
- // 20.11.4.3 specialization of common_type (for duration)
- template
-struct common_type,
- chrono::duration<_Rep2, _Period2>>
+
+ // 20.11.4.3 specialization of common_type (for duration, sfinae-friendly)
+
+ template
+struct __duration_common_type_wrapper
{
private:
- typedef __static_gcd<_Period1::num, _Period2::num> __gcd_num;
- typedef __static_gcd<_Period1::den, _Period2::den> __gcd_den;
- typedef typename common_type<_Rep1, _Rep2>::type __cr;
+ typedef __static_gcd<_Period1::num, _Period2::num> __gcd_num;
+ typedef __static_gcd<_Period1::den, _Period2::den> __gcd_den;
+ typedef typename _CT::type __cr;
typedef ratio<__gcd_num::value,
- (_Period1::den / __gcd_den::value) * _Period2::den> __r;
-
+(_Period1::den / __gcd_den::value) * _Period2::den> __r;
public:
- typedef chrono::duration<__cr, __r> type;
+ typedef __success_type> type;
};
- // 20.11.4.3 specialization of common_type (for time_point)
- template
-struct common_type,
- chrono::time_point<_Clock, _Dur2>>
+ template
+struct __duration_common_type_wrapper<__failure_type, _Period1, _Period2>
+{ typedef __failure_type type; };
+
+ template
+struct common_type,
+ chrono::duration<_Rep2, _Period2>>
+: public __duration_common_type_wrapper>::type, _Period1, _Period2>::type
+{ };
+
+ // 20.11.4.3 specialization of common_type (for time_point, sfinae-friendly)
+
+ template
+struct __timepoint_common_type_wrapper
{
-private:
- typedef typename common_type<_Dur1, _Dur2>::type __ct;
+ typedef __success_type>
+type;
+};
-public:
- typedef chrono::time_point<_Clock, __ct> type;
-};
+ template
+struct __timepoint_common_type_wrapper<__failure_type, _Clock>
+{ typedef __failure_type type; };
+
+ template
+struct common_type,
+ chrono::time_point<_Clock, _Duration2>>
+: public __timepoint_common_type_wrapper>::type, _Clock>::type
+{ };
+
_GLIBCXX_END_NAMESPACE_VERSION
namespace chrono
Index: include/std/type_traits
===
--- include/std/type_traits (revision 192262)
+++ include/std/type_traits (working copy)
@@ -133,6 +133,18 @@
typedef struct { char __arr[2]; } __two;
};
+ // For several sfinae-friendly trait implementations we transport both the
+ // result information (as the member type) and the failure information (no
+ // member type). This is very similar to std::enable_if, but we cannot use
+ // them, because we need to derive from them as an implementation detail.
+
+ template
+struct __success_type
+{ typedef _Tp type; };
+
+ struct __failure_type
+ { };
+
// primary type categories.
template
@@ -1771,25 +1783,70 @@
struct conditional
{ typedef _Iffalse type; };
-
/// common_type
template
struct common_type;
+ // sfinae-friendly common_type implementation:
+
+ struct __do_common_type_impl
+ {
+template
+ static __success_type() : std::declval<_Up>())
+ >::type> _S_test(int);
+
+template
+ static __failure
Re: [SH] PR 34777 - Add test case
Oleg Endo wrote: > Uhm, yes, I forgot to add the -fschedule-insns and -mprefergot options. > Regarding the -Os option, I think it's better to test this one at > multiple optimization levels, just in case. I've looked through > gcc.c-torture/compile and found some target specific test cases there, > so I thought it would be OK to do the same :) > Some targets also have their own torture subdir. If it's better, I > could also create gcc.target/sh/torture. Maybe. For this specific test, I thought that "-Os -fschedule-insns -fPIC -mprefergot" would be enough because empirically these options will give high R0 register pressure which had caused that PR. Regards, kaz
Re: [SH] PR 52480 - fix movua.l for big endian
Oleg Endo wrote:
> This is the same patch I posted in the PR. It seems to fix the issue.
> Tested on rev 192200 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new failures.
> OK?
OK.
Regards,
kaz
[patch] Fix PR bootstrap/54820
Hi,
native compilers are now built with -static-libstdc++ -static-libgcc (if
bootstrapped) because the switches are added to LDFLAGS during stage 2 and 3.
Nothing is done for stage 1 or cross-compilers, except for Ada where we force
the switches, but this is far from ideal as reported under the PR.
The attached patch enables -static-libstdc++ -static-libgcc for stage 1 and
cross-compilers if g++ is detected and the switches work, using the same idea
as for later stages (i.e. setting --with-stage1-ldflags if not already set).
It turns out that --with-stage1-ldflags is currently broken: LDFLAGS is
correctly passed and set in gcc/ at configure time during stage 1, but a
'make' invocation from the toplevel passes an empty LDFLAGS to gcc/.
Tested on x86_64-suse-linux, OK for the mainline?
2012-10-09 Eric Botcazou
PR bootstrap/54820
* Makefile.tpl (STAGE1_FLAGS_TO_PASS): New variable.
(host_modules): Add STAGE1_FLAGS_TO_PASS to args.
* Makefile.in: Regenerate.
* configure.ac (have_static_libs): New variable and associated check.
(stage1-ldflags): Move to after stage1_libs and set to -static-libstdc++
-static-libgcc if stage1_libs is empty and have_static_libs is yes.
* configure: Regenerate.
gcc/ada
* gcc-interface/Make-lang.in (GCC_LINK): Remove -static-libstdc++
-static-libgcc.
--
Eric BotcazouIndex: Makefile.tpl
===
--- Makefile.tpl (revision 192137)
+++ Makefile.tpl (working copy)
@@ -615,6 +615,12 @@ EXTRA_HOST_FLAGS = \
FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
+# Flags to pass to stage1 or when not bootstrapping.
+
+STAGE1_FLAGS_TO_PASS = \
+ LDFLAGS="$${LDFLAGS}" \
+ HOST_LIBS="$${HOST_LIBS}"
+
# Flags to pass to stage2 and later makes.
POSTSTAGE1_FLAGS_TO_PASS = \
@@ -1161,7 +1167,7 @@ clean-stage[+id+]-[+prefix+][+module+]:
[+ all prefix="" subdir="$(HOST_SUBDIR)"
exports="$(HOST_EXPORTS)"
poststage1_exports="$(POSTSTAGE1_HOST_EXPORTS)"
- args="$(EXTRA_HOST_FLAGS)"
+ args="$(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS)"
poststage1_args="$(POSTSTAGE1_FLAGS_TO_PASS)" +]
.PHONY: check-[+module+] maybe-check-[+module+]
Index: configure.ac
===
--- configure.ac (revision 192137)
+++ configure.ac (working copy)
@@ -1182,6 +1182,22 @@ if test -z "$LD"; then
fi
fi
+# Check whether -static-libstdc++ -static-libgcc is supported
+have_static_libs=no
+if test "$GCC" = yes; then
+ saved_LDFLAGS="$LDFLAGS"
+
+ LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
+ AC_MSG_CHECKING([whether g++ accepts -static-libstdc++ -static-libgcc])
+ AC_LANG_PUSH(C++)
+ AC_LINK_IFELSE([int main() {}],
+[AC_MSG_RESULT([yes]); have_static_libs=yes],
+[AC_MSG_RESULT([no])])
+ AC_LANG_POP(C++)
+
+ LDFLAGS="$saved_LDFLAGS"
+fi
+
ACX_PROG_GNAT
ACX_PROG_CMP_IGNORE_INITIAL
@@ -1478,17 +1494,6 @@ case $with_host_libstdcxx in
;;
esac
-# Linker flags to use for stage1 or when not boostrapping.
-AC_ARG_WITH(stage1-ldflags,
-[AS_HELP_STRING([--with-stage1-ldflags=FLAGS], [linker flags for stage1])],
-[if test "$withval" = "no" -o "$withval" = "yes"; then
- stage1_ldflags=
- else
- stage1_ldflags=$withval
- fi],
-[stage1_ldflags=])
-AC_SUBST(stage1_ldflags)
-
# Libraries to use for stage1 or when not bootstrapping.
AC_ARG_WITH(stage1-libs,
[AS_HELP_STRING([--with-stage1-libs=LIBS], [libraries for stage1])],
@@ -1500,6 +1505,23 @@ AC_ARG_WITH(stage1-libs,
[stage1_libs=$with_host_libstdcxx])
AC_SUBST(stage1_libs)
+# Linker flags to use for stage1 or when not bootstrapping.
+AC_ARG_WITH(stage1-ldflags,
+[AS_HELP_STRING([--with-stage1-ldflags=FLAGS], [linker flags for stage1])],
+[if test "$withval" = "no" -o "$withval" = "yes"; then
+ stage1_ldflags=
+ else
+ stage1_ldflags=$withval
+ fi],
+[stage1_ldflags=
+ # In stage 1, default to linking libstdc++ and libgcc statically with GCC
+ # if supported. But if the user explicitly specified the libraries to use,
+ # trust that they are doing what they want.
+ if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
+ stage1_ldflags="-static-libstdc++ -static-libgcc"
+ fi])
+AC_SUBST(stage1_ldflags)
+
# Libraries to use for stage2 and later builds. This defaults to the
# argument passed to --with-host-libstdcxx.
AC_ARG_WITH(boot-libs,
Index: gcc/ada/gcc-interface/Make-lang.in
===
--- gcc/ada/gcc-interface/Make-lang.in (revision 192137)
+++ gcc/ada/gcc-interface/Make-lang.in (working copy)
@@ -172,7 +172,7 @@ endif
# Strip -Werror during linking for the LTO bootstrap
GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS))
-GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) -static-libgcc -static-libstdc++ $(LDFLAGS)
+GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(LDFLAGS)
# Lists of files for various purposes
[PATCH] rs6000: Don't allow %. in PRINT_OPERAND_PUNCT_VALID_P
As David noticed, I forgot PRINT_OPERAND_PUNCT_VALID_P in the patch that removed %. This fixes it. Bootstrapped and regression tested on powerpc64-linux. Okay to apply? Segher 2012-10-09 Segher Boessenkool gcc/ * config/rs6000/rs6000.h (PRINT_OPERAND_PUNCT_VALID_P): Delete '.'. --- gcc/config/rs6000/rs6000.h |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h index b968802..82388d9 100644 --- a/gcc/config/rs6000/rs6000.h +++ b/gcc/config/rs6000/rs6000.h @@ -2229,8 +2229,7 @@ extern char rs6000_reg_names[][8];/* register names (0 vs. %r0). */ /* Define which CODE values are valid. */ -#define PRINT_OPERAND_PUNCT_VALID_P(CODE) \ - ((CODE) == '.' || (CODE) == '&') +#define PRINT_OPERAND_PUNCT_VALID_P(CODE) ((CODE) == '&') /* Print a memory address as an operand to reference that memory location. */ -- 1.7.7.6
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c
Ok, David preferred the 2 series of patches which replace all of the flags in
target_flags to rs6000_isa_flags to the 3 series of patches, which started
over, and added a new flag word, but did not change the existing options.
In an effort to simplify the main patch, I'm going to push out some of the
patches that are standalone. This patch fixes the 3 signed/unsigned warnings
that were caused by comparing an integer type with an enumeration. I did
bootstap and make check with no regressions. Is it ok to install (it is
probably ok under the obvious rule)?
2012-10-09 Michael Meissner
* config/rs6000/rs6000.c (altivec_expand_dst_builtin): Fix signed
vs. unsigned warnings by using enum type for function code.
(paired_expand_builtin): Likewise.
(spe_expand_builtin): Likewise.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 192265)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -10442,7 +10442,7 @@ altivec_expand_dst_builtin (tree exp, rt
bool *expandedp)
{
tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
- unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
+ enum rs6000_builtins fcode = (enum rs6000_builtins) DECL_FUNCTION_CODE
(fndecl);
tree arg0, arg1, arg2;
enum machine_mode mode0, mode1;
rtx pat, op0, op1, op2;
@@ -10844,7 +10844,7 @@ static rtx
paired_expand_builtin (tree exp, rtx target, bool * expandedp)
{
tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
- unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
+ enum rs6000_builtins fcode = (enum rs6000_builtins) DECL_FUNCTION_CODE
(fndecl);
const struct builtin_description *d;
size_t i;
@@ -10909,7 +10909,7 @@ spe_expand_builtin (tree exp, rtx target
{
tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
tree arg1, arg0;
- unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
+ enum rs6000_builtins fcode = (enum rs6000_builtins) DECL_FUNCTION_CODE
(fndecl);
enum insn_code icode;
enum machine_mode tmode, mode0;
rtx pat, op0;
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d
This patch is a preparation patch for the main infrastructure patch. It
changes the types of the builtin masks and target options from unsigned/signed
int to HOST_WIDE_INT. I built this with #2c also installed (but the two
patches are independent). It bootstraped and had no regressions. Is it ok to
install?
2012-10-09 Michael Meissner
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Change
builtin mask, target flags masks type to HOST_WIDE_INT in
preparation for growing the number of ISA switches from 31 to 63.
* config/rs6000/rs6000.opt (rs6000_builtin_mask): Make mask type
HOST_WIDE_INT.
* config/rs6000/rs6000.c (struct builtin_description): Make
builtin mask field HOST_WIDE_INT. Make target flags field
HOST_WIDE_INT in preparation for growing the # of ISA switches.
(struct rs6000_builtin_info_type): Likewise.
(struct rs6000_ptt): Likewise.
(rs6000_builtin_mask_calculate): Likewise.
(rs6000_invalid_builtin): Likewise.
(rs6000_builtin_decl): Likewise.
(rs6000_common_init_builtins): Likewise.
(rs6000_darwin_file_start): Likewise.
(rs6000_final_prescan_insn): Likewise.
(rs6000_inner_target_options): Likewise.
(build_target_option_node): Likewise.
(rs6000_function_specific_print): Likewise.
(DEBUG_FMT_W): New format for printing HOST_WIDE_INT in hex.
* config/rs6000/rs6000-protos.h (rs6000_builtin_mask_calculate):
Make target flags, builtin masks arguments/return values
HOST_WIDE_INT in preparation for growing the number of ISA from 31
to 63.
(rs6000_target_modify_macros): Likewise.
(rs6000_target_modify_macros_ptr): Likewise.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 192265)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -285,12 +285,15 @@ rs6000_define_or_undefine_macro (bool de
have both the target flags and the builtin flags as arguments. */
void
-rs6000_target_modify_macros (bool define_p, int flags, unsigned bu_mask)
+rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT flags,
+HOST_WIDE_INT bu_mask)
{
if (TARGET_DEBUG_BUILTIN || TARGET_DEBUG_TARGET)
-fprintf (stderr, "rs6000_target_modify_macros (%s, 0x%x, 0x%x)\n",
+fprintf (stderr,
+"rs6000_target_modify_macros (%s, " HOST_WIDE_INT_PRINT_HEX
+", " HOST_WIDE_INT_PRINT_HEX ")\n",
(define_p) ? "define" : "undef",
-(unsigned) flags, bu_mask);
+flags, bu_mask);
/* target_flags based options. */
rs6000_define_or_undefine_macro (define_p, "_ARCH_PPC");
Index: gcc/config/rs6000/rs6000.opt
===
--- gcc/config/rs6000/rs6000.opt(revision 192265)
+++ gcc/config/rs6000/rs6000.opt(working copy)
@@ -80,7 +80,7 @@ unsigned int rs6000_recip_control
;; Mask of what builtin functions are allowed
TargetVariable
-unsigned int rs6000_builtin_mask
+HOST_WIDE_INT rs6000_builtin_mask
;; Debug flags
TargetVariable
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 192265)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -214,7 +214,7 @@ static GTY(()) section *toc_section;
struct builtin_description
{
- const unsigned int mask;
+ const HOST_WIDE_INT mask;
const enum insn_code icode;
const char *const name;
const enum rs6000_builtins code;
@@ -288,7 +288,7 @@ typedef rtx (*gen_2arg_fn_t) (rtx, rtx,
/* Pointer to function (in rs6000-c.c) that can define or undefine target
macros that have changed. Languages that don't support the preprocessor
don't link in rs6000-c.c, so we can't call it directly. */
-void (*rs6000_target_modify_macros_ptr) (bool, int, unsigned);
+void (*rs6000_target_modify_macros_ptr) (bool, HOST_WIDE_INT, HOST_WIDE_INT);
/* Target cpu costs. */
@@ -894,7 +894,7 @@ struct processor_costs ppca2_cost = {
struct rs6000_builtin_info_type {
const char *name;
const enum insn_code icode;
- const unsigned mask;
+ const HOST_WIDE_INT mask;
const unsigned attr;
};
@@ -1505,7 +1505,7 @@ struct rs6000_ptt
{
const char *const name; /* Canonical processor name. */
const enum processor_type processor; /* Processor type enum value. */
- const int target_enable; /* Target flags to enable. */
+ const HOST_WIDE_INT target_enable; /* Target flags to enable. */
};
static struct rs6000_ptt const processor_target_table[] =
@@ -1719,6 +1719,7 @@ rs6000_debug_reg_print (int first_regno,
#define DEBUG_FM
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2e
This patch adds more debugging via -mdebug=reg to the compiler, and it is the
main way I verified that all of the options were set correctly. If you do not
use -mdebug=reg, this patch has no effect. When I emailed this patch, I had
bootstraped the compiler, and I was beginning to do make check. Assuming there
are no regressions, is it ok to check in?
2012-10-09 Michael Meissner
* config/rs6000/rs6000.c (DEBUG_FMT_ID): Move "-32s" to a separate
define and change DEBUG_FMT_ to use it.
(DEBUG_FMT_D): Likewise.
(DEBUG_FMT_S): Likewise.
(DEBUG_FMT_X): Delete, no longer used.
(DEBUG_FMT_W): Likewise.
(DEBUG_FMT_WX): New debug format for printing options in a
friendly fashion.
(rs6000_debug_reg_global): If -mdebug=reg, print all of the
options in target_flags and target_flags_explicit. Print the
default options for -mcpu=, -mtune=, and the default
options. Adjust printing out the builtin options.
(rs6000_option_override_internal): Change printing the builtin
options to use rs6000_print_builtin_options.
(rs6000_function_specific_print): Change to use
rs6000_print_isa_options to print ISA flags.
(rs6000_print_options_internal): New function for expanded
-mdebug=reg option printing to print both the ISA options, and the
builtins that are enabled.
(rs6000_print_isa_options): New function to print the ISA
options.
(rs6000_print_builtin_options): New function to print the builtin
functions enabled.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
--- gcc/config/rs6000/rs6000.c.~3~ 2012-10-09 18:03:14.461726078 -0400
+++ gcc/config/rs6000/rs6000.c 2012-10-09 18:43:10.627789006 -0400
@@ -1016,6 +1016,11 @@ bool (*rs6000_cannot_change_mode_class_p
const int INSN_NOT_AVAILABLE = -1;
+static void rs6000_print_isa_options (FILE *, int, const char *,
+ HOST_WIDE_INT);
+static void rs6000_print_builtin_options (FILE *, int, const char *,
+ HOST_WIDE_INT);
+
/* Hash table stuff for keeping track of TOC entries. */
struct GTY(()) toc_hash_struct
@@ -1716,10 +1721,10 @@ rs6000_debug_reg_print (int first_regno,
}
}
-#define DEBUG_FMT_D "%-32s= %d\n"
-#define DEBUG_FMT_X "%-32s= 0x%x\n"
-#define DEBUG_FMT_S "%-32s= %s\n"
-#define DEBUG_FMT_W "%-32s= " HOST_WIDEST_INT_PRINT_HEX "\n"
+#define DEBUG_FMT_ID "%-32s= "
+#define DEBUG_FMT_D DEBUG_FMT_ID "%d\n"
+#define DEBUG_FMT_WX DEBUG_FMT_ID "%#.12" HOST_WIDE_INT_PRINT "x: "
+#define DEBUG_FMT_S DEBUG_FMT_ID "%s\n"
/* Print various interesting information with -mdebug=reg. */
static void
@@ -1730,11 +1735,13 @@ rs6000_debug_reg_global (void)
int m;
char costly_num[20];
char nop_num[20];
+ char flags_buffer[40];
const char *costly_str;
const char *nop_str;
const char *trace_str;
const char *abi_str;
const char *cmodel_str;
+ struct cl_target_option cl_opts;
/* Map enum rs6000_vector to string. */
static const char *rs6000_debug_vector_unit[] = {
@@ -1814,12 +1821,42 @@ rs6000_debug_reg_global (void)
}
if (rs6000_cpu_index >= 0)
-fprintf (stderr, DEBUG_FMT_S, "cpu",
-processor_target_table[rs6000_cpu_index].name);
+{
+ const char *name = processor_target_table[rs6000_cpu_index].name;
+ HOST_WIDE_INT flags
+ = processor_target_table[rs6000_cpu_index].target_enable;
+
+ sprintf (flags_buffer, "-mcpu=%s flags", name);
+ rs6000_print_isa_options (stderr, 0, flags_buffer, flags);
+}
+ else
+fprintf (stderr, DEBUG_FMT_S, "cpu", "");
if (rs6000_tune_index >= 0)
-fprintf (stderr, DEBUG_FMT_S, "tune",
-processor_target_table[rs6000_tune_index].name);
+{
+ const char *name = processor_target_table[rs6000_tune_index].name;
+ HOST_WIDE_INT flags
+ = processor_target_table[rs6000_tune_index].target_enable;
+
+ sprintf (flags_buffer, "-mtune=%s flags", name);
+ rs6000_print_isa_options (stderr, 0, flags_buffer, flags);
+}
+ else
+fprintf (stderr, DEBUG_FMT_S, "tune", "");
+
+ cl_target_option_save (&cl_opts, &global_options);
+ rs6000_print_isa_options (stderr, 0, "target_flags", target_flags);
+
+ rs6000_print_isa_options (stderr, 0, "target_flags_explicit",
+ target_flags_explicit);
+
+ rs6000_print_builtin_options (stderr, 0, "rs6000_builtin_mask",
+ rs6000_builtin_mask);
+
+ rs6000_print_isa_options (stderr, 0, "TARGET_DEFAULT", TARGET_DEFAULT);
+
+ fprintf (stderr, DEBUG_FMT_S, "--with-cpu default",
+ OPTION_TARGET_CPU_DEFAULT ? OPTION_TARGET_CPU_DEFAULT : "");
switch (rs6000_sched_costly_dep)
{
@@ -1937,7 +1974,15 @@ rs6000_debug_reg_global (void)
if (rs6000_floa
Re: [PATCH] Rs6000 infrastructure cleanup (switches), question
No before I go an redo the main part of patch #2, I have a question, which
people prefer.
The current code has sequences of:
target_flags |= MASK_FOO; /* set -mfoo */
if ((target_flags_explicit & MASK_FOO)) ... /* Did user do -mfoo or
-mno-foo */
I can either change the code like I did before:
rs6000_isa_flags |= OPTION_MASK_FOO;
if ((rs6000_isa_flags_explicit & OPTION_MASK_FOO)) ...
Or I can add various macros to 'hide' the underlying bit manipulation, which
would allow me to stage all of the changes into multiple patches. I tend to
prefer the raw bit manipulation because it is less change overall, we've used
raw bit manipulation forever. However I'm willing to add the accessor macros
and submit multiple patches to get this checked in:
#define TARGET_FOO_EXPLICIT ((target_flags_explict & MASK_FOO) != 0)
#define SET_TARGET_FOO(VALUE)\
do { \
if (VALUE) \
target_flags |= MASK_FOO;\
else \
target_flags &= ~MASK_FOO; \
} while (0)
#define SET_TARGET_FOO_EXPLICIT (target_flags_explicit |= MASK_FOO)
and then once all of the raw access to target_flags and target_flags_explicit
is done via accessors, I can finally do the change:
#define TARGET_FOO_EXPLICIT \
((rs6000_isa_flags_explict & OPTION_MASK_FOO) != 0)
#define SET_TARGET_FOO(VALUE)\
do { \
if (VALUE) \
rs6000_isa_flags |= OPTION_MASK_FOO; \
else \
rs6000_isa_flags &= ~OPTION_MASK_FOO;\
} while (0)
#define SET_TARGET_FOO_EXPLICIT \
(rs6000_isa_flags_explicit |= OPTION_MASK_FOO)
An alternative would be to provide separate SET/CLEAR macros:
#define TARGET_FOO_EXPLICIT ((target_flags_explict & MASK_FOO) != 0)
#define SET_TARGET_FOO (target_flags |= MASK_FOO)
#define CLEAR_TARGET_FOO (target_flags &= ~MASK_FOO)
#define SET_TARGET_FOO_EXPLICIT (target_flags_explicit |= MASK_FOO)
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[C++ testcase] PR 53307
Hi,
I'm adding the testcase and closing the PR as fixed. Tested x86_64-linux.
Thanks,
Paolo.
//
2012-10-10 Paolo Carlini
PR c++/53307
* g++.dg/cpp0x/decltype44.C: New.
Index: g++.dg/cpp0x/decltype44.C
===
--- g++.dg/cpp0x/decltype44.C (revision 0)
+++ g++.dg/cpp0x/decltype44.C (working copy)
@@ -0,0 +1,44 @@
+// PR c++/53307
+// { dg-do compile { target c++11 } }
+
+template struct tuple{};
+
+struct funct
+{
+ template
+ T operator()(T arg1, argTs...)
+ {
+return arg1;
+ }
+};
+
+template class test;
+
+template < template class tp,
+ class...arg1Ts,
+ class...arg2Ts>
+class test, tp>
+{
+ public:
+ template
+auto test_pass(func fun, arg2Ts...arg2s)
+-> decltype(fun(arg2s...))
+ {
+return fun(arg2s...);
+ }
+
+ template
+auto testbug(func fun, arg2Ts...arg2s, arg3Ts...arg3s)
+-> decltype(fun(arg2s..., arg3s...))
+ {
+return fun(arg2s..., arg3s...);
+ }
+};
+
+int main()
+{
+ test, tuple> t;
+ t.test_pass (funct(), 'a', 2);
+ t.testbug (funct(), 'a', 2, "fine");
+ t.testbug (funct(), 'a', 2);
+}
Re: Use conditional casting with symtab_node
On 10/5/12, Jan Hubicka wrote:
>> On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo wrote:
>> > On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl wrote:
>> >
>> >> So, Jan Hubicka requested and approved the current spelling.
>> >> What now?
>> >
>> > I don't think we should hold this up. The names Jan requested seem
>> > reasonable enough. We seem to be running in circles here.
>>
>> I suppose I have your promise that we'll release with consistent names.
>> Please allocate some work hours on your side for the renaming of
>> cgraph_node and varpool_node for the case Honza doesn't get to it in
>> time.
>
> Not that I would not agree with Richard with most of his points. To be
> however
> fair here, I only asked to continue naming I already introduced in:
>
> /* Return true when NODE is function. */
> static inline bool
> symtab_function_p (symtab_node node)
> {
> return node->symbol.type == SYMTAB_FUNCTION;
> }
>
> /* Return true when NODE is variable. */
> static inline bool
> symtab_variable_p (symtab_node node)
> {
> return node->symbol.type == SYMTAB_VARIABLE;
> }
>
> Even if variable are represented by varpool and functions by cgraph, I do
> not
> see these names more confusing compared to
> symtab_cgraph_p/symtab_varpool_p.
> The most common use is when you walk the symbol table and you want to
> handle
> functions and variables specially.
>
> The new interface with try_ scheme gives a bit more inconsistent feeling,
> but it is just an surface, nothing really changes.
>
> I am not happy with current naming scheme and also with the fact that for
> gengtype reasons we also have symtab_node typedef, but for varpool and
> cgraph
> we use struct (this is because symtab_node has to be union without GTY
> supporting inheritance).
>
> Introducing symtab I did not have much other options and I expected that
> at the end of this stage1 I will clean it up. This is, well, more or less
> now
> when assuming that there are no major patches to this area just to appear
> for this stage1.
>
> I guess we all agreed we want to drop cgraph/varpool nodes in favor of
> functions/ variables. How realistic is for gengtype to support inheritance
> this release cycle? I would really like to see these three turned into
> classes
> with the inheritance this release cycle. Renaming them during the process
> should be easy and just a nice bonus.
I would like some clarity. Can I commit this patch?
--
Lawrence Crowl
Re: [PATCH] Assigning correct source location for deallocator
OK. Jason
Re: [PATCH 0/3] Fix fallouts from c++11 attributes work
These are all OK. Jason
Re: [PATCH] rs6000: Don't allow %. in PRINT_OPERAND_PUNCT_VALID_P
On Tue, Oct 9, 2012 at 6:53 PM, Segher Boessenkool wrote: > As David noticed, I forgot PRINT_OPERAND_PUNCT_VALID_P in the patch > that removed %. This fixes it. > > Bootstrapped and regression tested on powerpc64-linux. Okay to > apply? > 2012-10-09 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.h (PRINT_OPERAND_PUNCT_VALID_P): > Delete '.'. Okay. Thanks, David
Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables
On 10/09/2012 04:36 PM, Dominique Dhumieres wrote: ==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd ==36994==at 0x10001252D: free (vg_replace_malloc.c:430) ==36994==by 0x1003B5CB2: emutls_destroy (in /opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib) Aha. So the problem is that we're destroying the TLS data from one pthread key destructor, and then a later destructor tries to use it. Hmm, that's awkward. And surprising, since we do TLS lookup before creating the key for the atexit list, so the emutls_destroy destructor should have been registered sooner, and so run later. Does the Darwin pthread_tsd_cleanup not run destructors in reverse order of registration? Jason
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c
On Tue, Oct 9, 2012 at 6:58 PM, Michael Meissner wrote: > Ok, David preferred the 2 series of patches which replace all of the flags in > target_flags to rs6000_isa_flags to the 3 series of patches, which started > over, and added a new flag word, but did not change the existing options. > > In an effort to simplify the main patch, I'm going to push out some of the > patches that are standalone. This patch fixes the 3 signed/unsigned warnings > that were caused by comparing an integer type with an enumeration. I did > bootstap and make check with no regressions. Is it ok to install (it is > probably ok under the obvious rule)? > > 2012-10-09 Michael Meissner > > * config/rs6000/rs6000.c (altivec_expand_dst_builtin): Fix signed > vs. unsigned warnings by using enum type for function code. > (paired_expand_builtin): Likewise. > (spe_expand_builtin): Likewise. This patch is okay. Thanks, David
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d
On Tue, Oct 9, 2012 at 7:01 PM, Michael Meissner wrote: > This patch is a preparation patch for the main infrastructure patch. It > changes the types of the builtin masks and target options from unsigned/signed > int to HOST_WIDE_INT. I built this with #2c also installed (but the two > patches are independent). It bootstraped and had no regressions. Is it ok to > install? > > 2012-10-09 Michael Meissner > > * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Change > builtin mask, target flags masks type to HOST_WIDE_INT in > preparation for growing the number of ISA switches from 31 to 63. > > * config/rs6000/rs6000.opt (rs6000_builtin_mask): Make mask type > HOST_WIDE_INT. > > * config/rs6000/rs6000.c (struct builtin_description): Make > builtin mask field HOST_WIDE_INT. Make target flags field > HOST_WIDE_INT in preparation for growing the # of ISA switches. > (struct rs6000_builtin_info_type): Likewise. > (struct rs6000_ptt): Likewise. > (rs6000_builtin_mask_calculate): Likewise. > (rs6000_invalid_builtin): Likewise. > (rs6000_builtin_decl): Likewise. > (rs6000_common_init_builtins): Likewise. > (rs6000_darwin_file_start): Likewise. > (rs6000_final_prescan_insn): Likewise. > (rs6000_inner_target_options): Likewise. > (build_target_option_node): Likewise. > (rs6000_function_specific_print): Likewise. > (DEBUG_FMT_W): New format for printing HOST_WIDE_INT in hex. > > * config/rs6000/rs6000-protos.h (rs6000_builtin_mask_calculate): > Make target flags, builtin masks arguments/return values > HOST_WIDE_INT in preparation for growing the number of ISA from 31 > to 63. > (rs6000_target_modify_macros): Likewise. > (rs6000_target_modify_macros_ptr): Likewise. This patch is okay. Thanks, David
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2e
On Tue, Oct 9, 2012 at 7:20 PM, Michael Meissner wrote: > This patch adds more debugging via -mdebug=reg to the compiler, and it is the > main way I verified that all of the options were set correctly. If you do not > use -mdebug=reg, this patch has no effect. When I emailed this patch, I had > bootstraped the compiler, and I was beginning to do make check. Assuming > there > are no regressions, is it ok to check in? > > 2012-10-09 Michael Meissner > > * config/rs6000/rs6000.c (DEBUG_FMT_ID): Move "-32s" to a separate > define and change DEBUG_FMT_ to use it. > (DEBUG_FMT_D): Likewise. > (DEBUG_FMT_S): Likewise. > (DEBUG_FMT_X): Delete, no longer used. > (DEBUG_FMT_W): Likewise. > (DEBUG_FMT_WX): New debug format for printing options in a > friendly fashion. > (rs6000_debug_reg_global): If -mdebug=reg, print all of the > options in target_flags and target_flags_explicit. Print the > default options for -mcpu=, -mtune=, and the default > options. Adjust printing out the builtin options. > (rs6000_option_override_internal): Change printing the builtin > options to use rs6000_print_builtin_options. > (rs6000_function_specific_print): Change to use > rs6000_print_isa_options to print ISA flags. > (rs6000_print_options_internal): New function for expanded > -mdebug=reg option printing to print both the ISA options, and the > builtins that are enabled. > (rs6000_print_isa_options): New function to print the ISA > options. > (rs6000_print_builtin_options): New function to print the builtin > functions enabled. This patch is okay. Thanks, David
RE: [Patch ARM] Fix that miss DMB instruction for ARMv6-M
> -Original Message- > From: Richard Earnshaw > Sent: Tuesday, October 09, 2012 10:01 PM > To: Terry Guo > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [Patch ARM] Fix that miss DMB instruction for ARMv6-M > > On 08/10/12 08:29, Terry Guo wrote: > > Hi, > > > > When running libstdc++ regression test on Cortex-M0, the case > 49445.cc fails > > with error message: > > > > /tmp/ccMqZdgc.o: In function > `std::atomic::load(std::memory_order) > > const':^M > > /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none- > eabi/armv6-m/ > > libstdc++-v3/include/atomic:202: undefined reference to > > `__sync_synchronize'^M > > /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none- > eabi/armv6-m/ > > libstdc++-v3/include/atomic:202: undefined reference to > > `__sync_synchronize'^M > > /tmp/ccMqZdgc.o: In function > `std::atomic::load(std::memory_order) > > const':^M > > /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none- > eabi/armv6-m/ > > libstdc++-v3/include/atomic:202: undefined reference to > > `__sync_synchronize'^M > > /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none- > eabi/armv6-m/ > > libstdc++-v3/include/atomic:202: undefined reference to > > `__sync_synchronize'^M > > collect2: error: ld returned 1 exit status^M > > compiler exited with status 1 > > > > After investigation, the reason is current gcc doesn't think armv6-m > has DMB > > instruction. While according to ARM manuals, it has. With this wrong > > assumption, the expand_mem_thread_fence will generate a call to > library > > function __sync_synchronize rather than DMB instruction. While no > code to > > implement this library function, so the error generates. > > > > The attached patch intends to fix this issue by letting gcc also > think > > armv6-m has DMB instruction. Is it OK to trunk? > > > > BR, > > Terry > > > > 2012-10-08 Terry Guo > > > > * config/arm/arm.c (arm_arch6m): New variable to denote > armv6-m > > architecture. > > * config/arm/arm.h (TARGET_HAVE_DMB): The armv6-m also has > DMB > > instruction. > > > > > > Ok. > > R. Thanks Richard. Is it OK to 4.7? BR, Terry
[PATCH] Make Niagara-4 instruction scheduling more accurate.
Some recent work showed me that many of the latency values in the documentation I have for Niagara-4 were simply inaccurate. So I went through the instruction set and tried to determine the real values by hand using test programs. In particular the logical VIS operation, when working on 64-bit operands, can largely execute in 3 cycles instead of 11. 64-bit moves between float and integer registers can execute in 1 cycle. We also now properly represent the special third slot that stores can sometimes be scheduled into. Finally, we were emitting 'fsrc1' as the VIS move which on are quite expensive on Niagara-4 and later. 'fsrc2' executes in 1 cycle vs. 11 for 'fsrc1'. Committed to mainline. * config/sparc/sparc.md (type attribute): Add new types 'visl' (VIS logical operation), 'vismv' (VIS move), and 'pdistn'. Rename 'fgm_pdist' to 'pdist'. (*movsi_insn): Use vismv and visl. (*movdi_insn_sp64): Likewise. (*movsf_insn): Likewise. (*movdf_insn_sp64): Likewise. (*mov_insn): Likewise, use 'fsrc2s' instead of 'fsrc1s'. (*mov_insn_sp64): Likewise, use 'fsrc2s' instead of 'fsrc1s'. (*mov_insn_sp32): Likewise, use 'fsrc2s' instead of 'fsrc1s'. (VIS logical instructions): Mark as visl. (pdist_vis): Use 'pdist'. (pditsn_vis): Use 'pdistn'. * config/sparc/ultra1_2.md: Adjust for new VIS attribute types. * config/sparc/ultra3.md: Likewise. * config/sparc/niagara.md: Likewise. * config/sparc/niagara2.md: Likewise. * config/sparc/niagara4.md: Add cpu units "n4_slot2" and "n4_load_store" for special store scheduling. Use them in load and store reservations. Integer divide and multiply can only issue in slot-1. Represent 1-cycle VIS moves and 3-cycle VIS logic operations. --- gcc/ChangeLog| 25 ++ gcc/config/sparc/niagara.md | 2 +- gcc/config/sparc/niagara2.md | 4 ++-- gcc/config/sparc/niagara4.md | 49 gcc/config/sparc/sparc.md| 46 - gcc/config/sparc/ultra1_2.md | 6 +++--- gcc/config/sparc/ultra3.md | 4 ++-- 7 files changed, 96 insertions(+), 40 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index a7d550f..f428d07 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,28 @@ +2012-10-09 David S. Miller + + * config/sparc/sparc.md (type attribute): Add new types 'visl' + (VIS logical operation), 'vismv' (VIS move), and 'pdistn'. Rename + 'fgm_pdist' to 'pdist'. + (*movsi_insn): Use vismv and visl. + (*movdi_insn_sp64): Likewise. + (*movsf_insn): Likewise. + (*movdf_insn_sp64): Likewise. + (*mov_insn): Likewise, use 'fsrc2s' instead of 'fsrc1s'. + (*mov_insn_sp64): Likewise, use 'fsrc2s' instead of 'fsrc1s'. + (*mov_insn_sp32): Likewise, use 'fsrc2s' instead of 'fsrc1s'. + (VIS logical instructions): Mark as visl. + (pdist_vis): Use 'pdist'. + (pditsn_vis): Use 'pdistn'. + * config/sparc/ultra1_2.md: Adjust for new VIS attribute types. + * config/sparc/ultra3.md: Likewise. + * config/sparc/niagara.md: Likewise. + * config/sparc/niagara2.md: Likewise. + * config/sparc/niagara4.md: Add cpu units "n4_slot2" and + "n4_load_store" for special store scheduling. Use them in load + and store reservations. Integer divide and multiply can only + issue in slot-1. Represent 1-cycle VIS moves and 3-cycle VIS + logic operations. + 2012-10-10 Dehao Chen * tree-eh.c (lower_try_finally_onedest): Set correct location for diff --git a/gcc/config/sparc/niagara.md b/gcc/config/sparc/niagara.md index c7db7b9..e471b84 100644 --- a/gcc/config/sparc/niagara.md +++ b/gcc/config/sparc/niagara.md @@ -114,5 +114,5 @@ */ (define_insn_reservation "niag_vis" 8 (and (eq_attr "cpu" "niagara") -(eq_attr "type" "fga,fgm_pack,fgm_mul,fgm_pdist,edge,edgen,gsr,array")) +(eq_attr "type" "fga,visl,vismv,fgm_pack,fgm_mul,pdist,edge,edgen,gsr,array")) "niag_pipe*8") diff --git a/gcc/config/sparc/niagara2.md b/gcc/config/sparc/niagara2.md index 59499aa..856fc01 100644 --- a/gcc/config/sparc/niagara2.md +++ b/gcc/config/sparc/niagara2.md @@ -111,10 +111,10 @@ (define_insn_reservation "niag2_vis" 6 (and (eq_attr "cpu" "niagara2") -(eq_attr "type" "fga,fgm_pack,fgm_mul,fgm_pdist,edge,edgen,array,gsr")) +(eq_attr "type" "fga,vismv,visl,fgm_pack,fgm_mul,pdist,edge,edgen,array,gsr")) "niag2_pipe*6") (define_insn_reservation "niag3_vis" 9 (and (eq_attr "cpu" "niagara3") -(eq_attr "type" "fga,fgm_pack,fgm_mul,fgm_pdist,edge,edgen,array,gsr")) +(eq_attr "type" "fga,vismv,visl,fgm_pack,fgm_mul,pdist,pdistn,edge,edgen,array,gsr")) "niag2_pipe*9") diff --git a/gcc/config/sparc/niagara4.md b/gcc/config/sparc/niagara4.md index f1f83b6..272c8ff 10
Re: [testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux
On 10/09/2012 07:39 AM, Richard Earnshaw wrote:
> On 27/09/12 01:02, Janis Johnson wrote:
>> Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
>> targets, as described in PR54732. This patch adds an XFAIL.
>>
>> Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
>>
>> Janis
>>
>>
>> gcc-20120926-5
>>
>>
>> 2012-09-26 Janis Johnson
>>
>> * gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.
>>
>> Index: gcc.target/arm/div64-unwinding.c
>> ===
>> --- gcc.target/arm/div64-unwinding.c (revision 191765)
>> +++ gcc.target/arm/div64-unwinding.c (working copy)
>> @@ -1,6 +1,7 @@
>> /* Performing a 64-bit division should not pull in the unwinder. */
>>
>> -/* { dg-do run } */
>> +/* The test is expected to fail for GNU/Linux; see PR54723. */
>> +/* { dg-do run { xfail *-*-linux* } } */
>> /* { dg-options "-O0" } */
>>
>> #include
>>
>
> I don't like this. To me, XFAIL means "there's a bug here, but we're
> not too worried about it". The behaviour on linux targets is correct,
> so this test should either PASS or be skipped.
Richard,
The impression I got from Julian is "there's a bug here, but we're not
too worried about it". If you think it should be skipped instead then
I'll gladly change the test.
Janis
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
> Hi All,
>
> Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
> path when invoking the wrapped binutils program. This goes against the
> accepted practice in GCC to find sub-programs relative to where the
> GCC binaries are stored and to not make assumptions about the PATH.
>
> This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
> by factoring out some utility code for finding files from collect2.c.
> These functions are then leveraged to find the binutils programs.
> Note that similar code exist in gcc.c. Perhaps one day everything
> can be merged to the file-find files.
>
> Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
> arm-none-eabi targets. OK?
>
> P.S. I am not quite sure what is best for the copyrights and contributed
> by comments in the file-find* files I added since that code was just moved.
> This patch drops the contributed by and keeps all the copyright dates from
> collect2.c.
>
> 2012-10-04 Meador Inge
>
> * collect2.c (main): Call find_file_set_debug.
> (find_a_find, add_prefix, prefix_from_env, prefix_from_string):
> Factor out into ...
> * file-find.c (New file): ... here and ...
> * file-find.h (New file): ... here.
> * gcc-ar.c (standard_exec_prefix): New variable.
> (standard_libexec_prefix): Ditto.
> (tooldir_base_prefix) Ditto.
> (self_exec_prefix): Ditto.
> (self_libexec_prefix): Ditto.
> (self_tooldir_prefix): Ditto.
> (target_version): Ditto.
> (path): Ditto.
> (target_path): Ditto.
> (setup_prefixes): New function.
> (main): Rework how wrapped programs are found.
> * Makefile.in (OBJS-libcommon-target): Add file-find.o.
> (AR_OBJS): New variable.
> (gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
> (gcc-nm$(exeext)): Ditto.
> (gcc-ranlib(exeext)): Ditto.
> (COLLECT2_OBJS): Add file-find.o.
> (collect2.o): Add file-find.h prerequisite.
> (file-find.o): New rule.
>
> Index: gcc/gcc-ar.c
> ===
> --- gcc/gcc-ar.c (revision 192099)
> +++ gcc/gcc-ar.c (working copy)
> @@ -21,21 +21,110 @@
> #include "config.h"
> #include "system.h"
> #include "libiberty.h"
> +#include "file-find.h"
>
> #ifndef PERSONALITY
> #error "Please set personality"
> #endif
>
> +/* The exec prefix as derived at compile-time from --prefix. */
> +
> +static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
> +
> +/* The libexec prefix as derived at compile-time from --prefix. */
> +
> static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
> +
> +/* The bindir prefix as derived at compile-time from --prefix. */
> +
> static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
> -static const char *const target_machine = TARGET_MACHINE;
>
> +/* A relative path to be used in finding the location of tools
> + relative to this program. */
> +
> +static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
> +
> +/* The exec prefix as relocated from the location of this program. */
> +
> +static const char *self_exec_prefix;
> +
> +/* The libexec prefix as relocated from the location of this program. */
> +
> +static const char *self_libexec_prefix;
> +
> +/* The tools prefix as relocated from the location of this program. */
> +
> +static const char *self_tooldir_prefix;
> +
> +/* The name of the machine that is being targeted. */
> +
> +static const char *const target_machine = DEFAULT_TARGET_MACHINE;
> +
> +/* The target version. */
> +
> +static const char *const target_version = DEFAULT_TARGET_VERSION;
> +
> +/* The collection of target specific path prefixes. */
> +
> +static struct path_prefix target_path;
> +
> +/* The collection path prefixes. */
> +
> +static struct path_prefix path;
> +
> +/* The directory separator. */
> +
> static const char dir_separator[] = { DIR_SEPARATOR, 0 };
>
> +static void
> +setup_prefixes (const char *exec_path)
> +{
> + const char *self;
> +
> + self = getenv ("GCC_EXEC_PREFIX");
> + if (!self)
> +self = exec_path;
> + else
> +self = concat (self, "gcc-" PERSONALITY, NULL);
> +
> + /* Relocate the exec prefix. */
> + self_exec_prefix = make_relative_prefix (self,
> +standard_bin_prefix,
> +standard_exec_prefix);
> + if (self_exec_prefix == NULL)
> +self_exec_prefix = standard_exec_prefix;
> +
> + /* Relocate libexec prefix. */
> + self_libexec_prefix = make_relative_prefix (self,
> + standard_bin_prefix,
> + standard_libexec_prefix);
> + if (self_libexec_prefix == NULL)
> +self_libexec_prefix = standard_libexec_prefix;
> +
> +
> + /* Build the relative path to the target-specific tool director
[RS6000] VSX splat fix
This fixes a problem with my PR45844 fix. PR45844 was due to rs6000.c
reg_offset_addressing_ok_p testing the operand mode to determine
whether an insn supports reg+offset addressing, but the VSX splat insn
uses a DF/DI mode input operand. So the memory form of this insn was
wrongly seen to support reg+offset addressing. I hacked around this
by adjusting the mode in the insn predicate, which happened to work
for the PR45844 testcase, but actually causes the predicate to reject
all MEMs since general_operand checks that the mode matches. (Oddly,
this does not stop reload using the memory form of the insn!
const_double passes the predicate, reload forces to mem which matches
one of the constraints, and the predicate is not checked again.)
This avoids the general_operand mode check by expanding code from
there relevant to MEMs. Bootstrapped and regression tested
powerpc64-linux. OK for mainline and 4.6/4.7?
* config/rs6000/predicates.md (splat_input_operand): Don't call
input_operand for MEMs. Instead check for volatile and call
memory_address_addr_space_p with modified mode.
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 192236)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -941,12 +941,16 @@
{
if (MEM_P (op))
{
+ if (! volatile_ok && MEM_VOLATILE_P (op))
+ return 0;
if (mode == DFmode)
mode = V2DFmode;
else if (mode == DImode)
mode = V2DImode;
else
- gcc_unreachable ();
+ gcc_unreachable ();
+ return memory_address_addr_space_p (mode, XEXP (op, 0),
+ MEM_ADDR_SPACE (op));
}
return input_operand (op, mode);
})
--
Alan Modra
Australia Development Lab, IBM
[lra] another patch for lra-eliminations.c
The following patch is formed from latest discussion with Richard Sandiford.
The patch was successfully bootstrapped on x86/x86-64 and ppc64.
Committed as rev. 192287.
012-10-09 Vladimir Makarov
* lra-eliminations.c (lra_eliminate_regs_1): Remove mem_mode
check. Remove form_sum check. Remove code in #ifdef
WORD_REGISTER_OPERATIONS.
(eliminate_regs_in_insn): Rename argument validate_p to replace_p.
Rename val to validate_p. Remove clobber generation.
Index: lra-eliminations.c
===
--- lra-eliminations.c (revision 192262)
+++ lra-eliminations.c (working copy)
@@ -362,8 +362,7 @@ lra_eliminate_regs_1 (rtx x, enum machin
offset = (update_p
? ep->offset - ep->previous_offset : ep->offset);
- if (mem_mode != 0
- && CONST_INT_P (XEXP (x, 1))
+ if (CONST_INT_P (XEXP (x, 1))
&& INTVAL (XEXP (x, 1)) == -offset)
return to;
else
@@ -378,9 +377,14 @@ lra_eliminate_regs_1 (rtx x, enum machin
}
/* If this is part of an address, we want to bring any constant
-to the outermost PLUS. We will do this by doing hard
+to the outermost PLUS. We will do this by doing hard
register replacement in our operands and seeing if a constant
-shows up in one of them. */
+shows up in one of them.
+
+Note that there is no risk of modifying the structure of the
+insn, since we only get called for its operands, thus we are
+either modifying the address inside a MEM, or something like
+an address operand of a load-address insn. */
{
rtx new0 = lra_eliminate_regs_1 (XEXP (x, 0), mem_mode,
@@ -388,18 +392,8 @@ lra_eliminate_regs_1 (rtx x, enum machin
rtx new1 = lra_eliminate_regs_1 (XEXP (x, 1), mem_mode,
subst_p, update_p, full_p);
- if (reg_renumber && (new0 != XEXP (x, 0) || new1 != XEXP (x, 1)))
- {
- new_rtx = form_sum (new0, new1);
-
- /* As above, if we are not inside a MEM we do not want to
- turn a PLUS into something else. We might try to do so here
- for an addition of 0 if we aren't optimizing. */
- if (! mem_mode && GET_CODE (new_rtx) != PLUS)
- return gen_rtx_PLUS (GET_MODE (x), new_rtx, const0_rtx);
- else
- return new_rtx;
- }
+ if (new0 != XEXP (x, 0) || new1 != XEXP (x, 1))
+ return form_sum (new0, new1);
}
return x;
@@ -543,31 +537,15 @@ lra_eliminate_regs_1 (rtx x, enum machin
return x;
case SUBREG:
- new_rtx = lra_eliminate_regs_1 (SUBREG_REG (x), mem_mode,
- subst_p, update_p, full_p);
+ new_rtx = lra_eliminate_regs_1 (SUBREG_REG (x), mem_mode,
+ subst_p, update_p, full_p);
if (new_rtx != SUBREG_REG (x))
{
int x_size = GET_MODE_SIZE (GET_MODE (x));
int new_size = GET_MODE_SIZE (GET_MODE (new_rtx));
- if (MEM_P (new_rtx)
- && ((x_size < new_size
-#ifdef WORD_REGISTER_OPERATIONS
- /* On these machines, combine can create RTL of the form
- (set (subreg:m1 (reg:m2 R) 0) ...)
- where m1 < m2, and expects something interesting to
- happen to the entire word. Moreover, it will use the
- (reg:m2 R) later, expecting all bits to be preserved.
- So if the number of words is the same, preserve the
- subreg so that LRA can see it. */
- && ! ((x_size - 1) / UNITS_PER_WORD
-== (new_size -1 ) / UNITS_PER_WORD)
-#endif
- )
- || x_size == new_size)
- )
-
+ if (MEM_P (new_rtx) && x_size <= new_size)
{
SUBREG_REG (x) = new_rtx;
alter_subreg (&x, false);
@@ -766,18 +744,18 @@ mark_not_eliminable (rtx x)
/* Scan INSN and eliminate all eliminable hard registers in it.
- If VALIDATE_P is true, do the replacement destructively. Also
+ If REPLACE_P is true, do the replacement destructively. Also
delete the insn as dead it if it is setting an eliminable register.
- If VALIDATE_P is false, just update the offsets while keeping the
+ If REPLACE_P is false, just update the offsets while keeping the
base register the same. */
static void
-eliminate_regs_in_insn (rtx insn, bool validate_p)
+eliminate_regs_in_insn (rtx insn, bool replace_p)
{
int icode = recog_memoized (insn);
rtx old_set = single_set (insn);
- bool val;
+ bool validate_p;
int i;
rtx substed_operand[MAX_RECOG_OPERANDS];
rtx orig_operand[MAX_RECOG_OPERANDS];
@@ -800,7
Re: RFC: LRA for x86/x86-64 [7/9]
On 10/09/2012 06:17 AM, Richard Sandiford wrote: Thanks for the updates. Vladimir Makarov writes: + a change in the offset between the eliminable register and its + substitution if UPDATE_P, or the full offset if FULL_P, or + otherwise zero. I wonder if an enum would be better than two booleans? It avoids invalid combinations like UPDATE_P && FULL_P and might make the arguments more obvious too. IMHO, It is matter of choice. I don't like to introduce a new enum just for the function. It is pretty standard situation. I usually introduce enum when there are a few combinations prohibited. OK. I agree this is probably personal preference. + /* The only time we want to replace a PLUS with a REG +(this occurs when the constant operand of the PLUS is +the negative of the offset) is when we are inside a +MEM. We won't want to do so at other times because +that would change the structure of the insn in a way +that reload can't handle. We special-case the +commonest situation in eliminate_regs_in_insn, so +just replace a PLUS with a PLUS here, unless inside a +MEM. */ Reload reference. Does this restriction still apply? The later comment: I don't think so. I removed the comment. Well, the question was about the code as much as the comment. The comment did describe what the code did: if (mem_mode != 0 && CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, 1)) == -offset) return to; else return gen_rtx_PLUS (Pmode, to, plus_constant (Pmode, XEXP (x, 1), offset)); If the restriction doesn't apply any more then the mem_mode condition should be removed. If does apply then we should have some sort of comment to explain why. I suppose the question is: what happens for PLUS match_operators? If elimination changes a (plus (reg X) (const_int Y)) into (reg X'), and the (plus ...) is matched via a match_operator, will LRA cope correctly? Or does LRA require a plus matched via a match_operator to remain a plus? Or shouldn't we eliminate match_operators at all, and just process true operands? I wasn't sure at this point (and still haven't read through everything, so am still not sure now). I guess LRA can handle such change with or without minor modification (a new insn recognition). So I am removing mem_mode condition. At least I did not find a problem at least on two targets. I might return the code if I find a target where it is really necessary. +Note that there is no risk of modifying the structure of the insn, +since we only get called for its operands, thus we are either +modifying the address inside a MEM, or something like an address +operand of a load-address insn. */ I removed this too. I think that's still accurate and should be kept. I was just using it to emphasise a point (probably badly, sorry). I returned the comment. makes it sound on face value like the MEM restriction above is a reload-specific thing. Same question for: + /* As above, if we are not inside a MEM we do not want to + turn a PLUS into something else. We might try to do so here + for an addition of 0 if we aren't optimizing. */ It looks like your follow-up patch left this alone FWIW. I modify the code as above in hope that the removed code will be not necessary. +#ifdef WORD_REGISTER_OPERATIONS + /* On these machines, combine can create RTL of the form + (set (subreg:m1 (reg:m2 R) 0) ...) + where m1 < m2, and expects something interesting to + happen to the entire word. Moreover, it will use the + (reg:m2 R) later, expecting all bits to be preserved. + So if the number of words is the same, preserve the + subreg so that push_reload can see it. */ + && ! ((x_size - 1) / UNITS_PER_WORD +== (new_size -1 ) / UNITS_PER_WORD) +#endif Reload reference (push_reload). Do we still need this for LRA? It is hard me to say. So I would not touch this code at least for now. I changed push reload to LRA. Could I ask you to reconsider? The situation that the comment describes sounds like a bug to me. Removing it shouldn't affect the 4.8 submission. It just seems to me that LRA is our big chance of getting rid of some of this cruft. If we're too scared to touch code like this even on a big change like reload to LRA, we'll never be able to touch it. Yes, you are right. I am removing this too. It does not affect x86. It might affect other targets (although I don't think so. I guess LRA does not need this). If it affects, I'll find why and
