Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On 01/27/2013 03:16 AM, David Edelsohn wrote:
On Fri, Jan 25, 2013 at 8:55 AM, Michael Haubenwallner
michael.haubenwall...@salomon.at wrote:
Same here, building everything out-of-source. The prerequisites used are:
* CONFIG_SHELL=/usr/local/bin/bash 4.1.7 from bullfreeware (symlinks to
/opt/freeware/bin/)
* /usr/bin/{gcc,g++} 4.6.1 from bullfreeware (symlinks to /opt/freeware/bin/)
* /usr/bin/gmake 3.82 from bullfreeware (symlinks to /opt/freeware/bin/)
* gmp-5.0.4: as shared library, configured with --prefix=/prereq ABI=32
* mpfr-3.1.1: as shared library, configured with --prefix=/prereq
--with-gmp=/prereq
* mpfr-3.1.1: as shared library, configured with --prefix=/prereq
--with-{gmp,mpfr}=/prereq
* gawk-3.1.7, flex-2.5.35, m4-1.4.13 from some Gentoo Prefix instance,
nowhere in PATH,
thus: export {AWK,FLEX}=/gentoo/prefix/usr/bin/{awk,flex} and this patch:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00960.html
For gcc:
* $CONFIG_SHELL configure --prefix=/does/not/exist/yet
--with-{gmp,mpfr,mpc}=/prereq \
--enable--languages=c,c++ --disable-werror --disable-nls
* gmake bootstrap
I committed your patch.
Thank you!
But still curious if you've been able to reproduce the problem,
and why you didn't encounter this problem beforehand.
By the way, NLS works if you build and install GNU libiconv (1.14) and
add --with-libiconv-prefix=/prereq to force GCC bootstrap to use GNU
libiconv instead of AIX libiconv.
Yes, but (you've asked) here is this situation I don't want to configure extra
deplib-prefixes
for (remember bullfreeware is listed as provider for gcc-binaries):
* bullfreeware's libiconv-1.13.1 and gettext-0.17 is installed in /opt/freeware,
* /usr/lib/libintl.a is symlinked to /opt/freeware/lib (by bullfreeware's RPM),
* /usr/lib/libiconv.a is the original AIX' one.
Now, /usr/lib/libintl.a needs /opt/freeware/lib/libiconv.a[libiconv.so.2], and
it does
contain the correct RUNPATH. But subsequent binaries linking against
/usr/lib/libintl.a
don't (necessarily) know about the need to add /opt/freeware/lib as RUNPATH, so
these
binaries break with libiconv.so.2 not being found as member of
/usr/lib/libiconv.a, because
AIX unfortunately does stop its shared-library search at the first archive
filename found.
This also is the main reason for my filename-based-shared-library-versioning
thing.
While this topic is related, it has different reasoning - but the result does
work:
[1] http://www.perzl.org/aix/index.php?n=FAQs.FAQs#toolbox-compatibility-issue
/haubi/
RFA: RL78: Allow SP to be used as a base register
Hi DJ,
Please may I apply the patch below. It fixes the RL78 backend so that
the stack register can be used as a base address register.
Tested with no regressions on an rl78-elf toolchain.
Cheers
Nick
PS. I am currently investigating allow r8-r15 to be used as base
registers.
gcc/ChangeLog
2013-01-28 Nick Clifton ni...@redhat.com
* config/rl78/rl78.c (rl78_regno_mode_code_ok_for_base_p): Allow
SP_REG.
Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c (revision 195461)
+++ gcc/config/rl78/rl78.c (working copy)
@@ -769,7 +769,7 @@
addr_space_t address_space ATTRIBUTE_UNUSED,
int outer_code ATTRIBUTE_UNUSED, int
index_code)
{
- if (regno 24 regno = 16)
+ if (regno = SP_REG regno = 16)
return true;
if (index_code == REG)
return (regno == HL_REG);
Re: [Patch] Fix PR54814
On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com wrote: On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote: The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 Ironically, this revision fixes a reload problem on x86/x86_64 -- which doesn't use reload anymore now... Does this mean the fix is rejected for 4.8? No, just that it probably helps to add a RM to the CC list. FWIW, it seems to me that this patch should go into 4.8, because the bug is probably not limited to AVR. Indeed, the fix also looks quite obvious though I know nothing about the code at all. Thus, ok from a RM perspective if a reload-affine person approves it. Thanks, Richard. Ciao! Steven
Re: Cortex-A15 vfnma/vfnms test patch
[Taking gcc-help off this thread.] Amol, I have tested these instruction with GCC and these instructions are generated. Please review and marge this test support patch in gcc main trunk. Thanks for this patch and sorry about the delay in getting around to this. This is ok and I'll take this under the 10 line rule this time . If you intend to continue to submit patches to gcc can I ask that you start the process for copyright assignments or confirm that you have a copyright assignment on file ? http://gcc.gnu.org/contribute.html#legal If you don't, send an email to g...@gcc.gnu.org with a request for copyright assignment papers and a maintainer will send you these. http://gcc.gnu.org/contribute.html in general is a good summary of the process related to contributing patches to GCC in general . Please do read that and follow up on g...@gcc.gnu.org if you have any more questions. And finally don't forget to add a changelog to your patches as documented in links from the above mentioned page. Since this is your first time I've added the following Changelog entry for your patch and applied it. regards Ramana 2013-01-27 Amol Pise amolpis...@gmail.com * gcc.target/arm/neon-vfnms-1.c: New test. * gcc.target/arm/neon-vfnma-1.c: New test.
Re: [avr,committed] Fix fixed-point conversion
Gerald Pfeifer wrote:
On Thu, 24 Jan 2013, Georg-Johann Lay wrote:
Committed the following change:
http://gcc.gnu.org/r195424
* config/avr/avr.c (avr_out_fract): Make register numbers that
might be outside of source operand signed.
Can you still post patches to the list, and not just the reference?
Thanks,
Gerald
Thinks for pointing this out. I will follow the guideline in the future.
Here is the change:
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 195423)
+++ config/avr/avr.c(revision 195424)
@@ -7114,13 +7114,13 @@ avr_out_fract (rtx insn, rtx operands[],
unsigned d1 = d0 + step;
// Current and next regno of source
- unsigned s0 = d0 - offset;
- unsigned s1 = s0 + step;
+ signed s0 = d0 - offset;
+ signed s1 = s0 + step;
// Must current resp. next regno be CLRed? This applies to the low
// bytes of the destination that have no associated source bytes.
- bool clr0 = s0 src.regno;
- bool clr1 = s1 src.regno d1 = dest.regno;
+ bool clr0 = s0 (signed) src.regno;
+ bool clr1 = s1 (signed) src.regno d1 = dest.regno;
// First gather what code to emit (if any) and additional step to
// apply if a MOVW is in use. xop[2] is destination rtx and xop[3]
@@ -7150,12 +7150,12 @@ avr_out_fract (rtx insn, rtx operands[],
}
}
}
- else if (offset s0 = src.regno_msb)
+ else if (offset s0 = (signed) src.regno_msb)
{
int movw = AVR_HAVE_MOVW offset % 2 == 0
d0 % 2 == (offset 0)
d1 = dest.regno_msb d1 = dest.regno
- s1 = src.regno_msb s1 = src.regno;
+ s1 = (signed) src.regno_msb s1 = (signed) src.regno;
xop[2] = all_regs_rtx[d0 ~movw];
xop[3] = all_regs_rtx[s0 ~movw];
Re: [Patch] Fix PR54814
Richard Biener wrote: On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com wrote: On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote: The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 Ironically, this revision fixes a reload problem on x86/x86_64 -- which doesn't use reload anymore now... Does this mean the fix is rejected for 4.8? No, just that it probably helps to add a RM to the CC list. FWIW, it seems to me that this patch should go into 4.8, because the bug is probably not limited to AVR. Indeed, the fix also looks quite obvious though I know nothing about the code at all. Thus, ok from a RM perspective if a reload-affine person approves it. The patch was originally by Bernd, but FWIW it looks good to me as well. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
[PATCH] Fix sched ICE with prefetch (PR rtl-optimization/56117)
Hi!
We ICE on the following testcase when using cselib, because
cselib_lookup* is never called on the PREFETCH argument, and
add_insn_mem_dependence calls cselib_subst_to_values on it, which
assumes cselib_lookup* already happened on it earlier.
For MEMs sched_analyze_2 calls cselib_lookup_from_insn, but for PREFETCHes
it didn't.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2013-01-28 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/56117
* sched-deps.c (sched_analyze_2) case PREFETCH: For use_cselib
call cselib_lookup_from_insn on the MEM before calling
add_insn_mem_dependence.
* gcc.dg/pr56117.c: New test.
--- gcc/sched-deps.c.jj 2013-01-16 19:58:42.0 +0100
+++ gcc/sched-deps.c2013-01-28 09:43:33.248657691 +0100
@@ -2720,8 +2720,12 @@ sched_analyze_2 (struct deps_desc *deps,
prefetch has only the start address but it is better to have
something than nothing. */
if (!deps-readonly)
- add_insn_mem_dependence (deps, true, insn,
-gen_rtx_MEM (Pmode, XEXP (PATTERN (insn), 0)));
+ {
+ rtx x = gen_rtx_MEM (Pmode, XEXP (PATTERN (insn), 0));
+ if (sched_deps_info-use_cselib)
+ cselib_lookup_from_insn (x, Pmode, true, VOIDmode, insn);
+ add_insn_mem_dependence (deps, true, insn, x);
+ }
break;
case UNSPEC_VOLATILE:
--- gcc/testsuite/gcc.dg/pr56117.c.jj 2013-01-28 09:47:21.244381559 +0100
+++ gcc/testsuite/gcc.dg/pr56117.c 2013-01-28 09:46:31.0 +0100
@@ -0,0 +1,9 @@
+/* PR rtl-optimization/56117 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fsched2-use-superblocks } */
+
+void
+foo (void *p)
+{
+ __builtin_prefetch (p);
+}
Jakub
[PATCH][RFC] Avoid excessive BLOCK associations for locations
This avoids assigning BLOCKs to things that didn't have one before
(originally I observed that the code snippets below happily generate
a UNKNOWN_LOCATION, id-block association). A previous patch last
year changed expansion in a way to not jump back to the outermost
block when observing a NULL LOCATION_BLOCK in the IL, but similar
to UNKNOWN_LOCATION locus handling just inherit the currently active
BLOCK. Thus the patch below, instead of just avoiding the non-sensical
UNKNOWN_LOCATION, id-block association goes one step further and
never puts things in the outermost inline BLOCK if it didn't have
a BLOCK assigned before. This avoids the original non-sensical
issue and avoids excessive BLOCK associations where they are of not
much use.
What's the point of switching to the outermost scope for unknown-BLOCK
locations? Isn't inheriting the currently active scope much more
useful (it definitely is for UNKNOWN_LOCATIONs)? If we have a
non-UNKNOWN_LOCATION, would a NULL BLOCK not be an error anyway?
An error we hide in the current scheme?
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Does this make sense?
Thanks,
Richard.
2013-01-28 Richard Biener rguent...@suse.de
* tree-inline.c (remap_gimple_stmt): Do not assing a BLOCK
to a stmt that didn't have one.
(copy_phis_for_bb): Likewise for PHI arguments.
(copy_debug_stmt): Likewise for debug stmts.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 195502)
+++ gcc/tree-inline.c (working copy)
@@ -1198,7 +1198,6 @@ remap_gimple_stmt (gimple stmt, copy_bod
{
gimple copy = NULL;
struct walk_stmt_info wi;
- tree new_block;
bool skip_first = false;
/* Begin by recognizing trees that we'll completely rewrite for the
@@ -1458,19 +1457,15 @@ remap_gimple_stmt (gimple stmt, copy_bod
}
/* If STMT has a block defined, map it to the newly constructed
- block. When inlining we want statements without a block to
- appear in the block of the function call. */
- new_block = id-block;
+ block. */
if (gimple_block (copy))
{
tree *n;
n = (tree *) pointer_map_contains (id-decl_map, gimple_block (copy));
gcc_assert (n);
- new_block = *n;
+ gimple_set_block (copy, *n);
}
- gimple_set_block (copy, new_block);
-
if (gimple_debug_bind_p (copy) || gimple_debug_source_bind_p (copy))
return copy;
@@ -1987,7 +1982,6 @@ copy_phis_for_bb (basic_block bb, copy_b
edge old_edge = find_edge ((basic_block) new_edge-src-aux, bb);
tree arg;
tree new_arg;
- tree block = id-block;
edge_iterator ei2;
location_t locus;
@@ -2015,19 +2009,18 @@ copy_phis_for_bb (basic_block bb, copy_b
inserted = true;
}
locus = gimple_phi_arg_location_from_edge (phi, old_edge);
- block = id-block;
if (LOCATION_BLOCK (locus))
{
tree *n;
n = (tree *) pointer_map_contains (id-decl_map,
LOCATION_BLOCK (locus));
gcc_assert (n);
- block = *n;
+ locus = COMBINE_LOCATION_DATA (line_table, locus, *n);
}
+ else
+ locus = LOCATION_LOCUS (locus);
- add_phi_arg (new_phi, new_arg, new_edge, block ?
- COMBINE_LOCATION_DATA (line_table, locus, block) :
- LOCATION_LOCUS (locus));
+ add_phi_arg (new_phi, new_arg, new_edge, locus);
}
}
}
@@ -2324,14 +2317,11 @@ copy_debug_stmt (gimple stmt, copy_body_
tree t, *n;
struct walk_stmt_info wi;
- t = id-block;
if (gimple_block (stmt))
{
n = (tree *) pointer_map_contains (id-decl_map, gimple_block (stmt));
- if (n)
- t = *n;
+ gimple_set_block (stmt, n ? *n : id-block);
}
- gimple_set_block (stmt, t);
/* Remap all the operands in COPY. */
memset (wi, 0, sizeof (wi));
[committed] Avoid setting gimple_location of force_gimple_operand* created stmts to DECL_SOURCE_LOCATION of current fn (PR tree-optimization/56094)
Hi!
As discussed in the PR, this is a safer variant of a fix for 4.8, where
input_location during most optimization passes is set to
DECL_SOURCE_LOCATION (current_function_decl) and various parts of the
gimplifier e.g. during force_gimple_operand* may end up setting
gimple_location to that. For 4.9, we should revert this and set
input_location to UNKNOWN_LOCATION for the optimizers.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56094
* gimplify.c (force_gimple_operand_1): Temporarily set input_location
to UNKNOWN_LOCATION while gimplifying expr.
* gcc.dg/pr56094.c: New test.
--- gcc/gimplify.c.jj 2013-01-25 21:02:45.0 +0100
+++ gcc/gimplify.c 2013-01-28 11:34:15.671374132 +0100
@@ -8600,6 +8600,7 @@ force_gimple_operand_1 (tree expr, gimpl
{
enum gimplify_status ret;
struct gimplify_ctx gctx;
+ location_t saved_location;
*stmts = NULL;
@@ -8613,6 +8614,8 @@ force_gimple_operand_1 (tree expr, gimpl
push_gimplify_context (gctx);
gimplify_ctxp-into_ssa = gimple_in_ssa_p (cfun);
gimplify_ctxp-allow_rhs_cond_expr = true;
+ saved_location = input_location;
+ input_location = UNKNOWN_LOCATION;
if (var)
{
@@ -8634,6 +8637,7 @@ force_gimple_operand_1 (tree expr, gimpl
gcc_assert (ret != GS_ERROR);
}
+ input_location = saved_location;
pop_gimplify_context (NULL);
return expr;
--- gcc/testsuite/gcc.dg/pr56094.c.jj 2013-01-28 11:46:09.045221238 +0100
+++ gcc/testsuite/gcc.dg/pr56094.c 2013-01-28 11:47:54.052611852 +0100
@@ -0,0 +1,81 @@
+/* PR tree-optimization/56094 */
+/* { dg-do compile } */
+/* { dg-options -O2 -g -fdump-tree-optimized-lineno } */
+
+_Bool cond;
+
+int
+fn0 (unsigned char, unsigned long long, unsigned char,
+ unsigned char, signed short, unsigned int,
+ unsigned char *);
+
+extern void fn3 (unsigned char, unsigned char, unsigned char, unsigned char,
+unsigned char, unsigned char, unsigned char, unsigned short);
+extern void fn7 (int);
+extern void fn8 (int);
+
+static __inline__ __attribute__ ((always_inline)) void
+fn1 (unsigned char arg0, unsigned char arg1, unsigned char arg2,
+ unsigned char arg3, unsigned char arg4, unsigned char arg5,
+ unsigned short arg6)
+{
+ asm volatile ( :: g ((unsigned long long) arg0), g (arg1),
+ g (arg2), g (arg3), g (arg4), g (arg5),
+ g (arg6));
+ if (cond)
+{
+ unsigned char loc0 = 0;
+ fn3 (loc0, arg0, arg1, arg2, arg3, arg4, arg5, arg6);
+}
+}
+
+static __inline__ __attribute__ ((always_inline)) void
+fn4 (unsigned int arg0, unsigned long long arg1)
+{
+ asm volatile ( :: g (arg0), g (arg1));
+}
+
+static __inline__ __attribute__ ((always_inline)) void
+fn5 (unsigned int arg0, unsigned char arg1, unsigned int arg2,
+ unsigned char arg3)
+{
+ asm volatile ( :: g (arg0), g (arg1),
+ g ((unsigned long long) arg2), g (arg3));
+}
+
+static __inline__ __attribute__ ((always_inline)) void
+fn6 (unsigned long long arg0, unsigned char arg1,
+ unsigned char arg2, signed short arg3,
+ unsigned int arg4, unsigned char * arg5)
+{
+ asm volatile ( :: g (arg0), g ((unsigned long long) arg1),
+ g ((unsigned long long) arg2), g (arg3),
+ g (arg4), g (arg5));
+ if (cond)
+{
+ unsigned char loc0 = 0;
+ fn0 (loc0, arg0, arg1, arg2, arg3, arg4, arg5);
+}
+}
+
+unsigned char b[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xa };
+unsigned int q = sizeof (b) / sizeof (b[0]);
+
+void
+foo ()
+{
+ int i;
+ for (i = 1; i = 50; i++)
+{
+ fn6 (i + 0x1234, i + 1, i + 0xa, i + 0x1234, q, b);
+ fn5 (i + 0xabcd, i 1, i + 0x1234, i 2);
+ fn7 (i + 0xdead);
+ fn8 (i + 0xdead);
+ fn1 (i, i + 1, i + 2, i + 3, i + 4, i + 5, i 10);
+ fn4 (i + 0xfeed, i);
+}
+}
+
+/* Verify no statements get the location of the foo () decl. */
+/* { dg-final { scan-tree-dump-not : 65:1\\\] optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */
Jakub
[PATCH] Fix up pow folding (PR tree-optimization/56125)
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
correct for c which isn't an integer (otherwise the sqrt(x) factor would
need to be skipped), but they actually do not check this.
E.g. the pow (x, n) where n is integer is optimized only if:
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
powi_cost (n) = POWI_MAX_MULTS)))
and as in the testcase the function is called, it isn't optimized and
we fall through till the above mentioned optimization which blindly assumes
that c isn't an integer.
Fixed by both checking that c isn't an integer (and for the last
optimization also that 2c isn't an integer), and also not doing the
- sqrt(x) * powi(x, n / 2) resp. 1.0 / sqrt(x) * powi(x, abs(n) / 2)
optimization for -Os or cold functions, at least
__attribute__((cold)) double
foo (double x, double n)
{
return __builtin_pow (x, -1.5);
}
is smaller when expanded as pow call both on x86_64 and on powerpc (with
-Os -ffast-math). Even just the c*_is_int tests alone could be enough
to fix the bug, so if you say want to enable it for -Os even with c 1.5,
but not for negative values which add another operation, it can be adjusted.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
pow(x,c) into sqrt(x) * powi(x, n/2) or
1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when
optimizing for size.
Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or
1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an
integer.
* gcc.dg/pr56125.c: New test.
--- gcc/tree-ssa-math-opts.c.jj 2013-01-11 09:02:48.0 +0100
+++ gcc/tree-ssa-math-opts.c2013-01-28 10:56:40.105950483 +0100
@@ -1110,7 +1110,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
HOST_WIDE_INT n;
tree type, sqrtfn, cbrtfn, sqrt_arg0, sqrt_sqrt, result, cbrt_x, powi_cbrt_x;
enum machine_mode mode;
- bool hw_sqrt_exists;
+ bool hw_sqrt_exists, c_is_int, c2_is_int;
/* If the exponent isn't a constant, there's nothing of interest
to be done. */
@@ -1122,8 +1122,9 @@ gimple_expand_builtin_pow (gimple_stmt_i
c = TREE_REAL_CST (arg1);
n = real_to_integer (c);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c_is_int = real_identical (c, cint);
- if (real_identical (c, cint)
+ if (c_is_int
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
@@ -1221,7 +1222,8 @@ gimple_expand_builtin_pow (gimple_stmt_i
return build_and_insert_call (gsi, loc, cbrtfn, sqrt_arg0);
}
- /* Optimize pow(x,c), where n = 2c for some nonzero integer n, into
+ /* Optimize pow(x,c), where n = 2c for some nonzero integer n
+ and c not an integer, into
sqrt(x) * powi(x, n/2),n 0;
1.0 / (sqrt(x) * powi(x, abs(n/2))), n 0.
@@ -1230,10 +1232,13 @@ gimple_expand_builtin_pow (gimple_stmt_i
real_arithmetic (c2, MULT_EXPR, c, dconst2);
n = real_to_integer (c2);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c2_is_int = real_identical (c2, cint);
if (flag_unsafe_math_optimizations
sqrtfn
- real_identical (c2, cint))
+ c2_is_int
+ !c_is_int
+ optimize_function_for_speed_p (cfun))
{
tree powi_x_ndiv2 = NULL_TREE;
@@ -1286,6 +1291,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
cbrtfn
(gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
real_identical (c2, c)
+ !c2_is_int
optimize_function_for_speed_p (cfun)
powi_cost (n / 3) = POWI_MAX_MULTS)
{
--- gcc/testsuite/gcc.dg/pr56125.c.jj 2013-01-28 11:00:04.359814742 +0100
+++ gcc/testsuite/gcc.dg/pr56125.c 2013-01-28 11:00:55.048532118 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/56125 */
+/* { dg-do run } */
+/* { dg-options -O2 -ffast-math } */
+
+extern void abort (void);
+extern double fabs (double);
+
+__attribute__((cold)) double
+foo (double x, double n)
+{
+ double u = x / (n * n);
+ return u;
+}
+
+int
+main ()
+{
+ if (fabs (foo (29, 2) - 7.25) 0.001)
+abort ();
+ return 0;
+}
Jakub
[committed] Avoid string.h includes in -fno-builtin-memset testcases (PR testsuite/56053)
Hi!
Some targets apparently force fortification unconditionally or at least by
default, when string.h is then included, memset etc. inlines might call
__builtin_memset or __builtin___memset_chk directly and for explicit builtin
uses -fno-builtin* doesn't work. Fixed by avoiding those includes and
instead adding needed prototypes by hand, tested on x86_64-linux, committed
as obvious to trunk.
2013-01-28 Jakub Jelinek ja...@redhat.com
PR testsuite/56053
* c-c++-common/asan/heap-overflow-1.c: Don't include stdlib.h and
string.h. Provide memset, malloc and free prototypes, adjust line
numbers in dg-output.
* c-c++-common/asan/stack-overflow-1.c: Don't include string.h.
Provide memset prototype and adjust line numbers in dg-output.
* c-c++-common/asan/global-overflow-1.c: Likewise.
--- gcc/testsuite/c-c++-common/asan/heap-overflow-1.c.jj2012-12-13
00:02:50.0 +0100
+++ gcc/testsuite/c-c++-common/asan/heap-overflow-1.c 2013-01-28
13:47:58.682416114 +0100
@@ -2,8 +2,18 @@
/* { dg-options -fno-builtin-malloc -fno-builtin-free -fno-builtin-memset }
*/
/* { dg-shouldfail asan } */
-#include stdlib.h
-#include string.h
+#ifdef __cplusplus
+extern C {
+#endif
+
+void *memset (void *, int, __SIZE_TYPE__);
+void *malloc (__SIZE_TYPE__);
+void free (void *);
+
+#ifdef __cplusplus
+}
+#endif
+
volatile int ten = 10;
int main(int argc, char **argv) {
char *x = (char*)malloc(10);
@@ -14,8 +24,8 @@ int main(int argc, char **argv) {
}
/* { dg-output READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r) } */
-/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*heap-overflow-1.c:11|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r) } */
+/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*heap-overflow-1.c:21|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r) } */
/* { dg-output 0x\[0-9a-f\]+ is located 0 bytes to the right of 10-byte
region\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output allocated by thread T0 here:\[^\n\r]*(\n|\r\n|\r) } */
/* { dg-output #0 0x\[0-9a-f\]+ (in
_*(interceptor_|)malloc|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
-/* { dg-output #1 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*heap-overflow-1.c:9|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
+/* { dg-output #1 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*heap-overflow-1.c:19|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r) } */
--- gcc/testsuite/c-c++-common/asan/stack-overflow-1.c.jj 2012-12-13
00:02:50.0 +0100
+++ gcc/testsuite/c-c++-common/asan/stack-overflow-1.c 2013-01-28
13:48:41.046171347 +0100
@@ -2,9 +2,13 @@
/* { dg-options -fno-builtin-memset } */
/* { dg-shouldfail asan } */
-volatile int ten = 10;
+extern
+#ifdef __cplusplus
+C
+#endif
+void *memset (void *, int, __SIZE_TYPE__);
-#include string.h
+volatile int ten = 10;
int main() {
char x[10];
@@ -14,5 +18,5 @@ int main() {
}
/* { dg-output READ of size 1 at 0x\[0-9a-f\]+ thread
T0\[^\n\r]*(\n|\r\n|\r) } */
-/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*stack-overflow-1.c:12|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r) } */
+/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*stack-overflow-1.c:16|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r) } */
/* { dg-output Address 0x\[0-9a-f\]+ is\[^\n\r]*frame main } */
--- gcc/testsuite/c-c++-common/asan/global-overflow-1.c.jj 2012-12-13
00:02:50.0 +0100
+++ gcc/testsuite/c-c++-common/asan/global-overflow-1.c 2013-01-28
13:46:13.900017787 +0100
@@ -2,7 +2,12 @@
/* { dg-options -fno-builtin-memset } */
/* { dg-shouldfail asan } */
-#include string.h
+extern
+#ifdef __cplusplus
+C
+#endif
+void *memset (void *, int, __SIZE_TYPE__);
+
volatile int ten = 10;
int main() {
@@ -18,6 +23,6 @@ int main() {
}
/* { dg-output READ of size 1 at 0x\[0-9a-f\]+ thread T0.*(\n|\r\n|\r) } */
-/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*global-overflow-1.c:15|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r).* }
*/
+/* { dg-output #0 0x\[0-9a-f\]+ (in _*main
(\[^\n\r]*global-overflow-1.c:20|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r).* }
*/
/* { dg-output 0x\[0-9a-f\]+ is located 0 bytes to the right of global
variable } */
/* { dg-output .*YYY\[^\n\r]* of size 10\[^\n\r]*(\n|\r\n|\r) } */
Jakub
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
correct for c which isn't an integer (otherwise the sqrt(x) factor would
need to be skipped), but they actually do not check this.
E.g. the pow (x, n) where n is integer is optimized only if:
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
powi_cost (n) = POWI_MAX_MULTS)))
and as in the testcase the function is called, it isn't optimized and
we fall through till the above mentioned optimization which blindly assumes
that c isn't an integer.
Fixed by both checking that c isn't an integer (and for the last
optimization also that 2c isn't an integer), and also not doing the
- sqrt(x) * powi(x, n / 2) resp. 1.0 / sqrt(x) * powi(x, abs(n) / 2)
optimization for -Os or cold functions, at least
__attribute__((cold)) double
foo (double x, double n)
{
return __builtin_pow (x, -1.5);
}
is smaller when expanded as pow call both on x86_64 and on powerpc (with
-Os -ffast-math). Even just the c*_is_int tests alone could be enough
to fix the bug, so if you say want to enable it for -Os even with c 1.5,
but not for negative values which add another operation, it can be adjusted.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
pow(x,c) into sqrt(x) * powi(x, n/2) or
1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when
optimizing for size.
Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or
1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an
integer.
* gcc.dg/pr56125.c: New test.
--- gcc/tree-ssa-math-opts.c.jj 2013-01-11 09:02:48.0 +0100
+++ gcc/tree-ssa-math-opts.c 2013-01-28 10:56:40.105950483 +0100
@@ -1110,7 +1110,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
HOST_WIDE_INT n;
tree type, sqrtfn, cbrtfn, sqrt_arg0, sqrt_sqrt, result, cbrt_x,
powi_cbrt_x;
enum machine_mode mode;
- bool hw_sqrt_exists;
+ bool hw_sqrt_exists, c_is_int, c2_is_int;
/* If the exponent isn't a constant, there's nothing of interest
to be done. */
@@ -1122,8 +1122,9 @@ gimple_expand_builtin_pow (gimple_stmt_i
c = TREE_REAL_CST (arg1);
n = real_to_integer (c);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c_is_int = real_identical (c, cint);
- if (real_identical (c, cint)
+ if (c_is_int
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
@@ -1221,7 +1222,8 @@ gimple_expand_builtin_pow (gimple_stmt_i
return build_and_insert_call (gsi, loc, cbrtfn, sqrt_arg0);
}
- /* Optimize pow(x,c), where n = 2c for some nonzero integer n, into
+ /* Optimize pow(x,c), where n = 2c for some nonzero integer n
+ and c not an integer, into
sqrt(x) * powi(x, n/2),n 0;
1.0 / (sqrt(x) * powi(x, abs(n/2))), n 0.
@@ -1230,10 +1232,13 @@ gimple_expand_builtin_pow (gimple_stmt_i
real_arithmetic (c2, MULT_EXPR, c, dconst2);
n = real_to_integer (c2);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c2_is_int = real_identical (c2, cint);
if (flag_unsafe_math_optimizations
sqrtfn
- real_identical (c2, cint))
+ c2_is_int
+ !c_is_int
+ optimize_function_for_speed_p (cfun))
{
tree powi_x_ndiv2 = NULL_TREE;
@@ -1286,6 +1291,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
cbrtfn
(gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
real_identical (c2, c)
+ !c2_is_int
optimize_function_for_speed_p (cfun)
powi_cost (n / 3) = POWI_MAX_MULTS)
{
--- gcc/testsuite/gcc.dg/pr56125.c.jj 2013-01-28 11:00:04.359814742 +0100
+++ gcc/testsuite/gcc.dg/pr56125.c2013-01-28 11:00:55.048532118 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/56125 */
+/* { dg-do run } */
+/* { dg-options -O2 -ffast-math } */
+
+extern void abort (void);
+extern double fabs (double);
+
+__attribute__((cold)) double
+foo (double x, double n)
+{
+ double u = x / (n * n);
+ return u;
+}
+
+int
+main ()
+{
+ if (fabs (foo (29, 2) - 7.25) 0.001)
+abort ();
+ return 0;
+}
Jakub
--
Richard Biener rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: [PATCH][RFC] Avoid excessive BLOCK associations for locations
On Mon, Jan 28, 2013 at 03:15:53PM +0100, Richard Biener wrote: Does this make sense? Yes. Wouldn't hurt to run GDB testsuite with that, though I bet most of it is -O0 anyway and thus won't stress it out too much. 2013-01-28 Richard Biener rguent...@suse.de * tree-inline.c (remap_gimple_stmt): Do not assing a BLOCK to a stmt that didn't have one. (copy_phis_for_bb): Likewise for PHI arguments. (copy_debug_stmt): Likewise for debug stmts. Ok. Jakub
[PATCH] Fix PR56034
The following implements what I thought was present (eh ...). For
partitions that contain reductions (feed loop closed PHI nodes) we
rely on them being in the last partition of the loop - as we do not
bother to copy / care for loop closed PHI nodes. The following now
implements that fully (I've had a patch for that around), by both
seeding initial partition generation from scalar reductions and
taking care of merging them again into the very last partition of
the loop.
Completely disabling partitioning for loops with reductions would
have broken some existing testcases that happen to work because
for them the partitions are already in proper order.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-01-28 Richard Biener rguent...@suse.de
PR tree-optimization/56034
* tree-loop-distribution.c (enum partition_kind): Add
PKIND_REDUCTION.
(partition_builtin_p): Adjust.
(generate_code_for_partition): Handle PKIND_REDUCTION. Assert
it is the last partition.
(rdg_flag_uses): Check SSA_NAME_IS_DEFAULT_DEF before looking
up the vertex for the definition.
(classify_partition): Classify whether a partition is a
PKIND_REDUCTION, thus has uses outside of the loop.
(ldist_gen): Inherit PKIND_REDUCTION when merging partitions.
Merge all PKIND_REDUCTION partitions into the last partition.
(tree_loop_distribution): Seed partitions from reductions as well.
* gcc.dg/torture/pr56034.c: New testcase.
Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c(revision 195502)
--- gcc/tree-loop-distribution.c(working copy)
*** along with GCC; see the file COPYING3.
*** 51,57
#include tree-scalar-evolution.h
#include tree-pass.h
! enum partition_kind { PKIND_NORMAL, PKIND_MEMSET, PKIND_MEMCPY };
typedef struct partition_s
{
--- 51,59
#include tree-scalar-evolution.h
#include tree-pass.h
! enum partition_kind {
! PKIND_NORMAL, PKIND_REDUCTION, PKIND_MEMSET, PKIND_MEMCPY
! };
typedef struct partition_s
{
*** partition_free (partition_t partition)
*** 90,96
static bool
partition_builtin_p (partition_t partition)
{
! return partition-kind != PKIND_NORMAL;
}
/* Returns true if the partition has an writes. */
--- 92,98
static bool
partition_builtin_p (partition_t partition)
{
! return partition-kind PKIND_REDUCTION;
}
/* Returns true if the partition has an writes. */
*** generate_code_for_partition (struct loop
*** 481,486
--- 483,491
destroy_loop (loop);
break;
+ case PKIND_REDUCTION:
+ /* Reductions all have to be in the last partition. */
+ gcc_assert (!copy_p);
case PKIND_NORMAL:
generate_loops_for_partition (loop, partition, copy_p);
break;
*** rdg_flag_uses (struct graph *rdg, int u,
*** 628,634
{
tree use = USE_FROM_PTR (use_p);
! if (TREE_CODE (use) == SSA_NAME)
{
gimple def_stmt = SSA_NAME_DEF_STMT (use);
int v = rdg_vertex_for_stmt (rdg, def_stmt);
--- 633,640
{
tree use = USE_FROM_PTR (use_p);
! if (TREE_CODE (use) == SSA_NAME
! !SSA_NAME_IS_DEFAULT_DEF (use))
{
gimple def_stmt = SSA_NAME_DEF_STMT (use);
int v = rdg_vertex_for_stmt (rdg, def_stmt);
*** classify_partition (loop_p loop, struct
*** 858,882
unsigned i;
tree nb_iter;
data_reference_p single_load, single_store;
partition-kind = PKIND_NORMAL;
partition-main_dr = NULL;
partition-secondary_dr = NULL;
- if (!flag_tree_loop_distribute_patterns)
- return;
-
- /* Perform general partition disqualification for builtins. */
- nb_iter = number_of_exit_cond_executions (loop);
- if (!nb_iter || nb_iter == chrec_dont_know)
- return;
-
EXECUTE_IF_SET_IN_BITMAP (partition-stmts, 0, i, bi)
{
gimple stmt = RDG_STMT (rdg, i);
if (gimple_has_volatile_ops (stmt))
! return;
/* If the stmt has uses outside of the loop fail.
??? If the stmt is generated in another partition that
--- 864,881
unsigned i;
tree nb_iter;
data_reference_p single_load, single_store;
+ bool volatiles_p = false;
partition-kind = PKIND_NORMAL;
partition-main_dr = NULL;
partition-secondary_dr = NULL;
EXECUTE_IF_SET_IN_BITMAP (partition-stmts, 0, i, bi)
{
gimple stmt = RDG_STMT (rdg, i);
if (gimple_has_volatile_ops (stmt))
! volatiles_p = true;
/* If the stmt has uses outside of the loop fail.
??? If the stmt is generated in another partition that
*** classify_partition (loop_p loop, struct
***
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
LGTM! Thanks for fixing this.
Bill
On Mon, 2013-01-28 at 15:25 +0100, Jakub Jelinek wrote:
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
correct for c which isn't an integer (otherwise the sqrt(x) factor would
need to be skipped), but they actually do not check this.
E.g. the pow (x, n) where n is integer is optimized only if:
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
powi_cost (n) = POWI_MAX_MULTS)))
and as in the testcase the function is called, it isn't optimized and
we fall through till the above mentioned optimization which blindly assumes
that c isn't an integer.
Fixed by both checking that c isn't an integer (and for the last
optimization also that 2c isn't an integer), and also not doing the
- sqrt(x) * powi(x, n / 2) resp. 1.0 / sqrt(x) * powi(x, abs(n) / 2)
optimization for -Os or cold functions, at least
__attribute__((cold)) double
foo (double x, double n)
{
return __builtin_pow (x, -1.5);
}
is smaller when expanded as pow call both on x86_64 and on powerpc (with
-Os -ffast-math). Even just the c*_is_int tests alone could be enough
to fix the bug, so if you say want to enable it for -Os even with c 1.5,
but not for negative values which add another operation, it can be adjusted.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
pow(x,c) into sqrt(x) * powi(x, n/2) or
1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when
optimizing for size.
Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or
1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an
integer.
* gcc.dg/pr56125.c: New test.
--- gcc/tree-ssa-math-opts.c.jj 2013-01-11 09:02:48.0 +0100
+++ gcc/tree-ssa-math-opts.c 2013-01-28 10:56:40.105950483 +0100
@@ -1110,7 +1110,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
HOST_WIDE_INT n;
tree type, sqrtfn, cbrtfn, sqrt_arg0, sqrt_sqrt, result, cbrt_x,
powi_cbrt_x;
enum machine_mode mode;
- bool hw_sqrt_exists;
+ bool hw_sqrt_exists, c_is_int, c2_is_int;
/* If the exponent isn't a constant, there's nothing of interest
to be done. */
@@ -1122,8 +1122,9 @@ gimple_expand_builtin_pow (gimple_stmt_i
c = TREE_REAL_CST (arg1);
n = real_to_integer (c);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c_is_int = real_identical (c, cint);
- if (real_identical (c, cint)
+ if (c_is_int
((n = -1 n = 2)
|| (flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
@@ -1221,7 +1222,8 @@ gimple_expand_builtin_pow (gimple_stmt_i
return build_and_insert_call (gsi, loc, cbrtfn, sqrt_arg0);
}
- /* Optimize pow(x,c), where n = 2c for some nonzero integer n, into
+ /* Optimize pow(x,c), where n = 2c for some nonzero integer n
+ and c not an integer, into
sqrt(x) * powi(x, n/2),n 0;
1.0 / (sqrt(x) * powi(x, abs(n/2))), n 0.
@@ -1230,10 +1232,13 @@ gimple_expand_builtin_pow (gimple_stmt_i
real_arithmetic (c2, MULT_EXPR, c, dconst2);
n = real_to_integer (c2);
real_from_integer (cint, VOIDmode, n, n 0 ? -1 : 0, 0);
+ c2_is_int = real_identical (c2, cint);
if (flag_unsafe_math_optimizations
sqrtfn
- real_identical (c2, cint))
+ c2_is_int
+ !c_is_int
+ optimize_function_for_speed_p (cfun))
{
tree powi_x_ndiv2 = NULL_TREE;
@@ -1286,6 +1291,7 @@ gimple_expand_builtin_pow (gimple_stmt_i
cbrtfn
(gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
real_identical (c2, c)
+ !c2_is_int
optimize_function_for_speed_p (cfun)
powi_cost (n / 3) = POWI_MAX_MULTS)
{
--- gcc/testsuite/gcc.dg/pr56125.c.jj 2013-01-28 11:00:04.359814742 +0100
+++ gcc/testsuite/gcc.dg/pr56125.c2013-01-28 11:00:55.048532118 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/56125 */
+/* { dg-do run } */
+/* { dg-options -O2 -ffast-math } */
+
+extern void abort (void);
+extern double fabs (double);
+
+__attribute__((cold)) double
+foo (double x, double n)
+{
+ double u = x / (n * n);
+ return u;
+}
+
+int
+main ()
+{
+ if (fabs (foo (29, 2) - 7.25) 0.001)
+abort ();
+ return 0;
+}
Jakub
Re: [PATCH][RFC] Avoid excessive BLOCK associations for locations
Hi, On Mon, 28 Jan 2013, Richard Biener wrote: What's the point of switching to the outermost scope for unknown-BLOCK locations? It's the most sensical block for code which isn't otherwise associated with a BLOCK. But the latter Shouldn't Happen, because conceptually all code runs in some (perhaps artificial) lookup context. So, it's actually not the inliner which should fixup stuff here, but rather ... If we have a non-UNKNOWN_LOCATION, would a NULL BLOCK not be an error anyway? ... whatever is producing such non-BLOCK code snippets. But see below. Isn't inheriting the currently active scope much more useful (it definitely is for UNKNOWN_LOCATIONs)? And yes, the most likely useful block for such code will be the currently active block. This is true only before code transformations of course; while optimizing you have the same problems like with locations, i.e. how to merge multiple different BLOCKs into one sensible. Now, as an implementation optimization (to not bloat the location/block sets perhaps) you can define block==NULL -- block==outermost-scope, and in case you do so, it's indeed the inliner that needs to map NULL blocks to the mapped outermost scope of the inlined function. I would guess that this is what historically was done, and when this optimization is still employed your patch is wrong. IMHO this optimization should be used. Ciao, Michael.
Re: [Ping] [Patch, AArch64] Set libgloss_dir for aarch64*-*-* targets
Ping~
On 01/10/13 16:20, Yufeng Zhang wrote:
Hi,
This patch updates the top-level configuration files to explicitly set
libgloss_dir to aarch64 for aarch64*-*-* targets.
OK to commit?
Thanks,
Yufeng
2013-01-10 Yufeng Zhangyufeng.zh...@arm.com
* configure.ac: Set libgloss_dir for the aarch64*-*-* targets.
* configure: Regenerated.
top-level-config.patch
diff --git a/configure.ac b/configure.ac
index 02720ee..5bdf1d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -759,6 +759,9 @@ case ${target} in
sh*-*-pe|mips*-*-pe|*arm-wince-pe)
libgloss_dir=wince
;;
+ aarch64*-*-* )
+libgloss_dir=aarch64
+;;
arm*-*-*)
libgloss_dir=arm
;;
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner michael.haubenwall...@salomon.at wrote: But still curious if you've been able to reproduce the problem, and why you didn't encounter this problem beforehand. As I mentioned before, because of --boot-ld-flags, with earlier libgcc and libstdc++ installed in that directory. Yes, but (you've asked) here is this situation I don't want to configure extra deplib-prefixes for (remember bullfreeware is listed as provider for gcc-binaries): * bullfreeware's libiconv-1.13.1 and gettext-0.17 is installed in /opt/freeware, * /usr/lib/libintl.a is symlinked to /opt/freeware/lib (by bullfreeware's RPM), * /usr/lib/libiconv.a is the original AIX' one. Now, /usr/lib/libintl.a needs /opt/freeware/lib/libiconv.a[libiconv.so.2], and it does contain the correct RUNPATH. But subsequent binaries linking against /usr/lib/libintl.a don't (necessarily) know about the need to add /opt/freeware/lib as RUNPATH, so these binaries break with libiconv.so.2 not being found as member of /usr/lib/libiconv.a, because AIX unfortunately does stop its shared-library search at the first archive filename found. This also is the main reason for my filename-based-shared-library-versioning thing. Over the weekend, I successfully tested a different way to configure and build: all static libraries. If you build and privately install GMP, MPFR, MPC and LIBICONV configured as static libraries (--enable-static --disable-shared) and install in /prereq, then, combined with your patch to enable --static-libstdc++ --static-libgcc, the resulting GCC only depends on AIX libc.a -- no other shared libraries. Bull Freeware can distribute the shared versions of the libraries for other applications, but they do not need to be GCC dependencies. - David
Re: [PATCH ARM iWMMXt 0/5] Improve iWMMXt support
Hi Matt, Could this patch, or perhaps the much smaller one I attached to bug 35294 be committed to the 4.7 branch? Yes. Done. Also, could you close its duplicates, bugs 36798 and 36966? Sorry no. I do not actually own these PRs, so I cannot close them. :-( Cheers Nick
Re: [doc,committed] Fix missing ':' in inline asm example
Georg-Johann Lay wrote: Applied as obvious: http://gcc.gnu.org/r195471 * doc/extend.texi (Example of asm with clobbered asm reg): Fix missing ':' in asm example. The patch: --- trunk/gcc/doc/extend.texi 2013/01/25 17:55:09 195470 +++ trunk/gcc/doc/extend.texi 2013/01/25 18:11:53 195471 @@ -6062,7 +6062,7 @@ int *y = x; int result; asm (magic stuff accessing an 'int' pointed to by '%1' -=d (r) : a (y), m (*y)); + : =d (r) : a (y), m (*y)); return result; @} @end smallexample
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
On Mon, 28 Jan 2013, Jakub Jelinek wrote: 2013-01-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/56125 * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize pow(x,c) into sqrt(x) * powi(x, n/2) or 1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when optimizing for size. Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or 1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an integer. * gcc.dg/pr56125.c: New test. Hello, is there an implicit -lm in the testsuite? The testcase now generates a library call to pow, like gcc-4.6. This is correct, but I am surprised this is considered better than leaving the original x/(n*n) unchanged... Should that be a different PR? -- Marc Glisse
Re: [v3] Fix management of non empty hash functor
On 10 January 2013 21:02, François Dumont wrote: Hi Here is an other version of this patch. Indeed there were no need to expose many stuff public. Inheriting from _Hash_code_base is fine, it is not final and it deals with EBO itself. I only kept usage of _Hashtable_ebo_helper when embedding H2 functor. As it is an extension we could have impose it not to be final but it doesn't cost a lot to deal with it. Finally I only needed a single friend declaration to get access to the H2 part of _Hash_code_base. OK. I didn't touch the default cache policy for the moment except reducing constraints on the hash functor. I prefer to submit an other patch to change when we cache or not depending on the hash functor expected performance. OK. The reduced constraints are good. Does this actually affect performance? In my tests it doesn't, so I assume we still need to change the caching decision to notice any performance improvements? (Do the performance benchmarks actually tell us anything useful? When I run them I get such varying results it doesn't seem to be reliable.) I also took the time to replace some typedef expressions with using ones. I really know what is the rule about using one or the other but I remembered that Benjamin spent quite some time changing typedef in using so I prefer to stick to this approach in this file, even if there are still some typedef left. OK, that doesn't make any difference so isn't important which is used. Tested under linux x86_64 normal and debug modes. 2013-01-10 François Dumont fdum...@gcc.gnu.org * include/bits/hashtable_policy.h (_Local_iterator_base): Use _Hashtable_ebo_helper to embed necessary functors into the local_iterator when necessary. Pass information about functors Repeating necessary seems unnecessary here :) involved in hash code by copy. * include/bits/hashtable.h (__cache_default): Do not cache for builtin integral types unless the hash functor is not noexcept qualified or is not default constructible. Adapt static assertions and local iteraror instantiations. ^^ iteraror + // When hash codes are not cached local iterator inherits from + // __hash_code_base above to compute node bucket index so it has to be + // default constructible. + static_assert(__if_hash_not_cached + is_default_constructible__hash_code_base::value, + Cache the hash code or make functors involved in hash code +and bucket index computation default constructibles); constructible not constructibles This is OK for trunk, but not 4.7
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
On Mon, Jan 28, 2013 at 04:41:31PM +0100, Marc Glisse wrote: On Mon, 28 Jan 2013, Jakub Jelinek wrote: 2013-01-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/56125 * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize pow(x,c) into sqrt(x) * powi(x, n/2) or 1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when optimizing for size. Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or 1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an integer. * gcc.dg/pr56125.c: New test. is there an implicit -lm in the testsuite? Yes. The testcase now generates a library call to pow, like gcc-4.6. This is correct, but I am surprised this is considered better than leaving the original x/(n*n) unchanged... Should that be a different PR? The function in question is marked as cold, therefore it should be optimized for size. The call to pow is certainly shorter than the sqrt, multiplication, division etc. Jakub
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
On Mon, 28 Jan 2013, Jakub Jelinek wrote: On Mon, Jan 28, 2013 at 04:41:31PM +0100, Marc Glisse wrote: On Mon, 28 Jan 2013, Jakub Jelinek wrote: 2013-01-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/56125 * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize pow(x,c) into sqrt(x) * powi(x, n/2) or 1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when optimizing for size. Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or 1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an integer. * gcc.dg/pr56125.c: New test. The testcase now generates a library call to pow, like gcc-4.6. This is correct, but I am surprised this is considered better than leaving the original x/(n*n) unchanged... Should that be a different PR? The function in question is marked as cold, therefore it should be optimized for size. The call to pow is certainly shorter than the sqrt, multiplication, division etc. There is no sqrt, x/(n*n) is just one mul and one div, whereas with the call I see one mul, 3 movs to prepare for the call, and the call. -- Marc Glisse
Re: [PATCH] Fix up pow folding (PR tree-optimization/56125)
On Mon, Jan 28, 2013 at 05:07:10PM +0100, Marc Glisse wrote: There is no sqrt, x/(n*n) is just one mul and one div, whereas with the call I see one mul, 3 movs to prepare for the call, and the call. Ah, you're talking about the checked in testcase, rather than the one I've mentioned in the description whether the speed guard is desirable there or not. In the checked in testcase, the problem with code size is far earlier than that, already during folding that double u = x / (n * n); is replaced by: double u = x * __builtin_pow (n, -2.0e+0); And this isn't something you can then size optimize in the pow folder on its own, return pow (n, -2.0e); will be supposedly shorter than return 1.0 / (n * n), the folding doesn't see that this is used in multiplication which could be perhaps changed into division instead. Jakub
Re: [PATCH] Fix sched ICE with prefetch (PR rtl-optimization/56117)
On 01/28/2013 07:14 AM, Jakub Jelinek wrote: Hi! We ICE on the following testcase when using cselib, because cselib_lookup* is never called on the PREFETCH argument, and add_insn_mem_dependence calls cselib_subst_to_values on it, which assumes cselib_lookup* already happened on it earlier. For MEMs sched_analyze_2 calls cselib_lookup_from_insn, but for PREFETCHes it didn't. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2013-01-28 Jakub Jelinek ja...@redhat.com PR rtl-optimization/56117 * sched-deps.c (sched_analyze_2) case PREFETCH: For use_cselib call cselib_lookup_from_insn on the MEM before calling add_insn_mem_dependence. * gcc.dg/pr56117.c: New test. I'm assuming that we don't need the shallow_copy_rtx call and related code because in the PREFETCH case we generate a new MEM and the underlying address can be safely shared. Right? If that's true, OK. jeff
Re: [PATCH] Fix sched ICE with prefetch (PR rtl-optimization/56117)
On Mon, Jan 28, 2013 at 09:39:00AM -0700, Jeff Law wrote: I'm assuming that we don't need the shallow_copy_rtx call and related code because in the PREFETCH case we generate a new MEM and the underlying address can be safely shared. Right? AFAIK cselib_lookup* never modifies the rtx it is passed, shallow_copy_rtx in the MEM case is for: t = shallow_copy_rtx (dest); cselib_lookup_from_insn (XEXP (t, 0), address_mode, 1, GET_MODE (t), insn); XEXP (t, 0) = cselib_subst_to_values_from_insn (XEXP (t, 0), GET_MODE (t), insn); where we modify XEXP (t, 0) in the last assignment and don't want to change XEXP (dest, 0). Jakub
Re: [committed] Avoid setting gimple_location of force_gimple_operand* created stmts to DECL_SOURCE_LOCATION of current fn (PR tree-optimization/56094)
On 01/28/2013 07:09 AM, Jakub Jelinek wrote:
Hi!
As discussed in the PR, this is a safer variant of a fix for 4.8, where
input_location during most optimization passes is set to
DECL_SOURCE_LOCATION (current_function_decl) and various parts of the
gimplifier e.g. during force_gimple_operand* may end up setting
gimple_location to that. For 4.9, we should revert this and set
input_location to UNKNOWN_LOCATION for the optimizers.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56094
* gimplify.c (force_gimple_operand_1): Temporarily set input_location
to UNKNOWN_LOCATION while gimplifying expr.
* gcc.dg/pr56094.c: New test.
Based on c#15, we should probably consider this a bit of a band-aid,
right? Thus we'll install the band-aid, but keep the PR open pending a
better solution for handling of input_location, correct?
jeff
+/* Verify no statements get the location of the foo () decl. */
+/* { dg-final { scan-tree-dump-not : 65:1\\\] optimized } } */
+/* { dg-final { cleanup-tree-dump optimized } } */
Jakub
Re: [committed] Avoid setting gimple_location of force_gimple_operand* created stmts to DECL_SOURCE_LOCATION of current fn (PR tree-optimization/56094)
On Mon, Jan 28, 2013 at 09:50:35AM -0700, Jeff Law wrote: 2013-01-28 Jakub Jelinek ja...@redhat.com PR tree-optimization/56094 * gimplify.c (force_gimple_operand_1): Temporarily set input_location to UNKNOWN_LOCATION while gimplifying expr. * gcc.dg/pr56094.c: New test. Based on c#15, we should probably consider this a bit of a band-aid, right? Yeah. Thus we'll install the band-aid, but keep the PR open pending a better solution for handling of input_location, correct? That's what I did. Jakub
[Patch,avr] Remove fixed-point MUL and DIV routines from libgcc build
This removes modules from libgcc that are already supported by avr-specific fixed-point implementation and avoids duplicate functions like __mulsa3. Ok for trunk? Johann libgcc/ * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add: _mulQQ, _mulHQ, _mulHA, _mulSA, _mulUQQ, _mulUHQ, _mulUHA, _mulUSA, _divQQ, _divHQ, _divHA, _divSA, _divUQQ, _divUHQ, _divUHA, _divUSA. Index: config/avr/t-avr === --- config/avr/t-avr (revision 195301) +++ config/avr/t-avr (working copy) @@ -164,3 +164,17 @@ LIB2FUNCS_EXCLUDE += \ LIB2FUNCS_EXCLUDE += \ $(foreach func,_usadd _ussub _usneg,\ $(foreach mode,$(usat_modes),$(func_X))) + + +smul_modes = QQ HQ HA SA +umul_modes = UQQ UHQ UHA USA +sdiv_modes = QQ HQ HA SA +udiv_modes = UQQ UHQ UHA USA + +LIB2FUNCS_EXCLUDE += \ + $(foreach func,_mul,\ + $(foreach mode,$(smul_modes) $(umul_modes),$(func_X))) + +LIB2FUNCS_EXCLUDE += \ + $(foreach func,_div,\ + $(foreach mode,$(sdiv_modes) $(udiv_modes),$(func_X)))
Re: [Patch] Fix PR54814
On 01/27/2013 03:26 PM, Steven Bosscher wrote: On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote: The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 Ironically, this revision fixes a reload problem on x86/x86_64 -- which doesn't use reload anymore now... Does this mean the fix is rejected for 4.8? No, just that it probably helps to add a RM to the CC list. FWIW, it seems to me that this patch should go into 4.8, because the bug is probably not limited to AVR. At this stage, I tend to be more conservative. However, it looks like Ulrich Richi have taken a looksie and think the patch is fine. I'm certainly not going to object. jeff
Re: [Patch] Fix PR54814
On 01/27/2013 03:09 PM, Georg-Johann Lay wrote: If not, it'll probably need release manager approval before it can go in. Please attach your patch to PR54814 and attach PR 54814 to the 4.9 pending patches meta bug. Does this mean the fix is rejected for 4.8? Not necessarily. We're in a regression bugfix only stage; so regressions can obviously be fixed. If a change does not fix a regression, then it really needs the release manager's approval to go forward at this stage. Jeff
Re: [Patch] Fix PR54814
On 01/28/2013 06:55 AM, Ulrich Weigand wrote: Richard Biener wrote: On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com wrote: On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote: The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 Ironically, this revision fixes a reload problem on x86/x86_64 -- which doesn't use reload anymore now... Does this mean the fix is rejected for 4.8? No, just that it probably helps to add a RM to the CC list. FWIW, it seems to me that this patch should go into 4.8, because the bug is probably not limited to AVR. Indeed, the fix also looks quite obvious though I know nothing about the code at all. Thus, ok from a RM perspective if a reload-affine person approves it. The patch was originally by Bernd, but FWIW it looks good to me as well. Now that I know this is a regression, I've looked at it more closely and it looks good to me too. George-Johann, please install this onto the trunk. Thanks, Jeff
Re: RFA: RL78: Allow SP to be used as a base register
Please may I apply the patch below. It fixes the RL78 backend so that the stack register can be used as a base address register. Yes, please. Thanks!
Re: [PATCH] Adding target rdos to GCC
Uros, That is intentional. The gthr-rdos.h file is part of libgcc. My intention was to first patch gcc, then update the patches for newlib, and finally libgcc. The gthr-rdos.h file would reference include-files part of newlib, so this is kind of circular. I also cannot define the thread model for RDOS unless I define this file. I see a couple of possible solutions: 1. Keep as is. You cannot build libgcc at the current stage anyway, and the bootstrap must be built without threading 2. Add an empty gthr-rdos.h file until libgcc is done 3. Remove the threading-model for now, and add it with libgcc instead. Regards, Leif Ekblad - Original Message - From: Uros Bizjak ubiz...@gmail.com To: Leif Ekblad l...@rdos.net Cc: Richard Biener rguent...@suse.de; gcc-patches@gcc.gnu.org; H.J. Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com Sent: Monday, January 28, 2013 8:23 AM Subject: Re: [PATCH] Adding target rdos to GCC On Mon, Jan 28, 2013 at 7:50 AM, Leif Ekblad l...@rdos.net wrote: If the patch is ok, could some maintainer add it to trunk? There is no gthr-rdos.h file in your patch: *** gcc-4.8-20121230/config/gthr.m4 2012-10-15 15:10:30.0 +0200 --- gcc-work/config/gthr.m4 2013-01-07 10:14:04.620667900 +0100 *** *** 21,26 --- 21,27 tpf) thread_header=config/s390/gthr-tpf.h ;; vxworks) thread_header=config/gthr-vxworks.h ;; win32) thread_header=config/i386/gthr-win32.h ;; + rdos) thread_header=config/i386/gthr-rdos.h ;; This file should be part of libgcc, so it needs its own ChangeLog. Uros.
Re: [PATCH] Adding target rdos to GCC
On Mon, Jan 28, 2013 at 8:57 PM, Leif Ekblad l...@rdos.net wrote: That is intentional. The gthr-rdos.h file is part of libgcc. My intention was to first patch gcc, then update the patches for newlib, and finally libgcc. The gthr-rdos.h file would reference include-files part of newlib, so this is kind of circular. I also cannot define the thread model for RDOS unless I define this file. I see a couple of possible solutions: 1. Keep as is. You cannot build libgcc at the current stage anyway, and the bootstrap must be built without threading 2. Add an empty gthr-rdos.h file until libgcc is done 3. Remove the threading-model for now, and add it with libgcc instead. I propose option 3. Is it enough to remove gthr.m4 change from the patch in this case? Uros.
Re: [PATCH] Adding target rdos to GCC
- Original Message - From: Uros Bizjak ubiz...@gmail.com To: Leif Ekblad l...@rdos.net Cc: Richard Biener rguent...@suse.de; gcc-patches@gcc.gnu.org; H.J. Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com Sent: Monday, January 28, 2013 9:03 PM Subject: Re: [PATCH] Adding target rdos to GCC On Mon, Jan 28, 2013 at 8:57 PM, Leif Ekblad l...@rdos.net wrote: That is intentional. The gthr-rdos.h file is part of libgcc. My intention was to first patch gcc, then update the patches for newlib, and finally libgcc. The gthr-rdos.h file would reference include-files part of newlib, so this is kind of circular. I also cannot define the thread model for RDOS unless I define this file. I see a couple of possible solutions: 1. Keep as is. You cannot build libgcc at the current stage anyway, and the bootstrap must be built without threading 2. Add an empty gthr-rdos.h file until libgcc is done 3. Remove the threading-model for now, and add it with libgcc instead. I propose option 3. Is it enough to remove gthr.m4 change from the patch in this case? Uros. Yes, for all practical purposes. There is a reference to thread-file in config.gcc, when threading is enabled, which doesn't work for bootstrapping the compiler anyway. Regards, Leif Ekblad
[SH] PR 56121 - fix libgcc build for SH2A
Hi,
This is the same patch that I attached in the PR.
It fixes an ICE when building libgcc for the SH2A target.
Tested on rev. 195493 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
... comparing the test results against rev 193342 shows a few new
failures, but they seem unrelated to this case.
OK for trunk?
Cheers,
Oleg
gcc/ChangeLog:
PR target/56121
* config/sh/sh.md (bclr_m2a, bset_m2a, bst_m2a, bld_m2a,
bldsign_m2a, bld_reg, *bld_regqi, band_m2a, bandreg_m2a,
bor_m2a, borreg_m2a, bxor_m2a, bxorreg_m2a): Add
satisfies_constraint_K03 condition.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 195493)
+++ gcc/config/sh/sh.md (working copy)
@@ -13140,6 +13140,8 @@
})
;; SH2A instructions for bitwise operations.
+;; FIXME: Convert multiple instruction insns to insn_and_split.
+;; FIXME: Use iterators to fold at least and,xor,or insn variations.
;; Clear a bit in a memory location.
(define_insn bclr_m2a
@@ -13148,7 +13150,7 @@
(not:QI (ashift:QI (const_int 1)
(match_operand:QI 1 const_int_operand K03,K03)))
(match_dup 0)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bclr.b %1,%0
bclr.b %1,@(0,%t0)
@@ -13171,7 +13173,7 @@
(ashift:QI (const_int 1)
(match_operand:QI 1 const_int_operand K03,K03))
(match_dup 0)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bset.b %1,%0
bset.b %1,@(0,%t0)
@@ -13198,7 +13200,7 @@
(ior:QI
(ashift:QI (const_int 1) (match_dup 1))
(match_dup 0]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bst.b %1,%0
bst.b %1,@(0,%t0)
@@ -13211,7 +13213,7 @@
(match_operand:QI 0 bitwise_memory_operand Sbw,Sbv)
(const_int 1)
(match_operand 1 const_int_operand K03,K03)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bld.b %1,%0
bld.b %1,@(0,%t0)
@@ -13224,7 +13226,7 @@
(match_operand:QI 0 bitwise_memory_operand Sbw,m)
(const_int 1)
(match_operand 1 const_int_operand K03,K03)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bld.b %1,%0
bld.b %1,@(0,%t0)
@@ -13236,7 +13238,7 @@
(zero_extract:SI (match_operand:SI 0 arith_reg_operand r)
(const_int 1)
(match_operand 1 const_int_operand K03)))]
- TARGET_SH2A
+ TARGET_SH2A satisfies_constraint_K03 (operands[1])
bld %1,%0)
(define_insn *bld_regqi
@@ -13244,7 +13246,7 @@
(zero_extract:SI (match_operand:QI 0 arith_reg_operand r)
(const_int 1)
(match_operand 1 const_int_operand K03)))]
- TARGET_SH2A
+ TARGET_SH2A satisfies_constraint_K03 (operands[1])
bld %1,%0)
;; Take logical and of a specified bit of memory with the T bit and
@@ -13256,7 +13258,7 @@
(match_operand:QI 0 bitwise_memory_operand Sbw,m)
(const_int 1)
(match_operand 1 const_int_operand K03,K03]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
band.b %1,%0
band.b %1,@(0,%t0)
@@ -13269,7 +13271,7 @@
(const_int 1)
(match_operand 2 const_int_operand K03,K03))
(match_operand:SI 3 register_operand r,r)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[2])
{
static const char* alt[] =
{
@@ -13292,7 +13294,7 @@
(match_operand:QI 0 bitwise_memory_operand Sbw,m)
(const_int 1)
(match_operand 1 const_int_operand K03,K03]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bor.b %1,%0
bor.b %1,@(0,%t0)
@@ -13305,7 +13307,7 @@
(const_int 1)
(match_operand 2 const_int_operand K03,K03))
(match_operand:SI 3 register_operand =r,r)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[2])
{
static const char* alt[] =
{
@@ -13328,7 +13330,7 @@
(match_operand:QI 0 bitwise_memory_operand Sbw,m)
(const_int 1)
(match_operand 1 const_int_operand K03,K03]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[1])
@
bxor.b %1,%0
bxor.b %1,@(0,%t0)
@@ -13341,7 +13343,7 @@
(const_int 1)
(match_operand 2 const_int_operand K03,K03))
(match_operand:SI 3 register_operand =r,r)))]
- TARGET_SH2A TARGET_BITOPS
+ TARGET_SH2A TARGET_BITOPS satisfies_constraint_K03 (operands[2])
{
static const char* alt[] =
{
Re: [PATCH] Adding target rdos to GCC
On Mon, Jan 28, 2013 at 9:14 PM, Leif Ekblad l...@rdos.net wrote:
That is intentional. The gthr-rdos.h file is part of libgcc. My intention
was to first patch gcc, then update the patches for newlib, and finally
libgcc. The gthr-rdos.h file would reference include-files part of
newlib,
so this is kind of circular. I also cannot define the thread model for
RDOS
unless I define this file.
I see a couple of possible solutions:
1. Keep as is. You cannot build libgcc at the current stage anyway, and
the
bootstrap must be built without threading
2. Add an empty gthr-rdos.h file until libgcc is done
3. Remove the threading-model for now, and add it with libgcc instead.
I propose option 3.
Is it enough to remove gthr.m4 change from the patch in this case?
Yes, for all practical purposes. There is a reference to thread-file in
config.gcc, when threading is enabled, which doesn't work for bootstrapping
the compiler anyway.
Thanks for pointing it, I have also removed this reference.
Attached is the patch that has been committed to SVN. I have added
missing licence headers to new files and clean whitespace a bit.
2013-01-28 Leif Ekblad l...@rdos.net
* config.gcc (i[34567]86-*-rdos*, x86_64-*-rdos*): New targets.
* config/i386/i386.h (TARGET_RDOS): New macro.
(DEFAULT_LARGE_SECTION_THRESHOLD): New macro.
* config/i386/i386.c (ix86_option_override_internal): For 64bit
TARGET_RDOS, set ix86_cmodel to CM_MEDIUM_PIC and flag_pic to 1.
* config/i386/i386.opt (mlarge-data-threshold): Initialize to
DEFAULT_LARGE_SECTION_THRESHOLD.
* config/i386/i386.md (R14_REG, R15_REG): New constants.
* config/i386/rdos.h: New file.
* config/i386/rdos64.h: New file.
Thanks,
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 195515)
+++ config/i386/i386.c (working copy)
@@ -3235,10 +3235,12 @@ ix86_option_override_internal (bool main_args_p)
DLL, and is essentially just as efficient as direct addressing. */
if (TARGET_64BIT DEFAULT_ABI == MS_ABI)
ix86_cmodel = CM_SMALL_PIC, flag_pic = 1;
+ else if (TARGET_64BIT TARGET_RDOS)
+ ix86_cmodel = CM_MEDIUM_PIC, flag_pic = 1;
else if (TARGET_64BIT)
ix86_cmodel = flag_pic ? CM_SMALL_PIC : CM_SMALL;
else
-ix86_cmodel = CM_32;
+ ix86_cmodel = CM_32;
}
if (TARGET_MACHO ix86_asm_dialect == ASM_INTEL)
{
Index: config/i386/i386.h
===
--- config/i386/i386.h (revision 195515)
+++ config/i386/i386.h (working copy)
@@ -518,6 +518,9 @@ extern tree x86_mfence;
#define MACHOPIC_INDIRECT 0
#define MACHOPIC_PURE 0
+/* For the RDOS */
+#define TARGET_RDOS 0
+
/* For the Windows 64-bit ABI. */
#define TARGET_64BIT_MS_ABI (TARGET_64BIT ix86_cfun_abi () == MS_ABI)
@@ -2081,6 +2084,10 @@ do {
\
asm (SECTION_OP \n\t \
call CRT_MKSTR(__USER_LABEL_PREFIX__) #FUNC \n \
TEXT_SECTION_ASM_OP);
+
+/* Default threshold for putting data in large sections
+ with x86-64 medium memory model */
+#define DEFAULT_LARGE_SECTION_THRESHOLD 65536
/* Which processor to tune code generation for. */
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 195515)
+++ config/i386/i386.md (working copy)
@@ -300,6 +300,8 @@
(R11_REG40)
(R12_REG41)
(R13_REG42)
+ (R14_REG43)
+ (R15_REG44)
(XMM8_REG 45)
(XMM9_REG 46)
(XMM10_REG 47)
Index: config/i386/i386.opt
===
--- config/i386/i386.opt(revision 195515)
+++ config/i386/i386.opt(working copy)
@@ -140,7 +140,7 @@ Target RejectNegative Joined UInteger Var(ix86_bra
Branches are this expensive (1-5, arbitrary units)
mlarge-data-threshold=
-Target RejectNegative Joined UInteger Var(ix86_section_threshold) Init(65536)
+Target RejectNegative Joined UInteger Var(ix86_section_threshold)
Init(DEFAULT_LARGE_SECTION_THRESHOLD)
Data greater than given threshold will go into .ldata section in x86-64 medium
model
mcmodel=
Index: config/i386/rdos.h
===
--- config/i386/rdos.h (revision 0)
+++ config/i386/rdos.h (working copy)
@@ -0,0 +1,33 @@
+/* Definitions for RDOS on i386.
+ Copyright (C) 2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation;
Re: [Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
**ping**
On 23 January 2013 11:06, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
*** gfc_alloc_allocatable_for_assignment (gf
*** 8224,8229
--- 8250,8262
desc, tmp);
tmp = gfc_conv_descriptor_dtype (desc);
gfc_add_modify (alloc_block, tmp, gfc_get_dtype (TREE_TYPE (desc)));
+ if ((expr1-ts.type == BT_DERIVED)
+expr1-ts.u.derived-attr.alloc_comp)
+ {
+ tmp = gfc_nullify_alloc_comp (expr1-ts.u.derived, desc,
+ expr1-rank);
+ gfc_add_expr_to_block (alloc_block, tmp);
+ }
alloc_expr = gfc_finish_block (alloc_block);
When glancing at the patch, I wondered whether it would be better to use
CALLOC instead of MALLOC and avoid the nullification:
/* Malloc expression. */
gfc_init_block (alloc_block);
tmp = build_call_expr_loc (input_location,
builtin_decl_explicit (BUILT_IN_MALLOC),
1, size2);
On the other hand, the nullification is probably still required for REALLOC.
If so, the question is whether CALLOC + nullify in the realloc branch - or
malloc + nullify after the realloc/malloc branches is better. Hence, your
version is probably fine.
Sorry for not yet reviewing your patch.
Tobias
PS: Regarding allocatable and memory leak: PR55603 has as similar issue.
For scalars, gfortran never frees allocatable function results; that's
independent of the LHS (allocatable, pointer, neither). Thus, if you are in
the mood of fixing those kind of bugs … (Actually, I am not even sure
whether that's restricted to allocation, it might also occur with
expressions like a = f() + 5. Untested.)
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: [v3] Fix management of non empty hash functor
Attached patch applied.
2013-01-28 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable_policy.h (_Local_iterator_base): Use
_Hashtable_ebo_helper to embed functors into the local_iterator
when necessary. Pass information about functors involved in hash
code by copy.
* include/bits/hashtable.h (__cache_default): Do not cache for
builtin integral types unless the hash functor is not noexcept
qualified or is not default constructible. Adapt static assertions
and local iterator instantiations.
* include/debug/unordered_set
(std::__debug::unordered_set::erase): Detect local iterators to
invalidate using contained node rather than generating a dummy
local_iterator instance.
(std::__debug::unordered_multiset::erase): Likewise.
* include/debug/unordered_map
(std::__debug::unordered_map::erase): Likewise.
(std::__debug::unordered_multimap::erase): Likewise.
* testsuite/performance/23_containers/insert_erase/41975.cc: Test
std::tr1 and std versions of unordered_set regardless of any
macro. Add test on default cache behavior.
* testsuite/performance/23_containers/insert/54075.cc: Likewise.
* testsuite/23_containers/unordered_set/instantiation_neg.cc:
Adapt line number.
* testsuite/23_containers/unordered_set/
not_default_constructible_hash_neg.cc: New.
* testsuite/23_containers/unordered_set/buckets/swap.cc: New.
On 01/28/2013 04:42 PM, Jonathan Wakely wrote:
On 10 January 2013 21:02, François Dumont wrote:
Hi
Here is an other version of this patch. Indeed there were no need to
expose many stuff public. Inheriting from _Hash_code_base is fine, it is not
final and it deals with EBO itself. I only kept usage of
_Hashtable_ebo_helper when embedding H2 functor. As it is an extension we
could have impose it not to be final but it doesn't cost a lot to deal with
it. Finally I only needed a single friend declaration to get access to the
H2 part of _Hash_code_base.
OK.
I didn't touch the default cache policy for the moment except reducing
constraints on the hash functor. I prefer to submit an other patch to change
when we cache or not depending on the hash functor expected performance.
OK. The reduced constraints are good. Does this actually affect
performance? In my tests it doesn't, so I assume we still need to
change the caching decision to notice any performance improvements?
No performance gain plan with that patch indeed. It just restore support
for non-empty hash functor that used to work with previous
implementation. There is also no performance test impacted by the
modification of the default cache behavior so it is not surprised that
you noticed nothing.
(Do the performance benchmarks actually tell us anything useful?
When I run them I get such varying results it doesn't seem to be reliable.)
Last time I run the tests it was showing when not caching was better
than caching. I have even added a bench on the unordered containers
directly to show what are the performance of default behavior. For the
moment, for the Foo type used in 54075.cc, the default behavior is not
the best one. But I will submit a patch for that soon with a hash traits
telling if it is fast or not, like we already talk about.
François
Index: include/bits/hashtable_policy.h
===
--- include/bits/hashtable_policy.h (revision 195515)
+++ include/bits/hashtable_policy.h (working copy)
@@ -1,6 +1,6 @@
// Internal policy header for unordered_set and unordered_map -*- C++ -*-
-// Copyright (C) 2010, 2011, 2012 Free Software Foundation, Inc.
+// Copyright (C) 2010-2013 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
@@ -202,7 +202,7 @@
templatetypename _Value, bool _Cache_hash_code
struct _Node_iterator_base
{
- typedef _Hash_node_Value, _Cache_hash_code __node_type;
+ using __node_type = _Hash_node_Value, _Cache_hash_code;
__node_type* _M_cur;
@@ -282,7 +282,7 @@
struct _Node_const_iterator
: public _Node_iterator_base_Value, __cache
{
- private:
+private:
using __base_type = _Node_iterator_base_Value, __cache;
using __node_type = typename __base_type::__node_type;
@@ -941,6 +941,17 @@
};
/**
+ * Primary class template _Local_iterator_base.
+ *
+ * Base class for local iterators, used to iterate within a bucket
+ * but not between buckets.
+ */
+ templatetypename _Key, typename _Value, typename _ExtractKey,
+ typename _H1, typename _H2, typename _Hash,
+ bool __cache_hash_code
+struct _Local_iterator_base;
+
+ /**
* Primary class template _Hash_code_base.
*
* Encapsulates two policy issues that aren't quite orthogonal.
@@ -974,8 +985,8 @@
private _Hashtable_ebo_helper1, _Hash
{
Re: [v3] Fix management of non empty hash functor
On 28 January 2013 21:08, François Dumont wrote: (Do the performance benchmarks actually tell us anything useful? When I run them I get such varying results it doesn't seem to be reliable.) Last time I run the tests it was showing when not caching was better than caching. Yes, I've definitely seen real advantage from not caching (but that was in my own tests, not the performance testsuite.) I have even added a bench on the unordered containers directly to show what are the performance of default behavior. For the moment, for the Foo type used in 54075.cc, the default behavior is not the best one. But I will submit a patch for that soon with a hash traits telling if it is fast or not, like we already talk about. Great, thanks.
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Jan 28, 2013, at 7:07 AM, David Edelsohn dje@gmail.com wrote: Over the weekend, I successfully tested a different way to configure and build: all static libraries. Yeah, I think our build instructions for the dependent libraries should say to build them statically.
Re: [Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
Hi Paul, This patch is sufficiently straightforward that the ChangeLog entry describes it completely. The fix for both bugs lay in the nullification of the allocatable components of the newly (re)allocated array. I think this fix is OK for trunk, for the reasons you mentioned. I also think it is straightforward enough (bordering on the obvious, but only after having read it :-) that it does not carry too much risk of a regression. So yes, OK from my side, unless somebody speaks up really quickly. Thomas
[PATCH 0/2] Avoid duplicated instrumentation in Address Sanitizer
Hello, As the subject suggests, the little patch-set that follows this message implements a basic optimization for the Address Sanitizer pass: in the same basic block, it avoids instrumenting an access to a memory region, if that same access has been instrumented before. As we store instrumented accesses to memory region in a hash table (that uses the new hash-table.h interface), I found it handy to be able to define the hash table entries as a type that has obvious constructors, rather than requiring the user of the hash table entry to write boilerplate code to do the initialization. So it was handy as well to be able to use the new operator to allocate memory for these entries (rather than using malloc + boilerplate initialization code). So I added support for the having hash table entries managed by new/delete in hash-table.h. That's what the first patch does. The second patch is where the real meat of the set is. I deliberately chose to start with the same conservative (and simple) approach used by asan@llvm which is to clear the hash table containing the already-instrumented memory accesses each time we start a new BB or each time we come across a function call. It seems like we could be smarter than that, to allow this optimization to work in inter-BB cases where there is a dominator relationship between BBs containing duplicated memory accesses. But I thought this could be added later, after 4.8. Below is the summary of the patches. [asan] Allow creating/deleting hash table entries with new/delete [asan] Avoid instrumenting duplicated memory access in the same basic block gcc/Makefile.in| 3 +- gcc/asan.c | 366 ++--- gcc/hash-table.h | 16 + .../asan/no-redundant-instrumentation-1.c | 70 4 files changed, 409 insertions(+), 46 deletions(-) create mode 100644 gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c -- Dodji
Re: [Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Hi Janus, Or maybe wait for the fix for comment #4? Rather not (technically it's a separate issue, I guess). While the patch is rather large, I think it is OK. One request: Could you add a comment to gfc_sym_get_dummy_args explaining what the function does and under which conditions sym-formal is NULL, while sym-ts.interface-formal isn't? Regards Thomas
[PATCH 1/2] [asan] Allow creating/deleting hash table entries with new/delete
Hello,
The hash table type can handle creation and removal of entries with
malloc/free. This patchlet adds support for using new/delete. It's
useful for hash table entry types that have constructors (and/or
destructors), to prevent the user from having to type boilerplate code
to initialize them over and over again. This is used by the patch that
follows this one.
gcc/
* hash-table.h (struct typed_delete_remove): New type.
(typed_delete_remove::remove): Implement this using the delete
operator.
---
gcc/hash-table.h | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index 206423d..884840c 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -235,6 +235,22 @@ typed_free_remove Type::remove (Type *p)
free (p);
}
+/* Helpful type for removing entries with the delete operator. */
+
+template typename Type
+struct typed_delete_remove
+{
+ static inline void remove (Type *p);
+};
+
+/* Remove with delete. */
+
+template typename Type
+inline void
+typed_delete_remove Type::remove (Type *p)
+{
+ delete p;
+}
/* Helpful type for a no-op remove. */
--
1.7.11.7
--
Dodji
[PATCH 2/2] [asan] Avoid instrumenting duplicated memory access in the same basic block
Hello,
Like what Address Sanitizer does in LLVM, this patch avoids instrumented
duplicated memory accesses in the same basic blocks.
The approach taken is very conservative, to keep the pass simple, for
a start.
A memory access is considered to be a triplet made of an expression
tree representing the beginning of the memory region that is accessed,
an expression tree representing the length of that memory region, and
a boolean that says whether that access is a load or a store.
The patch builds a hash table of the memory accesses that have been
instrumented in the current basic block. Then it walks the gimple
statements of the current basic block. For each statement, it tests
if the memory regions it references have already been instrumented.
If not, the statement is instrumented and each memory references that
are actually instrumented are added to the hash table.
When the patch crosses a function call that is not a built-in function
that we ought to instrument, the hash table is cleared, because that
function call can possibly e.g free some memory that was instrumented.
Likewise, when a new basic block is visited, the hash table is
cleared. I guess we could be smarter than just unconditionally
clearing the hash table in this later case, but this is what asan@llvm
does, and for now, I thought starting in a conservative manner might
have some value.
The hash table is destroyed at the end of the pass.
Bootstrapped and tested against trunk on x86-64-unknown-linux-gnu.
gcc/
* Makefile.in (asan.o): Add new dependency on hash-table.h
* asan.c (struct mem_ref, struct mem_ref_hasher): New types.
(get_mem_ref_hash_table, has_stmt_been_instrumented_p)
(update_mem_ref_hash_table, get_mem_ref_of_assignment): New
functions.
(get_mem_refs_of_builtin_call): Extract from
instrument_builtin_call and tweak a little bit to make it fit with
the new signature.
(instrument_builtin_call): Use the new
get_mem_refs_of_builtin_call.
(maybe_instrument_assignment): Renamed instrument_assignment into
this, and change it to advance the iterator when instrumentation
actually happened and return true in that case. This makes it
homogeneous with maybe_instrument_assignment, and thus give a
chance to callers to be more 'regular'.
(transform_statements): Clear the memory reference hash table
whenever we enter a new BB, when we cross a function call, or when
we are done transforming statements. Use
maybe_instrument_assignment instead of instrumentation. No more
need to special case maybe_instrument_assignment and advance the
iterator after calling it; it's now handled just like
maybe_instrument_call. Update comment.
gcc/testsuite/
* c-c++-common/asan/no-redundant-instrumentation-1.c: New test.
---
gcc/Makefile.in| 3 +-
gcc/asan.c | 368 ++---
.../asan/no-redundant-instrumentation-1.c | 70
3 files changed, 395 insertions(+), 46 deletions(-)
create mode 100644
gcc/testsuite/c-c++-common/asan/no-redundant-instrumentation-1.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6fe6345..8f7d122 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2226,7 +2226,8 @@ stor-layout.o : stor-layout.c $(CONFIG_H) $(SYSTEM_H)
coretypes.h $(TM_H) \
asan.o : asan.c asan.h $(CONFIG_H) $(SYSTEM_H) $(GIMPLE_H) \
output.h coretypes.h $(GIMPLE_PRETTY_PRINT_H) \
tree-iterator.h $(TREE_FLOW_H) $(TREE_PASS_H) \
- $(TARGET_H) $(EXPR_H) $(OPTABS_H) $(TM_P_H) langhooks.h
+ $(TARGET_H) $(EXPR_H) $(OPTABS_H) $(TM_P_H) langhooks.h \
+ $(HASH_TABLE_H)
tsan.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \
$(GIMPLE_H) $(DIAGNOSTIC_H) langhooks.h \
$(TM_H) coretypes.h $(TREE_DUMP_H) $(TREE_PASS_H) $(CGRAPH_H) $(GGC_H) \
diff --git a/gcc/asan.c b/gcc/asan.c
index f05e36c..f9a832f 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3. If not see
#include output.h
#include tm_p.h
#include langhooks.h
+#include hash-table.h
/* AddressSanitizer finds out-of-bounds and use-after-free bugs
with 2x slowdown on average.
@@ -212,6 +213,159 @@ alias_set_type asan_shadow_set = -1;
alias set is used for all shadow memory accesses. */
static GTY(()) tree shadow_ptr_types[2];
+/* Hashtable support for memory references used by gimple
+ statements. */
+
+/* This type represents a reference to a memory region. */
+struct __attribute__ ((visibility (hidden))) mem_ref
+{
+ /* The expression of the begining of the memory region. */
+ tree start;
+ /* The expression representing the length of the region. */
+ tree len;
+ /* This is true iff the memory reference is a store. */
+ bool is_store;
+
+ /* Constructors. */
+ mem_ref () : start (NULL_TREE), len (NULL_TREE),
Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld
On Mon, Jan 28, 2013 at 4:17 PM, Mike Stump m...@mrs.kithrup.com wrote: On Jan 28, 2013, at 7:07 AM, David Edelsohn dje@gmail.com wrote: Over the weekend, I successfully tested a different way to configure and build: all static libraries. Yeah, I think our build instructions for the dependent libraries should say to build them statically. A number of GCC developers who already do this. I previously had problem on AIX with an earlier release of GCC that was built with Graphite because one of the dependent libraries used C++, but GCC was not linked with libstdc++ at the time. The only way to break the C++ dependency of the library separate from GCC was through shared libraries. If one can link GCC against static libraries, it definitely simplifies things and avoids potential conflicts with multiple versions of GCC installed. - David
Re: [PATCH] Adding target rdos to GCC
That looks good. Thanks, Uros. Leif - Original Message - From: Uros Bizjak ubiz...@gmail.com To: Leif Ekblad l...@rdos.net Cc: Richard Biener rguent...@suse.de; gcc-patches@gcc.gnu.org; H.J. Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com Sent: Monday, January 28, 2013 9:45 PM Subject: Re: [PATCH] Adding target rdos to GCC On Mon, Jan 28, 2013 at 9:14 PM, Leif Ekblad l...@rdos.net wrote: That is intentional. The gthr-rdos.h file is part of libgcc. My intention was to first patch gcc, then update the patches for newlib, and finally libgcc. The gthr-rdos.h file would reference include-files part of newlib, so this is kind of circular. I also cannot define the thread model for RDOS unless I define this file. I see a couple of possible solutions: 1. Keep as is. You cannot build libgcc at the current stage anyway, and the bootstrap must be built without threading 2. Add an empty gthr-rdos.h file until libgcc is done 3. Remove the threading-model for now, and add it with libgcc instead. I propose option 3. Is it enough to remove gthr.m4 change from the patch in this case? Yes, for all practical purposes. There is a reference to thread-file in config.gcc, when threading is enabled, which doesn't work for bootstrapping the compiler anyway. Thanks for pointing it, I have also removed this reference. Attached is the patch that has been committed to SVN. I have added missing licence headers to new files and clean whitespace a bit. 2013-01-28 Leif Ekblad l...@rdos.net * config.gcc (i[34567]86-*-rdos*, x86_64-*-rdos*): New targets. * config/i386/i386.h (TARGET_RDOS): New macro. (DEFAULT_LARGE_SECTION_THRESHOLD): New macro. * config/i386/i386.c (ix86_option_override_internal): For 64bit TARGET_RDOS, set ix86_cmodel to CM_MEDIUM_PIC and flag_pic to 1. * config/i386/i386.opt (mlarge-data-threshold): Initialize to DEFAULT_LARGE_SECTION_THRESHOLD. * config/i386/i386.md (R14_REG, R15_REG): New constants. * config/i386/rdos.h: New file. * config/i386/rdos64.h: New file. Thanks, Uros.
Re: [PATCH 1/2] [asan] Allow creating/deleting hash table entries with new/delete
On 1/28/13, Dodji Seketeli do...@redhat.com wrote:
Hello,
The hash table type can handle creation and removal of entries with
malloc/free. This patchlet adds support for using new/delete. It's
useful for hash table entry types that have constructors (and/or
destructors), to prevent the user from having to type boilerplate code
to initialize them over and over again. This is used by the patch that
follows this one.
Looks good to me.
gcc/
* hash-table.h (struct typed_delete_remove): New type.
(typed_delete_remove::remove): Implement this using the delete
operator.
---
gcc/hash-table.h | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index 206423d..884840c 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -235,6 +235,22 @@ typed_free_remove Type::remove (Type *p)
free (p);
}
+/* Helpful type for removing entries with the delete operator. */
+
+template typename Type
+struct typed_delete_remove
+{
+ static inline void remove (Type *p);
+};
+
+/* Remove with delete. */
+
+template typename Type
+inline void
+typed_delete_remove Type::remove (Type *p)
+{
+ delete p;
+}
/* Helpful type for a no-op remove. */
--
1.7.11.7
--
Dodji
--
Lawrence Crowl
Re: [SH] PR 56121 - fix libgcc build for SH2A
Oleg Endo oleg.e...@t-online.de wrote:
This is the same patch that I attached in the PR.
It fixes an ICE when building libgcc for the SH2A target.
Tested on rev. 195493 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
... comparing the test results against rev 193342 shows a few new
failures, but they seem unrelated to this case.
OK for trunk?
OK.
Regards,
kaz
[4.9 PATCH, alpha]: Switch alpha to LRA
Hello! 2013-01-28 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.c (TARGET_LRA_P): New define. Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu. OK for 4.9? [1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02998.html Uros. Index: config/alpha/alpha.c === --- config/alpha/alpha.c(revision 195502) +++ config/alpha/alpha.c(working copy) @@ -9872,6 +9872,9 @@ #undef TARGET_LEGITIMATE_ADDRESS_P #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p +#undef TARGET_LRA_P +#define TARGET_LRA_P hook_bool_void_true + #undef TARGET_CONDITIONAL_REGISTER_USAGE #define TARGET_CONDITIONAL_REGISTER_USAGE alpha_conditional_register_usage
Re: [4.9 PATCH, alpha]: Switch alpha to LRA
On 01/28/2013 03:14 PM, Uros Bizjak wrote: 2013-01-28 Uros Bizjakubiz...@gmail.com * config/alpha/alpha.c (TARGET_LRA_P): New define. Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu. OK for 4.9? Yep. r~
gccgo patch committed: Fix initialization order bug
This patch to the Go frontend fixes a bug determining the initialization
order. I've committed a test case for the bug to the master Go
repository:
https://code.google.com/p/go/source/detail?spec=svn921e53d4863c8827756c0e7b228ab210441e4032r=c3155f9f1bb64c8b3adb2b6f5527895d51f83b74
The old algorithm was overly clever and frankly I don't know what I was
thinking. The new algorithm is simpler and probably more efficient.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r ee18ff1199b6 go/expressions.h
--- a/go/expressions.h Fri Jan 25 16:13:13 2013 -0800
+++ b/go/expressions.h Mon Jan 28 16:23:26 2013 -0800
@@ -983,6 +983,11 @@
statement_(statement), is_lvalue_(false)
{ }
+ // The temporary that this expression refers to.
+ Temporary_statement*
+ statement() const
+ { return this-statement_; }
+
// Indicate that this reference appears on the left hand side of an
// assignment statement.
void
diff -r ee18ff1199b6 go/gogo-tree.cc
--- a/go/gogo-tree.cc Fri Jan 25 16:13:13 2013 -0800
+++ b/go/gogo-tree.cc Mon Jan 28 16:23:26 2013 -0800
@@ -499,7 +499,7 @@
// A hash table we use to avoid looping. The index is the name of a
// named object. We only look through objects defined in this
// package.
- typedef Unordered_set(std::string) Seen_objects;
+ typedef Unordered_set(const void*) Seen_objects;
Find_var(Named_object* var, Seen_objects* seen_objects)
: Traverse(traverse_expressions),
@@ -547,7 +547,7 @@
if (init != NULL)
{
std::pairSeen_objects::iterator, bool ins =
- this-seen_objects_-insert(v-name());
+ this-seen_objects_-insert(v);
if (ins.second)
{
// This is the first time we have seen this name.
@@ -568,7 +568,7 @@
if (f-is_function() f-package() == NULL)
{
std::pairSeen_objects::iterator, bool ins =
- this-seen_objects_-insert(f-name());
+ this-seen_objects_-insert(f);
if (ins.second)
{
// This is the first time we have seen this name.
@@ -578,6 +578,25 @@
}
}
+ Temporary_reference_expression* tre = e-temporary_reference_expression();
+ if (tre != NULL)
+{
+ Temporary_statement* ts = tre-statement();
+ Expression* init = ts-init();
+ if (init != NULL)
+ {
+ std::pairSeen_objects::iterator, bool ins =
+ this-seen_objects_-insert(ts);
+ if (ins.second)
+ {
+ // This is the first time we have seen this temporary
+ // statement.
+ if (Expression::traverse(init, this) == TRAVERSE_EXIT)
+ return TRAVERSE_EXIT;
+ }
+ }
+}
+
return TRAVERSE_CONTINUE;
}
@@ -613,11 +632,11 @@
{
public:
Var_init()
-: var_(NULL), init_(NULL_TREE), waiting_(0)
+: var_(NULL), init_(NULL_TREE)
{ }
Var_init(Named_object* var, tree init)
-: var_(var), init_(init), waiting_(0)
+: var_(var), init_(init)
{ }
// Return the variable.
@@ -630,24 +649,11 @@
init() const
{ return this-init_; }
- // Return the number of variables waiting for this one to be
- // initialized.
- size_t
- waiting() const
- { return this-waiting_; }
-
- // Increment the number waiting.
- void
- increment_waiting()
- { ++this-waiting_; }
-
private:
// The variable being initialized.
Named_object* var_;
// The initialization expression to run.
tree init_;
- // The number of variables which are waiting for this one.
- size_t waiting_;
};
typedef std::listVar_init Var_inits;
@@ -660,6 +666,10 @@
static void
sort_var_inits(Gogo* gogo, Var_inits* var_inits)
{
+ typedef std::pairNamed_object*, Named_object* No_no;
+ typedef std::mapNo_no, bool Cache;
+ Cache cache;
+
Var_inits ready;
while (!var_inits-empty())
{
@@ -670,23 +680,30 @@
Named_object* dep = gogo-var_depends_on(var-var_value());
// Start walking through the list to see which variables VAR
- // needs to wait for. We can skip P1-WAITING variables--that
- // is the number we've already checked.
+ // needs to wait for.
Var_inits::iterator p2 = p1;
++p2;
- for (size_t i = p1-waiting(); i 0; --i)
- ++p2;
for (; p2 != var_inits-end(); ++p2)
{
Named_object* p2var = p2-var();
- if (expression_requires(init, preinit, dep, p2var))
+ No_no key(var, p2var);
+ std::pairCache::iterator, bool ins =
+ cache.insert(std::make_pair(key, false));
+ if (ins.second)
+ ins.first-second = expression_requires(init, preinit, dep, p2var);
+ if (ins.first-second)
{
// Check for cycles.
- if (expression_requires(p2var-var_value()-init(),
+ key = std::make_pair(p2var, var);
+ ins = cache.insert(std::make_pair(key, false));
+ if (ins.second)
+ ins.first-second =
+ expression_requires(p2var-var_value()-init(),
p2var-var_value()-preinit(),
gogo-var_depends_on(p2var-var_value()),
- var))
+ var);
+ if (ins.first-second)
{
Re: [4.9 PATCH, alpha]: Switch alpha to LRA
On 01/28/2013 04:14 PM, Uros Bizjak wrote: Hello! 2013-01-28 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.c (TARGET_LRA_P): New define. Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu. OK for 4.9? [1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02998.html Can you attach this to PR 55996, the 4.9 pending patches metabug. Thanks, jeff
Re: [Patch,avr] Remove fixed-point MUL and DIV routines from libgcc build
2013/1/28 Georg-Johann Lay a...@gjlay.de: This removes modules from libgcc that are already supported by avr-specific fixed-point implementation and avoids duplicate functions like __mulsa3. Ok for trunk? Johann libgcc/ * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add: _mulQQ, _mulHQ, _mulHA, _mulSA, _mulUQQ, _mulUHQ, _mulUHA, _mulUSA, _divQQ, _divHQ, _divHA, _divSA, _divUQQ, _divUHQ, _divUHA, _divUSA. Approved. Denis.
Ping: [Patch] PR56064: Fold VIEW_CONVERT_EXPR with FIXED_CST
Ping #1 for
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01053.html
Release Manager approval is here:
http://gcc.gnu.org/ml/gcc/2013-01/msg00222.html
This is tentative patch as discussed in
http://gcc.gnu.org/ml/gcc/2013-01/msg00187.html
fold-const.c gets 2 new function native_encode_fixed and
native_interpret_fixed. Code common with the integer case is factored out and
moved to the new constructor-like function double_int::from_buffer.
The code bootstraps fine on x86-linux-gnu and I have test coverage from
avr-unknown-none.
Ok to apply?
There are less intrusive solutions that only handle the int - fixed cases,
for example fold-const.c:fold_view_convert_expr() could test for these cases
and use double_int directly without serializing / deserializing through a
memory buffer.
Johann
PR tree-optimization/56064
* fixed-value.c (const_fixed_from_double_int): New function.
* fixed-value.h (const_fixed_from_double_int): New prototype.
* fold-const.c (native_interpret_fixed): New static function.
(native_interpret_expr) FIXED_POINT_TYPE: Use it.
(can_native_interpret_type_p) FIXED_POINT_TYPE: Return true.
(native_encode_fixed): New static function.
(native_encode_expr) FIXED_CST: Use it.
(native_interpret_int): Move double_int worker code to...
* double-int.c (double_int::from_buffer): ...this new static method.
* double-int.h (double_int::from_buffer): Prototype it.
testsuite/
PR tree-optimization/56064
* gcc.dg/fixed-point/view-convert.c: New test.
Index: fixed-value.c
===
--- fixed-value.c (revision 195301)
+++ fixed-value.c (working copy)
@@ -81,6 +81,24 @@ check_real_for_fixed_mode (REAL_VALUE_TY
return FIXED_OK;
}
+
+/* Construct a CONST_FIXED from a bit payload and machine mode MODE.
+ The bits in PAYLOAD are used verbatim. */
+
+FIXED_VALUE_TYPE
+const_fixed_from_double_int (double_int payload, enum machine_mode mode)
+{
+ FIXED_VALUE_TYPE value;
+
+ gcc_assert (GET_MODE_BITSIZE (mode) = HOST_BITS_PER_DOUBLE_INT);
+
+ value.data = payload;
+ value.mode = mode;
+
+ return value;
+}
+
+
/* Initialize from a decimal or hexadecimal string. */
void
Index: fixed-value.h
===
--- fixed-value.h (revision 195301)
+++ fixed-value.h (working copy)
@@ -49,6 +49,11 @@ extern FIXED_VALUE_TYPE fconst1[MAX_FCON
const_fixed_from_fixed_value (r, m)
extern rtx const_fixed_from_fixed_value (FIXED_VALUE_TYPE, enum machine_mode);
+/* Construct a CONST_FIXED from a bit payload and machine mode MODE.
+ The bits in PAYLOAD are used verbatim. */
+extern FIXED_VALUE_TYPE const_fixed_from_double_int (double_int,
+enum machine_mode);
+
/* Initialize from a decimal or hexadecimal string. */
extern void fixed_from_string (FIXED_VALUE_TYPE *, const char *,
enum machine_mode);
Index: fold-const.c
===
--- fold-const.c(revision 195301)
+++ fold-const.c(working copy)
@@ -7200,6 +7200,36 @@ native_encode_int (const_tree expr, unsi
}
+/* Subroutine of native_encode_expr. Encode the FIXED_CST
+ specified by EXPR into the buffer PTR of length LEN bytes.
+ Return the number of bytes placed in the buffer, or zero
+ upon failure. */
+
+static int
+native_encode_fixed (const_tree expr, unsigned char *ptr, int len)
+{
+ tree type = TREE_TYPE (expr);
+ enum machine_mode mode = TYPE_MODE (type);
+ int total_bytes = GET_MODE_SIZE (mode);
+ FIXED_VALUE_TYPE value;
+ tree i_value, i_type;
+
+ if (total_bytes * BITS_PER_UNIT HOST_BITS_PER_DOUBLE_INT)
+return 0;
+
+ i_type = lang_hooks.types.type_for_size (GET_MODE_BITSIZE (mode), 1);
+
+ if (NULL_TREE == i_type
+ || TYPE_PRECISION (i_type) != total_bytes)
+return 0;
+
+ value = TREE_FIXED_CST (expr);
+ i_value = double_int_to_tree (i_type, value.data);
+
+ return native_encode_int (i_value, ptr, len);
+}
+
+
/* Subroutine of native_encode_expr. Encode the REAL_CST
specified by EXPR into the buffer PTR of length LEN bytes.
Return the number of bytes placed in the buffer, or zero
@@ -7345,6 +7375,9 @@ native_encode_expr (const_tree expr, uns
case REAL_CST:
return native_encode_real (expr, ptr, len);
+case FIXED_CST:
+ return native_encode_fixed (expr, ptr, len);
+
case COMPLEX_CST:
return native_encode_complex (expr, ptr, len);
@@ -7368,44 +7401,37 @@ static tree
native_interpret_int (tree type, const unsigned char *ptr, int len)
{
int total_bytes = GET_MODE_SIZE (TYPE_MODE (type));
- int byte, offset, word, words;
- unsigned char value;
double_int result;
- if (total_bytes len)
-return NULL_TREE;
- if (total_bytes * BITS_PER_UNIT
