Re: valid_gimple_expression_p claims validity of invalid gimple

[Eric Botcazou]

> First is_gimple_min_invariant in try_to_simplify where it chooses
> DECL_INITIAL should be valid_gimple_expression_p instead.

That's a known problem, see tree-ssa-ccp.c:

/* The regular is_gimple_min_invariant does a shallow test of the object.
   It assumes that full gimplification has happened, or will happen on the
   object.  For a value coming from DECL_INITIAL, this is not true, so we
   have to be more strict ourselves.  */

static bool
ccp_decl_initial_min_invariant (tree t)
{
  if (!is_gimple_min_invariant (t))
return false;
  if (TREE_CODE (t) == ADDR_EXPR)
{
  /* Inline and unroll is_gimple_addressable.  */
  while (1)
{
  t = TREE_OPERAND (t, 0);
  if (is_gimple_id (t))
return true;
  if (!handled_component_p (t))
return false;
}
}
  return true;
}

static tree
get_symbol_constant_value (tree sym)
{
  if (TREE_STATIC (sym)
  && TREE_READONLY (sym)
  && !MTAG_P (sym))
{
  tree val = DECL_INITIAL (sym);
  if (val
  && ccp_decl_initial_min_invariant (val))
return val;
}

  return NULL_TREE;
}

You could turn ccp_decl_initial_min_invariant into a global predicate and 
invoke it from tree-ssa-sccvn.c on the DECL_INITIAL.

> However, even if i fix this, the testcase still fails because
> valid_gimple_expression says something that is clearly invalid is
> valid.
>
> (gdb) p valid_gimple_expression_p ($2)
> $3 = 1 '\001'
> (gdb) p debug_generic_stmt ($2)
> &((struct RegisterLayout *) (char *) &SimulatedRegisters)->intmask;
>
> This is not valid gimple by a longshot :)

Almost. :-)  The function was extracted unchanged from set_rhs but it looks 
like it needs to be beefed up a bit if it is to become of general use.

> If you fix this part, i'll happily fix the bug report with the first part.

The problem is again the ADDR_EXPR case, because it drags lvalues into the 
game.  This would be something like:

Index: tree-ssa-propagate.c
===
--- tree-ssa-propagate.c(revision 126545)
+++ tree-ssa-propagate.c(working copy)
@@ -606,10 +606,21 @@ valid_gimple_expression_p (tree expr)
   switch (code)
{
case ADDR_EXPR:
-  if (TREE_CODE (TREE_OPERAND (expr, 0)) == ARRAY_REF
- && !is_gimple_val (TREE_OPERAND (TREE_OPERAND (expr, 0), 1)))
-   return false;
- break;
+ {
+   tree t = TREE_OPERAND (expr, 0);
+   while (handled_component_p (t))
+ {
+   /* ??? More checks needed, see the GIMPLE verifier.  */
+   if ((TREE_CODE (t) == ARRAY_REF
+|| TREE_CODE (t) == ARRAY_RANGE_REF)
+   && !is_gimple_val (TREE_OPERAND (t, 1)))
+ return false;
+   t = TREE_OPERAND (t, 0);
+ }
+   if (!is_gimple_addressable (t))
+ return false;
+   break;
+ }
 
case TRUTH_NOT_EXPR:
  if (!is_gimple_val (TREE_OPERAND (expr, 0)))

-- 
Eric Botcazou

make clean-target fails at x86_64-unknown-linux-gnu/32/libjava

[Manuel López-Ibáñez]

make clean-target fails at x86_64-unknown-linux-gnu/32/libjava when
doing target 'mostlyclean-local' because it tries to execute:

find . -name '*.lo' -print | xargs /bin/sh ./libtool rm -f

and we get:

libtool: error: you must specify a MODE.

when it should execute:

find . -name '*.lo' -print | xargs /bin/sh ./libtool --mode=clean rm -f

I don't have any idea of autotools but it would be nice to provide a
fix. How can I fix this?

Cheers,

Manuel.

Re: Host/Target confusion in Dwarf output

[Richard Kenner]

> This means that the largest int on the host must be at least half the 
> size of the largest int on the target.  Hence, building 64-bit target 
> compilers on 32-bit host systems has never been a problem.  

I'm not sure I'd go as far as saying "has never been a problem".  It's
"mostly worked", but did have optimization losses and various minor
issues from time to time.  There was enough of a problem that (before
the days when we switched to HOST_WIDE_INT being "long long") I wanted
to be sure that I used a 64-bit host since I needed to build 64-bit
targets.

Re: RFH: GPLv3

[Richard Kenner]

> One could of course just take a blanket view that everything on the
> site is, as of a certain moment, licensed under GPLv3 (note you
> don't have to change file headers to achieve this, the file headers
> have no particular legal significance in any case).

Given the July 31 "deadline", that's essentially what's being done: any
file with a date before August 1, 2007 is GPLv2 and any after is GPLv3.
This is one of the reasons why I don't see the version number change as
so significant.

Re: RFH: GPLv3

[Krzysztof Halasa]

Rob Brown <[EMAIL PROTECTED]> writes:

> So, could there be a simultaneous release of gcc under GPLv2 and GPLv3,
> identical in all respects except for the license?

How could that be useful? That v2(+) version would already be v3
if the user wanted so (due to the "or later" clause).

Use any licence you want but don't mess with version numbers
or the branches (including closing) for purely political,
not technical reasons.
-- 
Krzysztof Halasa

Can realloc be marked as a mallloc-like function?

[H.J. Lu]

This patch

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html

causes the regression:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748

The only relevant change is

Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 126214)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -2276,6 +2276,7 @@ gfc_build_builtin_function_decls (void)
 (PREFIX("internal_realloc")),
 pvoid_type_node, 2, pvoid_type_node,
 gfc_index_int_type_node);
