RE: Thoughts on imposing a 100k per-comment limit

[Dave Korn]

On 01 February 2006 05:43, Daniel Berlin wrote:

> I was staring at the comment database, and noticed

> I can't imagine *any* of these comments are useful to human beings to
> read. 

  Did you browse a few?  I'm curious, my guess would be that they're mostly 
huge rtl dumps.
 
> If you dump the comment text from the >100k comments into a file, it's
> actually 71 meg of comments. 
> 
> These 271 comments make up ~40% of the space used in the entire comment
> database of 26k bugs. 
> 
> (All these are from RESOLVED bugs, BTW)
> 
> 
> Would anyone object to me just telling bugzilla to reject comments > 100k
> in length? 
> 
> (i've chosen 100k to keep arguments about what the "right" length is.  I
> believe *everyone* can agree that 100k is over that length :P ) 

  Seems reasonable to me.  Perhaps even better would be if it automagically 
turned >100k comments into gzipped attachments instead
of discarding/rejecting them altogether, but that would be a wish-list feature 
for v2 I guess ...


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

alias: Varying struct and fixed scalar question

[Andreas Krebbel]

Hi,

in true_dependence (alias.c) a varying struct
address is considered to never alias a fixed scalar value. This
rule is triggered also in something like the following:

struct foo { int n; };
extern unsigned long c = 0;

{
  int b;

  b = 2;
  ((struct foo*)(&b + c))->n = 3;
}

This is a bit oversimplifyfied. The real testcase unfortunately fails
only on s390 but there with gcc 2.95, 3.4 and 4.2.

true_dependence asks fixed_scalar_and_varying_struct_p whether these
MEMs may be an alias for each other.

The address of b on the stack (%fp - frame pointer):
(mem/f:DI (plus:DI (reg/f:DI 34 %fp)
(const_int 160 [0xa0])) [4 b+0 S8 A64])

&b + c
(mem/s:DI (plus:DI (reg:DI 74)
(plus:DI (reg/f:DI 34 %fp)
(const_int 160 [0xa0]))) [0 .n+0 S8 A64])

It can be seen that the first MEM has a 'scalar' flag and the second
an 'in struct' flag.

Although I must admit that this doesn't seem to be very sane code
I was wondering why gcc considers these MEMs to not alias each other although
both have the same base address? What c99 rule would back this behaviour?

According to c99 I would say the memory of b should be safely accessible
using a pointer cast to (struct foo*) because the struct member has the
same type as b:

'An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
...
an aggregate or union type that includes one of the aforementioned 
types among its members (including, recursively, a member of a 
subaggregate or contained union), or
...'

Bye,

-Andreas-

Re: alias: Varying struct and fixed scalar question

[Richard Guenther]

On 2/1/06, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> in true_dependence (alias.c) a varying struct
> address is considered to never alias a fixed scalar value. This
> rule is triggered also in something like the following:
>
> struct foo { int n; };
> extern unsigned long c = 0;
>
> {
>   int b;
>
>   b = 2;
>   ((struct foo*)(&b + c))->n = 3;
> }

I believe this is invalid due to the non-transitive alias relation
involved.  I.e.
an access of an object of type struct foo through type int aliases, but not
the other way around.

Richard.

Re: alias: Varying struct and fixed scalar question

[Andreas Krebbel]

> struct foo { int n; };
> extern unsigned long c = 0;
> 
> {
>   int b;
> 
>   b = 2;
>   ((struct foo*)(&b + c))->n = 3;
> }

For having a true dependency the example should look like this:

struct foo { int n; };
extern unsigned long c = 0;

{
  int b;
  int d;

  b = 2;
  d = ((struct foo*)(&b + c))->n;
}

Bye,

-Andreas-

Re: alias: Varying struct and fixed scalar question

[Andrew Haley]

Andreas Krebbel writes:
 > 
 > > struct foo { int n; };
 > > extern unsigned long c = 0;
 > > 
 > > {
 > >   int b;
 > > 
 > >   b = 2;
 > >   ((struct foo*)(&b + c))->n = 3;
 > > }
 > 
 > For having a true dependency the example should look like this:
 > 
 > struct foo { int n; };
 > extern unsigned long c = 0;
 > 
 > {
 >   int b;
 >   int d;
 > 
 >   b = 2;
 >   d = ((struct foo*)(&b + c))->n;
 > }

6.7.2.1:  A pointer to a struct object, suitably converted, points to
its initial member, and vice versa.

However, that doesn't imply that you can convert a pointer to an
arbitrary scalar to a pointer to a structure whose initial member has
the same type as the scalar.

Andrew.

Re: Regular LAPACK testing

[Andrew Pinski]

On Feb 1, 2006, at 1:47 AM, Jerry DeLisle wrote:

I would like to get regular LAPACK regression testing and automatic 
reporting set up.


Is there a gcc.gnu server somewhere that I can get access to to set 
this up and have it run once daily?


You can use the compiler farm servers:
http://gcc.gnu.org/wiki/CompileFarm

-- Pinski

Re: Thoughts on imposing a 100k per-comment limit

[Daniel Berlin]

Dave Korn wrote:
> On 01 February 2006 05:43, Daniel Berlin wrote:
> 
>> I was staring at the comment database, and noticed
> 
>> I can't imagine *any* of these comments are useful to human beings to
>> read. 
> 
>   Did you browse a few?  I'm curious, my guess would be that they're mostly 
> huge rtl dumps.

They are mostly people pasting very large preprocessed source into the
comments.

>

Re: Generalize ready list sorting via heuristics in rank_for_schedule.

[Ian Lance Taylor]

Peter Steinmetz <[EMAIL PROTECTED]> writes:

> Currently, within the ready_sort macro in haifa-sched.c, the call to qsort
> is passed "rank_for_schedule" to help it decide which of two instructions
> should be placed further towards the front of the ready list.
> Rank_for_schedule uses a set of ordered heuristics (rank, priority, etc.)
> to make this decision.  The set of heuristics is fixed for all target
> machines.
> 
> There can be cases, however, where a target machine may want to define
> heuristics driven by specific characteristics of that machine.  Those
> heuristics may be meaningless on other targets.
> 
> Likewise, a given target machine may prefer a different order in which to
> check the heuristics, possibly going as far as checking them in a different
> order based on which pass of the scheduler is running.
> 
> I'd be interested in seeing "rank_for_schedule" converted into a scheduler
> target hook.  Target machines would then have the flexibility to define
> further heuristics for determining sort order.  The default for an
> undefined hook would be to use the current algorithm,
> 
> One could go a step further and break each heuristic out into a separate
> function.  This would allow target machines to specify to the scheduler a
> list of which heuristics to apply and an order in which to apply them.  A
> target machine could also define its own heuristic functions and include
> them in the heuristic ordering for that target.  In addition, a different
> set of heuristics, or a different ordering could be applied based on which
> pass of the scheduler is running.
> 
> I'd like to start experimenting with this, but would appreciate any
> comments or suggestions from others that may be familiar with this code.

This seems like a good idea to me.

In the past, I've changed the code to track register pressure as it
goes along, and rank by register pressure ahead of priority when the
pressure was getting close to the number of available registers.  This
gave me good results on XScale.  I never got around to tracking
register pressure by register class, though.  On x86 it might be
interesting to enable to first scheduling pass but to always use
register pressure first when ranking instructions.

I'll note that although this wasn't a difficult change, the harder
part was not in rank_for_schedule, it was in updating the register
pressure information for the other instructions after choosing an
instruction in which the register formerly died, but after the
rearrangement was now used by a later instruction.

Ian

Re: reload madness, question

[Ian Lance Taylor]

DJ Delorie <[EMAIL PROTECTED]> writes:

> I'm looking at an insn that has these reloads [attached].  Note that
> reload2 is not needed IF the reload 1 gets resolved.  I haven't
> figured out yet how to tell gcc this.  Suggestions?  The fb+0
> construct is something I create to recognize patterns that I've set up
> during legitimize_reload_address; eventually fb gets copied to a0.
> 
> This is, of course, for m32c.
> 
> Reload 0: reload_in (HI) = (reg/f:HI 0 r0 [1956])
>   A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
>   reload_in_reg: (reg/f:HI 0 r0 [1956])
> Reload 1: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
>   (const_int 0))
>   A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1)
>   reload_in_reg: (plus:HI (reg/f:HI 7 fb)
>   (const_int 0))
> Reload 2: reload_in (HI) = (mem/c:HI (plus:HI (plus:HI (reg/f:HI 7 fb)
>  (const_int 0))
> (const_int -170)) [246 p+0 S2 A8])
>   A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), can't combine
>   reload_in_reg: (reg/v/f:HI 1722 [ p ])

How could reload 1 not get resolved?

When you are looking at reload 2 in some predicate, can you simply
assume that reload 1 will get resolved, and report that the mem
matches the predicate?

Ian

Re: reload madness, question

[DJ Delorie]

> How could reload 1 not get resolved?

Well, it always does, if it gets that far.

> When you are looking at reload 2 in some predicate, can you simply
> assume that reload 1 will get resolved, and report that the mem
> matches the predicate?

Tried it, didn't help.

Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC

[Albert Chin]

We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
compiler. The compiler mangled a function name in a .cpp file though
it was declared extern "C" in the .h file. After a post to the HP C++
developers list, we were told this behavior is correct. GCC 4.0.2 does
not do this so I'd like to get your opinion.

$ cat mangle-1.cc
typedef enum {
  XSLDBG_MSG_THREAD_NOTUSED,
  XSLDBG_MSG_THREAD_INIT
} XsldbgMessageEnum;

extern "C" {
  void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
 const void *data));
}

static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
  const void *data) = 0;

void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
   const void *data))
{
  notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
}

$ g++ --version
g++ (GCC) 4.0.2 (TWW)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ g++ -c mangle-1.cc
$ nm mangle-1.o | grep -i xsldbg
 b notifyXsldbgAppFuncPtr
 T xsldbgSetAppFunc

So, GCC isn't mangling it. Now for the HP C++ compiler:
  [HP-UX 11.23/IA]
  $ aCC -AA -c mangle-1.cc
  # nm mangle-1.o | grep -i xsldbg
  [9]  |0|  48|FUNC |GLOB |0|   
.text|_Z16xsldbgSetAppFuncPFi17XsldbgMessageEnumPKvE

Let's try some other compilers:
  [Solaris 8]
  $ CC -V
  CC: Sun C++ 5.5 Patch 113817-15 2005/10/25
  $ CC -c mangle-1.cc
  "mangle-1.cc", line 15: Warning: function void(int(*)(XsldbgMessageEnum,const 
void*)) overloads extern "C" void(extern "C" int(*)(XsldbgMessageEnum,const 
void*)) because of different language linkages.
  1 Warning(s) detected.
  $ nm mangle-1.o | grep -i xsldbg
  [4] |16|  36|FUNC |GLOB |0|2 
|__1cQxsldbgSetAppFunc6FpFnRXsldbgMessageEnum_pkv_i_v_
  [3] | 0|   4|OBJT |LOCL |0|3 |notifyXsldbgAppFuncPtr

  [IRIX 6.5]
  $ CC -version
  MIPSpro Compilers: Version 7.4.4m
  $ CC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  [3] | 0|  40|FUNC |GLOB |DEFAULT  |5 |xsldbgSetAppFunc
  [16]| 0|   0|STAT |LOCL |DEFAULT 
|MIPS_DATA|notifyXsldbgAppFuncPtr

  [AIX 5.3]
  $ xlC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  .xsldbgSetAppFuncT   0
  xsldbgSetAppFunc D  88  12
  xsldbgSetAppFunc d  80   4

  [Tru64 UNIX 5.1]
  $ cxx -version V7.1-006 -V
  Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1 (Rev. 732)
  Compiler Driver V7.1-006 (cxx) cxx Driver
  $ cxx -version V7.1-006 -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg  
  xsldbgSetAppFunc(int (*)(XsldbgMessageEnum, const void*)) |  
