[PATCH] Proposed fix for bug #31899

Hi,

    Could someone review and approve this? Thanks.

-Doug

2007-07-26  Doug Kwan  <dougkwan <at> google.com>

  * dwarf2out.c: (may_reference_to_unsued) : Renamed from reference_to_unsued
    as it is now more conservative than before. Replace unreachable assert
    into a return that tells caller that tree may reference an unused DECL.
    (rtl_for_decl_init): Rename callee to may_reference_to_usused.

--- dwarf2out.c.orig	2007-07-26 11:28:11.000000000 -0700
+++ dwarf2out.c	2007-07-26 11:31:33.000000000 -0700
 <at>  <at>  -9993,9 +9993,10  <at>  <at> 
 /* Determine whether the evaluation of EXPR references any variables
    or functions which aren't otherwise used (and therefore may not be
    output).  */
+
 static tree
-reference_to_unused (tree * tp, int * walk_subtrees,
-		     void * data ATTRIBUTE_UNUSED)
+may_reference_to_unused (tree * tp, int * walk_subtrees,
+			 void * data ATTRIBUTE_UNUSED)
 {
   if (! EXPR_P (*tp) && ! CONSTANT_CLASS_P (*tp))
     *walk_subtrees = 0;
 <at>  <at>  -10007,7 +10008,12  <at>  <at> 

Re: New back end ia16: 16-bit Intel x86

On Tue, Jul 31, 2007 at 01:44:56PM -0400, Ross Ridge wrote:
> Michael Matz writes:
> > Blaeh, that's all ugly.  I actually think that ia16 is a reasonable name 
> >for this ISA, even though Rask just made it up.
> 
> I think "ia16" is an ugly backformation and being made up like this
> there's a risk of it conflicting with something else in the future.

   I did not make it up. Try asking Google for "Intel IA16" or "Intel
IA-16". At least one search result is 7 (seven) years old. It is also clear
from the search results that outside of Intel, IA16 or IA-16 means the
16-bit x86 family members i8086-i80286 and IA32 or IA-32 means x86 family
members starting with the i80386.

> >It's generating code for the 16 bit mode (which works on all the intel
> >CPUs) which for all practical measures is a different CPU architecture
> >than the same chip in 32bit or 64bit mode (it just happens to share some
> >mnemonics and insn encodings).
> 
> That's absurd.  By sharing the same instruction set and registers, for
> "all practical measures" it is the same CPU architecture.

   You know, over the years Intel (and for x86-64, AMD) fixed (or worked
around) many shortcomings of the i8086:

   1) Addressing modes, most notably the lack of sp relative addressing.
   2) Tight register constraints.
   3) Registers with no 8-bit move instructions.
   4) Lack (or prohibitive slowness) of useful instructions.

PATCH: libiberty/make-relative-prefix.c, resource leak.

gmane.comp.gcc.patches

2007-07-31  Michael Snyder  <msnyder <at> access-company.com>

	* make-relative-prefix.c (make_relative_prefix_1): Resource leak.