+  DECL_IS_MALLOC (gfor_fndecl_internal_realloc) = 1;
 
   gfor_fndecl_allocate =
 gfc_build_library_function_decl (get_identifier (PREFIX("allocate")),

In calls.c, there are comments:

  /* The return value from a malloc-like function can not alias
 anything else.  */

It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are

1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.

BTW, glibc also marks realloc with __attribute_malloc__.


H.J.

Re: Can realloc be marked as a mallloc-like function?

[Tobias Schlüter]

H.J. Lu wrote:

It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are

1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.

BTW, glibc also marks realloc with __attribute_malloc__.


There was an absurdely long thread on this topic starting at 
.  I didn't dig through 
it to find the answer.


HTH,
- Tobi

FAIL: gcc.dg/pragma-darwin.c

[Dominique Dhumieres]

The test FAIL: gcc.dg/pragma-darwin.c fails with

FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 17)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 18)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 19)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 67)
FAIL: gcc.dg/pragma-darwin.c  (test for errors, line 68)
FAIL: gcc.dg/pragma-darwin.c (test for excess errors)

(see http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00621.html)

Apparently gcc 4.3 emits only warnings while the test expects errors:

...
#pragma options 23  /* { dg-error "malformed '#pragma options'" } */
#pragma options align  /* { dg-error "malformed '#pragma options'" } */
#pragma options align natural /* { dg-error "malformed '#pragma options'" } */
#pragma options align=45 /* { dg-error "malformed '#pragma options'" } */
#pragma options align=foo /* { dg-error "malformed '#pragma options align" } */
...
#pragma unused  /* { dg-error "missing '.' after '#pragma unused" } */
#pragma unused (a  /* { dg-error "missing '.' after '#pragma unused" } */
...

TIA

Dominique

Re: Can realloc be marked as a mallloc-like function?

[H.J. Lu]

On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:
> H.J. Lu wrote:
> >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> >return an address which can alias something else. But it isn't true
> >for realloc. Now, the qestions are
> >
> >1. Can gcc make such an assumption?
> >2. Can realloc be marked as DECL_IS_MALLOC.
> >
> >BTW, glibc also marks realloc with __attribute_malloc__.
> 
> There was an absurdely long thread on this topic starting at 
> .  I didn't dig through 
> it to find the answer.