| T | 0008

So, it looks like the HP-UX/IA, Sun, and Tru64 UNIX C++ compilers
mangle but the AIX, SGI, and GNU C++ compilers do not.

Fixing mangle-1.c for HP, Sun, and Tru64 UNIX is easy (after the HP
developer told me how to do it):
  $ cat mangle-2.cc
  typedef enum {
XSLDBG_MSG_THREAD_NOTUSED,
XSLDBG_MSG_THREAD_INIT
  } XsldbgMessageEnum;

  typedef int (*notifyXsldbgAppFuncType) (XsldbgMessageEnum type,
  const void *data);

  extern "C" {
void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc);
  }

  static notifyXsldbgAppFuncType notifyXsldbgAppFuncPtr = 0;

  void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc) {
notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
  }

According to the HP developer:
 >This is a subtle one that we see fairly often.  The problem is that
 >there are two functions xsldbgSetAppFunc with different types.  The
 >first (the declaration) has a parameter of type
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >and that parameter has C linkage.  The second (the definition, which
 >ends up being mangled) has a parameter of type:
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >but that parameter has C++ linkage.  Since this is recognized as a
 >different function because of the difference in parameter, and is not
 >itself enclosed in an extern "C" block, it is mangled.
 >
 >To get these to match, you need to define a type for the parameter
 >which has C linkage and use it in both places, or place the entire
 >definition in an extern "C" block, if that will fork for your actual
 >situation.

 >The linkage of a parameter that is a function is considered in its type.   
 >One has C linkage, the other C++ linkage.  It is subtle.

Who is right?

-- 
albert chin ([EMAIL PROTECTED])

x86 Darwin an libgcc-math

[Shantonu Sen]

With trunk and those set of patches, x86 Darwin bootstraps and builds  
libgcc-math. However, there are some issues actually using it:


alias:/tmp ssen$ cat test.c
#include 
#include 

int main(int argc, char *argv[]) {
  double a = 1.5900;
  printf("%f\n", sin(a));
  return 0;
}
alias:/tmp ssen$ /opt/gcc/bin/gcc -o test test.c -msselibm
/usr/bin/ld: Undefined symbols:
___libm_sse2_sin
collect2: ld returned 1 exit status
alias:/tmp ssen$

The problem appears to be that Darwin's specs override  
LINK_COMMAND_SPEC and don't include %(link_gcc_math). Something like  
this may be needed:

