[commit] [patch] DW_AT_producer: Ignore -fpreprocessed
On Sat, 17 Jan 2015 07:41:51 +0100, Jakub Jelinek wrote: gcc/ChangeLog * dwarf2out.c (gen_producer_string): Ignore also OPT_fpreprocessed. Ok for trunk, thanks. Checked in: 219797 Jan
[PATCH 0/6] rs6000: More -m32 -mpowerpc64 patches
With this, almost all of the testsuite passes for -m32 -mpowerpc64 as for -m32; of the remaining failures, most are testsuite problems. There also are a few(?) problems remaining that the testsuite does not test for, alas. Tested on powerpc64-linux, -m32,-m32/-mpowerpc64,-m64,-m64/-mlra. Are these okay for mainline? It's still friday, I didn't sleep yet! Segher Segher Boessenkool (6): rs6000: Fix multi-reg return types for -m32 -mpowerpc64 rs6000: Do not allow lo_sum accesses = 4 bytes if unaligned rs6000: Fix SDmode varargs for -m32 -mpowerpc64 rs6000: Fix stack probes for -m32 -mpowerpc64 rs6000: Fix gcc.dg/20020919-1.c for -m32 -mpowerpc64 rs6000: Fix ppc-fpconv-[48].c for -m32 -mpowerpc64 gcc/config/rs6000/rs6000.c | 144 ++-- gcc/config/rs6000/rs6000.md | 7 +- gcc/testsuite/gcc.dg/20020919-1.c | 2 +- gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c | 1 + gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c | 1 + 5 files changed, 90 insertions(+), 65 deletions(-) -- 1.8.1.4
[PATCH 1/6] rs6000: Fix multi-reg return types for -m32 -mpowerpc64
This fixes 135 FAILs.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.c (rs6000_parallel_return): New function.
(rs6000_function_value): Use it. Handle SCmode and TCmode as well,
for TARGET_32BIT TARGET_POWERPC64. Fix another BITS_PER_WORD
snafu.
(rs6000_libcall_value): Use the new function.
---
gcc/config/rs6000/rs6000.c | 105 +++--
1 file changed, 45 insertions(+), 60 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 3926b07..551181b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -31583,6 +31583,29 @@ rs6000_complex_function_value (machine_mode mode)
return gen_rtx_PARALLEL (mode, gen_rtvec (2, r1, r2));
}
+/* Return an rtx describing a return value of MODE as a PARALLEL
+ in N_ELTS registers, each of mode ELT_MODE, starting at REGNO,
+ stride REG_STRIDE. */
+
+static rtx
+rs6000_parallel_return (machine_mode mode,
+ int n_elts, machine_mode elt_mode,
+ unsigned int regno, unsigned int reg_stride)
+{
+ rtx par = gen_rtx_PARALLEL (mode, rtvec_alloc (n_elts));
+
+ int i;
+ for (i = 0; i n_elts; i++)
+{
+ rtx r = gen_rtx_REG (elt_mode, regno);
+ rtx off = GEN_INT (i * GET_MODE_SIZE (elt_mode));
+ XVECEXP (par, 0, i) = gen_rtx_EXPR_LIST (VOIDmode, r, off);
+ regno += reg_stride;
+}
+
+ return par;
+}
+
/* Target hook for TARGET_FUNCTION_VALUE.
On the SPE, both FPs and vectors are returned in r3.
@@ -31618,12 +31641,12 @@ rs6000_function_value (const_tree valtype,
/* Otherwise fall through to standard ABI rules. */
}
+ mode = TYPE_MODE (valtype);
+
/* The ELFv2 ABI returns homogeneous VFP aggregates in registers. */
- if (rs6000_discover_homogeneous_aggregate (TYPE_MODE (valtype), valtype,
-elt_mode, n_elts))
+ if (rs6000_discover_homogeneous_aggregate (mode, valtype, elt_mode,
n_elts))
{
- int first_reg, n_regs, i;
- rtx par;
+ int first_reg, n_regs;
if (SCALAR_FLOAT_MODE_P (elt_mode))
{
@@ -31637,53 +31660,25 @@ rs6000_function_value (const_tree valtype,
n_regs = 1;
}
- par = gen_rtx_PARALLEL (TYPE_MODE (valtype), rtvec_alloc (n_elts));
- for (i = 0; i n_elts; i++)
- {
- rtx r = gen_rtx_REG (elt_mode, first_reg + i * n_regs);
- rtx off = GEN_INT (i * GET_MODE_SIZE (elt_mode));
- XVECEXP (par, 0, i) = gen_rtx_EXPR_LIST (VOIDmode, r, off);
- }
-
- return par;
+ return rs6000_parallel_return (mode, n_elts, elt_mode, first_reg,
n_regs);
}
- if (TARGET_32BIT TARGET_POWERPC64 TYPE_MODE (valtype) == DImode)
-{
- /* Long long return value need be split in -mpowerpc64, 32bit ABI. */
- return gen_rtx_PARALLEL (DImode,
- gen_rtvec (2,
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode, GP_ARG_RETURN),
- const0_rtx),
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode,
- GP_ARG_RETURN + 1),
- GEN_INT (4;
-}
- if (TARGET_32BIT TARGET_POWERPC64 TYPE_MODE (valtype) == DCmode)
-{
- return gen_rtx_PARALLEL (DCmode,
- gen_rtvec (4,
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode, GP_ARG_RETURN),
- const0_rtx),
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode,
- GP_ARG_RETURN + 1),
- GEN_INT (4)),
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode,
- GP_ARG_RETURN + 2),
- GEN_INT (8)),
- gen_rtx_EXPR_LIST (VOIDmode,
- gen_rtx_REG (SImode,
- GP_ARG_RETURN + 3),
- GEN_INT (12;
-}
+ /* Some return value types need be split in -mpowerpc64, 32bit ABI. */
+ if (TARGET_32BIT TARGET_POWERPC64)
+switch (mode)
+ {
+ default:
+ break;
+ case DImode:
+ case SCmode:
+ case DCmode:
+ case TCmode:
+ int count = GET_MODE_SIZE (mode) / 4;
+ return rs6000_parallel_return (mode, count, SImode, GP_ARG_RETURN, 1);
+ }
- mode = TYPE_MODE (valtype);
- if ((INTEGRAL_TYPE_P (valtype) GET_MODE_BITSIZE (mode) BITS_PER_WORD)
+ if ((INTEGRAL_TYPE_P (valtype)
+GET_MODE_BITSIZE (mode) (TARGET_32BIT ? 32 : 64))
||
[PATCH 2/6] rs6000: Do not allow lo_sum accesses = 4 bytes if unaligned
This fixes 29 FAILs.
The ld, lwa etc. insns do not encode the low two bits of the offset in
the opcode; those have to be zero. For -m64 this seemed to never matter,
datums are always aligned; but for -m32 -mpowerpc64 you can get symbols
that are not sufficiently aligned. So check for that.
[ Hrm, I think this triggers for lwz as well? I'll investigate. ]
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.c (lo_sum_symbol_misaligned_p): New function.
(legitimate_lo_sum_address_p): Use it for TARGET_POWERPC64.
---
gcc/config/rs6000/rs6000.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 551181b..53bee13 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -6735,6 +6735,39 @@ macho_lo_sum_memory_operand (rtx x, machine_mode mode)
return CONSTANT_P (x);
}
+/* Return true if X (which is the second operand of a LO_SUM) is a symbol
+ that is not sufficiently aligned for a DS-form instruction. */
+static bool
+lo_sum_symbol_misaligned_p (rtx x)
+{
+ if (GET_CODE (x) == CONST)
+x = XEXP (x, 0);
+
+ if (GET_CODE (x) == PLUS)
+x = XEXP (x, 0);
+
+ if (GET_CODE (x) != SYMBOL_REF)
+return false;
+
+ tree decl = SYMBOL_REF_DECL (x);
+ if (decl)
+return DECL_ALIGN_UNIT (decl) 4;
+
+ if (SYMBOL_REF_HAS_BLOCK_INFO_P (x)
+ SYMBOL_REF_ANCHOR_P (x))
+{
+ struct object_block *block = SYMBOL_REF_BLOCK (x);
+ if (block)
+ return block-alignment 32;
+}
+
+ if (CONSTANT_POOL_ADDRESS_P (x))
+return GET_MODE_ALIGNMENT (get_pool_mode (x)) 32;
+
+ /* Assume it's okay otherwise. */
+ return false;
+}
+
static bool
legitimate_lo_sum_address_p (machine_mode mode, rtx x, int strict)
{
@@ -6774,6 +6807,10 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
int strict)
TARGET_HARD_FLOAT TARGET_FPRS TARGET_DOUBLE_FLOAT
(mode == DFmode || mode == DDmode)))
return false;
+ if (TARGET_POWERPC64
+ GET_MODE_SIZE (mode) = 4
+ lo_sum_symbol_misaligned_p (x))
+ return false;
return CONSTANT_P (x) || large_toc_ok;
}
--
1.8.1.4
[PATCH 5/6] rs6000: Fix gcc.dg/20020919-1.c for -m32 -mpowerpc64
long long takes one register exactly when TARGET_POWERPC64, which is _ARCH_PPC64 in preprocessor macros; not just for 64-bit ABIs. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/testsuite/ * gcc.dg/20020919-1.c: Use _ARCH_PPC64 to test for -mpowerpc64. --- gcc/testsuite/gcc.dg/20020919-1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/20020919-1.c b/gcc/testsuite/gcc.dg/20020919-1.c index dfb0721..40f2e6c 100644 --- a/gcc/testsuite/gcc.dg/20020919-1.c +++ b/gcc/testsuite/gcc.dg/20020919-1.c @@ -42,7 +42,7 @@ || defined (__ppc) # define REG1 6 # define REG2 7 -# if !defined(__powerpc64__) !defined(__LP64__) +# if !defined(_ARCH_PPC64) # define REG3 8 # define REG4 9 # endif -- 1.8.1.4
[PATCH 3/6] rs6000: Fix SDmode varargs for -m32 -mpowerpc64
This fixes 26 FAILs. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use TARGET_32BIT to test for 32-bit ABIs, not !TARGET_POWERPC64. --- gcc/config/rs6000/rs6000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 53bee13..4807ad6 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -11508,7 +11508,7 @@ rs6000_gimplify_va_arg (tree valist, tree type, gimple_seq *pre_p, /* _Decimal32 varargs are located in the second word of the 64-bit FP register for 32-bit binaries. */ - if (!TARGET_POWERPC64 + if (TARGET_32BIT TARGET_HARD_FLOAT TARGET_FPRS TYPE_MODE (type) == SDmode) t = fold_build_pointer_plus_hwi (t, size); -- 1.8.1.4
[PATCH 6/6] rs6000: Fix ppc-fpconv-[48].c for -m32 -mpowerpc64
These tests test that no 64-bit etc. insns are used when the compiler
options say they should not be used. But -mpowerpc64 says that they
_should_ be used. So skip the tests in that case.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/testsuite/
* gcc.target/powerpc/ppc-fpconv-4.c: Skip for -mpowerpc64.
* gcc.target/powerpc/ppc-fpconv-8.c: Ditto.
---
gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c | 1 +
gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c
b/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c
index dc1f710..562e672 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-4.c
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if { powerpc*-*-darwin* } { * } { } } */
/* { dg-require-effective-target ilp32 } */
+/* { dg-skip-if { powerpc*-*-* } { -mpowerpc64 } } */
/* { dg-skip-if do not override -mcpu { powerpc*-*-* } { -mcpu=* } {
-mcpu=750 } } */
/* { dg-options -O2 -mcpu=750 -ffast-math } */
/* { dg-final { scan-assembler-not lfiwax } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c
b/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c
index 5f1bb23..0daf573 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-fpconv-8.c
@@ -1,6 +1,7 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* { dg-skip-if { powerpc*-*-darwin* } { * } { } } */
/* { dg-require-effective-target ilp32 } */
+/* { dg-skip-if { powerpc*-*-* } { -mpowerpc64 } } */
/* { dg-require-effective-target powerpc_fprs } */
/* { dg-skip-if do not override -mcpu { powerpc*-*-* } { -mcpu=* } {
-mcpu=750 } } */
/* { dg-options -O3 -mcpu=750 -ffast-math } */
--
1.8.1.4
[PATCH 4/6] rs6000: Fix stack probes for -m32 -mpowerpc64
This fixes 3 FAILs.
The generic emit_stack_probe (that is used for probe_stack patterns) uses
word_mode, which won't fly for -m32 -mpowerpc64. Use probe_stack_address
instead, and create the MEM by hand.
2015-01-16 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.md (probe_stack): Delete.
(probe_stack_address): New.
---
gcc/config/rs6000/rs6000.md | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index a97cc1d..570d28f 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -11691,11 +11691,13 @@ (define_insn blockage
)
-(define_expand probe_stack
- [(set (match_operand 0 memory_operand =m)
-(unspec [(const_int 0)] UNSPEC_PROBE_STACK))]
+(define_expand probe_stack_address
+ [(use (match_operand 0 address_operand))]
{
+ operands[0] = gen_rtx_MEM (Pmode, operands[0]);
+ MEM_VOLATILE_P (operands[0]) = 1;
+
if (TARGET_64BIT)
emit_insn (gen_probe_stack_di (operands[0]));
else
--
1.8.1.4
---
gcc/config/rs6000/rs6000.md | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index a97cc1d..570d28f 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -11691,11 +11691,12 @@ (define_insn blockage
)
-(define_expand probe_stack
- [(set (match_operand 0 memory_operand =m)
-(unspec [(const_int 0)] UNSPEC_PROBE_STACK))]
+(define_expand probe_stack_address
+ [(use (match_operand 0 address_operand))]
{
+ operands[0] = gen_rtx_MEM (Pmode, operands[0]);
+
if (TARGET_64BIT)
emit_insn (gen_probe_stack_di (operands[0]));
else
--
1.8.1.4
Re: Fix a MinGW warning in libiberty/strerror.c
Date: Fri, 16 Jan 2015 16:39:20 -0500 From: DJ Delorie d...@redhat.com CC: ktiet...@googlemail.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org Thanks. Do I need to hear from someone else approving this, or can I go ahead and commit? Go ahead and commit. Thanks. Last-minute thought, in case I'm confused: you mean commit to the sourceware Git repo, right? If not, where?
Re: [PATCH, autofdo] Some code cleanup
Hi, I updated the patch adding one ChangeLog entry. OK for the trunk? Thanks. Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 219297) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,12 @@ +2015-01-17 Felix Yang felix.y...@huawei.com + + * auto-profile.c (afdo_find_equiv_class): Remove unnecessary code. + (autofdo_source_profile::get_callsite_total_count, + function_instance::get_function_instance_by_decl, + string_table::get_index, string_table::get_index_by_decl, + afdo_vpt_for_early_inline, afdo_callsite_hot_enough_for_early_inline): + Fix comment typos and formatting. + 2015-01-06 Sandra Loosemore san...@codesourcery.com * doc/invoke.texi (RS/6000 and PowerPC Options): Tidy formatting Index: gcc/auto-profile.c === --- gcc/auto-profile.c (revision 219297) +++ gcc/auto-profile.c (working copy) @@ -96,7 +96,7 @@ along with GCC; see the file COPYING3. If not see standalone symbol, or a clone of a function that is inlined into another function. - Phase 2: Early inline + valur profile transformation. + Phase 2: Early inline + value profile transformation. Early inline uses autofdo_source_profile to find if a callsite is: * inlined in the profiled binary. * callee body is hot in the profiling run. @@ -361,7 +361,7 @@ get_original_name (const char *name) /* Return the combined location, which is a 32bit integer in which higher 16 bits stores the line offset of LOC to the start lineno - of DECL, The lower 16 bits stores the discrimnator. */ + of DECL, The lower 16 bits stores the discriminator. */ static unsigned get_combined_location (location_t loc, tree decl) @@ -424,7 +424,7 @@ get_inline_stack (location_t locus, inline_stack * /* Return STMT's combined location, which is a 32bit integer in which higher 16 bits stores the line offset of LOC to the start lineno - of DECL, The lower 16 bits stores the discrimnator. */ + of DECL, The lower 16 bits stores the discriminator. */ static unsigned get_relative_location_for_stmt (gimple stmt) @@ -481,8 +481,8 @@ string_table::get_index (const char *name) const string_index_map::const_iterator iter = map_.find (name); if (iter == map_.end ()) return -1; - else -return iter-second; + + return iter-second; } /* Return the index of a given function DECL. Return -1 if DECL is not @@ -502,8 +502,8 @@ string_table::get_index_by_decl (tree decl) const return ret; if (DECL_ABSTRACT_ORIGIN (decl)) return get_index_by_decl (DECL_ABSTRACT_ORIGIN (decl)); - else -return -1; + + return -1; } /* Return the function name of a given INDEX. */ @@ -569,8 +569,8 @@ function_instance::get_function_instance_by_decl ( } if (DECL_ABSTRACT_ORIGIN (decl)) return get_function_instance_by_decl (lineno, DECL_ABSTRACT_ORIGIN (decl)); - else -return NULL; + + return NULL; } /* Store the profile info for LOC in INFO. Return TRUE if profile info @@ -597,7 +597,7 @@ function_instance::mark_annotated (location_t loc) iter-second.annotated = true; } -/* Read the inlinied indirect call target profile for STMT and store it in +/* Read the inlined indirect call target profile for STMT and store it in MAP, return the total count for all inlined indirect calls. */ gcov_type @@ -824,8 +824,8 @@ autofdo_source_profile::get_callsite_total_count ( || afdo_string_table-get_index (IDENTIFIER_POINTER ( DECL_ASSEMBLER_NAME (edge-callee-decl))) != s-name ()) return 0; - else -return s-total_count (); + + return s-total_count (); } /* Read AutoFDO profile and returns TRUE on success. */ @@ -956,9 +956,9 @@ read_profile (void) histograms for indirect-call optimization. This function is actually served for 2 purposes: - * before annotation, we need to mark histogram, promote and inline - * after annotation, we just need to mark, and let follow-up logic to - decide if it needs to promote and inline. */ + * before annotation, we need to mark histogram, promote and inline + * after annotation, we just need to mark, and let follow-up logic to + decide if it needs to promote and inline. */ static void afdo_indirect_call (gimple_stmt_iterator *gsi, const icall_target_map map, @@ -1054,7 +1054,7 @@ set_edge_annotated (edge e, edge_set *annotated) } /* For a given BB, set its execution count. Attach value profile if a stmt - is not in PROMOTED, because we only want to promot an indirect call once. + is not in PROMOTED, because we only want to promote an indirect call once. Return TRUE if BB is annotated. */ static bool @@ -1138,7 +1138,7 @@ afdo_find_equiv_class (bb_set *annotated_bb) bb1-aux = bb; if (bb1-count bb-count is_bb_annotated (bb1,
Re: Use static chain and libffi for Go closures
../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 17 January 2015 at 06:45, Hans-Peter Nilsson h...@bitrange.com wrote: On Fri, 16 Jan 2015, pins...@gmail.com wrote: On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote: This patch has broken bootstrap on AIX May I mention that this really should have been tested on systems other than x86 Linux. It also broke all newlib targets too. So you could have tested one listed in the sim-test web page. For those interested, PR64638. I'll fix it later today if Torvald doesn't beat me to it.
[Patch, fortran] PR55901 - [OOP] type is (character(len=*)) misinterpreted as array - part 1
Dear All, The attached patch fixes the confusion between substrings of character associate-names and scalars being misused as arrays. It is sufficiently obvious and has been tested by Dominique that I will commit it later today if there are no opinions to the contrary. I will now turn my attention to Andre's patches for PR60357 and PR61275. Afterwards, I will fix the rest of the fix for this PR, via Andre's patch for PR60255 and the query in the final message in the thread. Bootstrapped and regtested on x86_64/FC21 - OK for trunk? Cheers Paul 2015-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/55901 * primary.c (gfc_match_varspec): Exclude dangling associate- names with dimension 0 from being counted as arrays. * resolve.c (resolve_assoc_var): Sub-strings are permissible for associate-names, so exclude characters from the test for misuse as arrays. * trans-decl.c (gfc_get_symbol_decl): Associate-names can use the hidden string length variable of their associated target. Signal this by setting 'length' to a constant, if the decl for the string length is a variable. 2015-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/55901 * gfortran.dg/associate_1.f03: Allow test for character with automatic length. -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild ve...@gmx.de wrote:
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over an
oddity:
For a deferred length kind4 char array, the length of the string is stored
without multiplication by 4 in the length variable attached. So when we now
decide to store the length of the string in an unlimited polymorphic entity in
bytes in the component formerly called _len and the size of each character in
_vtype-_size then we have an inconsistency with the style deferred char
lengths are stored. IMHO we should store this consistently, i.e., both
'length'-variables store either the length of the string ('length' =
array_len)
or the size of the memory needed ('length' = array_len * char_size). What do
you think?
Furthermore, think about debugging: When looking at an unlimited polymorphic
entity storing a kind-4-char-array of length 7, then having a 'length'
component
set to 28 will lead to confusion. I humbly predict, that this will produce
many
entries in the bugtracker, because people don't understand that 'length'
stores
the product of elem_size times string_len, because all they see is an
assignment of a length-7 char array.
What do we do about it?
Regards,
Andre
On Thu, 8 Jan 2015 20:56:43 +0100
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the division in evaluating LEN (). I am happy to accept contrary
opinions from the others.
I do not believe that the bind_c issue is an issue. Your patch
correctly deals with it IMHO.
Subject to the above change in the value of _len, I think that your
patch is OK for trunk.
With best regards
Paul
On 4 January 2015 at 13:40, Andre Vehreschild ve...@gmx.de wrote:
Hi Janus, hi Paul, hi Tobias,
Janus: During code review, I found that I had the code in
gfc_get_len_component() duplicated. So I now reintroduced and documented
the
routine making is more commonly usable and added more documentation. The
call sites are now simplify.c (gfc_simplify_len) and trans-expr.c
(gfc_trans_pointer_assignment). Attached is the reworked version of the
patch.
Paul, Tobias: Can one of you have a look at line 253 of the patch? I need
some expertise on the bind_c behavior. My patch needs the check for
is_bind_c added in trans_expr.c (gfc_conv_expr) to prevent mistyping an
associated variable in a select type() during the conv. Background: This
code fragment taken from the testcase in the patch:
MODULE m
contains
subroutine bar (arg, res)
class(*) :: arg
character(100) :: res
select type (w = arg)
type is (character(*))
write (res, '(I2)') len(w)
end select
end subroutine
END MODULE
has the conditions required for line trans-expr.c:6630 of gfc_conv_expr
when
the associate variable w is converted. This transforms the type of the
associate variable to something unexpected in the further processing
leading to some issues during fortraning. Janus told me, that the f90_type
has been abused for some other things (unlimited polymorphic treatment).
Although I believe that reading the comments above the if in question, the
check I had to enhance is treating bind_c stuff (see the threads content
for more). I would feel safer when one of you gfortran gurus can have a
look and given an opinion, whether the change is problematic. I couldn't
figure why w is resolved to meet the criteria (any ideas). Btw, all regtest
are ok reporting no issues at all.
Bootstraps and regtests ok on x86_64-linux-gnu
Regards,
Andre
On Sat, 3 Jan 2015 16:45:07 +0100
Janus Weil ja...@gcc.gnu.org wrote:
Hi Andre,
For the
second one (in gfc_conv_expr), I don't directly see how it's related
to deferred char-len. Why is this change needed?
That change is needed, because in some rare case where an associated
variable in a select type () is used, then the type and f90_type
match the condition while them not really being in a bind_c context.
Therefore I have added the check for bind_c. Btw, I now have removed
the TODO, because that case is covered by the regression tests.
I don't understand how f90_type can be BT_VOID without being in a
BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test
case is the one that triggered this?
This case is triggered by the test-case in the patch, where in the
select
type (w = arg) in module m routine bar the w meets the criteria to make
Re: [PATCH] Install libgcj.pc as libgcj-5.pc rather than libgcj-5.0.pc (PR libgcj/64219)
On Monday 2015-01-12 21:04, Jakub Jelinek wrote: This patch changes the libgcj*.pc installed filename to match the new GCC versioning scheme. Cool, as I said in August https://gcc.gnu.org/ml/gcc/2014-08/msg00250.html and Jeff confirmed in November https://gcc.gnu.org/ml/gcc/2014-11/msg00321.html Thanks, Gerald
Re: [PATCH 3/5] OpenACC 2.0 support for libgomp - outline documentation (repost)
On Saturday 2014-11-15 00:52, Julian Brown wrote:
Thanks -- here's a new version of the patch, which incorporates David
Malcolm's new backronym for libgomp, and edits the above files also.
+@uref{http://www.openacc.org/, OpenACC specification v2.0}, section
By the way, here and in other cases, you do not need the trailing
slash. (For subdirectories it is appropriate, if referring to just
the top level, it is implied by the standard, and it looks nicer
without.)
Also, can you use the actual link only once, for the first reference?
Otherwise if this changes, we'd have to edit lots of links, and that
is rather common practice that way.
-Bugs in the GNU OpenMP implementation should be reported via
-@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}. For all cases, please add
+Bugs in the GNU OpenACC or OpenMP implementation should be reported via
+@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}. For OpenMP cases, please add
openmp to the keywords field in the bug report.
I suggest to actually remove this. It just looks like an extra piece
of redundancy.
Gerald
Re: [PATCH][wwwdocs] Mention -freport-bug in release notes
Hi Yury, On Friday 2015-01-16 12:18, Yury Gribov wrote: This is a wwwdocs patch to changes.html to announce -freport-bug flag. how about the following variation (which I have not committed yet)? Index: changes.html === @@ -514,6 +514,9 @@ h2Other significant improvements/h2 h3 id=gcc-ar/h3 ul +liWhen the new command-line option code-freport-bug/code is + used, GCC automatically generates a developer-friendly reproducer + whenever an internal compiler error is encountered./li liThe codegcc-ar, gcc-nm, gcc-ranlib/code wrappers now understand a code-B/code option to set the compiler to use./li /ul
[wwwdocs] Two editorial changes to gcc-5/changes.html
I must have made this weeks ago, committed now. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.57 diff -u -r1.57 changes.html --- changes.html8 Jan 2015 16:50:23 - 1.57 +++ changes.html17 Jan 2015 11:50:51 - @@ -35,12 +35,12 @@ ul liInter-procedural optimization improvements: ul - liDevirtualization pass was significantly improved by adding + liThe devirtualization pass was significantly improved by adding better support for speculative devirtualization and dynamic type detection. About 50% of virtual calls in Firefox are speculatively devirtualized during link-time optimization./li - liNew comdat localization pass lets linker to eliminate more dead code -in presence of C++ inline functions./li + liA new comdat localization pass allows the linker to eliminate more + dead code in presence of C++ inline functions./li liVirtual tables are now optimized. Local aliases are used to reduce dynamic linking time of C++ virtual tables on ELF targets and data alignment has been reduced to limit data segment bloat./li
Re: RTL cprop vs. fixed hard regs
On January 17, 2015 1:37:12 AM CET, Alan Modra amo...@gmail.com wrote: On Fri, Jan 16, 2015 at 11:03:24AM -0600, Segher Boessenkool wrote: On Fri, Jan 16, 2015 at 08:12:27PM +1030, Alan Modra wrote: OK, so we need to fix this in the rs6000 backend, but it occurs to me that cprop also has a bug here. It shouldn't be touching fixed hard registers. Why not? It cannot allocate a fixed reg to a pseudo, but other than that there is nothing special about fixed regs; the transform is perfectly valid as far as I see. I didn't say that copying to a pseudo and using that was invalid.. The bug I see is a mis-optimisation. Also, the asm operands case that do_local_cprop already rules out changing is very similar to fixed regs. Would you argue that changing asm operands is also valid? :) It isn't a desirable transform in this case, but that is not true for fixed regs in general (just because the stack pointer is live everywhere). What's the point in extending the lifetime of some pseudo when you know the original fixed register is available everywhere? Do you have some concrete example in mind where this optimisation is beneficial? Some ports even include pc in fixed_regs. So there are obvious examples where regs in fixed_regs change behind the compiler's back. Naive users might even expect to see the current value of those regs. (Again, I'm not saying that it is invalid if gcc substituted an older value.) Just to add, we avoid doing this on the GIMPLE level as well. Richard.
Re: [PATCH 3/5] OpenACC 2.0 support for libgomp - outline documentation (repost)
On Sat, Jan 17, 2015 at 12:16:17PM +0100, Gerald Pfeifer wrote:
Also, can you use the actual link only once, for the first reference?
Otherwise if this changes, we'd have to edit lots of links, and that
is rather common practice that way.
-Bugs in the GNU OpenMP implementation should be reported via
-@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}. For all cases, please add
+Bugs in the GNU OpenACC or OpenMP implementation should be reported via
+@uref{http://gcc.gnu.org/bugzilla/, Bugzilla}. For OpenMP cases, please add
openmp to the keywords field in the bug report.
I suggest to actually remove this. It just looks like an extra piece
of redundancy.
The openmp resp. openacc keywords is something I'd like to keep
reminding people to add, openmp keyword is what I use in my OpenMP bugs
queries.
Jakub
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays are accessed. The former uses
pointer arithmetic and the latter array references. I was trying to
avoid divisions by KIND within scalarization loops. Also, I found that
in developing your patch, that allocating with unlimited polymorphic
sources looks neatest when the _len contains the memory size of the
elements of any dynamic type, since a priori it is not known at
compile time whether it is a character or not. Of course, one could
interrogate the _hash field of the vtable, at the expense of more
runtime code.
Cheers
Paul
PS I have your patches for PR60357 and 61275 regtesting right now.
Both look OK to me. At the risk of making potential regressions more
complicated to unravel, to save my time I intend to commit both at
once, unless anybody objects.
On 17 January 2015 at 13:10, Andre Vehreschild ve...@gmx.de wrote:
Hi Paul,
I am open on what to call the new component.
Have you thought about my findings, that for deferred length char arrays the
length is stored in characters and not in bytes, I.e., for a
character(kind=4, Len=:) the length is stored in number of characters and
not in bytes needed, which would be Len*4. IMHO both concepts should be
changed, or none. I favor to keep storing the string length of both concepts
(deferred char arrays and chararrays in unlimited polymorphic entities)
interchangeable w/o computation.
What's your opinion?
Regards, Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas paul.richard.tho...@gmail.com schrieb:
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild ve...@gmx.de wrote:
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over an
oddity:
For a deferred length kind4 char array, the length of the string is stored
without multiplication by 4 in the length variable attached. So when we
now
decide to store the length of the string in an unlimited polymorphic
entity in
bytes in the component formerly called _len and the size of each character
in
_vtype-_size then we have an inconsistency with the style deferred char
lengths are stored. IMHO we should store this consistently, i.e., both
'length'-variables store either the length of the string ('length' =
array_len)
or the size of the memory needed ('length' = array_len * char_size). What
do
you think?
Furthermore, think about debugging: When looking at an unlimited
polymorphic
entity storing a kind-4-char-array of length 7, then having a 'length'
component
set to 28 will lead to confusion. I humbly predict, that this will produce
many
entries in the bugtracker, because people don't understand that 'length'
stores
the product of elem_size times string_len, because all they see is an
assignment of a length-7 char array.
What do we do about it?
Regards,
Andre
On Thu, 8 Jan 2015 20:56:43 +0100
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the division in evaluating LEN (). I am happy to accept contrary
opinions from the others.
I do not believe that the bind_c issue is an issue. Your patch
correctly deals with it IMHO.
Subject to the above change in the value of _len, I think that your
patch is OK for trunk.
With best regards
Paul
On 4 January 2015 at 13:40, Andre Vehreschild ve...@gmx.de wrote:
Hi Janus, hi Paul, hi Tobias,
Janus: During code review, I found that I had the code in
gfc_get_len_component() duplicated. So I now reintroduced and
documented the
routine making is more commonly usable and added more documentation.
The
call sites are now simplify.c (gfc_simplify_len) and trans-expr.c
(gfc_trans_pointer_assignment). Attached is the reworked version of the
patch.
Paul, Tobias: Can one of you have a look at line 253 of the patch? I
need
some expertise on the bind_c behavior. My patch needs the check for
is_bind_c added in trans_expr.c (gfc_conv_expr) to prevent mistyping an
associated variable in a select type() during the conv. Background:
This
code fragment taken from the testcase in the patch:
MODULE m
contains
subroutine bar (arg, res)
class(*) :: arg
character(100) :: res
select type (w = arg)
type is (character(*))
write (res, '(I2)') len(w)
end select
end subroutine
END MODULE
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Cancel that - It should be multiplies by kind, shouldn't it ? :-) OK,
string length it is. We will probably have to set _len = 1 for other
dynamic types, though, so that the pointer arising from an array
reference is base_address + _len*vptr-size*index
Cheers
Paul
On 17 January 2015 at 13:44, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays are accessed. The former uses
pointer arithmetic and the latter array references. I was trying to
avoid divisions by KIND within scalarization loops. Also, I found that
in developing your patch, that allocating with unlimited polymorphic
sources looks neatest when the _len contains the memory size of the
elements of any dynamic type, since a priori it is not known at
compile time whether it is a character or not. Of course, one could
interrogate the _hash field of the vtable, at the expense of more
runtime code.
Cheers
Paul
PS I have your patches for PR60357 and 61275 regtesting right now.
Both look OK to me. At the risk of making potential regressions more
complicated to unravel, to save my time I intend to commit both at
once, unless anybody objects.
On 17 January 2015 at 13:10, Andre Vehreschild ve...@gmx.de wrote:
Hi Paul,
I am open on what to call the new component.
Have you thought about my findings, that for deferred length char arrays the
length is stored in characters and not in bytes, I.e., for a
character(kind=4, Len=:) the length is stored in number of characters and
not in bytes needed, which would be Len*4. IMHO both concepts should be
changed, or none. I favor to keep storing the string length of both concepts
(deferred char arrays and chararrays in unlimited polymorphic entities)
interchangeable w/o computation.
What's your opinion?
Regards, Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas paul.richard.tho...@gmail.com schrieb:
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild ve...@gmx.de wrote:
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over an
oddity:
For a deferred length kind4 char array, the length of the string is stored
without multiplication by 4 in the length variable attached. So when we
now
decide to store the length of the string in an unlimited polymorphic
entity in
bytes in the component formerly called _len and the size of each character
in
_vtype-_size then we have an inconsistency with the style deferred char
lengths are stored. IMHO we should store this consistently, i.e., both
'length'-variables store either the length of the string ('length' =
array_len)
or the size of the memory needed ('length' = array_len * char_size). What
do
you think?
Furthermore, think about debugging: When looking at an unlimited
polymorphic
entity storing a kind-4-char-array of length 7, then having a 'length'
component
set to 28 will lead to confusion. I humbly predict, that this will produce
many
entries in the bugtracker, because people don't understand that 'length'
stores
the product of elem_size times string_len, because all they see is an
assignment of a length-7 char array.
What do we do about it?
Regards,
Andre
On Thu, 8 Jan 2015 20:56:43 +0100
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the division in evaluating LEN (). I am happy to accept contrary
opinions from the others.
I do not believe that the bind_c issue is an issue. Your patch
correctly deals with it IMHO.
Subject to the above change in the value of _len, I think that your
patch is OK for trunk.
With best regards
Paul
On 4 January 2015 at 13:40, Andre Vehreschild ve...@gmx.de wrote:
Hi Janus, hi Paul, hi Tobias,
Janus: During code review, I found that I had the code in
gfc_get_len_component() duplicated. So I now reintroduced and
documented the
routine making is more commonly usable and added more documentation.
The
call sites are now simplify.c (gfc_simplify_len) and trans-expr.c
(gfc_trans_pointer_assignment). Attached is the reworked version of the
patch.
Paul, Tobias: Can one of you have a look at line 253 of the patch? I
need
some expertise on the bind_c behavior. My patch needs the check for
is_bind_c added in trans_expr.c (gfc_conv_expr) to prevent mistyping an
Re: [gcc] [SH] Introduce treg_set_expr
Oleg Endo oleg.e...@t-online.de wrote: Kaz, could you please test the patch on your sh4-linux setup and report your findings? Even though it's a bit late, I'd like to get this in for GCC 5, if it doesn't break too many things. Looks wrong code problem for tls and atomic constructs. Here is the result of compare_tests for unpatched/patched sh4-unknown-linux-gnu compilers: New tests that FAIL: g++.dg/tls/static-1.C -std=gnu++11 execution test g++.dg/tls/static-1.C -std=gnu++14 execution test g++.dg/tls/static-1.C -std=gnu++98 execution test g++.dg/tls/thread_local-cse.C -std=gnu++11 execution test g++.dg/tls/thread_local-cse.C -std=gnu++14 execution test gcc.dg/atomic/stdatomic-op-1.c -O1 execution test gcc.dg/atomic/stdatomic-op-1.c -O2 execution test gcc.dg/atomic/stdatomic-op-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test gcc.dg/atomic/stdatomic-op-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test gcc.dg/atomic/stdatomic-op-1.c -O3 -fomit-frame-pointer execution test gcc.dg/atomic/stdatomic-op-1.c -O3 -g execution test gcc.dg/atomic/stdatomic-op-1.c -Os execution test gcc.dg/tls/pr24428.c execution test gcc.dg/torture/tls/run-le.c -O1 -fPIC execution test gcc.dg/torture/tls/run-le.c -O1 -fpic execution test gcc.dg/torture/tls/run-le.c -O2 -fPIC execution test gcc.dg/torture/tls/run-le.c -O2 -fpic execution test gcc.dg/torture/tls/run-le.c -O3 -fomit-frame-pointer -fPIC execution test gcc.dg/torture/tls/run-le.c -O3 -fomit-frame-pointer -fpic execution test gcc.dg/torture/tls/run-le.c -O3 -g -fPIC execution test gcc.dg/torture/tls/run-le.c -O3 -g -fpic execution test gcc.dg/torture/tls/run-le.c -Os -fPIC execution test gcc.dg/torture/tls/run-le.c -Os -fpic execution test gcc.dg/torture/tls/thr-init-1.c -O1 execution test gcc.dg/torture/tls/thr-init-1.c -O2 execution test gcc.dg/torture/tls/thr-init-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test gcc.dg/torture/tls/thr-init-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test gcc.dg/torture/tls/thr-init-1.c -O3 -fomit-frame-pointer execution test gcc.dg/torture/tls/thr-init-1.c -O3 -g execution test gcc.dg/torture/tls/thr-init-1.c -Os execution test gcc.dg/torture/tls/thr-init-2.c -O1 execution test gcc.dg/torture/tls/thr-init-2.c -O2 execution test gcc.dg/torture/tls/thr-init-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test gcc.dg/torture/tls/thr-init-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test gcc.dg/torture/tls/thr-init-2.c -O3 -fomit-frame-pointer execution test gcc.dg/torture/tls/thr-init-2.c -O3 -g execution test gcc.dg/torture/tls/thr-init-2.c -Os execution test gcc.dg/torture/tls/tls-reload-1.c -O1 execution test gcc.dg/torture/tls/tls-test.c -O1 execution test gcc.dg/torture/tls/tls-test.c -O2 execution test gcc.dg/torture/tls/tls-test.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test gcc.dg/torture/tls/tls-test.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test gcc.dg/torture/tls/tls-test.c -O3 -fomit-frame-pointer execution test gcc.dg/torture/tls/tls-test.c -O3 -g execution test gcc.dg/torture/tls/tls-test.c -Os execution test gcc.target/sh/pr51244-4.c scan-assembler-times not 1 libgomp.c/copyin-1.c execution test libgomp.c/copyin-2.c execution test libgomp.fortran/allocatable11.f90 -O1 execution test libgomp.fortran/allocatable11.f90 -O2 execution test libgomp.fortran/allocatable11.f90 -O3 -fomit-frame-pointer execution test libgomp.fortran/allocatable11.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test libgomp.fortran/allocatable11.f90 -O3 -fomit-frame-pointer -funroll-loops execution test libgomp.fortran/allocatable11.f90 -O3 -g execution test libgomp.fortran/allocatable11.f90 -Os execution test libgomp.fortran/allocatable2.f90 -O1 execution test libgomp.fortran/allocatable2.f90 -O2 execution test libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer execution test libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test libgomp.fortran/allocatable2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test libgomp.fortran/allocatable2.f90 -O3 -g execution test libgomp.fortran/allocatable2.f90 -Os execution test libgomp.fortran/allocatable8.f90 -O1 execution test libgomp.fortran/allocatable8.f90 -O2 execution test libgomp.fortran/allocatable8.f90 -O3 -fomit-frame-pointer execution test libgomp.fortran/allocatable8.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test libgomp.fortran/allocatable8.f90 -O3 -fomit-frame-pointer -funroll-loops execution test libgomp.fortran/allocatable8.f90 -O3 -g execution test libgomp.fortran/allocatable8.f90
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been tested on systems
other than x86 Linux.
It also broke all newlib targets too. So you could have tested one listed in
the sim-test web page.
For those interested, PR64638.
Should be fixed in trunk now, by this patch.
commit a0fe2162e3b10f6d35e4ea73bae209081bf2e9c2
Author: Jonathan Wakely jwak...@redhat.com
Date: Sat Jan 17 13:29:17 2015 +
PR libstdc++/64638
* include/bits/atomic_futex.h: Use appropriate config macros for
availability of std::mutex, std::condition and std::chrono.
diff --git a/libstdc++-v3/include/bits/atomic_futex.h b/libstdc++-v3/include/bits/atomic_futex.h
index 9a418d8..2673604 100644
--- a/libstdc++-v3/include/bits/atomic_futex.h
+++ b/libstdc++-v3/include/bits/atomic_futex.h
@@ -48,6 +48,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#if defined(_GLIBCXX_HAS_GTHREADS) defined(_GLIBCXX_USE_C99_STDINT_TR1)
#if defined(_GLIBCXX_HAVE_LINUX_FUTEX)
struct __atomic_futex_unsigned_base
{
@@ -209,7 +210,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
-#else
+#else // !_GLIBCXX_HAVE_LINUX_FUTEX
// If futexes are not available, use a mutex and a condvar to wait.
// Because we access the data only within critical sections, all accesses
@@ -280,7 +281,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
-#endif
+#endif // _GLIBCXX_HAVE_LINUX_FUTEX
+#endif // _GLIBCXX_HAS_GTHREADS _GLIBCXX_USE_C99_STDINT_TR1
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
Re: [PATCH 1/6] rs6000: Fix multi-reg return types for -m32 -mpowerpc64
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 135 FAILs. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (rs6000_parallel_return): New function. (rs6000_function_value): Use it. Handle SCmode and TCmode as well, for TARGET_32BIT TARGET_POWERPC64. Fix another BITS_PER_WORD snafu. (rs6000_libcall_value): Use the new function. Okay. Thanks, David
Re: [PATCH 2/6] rs6000: Do not allow lo_sum accesses = 4 bytes if unaligned
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 29 FAILs. The ld, lwa etc. insns do not encode the low two bits of the offset in the opcode; those have to be zero. For -m64 this seemed to never matter, datums are always aligned; but for -m32 -mpowerpc64 you can get symbols that are not sufficiently aligned. So check for that. [ Hrm, I think this triggers for lwz as well? I'll investigate. ] 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (lo_sum_symbol_misaligned_p): New function. (legitimate_lo_sum_address_p): Use it for TARGET_POWERPC64. Okay. Thanks, David
Re: [PATCH 3/6] rs6000: Fix SDmode varargs for -m32 -mpowerpc64
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 26 FAILs. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (rs6000_gimplify_va_arg): Use TARGET_32BIT to test for 32-bit ABIs, not !TARGET_POWERPC64. Okay. Thanks, David
Re: [PATCH 4/6] rs6000: Fix stack probes for -m32 -mpowerpc64
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 3 FAILs. The generic emit_stack_probe (that is used for probe_stack patterns) uses word_mode, which won't fly for -m32 -mpowerpc64. Use probe_stack_address instead, and create the MEM by hand. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.md (probe_stack): Delete. (probe_stack_address): New. Okay. Thanks, David
Re: [PATCH 5/6] rs6000: Fix gcc.dg/20020919-1.c for -m32 -mpowerpc64
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: long long takes one register exactly when TARGET_POWERPC64, which is _ARCH_PPC64 in preprocessor macros; not just for 64-bit ABIs. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/testsuite/ * gcc.dg/20020919-1.c: Use _ARCH_PPC64 to test for -mpowerpc64. Okay. Thanks, David
Re: [PATCH 6/6] rs6000: Fix ppc-fpconv-[48].c for -m32 -mpowerpc64
On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: These tests test that no 64-bit etc. insns are used when the compiler options say they should not be used. But -mpowerpc64 says that they _should_ be used. So skip the tests in that case. 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/testsuite/ * gcc.target/powerpc/ppc-fpconv-4.c: Skip for -mpowerpc64. * gcc.target/powerpc/ppc-fpconv-8.c: Ditto. Okay. Thanks, David
Re: [PATCH][ARM] FreeBSD arm support, EABI, v2
On Friday 2015-01-09 15:24, Andreas Tobler wrote: Committed. (r219388) Thanks. Can this also go into the GCC 4.9 branch? That is (and will be for a while) the latest release stream and the patch is pretty much isolated to FreeBSD. Gerald
Re: [PATCH, i386] Remove EBX usage from asm code
Hi Evgeny, The patch removes EBX usage from asm code used in libgcc/crtstuff.c It is safe now, but potentially buggy when glibc is rebuild with GCC 5.0 as EBX is not GOT register any more. x86 bootstrap, make check passed. Is it ok? Evgeny 2014-12-28 Evgeny Stupachenko evstu...@gmail.com * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. this patch broke Solaris 10/x86 bootstrap: when building amd64 crtbegin.o, gas complains crtstuff.s: Assembler messages: crtstuff.s:179: Error: invalid instruction suffix for `pop' crtstuff.s:180: Error: incorrect register `%rdx' used with `l' suffix popl%rdx addl$_GLOBAL_OFFSET_TABLE_+[.-.LPR115],%rdx Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Dear Andre,
Don't worry about the lack of a laptop. I am on to it :-)
Paul
On 17 January 2015 at 16:14, Andre Vehreschild ve...@gmx.de wrote:
Dear Paul,
Setting _Len to one by default should be quite simple. When I remember
correctly, then there is only one place where the current code sets it to
zero. Could be in gfc_conv_structure but that is only a guess.
Unfortunately am I on travel 'till Sunday and don't have my laptop with me.
Sorry for that.
Regards,
Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas paul.richard.tho...@gmail.com schrieb:
Cancel that - It should be multiplies by kind, shouldn't it ? :-) OK,
string length it is. We will probably have to set _len = 1 for other
dynamic types, though, so that the pointer arising from an array
reference is base_address + _len*vptr-size*index
Cheers
Paul
On 17 January 2015 at 13:44, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear Andre,
I am open to either - what do the others think?
The reason why I am for differentiating between unlimited_polymorphic
objects and the deferred length character arrays is because of the
difference in the way in which arrays are accessed. The former uses
pointer arithmetic and the latter array references. I was trying to
avoid divisions by KIND within scalarization loops. Also, I found that
in developing your patch, that allocating with unlimited polymorphic
sources looks neatest when the _len contains the memory size of the
elements of any dynamic type, since a priori it is not known at
compile time whether it is a character or not. Of course, one could
interrogate the _hash field of the vtable, at the expense of more
runtime code.
Cheers
Paul
PS I have your patches for PR60357 and 61275 regtesting right now.
Both look OK to me. At the risk of making potential regressions more
complicated to unravel, to save my time I intend to commit both at
once, unless anybody objects.
On 17 January 2015 at 13:10, Andre Vehreschild ve...@gmx.de wrote:
Hi Paul,
I am open on what to call the new component.
Have you thought about my findings, that for deferred length char arrays
the
length is stored in characters and not in bytes, I.e., for a
character(kind=4, Len=:) the length is stored in number of characters and
not in bytes needed, which would be Len*4. IMHO both concepts should be
changed, or none. I favor to keep storing the string length of both
concepts
(deferred char arrays and chararrays in unlimited polymorphic entities)
interchangeable w/o computation.
What's your opinion?
Regards, Andre
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel. +49 241.9291018 * ve...@gmx.de
Paul Richard Thomas paul.richard.tho...@gmail.com schrieb:
Dear Andre,
Perhaps, rather than calling the new component _len, we should call it
_mem_size or some such?
Cheers
Paul
On 9 January 2015 at 11:52, Andre Vehreschild ve...@gmx.de wrote:
Hi all, hi Paul,
I started to implement the changes requested below, but I stumbled over
an
oddity:
For a deferred length kind4 char array, the length of the string is
stored
without multiplication by 4 in the length variable attached. So when we
now
decide to store the length of the string in an unlimited polymorphic
entity in
bytes in the component formerly called _len and the size of each
character
in
_vtype-_size then we have an inconsistency with the style deferred char
lengths are stored. IMHO we should store this consistently, i.e., both
'length'-variables store either the length of the string ('length' =
array_len)
or the size of the memory needed ('length' = array_len * char_size).
What
do
you think?
Furthermore, think about debugging: When looking at an unlimited
polymorphic
entity storing a kind-4-char-array of length 7, then having a 'length'
component
set to 28 will lead to confusion. I humbly predict, that this will
produce
many
entries in the bugtracker, because people don't understand that 'length'
stores
the product of elem_size times string_len, because all they see is an
assignment of a length-7 char array.
What do we do about it?
Regards,
Andre
On Thu, 8 Jan 2015 20:56:43 +0100
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
Dear Andre,
Thanks for the patch. As I have said to you, off list, I think that
the _size field in the vtable should contain the kind information and
that the _len field should carry the length of the string in bytes. I
think that it is better to optimise array access this way than to
avoid the division in evaluating LEN (). I am happy to accept contrary
opinions from the others.
I do not believe that the bind_c issue is an issue. Your patch
correctly deals with it IMHO.
Subject to the above change in the value of _len, I think that your
patch is OK for trunk.
With best regards
Paul
On 4 January 2015 at 13:40, Andre Vehreschild
Re: [PATCH, i386] Remove EBX usage from asm code
On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: The patch removes EBX usage from asm code used in libgcc/crtstuff.c It is safe now, but potentially buggy when glibc is rebuild with GCC 5.0 as EBX is not GOT register any more. x86 bootstrap, make check passed. Is it ok? Evgeny 2014-12-28 Evgeny Stupachenko evstu...@gmail.com * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. this patch broke Solaris 10/x86 bootstrap: when building amd64 crtbegin.o, gas complains Looks like config.gcc error for Solaris x86, amd64 target should not include i386/gnu-user.h but i386/gnu-user64.h Uros.
Re: [Fortran, Patch] Fix for PR60357 and possibly also for 55932, 57857 and others
Committed with the patch for PR61275 as revision 219801. Also fixes PR55932 for which a testcase has been added. Will follow with a commit to 4.9 during the week. Cheers Paul On 16 January 2015 at 12:30, Andre Vehreschild ve...@gmx.de wrote: Hi all, please find attached a fix for pr60357. This patch includes work published by Janus Weil in the bug. I have made the extensions to support allocatable scalar components in structure constructors. This patch also addresses allocatable deferred length char arrays in structure constructors, which are now supported. Furthermore is the artificial string-length component set correctly now. I hope I have covered all paths. Please note, that this patch does not fix allocatable deferred length char array components in types that are defined and exported in/from a module. For this bug Tobias Burnus wrote a patch, that will hopefully be published soon. During development I have found several related issues in the bugtracker notably: pr55932 - [F03] ICE for structure constructor with scalar allocatable component pr57959 - [F03] ICE with structure constructor with scalar allocatable comp. pr61275 - Invalid initialization expression for ALLOCATABLE component in structure constructor at (1) I haven't check which ones are covered by the patch, too. I hope for support of Dominique here, who is a valued resource for checking conflicts and suddenly fixed bugs. :-) Would you do that for me Dominique? All comments welcome. Bootstraps and regtests ok on x86_64-linux-gnu. Regards, Andre -- Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Tel.: +49 241 9291018 * Email: ve...@gmx.de -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: Compare-elim pass (was: Re: [PATCH] Fix PR 61225)
(Waking up an old thread with my 2 cents due to being a little behind on reading...) On Sat, 6 Dec 2014, Jakub Jelinek wrote: On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote: That's already what it does though, did you mean the opposite? Or did you mean to write combine instead of compare? The above should read ... that existing RTX *combine* pass be updated ..., thanks for pointing out! Which target actually uses the [(operation) (set (cc) ...)] order in their *.md patterns? Even aarch64 and arm use the [(set (cc) ...) (operation)] order that combine expects, I thought compare-elim was written for those targets? If the vast majority of mds use the order that combine expects, I think it should be easier to adjust compare-elim.c and those few targets that diverge. The current cc-first order happened more of an accidental opinion than an architectural decision as I vaguely recall, when asking. We also have the canonical location of a *cc clobber*, i.e. last in a parallel. For that reason, it then makes sense to have the *cc-setting* last. Changing rebelling ports doesn't solve that inconsistency. So, my vote for canonically declaring the order non-canonical *and* automatically generating/matching both orders. brgds, H-P
Re: [Patch, fortran] PR55901 - [OOP] type is (character(len=*)) misinterpreted as array - part 1
Dear All,
Steve Kargl has pointed out to me that the attachment was a null
attachment. As is well known, these are the Swiss Army knife of
patches and will fix anything. In fact, this patch was already posted
long while since with the PR. However, since I am now in a slightly
more pedestrian mood, I have attached it to this message too :-)
Cheers
Paul
On 17 January 2015 at 11:55, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear All,
The attached patch fixes the confusion between substrings of character
associate-names and scalars being misused as arrays.
It is sufficiently obvious and has been tested by Dominique that I
will commit it later today if there are no opinions to the contrary.
I will now turn my attention to Andre's patches for PR60357 and PR61275.
Afterwards, I will fix the rest of the fix for this PR, via Andre's
patch for PR60255 and the query in the final message in the thread.
Bootstrapped and regtested on x86_64/FC21 - OK for trunk?
Cheers
Paul
2015-01-17 Paul Thomas pa...@gcc.gnu.org
PR fortran/55901
* primary.c (gfc_match_varspec): Exclude dangling associate-
names with dimension 0 from being counted as arrays.
* resolve.c (resolve_assoc_var): Sub-strings are permissible
for associate-names, so exclude characters from the test for
misuse as arrays.
* trans-decl.c (gfc_get_symbol_decl): Associate-names can use
the hidden string length variable of their associated target.
Signal this by setting 'length' to a constant, if the decl for
the string length is a variable.
2015-01-17 Paul Thomas pa...@gcc.gnu.org
PR fortran/55901
* gfortran.dg/associate_1.f03: Allow test for character with
automatic length.
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
Index: gcc/fortran/primary.c
===
*** gcc/fortran/primary.c (revision 216426)
--- gcc/fortran/primary.c (working copy)
*** gfc_match_varspec (gfc_expr *primary, in
*** 1855,1861
Thus if we have one and parentheses follow, we have to assume that it
actually is one for now. The final decision will be made at
resolution time, of course. */
! if (sym-assoc gfc_peek_ascii_char () == '(')
sym-attr.dimension = 1;
if ((equiv_flag gfc_peek_ascii_char () == '(')
--- 1855,1864
Thus if we have one and parentheses follow, we have to assume that it
actually is one for now. The final decision will be made at
resolution time, of course. */
! if (sym-assoc gfc_peek_ascii_char () == '('
!!(sym-assoc-dangling sym-assoc-st
! sym-assoc-st-n.sym
! sym-assoc-st-n.sym-attr.dimension == 0))
sym-attr.dimension = 1;
if ((equiv_flag gfc_peek_ascii_char () == '(')
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 216427)
--- gcc/fortran/resolve.c (working copy)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 7882,7887
--- 7882,7890
/* Finally resolve if this is an array or not. */
if (sym-attr.dimension target-rank == 0)
{
+ /* primary.c makes the assumption that a reference to an associate
+name followed by a left parenthesis is an array reference. */
+ if (sym-ts.type != BT_CHARACTER)
gfc_error (Associate-name '%s' at %L is used as array,
sym-name, sym-declared_at);
sym-attr.dimension = 0;
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 216426)
--- gcc/fortran/trans-decl.c(working copy)
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1435,1441
--- 1435,1448
/* Create string length decl first so that they can be used in the
type declaration. */
if (sym-ts.type == BT_CHARACTER)
+ {
+ if (sym-attr.associate_var
+ sym-ts.u.cl-backend_decl
+ TREE_CODE (sym-ts.u.cl-backend_decl) == VAR_DECL)
+ length = gfc_index_zero_node;
+ else
length = gfc_create_string_length (sym);
+ }
/* Create the decl for the variable. */
decl = build_decl (sym-declared_at.lb-location,
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1497,1502
--- 1504,1511
/* Character variables need special handling. */
gfc_allocate_lang_decl (decl);
+ /* Associate names can use the hidden string length variable
+of their associated target. */
if (TREE_CODE (length) != INTEGER_CST)
{
gfc_finish_var_decl (length, sym);
Index: gcc/testsuite/gfortran.dg/associate_1.f03
Re: Use static chain and libffi for Go closures
On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? r~
Re: Use static chain and libffi for Go closures
Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [PATCH 2/6] rs6000: Do not allow lo_sum accesses = 4 bytes if unaligned
On Sat, Jan 17, 2015 at 09:30:07AM -0500, David Edelsohn wrote: On Sat, Jan 17, 2015 at 3:48 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 29 FAILs. The ld, lwa etc. insns do not encode the low two bits of the offset in the opcode; those have to be zero. For -m64 this seemed to never matter, datums are always aligned; but for -m32 -mpowerpc64 you can get symbols that are not sufficiently aligned. So check for that. [ Hrm, I think this triggers for lwz as well? I'll investigate. ] 2015-01-16 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (lo_sum_symbol_misaligned_p): New function. (legitimate_lo_sum_address_p): Use it for TARGET_POWERPC64. Okay. I'll hold off on this one until it's clear what it does for lwz, and -m64 performance too. It should do absolutely nothing for aligned accesses, so it cannot be all that bad, but I don't want to regress even a tiny little bit so late in the game. -m32 -mpowerpc64 hasn't worked properly for years, this series does not fix everything yet (it doesn't do anything specific to Darwin, too), and this patch fixes a relatively minor issue (not affecting too many programs). Segher
Re: Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
Re: On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote: On Fri, 16 Jan 2015, pins...@gmail.com wrote: On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote: This patch has broken bootstrap on AIX May I mention that this really should have been tested on systems other than x86 Linux. It also broke all newlib targets too. So you could have tested one listed in the sim-test web page. For those interested, PR64638. Should be fixed in trunk now, by this patch. I'm now getting this error in an arm-none-linux-gnueabi cross build: In file included from /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/future:44:0, from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/functexcept.cc:34: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:71:3: error: #error We require lock-free atomic operations on int # error We require lock-free atomic operations on int ^ It used to work a few days ago nothing changed in my build environment except that I did svn up in my gcc source directory -Sandra
Re: Compare-elim pass (was: Re: [PATCH] Fix PR 61225)
On Sat, Jan 17, 2015 at 01:18:44PM -0500, Hans-Peter Nilsson wrote: (Waking up an old thread with my 2 cents due to being a little behind on reading...) On Sat, 6 Dec 2014, Jakub Jelinek wrote: On Sat, Dec 06, 2014 at 09:28:57AM +0100, Uros Bizjak wrote: That's already what it does though, did you mean the opposite? Or did you mean to write combine instead of compare? The above should read ... that existing RTX *combine* pass be updated ..., thanks for pointing out! Which target actually uses the [(operation) (set (cc) ...)] order in their *.md patterns? Even aarch64 and arm use the [(set (cc) ...) (operation)] order that combine expects, I thought compare-elim was written for those targets? If the vast majority of mds use the order that combine expects, I think it should be easier to adjust compare-elim.c and those few targets that diverge. The current cc-first order happened more of an accidental opinion than an architectural decision as I vaguely recall, when asking. We also have the canonical location of a *cc clobber*, i.e. last in a parallel. For that reason, it then makes sense to have the *cc-setting* last. Changing rebelling ports doesn't solve that inconsistency. Clobber is clobber, all clobbers come last, so it has nothing to do if cc set is first or second. Jakub
Re: [PATCH, autofdo] Some code cleanup
Hi, I updated the patch adding one ChangeLog entry. OK for the trunk? Thanks. OK thanks. (for my taste the else before return is OK, but I do not mind either way. Comment updates are definitly welcome) Honza Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 219297) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,12 @@ +2015-01-17 Felix Yang felix.y...@huawei.com + + * auto-profile.c (afdo_find_equiv_class): Remove unnecessary code. + (autofdo_source_profile::get_callsite_total_count, + function_instance::get_function_instance_by_decl, + string_table::get_index, string_table::get_index_by_decl, + afdo_vpt_for_early_inline, afdo_callsite_hot_enough_for_early_inline): + Fix comment typos and formatting. + 2015-01-06 Sandra Loosemore san...@codesourcery.com * doc/invoke.texi (RS/6000 and PowerPC Options): Tidy formatting Index: gcc/auto-profile.c === --- gcc/auto-profile.c(revision 219297) +++ gcc/auto-profile.c(working copy) @@ -96,7 +96,7 @@ along with GCC; see the file COPYING3. If not see standalone symbol, or a clone of a function that is inlined into another function. - Phase 2: Early inline + valur profile transformation. + Phase 2: Early inline + value profile transformation. Early inline uses autofdo_source_profile to find if a callsite is: * inlined in the profiled binary. * callee body is hot in the profiling run. @@ -361,7 +361,7 @@ get_original_name (const char *name) /* Return the combined location, which is a 32bit integer in which higher 16 bits stores the line offset of LOC to the start lineno - of DECL, The lower 16 bits stores the discrimnator. */ + of DECL, The lower 16 bits stores the discriminator. */ static unsigned get_combined_location (location_t loc, tree decl) @@ -424,7 +424,7 @@ get_inline_stack (location_t locus, inline_stack * /* Return STMT's combined location, which is a 32bit integer in which higher 16 bits stores the line offset of LOC to the start lineno - of DECL, The lower 16 bits stores the discrimnator. */ + of DECL, The lower 16 bits stores the discriminator. */ static unsigned get_relative_location_for_stmt (gimple stmt) @@ -481,8 +481,8 @@ string_table::get_index (const char *name) const string_index_map::const_iterator iter = map_.find (name); if (iter == map_.end ()) return -1; - else -return iter-second; + + return iter-second; } /* Return the index of a given function DECL. Return -1 if DECL is not @@ -502,8 +502,8 @@ string_table::get_index_by_decl (tree decl) const return ret; if (DECL_ABSTRACT_ORIGIN (decl)) return get_index_by_decl (DECL_ABSTRACT_ORIGIN (decl)); - else -return -1; + + return -1; } /* Return the function name of a given INDEX. */ @@ -569,8 +569,8 @@ function_instance::get_function_instance_by_decl ( } if (DECL_ABSTRACT_ORIGIN (decl)) return get_function_instance_by_decl (lineno, DECL_ABSTRACT_ORIGIN (decl)); - else -return NULL; + + return NULL; } /* Store the profile info for LOC in INFO. Return TRUE if profile info @@ -597,7 +597,7 @@ function_instance::mark_annotated (location_t loc) iter-second.annotated = true; } -/* Read the inlinied indirect call target profile for STMT and store it in +/* Read the inlined indirect call target profile for STMT and store it in MAP, return the total count for all inlined indirect calls. */ gcov_type @@ -824,8 +824,8 @@ autofdo_source_profile::get_callsite_total_count ( || afdo_string_table-get_index (IDENTIFIER_POINTER ( DECL_ASSEMBLER_NAME (edge-callee-decl))) != s-name ()) return 0; - else -return s-total_count (); + + return s-total_count (); } /* Read AutoFDO profile and returns TRUE on success. */ @@ -956,9 +956,9 @@ read_profile (void) histograms for indirect-call optimization. This function is actually served for 2 purposes: - * before annotation, we need to mark histogram, promote and inline - * after annotation, we just need to mark, and let follow-up logic to - decide if it needs to promote and inline. */ + * before annotation, we need to mark histogram, promote and inline + * after annotation, we just need to mark, and let follow-up logic to + decide if it needs to promote and inline. */ static void afdo_indirect_call (gimple_stmt_iterator *gsi, const icall_target_map map, @@ -1054,7 +1054,7 @@ set_edge_annotated (edge e, edge_set *annotated) } /* For a given BB, set its execution count. Attach value profile if a stmt - is not in PROMOTED, because we only want to promot an indirect call once. + is not in PROMOTED, because we
Re: Use static chain and libffi for Go closures
On 01/17/2015 11:07 AM, Andreas Schwab wrote: Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Because I don't see that error here, obviously. r~
Re: Use static chain and libffi for Go closures
On 01/17/2015 02:07 PM, Andrew Pinski wrote: On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote: Andrew Pinski pins...@gmail.com writes: On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote: On 01/17/2015 11:07 AM, Andreas Schwab wrote: Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Because I don't see that error here, obviously. It fails for me with mips64-linux-gnu. It fails almost everywhere. Well it is working for aarch64-linux-gnu and x86_64-linux-gnu (the two other targets I care about). I tested non-support of libffi go closures before applying the patches for them for ppc, but I guess I busted something in the meantime. Please try this. r~ diff --git a/libgo/go/reflect/makefunc_ffi_c.c b/libgo/go/reflect/makefunc_ffi_c.c index 727ae81..e708c93 100644 --- a/libgo/go/reflect/makefunc_ffi_c.c +++ b/libgo/go/reflect/makefunc_ffi_c.c @@ -5,17 +5,12 @@ #include runtime.h #include go-type.h #include go-panic.h - -#ifdef USE_LIBFFI - #include go-ffi.h -#if FFI_GO_CLOSURES +#if defined(USE_LIBFFI) defined(FFI_GO_CLOSURES) #define USE_LIBFFI_CLOSURES #endif -#endif /* defined(USE_LIBFFI) */ - /* Declare C functions with the names used to call from Go. */ void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) diff --git a/libgo/runtime/go-ffi.h b/libgo/runtime/go-ffi.h index afae4b6..a69da26 100644 --- a/libgo/runtime/go-ffi.h +++ b/libgo/runtime/go-ffi.h @@ -6,11 +6,8 @@ #include config.h #include go-type.h - -#ifdef USE_LIBFFI - #include ffi.h +#ifdef USE_LIBFFI void __go_func_to_cif (const struct __go_func_type *, _Bool, _Bool, ffi_cif *); - #endif
Re: Use static chain and libffi for Go closures
On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor i...@golang.org wrote:
You should also revert alpha specific change to
libgo/go/testing/quick/quick_test.go, please see [1] and [2].
[1] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038.html
[2] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038/foo.patch
Done like so. Committed to mainline.
Thanks!
There is another part in runtime/go-ffi.c that looks like it is not
necessary anymore with FFI_TARGET_HAS_COMPLEX_TYPE.
Attached proto-patch that removes special Complex64 handling survives
go regression test for i686 target. However, some of i686 targets
don't define FFI_TARGET_HAS_COMPLEX_TYPE, so at least this part should
be conditional on !ifndef FFI_TARGET_HAS_COMPLEX_TYPE.
Uros.
Index: libgo/runtime/go-ffi.c
===
--- libgo/runtime/go-ffi.c (revision 219797)
+++ libgo/runtime/go-ffi.c (working copy)
@@ -289,22 +289,8 @@ go_func_return_ffi (const struct __go_func_type *f
types = (const struct __go_type_descriptor **) func-__out.__values;
if (count == 1)
-{
+return go_type_to_ffi (types[0]);
-#if defined (__i386__) !defined (__x86_64__)
- /* FFI does not support complex types. On 32-bit x86, a
-complex64 will be returned in %eax/%edx. We normally tell
-FFI that a complex64 is a struct of two floats. On 32-bit
-x86 a struct of two floats is returned via a hidden first
-pointer parameter. Fortunately we can make everything work
-by pretending that complex64 is int64. */
- if ((types[0]-__code GO_CODE_MASK) == GO_COMPLEX64)
- return ffi_type_sint64;
-#endif
-
- return go_type_to_ffi (types[0]);
-}
-
ret = (ffi_type *) __go_alloc (sizeof (ffi_type));
ret-type = FFI_TYPE_STRUCT;
ret-elements = (ffi_type **) __go_alloc ((count + 1) * sizeof (ffi_type *));
Re: [PATCH, i386] Remove EBX usage from asm code
Uros Bizjak ubiz...@gmail.com writes: On Sat, Jan 17, 2015 at 4:18 PM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: The patch removes EBX usage from asm code used in libgcc/crtstuff.c It is safe now, but potentially buggy when glibc is rebuild with GCC 5.0 as EBX is not GOT register any more. x86 bootstrap, make check passed. Is it ok? Evgeny 2014-12-28 Evgeny Stupachenko evstu...@gmail.com * gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage. * config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto. this patch broke Solaris 10/x86 bootstrap: when building amd64 crtbegin.o, gas complains Looks like config.gcc error for Solaris x86, amd64 target should not include i386/gnu-user.h but i386/gnu-user64.h The target is i386-pc-solaris2.10, which includes i386/sysv4.h. Only the amd64 crtbegin.o is affected, the i386 one is fine. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Use static chain and libffi for Go closures
Andrew Pinski pins...@gmail.com writes: On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote: On 01/17/2015 11:07 AM, Andreas Schwab wrote: Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Because I don't see that error here, obviously. It fails for me with mips64-linux-gnu. It fails almost everywhere. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Use static chain and libffi for Go closures
On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote: On 01/17/2015 11:07 AM, Andreas Schwab wrote: Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Because I don't see that error here, obviously. It fails for me with mips64-linux-gnu. Thanks, Andrew Pinski r~
Re: Use static chain and libffi for Go closures
On Sat, Jan 17, 2015 at 2:02 PM, Andreas Schwab sch...@linux-m68k.org wrote: Andrew Pinski pins...@gmail.com writes: On Sat, Jan 17, 2015 at 1:26 PM, Richard Henderson r...@redhat.com wrote: On 01/17/2015 11:07 AM, Andreas Schwab wrote: Richard Henderson r...@redhat.com writes: On 01/17/2015 01:52 AM, Andreas Schwab wrote: ../../../libgo/go/reflect/makefunc_ffi_c.c:21:53: error: unknown type name 'ffi_go_closure' void makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ ../../../libgo/go/reflect/makefunc_ffi_c.c:86:48: error: unknown type name 'ffi_go_closure' makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl) ^ make[4]: *** [reflect/makefunc_ffi_c.lo] Error 1 What target? Why does it matter? Because I don't see that error here, obviously. It fails for me with mips64-linux-gnu. It fails almost everywhere. Well it is working for aarch64-linux-gnu and x86_64-linux-gnu (the two other targets I care about). Thanks, Andrew Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 01/17/2015 01:23 PM, Jonathan Wakely wrote: On 17/01/15 12:59 -0700, Sandra Loosemore wrote: Re: On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote: On Fri, 16 Jan 2015, pins...@gmail.com wrote: On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote: This patch has broken bootstrap on AIX May I mention that this really should have been tested on systems other than x86 Linux. It also broke all newlib targets too. So you could have tested one listed in the sim-test web page. For those interested, PR64638. Should be fixed in trunk now, by this patch. I'm now getting this error in an arm-none-linux-gnueabi cross build: In file included from /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/future:44:0, from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/functexcept.cc:34: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:71:3: error: #error We require lock-free atomic operations on int # error We require lock-free atomic operations on int ^ It used to work a few days ago nothing changed in my build environment except that I did svn up in my gcc source directory Well that file didn't exist until yesterday :-) Does the attached patch fix it? The new __atomic_futex_unsigned type is only used in future when ATOMIC_LOCK_FREE 1, so there's no point trying to define it and then failing if int is not lock-free, as the type isn't going to be used anyway. I'm getting a different series of build errors with this patch -- starting with In file included from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5: error: 'mutex' does not name a type mutex _M_mutex; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5: error: 'condition_variable' does not name a type condition_variable _M_condvar; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h: In member function 'unsigned int std::__atomic_futex_unsigned_Waiter_bit::_M_load(std::memory_ order)': /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7: error: 'unique_lock' was not declared in this scope unique_lockmutex __lock(_M_mutex); ^ and going on for several screenfuls. Maybe the patch(es) causing all these problems should be reverted until the breakage is tracked down and fixed and regression-tested on a variety of targets? It's not really blocking me at the moment, but it seems unfortunate that trunk is so unstable as we're entering Stage 4. -Sandra
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 17/01/15 15:22 -0700, Sandra Loosemore wrote: On 01/17/2015 01:23 PM, Jonathan Wakely wrote: On 17/01/15 12:59 -0700, Sandra Loosemore wrote: Re: On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote: On Fri, 16 Jan 2015, pins...@gmail.com wrote: On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote: This patch has broken bootstrap on AIX May I mention that this really should have been tested on systems other than x86 Linux. It also broke all newlib targets too. So you could have tested one listed in the sim-test web page. For those interested, PR64638. Should be fixed in trunk now, by this patch. I'm now getting this error in an arm-none-linux-gnueabi cross build: In file included from /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/future:44:0, from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/functexcept.cc:34: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:71:3: error: #error We require lock-free atomic operations on int # error We require lock-free atomic operations on int ^ It used to work a few days ago nothing changed in my build environment except that I did svn up in my gcc source directory Well that file didn't exist until yesterday :-) Does the attached patch fix it? The new __atomic_futex_unsigned type is only used in future when ATOMIC_LOCK_FREE 1, so there's no point trying to define it and then failing if int is not lock-free, as the type isn't going to be used anyway. I'm getting a different series of build errors with this patch -- starting with In file included from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5: error: 'mutex' does not name a type mutex _M_mutex; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5: error: 'condition_variable' does not name a type condition_variable _M_condvar; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h: In member function 'unsigned int std::__atomic_futex_unsigned_Waiter_bit::_M_load(std::memory_ order)': /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7: error: 'unique_lock' was not declared in this scope unique_lockmutex __lock(_M_mutex); ^ and going on for several screenfuls. Odd, that should already be fixed at rev 219799. Are you still at a revision older than that? Maybe the patch(es) causing all these problems should be reverted until the breakage is tracked down and fixed and regression-tested on a variety of targets? It's not really blocking me at the moment, but it seems unfortunate that trunk is so unstable as we're entering Stage 4.
Re: Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 17/01/15 12:59 -0700, Sandra Loosemore wrote:
Re:
On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote:
On Fri, 16 Jan 2015, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn dje@gmail.com wrote:
This patch has broken bootstrap on AIX
May I mention that this really should have been tested on systems
other than x86 Linux.
It also broke all newlib targets too. So you could have tested one listed in
the sim-test web page.
For those interested, PR64638.
Should be fixed in trunk now, by this patch.
I'm now getting this error in an arm-none-linux-gnueabi cross build:
In file included from
/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/future:44:0,
from
/scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/functexcept.cc:34:
/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:71:3:
error: #error We require lock-free atomic operations on int
# error We require lock-free atomic operations on int
^
It used to work a few days ago nothing changed in my build
environment except that I did svn up in my gcc source directory
Well that file didn't exist until yesterday :-)
Does the attached patch fix it?
The new __atomic_futex_unsigned type is only used in future when
ATOMIC_LOCK_FREE 1, so there's no point trying to define it and
then failing if int is not lock-free, as the type isn't going to be
used anyway.
diff --git a/libstdc++-v3/include/bits/atomic_futex.h b/libstdc++-v3/include/bits/atomic_futex.h
index 2673604..b4138ba 100644
--- a/libstdc++-v3/include/bits/atomic_futex.h
+++ b/libstdc++-v3/include/bits/atomic_futex.h
@@ -49,7 +49,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
_GLIBCXX_BEGIN_NAMESPACE_VERSION
#if defined(_GLIBCXX_HAS_GTHREADS) defined(_GLIBCXX_USE_C99_STDINT_TR1)
-#if defined(_GLIBCXX_HAVE_LINUX_FUTEX)
+#if defined(_GLIBCXX_HAVE_LINUX_FUTEX) ATOMIC_INT_LOCK_FREE 1
struct __atomic_futex_unsigned_base
{
// Returns false iff a timeout occurred.
@@ -66,10 +66,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
typedef chrono::system_clock __clock_t;
-// XXX We expect this to be lock-free, and having the payload at offset 0.
-#if ATOMIC_INT_LOCK_FREE 2
-# error We require lock-free atomic operations on int
-#endif
+// This must be lock-free and at offset 0.
atomicunsigned _M_data;
__atomic_futex_unsigned(unsigned __data) : _M_data(__data)
@@ -281,7 +278,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
-#endif // _GLIBCXX_HAVE_LINUX_FUTEX
+#endif // _GLIBCXX_HAVE_LINUX_FUTEX ATOMIC_INT_LOCK_FREE 1
#endif // _GLIBCXX_HAS_GTHREADS _GLIBCXX_USE_C99_STDINT_TR1
_GLIBCXX_END_NAMESPACE_VERSION
[Patch, fortran] PR64578 - [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function
Applied as 'obvious' in revision 219802.
2015-01-17 Paul Thomas pa...@gcc.gnu.org
PR fortran/64578
* trans-expr.c (gfc_trans_pointer_assignment): Make sure that
before reinitializing rse, to add the rse.pre to block before
creating 'ptrtemp'.
* trans-intrinsic.c (gfc_conv_associated): Deal with the class
data being a descriptor.
2015-01-17 Paul Thomas pa...@gcc.gnu.org
PR fortran/64578
* gfortran.dg/unlimited_polymorphic_21.f90: New test
Cheers
Paul
--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.
Groucho Marx
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 219801)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_trans_pointer_assignment (gfc_expr *
*** 7075,7080
--- 7075,7081
rse.expr = gfc_class_data_get (rse.expr);
else
{
+ gfc_add_block_to_block (block, rse.pre);
tmp = gfc_create_var (TREE_TYPE (rse.expr), ptrtemp);
gfc_add_modify (lse.pre, tmp, rse.expr);
*** gfc_trans_pointer_assignment (gfc_expr *
*** 7146,7151
--- 7147,7153
}
else
{
+ gfc_add_block_to_block (block, rse.pre);
tmp = gfc_create_var (TREE_TYPE (rse.expr), ptrtemp);
gfc_add_modify (lse.pre, tmp, rse.expr);
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 219800)
--- gcc/fortran/trans-intrinsic.c (working copy)
*** gfc_conv_associated (gfc_se *se, gfc_exp
*** 6554,6560
--- 6554,6564
arg1se.expr = build_fold_indirect_ref_loc (input_location,
arg1se.expr);
if (arg1-expr-ts.type == BT_CLASS)
+ {
tmp2 = gfc_class_data_get (arg1se.expr);
+ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (tmp2)))
+ tmp2 = gfc_conv_descriptor_data_get (tmp2);
+ }
else
tmp2 = arg1se.expr;
}
Index: gcc/testsuite/gfortran.dg/unlimited_polymorphic_21.f90
===
*** gcc/testsuite/gfortran.dg/unlimited_polymorphic_21.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_21.f90 (working copy)
***
*** 0
--- 1,35
+ ! { dg-do run }
+ ! Tests the fix for PR64578.
+ !
+ ! Contributed by Damian Rouson dam...@sourceryinstitute.org
+ !
+ type foo
+ real, allocatable :: component(:)
+ end type
+ type (foo), target :: f
+ class(*), pointer :: ptr(:)
+ allocate(f%component(1),source=[0.99])
+ call associate_pointer(f,ptr)
+ select type (ptr)
+ type is (real)
+ if (abs (ptr(1) - 0.99) 1e-5) call abort
+ end select
+ ptr = return_pointer(f) ! runtime segmentation fault
+ if (associated(return_pointer(f)) .neqv. .true.) call abort
+ select type (ptr)
+ type is (real)
+ if (abs (ptr(1) - 0.99) 1e-5) call abort
+ end select
+ contains
+ subroutine associate_pointer(this, item)
+ class(foo), target :: this
+ class(*), pointer :: item(:)
+ item = this%component
+ end subroutine
+ function return_pointer(this)
+ class(foo), target :: this
+ class(*), pointer :: return_pointer(:)
+ return_pointer = this%component
+ end function
+ end
+
[doc, committed] remove duplicate docs for -ftracer
I noticed that there two separate documentation entries for -ftracer in the GCC manual, one of which had an extra sentence but was otherwise identical to the other. This patch removes the copy without the extra sentence; I've checked it in as an obvious fix. -Sandra 2015-01-17 Sandra Loosemore san...@codesourcery.com gcc/ * doc/invoke.texi ([-ftracer]): Remove duplicate option listing. 2015-01-17 Sandra Loosemore san...@codesourcery.com gcc/ * doc/invoke.texi ([-ftracer]): Remove duplicate option listing.
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 01/17/2015 03:36 PM, Jonathan Wakely wrote: On 17/01/15 15:22 -0700, Sandra Loosemore wrote: [snip snip] I'm getting a different series of build errors with this patch -- starting with In file included from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5: error: 'mutex' does not name a type mutex _M_mutex; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5: error: 'condition_variable' does not name a type condition_variable _M_condvar; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h: In member function 'unsigned int std::__atomic_futex_unsigned_Waiter_bit::_M_load(std::memory_ order)': /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7: error: 'unique_lock' was not declared in this scope unique_lockmutex __lock(_M_mutex); ^ and going on for several screenfuls. Odd, that should already be fixed at rev 219799. Are you still at a revision older than that? My source tree is at r219802 now. Maybe the patch(es) causing all these problems should be reverted until the breakage is tracked down and fixed and regression-tested on a variety of targets? It's not really blocking me at the moment, but it seems unfortunate that trunk is so unstable as we're entering Stage 4. -Sandra
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 17/01/15 15:54 -0700, Sandra Loosemore wrote: On 01/17/2015 03:36 PM, Jonathan Wakely wrote: On 17/01/15 15:22 -0700, Sandra Loosemore wrote: [snip snip] I'm getting a different series of build errors with this patch -- starting with In file included from /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0: /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5: error: 'mutex' does not name a type mutex _M_mutex; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5: error: 'condition_variable' does not name a type condition_variable _M_condvar; ^ /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h: In member function 'unsigned int std::__atomic_futex_unsigned_Waiter_bit::_M_load(std::memory_ order)': /scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7: error: 'unique_lock' was not declared in this scope unique_lockmutex __lock(_M_mutex); ^ and going on for several screenfuls. Odd, that should already be fixed at rev 219799. Are you still at a revision older than that? My source tree is at r219802 now. My fault, this additional chunk is needed alongside the patch I sent earlier: --- a/libstdc++-v3/include/bits/atomic_futex.h +++ b/libstdc++-v3/include/bits/atomic_futex.h @@ -35,7 +35,7 @@ #include bits/c++config.h #include atomic #include chrono -#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX) +#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) ATOMIC_INT_LOCK_FREE 1) #include mutex #include condition_variable #endif What I sent earlier causes your target to use std::mutex and std::condition_variable, but without the bit above the headers aren't included. Maybe the patch(es) causing all these problems should be reverted until the breakage is tracked down and fixed and regression-tested on a variety of targets? It's not really blocking me at the moment, but it seems unfortunate that trunk is so unstable as we're entering Stage 4. Torvald, if the extra change above doesn't fix it (although it should do) then maybe it should be reverted until it can be tested more widely.
Re: [RFC] POWER8 default for PPC64LE
Supporting this turned out to be more involved. --with-cpu implicitly adds -mcpu to all specs, which invokes the assembler with the correct option. Directly setting TARGET_DEFAULT does not adjust the assembler invocation. This patch adds support to rs6000_file_start to emit the .machine assembler pseudo-op to inform the assembler of the processor type. For the moment, the .machine pseudo-op is not emitted if --with-cpu or -mcpu= was used because the assembly explicitly is invoked with the processor type. The default is machine ppc64 or ppc. The implementation does not attempt to cover the various embedded processors, but they already were configured explicitly. The machine type only is emitted for ELF files. Darwin already emits the option and I am skipping this on AIX for the moment. The patch also changes the default processor tuning to POWER8 for PPC64 big endian Linux and detects POWER7 on AIX. Thanks, David * config/rs6000/default64.h: Include rs6000-cpus.def. (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7. * config/rs6000/linux64.h: Always default to POWER8. * config/rs6000/rs6000.c (rs6000_file_start): Emit .machine pseudo-op to specify assembler dialect. ZZ Description: Binary data
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely jwak...@redhat.com wrote:
In that case, why bother using a unique_ptr initially, if it will just
have to allocate a shared_ptr control block later anyway? It's better
to use make_shared to reduce the number of allocations, isn't it?
Yes you are right, I didn't notice that shared_ptr_NFA can be
implicitly converted to shared_ptrconst _NFA.
Fixed.
On Fri, Jan 16, 2015 at 4:14 AM, Jonathan Wakely jwak...@redhat.com wrote:
@@ -675,12 +681,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
assign(const basic_string_Ch_type, _Ch_typeraits, _Alloc __s,
flag_type __flags = ECMAScript)
{
+ auto __traits = _M_traits;
+ auto __f = _M_flags;
_M_flags = __flags;
- _M_original_str.assign(__s.begin(), __s.end());
- auto __p = _M_original_str.c_str();
- _M_automaton = __detail::__compile_nfa(__p,
-__p +
_M_original_str.size(),
-_M_traits, _M_flags);
+ _M_traits = __traits;
What is this assignnment for?
Sorry, I didn't notice that _M_traits doesn't change in this function. Fixed.
On Fri, Jan 16, 2015 at 5:39 AM, Jonathan Wakely jwak...@redhat.com wrote:
If std::move on a pointer definitely doesn't pessimize, then I suppose
it's no worse and the move is OK.
I'm not 100% sure of that, but isn't moving a pointer the same as copying?
Also adjusted SFINAE (add _CharT* specialization).
--
Regards,
Tim Shen
commit 866d34c2bbcb4fc72fe7088e550a59a1139fe28c
Author: timshen tims...@google.com
Date: Wed Jan 14 01:35:22 2015 -0800
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (basic_regex::basic_regex,
basic_regex::assign, basic_regex::imbue,
basic_regex::swap, basic_regex::mark_count): Drop NFA after
imbuing basic_regex; Make assign() transactional against exception.
* testsuite/28_regex/basic_regex/assign/char/string.cc: New testcase.
* testsuite/28_regex/basic_regex/imbue/string.cc: New testcase.
diff --git a/libstdc++-v3/include/bits/regex.h
b/libstdc++-v3/include/bits/regex.h
index 3cbec3c..b358c79 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -476,7 +476,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
basic_regex(const basic_regex __rhs)
: _M_flags(__rhs._M_flags), _M_original_str(__rhs._M_original_str)
- { this-imbue(__rhs.getloc()); }
+ {
+ _M_traits.imbue(__rhs.getloc());
+ this-assign(_M_original_str, _M_flags);
+ }
/**
* @brief Move-constructs a basic regular expression.
@@ -490,7 +493,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: _M_flags(__rhs._M_flags),
_M_original_str(std::move(__rhs._M_original_str))
{
- this-imbue(__rhs.getloc());
+ _M_traits.imbue(__rhs.getloc());
+ this-assign(_M_original_str, _M_flags);
__rhs._M_automaton.reset();
}
@@ -604,7 +608,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_M_flags = __rhs._M_flags;
_M_original_str = __rhs._M_original_str;
- this-imbue(__rhs.getloc());
+ _M_traits.imbue(__rhs.getloc());
+ this-assign(_M_original_str, _M_flags);
return *this;
}
@@ -622,7 +627,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_flags = __rhs._M_flags;
_M_original_str = std::move(__rhs._M_original_str);
__rhs._M_automaton.reset();
- this-imbue(__rhs.getloc());
+ _M_traits.imbue(__rhs.getloc());
+ this-assign(_M_original_str, _M_flags);
+ return *this;
}
/**
@@ -675,12 +682,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
assign(const basic_string_Ch_type, _Ch_typeraits, _Alloc __s,
flag_type __flags = ECMAScript)
{
+ _M_automaton = __detail::__compile_nfa(
+ __s.data(), __s.data() + __s.size(), _M_traits, __flags);
+ _M_original_str = __s;
_M_flags = __flags;
- _M_original_str.assign(__s.begin(), __s.end());
- auto __p = _M_original_str.c_str();
- _M_automaton = __detail::__compile_nfa(__p,
-__p + _M_original_str.size(),
-_M_traits, _M_flags);
return *this;
}
@@ -725,7 +730,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
unsigned int
mark_count() const
- { return _M_automaton-_M_sub_count() - 1; }
+ {
+ if (_M_automaton)
+ return _M_automaton-_M_sub_count() - 1;
+ return 0;
+ }
/**
* @brief Gets the flags used to construct the regular expression
@@ -744,9 +753,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
locale_type
imbue(locale_type __loc)
{
- auto __ret = _M_traits.imbue(__loc);
- this-assign(_M_original_str, _M_flags);
-
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen tims...@google.com wrote: I'm not 100% sure of that, but isn't moving a pointer the same as copying? I mean time cost here. By the way, is the rhs pointer still valid or in an unspecified state? -- Regards, Tim Shen
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On 17/01/15 16:08 -0800, Tim Shen wrote: On Sat, Jan 17, 2015 at 4:06 PM, Tim Shen tims...@google.com wrote: I'm not 100% sure of that, but isn't moving a pointer the same as copying? You can't move a pointer, you can only copy it. Rmember all std::move does is cast something to an rvalue reference, whether that actually leads to a move depends on what happens to the object afterwards. Initializing a pointer from another pointer just copies the value and has no way of doing anything different whether the source is an rvalue or an lvalue. I mean time cost here. By the way, is the rhs pointer still valid or in an unspecified state? It won't be changed at all.
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On 17/01/15 16:53 -0800, Tim Shen wrote: Then std::move on a pointer definitely doesn't pessimize is true. Here I read pessimize as less efficient. Well without optimization it certainly is less efficient, because you get calls to std::move (just compare the code for foo and bar at http://goo.gl/lTxgBw), but I'm confident even at -O1 they disappear and its nothing to worry about. Anyway, I'll review your new patches tomorrow - thanks.
[Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.
Thanks!
--
Regards,
Tim Shen
commit e433cdbe4a1b8660fcd452c1a5e08972c495d08f
Author: timshen tims...@google.com
Date: Sat Jan 17 19:34:14 2015 -0800
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits::lookup_collatename,
regex_traits::lookup_classname): Conform forward iterator constrain
for lookup_collatename lookup_classname.
* testsuite/28_regex/traits/char/lookup_classname.cc: New testcases.
* testsuite/28_regex/traits/char/lookup_collatename.cc: New testcase.
diff --git a/libstdc++-v3/include/bits/regex.tcc
b/libstdc++-v3/include/bits/regex.tcc
index 4ea8180..3f16e66 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -267,53 +267,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
right-curly-bracket,
tilde,
DEL,
-
};
- // same as boost
- //static const char* __digraphs[] =
- // {
- //ae,
- //Ae,
- //AE,
- //ch,
- //Ch,
- //CH,
- //ll,
- //Ll,
- //LL,
- //ss,
- //Ss,
- //SS,
- //nj,
- //Nj,
- //NJ,
- //dz,
- //Dz,
- //DZ,
- //lj,
- //Lj,
- //LJ,
- //
- // };
-
- std::string __s(__last - __first, '?');
- __fctyp.narrow(__first, __last, '?', *__s.begin());
-
- for (unsigned int __i = 0; *__collatenames[__i]; __i++)
- if (__s == __collatenames[__i])
- return string_type(1, __fctyp.widen(static_castchar(__i)));
-
- //for (unsigned int __i = 0; *__digraphs[__i]; __i++)
- // {
- //const char* __now = __digraphs[__i];
- //if (__s == __now)
- // {
- // string_type ret(__s.size(), __fctyp.widen('?'));
- // __fctyp.widen(__now, __now + 2/* ouch */, *ret.begin());
- // return ret;
- // }
- // }
+ string __s(__first, __last);
+ for (const auto __it : __collatenames)
+ if (__s == __it)
+ return string_type(1, __fctyp.widen(
+ static_castchar(__it - __collatenames)));
+
+ // TODO Add digraph support:
+ // http://boost.sourceforge.net/libs/regex/doc/collating_names.html
+
return string_type();
}
@@ -324,12 +288,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
lookup_classname(_Fwd_iter __first, _Fwd_iter __last, bool __icase) const
{
typedef std::ctypechar_type __ctype_type;
- typedef std::ctypechar __cctype_type;
- typedef const pairconst char*, char_class_type _ClassnameEntry;
const __ctype_type __fctyp(use_facet__ctype_type(_M_locale));
- const __cctype_type __cctyp(use_facet__cctype_type(_M_locale));
- static _ClassnameEntry __classnames[] =
+ // Mappings from class name to class mask.
+ static const pairconst char*, char_class_type __classnames[] =
{
{d, ctype_base::digit},
{w, {ctype_base::alnum, _RegexMask::_S_under}},
@@ -348,22 +310,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{xdigit, ctype_base::xdigit},
};
- std::string __s(__last - __first, '?');
- __fctyp.narrow(__first, __last, '?', __s[0]);
- __cctyp.tolower(*__s.begin(), *__s.begin() + __s.size());
- for (_ClassnameEntry* __it = __classnames;
- __it *(__classnames + 1);
- ++__it)
- {
- if (__s == __it-first)
- {
- if (__icase
- ((__it-second
- (ctype_base::lower | ctype_base::upper)) != 0))
- return ctype_base::alpha;
- return __it-second;
- }
- }
+ string __s;
+ for (auto __cur = __first; __cur != __last; ++__cur)
+ __s += __fctyp.narrow(__fctyp.tolower(*__cur), '?');
+
+ for (const auto __it : __classnames)
+ if (__s == __it.first)
+ {
+ if (__icase
+((__it.second
+ (ctype_base::lower | ctype_base::upper)) != 0))
+ return ctype_base::alpha;
+ return __it.second;
+ }
return 0;
}
diff --git a/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc
b/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc
index d7216ce..f4c9758 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/char/lookup_classname.cc
@@ -26,6 +26,7 @@
// 28.7(9) Class template regex_traits [re.traits]
#include regex
+#include forward_list
#include testsuite_hooks.h
void
@@ -47,8 +48,29 @@ test01()
VERIFY( c2 == c3 );
}
+// Test forward iterator
+void
+test02()
+{
+ const char strlit[] = upper;
+ std::forward_listchar s(strlit, strlit + strlen(strlit));
+
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On Sat, Jan 17, 2015 at 4:24 PM, Jonathan Wakely jwak...@redhat.com wrote: Initializing a pointer from another pointer just copies the value and has no way of doing anything different whether the source is an rvalue or an lvalue. Then std::move on a pointer definitely doesn't pessimize is true. Here I read pessimize as less efficient. -- Regards, Tim Shen
[doc, committed] remove more duplicate option documentation
While continuing to work on a proposal for splitting up the optimization
options section of the GCC manual into subsections (just posted to
gcc@), I found that -funroll-loops and -funroll-all-loops also had
duplicate entries. As with the previous patch to remove the duplicate
for -ftracer, I kept the more featureful of the two entries.
Patch committed as obvious.
-Sandra
2015-01-18 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/invoke.texi ([-funroll-loops], [-funroll-all-loops]):
Remove duplicate option listings.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219803)
+++ gcc/doc/invoke.texi (working copy)
@@ -8727,20 +8727,6 @@ enabled by default at @option{-O2} and h
elimination is only done if @option{-fdelete-null-pointer-checks} is
enabled.
-@item -funroll-loops
-@opindex funroll-loops
-Unroll loops whose number of iterations can be determined at compile
-time or upon entry to the loop. @option{-funroll-loops} implies
-@option{-frerun-cse-after-loop}. This option makes code larger,
-and may or may not make it run faster.
-
-@item -funroll-all-loops
-@opindex funroll-all-loops
-Unroll all loops, even if their number of iterations is uncertain when
-the loop is entered. This usually makes programs run more slowly.
-@option{-funroll-all-loops} implies the same options as
-@option{-funroll-loops},
-
@item -fsplit-ivs-in-unroller
@opindex fsplit-ivs-in-unroller
Enables expression of values of induction variables in later iterations
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
On 01/17/2015 03:58 PM, Jonathan Wakely wrote: My fault, this additional chunk is needed alongside the patch I sent earlier: --- a/libstdc++-v3/include/bits/atomic_futex.h +++ b/libstdc++-v3/include/bits/atomic_futex.h @@ -35,7 +35,7 @@ #include bits/c++config.h #include atomic #include chrono -#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX) +#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) ATOMIC_INT_LOCK_FREE 1) #include mutex #include condition_variable #endif What I sent earlier causes your target to use std::mutex and std::condition_variable, but without the bit above the headers aren't included. Still no joy: /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:45:3: error: '__atomic_futex_unsigned_base' has not been declared __atomic_futex_unsigned_base::_M_futex_wait_until(unsigned *__addr, ^ /scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:88:3: error: '__atomic_futex_unsigned_base' has not been declared __atomic_futex_unsigned_base::_M_futex_notify_all(unsigned* __addr) ^ Maybe the patch(es) causing all these problems should be reverted until the breakage is tracked down and fixed and regression-tested on a variety of targets? It's not really blocking me at the moment, but it seems unfortunate that trunk is so unstable as we're entering Stage 4. Torvald, if the extra change above doesn't fix it (although it should do) then maybe it should be reverted until it can be tested more widely. -Sandra
