Re: [PATCH] RFC: Interix resurrection
On 01/22/2012 10:16 PM, Douglas Rupp wrote: May I regenerate libiberty/configure and check it in, or does that require a libiberty maintainer? Yes, regenerate everything that is affected. Paolo
[PATCH] Fix PR 29333: Jump threading getting in the way of PHI-OPT
Hi, The problem here is not really jump threading getting in the way of PHI-OPT rather there is no cleanup of the IR after jump thread but before phi-opt. This patch adds a pass_phi_only_cprop right after the first vrp and pass_merge_phi right before the first and last phiopts. Since VRP does jump threading just like DOM does, we need a pass_phi_only_cprop right after it. And the merge PHI pass should be done so that going into PHI-OPT we have a CFG which there is only one PHI for a case like: bb0: if (a) goto L1; bb3: if (b) goto L2; L1: x = PHI L2: x= PHI PHI-OPT does not handle PHIs like this that well. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Thanks, Andrew Pinski ChangeLog: * passes.c (init_optimization_passes): Add pass_phi_only_cprop after the first vpr pass. Add pass_merge_phi before the first and last phiopt passes. testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-7.c: New testcase. Index: testsuite/gcc.dg/tree-ssa/phi-opt-7.c === --- testsuite/gcc.dg/tree-ssa/phi-opt-7.c (revision 0) +++ testsuite/gcc.dg/tree-ssa/phi-opt-7.c (revision 0) @@ -0,0 +1,25 @@ +/* { dg-do compile } */ +/* { dg-options "-O -fdump-tree-phiopt1" } */ + + +int minmax_correct(int a) +{ +if (a > 32767) a = 32767; +else if (a < -32768) a = -32768; + +return a; +} + +int minmax_wrong(int a) +{ +if (a > 32767) a = 32767; +if (a < -32768) a = -32768; + +return a; +} + +/* { dg-final { scan-tree-dump-not "if" "phiopt1" } } */ +/* { dg-final { scan-tree-dump-times "MAX_EXPR" 2 "phiopt1" } } */ +/* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "phiopt1" } } */ +/* { dg-final { cleanup-tree-dump "phiopt1" } } */ + Index: passes.c === --- passes.c(revision 183396) +++ passes.c(working copy) @@ -1302,9 +1302,11 @@ init_optimization_passes (void) NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_vrp); + NEXT_PASS (pass_phi_only_cprop); NEXT_PASS (pass_dce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_tree_ifcombine); + NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); @@ -1401,6 +1403,7 @@ init_optimization_passes (void) NEXT_PASS (pass_late_warn_uninitialized); NEXT_PASS (pass_dse); NEXT_PASS (pass_forwprop); + NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_phiopt); NEXT_PASS (pass_fold_builtins); NEXT_PASS (pass_optimize_widening_mul);
Re: [wwwdocs] List new Fortran options under Fortran section
On Wed, 18 Jan 2012, Tobias Burnus wrote: > Looks OK to me. Though, I had made the N and M italic at: > +-freal-N-real-M have been added. These options promote > and > +N andM can be 4 and 8 and, if available, Something like -freal-N-real-M have been added. These options promote and N and M can be 4 and 8 and, if available... ? Yes, that would be nice. > No, there is no ChangeLog - and due to using CVS, the commit message > (may but) does not need to contain file name as cvs saves the log per > file. Yep. Just something like Document -freal-N-real-M and -finteger-4-integer-8. would be fine. If you prefer a changelog entry like we do for code, that's fine as well, though. :-) Gerald
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/17/2012 04:07 AM, Rainer Orth wrote: > * The 32-bit failures on Solaris 8 to 10 have a different root cause: > _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()). It > turns out that there are two copies of the unwinder in eh-1.exe: one > from libgcc_s.so.1, and another one from libgcc_eh.a. eh-1.o has a > reference to _Unwind_Resume (don't yet know why), which is resolved > from libgcc_eh.a. This doesn't happen on Solaris 11, which uses the > dl_iterate_phdr based unwinder, thus no __register_frame_info_bases. Er.. how did we get two copies? I don't think this change is correct, as it seems just as likely that we'd hit the same problem with real applications. This just seems like it's papering over the real problem. r~
Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld
On 01/17/2012 03:36 AM, Rainer Orth wrote: > 2011-11-18 Rainer Orth > > * clearcap.map: New file. > * acinclude.m4 (LIBITM_CHECK_LINKER_HWCAP): New test. > * configure.ac: Call it. > Clear HWCAP_LDFLAGS if defaulting to -mavx. > * Makefile.am (AM_LDFLAGS): Add $(HWCAP_LDFLAGS) > * configure: Regenerate. > * Makefile.in: Regenerate. > * testsuite/Makefile.in: Regenerate. Ok. r~
Re: [libitm, build] Support sun symbol versioning
On 01/17/2012 03:41 AM, Rainer Orth wrote: > 2012-01-14 Rainer Orth > > * libitm.h (_ITM_getThreadnum): Remove. > * libitm.map (_ITM_getThreadnum): Remove from LIBITM_1.0. Ok. r~
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On 01/20/2012 12:51 AM, Uros Bizjak wrote: > OTOH, in GTM_beginTransaction we can > still access other variable arguments through the pointer to CFA. Well, no, not really. If we really want GTM_beginTransaction to have access to the variadic portions, we'll need to have the sjlj stub pass in a va_list. Thankfully we can generally ignore this until we actually need those extra bits. Which is not in the near-term cards. r~
Re: [PATCH, trans-mem]: Fix PR51830, FAIL: libitm.c/mem(cpy|set)-1.c execution test on x86_32
On 01/19/2012 06:26 AM, Uros Bizjak wrote: > 2012-01-18 Uros Bizjak > > PR libitm/51830 > * builtin-types.def (BT_FN_UINT_UINT_VAR): New. > * gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR. > > libitm/ChangeLog: > > 2012-01-18 Uros Bizjak > > PR libitm/51830 > * config/x86/sjlj.S (_ITM_beginTransaction) [!__x86_64__]: Load > the first function argument to %eax. Ok. r~
Re: Add -lssp_nonshared to LINK_SSP_SPEC
On Sat, 21 Jan 2012, Tijl Coosemans wrote: > I've been using this patch now. It's similar to the above url, but > conditional on TARGET_LIBC_PROVIDES_SSP to support older FreeBSD > versions. > > Gerald volunteered to commit. Gerald, just trunk for now or older > branches too? If Richi agries, I'd apply this on trunk and the GCC 4.6 branch, since that is the stable release our users employ. Gerald PS: We also need to update the copyright date at the top, and I'll take care of that when committing. > 2011-01-20 Tijl Coosemans > > * gcc/config/freebsd-spec.h [TARGET_LIBC_PROVIDES_SSP] (LINK_SSP_SPEC): > Define. > > --- gcc/config/freebsd-spec.h > +++ gcc/config/freebsd-spec.h > @@ -138,6 +138,10 @@ is built with the --enable-threads confi > #define LINK_EH_SPEC "%{!static:--eh-frame-hdr} " > #endif > > +#ifdef TARGET_LIBC_PROVIDES_SSP > +#define LINK_SSP_SPEC > "%{fstack-protector|fstack-protector-all:-lssp_nonshared}" > +#endif > + > /* Use --as-needed -lgcc_s for eh support. */ > #ifdef HAVE_LD_AS_NEEDED > #define USE_LD_AS_NEEDED 1 >
Re: [Patch, fortran] PR51870 - [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS
Dear Paul, Paul Richard Thomas wrote: The attached is quite straightforward - for non-variable class STATUS expressions, I believe that you mean source-expr (i.e. SOURCE= and MOLD=) and not STATUS. Note that I have begged off including variables in this process, given the stage that we are at with 4.7.0. That's appreciated. I think that 4.7 will be released relatively soonish, given that there are just 83 serious regressions (9 P1, 66 P2, 8 P3; 63 P4, 56 P4). The plan was to release around mid-March to beginning of April. Given the low number of regressions, it might be slightly earlier, though not much as the release managers want to give users some time to find more regressions. This means that the patch only affects the part that was broken. Early in 4.8.0, gfc_trans_allocate will have to undergo a massive clean up. Clean-ups are also appreciated ;-) * * * I somehow liked your draft patch more: * The big program which I reduced to the test case in PR 51870 fails with the current patch - only the reduced test case of the PR works. The failure of the bigger program is - at runt time - a SIGABRT at #6 0x409175 in __show_class_MOD___copy_show_class_Show * It also fixed PR 48705. Your current patch fixes the reduced test case (comment 1) of that PR, but no longer the original version, which fails at the end of the program ("end program" line) at run time (SIGABRT). Valgrind shows: Invalid write of size 8 at 0x4009B3: __generic_deferred_MOD___copy_generic_deferred_Vec (in /dev/shm/a.out) (I assume both programs have the same issue.) Thus, I would prefer if you could have a look at the latter PR. 2012-01-22 Paul Thomas PR fortran/51870 Could you also add PR fortran/51943 and PR 51946? (I think those are effectively the same examples. Also the full example ssdSource/chapter08/puppeteer_f2003 works for me.) + /* This is the safest way of converting to a compatible +type for use in the allocation. */ + tmp = TYPE_SIZE_UNIT (TREE_TYPE (gfc_index_zero_node)); + memsz = fold_convert (TREE_TYPE (tmp), memsz); How about: + memsz = fold_convert (size_type_node, memsz); /* Determine allocate size. */ - if (al->expr->ts.type == BT_CLASS && code->expr3) + if (al->expr->ts.type == BT_CLASS + && code->expr3 + && memsz == NULL_TREE) { Indentation looks wrong. for (al = code->ext.alloc.list; al != NULL; al = al->next) { ... + class_expr = build_fold_indirect_ref_loc (input_location, + se_sz.expr); + class_expr = gfc_evaluate_now (class_expr, &se.pre); I have the feeling that you evaluate the function multiple times. Actually, for* allocate(kernel, kernel2, mold=executive_producer%create_show() ) I find: D.1890 = create_show (); (struct __vtype_show_producer_class_Integrand *) kernel._vptr = (struct __vtype_show_producer_class_Integrand *) D.1890._vptr; (void) __builtin_memcpy ((void *) kernel._data, (void *) &create_show (), 4); D.1892 = create_show (); (struct __vtype_show_producer_class_Integrand *) kernel2._vptr = (struct __vtype_show_producer_class_Integrand *) D.1892._vptr; (void) __builtin_memcpy ((void *) kernel2._data, (void *) &create_show (), 4); Thus, one evaluates the function 4 times instead of only once. Additionally, MOLD= does not invoke the default initializer (as expected for MOLD=) but memcopy (as expected for SOURCE=). The memcpy is also wrong. If CLASS(integrand) (of create_show) returned a derived type with allocatable components, one had to to a deep copy. As this is not known at compile time, a call to vtab->__copy is required. And a last issue: If one changes in type(show_producer), allocatable :: executive_producer the TYPE to CLASS one gets still an ICE in conv_function_val. Tobias * Ditto for SOURCE=, though there one runs into PR51953 as F2003 only allowed one allocate-object.
Re: Commit: RX: Add return pattern
On 01/13/2012 04:31 AM, nick clifton wrote: > Hi Richard, > >> Not an ideal solution, since the availability of this pattern implies >> it's extremely cheap, and we'll replace jumps to the epilogue with >> this pattern. >> Or to define an availability predicate similar to i386, testing if >> the epilogue is trivial, and only a return insn is needed. > > Something like the attached ? > > I am running some local checks now and if there are no regressions then I > will check the patch in tomorrow. Looks good, thanks. r~
Re: [PATCH] RFC: Interix resurrection
On 1/22/2012 4:41 AM, Paolo Bonzini wrote: On 01/01/2012 10:01 PM, Douglas Rupp wrote: -i[[34567]]86-*-interix3*) +i[[34567]]86-*-interix[[3-9]]*) # Interix 3.x gcc -fpic/-fPIC options generate broken code. # Instead, we relocate shared libraries at runtime. ;; Is this still true? Build parts are ok. Paolo Thanks. May I regenerate libiberty/configure and check it in, or does that require a libiberty maintainer? Regarding your question(s) I believe -fpic/PIC is still broken on Interix but I'll have to dig into some old notes to clarify the reason. The comment about shared library relocation is still true.
[Patch, fortran] PR51870 - [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS
Dear All, The attached is quite straightforward - for non-variable class STATUS expressions, the class object is extracted, together with the element size for the dynamic type. These are then used for the allocation and the copy of the source data into the allocated object. Note that I have begged off including variables in this process, given the stage that we are at with 4.7.0. This means that the patch only affects the part that was broken. Early in 4.8.0, gfc_trans_allocate will have to undergo a massive clean up. Too many people, myself included, have left their fingerprints on it :-) I realized at the last moment that get_class_array_ref and gfc_copy_class_to_class should be moved to trans-expr.c. The former should also be called from trans.c(gfc_build_array_ref) and the repeated code removed form there. I will do this before commiting. Bootstrapped and regtested on FC9/x86_64 - OK for trunk? Cheers Paul 2012-01-22 Paul Thomas PR fortran/51870 * trans-array.c (gfc_array_init_size): Add two extra arguments to convey the dynamic element size of a calls object and to return the number of elements that have been allocated. (gfc_array_allocate): Add the same arguments and use them to call gfc_array_init_size. Before the allocation dereference the data pointer, if necessary. Set the allocated array to zero if the class element size or expr3 are non-null. * trans-expr.c (gfc_conv_class_to_class): Give this function global scope. * trans-array.h : Update prototype for gfc_array_allocate. * trans-stmt.c (get_class_array_ref): New function. (gfc_copy_class_to_class): New function. (gfc_trans_allocate): For non-variable class STATUS expressions extract the class object and the dynamic element size. Use the latter to call gfc_array_allocate and the former for setting the vptr and, via gfc_copy_class_to_class, to copy to the allocated data. * trans.h : Prototype for gfc_conv_class_to_class. 2012-01-22 Paul Thomas PR fortran/51870 * gfortran.dg/class_allocate_7.f03: New. * gfortran.dg/class_allocate_8.f03: New. Index: gcc/fortran/trans-array.c === *** gcc/fortran/trans-array.c (revision 183364) --- gcc/fortran/trans-array.c (working copy) *** static tree *** 4719,4725 gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset, gfc_expr ** lower, gfc_expr ** upper, stmtblock_t * pblock, stmtblock_t * descriptor_block, tree * overflow, ! gfc_expr *expr3) { tree type; tree tmp; --- 4719,4725 gfc_array_init_size (tree descriptor, int rank, int corank, tree * poffset, gfc_expr ** lower, gfc_expr ** upper, stmtblock_t * pblock, stmtblock_t * descriptor_block, tree * overflow, ! tree expr3_elem_size, tree *nelems, gfc_expr *expr3) { tree type; tree tmp; *** gfc_array_init_size (tree descriptor, in *** 4876,4882 /* The stride is the number of elements in the array, so multiply by the size of an element to get the total size. Obviously, if there ia a SOURCE expression (expr3) we must use its element size. */ ! if (expr3 != NULL) { if (expr3->ts.type == BT_CLASS) { --- 4876,4884 /* The stride is the number of elements in the array, so multiply by the size of an element to get the total size. Obviously, if there ia a SOURCE expression (expr3) we must use its element size. */ ! if (expr3_elem_size != NULL_TREE) ! tmp = expr3_elem_size; ! else if (expr3 != NULL) { if (expr3->ts.type == BT_CLASS) { *** gfc_array_init_size (tree descriptor, in *** 4904,4909 --- 4906,4912 if (rank == 0) return element_size; + *nelems = gfc_evaluate_now (stride, pblock); stride = fold_convert (size_type_node, stride); /* First check for overflow. Since an array of type character can *** gfc_array_init_size (tree descriptor, in *** 4962,4968 bool gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, ! tree errlen, tree label_finish, gfc_expr *expr3) { tree tmp; tree pointer; --- 4965,4972 bool gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg, ! tree errlen, tree label_finish, tree expr3_elem_size, ! tree *nelems, gfc_expr *expr3) { tree tmp; tree pointer; *** gfc_array_allocate (gfc_se * se, gfc_exp *** 5047,5053 size = gfc_array_init_size (se->expr, ref->u.ar.as->rank, ref->u.ar.as->corank, &offset, lower, upper, &se->pre, &set_descriptor_block, &overflow, ! expr3); if (dimension) { --- 5051,5057 size = gfc_array_init_size (se->expr, re
Re: [patch PR 51900]: Fix PE's delegitimize_address functions
2012/1/22 Kai Tietz : > 2012/1/22 Jakub Jelinek : >> On Sun, Jan 22, 2012 at 08:05:12PM +0100, Kai Tietz wrote: >>> this patch fixes reported issue in PR about common-symbols and fix >>> behavior about -fcommon/-fno-common. Additionally it adds proper >>> support for weakref, local-variant of weaks, and tries to handle >>> resolution-file information for PE-COFF. >> >> The dwarf2out.c change looks wrong to me, either it is necessary >> for it to be CONST to be delegitimized, then it should be really CONST in >> the IL too, or it is not needed, then delegitimize_address those targets >> should handle it even without CONST. So here is the revised patch. ChangeLog 2012-01-22 Kai Tietz PR target/51900 * dwarf2out.c (const_ok_for_output_1): Try to delegitimize address before checking for UNSPEC. * config/i386/predicates.md (symbolic_operand): Allow UNSPEC_PCREL as PIC expression for lea. * config/i386/winnt.c (i386_pe_binds_local_p): Reworked. * config/i386/i386.c (ix86_delegitimize_address): Handle UNSPEC_PCREL for none-MEM, too. Kai Index: dwarf2out.c === --- dwarf2out.c (revision 183389) +++ dwarf2out.c (working copy) @@ -10653,8 +10653,17 @@ { rtx rtl = *rtlp; + /* Try to delegitimize address before check. */ if (GET_CODE (rtl) == UNSPEC) { + rtx n = targetm.delegitimize_address (rtl); + + if (GET_CODE (n) == SYMBOL_REF) +*rtlp = rtl = n; +} + + if (GET_CODE (rtl) == UNSPEC) +{ /* If delegitimize_address couldn't do anything with the UNSPEC, assume we can't express it in the debug info. */ #ifdef ENABLE_CHECKING Index: config/i386/predicates.md === --- config/i386/predicates.md (revision 183389) +++ config/i386/predicates.md (working copy) @@ -410,6 +410,7 @@ || (GET_CODE (op) == UNSPEC && (XINT (op, 1) == UNSPEC_GOT || XINT (op, 1) == UNSPEC_GOTOFF + || XINT (op, 1) == UNSPEC_PCREL || XINT (op, 1) == UNSPEC_GOTPCREL))) return true; if (GET_CODE (op) != PLUS Index: config/i386/winnt.c === --- config/i386/winnt.c (revision 183389) +++ config/i386/winnt.c (working copy) @@ -350,20 +350,101 @@ SYMBOL_REF_FLAGS (symbol) = flags; } + bool i386_pe_binds_local_p (const_tree exp) { - /* PE does not do dynamic binding. Indeed, the only kind of - non-local reference comes from a dllimport'd symbol. */ - if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) - && DECL_DLLIMPORT_P (exp)) -return false; + bool is_dllimported = false; + bool resolved_to_local_def = false; + bool resolved_locally = false; - /* Or a weak one, now that they are supported. */ - if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) - && DECL_WEAK (exp)) + if (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) +is_dllimported = DECL_DLLIMPORT_P (exp); + + if (TREE_CODE (exp) == VAR_DECL && TREE_PUBLIC (exp) + && (TREE_STATIC (exp) || DECL_EXTERNAL (exp))) +{ + struct varpool_node *vnode = varpool_get_node (exp); + if (vnode) +{ + if (vnode->resolution == LDPR_PREVAILING_DEF + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || vnode->resolution == LDPR_PREEMPTED_REG + || vnode->resolution == LDPR_PREEMPTED_IR + || vnode->resolution == LDPR_RESOLVED_IR + || vnode->resolution == LDPR_RESOLVED_EXEC) + resolved_locally = !is_dllimported; + if (vnode->resolution == LDPR_PREVAILING_DEF + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY) + resolved_to_local_def = true; + } +} + else if (TREE_CODE (exp) == FUNCTION_DECL && TREE_PUBLIC (exp)) +{ + struct cgraph_node *node = cgraph_get_node (exp); + if (node) +{ + if (node->resolution == LDPR_PREVAILING_DEF + || node->resolution == LDPR_PREVAILING_DEF_IRONLY + || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || node->resolution == LDPR_PREEMPTED_REG + || node->resolution == LDPR_PREEMPTED_IR + || node->resolution == LDPR_RESOLVED_IR + || node->resolution == LDPR_RESOLVED_EXEC) + resolved_locally = !is_dllimported; + if (node->resolution == LDPR_PREVAILING_DEF + || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || node->resolution == LDPR_PREVAILING_DEF_IRONLY) + resolved_to_local_def = true; + } +} + + if (resolved_locally && is_dllimported) +
Re: [patch PR 51900]: Fix PE's delegitimize_address functions
2012/1/22 Jakub Jelinek : > On Sun, Jan 22, 2012 at 08:05:12PM +0100, Kai Tietz wrote: >> this patch fixes reported issue in PR about common-symbols and fix >> behavior about -fcommon/-fno-common. Additionally it adds proper >> support for weakref, local-variant of weaks, and tries to handle >> resolution-file information for PE-COFF. > > The dwarf2out.c change looks wrong to me, either it is necessary > for it to be CONST to be delegitimized, then it should be really CONST in > the IL too, or it is not needed, then delegitimize_address those targets > should handle it even without CONST. Well, it is CONST in IL, but CONST { list-of-addresses }. Ok, I will rework target's delegitimize_address and don't post-fix rtx by CONST at call for in dwarf2out. Would that be ok for you? Kai
Re: [patch PR 51900]: Fix PE's delegitimize_address functions
On Sun, Jan 22, 2012 at 08:05:12PM +0100, Kai Tietz wrote: > this patch fixes reported issue in PR about common-symbols and fix > behavior about -fcommon/-fno-common. Additionally it adds proper > support for weakref, local-variant of weaks, and tries to handle > resolution-file information for PE-COFF. The dwarf2out.c change looks wrong to me, either it is necessary for it to be CONST to be delegitimized, then it should be really CONST in the IL too, or it is not needed, then delegitimize_address those targets should handle it even without CONST. Jakub
[patch PR 51900]: Fix PE's delegitimize_address functions
Hello, this patch fixes reported issue in PR about common-symbols and fix behavior about -fcommon/-fno-common. Additionally it adds proper support for weakref, local-variant of weaks, and tries to handle resolution-file information for PE-COFF. I did regression tests of all standard-languages for x86_64-w64-mingw32 and i686-w64-mingw32. Dave would you mind to test it for cygwin, too? I assume it will fit for cygwin, but just to make sure. Also I did a regression test for x86_64-unknown-linux-gnu. Patch ok for apply? Regards, Kai PS: Sorry missed first time subject-line ChangeLog 2012-01-22 Kai Tietz PR target/51900 * dwarf2out.c (const_ok_for_output_1): Try to delegitimize address before checking for UNSPEC. * config/i386/predicates.md (symbolic_operand): Allow UNSPEC_PCREL as PIC expression for lea. * config/i386/winnt.c (i386_pe_binds_local_p): Reworked. * config/i386/i386.c (ix86_delegitimize_address): Handle UNSPEC_PCREL for none-MEM, too. Index: dwarf2out.c === --- dwarf2out.c (revision 183389) +++ dwarf2out.c (working copy) @@ -10653,8 +10653,18 @@ { rtx rtl = *rtlp; + /* Try to delegitimize address by adding a CONST in front. + This is required due pattern checked in delegitimize_address. */ if (GET_CODE (rtl) == UNSPEC) { + rtx newrtl = gen_rtx_CONST (Pmode, rtl); + newrtl = targetm.delegitimize_address (newrtl); + if (GET_CODE (newrtl) == SYMBOL_REF) +*rtlp = rtl = newrtl; +} + + if (GET_CODE (rtl) == UNSPEC) +{ /* If delegitimize_address couldn't do anything with the UNSPEC, assume we can't express it in the debug info. */ #ifdef ENABLE_CHECKING Index: config/i386/predicates.md === --- config/i386/predicates.md (revision 183389) +++ config/i386/predicates.md (working copy) @@ -410,6 +410,7 @@ || (GET_CODE (op) == UNSPEC && (XINT (op, 1) == UNSPEC_GOT || XINT (op, 1) == UNSPEC_GOTOFF + || XINT (op, 1) == UNSPEC_PCREL || XINT (op, 1) == UNSPEC_GOTPCREL))) return true; if (GET_CODE (op) != PLUS Index: config/i386/winnt.c === --- config/i386/winnt.c (revision 183389) +++ config/i386/winnt.c (working copy) @@ -350,20 +350,101 @@ SYMBOL_REF_FLAGS (symbol) = flags; } + bool i386_pe_binds_local_p (const_tree exp) { - /* PE does not do dynamic binding. Indeed, the only kind of - non-local reference comes from a dllimport'd symbol. */ - if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) - && DECL_DLLIMPORT_P (exp)) -return false; + bool is_dllimported = false; + bool resolved_to_local_def = false; + bool resolved_locally = false; - /* Or a weak one, now that they are supported. */ - if ((TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) - && DECL_WEAK (exp)) + if (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == FUNCTION_DECL) +is_dllimported = DECL_DLLIMPORT_P (exp); + + if (TREE_CODE (exp) == VAR_DECL && TREE_PUBLIC (exp) + && (TREE_STATIC (exp) || DECL_EXTERNAL (exp))) +{ + struct varpool_node *vnode = varpool_get_node (exp); + if (vnode) +{ + if (vnode->resolution == LDPR_PREVAILING_DEF + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || vnode->resolution == LDPR_PREEMPTED_REG + || vnode->resolution == LDPR_PREEMPTED_IR + || vnode->resolution == LDPR_RESOLVED_IR + || vnode->resolution == LDPR_RESOLVED_EXEC) + resolved_locally = !is_dllimported; + if (vnode->resolution == LDPR_PREVAILING_DEF + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || vnode->resolution == LDPR_PREVAILING_DEF_IRONLY) + resolved_to_local_def = true; + } +} + else if (TREE_CODE (exp) == FUNCTION_DECL && TREE_PUBLIC (exp)) +{ + struct cgraph_node *node = cgraph_get_node (exp); + if (node) +{ + if (node->resolution == LDPR_PREVAILING_DEF + || node->resolution == LDPR_PREVAILING_DEF_IRONLY + || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || node->resolution == LDPR_PREEMPTED_REG + || node->resolution == LDPR_PREEMPTED_IR + || node->resolution == LDPR_RESOLVED_IR + || node->resolution == LDPR_RESOLVED_EXEC) + resolved_locally = !is_dllimported; + if (node->resolution == LDPR_PREVAILING_DEF + || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP + || node->resolution == LDPR_PREVAILING_DEF_IRONLY) + resolved_to_local_def = true; +
Re: [ C frontend ] add support for builtins that take signed and unsigned md types
On Jan 22, 2012, at 4:53 AM, Richard Guenther wrote: > Why add a new loop? It seems to be bogus to not check signedness in > the existing loop (mind that for fixed-point types you need to check > saturating/nonsaturating flag. We can remove the other loop, if people don't want any of the old semantics. I'll just note, it can break things, though, for ports that are so broken, they can introduce additional signatures to restore how they want it to work. > You miss a testcase where this fix matters. I have a testcase, but it is dependent upon a port that isn't in the tree. I'll plead ignorance of another port that is fixed by the patch.
Re: [Patch, Fortran] PR41600 - fix ICE with type conversion in default initializer
Tobias Burnus wrote: the middle end does not like to fold_convert a real number to an integer, but gfortran does not type-convert the expressions of initialization expressions. This patch fixes the issue And Tobias Schlüter wrote in the PR: (In reply to comment #3) + if (comp->ts.type != comp->initializer->ts.type + || comp->ts.kind != comp->initializer->ts.kind) + gfc_convert_type_warn (ctor->expr,&comp->ts, 2, false); + } Isn't gfc_compare_types() more appropriate or are derived types not allowed? Well, the function gfc_default_initializer should only be reachable if the LHS and the RHS are type compatible. While, "integer = 4.8" and "real = cmplx(1.0, 3.0)" are possible, you cannot have "type(t2) :: x = t1()". Thus, I sincerely hope that such incompatible types are diagnosed before. Hence, doing this simple test should be sufficient. * * * Having said that, the following program compiles without any error - until one tries to use "my_t". (Now filled as PR51945.) type t integer :: i = 3 end type t type, extends(t) :: t2 end type t2 type :: t3 integer :: i = 78 end type t3 type my_t type(t) :: x = t() ! OK type(t) :: y = t2() ! Invalid type(t) :: z = t3() ! Invalid end type my_t ! type(my_t) :: a end Tobias
[Patch, Fortran] PR41600 - fix ICE with type conversion in default initializer
Dear all, the middle end does not like to fold_convert a real number to an integer, but gfortran does not type-convert the expressions of initialization expressions. This patch fixes the issue - and thus part of of the issue of the PR. Build and regtested on x86-64-linux. OK for the trunk? Tobias 2012-01-22 Tobias Burnus PR fortran/41600 * expr.c (gfc_default_initializer): Convert the values if the type does not match. 2012-01-22 Tobias Burnus PR fortran/41600 * gfortran.dg/default_initialization_6.f90: New. diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index 7cea780..8565b81 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3774,7 +3780,13 @@ gfc_default_initializer (gfc_typespec *ts) gfc_constructor *ctor = gfc_constructor_get(); if (comp->initializer) - ctor->expr = gfc_copy_expr (comp->initializer); + { + ctor->expr = gfc_copy_expr (comp->initializer); + if ((comp->ts.type != comp->initializer->ts.type + || comp->ts.kind != comp->initializer->ts.kind) + && !comp->attr.pointer && !comp->attr.proc_pointer) + gfc_convert_type_warn (ctor->expr, &comp->ts, 2, false); + } if (comp->attr.allocatable || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->attr.allocatable)) --- /dev/null 2012-01-22 08:37:16.127677872 +0100 +++ gcc/gcc/testsuite/gfortran.dg/default_initialization_6.f90 2012-01-22 15:46:16.0 +0100 @@ -0,0 +1,11 @@ +! { dg-do compile } +! +! PR fortran/41600 +! + implicit none + type t + integer :: X = -999.0 + end type t + class(t), allocatable :: y(:) + allocate (t :: y(1)) +end
Fix flag_trapping_math in java frontend
The java frontend wants that floating point operations are assumed to never trap, thus clears flag_trapping_math in java_init_options_struct. But this is no longer effective after revision 165823, because set_fast_math_flags is now always called during option processing, overriding anything what the frontend did to flag_trapping_math. This is an amendment to revision 169930 which introduced frontend_set_flag_trapping_math, but didn't set it in java_init_options_struct. While this was found during examination of PR49847, this doesn't fix it, but only makes the bug dormant again in 4.6. Tested on powerpc-linux, ok for trunk and 4.6 branch? Andreas. 2012-01-22 Andreas Schwab * lang.c (java_init_options_struct): Set frontend_set_flag_trapping_math. diff --git a/gcc/java/lang.c b/gcc/java/lang.c index ccab48c..da7dd05 100644 --- a/gcc/java/lang.c +++ b/gcc/java/lang.c @@ -1,6 +1,6 @@ /* Java(TM) language-specific utility routines. Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, - 2005, 2006, 2007, 2008, 2010 Free Software Foundation, Inc. + 2005, 2006, 2007, 2008, 2010, 2012 Free Software Foundation, Inc. This file is part of GCC. @@ -550,6 +550,7 @@ java_init_options_struct (struct gcc_options *opts) /* In Java floating point operations never trap. */ opts->x_flag_trapping_math = 0; + opts->frontend_set_flag_trapping_math = true; /* In Java arithmetic overflow always wraps around. */ opts->x_flag_wrapv = 1; -- 1.7.8.4 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Partial fix for LTO bootstrap with Ada
The LTO bootstrap of the Ada compiler is currently plagued by at least three different problems. The attached patch is for the easy one: it prevents fake variables whose type contains a placeholder from being created, which doesn't work in LTO mode because you cannot instantiate the PLACEHOLDER_EXPRs. IIUC this is only a slight pessimization. Bootstrapped/regtested on x86_64-suse-linux, OK for mainline? 2012-01-22 Eric Botcazou * tree-ssa-structalias.c (intra_create_variable_infos): Do not create fake variables for restrict-qualified pointers whose pointed-to type contains a placeholder. -- Eric Botcazou Index: tree-ssa-structalias.c === --- tree-ssa-structalias.c (revision 183348) +++ tree-ssa-structalias.c (working copy) @@ -5664,7 +5664,8 @@ intra_create_variable_infos (void) Treat restrict qualified references the same. */ if (TYPE_RESTRICT (TREE_TYPE (t)) && ((DECL_BY_REFERENCE (t) && POINTER_TYPE_P (TREE_TYPE (t))) - || TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE)) + || TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE) + && !type_contains_placeholder_p (TREE_TYPE (TREE_TYPE (t { struct constraint_expr lhsc, rhsc; varinfo_t vi;
Fix PR rtl-optimization/51924
This is another problem uncovered by the generalization of the ZEE pass: when the definition insn of an extension is itself an extension, modifying the insn for the first extension breaks the handling of the second extension. This was silent in ZEE because you never have 2 identical successive extensions, but is now exposed in REE. The attached patch implements a minimal fix with the associated FIXME. Tested on x86_64-suse-linux, applied on the mainline. 2012-01-22 Eric Botcazou PR rtl-optimization/51924 * ree.c (combine_set_extension): Improve debugging message. (combine_reaching_defs): Likewise. (get_defs): Rename confusingly named variable. (find_and_remove_re): Skip a candidate if the extension expression has been modified. 2012-01-22 Eric Botcazou * gcc.dg/ext-elim-1.c: New test. -- Eric Botcazou Index: ree.c === --- ree.c (revision 183348) +++ ree.c (working copy) @@ -346,7 +346,8 @@ combine_set_extension (ext_cand *cand, r { if (dump_file) { - fprintf (dump_file, "Merged instruction with extension:\n"); + fprintf (dump_file, + "Tentatively merged extension with definition:\n"); print_rtl_single (dump_file, curr_insn); } return true; @@ -407,21 +408,21 @@ transform_ifelse (ext_cand *cand, rtx de static struct df_link * get_defs (rtx insn, rtx reg, VEC (rtx,heap) **dest) { - df_ref reg_info, *defs; + df_ref reg_info, *uses; struct df_link *ref_chain, *ref_link; reg_info = NULL; - for (defs = DF_INSN_USES (insn); *defs; defs++) + for (uses = DF_INSN_USES (insn); *uses; uses++) { - reg_info = *defs; + reg_info = *uses; if (GET_CODE (DF_REF_REG (reg_info)) == SUBREG) return NULL; if (REGNO (DF_REF_REG (reg_info)) == REGNO (reg)) break; } - gcc_assert (reg_info != NULL && defs != NULL); + gcc_assert (reg_info != NULL && uses != NULL); ref_chain = DF_REF_CHAIN (reg_info); @@ -686,11 +687,10 @@ combine_reaching_defs (ext_cand *cand, r purposes. This extension cannot be deleted. */ if (dump_file) { - FOR_EACH_VEC_ELT (rtx, vec, i, def_insn) -{ - fprintf (dump_file, "Non-mergeable definitions:\n"); - print_rtl_single (dump_file, def_insn); -} + fprintf (dump_file, + "Merge cancelled, non-mergeable definitions:\n"); + FOR_EACH_VEC_ELT (rtx, vec, i, def_insn) + print_rtl_single (dump_file, def_insn); } } } @@ -843,6 +843,12 @@ find_and_remove_re (void) { num_re_opportunities++; + /* If the candidate insn is itself a definition insn for another + candidate, it may have been modified and the UD chain broken. + FIXME: the handling of successive extensions can be improved. */ + if (!reg_mentioned_p (curr_cand->expr, PATTERN (curr_cand->insn))) + continue; + /* Try to combine the extension with the definition. */ if (dump_file) { /* PR rtl-optimization/51924 */ /* Testcase by Zdenek Sojka */ /* { dg-do run } */ /* { dg-options "-O -free -fno-rename-registers -ftree-vectorize -funroll-loops" } */ typedef __UINT64_TYPE__ uint64_t; uint64_t __attribute__ ((noinline, noclone)) bn_sub_words (uint64_t * r, const uint64_t * a, const uint64_t * b, int n) { uint64_t t1, t2; unsigned c = 0; while (n) { t1 = a[0]; t2 = b[0]; r[0] = (t1 - t2 - c); if (t1 != t2) c = (t1 < t2); a++; b++; r++; n--; } return (c); } int main (void) { uint64_t r[2]; uint64_t a[2] = { -1, -1 }; uint64_t b[2] = { 0, 0 }; if (bn_sub_words (r, a, b, 2) != 0) __builtin_abort (); return 0; }
Re: [PATCH] RFC: Interix resurrection
Hello! > Ping. > Patch retested with 1/18/2012 sources. > >> On 1/1/2012 1:01 PM, Douglas Rupp wrote: >> >>This is for 32bit, "C" language only. >>Tested by cross and then cross-native from x86_64 Linux > Build parts are ok. Looking at the patch, I didn't spotted anything obviously wrong. It looks there is no active Interix maintainer listed in MAINTAINERS file, and since in addition to build parts your patch touches only Interix specific files, please go ahead and commit the patch to SVN. So, OK for mainline. Uros.
Re: [ C frontend ] add support for builtins that take signed and unsigned md types
On Sat, Jan 21, 2012 at 12:21 AM, Mike Stump wrote: > unsigned builtins don't always work, as the type matching code can ignore the > signed/unsigned variants when searching for a type with a particular mode. > This patch fixes this problem. If a type with same unsignededness exists, we > prefer it over a type with the same mode, but different unsignededness. > > Ok? Why add a new loop? It seems to be bogus to not check signedness in the existing loop (mind that for fixed-point types you need to check saturating/nonsaturating flag. You miss a testcase where this fix matters. Richard. > 2012-01-20 Mike Stump > > * c-common.c (c_common_type_for_mode): Match signed/unsigned types > exactly. > > Index: c-common.c > === > *** c-common.c (revision 183357) > --- c-common.c (working copy) > *** c_common_type_for_mode (enum machine_mod > *** 3089,3094 > --- 3089,3099 > } > > for (t = registered_builtin_types; t; t = TREE_CHAIN (t)) > + if (TYPE_MODE (TREE_VALUE (t)) == mode > + && !!unsignedp == !!TYPE_UNSIGNED (TREE_VALUE (t))) > + return TREE_VALUE (t); > + > + for (t = registered_builtin_types; t; t = TREE_CHAIN (t)) > if (TYPE_MODE (TREE_VALUE (t)) == mode) > return TREE_VALUE (t); > > >
Re: varpool PATCH for c++/51832 (multiply defined symbol with LTO plugin)
On Fri, Jan 20, 2012 at 8:59 PM, Jason Merrill wrote: > As a result of my recent mangling work, any code that uses variadic > templates will use the forward-compatibility aliases because the mangling of > argument packs has changed. This exposed an issue that we weren't copying > DECL_EXTERNAL from decl to alias along with other linkage flags in > varpool_analyze_pending_decls. Fixed thus. It would be nice for the front > end to fix up the linkage flags appropriately, but this small change seems > preferable for 4.7. > > Tested x86_64-pc-linux-gnu. OK for trunk? Ok. Thanks, Richard.
Re: [PATCH] RFC: Interix resurrection
On 01/01/2012 10:01 PM, Douglas Rupp wrote: -i[[34567]]86-*-interix3*) +i[[34567]]86-*-interix[[3-9]]*) # Interix 3.x gcc -fpic/-fPIC options generate broken code. # Instead, we relocate shared libraries at runtime. ;; Is this still true? Build parts are ok. Paolo
Re: [PATCH] Prevent 'control reaches end of non-void function' warning for DO_WHILE
On 09/12/11 10:45, Richard Guenther wrote: > On Fri, Dec 9, 2011 at 9:38 AM, Tom de Vries wrote: >> Jakub, >> >> This patch fixes the problem reported in >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973#c4 . >> >> The test-case listed there is: >> ... >> struct Block >> { >> public: >>Block(); >>~Block(); >> }; >> >> bool func( bool bar ) >> { >> Block block; >> bool foo = false; >> >> if( !foo || bar ) >>do { return true; } while( 0 ); >> else >>do { return false; } while( 0 ); >> } >> ... >> >> For O0, a spurious warning is generated: >> ... >> $ gcc -O0 -Wreturn-type block.C -S: >> block.C: In function ‘bool func(bool)’: >> block.C:17:1: warning: control reaches end of non-void function >> [-Wreturn-type] >> ... >> > > Hm. I would prefer if the gimplifier is fed GENERIC, not > GENERIC plus FE specific codes ... (both C and C++ do > "genericization" passes, but they actually do not transform > all code to GENERIC). Can you check if it's easy enough to > lower DO_STMT during cp_genericize? Richard, I implement this approach in attached patch. Bootstrapped and reg-tested on x86_64. OK for stage1? I would guess this patch is too intrusive for stage4. Furthermore, should I put PR c++/25973 in the log? The patch fixes the testcase in comment 4, but doesn't seem related to the example listed in the description field of the PR. Thanks, - Tom 2012-01-22 Tom de Vries * cp-gimplify.c (begin_bc_block): Add location parameter and use as location argument to create_artificial_label. (finish_bc_block): Change return type to void. Remove body_seq parameter, and add block parameter. Append label to STMT_LIST and return in block. (gimplify_cp_loop, gimplify_for_stmt, gimplify_while_stmt) (gimplify_do_stmt, gimplify_switch_stmt): Remove function. (genericize_cp_loop, genericize_for_stmt, genericize_while_stmt) (genericize_do_stmt, genericize_switch_stmt, genericize_continue_stmt) (genericize_break_stmt, genericize_omp_for_stmt): New function. (cp_gimplify_omp_for): Remove bc_continue processing. (cp_gimplify_expr): Genericize VEC_INIT_EXPR. (cp_gimplify_expr): Mark FOR_STMT, WHILE_STMT, DO_STMT, SWITCH_STMT, CONTINUE_STMT, and BREAK_STMT as unreachable. (cp_genericize_r): Genericize FOR_STMT, WHILE_STMT, DO_STMT, SWITCH_STMT, CONTINUE_STMT, BREAK_STMT and OMP_FOR. (cp_genericize_tree): New function, factored out of ... (cp_genericize): ... this function. * g++.dg/pr51264-4.C: New test. Index: gcc/cp/cp-gimplify.c === --- gcc/cp/cp-gimplify.c (revision 183325) +++ gcc/cp/cp-gimplify.c (working copy) @@ -34,6 +34,11 @@ along with GCC; see the file COPYING3. #include "flags.h" #include "splay-tree.h" +/* Forward declarations. */ + +static tree cp_genericize_r (tree *, int *, void *); +static void cp_genericize_tree (tree*); + /* Local declarations. */ enum bc_t { bc_break = 0, bc_continue = 1 }; @@ -45,37 +50,42 @@ static tree bc_label[2]; /* Begin a scope which can be exited by a break or continue statement. BC indicates which. - Just creates a label and pushes it into the current context. */ + Just creates a label with location LOCATION and pushes it into the current + context. */ static tree -begin_bc_block (enum bc_t bc) +begin_bc_block (enum bc_t bc, location_t location) { - tree label = create_artificial_label (input_location); + tree label = create_artificial_label (location); DECL_CHAIN (label) = bc_label[bc]; bc_label[bc] = label; return label; } /* Finish a scope which can be exited by a break or continue statement. - LABEL was returned from the most recent call to begin_bc_block. BODY is + LABEL was returned from the most recent call to begin_bc_block. BLOCK is an expression for the contents of the scope. If we saw a break (or continue) in the scope, append a LABEL_EXPR to - body. Otherwise, just forget the label. */ + BLOCK. Otherwise, just forget the label. */ -static gimple_seq -finish_bc_block (enum bc_t bc, tree label, gimple_seq body) +static void +finish_bc_block (tree *block, enum bc_t bc, tree label) { gcc_assert (label == bc_label[bc]); if (TREE_USED (label)) { - gimple_seq_add_stmt (&body, gimple_build_label (label)); + tree expr = NULL; + append_to_statement_list (*block, &expr); + *block = expr; + + append_to_statement_list (build1 (LABEL_EXPR, void_type_node, label), +block); } bc_label[bc] = DECL_CHAIN (label); DECL_CHAIN (label) = NULL_TREE; - return body; } /* Get the LABEL_EXPR to represent a break or continue statement @@ -183,173 +193,232 @@ genericize_if_stmt (tree *stmt_p) evaluated before the loop body as in while and for loops, or after the loop body as in do-while loops. */ -static gimple_seq -
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
Hi Patrick, thanks for doing this, On 21 Jan 2012, at 22:57, Patrick Marlier wrote: Dominique or Iain, may I ask you to test this patch on darwin? I have a sporadic access to a darwin machine. bootstrapped on i686-darwin9 - tests in progress... minor observations: PR lto/51916 * lto-object.c (LTO_SEGMENT_NAME): Define segment name. * lto-wrapper.c ( (lto_obj_file_open): Use it. (run_gcc): cheers Iain
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
> Dominique or Iain, may I ask you to test this patch on darwin? I have a > sporadic access to a darwin machine. The patch fixes the PR without regression on x86_64-apple-darwin10. Bootstraping on powerpc-apple-darwin9 will finish in a couple hours. Thanks for the debugging and the patch, Dominique
Ping^4: Out-of-order update of new_spill_reg_store[]
Ping for this reload patch: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00266.html or perhaps the original: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00663.html which fixes some wrong-code regressions on mips64-linux-gnu. Richard
Re: [RFC combine] PR48308 - Fix issue with missing(?) LOG_LINKS
> The un-combining thing around line 2800 is somewhat of a kludge and I > wouldn't be surprised if there were other fallouts. But your change is > clearly correct and looks relatively safe, so OK for trunk and 4.6 branch > after full testing. I overlooked something though: it might be possible for combine_instructions to try to combine i2 again if the previous combination fails (if it succeeds, i1 is deleted so this is OK) so the stall LOG_LINKS could be problematic. That's why LOG_LINKS (i2) needs to SUBST-ituted like the two lines just above. -- Eric Botcazou
[committed] PR 51931: force non-MIPS16ness for long-branch tests
The MIPS16 port has never handled long branches properly; see PR 51931 for the details. It isn't easy to xfail MIPS16-specific problems at the dejagnu level because of -mflip-mips16, so the patch below forces a nomips16 attribute instead. Tested on mips64-linux-gnu and applied. Richard gcc/testsuite/ PR target/51931 * gcc.c-torture/compile/20001226-1.c: Add nomips16 attribute. * g++.dg/opt/longbranch1.C: Likewise. Index: gcc/testsuite/gcc.c-torture/compile/20001226-1.c === --- gcc/testsuite/gcc.c-torture/compile/20001226-1.c2012-01-21 11:06:35.0 + +++ gcc/testsuite/gcc.c-torture/compile/20001226-1.c2012-01-21 11:24:26.0 + @@ -21,6 +21,10 @@ #define C256(x,y) C64(x,y) C64(x,y+4) C6 #define C1024(x,y) C256(x,y) C256(x+16,y) C256(x+32,y) C256(x+48,y) #define C4096(x,y) C1024(x,y) C1024(x,y+16) C1024(x,y+32) C1024(x,y+48) +#ifdef __mips +/* See PR 51931. */ +__attribute__((nomips16)) +#endif unsigned foo(int x[64], int y[64]) { C4096(x,y); Index: gcc/testsuite/g++.dg/opt/longbranch1.C === --- gcc/testsuite/g++.dg/opt/longbranch1.C 2012-01-21 11:24:44.0 + +++ gcc/testsuite/g++.dg/opt/longbranch1.C 2012-01-21 11:24:48.0 + @@ -26,6 +26,10 @@ #define verymuchcode \ muchcode; muchcode; muchcode; muchcode; muchcode; muchcode; \ muchcode; muchcode; muchcode; muchcode; muchcode; muchcode +#ifdef __mips +/* See PR 51931. */ +__attribute__((nomips16)) +#endif int main (int argc, char **argv) {