Now, we have a real testcase to show the problem. How do we solve
it?


H.J.

Re: RFH: GPLv3

[Michael Eager]

Richard Kenner wrote:

One could of course just take a blanket view that everything on the
site is, as of a certain moment, licensed under GPLv3 (note you
don't have to change file headers to achieve this, the file headers
have no particular legal significance in any case).


Given the July 31 "deadline", that's essentially what's being done: any
file with a date before August 1, 2007 is GPLv2 and any after is GPLv3.
This is one of the reasons why I don't see the version number change as
so significant.


This would be a desirable situation.

Unfortunately, as I understand it, this is not the case.  If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.  (This is unless FSF agrees with Mark's proposal
to dual license patches.)

As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

[Robert Dewar]

Michael Eager wrote:


Unfortunately, as I understand it, this is not the case.  If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.  (This is unless FSF agrees with Mark's proposal
to dual license patches.)

As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.


That's why I suggested a simple rule that ALL software on the site is
GPLv3 after a certain date, so you don't have to know the version number
or anything else, just the date on which you access the site, and if you
are GPLv3 allergic, then the simple rule is not to take ANYTHING off
the site after that date. This is really much the easiest rule.

Re: RFH: GPLv3

[Michael Eager]

Robert Dewar wrote:

Michael Eager wrote:


Unfortunately, as I understand it, this is not the case.  If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.  (This is unless FSF agrees with Mark's proposal
to dual license patches.)

As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.


That's why I suggested a simple rule that ALL software on the site is
GPLv3 after a certain date, so you don't have to know the version number
or anything else, just the date on which you access the site, and if you
are GPLv3 allergic, then the simple rule is not to take ANYTHING off
the site after that date. This is really much the easiest rule.


I understood your suggestion.

This amounts to telling companies that they cannot upgrade their tool
chains to newer versions, or even pick up patches to old versions, until
they (and/or their legal departments) approve GPLv3.

This seems unnecessary.  If you are trying to make GPLv3 more
easily adopted by companies, then this is not the way to do it.

On the other hand, perhaps I should simply agree with you.
I'll get more business supporting private tool chain development.

I have contracts with corporations to upgrade their software.
I regularly encourage them to contribute to the open source
repositories and sometimes they agree, although it usually
takes a while to convince them (management and legal departments)
that there is a benefit to this and no risk to their IP rights.

Converting previously released software to a license which they
have not yet evaluated will close these conversations.  Rather
than move to later versions of the tools and being more involved
with the open source community, they will stay with their existing
privately supported tool chains.  I'll get more work to fix problems
which are already fixed in later releases, but which are off limits
until the legal department gives it's OK.  Once a corporation decides
that their current version of gcc is "good enough" and decides that
they will not upgrade, there will be little reason for management to
press their legal department to evaluate or approve GPLv3.

My experience is that for every company which is actively
using and developing gcc and contributes to the open source
community, I talk with many other companies who do gcc development
and follow the GPLv2 completely, but do not submit their patches
to the open source repository.  There are a number of reasons
for this, including inertia, caution, secretiveness, etc.  I'd
rather not give them another reason.

The result is that there are many private forks of gcc and other
development tools.

You may think that "do it my way or else" is a winning negotiating
tactic, but most of the companies I work with are quite happy to
do things on their own.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Efficiently encoding a hierarchy

[Kannan Goundan]

(I don't follow this list regularly, but ran into the GIMPLE tuples
proposal and had a suggestion.  Apologies if you were already aware of
this technique.)

The proposed tuple structure has the fields "code" and "subcode".  My
reading of its intent is to allow a simple two-level hierarchy of types.
Another way to encode a hierarchy is to use only a single "code" field
and associate each type with a range of IDs.  For example:

- A (0,5)
  - B (1,1)
  - C (2,4)
- D (3,3) 
- E (4,4)
  - F (5,5)
- G (6,7)
  - H (7,7)

A given instance is of type "C" if its "code" field is between 2 and 4,
inclusive.

