Re: [PATCH] RISC-V: Short-forward-branch opt for SiFive 7 series cores.
On Tue, Apr 30, 2019 at 4:47 PM Jim Wilson wrote: > The SiFive 7 series cores have macro fusion support to convert a branch over > a single instruction into a conditionally executed instruction. This adds > a conditional move pattern, enabled only for the SiFive 7 series cores, that > implements the initial optimization support for this feature. This gives us > about a 10% increase in coremark scores for this core. I forgot to mention that Andrew Waterman wrote the first version of the patch. I checked in an update to the ChangeLog entry to give him credit. Jim
[PATCH] PR libstdc++/61761 fix std::proj for targets without C99 cproj
The current generic implementation of __complex_proj used when cproj is
not available calculates the wrong projection, giving a different result
than given by C99's cproj.
When C99 cproj is not available but isinf and copysign are, use those to
give correct results for float, double and long double. Otherwise, and
for other specializations of std::complex, just use a generic version
that returns its argument, and so doesn't support infinities.
We might want to consider adding additional overloads of __complex_proj
to support extended types such as _Float64x, _Float128 etc.
PR libstdc++/61761
* include/std/complex (__complex_proj): Return parameter unchanged.
[_GLIBCXX_USE_C99_COMPLEX] (__complex_proj): Change overloads for
floating-point types to take std::complex arguments.
[_GLIBCXX_USE_C99_MATH_TR1] (__complex_proj): Add overloads for
floating-point types.
* testsuite/26_numerics/complex/proj.cc: New test.
Tested powerpc64le-linux, powerpc-aix7.2.0.0, x86_64-freebsd11.2,
committed to trunk.
commit 8f1124b7355c14fbb00435284d6c33c6575d9e09
Author: Jonathan Wakely
Date: Tue Apr 30 21:56:33 2019 +0100
PR libstdc++/61761 fix std::proj for targets without C99 cproj
The current generic implementation of __complex_proj used when cproj is
not available calculates the wrong projection, giving a different result
than given by C99's cproj.
When C99 cproj is not available but isinf and copysign are, use those to
give correct results for float, double and long double. Otherwise, and
for other specializations of std::complex, just use a generic version
that returns its argument, and so doesn't support infinities.
We might want to consider adding additional overloads of __complex_proj
to support extended types such as _Float64x, _Float128 etc.
PR libstdc++/61761
* include/std/complex (__complex_proj): Return parameter unchanged.
[_GLIBCXX_USE_C99_COMPLEX] (__complex_proj): Change overloads for
floating-point types to take std::complex arguments.
[_GLIBCXX_USE_C99_MATH_TR1] (__complex_proj): Add overloads for
floating-point types.
* testsuite/26_numerics/complex/proj.cc: New test.
diff --git a/libstdc++-v3/include/std/complex b/libstdc++-v3/include/std/complex
index 0a4f68bc438..45450e8ca01 100644
--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -1898,41 +1898,59 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
std::complex<_Tp> proj(const std::complex<_Tp>&);
- template
-std::complex<_Tp>
-__complex_proj(const std::complex<_Tp>& __z)
-{
- const _Tp __den = (__z.real() * __z.real()
-+ __z.imag() * __z.imag() + _Tp(1.0));
-
- return std::complex<_Tp>((_Tp(2.0) * __z.real()) / __den,
- (_Tp(2.0) * __z.imag()) / __den);
-}
-
-#if _GLIBCXX_USE_C99_COMPLEX
- inline __complex__ float
- __complex_proj(__complex__ float __z)
- { return __builtin_cprojf(__z); }
-
- inline __complex__ double
- __complex_proj(__complex__ double __z)
- { return __builtin_cproj(__z); }
-
- inline __complex__ long double
- __complex_proj(const __complex__ long double& __z)
- { return __builtin_cprojl(__z); }
-
+ // Generic implementation of std::proj, does not work for infinities.
template
inline std::complex<_Tp>
-proj(const std::complex<_Tp>& __z)
-{ return __complex_proj(__z.__rep()); }
-#else
+__complex_proj(const std::complex<_Tp>& __z)
+{ return __z; }
+
+#if _GLIBCXX_USE_C99_COMPLEX
+ inline complex
+ __complex_proj(const complex& __z)
+ { return __builtin_cprojf(__z.__rep()); }
+
+ inline complex
+ __complex_proj(const complex& __z)
+ { return __builtin_cproj(__z.__rep()); }
+
+ inline complex
+ __complex_proj(const complex& __z)
+ { return __builtin_cprojl(__z.__rep()); }
+#elif defined _GLIBCXX_USE_C99_MATH_TR1
+ inline complex
+ __complex_proj(const complex& __z)
+ {
+if (__builtin_isinf(__z.real()) || __builtin_isinf(__z.imag()))
+ return complex(__builtin_inff(),
+ __builtin_copysignf(0.0f, __z.imag()));
+return __z;
+ }
+
+ inline complex
+ __complex_proj(const complex& __z)
+ {
+if (__builtin_isinf(__z.real()) || __builtin_isinf(__z.imag()))
+ return complex(__builtin_inf(),
+__builtin_copysign(0.0, __z.imag()));
+return __z;
+ }
+
+ inline complex
+ __complex_proj(const complex& __z)
+ {
+if (__builtin_isinf(__z.real()) || __builtin_isinf(__z.imag()))
+ return complex(__builtin_infl(),
+ __builtin_copysignl(0.0l, __z.imag()));
+return __z;
+ }
+#endif
+
template
inline std::complex<_Tp>
proj(const std::complex<_Tp>& __z)
{ return __complex_proj(__z); }
-#endif
+ // Overload for scalars
template
inline
[PATCH] RISC-V: Short-forward-branch opt for SiFive 7 series cores.
The SiFive 7 series cores have macro fusion support to convert a branch over
a single instruction into a conditionally executed instruction. This adds
a conditional move pattern, enabled only for the SiFive 7 series cores, that
implements the initial optimization support for this feature. This gives us
about a 10% increase in coremark scores for this core.
To reduce duplication of patterns, this simplifies the existing two pattern
support for branches to one pattern. This requires an assembler optimization
to convert 3 operand branches comparing against zero into a compressed
instruction. This gas patch missed the deadline for binutils-2.32, so this
gcc patch had to wait until after the gcc-9 branch was made.
This was tested with 32-bit/elf and 64-bit/linux cross builds and checks,
configured for the default rocket target, and for the sifive-7-series target.
There were no regressions.
Adding a conditional move pattern enables the cselim tree pass unconditionally,
so this does accidentally affect other targets, but I'm seeing smaller code
sizes with the patch except in uncommon cases, so this does not appear to be
a problem. For the sifive-7-series target, code size does increase slightly,
but the performance benefit outweighs the code size increase.
Committed.
Jim
gcc/
* config/riscv/constraints.md (L): New.
* config/riscv/predicates.md (lui_operand): New.
(sfb_alu_operand): New.
* config/riscv/riscv-protos.h (riscv_expand_conditional_move): Declare.
* config/riscv/riscv.c (riscv_expand_conditional_move): New.
* config/riscv/riscv.h (TARGET_SFB_ALU): New.
* config/riscv/risc.md (type): Add sfb_alu.
(branch): Renamed from branch_order. Change predicate for
operand 3 to reg_or_0_operand. In output string, change %3 to %z3.
(branch_zero): Delete.
(movcc): New.
(movcc): Likewise.
* config/riscv/sifive-7.md (sifive_7_sfb_alu): New. Use in bypasses.
---
gcc/config/riscv/constraints.md | 5
gcc/config/riscv/predicates.md | 8 +
gcc/config/riscv/riscv-protos.h | 1 +
gcc/config/riscv/riscv.c| 12
gcc/config/riscv/riscv.h| 11 +++
gcc/config/riscv/riscv.md | 53 +++--
gcc/config/riscv/sifive-7.md| 12 ++--
7 files changed, 84 insertions(+), 18 deletions(-)
diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index b4de83f8324..40faf0e0380 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -49,6 +49,11 @@
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 0, 31)")))
+(define_constraint "L"
+ "A U-type 20-bit signed immediate."
+ (and (match_code "const_int")
+ (match_test "LUI_OPERAND (ival)")))
+
;; Floating-point constant +0.0, used for FCVT-based moves when FMV is
;; not available in RV32.
(define_constraint "G"
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 83fc4bd663d..aa5e1327dd5 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -27,6 +27,14 @@
(ior (match_operand 0 "const_arith_operand")
(match_operand 0 "register_operand")))
+(define_predicate "lui_operand"
+ (and (match_code "const_int")
+ (match_test "LUI_OPERAND (INTVAL (op))")))
+
+(define_predicate "sfb_alu_operand"
+ (ior (match_operand 0 "arith_operand")
+ (match_operand 0 "lui_operand")))
+
(define_predicate "const_csr_operand"
(and (match_code "const_int")
(match_test "IN_RANGE (INTVAL (op), 0, 31)")))
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 5c1002bbc29..69e39f7a208 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -59,6 +59,7 @@ extern const char *riscv_output_return ();
extern void riscv_expand_int_scc (rtx, enum rtx_code, rtx, rtx);
extern void riscv_expand_float_scc (rtx, enum rtx_code, rtx, rtx);
extern void riscv_expand_conditional_branch (rtx, enum rtx_code, rtx, rtx);
+extern void riscv_expand_conditional_move (rtx, rtx, rtx, rtx_code, rtx, rtx);
#endif
extern rtx riscv_legitimize_call_address (rtx);
extern void riscv_set_return_address (rtx, rtx);
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 6fb6c6ad372..3f66b9d8487 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -2324,6 +2324,18 @@ riscv_expand_conditional_branch (rtx label, rtx_code
code, rtx op0, rtx op1)
emit_jump_insn (gen_condjump (condition, label));
}
+/* If (CODE OP0 OP1) holds, move CONS to DEST; else move ALT to DEST. */
+
+void
+riscv_expand_conditional_move (rtx dest, rtx cons, rtx alt, rtx_code code,
+ rtx op0, rtx op1)
+{
+ riscv_emit_int_compare (, , );
+ rtx cond = gen_rtx_fmt_ee (code, GET_MODE (op0), op0, op1);
+ emit_insn (gen_rtx_SET (dest, gen_rtx_IF_THEN_ELSE (GET_MODE (dest), cond,
+
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 12:06 PM Jakub Jelinek wrote: > I think you can e.g. have a look at what alpha does in > alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit > compare and swap either. Thanks. I had noticed that the rs6000 port had what I needed, but looking the alpha one too is a good idea, as that one might be closer in design to the RISC-V architecture since both are similar to MIPS. Jim
Backports from trunk to 8 branch
Hi!
I've backported following 46 patches from trunk to gcc-8-branch,
bootstrapped/regtested on x86_64-linux and i686-linux and committed.
Jakub
2019-04-30 Jakub Jelinek
Backported from mainline
2019-02-20 Jakub Jelinek
PR middle-end/88074
PR middle-end/89415
* toplev.c (do_compile): Double the emin/emax exponents to workaround
buggy mpc_norm.
* gcc.dg/pr88074-2.c: New test.
2019-02-19 Richard Biener
PR middle-end/88074
* toplev.c (do_compile): Initialize mpfr's exponent range
based on available float modes.
* gcc.dg/pr88074.c: New testcase.
--- gcc/toplev.c(revision 269014)
+++ gcc/toplev.c(revision 269055)
@@ -2153,6 +2153,34 @@
else
int_n_enabled_p[i] = false;
+ /* Initialize mpfrs exponent range. This is important to get
+ underflow/overflow in a reasonable timeframe. */
+ machine_mode mode;
+ int min_exp = -1;
+ int max_exp = 1;
+ FOR_EACH_MODE_IN_CLASS (mode, MODE_FLOAT)
+ if (SCALAR_FLOAT_MODE_P (mode))
+ {
+ const real_format *fmt = REAL_MODE_FORMAT (mode);
+ if (fmt)
+ {
+ /* fmt->emin - fmt->p + 1 should be enough but the
+ back-and-forth dance in real_to_decimal_for_mode we
+ do for checking fails due to rounding effects then. */
+ if ((fmt->emin - fmt->p) < min_exp)
+ min_exp = fmt->emin - fmt->p;
+ if (fmt->emax > max_exp)
+ max_exp = fmt->emax;
+ }
+ }
+ /* E.g. mpc_norm assumes it can square a number without bothering with
+with range scaling, so until that is fixed, double the minimum
+and maximum exponents, plus add some buffer for arithmetics
+on the squared numbers. */
+ if (mpfr_set_emin (2 * (min_exp - 1))
+ || mpfr_set_emax (2 * (max_exp + 1)))
+ sorry ("mpfr not configured to handle all float modes");
+
/* Set up the back-end if requested. */
if (!no_backend)
backend_init ();
--- gcc/testsuite/gcc.dg/pr88074.c (nonexistent)
+++ gcc/testsuite/gcc.dg/pr88074.c (revision 269015)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+#include
+
+int main()
+{
+ _Complex double x;
+ __real x = 3.091e+8;
+ __imag x = -4.045e+8;
+ /* This used to spend huge amounts of compile-time inside mpc. */
+ volatile _Complex double y = ctan (x);
+ return 0;
+}
--- gcc/testsuite/gcc.dg/pr88074-2.c(nonexistent)
+++ gcc/testsuite/gcc.dg/pr88074-2.c(revision 269055)
@@ -0,0 +1,17 @@
+/* PR middle-end/88074 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-add-options float128 } */
+/* { dg-require-effective-target float128 } */
+/* { dg-final { scan-tree-dump-not "link_error " "optimized" } } */
+
+extern void link_error (void);
+int
+main ()
+{
+ if (((__FLT128_MAX__ * 0.5 + __FLT128_MAX__ * 0.5i)
+ / (__FLT128_MAX__ * 0.25 + __FLT128_MAX__ * 0.25i))
+ != (_Complex _Float128) 2)
+link_error ();
+ return 0;
+}
2019-04-30 Jakub Jelinek
Backported from mainline
2019-02-20 Jakub Jelinek
David Malcolm
PR middle-end/89091
* fold-const.c (decode_field_reference): Return NULL_TREE if
lang_hooks.types.type_for_size returns NULL. Check it before
overwriting *exp_. Use return NULL_TREE instead of return 0.
* gcc.dg/torture/pr89091.c: New test.
--- gcc/fold-const.c(revision 269055)
+++ gcc/fold-const.c(revision 269056)
@@ -4280,7 +4280,7 @@ decode_field_reference (location_t loc,
There are problems with FP fields since the type_for_size call
below can fail for, e.g., XFmode. */
if (! INTEGRAL_TYPE_P (TREE_TYPE (exp)))
-return 0;
+return NULL_TREE;
/* We are interested in the bare arrangement of bits, so strip everything
that doesn't affect the machine mode. However, record the type of the
@@ -4296,7 +4296,7 @@ decode_field_reference (location_t loc,
exp = TREE_OPERAND (exp, 0);
STRIP_NOPS (exp); STRIP_NOPS (and_mask);
if (TREE_CODE (and_mask) != INTEGER_CST)
- return 0;
+ return NULL_TREE;
}
poly_int64 poly_bitsize, poly_bitpos;
@@ -4312,7 +4312,11 @@ decode_field_reference (location_t loc,
|| (! AGGREGATE_TYPE_P (TREE_TYPE (inner))
&& compare_tree_int (TYPE_SIZE (TREE_TYPE (inner)),
*pbitpos + *pbitsize) < 0))
-return 0;
+return NULL_TREE;
+
+ unsigned_type = lang_hooks.types.type_for_size (*pbitsize, 1);
+ if (unsigned_type == NULL_TREE)
+return NULL_TREE;
*exp_ = exp;
@@ -4323,7 +4327,6 @@ decode_field_reference (location_t loc,
*punsignedp = TYPE_UNSIGNED (outer_type);
/* Compute the mask to access the bitfield. */
- unsigned_type
[GC PATCH] Correct TS marking of _EXPR nodes
I discovered we were not correctly marking the TS array for
language-specific _EXPR nodes. We got away with this because the GC
marking used other means for dealing with such nodes. I, however, was
relying on it for modules streaming.
applying to trunk.
nathan
--
Nathan Sidwell
2019-04-30 Nathan Sidwell
gcc/
* tree.h (MARK_TS_EXP): New.
gcc/c-family/
* c-common.c (c_common_init_ts): Use MARK_TS_EXP. Mark SIZEOF_EXPR.
gcc/cp/
* cp-objcp-common.c (cp_common_init_ts): Use MARK_TS_EXP for _EXPR
nodes. Call c_common_init_ts.
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 270708)
+++ gcc/c-family/c-common.c (working copy)
@@ -7907,8 +7907,9 @@ keyword_is_decl_specifier (enum rid keyw
void
c_common_init_ts (void)
{
- MARK_TS_TYPED (C_MAYBE_CONST_EXPR);
- MARK_TS_TYPED (EXCESS_PRECISION_EXPR);
+ MARK_TS_EXP (SIZEOF_EXPR);
+ MARK_TS_EXP (C_MAYBE_CONST_EXPR);
+ MARK_TS_EXP (EXCESS_PRECISION_EXPR);
}
/* Build a user-defined numeric literal out of an integer constant type VALUE
Index: gcc/cp/cp-objcp-common.c
===
--- gcc/cp/cp-objcp-common.c (revision 270708)
+++ gcc/cp/cp-objcp-common.c (working copy)
@@ -386,67 +386,88 @@ cp_common_init_ts (void)
MARK_TS_COMMON (BOUND_TEMPLATE_TEMPLATE_PARM);
MARK_TS_COMMON (UNBOUND_CLASS_TEMPLATE);
- MARK_TS_TYPED (EXPR_PACK_EXPANSION);
MARK_TS_TYPED (SWITCH_STMT);
MARK_TS_TYPED (IF_STMT);
MARK_TS_TYPED (FOR_STMT);
MARK_TS_TYPED (RANGE_FOR_STMT);
- MARK_TS_TYPED (AGGR_INIT_EXPR);
- MARK_TS_TYPED (EXPR_STMT);
MARK_TS_TYPED (EH_SPEC_BLOCK);
MARK_TS_TYPED (CLEANUP_STMT);
MARK_TS_TYPED (SCOPE_REF);
- MARK_TS_TYPED (CAST_EXPR);
- MARK_TS_TYPED (NON_DEPENDENT_EXPR);
- MARK_TS_TYPED (MODOP_EXPR);
MARK_TS_TYPED (TRY_BLOCK);
- MARK_TS_TYPED (THROW_EXPR);
MARK_TS_TYPED (HANDLER);
- MARK_TS_TYPED (REINTERPRET_CAST_EXPR);
- MARK_TS_TYPED (CONST_CAST_EXPR);
- MARK_TS_TYPED (STATIC_CAST_EXPR);
- MARK_TS_TYPED (DYNAMIC_CAST_EXPR);
- MARK_TS_TYPED (IMPLICIT_CONV_EXPR);
- MARK_TS_TYPED (TEMPLATE_ID_EXPR);
- MARK_TS_TYPED (ARROW_EXPR);
- MARK_TS_TYPED (SIZEOF_EXPR);
- MARK_TS_TYPED (ALIGNOF_EXPR);
- MARK_TS_TYPED (AT_ENCODE_EXPR);
- MARK_TS_TYPED (UNARY_PLUS_EXPR);
- MARK_TS_TYPED (TRAIT_EXPR);
MARK_TS_TYPED (TYPE_ARGUMENT_PACK);
MARK_TS_TYPED (NOEXCEPT_EXPR);
- MARK_TS_TYPED (NONTYPE_ARGUMENT_PACK);
MARK_TS_TYPED (WHILE_STMT);
- MARK_TS_TYPED (NEW_EXPR);
- MARK_TS_TYPED (VEC_NEW_EXPR);
MARK_TS_TYPED (BREAK_STMT);
- MARK_TS_TYPED (MEMBER_REF);
- MARK_TS_TYPED (DOTSTAR_EXPR);
MARK_TS_TYPED (DO_STMT);
- MARK_TS_TYPED (DELETE_EXPR);
- MARK_TS_TYPED (VEC_DELETE_EXPR);
MARK_TS_TYPED (CONTINUE_STMT);
- MARK_TS_TYPED (TAG_DEFN);
- MARK_TS_TYPED (PSEUDO_DTOR_EXPR);
- MARK_TS_TYPED (TYPEID_EXPR);
- MARK_TS_TYPED (MUST_NOT_THROW_EXPR);
- MARK_TS_TYPED (STMT_EXPR);
- MARK_TS_TYPED (OFFSET_REF);
- MARK_TS_TYPED (OFFSETOF_EXPR);
- MARK_TS_TYPED (ADDRESSOF_EXPR);
MARK_TS_TYPED (PTRMEM_CST);
- MARK_TS_TYPED (EMPTY_CLASS_EXPR);
- MARK_TS_TYPED (VEC_INIT_EXPR);
MARK_TS_TYPED (USING_STMT);
- MARK_TS_TYPED (LAMBDA_EXPR);
- MARK_TS_TYPED (CTOR_INITIALIZER);
- MARK_TS_TYPED (REQUIRES_EXPR);
- MARK_TS_TYPED (UNARY_LEFT_FOLD_EXPR);
- MARK_TS_TYPED (UNARY_RIGHT_FOLD_EXPR);
- MARK_TS_TYPED (BINARY_LEFT_FOLD_EXPR);
- MARK_TS_TYPED (BINARY_RIGHT_FOLD_EXPR);
MARK_TS_TYPED (OMP_DEPOBJ);
+
+ MARK_TS_EXP (AGGR_INIT_EXPR);
+ MARK_TS_EXP (CTOR_INITIALIZER);
+ MARK_TS_EXP (EXPR_STMT);
+ MARK_TS_EXP (TAG_DEFN);
+ MARK_TS_EXP (EMPTY_CLASS_EXPR);
+ MARK_TS_EXP (MODOP_EXPR);
+ MARK_TS_EXP (THROW_EXPR);
+ MARK_TS_EXP (CAST_EXPR);
+ MARK_TS_EXP (TYPE_EXPR);
+ MARK_TS_EXP (REINTERPRET_CAST_EXPR);
+ MARK_TS_EXP (CONST_CAST_EXPR);
+ MARK_TS_EXP (STATIC_CAST_EXPR);
+ MARK_TS_EXP (DYNAMIC_CAST_EXPR);
+ MARK_TS_EXP (IMPLICIT_CONV_EXPR);
+ MARK_TS_EXP (TEMPLATE_ID_EXPR);
+ MARK_TS_EXP (ARROW_EXPR);
+ MARK_TS_EXP (UNARY_PLUS_EXPR);
+ MARK_TS_EXP (TRAIT_EXPR);
+
+ MARK_TS_EXP (NON_DEPENDENT_EXPR);
+ MARK_TS_EXP (NEW_EXPR);
+ MARK_TS_EXP (VEC_NEW_EXPR);
+ MARK_TS_EXP (MEMBER_REF);
+ MARK_TS_EXP (DOTSTAR_EXPR);
+ MARK_TS_EXP (DELETE_EXPR);
+ MARK_TS_EXP (VEC_DELETE_EXPR);
+ MARK_TS_EXP (PSEUDO_DTOR_EXPR);
+ MARK_TS_EXP (TYPEID_EXPR);
+ MARK_TS_EXP (MUST_NOT_THROW_EXPR);
+ MARK_TS_EXP (STMT_EXPR);
+ MARK_TS_EXP (OFFSET_REF);
+ MARK_TS_EXP (OFFSETOF_EXPR);
+ MARK_TS_EXP (ADDRESSOF_EXPR);
+ MARK_TS_EXP (VEC_INIT_EXPR);
+ MARK_TS_EXP (LAMBDA_EXPR);
+
+ MARK_TS_EXP (ALIGNOF_EXPR);
+ MARK_TS_EXP (AT_ENCODE_EXPR);
+
+ MARK_TS_EXP (NONTYPE_ARGUMENT_PACK);
+ MARK_TS_EXP (EXPR_PACK_EXPANSION);
+ MARK_TS_EXP (UNARY_LEFT_FOLD_EXPR);
+ MARK_TS_EXP (UNARY_RIGHT_FOLD_EXPR);
+ MARK_TS_EXP (BINARY_LEFT_FOLD_EXPR);
+ MARK_TS_EXP (BINARY_RIGHT_FOLD_EXPR);
+
+ MARK_TS_EXP (REQUIRES_EXPR);
+ MARK_TS_EXP (SIMPLE_REQ);
+ MARK_TS_EXP
Re: [PATCH 3/3] Dump -fdbg-cnt limit reach also to stderr stream.
On 3/27/19 2:39 AM, marxin wrote: > > gcc/ChangeLog: > > 2019-03-27 Martin Liska > > * dbgcnt.c (print_limit_reach): New function. > (dbg_cnt): Use it. > --- > gcc/dbgcnt.c | 26 -- > 1 file changed, 16 insertions(+), 10 deletions(-) > Given this is dbgcnt stuff I don't think we have to deal with translation issues. OK for the trunk. jeff
Re: [PATCH 2/3] Extend format of -fdbg-cnt: add aux_base filter.
On 3/27/19 2:38 AM, marxin wrote: > gcc/ChangeLog: > > 2019-03-27 Martin Liska > > * dbgcnt.c (dbg_cnt_set_limit_by_name): Add new argument > aux_base and filter based on aux_base_name. > (dbg_cnt_process_single_pair): Parse aux_base. > * doc/invoke.texi: Document new extended format. > > gcc/testsuite/ChangeLog: > > 2019-03-27 Martin Liska > > * gcc.dg/dbg-cnt-1.c: New test. OK. jeff
Re: [PATCH 1/3] Fix multiple values for -fdbg-cnt.
On 3/27/19 1:43 AM, marxin wrote: > > gcc/ChangeLog: > > 2019-03-27 Martin Liska > > * dbgcnt.c (dbg_cnt_process_single_pair): Fix GNU coding style. > (dbg_cnt_process_opt): Parse first tokens aas > dbg_cnt_process_single_pair is also using strtok. > --- > gcc/dbgcnt.c | 25 +++-- > 1 file changed, 15 insertions(+), 10 deletions(-) > OK, though please fix the ChangeLog typo :-) jeff
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 21:06 +0200, Jakub Jelinek wrote: On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote: On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > cas using 32 bit one). This is a known problem on our to do list, and there is already a bugzilla or two about this. There are unfortunately a lot of items on our to do list as RISC-V is still a relatively new target. This is also complicated by the fact that we didn't have a formal memory model defined until last year, and now that we do have one, the gcc support needs to be updated to follow the formal memory model. There are a number of cleanup issues to fix here, such as the fact that we are emitting fences in places where the formal memory model says we don't need them. Anyways, we do want to fix this, but it is not clear when we will have time to do it. I think you can e.g. have a look at what alpha does in alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit compare and swap either. Anyway, once you make a change, there will need to be work on the libstdc++ side for riscv too to preserve ABI (i.e. keep exporting the _Lock_priority 1 variants and add _Lock_priority 2 to a new symbol version). Or to make the directory iterators keep using the same type as used today, __shared_ptr, even if the _S_atomic policy would work instead.
New German PO file for 'gcc' (version 9.1-b20190414)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/gcc/de.po (This file, 'gcc-9.1-b20190414.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote: > On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > > cas using 32 bit one). > > This is a known problem on our to do list, and there is already a > bugzilla or two about this. There are unfortunately a lot of items on > our to do list as RISC-V is still a relatively new target. This is > also complicated by the fact that we didn't have a formal memory model > defined until last year, and now that we do have one, the gcc support > needs to be updated to follow the formal memory model. There are a > number of cleanup issues to fix here, such as the fact that we are > emitting fences in places where the formal memory model says we don't > need them. Anyways, we do want to fix this, but it is not clear when > we will have time to do it. I think you can e.g. have a look at what alpha does in alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit compare and swap either. Anyway, once you make a change, there will need to be work on the libstdc++ side for riscv too to preserve ABI (i.e. keep exporting the _Lock_priority 1 variants and add _Lock_priority 2 to a new symbol version). Jakub
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > cas using 32 bit one). This is a known problem on our to do list, and there is already a bugzilla or two about this. There are unfortunately a lot of items on our to do list as RISC-V is still a relatively new target. This is also complicated by the fact that we didn't have a formal memory model defined until last year, and now that we do have one, the gcc support needs to be updated to follow the formal memory model. There are a number of cleanup issues to fix here, such as the fact that we are emitting fences in places where the formal memory model says we don't need them. Anyways, we do want to fix this, but it is not clear when we will have time to do it. Jim
Re: [PATCH][DOC] Define email limit for gcc-patches mailing list.
On Mon, Apr 29, 2019 at 06:29:50PM +, Iain Sandoe wrote: > > > On 26 Apr 2019, at 15:08, Gerald Pfeifer wrote: > > > > On Fri, 26 Apr 2019, Martin Liška wrote: > >> The patch clarifies that gcc-patches mailing list allows up to 400kB > >> size of an email. > > > As one minor detail, note we have KB in one place and with the > > patch would have kB. Technically it's probably KiB, but that > > may confuse people more than it helps, so KB which is generally > > more commonly used in our documentation? > > Do we really use ‘K’ rather than ‘k’ ? (as I understand things the latter is > correct even if use of K is widespread). I agree that kB is correct and KB is not. (And KiB... Let's just not talk about people who prefer that; Pluto is a planet, too!) Segher
Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"
On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote: > Here's the follow-up, getting rid of the observed > alignment-padding in execute/930126-1.c: the x parameter in f > spuriously being runtime-aligned to BITS_PER_WORD. I separated > this change because this is an older issue, a change introduced > in r94104 where BITS_PER_WORD was chosen perhaps because we > expect register-sized writes into this area. Here, we instead > align to a minimum of PREFERRED_STACK_BOUNDARY, but of course > gated on ! STRICT_ALIGNMENT. > > Regtested cris-elf and x86_64-pc-linux-gnu. > > Ok to commit? > > gcc: > * function.c (assign_parm_setup_block): If not STRICT_ALIGNMENT, > instead of always BITS_PER_WORD, align the stacked > parameter to a minimum PREFERRED_STACK_BOUNDARY. Interestingly enough in the thread from 2005 Richard S suggests that he could have made increasing the alignment conditional on STRICT_ALIGNMENT but thought that with the size already being rounded up it wasn't worth it and that we could take advantage of the increased alignment elsewhere. I wonder if we could just go back to that idea. Leave the alignment as DECL_ALIGN for !STRICT_ALIGNMENT targets and bump it up for STRICT_ALIGNMENT targets? So something like align = STRICT_ALIGNMENT ? MAX (DECL_ALIGN (parm), BITS_PER_WORD) : DECL_ALIGN (parm) Jeff
[wwwdocs] Add some info on LTO/IPA changes for GCC 9
Hi, this patch adds some notes on LTO/IPA changes and some statistics on bulid-time/memory use improvements I collected this weekend. I also added some of FDO changes I rememebr. Martin, perhaps you can do more. Honza Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.59 diff -u -r1.59 changes.html --- changes.html9 Apr 2019 21:08:28 - 1.59 +++ changes.html30 Apr 2019 17:19:05 - @@ -195,6 +195,11 @@ metadata such as the inlining chain, and profile information (if available). + Inter-procedural propagation of stack alignment can now be controlled by + https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fipa-stack-alignment;>-fipa-stack-alignment. + Propagation of addressability, readonly and writeonly flags on + static variables can now be controlled by + https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fipa-reference-addressable;>-fipa-reference-addressable. The following built-in functions have been introduced. @@ -246,6 +251,52 @@ can be transformed into 100 * how + 5 (for values defined in the switch statement). +Inter-prodcedural optimization improvements: + + Inliner defaults was tuned to better suits modern C++ codebases + especially when built with link time optimizations. + New parameters max-inline-insns-small, + max-inline-insns-size, + uninlined-function-insns, + uninlined-function-time, uninlined-thunk-insns, + and uninlined-thunk-time was added. + Hot/cold partitioning is now more precise and agressive. + Improved scalability for very large translation units (especially + when link-time optimizing large programs). + +Profile driven optimization improvements: + +-fprofile-use now enables + -fversion-loops-for-strides, + -floop-interchange, + -funroll-and-jam, + -ftree-loop-distribution. +Streaming of counter histograms was removed. This reduces + the size of profile files. Histogram is computed on the fly + with link-time optimization. +Parameter hot-bb-count-ws-permille was reduced +from 999 to 990 to account for more precise histograms. + +Link-time optimization improvements: + +Types are now simplified prior streaming resulting in significant + reductions of the LTO object files, link-time memory use, and + improvements of link-time parallelism. +Default number of partitions (--param lto-partitions) was + increased from 32 to 128 enabling effective use of CPUs with more than + 32 hyperthreads. --param lto-max-streaming-parallelism + can now be used to control number of streaming processes. +Warnings on C++ One Decl Rule violations (-Wodr) are + now more informative and produce fewer redundant results. + + Overal compile time of Firefox and LibreOffice was reduced by about 5% + compared to GCC 8.3. Size of LTO object files is reduced by 7%. + LTO link-time improves by 11% on 8-core machine and scales significantly better + for more parallel build environments. Serial stage of the link-time + optimization is 28% faster consuming 20% less memory. + Parallel stage now partitions to 128 partitions rather than 32 and + reduces memory use for every worker by 30%. + The following improvements to the gcov command-line utility have been made.
Re: [PATCH, rs6000] PR89765: Multiple problems with vec-insert implementation on PowerPC
On Tue, Apr 30, 2019 at 11:04:10AM -0500, Kelvin Nilsen wrote: > > In combination with a related recently committed patch > (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached > patch resolves the issues described in this problem report. This patch also > includes tests to exercise the previously committed patch. > > This patch includes redundant content from patch PR89424 > (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00994.html), which has been > already been approved by Segher for trunk and backports to GCC 7 and 8 but is > awaiting GCC 9 release. > > The patch has been bootstrapped and tested without regressions on > powerpc64le-unknown-linux-gnu (both P8 and P9) and on > powerpc64-unknown-linux-gnu (P7 and P8, both -m32 and -m64). > > Segher: After GCC9 release, is this ok for trunk and backports to GCC 7 and > GCC8? > > Jakub or Richi: Is this patch and the redundant PR89424 patch ok for > backports to GCC9? I'm not against backporting it for GCC 9.2, but would strongly prefer not to backport before GCC 9.1 is released. At least from what I've seen, you get many wrong-code issues with the V1TImode on powerpc since many years ago, so I don't see why it couldn't wait another week. The only changes to GCC 9.1 now should be severe blockers. > 2019-04-30 Kelvin Nilsen > > PR target/89765 > * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): > In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic > to compute vector element selector for both constant and variable > operands. > * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add case > to handle V1TImode vectors. Jakub
Re: [PATCH] Provide suggestions for unrecognized -dump options (PR driver/88911)
On 1/22/19 10:55 AM, David Malcolm wrote: > PR driver/88911 reports an issue where the user couldn't remember the spelling > of the "-dumpspecs" option, and attempted various similar spellings, but many > of them failed to contain a suggestion of the correct spelling: > > $ gcc q.c -dump-spec > cc1: warning: unrecognized gcc debugging option: u > cc1: warning: unrecognized gcc debugging option: m > cc1: warning: unrecognized gcc debugging option: - > cc1: warning: unrecognized gcc debugging option: s > cc1: warning: unrecognized gcc debugging option: e > cc1: warning: unrecognized gcc debugging option: c > $ gcc q.c -dump-specs > cc1: warning: unrecognized gcc debugging option: u > cc1: warning: unrecognized gcc debugging option: m > cc1: warning: unrecognized gcc debugging option: - > cc1: warning: unrecognized gcc debugging option: s > cc1: warning: unrecognized gcc debugging option: e > cc1: warning: unrecognized gcc debugging option: c > cc1: warning: unrecognized gcc debugging option: s > $ gcc q.c -fdump-spec > cc1: error: unrecognized command line option '-fdump-spec' > $ gcc q.c -fdump-specs > cc1: error: unrecognized command line option '-fdump-specs' > $ gcc q.c -fdumpspecs > gcc: error: unrecognized command line option '-fdumpspecs'; did you > mean '-dumpspecs'? > [Aha!] > > There are two issues here: > > (a) unmatched options beginning with "-d" are treated as part of the > "-d" option, leading to a warning from decode_d_option, but no > suggestion. > > (b) options beginning with "-fdump-" are also passed to a special > handler, and this doesn't offer suggestions for unmatched options > either. > > This patch uses option_proposer::suggest_option to add suggestions > in both places, leading to useful suggestions for all of the cases > given above. For the case of "-d" it only offers a suggestion for > the first unrecognized character. I also added quotes around the > character in the message, and indicate the full option for context, > so that the first example above becomes: > > $ gcc q.c -dump-spec > cc1: warning: unrecognized gcc debugging option: 'u' (as part of > '-dump-spec'); did you mean '-dumpspecs'? > cc1: warning: unrecognized gcc debugging option: 'm' (as part of > '-dump-spec') > cc1: warning: unrecognized gcc debugging option: '-' (as part of > '-dump-spec') > cc1: warning: unrecognized gcc debugging option: 's' (as part of > '-dump-spec') > cc1: warning: unrecognized gcc debugging option: 'e' (as part of > '-dump-spec') > cc1: warning: unrecognized gcc debugging option: 'c' (as part of > '-dump-spec') > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > Is this patch OK for trunk? > (it's not a regression, but it's fairly self-contained, so would this be > acceptable now, or should I queue it for when stage 1 reopens?) > > gcc/ChangeLog: > PR driver/88911 > * opts-global.c: Include "opt-suggestions.h". > (handle_common_deferred_options) : If the argument is > unrecognized, attempt to provide a hint. > * opts.c: Include "opt-suggestions.h". > (common_handle_option) : Pass original option argument text > to decode_d_option. > (decode_d_option): Add parameter "orig_arg". Use it to provide a > hint within the first unrecognized character. Wrap the character > in quotes, and indicate the original argument it belongs to. > > gcc/testsuite/ChangeLog: > PR driver/88911 > * gcc.dg/spellcheck-options-pr88911-1.c: New test. > * gcc.dg/spellcheck-options-pr88911-2.c: New test. > * gcc.dg/spellcheck-options-pr88911-3.c: New test. > * gcc.dg/spellcheck-options-pr88911-4.c: New test. > * gcc.dg/spellcheck-options-pr88911-5.c: New test. A "pocket veto" for gcc-9 :-) However it makes a lot of sense to me for gcc-10. It looks reasonable to me. Can't hurt to spin it again before committing. jeff
Re: [RFC][PATCH] Postpone print of --help=* option.
On 4/1/19 6:11 AM, Martin Liška wrote:
> Hi.
>
> Last week I was curious which warnings are disabled by default on top
> of -Wall and -Wextra. Thus I used --help=warning and noticed some discrepancy
> in between documentation and output of the --help option.
>
> I created PR89885 where I explained that OPT__help_ option handling happens
> early. That's why LangEnabledBy are not reflected and similarly target
> overrides
> don't take place.
>
> I'm attaching diff for --help=warning for C++ and -Ofast.
>
> Thoughts?
>
> gcc/ChangeLog:
>
> 2019-04-01 Martin Liska
>
> * gcc.c (process_command): Add dummy file only
> if n_infiles == 0.
> * opts-global.c (decode_options): Pass lang_mask.
> * opts.c (print_help): New function.
> (finish_options): Print --help if help_option_argument
> is set.
> (common_handle_option): Factor out content of OPT__help_
> into print_help.
> * opts.h (finish_options): Add new argument.
> ---
> gcc/gcc.c | 3 +-
> gcc/opts-global.c | 2 +-
> gcc/opts.c| 267 --
> gcc/opts.h| 3 +-
> 4 files changed, 146 insertions(+), 129 deletions(-)
>
>
>
> 0001-Postpone-print-of-help-option.patch
>
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 4f57765b012..7ce1cae28a7 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -4751,7 +4751,8 @@ process_command (unsigned int decoded_options_count,
> }
>
>/* Ensure we only invoke each subprocess once. */
> - if (print_subprocess_help || print_help_list || print_version)
> + if (n_infiles == 0
> + && (print_subprocess_help || print_help_list || print_version))
> {
>n_infiles = 0;
The assignment to n_infiles is redundant after your change. I suspect
the optimizers will catch this, so if you want to keep it for clarity
that's fine with me.
OK for the trunk. Your call whether or not to remove the redundant
assignment.
jeff
Re: Replacement for diagnostics linter
On 4/25/19 11:29 AM, Roland Illig wrote: > There's a linter in contrib/check-internal-format-escaping.py that > checks whether the base file for translations (such as French or German) > conform to some basic style rules. This mostly affects the diagnostics > emitted by GCC. > > As the German translation I have added several checks to the linter and > added rationales to most of the checks. > > Since I completely rewrote the linter, it's more convenient to not look > at the patch but only the rewritten code. Therefore I've provided both > of them. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117. > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119. > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176. > > Thoughts? > Given that Martin L is on board (he wrote the original linter), my recommendation would be to go with your updated linter. I'll commit it shortly. jeff
[PATCH, rs6000] PR89765: Multiple problems with vec-insert implementation on PowerPC
In combination with a related recently committed patch
(https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached patch
resolves the issues described in this problem report. This patch also includes
tests to exercise the previously committed patch.
This patch includes redundant content from patch PR89424
(https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00994.html), which has been
already been approved by Segher for trunk and backports to GCC 7 and 8 but is
awaiting GCC 9 release.
The patch has been bootstrapped and tested without regressions on
powerpc64le-unknown-linux-gnu (both P8 and P9) and on
powerpc64-unknown-linux-gnu (P7 and P8, both -m32 and -m64).
Segher: After GCC9 release, is this ok for trunk and backports to GCC 7 and
GCC8?
Jakub or Richi: Is this patch and the redundant PR89424 patch ok for backports
to GCC9?
gcc/ChangeLog:
2019-04-30 Kelvin Nilsen
PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add case
to handle V1TImode vectors.
gcc/testsuite/ChangeLog:
2019-04-30 Kelvin Nilsen
PR target/89765
* gcc.target/powerpc/pr89765-mc.c: New test.
* gcc.target/powerpc/vsx-builtin-10c.c: New test.
* gcc.target/powerpc/vsx-builtin-10d.c: New test.
* gcc.target/powerpc/vsx-builtin-11c.c: New test.
* gcc.target/powerpc/vsx-builtin-11d.c: New test.
* gcc.target/powerpc/vsx-builtin-12c.c: New test.
* gcc.target/powerpc/vsx-builtin-12d.c: New test.
* gcc.target/powerpc/vsx-builtin-13c.c: New test.
* gcc.target/powerpc/vsx-builtin-13d.c: New test.
* gcc.target/powerpc/vsx-builtin-14c.c: New test.
* gcc.target/powerpc/vsx-builtin-14d.c: New test.
* gcc.target/powerpc/vsx-builtin-15c.c: New test.
* gcc.target/powerpc/vsx-builtin-15d.c: New test.
* gcc.target/powerpc/vsx-builtin-16c.c: New test.
* gcc.target/powerpc/vsx-builtin-16d.c: New test.
* gcc.target/powerpc/vsx-builtin-17c.c: New test.
* gcc.target/powerpc/vsx-builtin-17d.c: New test.
* gcc.target/powerpc/vsx-builtin-18c.c: New test.
* gcc.target/powerpc/vsx-builtin-18d.c: New test.
* gcc.target/powerpc/vsx-builtin-19c.c: New test.
* gcc.target/powerpc/vsx-builtin-19d.c: New test.
* gcc.target/powerpc/vsx-builtin-20c.c: New test.
* gcc.target/powerpc/vsx-builtin-20d.c: New test.
* gcc.target/powerpc/vsx-builtin-9c.c: New test.
* gcc.target/powerpc/vsx-builtin-9d.c: New test.
* gcc.target/powerpc/vsx-builtin-13a.c (PR89424): Define this
macro to increase coverage of test.
* gcc.target/powerpc/vsx-builtin-13b.c (PR89424): Likewise.
* gcc.target/powerpc/vsx-builtin-20a.c (PR89424): Likewise.
* gcc.target/powerpc/vsx-builtin-20b.c (PR89424): Likewise.
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 270584)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -6736,11 +6736,13 @@ altivec_resolve_overloaded_builtin (location_t loc
/* If we can use the VSX xxpermdi instruction, use that for insert. */
mode = TYPE_MODE (arg1_type);
if ((mode == V2DFmode || mode == V2DImode) && VECTOR_UNIT_VSX_P (mode)
- && TREE_CODE (arg2) == INTEGER_CST
- && wi::ltu_p (wi::to_wide (arg2), 2))
+ && TREE_CODE (arg2) == INTEGER_CST)
{
+ wide_int selector = wi::to_wide (arg2);
+ selector = wi::umod_trunc (selector, 2);
tree call = NULL_TREE;
+ arg2 = wide_int_to_tree (TREE_TYPE (arg2), selector);
if (mode == V2DFmode)
call = rs6000_builtin_decls[VSX_BUILTIN_VEC_SET_V2DF];
else if (mode == V2DImode)
@@ -6752,11 +6754,12 @@ altivec_resolve_overloaded_builtin (location_t loc
return build_call_expr (call, 3, arg1, arg0, arg2);
}
else if (mode == V1TImode && VECTOR_UNIT_VSX_P (mode)
- && TREE_CODE (arg2) == INTEGER_CST
- && wi::eq_p (wi::to_wide (arg2), 0))
+ && TREE_CODE (arg2) == INTEGER_CST)
{
tree call = rs6000_builtin_decls[VSX_BUILTIN_VEC_SET_V1TI];
+ wide_int selector = wi::zero(32);
+ arg2 = wide_int_to_tree (TREE_TYPE (arg2), selector);
/* Note, __builtin_vec_insert_ has vector and scalar types
reversed. */
return build_call_expr (call, 3, arg1, arg0, arg2);
@@ -6764,10 +6767,13 @@ altivec_resolve_overloaded_builtin (location_t loc
/* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2) = arg0. */
arg1_inner_type = TREE_TYPE
Re: [PATCH][stage1] Prefer to use strlen call instead of inline expansion (PR target/88809).
On 4/29/19 4:47 AM, Martin Liška wrote: > On 4/26/19 11:05 AM, Martin Liška wrote: >> Then I'm very open to adjust that even for -Os to 'call strlen'. > That said, I'm suggesting following updated patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Thanks, > Martin > > > 0001-Prefer-to-use-strlen-call-instead-of-inline-expansio.patch > > From 435de2e8b88b2d9898901f2343e03102da367982 Mon Sep 17 00:00:00 2001 > From: marxin > Date: Tue, 23 Apr 2019 10:05:21 +0200 > Subject: [PATCH] Prefer to use strlen call instead of inline expansion (PR > target/88809). > > gcc/ChangeLog: > > 2019-04-23 Martin Liska > > PR target/88809 > * config/i386/i386.c (ix86_expand_strlen): Use strlen call. > With -minline-all-stringops use inline expansion using 4B loop. > * doc/invoke.texi: Document the change of > -minline-all-stringops. > > gcc/testsuite/ChangeLog: > > 2019-04-23 Martin Liska > > PR target/88809 > * gcc.target/i386/pr88809.c: New test. > * gcc.target/i386/pr88809-2.c: New test. OK for the trunk. jeff
Re: [PATCH] improve ifcvt optimization (PR rtl-optimization/89430)
On 3/14/19 10:46 PM, JiangNing OS wrote: > This patch is to fix a missing ifcvt opportunity in back-end. For the simple > case below, > > if (...) > x = a; /* x is memory */ > /* no else */ > > We can generate conditional move and remove the branch as below if the target > cost is acceptable. > > r1 = x > r2 = a > cmp ... > csel r3, r1, r2, cond > x = r3 > > This could be safe if x is a stack variable, and there isn't any address > taken in current function, so the store speculation can be avoided. > > In practice, this optimization can improve a real application performance by > %4 on aarch64. [ ... ] I notice that a couple weeks you'd sent a similar patch under the heading "Fixing ifcvt issue as exposed by BZ89430". Does this patch supersede the earlier patch? Jeff
Re: [PATCH] RX: Add rx-*-linux target
On 4/30/19 7:55 AM, Yoshinori Sato wrote: > On Tue, 30 Apr 2019 06:48:01 +0900, > Jeff Law wrote: >> >> On 3/26/19 8:21 AM, Yoshinori Sato wrote: >>> I ported linux kernel to Renesas RX. >>> >>> rx-*-elf target output a binary different from the standard ELF. >>> It has the same format as the Renesas compiler. >>> >>> But the linux kernel requires the standard ELF format. >>> I want to define a rx-*-linux target so that I can generate >>> a standard ELF binary.I believe you have a copyright assignment on file for >>> your H8 work. Was >> the assignment specific to the H8 or was it more general? > > No. This changes other target. > These files are not included in my copyright assignment. > >> >>> diff --git a/gcc/config/rx/linux.h b/gcc/config/rx/linux.h >>> new file mode 100644 >>> index 000..69500a379f2 >>> --- /dev/null >>> +++ b/gcc/config/rx/linux.h >> >>> + >>> +/* This is how to output an element of a case-vector that is relative. >>> + Note: The local label referenced by the "3b" below is emitted by >>> + the tablejump insn. */ >>> + >>> +#undef ASM_OUTPUT_ADDR_DIFF_ELT >>> +#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \ >>> + fprintf (FILE, "\t.long .L%d - 1b\n", VALUE) >> Note the comment references "3b", but the output is "1b". > > Oh. > I will update it. > >> I don't see anything in here significantly concerning. We just need to >> verify your copyright assignment status. > > OK. > >> Also, do you have write access to the repo? > > I don't have write permission of svn repository. OK. So let me know when the assignment is updated and I'll commit the changes. If you forsee doing future work, you might consider a broader assignment so that we don't have to go through the assignment process for each contribution. Jeff
Re: [PATCH] Come up with bootstrap-lto-lean config.
On 4/5/19 4:42 AM, Martin Liška wrote: > Hi. > > The patch adds a new config that makes LTO+PGO bootstrap faster by > using LTO only in stage4. In stage3, generators are build with LTO > in order to collect a reasonable profile for LTO FE. > > Ready for trunk? > Thanks, > Martin > > ChangeLog: > > 2019-04-05 Martin Liska > > * Makefile.in: Regenerate. > * Makefile.tpl: Pass GENERATOR_CFLAGS > in all stages. > > config/ChangeLog: > > 2019-04-05 Martin Liska > > * bootstrap-lto-lean.mk: New file. > > gcc/ChangeLog: > > 2019-04-05 Martin Liska > > * Makefile.in: Use GENERATOR_CFLAGS for all generators. > * configure: Regenerate. > * configure.ac: Pass GENERATOR_CFLAGS. > * doc/install.texi: Document the new config. OK jeff
Re: [PATCH][stage1] Enhance target and target_clone error messages.
On 4/23/19 4:06 AM, Martin Liška wrote:
> On 4/19/19 2:28 AM, Martin Sebor wrote:
>> On 4/18/19 5:09 AM, Martin Liška wrote:
>>> Hi.
>>>
>>> The patch distinguishes among target and target_clone attribute when
>>> reporting for an error. I've also reworded the affected error messages
>>> a bit.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed after stage1 opens?
>>> Thanks,
>>> Martin
>>>
>>> ---
>>> gcc/cgraphclones.c | 2 +-
>>> gcc/config/i386/i386-c.c | 5 +-
>>> gcc/config/i386/i386-protos.h | 4 +-
>>> gcc/config/i386/i386.c | 54 +-
>>> gcc/testsuite/gcc.target/i386/funcspec-4.c | 2 +-
>>> 5 files changed, 39 insertions(+), 28 deletions(-)
>> Just a suggestion to also consider making the phrasing in the messages
>> consistent by adding "is" below
>>
>> @@ -5316,7 +5322,7 @@ ix86_valid_target_attribute_inner_p (tree args, char
>> *p_strings[],
>>
>> else if (TREE_CODE (args) != STRING_CST)
>> {
>> - error ("attribute % argument not a string");
>> + error_at (loc, "attribute %qs argument not a string", attr_name);
>> return false;
>>
>> i.e., "is not a string" and changing the below
>>
>> @@ -5382,7 +5386,8 @@ ix86_valid_target_attribute_inner_p (tree args, char
>> *p_strings[],
>> /* Process the option. */
>> if (opt == N_OPTS)
>> {
>> - error ("attribute(target(\"%s\")) is unknown", orig_p);
>> + error_at (loc, "attribute value %qs is unknown in %qs attribute",
>> + orig_p, attr_name);
>>
>> to
>>
>> error_at (loc, "attribute %qs argument %qs is unknown",
>> attr_name, orig_p);
>>
>> Martin
> Thank you Martin. I'm sending updated patch.
>
> Martin
>
>
> 0001-Enhance-target-and-target_clone-error-messages.patch
>
> From 2778f9ab4f1cd091780694e8cc1335d6125d95ec Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Wed, 17 Apr 2019 13:59:14 +0200
> Subject: [PATCH] Enhance target and target_clone error messages.
>
> gcc/ChangeLog:
>
> 2019-04-18 Martin Liska
>
> * cgraphclones.c: Call valid_attribute_p with 1 for
> target_clone.
> * config/i386/i386-c.c (ix86_pragma_target_parse): Use 0 as
> it's for target attribute.
> * config/i386/i386-protos.h (ix86_valid_target_attribute_tree):
> Add new boolean argument.
> * config/i386/i386.c (ix86_valid_target_attribute_inner_p):
> Likewise.
> (ix86_valid_target_attribute_tree): Pass target_clone_attr
> to ix86_valid_target_attribute_inner_p.
> (ix86_valid_target_attribute_p): Pass flags argument to
> ix86_valid_target_attribute_inner_p.
> (get_builtin_code_for_version): Use 0 as it's target attribute.
>
> gcc/testsuite/ChangeLog:
>
> 2019-04-18 Martin Liska
>
> * gcc.target/i386/funcspec-4.c: Update scanned pattern.
> * g++.target/i386/pr57362.C: Likewise.
OK
Jeff
Re: [4/4][PATCH] Discussing PR83507
On 4/29/19 10:28 AM, Roman Zhuykov wrote:
> Hi, Segher
>
> In pr84524.c we got a loop with an extended inline asm:
> asm volatile ("" : "+r" (v))
> which also gives us a “surprising” situation Alexander predicts.
>
> For sched-deps scanner such volatile asm is a “true barrier” and we
> create dependencies to almost all other instructions, while DF scanners
> don’t give us such information.
There is no such thing as a "true barrier" in extended asm. The only thing
volatile asm means is that the asm has a side effect unknown to the
compiler;
this can *not* be a modification of a register or of memory contents, such
things are known by the compiler, that's what clobbers and "memory" clobber
are about.
>>>
>>> In sched-deps.c we got:
>>> case ASM_OPERANDS:
>>> case ASM_INPUT:
>>> {
>>>/* Traditional and volatile asm instructions must be considered to
>>> use
>>> and clobber all hard registers, all pseudo-registers and all of
>>> memory. So must TRAP_IF and UNSPEC_VOLATILE operations.
>>>
>>> Consider for instance a volatile asm that changes the fpu rounding
>>> mode. An insn should not be moved across this even if it only
>>> uses
>>> pseudo-regs because it might give an incorrectly rounded result.
>>> */
>>>if ((code != ASM_OPERANDS || MEM_VOLATILE_P (x))
>>>&& !DEBUG_INSN_P (insn))
>>> reg_pending_barrier = TRUE_BARRIER;
>>>...
>>
>> This code was added in 1997 (r14770). In 2004 the documentation was
>> changed to clarify how things really work (r88999):
>>
>> "Note that even a volatile @code{asm} instruction can be moved relative to
>> other code, including across jump instructions."
>>
>> (followed by an example exactly about what this means for FPU control).
>
> Thanks for pointing to that changes! Unfortunately, sched-deps.c was
> more conservative this 15 years...
> Let’s try to fix it.
Also note that the integration of the Haifa scheduler was a large
change. A small detail like this could have been missed.
Jeff
Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)
On Tue, Apr 30, 2019 at 09:03:07AM -0600, Jeff Law wrote: > On 2/16/19 12:12 AM, Jakub Jelinek wrote: > > Both the C and C++ standard guarantee that the argc argument to main is > > non-negative, the following patch sets (or adjusts) the corresponding > > SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also > > propagate etc. I had to change one testcase because it started optimizing > > it better (the test has been folded away), so no sinking was done. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > 2019-02-16 Jakub Jelinek > > > > PR tree-optimization/89350 > > * gimple-ssa-evrp.c: Include tree-dfa.h and langhooks.h. > > (maybe_set_main_argc_range): New function. > > (execute_early_vrp): Call it. > > > > * gcc.dg/tree-ssa/vrp122.c: New test. > > * gcc.dg/tree-ssa/ssa-sink-3.c (main): Rename to ... > > (bar): ... this. > My recollection is this was somewhat controversial WRT standards > interpretation. Additionally, it's just not clear how often this will > help in the real world and Martin adjusted compute_objsize and the > restrict pass to avoid the false positive. > > Do we want to continue with this patch independently or not? My > inclination would be no. I wanted to follow-up on this and restrict it to for now to C++ where it is non-controversial. Would be of course nice if the C WG discusses it too and clarifies if needed, I agree the wording isn't 100% clear and the requirement shouldn't be on whatever use does with that parameter inside of main, but should be a contract on when main is called and if user decides to call main multiple times in C, that contract should not be violated even during the subsequent calls. Jakub
Re: [PATCH] Update sinhatanh test
On 4/29/19 3:41 PM, Giuliano Augusto Faulin Belinassi wrote: > Hi. > Ping :-) > (I hope I am not bothering you with it) > Giuliano. > > On Thu, Jan 10, 2019 at 6:51 PM Giuliano Belinassi > wrote: >> >> Previously, the tests 'sinhatanh-2.c' and 'sinhatanh-3.c' did not count >> the number of functions found in the tree-dump. This patch address this >> issue. >> >> 2019-01-10 Giuliano Belinassi >> >> * gcc.dg/sinhatanh-2.c: Count the number of functions. >> * gcc.dg/sinhatanh-3.c: Likewise. >> Thanks for the ping. The patch wasn't even in my queue of things to look at. I've installed the patch on the trunk. jeff
[PATCH] PR libstdc++/90281 Fix string conversions for filesystem::path
Fix several bugs in the encoding conversions for filesystem::path that prevent conversion of Unicode characters outside the Basic Multilingual Plane, and prevent returning basic_string specializations with alternative allocator types. The std::codecvt_utf8 class template is not suitable for UTF-16 conversions because it uses UCS-2 instead. For conversions between UTF-8 and UTF-16 either std::codecvt or codecvt_utf8_utf16 must be used. The __str_codecvt_in and __str_codecvt_out utilities do not return false on a partial conversion (e.g. for invalid or incomplete Unicode input). Add new helpers that treat partial conversions as errors, and use them for all filesystem::path conversions. PR libstdc++/90281 Fix string conversions for filesystem::path * include/bits/fs_path.h (u8path) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_in_all to fail for partial conversions and throw on error. [!_GLIBCXX_FILESYSTEM_IS_WINDOWS && _GLIBCXX_USE_CHAR8_T] (path::_Cvt): Add explicit specialization. [_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Remove overloads. [_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use if-constexpr instead of dispatching to _S_wconvert. Use codecvt instead of codecvt_utf8. Use __str_codecvt_in_all and __str_codecvt_out_all. [!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use codecvt instead of codecvt_utf8. Use __str_codecvt_out_all. (path::_S_str_convert) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values with allocator. Use __str_codecvt_out_all. Fallthrough to POSIX code after converting to UTF-8. (path::_S_str_convert): Use codecvt instead of codecvt_utf8. Use __str_codecvt_in_all. (path::string): Fix initialization of string types with different allocators. (path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all. * include/bits/locale_conv.h (__do_str_codecvt): Reorder static and runtime conditions. (__str_codecvt_out_all, __str_codecvt_in_all): New functions that return false for partial conversions. * include/experimental/bits/fs_path.h (u8path): [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Implement correctly for mingw. [_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_wconvert): Add missing handling for char8_t. Use codecvt and codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_in_all and __str_codecvt_out_all. [!_GLIBCXX_FILESYSTEM_IS_WINDOWS] (path::_Cvt::_S_convert): Use codecvt instead of codecvt_utf8. Use __str_codecvt_out_all. (path::string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use codecvt_utf8_utf16 instead of codecvt_utf8. Construct return values with allocator. Use __str_codecvt_out_all and __str_codecvt_in_all. (path::string) [!_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use __str_codecvt_in_all. (path::u8string) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use codecvt_utf8_utf16 instead of codecvt_utf8. Use __str_codecvt_out_all. * src/c++17/fs_path.cc (path::_S_convert_loc): Use __str_codecvt_in_all. * src/filesystem/path.cc (path::_S_convert_loc): Likewise. * testsuite/27_io/filesystem/path/construct/90281.cc: New test. * testsuite/27_io/filesystem/path/factory/u8path.cc: New test. * testsuite/27_io/filesystem/path/native/string.cc: Test with empty strings and with Unicode characters outside the basic multilingual plane. * testsuite/27_io/filesystem/path/native/alloc.cc: New test. * testsuite/experimental/filesystem/path/construct/90281.cc: New test. * testsuite/experimental/filesystem/path/factory/u8path.cc: New test. * testsuite/experimental/filesystem/path/native/alloc.cc: New test. * testsuite/experimental/filesystem/path/native/string.cc: Test with empty strings and with Unicode characters outside the basic multilingual plane. Tested powerpc64le-linux and x86_64-w64-mingw32. As this ended up being a large patch I'll wait until after 9.1.0 is released to commit this (and then will backport a simpler version). commit d7a5837ddbbae9f50f72acd63d09b7a6662c8828 Author: Jonathan Wakely Date: Mon Apr 29 21:43:49 2019 +0100 PR libstdc++/90281 Fix string conversions for filesystem::path Fix several bugs in the encoding conversions for filesystem::path that prevent conversion of Unicode characters outside the Basic Multilingual Plane, and prevent returning basic_string specializations with alternative allocator types. The std::codecvt_utf8 class template is not suitable for UTF-16
Re: [PATCH] Teach evrp that main's argc argument is always non-negative for C family (PR tree-optimization/89350)
On 2/16/19 12:12 AM, Jakub Jelinek wrote: > Hi! > > Both the C and C++ standard guarantee that the argc argument to main is > non-negative, the following patch sets (or adjusts) the corresponding > SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also > propagate etc. I had to change one testcase because it started optimizing > it better (the test has been folded away), so no sinking was done. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-02-16 Jakub Jelinek > > PR tree-optimization/89350 > * gimple-ssa-evrp.c: Include tree-dfa.h and langhooks.h. > (maybe_set_main_argc_range): New function. > (execute_early_vrp): Call it. > > * gcc.dg/tree-ssa/vrp122.c: New test. > * gcc.dg/tree-ssa/ssa-sink-3.c (main): Rename to ... > (bar): ... this. My recollection is this was somewhat controversial WRT standards interpretation. Additionally, it's just not clear how often this will help in the real world and Martin adjusted compute_objsize and the restrict pass to avoid the false positive. Do we want to continue with this patch independently or not? My inclination would be no. jeff >
Re: [PATCH 04/10] libiberty: Fix crash in ada_demangle()
On 1/10/19 5:16 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > The output buffer is pre-allocated to a maximum size under the assumption that > special names can only occur once, however nothing was enforcing this for > stream attributes. > > To fix this we treat stream attributes that appear before the end of the > mangled input as an error. > > * cplus-dem.c (ada_demangle): Only accept stream attributes if they're at > the end of the input. > * testsuite/demangle-expected: Add testcase. > I don't feel qualified enough to ACK/NACK this patch. What's not clear to me is whether or not a stream attribute can or can not appear more than once in a mangled name in Ada -- largely because of my lack of knowledge of Ada itself. Are function names mangled in Ada? If so, couldn't we have multiple parameters, each of which potentially has a stream attribute? What about structures where there's multiple members which have stream attributes? If we then have to mangle the structure, then ISTM we could end up with multiple stream attributes. Someone with more experience in Ada and our mangling scheme will need to chime in. Jeff
Re: [PATCH 09/10] libiberty: Correctly handle error result in dlang_parse_assocarray()
On 1/10/19 5:19 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > The number of elements were being taken as valid and for each one a separator > was appended to the output, resulting in a huge memory bloat before crashing > later on due to a signed integer overflow. > > * d-demangle.c (dlang_parse_assocarray): Correctly handle error result. > * testsuite/d-demangle-expected: Add testcase. > Thanks. I've installed this on the trunk. jeff
Re: [PATCH 08/10] libiberty: Correctly handle error result in dlang_parse_tuple()
On 1/10/19 5:18 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > The number of elements were being taken as valid and for each one a separator > was appended to the output, resulting in a huge memory bloat before crashing > later on due to a signed integer overflow. > > * d-demangle.c (dlang_parse_tuple): Correctly handle error result. > * testsuite/d-demangle-expected: Add testcase. > Thanks. I've installed this on the trunk. jeff
Re: [PATCH 07/10] libiberty: Correctly handle error result in dlang_parse_structlit()
On 1/10/19 5:18 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > The number of elements were being taken as valid and for each one a separator > was appended to the output, resulting in a huge memory bloat before crashing > later on due to a signed integer overflow. > > * d-demangle.c (dlang_parse_structlit): Correctly handle error result. > * testsuite/d-demangle-expected: Add testcase. > THanks. I've installed this on the trunk. jeff
Re: [PATCH 06/10] libiberty: Correctly handle error result in dlang_parse_arrayliteral()
On 1/10/19 5:17 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > The number of elements were being taken as valid and for each one a separator > was appended to the output, resulting in a huge memory bloat before crashing > later on due to a signed integer overflow. > > * d-demangle.c (dlang_parse_arrayliteral): Correctly handle error result. > * testsuite/d-demangle-expected: Add testcase. > Thanks. Installed on the trunk. jeff
Re: [PATCH 05/10] libiberty: Fix stack underflow in dlang_parse_integer()
On 1/10/19 5:17 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > A char array of size 10 was created on the stack to hold the decimal > representation of a long, which on my platform is 64 bits and hence has a > maximum value of 9223372036854775807, far exceeding 10 characters. > > Fix this by bumping the size of the array to 20 characters. > > * d-demangle.c (dlang_parse_integer): Fix stack underflow. > * testsuite/d-demangle-expected: Add testcase. > THanks. I've installed this on the trunk. jeff
Re: [PATCH 03/10] libiberty: Fix a crash in d_print_comp_inner()
On 1/10/19 5:15 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > 'typed_name' is checked before the loop, but not checked after every > iteration. This can cause a crash if the input buffer is malformed since > 'typed_name' can be assigned NULL. > > To fix this, break out of the loop if we see it's NULL and handle that case > afterwards. > > * cp-demangle (d_print_comp_inner): Guard against a NULL 'typed_name'. > * testsuite/demangle-expected: Add testcase. > THanks. I've installed this on the trunk. jeff
Re: [PATCH 02/10] libiberty: Fix a crash in d_encoding()
On 1/10/19 5:14 PM, Ben L wrote: > Hi all, > > First time emailing gcc-patches, so I'm sorry if I get any of this wrong or if > there's obvious errors repeated in my patches. AFAICT I should be sending each > change individually rather than as one bulk patch, so I'm sorry about the spam > too. > > All of these changes were found by fuzzing libiberty's demanglers over the > past week, and I have at least one more that it's currently crashing out on > but I haven't had time to look into why yet. > > Obviously since this is my first time emailing I don't have write access to > commit any of these, so if any are approved then I'd be grateful if you can > commit them too. > > Thanks, > Ben > > -- > > Passing "_ZZaSFvOEES_" to cplus_demangle() without the DMGL_PARAMS flag causes > a crash due to d_right (dc) returning NULL inside d_encoding(). > > Check for this case and handle it as an error rather than crashing when trying > to dereference the right side's type. > > * cp-demangle.c (d_encoding): Guard against NULL return values from > d_right (dc). > * testsuite/demangle-expected: Add testcase. > THanks. I've installed this on the trunk. Jeff
Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
On 4/30/19 8:00 AM, Jakub Jelinek wrote: > On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote: >>> Just curious, do we want to add math identities like above to match.pd ? >> I'd think so. >> >> >>> In practice, I am not sure how often we'd see "tanh * cosh" instead >>> of sinh directly in source, >> We're often surprised when what ultimately shows up in sources :-) And >> a transformation that allows us to turn two transcendentals and a >> multiplication into a single transcendental is going to be a big win. > > I guess an important question is if such transformations need to be guarded > by some -ffast-math suboptions, whether those transformations work properly > for signed zeros, NaNs, sNaNs, infinities, guarantee the same ulp, have the > same -ferrno-math behavior etc. Yes. If you look at the discussion with Gualiano for the first set in this space that was the hardest part. And for Barbara's we know there's at least one issue in this space as well -- in particular it looks like the long double handling is incorrect in the sign bit for very small inputs. The question is precisely where that's gone wrong :-) jeff
Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote: > > Just curious, do we want to add math identities like above to match.pd ? > I'd think so. > > > > In practice, I am not sure how often we'd see "tanh * cosh" instead > > of sinh directly in source, > We're often surprised when what ultimately shows up in sources :-) And > a transformation that allows us to turn two transcendentals and a > multiplication into a single transcendental is going to be a big win. I guess an important question is if such transformations need to be guarded by some -ffast-math suboptions, whether those transformations work properly for signed zeros, NaNs, sNaNs, infinities, guarantee the same ulp, have the same -ferrno-math behavior etc. Jakub
Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
On 4/29/19 9:58 PM, Prathamesh Kulkarni wrote: > On Tue, 30 Apr 2019 at 02:56, Jeff Law wrote: >> >> On 1/30/19 7:10 AM, Bárbara de Castro Fernandes wrote: >>> This patch simplifies the function tanh (x) * cosh (x) -> sinh (x). >>> This rule is derived from the relationship between hyperbolic >>> functions. >>> >>> I ran the tests and gfortran.dg/pr79966.f90 failed, but this failure >>> is unrelated to the patch (see >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711 for more >>> information). My architecture is x86_64. >>> >>> gcc/ChangeLog: >>> 2019-01-30 Bárbara Fernandes >>> >>> * match.pd (tanh (x) * cosh (x)): New simplification rule. >>> >>> gcc/testsuite/ChangeLog: >>> 2019-01-30 Bárbara Fernandes >>> >>> * tanhtimescosh.c: New test. >> So how does this behave for numbers extremely close to zero in practice >> and do we have to worry about overflow problems when cosh(x) gets large? > Hi Jeff, > Just curious, do we want to add math identities like above to match.pd ? I'd think so. > In practice, I am not sure how often we'd see "tanh * cosh" instead > of sinh directly in source, We're often surprised when what ultimately shows up in sources :-) And a transformation that allows us to turn two transcendentals and a multiplication into a single transcendental is going to be a big win. > altho it seems we do simplify tan * cos -> sin. > In general, I suppose there are lot of identities we haven't added > because the likelihood of "match" part isn't high. Perhaps. I have to assume the submitter submitted this particular simplification for a reason. jeff
Re: [PATCH] RX: Add rx-*-linux target
On Tue, 30 Apr 2019 06:48:01 +0900, Jeff Law wrote: > > On 3/26/19 8:21 AM, Yoshinori Sato wrote: > > I ported linux kernel to Renesas RX. > > > > rx-*-elf target output a binary different from the standard ELF. > > It has the same format as the Renesas compiler. > > > > But the linux kernel requires the standard ELF format. > > I want to define a rx-*-linux target so that I can generate > > a standard ELF binary.I believe you have a copyright assignment on file for > > your H8 work. Was > the assignment specific to the H8 or was it more general? No. This changes other target. These files are not included in my copyright assignment. > > > diff --git a/gcc/config/rx/linux.h b/gcc/config/rx/linux.h > > new file mode 100644 > > index 000..69500a379f2 > > --- /dev/null > > +++ b/gcc/config/rx/linux.h > > > + > > +/* This is how to output an element of a case-vector that is relative. > > + Note: The local label referenced by the "3b" below is emitted by > > + the tablejump insn. */ > > + > > +#undef ASM_OUTPUT_ADDR_DIFF_ELT > > +#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \ > > + fprintf (FILE, "\t.long .L%d - 1b\n", VALUE) > Note the comment references "3b", but the output is "1b". Oh. I will update it. > I don't see anything in here significantly concerning. We just need to > verify your copyright assignment status. OK. > Also, do you have write access to the repo? I don't have write permission of svn repository. > Jeff > -- Yosinori Sato
[PATCH][DOC] Add missing dash for 2 options in documentation (PR debug/90288).
Hi.
One obvious documentation fix that I'm going to install.
Martin
gcc/ChangeLog:
2019-04-30 Martin Liska
PR debug/90288
* doc/invoke.texi: Add missing dash for gas-locview-support
and gno-as-locview-support.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 29585cf15aa..516eb24eb74 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7961,7 +7961,7 @@ assembler was found to support such directives.
Force GCC to generate DWARF2+ line number tables internally, if DWARF2+
line number tables are to be generated.
-@item gas-locview-support
+@item -gas-locview-support
@opindex gas-locview-support
Inform the compiler that the assembler supports @code{view} assignment
and reset assertion checking in @code{.loc} directives.
@@ -7969,7 +7969,7 @@ and reset assertion checking in @code{.loc} directives.
This option will be enabled by default if, at GCC configure time, the
assembler was found to support them.
-@item gno-as-locview-support
+@item -gno-as-locview-support
Force GCC to assign view numbers internally, if
@option{-gvariable-location-views} are explicitly requested.
Re: [PATCH, stage1] Construct ipa_reduced_postorder always for overwritable (PR ipa/89009).
PING^2
On 3/6/19 11:05 AM, Martin Liška wrote:
> @Honza: PING^1
>
> On 2/20/19 10:10 AM, Martin Liška wrote:
>> On 2/19/19 2:25 PM, Martin Jambor wrote:
>>> Hi,
>>>
>>> On Tue, Feb 19 2019, Martin Liška wrote:
On 2/14/19 11:19 AM, Jan Hubicka wrote:
>
>>>
>>> ...
>>>
> Next stage1 we should also teach the callback to ignore edges of calls
> that are not being optimized.
I'm sending patch for that.
>>>
>>> ...
>>>
gcc/ChangeLog:
2019-02-19 Martin Liska
* ipa-cp.c (ignore_edge_p): New function.
(build_toporder_info): Use it.
* ipa-inline.c (ignore_edge_p): New function/
(inline_small_functions): Use it.
* ipa-pure-const.c (ignore_edge_for_nothrow):
Verify opt_for_fn for caller and callee.
(ignore_edge_for_pure_const): Likewise.
* ipa-reference.c (ignore_edge_p): Extend to check
for opt_for_fn.
* ipa-utils.c (searchc): Refactor.
* ipa-utils.h: Fix coding style.
---
gcc/ipa-cp.c | 18 +-
gcc/ipa-inline.c | 12 +++-
gcc/ipa-pure-const.c | 17 -
gcc/ipa-reference.c | 13 ++---
gcc/ipa-utils.c | 3 +--
gcc/ipa-utils.h | 2 --
6 files changed, 51 insertions(+), 14 deletions(-)
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 442d5c63eff..004b3a34b1c 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -806,6 +806,21 @@ public:
{}
};
+/* Skip edges from and to nodes without ipa_cp enabled.
+ Ignore not available symbols. */
+
+static bool
+ignore_edge_p (cgraph_edge *e)
+{
+ enum availability avail;
+ e->callee->function_or_virtual_thunk_symbol (, e->caller);
>>>
>>> Can't the return value of this call be directly fed...
>>>
+
+ return (avail <= AVAIL_INTERPOSABLE
+|| !opt_for_fn (e->caller->decl, flag_ipa_cp)
+|| !opt_for_fn (e->callee->function_symbol ()->decl,
>>>
>>> ...here instead of calling function_symbol... which does not look
>>> through thunks which IMHO you want, even if only for consistency.
>>
>> Yes, I like it.
>>
>> There's a new version of the patch I've just tested.
>>
>> Martin
>>
>>>
>>> Otherwise, it the IPA-CP bits obviously look good,
>>>
>>> Martin
>>>
>>
>
[PATCH][GCC 10][RFC] Fix PR testsuite/90113
Hello
Two weeks ago I posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113 We have some
unnecessary torture runs for gfortran.dg tests. Full description
inside PR.
Regtested r270624 trunk on x86_64:
Unpatched:
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes50246
# of expected failures 188
# of unsupported tests 80
Patched:
=== gfortran tests ===
Running target unix
FAIL: gfortran.dg/class_45b.f03 (test for excess errors)
FAIL: gfortran.dg/inline_matmul_1.f90 scan-tree-dump-times optimized
"_gfortran_matmul" 0
FAIL: gfortran.dg/iso_fortran_env_3.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/iso_fortran_env_3.f90 compilation failed to
produce executable
FAIL: gfortran.dg/iso_fortran_env_5.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/iso_fortran_env_5.f90 scan-tree-dump-times
original "_gfortran_stop" 0
FAIL: gfortran.dg/iso_fortran_env_6.f90 (test for errors, line 24)
FAIL: gfortran.dg/iso_fortran_env_6.f90 (test for errors, line 29)
FAIL: gfortran.dg/iso_fortran_env_6.f90 (test for errors, line 34)
FAIL: gfortran.dg/iso_fortran_env_6.f90 (test for excess errors)
FAIL: gfortran.dg/iso_fortran_env_7.f90 (test for excess errors)
FAIL: gfortran.dg/pr67140.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/pr67140.f90 compilation failed to produce executable
FAIL: gfortran.dg/pr71649.f90 (test for errors, line 4)
FAIL: gfortran.dg/pr71649.f90 (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_6.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/proc_ptr_comp_6.f90 compilation failed to
produce executable
FAIL: gfortran.dg/quad_1.f90 (test for excess errors)
FAIL: gfortran.dg/quad_3.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/quad_3.f90 compilation failed to produce executable
FAIL: gfortran.dg/read_eof_all.f90 execution test
FAIL: gfortran.dg/short_circuiting.f90 (test for warnings, line 30)
FAIL: gfortran.dg/storage_size_4.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/storage_size_4.f90 scan-tree-dump-not original
"_gfortran_stop"
FAIL: gfortran.dg/team_form_1.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/team_form_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/team_number_1.f90 (test for excess errors)
UNRESOLVED: gfortran.dg/team_number_1.f90 compilation failed to
produce executable
=== gfortran Summary ===
# of expected passes23396
# of unexpected failures20
# of expected failures 163
# of unresolved testcases 8
# of unsupported tests 56
I haven't looked at those failures yet. Maybe torture should be
disabled another way, I'm not sure.
Roman
diff --git a/gcc/testsuite/gfortran.dg/dg.exp b/gcc/testsuite/gfortran.dg/dg.exp
--- a/gcc/testsuite/gfortran.dg/dg.exp
+++ b/gcc/testsuite/gfortran.dg/dg.exp
@@ -54,10 +54,10 @@ proc dg-compile-aux-modules { args } {
}
# Main loop.
-gfortran-dg-runtest [lsort \
+dg-runtest [lsort \
[glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ] ]
"" $DEFAULT_FFLAGS
-gfortran-dg-runtest [lsort \
+dg-runtest [lsort \
[glob -nocomplain $srcdir/$subdir/g77/*.\[fF\] ] ] "" $DEFAULT_FFLAGS
Re: [Patch AArch64] Add __ARM_FEATURE_ATOMICS
On Tue, Apr 30, 2019 at 12:38 PM Jakub Jelinek wrote:
>
> On Tue, Apr 30, 2019 at 10:50:46AM +0100, Richard Earnshaw (lists) wrote:
> > > * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> > > __ARM_FEATURE_ATOMICS
> > >
> > > atomics.txt
> > >
> > > diff --git a/gcc/config/aarch64/aarch64-c.c
> > > b/gcc/config/aarch64/aarch64-c.c
> > > index fcb1e80177d..6d5acb02fc6 100644
> > > --- a/gcc/config/aarch64/aarch64-c.c
> > > +++ b/gcc/config/aarch64/aarch64-c.c
> > > @@ -147,6 +147,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
> > >builtin_define_with_int_value ("__ARM_FEATURE_SVE_BITS", bits);
> > > }
> > >
> > > + aarch64_def_or_undef (TARGET_LSE, "__ARM_FEATURE_ATOMICS", pfile);
> > >aarch64_def_or_undef (TARGET_AES, "__ARM_FEATURE_AES", pfile);
> > >aarch64_def_or_undef (TARGET_SHA2, "__ARM_FEATURE_SHA2", pfile);
> > >aarch64_def_or_undef (TARGET_SHA3, "__ARM_FEATURE_SHA3", pfile);
> > >
> >
> >
> > This is OK for trunk, 7 and 8. For 9, I think you'll need to wait for
> > 9.2 now, unless Jakub is feeling generous...
>
> Ok if you can commit it in the next hour at most, want to do a rc2 then and
> afterwards would hope no changes till release.
Done with a very quick smoke test.
Thank you Jakub and Richard.
Ramana
>
> Jakub
Re: Replacement for diagnostics linter
On 4/25/19 7:29 PM, Roland Illig wrote: > There's a linter in contrib/check-internal-format-escaping.py that > checks whether the base file for translations (such as French or German) > conform to some basic style rules. This mostly affects the diagnostics > emitted by GCC. > > As the German translation I have added several checks to the linter and > added rationales to most of the checks. > > Since I completely rewrote the linter, it's more convenient to not look > at the patch but only the rewritten code. Therefore I've provided both > of them. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117. > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119. > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176. > > Thoughts? > Hi. I'm fine with the replacement, please provide a ChangeLog entry and install it. Martin
Re: [Patch AArch64] Add __ARM_FEATURE_ATOMICS
On Tue, Apr 30, 2019 at 10:50:46AM +0100, Richard Earnshaw (lists) wrote:
> > * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> > __ARM_FEATURE_ATOMICS
> >
> > atomics.txt
> >
> > diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
> > index fcb1e80177d..6d5acb02fc6 100644
> > --- a/gcc/config/aarch64/aarch64-c.c
> > +++ b/gcc/config/aarch64/aarch64-c.c
> > @@ -147,6 +147,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
> >builtin_define_with_int_value ("__ARM_FEATURE_SVE_BITS", bits);
> > }
> >
> > + aarch64_def_or_undef (TARGET_LSE, "__ARM_FEATURE_ATOMICS", pfile);
> >aarch64_def_or_undef (TARGET_AES, "__ARM_FEATURE_AES", pfile);
> >aarch64_def_or_undef (TARGET_SHA2, "__ARM_FEATURE_SHA2", pfile);
> >aarch64_def_or_undef (TARGET_SHA3, "__ARM_FEATURE_SHA3", pfile);
> >
>
>
> This is OK for trunk, 7 and 8. For 9, I think you'll need to wait for
> 9.2 now, unless Jakub is feeling generous...
Ok if you can commit it in the next hour at most, want to do a rc2 then and
afterwards would hope no changes till release.
Jakub
Re: [9/10 PATCH] Fix up filesystem libstdc++ exports for riscv64
On 30/04/19 13:35 +0200, Jakub Jelinek wrote: On Tue, Apr 30, 2019 at 12:02:18PM +0100, Jonathan Wakely wrote: > So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle > https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w > > Unfortunately, at least judging from the libstdc++*debug symbols on riscv64 > I've posted, it probably isn't just a matter of following, because while > some symbols like that are in, most of them are not. I've populated a riscv64-linux-gnu fedora sysroot and built a cross-compiler, on which I've managed to reproduce it too. The issue with seemingly missing STB_LOCAL symbols from the list I was expecting is most likely due to -ffunction-sections -Wl,--gc-sections way of how is libstdc++.so linked. With the following patch they are now all included and the patch also adjusts the riscv64 baseline to match that. Ok for trunk/9.1? OK, thanks very much.
[9/10 PATCH] Fix up filesystem libstdc++ exports for riscv64
On Tue, Apr 30, 2019 at 12:02:18PM +0100, Jonathan Wakely wrote:
> > So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
> > https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
> >
> > Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
> > I've posted, it probably isn't just a matter of following, because while
> > some symbols like that are in, most of them are not.
I've populated a riscv64-linux-gnu fedora sysroot and built a
cross-compiler, on which I've managed to reproduce it too.
The issue with seemingly missing STB_LOCAL symbols from the list I was
expecting is most likely due to -ffunction-sections -Wl,--gc-sections
way of how is libstdc++.so linked.
With the following patch they are now all included and the patch also
adjusts the riscv64 baseline to match that.
Ok for trunk/9.1?
2019-04-30 Jakub Jelinek
* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Change _Lock_policyE2 exports
to _Lock_policyE[012].
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
--- libstdc++-v3/config/abi/pre/gnu.ver.jj 2019-04-30 10:55:31.118223843
+0200
+++ libstdc++-v3/config/abi/pre/gnu.ver 2019-04-30 13:27:23.810663072 +0200
@@ -2234,17 +2234,17 @@ GLIBCXX_3.4.26 {
_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_;
_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
-
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS6_;
# basic_ostream::operator<<(nullptr_t)
_ZNSolsEDn;
--- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj
2019-04-30 10:55:39.878083876 +0200
+++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
2019-04-30 13:27:50.897230866 +0200
@@ -2058,6 +2058,16 @@ FUNC:_ZNSt12__basic_fileIcEC1EP15pthread
FUNC:_ZNSt12__basic_fileIcEC2EP15pthread_mutex_t@@GLIBCXX_3.4
FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX_3.4
FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS4_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEaSEOS4_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEC1EOS6_@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_@@GLIBCXX_3.4.26
Re: [4/4][PATCH] Discussing PR83507
> > > This code was added in 1997 (r14770). In 2004 the documentation was
> > > changed to clarify how things really work (r88999):
> > >
> > > "Note that even a volatile @code{asm} instruction can be moved relative to
> > > other code, including across jump instructions."
> > >
> > > (followed by an example exactly about what this means for FPU control).
> >
> > Thanks for pointing to that changes! Unfortunately, sched-deps.c was
> > more conservative this 15 years...
> > Let’s try to fix it.
>
> If it causes problems now, that would be a good idea yes :-)
>
> > > I mean have the modulo scheduler implement the correct asm semantics, not
> > > some more restrictive thing that gets it into conflicts with DF, etc.
> > >
> > > I don't think this will turn out to be a problem in any way. Some invalid
> > > asm will break, sure.
> >
> > I have started with applying this without any SMS changes:
> >
> > diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
> > --- a/gcc/sched-deps.c
> > +++ b/gcc/sched-deps.c
> > @@ -2753,22 +2753,14 @@ sched_analyze_2 (struct deps_desc *deps, rtx
> > x, rtx_insn *insn)
> >
> > case UNSPEC_VOLATILE:
> >flush_pending_lists (deps, insn, true, true);
> > +
> > + if (!DEBUG_INSN_P (insn))
> > + reg_pending_barrier = TRUE_BARRIER;
> >/* FALLTHRU */
> >
> > case ASM_OPERANDS:
> > case ASM_INPUT:
> >{
> > - /* Traditional and volatile asm instructions must be considered to
> > use
> > - and clobber all hard registers, all pseudo-registers and all of
> > - memory. So must TRAP_IF and UNSPEC_VOLATILE operations.
> > -
> > - Consider for instance a volatile asm that changes the fpu
> > rounding
> > - mode. An insn should not be moved across this even if it only
> > uses
> > - pseudo-regs because it might give an incorrectly rounded result.
> > */
> > - if ((code != ASM_OPERANDS || MEM_VOLATILE_P (x))
> > - && !DEBUG_INSN_P (insn))
> > - reg_pending_barrier = TRUE_BARRIER;
> > -
> > /* For all ASM_OPERANDS, we must traverse the vector of input
> > operands.
> >We cannot just fall through here since then we would be confused
> >by the ASM_INPUT rtx inside ASM_OPERANDS, which do not indicate
>
> UNSPEC_VOLATILE and volatile asm should have the same semantics, ideally.
> One step at a time I guess :-)
When barrier for UNSPEC_VOLATILE is also dropped, there are more
issues on x86_64:
FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr62021.c execution test
FAIL: gcc.target/i386/avx2-vect-aggressive.c execution test
I haven’t looked at those vectorization tests.
> > Regstrapping it on x86-64 shows some failures. First is with ms-sysv
> > abi test and can be solved like this:
>
> [ snip ]
>
> > Here we have some asms which control stack pointer (sigh!). It
> > certainly may be broken at any moment, but right now “memory” clobber
> > fixes everything for me.
>
> Makes sense.
>
> > Another failure is:
> >
> > FAIL: gcc.dg/guality/pr58791-4.c -O2 -DPREVENT_OPTIMIZATION line
> > pr58791-4.c:32 i == 486
>
> [ snip ]
>
> > It is connected to debug-info, and I cannot solve it myself. I am not
> > sure how this should work when we try to print dead-code variable (i2)
> > while debugging -O2 (O3/Os) compiled executable. Jakub created that
> > test, he is in CC already.
>
> What does PREVENT_OPTIMIZATION do? It probably needs to be made a bit
> stronger.
It seems PREVENT_OPTIMIZATION stuff influents only one test –
gcc.dg/guality/pr45882.c. Other tests do not contain ATTRIBUTE_USED
macro.
> (It seems to just add some "used"?)
>
> > I will also look at aarch64 regstrap a bit later. But that job should
> > also be done for all other targets. Segher, could you test it on
> > rs6000?
>
> Do you have an account on the compile farm? It has POWER7 (BE, 32/64),
> as well as POWER8 and POWER9 machines (both LE).
> https://cfarm.tetaneutral.net/
Ok, I’ll use the farm. Have filled the “new user” form already.
Aarch64 is still testing, maybe next time will use farm instead of
qemu-system.
I forgot to mention in previous letter, that with this patch we also
drop dependencies between volatile asms and volatile mems. We have
some offline discussion with Alex, and it seems that since 2004 docs
never guarantee such a dependency, user should add relevant
constraints into asm in all cases. But somebody may have another
opinion about this tricky moment.
Roman
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 12:29 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> Answer for that is easy, because gnu.ver doesn't say so:
Doh, of course.
>
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
>
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
>
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
>
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
>
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
>
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
> Thus, you'd need to replace those _Lock_policyE2 with _Lock_policyE[012].
> If we want to do that, we need to do that right now (but not sure how long
> would it take to get a confirmation from riscv64, either we'd need to ask
> Matthias to do some build, or I'd need to talk to whatever maintainers
Linking this program should verify if the symbols are needed:
#include
int main()
{
for (auto f : std::filesystem::directory_iterator("."))
;
for (auto f : std::filesystem::recursive_directory_iterator("."))
;
}
So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
I've posted, it probably isn't just a matter of following, because while
some symbols like that are in, most of them are not.
E.g. the first one mentioned in the above paste is missing, the closest
constructor to
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_
that is missing but needed by the binary is:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1ERKSt10__weak_ptrIS2_LS4_1EESt9nothrow_t
I've tried to simulate this on x86_64 by hand-editing c++config.h to
-#define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
+/* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
but then after make clean; make -j32 in libstdc++ objdir I don't see any
__shared_ptr.*_Lock_policyE symbols.
This patch should simulate it more reliably, by explicitly selecting
the _S_mutex policy instead of using the default.
diff --git a/libstdc++-v3/include/bits/fs_dir.h b/libstdc++-v3/include/bits/fs_dir.h
index 69f0eb825fe..dc1569067e0 100644
--- a/libstdc++-v3/include/bits/fs_dir.h
+++ b/libstdc++-v3/include/bits/fs_dir.h
@@ -420,7 +420,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
friend class recursive_directory_iterator;
-std::__shared_ptr<_Dir> _M_dir;
+std::__shared_ptr<_Dir, _S_mutex> _M_dir;
};
inline directory_iterator
@@ -509,7 +509,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{ return !(__lhs == __rhs); }
struct _Dir_stack;
-std::__shared_ptr<_Dir_stack> _M_dirs;
+std::__shared_ptr<_Dir_stack, _S_mutex> _M_dirs;
};
inline recursive_directory_iterator
@@ -529,9 +529,9 @@ _GLIBCXX_END_NAMESPACE_CXX11
// value of __default_lock_policy between code including this header and
// the library will cause a linker error.
extern template class
-__shared_ptr;
+__shared_ptr;
extern template class
-__shared_ptr;
+__shared_ptr;
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index d8c48f6d6d8..92a48836cf4 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -38,8 +38,8 @@
namespace fs = std::filesystem;
namespace posix = std::filesystem::__gnu_posix;
-template class std::__shared_ptr;
-template class std::__shared_ptr;
+template class std::__shared_ptr;
+template class std::__shared_ptr;
struct fs::_Dir : _Dir_base
{
@@ -135,7 +135,7 @@ directory_iterator(const path& p, directory_options options, error_code* ecptr)
if (dir.dirp)
{
- auto sp = std::__make_shared(std::move(dir));
+ auto sp = std::__make_shared(std::move(dir));
if (sp->advance(skip_permission_denied, ec))
_M_dir.swap(sp);
}
@@ -203,7 +203,7 @@ recursive_directory_iterator(const path& p, directory_options options,
{
if (ecptr)
ecptr->clear();
- auto sp = std::__make_shared<_Dir_stack>(options, dirp, p);
+ auto sp = std::__make_shared<_Dir_stack, _S_mutex>(options, dirp, p);
if (ecptr ? sp->top().advance(*ecptr) : sp->top().advance())
_M_dirs.swap(sp);
[PATCH] Fix filesystem::path tests
The root_path.cc test had some debugging macros left in accidentally, so
didn't FAIL correctly if an assertion failed.
The string-char8_t.cc tests didn't compile on Windows.
* testsuite/27_io/filesystem/path/decompose/root_path.cc: Remove
macros accidentally left in.
* testsuite/27_io/filesystem/path/native/string-char8_t.cc: Remove
unnecessary -lstdc++fs option. Fix test for mingw.
* testsuite/experimental/filesystem/path/native/string-char8_t.cc:
Fix test for mingw.
Tested x86_64-linux and x86_64-w64-mingw32, committed to trunk.
commit 4c493a0cb94c9f9d7131c7f7c37f2b321fc12559
Author: Jonathan Wakely
Date: Tue Apr 30 11:23:02 2019 +0100
Fix filesystem::path tests
The root_path.cc test had some debugging macros left in accidentally, so
didn't FAIL correctly if an assertion failed.
The string-char8_t.cc tests didn't compile on Windows.
* testsuite/27_io/filesystem/path/decompose/root_path.cc: Remove
macros accidentally left in.
* testsuite/27_io/filesystem/path/native/string-char8_t.cc: Remove
unnecessary -lstdc++fs option. Fix test for mingw.
* testsuite/experimental/filesystem/path/native/string-char8_t.cc:
Fix test for mingw.
diff --git
a/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/root_path.cc
b/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/root_path.cc
index 4f4c531819f..d573b4899c0 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/root_path.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/decompose/root_path.cc
@@ -35,10 +35,6 @@ test01()
VERIFY( p2.root_path() == path("/") );
}
-#undef VERIFY
-#define VERIFY(X) do { if (!(X)) { __builtin_puts("FAIL: " #X); } }
while(false)
-#define DUMP(X, Y, Z) do { if (!(Y == Z)) { __builtin_printf("%s %s %s\n",
X.c_str(), Y.c_str(), Z.c_str()); } } while(false)
-
void
test02()
{
@@ -48,7 +44,6 @@ test02()
path rootn = p.root_name();
path rootd = p.root_directory();
VERIFY( rootp == (rootn / rootd) );
-DUMP(p, rootp , (rootn / rootd) );
}
}
diff --git
a/libstdc++-v3/testsuite/27_io/filesystem/path/native/string-char8_t.cc
b/libstdc++-v3/testsuite/27_io/filesystem/path/native/string-char8_t.cc
index f5bb1afca5d..d333787a71e 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/native/string-char8_t.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/native/string-char8_t.cc
@@ -15,7 +15,7 @@
// with this library; see the file COPYING3. If not see
//
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> > Answer for that is easy, because gnu.ver doesn't say so:
>
> Doh, of course.
>
> >
> > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
> >
> > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
> >
> > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
> >
> > _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
> >
> > _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
> >
> > _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
> >
> > _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
> >
> > _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
> >
> > _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
> >
> > _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
> > Thus, you'd need to replace those _Lock_policyE2 with _Lock_policyE[012].
> > If we want to do that, we need to do that right now (but not sure how long
> > would it take to get a confirmation from riscv64, either we'd need to ask
> > Matthias to do some build, or I'd need to talk to whatever maintainers
>
> Linking this program should verify if the symbols are needed:
>
> #include
> int main()
> {
> for (auto f : std::filesystem::directory_iterator("."))
>;
> for (auto f : std::filesystem::recursive_directory_iterator("."))
>;
> }
So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
I've posted, it probably isn't just a matter of following, because while
some symbols like that are in, most of them are not.
E.g. the first one mentioned in the above paste is missing, the closest
constructor to
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_
that is missing but needed by the binary is:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1ERKSt10__weak_ptrIS2_LS4_1EESt9nothrow_t
I've tried to simulate this on x86_64 by hand-editing c++config.h to
-#define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
+/* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
but then after make clean; make -j32 in libstdc++ objdir I don't see any
__shared_ptr.*_Lock_policyE symbols.
--- libstdc++-v3/config/abi/pre/gnu.ver.jj 2019-04-26 17:37:44.807122357
+0200
+++ libstdc++-v3/config/abi/pre/gnu.ver 2019-04-30 11:47:03.962801721 +0200
@@ -2234,17 +2234,17 @@ GLIBCXX_3.4.26 {
_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_;
_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
-
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
-
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
-
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS5_;
+
Re: [PATCH] Don't ignore leading whitespace in AArch64 target attribute/pragma (PR target/89093)
On 16/04/2019 19:32, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 07:50:35PM +0200, Jakub Jelinek wrote:
>> On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
>>> No, that's not right. we should get rid of this.
>>
>> Here is a patch for that.
>>
>> Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> And here is the same thing for aarch64. Bootstrapped/regtested on
> aarch64-linux, ok for trunk?
>
> I think it is better not to accept any spaces in there, than accepting it
> only at the beginning and after , but not e.g. at the end of before ,
> like the trunk currently does, furthermore, e.g. x86 or ppc don't allow
> spaces there.
>
> 2019-04-16 Jakub Jelinek
>
> PR target/89093
> * config/aarch64/aarch64.c (aarch64_process_one_target_attr): Don't skip
> whitespace at the start of target attribute string.
>
> * gcc.target/aarch64/pr89093.c: New test.
> * gcc.target/aarch64/pr63304_1.c: Remove space from target string.
OK. I'll let you decide if you want this on gcc-9 as well :-)
R.
>
> --- gcc/config/aarch64/aarch64.c.jj 2019-04-11 10:26:22.907293129 +0200
> +++ gcc/config/aarch64/aarch64.c 2019-04-15 19:59:55.784226278 +0200
> @@ -12536,10 +12536,6 @@ aarch64_process_one_target_attr (char *a
>char *str_to_check = (char *) alloca (len + 1);
>strcpy (str_to_check, arg_str);
>
> - /* Skip leading whitespace. */
> - while (*str_to_check == ' ' || *str_to_check == '\t')
> -str_to_check++;
> -
>/* We have something like __attribute__ ((target ("+fp+nosimd"))).
> It is easier to detect and handle it explicitly here rather than going
> through the machinery for the rest of the target attributes in this
> --- gcc/testsuite/gcc.target/aarch64/pr89093.c.jj 2019-04-15
> 20:02:25.456788897 +0200
> +++ gcc/testsuite/gcc.target/aarch64/pr89093.c2019-04-15
> 20:02:04.433131260 +0200
> @@ -0,0 +1,7 @@
> +/* PR target/89093 */
> +/* { dg-do compile } */
> +
> +__attribute__((target (" no-strict-align"))) void f1 (void) {} /* {
> dg-error "is not valid" } */
> +__attribute__((target (" general-regs-only"))) void f2 (void) {} /* {
> dg-error "is not valid" } */
> +#pragma GCC target ("general-regs-only") /* { dg-error "is not valid" }
> */
> +void f3 (void) {}
> --- gcc/testsuite/gcc.target/aarch64/pr63304_1.c.jj 2017-09-13
> 16:22:19.795513580 +0200
> +++ gcc/testsuite/gcc.target/aarch64/pr63304_1.c 2019-04-15
> 20:27:17.724847578 +0200
> @@ -1,7 +1,7 @@
> /* { dg-do assemble } */
> /* { dg-options "-O1 --save-temps" } */
> #pragma GCC push_options
> -#pragma GCC target ("+nothing+simd, cmodel=small")
> +#pragma GCC target ("+nothing+simd,cmodel=small")
>
> int
> cal (double a)
>
>
> Jakub
>
Re: [Patch AArch64] Add __ARM_FEATURE_ATOMICS
On 09/04/2019 10:50, Ramana Radhakrishnan wrote:
> This keeps coming up repeatedly and the ACLE has finally added
> __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of
> the latest ACLE release
> (https://developer.arm.com/docs/101028/latest/5-feature-test-macros)
>
> I know it's late for GCC-9 but this is a simple macro which need not
> wait for another year.
>
> Ok for trunk and to backport to all release branches ?
>
> Tested with a simple build and a smoke test.
>
>
> regards
> Ramana
>
> * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> __ARM_FEATURE_ATOMICS
>
> atomics.txt
>
> diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
> index fcb1e80177d..6d5acb02fc6 100644
> --- a/gcc/config/aarch64/aarch64-c.c
> +++ b/gcc/config/aarch64/aarch64-c.c
> @@ -147,6 +147,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
>builtin_define_with_int_value ("__ARM_FEATURE_SVE_BITS", bits);
> }
>
> + aarch64_def_or_undef (TARGET_LSE, "__ARM_FEATURE_ATOMICS", pfile);
>aarch64_def_or_undef (TARGET_AES, "__ARM_FEATURE_AES", pfile);
>aarch64_def_or_undef (TARGET_SHA2, "__ARM_FEATURE_SHA2", pfile);
>aarch64_def_or_undef (TARGET_SHA3, "__ARM_FEATURE_SHA3", pfile);
>
This is OK for trunk, 7 and 8. For 9, I think you'll need to wait for
9.2 now, unless Jakub is feeling generous...
R
Re: [PATCH][GCC-7][AArch64] PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-7)
On 29/04/2019 17:58, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused by expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 7 branch? If ok, could someone please commit the patch on my
> behalf, I don't have commit rights.
Applied.
R.
>
> *** gcc/ChangeLog ***
>
> 2019-04-29 Srinath Parvathaneni
>
> PR target/90075
> * config/aarch64/iterators.md (V_INT_EQUIV): Add mode for
> integer equivalent of floating point values.
>
> Backport from mainline
> 2018-12-11 Richard Earnshaw
>
> PR target/37369
> * config/aarch64/iterators.md (sizem1): Add sizes for
> SFmode and DFmode.
> (Vbtype): Add SFmode mapping.
> * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete.
> (copysign3): New expand pattern.
> (copysign3_insn): New insn pattern.
>
> *** gcc/testsuite/ChangeLog ***
>
> 2019-04-29 Srinath Parvathaneni
>
> PR target/90075
> * gcc.target/aarch64/pr90075.c: New test.
>
>
> rb9.patch
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> 4c4e144587e6daa8e577477460594ebd66dbdf33..90f9ee658c5cc2eb0477502b3f9e2f60b7b23efd
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -140,6 +140,7 @@
> UNSPEC_RSQRTS
> UNSPEC_NZCV
> UNSPEC_XPACLRI
> +UNSPEC_COPYSIGN
> ])
>
> (define_c_enum "unspecv" [
> @@ -5003,45 +5004,45 @@
> ;; LDR d2, #(1 << 63)
> ;; BSL v2.8b, [y], [x]
> ;;
> -;; or another, equivalent, sequence using one of BSL/BIT/BIF.
> -;; aarch64_simd_bsldf will select the best suited of these instructions
> -;; to generate based on register allocation, and knows how to partially
> -;; constant fold based on the values of X and Y, so expand through that.
> -
> -(define_expand "copysigndf3"
> - [(match_operand:DF 0 "register_operand")
> - (match_operand:DF 1 "register_operand")
> - (match_operand:DF 2 "register_operand")]
> +;; or another, equivalent, sequence using one of BSL/BIT/BIF. Because
> +;; we expect these operations to nearly always operate on
> +;; floating-point values, we do not want the operation to be
> +;; simplified into a bit-field insert operation that operates on the
> +;; integer side, since typically that would involve three inter-bank
> +;; register copies. As we do not expect copysign to be followed by
> +;; other logical operations on the result, it seems preferable to keep
> +;; this as an unspec operation, rather than exposing the underlying
> +;; logic to the compiler.
> +
> +(define_expand "copysign3"
> + [(match_operand:GPF 0 "register_operand")
> + (match_operand:GPF 1 "register_operand")
> + (match_operand:GPF 2 "register_operand")]
>"TARGET_FLOAT && TARGET_SIMD"
> {
> - rtx mask = gen_reg_rtx (DImode);
> - emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 63));
> - emit_insn (gen_aarch64_simd_bsldf (operands[0], mask,
> - operands[2], operands[1]));
> + rtx bitmask = gen_reg_rtx (mode);
> + emit_move_insn (bitmask, GEN_INT (HOST_WIDE_INT_M1U
> + << (GET_MODE_BITSIZE (mode) - 1)));
> + emit_insn (gen_copysign3_insn (operands[0], operands[1], operands[2],
> +bitmask));
>DONE;
> }
> )
>
> -;; As above, but we must first get to a 64-bit value if we wish to use
> -;; aarch64_simd_bslv2sf.
> -
> -(define_expand "copysignsf3"
> - [(match_operand:SF 0 "register_operand")
> - (match_operand:SF 1 "register_operand")
> - (match_operand:SF 2 "register_operand")]
> +(define_insn "copysign3_insn"
> + [(set (match_operand:GPF 0 "register_operand" "=w,w,w,r")
> + (unspec:GPF [(match_operand:GPF 1 "register_operand" "w,0,w,r")
> + (match_operand:GPF 2 "register_operand" "w,w,0,0")
> + (match_operand: 3 "register_operand"
> + "0,w,w,X")]
> + UNSPEC_COPYSIGN))]
>"TARGET_FLOAT && TARGET_SIMD"
> -{
> - rtx mask = gen_reg_rtx (DImode);
> -
> - /* Juggle modes to get us in to a vector mode for BSL. */
> - rtx op1 = lowpart_subreg (V2SFmode, operands[1], SFmode);
> - rtx op2 = lowpart_subreg (V2SFmode, operands[2], SFmode);
> - rtx tmp = gen_reg_rtx (V2SFmode);
> - emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 31));
> - emit_insn (gen_aarch64_simd_bslv2sf (tmp, mask, op2, op1));
> - emit_move_insn (operands[0], lowpart_subreg (SFmode, tmp, V2SFmode));
> - DONE;
> -}
> + "@
> + bsl\\t%0., %2., %1.
> + bit\\t%0., %2., %3.
> + bif\\t%0., %1., %3.
> + bfxil\\t%0, %1, #0, "
> + [(set_attr "type" "neon_bsl,neon_bsl,neon_bsl,bfm")]
> )
>
> ;; ---
> diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
> index
>
Re: [PATCH][GCC-8][AArch64] PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-8)
On 29/04/2019 17:56, Srinath Parvathaneni wrote:
> Hi All,
>
> This patch is to fix the ICE caused in expand pattern of copysignf
> builtin. This is a back port to r267019 of trunk.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on
> aarch64-none-elf.
>
> Ok for gcc 8 branch? If ok, could someone commit the patch on my behalf,
> I don't have commit rights.
Applied.
R.
>
> *** gcc/ChangeLog ***
>
> 2019-04-29 Srinath Parvathaneni
>
> Backport from mainline
> 2018-12-11 Richard Earnshaw
>
> PR target/37369
> * config/aarch64/iterators.md (sizem1): Add sizes for
> SFmode and DFmode.
> (Vbtype): Add SFmode mapping.
> * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete.
> (copysign3): New expand pattern.
> (copysign3_insn): New insn pattern.
>
> *** gcc/testsuite/ChangeLog ***
>
> 2019-04-29 Srinath Parvathaneni
>
> PR target/90075
> * gcc.target/aarch64/pr90075.c: New test.
>
>
>
> rb0.patch
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> 32a0e1f3685746b9a7d70239745586d0f0fa7ee1..11c0ef00dcfd5fc41a0eb93c8d5b5bda8a6e6885
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -189,6 +189,7 @@
> UNSPEC_CLASTB
> UNSPEC_FADDA
> UNSPEC_REV_SUBREG
> +UNSPEC_COPYSIGN
> ])
>
> (define_c_enum "unspecv" [
> @@ -5427,49 +5428,48 @@
> ;; LDR d2, #(1 << 63)
> ;; BSL v2.8b, [y], [x]
> ;;
> -;; or another, equivalent, sequence using one of BSL/BIT/BIF.
> -;; aarch64_simd_bsldf will select the best suited of these instructions
> -;; to generate based on register allocation, and knows how to partially
> -;; constant fold based on the values of X and Y, so expand through that.
> -
> -(define_expand "copysigndf3"
> - [(match_operand:DF 0 "register_operand")
> - (match_operand:DF 1 "register_operand")
> - (match_operand:DF 2 "register_operand")]
> +;; or another, equivalent, sequence using one of BSL/BIT/BIF. Because
> +;; we expect these operations to nearly always operate on
> +;; floating-point values, we do not want the operation to be
> +;; simplified into a bit-field insert operation that operates on the
> +;; integer side, since typically that would involve three inter-bank
> +;; register copies. As we do not expect copysign to be followed by
> +;; other logical operations on the result, it seems preferable to keep
> +;; this as an unspec operation, rather than exposing the underlying
> +;; logic to the compiler.
> +
> +(define_expand "copysign3"
> + [(match_operand:GPF 0 "register_operand")
> + (match_operand:GPF 1 "register_operand")
> + (match_operand:GPF 2 "register_operand")]
>"TARGET_FLOAT && TARGET_SIMD"
> {
> - rtx mask = gen_reg_rtx (DImode);
> - emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 63));
> - emit_insn (gen_aarch64_simd_bsldf (operands[0], mask,
> - operands[2], operands[1]));
> + rtx bitmask = gen_reg_rtx (mode);
> + emit_move_insn (bitmask, GEN_INT (HOST_WIDE_INT_M1U
> + << (GET_MODE_BITSIZE (mode) - 1)));
> + emit_insn (gen_copysign3_insn (operands[0], operands[1], operands[2],
> +bitmask));
>DONE;
> }
> )
>
> -;; As above, but we must first get to a 64-bit value if we wish to use
> -;; aarch64_simd_bslv2sf.
> -
> -(define_expand "copysignsf3"
> - [(match_operand:SF 0 "register_operand")
> - (match_operand:SF 1 "register_operand")
> - (match_operand:SF 2 "register_operand")]
> +(define_insn "copysign3_insn"
> + [(set (match_operand:GPF 0 "register_operand" "=w,w,w,r")
> + (unspec:GPF [(match_operand:GPF 1 "register_operand" "w,0,w,r")
> + (match_operand:GPF 2 "register_operand" "w,w,0,0")
> + (match_operand: 3 "register_operand"
> + "0,w,w,X")]
> + UNSPEC_COPYSIGN))]
>"TARGET_FLOAT && TARGET_SIMD"
> -{
> - rtx v_bitmask = gen_reg_rtx (V2SImode);
> -
> - /* Juggle modes to get us in to a vector mode for BSL. */
> - rtx op1 = lowpart_subreg (DImode, operands[1], SFmode);
> - rtx op2 = lowpart_subreg (V2SFmode, operands[2], SFmode);
> - rtx tmp = gen_reg_rtx (V2SFmode);
> - emit_move_insn (v_bitmask,
> - aarch64_simd_gen_const_vector_dup (V2SImode,
> - HOST_WIDE_INT_M1U << 31));
> - emit_insn (gen_aarch64_simd_bslv2sf (tmp, v_bitmask, op2, op1));
> - emit_move_insn (operands[0], lowpart_subreg (SFmode, tmp, V2SFmode));
> - DONE;
> -}
> + "@
> + bsl\\t%0., %2., %1.
> + bit\\t%0., %2., %3.
> + bif\\t%0., %1., %3.
> + bfxil\\t%0, %1, #0, "
> + [(set_attr "type" "neon_bsl,neon_bsl,neon_bsl,bfm")]
> )
>
> +
> ;; For xorsign (x, y), we want to generate:
> ;;
> ;; LDR d2, #1<<63
> diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
> index
>
Re: [PATCH] Handle __builtin_bswap{16,32,64} in bitwise ccp (PR tree-optimization/89475)
On Sun, Feb 24, 2019 at 03:12:38PM +0100, Richard Biener wrote:
> On February 24, 2019 12:58:05 PM GMT+01:00, Jakub Jelinek
> wrote:
> >Hi!
> >
> >These builtins are perfect candidates for bitwise ccp, the bytes are
> >preserved, just byte-swapped.
> >
> >Noticed this while wondering why we haven't optimized the f9 function
> >in another PR, bswap64 zero extended from 32-bits, later casted to
> >32-bit
> >unsigned int is 0.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC10?
>
> OK.
Rebootstrapped/regtested now and committed to trunk. Thanks.
> >2019-02-23 Jakub Jelinek
> >
> > PR tree-optimization/89475
> > * tree-ssa-ccp.c (evaluate_stmt): Handle BUILT_IN_BSWAP{16,32,64}
> > calls.
> >
> > * gcc.dg/tree-ssa/pr89475.c: New test.
> >
> >--- gcc/tree-ssa-ccp.c.jj2019-01-01 12:37:17.078976247 +0100
> >+++ gcc/tree-ssa-ccp.c 2019-02-23 22:35:23.888343273 +0100
> >@@ -1960,6 +1960,35 @@ evaluate_stmt (gimple *stmt)
> > break;
> > }
> >
> >+case BUILT_IN_BSWAP16:
> >+case BUILT_IN_BSWAP32:
> >+case BUILT_IN_BSWAP64:
> >+ val = get_value_for_expr (gimple_call_arg (stmt, 0), true);
> >+ if (val.lattice_val == UNDEFINED)
> >+break;
> >+ else if (val.lattice_val == CONSTANT
> >+ && val.value
> >+ && TREE_CODE (val.value) == INTEGER_CST)
> >+{
> >+ tree type = TREE_TYPE (gimple_call_lhs (stmt));
> >+ int prec = TYPE_PRECISION (type);
> >+ wide_int wval = wi::to_wide (val.value);
> >+ val.value
> >+= wide_int_to_tree (type,
> >+wide_int::from (wval, prec,
> >+UNSIGNED).bswap ());
> >+ val.mask
> >+= widest_int::from (wide_int::from (val.mask, prec,
> >+UNSIGNED).bswap (),
> >+UNSIGNED);
> >+ if (wi::sext (val.mask, prec) != -1)
> >+break;
> >+}
> >+ val.lattice_val = VARYING;
> >+ val.value = NULL_TREE;
> >+ val.mask = -1;
> >+ break;
> >+
> > default:;
> > }
> > }
> >--- gcc/testsuite/gcc.dg/tree-ssa/pr89475.c.jj 2019-02-23
> >18:58:23.035845645 +0100
> >+++ gcc/testsuite/gcc.dg/tree-ssa/pr89475.c 2019-02-23
> >18:59:38.462607598 +0100
> >@@ -0,0 +1,104 @@
> >+/* PR tree-optimization/89475 */
> >+/* { dg-do compile { target { ilp32 || lp64 } } } */
> >+/* { dg-options "-O2 -fdump-tree-optimized" } */
> >+/* { dg-final { scan-tree-dump-not "link_error " "optimized" } } */
> >+
> >+void link_error (void);
> >+
> >+unsigned short
> >+f0 (unsigned short x)
> >+{
> >+ x &= 0xaa55;
> >+ x = __builtin_bswap16 (x);
> >+ if (x & 0xaa55)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned short
> >+f1 (unsigned short x)
> >+{
> >+ x &= 0x55aa;
> >+ x = __builtin_bswap16 (x);
> >+ if (x & 0x55aa)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned int
> >+f2 (unsigned int x)
> >+{
> >+ x &= 0x55aa5aa5U;
> >+ x = __builtin_bswap32 (x);
> >+ if (x & 0x5aa555aaU)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned long long int
> >+f3 (unsigned long long int x)
> >+{
> >+ x &= 0x55aa5aa544cc2211ULL;
> >+ x = __builtin_bswap64 (x);
> >+ if (x & 0xeedd33bb5aa555aaULL)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned short
> >+f4 (unsigned short x)
> >+{
> >+ x = __builtin_bswap32 (x);
> >+ if (x != 0)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned int
> >+f5 (unsigned int x)
> >+{
> >+ x = __builtin_bswap64 (x);
> >+ if (x != 0)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned short
> >+f6 (unsigned short x)
> >+{
> >+ x |= 0xaa55;
> >+ x = __builtin_bswap16 (x);
> >+ if ((x | 0xaa55) != 0x)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned short
> >+f7 (unsigned short x)
> >+{
> >+ x |= 0x55aa;
> >+ x = __builtin_bswap16 (x);
> >+ if ((x | 0x55aa) != 0x)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned int
> >+f8 (unsigned int x)
> >+{
> >+ x |= 0x55aa5aa5U;
> >+ x = __builtin_bswap32 (x);
> >+ if ((x | 0x5aa555aaU) != 0xU)
> >+link_error ();
> >+ return x;
> >+}
> >+
> >+unsigned long long int
> >+f9 (unsigned long long int x)
> >+{
> >+ x |= 0x55aa5aa544cc2211ULL;
> >+ x = __builtin_bswap64 (x);
> >+ if ((x | 0xeedd33bb5aa555aaULL) != 0xULL)
> >+link_error ();
> >+ return x;
> >+}
Jakub
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 10:54 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 09:36:31AM +0100, Jonathan Wakely wrote:
On 30/04/19 10:28 +0200, Jakub Jelinek wrote:
> On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
> > And here for powerpc 32-bit and s390 32-bit from binaries provided by
> > richi, the former cross-checked from binaries on a recent compile farm
> > bootstrap I've done.
>
> And here is riscv64, cross checked between Debian riscv64 build from 0428
> and Fedora alt riscv64 build from 0328, ok for trunk/9.1?
OK, thanks.
We're still waiting to hear from Rainer if his Solaris tests passed,
so we can commit his patch for the Solaris baselines.
> Note, this is the only port I've touched the baseline_symbols.txt for that
> has fewer GLIBCXX_3.4.26 symbols from the others, in particular compared
> to e.g. x86_64-linux and others, following symbols are missing:
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
> Would that be because of no _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY ?
Yes, but I wonder why it doesn't have _Lock_policyE1 symbols instead
of the _Lock_policyE2 ones.
Answer for that is easy, because gnu.ver doesn't say so:
Doh, of course.
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
Thus, you'd need to replace those _Lock_policyE2 with _Lock_policyE[012].
If we want to do that, we need to do that right now (but not sure how long
would it take to get a confirmation from riscv64, either we'd need to ask
Matthias to do some build, or I'd need to talk to whatever maintainers
Linking this program should verify if the symbols are needed:
#include
int main()
{
for (auto f : std::filesystem::directory_iterator("."))
;
for (auto f : std::filesystem::recursive_directory_iterator("."))
;
}
RISCV64 Fedora alt port has). From what I can see, these _Lock_policyE2
symbols are only exported in GLIBCXX_3.4.26, not earlier symvers.
Right, they're new with the std::filesystem exports.
Note, there are many other _Lock_policyE2 symbols that aren't exported
Yes those other symbols are instantiated but only referenced from
within libstdc++.so.6 and not needed (or even possible to use) for
clients of the lib.
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 09:36:31AM +0100, Jonathan Wakely wrote: > On 30/04/19 10:28 +0200, Jakub Jelinek wrote: > > On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote: > > > And here for powerpc 32-bit and s390 32-bit from binaries provided by > > > richi, the former cross-checked from binaries on a recent compile farm > > > bootstrap I've done. > > > > And here is riscv64, cross checked between Debian riscv64 build from 0428 > > and Fedora alt riscv64 build from 0328, ok for trunk/9.1? > > OK, thanks. > > We're still waiting to hear from Rainer if his Solaris tests passed, > so we can commit his patch for the Solaris baselines. > > > Note, this is the only port I've touched the baseline_symbols.txt for that > > has fewer GLIBCXX_3.4.26 symbols from the others, in particular compared > > to e.g. x86_64-linux and others, following symbols are missing: > > FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 > > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26 > > Would that be because of no _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY ? > > Yes, but I wonder why it doesn't have _Lock_policyE1 symbols instead > of the _Lock_policyE2 ones. Answer for that is easy, because gnu.ver doesn't say so: _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev; _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_; _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_; _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev; _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_; _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev; _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_; _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_; _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev; _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_; Thus, you'd need to replace those _Lock_policyE2 with _Lock_policyE[012]. If we want to do that, we need to do that right now (but not sure how long would it take to get a confirmation from riscv64, either we'd need to ask Matthias to do some build, or I'd need to talk to whatever maintainers RISCV64 Fedora alt port has). From what I can see, these _Lock_policyE2 symbols are only exported in GLIBCXX_3.4.26, not earlier symvers. Note, there are many other _Lock_policyE2 symbols that aren't exported in x86_64-linux libstdc++.so.6 and many other _Lock_policyE1 symbols that aren't exported in riscv64-linux libstdc++.so.6. For reference, here is readelf -Wa libstdc++.so.6.*debug | grep _Lock_policyE from riscv64 debuginfo: $ readelf -Wa libstdc++.so.6.0.26-9.0.1-0.12.0.riscv64.fc31.riscv64.debug | grep _Lock_policyE 840: 0013d642 128 FUNCLOCAL DEFAULT 11 _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EE5resetEv 857: 001333d8 2 FUNCLOCAL DEFAULT 11 _ZNSt23_Sp_counted_ptr_inplaceINSt10filesystem7__cxx1116filesystem_error5_ImplESaIS3_ELN9__gnu_cxx12_Lock_policyE1EED2Ev 859: 001288c0 8 FUNCLOCAL DEFAULT 11 _ZNSt23_Sp_counted_ptr_inplaceINSt10filesystem7__cxx114_DirESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED0Ev 862: 001b0ce824 OBJECT LOCAL DEFAULT 20 _ZTISt23_Sp_counted_ptr_inplaceINSt10filesystem28recursive_directory_iterator10_Dir_stackESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE 867: 0013cee472 FUNCLOCAL DEFAULT 11
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 10:28 +0200, Jakub Jelinek wrote: On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote: And here for powerpc 32-bit and s390 32-bit from binaries provided by richi, the former cross-checked from binaries on a recent compile farm bootstrap I've done. And here is riscv64, cross checked between Debian riscv64 build from 0428 and Fedora alt riscv64 build from 0328, ok for trunk/9.1? OK, thanks. We're still waiting to hear from Rainer if his Solaris tests passed, so we can commit his patch for the Solaris baselines. Note, this is the only port I've touched the baseline_symbols.txt for that has fewer GLIBCXX_3.4.26 symbols from the others, in particular compared to e.g. x86_64-linux and others, following symbols are missing: FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26 Would that be because of no _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY ? Yes, but I wonder why it doesn't have _Lock_policyE1 symbols instead of the _Lock_policyE2 ones. From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit cas using 32 bit one). 2019-04-30 Jakub Jelinek * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj 2019-03-08 09:52:12.761367362 +0100 +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 2019-04-30 09:51:49.819285891 +0200 @@ -338,7 +338,9 @@ FUNC:_ZNKSt10filesystem16filesystem_erro FUNC:_ZNKSt10filesystem16filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem16filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem18directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path12has_filenameEv@@GLIBCXX_3.4.26 @@ -364,7 +366,9 @@ FUNC:_ZNKSt10filesystem7__cxx1116filesys FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1118directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path12has_filenameEv@@GLIBCXX_3.4.26 @@ -1804,6 +1808,7 @@ FUNC:_ZNSt10filesystem18create_directori FUNC:_ZNSt10filesystem18create_directoriesERKNS_4pathERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathE@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathERSt10error_code@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem18directory_iterator9incrementERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC1ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC2ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorppEv@@GLIBCXX_3.4.26 @@ -1815,6 +1820,7 @@ FUNC:_ZNSt10filesystem24create_directory FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_4pathES2_RSt10error_code@@GLIBCXX_3.4.26
[9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote: > And here for powerpc 32-bit and s390 32-bit from binaries provided by > richi, the former cross-checked from binaries on a recent compile farm > bootstrap I've done. And here is riscv64, cross checked between Debian riscv64 build from 0428 and Fedora alt riscv64 build from 0328, ok for trunk/9.1? Note, this is the only port I've touched the baseline_symbols.txt for that has fewer GLIBCXX_3.4.26 symbols from the others, in particular compared to e.g. x86_64-linux and others, following symbols are missing: FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26 Would that be because of no _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY ? >From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit cas using 32 bit one). 2019-04-30 Jakub Jelinek * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj 2019-03-08 09:52:12.761367362 +0100 +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 2019-04-30 09:51:49.819285891 +0200 @@ -338,7 +338,9 @@ FUNC:_ZNKSt10filesystem16filesystem_erro FUNC:_ZNKSt10filesystem16filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem16filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem18directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path12has_filenameEv@@GLIBCXX_3.4.26 @@ -364,7 +366,9 @@ FUNC:_ZNKSt10filesystem7__cxx1116filesys FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1118directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path12has_filenameEv@@GLIBCXX_3.4.26 @@ -1804,6 +1808,7 @@ FUNC:_ZNSt10filesystem18create_directori FUNC:_ZNSt10filesystem18create_directoriesERKNS_4pathERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathE@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathERSt10error_code@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem18directory_iterator9incrementERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC1ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC2ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorppEv@@GLIBCXX_3.4.26 @@ -1815,6 +1820,7 @@ FUNC:_ZNSt10filesystem24create_directory FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_4pathES2_RSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_7__cxx114pathES3_@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_7__cxx114pathES3_RSt10error_code@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem28recursive_directory_iterator25disable_recursion_pendingEv@@GLIBCXX_3.4.26
Re: [GCC 9 RM attention] Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior
Hi Jakub!
On Mon, 29 Apr 2019 12:59:03 +0200, Jakub Jelinek wrote:
> On Mon, Apr 29, 2019 at 12:18:15PM +0200, Thomas Schwinge wrote:
> > I know it's very late in the GCC 9 release process, but I'm still
> > catching up with OpenACC patch review, and just at the end of last week
> > I'd noticed that this commit (trunk r261813):
>
> I'd like to see full patch before considering. The bar at this point for
> anything to gcc-9-branch is very high.
Sure, understood.
I've spent some time thinking about this ABI change, back and forth, and
even produced the obvious patch (to use 'GOACC_FLAG_IF_PRESENT',
'GOACC_FLAG_FINALIZE'; attached for posterity), but in the end I'd like
to withdraw, and keep the current ABI. (..., and I'll instead follow up,
at a later point in time, with some documentation updates and code
restructuring, to make this better understandable/maintainable.)
Grüße
Thomas
From 46913aca5aa2dc24b04bd9012b8506bf767b442e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Mon, 29 Apr 2019 21:25:41 +0200
Subject: [PATCH] [WIP] 'GOACC_FLAG_IF_PRESENT', 'GOACC_FLAG_FINALIZE'
TODO Adjust tree-scanning test cases.
---
gcc/gimplify.c | 47
gcc/omp-expand.c | 22 +++
include/gomp-constants.h | 4
libgomp/oacc-parallel.c | 25 ++---
4 files changed, 29 insertions(+), 69 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e59f38261c36..44399b1af0d0 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -11811,53 +11811,6 @@ gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
ort, TREE_CODE (expr));
gimplify_adjust_omp_clauses (pre_p, NULL, _STANDALONE_CLAUSES (expr),
TREE_CODE (expr));
- if (TREE_CODE (expr) == OACC_UPDATE
- && omp_find_clause (OMP_STANDALONE_CLAUSES (expr),
- OMP_CLAUSE_IF_PRESENT))
-{
- /* The runtime uses GOMP_MAP_{TO,FROM} to denote the if_present
- clause. */
- for (tree c = OMP_STANDALONE_CLAUSES (expr); c; c = OMP_CLAUSE_CHAIN (c))
- if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP)
- switch (OMP_CLAUSE_MAP_KIND (c))
- {
- case GOMP_MAP_FORCE_TO:
- OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_TO);
- break;
- case GOMP_MAP_FORCE_FROM:
- OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_FROM);
- break;
- default:
- break;
- }
-}
- else if (TREE_CODE (expr) == OACC_EXIT_DATA
- && omp_find_clause (OMP_STANDALONE_CLAUSES (expr),
- OMP_CLAUSE_FINALIZE))
-{
- /* Use GOMP_MAP_DELETE/GOMP_MAP_FORCE_FROM to denote that "finalize"
- semantics apply to all mappings of this OpenACC directive. */
- bool finalize_marked = false;
- for (tree c = OMP_STANDALONE_CLAUSES (expr); c; c = OMP_CLAUSE_CHAIN (c))
- if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP)
- switch (OMP_CLAUSE_MAP_KIND (c))
- {
- case GOMP_MAP_FROM:
- OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_FORCE_FROM);
- finalize_marked = true;
- break;
- case GOMP_MAP_RELEASE:
- OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_DELETE);
- finalize_marked = true;
- break;
- default:
- /* Check consistency: libgomp relies on the very first data
- mapping clause being marked, so make sure we did that before
- any other mapping clauses. */
- gcc_assert (finalize_marked);
- break;
- }
-}
stmt = gimple_build_omp_target (NULL, kind, OMP_STANDALONE_CLAUSES (expr));
gimplify_seq_add_stmt (pre_p, stmt);
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 89a3a3232671..53dbadea4c76 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -7542,14 +7542,28 @@ expand_omp_target (struct omp_region *region)
clauses = gimple_omp_target_clauses (entry_stmt);
+ /* By default, no GOACC_FLAGs are set. */
+ int goacc_flags_i = 0;
+
+ if (omp_find_clause (clauses, OMP_CLAUSE_IF_PRESENT))
+{
+ gcc_checking_assert (gimple_omp_target_kind (entry_stmt)
+ == GF_OMP_TARGET_KIND_OACC_UPDATE);
+ goacc_flags_i |= GOACC_FLAG_IF_PRESENT;
+}
+
+ if (omp_find_clause (clauses, OMP_CLAUSE_FINALIZE))
+{
+ gcc_checking_assert (gimple_omp_target_kind (entry_stmt)
+ == GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA);
+ goacc_flags_i |= GOACC_FLAG_FINALIZE;
+}
+
tree device = NULL_TREE;
location_t device_loc = UNKNOWN_LOCATION;
tree goacc_flags = NULL_TREE;
if (is_gimple_omp_oacc (entry_stmt))
-{
- /* By default, no GOACC_FLAGs are set. */
- goacc_flags = integer_zero_node;
-}
+goacc_flags = build_int_cst (integer_type_node, goacc_flags_i);
else
{
c = omp_find_clause (clauses, OMP_CLAUSE_DEVICE);
diff --git a/include/gomp-constants.h b/include/gomp-constants.h
index 8b93634f1b8b..8808c343034e 100644
--- a/include/gomp-constants.h
+++ b/include/gomp-constants.h
@@ -202,6 +202,10 @@ enum gomp_map_kind
/* Force host fallback execution. */
#define GOACC_FLAG_HOST_FALLBACK (1 << 0)
Re: [PATCH][DOC] Define email limit for gcc-patches mailing list.
On 4/29/19 11:27 PM, Eric Gallager wrote: > On 4/29/19, Eric Gallager wrote: >> On 4/29/19, Martin Liška wrote: >>> On 4/26/19 10:31 PM, Bernhard Reutner-Fischer wrote: On 26 April 2019 16:08:19 CEST, Gerald Pfeifer wrote: > On Fri, 26 Apr 2019, Martin Liška wrote: >> The patch clarifies that gcc-patches mailing list allows up to 400kB >> size of an email. > > Thanks, yes. Maybe drop references to gcc-prs while at it as: https://gcc.gnu.org/ml/gcc/2017-05/msg6.html thanks, >>> >>> Good idea. I'm going to move multiple legacy mailing lists to Historical >>> ones. >>> >>> Martin >>> >> >> This would fix bug 89770 if/when you commit it, btw: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770 >> > > Also, while you're at it, it might be worth it to change the tense of > verbs in descriptions of lists moved to the "Historical" section, too. > (i.e. "is" -> "was" etc.) > Thanks for useful comments, I've included all of them (except kB change). Feel free to see current version at https://gcc.gnu.org/lists.html Martin
