Patch ping
Hi! I'd like to ping a few unreviewed patches: - use libbacktrace in libsanitizer symbolization - PR sanitizer/59136 http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00558.html - allow building libsanitizer against older kernel headers http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00963.html - use cp-demangle as libsanitizer+libbacktrace demangler http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00964.html (note, Gary has already committed his fix, so the demangler is now really malloc/calloc/realloc call free) - ifcvt/crossjumping fix - PR rtl-optimization/58668 http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01726.html (note, Eric approved earlier version of the patch but Steven wanted to use active_insn_p instead, haven't committed anything yet, waiting to see what should be committed) - improve Scimark2 SOR by 42% through small predcom change - PR tree-optimization/59643 http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01986.html - fix up PCH - PR pch/59436 http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00016.html (note, as pointed out by Mike in followup, what I'd like to commit is a version with s/(void *) // in the patch, already bootstrapped/regtested) Jakub
Re: [PATCH] Fix PR58115
Bernd Edlinger writes:
> Hello,
>
> on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails
> because of
> an internal compiler error, see PR58155.
>
> The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
> should be enabled.
>
> This happens because invoke_set_current_function_hook changes the pointer
> "this_fn_optabs" after targetm.set_current_function has already modified the
> optab to enable/disable CODE_FOR_movv8sf, leaving that optab entry
> in an undefined state.
>
> Boot-strapped and regression-tested on i686-pc-linux-gnu.
>
> Ok for trunk?
>
> Regards
> Bernd.
>
>
> Index: gcc/function.c
> ===
> --- gcc/function.c(revision 204101)
> +++ gcc/function.c(working copy)
> @@ -4426,7 +4426,6 @@ invoke_set_current_function_hook (tree fndecl)
> cl_optimization_restore (&global_options, TREE_OPTIMIZATION (opts));
> }
>
> - targetm.set_current_function (fndecl);
>this_fn_optabs = this_target_optabs;
>
>if (opts != optimization_default_node)
> @@ -4436,6 +4435,8 @@ invoke_set_current_function_hook (tree fndecl)
> this_fn_optabs = (struct target_optabs *)
> TREE_OPTIMIZATION_OPTABS (opts);
> }
> +
> + targetm.set_current_function (fndecl);
> }
> }
>
Sorry for only realising now, but this breaks the mips16 attribute.
The idea with the old order was that set_current_function would set
up this_target, then that choice would percolate through.
I don't think the patch is really correct for i386 either. Although
it fixes the intrinsics_4.c test for -m32, it fails for this extended
version, both with and without -m32:
#include
__m256 a[10], b[10], c[10];
void __attribute__((target ("avx")))
foo (void)
{
a[0] = _mm256_and_ps (b[0], c[0]);
}
void __attribute__((target ("avx"), optimize (3)))
bar (void)
{
a[0] = _mm256_and_ps (b[0], c[0]);
}
The failure without -m32 is a regression from before the patch.
i386.c tries to detect when we're moving between different target options
and when a target_reinit is needed, but it doesn't take into account the
fact that optabs are cached on a per-optimisation-node basis. It's
possible to move between functions with the same target node but
different optimisation nodes. With the old order this wasn't
really something i386.c should have to worry about, since it was
invoke_set_current_function that handled optimisation nodes.
But with the new order i386.c would need to reinitialise at least
the optabs when moving between functions with the same target node
but different optimisation nodes. And I'd really rather not force
every target that uses DECL_FUNCTION_SPECIFIC_TARGET to copy-&-paste
the code to do that.
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
Thanks,
Richard
Re: [Patch, Fortran] PR 59023: [4.9 regression] ICE in gfc_search_interface with BIND(C)
Dear Janus, dear all, Happy New Year! The patch is OK for trunk. Thanks a lot. Paul On 3 January 2014 10:29, Janus Weil wrote: > In addition this patch fixes PR 59662. > > Also: Ping! > > Cheers, > Janus > > > > 2013/12/31 Janus Weil : >> Hi all, >> >> ... and the reg-bashing continues: Here is a small patch to fix a >> bind(c) problem. It essentially prevents 'resolve_global_procedure' to >> be applied to bind(c) procedures. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >> >> Cheers, >> Janus >> >> >> >> 2013-12-31 Janus Weil >> >> PR fortran/59023 >> * resolve.c (resolve_global_procedure): Don't apply to c-binding >> procedures. >> (gfc_verify_binding_labels): Remove duplicate line. >> >> 2013-12-31 Janus Weil >> >> PR fortran/59023 >> * gfortran.dg/bind_c_procs_2.f90: New. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH] Fix PR58115
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote: > Of course, IMO, the cleanest fix would be to use switchable targets > for i386... We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons to compile because even with just a few routines in a CU there are hundreds or thousands of IRA reinitializations. Jakub
Fix PR debug/59350
This is the ICE on the checking assertion for ONEPART_VALUEs at the beginning
of vt_expand_var_loc_chain. The assertion looks a bit overzealous to me: it
triggers here because we don't record a SET in add_stores, but only because we
don't preserve the source: the source is a zero-extension of something and
cselib manages to record an equivalence between the value of this something
and the truncation of the value of the source(!) by the mere virtue of the
existence of the source (see cselib.c:2013 and below). Not sure why we would
need to preserve it if we don't use it, but that's very likely simpler.
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2014-01-06 Eric Botcazou
PR debug/59350
PR debug/59510
* var-tracking.c (add_stores): Preserve the value of the source even if
we don't record the store.
2014-01-06 Eric Botcazou
* gcc.dg/pr59350-2.c: New test.
* g++.dg/pr59510.C: Likewise.
--
Eric BotcazouIndex: var-tracking.c
===
--- var-tracking.c (revision 206336)
+++ var-tracking.c (working copy)
@@ -5930,6 +5930,13 @@ add_stores (rtx loc, const_rtx expr, voi
if (type != MO_VAL_SET)
goto log_and_return;
+ v = find_use_val (oloc, mode, cui);
+
+ if (!v)
+goto log_and_return;
+
+ resolve = preserve = !cselib_preserved_value_p (v);
+
/* We cannot track values for multiple-part variables, so we track only
locations for tracked parameters passed either by invisible reference
or directly in multiple locations. */
@@ -5943,14 +5950,15 @@ add_stores (rtx loc, const_rtx expr, voi
&& XEXP (DECL_INCOMING_RTL (REG_EXPR (loc)), 0) != arg_pointer_rtx)
|| (GET_CODE (DECL_INCOMING_RTL (REG_EXPR (loc))) == PARALLEL
&& XVECLEN (DECL_INCOMING_RTL (REG_EXPR (loc)), 0) > 1)))
-goto log_and_return;
-
- v = find_use_val (oloc, mode, cui);
-
- if (!v)
-goto log_and_return;
-
- resolve = preserve = !cselib_preserved_value_p (v);
+{
+ /* Although we don't use the value here, it could be used later by the
+ mere virtue of its existence as the operand of the reverse operation
+ that gave rise to it (typically extension/truncation). Make sure it
+ is preserved as required by vt_expand_var_loc_chain. */
+ if (preserve)
+ preserve_value (v);
+ goto log_and_return;
+}
if (loc == stack_pointer_rtx
&& hard_frame_pointer_adjustment != -1/* PR debug/59350 */
/* { dg-do compile } */
/* { dg-options "-O -g " } */
typedef struct
{
void *v;
int len;
int sign;
} ZVALUE;
extern int pred (ZVALUE);
static unsigned long
small_factor (ZVALUE z)
{
if (z.len > 0)
return 0;
return pred (z) ? -1 : 0;
}
unsigned long
zfactor (ZVALUE z)
{
z.sign = 0;
return small_factor (z);
}// PR debug/59510
// { dg-do compile }
// { dg-options "-O2 -g --param=large-stack-frame-growth=1" }
template
struct _Iter_base
{
typedef _Iterator iterator_type;
};
template
struct basic_ostream;
template
struct basic_ostringstream;
template
struct ostreambuf_iterator;
typedef basic_ostringstream ostringstream;
template struct _Miter_base : _Iter_base <_Iterator>
{
};
template
typename _Miter_base <_Iterator>::iterator_type __miter_base (_Iterator);
template
ostreambuf_iterator <_CharT>
__copy_move_a2 (ostreambuf_iterator <_CharT>);
template
_OI copy (_II __first, _II __last, _OI __result)
{
__copy_move_a2 (__first, __miter_base (__last), __result);
}
struct ios_base {
struct _Words {
int *_M_pword;
long _M_iword;
};
_Words _M_local_word[8];
};
template
struct basic_streambuf
{
typedef _CharT char_type;
int sputn (char_type *, int);
};
template
struct ostreambuf_iterator
{
typedef basic_streambuf <_CharT> streambuf_type;
typedef basic_ostream <_CharT> ostream_type;
streambuf_type *_M_sbuf;
bool _M_failed;
ostreambuf_iterator (ostream_type __s) : _M_sbuf (__s.rdbuf ()), _M_failed () {}
void _M_put (_CharT * __ws, int __len)
{
if (_M_failed && _M_sbuf->sputn (__ws, __len) != __len) _M_failed = true;
}
};
template
void __copy_move_a2 (_CharT * __first,_CharT * __last,ostreambuf_iterator <_CharT> __result)
{
int __num = __last - __first;
__result._M_put (__first, __num);
}
template
struct basic_ios : ios_base
{
basic_streambuf <_CharT> *rdbuf ();
};
template
struct basic_ostream : public basic_ios <_CharT>
{
};
template
struct basic_ostringstream : public basic_ostream <_CharT>
{
};
void
test01 () {
char data1[] = "foo";
char *beg1 = data1;
ostringstream oss1;
ostreambuf_iterator out1 (oss1);
out1 = copy (beg1, beg1, out1);
}
Re: [C PATCH] Don't pedwarn for C99/C11 enum bit-fields (PR c/57773)
On Fri, Jan 03, 2014 at 05:17:28PM +, Joseph S. Myers wrote:
> Implementation-defined behavior is documented in implement-c.texi, so this
> patch is incomplete as it doesn't update that file where it says:
>
> No other types are permitted in strictly conforming mode.
> @c Would it be better to restrict the pedwarn for other types to C90
> @c mode and document the other types for C99/C11 mode?
Sorry for missing this one.
> (And this isn't just about enums, but other integer types as well, so the
> test should cover those.)
I've put some more types in the test.
Ok now? Thanks,
2014-01-06 Marek Polacek
PR c/57773
* doc/implement-c.texi: Mention that other integer types are
permitted as bit-field types in strictly conforming mode.
c/
* c-decl.c (check_bitfield_type_and_width): Warn for implementation
defined bit-field types only in ISO C.
testsuite/
* gcc.dg/pr57773.c: New test.
--- gcc/doc/implement-c.texi.mp 2014-01-03 18:22:47.320742545 +0100
+++ gcc/doc/implement-c.texi2014-01-06 12:34:02.280756348 +0100
@@ -479,9 +479,8 @@ by the @option{-funsigned-bitfields} opt
@cite{Allowable bit-field types other than @code{_Bool}, @code{signed int},
and @code{unsigned int} (C99 and C11 6.7.2.1).}
-No other types are permitted in strictly conforming mode.
-@c Would it be better to restrict the pedwarn for other types to C90
-@c mode and document the other types for C99/C11 mode?
+Other integer types, such as @code{long int}, and enumerated types are
+permitted even in strictly conforming mode.
@item
@cite{Whether atomic types are permitted for bit-fields (C11 6.7.2.1).}
--- gcc/c/c-decl.c.mp 2014-01-03 13:50:37.041997222 +0100
+++ gcc/c/c-decl.c 2014-01-03 14:46:29.115816235 +0100
@@ -4840,7 +4840,8 @@ check_bitfield_type_and_width (tree *typ
if (!in_system_header_at (input_location)
&& type_mv != integer_type_node
&& type_mv != unsigned_type_node
- && type_mv != boolean_type_node)
+ && type_mv != boolean_type_node
+ && !flag_isoc99)
pedwarn (input_location, OPT_Wpedantic,
"type of bit-field %qs is a GCC extension", name);
--- gcc/testsuite/gcc.dg/pr57773.c.mp 2014-01-03 14:50:51.097902818 +0100
+++ gcc/testsuite/gcc.dg/pr57773.c 2014-01-06 12:34:24.0 +0100
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c99 -Wpedantic" } */
+
+enum e { A };
+struct { enum e b: 2; } s1;
+struct { signed char b: 2; } s2;
+struct { unsigned char b: 2; } s3;
+struct { short b: 2; } s4;
+struct { unsigned short b: 2; } s5;
+struct { long int b: 2; } s6;
+struct { unsigned long int b: 2; } s7;
+struct { long long int b: 2; } s8;
+struct { unsigned long long int b: 2; } s9;
Marek
[PATCH][AArch64] Vector shift by 64 fix
Hi,
This patch fixes vector shift by 64 behavior to meet reference
manual expectations. Testcase included to check that expectations
are now met. No regressions found.
Is patch OK?
Thanks,
Alex
2014-01-06 Alex Velenko
gcc/
* config/aarch64/aarch64-simd-builtins.def (ashr): DI mode removed.
(ashr_simd): New builtin handling DI mode.
* config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): New pattern.
(aarch64_sshr_simddi): New match pattern.
* config/aarch64/arm_neon.h (vshr_n_s32): Builtin call modified.
(vshrd_n_s64): Likewise.
* config/aarch64/predicates.md (aarch64_shift_imm64_di): New predicate.
gcc/testsuite/
* gcc.target/aarch64/sshr64_1.c: New testcase.
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index 1dc3c1fe33fdb8148d2ff9c7198e4d85d5dac5d7..1e88661fd2f0f756ce1427681c843fc0783ab6a2 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -189,7 +189,8 @@
BUILTIN_VSDQ_I_DI (BINOP, srshl, 0)
BUILTIN_VSDQ_I_DI (BINOP, urshl, 0)
- BUILTIN_VSDQ_I_DI (SHIFTIMM, ashr, 3)
+ BUILTIN_VDQ_I (SHIFTIMM, ashr, 3)
+ VAR1 (SHIFTIMM, ashr_simd, 0, di)
BUILTIN_VSDQ_I_DI (SHIFTIMM, lshr, 3)
/* Implemented by aarch64_shr_n. */
BUILTIN_VSDQ_I_DI (SHIFTIMM, srshr_n, 0)
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 158b3dca6da12322de0af80d35f593039d716de6..839186a5e3e3363973186d68aeed6fbaf7f0dfea 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -668,6 +668,32 @@
DONE;
})
+;; DI vector shift
+(define_expand "aarch64_ashr_simddi"
+ [(match_operand:DI 0 "register_operand" "=w")
+ (match_operand:DI 1 "register_operand" "w")
+ (match_operand:QI 2 "aarch64_shift_imm64_di" "")]
+ "TARGET_SIMD"
+ {
+if (INTVAL (operands[2]) == 64)
+ emit_insn (gen_aarch64_sshr_simddi (operands[0], operands[1]));
+else
+ emit_insn (gen_ashrdi3 (operands[0], operands[1], operands[2]));
+DONE;
+ }
+)
+
+;; SIMD shift by 64. This pattern is a special case as standard pattern does
+;; not handle NEON shifts by 64.
+(define_insn "aarch64_sshr_simddi"
+ [(set (match_operand:DI 0 "register_operand" "=w")
+(unspec:DI
+ [(match_operand:DI 1 "register_operand" "w")] UNSPEC_SSHR64))]
+ "TARGET_SIMD"
+ "sshr\t%d0, %d1, 64"
+ [(set_attr "type" "neon_shift_imm")]
+)
+
(define_expand "vlshr3"
[(match_operand:VQ_S 0 "register_operand" "")
(match_operand:VQ_S 1 "register_operand" "")
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 8b3dbd7550e8e9037de1a1384276bee28d21cb3d..130a11c0231c32440573276fd78e62b6f019d302 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -92,6 +92,7 @@
UNSPEC_SISD_SSHL
UNSPEC_SISD_USHL
UNSPEC_SSHL_2S
+UNSPEC_SSHR64
UNSPEC_ST2
UNSPEC_ST3
UNSPEC_ST4
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 03549bd7a27cccb14ed8cdce91cbd4e4278c273f..64012775b3fa7d174af1472f73aadf4174d0d291 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -23235,7 +23235,7 @@ vshr_n_s32 (int32x2_t __a, const int __b)
__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
vshr_n_s64 (int64x1_t __a, const int __b)
{
- return (int64x1_t) __builtin_aarch64_ashrdi (__a, __b);
+ return (int64x1_t) __builtin_aarch64_ashr_simddi (__a, __b);
}
__extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
@@ -23313,7 +23313,7 @@ vshrq_n_u64 (uint64x2_t __a, const int __b)
__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
vshrd_n_s64 (int64x1_t __a, const int __b)
{
- return (int64x1_t) __builtin_aarch64_ashrdi (__a, __b);
+ return (int64x1_t) __builtin_aarch64_ashr_simddi (__a, __b);
}
__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
diff --git a/gcc/config/aarch64/predicates.md b/gcc/config/aarch64/predicates.md
index dbc90826665d19a6ac6131918efb2c8a32bd1f04..9538107a5c148408f5c6e8e37aeef92aa5be0856 100644
--- a/gcc/config/aarch64/predicates.md
+++ b/gcc/config/aarch64/predicates.md
@@ -86,6 +86,10 @@
(and (match_code "const_int")
(match_test "(unsigned HOST_WIDE_INT) INTVAL (op) < 64")))
+(define_predicate "aarch64_shift_imm64_di"
+ (and (match_code "const_int")
+ (match_test "(unsigned HOST_WIDE_INT) INTVAL (op) <= 64")))
+
(define_predicate "aarch64_reg_or_shift_imm_si"
(ior (match_operand 0 "register_operand")
(match_operand 0 "aarch64_shift_imm_si")))
diff --git a/gcc/testsuite/gcc.target/aarch64/sshr64_1.c b/gcc/testsuite/gcc.target/aarch64/sshr64_1.c
new file mode 100644
index ..89c6096ad3934d1c42fac2c8fba6eba6170762da
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sshr6
Re: [PATCH] Fix PR58115
Jakub Jelinek wrote: >On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote: >> Of course, IMO, the cleanest fix would be to use switchable targets >> for i386... > >We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons >to >compile because even with just a few routines in a CU there are >hundreds or >thousands of IRA reinitializations. We also want a big fat comment before the non-obvious order of inits when switching cfuns. Bernd, please revert your patch for now. Thanks, Richard. > Jakub
[PATCH, AArch64] Use llfloor and llceil for vcvtmd_s64_f64 and vcvtpd_s64_f64 in arm_neon.h
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64
in arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
This patch will fix the following test failure in the ILP32 mode:
FAIL: gcc.target/aarch64/vect-vcvt.c scan-assembler fcvtms\\tx[0-9]+,
d[0-9]+
OK for the trunk?
Thanks,
Yufeng
gcc/
* config/aarch64/aarch64-builtins.c
(aarch64_builtin_vectorized_function): Add BUILT_IN_LFLOORF,
BUILT_IN_LLFLOOR, BUILT_IN_LCEILF and BUILT_IN_LLCEIL.
* config/aarch64/arm_neon.h (vcvtaq_u64_f64): Call __builtin_llfloor
instead of __builtin_lfloor.
(vcvtnq_u64_f64): Call __builtin_llceil instead of __builtin_lceil.diff --git a/gcc/config/aarch64/aarch64-builtins.c
b/gcc/config/aarch64/aarch64-builtins.c
index 439c3f4..27af30f 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1034,6 +1034,8 @@ aarch64_builtin_vectorized_function (tree fndecl, tree
type_out, tree type_in)
(out_mode == N##Imode && out_n == C \
&& in_mode == N##Fmode && in_n == C)
case BUILT_IN_LFLOOR:
+ case BUILT_IN_LFLOORF:
+ case BUILT_IN_LLFLOOR:
case BUILT_IN_IFLOORF:
{
enum aarch64_builtins builtin;
@@ -1049,6 +1051,8 @@ aarch64_builtin_vectorized_function (tree fndecl, tree
type_out, tree type_in)
return aarch64_builtin_decls[builtin];
}
case BUILT_IN_LCEIL:
+ case BUILT_IN_LCEILF:
+ case BUILT_IN_LLCEIL:
case BUILT_IN_ICEILF:
{
enum aarch64_builtins builtin;
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index e33a684..c855b0f 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -17699,7 +17699,7 @@ vcvtaq_u64_f64 (float64x2_t __a)
__extension__ static __inline int64_t __attribute__ ((__always_inline__))
vcvtmd_s64_f64 (float64_t __a)
{
- return __builtin_lfloor (__a);
+ return __builtin_llfloor (__a);
}
__extension__ static __inline uint64_t __attribute__ ((__always_inline__))
@@ -17835,7 +17835,7 @@ vcvtnq_u64_f64 (float64x2_t __a)
__extension__ static __inline int64_t __attribute__ ((__always_inline__))
vcvtpd_s64_f64 (float64_t __a)
{
- return __builtin_lceil (__a);
+ return __builtin_llceil (__a);
}
__extension__ static __inline uint64_t __attribute__ ((__always_inline__))
[testsuite, i386] Declare fma in gcc.target/i386/pr59390.c
The new Declare fma in gcc.target/i386/pr59390*.c tests were FAILing on
Solaris 9/x86, which lacks C99 support:
FAIL: gcc.target/i386/pr59390.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr59390.c:12:9: warnin
g: implicit declaration of function 'fma' [-Wimplicit-function-declaration]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr59390.c:12:18: warni
ng: incompatible implicit declaration of built-in function 'fma' [enabled by def
ault]
This patch fixes this by declaring fma() directly instead of relying on
, like many other testcases already do.
Tested on i386-pc-solaris2.9, i386-pc-solaris2.10, and
x86_64-unknown-linux-gnu, installed on mainline.
Rainer
2014-01-06 Rainer Orth
* gcc.target/i386/pr59390.c: Replace math.h by fma declaration.
* gcc.target/i386/pr59390_1.c: Likewise.
* gcc.target/i386/pr59390_2.c: Likewise.
# HG changeset patch
# Parent 756e0ac368a0ebe940873aa37cdf510600f32bef
Declare fma in gcc.target/i386/pr59390.c
diff --git a/gcc/testsuite/gcc.target/i386/pr59390.c b/gcc/testsuite/gcc.target/i386/pr59390.c
--- a/gcc/testsuite/gcc.target/i386/pr59390.c
+++ b/gcc/testsuite/gcc.target/i386/pr59390.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-std=c99 -O3" } */
-#include "math.h"
+extern double fma (double, double, double);
void fun() __attribute__((target("fma")));
void
diff --git a/gcc/testsuite/gcc.target/i386/pr59390_1.c b/gcc/testsuite/gcc.target/i386/pr59390_1.c
--- a/gcc/testsuite/gcc.target/i386/pr59390_1.c
+++ b/gcc/testsuite/gcc.target/i386/pr59390_1.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-std=c99 -O3" } */
-#include "math.h"
+extern double fma (double, double, double);
void fun() __attribute__((target("fma")));
__attribute__((target("fma")))
diff --git a/gcc/testsuite/gcc.target/i386/pr59390_2.c b/gcc/testsuite/gcc.target/i386/pr59390_2.c
--- a/gcc/testsuite/gcc.target/i386/pr59390_2.c
+++ b/gcc/testsuite/gcc.target/i386/pr59390_2.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-std=c99 -O3 -mfma" } */
-#include "math.h"
+extern double fma (double, double, double);
void fun() __attribute__((target("fma")));
void
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
The new gcc.target/i386/pr59501-*.c tests were FAILing on Solaris 9/x86
with Sun as:
FAIL: gcc.target/i386/pr59501-1.c (test for excess errors)
Excess errors:
Assembler: pr59501-1.c
"/var/tmp//cclOtnd2.s", line 28 : Illegal mnemonic
"/var/tmp//cclOtnd2.s", line 28 : Syntax error
and many more. Obviously they need an assembler with avx support. Fixed
by requiring an avx effective-target.
Tested on i386-pc-solaris2.9, i386-pc-solaris2.10, and
x86_64-unknown-linux-gnu; installed on mainline.
Rainer
2014-01-03 Rainer Orth
* gcc.target/i386/pr59501-1.c: Require avx effective target.
* gcc.target/i386/pr59501-2.c: Likewise.
* gcc.target/i386/pr59501-3.c: Likewise.
* gcc.target/i386/pr59501-4.c: Likewise.
* gcc.target/i386/pr59501-5.c: Likewise.
* gcc.target/i386/pr59501-6.c: Likewise.
# HG changeset patch
# Parent aa22378cc97bc7b2f41b6d14213c5be4b3566bce
Require avx in gcc.target/i386/pr59501-*.c
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-1.c b/gcc/testsuite/gcc.target/i386/pr59501-1.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-1.c
@@ -1,6 +1,7 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -mno-accumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#define CHECK_H "avx-check.h"
#define TEST avx_test
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-2.c b/gcc/testsuite/gcc.target/i386/pr59501-2.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-2.c
@@ -1,5 +1,6 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -maccumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#include "pr59501-1.c"
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-3.c b/gcc/testsuite/gcc.target/i386/pr59501-3.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-3.c
@@ -1,6 +1,7 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -mno-accumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#define CHECK_H "avx-check.h"
#define TEST avx_test
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-4.c b/gcc/testsuite/gcc.target/i386/pr59501-4.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-4.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-4.c
@@ -1,5 +1,6 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -maccumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#include "pr59501-3.c"
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-5.c b/gcc/testsuite/gcc.target/i386/pr59501-5.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-5.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-5.c
@@ -1,6 +1,7 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -mno-accumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#define CHECK_H "avx-check.h"
#define TEST avx_test
diff --git a/gcc/testsuite/gcc.target/i386/pr59501-6.c b/gcc/testsuite/gcc.target/i386/pr59501-6.c
--- a/gcc/testsuite/gcc.target/i386/pr59501-6.c
+++ b/gcc/testsuite/gcc.target/i386/pr59501-6.c
@@ -1,5 +1,6 @@
/* PR target/59501 */
/* { dg-do run } */
/* { dg-options "-O2 -mavx -maccumulate-outgoing-args" } */
+/* { dg-require-effective-target avx } */
#include "pr59501-5.c"
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[testsuite, i386] Correctly require C99 support in avx512f tests
Several of the new AVX512F tests were FAILing on Solaris 10+/x86:
FAIL: gcc.target/i386/avx512f-vcmppd-2.c (test for excess errors)
WARNING: gcc.target/i386/avx512f-vcmppd-2.c compilation failed to produce
executable
Excess errors:
Undefined first referenced
symbol in file
isunordered /var/tmp//cc33Hbdi.o
ld: fatal: symbol referencing errors. No output written to
./avx512f-vcmppd-2.exe
This happens because isunordered() in is only visible with
-std=c99.
FAIL: gcc.target/i386/avx512f-vfixupimmpd-2.c (test for excess errors)
WARNING: gcc.target/i386/avx512f-vfixupimmpd-2.c compilation failed to produce
executable
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c:26:29:
error: 'NAN' undeclared (first use in this function)
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c:32:13:
error: 'INFINITY' undeclared (first use in this function)
Likewise for NAN and INFINITY.
This patch fixes all those instances by adding -std=c99 and requiring
c99_runtime.
Two cases required extra care:
*
FAIL: gcc.target/i386/avx512f-vgetmantpd-2.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/avx512f-helper.h:81:19
: warning: return type defaults to 'int' [enabled by default]
This function needs to be declared void static to avoid the warning.
* Four testcases use M_PI_2 which is not in C99, so I'm compiling
them with -std=gnu99 instead.
Tested on i386-pc-solaris2.10 and x86_64-unknown-linux-gnu, installed on
mainline.
Rainer
2014-01-03 Rainer Orth
* gcc.target/i386/avx512f-vcmppd-2.c: Add -std=c99.
Require c99_runtime.
* gcc.target/i386/avx512f-vcmpps-2.c: Likewise.
* gcc.target/i386/avx512f-vfixupimmpd-2.c: Add -std=gnu99.
Require c99_runtime.
* gcc.target/i386/avx512f-vfixupimmps-2.c: Likewise.
* gcc.target/i386/avx512f-vfixupimmsd-2.c: Likewise.
* gcc.target/i386/avx512f-vfixupimmss-2.c: Likewise.
* gcc.target/i386/avx512f-vgetmantpd-2.c: Add -std=c99.
Require c99_runtime.
Make CALC void static.
* gcc.target/i386/avx512f-vgetmantps-2.c: Likewise.
* gcc.target/i386/avx512f-vgetmantsd-2.c: Add -std=c99.
Require c99_runtime.
* gcc.target/i386/avx512f-vgetmantss-2.c: Likewise.
# HG changeset patch
# Parent c17a0967641b237595fd34cea929b4fb732231e3
Correctly require C99 support in avx512f tests
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vcmppd-2.c b/gcc/testsuite/gcc.target/i386/avx512f-vcmppd-2.c
--- a/gcc/testsuite/gcc.target/i386/avx512f-vcmppd-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vcmppd-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
-/* { dg-options "-O2 -mavx512f" } */
+/* { dg-options "-O2 -mavx512f -std=c99" } */
/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target c99_runtime } */
#define AVX512F
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vcmpps-2.c b/gcc/testsuite/gcc.target/i386/avx512f-vcmpps-2.c
--- a/gcc/testsuite/gcc.target/i386/avx512f-vcmpps-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vcmpps-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
-/* { dg-options "-O2 -mavx512f" } */
+/* { dg-options "-O2 -mavx512f -std=c99" } */
/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target c99_runtime } */
#define AVX512F
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c
--- a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmpd-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
-/* { dg-options "-O2 -mavx512f" } */
+/* { dg-options "-O2 -mavx512f -std=gnu99" } */
/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target c99_runtime } */
#define AVX512F
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmps-2.c b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmps-2.c
--- a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmps-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmps-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
-/* { dg-options "-O2 -mavx512f" } */
+/* { dg-options "-O2 -mavx512f -std=gnu99" } */
/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target c99_runtime } */
#define AVX512F
diff --git a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmsd-2.c b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmsd-2.c
--- a/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmsd-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512f-vfixupimmsd-2.c
@@ -1,6 +1,7 @@
/* { dg-do run } */
-/* { dg-options "-mavx512f -O2" } */
+/* { dg-options "-mavx512f -O2 -std=gnu99" } */
/* { dg-require-effective-target avx512f } */
+/* { dg-require-effective-target c99_runtime } */
#include "avx512f-check.h"
#include "avx512f-helper.h"
d
Re: [testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
Hello! > 2014-01-03 Rainer Orth > > * gcc.target/i386/pr59501-1.c: Require avx effective target. > * gcc.target/i386/pr59501-2.c: Likewise. > * gcc.target/i386/pr59501-3.c: Likewise. > * gcc.target/i386/pr59501-4.c: Likewise. > * gcc.target/i386/pr59501-5.c: Likewise. > * gcc.target/i386/pr59501-6.c: Likewise. OK, but please put dg-require-effective-target directive just after dg-do, before dg-options. Thanks, Uros.
Re: [testsuite, i386] Declare fma in gcc.target/i386/pr59390.c
Hello! > 2014-01-06 Rainer Orth > > * gcc.target/i386/pr59390.c: Replace math.h by fma declaration. > * gcc.target/i386/pr59390_1.c: Likewise. > * gcc.target/i386/pr59390_2.c: Likewise. OK. Thanks, Uros.
[testsuite] Clear hardware capabilities for gcc.dg/vect/vect-simd-clone-*.c
The new gcc.dg/vect/vect-simd-clone-*.c tests were FAILing on Solaris
10+/x86 with Sun as:
FAIL: gcc.dg/vect/vect-simd-clone-1.c execution test
ld.so.1: vect-simd-clone-1.exe: fatal: vect-simd-clone-1.exe: hardware
capability (CA_SUNW_HW_2) unsupported: 0x40 [ 0x40 ]
As can be seen in , this is:
#define AV2_386_AVX20x00040 /* Intel AVX2 insns */
Since the tests check for avx2 support at runtime, we need the same
solution as in gcc.target/i386: clear the hardware capabilities when
linking the executable.
Tested on i386-pc-solaris2.10 and x86_64-unknown-linux-gnu, installed on
mainline.
Rainer
2014-01-03 Rainer Orth
* gcc.dg/vect/vect.exp: Add clearcap_ldflags to DEFAULT_VECTCFLAGS
if supported.
# HG changeset patch
# Parent 17f8dc18e3a0f24a1c47b85f98782124de4c1b60
Clear hardware capabilities for gcc.dg/vect/vect-simd-clone-*.c
diff --git a/gcc/testsuite/gcc.dg/vect/vect.exp b/gcc/testsuite/gcc.dg/vect/vect.exp
--- a/gcc/testsuite/gcc.dg/vect/vect.exp
+++ b/gcc/testsuite/gcc.dg/vect/vect.exp
@@ -41,6 +41,28 @@ if ![check_vect_support_and_set_flags] {
# These flags are used for all targets.
lappend DEFAULT_VECTCFLAGS "-ftree-vectorize" "-fno-vect-cost-model" "-fno-common"
+# If the linker used understands -M , pass it to clear hardware
+# capabilities set by the Sun assembler.
+# Try mapfile syntax v2 first which is the only way to clear hwcap_2 flags.
+set clearcap_ldflags "-Wl,-M,$srcdir/gcc.target/i386/clearcapv2.map"
+
+if ![check_no_compiler_messages mapfilev2 executable {
+int main (void) { return 0; }
+} $clearcap_ldflags ] {
+# If this doesn't work, fall back to the less capable v1 syntax.
+set clearcap_ldflags "-Wl,-M,$srcdir/gcc.target/i386/clearcap.map"
+
+if ![check_no_compiler_messages mapfile executable {
+ int main (void) { return 0; }
+} $clearcap_ldflags ] {
+ unset clearcap_ldflags
+}
+}
+
+if [info exists clearcap_ldflags] {
+lappend DEFAULT_VECTCFLAGS $clearcap_ldflags
+}
+
# Initialize `dg'.
dg-init
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [testsuite, i386] Correctly require C99 support in avx512f tests
Hello! > 2014-01-03 Rainer Orth > > * gcc.target/i386/avx512f-vcmppd-2.c: Add -std=c99. > Require c99_runtime. > * gcc.target/i386/avx512f-vcmpps-2.c: Likewise. > > * gcc.target/i386/avx512f-vfixupimmpd-2.c: Add -std=gnu99. > Require c99_runtime. > * gcc.target/i386/avx512f-vfixupimmps-2.c: Likewise. > * gcc.target/i386/avx512f-vfixupimmsd-2.c: Likewise. > * gcc.target/i386/avx512f-vfixupimmss-2.c: Likewise. > > * gcc.target/i386/avx512f-vgetmantpd-2.c: Add -std=c99. > Require c99_runtime. > Make CALC void static. > * gcc.target/i386/avx512f-vgetmantps-2.c: Likewise. > > * gcc.target/i386/avx512f-vgetmantsd-2.c: Add -std=c99. > Require c99_runtime. > * gcc.target/i386/avx512f-vgetmantss-2.c: Likewise. OK. Thanks, Uros.
[PATCH, PR 59008] Fix wrong type of param_index in ipcp_discover_new_direct_edges
Hi,
the patch below makes param_index in ipcp_discover_new_direct_edges an
integer. Now it is bool which makes kind of difficult to work with
parameters with index 2 or higher, as demonstrated by the testcase.
Bootstrapped and tested on x86_64-linux, approved by Honza in person,
I am about to commit it.
Thanks,
Martin
2014-01-06 Martin Jambor
PR ipa/59008
* ipa-cp.c (ipcp_discover_new_direct_edges): Changed param_index type
to int.
* ipa-inline.c (ipa_inline): Also dump ipa-prop structures in detailed
dumps.
* ipa-prop.c (ipa_print_node_params): Fix indentation.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index b484d05..79d066a 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2281,7 +2281,7 @@ ipcp_discover_new_direct_edges (struct cgraph_node *node,
{
bool agg_contents = ie->indirect_info->agg_contents;
bool polymorphic = ie->indirect_info->polymorphic;
- bool param_index = ie->indirect_info->param_index;
+ int param_index = ie->indirect_info->param_index;
struct cgraph_edge *cs = ipa_make_edge_direct_to_target (ie, target);
found = true;
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 5a337f7..b12bda4 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3326,6 +3326,7 @@ ipa_print_node_params (FILE *f, struct cgraph_node *node)
{
int c;
+ fprintf (f, "");
ipa_dump_param (f, info, i);
if (ipa_is_param_used (info, i))
fprintf (f, " used");
diff --git a/gcc/testsuite/gcc.dg/ipa/pr59008.c
b/gcc/testsuite/gcc.dg/ipa/pr59008.c
new file mode 100644
index 000..b729672
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr59008.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+typedef int (*funct)(int, int, int);
+
+extern int f(int, int, int);
+extern int g(int, int, int);
+extern int h(int, funct, funct);
+
+static int baz(int x, int y, int z)
+{
+ return x + y + z;
+}
+
+static int bar(int n, funct f1, funct f2)
+{
+ return h(n, f1, f2) + f1(0, 1, 2);
+}
+
+static int foo(int n, funct f1, funct f2)
+{
+ return bar(n, f1, f2) + f2(0, 1, 2);
+}
+
+int main(void)
+{
+ return foo(0, f, g)
+#ifndef ICE2
+ + foo(0, baz, g)
+#endif
+ ;
+}
Re: [testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
Hi Uros, >> 2014-01-03 Rainer Orth >> >> * gcc.target/i386/pr59501-1.c: Require avx effective target. >> * gcc.target/i386/pr59501-2.c: Likewise. >> * gcc.target/i386/pr59501-3.c: Likewise. >> * gcc.target/i386/pr59501-4.c: Likewise. >> * gcc.target/i386/pr59501-5.c: Likewise. >> * gcc.target/i386/pr59501-6.c: Likewise. > > OK, but please put dg-require-effective-target directive just after > dg-do, before dg-options. I'd already committed the patch based on testsuite maintainership/obviousness. I can change the order if you like, but already found it to be mostly random in other testcases. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
On Mon, Jan 6, 2014 at 2:53 PM, Rainer Orth wrote: >>> 2014-01-03 Rainer Orth >>> >>> * gcc.target/i386/pr59501-1.c: Require avx effective target. >>> * gcc.target/i386/pr59501-2.c: Likewise. >>> * gcc.target/i386/pr59501-3.c: Likewise. >>> * gcc.target/i386/pr59501-4.c: Likewise. >>> * gcc.target/i386/pr59501-5.c: Likewise. >>> * gcc.target/i386/pr59501-6.c: Likewise. >> >> OK, but please put dg-require-effective-target directive just after >> dg-do, before dg-options. > > I'd already committed the patch based on testsuite > maintainership/obviousness. I can change the order if you like, but > already found it to be mostly random in other testcases. No, in this case, it is OK as it is. Thanks, Uros.
Re: [testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
I was about to open a PR for the same failures on darwin.
Since the tests are supposed to be run, I think they should be skipped
on CPUs not supporting axv instructions. Would not it be better to use
/* { dg-require-effective-target avx_runtime } */
?
Dominique
Re: [testsuite, i386] Require avx in gcc.target/i386/pr59501-*.c
On Mon, Jan 6, 2014 at 2:57 PM, Dominique Dhumieres wrote:
> I was about to open a PR for the same failures on darwin.
> Since the tests are supposed to be run, I think they should be skipped
> on CPUs not supporting axv instructions. Would not it be better to use
>
> /* { dg-require-effective-target avx_runtime } */
>
> ?
These tests won't run on non-avx targets, they have runtime check for
AVX. They can still be compiled all the way to an executable.
Uros.
[v3] Update Solaris baselines
Since the GCC 4.9.0 release is approaching, we should update the Solaris
baselines again.
This patch does just that, bootstrapped without regressions on the full
rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
Ok for mainline now or better wait until a bit closer to the release?
Thanks.
Rainer
2014-01-03 Rainer Orth
* config/abi/post/solaris2.9/baseline_symbols.txt: Regenerate.
* config/abi/post/solaris2.9/sparcv9/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/amd64/baseline_symbols.txt: Likewise.
* config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt: Likewise.
# HG changeset patch
# Parent 256fc62e02ff69f6070855229290102d9f2f639b
Update Solaris baselines
diff --git a/libstdc++-v3/config/abi/post/solaris2.10/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/solaris2.10/amd64/baseline_symbols.txt
--- a/libstdc++-v3/config/abi/post/solaris2.10/amd64/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/solaris2.10/amd64/baseline_symbols.txt
@@ -388,6 +388,7 @@ FUNC:_ZNKSt15basic_streambufIwSt11char_t
FUNC:_ZNKSt15basic_streambufIwSt11char_traitsIwEE6getlocEv@@GLIBCXX_3.4
FUNC:_ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4
FUNC:_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4
+FUNC:_ZNKSt16bad_array_length4whatEv@@CXXABI_1.3.8
FUNC:_ZNKSt17bad_function_call4whatEv@@GLIBCXX_3.4.18
FUNC:_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv@@GLIBCXX_3.4
FUNC:_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@@GLIBCXX_3.4
@@ -401,6 +402,7 @@ FUNC:_ZNKSt19basic_ostringstreamIcSt11ch
FUNC:_ZNKSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE5rdbufEv@@GLIBCXX_3.4
FUNC:_ZNKSt19basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4
FUNC:_ZNKSt19basic_ostringstreamIwSt11char_traitsIwESaIwEE5rdbufEv@@GLIBCXX_3.4
+FUNC:_ZNKSt20bad_array_new_length4whatEv@@CXXABI_1.3.8
FUNC:_ZNKSt3tr14hashIRKSbIwSt11char_traitsIwESaIwEEEclES6_@@GLIBCXX_3.4.10
FUNC:_ZNKSt3tr14hashIRKSsEclES2_@@GLIBCXX_3.4.10
FUNC:_ZNKSt3tr14hashISbIwSt11char_traitsIwESaIwEEEclES4_@@GLIBCXX_3.4.10
@@ -1178,6 +1180,7 @@ FUNC:_ZNSt11range_errorC2ERKSs@@GLIBCXX_
FUNC:_ZNSt11range_errorD0Ev@@GLIBCXX_3.4
FUNC:_ZNSt11range_errorD1Ev@@GLIBCXX_3.4
FUNC:_ZNSt11range_errorD2Ev@@GLIBCXX_3.4.15
+FUNC:_ZNSt11regex_errorC1ENSt15regex_constants10error_typeE@@GLIBCXX_3.4.20
FUNC:_ZNSt11regex_errorD0Ev@@GLIBCXX_3.4.15
FUNC:_ZNSt11regex_errorD1Ev@@GLIBCXX_3.4.15
FUNC:_ZNSt11regex_errorD2Ev@@GLIBCXX_3.4.15
@@ -1753,6 +1756,9 @@ FUNC:_ZNSt16__numpunct_cacheIwEC2Em@@GLI
FUNC:_ZNSt16__numpunct_cacheIwED0Ev@@GLIBCXX_3.4
FUNC:_ZNSt16__numpunct_cacheIwED1Ev@@GLIBCXX_3.4
FUNC:_ZNSt16__numpunct_cacheIwED2Ev@@GLIBCXX_3.4
+FUNC:_ZNSt16bad_array_lengthD0Ev@@CXXABI_1.3.8
+FUNC:_ZNSt16bad_array_lengthD1Ev@@CXXABI_1.3.8
+FUNC:_ZNSt16bad_array_lengthD2Ev@@CXXABI_1.3.8
FUNC:_ZNSt16invalid_argumentC1ERKSs@@GLIBCXX_3.4
FUNC:_ZNSt16invalid_argumentC2ERKSs@@GLIBCXX_3.4
FUNC:_ZNSt16invalid_argumentD0Ev@@GLIBCXX_3.4
@@ -1873,6 +1879,9 @@ FUNC:_ZNSt19basic_ostringstreamIwSt11cha
FUNC:_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED0Ev@@GLIBCXX_3.4
FUNC:_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED1Ev@@GLIBCXX_3.4
FUNC:_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED2Ev@@GLIBCXX_3.4
+FUNC:_ZNSt20bad_array_new_lengthD0Ev@@CXXABI_1.3.8
+FUNC:_ZNSt20bad_array_new_lengthD1Ev@@CXXABI_1.3.8
+FUNC:_ZNSt20bad_array_new_lengthD2Ev@@CXXABI_1.3.8
FUNC:_ZNSt22condition_variable_anyC1Ev@@GLIBCXX_3.4.11
FUNC:_ZNSt22condition_variable_anyC2Ev@@GLIBCXX_3.4.11
FUNC:_ZNSt22condition_variable_anyD1Ev@@GLIBCXX_3.4.11
@@ -2177,13 +2186,16 @@ FUNC:_ZNSt9type_infoD1Ev@@GLIBCXX_3.4
FUNC:_ZNSt9type_infoD2Ev@@GLIBCXX_3.4
FUNC:_ZSt10unexpectedv@@GLIBCXX_3.4
FUNC:_ZSt11_Hash_bytesPKvmm@@CXXABI_1.3.5
+FUNC:_ZSt13get_terminatev@@GLIBCXX_3.4.20
FUNC:_ZSt13set_terminatePFvvE@@GLIBCXX_3.4
FUNC:_ZSt14__convert_to_vIdEvPKcRT_RSt12_Ios_IostateRKPi@@GLIBCXX_3.4
FUNC:_ZSt14__convert_to_vIeEvPKcRT_RSt12_Ios_IostateRKPi@@GLIBCXX_3.4
FUNC:_ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi@@GLIBCXX_3.4
+FUNC:_ZSt14get_unexpectedv@@GLIBCXX_3.4.20
FUNC:_ZSt14set_unexpectedPFvvE@@GLIBCXX_3.4
FUNC:_ZSt15_Fnv_hash_bytesPKvmm@@CXXABI_1.3.5
FUNC:_ZSt15future_categoryv@@GLIBCXX_3.4.15
+FUNC:_ZSt15get_new_handlerv@@GLIBCXX_3.4.20
FUNC:_ZSt15set_new_handlerPFvvE@@GLIBCXX_3.4
FUNC:_ZSt15system_categoryv@@GLIBCXX_3.4.11
FUNC:_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@@GLIBCXX_3.4.9
@@ -2221,6 +2233,7 @@ FUNC:_ZSt21__throw_runtime_errorPKc@@GLI
FUNC:_ZSt22__throw_overflow_errorPKc@@GLIBCXX_3.4
FUNC:_ZSt23__throw_underflow_errorPKc@@GLIBCXX_3.4
FUNC:_ZSt24__throw_invalid_argumentPKc@@GLIBCXX_3.4
+FUNC:_ZSt24__throw_out_of_range_fmtPKcz@@GLIBCXX_3.4.20
FUNC:_ZSt25__throw_bad_function_callv@@GLIBCXX_3.4.14
FUNC:_ZSt28_Rb_t
Re: [Patch] libgcov.c re-factoring
On 12/22/2013 01:27 PM, Jan Hubicka wrote: I believe when the code was created by moving it from elsehwre, the copyright should say original date of gcov-io.h. + +#include "tconfig.h" +#include "tsystem.h" +#include "coretypes.h" +#include "tm.h" +#include "libgcc_tm.h" I would really like someone working on header restructuring to comment on those. I am not 100% sure what our best practices currently are in respect of including headers within headers and specially after good amount of defines like gcov-io.h gets included. Just back.. For the moment the goal with headers is to completely flatten them.. ie, we do not want to include header files from header files. Once there is a sensible restructuring of things in place, we are likely to reintroduce them in a controlled and sensible manner. So at the moment, I'd like to not include any additional .h files from within .h files... Andrew
Re: [PATCH] Fix PR c++/59638
On 01/04/2014 04:54 AM, Adam Butcher wrote: + /* Declarations involving function parameter lists containing implicit + template parameters will have been made into implicit templates. If they + do not turn out to be actual function declarations then finish the + template declaration here. */ This will always be an error, right? Please mention that in the comment. OK with that change. Jason
Re: [PATCH] Fix PR c++/59636
OK. Jason
Re: [Patch] libgcov.c re-factoring
> On 12/22/2013 01:27 PM, Jan Hubicka wrote: > > > >I believe when the code was created by moving it from elsehwre, the > >copyright should say > >original date of gcov-io.h. > >>+ > >>+#include "tconfig.h" > >>+#include "tsystem.h" > >>+#include "coretypes.h" > >>+#include "tm.h" > >>+#include "libgcc_tm.h" > > > >I would really like someone working on header restructuring to comment on > >those. > >I am not 100% sure what our best practices currently are in respect of > >including headers within headers and specially after good amount of > >defines like gcov-io.h gets included. > > > > > Just back.. > > For the moment the goal with headers is to completely flatten them.. OK. Seems sensible. I will push IPA/cgraph/symtab in this direction next stage1. > ie, we do not want to include header files from header files. Once > there is a sensible restructuring of things in place, we are likely > to reintroduce them in a controlled and sensible manner. > > So at the moment, I'd like to not include any additional .h files > from within .h files... The situation here is slightly more slipperly than in other cases, since we have headers (gcov-io.h.h) that is shared across GCC coverage code and runtime (libgcov) and stand alone tools (gcov-tool and gcov). The header has several ifdefs that makes it to do the right thing in all 3 contexts that are different. The change in question is to pull out a lot of mess that is specific into runtime to libgcov specific header file that includes gcov-io.h later in game. In a way I see this as an improvement, since runtime bits are localized to place where rest of libgcov is (that is for some reason libgcc and not libgcov directory) rather than hidding it in geenral purpose header. I suppose it will also make easier to make libgcov portable to non-stdio based environments, like in kernel, that is google's desire. What would be preferred solution here? Honza > > Andrew >
Re: [v3] Update Solaris baselines
On 6 January 2014 14:10, Rainer Orth wrote:
> Since the GCC 4.9.0 release is approaching, we should update the Solaris
> baselines again.
>
> This patch does just that, bootstrapped without regressions on the full
> rang of Solaris configurations ({i386,sparc}-*-solaris2.{9,10,11}).
>
> Ok for mainline now or better wait until a bit closer to the release?
I think now is a good time, I hope we won't be adding new symbols
before the release.
Thanks.
Re: [C++ Patch] Fix __is_base_of vs incomplete types
I think this is getting too tricky, so let's go back to your first patch (which is OK). Sorry about the runaround. Jason
Re: [PATCH] Fix PR c++/59635
OK. Jason
Re: [Patch] libgcov.c re-factoring
On 01/06/2014 09:37 AM, Jan Hubicka wrote: On 12/22/2013 01:27 PM, Jan Hubicka wrote: I believe when the code was created by moving it from elsehwre, the copyright should say original date of gcov-io.h. + +#include "tconfig.h" +#include "tsystem.h" +#include "coretypes.h" +#include "tm.h" +#include "libgcc_tm.h" I would really like someone working on header restructuring to comment on those. I am not 100% sure what our best practices currently are in respect of including headers within headers and specially after good amount of defines like gcov-io.h gets included. Just back.. For the moment the goal with headers is to completely flatten them.. OK. Seems sensible. I will push IPA/cgraph/symtab in this direction next stage1. ie, we do not want to include header files from header files. Once there is a sensible restructuring of things in place, we are likely to reintroduce them in a controlled and sensible manner. So at the moment, I'd like to not include any additional .h files from within .h files... The situation here is slightly more slipperly than in other cases, since we have headers (gcov-io.h.h) that is shared across GCC coverage code and runtime (libgcov) and stand alone tools (gcov-tool and gcov). The header has several ifdefs that makes it to do the right thing in all 3 contexts that are different. The change in question is to pull out a lot of mess that is specific into runtime to libgcov specific header file that includes gcov-io.h later in game. In a way I see this as an improvement, since runtime bits are localized to place where rest of libgcov is (that is for some reason libgcc and not libgcov directory) rather than hidding it in geenral purpose header. I suppose it will also make easier to make libgcov portable to non-stdio based environments, like in kernel, that is google's desire. What would be preferred solution here? Yeah, this isnt only a compiler header file, so what makes the most sense may be different. The rationale for flattening the compiler header files is to get a grasp on what is coming from where, regroup things in a more logical manner, then possibly reintroduce a more sensible include hierarchy. If this is improving the locality of the runtime then I wouldnt worry about it. we haven't gotten anywhere near that yet :-) I didnt realize on first glance that it was a libgcc file. if we ever do get that far, we can deal with it then :-) It isn't undoing anything we've done so far. Andrew
[ping][gomp4] splay tree implementation for future OpenACC runtime library usage.
Hi! Ping * 2 http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00527.html Thanks!
Re: [PATCH] Fix PR c++/59629
OK. Jason
[AArch64] Define BE loader name.
Hi,
This patch defines the AArch64 BE loader name. Corresponding patches
for glibc and binutils have been posted on the relevant lists.
/Marcus
* config/aarch64/aarch64-linux.h (GLIBC_DYNAMIC_LINKER): Expand
loader
name using mbig-endian.
(LINUX_TARGET_LINK_SPEC): Pass linker -m flag.diff --git a/gcc/config/aarch64/aarch64-linux.h
b/gcc/config/aarch64/aarch64-linux.h
index 15272b8..a8f0771 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -21,7 +21,7 @@
#ifndef GCC_AARCH64_LINUX_H
#define GCC_AARCH64_LINUX_H
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"
+#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}.so.1"
#define CPP_SPEC "%{pthread:-D_REENTRANT}"
@@ -32,7 +32,8 @@
%{rdynamic:-export-dynamic} \
-dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
-X \
- %{mbig-endian:-EB} %{mlittle-endian:-EL}"
+ %{mbig-endian:-EB} %{mlittle-endian:-EL} \
+ -maarch64linux%{mbig-endian:b}"
#define LINK_SPEC LINUX_TARGET_LINK_SPEC
Re: Fix IBM long double spurious overflows
On Sat, Jan 4, 2014 at 8:16 AM, Joseph S. Myers wrote: > This patch fixes various cases of spurious overflow exceptions in the > IBM long double support code. The generic issue is that an initial > approximation is computed by using the relevant arithmetic operation > on the high parts of the operands - but this may overflow double in > some cases where the final result is large but still a long way (up to > around 2^53 ulp) from overflowing long double. For division overflow > could occur not just from the initial a / c division but also from the > subsequent multiplication of the result by c (in some cases where a is > DBL_MAX, say), when the final result of the division need not be large > at all. > > __gcc_qadd already tried to handle such overflow cases, but detected > them by examining the result of the addition of high parts - which > leaves a spurious overflow exception raised even if it returns the > correct non-overflowing value. This patch instead checks the operands > and does appropriate scaling, in all of __gcc_qadd, __gcc_qmul and > __gcc_qdiv, to avoid spurious overflow exceptions arising as well as > avoiding the bad results arising from such overflows. > > Tested with no regressions with cross to powerpc-linux-gnu (and also > ran the glibc libm tests, which provide a rather more thorough test of > floating-point arithmetic than the GCC testsuite; this patch fixes, at > least, bad results from cbrtl (LDBL_MAX) that arose from the second > division issue mentioned, as well as the specific cases shown in the > tests added to the GCC testsuite). OK to commit? Before we go farther down this path, IBM needs to internally decide on the end goal and the amount of language / library conformance that makes sense for the IBM long double format. Thanks, David
[PATCH, aarch64] Fix cost calculation for MADD
AArch64 gcc has supported a MADD instruction for a while now. Unfortunately, it's generally failed to generate it because the costs returned for it were too high. That's because we cost the operands to the pattern more than once. Fixed thusly: 2014-01-06 Richard Earnshaw * aarch64.c (aarch64_rtx_costs): Fix cost calculation for MADD.--- aarch64.c (revision 206289) +++ aarch64.c (local) @@ -4643,12 +4643,15 @@ aarch64_rtx_costs (rtx x, int code, int extra_cost->mult[GET_MODE (x) == DImode].extend_add; return true; } + *cost += (rtx_cost (XEXP (op0, 0), MULT, 0, speed) + rtx_cost (XEXP (op0, 1), MULT, 1, speed) + rtx_cost (op1, PLUS, 1, speed)); if (speed) *cost += extra_cost->mult[GET_MODE (x) == DImode].add; + + return true; } *cost += (rtx_cost (new_op0, PLUS, 0, speed)
Re: [PATCH] Introduce MODE_SIZE mode attribute
On Sat, Jan 04, 2014 at 12:37:57AM +0100, Jakub Jelinek wrote: > That is certainly doable (as attached), but strangely if the patch (that I've > already committed) is reverted and this one applied, the .text savings are > much smaller. > > Here are .text and .rodata readelf -WS lines from x86_64 (first 4 pairs) and > i686 (last 4 pairs) builds, always vanilla trunk before r206312, that plus > r206312 patch, without r206312 but with attached patch, with both r206312 > and attached patch. So, for .text size the best is both patches, but > for .rodata patches just r206312. I'll try to look at details why this is so > next week. The difference is I think caused by the way gencondition.c works. As the array with the conditions is a toplevel array, __builtin_constant_p is folded there already during the parsing, after folding the conditions. If I (manually for now) move the build/gencondmd.c insn_conditions array instead of main and remove static const keywords, I get undefined references when linking build/gencondmd, on x86_64 about the: `default_target_flag_state' `flag_unsafe_math_optimizations' `insn' `ix86_arch_features' `ix86_fpmath' `ix86_isa_flags' `ix86_stack_protector_guard' `operands' `reload_completed' `reload_in_progress' `target_flags' symbols. Jakub
[PATCH] libiberty: fix --enable-install-libiberty flag [PR 56780]
Commit 199570 fixed the --disable-install-libiberty behavior, but it also
added a bug where the enable path never works because the initial clear
of target_header_dir wasn't deleted. So we end up initializing properly
at the top only to reset it at the end all the time.
2014-01-06 Mike Frysinger
PR other/56780
* configure.ac: Delete target_header_dir assignment.
* configure: Regenerated.
---
libiberty/configure| 1 -
libiberty/configure.ac | 1 -
2 files changed, 2 deletions(-)
diff --git a/libiberty/configure b/libiberty/configure
index 8ea54da..7bde9b3 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5510,7 +5510,6 @@ fi
setobjs=
CHECK=
-target_header_dir=
if test -n "${with_target_subdir}"; then
# We are being configured as a target library. AC_REPLACE_FUNCS
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 4ad88a9..d6180bc 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -411,7 +411,6 @@ fi
setobjs=
CHECK=
-target_header_dir=
if test -n "${with_target_subdir}"; then
# We are being configured as a target library. AC_REPLACE_FUNCS
--
1.8.4.3
Re: [C PATCH] Don't pedwarn for C99/C11 enum bit-fields (PR c/57773)
On Mon, 6 Jan 2014, Marek Polacek wrote: > 2014-01-06 Marek Polacek > > PR c/57773 > * doc/implement-c.texi: Mention that other integer types are > permitted as bit-field types in strictly conforming mode. > c/ > * c-decl.c (check_bitfield_type_and_width): Warn for implementation > defined bit-field types only in ISO C. > testsuite/ > * gcc.dg/pr57773.c: New test. OK. -- Joseph S. Myers jos...@codesourcery.com
[google][4.8] Add more inexpensive debug checks to vector, bitvector, deque
Greetings,
For Google b/9127283, I've committed attached patch on google/gcc-4_8 branch.
Related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109
This caught ~10 bugs for us. erase(end()) and pop_back() on empty
vector appear to be most common.
--
Paul Pluzhnikov
Index: libstdc++-v3/include/bits/stl_vector.h
===
--- libstdc++-v3/include/bits/stl_vector.h (revision 206330)
+++ libstdc++-v3/include/bits/stl_vector.h (working copy)
@@ -1050,6 +1050,10 @@
void
pop_back()
{
+#if __google_stl_debug_vector
+ if (this->empty())
+ __throw_logic_error(__N("pop_back() on empty vector"));
+#endif
--this->_M_impl._M_finish;
_Alloc_traits::destroy(this->_M_impl, this->_M_impl._M_finish);
}
@@ -1135,7 +1139,13 @@
*/
void
insert(iterator __position, size_type __n, const value_type& __x)
- { _M_fill_insert(__position, __n, __x); }
+ {
+#if __google_stl_debug_vector
+ if (__position < this->begin() || __position > this->end())
+ __throw_out_of_range(__N("insert() at invalid position"));
+#endif
+ _M_fill_insert(__position, __n, __x);
+ }
/**
* @brief Inserts a range into the %vector.
@@ -1157,13 +1167,23 @@
void
insert(iterator __position, _InputIterator __first,
_InputIterator __last)
-{ _M_insert_dispatch(__position, __first, __last, __false_type()); }
+{
+#if __google_stl_debug_vector
+ if (__position < this->begin() || __position > this->end())
+ __throw_out_of_range(__N("insert() at invalid position"));
+#endif
+ _M_insert_dispatch(__position, __first, __last, __false_type());
+ }
#else
template
void
insert(iterator __position, _InputIterator __first,
_InputIterator __last)
{
+#if __google_stl_debug_vector
+ if (__position < this->begin() || __position > this->end())
+ __throw_out_of_range(__N("insert() at invalid position"));
+#endif
// Check whether it's an integral type. If so, it's not an iterator.
typedef typename std::__is_integer<_InputIterator>::__type _Integral;
_M_insert_dispatch(__position, __first, __last, _Integral());
Index: libstdc++-v3/include/bits/stl_deque.h
===
--- libstdc++-v3/include/bits/stl_deque.h (revision 206330)
+++ libstdc++-v3/include/bits/stl_deque.h (working copy)
@@ -1552,7 +1552,13 @@
*/
void
insert(iterator __position, size_type __n, const value_type& __x)
- { _M_fill_insert(__position, __n, __x); }
+ {
+#if __google_stl_debug_deque
+ if (__position < this->begin() || __position > this->end())
+ __throw_logic_error("insert() at invalid position");
+#endif
+ _M_fill_insert(__position, __n, __x);
+ }
/**
* @brief Inserts a range into the %deque.
@@ -1570,7 +1576,13 @@
void
insert(iterator __position, _InputIterator __first,
_InputIterator __last)
-{ _M_insert_dispatch(__position, __first, __last, __false_type()); }
+{
+#if __google_stl_debug_deque
+ if (__position < this->begin() || __position > this->end())
+ __throw_logic_error("insert() at invalid position");
+#endif
+ _M_insert_dispatch(__position, __first, __last, __false_type());
+ }
#else
template
void
Index: libstdc++-v3/include/bits/vector.tcc
===
--- libstdc++-v3/include/bits/vector.tcc(revision 206330)
+++ libstdc++-v3/include/bits/vector.tcc(working copy)
@@ -107,6 +107,10 @@
vector<_Tp, _Alloc>::
insert(iterator __position, const value_type& __x)
{
+#if __google_stl_debug_vector
+ if (__position < this->begin() || __position > this->end())
+ __throw_out_of_range(__N("insert() at invalid position"));
+#endif
const size_type __n = __position - begin();
if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage
&& __position == end())
@@ -134,6 +138,10 @@
vector<_Tp, _Alloc>::
erase(iterator __position)
{
+#if __google_stl_debug_vector
+ if (__position < this->begin() || __position >= this->end())
+ __throw_out_of_range(__N("erase() at invalid position"));
+#endif
if (__position + 1 != end())
_GLIBCXX_MOVE3(__position + 1, end(), __position);
--this->_M_impl._M_finish;
@@ -146,6 +154,10 @@
vector<_Tp, _Alloc>::
erase(iterator __first, iterator __last)
{
+#if __google_stl_debug_vector
+ if (__first < this->begin() || __first > __last || __last > this->end())
+ __throw_out_of_range("erase() invalid range");
+#endif
if (__first != __last)
{
if (__last != end())
@@ -298,6 +3
Re: [Patch, SMS] Fix a potential bug of schedule_reg_moves of SMS
On 01/02/14 07:17, Felix Yang wrote: +2014-01-02 Felix Yang + +* modulo-sched.c (schedule_reg_moves): Clear distance1_uses if it +is newly allocated. Thanks. Applied. If you have a testcase where failure to properly initialize distance1_uses resulted in some kind of unexpected behaviour, could you please post it along with details about the failure so that we can add it to the regression suite. Thanks, jeff
Re: [PATCH, committed] Fix PR 57422
On 12/27/13 03:16, Jakub Jelinek wrote: On Fri, Dec 27, 2013 at 02:11:13PM +0400, Andrey Belevantsev wrote: Testcase is very small. Why not add it? Frankly, I think that the chances of this test uncovering similar issues in the future are very small. It needs lots of options to make it trigger and even with this a specific revision. The chance of triggering the asserts I added on another code is much higher. In the past, I have also avoided to add tests that require 5+ options to trigger the issue, adding only those that have some hope on more ore less reliably reproducing the required issue. The best solution of course is having an infrastructure to test the specific scheduler decisions, which we don't have. You are welcome to add the test if you feel so strongly about us needing it. I guess it depends, if you e.g. have a small runtime testcase, it might be useful to add it, while it is unlikely it will trigger the same issue, it could trigger a different issue in another part of the compiler, especially if the testcase is a combination of e.g. several more rarely used features. But for a ICE testcase with many weird options to trigger it I agree it sometimes doesn't make sense to add the testcase, especially if it already doesn't trigger on the trunk as in this case. IIRC, for this particular bug it also heavily depended on the exact register allocation at a key point. So it could easily go latent on the trunk. jeff
RE: [PATCH] Fix PR58115
> > Jakub Jelinek wrote: >>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote: >>> Of course, IMO, the cleanest fix would be to use switchable targets >>> for i386... >> >>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons >>to >>compile because even with just a few routines in a CU there are >>hundreds or >>thousands of IRA reinitializations. > > We also want a big fat comment before the non-obvious order of inits when > switching cfuns. > > Bernd, please revert your patch for now. > OK, reverted for now. Bernd. > Thanks, > Richard. > >> Jakub > >
Re: [AArch64] Define BE loader name.
On Mon, Jan 6, 2014 at 7:36 AM, Marcus Shawcroft wrote: > Hi, > > This patch defines the AArch64 BE loader name. Corresponding patches for > glibc and binutils have been posted on the relevant lists. This is a huge ABI change and makes GCC 4.8.x incompatible with GCC 4.9.0. Thanks, Andrew > > /Marcus > > >* config/aarch64/aarch64-linux.h (GLIBC_DYNAMIC_LINKER): Expand > loader >name using mbig-endian. >(LINUX_TARGET_LINK_SPEC): Pass linker -m flag.
Re: memory leak in reorg_loops
On 01/02/14 19:31, dxq wrote: hi, In hw-doloop.c, is there a memory leak? valgrind checking shows: ==18622== 1,479,296 bytes in 364 blocks are definitely lost in loss record 559 of 559 ==18622==at 0x4006ADD: malloc (vg_replace_malloc.c:291) ==18622==by 0x8C0A9D5: xmalloc (xmalloc.c:147) ==18622==by 0x910457: _obstack_begin (in /lib/libc-2.5.so) ==18622==by 0x81EDD24: bitmap_obstack_initialize (bitmap.c:318) ==18622==by 0x8B22BBE: reorg_loops (hw-doloop.c:635) ... ... ==18622==by 0x8688B3E: rest_of_handle_machine_reorg (reorg.c:4183) ==18622==by 0x861D2A6: execute_one_pass (passes.c:2097) ==18622==by 0x861D6A0: execute_pass_list (passes.c:2152) ==18622==by 0x861D6BC: execute_pass_list (passes.c:2153) ==18622==by 0x861D6BC: execute_pass_list (passes.c:2153) should loop_stack be freed at the end of reorg_loops? please confirm! if it's true, commit for me, thanks! free_loops (loops); + bitmap_obstack_release (&loop_stack); if (dump_file) print_rtl (dump_file, get_insns ()); thanks! Isn't the bitmap free'd from within free_loops? jeff
Re: Re: [Patch, fortran] PR58007: unresolved fixup hell
Hello, I will try to produce a testcase for 4.8 and/or that doesn't involve OOP. I come back to you later. Thanks for the review. Mikael
Re: [PATCH] libiberty: fix --enable-install-libiberty flag [PR 56780]
On Mon, Jan 6, 2014 at 8:07 AM, Mike Frysinger wrote: > > 2014-01-06 Mike Frysinger > > PR other/56780 > * configure.ac: Delete target_header_dir assignment. > * configure: Regenerated. This is OK. Thanks. Ian
Re: [Patch] libgcov.c re-factoring
On Sun, Jan 5, 2014 at 12:08 PM, Jan Hubicka wrote:
>> 2014-01-03 Rong Xu
>>
>> * gcc/gcov-io.c (gcov_var): Move from gcov-io.h.
>> (gcov_position): Ditto.
>> (gcov_is_error): Ditto.
>> (gcov_rewrite): Ditto.
>> * gcc/gcov-io.h: Refactor. Move gcov_var to gcov-io.h, and libgcov
>> only part to libgcc/libgcov.h.
>> * libgcc/libgcov-driver.c: Use libgcov.h.
>> (buffer_fn_data): Use xmalloc instead of malloc.
>> (gcov_exit_merge_gcda): Ditto.
>> * libgcc/libgcov-driver-system.c (allocate_filename_struct): Ditto.
>> * libgcc/libgcov.h: New common header files for libgcov-*.h.
>> * libgcc/libgcov-interface.c: Use libgcov.h
>> * libgcc/libgcov-merge.c: Ditto.
>> * libgcc/libgcov-profiler.c: Ditto.
>> * libgcc/Makefile.in: Add dependence to libgcov.h
>
> OK, with the licence changes and...
>>
>> Index: gcc/gcov-io.c
>> ===
>> --- gcc/gcov-io.c (revision 206100)
>> +++ gcc/gcov-io.c (working copy)
>> @@ -36,6 +36,61 @@ static const gcov_unsigned_t *gcov_read_words (uns
>> static void gcov_allocate (unsigned);
>> #endif
>>
>> +/* Optimum number of gcov_unsigned_t's read from or written to disk. */
>> +#define GCOV_BLOCK_SIZE (1 << 10)
>> +
>> +GCOV_LINKAGE struct gcov_var
>> +{
>> + FILE *file;
>> + gcov_position_t start; /* Position of first byte of block */
>> + unsigned offset; /* Read/write position within the block. */
>> + unsigned length; /* Read limit in the block. */
>> + unsigned overread; /* Number of words overread. */
>> + int error; /* < 0 overflow, > 0 disk error. */
>> + int mode;/* < 0 writing, > 0 reading */
>> +#if IN_LIBGCOV
>> + /* Holds one block plus 4 bytes, thus all coverage reads & writes
>> + fit within this buffer and we always can transfer GCOV_BLOCK_SIZE
>> + to and from the disk. libgcov never backtracks and only writes 4
>> + or 8 byte objects. */
>> + gcov_unsigned_t buffer[GCOV_BLOCK_SIZE + 1];
>> +#else
>> + int endian; /* Swap endianness. */
>> + /* Holds a variable length block, as the compiler can write
>> + strings and needs to backtrack. */
>> + size_t alloc;
>> + gcov_unsigned_t *buffer;
>> +#endif
>> +} gcov_var;
>> +
>> +/* Save the current position in the gcov file. */
>> +static inline gcov_position_t
>> +gcov_position (void)
>> +{
>> + gcc_assert (gcov_var.mode > 0);
>> + return gcov_var.start + gcov_var.offset;
>> +}
>> +
>> +/* Return nonzero if the error flag is set. */
>> +static inline int
>> +gcov_is_error (void)
>> +{
>> + return gcov_var.file ? gcov_var.error : 1;
>> +}
>> +
>> +#if IN_LIBGCOV
>> +/* Move to beginning of file and initialize for writing. */
>> +GCOV_LINKAGE inline void
>> +gcov_rewrite (void)
>> +{
>> + gcc_assert (gcov_var.mode > 0);
>
> I would turn those two asserts into checking asserts so they do not
> bloat the runtime lib.
Ok, but note that there are a number of other gcc_assert already in
gcov-io.c (these were the only 2 in gcov-io.h, now moved here). Should
I go ahead and change all of them in gcov-io.c?
Thanks,
Teresa
>
> Thanks,
> Honza
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: [PATCH] Fix PR c++/59638
On 2014-01-06 14:36, Jason Merrill wrote: On 01/04/2014 04:54 AM, Adam Butcher wrote: + /* Declarations involving function parameter lists containing implicit + template parameters will have been made into implicit templates. If they + do not turn out to be actual function declarations then finish the + template declaration here. */ This will always be an error, right? Please mention that in the comment. OK with that change. Yes I think so. Will commit with this mod: diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 991588d..68f81b7 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -16784,10 +16784,11 @@ cp_parser_init_declarator (cp_parser* parser, warning (OPT_Wattributes, "attributes after parenthesized initializer ignored"); - /* Declarations involving function parameter lists containing implicit - template parameters will have been made into implicit templates. If they - do not turn out to be actual function declarations then finish the - template declaration here. */ + /* A non-template declaration involving a function parameter list containing + an implicit template parameter will have been made into a template. If it + turns out that the resulting declaration is not an actual function then + finish the template declaration here. An error message will already have + been issued. */ if (parser->fully_implicit_function_template_p) if (!function_declarator_p (declarator)) finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
[PATCH] RTEMS: Generalize t-rtems usage
2014-01-06 Sebastian Huber
* config.gcc (*-*-rtems*): Add t-rtems to tmake_file.
(arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*): Do not
override an existing tmake_file.
(arm*-*-rtems*): Use t-rtems from existing tmake_file.
(avr-*-rtems*): Likewise.
(bfin*-rtems*): Likewise.
(moxie-*-rtems*): Likewise.
(h8300-*-rtems*): Likewise.
(i[34567]86-*-rtems*): Likewise.
(lm32-*-rtems*): Likewise.
(m32r-*-rtems*): Likewise.
(m68k-*-rtems*): Likewise.
(microblaze*-*-rtems*): Likewise.
(mips*-*-rtems*): Likewise.
(powerpc-*-rtems*): Likewise.
(sh-*-rtems*): Likewise.
(sparc-*-rtems*): Likewise.
(sparc64-*-rtems*): Likewise.
(v850-*-rtems*): Likewise.
(m32c-*-rtems*): Likewise.
---
gcc/config.gcc | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index bd0fb63..50e86e5 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -775,6 +775,7 @@ case ${target} in
case ${enable_threads} in
yes) thread_file='rtems' ;;
esac
+ tmake_file="${tmake_file} t-rtems"
extra_options="${extra_options} rtems.opt"
default_use_cxa_atexit=yes
use_gcc_stdint=wrap
@@ -1027,7 +1028,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
esac
default_use_cxa_atexit=yes
tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
- tmake_file="arm/t-arm arm/t-arm-elf"
+ tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf"
case ${target} in
arm*-*-eabi*)
tm_file="$tm_file newlib-stdint.h"
@@ -1036,7 +1037,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
;;
arm*-*-rtems*)
tm_file="${tm_file} rtems.h arm/rtems-eabi.h newlib-stdint.h"
- tmake_file="${tmake_file} arm/t-bpabi t-rtems arm/t-rtems-eabi"
+ tmake_file="${tmake_file} arm/t-bpabi arm/t-rtems-eabi"
;;
arm*-*-symbianelf*)
tm_file="${tm_file} arm/symbian.h"
@@ -1049,7 +1050,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
;;
avr-*-rtems*)
tm_file="elfos.h avr/elf.h avr/avr-arch.h avr/avr.h dbxelf.h
avr/rtems.h rtems.h newlib-stdint.h"
- tmake_file="avr/t-avr avr/t-multilib t-rtems avr/t-rtems"
+ tmake_file="${tmake_file} avr/t-avr avr/t-multilib avr/t-rtems"
extra_gcc_objs="driver-avr.o avr-devices.o"
extra_objs="avr-devices.o avr-log.o"
;;
@@ -1081,7 +1082,7 @@ bfin*-linux-uclibc*)
;;
bfin*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h bfin/elf.h bfin/rtems.h rtems.h
newlib-stdint.h"
- tmake_file="t-rtems bfin/t-rtems"
+ tmake_file="${tmake_file} bfin/t-rtems"
;;
bfin*-*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h bfin/elf.h"
@@ -1155,11 +1156,11 @@ moxie-*-uclinux*)
tmake_file="${tmake_file} moxie/t-moxie"
;;
moxie-*-rtems*)
- tmake_file="${tmake_file} moxie/t-moxie t-rtems"
+ tmake_file="${tmake_file} moxie/t-moxie"
tm_file="moxie/moxie.h dbxelf.h elfos.h moxie/rtems.h rtems.h
newlib-stdint.h"
;;
h8300-*-rtems*)
- tmake_file="h8300/t-h8300 t-rtems h8300/t-rtems"
+ tmake_file="${tmake_file} h8300/t-h8300 h8300/t-rtems"
tm_file="h8300/h8300.h dbxelf.h elfos.h h8300/elf.h h8300/rtems.h
rtems.h newlib-stdint.h"
;;
h8300-*-elf*)
@@ -1500,7 +1501,7 @@ i[34567]86-*-nto-qnx*)
;;
i[34567]86-*-rtems*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
i386/i386elf.h i386/rtemself.h rtems.h newlib-stdint.h"
- tmake_file="${tmake_file} i386/t-rtems t-rtems"
+ tmake_file="${tmake_file} i386/t-rtems"
;;
i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
tm_file="${tm_file} i386/unix.h i386/att.h ${sol2_tm_file}"
@@ -1748,7 +1749,6 @@ lm32-*-elf*)
lm32-*-rtems*)
tm_file="dbxelf.h elfos.h ${tm_file} lm32/rtems.h rtems.h
newlib-stdint.h"
tmake_file="${tmake_file} lm32/t-lm32"
- tmake_file="${tmake_file} t-rtems"
tmake_file="${tmake_file} lm32/t-rtems"
;;
lm32-*-uclinux*)
@@ -1763,7 +1763,7 @@ m32rle-*-elf*)
;;
m32r-*-rtems*)
tm_file="dbxelf.h elfos.h ${tm_file} m32r/rtems.h rtems.h
newlib-stdint.h"
- tmake_file="m32r/t-m32r t-rtems"
+ tmake_file="${tmake_file} m32r/t-m32r"
;;
m32r-*-linux*)
tm_file="dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file}
m32r/linux.h"
@@ -1854,7 +1854,7 @@ m68k-*-linux*)# Motorola m68k's
running GNU/Linux
m68k-*-rtems*)
default_m68k_cpu=68020
default_cf_cpu=5206
- tmake_file="m68k/t-floatlib m68k/t-m68kbare m68k/t-crtstuff t-rtems
m68k/t-rtems m68k/t-mlibs"
+ tmake_file="${tmake_file} m68k/t-floatlib m68k/t-m68kbare
m68k/t-crtstuff m68k/t-rtems m68k/t-mlibs"
tm_
Re: [PATCH] Fix PR58115
Bernd Edlinger writes:
>>
>> Jakub Jelinek wrote:
>>>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
Of course, IMO, the cleanest fix would be to use switchable targets
for i386...
>>>
>>>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
>>>to
>>>compile because even with just a few routines in a CU there are
>>>hundreds or
>>>thousands of IRA reinitializations.
>>
>> We also want a big fat comment before the non-obvious order of inits
>> when switching cfuns.
>>
>> Bernd, please revert your patch for now.
>>
>
> OK, reverted for now.
Thanks Bernd. (And sorry for the tone of my original message -- wasn't happy
with that when I read it back.)
How about this patch for the big comment?
Thanks,
Richard
gcc/
* function.c (invoke_set_current_function_hook): Add more commentary.
Index: gcc/function.c
===
--- gcc/function.c 2014-01-06 19:09:27.821167117 +
+++ gcc/function.c 2014-01-06 19:15:27.764240857 +
@@ -4405,9 +4405,23 @@ invoke_set_current_function_hook (tree f
cl_optimization_restore (&global_options, TREE_OPTIMIZATION (opts));
}
+ /* Give the target an opportunity to change the global state in
+response to function attributes. This includes picking the
+correct value of this_target on SWITCHABLE_TARGET targets.
+
+Note that this_target (and in particular this_target_optabs)
+should always reflect the target state with default optimization
+options. We therefore call the target hook first and then apply
+any function-specific optimization options on top. */
targetm.set_current_function (fndecl);
+
+ /* Set this_fn_optabs appropriately, on the assumption that we
+want the default optimization options. */
this_fn_optabs = this_target_optabs;
+ /* Now adjust this_fn_optabs if using non-default optimization options.
+init_tree_optimization_optabs ensures that the cached value of
+TREE_OPTIMIZATION_OPTABS (opts) is correct for this_target. */
if (opts != optimization_default_node)
{
init_tree_optimization_optabs (opts);
libgo patch committed: Recognize arm64
This libgo patch from Michael Hudson-Doyle recognizes arm64 as the Go
name for the AArch64 architecture. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 070005ab99f5 libgo/configure.ac
--- a/libgo/configure.ac Sun Jan 05 19:00:53 2014 -0800
+++ b/libgo/configure.ac Mon Jan 06 11:13:23 2014 -0800
@@ -174,6 +174,7 @@
is_386=no
is_alpha=no
is_arm=no
+is_arm64=no
is_m68k=no
mips_abi=unknown
is_ppc=no
@@ -187,6 +188,10 @@
is_alpha=yes
GOARCH=alpha
;;
+ aarch64-*-*)
+is_arm64=yes
+GOARCH=arm64
+;;
arm*-*-* | strongarm*-*-* | ep9312*-*-* | xscale-*-*)
is_arm=yes
GOARCH=arm
@@ -267,6 +272,7 @@
AM_CONDITIONAL(LIBGO_IS_386, test $is_386 = yes)
AM_CONDITIONAL(LIBGO_IS_ALPHA, test $is_alpha = yes)
AM_CONDITIONAL(LIBGO_IS_ARM, test $is_arm = yes)
+AM_CONDITIONAL(LIBGO_IS_ARM64, test $is_arm64 = yes)
AM_CONDITIONAL(LIBGO_IS_M68K, test $is_m68k = yes)
AM_CONDITIONAL(LIBGO_IS_MIPS, test $mips_abi != unknown)
AM_CONDITIONAL(LIBGO_IS_MIPSO32, test $mips_abi = o32)
diff -r 070005ab99f5 libgo/go/go/build/build.go
--- a/libgo/go/go/build/build.go Sun Jan 05 19:00:53 2014 -0800
+++ b/libgo/go/go/build/build.go Mon Jan 06 11:13:23 2014 -0800
@@ -1211,6 +1211,8 @@
return "6", nil
case "arm":
return "5", nil
+ case "arm64":
+ return "7", nil
}
return "", errors.New("unsupported GOARCH " + goarch)
}
diff -r 070005ab99f5 libgo/go/go/build/deps_test.go
--- a/libgo/go/go/build/deps_test.go Sun Jan 05 19:00:53 2014 -0800
+++ b/libgo/go/go/build/deps_test.go Mon Jan 06 11:13:23 2014 -0800
@@ -360,7 +360,7 @@
var bools = []bool{false, true}
var geese = []string{"darwin", "dragonfly", "freebsd", "linux", "netbsd", "openbsd", "plan9", "windows"}
-var goarches = []string{"386", "amd64", "arm"}
+var goarches = []string{"386", "amd64", "arm", "arm64"}
type osPkg struct {
goos, pkg string
diff -r 070005ab99f5 libgo/go/go/build/syslist.go
--- a/libgo/go/go/build/syslist.go Sun Jan 05 19:00:53 2014 -0800
+++ b/libgo/go/go/build/syslist.go Mon Jan 06 11:13:23 2014 -0800
@@ -5,4 +5,4 @@
package build
const goosList = "darwin dragonfly freebsd linux netbsd openbsd plan9 windows solaris "
-const goarchList = "386 amd64 arm alpha m68k mipso32 mipsn32 mipsn64 mipso64 ppc ppc64 sparc sparc64 "
+const goarchList = "386 amd64 arm arm64 alpha m68k mipso32 mipsn32 mipsn64 mipso64 ppc ppc64 sparc sparc64 "
diff -r 070005ab99f5 libgo/go/runtime/extern.go
--- a/libgo/go/runtime/extern.go Sun Jan 05 19:00:53 2014 -0800
+++ b/libgo/go/runtime/extern.go Mon Jan 06 11:13:23 2014 -0800
@@ -185,5 +185,5 @@
const GOOS string = theGoos
// GOARCH is the running program's architecture target:
-// 386, amd64, or arm.
+// 386, amd64, arm or arm64.
const GOARCH string = theGoarch
[PATCH] Fix PR57386 for 4.8/4.9 on powerpc
I could have sworn I sent this patch out in mid-December, but I don't see it, so I'm resending this now. This patch fixes the problem that breaks some code on the SPE. I have patches for 4.8 and 4.9. Roland says that it fixes the problem in 4.8. In 4.9 there are other unrelated problems that Roland is currently working on. I tested these patches on powerpc linux, and I did not see a regression. Are these patches ok to check into both the 4.8 and 4.9 branches? 2013-12-12 Roland Stigge Michael Meissner * config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p): Only check TFmode for SPE constants. Don't check TImode or TDmode. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797 Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 205902) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -5428,12 +5428,13 @@ rs6000_legitimate_offset_address_p (enum break; case TFmode: -case TDmode: -case TImode: if (TARGET_E500_DOUBLE) return (SPE_CONST_OFFSET_OK (offset) && SPE_CONST_OFFSET_OK (offset + 8)); + /* fall through */ +case TDmode: +case TImode: extra = 8; if (!worst_case) break; Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 205896) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -6321,13 +6321,14 @@ rs6000_legitimate_offset_address_p (enum break; case TFmode: -case TDmode: -case TImode: -case PTImode: if (TARGET_E500_DOUBLE) return (SPE_CONST_OFFSET_OK (offset) && SPE_CONST_OFFSET_OK (offset + 8)); + /* fall through */ +case TDmode: +case TImode: +case PTImode: extra = 8; if (!worst_case) break;
Re: [Patch, Fortran] PR 59023: [4.9 regression] ICE in gfc_search_interface with BIND(C)
Hi Paul, > Happy New Year! same to you! > The patch is OK for trunk. Thanks, committed as r206355, reducing the regression count by two in one go. Unfortunately it's still at what is probably an all-time high for gfortran (~40). I'm about to post another regfix soon (for PR 59589), and I'd love to see others join me and Mikael in the regbashing game ... ;) Cheers, Janus > On 3 January 2014 10:29, Janus Weil wrote: >> In addition this patch fixes PR 59662. >> >> Also: Ping! >> >> Cheers, >> Janus >> >> >> >> 2013/12/31 Janus Weil : >>> Hi all, >>> >>> ... and the reg-bashing continues: Here is a small patch to fix a >>> bind(c) problem. It essentially prevents 'resolve_global_procedure' to >>> be applied to bind(c) procedures. >>> >>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >>> >>> Cheers, >>> Janus >>> >>> >>> >>> 2013-12-31 Janus Weil >>> >>> PR fortran/59023 >>> * resolve.c (resolve_global_procedure): Don't apply to c-binding >>> procedures. >>> (gfc_verify_binding_labels): Remove duplicate line. >>> >>> 2013-12-31 Janus Weil >>> >>> PR fortran/59023 >>> * gfortran.dg/bind_c_procs_2.f90: New. > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. >--Hitchhikers Guide to the Galaxy
[PATCH] Fix up my recent PR59501 i?86 changes (PR target/59644)
Hi!
As discussed in the PR, my recent patch broke the Linux kernel.
The problem is that if register allocation calls ix86_compute_frame_layout
to determine elimination offsets and the DRAP register is assumed saved at
that point, but later on during pro_epilogue pass
ix86_finalize_stack_realign_flags determines we don't need to save/restore
the DRAP register, it is in some cases already too late, as the size of the
DRAP register save slot is accounted for in the RA elimination offsets in
instructions (both for fp -> hfp elimination or even argp -> sp).
So, this patch essentially reverts part of those changes, the only way to do
it if there are rsp/rbp references in the function is to do this during LRA
(perhaps some target hook), if there is some point where we know we won't
need further vector mode spill slots and thus can know whether we'll need
dynamic stack readjustment or not, and could still change elimination
offsets. For the easy case where a leaf function doesn't mention rsp/rbp
anywhere we can still avoid saving/restoring the DRAP register unnecessarily
as the patch does, if it is needed at all, and if not continue to not set it
up at all nor save/restore.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-01-06 Jakub Jelinek
PR target/59644
* config/i386/i386.h (struct machine_function): Add
no_drap_save_restore field.
* config/i386/i386.c (ix86_save_reg): Use
!cfun->machine->no_drap_save_restore instead of
crtl->stack_realign_needed.
(ix86_finalize_stack_realign_flags): Don't clear drap_reg unless
this function clears frame_pointer_needed. Set
cfun->machine->no_drap_save_restore if clearing frame_pointer_needed
and DRAP reg is needed.
* gcc.target/i386/pr59644.c: New test.
--- gcc/config/i386/i386.h.jj 2014-01-03 11:41:06.0 +0100
+++ gcc/config/i386/i386.h 2014-01-06 13:41:10.445337916 +0100
@@ -2419,6 +2419,9 @@ struct GTY(()) machine_function {
stack below the return address. */
BOOL_BITFIELD static_chain_on_stack : 1;
+ /* If true, it is safe to not save/restore DRAP register. */
+ BOOL_BITFIELD no_drap_save_restore : 1;
+
/* During prologue/epilogue generation, the current frame state.
Otherwise, the frame state at the end of the prologue. */
struct machine_frame_state fs;
--- gcc/config/i386/i386.c.jj 2014-01-04 10:56:54.0 +0100
+++ gcc/config/i386/i386.c 2014-01-06 13:42:53.016821514 +0100
@@ -9281,7 +9281,7 @@ ix86_save_reg (unsigned int regno, bool
if (crtl->drap_reg
&& regno == REGNO (crtl->drap_reg)
- && crtl->stack_realign_needed)
+ && !cfun->machine->no_drap_save_restore)
return true;
return (df_regs_ever_live_p (regno)
@@ -10519,18 +10519,6 @@ ix86_finalize_stack_realign_flags (void)
return;
}
- /* If drap has been set, but it actually isn't live at the start
- of the function and !stack_realign, there is no reason to set it up. */
- if (crtl->drap_reg && !stack_realign)
-{
- basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb;
- if (! REGNO_REG_SET_P (DF_LR_IN (bb), REGNO (crtl->drap_reg)))
- {
- crtl->drap_reg = NULL_RTX;
- crtl->need_drap = false;
- }
-}
-
/* If the only reason for frame_pointer_needed is that we conservatively
assumed stack realignment might be needed, but in the end nothing that
needed the stack alignment had been spilled, clear frame_pointer_needed
@@ -10584,6 +10572,8 @@ ix86_finalize_stack_realign_flags (void)
crtl->need_drap = false;
}
}
+ else
+ cfun->machine->no_drap_save_restore = true;
frame_pointer_needed = false;
stack_realign = false;
--- gcc/testsuite/gcc.target/i386/pr59644.c.jj 2014-01-06 14:19:52.201616003
+0100
+++ gcc/testsuite/gcc.target/i386/pr59644.c 2014-01-06 14:22:04.606940097
+0100
@@ -0,0 +1,42 @@
+/* PR target/59644 */
+/* { dg-do run { target lp64 } } */
+/* { dg-options "-O2 -ffreestanding -mno-sse -mpreferred-stack-boundary=3
-maccumulate-outgoing-args -mno-red-zone" } */
+
+/* This test uses __builtin_trap () instead of e.g. abort,
+ because due to -mpreferred-stack-boundary=3 it should not call
+ any library function from within main (). */
+
+#include
+
+__attribute__((noinline, noclone))
+int
+bar (int x, int y, int z, int w, const char *fmt, va_list ap)
+{
+ if (x != 1 || y != 2 || z != 3 || w != 4)
+__builtin_trap ();
+ if (fmt[0] != 'f' || fmt[1] != 'o' || fmt[2] != 'o' || fmt[3])
+__builtin_trap ();
+ if (va_arg (ap, int) != 5 || va_arg (ap, int) != 6
+ || va_arg (ap, long long) != 7LL)
+__builtin_trap ();
+ return 9;
+}
+
+__attribute__((noinline, noclone, optimize ("Os")))
+int
+foo (const char *fmt, ...)
+{
+ va_list ap;
+ va_start (ap, fmt);
+ int r = bar (1, 2, 3, 4, fmt, ap);
+ va_end (ap);
+ return r;
+}
+
+int
+main ()
+{
+
Re: [PATCH] Fix up my recent PR59501 i?86 changes (PR target/59644)
On 01/06/2014 01:07 PM, Jakub Jelinek wrote: > 2014-01-06 Jakub Jelinek > > PR target/59644 > * config/i386/i386.h (struct machine_function): Add > no_drap_save_restore field. > * config/i386/i386.c (ix86_save_reg): Use > !cfun->machine->no_drap_save_restore instead of > crtl->stack_realign_needed. > (ix86_finalize_stack_realign_flags): Don't clear drap_reg unless > this function clears frame_pointer_needed. Set > cfun->machine->no_drap_save_restore if clearing frame_pointer_needed > and DRAP reg is needed. > > * gcc.target/i386/pr59644.c: New test. Ok. r~
Re: [patch] PR56572 flatten unnecessary nested transactions after inlining
On 12/19/2013 11:06 AM, Richard Biener wrote: > Aldy Hernandez wrote: >> I'd still like to catch the common cases, like I do with this patch. >> >> Perhaps we move this code to the .tmmark pass and handle the >> uninstrumented case. rth? tmmark is way way later than you'd want. I believe that ipa_tm is the right place. That's where we generate clones. The clones know a-priori that they're called within a transaction and thus all internal transations may be eliminated. And thus any inlining that would happen after ipa_tm would properly inline the clone, and thus no more need be done. > Btw, don't you want an IPA pass that clones functions called from within > transactions and optimize those accordingly? That's what we have, modulo the "optimize those accordingly". > Thus make the tm lowering a real IPA pass? There are plenty of tm-related passes, one of which is "lower_tm". Like most of the other "lower" passes, the high-level gimple that it processes can't be used as input to build_cfg. r~
RE: [PATCH] Fix PR58115
On Mon, 6 Jan 2014 19:16:57, Richard Saniford wrote:
>
> Bernd Edlinger writes:
>>>
>>> Jakub Jelinek wrote:
On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
> Of course, IMO, the cleanest fix would be to use switchable targets
> for i386...
We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
to
compile because even with just a few routines in a CU there are
hundreds or
thousands of IRA reinitializations.
>>>
>>> We also want a big fat comment before the non-obvious order of inits
>>> when switching cfuns.
>>>
>>> Bernd, please revert your patch for now.
>>>
>>
>> OK, reverted for now.
>
> Thanks Bernd. (And sorry for the tone of my original message -- wasn't happy
> with that when I read it back.)
>
No problem, Richard, I don't see this personally in any way.
> How about this patch for the big comment?
>
The comment should say that target_set_current_function()
cannot call target_reinit() because:
target_reinit()=>lang_dependent_init_target()
=>init_optabs()=>init_all_optabs(this_fn_optabs);
uses this_fn_optabs which is undefined here.
However many targets (nios2, rx, i386, rs6000) do exactly that.
Is there currently any target, that sets this_target_optab in the
target_set_current_function?
Regards,
Bernd.
> Thanks,
> Richard
>
>
> gcc/
> * function.c (invoke_set_current_function_hook): Add more commentary.
>
> Index: gcc/function.c
> ===
> --- gcc/function.c 2014-01-06 19:09:27.821167117 +
> +++ gcc/function.c 2014-01-06 19:15:27.764240857 +
> @@ -4405,9 +4405,23 @@ invoke_set_current_function_hook (tree f
> cl_optimization_restore (&global_options, TREE_OPTIMIZATION (opts));
> }
>
> + /* Give the target an opportunity to change the global state in
> + response to function attributes. This includes picking the
> + correct value of this_target on SWITCHABLE_TARGET targets.
> +
> + Note that this_target (and in particular this_target_optabs)
> + should always reflect the target state with default optimization
> + options. We therefore call the target hook first and then apply
> + any function-specific optimization options on top. */
> targetm.set_current_function (fndecl);
> +
> + /* Set this_fn_optabs appropriately, on the assumption that we
> + want the default optimization options. */
> this_fn_optabs = this_target_optabs;
>
> + /* Now adjust this_fn_optabs if using non-default optimization options.
> + init_tree_optimization_optabs ensures that the cached value of
> + TREE_OPTIMIZATION_OPTABS (opts) is correct for this_target. */
> if (opts != optimization_default_node)
> {
> init_tree_optimization_optabs (opts);
>
[Patch, Fortran, OOP] PR 59589: [4.9 Regression] Memory leak when deallocating polymorphic
Hi all,
here is a regression fix for polymorphic deallocation. The attached
patch is identical in functionality to the one-liner in comment 13 of
the PR, fixing a bug in the detection of finalizable components (with
include allocatable components).
All it does in addition to the one-liner is to encapsulate the code
necessary to detect finalizable components into a function, which is
then used in two different places. This makes the code less
error-prone and more readable.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-01-06 Janus Weil
PR fortran/59589
* class.c (comp_is_finalizable): New function to dermine if a given
component is finalizable.
(finalize_component, generate_finalization_wrapper): Use it.
2014-01-06 Janus Weil
PR fortran/59589
* gfortran.dg/class_allocate_16.f90: New.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 206374)
+++ gcc/fortran/class.c (working copy)
@@ -787,6 +787,25 @@ has_finalizer_component (gfc_symbol *derived)
}
+static bool
+comp_is_finalizable (gfc_component *comp)
+{
+ if (comp->attr.allocatable && comp->ts.type != BT_CLASS)
+return true;
+ else if (comp->ts.type == BT_DERIVED && !comp->attr.pointer
+ && (comp->ts.u.derived->attr.alloc_comp
+ || has_finalizer_component (comp->ts.u.derived)
+ || (comp->ts.u.derived->f2k_derived
+ && comp->ts.u.derived->f2k_derived->finalizers)))
+return true;
+ else if (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+ && CLASS_DATA (comp)->attr.allocatable)
+return true;
+ else
+return false;
+}
+
+
/* Call DEALLOCATE for the passed component if it is allocatable, if it is
neither allocatable nor a pointer but has a finalizer, call it. If it
is a nonpointer component with allocatable components or has finalizers,
walk
@@ -803,21 +822,9 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
gfc_expr *e;
gfc_ref *ref;
- if (comp->ts.type != BT_DERIVED && comp->ts.type != BT_CLASS
- && !comp->attr.allocatable)
+ if (!comp_is_finalizable (comp))
return;
- if ((comp->ts.type == BT_DERIVED && comp->attr.pointer)
- || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
- && CLASS_DATA (comp)->attr.pointer))
-return;
-
- if (comp->ts.type == BT_DERIVED && !comp->attr.allocatable
- && (comp->ts.u.derived->f2k_derived == NULL
- || comp->ts.u.derived->f2k_derived->finalizers == NULL)
- && !has_finalizer_component (comp->ts.u.derived))
-return;
-
e = gfc_copy_expr (expr);
if (!e->ref)
e->ref = ref = gfc_get_ref ();
@@ -1462,17 +1469,7 @@ generate_finalization_wrapper (gfc_symbol *derived
&& ancestor_wrapper && ancestor_wrapper->expr_type != EXPR_NULL)
continue;
- if (comp->ts.type != BT_CLASS && !comp->attr.pointer
- && (comp->attr.allocatable
- || (comp->ts.type == BT_DERIVED
- && (comp->ts.u.derived->attr.alloc_comp
- || has_finalizer_component (comp->ts.u.derived)
- || (comp->ts.u.derived->f2k_derived
- && comp->ts.u.derived->f2k_derived->finalizers)
- finalizable_comp = true;
- else if (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
-&& CLASS_DATA (comp)->attr.allocatable)
- finalizable_comp = true;
+ finalizable_comp |= comp_is_finalizable (comp);
}
/* If there is no new finalizer and no new allocatable, return with
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
!
! PR 59589: [4.9 Regression] [OOP] Memory leak when deallocating polymorphic
!
! Contributed by Rich Townsend
implicit none
type :: foo
real, allocatable :: x(:)
end type
type :: bar
type(foo) :: f
end type
class(bar), allocatable :: b
allocate(bar::b)
allocate(b%f%x(100))
b%f%x = 1.
deallocate(b)
end
! { dg-final { scan-tree-dump-times "__builtin_free" 4 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Re: [Patch, Fortran, OOP] PR 59589: [4.9 Regression] Memory leak when deallocating polymorphic
On Mon, Jan 06, 2014 at 11:28:51PM +0100, Janus Weil wrote: > > here is a regression fix for polymorphic deallocation. The attached > patch is identical in functionality to the one-liner in comment 13 of > the PR, fixing a bug in the detection of finalizable components (with > include allocatable components). > > All it does in addition to the one-liner is to encapsulate the code > necessary to detect finalizable components into a function, which is > then used in two different places. This makes the code less > error-prone and more readable. > > Regtested on x86_64-unknown-linux-gnu. Ok for trunk? > Yes. PS: Thanks for the recent spurt of bugfixes. -- Steve
Re: [patch] PR56572 flatten unnecessary nested transactions after inlining
On 01/06/14 13:40, Richard Henderson wrote: On 12/19/2013 11:06 AM, Richard Biener wrote: Aldy Hernandez wrote: I'd still like to catch the common cases, like I do with this patch. Perhaps we move this code to the .tmmark pass and handle the uninstrumented case. rth? tmmark is way way later than you'd want. I believe that ipa_tm is the right place. That's where we generate clones. The clones know a-priori that they're called within a transaction and thus all internal transations may be eliminated. And thus any inlining that would happen after ipa_tm would properly inline the clone, and thus no more need be done. But ipa_tm still runs before the latter inliner: ... u.c.041i.tmipa u.c.043i.whole-program u.c.044i.profile_estimate u.c.045i.devirt u.c.046i.cp u.c.048i.inline So even though my proposed patch works in the supplied testcase (because the early inliner ran before .tmipa and inlined the nested transaction), if the latter inliner added a nested transaction we're in the same boat. I just saw this happen with LTO, as Richi pointed out. What do you suggest?
Re: [patch] PR56572 flatten unnecessary nested transactions after inlining
On 01/06/14 15:04, Aldy Hernandez wrote:
On 01/06/14 13:40, Richard Henderson wrote:
On 12/19/2013 11:06 AM, Richard Biener wrote:
Aldy Hernandez wrote:
I'd still like to catch the common cases, like I do with this patch.
Perhaps we move this code to the .tmmark pass and handle the
uninstrumented case. rth?
tmmark is way way later than you'd want. I believe that ipa_tm is the
right
place. That's where we generate clones. The clones know a-priori
that they're
called within a transaction and thus all internal transations may be
eliminated. And thus any inlining that would happen after ipa_tm would
properly inline the clone, and thus no more need be done.
But ipa_tm still runs before the latter inliner:
...
u.c.041i.tmipa
u.c.043i.whole-program
u.c.044i.profile_estimate
u.c.045i.devirt
u.c.046i.cp
u.c.048i.inline
So even though my proposed patch works in the supplied testcase (because
the early inliner ran before .tmipa and inlined the nested transaction),
if the latter inliner added a nested transaction we're in the same boat.
I just saw this happen with LTO, as Richi pointed out.
What do you suggest?
Though, let me clarify what I saw. LTO would only do it's cross TU
inlining thing if the inlinee was marked as transaction_safe, because
anything else wouldn't be valid inside an atomic transaction:
reynosa:/dev/shm/trunk/gcc/u$ cat d.c
int a;
void inc(){
__transaction_atomic { a++; }
}
reynosa:/dev/shm/trunk/gcc/u$ cat e.c
extern void inc() __attribute__((transaction_safe));
main()
{
__transaction_atomic {
inc();
}
}
So perhaps we don't care about LTO inlining, since most of what it would
inline isn't valid within the transactional context ??. So perhaps just
getting rid of transactions appearing in a clone we're about to create
in ipa-tm is all we need? Is that what you were getting at, or am I
running around in circles here? :)
Aldy
Fix build under "make --no-builtin-rules"
Hi, The following tiny patch allows GCC to be built with the "--no-builtin-rules" GNU make flag. It replaces two usages of the automatic variable $* within the body of an explicit rule. Using $* inside the body of an explicit rule should be avoided[0] and, as in this scenario, may break an otherwise fine Makefile under the --no-builtin-rules flag. >From what I inferred from the make manual[0], $* is functionally equivalent to $(basename $@) in this case. This patch therefore replaces $* with $(basename $@). I tested this patch by successfully performing a 3-stage bootstrap and a non-bootstrap build with and without the --no-builtin-rules flag. Without the patch, the build would fail during the compilation of libgcc/morestack.S under the --no-builtin-rules flag. This patch is interesting because the --no-builtin-rules flag may significantly shorten rebuild times. For example, on my machine an idempotent rebuild of the (non-bootstrapped) compiler takes 2s with the flag versus 2.6s without. Similarly, a rebuild after changing a single source file takes 20s versus 22s. This patch lets you seamlessly build and rebuild the compiler under the --no-builtin-rules flag without having to worry about possible build errors. [0]: http://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html#Automatic-Variables
Re: Fix build under "make --no-builtin-rules"
On Mon, Jan 6, 2014 at 6:33 PM, Patrick Palka wrote: > Hi, > > The following tiny patch allows GCC to be built with the > "--no-builtin-rules" GNU make flag. It replaces two usages of the > automatic variable $* within the body of an explicit rule. Using $* > inside the body of an explicit rule should be avoided[0] and, as in > this scenario, may break an otherwise fine Makefile under the > --no-builtin-rules flag. > > From what I inferred from the make manual[0], $* is functionally > equivalent to $(basename $@) in this case. This patch therefore > replaces $* with $(basename $@). I tested this patch by successfully > performing a 3-stage bootstrap and a non-bootstrap build with and > without the --no-builtin-rules flag. Without the patch, the build > would fail during the compilation of libgcc/morestack.S under the > --no-builtin-rules flag. > > This patch is interesting because the --no-builtin-rules flag may > significantly shorten rebuild times. For example, on my machine an > idempotent rebuild of the (non-bootstrapped) compiler takes 2s with > the flag versus 2.6s without. Similarly, a rebuild after changing a > single source file takes 20s versus 22s. This patch lets you > seamlessly build and rebuild the compiler under the --no-builtin-rules > flag without having to worry about possible build errors. > > [0]: > http://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html#Automatic-Variables Oops, forgot the patch: --- a/libgcc/ChangeLog +++ b/libgcc/ChangeLog @@ -1,3 +1,8 @@ +2014-01-06 Patrick Palka + + * shared-object.mk ($(base)$(objext)): Don't use $*. + * static-object.mk ($(base)$(objext)): Likewise. + 2014-01-02 Joseph Myers * config/rs6000/ibm-ldouble.c (__gcc_qdiv): Scale up arguments in diff --git a/libgcc/shared-object.mk b/libgcc/shared-object.mk index d9ee922..adbd165 100644 --- a/libgcc/shared-object.mk +++ b/libgcc/shared-object.mk @@ -25,7 +25,7 @@ endif endif $(base)$(objext): $o $(base).vis - $(gcc_compile) -c -xassembler-with-cpp -include $*.vis $< + $(gcc_compile) -c -xassembler-with-cpp -include $(basename $@).vis $< $(base).vis: $(base)_s$(objext) $(gen-hide-list) diff --git a/libgcc/static-object.mk b/libgcc/static-object.mk index 4f53636..19c3006 100644 --- a/libgcc/static-object.mk +++ b/libgcc/static-object.mk @@ -25,7 +25,7 @@ endif endif $(base)$(objext): $o $(base).vis - $(gcc_compile) -c -xassembler-with-cpp -include $*.vis $< + $(gcc_compile) -c -xassembler-with-cpp -include $(basename $@).vis $< $(base).vis: $(base)_s$(objext) $(gen-hide-list)
Re: Fix build under "make --no-builtin-rules"
Patrick Palka writes: > From what I inferred from the make manual[0], $* is functionally > equivalent to $(basename $@) in this case. Or $(base), I think. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Fix build under "make --no-builtin-rules"
On Mon, Jan 6, 2014 at 6:47 PM, Andreas Schwab wrote: > Patrick Palka writes: > >> From what I inferred from the make manual[0], $* is functionally >> equivalent to $(basename $@) in this case. > > Or $(base), I think. > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." I tried using $(base) but I wound up with a different build error. When compiling morestack.S, $(base) gets expanded into "unwind-sjlj" instead of "morestack". I believe this is because Makefile variables inside rule bodies are late-bound/expanded.
Re: [PATCH] Fix PR57386 for 4.8/4.9 on powerpc
On Mon, Jan 6, 2014 at 2:33 PM, Michael Meissner wrote: > I could have sworn I sent this patch out in mid-December, but I don't see it, > so I'm resending this now. > > This patch fixes the problem that breaks some code on the SPE. I have patches > for 4.8 and 4.9. Roland says that it fixes the problem in 4.8. In 4.9 there > are other unrelated problems that Roland is currently working on. > > I tested these patches on powerpc linux, and I did not see a regression. Are > these patches ok to check into both the 4.8 and 4.9 branches? > > 2013-12-12 Roland Stigge > Michael Meissner > > * config/rs6000/rs6000.c (rs6000_legitimate_offset_address_p): > Only check TFmode for SPE constants. Don't check TImode or > TDmode. Okay. Thanks, David
Re: [PATCH] pch bug fix (take 2, PR pch/59436)
On 01/01/14 16:08, Jakub Jelinek wrote: On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote: Without any gengtype.c changes, I wonder if just following change wouldn't do it, gengtype considers only char and unsigned char pointers as strings with the special strlen handling, all other scalar types are treated differently it seems, and signed char aliases everything too. Or s/signed char/void/ in the patch is perhaps even better. I've bootstrapped/regtested this on x86_64-linux and i686-linux, and hopefully verified the problem from the PR is gone, by running over 610 successful PCH write + PCH read cycles as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures with the patch, while on a tree from yesterday without the patch I could reproduce it 17 times, on average every 22 iterations (from 2 to 81). Ok for trunk (and after a while for 4.8)? 2014-01-01 Mike Stump Jakub Jelinek PR pch/59436 * tree-core.h (struct tree_optimization_option): Change optabs type from unsigned char * to void *. * optabs.c (init_tree_optimization_optabs): Adjust TREE_OPTIMIZATION_OPTABS initialization. OK for the trunk. Release managers have final say on 4.8. I hope this was the root cause of the occasional PCH failure I was seeing as well. Jeff
Re: [PATCH] Tiny predcom improvement (PR tree-optimization/59643)
On 12/31/13 12:04, Jakub Jelinek wrote: Hi! As written in the PR, I've been looking why is llvm 3.[34] so much faster on Scimark2 SOR benchmark and the reason is that it's predictive commoning or whatever it uses doesn't give up on the inner loop, while our predcom unnecessarily gives up, because there are reads that could alias the write. This simple patch improves the benchmark by 42%. We already ignore unsuitable dependencies for read/read, the patch extends that for unsuitable dependencies for read/write by just putting the read (and anything in it's component) into the bad component which is ignored. pcom doesn't optimize away the writes and will keep the potentially aliasing reads unmodified as well. Without the patch we'd merge the two components, and as !determine_offset between the two DRs, it would mean the whole merged component would be always unsuitable and thus ignored. With the patch we'll hopefully have some other reads with known offset to the write and can optimize that, so the patch should always either handle what it did before or handle perhaps some more cases. The inner loop from the (public domain) benchmark is added in the two tests, one runtime test and one test looking whether pcom actually optimized it. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2013-12-31 Jakub Jelinek PR tree-optimization/59643 * tree-predcom.c (split_data_refs_to_components): If one dr is read and one write, determine_offset fails and the write isn't in the bad component, just put the read into the bad component. * gcc.dg/pr59643.c: New test. * gcc.c-torture/execute/pr59643.c: New test. OK for the trunk. jeff
Re: [PATCH] Fix ifcvt (PR rtl-optimization/58668)
On 12/19/13 13:34, Jakub Jelinek wrote: On Thu, Dec 19, 2013 at 12:38:49PM +0100, Steven Bosscher wrote: Why not use active_insn_p instead of hand-checks for USE and CLOBBER insns? Because it brings in the JUMP_TABLE_DATA mess into the picture? Not as long as you look only between BB_HEAD and BB_END (JUMP_TABLE_DATA only appears outside basic blocks). AFAICT the code your patch touches only looks at insns contained in basic blocks. So like this instead? Bootstrapped/regtested on x86_64-linux and i686-linux. For 4.8 I'd still prefer the earlier patch though. 2013-12-18 Jakub Jelinek PR rtl-optimization/58668 * cfgcleanup.c (flow_find_cross_jump): Don't count any jumps if dir_p is NULL. Remove p1 variable, use active_insn_p to determine what is counted. (flow_find_head_matching_sequence): Use active_insn_p to determine what is counted. (try_head_merge_bb): Adjust for the flow_find_head_matching_sequence counting change. * ifcvt.c (count_bb_insns): Use active_insn_p && !JUMP_P to determine what is counted. * gcc.dg/pr58668.c: New test. This is fine for the trunk. Release manager's call for what they'd prefer on the 4.8 branch. jeff
Re: Inline functions tweeks 1/n
On 01/02/14 10:21, Jan Hubicka wrote: Hi, While looking for -Winline messages I noticed that sched-int.h has self recursive function declared inline. The recursion is tail recursion but we fail to recognize it as such. The problem ist hat there is a local variable link whose address is passed to function &DEPS_LIST_FIRST (list) and we are thus unsure if the memory location is dead. I tried to bring that function inline, too, but it does not help, since alias analysis won't figure out that passing the address to a function won't capture it because we do not have nocapture discovery in early passes (it may be valuable addition). Anyway, it is easy to turn recursion into iteration here and probably makes sense. Bootstrapped/regtested x86_64-linux, OK? Honza * sched-int.h (sd_iterator_cond): Manually tail recurse. Are these really things we need for 4.9? We're supposed to be fixing bugs right now :-) jeff
Re: [RFA][PATCH][PR middle-end/59285] BARRIERS and merged blocks
On 12/24/13 13:19, Steven Bosscher wrote:
On Fri, Dec 20, 2013 at 7:30 PM, Jeff Law wrote:
So here's an alternate approach to fixing 59285. I still think attacking
this in rtl_merge_blocks is better, but with nobody else chiming in to break
the deadlock Steven and myself are in, I'll go with Steven's preferred
solution (fix the callers in ifcvt.c).
I didn't intend to cause a deadlock, I only really want us to respect
the rules of the CFG, one of which is that you can't merge two basic
blocks that are not connected by an edge. I think this is a really
important invariant because it avoids accidental basic block merges
that are not correct.
I certainly don't think you're trying to cause a deadlock, I think it's
just in the nature of how many maintainers work. Once someone reviews a
patch, the other maintainers tend to step back and let the submitter and
reviewer iterate. That's not always the case, but it happens enough to
be noticeable, IMHO. And it's not necessarily bad. Anyway...
Note carefully that we're not merging blocks without edges between them.
That's a misunderstanding, most likely due to my initial messages on
this issue. I thought I explained things better in my most recent
message, I'll try again :-)
If we were to return to a "fix rtl_merge_blocks" approach, I would revamp
that patch to utilize the ideas in this one. Namely that it's not just
barriers between the merged blocks that are a problem. In fact, that's a
symptom of the problem. Things have already gone wrong by that point.
What has gone wrong at that point, is that we'd be trying to merge two
basic blocks that have no control flow connection. The case of
builtin_unreachable (the only legitimate case for an empty basic block
without successors) is a special case. (This is the reason why I would
like us to have a special instruction or some kind of other marker for
builtin_unreachable...)
No. That's a symptom of the problem. We were both barking up the wrong
tree earlier, in large part I'm sure due to my early conclusions.
Given blocks A & B that will be merged. If A has > 1 successor and B has no
successors, the combined block will always have at least 1 successor.
However, the combined block will be followed by a BARRIER that must be
removed.
Note this would happen automatically if there as an edge connecting
the blocks and a JUMP_INSN ending block B.
Umm, no. Read that paragraph again. Perhaps the RTL will help too.
Given:
(note 5 1 67 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
[ ... ]
(jump_insn 17 16 19 2 (set (pc)
(if_then_else (ne (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 25)
(pc))) j.c:14 236 {arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 5000 (nil)))
-> 25)
(note 19 17 18 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note/s 18 19 20 3 ("lab2") NOTE_INSN_DELETED_LABEL 3)
(note/s 20 18 21 ("lab") NOTE_INSN_DELETED_LABEL 4)
(barrier 21 20 25)
[ ... ]
We call merge blocks to merge blocks #2 and #3. Note well that block #2
reaches block #3 (and block #4). Block #3 has no successors. There's
no reason I can see that we can not request those blocks be merged. And
if they are merged, we *must* remove the BARRIER after block #3. If we
do that properly (per my most recent patch), all the other issues just
go away.
I propose we just punt on optimizing this case for now.
I disagree. There is no good reason why we can't handle this in a
sensible manner now.
For GCC 4.10
we should define what behavior should result from builtin_unreachable
(Should it trap? Can it be optimized away after a while to avoid these
unnecessary conditional jumps? ...) but for the moment it seems wrong
IMHO to only optimize this in the cond_exec case and to do so against
the rules of the control flow graph.
This problem can (and should) be addressed independently of a review of
the __builtin_unreachable semantics.
Something like the patch below, tested with a cross-compiler for arm-eabi.
What do you think of this approach?
PR middle-end/59285
* ifcvt. (cond_exec_find_if_block): Do not try to if-convert an empty
basic block without successors due to builtin_unreachable.
I still prefer my most recent patch.
jeff
Re: [Patch] Regex bracket matcher cache optimization
I'd prefer to propose another patch that should be commited with this
one, which fix bugs (say _M_flags & regex_constants::icase, not "&&"),
and do more "matcher optimization".
It is now more DRY (_RegexTranslator<>) and efficient, but
takes longer to compile, mainly because now we have 4 times more
_Compiler<> versions :)
Booted and tested with -m32 and -m64 respectively.
Thank you!
--
Regards,
Tim Shen
commit 9dcc87dd782c7a09b5e075e746ceb3d0c6f1f4db
Author: tim
Date: Mon Jan 6 00:03:41 2014 -0500
2014-01-07 Tim Shen
* bits/regex_automaton.tcc: Indentation fix.
* bits/regex_compiler.h (__compile_nfa<>(), _Compiler<>,
_RegexTranslator<> _AnyMatcher<>, _CharMatcher<>,
_BracketMatcher<>): Add bool option template parameter and
specialization to make matching more efficient and space saving.
* bits/regex_compiler.tcc: Likewise.
diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc
b/libstdc++-v3/include/bits/regex_automaton.tcc
index 7edc67f..e222803 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -134,9 +134,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_NFA<_TraitsT>::_M_dot(std::ostream& __ostr) const
{
__ostr << "digraph _Nfa {\n"
- " rankdir=LR;\n";
+ " rankdir=LR;\n";
for (size_t __i = 0; __i < this->size(); ++__i)
-(*this)[__i]._M_dot(__ostr, __i);
+ (*this)[__i]._M_dot(__ostr, __i);
__ostr << "}\n";
return __ostr;
}
diff --git a/libstdc++-v3/include/bits/regex_compiler.h
b/libstdc++-v3/include/bits/regex_compiler.h
index 4ac67df..4873166 100644
--- a/libstdc++-v3/include/bits/regex_compiler.h
+++ b/libstdc++-v3/include/bits/regex_compiler.h
@@ -39,11 +39,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
- template
+ template
struct _BracketMatcher;
/// Builds an NFA from an input iterator interval.
- template
+ template
class _Compiler
{
public:
@@ -63,7 +63,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typedef typename _ScannerT::_TokenT _TokenT;
typedef _StateSeq<_TraitsT>_StateSeqT;
typedef std::stack<_StateSeqT, std::vector<_StateSeqT>> _StackT;
- typedef _BracketMatcher<_TraitsT>
_BMatcherT;
+ typedef _BracketMatcher<_TraitsT, __icase, __collate> _BMatcherT;
typedef std::ctype_CtypeT;
// accepts a specific token or returns false.
@@ -95,12 +95,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_expression_term(_BMatcherT& __matcher);
bool
- _M_range_expression(_BMatcherT& __matcher);
-
- bool
- _M_collating_symbol(_BMatcherT& __matcher);
-
- bool
_M_equivalence_class(_BMatcherT& __matcher);
bool
@@ -134,8 +128,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__compile_nfa(_FwdIter __first, _FwdIter __last, const _TraitsT& __traits,
regex_constants::syntax_option_type __flags)
{
- using _Cmplr = _Compiler<_FwdIter, _TraitsT>;
- return _Cmplr(__first, __last, __traits, __flags)._M_get_nfa();
+ if (!(__flags & regex_constants::icase))
+ if (!(__flags & regex_constants::collate))
+ return _Compiler<_FwdIter, _TraitsT, false, false>
+ (__first, __last, __traits, __flags)._M_get_nfa();
+ else
+ return _Compiler<_FwdIter, _TraitsT, false, true>
+ (__first, __last, __traits, __flags)._M_get_nfa();
+ else
+ if (!(__flags & regex_constants::collate))
+ return _Compiler<_FwdIter, _TraitsT, true, false>
+ (__first, __last, __traits, __flags)._M_get_nfa();
+ else
+ return _Compiler<_FwdIter, _TraitsT, true, true>
+ (__first, __last, __traits, __flags)._M_get_nfa();
}
template
@@ -148,16 +154,110 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __compile_nfa(__cfirst, __cfirst + __len, __traits, __flags);
}
- template
-struct _AnyMatcher
+ // [28.13.14]
+ template
+class _RegexTranslator
{
- typedef typename _TraitsT::char_type _CharT;
+public:
+ typedef typename _TraitsT::char_type _CharT;
+ typedef typename _TraitsT::string_type _StringT;
+ typedef typename std::conditional<__collate,
+ _StringT,
+ _CharT>::type _StrTransT;
explicit
- _AnyMatcher(const _TraitsT& __traits)
+ _RegexTranslator(const _TraitsT& __traits)
: _M_traits(__traits)
{ }
+ _CharT
+ _M_translate(_CharT __ch) const
+ {
+ if (__icase)
+ return _M_traits.translate_nocase(__ch);
+ else if (__collate)
+ return _M_traits.translate(__ch);
+ else
+ return __ch;
+ }
+
+ _StrTransT
+ _M_transform(_CharT __ch) const
+ {
+ retu