Advantages of this approach:
- the type hierarchy can be as deep as you like
- checking the exact type is a single comparison
- the subtype check is only two comparisons.
- the ID range is used efficiently (one ID per type)

However, if your hierarchy is really only two levels deep, then the
code/subcode approach has some advantages:
- the subtype check is a single comparison
- you can do a C "switch" on non-leaf types as well

- Kannan

Re: RFH: GPLv3

[Krzysztof Halasa]

Michael Eager <[EMAIL PROTECTED]> writes:

> Unfortunately, as I understand it, this is not the case.  If you
> apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
> this entire branch, and all files in it, magically and silently
> becomes GPLv3.  (This is unless FSF agrees with Mark's proposal
> to dual license patches.)

I hope the COPYING or similar file will contain the licence text
under which the code is distributed?
-- 
Krzysztof Halasa

Re: RFH: GPLv3

[Michael Eager]

Krzysztof Halasa wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


Unfortunately, as I understand it, this is not the case.  If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.  (This is unless FSF agrees with Mark's proposal
to dual license patches.)


I hope the COPYING or similar file will contain the licence text
under which the code is distributed?


Not until someone updates the txt.  Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

[Krzysztof Halasa]

Michael Eager <[EMAIL PROTECTED]> writes:

> Not until someone updates the txt.  Which should happen quickly,
> but if someone applies a GPLv3 patch to a previously GPLv2 branch,
> the entire branch becomes GPLv3, whether the COPYING file was
> updated or not.

Come on, if the FSF (the copyright holder) distributes a program,
and if the included licence says GPLv2+, then the licence is GPLv2+
and you'll have a really hard time trying to convince anyone that
it's different.

BTW: the copyright holder is free to take a GPLv3 patch and
release it under GPLv2 (and any other licence).
-- 
Krzysztof Halasa

Re: RFH: GPLv3

[Michael Eager]

Krzysztof Halasa wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


Not until someone updates the txt.  Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.


Come on, if the FSF (the copyright holder) distributes a program,
and if the included licence says GPLv2+, then the licence is GPLv2+
and you'll have a really hard time trying to convince anyone that
it's different.


You asked if COPYING would be updated.  The answer is not necessarily.
The COPYING text may say GPLv2+, but if there has been a GPLv3 patch
applied to the branch, then the entire branch is GPLv3.


BTW: the copyright holder is free to take a GPLv3 patch and
release it under GPLv2 (and any other licence).


FSF is the copyright holder.  As of this time, they have said
that they are not willing to release patches under GPLv2 for
application to GPLv2 branches.  Mark has a proposal which would
allow for that.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

[Rob Brown]

>Krzysztof Halasa wrote:
>> Michael Eager <[EMAIL PROTECTED]> writes:
>>
>>> Not until someone updates the txt.  Which should happen quickly,
>>> but if someone applies a GPLv3 patch to a previously GPLv2 branch,
>>> the entire branch becomes GPLv3, whether the COPYING file was
>>> updated or not.
>>
>> Come on, if the FSF (the copyright holder) distributes a program,
>> and if the included licence says GPLv2+, then the licence is GPLv2+
>> and you'll have a really hard time trying to convince anyone that
>> it's different.
>
>You asked if COPYING would be updated.  The answer is not necessarily.
>The COPYING text may say GPLv2+, but if there has been a GPLv3 patch
>applied to the branch, then the entire branch is GPLv3.

I struggle to believe this. Afaik a bunch of code is released under a
license, and nothing has the power to magically change that license. If
someone applies a GPLv3 patch to some GPLv2 code and releases the whole
under the GPLv2, then that person has broken copyright law and the release
is invalid (because the GPLv3 code has been released without a license),
but the rest of the GPLv2 code is still GPLv2. Or have I missed something
here? It sounds to me like the syntactic mischief Microsoft is playing when
it calls the GPL "viral" (note, I'm not suggesting that you are making
mischief, just that the implication is similar)!

>
>> BTW: the copyright holder is free to take a GPLv3 patch and
>> release it under GPLv2 (and any other licence).
>
>FSF is the copyright holder.  As of this time, they have said
>that they are not willing to release patches under GPLv2 for
>application to GPLv2 branches.  Mark has a proposal which would
>allow for that.
>