Index: make-relative-prefix.c
===================================================================
RCS file: /cvs/src/src/libiberty/make-relative-prefix.c,v
retrieving revision 1.9
diff -p -r1.9 make-relative-prefix.c
*** make-relative-prefix.c	11 Apr 2007 20:01:26 -0000	1.9
--- make-relative-prefix.c	1 Aug 2007 01:13:35 -0000
*************** make_relative_prefix_1 (const char *prog
*** 299,309 ****
      full_progname = strdup(progname);

    prog_dirs = split_directories (full_progname, &prog_num);
-   bin_dirs = split_directories (bin_prefix, &bin_num);
    free (full_progname);
!   if (bin_dirs == NULL || prog_dirs == NULL)
      return NULL;

    /* Remove the program name from comparison of directory names.  */
    prog_num--;

--- 299,315 ----
      full_progname = strdup(progname);

    prog_dirs = split_directories (full_progname, &prog_num);

Re: PATCH: bug in find_reloads_address_part

Sandra Loosemore <sandra <at> codesourcery.com> writes:

> One of the new MIPS features I'm working on tripped over an obvious
> bug in reload.c.  This patch fixes the particular problem I ran into,
> but could someone who's familiar with this code look and see if the
> first branch of the if (where X is a constant and not a PLUS
> containing a constant) is also incorrect in passing &tem instead of
> &x?  It looks suspicious to me.
> 
> -Sandra
> 
> 
> 2007-07-19  Sandra Loosemore  <sandra <at> codesourcery.com>
> 
> 	gcc/
> 	* reload.c (find_reloads_address_part):  Pass correct MEMREFLOC
> 	argument to find_reloads_address.

I have to agree that this appears to fix an obvious bug.  However,
it's rather unnerving that this bug appears to have existed since the
beginning of time.

I think the code in the first part of find_reloads_address_part should
almost certainly pass loc rathern than &tem in the call to
find_reloads_address.

I'll approve your patch and that patch if they pass bootstrap and
testing on a primary platform.

Thanks.

Re: [PATCH] drop MAXPATHLEN dependency from gcc/tlink.c

Samuel Thibault <samuel.thibault <at> ens-lyon.org> writes:

> Some systems don't define MAXPATHLEN because they don't have such hard
> limit.  Here is a patch against gcc/tlink.c to take benefit of this.
> 
> Samuel
> 
> 2007-07-24  Samuel Thibault  <samuel.thibault <at> ens-lyon.org>
> 
> 	* gcc/tlink.c (initial_cwd): Change type into char*.
> 	(tlink_init): Add loop to dynamically allocate initial_cwd as needed.

Just call getpwd instead.

Thanks.

Ian

PATCH: libiberty/cp-demangle.c, guard against null

gmane.comp.gcc.patches

2007-07-31  Michael Snyder  <msnyder <at> access-company.com>

	* cp-demangle.c (d_print_comp): Guard against null.

Index: cp-demangle.c
===================================================================
RCS file: /cvs/src/src/libiberty/cp-demangle.c,v
retrieving revision 1.67
diff -p -r1.67 cp-demangle.c
*** cp-demangle.c	6 May 2007 00:25:11 -0000	1.67
--- cp-demangle.c	1 Aug 2007 01:41:03 -0000
*************** d_print_comp (struct d_print_info *dpi,
*** 2912,2917 ****
--- 2912,2923 ----
  	    typed_name = d_left (typed_name);
  	  }

+ 	if (typed_name == NULL)
+ 	  {
+ 	    d_print_error (dpi);
+ 	    return;
+ 	  }
+ 
  	/* If typed_name is a template, then it applies to the
  	   function type as well.  */
  	if (typed_name->type == DEMANGLE_COMPONENT_TEMPLATE)

Re: PING: Re: patch: libiberty adjustments for _WIN64

Kai Tietz <Kai.Tietz <at> onevision.com> writes:

> Daniel Jacobowitz wrote on 25.07.2007 23:48:07:
> 
> > On Wed, Jul 25, 2007 at 04:51:02PM -0400, DJ Delorie wrote:
> > > 
> > > > As far as I can see, the type used here is never exposed outside of
> > > > the pex_run interface.
> > > 
> > > Hmmm.. maybe I was thinking of some other libiberty interface, then.
> > > Perhaps hash tables?
> > 
> > I think that was the splay tree keys.
> 
> Yes, the splay tree keys are this issue.
> 
> But why can't we use the 'pid_t' type for pex ?

Just because the pex code is intended to be highly portable, and not
every system defines a pid_t type.  You can use pid_t if you make sure
that it is defined reasonably.

Ian

[PATCH] Fix IV-opts so it no longer produces MEM[index:]

Hi,
  The problem here is that add_candidate_1 is using generic_type_for which 
causes the pointer type be converted over to sizetype and so when we go to 
use that candidate, we create MEM[index:].  This changes that and fixes up 
all the fallout in the testsuite I could find (including two new issues 
which showed up after the summit, I had originally tested it before the 
summit but I decided to test it again before submitting it).  The fall out 
is having tree-affine use sizetype of the steps, fixing up add_to_parts to 
use POINTER_PLUS_EXPR instead of PLUS_EXPR for pointers, create_iv use 
sizetype variable for the step for pointer types, and also fixing up parts 
of iv-opts to use sizetype for steps.  The main reason why I am doing this 
is to reduce the memory usage after IV-opts and also so maybe we can rerun 
may_alias after iv-opts and not get confused as much and it is nice to see 
no cast from pointer types to sizetype in the code any more and I think it 
also helps out with the REG_POINTER issue when I get rid of the 
DECL_AFTICIAL clause as we have a real pointer type here now.

OK? Bootstrapped and tested on i686-linux-gnu and powerpc64-linux-gnu with 
no regressions.

Thank,
Andrew Pinski

ChangeLog:

        * tree-ssa-loop-manip.c (create_iv): Use a new temp
        variable for the step with the correct type.
        * tree-ssa-loop-ivopts.c (find_bivs): Convert the step
        to sizetype if type is a pointer type.
        (add_candidate_1): Don't convert the base and step to

MIPS PATCH: additional mips16 hard float library support

This patch adds mips16 library support for unordered float/double comparisons 
and conversions to float/double from unsigned.  Tests clean on both mips32r2 and 
mips64.  OK to commit?

-Sandra

PATCH: Fix PR 32953

GCC gives the wrong warning with -Wformat for unterminated format strings
of length 1:

	/* bar.c */
#include <stdio.h>
const char s[1] = "s";
int
main (void)
{
  printf (s);
  return 0;
}

$ gcc-svn -std=gnu99 -Wformat=2 bar.c
bar.c: In function 'main':
bar.c:6: warning: zero-length printf format string

Which is wrong since the string is not zero-length, it's unterminated.
This patch fixes that, with testcase included.  I bootstrapped and ran
the tests for gcc and g++.  OK to commit?

gcc/
2007-07-31  Dan Hipschman  <dsh <at> google.com>

	PR 32953
	* c-format.c (check_format_arg): Move check for zero-length
	format strings below the check for unterminated strings.

testsuite/