Index: config/darwin.h
===
--- config/darwin.h (revision 110474)
+++ config/darwin.h (working copy)
@@ -202,17 +202,17 @@
#define LINK_COMMAND_SPEC "\
%{!fdump=*:%{!fsyntax-only:%{!precomp:%{!c:%{!M:%{!MM:%{!E:%{!S:\
 %{!Zdynamiclib:%(linker)}%{Zdynamiclib:/usr/bin/libtool} \
 %l %X %{d} %{s} %{t} %{Z} \
 %{!Zdynamiclib:%{A} %{e*} %{m} %{N} %{n} %{r} %{u*} %{x} %{z}} \
 %{@:-o %f%u.out}%{!@:%{o*}%{!o:-o a.out}} \
 %{!Zdynamiclib:%{!A:%{!nostdlib:%{!nostartfiles:%S \
 %{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate| 
coverage:-lgcov} \

-%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %G %L}} \
+%{!nostdlib:%{!nodefaultlibs:%(link_gcc_math) %(link_ssp) %G %L}} \
 %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} "

/* Please keep the random linker options in alphabetical order (modulo
'Z' and 'no' prefixes).  Options that can only go to one of libtool
or ld must be listed twice, under both !Zdynamiclib and
Zdynamiclib, with one of the cases reporting an error.  */
/* Note that options taking arguments may appear multiple times on a
command line with different arguments each time, so put a * after


However, once you make that change:
alias:/tmp ssen$ /opt/gccmath-bootstrap/bin/gcc -o test test.c -msselibm
symbol ___isinf used from dynamic library /usr/lib/libSystem.dylib 
(xmm_misc.o) not from earlier dynamic library /opt/gccmath-bootstrap/ 
lib/libgcc-math.0.dylib(libsse2_la-s_isinf.o)
symbol ___isinff used from dynamic library /usr/lib/libSystem.dylib 
(xmm_misc.o) not from earlier dynamic library /opt/gccmath-bootstrap/ 
lib/libgcc-math.0.dylib(libsse2_la-s_isinff.o)
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding  
may result in errors or different symbols being used

alias:/tmp ssen$

Is it intentional that these functions have global visibility and  
interfere with functions declared and implemented by the system  
libraries? If not, can they be compilied with hidden visibility?


Shantonu

Re: Regular LAPACK testing

[Janis Johnson]

On Tue, Jan 31, 2006 at 10:47:09PM -0800, Jerry DeLisle wrote:
> I would like to get regular LAPACK regression testing and automatic 
> reporting set up.
> 
> Is there a gcc.gnu server somewhere that I can get access to to set this up 
> and have it run once daily?
> 
> This is mostly to catch gfortran regressions as well as an occasional 
> back-end or middle-end bug.

If you update http://gcc.gnu.org/testing/testing-lapack.html I'll run it
occasionally on powerpc64-unknown-linux-gnu.  With g77 the LAPACK results
varied widely from one target to another, so it would be useful to verify
a baseline so I can recognize regressions and report them.

Janis

Re: x86 Darwin an libgcc-math

[Paolo Bonzini]

Is it intentional that these functions have global visibility and  
interfere with functions declared and implemented by the system  
libraries? If not, can they be compilied with hidden visibility?


Yes (I originally tried to "see what happens if we use the glibc 
routines", then I shared the code with Richard who did the configury and 
the back-end patches.  glibc people do not try to make life easy for 
people that use their code outside glibc, but I forgot to tell him about 
this...).


Paolo

Re: Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC

[Andrew Pinski]

> 
> We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> compiler. The compiler mangled a function name in a .cpp file though
> it was declared extern "C" in the .h file. After a post to the HP C++
> developers list, we were told this behavior is correct. GCC 4.0.2 does
> not do this so I'd like to get your opinion.
> 
> $ cat mangle-1.cc
> typedef enum {
>   XSLDBG_MSG_THREAD_NOTUSED,
>   XSLDBG_MSG_THREAD_INIT
> } XsldbgMessageEnum;
> 
> extern "C" {
>   void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
>  const void *data));
> }
> 
> static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
>   const void *data) = 0;
> 
> void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
>const void *data))
> {
>   notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
> }

This is most likely very related to PR 2316 where GCC does not use language
as the overloaded part.  

-- Pinski

Upated memory hog patch for make

[H. J. Lu]

On Wed, Feb 01, 2006 at 06:33:40PM +0100, Klaus Singvogel wrote:
> 
> Hello Mr. H. J. Lu,
> I just want to inform you, that we got a problem report regarding your
> "memory hog" patch from 2005-Dec-08 for gmake-3.80. If compilation of
> "binutils" is started with "MALLOC_CHECK_=2", a crash in gmake occurs.
> 
> I digged a bit deeper into it and noticed this:
> 

My memory hog patch for make has 2 typos. This patch fixes them.


H.J.
--- make-3.80/file.c.memory 2002-10-03 19:13:42.0 -0700
+++ make-3.80/file.c2006-02-01 10:45:32.0 -0800
@@ -434,7 +434,7 @@ snap_deps ()
if (d->file == 0)
  d->file = enter_file (d->name);
else
- free (d->name);
+ hash_strfree (d->name);
d->name = 0;
  }
   free (file_slot_0);
--- make-3.80/implicit.c.memory 2002-09-04 00:26:19.0 -0700
+++ make-3.80/implicit.c2006-02-01 10:45:32.0 -0800
@@ -539,7 +539,7 @@ pattern_search (file, archive, depth, re
  dep->file = enter_file (dep->name);
   /* enter_file uses dep->name _if_ we created a new file.  */
   if (dep->name != dep->file->name)
-free (dep->name);
+hash_strfree (dep->name);
  dep->name = 0;
  dep->file->tried_implicit |= dep->changed;
}
--- make-3.80/main.c.memory 2002-08-09 18:27:17.0 -0700
+++ make-3.80/main.c2006-02-01 10:45:32.0 -0800
@@ -501,6 +501,7 @@ initialize_global_hash_tables ()
   init_hash_files ();
   hash_init_directories ();
   hash_init_function_table ();
+  init_hash_strings ();
 }
 
 static struct file *
--- make-3.80/make.h.memory 2002-09-11 09:55:44.0 -0700
+++ make-3.80/make.h2006-02-01 10:45:32.0 -0800
@@ -427,6 +427,11 @@ extern char *find_char_unquote PARAMS ((
 extern char *find_percent PARAMS ((char *));
 extern FILE *open_tmpfile PARAMS ((char **, const char *));
 
+extern void init_hash_strings PARAMS ((void));
+extern char *hash_strdup PARAMS ((const char *));
+extern char *hash_savestring PARAMS ((const char *, unsigned int));
+extern void hash_strfree PARAMS ((char *));
+
 #ifndef NO_ARCHIVES
 extern int ar_name PARAMS ((char *));
 extern void ar_parse_name PARAMS ((char *, char **, char **));
--- make-3.80/misc.c.memory 2002-09-12 15:15:58.0 -0700
+++ make-3.80/misc.c2006-02-01 11:05:44.0 -0800
@@ -18,8 +18,10 @@ along with GNU Make; see the file COPYIN
 the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  */
 
+#include 
 #include "make.h"
 #include "dep.h"
+#include "hash.h"
 #include "debug.h"
 
 /* Variadic functions.  We go through contortions to allow proper function
@@ -564,7 +566,7 @@ copy_dep_chain (d)
   c = (struct dep *) xmalloc (sizeof (struct dep));
   bcopy ((char *) d, (char *) c, sizeof (struct dep));
   if (c->name != 0)
-   c->name = xstrdup (c->name);
+   c->name = hash_strdup (c->name);
   c->next = 0;
   if (firstnew == 0)
firstnew = lastnew = c;
@@ -891,3 +893,154 @@ atomic_readdir(dir)
 }
 
 #endif  /* HAVE_BROKEN_RESTART */
+
+/* Hash table of duplicated strings.  */
+
+struct hash_string
+{
+  char *string;
+  unsigned int count;
+};
+
+static unsigned long
+string_hash_1 (key)
+const void *key;
+{
+  return_ISTRING_HASH_1 (((const struct hash_string *) key)->string);
+}
+
+static unsigned long
+string_hash_2 (key)
+const void *key;
+{
+  return_ISTRING_HASH_2 (((const struct hash_string *) key)->string);
+}
+
+static int
+string_hash_cmp (x, y)
+const void *x;
+const void *y;
+{
+  return_ISTRING_COMPARE (((const struct hash_string *) x)->string,
+ ((const struct hash_string *) y)->string);
+}
+
+static struct hash_table strings;
+
+void
+init_hash_strings ()
+{
+  hash_init (&strings, 1000, string_hash_1, string_hash_2,
+string_hash_cmp);
+}
+
+/* Keep track duplicated string and return the old one if exists.  */
+
+char *
+hash_strdup (ptr)
+ const char *ptr;
+{
+  struct hash_string *h, key;
+  
+  if (*ptr == '\0')
+return "";
+
+  key.string = (char *) ptr;
+  key.count = 0;
+  h = (struct hash_string *) hash_find_item (&strings, &key);
+  if (h == NULL)
+{
+  char *result = (char *) malloc (strlen (ptr) + 1);
+
+  if (result == NULL)
+   fatal (NILF, _("virtual memory exhausted"));
+
+  strcpy (result, ptr);
+
+  h = (struct hash_string *) malloc (sizeof (struct hash_string));
+  if (h == NULL)
+   fatal (NILF, _("virtual memory exhausted"));
+
+  h->string = result;
+  h->count = 1;
+  hash_insert (&strings, h);
+}
+  else
+{
+  h->count++;
+  assert (h->count != 0);
+}
+  
+  return h->string;
+}
+
+char *
+hash_savestring (str, length)
+ const char *str;
+ unsigned int length;
+{
+  struct hash_string *h, key;
+  
+  if (length == 0 || *str == '\0')
+

Spec reading causes ppc64 crash

[Daniel Berlin]

So it looks like the addition of reading ldblspecs causes crashes
because it's reading from unallocated memory.

(i found this because bootstrap on dataflow branch fails on ppc64 with
this crash).

I can't trigger it with -save-temps, sadly.

According to valgrind on ppc (3.1.0 from developer.valgrind.org):

valgrind /home/dberlin/gcc/build/./gcc/xgcc
-B/home/dberlin/gcc/build/./gcc/ -B/usr/local/powerpc-suse-linux/bin/
-B/usr/local/powerpc-suse-linux/lib/ -isystem
/usr/local/powerpc-suse-linux/include -isystem
/usr/local/powerpc-suse-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -specs=ldblspecs -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber -DSHARED -fPIC -mstrict-align -DL_divdi3 -fexceptions
-fnon-call-exceptions -c ../../gcc/libgcc2.c -o libgcc/./_divdi3_s.o

gives

==10712== Memcheck, a memory error detector.
==10712== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==10712== Using LibVEX rev 1471, a library for dynamic binary translation.
==10712== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==10712== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==10712== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==10712== For more details, rerun with: -v
==10712==
Reading specs from /home/dberlin/gcc/build/./gcc/specs
Reading specs from /home/dberlin/gcc/build/./gcc/ldblspecs
==10712== Invalid read of size 1
==10712==at 0x100141D4: used_arg (gcc.c:7070)
==10712==by 0x10014B0C: set_multilib_dir (gcc.c:7315)
==10712==by 0x10011C38: main (gcc.c:6348)
==10712==  Address 0x44D25D4 is 0 bytes after a block of size 12 alloc'd
==10712==at 0xFFBA77C: malloc (vg_replace_malloc.c:149)
==10712==by 0x1001FE90: xmalloc (xmalloc.c:147)
==10712==by 0x10020024: xstrdup (xstrdup.c:34)
==10712==by 0x10002E30: set_spec (gcc.c:1843)
==10712==by 0x10003DC0: read_specs (gcc.c:2223)
==10712==by 0x10011BBC: main (gcc.c:6333)
Target: powerpc-suse-linux
Configured with: ../configure --enable-languages=c,c++,f95
powerpc-suse-linux
Thread model: posix
gcc version 4.2.0 20060201 (experimental)
 /home/dberlin/gcc/build/./gcc/cc1 -quiet -v -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber -I../libdecnumber -iprefix
/home/dberlin/gcc/build/gcc/../lib/gcc/powerpc-suse-linux/4.2.0/
-isystem /home/dberlin/gcc/build/./gcc/include -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux
-Asystem=linux -Asystem=unix -Asystem=posix -DIN_GCC -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DSHARED -DL_divdi3 -isystem
/usr/local/powerpc-suse-linux/include -isystem
/usr/local/powerpc-suse-linux/sys-include -isystem ./include
../../gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mstrict-align
-auxbase-strip libgcc/./_divdi3_s.o -g -g -O2 -O2 -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -version -fPIC -fPIC -fexceptions
-fnon-call-exceptions -mlong-double-128 -o /tmp/cc96agbK.s
ignoring nonexistent directory "/usr/local/powerpc-suse-linux/include"
ignoring nonexistent directory "/usr/local/powerpc-suse-linux/sys-include"
ignoring duplicate directory "./include"
ignoring nonexistent directory
"/home/dberlin/gcc/build/gcc/../lib/gcc/powerpc-suse-linux/4.2.0/include"
ignoring nonexistent directory
"/home/dberlin/gcc/build/gcc/../lib/gcc/powerpc-suse-linux/4.2.0/../../../../powerpc-suse-linux/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc-suse-linux/4.2.0/include"
ignoring nonexistent directory
"/usr/local/lib/../powerpc-suse-linux/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../gcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../gcc
 ../../gcc/../include
 ../../gcc/../libcpp/include
 ../../gcc/../libdecnumber
 ../libdecnumber
 /home/dberlin/gcc/build/./gcc/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 4.2.0 20060201 (experimental) (powerpc-suse-linux)
compiled by GNU C version 4.0.2 20050901 (prerelease) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 536fdbb2127ba0d2ba62501205c6db21
 /home/dberlin/gcc/build/./gcc/as -mppc -many -V -Qy -K PIC -o
libgcc/./_divdi3_s.o /tmp/cc96agbK.s
GNU assembler version 2.16.91.0.2 (powerpc-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)
==10712==
==10712== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 6 from 2)
==10712== malloc/free: in 

Re: x86 Darwin an libgcc-math

[Richard Guenther]

On 2/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > Is it intentional that these functions have global visibility and
> > interfere with functions declared and implemented by the system
> > libraries? If not, can they be compilied with hidden visibility?
>
> Yes (I originally tried to "see what happens if we use the glibc
> routines", then I shared the code with Richard who did the configury and
> the back-end patches.  glibc people do not try to make life easy for
> people that use their code outside glibc, but I forgot to tell him about
> this...).

Ok, so Darwin does not support symbol versioning?  As then all these
conflicting symbols should be local.  Originally Paolo added #pragma
visibility stuff which I removed during getting rid of all the C wrapper files.
I wonder if we can do some clever stuff with just using default hidden for
all files and appending an visibility attribute to the name defines.  I can
work on this, but I didn't see any difference in exported symbols if using
it or not (probably due to the used linker script).

Richard.

[HELP take two] GCC 4.1 branch Ada status on powerpc-darwin?

[Laurent GUERBY]

I've not seen any Ada enabled results on powerpc-darwin posted on
gcc-testresults after the patches came in.

Could someone with powerpc-darwin access check wether Ada is now working
or not, if not populate bugzilla?

Thanks in advance,

Laurent

Re: Generalize ready list sorting via heuristics in rank_for_schedule.

[Maxim Kuvyrkov]

Peter Steinmetz wrote:

Currently, within the ready_sort macro in haifa-sched.c, the call to qsort
is passed "rank_for_schedule" to help it decide which of two instructions
should be placed further towards the front of the ready list.
Rank_for_schedule uses a set of ordered heuristics (rank, priority, etc.)
to make this decision.  The set of heuristics is fixed for all target
machines.
There already are two target hooks specifically for this purpose: 
targetm.sched.{reorder, reorder2}. They both have higher priority, than 
ready_sort ().



There can be cases, however, where a target machine may want to define
heuristics driven by specific characteristics of that machine.  Those
heuristics may be meaningless on other targets.
In rank_for_schedule () only machine independent heuristics are 
gathered; the rest of the haifa scheduler is no less machine dependent, 
than these heuristics are. Machine dependent things are separated in 
reorder hooks (which, btw, are defined on 3 targets only).


--
Maxim

Re: [HELP take two] GCC 4.1 branch Ada status on powerpc-darwin?

[Eric Botcazou]

> Could someone with powerpc-darwin access check wether Ada is now working
> or not, if not populate bugzilla?

The compiler bootstraps fine but all ACATS tests fail to link.  You need to 
manually pass -static-libgcc at link time.

-- 
Eric Botcazou

Re: x86 Darwin an libgcc-math

[Richard Guenther]

On 2/1/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 2/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> >
> > > Is it intentional that these functions have global visibility and
> > > interfere with functions declared and implemented by the system
> > > libraries? If not, can they be compilied with hidden visibility?
> >
> > Yes (I originally tried to "see what happens if we use the glibc
> > routines", then I shared the code with Richard who did the configury and
> > the back-end patches.  glibc people do not try to make life easy for
> > people that use their code outside glibc, but I forgot to tell him about
> > this...).
>
> Ok, so Darwin does not support symbol versioning?  As then all these
> conflicting symbols should be local.  Originally Paolo added #pragma
> visibility stuff which I removed during getting rid of all the C wrapper 
> files.
> I wonder if we can do some clever stuff with just using default hidden for
> all files and appending an visibility attribute to the name defines.  I can
> work on this, but I didn't see any difference in exported symbols if using
> it or not (probably due to the used linker script).

Can you try the attached patch (it's not perfect as it misses to export some
of the symbols due to the simple #define hack not working for them) and
see if in principle it would solve the issue on Darwin?

Thanks,
Richard.


p8-6
Description: Binary data

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Laurent GUERBY]

On Tue, 2006-01-24 at 10:29 +0100, Arnaud Charlet wrote:
> Otherwise, we could modify systematically the binder/linker to always
> call gcc with either -static-libgcc or -shared-libgcc when linking, depending
> on whether shared libs are used. Or we could make this capability optional
> and enabled with a flag in link.c named e.g. "__gnat_force_libgcc_switch"

You mean value of zero or one, zero everywhere but if on darwin (what's
the define for this target?), imported in gnatlink.adb, if one then if
GNAT_Static add -static-libgcc elsif GNAT_Shared add -shared-libgcc?

Looks a bit tricky since I don't know the code, but doable.

Laurent

Re: x86 Darwin an libgcc-math

[Shantonu Sen]

Awesome.

With trunk, your 3 previous patches, my config/darwin.h patch for the  
link line, and your further patch for visibility:


[EMAIL PROTECTED] /opt/gccmath/bin/gcc -o test test.c -msselibm
[EMAIL PROTECTED] otool -Lv test
test:
/opt/gccmath/lib/libgcc-math.0.dylib (compatibility version  
1.0.0, current version 1.0.0)

time stamp 1138831883 Wed Feb  1 14:11:23 2006
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.5)

time stamp 1137810491 Fri Jan 20 18:28:11 2006
[EMAIL PROTECTED] ./test
0.999816

Also, using nm I see that only the intentional support API is global.

[EMAIL PROTECTED] nm -g -f /opt/gccmath/lib/libgcc-math.0.dylib | grep -v  
" U "

33a0 T ___libm_sse2_acos
3080 T ___libm_sse2_acosf
4460 T ___libm_sse2_asin
5580 T ___libm_sse2_asinf
000139a0 T ___libm_sse2_atan
5a40 T ___libm_sse2_atan2
a6c0 T ___libm_sse2_atan2f
00017660 T ___libm_sse2_cos
00015f80 T ___libm_sse2_cosf
add0 T ___libm_sse2_exp
b250 T ___libm_sse2_expf
ce90 T ___libm_sse2_log10
cfc0 T ___libm_sse2_log10f
e4b0 T ___libm_sse2_powf
00018a30 T ___libm_sse2_sin
0001acb0 T ___libm_sse2_sinf
0001adf0 T ___libm_sse2_tan
00021270 T ___libm_sse2_tanf
[EMAIL PROTECTED]

Thank you very much! Bootstrapped on i386-apple-darwin8.4.1

Shantonu

On Feb 1, 2006, at 1:10 PM, Richard Guenther wrote:



Can you try the attached patch (it's not perfect as it misses to  
export some
of the symbols due to the simple #define hack not working for them)  
and

see if in principle it would solve the issue on Darwin?

Thanks,
Richard.

Re: x86 Darwin an libgcc-math

[Richard Guenther]

On 2/2/06, Shantonu Sen <[EMAIL PROTECTED]> wrote:
> Awesome.
>
> With trunk, your 3 previous patches, my config/darwin.h patch for the
> link line, and your further patch for visibility:
>
> [EMAIL PROTECTED] /opt/gccmath/bin/gcc -o test test.c -msselibm
> [EMAIL PROTECTED] otool -Lv test
> test:
>  /opt/gccmath/lib/libgcc-math.0.dylib (compatibility version
> 1.0.0, current version 1.0.0)
>  time stamp 1138831883 Wed Feb  1 14:11:23 2006
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 88.1.5)
>  time stamp 1137810491 Fri Jan 20 18:28:11 2006
> [EMAIL PROTECTED] ./test
> 0.999816
>
> Also, using nm I see that only the intentional support API is global.
>
> [EMAIL PROTECTED] nm -g -f /opt/gccmath/lib/libgcc-math.0.dylib | grep -v
> " U "
> 33a0 T ___libm_sse2_acos
> 3080 T ___libm_sse2_acosf
> 4460 T ___libm_sse2_asin
> 5580 T ___libm_sse2_asinf
> 000139a0 T ___libm_sse2_atan
> 5a40 T ___libm_sse2_atan2
> a6c0 T ___libm_sse2_atan2f
> 00017660 T ___libm_sse2_cos
> 00015f80 T ___libm_sse2_cosf
> add0 T ___libm_sse2_exp
> b250 T ___libm_sse2_expf
> ce90 T ___libm_sse2_log10
> cfc0 T ___libm_sse2_log10f
> e4b0 T ___libm_sse2_powf
> 00018a30 T ___libm_sse2_sin
> 0001acb0 T ___libm_sse2_sinf
> 0001adf0 T ___libm_sse2_tan
> 00021270 T ___libm_sse2_tanf
> [EMAIL PROTECTED]
>
> Thank you very much! Bootstrapped on i386-apple-darwin8.4.1

Thanks for testing!  I'll come up with a patch that includes the
missing symbols (for atanf, logf, log and pow) tomorrow.

Richard.

Re: Bad indentation and strange code in fortran/trans-array.c

[Paul Thomas]

H. J

This regtests OK and simplifies things somewhat:

Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 110407)
--- gcc/fortran/trans-array.c (working copy)
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 3911,3917 
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;
! if (expr->ts.type == BT_CHARACTER)
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
--- 3911,3919 
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;
!
! if (expr->ts.type == BT_CHARACTER
! && expr->ts.cl->backend_decl == NULL_TREE)
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
*** gfc_conv_expr_descriptor (gfc_se * se, g
*** 3920,3935 
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}
! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);

/* ... which can hold our string, if present. */
! if (expr->ts.type == BT_CHARACTER)
! {
! loop.temp_ss->string_length = TYPE_SIZE_UNIT (loop.temp_ss->data.temp. 
type);

! se->string_length = loop.temp_ss->string_length;
! }
! else
! loop.temp_ss->string_length = NULL;
loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}
--- 3922,3933 
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}
!
! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);

/* ... which can hold our string, if present. */
! se->string_length = loop.temp_ss->string_length;
!
loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}

giving:

if (need_tmp)
{
/* Tell the scalarizer to make a temporary. */
loop.temp_ss = gfc_get_ss ();
loop.temp_ss->type = GFC_SS_TEMP;
loop.temp_ss->next = gfc_ss_terminator;

if (expr->ts.type == BT_CHARACTER
&& expr->ts.cl->backend_decl == NULL_TREE) /* GET THE CHARLEN */
{
gcc_assert (expr->ts.cl && expr->ts.cl->length
&& expr->ts.cl->length->expr_type == EXPR_CONSTANT);
loop.temp_ss->string_length = gfc_conv_mpz_to_tree
(expr->ts.cl->length->value.integer,
expr->ts.cl->length->ts.kind);
expr->ts.cl->backend_decl = loop.temp_ss->string_length;
}

loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts); /* 
PASS IT TO TEMP */


/* ... which can hold our string, if present. */
se->string_length = loop.temp_ss->string_length; /* THEN WE MUST WRITE 
TO SE */


loop.temp_ss->data.temp.dimen = loop.dimen;
gfc_add_ss_to_loop (&loop, loop.temp_ss);
}

Paul T

Re: Bad indentation and strange code in fortran/trans-array.c

[H. J. Lu]

On Thu, Feb 02, 2006 at 12:39:41AM +0100, Paul Thomas wrote:
> H. J
> 
> This regtests OK and simplifies things somewhat:
> 

What is this format? I don't think I can apply it cleanly?


H.J.
---
> Index: gcc/fortran/trans-array.c
> ===
> *** gcc/fortran/trans-array.c (revision 110407)
> --- gcc/fortran/trans-array.c (working copy)
> *** gfc_conv_expr_descriptor (gfc_se * se, g
> *** 3911,3917 
> loop.temp_ss = gfc_get_ss ();
> loop.temp_ss->type = GFC_SS_TEMP;
> loop.temp_ss->next = gfc_ss_terminator;
> ! if (expr->ts.type == BT_CHARACTER)
> {
> gcc_assert (expr->ts.cl && expr->ts.cl->length
> && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
> --- 3911,3919 
> loop.temp_ss = gfc_get_ss ();
> loop.temp_ss->type = GFC_SS_TEMP;
> loop.temp_ss->next = gfc_ss_terminator;
> !
> ! if (expr->ts.type == BT_CHARACTER
> ! && expr->ts.cl->backend_decl == NULL_TREE)
> {
> gcc_assert (expr->ts.cl && expr->ts.cl->length
> && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
> *** gfc_conv_expr_descriptor (gfc_se * se, g
> *** 3920,3935 
> expr->ts.cl->length->ts.kind);
> expr->ts.cl->backend_decl = loop.temp_ss->string_length;
> }
> ! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);
> 
> /* ... which can hold our string, if present. */
> ! if (expr->ts.type == BT_CHARACTER)
> ! {
> ! loop.temp_ss->string_length = TYPE_SIZE_UNIT (loop.temp_ss->data.temp. 
> type);
> ! se->string_length = loop.temp_ss->string_length;
> ! }
> ! else
> ! loop.temp_ss->string_length = NULL;
> loop.temp_ss->data.temp.dimen = loop.dimen;
> gfc_add_ss_to_loop (&loop, loop.temp_ss);
> }
> --- 3922,3933 
> expr->ts.cl->length->ts.kind);
> expr->ts.cl->backend_decl = loop.temp_ss->string_length;
> }
> !
> ! loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);
> 
> /* ... which can hold our string, if present. */
> ! se->string_length = loop.temp_ss->string_length;
> !
> loop.temp_ss->data.temp.dimen = loop.dimen;
> gfc_add_ss_to_loop (&loop, loop.temp_ss);
> }
> 
> giving:
> 
> if (need_tmp)
> {
> /* Tell the scalarizer to make a temporary. */
> loop.temp_ss = gfc_get_ss ();
> loop.temp_ss->type = GFC_SS_TEMP;
> loop.temp_ss->next = gfc_ss_terminator;
> 
> if (expr->ts.type == BT_CHARACTER
> && expr->ts.cl->backend_decl == NULL_TREE) /* GET THE CHARLEN */
> {
> gcc_assert (expr->ts.cl && expr->ts.cl->length
> && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
> loop.temp_ss->string_length = gfc_conv_mpz_to_tree
> (expr->ts.cl->length->value.integer,
> expr->ts.cl->length->ts.kind);
> expr->ts.cl->backend_decl = loop.temp_ss->string_length;
> }
> 
> loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts); /* 
> PASS IT TO TEMP */
> 
> /* ... which can hold our string, if present. */
> se->string_length = loop.temp_ss->string_length; /* THEN WE MUST WRITE 
> TO SE */
> 
> loop.temp_ss->data.temp.dimen = loop.dimen;
> gfc_add_ss_to_loop (&loop, loop.temp_ss);
> }
> 
> Paul T
> 