I think this misses a point: FSF is a copyright assignee, and I don't know
how that relates to "holding", but the person who wrote the patch is free
to dual-license without reference to the FSF. So as a completely fabricated
example: say in 6 months Richard Kenner makes a patch to (GPLv3) mainline
for a bug, and you want that patch to improve a GPLv2 product that you're
maintaining for one of your customers. You are free to ask Richard to
release that patch to you under GPLv2, and Richard is free to grant that
request.

Re: ICE building libgcc2.c for MIPS, too

[Sandra Loosemore]

Ian Lance Taylor wrote:

Sandra Loosemore <[EMAIL PROTECTED]> writes:


I'm now at revision 126547, and am getting a different ICE when
building the same configuration:



/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:
In member function 'std::string std::locale::name() const':
/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:143:
internal compiler error: Aborted


This is most likely unrelated.  If you would like to me to look at it,
please send me the .ii file.  Thanks.


This is still failing for me on mainline head, so I've spent some time trying to 
track this down.


Revision 126515 built cleanly for me.

Revision 126517 (the no_new_pseudos removal) plus this patch 
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01023.html

failed with the error above.

I poked at it in GDB

*** glibc detected *** double free or corruption (!prev): 0x08b2fe28 ***

Program received signal SIGABRT, Aborted.
0xe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xe410 in __kernel_vsyscall ()
#1  0x0047b7a5 in raise () from /lib/tls/libc.so.6
#2  0x0047d209 in abort () from /lib/tls/libc.so.6
#3  0x004af71a in __libc_message () from /lib/tls/libc.so.6
#4  0x004b5fbf in _int_free () from /lib/tls/libc.so.6
#5  0x004b633a in free () from /lib/tls/libc.so.6
#6  0x0875dc03 in rest_of_handle_combine ()
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
#7  0x08434ee2 in execute_one_pass (pass=0x89251a0)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/passes.c:1126
#8  0x0843507e in execute_pass_list (pass=0x89251a0)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/passes.c:1179
#9  0x08435091 in execute_pass_list (pass=0x89221c0)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/passes.c:1180
#10 0x08527728 in tree_rest_of_compilation (fndecl=0xf76d5a00)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/tree-optimize.c:406
#11 0x08187ba9 in expand_body (fn=0xf76d5a00)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/cp/semantics.c:3136
#12 0x086aff50 in cgraph_expand_function (node=0xf74111f8)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/cgraphunit.c:1073
#13 0x086b1b5e in cgraph_optimize ()
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/cgraphunit.c:1142
#14 0x0810bda4 in cp_write_global_declarations ()
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/cp/decl2.c:3310
#15 0x084c0ce1 in toplev_main (argc=0, argv=0x0)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/toplev.c:1064
#16 0x082238fe in main (argc=0, argv=0x0)
at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/main.c:35

Looks like a job for valgrind?  But I'm out of time for working on this, at 
least for now.  Can anyone else take a stab at it?


-Sandra

Re: RFH: GPLv3

[Rob Brown]

Robert Dewar wrote:
>One could of course just take a blanket view that everything
>on the site is, as of a certain moment, licensed under GPLv3
>(note you don't have to change file headers to achieve this,
>the file headers have no particular legal significance in
>any case).

According to http://www.gnu.org/licenses/gpl-howto.html, the file headers
are precisely the place to make the license grant.

>
>That at least would be clean, and anyone concerned with
>accepting GPLv3 stuff would simply know that as of this
>date and time, they should no longer download ANYTHING
>from the entire gnu.org site.
>
>That's actually not so terrible, you lose some users
>temporarily, but at least there is no misunderstanding.

There would be gross misunderstanding! Placing everything on gnu.org under
GPLv3 does nothing to affect all of its mirrors. So if I download
gcc-4.2.0.tar.bz2 from ftp.gnu.org then it's GPLv3, but if I download it
from any of the mirrors then it's GPLv2.

