[Patch, AArch64, AArch64-4.7] Backport Optimize cmp in some cases patch
Hi Maintainers,
The attached patch backports the gcc trunk patch
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00143.html to
ARM/aarch64-4.7-branch branch.
ChangeLog.aarch64
2013-01-27 Venkataramanan Kumar venkataramanan.ku...@linaro.org
Backport from mainline.
2013-01-04 Andrew Pinski apin...@cavium.com
* config/aarch64/aarch64.c (aarch64_fixed_condition_code_regs):
New function.
(TARGET_FIXED_CONDITION_CODE_REGS): Define
Path is attached. Please let me know if I can change -1 to
INVALID_REGNUM and commit.
Built gcc and tested the gcc testsuites for the aarch64-none-elf
target with ARMv8 Foundation model. No new regressions.
Ok to for the ARM/aarch64-4.7-branch ?
regards,
Venkat.
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 195486)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -2971,6 +2971,16 @@
return REAL_VALUES_EQUAL (r, dconst0);
}
+/* Return the fixed registers used for condition codes. */
+
+static bool
+aarch64_fixed_condition_code_regs (unsigned int *p1, unsigned int *p2)
+{
+ *p1 = CC_REGNUM;
+ *p2 = -1;
+ return true;
+}
+
enum machine_mode
aarch64_select_cc_mode (RTX_CODE code, rtx x, rtx y)
{
@@ -7809,6 +7819,9 @@
#undef TARGET_EXPAND_BUILTIN_VA_START
#define TARGET_EXPAND_BUILTIN_VA_START aarch64_expand_builtin_va_start
+#undef TARGET_FIXED_CONDITION_CODE_REG
+#define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs
+
#undef TARGET_FUNCTION_ARG
#define TARGET_FUNCTION_ARG aarch64_function_arg
Index: gcc/testsuite/gcc.target/aarch64/cmp-1.c
===
--- gcc/testsuite/gcc.target/aarch64/cmp-1.c(revision 0)
+++ gcc/testsuite/gcc.target/aarch64/cmp-1.c(working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+int f(int a, int b)
+{
+ if(ab)
+return 1;
+ if(ab)
+return -1;
+ return 0;
+}
+
+/* We should optimize away the second cmp. */
+/* { dg-final { scan-assembler-times cmp\tw 1 } } */
+
[PATCH, i386]: Fix PR 56114, x86_64-linux-gnu-gcc generate wrong asm instruction MOVABS for intel syntax
Hello!
2013-01-27 Uros Bizjak ubiz...@gmail.com
PR target/56114
* config/i386/i386.md (*movabsmode_1): Add square brackets around
operand 0 in movabs insn template for -masm=intel asm alternative.
(*movabsmode_2): Ditto for operand 1.
testsuite/ChangeLog:
2013-01-27 Uros Bizjak ubiz...@gmail.com
PR target/56114
* gcc.target/i386/pr56114.c: New test.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN, will be
backported to other release branches.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 195488)
+++ config/i386/i386.md (working copy)
@@ -2308,7 +2308,7 @@
(match_operand:SWI1248x 1 nonmemory_operand a,ri))]
TARGET_LP64 ix86_check_movabs (insn, 0)
@
- movabs{imodesuffix}\t{%1, %P0|%P0, %1}
+ movabs{imodesuffix}\t{%1, %P0|[%P0], %1}
mov{imodesuffix}\t{%1, %a0|%a0, %1}
[(set_attr type imov)
(set_attr modrm 0,*)
@@ -2322,7 +2322,7 @@
(mem:SWI1248x (match_operand:DI 1 x86_64_movabs_operand i,r)))]
TARGET_LP64 ix86_check_movabs (insn, 1)
@
- movabs{imodesuffix}\t{%P1, %0|%0, %P1}
+ movabs{imodesuffix}\t{%P1, %0|%0, [%P1]}
mov{imodesuffix}\t{%a1, %0|%0, %a1}
[(set_attr type imov)
(set_attr modrm 0,*)
Index: testsuite/gcc.target/i386/pr56114.c
===
--- testsuite/gcc.target/i386/pr56114.c (revision 0)
+++ testsuite/gcc.target/i386/pr56114.c (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do assemble } */
+/* { dg-options -O2 -masm=intel } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-require-effective-target masm_intel } */
+
+long
+foo2 (void)
+{
+ return *(volatile int *) 0xFEE0;
+}
Re: [wwwdocs] SH 4.8 changes - document thread pointer built-ins
On Sat, 2013-01-05 at 15:19 +0100, Oleg Endo wrote: Hi, On Wed, 2013-01-02 at 19:13 -1000, Gerald Pfeifer wrote: Hi Oleg, On Wed, 17 Oct 2012, Oleg Endo wrote: +liAdded support for the built-in functions +code__builtin_thread_pointer/code and +code__builtin_set_thread_pointer/code. This assumes that +codeGBR/code is used to hold the thread pointer of the current thread, +which has been the case since a while already. since a while - for a while, and I made that change. That said, why is this important, and is there a fixed date or version? It might be important for some embedded systems software that does not use the GBR for storing the thread pointer, but for something else (like a pointer to some global table of frequently used stuff or something like that). I just thought it might be better to mention this. But you're right, the last for a while part sounds strange, and should probably just be removed, reducing it to This assumes that codeGBR/code is used to hold the thread pointer of the current thread. That sounds good. I noticed this has not been changed yet, so I assume you were probably waiting for my response? Will you be making this change? I also assume I was waiting for your response ;) (it's been a while, can't remember exactly). I'll send a patch with the change. Thanks for reminding me. Cheers, Oleg I have just committed the attached patch to fix the issue mentioned above. Cheers, Oleg ? www_4_8_sh_changes_4.patch Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.88 diff -u -r1.88 changes.html --- htdocs/gcc-4.8/changes.html 20 Jan 2013 13:41:25 - 1.88 +++ htdocs/gcc-4.8/changes.html 27 Jan 2013 13:42:23 - @@ -671,10 +671,10 @@ liAdded support for the built-in functions code__builtin_thread_pointer/code and code__builtin_set_thread_pointer/code. This assumes that -codeGBR/code is used to hold the thread pointer of the current thread, -which has been the case for a while already. Memory loads and stores -relative to the address returned by code__builtin_thread_pointer/code -will now also utilize codeGBR/code based displacement address modes. +codeGBR/code is used to hold the thread pointer of the current thread. +Memory loads and stores relative to the address returned by +code__builtin_thread_pointer/code will now also utilize codeGBR/code +based displacement address modes. /li /ul
Re: FW: [PATCH] [MIPS] microMIPS gcc support
On Sat, 26 Jan 2013, Richard Sandiford wrote: How about instead of complicating this we simply add support for microMIPS encoding in the PLT? I think I should be able to squeeze out some time next week to dust off and retest the binutils patch I've had pending far too long now. This way we won't have to maintain separate cases where tail calls may or may not be made via the PLT. Note that we need that support sooner or later anyway due to the prospect of pure-microMIPS processors. Just so I know: what does the PLT patch do for external functions that are jumped to by both microMIPS and non-microMIPS code? Two PLT entries are produced in that case. PLT entries are created based on the relocation type referring: R_MIPS_26 relocations trigger a standard MIPS PLT entry, R_MICROMIPS_26_S1 relocations trigger a microMIPS PLT entry. Other relocations reuse a PLT entry already produced for one of the jump relocations, or if none present, then they make an own PLT entry according to ELF file header flags: if EF_MIPS_ARCH_ASE_MICROMIPS is set, then a microMIPS entry is produced, otherwise a standard MIPS one. Therefore depending on relocations seen up to two entries can be produced, encoded differently so that there is no need to switch modes with direct jumps. If all the individual PLT entries ultimately produced are microMIPS code, then the PLT header is built as microMIPS code as well, otherwise it's standard MIPS code. This guarantees no standard MIPS code is produced in the PLT if there's none already in the executable (and vice versa). Maciej
Re: [Patch, fortran] PR53537 Explicit import of USE renamed symbol.
Dear Mikael,
This looks good to me. The two week delay to back-porting is a good idea.
Thanks for the patch
Paul
On 10 January 2013 15:57, Mikael Morin mikael.mo...@sfr.fr wrote:
Hello,
for the case:
[...]
use select_precision, only: wp = dp
interface
subroutine ode_derivative(x)
import :: wp
[...]
`wp' is currently imported in the subroutine namespace under its original
name `dp', which leads to an error if one tries to use `wp'.
The core of the fix, which is basically a collection of the patches Tobias
posted in the PR, uses the matched name instead of the original name for the
symtree in the subroutine namespace.
Tobias' patches regress on import7.f90 because variable_decl lookups for the
type in the interface namespace (to check that it has been declared) using
the original name (which is the only one available there).
The fix I propose for that is to remove the regressing error, and try to
trigger the existing generic code diagnosing undeclared types. The latter
doesn't trigger currently because gfc_get_ha_symtree keep going up the
parent namespace until it finds a symbol, so in an interface block, it is
guaranteed to find a declared symbol, even if the latter hasn't been
imported in the interface.
The fix for that checks whether we are in an interface body without blank
import statement, and aborts the lookup in that case. A few adjustments are
then needed where the parent namespace is accessed directly, thus bypassing
the above check.
The change from the interface-specific error to the more general error needs
a few test cases to be adjusted, namely import2.f90, import8.f90, and
interface_derived_type_1.f90
from:
type(fcnparms) :: fparams ! { dg-error not been declared within
the in
1
Error: The type of 'fparams' at (1) has not been declared within the
interface
to:
type(fcnparms) :: fparams ! { dg-error not been declared within
the in
1
Error: Derived type 'fcnparms' at (1) is being used before it is defined
The caret is slightly better, the message is slightly worse. I think it's
OK, but could consider trying to issue a better error message.
Otherwise it passes the test suite. OK for trunk?
As the code impacts the name to symbol resolution code, it has a big
potential for breakage; the bug is a regression however, so I plan to
backport to 4.7 and 4.6, say, two weeks after trunk at least (if I don't
forget). Does it sound good?
Mikael
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: Cortex-A15 vfnma/vfnms test patch
Dear Mike, Thanks for the information. Thank You, Amol Pise On Sat, Jan 26, 2013 at 12:17 AM, Mike Stump mikest...@comcast.net wrote: Given what stage we are in for trunk, I'm going to let the arm folks review this… [ this is my form of a ping for you! ] On Jan 21, 2013, at 9:04 PM, amol pise amolpis...@gmail.com wrote: Please let me know the patch is OK for trunk ? On 1/21/13, amol pise amolpis...@gmail.com wrote: * gcc/testsuite/gcc.target/arm/neon-vfma-1.c * gcc/testsuite/gcc.target/arm/neon-vfms-1.c
SLP for vectors
Hello,
this message is to check that I am not doing something absurd and ask for
a bit of advice.
In the attached patch, I let SLP recognize vector loads/stores just like
it recognizes those in an array. It has a few issues: the cost of the
vectorized version is overestimated, the base object is wrong (doesn't
strip the bit_field_ref, but since the base address is right and the base
object is almost unused...), but most importantly it only works if the
vectors have their address taken, otherwise (after asking gimple_vuse?)
SLP doesn't detect their use as loads or stores at all. Also, it only
works if you write result[0]=..., result[1]=... and does not recognize a
constructor as a series of stores.
Is slowly extending SLP the right way to go? Should get_references_in_stmt
report vector element accesses?
(the patch as is passes the testsuite on x86_64-linux and vectorizes the
few examples I tried)
--
Marc GlisseIndex: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 195493)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -3860,20 +3860,21 @@ vectorizable_store (gimple stmt, gimple_
/* Is vectorizable store? */
if (!is_gimple_assign (stmt))
return false;
scalar_dest = gimple_assign_lhs (stmt);
if (TREE_CODE (scalar_dest) == VIEW_CONVERT_EXPR
is_pattern_stmt_p (stmt_info))
scalar_dest = TREE_OPERAND (scalar_dest, 0);
if (TREE_CODE (scalar_dest) != ARRAY_REF
+ TREE_CODE (scalar_dest) != BIT_FIELD_REF
TREE_CODE (scalar_dest) != INDIRECT_REF
TREE_CODE (scalar_dest) != COMPONENT_REF
TREE_CODE (scalar_dest) != IMAGPART_EXPR
TREE_CODE (scalar_dest) != REALPART_EXPR
TREE_CODE (scalar_dest) != MEM_REF)
return false;
gcc_assert (gimple_assign_single_p (stmt));
op = gimple_assign_rhs1 (stmt);
if (!vect_is_simple_use (op, stmt, loop_vinfo, bb_vinfo, def_stmt,
@@ -4394,20 +4395,21 @@ vectorizable_load (gimple stmt, gimple_s
/* Is vectorizable load? */
if (!is_gimple_assign (stmt))
return false;
scalar_dest = gimple_assign_lhs (stmt);
if (TREE_CODE (scalar_dest) != SSA_NAME)
return false;
code = gimple_assign_rhs_code (stmt);
if (code != ARRAY_REF
+ code != BIT_FIELD_REF
code != INDIRECT_REF
code != COMPONENT_REF
code != IMAGPART_EXPR
code != REALPART_EXPR
code != MEM_REF
TREE_CODE_CLASS (code) != tcc_declaration)
return false;
if (!STMT_VINFO_DATA_REF (stmt_info))
return false;
Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 195493)
+++ gcc/tree-vect-slp.c (working copy)
@@ -660,20 +660,21 @@ vect_build_slp_tree (loop_vec_info loop_
}
else
{
if (first_stmt_code != rhs_code
(first_stmt_code != IMAGPART_EXPR
|| rhs_code != REALPART_EXPR)
(first_stmt_code != REALPART_EXPR
|| rhs_code != IMAGPART_EXPR)
!(STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (stmt))
(first_stmt_code == ARRAY_REF
+ || first_stmt_code == BIT_FIELD_REF
|| first_stmt_code == INDIRECT_REF
|| first_stmt_code == COMPONENT_REF
|| first_stmt_code == MEM_REF)))
{
if (dump_enabled_p ())
{
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
Build SLP failed: different operation
in stmt );
dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM, stmt, 0);
Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 195493)
+++ gcc/tree-data-ref.c (working copy)
@@ -854,20 +854,24 @@ dr_analyze_indices (struct data_referenc
/* Analyze access functions of dimensions we know to be independent. */
while (handled_component_p (ref))
{
if (TREE_CODE (ref) == ARRAY_REF)
{
op = TREE_OPERAND (ref, 1);
access_fn = analyze_scalar_evolution (loop, op);
access_fn = instantiate_scev (before_loop, loop, access_fn);
access_fns.safe_push (access_fn);
}
+ else if (TREE_CODE (ref) == BIT_FIELD_REF)
+ {
+ access_fns.safe_push (TREE_OPERAND (ref, 2));
+ }
else if (TREE_CODE (ref) == COMPONENT_REF
TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) == RECORD_TYPE)
{
/* For COMPONENT_REFs of records (but not unions!) use the
FIELD_DECL offset as constant access function so we can
disambiguate a[i].f1 and a[i].f2. */
tree off = component_ref_field_offset (ref);
off = size_binop (PLUS_EXPR,
Re: [PATCH 1/2] Document HLE / RTM intrinsics
On 01/12/2013 04:28 PM, Andi Kleen wrote: The TSX HLE/RTM intrinsics were missing documentation. Add this to the manual. Are these intrinsics restricted to free-standing implementations? Or are these instructions designed in such a way that they work as expected even if the threading library uses them internally? (That would be quite a feat.) -- Florian Weimer / Red Hat Product Security Team
[patch, fortran] Fix PR 50627
Hello world,
the attached patch fixes the regression regarding freeing
namespaces twice.
The test cases where also run unter valgrind without
producing errors.
Regression-tested. OK for trunk?
Thomas
2013-01-27 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/56054
* decl.c (gfc_match_end): Remove half-ready namespace
from parent if the end of a block is missing.
* parse.c (parse_module): Do not put namespace into
gsymbol on error.
2013-01-27 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/56054
* gfortran.dg/block_12.f90: New test.
* gfortran.dg/module_error_1.f90: New test.
Index: decl.c
===
--- decl.c (Revision 195319)
+++ decl.c (Arbeitskopie)
@@ -5979,6 +5979,8 @@ gfc_match_end (gfc_statement *st)
const char *target;
int eos_ok;
match m;
+ gfc_namespace *parent_ns, *ns, *prev_ns;
+ gfc_namespace **nsp;
old_loc = gfc_current_locus;
if (gfc_match (end) != MATCH_YES)
@@ -6204,6 +6206,35 @@ syntax:
cleanup:
gfc_current_locus = old_loc;
+
+ /* If we are missing an END BLOCK, we created a half-ready namespace.
+ Remove it from the parent namespace's sibling list. */
+
+ if (state == COMP_BLOCK)
+{
+ parent_ns = gfc_current_ns-parent;
+
+ nsp = (gfc_state_stack-previous-tail-ext.block.ns);
+
+ prev_ns = NULL;
+ ns = *nsp;
+ while (ns)
+ {
+ if (ns == gfc_current_ns)
+ {
+ if (prev_ns == NULL)
+ *nsp = NULL;
+ else
+ prev_ns-sibling = ns-sibling;
+ }
+ prev_ns = ns;
+ ns = ns-sibling;
+ }
+
+ gfc_free_namespace (gfc_current_ns);
+ gfc_current_ns = parent_ns;
+}
+
return MATCH_ERROR;
}
Index: parse.c
===
--- parse.c (Revision 195319)
+++ parse.c (Arbeitskopie)
@@ -4291,6 +4291,7 @@ parse_module (void)
{
gfc_statement st;
gfc_gsymbol *s;
+ bool error;
s = gfc_get_gsymbol (gfc_new_block-name);
if (s-defined || (s-type != GSYM_UNKNOWN s-type != GSYM_MODULE))
@@ -4304,6 +4305,7 @@ parse_module (void)
st = parse_spec (ST_NONE);
+ error = false;
loop:
switch (st)
{
@@ -4322,12 +4324,15 @@ loop:
gfc_error (Unexpected %s statement in MODULE at %C,
gfc_ascii_statement (st));
+ error = true;
reject_statement ();
st = next_statement ();
goto loop;
}
- s-ns = gfc_current_ns;
+ /* Make sure not to free the namespace twice on error. */
+ if (!error)
+s-ns = gfc_current_ns;
}
! { dg-do compile }
module kernels
select type (args) ! { dg-error Unexpected SELECT TYPE }
end module kernels
! { dg-do compile }
! PR 56054 - this used to free a namespace twice.
program main
block
end program main ! { dg-error END BLOCK }
! { dg-prune-output Unexpected end of file }
[Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Hi all, the attached patch fixes a regression with PROCEDURE declarations and is a co-production of Mikael and me. The problem is this: For a procedure declaration like PROCEDURE(ifc) :: proc we currently go to quite some lengths to copy the complete interface (i.e. formal args etc) from symbol 'ifc' to the just declared symbol 'proc'. If done properly (which only happens as of lately), this will result in an infinite loop for declarations like this: subroutine sub (arg) procedure(sub) :: arg end subroutine Here the argument is a procedure which inherits its interface from the host subroutine (so that the interface of 'sub' is defined 'recursively', so to speak), and we just keep building an infinite chain of symbols. The simple and effective solution to this problem is to avoid the complete copying procedure altogether and to just keep a pointer to the interface (which we have anyway: ts.interface). This even simplifies a few things and allows us to get rid of some code parts. In turn, we have to make sure to use the formal args not from the symbol itself, but from its interface (ts.interface). This is what the new function 'gfc_sym_get_dummy_args' does. This new approach also allows us to get rid of the 'formal' and 'formal_ns' in gfc_components (which are now available via ts.interface). This also means we don't have to read those from the mod files any more, which therefore change their format. What confuses me: While our documentation claims that the module format has been changed for 4.8 (see http://gcc.gnu.org/wiki/GFortran#GCC4.8 and http://gcc.gnu.org/gcc-4.8/changes.html), I see in module.c: #define MOD_VERSION 9 in both 4.8 and trunk. Can anyone tell me why the documentation does not match the implementation? Or am I missing something? Anyway, should we bump the mod version with this patch, or should we rather avoid it? The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-01-27 Janus Weil ja...@gcc.gnu.org Mikael Morin mik...@gcc.gnu.org PR fortran/54107 * gfortran.h (gfc_component): Delete members 'formal' and 'formal_ns'. (gfc_copy_formal_args,gfc_copy_formal_args_ppc,gfc_expr_replace_symbols, gfc_expr_replace_comp): Delete. (gfc_sym_get_dummy_args): New prototype. * dependency.c (gfc_check_fncall_dependency): Use 'gfc_sym_get_dummy_args'. * expr.c (gfc_is_constant_expr): Ditto. (replace_symbol,gfc_expr_replace_symbols,replace_comp, gfc_expr_replace_comp): Deleted. * frontend-passes.c (doloop_code,do_function): Use 'gfc_sym_get_dummy_args'. * interface.c (gfc_check_operator_interface,gfc_compare_interfaces, gfc_procedure_use,gfc_ppc_use,gfc_arglist_matches_symbol, gfc_check_typebound_override): Ditto. * module.c (mio_component): Do not read/write 'formal' and 'formal_ns'. * resolve.c (resolve_procedure_interface,resolve_fl_derived0): Do not copy formal args, but just keep a pointer to the interface. (resolve_function,resolve_call,resolve_typebound_generic_call, resolve_ppc_call,resolve_expr_ppc,generate_component_assignments, resolve_fl_procedure,gfc_resolve_finalizers,check_generic_tbp_ambiguity, resolve_typebound_procedure,check_uop_procedure): Use 'gfc_sym_get_dummy_args'. * symbol.c (free_components): Do not free 'formal' and 'formal_ns'. (gfc_copy_formal_args,gfc_copy_formal_args_ppc): Deleted. (gfc_sym_get_dummy_args): New function. * trans-array.c (get_array_charlen,gfc_walk_elemental_function_args): Use 'gfc_sym_get_dummy_args'. * trans-decl.c (build_function_decl,create_function_arglist, build_entry_thunks,init_intent_out_dt,gfc_trans_deferred_vars, add_argument_checking): Ditto. * trans-expr.c (gfc_map_fcn_formal_to_actual,gfc_conv_procedure_call, gfc_conv_statement_function): Ditto. * trans-stmt.c (gfc_conv_elemental_dependencies): Ditto. * trans-types.c (create_fn_spec,gfc_get_function_type): Ditto. 2013-01-27 Janus Weil ja...@gcc.gnu.org Mikael Morin mik...@gcc.gnu.org PR fortran/54107 * gfortran.dg/proc_ptr_comp_36.f90: New. pr54107_v4.diff Description: Binary data proc_ptr_comp_36.f90 Description: Binary data
Re: [patch, fortran] Fix PR 50627
Of course, that should be PR 50627 in the ChangeLog.
Re: [patch, fortran] Fix PR 50627
Of course, that should be PR 50627 in the ChangeLog. I think you need both PR 50627 and 56054. The patch fixes these PRs, full testing in progress. Dominique
Re: [Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Hi Janus, Le 27/01/2013 19:49, Janus Weil a écrit : subroutine sub (arg) procedure(sub) :: arg end subroutine You forgot to precise that this case (which is basically comment #4 in the PR) is *not* fixed by the patch, as it fails later on at translation stage. I have made up my mind that it's not possible for the middle-end to build such a recursive type. So `arg' will have to have a variadic function type. No patch yet, sorry; I have just figured it out. Anyway, should we bump the mod version with this patch, or should we rather avoid it? I forgot the reason why we are so reluctant to do it. Module versions are not a rare resource. I'm in favor of bumping (and any time we change module format). About the patch, one nit: Index: gcc/fortran/gfortran.h === --- gcc/fortran/gfortran.h (revision 195493) +++ gcc/fortran/gfortran.h (working copy) @@ -974,8 +974,6 @@ typedef struct gfc_component struct gfc_component *next; /* Needed for procedure pointer components. */ - struct gfc_formal_arglist *formal; - struct gfc_namespace *formal_ns; struct gfc_typebound_proc *tb; } gfc_component; The comment should probably be removed as well. The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK from my side; you may or may not need someone else's ack as I'm the coauthor. Or maybe wait for the fix for comment #4? Mikael
Re: [Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Am 27.01.2013 21:16, schrieb Mikael Morin: Or maybe wait for the fix for comment #4? I would rather commit the fixes now, just on general principles. If any regression should occur, it would be easier to pinpoint the reason. Thomas
Re: [Patch, Fortran] PR 54107: [4.8 Regression] Memory hog with abstract interface
Hi, subroutine sub (arg) procedure(sub) :: arg end subroutine You forgot to precise that this case (which is basically comment #4 in the PR) is *not* fixed by the patch, as it fails later on at translation stage. yes, I just silently ignored that fact. I have made up my mind that it's not possible for the middle-end to build such a recursive type. So `arg' will have to have a variadic function type. No patch yet, sorry; I have just figured it out. Don't worry. I agree with Thomas that this should preferably be done in a follow-up patch. (The hard part is probably to detect all the cases of 'recursive' definitions, also the indirect ones.) Anyway, should we bump the mod version with this patch, or should we rather avoid it? I forgot the reason why we are so reluctant to do it. Module versions are not a rare resource. I'm in favor of bumping (and any time we change module format). I'm also ok with a bump, but of course it would be preferable to have a stable ABI and module format at some point. As a matter of fact, the module format has changed in all recent releases, though (that's why we introduced the module versioning, after all). About the patch, one nit: Index: gcc/fortran/gfortran.h === --- gcc/fortran/gfortran.h (revision 195493) +++ gcc/fortran/gfortran.h (working copy) @@ -974,8 +974,6 @@ typedef struct gfc_component struct gfc_component *next; /* Needed for procedure pointer components. */ - struct gfc_formal_arglist *formal; - struct gfc_namespace *formal_ns; struct gfc_typebound_proc *tb; } gfc_component; The comment should probably be removed as well. Well, it still applies to 'tb' ... The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK from my side; you may or may not need someone else's ack as I'm the coauthor. Certainly a second review/opinion could not hurt. I'm attaching an updated patch, which includes the module-version bump now. Or maybe wait for the fix for comment #4? Rather not (technically it's a separate issue, I guess). Cheers, Janus pr54107_v5.diff Description: Binary data
Re: [PATCH 1/2] Document HLE / RTM intrinsics
On Sun, Jan 27, 2013 at 07:15:42PM +0100, Florian Weimer wrote: On 01/12/2013 04:28 PM, Andi Kleen wrote: The TSX HLE/RTM intrinsics were missing documentation. Add this to the manual. Are these intrinsics restricted to free-standing implementations? Or are these instructions designed in such a way that they work as expected even if the threading library uses them internally? (That would be quite a feat.) They can be combined with a threading library, with some restrictions. See the manual for details. All transactions are flattened. http://software.intel.com/sites/default/files/m/a/b/3/4/d/41604-319433-012a.pdf chapter 8 restrictions may lead to not eliding or abort, but never to correctness problems. Documenting all that is out of scope for the gcc manual though. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: Update my entry into the contributions
On Fri, 25 Jan 2013, Andrew Pinski wrote: I thought I would update my entry which just mentions the bug work which I have done. I mentioned pointer plus and other optimizations in the new entry. Okay. Just give others two, three days to chime in if I am missing something. And, should it read GIMPLE? I think other people should update their own entry also. Absolutely! Geald
Re: [Patch] Fix PR54814
Georg-Johann Lay schrieb: Jeff Law schrieb: On 01/25/2013 11:41 AM, Georg-Johann Lay wrote: PR54814 causes spill fails because reload.c:find_valid_class_1 tests only one hard register instead of all hard registers of regno:mode in rclass: http://gcc.gnu.org/PR54814 The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 The patch is bootstrapped and tested on x86_64-linux and also fixes the spill fails that originally occurred on avr-unknown-one. Ok to apply? PR other/54814 * reload.c (find_valid_class_1): Use in_hard_reg_set_p instead of TEST_HARD_REG_BIT. Is this a regression relative to a prior version of GCC? Yes, it's 4.8 regression. 4.7 works and r190252 was only applied to 4.8 trunk. If not, it'll probably need release manager approval before it can go in. Please attach your patch to PR54814 and attach PR 54814 to the 4.9 pending patches meta bug. Does this mean the fix is rejected for 4.8? I found no 4.9 meta-bug in the 47 meta-bugs. You have th PR? http://gcc.gnu.org/bugzilla/buglist.cgi?keywords=meta-bug%2C%20keywords_type=allwordslist_id=51998cf_known_to_fail_type=allwordscf_known_to_work_type=allwordsquery_format=advancedbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDproduct=gcc FYI, this bug breaks the avr port almost completely. Many real-world programs ICE.
Re: [Patch] Fix PR54814
On Sun, 27 Jan 2013, Georg-Johann Lay wrote: I found no 4.9 meta-bug in the 47 meta-bugs. You have th PR? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996 -- Marc Glisse
Re: [avr,committed] Fix fixed-point conversion
On Thu, 24 Jan 2013, Georg-Johann Lay wrote: Committed the following change: http://gcc.gnu.org/r195424 * config/avr/avr.c (avr_out_fract): Make register numbers that might be outside of source operand signed. Can you still post patches to the list, and not just the reference? Thanks, Gerald
Re: [Patch] Fix PR54814
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote: The patch was originally worked out by Bernd Schmidt and fixed a problem introduced in http://gcc.gnu.org/r190252 Ironically, this revision fixes a reload problem on x86/x86_64 -- which doesn't use reload anymore now... Does this mean the fix is rejected for 4.8? No, just that it probably helps to add a RM to the CC list. FWIW, it seems to me that this patch should go into 4.8, because the bug is probably not limited to AVR. Ciao! Steven
[patch] Fix libstdc++/56112, inserting non-pairs into std::unordered_map
This is a much simpler fix than discussed in bugzilla, just forward to
_M_emplace() when inserting from a type that needs conversion to
value_type. This also fixes the dangling reference problem as well as
the regression with calling insert() with convertible types.
PR libstdc++/56112
* include/bits/hashtable_policy.h (insert(_Pair)): Use _M_emplace
to construct value_type explicitly before trying to extract the key.
* testsuite/23_containers/unordered_map/cons/56112.cc: New.
Tested x86_64-linux, will commit to trunk tomorrow.
N.B. The dangling reference bug is present on the 4.6 and 4.7
branches, but not a regression.
commit ca741fccc5d052db08ba839bd45ece7564ac5004
Author: Jonathan Wakely jwakely@gmail.com
Date: Mon Jan 28 00:08:43 2013 +
PR libstdc++/56112
* include/bits/hashtable_policy.h (insert(_Pair)): Use _M_emplace
to construct value_type explicitly before trying to extract the key.
* testsuite/23_containers/unordered_map/cons/56112.cc: New.
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h
b/libstdc++-v3/include/bits/hashtable_policy.h
index 023f46d..1ade3f9 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -836,7 +836,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
insert(_Pair __v)
{
__hashtable __h = this-_M_conjure_hashtable();
- return __h._M_insert(std::forward_Pair(__v), __unique_keys());
+ return __h._M_emplace(__unique_keys(), std::forward_Pair(__v));
}
templatetypename _Pair, typename = _IFconsp_Pair
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
new file mode 100644
index 000..c297ef7
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
@@ -0,0 +1,49 @@
+// { dg-options -std=gnu++0x }
+
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+#include unordered_map
+#include utility
+
+struct Key
+{
+ explicit Key(const int* p) : value(p) { }
+ ~Key() { value = nullptr; }
+
+ bool operator==(const Key k) const { return *value == *k.value; }
+
+ const int* value;
+};
+
+struct hash
+{
+ std::size_t operator()(const Key k) const noexcept { return *k.value; }
+};
+
+struct S
+{
+ int value;
+ operator std::pairconst Key, int() const { return {Key(value), value}; }
+};
+
+int main()
+{
+S s[1] = { {2} };
+std::unordered_mapKey, int, hash m(s, s+1);
+std::unordered_multimapKey, int, hash mm(s, s+1);
+}
Re: [PATCH ARM iWMMXt 0/5] Improve iWMMXt support
On Tue, Jun 26, 2012 at 7:56 AM, nick clifton ni...@redhat.com wrote: Hi Matt, There's also a trivial documentation fix: [PATCH 1/2] doc: Correct __builtin_arm_tinsr prototype documentation and a test to exercise the intrinsics: [PATCH 2/2] arm: add iwMMXt mmx-2.c test These have both been checked in. It turns out that both needed minor updates as some of the builtins have changed since these patches were written. I have taken care of this however. Cheers Nick Hi Nick, Could this patch, or perhaps the much smaller one I attached to bug 35294 be committed to the 4.7 branch? Also, could you close its duplicates, bugs 36798 and 36966? Thanks, Matt
Re: [PATCH] Adding target rdos to GCC
If the patch is ok, could some maintainer add it to trunk? Regards, Leif Ekblad - Original Message - From: Richard Biener rguent...@suse.de To: Uros Bizjak ubiz...@gmail.com Cc: Leif Ekblad l...@rdos.net; gcc-patches@gcc.gnu.org; H.J. Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com Sent: Wednesday, January 09, 2013 9:37 AM Subject: Re: [PATCH] Adding target rdos to GCC On Wed, 9 Jan 2013, Uros Bizjak wrote: On Tue, Jan 8, 2013 at 9:32 PM, Leif Ekblad l...@rdos.net wrote: After some new suggestions from Uros, I've made a new diff. Change log: * config/gthr.m4: Added rdos thread header. * gcc/config/i386/i386.c: Provided a way to define a default setting for medium memory model and PIC using TARGET_RDOS define. * gcc/config/i386/i386.h: Defined TARGET_RDOS macro. Defined default value for large-data-threshold. * gcc/config/i386/i386.md: Added r14 and r15 register names. * gcc/config/i386/i386.opt: Changed initial value for large-data-threshold to DEFAULT_LARGE_SECTION_THRESHOLD. * gcc/config/i386/rdos.h: Common definitions for target rdos * gcc/config/i386/rdos64.h: Specific definitions for 64-bit rdos target. * gcc/config.gcc: Added rdos targets Please use present tense in ChangeLog (see many other entries). Tested on target rdos and rdos32. This is OK for mainline, but the patch needs explicit approval from Release Managers at this stage. Ok with me. Richard.
Re: [PATCH] Adding target rdos to GCC
On Mon, Jan 28, 2013 at 7:50 AM, Leif Ekblad l...@rdos.net wrote: If the patch is ok, could some maintainer add it to trunk? There is no gthr-rdos.h file in your patch: *** gcc-4.8-20121230/config/gthr.m4 2012-10-15 15:10:30.0 +0200 --- gcc-work/config/gthr.m4 2013-01-07 10:14:04.620667900 +0100 *** *** 21,26 --- 21,27 tpf) thread_header=config/s390/gthr-tpf.h ;; vxworks) thread_header=config/gthr-vxworks.h ;; win32)thread_header=config/i386/gthr-win32.h ;; + rdos) thread_header=config/i386/gthr-rdos.h ;; This file should be part of libgcc, so it needs its own ChangeLog. Uros.