Re: Thoughts on LLVM and LTO

[Ben Elliston]

Sorry for the long delay in this thread .. still catching up from the
break.

> > 2) Testability of optimization passes
> > 
> > How much precision one can get while testing particular feature,
> > optimization pass?
> 
> You can run one pass at a time, if you wanted to, using opt (or two,
> or three).

I have patches to GCC to do this if anyone thinks they'd be useful?

Ben

Re: Bad indentation and strange code in fortran/trans-array.c

[Paul Thomas]

H. J. Lu wrote:


On Thu, Feb 02, 2006 at 12:39:41AM +0100, Paul Thomas wrote:
 


H. J

This regtests OK and simplifies things somewhat:

   



What is this format? I don't think I can apply it cleanly?

 

I am not surprised - I tried to cut and paste from a large patch that I 
am working on.


I'll resend tonight.

Paul

Inconsistency in runtime target tool search

[Shantonu Sen]

When I build a cross compiler, say from x86_64-unknown-linux-gnu to  
i386-apple-darwin8.4.1, and have a directory in my PATH with "i386- 
apple-darwin8.4.1-as" and "i386-apple-darwin8.4.1-ld", it appears  
that the target-prefixed "ld" is found by collect2, but not the  
target-prefixed "as" by the driver.



[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-as
i386-apple-darwin8.4.1-as is /opt/odcctools/bin/i386-apple- 
darwin8.4.1-as

[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-ld
i386-apple-darwin8.4.1-ld is /opt/odcctools/bin/i386-apple- 
darwin8.4.1-ld

[EMAIL PROTECTED]:/tmp$

[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -v -c test.c
Using built-in specs.
Target: i386-apple-darwin8.4.1
Configured with: ../gcc/configure --prefix=/opt/gcc-darwin -- 
target=i386-apple-darwin8.4.1 --with-sysroot=/MacOSX10.4u.sdk -- 
disable-libgomp --disable-libssp --disable-libgcc-math

Thread model: posix
gcc version 4.2.0 20060202 (experimental)
...
 as -arch i386 -force_cpusubtype_ALL -o test.o /tmp/ccqadIjw.s
Assembler messages:
Fatal error: invalid listing option `r'
[EMAIL PROTECTED]:/tmp$


My expectation here was that since this is a cross-compiler built  
with --target=i386-apple-darwin8.4.1, the driver would look for the  
assembler as "i386-apple-darwin8.4.1-as" if it wasn't found in any of  
the normal tool directories in $prefix/libexec/gcc or $prefix/ 
$target, etc. This does not seem to be the case, and a Linux ELF  
assembler doesn't do me a lot of good. Note that I did not use --with- 
ld/--with-as explicitly during configuration, so I expect directories  
and paths to be searched at runtime.


However, what I find confusing is that collect2 implements the  
algorithm as I expected it to:



[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -S test.c
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-as -arch i386 - 
force_cpusubtype_ALL -o test.o test.s

[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -o test test.o -Wl,-v
collect2 version 4.2.0 20060202 (experimental) (i686 Darwin)
/opt/odcctools/bin/i386-apple-darwin8.4.1-ld -dynamic -arch i386 - 
weak_reference_mismatches non-weak -o test -lcrt1.o -L/opt/gcc- 
darwin/lib/gcc/i386-apple-darwin8.4.1/4.2.0 -L/opt/gcc-darwin/lib/ 
gcc/i386-apple-darwin8.4.1/4.2.0/../../../../i386-apple-darwin8.4.1/ 
lib -L/MacOSX10.4u.sdk/usr/lib test.o -v -lgcc -lSystem

Apple Computer, Inc. version odcctools-590.18od10
[EMAIL PROTECTED]:/tmp$


This seems to be because collect2.c has:
#ifdef CROSS_COMPILE
  /* If we look for a program in the compiler directories, we just use
 the short name, since these directories are already system- 
specific.

 But it we look for a program in the system directories, we need to
 qualify the program name with the target machine.  */

  const char *const full_ld_suffix =
concat(target_machine, "-", ld_suffix, NULL);


Now, my question is, why does collect2 implement its target tool  
search by prefixing the target name, but the driver itself doesn't  
when invoking the assembler? Should I file a bug to align all the  
code that searches for target tools?


As an aside, the cross compiler successfully builds and links target  
libraries because it uses:

[EMAIL PROTECTED]:~/gcc-build$ cat gcc/as
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-as "$@"
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/collect-ld
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-ld "$@"
[EMAIL PROTECTED]:~/gcc-build$


I guess I'm asking for the driver to have parity with gcc's build  
system, which prepends the target name for these tools


Shantonu