Re: [committed] copy-edit -flto documentation
> When I was looking at some LTO-related test failures last week (see mail > on gcc@), I found that the many punctuation and grammatical errors in > the -flto documentation made this section of the GCC manual hard to > read. I made a pass over it to clean up the worst problems -- since the > changes don't affect content, I've checked in this patch as "obvious". If you happen to have a 4.6 branch around and the patch can be applied without too many adjustments, please consider applying it on the branch. -- Eric Botcazou
[PATCH] OpenBSD stdint fix
These are "long long" on all supported platforms instead of the default "long" on 64-bit, "long long" on 32-bit that defaults.h assumes. 2012-01-03 Mark Kettenis * config/openbsd-stdint.h (INTMAX_TYPE, UINTMAX_TYPE): New defines. Index: gcc/config/openbsd-stdint.h === --- gcc/config/openbsd-stdint.h (revision 182767) +++ gcc/config/openbsd-stdint.h (working copy) @@ -26,6 +26,9 @@ #define UINT_FAST16_TYPE "unsigned int" #define UINT_FAST32_TYPE "unsigned int" #define UINT_FAST64_TYPE "long long unsigned int" + +#define INTMAX_TYPE"long long int" +#define UINTMAX_TYPE "long long unsigned int" #define INTPTR_TYPE"long int" #define UINTPTR_TYPE "long unsigned int"
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
> AFAICT, we previously wanted to handle "restart safety" by adding > abnormal edges to all calls to the TM runtime library (which could in > turn call the libitm longjmp that actually restarts a transaction). > Richard mentioned that we could drop this code (I think he meant this, > and others pieces perhaps) if the returns-twice approach works. Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is thought to be quite a big hammer. -- Eric Botcazou
Re: [PATCH] Fix gimple_ic if adding a noreturn direct call variant to an indirect not noreturn call (PR tree-optimization/51719)
On Mon, 2 Jan 2012, Jakub Jelinek wrote:
> Hi!
>
> When gimple_ic is changing an indirect call into
> if (cond)
> direct_call ();
> else
> (*indirect_call) ()
> and the indirect_call is not noreturn, but direct_call is
> noreturn, we ICE during checking after profile, because the noreturn
> call still has lhs set and edges that it shouldn't have.
>
> The following patch fixes, it, bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2012-01-02 Jakub Jelinek
>
> PR tree-optimization/51719
> * value-prof.c (gimple_ic): When indirect call isn't noreturn,
> but direct call is, clear direct call's lhs and don't add fallthrough
> edge from dcall_bb to join_bb and PHIs.
>
> * g++.dg/tree-prof/pr51719.C: New test.
>
> --- gcc/value-prof.c.jj 2011-08-18 08:36:00.0 +0200
> +++ gcc/value-prof.c 2012-01-02 19:01:33.760867971 +0100
> @@ -1149,7 +1149,7 @@ gimple_ic (gimple icall_stmt, struct cgr
>tree optype = build_pointer_type (void_type_node);
>edge e_cd, e_ci, e_di, e_dj = NULL, e_ij;
>gimple_stmt_iterator gsi;
> - int lp_nr;
> + int lp_nr, dflags;
>
>cond_bb = gimple_bb (icall_stmt);
>gsi = gsi_for_stmt (icall_stmt);
> @@ -1176,6 +1176,9 @@ gimple_ic (gimple icall_stmt, struct cgr
>update_stmt (icall_stmt);
>dcall_stmt = gimple_copy (icall_stmt);
>gimple_call_set_fndecl (dcall_stmt, direct_call->decl);
> + dflags = flags_from_decl_or_type (direct_call->decl);
> + if ((dflags & ECF_NORETURN) != 0)
> +gimple_call_set_lhs (dcall_stmt, NULL_TREE);
>gsi_insert_before (&gsi, dcall_stmt, GSI_SAME_STMT);
>
>/* Fix CFG. */
> @@ -1220,17 +1223,23 @@ gimple_ic (gimple icall_stmt, struct cgr
>
>if (e_ij != NULL)
> {
> - e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
> - e_dj->probability = REG_BR_PROB_BASE;
> - e_dj->count = count;
> + if ((dflags & ECF_NORETURN) != 0)
> + e_ij->count = all;
> + else
> + {
> + e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
> + e_dj->probability = REG_BR_PROB_BASE;
> + e_dj->count = count;
>
> + e_ij->count = all - count;
> + }
>e_ij->probability = REG_BR_PROB_BASE;
> - e_ij->count = all - count;
> }
>
>/* Insert PHI node for the call result if necessary. */
>if (gimple_call_lhs (icall_stmt)
> - && TREE_CODE (gimple_call_lhs (icall_stmt)) == SSA_NAME)
> + && TREE_CODE (gimple_call_lhs (icall_stmt)) == SSA_NAME
> + && (dflags & ECF_NORETURN) == 0)
> {
>tree result = gimple_call_lhs (icall_stmt);
>gimple phi = create_phi_node (result, join_bb);
> --- gcc/testsuite/g++.dg/tree-prof/pr51719.C.jj 2012-01-02
> 19:11:27.633358952 +0100
> +++ gcc/testsuite/g++.dg/tree-prof/pr51719.C 2012-01-02 19:12:27.797004399
> +0100
> @@ -0,0 +1,27 @@
> +// PR tree-optimization/51719
> +// { dg-options "-O -fpartial-inlining" }
> +
> +int
> +bar (void)
> +{
> + throw 1;
> +}
> +
> +int __attribute__ ((noinline, noclone))
> +foo (int (*f) (void))
> +{
> + try
> + {
> +return (*f) ();
> + }
> + catch (...)
> + {
> + }
> + return 0;
> +}
> +
> +int
> +main ()
> +{
> + return foo (bar);
> +}
>
> Jakub
>
>
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH] Fix PR51730
On Mon, 2 Jan 2012, Richard Guenther wrote:
>
> I am testing the following patch to fix PR51730.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
> Richard.
>
> 2012-01-02 Richard Guenther
>
> PR middle-end/51730
> * fold-const.c (fold_comparison): Properly canonicalize
> tree offset and HOST_WIDE_INT bit position.
>
> * gcc.dg/fold-compare-6.c: New testcase.
>
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c (revision 182784)
> +++ gcc/fold-const.c (working copy)
> @@ -8886,6 +8886,14 @@ fold_comparison (location_t loc, enum tr
> indirect_base0 = true;
> }
> offset0 = TREE_OPERAND (arg0, 1);
> + if (host_integerp (offset0, 0)
> + && ((HOST_WIDE_INT) (TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT)
> + / BITS_PER_UNIT
> + == (HOST_WIDE_INT) TREE_INT_CST_LOW (offset0)))
> + {
> + bitpos0 = TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT;
> + offset0 = NULL_TREE;
> + }
> }
>
>base1 = arg1;
> @@ -8909,6 +8917,14 @@ fold_comparison (location_t loc, enum tr
> indirect_base1 = true;
> }
> offset1 = TREE_OPERAND (arg1, 1);
> + if (host_integerp (offset1, 0)
> + && ((HOST_WIDE_INT) (TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT)
> + / BITS_PER_UNIT
> + == (HOST_WIDE_INT) TREE_INT_CST_LOW (offset1)))
> + {
> + bitpos1 = TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT;
> + offset1 = NULL_TREE;
> + }
> }
>
>/* A local variable can never be pointed to by
> Index: gcc/testsuite/gcc.dg/fold-compare-6.c
> ===
> --- gcc/testsuite/gcc.dg/fold-compare-6.c (revision 0)
> +++ gcc/testsuite/gcc.dg/fold-compare-6.c (revision 0)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fdump-tree-original" } */
> +
> +char digs[] = "0123456789";
> +int foo (void)
> +{
> + int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
> + return xlcbug;
> +}
> +
> +/* { dg-final { scan-tree-dump "xlcbug = 1;" "original" } } */
> +/* { dg-final { cleanup-tree-dump "original" } } */
>
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
[Committed] S/390: Fix 2 md file comments.
Applied to mainline.
2011-10-11 Andreas Krebbel
* config/s390/s390.md ("*cmp_ccs"): Fix comment mentioning
the instructions emitted by the pattern.
("*TDC_insn_"): Add comment.
---
gcc/config/s390/s390.md |3 +!!
1 file changed, 1 insertion(+), 2 modifications(!)
Index: gcc/config/s390/s390.md
===
*** gcc/config/s390/s390.md.orig
--- gcc/config/s390/s390.md
***
*** 1010,1016
[(set_attr "op_type" "RRE")
(set_attr "type" "fsimp")])
! ; cxtr, cxbr, cdbr, cebr, cdb, ceb, cxbtr, cdbtr
(define_insn "*cmp_ccs"
[(set (reg CC_REGNUM)
(compare (match_operand:FP 0 "register_operand" "f,f")
--- 1010,1016
[(set_attr "op_type" "RRE")
(set_attr "type" "fsimp")])
! ; cxtr, cxbr, cdtr, cdbr, cebr, cdb, ceb
(define_insn "*cmp_ccs"
[(set (reg CC_REGNUM)
(compare (match_operand:FP 0 "register_operand" "f,f")
***
*** 2816,2821
--- 2816,2822
; is the register to be tested and the second one is the bit mask
; specifying the required test(s).
;
+ ; tcxb, tcdb, tceb, tdcxt, tdcdt, tdcet
(define_insn "*TDC_insn_"
[(set (reg:CCZ CC_REGNUM)
(unspec:CCZ [(match_operand:FP_ALL 0 "register_operand" "f")
Re: [PATCH SMS 2/2, RFC] Register pressure estimation for the partial schedule (re-submission)
Hello,
> On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
> wrote:
> > Ayal Zaks writes:
> >> + for (i = 0; i < ira_pressure_classes_num; i++)
> >> + {
> >> + enum reg_class pressure_class;
> >> +
> >> + pressure_class = ira_pressure_classes[i];
> >> +
> >> + if (max_reg_pressure[pressure_class] == 0)
> >> + continue;
> >> +
> >> + if (dump_file)
> >> + fprintf (dump_file, "%s=%d %d ", reg_class_names
[pressure_class],
> >> + max_reg_pressure[pressure_class],
> >> + ira_available_class_regs[pressure_class]);
> >> +
> >> + if (max_reg_pressure[pressure_class]
> >> + > ira_class_hard_regs_num[pressure_class])
> >> + {
> >> + if (dump_file)
> >> + fprintf (dump_file, "(pressure)\n");
> >> +
> >> + pressure_p = true;
> >>
> >> you can "break;" now.
> >
> > FWIW, I thought the same thing at first, but I think Revital's wayis
better.
> > It's nice to know when looking at dumps whether there is excess
pressure
> > in more than one class. This isn't performance-critical code after
all.
> >
>
> ok
>
> >> however, you have everything setup to compute the amount of spill, so
> >> suggest to do the following instead:
> >>
> >> pressure += max_reg_pressure[pressure_class]
> >> - ira_class_hard_regs_num[pressure_class]);
> >>
> >> or better call the variable "spillage" instead of "pressure", and
> >> return it. Current use will only check if it's zero or positive.
> >
> > I read this suggestion in the same way as Revital seems to have done:
> > that we sum the pressure change over all classes. But that isn't the
idea.
> > Using N too many registers in one pressure class cannot be mitigated by
> > leaving N registers in another pressure class unused.
> >
>
> of-course (wasn't thinking of spilling from one register file to
> another); meant to suggest doing:
>
> if (max_reg_pressure[pressure_class] > ira_class_hard_regs_num
> [pressure_class])
> spillage += max_reg_pressure[pressure_class] -
> ira_class_hard_regs_num[pressure_class]);
>
>
> > TBH, the original version of this function looked better to me.
> >
>
> ok, it would surely suffice for now.
>
Attached is an updated version with the two changes mentioned above taken
from the previous patch.
Tested and bootstrap with the other patch in the series on
ppc64-redhat-linux, enabling SMS on loops with SC 1.
Thanks again,
Revital
2012-01-03 Richard Sandiford
Revital Eres
* loop-invariant.c (get_regno_pressure_class): Move function to...
* ira.c: Here.
* common.opt (fmodulo-sched-reg-pressure, -fmodulo-sched-verbose):
New flags.
* doc/invoke.texi (fmodulo-sched-reg-pressure,
-fmodulo-sched-verbose): Document the flags.
* ira.h (get_regno_pressure_class,
reset_pseudo_classes_defined_p): Declare.
* ira-costs.c (reset_pseudo_classes_defined_p): New function.
* Makefile.in (modulo-sched.o): Include ira.h and modulo-sched.h.
(modulo-sched-pressure.o): New.
* modulo-sched.c (ira.h, modulo-sched.h): New includes.
(partial_schedule_ptr, ps_insn_ptr, struct ps_insn,
struct ps_reg_move_info, struct partial_schedule): Move to
modulo-sched.h.
(ps_rtl_insn, ps_reg_move): Remove static.
(apply_reg_moves): Remove static and call df_insn_rescan only
if PS is final.
(undo_reg_moves): New function.
(sms_schedule): Call register pressure estimation.
* modulo-sched.h: New file.
* modulo-sched-pressure.c: New file.
(See attached file: patch_pressure_3_1_12.txt)Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 182766)
+++ doc/invoke.texi (working copy)
@@ -374,6 +374,7 @@ Objective-C and Objective-C++ Dialects}.
-floop-parallelize-all -flto -flto-compression-level @gol
-flto-partition=@var{alg} -flto-report -fmerge-all-constants @gol
-fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves @gol
+-fmodulo-sched-reg-pressure -fmodulo-sched-verbose=@var{n} @gol
-fmove-loop-invariants fmudflap -fmudflapir -fmudflapth -fno-branch-count-reg
@gol
-fno-default-inline @gol
-fno-defer-pop -fno-function-cse -fno-guess-branch-probability @gol
@@ -6476,6 +6477,16 @@ deleted which will trigger the generatio
life-range analysis. This option is effective only with
@option{-fmodulo-sched} enabled.
+@item -fmodulo-sched-reg-pressure
+@opindex fmodulo-sched-reg-pressure
+Do not apply @option{-fmodulo-sched} to loops if the result would lead
+to register spilling within the loop.
+This option is effective only with @option{-fmodulo-sched} enabled.
+
+@item -fmodulo-sched-verbose=@var{n}
+@opindex fmodulo-sched-verbose
+Set up how verbose dump file for the SMS will be.
+
@item -fno-branch-count-reg
@opindex fno-branch-count-reg
Do not use ``decrement and branch'' instructions on a count
Re: [PATCH] Fix PR tree-optimization/51315
On Mon, Jan 2, 2012 at 8:00 PM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> You are basically (but non-optimally) locally re-implementing
>>> what expr.c:get_object_or_type_alignment does, for the
>>> bare MEM_REF case (you don't consider offsets that
>>> do not change the alignment, nor alignment information
>>> present on the SSA name).
>>
>> Adjusted version attached, regression-tested on SPARC/Solaris. I'll do a
>> full
>> testing cycle if it is OK for mainline.
>>
>> get_object_or_type_alignment doesn't exist on the 4.6 branch, the expanders
>> for
>> MEM_REF and TARGET_MEM_REF do:
>>
>> MAX (TYPE_ALIGN (TREE_TYPE (exp)),
>> get_object_alignment (exp, BIGGEST_ALIGNMENT)))
>>
>> instead, so I presume I should do the same for them in
>> tree_non_aligned_mem_p?
>>
>>
>> 2011-12-07 Eric Botcazou
>>
>> PR tree-optimization/51315
>> * tree.h (get_object_or_type_alignment): Declare.
>> * expr.c (get_object_or_type_alignment): Move to...
>> * builtins.c (get_object_or_type_alignment): ...here. Add assertion.
>> * tree-sra.c (tree_non_mode_aligned_mem_p): Rename to...
>> (tree_non_aligned_mem_p): ...this. Add ALIGN parameter. Look into
>> MEM_REFs and use get_object_or_type_alignment for them.
>> (build_accesses_from_assign): Adjust for above change.
>> (access_precludes_ipa_sra_p): Likewise.
>
> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
> SRA test, but in this case I think it really is showing a genuine problem.
> We have:
>
> struct a {int a,b,c;} a;
> int test(struct a a)
> {
> struct a nasty_local;
> __builtin_memcpy (&nasty_local,&a, sizeof(a));
> return nasty_local.a;
> }
>
> We apply LOCAL_ALIGNMENT to nasty_local during estimated_stack_frame_size,
> so we have a VAR_DECL (nasty_local) with 64-bit alignment and a PARM_DECL
> (a) with 32-bit alignment. This fails the condition:
>
> if (STRICT_ALIGNMENT
> && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
> lacc->grp_unscalarizable_region = 1;
>
> because LHS has 64-bit alignment but RHS has 32-bit alignment.
Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
are BLKmode? I suppose they are, in this case. Or should we truncate
the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
than that to avoid this situation?
I suppose Eric will know which case the expander would handle correctly.
Richard.
> Richard
Re: Fix cross-builds broken from C++-creep
On Tue, Jan 3, 2012 at 5:53 AM, Hans-Peter Nilsson wrote: > All cross-builds are "still" done as C. In C++ you don't need > the missing struct qualifier or the typedef in "typedef struct > gfc_expr ... gfc_expr;" (the struct declaration suffices) as > there's no separate struct namespace IIUC. > > Doesn't this show a bug in the compatibility warning system, or > is that turned off when bootstrapping as C++? It only works the other way around - warn for C when a construct is not compatible with C++. Thus it won't ever catch issues in frontends that are not compiled in stage1. Richard. > > Anyway, committed as obvious after a cris-elf build has passed > the point of failure, which looked as follows (first five lines > of errors). > > ... > gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W > -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common > -DHAVE_CONFIG_H -I. -Ifortran -I/tmp/fail0102-96/gcc/gcc > -I/tmp/fail0102-96/gcc/gcc/fortran -I/tmp/fail0102-96/gcc/gcc/../include > -I/tmp/fail0102-96/gcc/gcc/../libcpp/include -I/tmp/fail0102-96/gccobj/./gmp > -I/tmp/fail0102-96/gcc/gmp -I/tmp/fail0102-96/gccobj/./mpfr > -I/tmp/fail0102-96/gcc/mpfr -I/tmp/fail0102-96/gcc/mpc/src > -I/tmp/fail0102-96/gcc/gcc/../libdecnumber > -I/tmp/fail0102-96/gcc/gcc/../libdecnumber/dpd -I../libdecnumber > /tmp/fail0102-96/gcc/gcc/fortran/arith.c -o fortran/arith.o > In file included from /tmp/fail0102-96/gcc/gcc/fortran/arith.c:31: > /tmp/fail0102-96/gcc/gcc/fortran/gfortran.h:1702: error: expected > specifier-qualifier-list before 'gfc_expr' > /tmp/fail0102-96/gcc/gcc/fortran/arith.c: In function 'gfc_arith_not': > /tmp/fail0102-96/gcc/gcc/fortran/arith.c:418: error: 'gfc_expr' has no member > named 'value' > /tmp/fail0102-96/gcc/gcc/fortran/arith.c:418: error: 'gfc_expr' has no member > named 'value' > /tmp/fail0102-96/gcc/gcc/fortran/arith.c: In function 'gfc_arith_and': > /tmp/fail0102-96/gcc/gcc/fortran/arith.c:432: error: 'gfc_expr' has no member > named 'value' > /tmp/fail0102-96/gcc/gcc/fortran/arith.c:432: error: 'gfc_expr' has no member > named 'value' > > fortran: > * gfortran.h (struct gfc_expr): Add missing "struct" > qualifier for member base_expr. > > Index: gcc/fortran/gfortran.h > === > --- gcc/fortran/gfortran.h (revision 182825) > +++ gcc/fortran/gfortran.h (working copy) > @@ -1699,7 +1699,7 @@ typedef struct gfc_expr > > /* Used to store the base expression in component calls, when the expression > is not a variable. */ > - gfc_expr *base_expr; > + struct gfc_expr *base_expr; > > /* is_boz is true if the integer is regarded as BOZ bitpatten and is_snan > denotes a signalling not-a-number. */ > > brgds, H-P
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou wrote: >> AFAICT, we previously wanted to handle "restart safety" by adding >> abnormal edges to all calls to the TM runtime library (which could in >> turn call the libitm longjmp that actually restarts a transaction). >> Richard mentioned that we could drop this code (I think he meant this, >> and others pieces perhaps) if the returns-twice approach works. > > Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is > thought to be quite a big hammer. Indeed. And I wonder if it really works - given the restrictions on automatic variable use with these functions (IIRC you have to be careful and mark them all 'volatile'). Richard. > -- > Eric Botcazou
Re: [patch] Fix PR tree-optimization/51624
> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY > then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p > will return false (it ICEd in previous releases I believe) and thus you > won't stop attaching COMPONENT_REFs. > > So the fix isn't complete. OK, I see. Then the only way out I can think of is to stop going up the chain of COMPONENT_REFs as soon as the offset becomes negative. > > MEM_REF is nice, but SRA should stop rewriting component accesses that it > > doesn't scalarize, this is waste of time and memory, and introduces bugs. > > I agree - I didn't know it does that. Do you have an example? The very problem I'm debugging: SR.37_109 = it.nam; SR.38_110 = it.typ; What's the point in generating MEM_REF to access a simple component? Of course, this is somewhat hidden since the tree pretty-printer is clever (evil?) enough to print >>, nam> as it.nam but this wastes 2 tree nodes. -- Eric Botcazou
Re: [patch] Fix PR tree-optimization/51624
On Tue, Jan 3, 2012 at 11:16 AM, Eric Botcazou wrote: >> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY >> then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p >> will return false (it ICEd in previous releases I believe) and thus you >> won't stop attaching COMPONENT_REFs. >> >> So the fix isn't complete. > > OK, I see. Then the only way out I can think of is to stop going up the chain > of COMPONENT_REFs as soon as the offset becomes negative. Yeah, that sounds like a better solution. >> > MEM_REF is nice, but SRA should stop rewriting component accesses that it >> > doesn't scalarize, this is waste of time and memory, and introduces bugs. >> >> I agree - I didn't know it does that. Do you have an example? > > The very problem I'm debugging: > > SR.37_109 = it.nam; > SR.38_110 = it.typ; > > What's the point in generating MEM_REF to access a simple component? Of > course, this is somewhat hidden since the tree pretty-printer is clever > (evil?) enough to print > > >>, nam> > > as > > it.nam > > but this wastes 2 tree nodes. Ah. Well - the point is that SRA analyzes accesses using a type, offset, size triple, thus it handles scalarizing unions well even if multiple fields are used from it. But it indeed can as well use the original access tree if it does not change the access (by decomposing it, for example). That's probably a worthwhile change anyway - Martin? Thanks, Richard. > -- > Eric Botcazou
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
On Tue, 2012-01-03 at 09:36 +0100, Eric Botcazou wrote: > > AFAICT, we previously wanted to handle "restart safety" by adding > > abnormal edges to all calls to the TM runtime library (which could in > > turn call the libitm longjmp that actually restarts a transaction). > > Richard mentioned that we could drop this code (I think he meant this, > > and others pieces perhaps) if the returns-twice approach works. > > Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is > thought to be quite a big hammer. I don't know, actually. When I looked at the miscompilation case, all abnormal edges seemed to be in place. @rth: Do you have an idea what could be going wrong? I haven't tried the other thing you sent me, what was it supposed to fix?
[PATCH] Fix PR51070 (again)
This fixes another piece of PR51070 -
stmt_has_scalar_dependences_outside_loop was not handling calls.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther
PR tree-optimization/51070
* tree-loop-distribution.c (stmt_has_scalar_dependences_outside_loop):
Properly handle calls.
* gcc.dg/torture/pr51070-2.c: New testcase.
Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 182829)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -89,8 +89,9 @@ stmt_has_scalar_dependences_outside_loop
switch (gimple_code (stmt))
{
+case GIMPLE_CALL:
case GIMPLE_ASSIGN:
- name = gimple_assign_lhs (stmt);
+ name = gimple_get_lhs (stmt);
break;
case GIMPLE_PHI:
@@ -101,8 +102,10 @@ stmt_has_scalar_dependences_outside_loop
return false;
}
- return TREE_CODE (name) == SSA_NAME
-&& ssa_name_has_uses_outside_loop_p (name, loop_containing_stmt (stmt));
+ return (name
+ && TREE_CODE (name) == SSA_NAME
+ && ssa_name_has_uses_outside_loop_p (name,
+ loop_containing_stmt (stmt)));
}
/* Update the PHI nodes of NEW_LOOP. NEW_LOOP is a duplicate of
Index: gcc/testsuite/gcc.dg/torture/pr51070-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr51070-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr51070-2.c(revision 0)
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-inline" } */
+
+int
+func_4 (int si1, int si2)
+{
+ return si1;
+}
+
+int
+func_14 (int left, int right)
+{
+ return 1;
+}
+
+int
+func_37 (int left, int right)
+{
+ return left;
+}
+
+int g_92[1024];
+int g_95[1024];
+int g_224;
+int g_352[1024];
+int
+func_9 ()
+{
+ for (; g_224; g_224 += 1)
+{
+ g_95[0] = func_4 (func_37 (g_92[g_224], 0), 0);
+ g_92[g_224] = 0, g_352[g_224] = func_14 (0, 0);
+}
+ return 0;
+}
[PATCH] Fix PR51692
This fixes PR51692, we shouldn't remove the lhs of allocation
calls before the special malloc/free pair removal code kicks in.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-01-03 Richard Guenther
PR tree-optimization/51692
* tree-ssa-dce.c (eliminate_unnecessary_stmts): Do not remove
the LHS of allocation stmts.
* gcc.dg/torture/pr51692.c: New testcase.
Index: gcc/tree-ssa-dce.c
===
--- gcc/tree-ssa-dce.c (revision 182829)
+++ gcc/tree-ssa-dce.c (working copy)
@@ -1329,31 +1329,38 @@ eliminate_unnecessary_stmts (void)
}
else if (is_gimple_call (stmt))
{
- call = gimple_call_fndecl (stmt);
- if (call)
- {
- tree name;
+ tree name = gimple_call_lhs (stmt);
- /* When LHS of var = call (); is dead, simplify it into
-call (); saving one operand. */
- name = gimple_call_lhs (stmt);
- if (name && TREE_CODE (name) == SSA_NAME
- && !TEST_BIT (processed, SSA_NAME_VERSION (name)))
- {
- something_changed = true;
- if (dump_file && (dump_flags & TDF_DETAILS))
- {
- fprintf (dump_file, "Deleting LHS of call: ");
- print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
- fprintf (dump_file, "\n");
- }
+ notice_special_calls (stmt);
- gimple_call_set_lhs (stmt, NULL_TREE);
- maybe_clean_or_replace_eh_stmt (stmt, stmt);
- update_stmt (stmt);
- release_ssa_name (name);
+ /* When LHS of var = call (); is dead, simplify it into
+call (); saving one operand. */
+ if (name
+ && TREE_CODE (name) == SSA_NAME
+ && !TEST_BIT (processed, SSA_NAME_VERSION (name))
+ /* Avoid doing so for allocation calls which we
+did not mark as necessary, it will confuse the
+special logic we apply to malloc/free pair removal. */
+ && (!(call = gimple_call_fndecl (stmt))
+ || DECL_BUILT_IN_CLASS (call) != BUILT_IN_NORMAL
+ || (DECL_FUNCTION_CODE (call) != BUILT_IN_MALLOC
+ && DECL_FUNCTION_CODE (call) != BUILT_IN_CALLOC
+ && DECL_FUNCTION_CODE (call) != BUILT_IN_ALLOCA
+ && (DECL_FUNCTION_CODE (call)
+ != BUILT_IN_ALLOCA_WITH_ALIGN
+ {
+ something_changed = true;
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file, "Deleting LHS of call: ");
+ print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
+ fprintf (dump_file, "\n");
}
- notice_special_calls (stmt);
+
+ gimple_call_set_lhs (stmt, NULL_TREE);
+ maybe_clean_or_replace_eh_stmt (stmt, stmt);
+ update_stmt (stmt);
+ release_ssa_name (name);
}
}
}
Index: gcc/testsuite/gcc.dg/torture/pr51692.c
===
--- gcc/testsuite/gcc.dg/torture/pr51692.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr51692.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+int
+main ()
+{
+ volatile double d = 0.0;
+ double *p = __builtin_calloc (1, sizeof (double));
+ d += 1.0;
+ *p += 2.0;
+ __builtin_free (p);
+ return 0;
+}
+
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
On Tue, 2012-01-03 at 10:41 +0100, Richard Guenther wrote: > On Tue, Jan 3, 2012 at 9:36 AM, Eric Botcazou wrote: > >> AFAICT, we previously wanted to handle "restart safety" by adding > >> abnormal edges to all calls to the TM runtime library (which could in > >> turn call the libitm longjmp that actually restarts a transaction). > >> Richard mentioned that we could drop this code (I think he meant this, > >> and others pieces perhaps) if the returns-twice approach works. > > > > Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is > > thought to be quite a big hammer. > > Indeed. And I wonder if it really works - given the restrictions on automatic > variable use with these functions (IIRC you have to be careful and mark them > all 'volatile'). Well, every variable that does get its address taken will have its accesses re-routed through libitm, so those locations will be handled properly using undo-logging and rollback by libitm. For everything that is only on the stack or in registers, it should work too because we don't reuse the stack slots that cross the transaction begin, so we always have those values available as a snapshot. Also, the (non-working?) abnormal edges are still active in what I tried, so perhaps there's some overlap there.
Re: [PATCH, ia64]: Fix PR 51681, ICE in gcc.dg/torture/vshuf-v2si.c (+ more)
On Mon, Jan 2, 2012 at 9:31 PM, Richard Henderson wrote: > On 01/03/2012 06:47 AM, Uros Bizjak wrote: >> if (d->testing_p) >> return true; >> >> + hi = shift < nelt ? d->op1 : d->op0; >> + lo = shift < nelt ? d->op0 : d->op1; >> + >> + shift %= nelt; > > This bit only works for little-endian. It's why I had that assert > for shift range 1-63, for one thing. > > I guess an extra check for big-endian before the loop could fix that. > I.e. > > shift = d->perm[0]; > + if (BYTES_BIG_ENDIAN && shift > nelt) > + return false; I tried to investigate -mbig-endian a bit, but unfortunately almost all gcc.dg/torture/vshuf-*.c tests FAIL with -O2 on unpatched gcc. Tests pass with -O0, though. Due to this, I committed only the obvious part of the patch, that is: 2012-01-02 Uros Bizjak * config/ia64/ia64.c (expand_vec_perm_broadcast): Use correct operands for extzv pattern. Uros.
[patch] Fix PR tree-optimization/51269
Hi,
As described in PR 51269, the vectorizer adjusts number of prologue loop
iterations according to cost model, but never uses the result. This happens
because the result is not returned from the function that computes it, and
is, therefore, ignored.
Bootstrapped and tested on powerpc64-suse-linux.
I am going to commit it shortly.
Ira
ChangeLog:
PR tree-optimization/51269
* tree-vect-loop-manip.c (set_prologue_iterations): Make
first_niters
a pointer.
(slpeel_tree_peel_loop_to_edge): Likewise.
(vect_do_peeling_for_loop_bound): Update call to
slpeel_tree_peel_loop_to_edge.
(vect_gen_niters_for_prolog_loop): Don't compute wide_prolog_niters
here. Remove it from the parameters list.
(vect_do_peeling_for_alignment): Update calls and compute
wide_prolog_niters.
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c (revision 182833)
+++ tree-vect-loop-manip.c (working copy)
@@ -1037,7 +1037,7 @@ slpeel_verify_cfg_after_peeling (struct loop *firs
static void
set_prologue_iterations (basic_block bb_before_first_loop,
-tree first_niters,
+tree *first_niters,
struct loop *loop,
unsigned int th)
{
@@ -1100,9 +1100,9 @@ set_prologue_iterations (basic_block bb_before_fir
newphi = create_phi_node (var, bb_before_first_loop);
add_phi_arg (newphi, prologue_after_cost_adjust_name, e_fallthru,
UNKNOWN_LOCATION);
- add_phi_arg (newphi, first_niters, e_false, UNKNOWN_LOCATION);
+ add_phi_arg (newphi, *first_niters, e_false, UNKNOWN_LOCATION);
- first_niters = PHI_RESULT (newphi);
+ *first_niters = PHI_RESULT (newphi);
}
/* Function slpeel_tree_peel_loop_to_edge.
@@ -1158,7 +1158,7 @@ set_prologue_iterations (basic_block bb_before_fir
static struct loop*
slpeel_tree_peel_loop_to_edge (struct loop *loop,
- edge e, tree first_niters,
+ edge e, tree *first_niters,
tree niters, bool update_first_loop_count,
unsigned int th, bool check_profitability,
tree cond_expr, gimple_seq
cond_expr_stmt_list)
@@ -1328,8 +1328,8 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
if (!update_first_loop_count)
{
pre_condition =
- fold_build2 (LE_EXPR, boolean_type_node, first_niters,
-build_int_cst (TREE_TYPE (first_niters), 0));
+ fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
+build_int_cst (TREE_TYPE (*first_niters), 0));
if (check_profitability)
{
tree scalar_loop_iters
@@ -1360,8 +1360,8 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
loop, th);
pre_condition =
- fold_build2 (LE_EXPR, boolean_type_node, first_niters,
-build_int_cst (TREE_TYPE (first_niters), 0));
+ fold_build2 (LE_EXPR, boolean_type_node, *first_niters,
+build_int_cst (TREE_TYPE (*first_niters), 0));
}
skip_e = slpeel_add_loop_guard (bb_before_first_loop, pre_condition,
@@ -1402,7 +1402,7 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
bb_after_second_loop = split_edge (single_exit (second_loop));
pre_condition =
- fold_build2 (EQ_EXPR, boolean_type_node, first_niters, niters);
+ fold_build2 (EQ_EXPR, boolean_type_node, *first_niters, niters);
skip_e = slpeel_add_loop_guard (bb_between_loops, pre_condition, NULL,
bb_after_second_loop,
bb_before_first_loop);
slpeel_update_phi_nodes_for_guard2 (skip_e, second_loop,
@@ -1411,7 +1411,7 @@ slpeel_tree_peel_loop_to_edge (struct loop *loop,
/* 4. Make first-loop iterate FIRST_NITERS times, if requested.
*/
if (update_first_loop_count)
-slpeel_make_loop_iterate_ntimes (first_loop, first_niters);
+slpeel_make_loop_iterate_ntimes (first_loop, *first_niters);
BITMAP_FREE (definitions);
delete_update_ssa ();
@@ -1925,7 +1925,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
}
new_loop = slpeel_tree_peel_loop_to_edge (loop, single_exit (loop),
-ratio_mult_vf_name, ni_name,
false,
+&ratio_mult_vf_name, ni_name,
false,
th, check_profitability,
cond_expr,
cond_expr_stmt_list);
gcc_assert (new_loop);
@@ -1988,8 +1988,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop
use TYPE_VECTOR_SUBPARTS. */
static tree
-vect_gen_niters_for_prolog_loop (loop_vec_info loop_vinfo, tree
loop_niters,
-tree *wide_prolog_niters)
+vect_gen_niters_for_prolog_loop (loop_vec_info loop_vinf
Re: [PATCH] Fix PR tree-optimization/51315
> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
> SRA test, but in this case I think it really is showing a genuine problem.
> We have:
>
> struct a {int a,b,c;} a;
> int test(struct a a)
> {
> struct a nasty_local;
> __builtin_memcpy (&nasty_local,&a, sizeof(a));
> return nasty_local.a;
> }
>
> We apply LOCAL_ALIGNMENT to nasty_local during estimated_stack_frame_size,
> so we have a VAR_DECL (nasty_local) with 64-bit alignment and a PARM_DECL
> (a) with 32-bit alignment. This fails the condition:
>
> if (STRICT_ALIGNMENT
> && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
> lacc->grp_unscalarizable_region = 1;
>
> because LHS has 64-bit alignment but RHS has 32-bit alignment.
Do you mean that the patch pessimizes this case? If so, yes, this is known, I
ran into similar cases in Ada (we do this kind of local alignment promotion).
The patch is conservative but, given the number of problems we have with SRA on
strict-alignment platforms, we need to draw a line somewhere. But if you think
that optimizing this kind of memcpy calls is worth the hassle, then let's try
harder. We have:
MEM[(char * {ref-all})&nasty_local] = MEM[(char * {ref-all})&a];
and SRA now refuses to scalarize this on the ground that the LHS has 64-bit
alignment so SRA could generate a 64-bit aligned load-store, which would break
since the RHS only has 32-bit alignment. This is meant for cases like:
struct a {int a,b,c;} a;
struct __attribute__((packed)) b { struct a f; }
int test(struct b b)
{
struct a nasty_local;
__builtin_memcpy (&nasty_local, &b.f, sizeof(a));
return nasty_local.a;
}
where you cannot scalarize (even without alignment promotion). I can propose
an alignment cap to that of the access type:
Index: tree-sra.c
===
--- tree-sra.c (revision 182780)
+++ tree-sra.c (working copy)
@@ -1124,7 +1124,9 @@ build_accesses_from_assign (gimple stmt)
{
lacc->grp_assignment_write = 1;
if (STRICT_ALIGNMENT
- && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
+ && tree_non_aligned_mem_p (rhs,
+MIN (TYPE_ALIGN (lacc->type),
+ get_object_alignment (lhs
lacc->grp_unscalarizable_region = 1;
}
@@ -1135,7 +1137,9 @@ build_accesses_from_assign (gimple stmt)
&& !is_gimple_reg_type (racc->type))
bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
if (STRICT_ALIGNMENT
- && tree_non_aligned_mem_p (lhs, get_object_alignment (rhs)))
+ && tree_non_aligned_mem_p (lhs,
+MIN (TYPE_ALIGN (racc->type),
+ get_object_alignment (rhs
racc->grp_unscalarizable_region = 1;
}
on the grounds that sub-accesses shouldn't be more aligned. I think this
should be OK but, well...
--
Eric Botcazou
Re: [PATCH] Fix PR51650
On Mon, 2 Jan 2012, Jason Merrill wrote:
> On 01/02/2012 10:49 AM, Richard Guenther wrote:
> > For the idea creating the DIE at the point we process the limbo DIE
> > yes. But would you consider doing that unconditional or only for LTO?
>
> Unconditional. Anything that already passed the assert should be unaffected
> by the change.
There is a change in case the context is a FUNCTION_DECL or a
NAMESPACE_DECL and the DIE for it is not already present. Previously
we'd add the DIE to comp_unit_die (), now we are going to create
a DIE for the function/namespace (which sounds better anyway,
or if that was not supposed to happen we should have asserted that).
> > I can certainly give it a shot. Just to check, do you mean the
> > following?
>
> Yes.
Ok, I committed the following.
[LTO] Bootstrapped and tested on x86_64-unknown-linux-gnu, SPEC 2k6
LTO build tested.
Richard.
2012-01-03 Richard Guenther
PR debug/51650
* dwarf2out.c (dwarf2out_finish): Always create a DIE for
the context of a limbo DIE when it does not already exist.
* g++.dg/lto/pr51650-3_0.C: New testcase.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 182784)
+++ gcc/dwarf2out.c (working copy)
@@ -22501,15 +22501,8 @@ dwarf2out_finish (const char *filename)
else if (TYPE_P (node->created_for))
context = TYPE_CONTEXT (node->created_for);
- gcc_assert (context
- && (TREE_CODE (context) == FUNCTION_DECL
- || TREE_CODE (context) == NAMESPACE_DECL));
-
- origin = lookup_decl_die (context);
- if (origin)
- add_child_die (origin, die);
- else
- add_child_die (comp_unit_die (), die);
+ origin = get_context_die (context);
+ add_child_die (origin, die);
}
}
}
Index: gcc/testsuite/g++.dg/lto/pr51650-3_0.C
===
--- gcc/testsuite/g++.dg/lto/pr51650-3_0.C (revision 0)
+++ gcc/testsuite/g++.dg/lto/pr51650-3_0.C (revision 0)
@@ -0,0 +1,20 @@
+// { dg-lto-do link }
+// { dg-lto-options { { -flto -g } } }
+
+struct T;
+struct C
+{
+typedef ::T T;
+virtual void E();
+static T *m ()
+ {
+ static T *d;
+ return d;
+ }
+};
+int
+fn ()
+{
+ C::m ();
+}
+int main() {}
Re: [PATCH] Fix PR tree-optimization/51315
> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
> are BLKmode? I suppose they are, in this case. Or should we truncate
> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
> than that to avoid this situation?
Sorry, I didn't read your message before sending mine. Yes, the alignment cap
appears to be the best solution, but of course TYPE_ALIGN (access->type) won't
work (that was the original code), so TYPE_ALIGN (TREE_TYPE (access->base)):
Index: tree-sra.c
===
--- tree-sra.c (revision 182780)
+++ tree-sra.c (working copy)
@@ -1124,7 +1124,9 @@ build_accesses_from_assign (gimple stmt)
{
lacc->grp_assignment_write = 1;
if (STRICT_ALIGNMENT
- && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
+ && tree_non_aligned_mem_p (rhs,
+MIN (TYPE_ALIGN (TREE_TYPE (lacc->base)),
+ get_object_alignment (lhs
lacc->grp_unscalarizable_region = 1;
}
@@ -1135,7 +1137,9 @@ build_accesses_from_assign (gimple stmt)
&& !is_gimple_reg_type (racc->type))
bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
if (STRICT_ALIGNMENT
- && tree_non_aligned_mem_p (lhs, get_object_alignment (rhs)))
+ && tree_non_aligned_mem_p (lhs,
+MIN (TYPE_ALIGN (TREE_TYPE (racc->base)),
+ get_object_alignment (rhs
racc->grp_unscalarizable_region = 1;
}
--
Eric Botcazou
Re: [PATCH] Fix PR tree-optimization/51315
Eric Botcazou writes:
>> Sorry for the late notice, but this regressed memcpy-1.c for n32 and n64
>> on mips64-linux-gnu. I realise memcpy-1.c isn't viewed as being a proper
>> SRA test, but in this case I think it really is showing a genuine problem.
>> We have:
>>
>> struct a {int a,b,c;} a;
>> int test(struct a a)
>> {
>> struct a nasty_local;
>> __builtin_memcpy (&nasty_local,&a, sizeof(a));
>> return nasty_local.a;
>> }
>>
>> We apply LOCAL_ALIGNMENT to nasty_local during estimated_stack_frame_size,
>> so we have a VAR_DECL (nasty_local) with 64-bit alignment and a PARM_DECL
>> (a) with 32-bit alignment. This fails the condition:
>>
>> if (STRICT_ALIGNMENT
>>&& tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
>> lacc->grp_unscalarizable_region = 1;
>>
>> because LHS has 64-bit alignment but RHS has 32-bit alignment.
>
> Do you mean that the patch pessimizes this case?
Yeah.
> If so, yes, this is known, I ran into similar cases in Ada (we do this
> kind of local alignment promotion).
OK. But passing small structures by value doesn't seem that rare --
especially in C++ -- and it doesn't feel right to disable SRA just because
the backend likes to increase the alignment of stack vars. So...
> Index: tree-sra.c
> ===
> --- tree-sra.c (revision 182780)
> +++ tree-sra.c (working copy)
> @@ -1124,7 +1124,9 @@ build_accesses_from_assign (gimple stmt)
> {
>lacc->grp_assignment_write = 1;
>if (STRICT_ALIGNMENT
> - && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
> + && tree_non_aligned_mem_p (rhs,
> +MIN (TYPE_ALIGN (lacc->type),
> + get_object_alignment (lhs
> lacc->grp_unscalarizable_region = 1;
> }
>
> @@ -1135,7 +1137,9 @@ build_accesses_from_assign (gimple stmt)
> && !is_gimple_reg_type (racc->type))
> bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
>if (STRICT_ALIGNMENT
> - && tree_non_aligned_mem_p (lhs, get_object_alignment (rhs)))
> + && tree_non_aligned_mem_p (lhs,
> +MIN (TYPE_ALIGN (racc->type),
> + get_object_alignment (rhs
> racc->grp_unscalarizable_region = 1;
> }
>
> on the grounds that sub-accesses shouldn't be more aligned. I think this
> should be OK but, well...
...something like this sounds good, although you seem less than happy
with it :-)
(I suppose we shouldn't literally use MIN on get_object_alignment,
since it's a bit too expensive to evaluate twice.)
Richard
Re: [PATCH] Fix PR tree-optimization/51315
On Tue, Jan 3, 2012 at 12:26 PM, Eric Botcazou wrote:
>> Shouldn't we go back and unconditionally return false if lhs and (or?) rhs
>> are BLKmode? I suppose they are, in this case. Or should we truncate
>> the alignment from get_object_alignment to TYPE_ALIGN if it is bigger
>> than that to avoid this situation?
>
> Sorry, I didn't read your message before sending mine. Yes, the alignment cap
> appears to be the best solution, but of course TYPE_ALIGN (access->type) won't
> work (that was the original code), so TYPE_ALIGN (TREE_TYPE (access->base)):
>
> Index: tree-sra.c
> ===
> --- tree-sra.c (revision 182780)
> +++ tree-sra.c (working copy)
> @@ -1124,7 +1124,9 @@ build_accesses_from_assign (gimple stmt)
> {
> lacc->grp_assignment_write = 1;
> if (STRICT_ALIGNMENT
> - && tree_non_aligned_mem_p (rhs, get_object_alignment (lhs)))
> + && tree_non_aligned_mem_p (rhs,
> + MIN (TYPE_ALIGN (TREE_TYPE (lacc->base)),
> + get_object_alignment (lhs
> lacc->grp_unscalarizable_region = 1;
> }
>
> @@ -1135,7 +1137,9 @@ build_accesses_from_assign (gimple stmt)
> && !is_gimple_reg_type (racc->type))
> bitmap_set_bit (should_scalarize_away_bitmap, DECL_UID (racc->base));
> if (STRICT_ALIGNMENT
> - && tree_non_aligned_mem_p (lhs, get_object_alignment (rhs)))
> + && tree_non_aligned_mem_p (lhs,
> + MIN (TYPE_ALIGN (TREE_TYPE (racc->base)),
> + get_object_alignment (rhs
> racc->grp_unscalarizable_region = 1;
I suppose we should move this logic to tree_non_aligned_mem_p, maybe
renaming it to tree_non_matching_align_mems_p or so, thus passing
down both lhs and rhs.
But I agree - let's sort out correctness issues first, then try to address the
missed optimizations we caused by that.
Richard.
> }
>
> --
> Eric Botcazou
Re: [PATCH, ia64]: Fix PR 51681, ICE in gcc.dg/torture/vshuf-v2si.c (+ more)
On Tue, Jan 3, 2012 at 11:50 AM, Uros Bizjak wrote: > On Mon, Jan 2, 2012 at 9:31 PM, Richard Henderson wrote: >> On 01/03/2012 06:47 AM, Uros Bizjak wrote: >>> if (d->testing_p) >>> return true; >>> >>> + hi = shift < nelt ? d->op1 : d->op0; >>> + lo = shift < nelt ? d->op0 : d->op1; >>> + >>> + shift %= nelt; >> >> This bit only works for little-endian. It's why I had that assert >> for shift range 1-63, for one thing. >> >> I guess an extra check for big-endian before the loop could fix that. >> I.e. >> >> shift = d->perm[0]; >> + if (BYTES_BIG_ENDIAN && shift > nelt) >> + return false; > > I tried to investigate -mbig-endian a bit, but unfortunately almost > all gcc.dg/torture/vshuf-*.c tests FAIL with -O2 on unpatched gcc. > Tests pass with -O0, though. ATM, we have gcc.dg/torture/vshuf*.c: Native configuration is ia64-unknown-linux-gnu === gcc tests === Running target unix FAIL: gcc.dg/torture/vshuf-v2si.c -O2 (internal compiler error) FAIL: gcc.dg/torture/vshuf-v2si.c -O2 (test for excess errors) UNRESOLVED: gcc.dg/torture/vshuf-v2si.c -O2 compilation failed to produce executable === gcc Summary for unix === # of expected passes30 # of unexpected failures2 # of unresolved testcases 1 # of unsupported tests 112 Running target unix/-mbig-endian FAIL: gcc.dg/torture/vshuf-v16hi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v16qi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v2sf.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v2si.c -O2 (internal compiler error) FAIL: gcc.dg/torture/vshuf-v2si.c -O2 (test for excess errors) UNRESOLVED: gcc.dg/torture/vshuf-v2si.c -O2 compilation failed to produce executable FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v4hi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v4sf.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v4si.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v8hi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test FAIL: gcc.dg/torture/vshuf-v8si.c -O2 execution test === gcc Summary for unix/-mbig-endian === # of expected passes20 # of unexpected failures12 # of unresolved testcases 1 # of unsupported tests 112 === gcc Summary === # of expected passes50 # of unexpected failures14 # of unresolved testcases 2 # of unsupported tests 224 /home/uros/gcc-build/gcc/xgcc version 4.7.0 20120103 (experimental) [trunk revision 182829] (GCC) Uros.
Re: refine cast in collect2 for AIX, fixing bootstrap
On Jan 2, 2012, at 13:45 , Richard Guenther wrote: > Ok. Thanks Richard.
[PATCH] Use ggc allocated strings instead of malloced for debug macro sections (PR pch/51722)
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus free on them is invalid.
Fixed by making the strings GC allocated all the time.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-01-03 Jakub Jelinek
PR pch/51722
* dwarf2out.c (dwarf2out_start_source_file, dwarf2out_define,
dwarf2out_undef): Allocate e.info using ggc_strdup instead
of xstrdup.
(output_macinfo_op): Don't ggc_strdup fd->filename.
(optimize_macinfo_range): Allocate grp_name using XALLOCAVEC,
then ggc_strdup it. Don't free inc->info or cur->info.
(output_macinfo): Don't free ref->info or file->info.
--- gcc/dwarf2out.c.jj 2012-01-01 19:54:46.0 +0100
+++ gcc/dwarf2out.c 2012-01-03 10:42:01.608744373 +0100
@@ -20549,7 +20549,7 @@ dwarf2out_start_source_file (unsigned in
macinfo_entry e;
e.code = DW_MACINFO_start_file;
e.lineno = lineno;
- e.info = xstrdup (filename);
+ e.info = ggc_strdup (filename);
VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
}
}
@@ -20595,7 +20595,7 @@ dwarf2out_define (unsigned int lineno AT
}
e.code = DW_MACINFO_define;
e.lineno = lineno;
- e.info = xstrdup (buffer);;
+ e.info = ggc_strdup (buffer);
VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
}
}
@@ -20622,7 +20622,7 @@ dwarf2out_undef (unsigned int lineno ATT
}
e.code = DW_MACINFO_undef;
e.lineno = lineno;
- e.info = xstrdup (buffer);
+ e.info = ggc_strdup (buffer);
VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
}
}
@@ -20662,8 +20662,6 @@ output_macinfo_op (macinfo_entry *ref)
{
case DW_MACINFO_start_file:
fd = lookup_filename (ref->info);
- if (fd->filename == ref->info)
- fd->filename = ggc_strdup (fd->filename);
file_num = maybe_emit_file (fd);
dw2_asm_output_data (1, DW_MACINFO_start_file, "Start new file");
dw2_asm_output_data_uleb128 (ref->lineno,
@@ -20802,8 +20800,8 @@ optimize_macinfo_range (unsigned int idx
linebuf_len = strlen (linebuf);
/* The group name format is: wmN.[.]. */
- grp_name = XNEWVEC (char, 4 + encoded_filename_len + linebuf_len + 1
- + 16 * 2 + 1);
+ grp_name = XALLOCAVEC (char, 4 + encoded_filename_len + linebuf_len + 1
++ 16 * 2 + 1);
memcpy (grp_name, DWARF_OFFSET_SIZE == 4 ? "wm4." : "wm8.", 4);
tail = grp_name + 4;
if (encoded_filename_len)
@@ -20824,14 +20822,13 @@ optimize_macinfo_range (unsigned int idx
inc = VEC_index (macinfo_entry, macinfo_table, idx - 1);
inc->code = DW_MACRO_GNU_transparent_include;
inc->lineno = 0;
- inc->info = grp_name;
+ inc->info = ggc_strdup (grp_name);
if (*macinfo_htab == NULL)
*macinfo_htab = htab_create (10, htab_macinfo_hash, htab_macinfo_eq, NULL);
/* Avoid emitting duplicates. */
slot = htab_find_slot (*macinfo_htab, inc, INSERT);
if (*slot != NULL)
{
- free (CONST_CAST (char *, inc->info));
inc->code = 0;
inc->info = NULL;
/* If such an entry has been used before, just emit
@@ -20846,7 +20843,6 @@ optimize_macinfo_range (unsigned int idx
i++)
{
cur->code = 0;
- free (CONST_CAST (char *, cur->info));
cur->info = NULL;
}
}
@@ -20909,7 +20905,6 @@ output_macinfo (void)
if (!VEC_empty (macinfo_entry, files))
{
macinfo_entry *file = VEC_last (macinfo_entry, files);
- free (CONST_CAST (char *, file->info));
VEC_pop (macinfo_entry, files);
}
break;
@@ -20939,10 +20934,6 @@ output_macinfo (void)
break;
}
output_macinfo_op (ref);
- /* For DW_MACINFO_start_file ref->info has been copied into files
-vector. */
- if (ref->code != DW_MACINFO_start_file)
- free (CONST_CAST (char *, ref->info));
ref->info = NULL;
ref->code = 0;
}
@@ -20976,7 +20967,6 @@ output_macinfo (void)
ref->lineno);
ASM_OUTPUT_LABEL (asm_out_file, label);
ref->code = 0;
- free (CONST_CAST (char *, ref->info));
ref->info = NULL;
dw2_asm_output_data (2, 4, "DWARF macro version number");
if (DWARF_OFFSET_SIZE == 8)
@@ -20989,7 +20979,6 @@ output_macinfo (void)
case DW_MACINFO_undef:
output_macinfo_op (ref);
ref->code = 0;
- free (CONST_CAST (char *, ref->info));
ref->info = NULL;
break;
default:
Jakub
Re: [PATCH] Use ggc allocated strings instead of malloced for debug macro sections (PR pch/51722)
On Tue, Jan 3, 2012 at 2:25 PM, Jakub Jelinek wrote:
> Hi!
>
> Referring to malloced strings from GC hashtable macinfo_table entries
> and then freeing them at the end of compilation process is problematic
> with PCH, because without PCH the strings are malloced, but with PCH
> ggc allocated after restore and thus free on them is invalid.
>
> Fixed by making the strings GC allocated all the time.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2012-01-03 Jakub Jelinek
>
> PR pch/51722
> * dwarf2out.c (dwarf2out_start_source_file, dwarf2out_define,
> dwarf2out_undef): Allocate e.info using ggc_strdup instead
> of xstrdup.
> (output_macinfo_op): Don't ggc_strdup fd->filename.
> (optimize_macinfo_range): Allocate grp_name using XALLOCAVEC,
> then ggc_strdup it. Don't free inc->info or cur->info.
> (output_macinfo): Don't free ref->info or file->info.
>
> --- gcc/dwarf2out.c.jj 2012-01-01 19:54:46.0 +0100
> +++ gcc/dwarf2out.c 2012-01-03 10:42:01.608744373 +0100
> @@ -20549,7 +20549,7 @@ dwarf2out_start_source_file (unsigned in
> macinfo_entry e;
> e.code = DW_MACINFO_start_file;
> e.lineno = lineno;
> - e.info = xstrdup (filename);
> + e.info = ggc_strdup (filename);
> VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
> }
> }
> @@ -20595,7 +20595,7 @@ dwarf2out_define (unsigned int lineno AT
> }
> e.code = DW_MACINFO_define;
> e.lineno = lineno;
> - e.info = xstrdup (buffer);;
> + e.info = ggc_strdup (buffer);
> VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
> }
> }
> @@ -20622,7 +20622,7 @@ dwarf2out_undef (unsigned int lineno ATT
> }
> e.code = DW_MACINFO_undef;
> e.lineno = lineno;
> - e.info = xstrdup (buffer);
> + e.info = ggc_strdup (buffer);
> VEC_safe_push (macinfo_entry, gc, macinfo_table, &e);
> }
> }
> @@ -20662,8 +20662,6 @@ output_macinfo_op (macinfo_entry *ref)
> {
> case DW_MACINFO_start_file:
> fd = lookup_filename (ref->info);
> - if (fd->filename == ref->info)
> - fd->filename = ggc_strdup (fd->filename);
> file_num = maybe_emit_file (fd);
> dw2_asm_output_data (1, DW_MACINFO_start_file, "Start new file");
> dw2_asm_output_data_uleb128 (ref->lineno,
> @@ -20802,8 +20800,8 @@ optimize_macinfo_range (unsigned int idx
> linebuf_len = strlen (linebuf);
>
> /* The group name format is: wmN.[.]. */
> - grp_name = XNEWVEC (char, 4 + encoded_filename_len + linebuf_len + 1
> - + 16 * 2 + 1);
> + grp_name = XALLOCAVEC (char, 4 + encoded_filename_len + linebuf_len + 1
> + + 16 * 2 + 1);
> memcpy (grp_name, DWARF_OFFSET_SIZE == 4 ? "wm4." : "wm8.", 4);
> tail = grp_name + 4;
> if (encoded_filename_len)
> @@ -20824,14 +20822,13 @@ optimize_macinfo_range (unsigned int idx
> inc = VEC_index (macinfo_entry, macinfo_table, idx - 1);
> inc->code = DW_MACRO_GNU_transparent_include;
> inc->lineno = 0;
> - inc->info = grp_name;
> + inc->info = ggc_strdup (grp_name);
> if (*macinfo_htab == NULL)
> *macinfo_htab = htab_create (10, htab_macinfo_hash, htab_macinfo_eq,
> NULL);
> /* Avoid emitting duplicates. */
> slot = htab_find_slot (*macinfo_htab, inc, INSERT);
> if (*slot != NULL)
> {
> - free (CONST_CAST (char *, inc->info));
> inc->code = 0;
> inc->info = NULL;
> /* If such an entry has been used before, just emit
> @@ -20846,7 +20843,6 @@ optimize_macinfo_range (unsigned int idx
> i++)
> {
> cur->code = 0;
> - free (CONST_CAST (char *, cur->info));
> cur->info = NULL;
> }
> }
> @@ -20909,7 +20905,6 @@ output_macinfo (void)
> if (!VEC_empty (macinfo_entry, files))
> {
> macinfo_entry *file = VEC_last (macinfo_entry, files);
> - free (CONST_CAST (char *, file->info));
> VEC_pop (macinfo_entry, files);
> }
> break;
> @@ -20939,10 +20934,6 @@ output_macinfo (void)
> break;
> }
> output_macinfo_op (ref);
> - /* For DW_MACINFO_start_file ref->info has been copied into files
> - vector. */
> - if (ref->code != DW_MACINFO_start_file)
> - free (CONST_CAST (char *, ref->info));
> ref->info = NULL;
> ref->code = 0;
> }
> @@ -20976,7 +20967,6 @@ output_macinfo (void)
> ref->lineno);
> ASM_OUTPUT_LABEL (asm_out_file, label);
> ref->code = 0;
> - free (CONST_CAST (char *, ref->info));
> ref->info = NULL;
> dw2_asm_output_data (2, 4, "DWARF macro version number");
> if (DWARF_OFFSET_SIZE == 8)
> @@ -20989,7 +20979,6 @@ output_macinfo (void)
> case DW_MACINFO_undef:
> output_macinfo_op (ref);
> ref->code = 0;
> - free (CONST
[C++ Patch] PR 29273
Hi,
in this issue, filed by Martin Sebor and confirmed at the time by the
EDG people (indeed ICC accepts the testcase), we reject an array as
source v of a dynamic_cast, because we don't decay it to pointer, as we
should when T is a pointer type, per 5, p8 in C++03 about an lvalue
expression as operand of an operator which expects an rvalue (I get
C++11 as not changing anything in terms of decay, modulo talking about
glvalue, prvalue, etc).
I also tweaked a bit the code to make sure that in any case we output
the original v in error messages.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2012-02-03 Paolo Carlini
PR c++/29273
* rtti.c (build_dynamic_cast_1): In case of T a pointer type,
call decay_conversion on v.
/testsuite
2012-02-03 Paolo Carlini
PR c++/29273
* g++.dg/rtti/dyncast5.C: New.
Index: testsuite/g++.dg/rtti/dyncast5.C
===
--- testsuite/g++.dg/rtti/dyncast5.C(revision 0)
+++ testsuite/g++.dg/rtti/dyncast5.C(revision 0)
@@ -0,0 +1,9 @@
+// PR c++/29273
+
+struct A { virtual ~A () { } };
+struct B: A { } b [1];
+
+void foo ()
+{
+ dynamic_cast(b);
+}
Index: cp/rtti.c
===
--- cp/rtti.c (revision 182832)
+++ cp/rtti.c (working copy)
@@ -515,7 +515,7 @@ static tree
build_dynamic_cast_1 (tree type, tree expr, tsubst_flags_t complain)
{
enum tree_code tc = TREE_CODE (type);
- tree exprtype = TREE_TYPE (expr);
+ tree exprtype;
tree dcast_fn;
tree old_expr = expr;
const char *errstr = NULL;
@@ -551,6 +551,9 @@ build_dynamic_cast_1 (tree type, tree expr, tsubst
if (tc == POINTER_TYPE)
{
+ expr = decay_conversion (expr);
+ exprtype = TREE_TYPE (expr);
+
/* If T is a pointer type, v shall be an rvalue of a pointer to
complete class type, and the result is an rvalue of type T. */
@@ -576,7 +579,7 @@ build_dynamic_cast_1 (tree type, tree expr, tsubst
{
expr = mark_lvalue_use (expr);
- exprtype = build_reference_type (exprtype);
+ exprtype = build_reference_type (TREE_TYPE (expr));
/* T is a reference type, v shall be an lvalue of a complete class
type, and the result is an lvalue of the type referred to by T. */
@@ -764,7 +767,7 @@ build_dynamic_cast_1 (tree type, tree expr, tsubst
fail:
if (complain & tf_error)
error ("cannot dynamic_cast %qE (of type %q#T) to type %q#T (%s)",
- expr, exprtype, type, errstr);
+ old_expr, TREE_TYPE (old_expr), type, errstr);
return error_mark_node;
}
[PATCH] Fix fallout from fix for PR49651
The fix for PR49651 was too conservative as I noticed when trying
to backport it to the 4.5 branch. The following adjusts it to
preserve the optimization cases we have in the tree-ssa testsuite.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-03 Richard Guenther
PR tree-optimization/49651
* tree-ssa-structalias.c (type_can_have_subvars): New function.
(var_can_have_subvars): Use it.
(get_constraint_for_1): Only consider subfields if there
can be any.
* gcc.dg/tree-ssa/pta-ptrarith-1.c: Adjust.
* gcc.dg/tree-ssa/pta-ptrarith-2.c: Likewise.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 182838)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -303,6 +303,7 @@ static varinfo_t first_vi_for_offset (va
static varinfo_t first_or_preceding_vi_for_offset (varinfo_t,
unsigned HOST_WIDE_INT);
static varinfo_t lookup_vi_for_tree (tree);
+static inline bool type_can_have_subvars (const_tree);
/* Pool of variable info structures. */
static alloc_pool variable_info_pool;
@@ -3275,7 +3276,8 @@ get_constraint_for_1 (tree t, VEC (ce_s,
return;
cs = *VEC_last (ce_s, *results);
- if (cs.type == DEREF)
+ if (cs.type == DEREF
+ && type_can_have_subvars (TREE_TYPE (t)))
{
/* For dereferences this means we have to defer it
to solving time. */
@@ -5043,6 +5045,15 @@ sort_fieldstack (VEC(fieldoff_s,heap) *f
VEC_qsort (fieldoff_s, fieldstack, fieldoff_compare);
}
+/* Return true if T is a type that can have subvars. */
+
+static inline bool
+type_can_have_subvars (const_tree t)
+{
+ /* Aggregates without overlapping fields can have subvars. */
+ return TREE_CODE (t) == RECORD_TYPE;
+}
+
/* Return true if V is a tree that we can have subvars for.
Normally, this is any aggregate type. Also complex
types which are not gimple registers can have subvars. */
@@ -5058,11 +5069,7 @@ var_can_have_subvars (const_tree v)
if (!DECL_P (v))
return false;
- /* Aggregates without overlapping fields can have subvars. */
- if (TREE_CODE (TREE_TYPE (v)) == RECORD_TYPE)
-return true;
-
- return false;
+ return type_can_have_subvars (TREE_TYPE (v));
}
/* Return true if T is a type that does contain pointers. */
Index: gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c (revision 182838)
+++ gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fno-tree-ccp -fdump-tree-ealias" } */
+/* { dg-options "-O2 -fno-tree-forwprop -fno-tree-ccp -fdump-tree-ealias" } */
extern void abort (void);
struct X {
Index: gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c (revision 182838)
+++ gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fno-tree-ccp -fdump-tree-ealias" } */
+/* { dg-options "-O2 -fno-tree-forwprop -fno-tree-ccp -fdump-tree-ealias" } */
extern void abort (void);
struct X {
Re: PR middle-end/51212: sorry out on -fgnu-tm + -fnon-call-exceptions
On 12/23/11 03:31, Richard Guenther wrote: On Thu, Dec 22, 2011 at 8:47 PM, Aldy Hernandez wrote: The problem here is that with -fnon-call-exceptions, a memory dereference may trap, but when we instrument the store, we have lost the landing pad information. One solution would be to move the EH information to the TM load/store instrumentation builtins, but that doesn't get us around the fact that libitm is not exception safe, and we have no mechanism for taking and exception (and propagating it) in the middle of a transaction. Richard has suggested that another alternative could be to support the exception case for NULL, but non-null faulting memory references would still cause a crash. In this case we would simply test for NULL at the start of the accessors and explicitly throw the exception. And yet a third alternative, is to disable the -fgnu-tm and -fnon-call-exceptions combination. I have implemented this one, as I'd rather have it not work, than work half-way. Torvald, do you have any thoughts on the matter? Attached patch for disabling the feature, if you both agree on this approach. I think this should be documented at the place -fgnu-tm is documented. Richard. I can certainly do this. I am however, waiting for the final approval. It wasn't clear whether that was an approval from Richard Henderson, or whether I should wait for an official ok. OK for mainline?
Re: [C++ Patch] PR 29273
OK. Jason
Re: [PATCH] Use ggc allocated strings instead of malloced for debug macro sections (PR pch/51722)
On 01/03/2012 08:25 AM, Jakub Jelinek wrote:
Hi!
Referring to malloced strings from GC hashtable macinfo_table entries
and then freeing them at the end of compilation process is problematic
with PCH, because without PCH the strings are malloced, but with PCH
ggc allocated after restore and thus free on them is invalid.
Fixed by making the strings GC allocated all the time.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
@@ -20909,7 +20905,6 @@ output_macinfo (void)
if (!VEC_empty (macinfo_entry, files))
{
macinfo_entry *file = VEC_last (macinfo_entry, files);
- free (CONST_CAST (char *, file->info));
VEC_pop (macinfo_entry, files);
}
break;
This breaks bootstrap:
../../trunk/gcc/dwarf2out.c: In function ‘void output_macinfo()’:
../../trunk/gcc/dwarf2out.c:20907:23: error: unused variable ‘file’
[-Werror=unused-variable]
cc1plus: all warnings being treated as errors
I guess it is a way to fix it.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 182848)
+++ gcc/dwarf2out.c (working copy)
@@ -20904,7 +20904,6 @@ output_macinfo (void)
case DW_MACINFO_end_file:
if (!VEC_empty (macinfo_entry, files))
{
- macinfo_entry *file = VEC_last (macinfo_entry, files);
VEC_pop (macinfo_entry, files);
}
break;
Patrick Marlier.
Re: [PATCH] Use ggc allocated strings instead of malloced for debug macro sections (PR pch/51722)
On Tue, Jan 03, 2012 at 10:22:05AM -0500, Patrick Marlier wrote:
> >@@ -20909,7 +20905,6 @@ output_macinfo (void)
> > if (!VEC_empty (macinfo_entry, files))
> > {
> > macinfo_entry *file = VEC_last (macinfo_entry, files);
> >- free (CONST_CAST (char *, file->info));
> > VEC_pop (macinfo_entry, files);
> > }
> > break;
>
> This breaks bootstrap:
> ../../trunk/gcc/dwarf2out.c: In function ‘void output_macinfo()’:
> ../../trunk/gcc/dwarf2out.c:20907:23: error: unused variable ‘file’
> [-Werror=unused-variable]
> cc1plus: all warnings being treated as errors
>
> I guess it is a way to fix it.
Just svn update, I've noticed it in my bootstrap and fixed it
for that, but forgot to update the patch I checked in. Sorry.
Jakub
[patch, Fortran] Fix PR 49693, unused variable warnings in common blocks
Hello world,
the attached patch fixes the PR by unconditionally disabling warnings
about unused variables in common blocks.
The reasons are outlined in the PR; there is quite a lot of unnecessary
clutter caused by common blocks in module interfaces.
Regression-tested. OK for trunk?
Thomas
2012-01-03 Thomas Koenig
PR fortran/49693
* trans-common.c (create_common): Mark variables as
used to avoid warnings about unused variables in common
blocks.
2012-01-03 Thomas Koenig
PR fortran/49693
* gfortran.dg/common_17.f90: New test.
Index: trans-common.c
===
--- trans-common.c (Revision 182754)
+++ trans-common.c (Arbeitskopie)
@@ -689,7 +689,9 @@ create_common (gfc_common_head *com, segment_info
VAR_DECL, DECL_NAME (s->field),
TREE_TYPE (s->field));
TREE_STATIC (var_decl) = TREE_STATIC (decl);
- TREE_USED (var_decl) = TREE_USED (decl);
+ /* Mark the variable as used in order to avoid warnings about
+ unused variables. */
+ TREE_USED (var_decl) = 1;
if (s->sym->attr.use_assoc)
DECL_IGNORED_P (var_decl) = 1;
if (s->sym->attr.target)
! { dg-do compile }
! { dg-options "-Wall" }
! PR fortran/49693 - this used to cause a spurious warning for the
! variable in the common block.
! Original test case by Stephan Kramer.
module foo
implicit none
integer:: a
common a
end module foo
! { dg-final { cleanup-modules "foo" } }
[PATCH] [4.6] shared_ptr needs explicit copy constructor
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only this part should be applied to 4.6. This has been
tested on an x86_64 host with clang 3.0 as the C++ compiler.
PR c++/50500
* Explicitly define default copy constructor for std::shared_ptr
--- a/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180158)
+++ b/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180159)
@@ -211,6 +211,7 @@
* @param __r A %shared_ptr.
* @post get() == __r.get() && use_count() == __r.use_count()
*/
+ shared_ptr(const shared_ptr&) = default; // never throws
template::value>::type>
shared_ptr(const shared_ptr<_Tp1>& __r)
@@ -264,6 +265,7 @@
constexpr shared_ptr(nullptr_t __p)
: __shared_ptr<_Tp>(__p) { }
+ shared_ptr& operator=(const shared_ptr&) = default;
template
shared_ptr&
operator=(const shared_ptr<_Tp1>& __r) // never throws
--- a/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/03/22 15:15:03
171293
+++ b/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/05/18 22:59:17
173882
@@ -799,7 +801,9 @@
: _M_ptr(__p), _M_refcount(__r._M_refcount) // never throws
{ }
- // generated copy constructor, assignment, destructor are fine.
+ __shared_ptr(const __shared_ptr&) = default; // never throws
+ __shared_ptr& operator=(const __shared_ptr&) = default; // never throws
+ ~__shared_ptr() = default;
template::value>::type>
@@ -1216,7 +1220,9 @@
: _M_ptr(0), _M_refcount() // never throws
{ }
- // Generated copy constructor, assignment, destructor are fine.
+ __weak_ptr(const __weak_ptr&) = default; // never throws
+ __weak_ptr& operator=(const __weak_ptr&) = default; // never throws
+ ~__weak_ptr() = default;
// The "obvious" converting constructor implementation:
//
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
Fixing a typo when Cc'ing Matthias Klose.
---
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revision 180159. The rest of the revision includes new
functionality, so only this part should be applied to 4.6. This has been
tested on an x86_64 host with clang 3.0 as the C++ compiler.
PR c++/50500
* Explicitly define default copy constructor for std::shared_ptr
--- a/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180158)
+++ b/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180159)
@@ -211,6 +211,7 @@
* @param __r A %shared_ptr.
* @post get() == __r.get() && use_count() == __r.use_count()
*/
+ shared_ptr(const shared_ptr&) = default; // never throws
template::value>::type>
shared_ptr(const shared_ptr<_Tp1>& __r)
@@ -264,6 +265,7 @@
constexpr shared_ptr(nullptr_t __p)
: __shared_ptr<_Tp>(__p) { }
+ shared_ptr& operator=(const shared_ptr&) = default;
template
shared_ptr&
operator=(const shared_ptr<_Tp1>& __r) // never throws
--- a/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/03/22
15:15:03171293
+++ b/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/05/18
22:59:17173882
@@ -799,7 +801,9 @@
: _M_ptr(__p), _M_refcount(__r._M_refcount) // never throws
{ }
- // generated copy constructor, assignment, destructor are fine.
+ __shared_ptr(const __shared_ptr&) = default; // never throws
+ __shared_ptr& operator=(const __shared_ptr&) = default; // never
throws
+ ~__shared_ptr() = default;
template::value>::type>
@@ -1216,7 +1220,9 @@
: _M_ptr(0), _M_refcount() // never throws
{ }
- // Generated copy constructor, assignment, destructor are fine.
+ __weak_ptr(const __weak_ptr&) = default; // never throws
+ __weak_ptr& operator=(const __weak_ptr&) = default; // never throws
+ ~__weak_ptr() = default;
// The "obvious" converting constructor implementation:
//
Re: [committed] copy-edit -flto documentation
On 01/03/2012 01:18 AM, Eric Botcazou wrote: When I was looking at some LTO-related test failures last week (see mail on gcc@), I found that the many punctuation and grammatical errors in the -flto documentation made this section of the GCC manual hard to read. I made a pass over it to clean up the worst problems -- since the changes don't affect content, I've checked in this patch as "obvious". If you happen to have a 4.6 branch around and the patch can be applied without too many adjustments, please consider applying it on the branch. Done. -Sandra
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 16:23, Chase Douglas wrote: > When compiling with a compiler that is conformant to the c++11 spec for PR > c++/50500, std::shared_ptr must have an explicitly defined copy constructor. This has already been fixed in GCC 4.7, see PR 50500 PR 51699 is another example of Clang failing to compile the 4.6 library, where the changes are already in 4.7
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 16:59, Jonathan Wakely wrote: > On 3 January 2012 16:23, Chase Douglas wrote: >> When compiling with a compiler that is conformant to the c++11 spec for PR >> c++/50500, std::shared_ptr must have an explicitly defined copy constructor. > > This has already been fixed in GCC 4.7, see PR 50500 Doh, sorry - I should have actually read your message! As I said in 51699, I agree with backporting relevant library fixes, so I'm ok with this change. Has it also been testing using G++ 4.6 as the compiler? :)
PR middle-end/51696: display indirect function calls properly for trans-mem
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr->compare();
/* ^^ */
/* error: unsafe function call ‘’ */
compare();
}
This happens because pp_c_tree_decl_identifier() dumps the memory
address when there is no DECL_NAME associated with the symbol.
Instead of displaying something like in this particular error,
perhaps we can display "unsafe indirect function call...".
OK?
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Index: testsuite/gcc.dg/tm/pr51696.c
===
--- testsuite/gcc.dg/tm/pr51696.c (revision 0)
+++ testsuite/gcc.dg/tm/pr51696.c (revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm" } */
+
+struct list {
+ void (*compare)();
+} *listPtr;
+
+static void (*compare)();
+
+__attribute__((transaction_safe))
+static void func () {
+ listPtr->compare(); /* { dg-error "unsafe indirect function call" } */
+ compare(); /* { dg-error "unsafe function call" } */
+}
Index: trans-mem.c
===
--- trans-mem.c (revision 182848)
+++ trans-mem.c (working copy)
@@ -664,9 +664,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"atomic transaction", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "atomic transaction", fn);
+ {
+ if (DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "atomic transaction", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "atomic transaction", fn);
+ }
}
else
{
@@ -675,9 +682,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"% function", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "% function", fn);
+ {
+ if (DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "% function", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "% function", fn);
+ }
}
}
}
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 01/03/2012 12:01 PM, Jonathan Wakely wrote: > On 3 January 2012 16:59, Jonathan Wakely wrote: >> On 3 January 2012 16:23, Chase Douglas wrote: >>> When compiling with a compiler that is conformant to the c++11 >>> spec for PR c++/50500, std::shared_ptr must have an explicitly >>> defined copy constructor. >> >> This has already been fixed in GCC 4.7, see PR 50500 > > Doh, sorry - I should have actually read your message! > > As I said in 51699, I agree with backporting relevant library > fixes, so I'm ok with this change. Has it also been testing using > G++ 4.6 as the compiler? :) Maybe if there was a test case to go with the patch -- Stephen M. Webb
Re: PR middle-end/51696: display indirect function calls properly for trans-mem
On 01/03/12 11:04, Aldy Hernandez wrote:
For the following testcase, we display indirect calls as memory
addresses, which can confuse the user:
struct list {
void (*compare)();
} *listPtr;
static void (*compare)();
__attribute__((transaction_safe))
static void func () {
listPtr->compare();
/* ^^ */
/* error: unsafe function call ‘’ */
compare();
}
This happens because pp_c_tree_decl_identifier() dumps the memory
address when there is no DECL_NAME associated with the symbol.
Instead of displaying something like in this particular error,
perhaps we can display "unsafe indirect function call...".
OK?
Whoops, wrong revision of the patch. Revised one here.
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Index: testsuite/gcc.dg/tm/pr51696.c
===
--- testsuite/gcc.dg/tm/pr51696.c (revision 0)
+++ testsuite/gcc.dg/tm/pr51696.c (revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm" } */
+
+struct list {
+ void (*compare)();
+} *listPtr;
+
+static void (*compare)();
+
+__attribute__((transaction_safe))
+static void func () {
+ listPtr->compare(); /* { dg-error "unsafe indirect function call" } */
+ compare(); /* { dg-error "unsafe function call" } */
+}
Index: trans-mem.c
===
--- trans-mem.c (revision 182848)
+++ trans-mem.c (working copy)
@@ -664,9 +664,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"atomic transaction", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "atomic transaction", fn);
+ {
+ if (DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "atomic transaction", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "atomic transaction");
+ }
}
else
{
@@ -675,9 +682,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"% function", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "% function", fn);
+ {
+ if (DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "% function", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "% function");
+ }
}
}
}
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 17:13, Stephen M. Webb wrote: > On 01/03/2012 12:01 PM, Jonathan Wakely wrote: >> On 3 January 2012 16:59, Jonathan Wakely wrote: >>> On 3 January 2012 16:23, Chase Douglas wrote: When compiling with a compiler that is conformant to the c++11 spec for PR c++/50500, std::shared_ptr must have an explicitly defined copy constructor. >>> >>> This has already been fixed in GCC 4.7, see PR 50500 >> >> Doh, sorry - I should have actually read your message! >> >> As I said in 51699, I agree with backporting relevant library >> fixes, so I'm ok with this change. Has it also been testing using >> G++ 4.6 as the compiler? :) > > Maybe if there was a test case to go with the patch We can't add a testcase that checks that non-G++ compilers compile our shared_ptr, which is what this patch is allowing. If it passes the existing tests in the 4.6 branch then the change is safe for GCC 4.6, and Chase already stated that it works for Clang++ 3.0
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 01/03/2012 09:01 AM, Jonathan Wakely wrote: > On 3 January 2012 16:59, Jonathan Wakely wrote: >> On 3 January 2012 16:23, Chase Douglas wrote: >>> When compiling with a compiler that is conformant to the c++11 spec for PR >>> c++/50500, std::shared_ptr must have an explicitly defined copy constructor. >> >> This has already been fixed in GCC 4.7, see PR 50500 > > Doh, sorry - I should have actually read your message! > > As I said in 51699, I agree with backporting relevant library fixes, > so I'm ok with this change. Has it also been testing using G++ 4.6 as > the compiler? :) I just double checked. We have a library called utouch-frame (http://launchpad.net/utouch-frame). It uses std::shared_ptr all over the place. It also has a test suite that has virtually 100% function coverage, and is tested with a real-world device recording, so it's a mix of unit and integration testing. I rebuilt the library with this change to gcc and ran the test suite. All passed normally. -- Chase
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 18:07, Chase Douglas wrote: > I rebuilt the library with this > change to gcc and ran the test suite. All passed normally. That's what I needed to know, your original mail didn't say anything about running the test suite. Looking at the patch again, why have you added destructors in shared_ptr_base.h? That part of the patch is not backported from the PR 50500 fix, is it needed for Clang++? If so, and G++ doesn't catch the errors, that would imply the fix for 50500 was incomplete and so should be reopened. The ChangeLog is in the wrong format: > PR c++/50500 > * Explicitly define default copy constructor for std::shared_ptr This doesn't name the affected files.
[C++ Patch] PR 51738
Hi,
so this is what I did earlier today to add the missing bits to the
parser. The work turned out to be very easy, maybe too easy? ;) Is there
something I'm missing? I'm also adding a 'dg-do run' library testcase.
Booted and tested x96_64-linux.
Thanks,
Paolo.
///
/gcc/cp
2012-01-03 Paolo Carlini
PR c++/51738
* parser.c (cp_parser_postfix_open_square_expression): Handle
postfix-expression [ braced-init-list ].
/gcc/testsuite
2012-01-03 Paolo Carlini
PR c++/51738
* g++.dg/cpp0x/initlist-postfix-open-square.C: New.
/libstdc++-v3
2012-01-03 Paolo Carlini
PR c++/51738
* testsuite/23_containers/map/element_access/39901.cc: New.
Index: libstdc++-v3/testsuite/23_containers/map/element_access/39901.cc
===
--- libstdc++-v3/testsuite/23_containers/map/element_access/39901.cc
(revision 0)
+++ libstdc++-v3/testsuite/23_containers/map/element_access/39901.cc
(revision 0)
@@ -0,0 +1,42 @@
+// { dg-options "-std=gnu++0x" }
+
+// Copyright (C) 2012 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
+//
[PATCH, testsuite]: Use dg-add-options ieee in gfortran.dg/typebound_operator_8.f03
Hello!
-mieee is needed for this runtime test to avoid
FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test
FAIL: gfortran.dg/typebound_operator_8.f03 -Os execution test
on alpha-linux-gnu.
Probably underflow, or something exceptional, gdb is not a friend with
fortran code on this target:
Program received signal SIGFPE, Arithmetic exception.
0x000120004190 in cartesian_2d_objects::process_cart2d_p (obj=...)
at
/home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03:172
172 process_cart2d_p%c = -sign (obj%c, 1.0)*obj%c** 4
(gdb)
2012-01-03 Uros Bizjak
* gfortran.dg/typebound_operator_8.f03: Use dg-add-options ieee.
Tested on alphaev68-unknown-linux-gnu, committed to mainline SVN.
Uros.
Index: gfortran.dg/typebound_operator_8.f03
===
--- gfortran.dg/typebound_operator_8.f03(revision 182853)
+++ gfortran.dg/typebound_operator_8.f03(working copy)
@@ -1,4 +1,5 @@
! { dg-do run }
+! { dg-add-options ieee }
!
! Solve a diffusion problem using an object-oriented approach
!
Re: [PATCH] [4.6] shared_ptr needs explicit copy constructor
On 01/03/2012 10:13 AM, Jonathan Wakely wrote: > On 3 January 2012 18:07, Chase Douglas wrote: >> I rebuilt the library with this >> change to gcc and ran the test suite. All passed normally. > > That's what I needed to know, your original mail didn't say anything > about running the test suite. > > Looking at the patch again, why have you added destructors in > shared_ptr_base.h? That part of the patch is not backported from the > PR 50500 fix, is it needed for Clang++? If so, and G++ doesn't catch > the errors, that would imply the fix for 50500 was incomplete and so > should be reopened. Sorry, I don't know exactly how that got in there (I did this over a week ago). I thought I did: $ svn diff -c 180159 > patch Then removed all the stuff that did not look salient. I think I then tried to compile, and got errors because __shared_ptr and __weak_ptr also did not have explicitly defined copy constructors. I guess I then found the changes in revision 173882, which also included the destructor change in the same hunk. I have removed the destructor declaration and recompiled my library and tests. The tests ran properly. I'll resend the patch. > The ChangeLog is in the wrong format: > >> PR c++/50500 >> * Explicitly define default copy constructor for std::shared_ptr > > This doesn't name the affected files. Ok. This is my first gcc submission, so I'm still learning :). Thanks! -- Chase
[PATCH] Another canonical cselib_val bootstrap fix (PR bootstrap/51725)
Hi!
My previous patch apparently wasn't enough. If at add_mem_*
time mem_elt is still its own canonical cselib_val, but only afterwards
new_elt_loc_list adds a new canonical cselib_val to it (and moves
over its locs), then we can still crash in cselib_invalidate_mem.
This patch ensures that new_elt_loc_list when moving over the locs also
adds the canonical cselib_val to first_containing_mem list if it
wasn't already there and the old val was (it would be better to
remove it, but the chain is only single linked list and it would be
expensive to remove it there - the next cselib_invalidate_mem
will handle it automatically, as non-canonical values don't have any mem
locs and thus are removed from the chain).
In cselib_invalidate_mem it needs to call canonical_cselib_val on the
addr_list chain elts (those aren't canonicalized by anything).
There is no need to call canonical_cselib_val on v, the new_elt_loc_list
change ensures that the canonical value is in the list always too
and non-canonical values don't have MEM locs.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
cross jc1 to ia64-linux on gnu-CORBA.list compilation. Ok for trunk?
2012-01-03 Jakub Jelinek
PR bootstrap/51725
* cselib.c (new_elt_loc_list): When moving locs from one
cselib_val to its new canonical_cselib_val and the
cselib_val was in first_containing_mem chain, but
the canonical_cselib_val was not, add the latter into the
chain.
(cselib_invalidate_mem): Compare canonical_cselib_val of
addr_list chain elt with v.
--- gcc/cselib.c.jj 2012-01-03 16:22:48.0 +0100
+++ gcc/cselib.c2012-01-03 17:29:10.096229315 +0100
@@ -277,6 +277,12 @@ new_elt_loc_list (cselib_val *val, rtx l
}
el->next = val->locs;
next = val->locs = CSELIB_VAL_PTR (loc)->locs;
+ if (CSELIB_VAL_PTR (loc)->next_containing_mem != NULL
+ && val->next_containing_mem == NULL)
+ {
+ val->next_containing_mem = first_containing_mem;
+ first_containing_mem = val;
+ }
}
/* Chain LOC back to VAL. */
@@ -2211,7 +2217,7 @@ cselib_invalidate_mem (rtx mem_rtx)
mem_chain = &addr->addr_list;
for (;;)
{
- if ((*mem_chain)->elt == v)
+ if (canonical_cselib_val ((*mem_chain)->elt) == v)
{
unchain_one_elt_list (mem_chain);
break;
Jakub
[PATCH v2] [4.6] shared_ptr needs explicit copy constructor
When compiling with a compiler that is conformant to the c++11 spec for PR
c++/50500, std::shared_ptr must have an explicitly defined copy constructor.
Backported from revisions 180159 and 173882. The rest of the revisions include
new functionality, so only this part should be applied to 4.6.
This has been tested on an x86_64 host with g++ 4.6 and clang 3.0 as the C++
compilers. A shared library utilizing std::shared_ptr with an extensive
testsuite has shown no regressions when compiled with g++. Unfortunately, gtest
does not compile under clang, so I cannot verify correct behavior under that
scenario.
PR c++/50500
* include/bits/shared_ptr.h: Add lazy copy ops even if there's a move
* include/bits/shared_ptr_base.h: Define special member functions as defaulted
--- a/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180158)
+++ b/src/libstdc++-v3/include/bits/shared_ptr.h(revision 180159)
@@ -211,6 +211,7 @@
* @param __r A %shared_ptr.
* @post get() == __r.get() && use_count() == __r.use_count()
*/
+ shared_ptr(const shared_ptr&) = default; // never throws
template::value>::type>
shared_ptr(const shared_ptr<_Tp1>& __r)
@@ -264,6 +265,7 @@
constexpr shared_ptr(nullptr_t __p)
: __shared_ptr<_Tp>(__p) { }
+ shared_ptr& operator=(const shared_ptr&) = default;
template
shared_ptr&
operator=(const shared_ptr<_Tp1>& __r) // never throws
--- a/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/03/22 15:15:03
171293
+++ b/src/libstdc++-v3/include/bits/shared_ptr_base.h 2011/05/18 22:59:17
173882
@@ -799,7 +801,8 @@
: _M_ptr(__p), _M_refcount(__r._M_refcount) // never throws
{ }
- // generated copy constructor, assignment, destructor are fine.
+ __shared_ptr(const __shared_ptr&) = default; // never throws
+ __shared_ptr& operator=(const __shared_ptr&) = default; // never throws
template::value>::type>
@@ -1216,7 +1220,8 @@
: _M_ptr(0), _M_refcount() // never throws
{ }
- // Generated copy constructor, assignment, destructor are fine.
+ __weak_ptr(const __weak_ptr&) = default; // never throws
+ __weak_ptr& operator=(const __weak_ptr&) = default; // never throws
// The "obvious" converting constructor implementation:
//
Re: [C++ Patch] PR 51738
OK. Jason
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
On Mon, 2012-01-02 at 19:10 +0100, Torvald Riegel wrote:
> - Do we potentially get unnecessary warnings (if vars are live across
> a transaction begin)? I didn't get such warnings in the STAMP app
> that wasn't working though. Does anyone has suggestions for a test
> case?
Attached is a test that raises a warning. This requires g++ and
-Wclobbered (-Wall is not sufficient), so it might still be okay until
we have a proper solution.
Interestingly (at least to me), I wasn't able to construct a test on my
own (see main2() for my attempts...), but had to web-search for one (see
main()). Is the warning actually supposed to always trigger? We only
seem to have a test for a case where there should be _no_ warning.
/* { dg-do compile } */
/* { dg-options "-fgnu-tm -Wclobbered -O" } */
#include
extern int foo(int);
extern int y;
int main2() {
int i;
int x[123];
int sum = 0;
x[5] += x[6] = 10;
for (i=0; i < 100; i++) {
__transaction_atomic {
y=12;
}
x[i] += x[5] + x[6] + i;
sum += x[i];
}
// and again, without loop.
__transaction_atomic {
y=12;
}
x[i] += x[5] + x[6] + i;
sum += x[i];
return foo(x[x[12]]) + sum;
}
int main() {
std::vector foo(y);
__transaction_atomic { y = 13; }
return 1;
}
Re: PR middle-end/51696: display indirect function calls properly for trans-mem
On 01/04/2012 04:18 AM, Aldy Hernandez wrote: > PR middle-end/51696 > * trans-mem.c (diagnose_tm_1): Display indirect calls with no name > correctly. Ok. r~
[Patch, fortran] PR48946 - Deferred Overloaded Assignment
Dear All,
This is a straightforward patch that adds a last ditch attempt to find
a specific typebound procedure when all that has been found for a
derived type base object is 'deferred'. typebound_operator_7.f03 has
been extended to test derived type as well as class base objects.
Bootstrapped and regtested on x86_64/FC9 - OK for trunk?
Paul
2012-01-03 Paul Thomas
PR fortran/PR48946
* resolve.c (resolve_typebound_static): If the typebound
procedure is 'deferred' have a go at finding the right specific
procedure in the derived type operator space itself.
2012-01-03 Paul Thomas
PR fortran/PR48946
* gfortran.dg/typebound_operator_7.f03: Add test for derived
type typebound operators as well as class bound operators.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 182853)
--- gcc/fortran/resolve.c (working copy)
*** resolve_typebound_static (gfc_expr* e, g
*** 5614,5619
--- 5614,5646
e->ref = NULL;
e->value.compcall.actual = NULL;
+ /* If we find a deferred typebound procedure, check for derived types
+ that an over-riding typebound procedure has not been missed. */
+ if (e->value.compcall.tbp->deferred
+&& e->value.compcall.name
+&& !e->value.compcall.tbp->non_overridable
+&& e->value.compcall.base_object
+&& e->value.compcall.base_object->ts.type == BT_DERIVED)
+{
+ gfc_symtree *st;
+ gfc_symbol *derived;
+
+ /* Use the derived type of the base_object. */
+ derived = e->value.compcall.base_object->ts.u.derived;
+ st = NULL;
+
+ /* Look for the typebound procedure 'name'. */
+ if (derived->f2k_derived && derived->f2k_derived->tb_sym_root)
+ st = gfc_find_symtree (derived->f2k_derived->tb_sym_root,
+ e->value.compcall.name);
+
+ /* Now find the specific name in the derived type namespace. */
+ if (st && st->n.tb && st->n.tb->u.specific)
+ gfc_find_sym_tree (st->n.tb->u.specific->name,
+ derived->ns, 1, &st);
+ if (st)
+ *target = st;
+}
return SUCCESS;
}
Index: gcc/testsuite/gfortran.dg/typebound_operator_7.f03
===
*** gcc/testsuite/gfortran.dg/typebound_operator_7.f03 (revision 182853)
--- gcc/testsuite/gfortran.dg/typebound_operator_7.f03 (working copy)
***
*** 1,5
--- 1,6
! { dg-do run }
! PR46328 - complex expressions involving typebound operators of class objects.
+ ! PR48946 - complex expressions involving typebound operators of derived types.
!
module field_module
implicit none
*** end module
*** 87,103
program main
use i_field_module
implicit none
! class(i_field) ,allocatable :: u
! allocate (u, source = i_field (99))
!
! u = u*2.
! u = (u*2.0*4.0) + u*4.0
! u = u%multiply_real (2.0)*4.0
! u = i_multiply_real (u, 2.0) * 4.0
!
! select type (u)
! type is (i_field); if (u%i .ne. 152064) call abort
! end select
end program
! { dg-final { cleanup-modules "field_module i_field_module" } }
--- 88,118
program main
use i_field_module
implicit none
! call check_class_tbos
! call check_derived_type_tbos
! contains
! subroutine check_class_tbos
! class(i_field) ,allocatable :: u
! allocate (u, source = i_field (99))
! u = u*2.
! u = (u*2.0*4.0) + u*4.0
! u = u%multiply_real (2.0)*4.0
! u = i_multiply_real (u, 2.0) * 4.0
! select type (u)
! type is (i_field); if (u%i .ne. 152064) call abort
! end select
! deallocate (u)
! end subroutine
! subroutine check_derived_type_tbos
! type(i_field) ,allocatable :: u
! allocate (u, source = i_field (99))
! u = u*2.
! u = (u*2.0*4.0) + u*4.0
! u = u%multiply_real (2.0)*4.0
! u = i_multiply_real (u, 2.0) * 4.0
! if (u%i .ne. 152064) call abort
! deallocate (u)
! end subroutine
end program
! { dg-final { cleanup-modules "field_module i_field_module" } }
Re: PR middle-end/51212: sorry out on -fgnu-tm + -fnon-call-exceptions
On 01/04/2012 01:10 AM, Aldy Hernandez wrote: > I can certainly do this. I am however, waiting for the final approval. It > wasn't clear whether that was an approval from Richard Henderson, or whether > I should wait for an official ok. > > OK for mainline? Yes, it was approval. r~
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 19:17, Chase Douglas wrote: > > PR c++/50500 > * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move That is the ChangeLog for the front-end part of 50500, isn't it? Should be something like "Default copy ctor and assignment." Otherwise this is OK to check in, thanks. (Do you need me to do the actual check in or can Matthias do it?)
Re: [PATCH, ia64]: Fix PR 51681, ICE in gcc.dg/torture/vshuf-v2si.c (+ more)
On 01/03/2012 09:50 PM, Uros Bizjak wrote: > I tried to investigate -mbig-endian a bit, but unfortunately almost > all gcc.dg/torture/vshuf-*.c tests FAIL with -O2 on unpatched gcc. > Tests pass with -O0, though. Tests without -O don't actually test this code. And -mbig-endian doesn't get big-endian execution on linux, so it's only useful for manually examining assembly and checking for ICEs. r~
Re: RE :Re: RE :Re: hashtable local iterator
Attached patch applied.
2012-01-03 François Dumont
* include/bits/hashtable_policy.h (_Ebo_helper<>): Rename to
the more
specific _Hashtable_ebo_helper. Hide this implementation detail
thanks
to private inheritance.
I was about to roll the ChangeLog but I saw that there is already a
January entry in it so I keep on adding to the current one.
François
On 01/02/2012 10:13 PM, Paolo Carlini wrote:
On 01/02/2012 09:01 PM, François Dumont wrote:
On 01/02/2012 02:27 PM, Paolo Carlini wrote:
Hi,
Hi
Here is a proposition of patch compiling all your remarks.
2012-01-02 François Dumont
* include/bits/hashtable_policy.h (_Ebo_helper<>): Rename
into the
more specific _Hashtable_ebo_helper. Hide this
implementation detail
thanks to private inheritance.
Tested under x86_64 linux normal and debug mode.
Ok to commit ?
Can you please also adjust those comments referring to the
deprecated unary_function? Otherwise the patch looks good to me.
Like this Paolo ?
Humm, now I see there is no underscore anywhere in those comments,
thus there is no risk of confusion with the deprecated unary_function
and binary_function. I'm sorry I may have misread, therefore I think
you can just go ahead with the rest of your work and leave out the
changes to the comments in include/bits/hashtable.h.
Thanks again,
Paolo.
Index: include/bits/hashtable_policy.h
===
--- include/bits/hashtable_policy.h (revision 182854)
+++ include/bits/hashtable_policy.h (working copy)
@@ -1,6 +1,6 @@
// Internal policy header for unordered_set and unordered_map -*- C++ -*-
-// Copyright (C) 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2010, 2011, 2012 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
@@ -517,43 +517,43 @@
// and when it worth it, type is empty.
template
-struct _Ebo_helper;
+struct _Hashtable_ebo_helper;
// Specialization using EBO.
template
-struct _Ebo_helper<_Nm, _Tp, true> : _Tp
+struct _Hashtable_ebo_helper<_Nm, _Tp, true> : private _Tp
{
- _Ebo_helper() = default;
- _Ebo_helper(const _Tp& __tp) : _Tp(__tp)
+ _Hashtable_ebo_helper() = default;
+ _Hashtable_ebo_helper(const _Tp& __tp) : _Tp(__tp)
{ }
static const _Tp&
- _S_cget(const _Ebo_helper& __eboh)
+ _S_cget(const _Hashtable_ebo_helper& __eboh)
{ return static_cast(__eboh); }
static _Tp&
- _S_get(_Ebo_helper& __eboh)
+ _S_get(_Hashtable_ebo_helper& __eboh)
{ return static_cast<_Tp&>(__eboh); }
};
// Specialization not using EBO.
template
-struct _Ebo_helper<_Nm, _Tp, false>
+struct _Hashtable_ebo_helper<_Nm, _Tp, false>
{
- _Ebo_helper() = default;
- _Ebo_helper(const _Tp& __tp) : __m_tp(__tp)
+ _Hashtable_ebo_helper() = default;
+ _Hashtable_ebo_helper(const _Tp& __tp) : _M_tp(__tp)
{ }
static const _Tp&
- _S_cget(const _Ebo_helper& __eboh)
- { return __eboh.__m_tp; }
+ _S_cget(const _Hashtable_ebo_helper& __eboh)
+ { return __eboh._M_tp; }
static _Tp&
- _S_get(_Ebo_helper& __eboh)
- { return __eboh.__m_tp; }
+ _S_get(_Hashtable_ebo_helper& __eboh)
+ { return __eboh._M_tp; }
private:
- _Tp __m_tp;
+ _Tp _M_tp;
};
// Class template _Hash_code_base. Encapsulates two policy issues that
@@ -583,11 +583,13 @@
template
struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2, _Hash, false>
-: _Ebo_helper<0, _ExtractKey>, _Ebo_helper<1, _Hash>
+: private _Hashtable_ebo_helper<0, _ExtractKey>,
+ private _Hashtable_ebo_helper<1, _Hash>
{
private:
- typedef _Ebo_helper<0, _ExtractKey> _EboExtractKey;
- typedef _Ebo_helper<1, _Hash> _EboHash;
+ typedef _Hashtable_ebo_helper<0, _ExtractKey> _EboExtractKey;
+ typedef _Hashtable_ebo_helper<1, _Hash> _EboHash;
+
protected:
// We need the default constructor for the local iterators.
_Hash_code_base() = default;
@@ -655,12 +657,14 @@
typename _H1, typename _H2>
struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,
_Default_ranged_hash, false>
-: _Ebo_helper<0, _ExtractKey>, _Ebo_helper<1, _H1>, _Ebo_helper<2, _H2>
+: private _Hashtable_ebo_helper<0, _ExtractKey>,
+ private _Hashtable_ebo_helper<1, _H1>,
+ private _Hashtable_ebo_helper<2, _H2>
{
private:
- typedef _Ebo_helper<0, _ExtractKey> _EboExtractKey;
- typedef _Ebo_helper<1, _H1> _EboH1;
- typedef _Ebo_helper<2, _H2> _EboH2;
+ typedef _Hashtable_ebo_helper<0, _ExtractKey> _EboExtractKey;
+ typedef _Hashtable_ebo_helper<1, _H1> _EboH1;
+ typedef _Hashtable_ebo_helper<2, _H2> _EboH2;
public:
t
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
On 01/03/2012 12:34 PM, Jonathan Wakely wrote: > On 3 January 2012 19:17, Chase Douglas wrote: >> >> PR c++/50500 >> * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move > > That is the ChangeLog for the front-end part of 50500, isn't it? > Should be something like "Default copy ctor and assignment." I just copied the changelog text from commit 180159. That was the suggested approach in the style guidelines, though I do agree that "Default copy ctor and assignment" makes more sense. What do you suggest I do? > Otherwise this is OK to check in, thanks. > > (Do you need me to do the actual check in or can Matthias do it?) I don't know if Matthias can do it. I copied him to keep him in the loop since he is the toolchain maintainer for Ubuntu and I would like to get this into the next release. If you have access, I would suggest you do it since Matthias hasn't been involved in the generation or review of this patch. Thanks! -- Chase
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 20:45, Chase Douglas wrote: > On 01/03/2012 12:34 PM, Jonathan Wakely wrote: >> On 3 January 2012 19:17, Chase Douglas wrote: >>> >>> PR c++/50500 >>> * include/bits/shared_ptr.h: Add lazy copy ops even if there's a move >> >> That is the ChangeLog for the front-end part of 50500, isn't it? >> Should be something like "Default copy ctor and assignment." > > I just copied the changelog text from commit 180159. That was the > suggested approach in the style guidelines, though I do agree that > "Default copy ctor and assignment" makes more sense. What do you suggest > I do? Use the text from the libstdc++-v3/ChangeLog for the shared_prt.h change: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/ChangeLog?r1=180159&r2=180158&pathrev=180159 You can look in libstdc++-v3/ChangeLog to find that too. Jason's commit message was the text from gcc/cp/ChangeLog, but he touched several parts (the C++ front-end, the C++ library and the testsuite) which all have their own ChangeLog files. >> Otherwise this is OK to check in, thanks. >> >> (Do you need me to do the actual check in or can Matthias do it?) > > I don't know if Matthias can do it. I copied him to keep him in the loop > since he is the toolchain maintainer for Ubuntu and I would like to get > this into the next release. If you have access, I would suggest you do > it since Matthias hasn't been involved in the generation or review of > this patch. OK, I'll do it. Thanks.
Re: [PATCH] Another canonical cselib_val bootstrap fix (PR bootstrap/51725)
On 01/04/2012 06:14 AM, Jakub Jelinek wrote: > PR bootstrap/51725 > * cselib.c (new_elt_loc_list): When moving locs from one > cselib_val to its new canonical_cselib_val and the > cselib_val was in first_containing_mem chain, but > the canonical_cselib_val was not, add the latter into the > chain. > (cselib_invalidate_mem): Compare canonical_cselib_val of > addr_list chain elt with v. Ok. r~
Re: RE :Re: RE :Re: hashtable local iterator
On 01/03/2012 09:36 PM, François Dumont wrote: I was about to roll the ChangeLog but I saw that there is already a January entry in it so I keep on adding to the current one. For the record, it's just that I was in a hurry, there is no plan behind that. Paolo.
Re: PR middle-end/51696: display indirect function calls properly for trans-mem
On 01/03/12 14:01, Richard Henderson wrote:
On 01/04/2012 04:18 AM, Aldy Hernandez wrote:
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Ok.
r~
Sorry for the noise, but I forgot to check that we actually have a DECL.
Patch updated and tested on x86-64 Linux.
Still OK?
PR middle-end/51696
* trans-mem.c (diagnose_tm_1): Display indirect calls with no name
correctly.
Index: testsuite/gcc.dg/tm/pr51696.c
===
--- testsuite/gcc.dg/tm/pr51696.c (revision 0)
+++ testsuite/gcc.dg/tm/pr51696.c (revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm" } */
+
+struct list {
+ void (*compare)();
+} *listPtr;
+
+static void (*compare)();
+
+__attribute__((transaction_safe))
+static void func () {
+ listPtr->compare(); /* { dg-error "unsafe indirect function call" } */
+ compare(); /* { dg-error "unsafe function call" } */
+}
Index: trans-mem.c
===
--- trans-mem.c (revision 182848)
+++ trans-mem.c (working copy)
@@ -664,9 +664,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"atomic transaction", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "atomic transaction", fn);
+ {
+ if (!DECL_P (fn) || DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "atomic transaction", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "atomic transaction");
+ }
}
else
{
@@ -675,9 +682,16 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi
"unsafe function call %qD within "
"% function", fn);
else
- error_at (gimple_location (stmt),
- "unsafe function call %qE within "
- "% function", fn);
+ {
+ if (!DECL_P (fn) || DECL_NAME (fn))
+ error_at (gimple_location (stmt),
+ "unsafe function call %qE within "
+ "% function", fn);
+ else
+ error_at (gimple_location (stmt),
+ "unsafe indirect function call within "
+ "% function");
+ }
}
}
}
Re: PR middle-end/51696: display indirect function calls properly for trans-mem
On 01/04/2012 08:19 AM, Aldy Hernandez wrote: > PR middle-end/51696 > * trans-mem.c (diagnose_tm_1): Display indirect calls with no name > correctly. Ok. r~
Re: [patch] PR 51006 fix bootstrap failure on NetBSD
On Mon, Jan 2, 2012 at 1:06 PM, Jonathan Wakely wrote: > libgcc/ChangeLog > 2012-01-02 Jonathan Wakely > > PR bootstrap/51006 > * enable-execute-stack-mprotect.c (getpagesize): Do not define > for NetBSD. > > This removes the definition of getpagesize which is always present on BSD. > > Tested x86_64-unknown-netbsd5.1 and already approved privately by a > NetBSD maintainer. > Krister, could you confirm this is OK to commit to mainline? OK! /Krister
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
I get testsuite failures with this change applied:
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858)
FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 354)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 1085)
FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for excess errors)
Did you not see them when testing?
Here's what I'm checking in
2012-01-03 Chase Douglas
Jonathan Wakely
* include/bits/shared_ptr.h: Default copy ctor and assignment.
* include/bits/shared_ptr_base.h: Likewise.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error
line numbers.
* testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Likewise.
Index: include/bits/shared_ptr.h
===
--- include/bits/shared_ptr.h (revision 182460)
+++ include/bits/shared_ptr.h (working copy)
@@ -100,6 +100,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr shared_ptr()
: __shared_ptr<_Tp>() { }
+ shared_ptr(const shared_ptr&) = default; // never throws
+
/**
* @brief Construct a %shared_ptr that owns the pointer @a __p.
* @param __p A pointer that is convertible to element_type*.
@@ -264,6 +266,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr shared_ptr(nullptr_t __p)
: __shared_ptr<_Tp>(__p) { }
+ shared_ptr& operator=(const shared_ptr&) = default;
+
template
shared_ptr&
operator=(const shared_ptr<_Tp1>& __r) // never throws
Index: include/bits/shared_ptr_base.h
===
--- include/bits/shared_ptr_base.h (revision 182460)
+++ include/bits/shared_ptr_base.h (working copy)
@@ -799,7 +799,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: _M_ptr(__p), _M_refcount(__r._M_refcount) // never throws
{ }
- // generated copy constructor, assignment, destructor are fine.
+ __shared_ptr(const __shared_ptr&) = default; // never throws
+ __shared_ptr& operator=(const __shared_ptr&) = default; // never throws
template::value>::type>
Index: testsuite/20_util/shared_ptr/cons/43820_neg.cc
===
--- testsuite/20_util/shared_ptr/cons/43820_neg.cc (revision 182460)
+++ testsuite/20_util/shared_ptr/cons/43820_neg.cc (working copy)
@@ -35,6 +35,6 @@ void test01()
// { dg-error "incomplete" "" { target *-*-* } 766 }
std::shared_ptr p9(ap()); // { dg-error "here" }
- // { dg-error "incomplete" "" { target *-*-* } 858 }
+ // { dg-error "incomplete" "" { target *-*-* } 859 }
}
Index: testsuite/20_util/weak_ptr/comparison/cmp_neg.cc
===
--- testsuite/20_util/weak_ptr/comparison/cmp_neg.cc(revision 182460)
+++ testsuite/20_util/weak_ptr/comparison/cmp_neg.cc(working copy)
@@ -42,8 +42,8 @@ main()
return 0;
}
-// { dg-warning "note" "" { target *-*-* } 354 }
-// { dg-warning "note" "" { target *-*-* } 1085 }
+// { dg-warning "note" "" { target *-*-* } 358 }
+// { dg-warning "note" "" { target *-*-* } 1086 }
// { dg-warning "note" "" { target *-*-* } 468 }
// { dg-warning "note" "" { target *-*-* } 586 }
// { dg-warning "note" "" { target *-*-* } 1049 }
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
On 01/03/2012 01:38 PM, Jonathan Wakely wrote: > I get testsuite failures with this change applied: > > FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858) > FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors) > FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 354) > FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 1085) > FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for excess errors) > > Did you not see them when testing? They didn't affect me when I ran my own library's test suite, and they didn't cause the packaged build for Ubuntu to fail. I saw there were many test failures in the Ubuntu packaged version, so I didn't really pick through them. > Here's what I'm checking in > > 2012-01-03 Chase Douglas > Jonathan Wakely > > * include/bits/shared_ptr.h: Default copy ctor and assignment. > * include/bits/shared_ptr_base.h: Likewise. > * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error > line numbers. > * testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Likewise. Ok, thanks. Next time I'll be sure to pay closer attention to the testsuite output.
Re: [PATCH v2] [4.6] shared_ptr needs explicit copy constructor
On 3 January 2012 21:48, Chase Douglas wrote: > On 01/03/2012 01:38 PM, Jonathan Wakely wrote: >> I get testsuite failures with this change applied: >> >> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for errors, line 858) >> FAIL: 20_util/shared_ptr/cons/43820_neg.cc (test for excess errors) >> FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 354) >> FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for warnings, line 1085) >> FAIL: 20_util/weak_ptr/comparison/cmp_neg.cc (test for excess errors) >> >> Did you not see them when testing? > > They didn't affect me when I ran my own library's test suite, and they > didn't cause the packaged build for Ubuntu to fail. I saw there were > many test failures in the Ubuntu packaged version, so I didn't really > pick through them. We don't care about your library or about the Ubuntu package :) If you're proposing a change to the FSF sources for GCC then you need to build and test the change against the FSF sources, and the libstdc++ testsuite is currently error-free on the 4.6 branch (e.g. see this report http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg00208.html on the gcc-testresults list) so we don't want a change which introduces failures. Unfortunately those particular files need to be adjusted whenever any lines are added or removed from shared_ptr.h
Re: [RFC][patch] trans-mem: mark transaction begins as returns-twice
On 01/03/2012 09:42 PM, Torvald Riegel wrote: >> Why does the explicit CFG approach not work exactly? cfun->calls_setjmp is >> thought to be quite a big hammer. > > I don't know, actually. When I looked at the miscompilation case, all > abnormal edges seemed to be in place. > > @rth: Do you have an idea what could be going wrong? I haven't tried > the other thing you sent me, what was it supposed to fix? There are several places where those edges (currently) get lost going from gimple to rtl. In addition, return value copy from the hard reg to the pseudo is in the wrong basic block wrt the abnormal edges. My inclination at this point is to use returns_twice for the 4.7 release and fix the abcall edges and associated fiddlery in 4.8 stage1. I'm not especially confident that we'd clear out all the bugs in time otherwise. r~
Re: [PATCH, testsuite]: Use dg-add-options ieee in gfortran.dg/typebound_operator_8.f03
Dear Uros,
Thanks for that. It is not a problem that I encountered on either the
32 bit or 64 bit machines that I use but, as you say, an underflow is
the most likely explanation. I guess that without any loss, as far as
the test is concerned, a test that obj%c(i,j) is greater than 1e-5,
say, could have been done before raising it to the fourth power!
Cheers
Paul
On Tue, Jan 3, 2012 at 7:36 PM, Uros Bizjak wrote:
> Hello!
>
> -mieee is needed for this runtime test to avoid
>
> FAIL: gfortran.dg/typebound_operator_8.f03 -O0 execution test
> FAIL: gfortran.dg/typebound_operator_8.f03 -Os execution test
>
> on alpha-linux-gnu.
>
> Probably underflow, or something exceptional, gdb is not a friend with
> fortran code on this target:
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x000120004190 in cartesian_2d_objects::process_cart2d_p (obj=...)
> at
> /home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03:172
> 172 process_cart2d_p%c = -sign (obj%c, 1.0)*obj%c** 4
> (gdb)
>
> 2012-01-03 Uros Bizjak
>
> * gfortran.dg/typebound_operator_8.f03: Use dg-add-options ieee.
>
> Tested on alphaev68-unknown-linux-gnu, committed to mainline SVN.
>
> Uros.
>
> Index: gfortran.dg/typebound_operator_8.f03
> ===
> --- gfortran.dg/typebound_operator_8.f03 (revision 182853)
> +++ gfortran.dg/typebound_operator_8.f03 (working copy)
> @@ -1,4 +1,5 @@
> ! { dg-do run }
> +! { dg-add-options ieee }
> !
> ! Solve a diffusion problem using an object-oriented approach
> !
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