Surely the aim of the process should be to eliminate "gotchas" as much as
possible. Everyone has the responsibility to verify that they have a
license before using someone else's code. How could I, as the recipient of
a file which says "GPLv2" etc at the top, know that it was downloaded from
gnu.org and is actually really GPLv3?

Re: ICE building libgcc2.c for MIPS, too

[Adam Nemet]

Sandra Loosemore <[EMAIL PROTECTED]> writes:
> #6  0x0875dc03 in rest_of_handle_combine ()
> at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
>
> ...
>
> Looks like a job for valgrind?  But I'm out of time for working on
> this, at least for now.  Can anyone else take a stab at it?

I am seeing the same thing.  The issues is basically that after the
no_new_pseudoes change mips_split_symbol through mips_force_temporary
will create new pseudos during combine.  The regnumber of these regs
will address out of the reg_stat array in combine.

This is incorrect as in combine you are supposed to use the scratch
register that combine provides through a clobber clause which AFAIK is
always an existing pseudo.  I am planning to fix this by changing
mips_split_symbol to use the scratch register instead of a new pseudo
when invoked from a splitter.  I will try to get the patch tested
overnight.

Adam

Fw: Failing matrix tests

[Ayal Zaks]

> Is anyone else seeing failures on the gcc.dg/matrix tests?  I am getting
> the following failures on IA64 HP-UX:
>

Hope Razya can help spot the cause, after she returns from vacation later
this week.
Ayal.


> FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions
1
> FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions
1
> FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions
1
> FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions
1
> FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Flattened 3
dimensions 1
> FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Transposed 3
> FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times Flattened 3
dimensions 1
> FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Flattened 2
dimensions 1
> FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times Transposed 2
>
> On my HPPA platforms I also get:
>
> FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Flattened 3
dimensions 1
> FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Transposed 2
> FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times Flattened 3
dimensions 1
> FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times Flattened 3
dimensions 1
>
> The main difference between IA64 HP-UX and IA64 Linux (where I do not
> see these failures) is big-endian vs. little-endian so I was wondering
> if any other big-endian platforms in particular are seeing these
> failures?  When I look at the matrix-1.c.038i.matrix-reorg file output
> on HP-UX and Linux, the Linux one starts with some comments about
> putting symbols into SSA form and doing an incremental SSA update.  That
> is missing from the HP-UX version, HP-UX starts with:
>
>Matrix "vel"; Escaping Level: 1, Num Dims: 3, Malloc Dims: 1,
>mem_init ()
>{
>
> Linux (after the SSA comments) has:
>
>Matrix "vel"; Escaping Level: 3, Num Dims: 3, Malloc Dims: 3,
>Flattened 3 dimensions
>mem_init ()
>{
>
> Andrew, I cc'ed you because of this email
> , it mentions some
> matrix failures on MIPS when testing on the PTR-PLUS branch.  I don't
> actually know if my failures are related to PTR-PLUS or not.
>
> Steve Ellcey
> [EMAIL PROTECTED]

Re: RFH: GPLv3

[Brooks Moses]

Robert Dewar wrote:

One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).


I'm going to pull a Wikipedia and call "citation needed" on that 
parenthetical claim.


At the very least, the file headers are a clear representation as to 
what license the file is under, and IMO a reasonable person would expect 
to be able to rely on such a representation.


Thus, I think there's a reasonable argument to be made that distributing 
a GCC with some file headers saying "GPLv2 or later" and some saying 
"GPLv3 or later" is violating the license.  The FSF is allowed to 
violate their own license, since they hold the copyrights, but nobody 
else is -- thus, a corrolary to that argument is that an exact copy of 
such a GCC is not redistributable unless the redistributor fixes the 
file headers.  That would be bad.


And, regardless of whether one accepts that argument, if I were to pull 
a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an 
exact copy of it to my friend, I would have to remember to tell her that 
the file isn't licensed under what it says it's licensed under.  That's 
also not good.


Thus, I think it's reasonably critical that _all_ file headers be 
updated, quickly, to match the state of intended license for the files 
that include them.


- Brooks