>Number:         153959
>Category:       gnu
>Synopsis:       Minor mips-specific gcc update
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          update
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 13 18:30:10 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Pedro F. Giffuni
>Release:        8.2-RC1
>Organization:
>Environment:
Non-relevant ... this only applies to MIPS platform.
>Description:
While I was looking for some GPLv2 updates for GCC
(submitted as gnu/153298), I noticed this MIPS specific
change that was committed upstream before the GPLv3 switch:
______
2007-08-20  Adam Nemet  <ane...@caviumnetworks.com>

    * config/mips/predicates.md
(const_call_insn_operand): Invoke
    SYMBOL_REF_LONG_CALL_P only on
SYMBOL_REFs.

http://gcc.gnu.org/viewcvs/branches/gcc-4_2-branch/gcc/config/mips/predicates.md?r1=117923&r2=127658&pathrev=127959
______

I have no idea of the relevance of the issue and I
don't have a MIPS platform to try this so I didn't
include it in the patchset, but it is to be the
expected behavior in upstream gcc, so I believe it
should be committed.
>How-To-Repeat:

>Fix:
The following patch applies cleanly to base gcc.

Patch attached with submission follows:

--- gcc/config/mips/predicates.md       2006/10/21 02:41:38     117923
+++ gcc/config/mips/predicates.md       2007/08/21 00:50:59     127658
@@ -116,7 +116,9 @@
       /* If -mlong-calls, force all calls to use register addressing.  Also,
         if this function has the long_call attribute, we must use register
         addressing.  */
-      return !TARGET_LONG_CALLS && !SYMBOL_REF_LONG_CALL_P (op);
+      return (!TARGET_LONG_CALLS
+             && !(GET_CODE (op) == SYMBOL_REF
+                  && SYMBOL_REF_LONG_CALL_P (op)));
 
     case SYMBOL_GOT_GLOBAL:
       /* Without explicit relocs, there is no special syntax for


>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Reply via email to