Problem in porting GLIBC...

[vivek]

Hello

We are trying to port GLIBC 2.2.5 on the ABACUS (processor similar to
SPARC) platform. We have done much of the porting work.

At this stage we are trying to get the 'ld-2.2.5.so' working. We are
facing problems in this. We are trying to run this on again on our own
Linux kernel for ABACUS processor. The GOT & PLT generated through the GCC
for ld-2.2.5.so is causing the problems.

At this moment we are into the main of the user test case. We have jumped
on the User Entry through the LD.so

There must be some problem in the relocation and now we are unable to
trace the flow as we are not having the debugger and we use to have  print
statememts to debug the LD. Now it is not possible to use the print
statements also.

Could you please give us some hint about how to proceed further.

As I am not member of the group please give me mail on my personal ID,
[EMAIL PROTECTED]

Thanks & Warm Regards

VIVEK

Re: [RFC] fold Reorganization Plan

[Neil Booth]

Joe Buck wrote:-

> > I think it's desirable for front-ends to be able to fold floating
> > point constant expressions too, no?  It can be handy for diagnostics
> > such as detecting overflow or unreachable code based on conditionals
> > whose expression is a floating one, albeit constant.
> 
> The problem is that the user can independently set the IEEE rounding mode.
> This means that you can only fold floating point constants in cases where
> the generated result is exact; you cannot fold 1./3. for example.

As Joseph pointed out, that's what the C99 pragma is for.  For C90 it
is probably best to not fold unless exact or it is necessary.

> Also, you should not assume that the user wants the kinds of diagnostics
> you describe; they might *want* the Infinity or NaN they generated.

You seem to have missed my point.  Nowhere did I say such a thing be
thrown away.  I was talking about diagnostics.  Joseph pointed out
the compiler needs to be able to fold for some initializers anyway.

Whether you can perform the analysis, and how the user can control
the results of that analysis - what you seem to be referring to -
are of course entirely orthogonal.

Neil.

Re: Shipping gmp and mpfr with gcc-4.0?

[Vincent Lefevre]

On 2005-02-16 08:13:24 +0100, Eric Botcazou wrote:
> > I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris
> > machines and I failed on the first try.  (I think the default install
> > for gmp on my machines is a 64-bit version, but the default for mpfr
> > and gcc is 32-bit, so I'm going to have to figure out how to configure
> > everything to match.)
> 
> ./configure sparc-sun-solaris2.9 --prefix=xxx --enable-mpfr

Do not use the MPFR version that comes with GMP. It is too old.
Remember that you can override the default by setting CFLAGS.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

gcc@gcc.gnu.org

[Richard Guenther]

Hi!

While trying to implement folding of &a +- cst to &a[c] I came
along the C frontend, which for

   int a[4];
   int *p = &a[-1];

produces

   p = &a + (int *)-4;

so my new transformation gets

 constant invariant
4294967292>

as (int *)-4.

But of course trying to fold the index back into an ARRAY_REF, thereby
adjusting for the element size does not preserve the unsigned pointer
overflow behavior and I get

   &a[-4U/4] from &a[-1]

which is of course not the same.

Any idea how to avoid this kind of mess and still fold &a + cst
to an ARRAY_REF if appropriate?

Thanks,
Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

gcc@gcc.gnu.org

[Paul Schlie]

> Richard Guenther wrote:
> While trying to implement folding of &a +- cst to &a[c] I came
> along the C frontend, which for
> 
>   int a[4];
>   int *p = &a[-1];
>
> produces
>
>   p = &a + (int *)-4;

Would guess it should be:

   p = &a - (int *)4;

or even:

   p = &a + - (int *)4;

Either yielding:

   &a[-4U/4U] from &a[-1]

Which would seem consistent.

(maybe in general negative unsigned values should be represented as a
 unary minus expression with an unsigned argument: (MINUS (CONST unsigned))

-paul-

gcc@gcc.gnu.org

[Richard Guenther]

On Wed, 16 Feb 2005, Paul Schlie wrote:

> > Richard Guenther wrote:
> > While trying to implement folding of &a +- cst to &a[c] I came
> > along the C frontend, which for
> >
> >   int a[4];
> >   int *p = &a[-1];
> >
> > produces
> >
> >   p = &a + (int *)-4;
>
> Would guess it should be:
>
>p = &a - (int *)4;
>
> or even:
>
>p = &a + - (int *)4;

Yes, of course, but it is the C frontent that is producing
&a + (int *)-4, not me.  I'm just trying to work around this...

In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
conversion, but pointer_int_sum is already called with PLUS_EXPR.
build_unary_op unconditionally expands &x[y] to x+y, regardless
of the sign of y.  Of course the standard says that they are equal.
But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
we have no way to convert this back to &x[-1], as we loose the
sign information by the (int *) cast.

How do the loop optimizers handle this - negative offsets by relying
on unsigned pointer wrap-around?

Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: License text irregularity in gcc/config/mips/linux-unwind.h

[Nix]

On 11 Feb 2005, Sam Lauber mused:
> As for the exception missing, it should be kept that way.  

As libgcc is linked against every program linked using the GCC driver,
and is required by code generated with GCC, this would make it illegal
to distribute any non-GPL software built with GCC.

This is patently ridiculous and would make GCC almost useless,
regardless of technical merit. Hence the exception clause.

(Well, *clauses* really: the precise wording is different for the Ada
libraries than for libgcc, and different yet again for the libstdc++
headers, corresponding to the different ways in which normal use of the
compiler would incorporate those things into programs built with GCC.)

-- 
Synapsids unite! You have nothing to lose but your eggshells!

Re: [RFC] fold Reorganization Plan

[Nathanael Nerode]

>In practice everyone uses round to nearest even.
Not when implementing interval arithmetic or affine arithmetic, etc.

-- 
This space intentionally left blank.

Re: SVN Test Repo updated

[Joseph S. Myers]

On Tue, 15 Feb 2005, Daniel Berlin wrote:

> However, if you are satisfied with client-only diff (which is the main
> case when you'd be writing changelogs) working in alphabetical order, i
> should be able to wing that.

Client-only diff is the main case.  (For more general cases it should be 
possible to write a utility to sort diffs after creation - into 
alphabetical order for this purpose, but I've also thought topological 
sort would be useful when generating release diffs (which are done direct 
from source trees, not with cvs diff) to ensure that diffs to generated 
files that aren't version controlled (and so not handled by gcc_update) 
come after the diffs to their source files.)

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

gcc@gcc.gnu.org

[Branko Äibej]

Richard Guenther wrote:
On Wed, 16 Feb 2005, Paul Schlie wrote:
 

Richard Guenther wrote:
While trying to implement folding of &a +- cst to &a[c] I came
along the C frontend, which for
 int a[4];
 int *p = &a[-1];
produces
 p = &a + (int *)-4;
 

Would guess it should be:
  p = &a - (int *)4;
or even:
  p = &a + - (int *)4;
   

Yes, of course, but it is the C frontent that is producing
&a + (int *)-4, not me.  I'm just trying to work around this...
In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
conversion, but pointer_int_sum is already called with PLUS_EXPR.
build_unary_op unconditionally expands &x[y] to x+y, regardless
of the sign of y.  Of course the standard says that they are equal.
But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
we have no way to convert this back to &x[-1], as we loose the
sign information by the (int *) cast.
How do the loop optimizers handle this - negative offsets by relying
on unsigned pointer wrap-around?
 

Out of curiosity, how can a cast to int* ever be correct here? The 
result of adding (or subtracting) two pointers is a ptrdiff_t, so it 
seems to me that the original transformation should be

   &a[-1]  ->  &a + (ptrdiff_t)-4
-- Brane

gcc@gcc.gnu.org

[Paul Schlie]

> Yes, of course, but it is the C frontent that is producing
> &a + (int *)-4, not me.  I'm just trying to work around this...
> 
> In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
> conversion, but pointer_int_sum is already called with PLUS_EXPR.
> build_unary_op unconditionally expands &x[y] to x+y, regardless
> of the sign of y.  Of course the standard says that they are equal.
> But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
> we have no way to convert this back to &x[-1], as we loose the
> sign information by the (int *) cast.
> 
> How do the loop optimizers handle this - negative offsets by relying
> on unsigned pointer wrap-around?

- request the front-end be fixed?

Re: SVN Test Repo updated

[Daniel Jacobowitz]

On Wed, Feb 16, 2005 at 02:43:35PM +, Joseph S. Myers wrote:
> On Tue, 15 Feb 2005, Daniel Berlin wrote:
> 
> > However, if you are satisfied with client-only diff (which is the main
> > case when you'd be writing changelogs) working in alphabetical order, i
> > should be able to wing that.
> 
> Client-only diff is the main case.  (For more general cases it should be 
> possible to write a utility to sort diffs after creation - into 
> alphabetical order for this purpose, but I've also thought topological 
> sort would be useful when generating release diffs (which are done direct 
> from source trees, not with cvs diff) to ensure that diffs to generated 
> files that aren't version controlled (and so not handled by gcc_update) 
> come after the diffs to their source files.)

This would be about ten lines of shell script using filterdiff(1) and
lsdiff(1).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

gcc@gcc.gnu.org

[Theodore Papadopoulo]

On Wed, 2005-02-16 at 14:25 +0100, Richard Guenther wrote:
> On Wed, 16 Feb 2005, Paul Schlie wrote:

> Yes, of course, but it is the C frontent that is producing
> &a + (int *)-4, not me.  I'm just trying to work around this...
> 
> In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
> conversion, but pointer_int_sum is already called with PLUS_EXPR.
> build_unary_op unconditionally expands &x[y] to x+y, regardless
> of the sign of y.  Of course the standard says that they are equal.
> But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
> we have no way to convert this back to &x[-1], as we loose the
> sign information by the (int *) cast.

Reading this thread, I keep wondering why this cast to an (int*). It
should be a simple int no ??  If the intent is to have both operands of
the PLUS to have the same type then it might be a counter-example for
this rule (but I do understand that it would require specific patterns
for pointer addition which is fairly stupid in general)

Now, I'm not sure I understand the premisses of the discussion: &a
[-4U/4] from &a[-1] are not written the same but still refer to the same
value since the overflow happens the same when multiplying
(unsigned)(-4) by 4... so I do not really see where is the problem.

Then, I must add that I do not know much about the compiler's
internals...

gcc@gcc.gnu.org

[Andrew Pinski]

On Feb 16, 2005, at 10:49 AM, Theodore Papadopoulo wrote:
Then, I must add that I do not know much about the compiler's
internals...
If a[-1] os converted to a[(unsigned)-1], this is fine iff unsigned is
the same size as pointers.
-- Pinski

gcc@gcc.gnu.org

[Paul Schlie]

Aditi, Sorry, I personally don't have any experience producing a new front
end for gcc, but the below represents the way I'd approach learning how to
go about it; but suspect the only way you're going to successfully integrate
a new language front-end into gcc is to begin ripping into the C/C++/Java
front-ends and discover what you need to know.

Treelang is a simple front end meant to provide an example of a hypothetical
implementation, you might want to search for all info you can find on it, in
addition to http://gcc.gnu.org/readings.html in general.

Best of luck, -paul-

> From: aditi amol deshpande <[EMAIL PROTECTED]>
> 
> Respected Sir/Madam,
> I am a Ph.D. student and i am writing a new C# front end to the existing GCC
> compiler. 
> I have several queries which unless and untill solved, I cannot move ahead. So
> hoping for a proper and quick reply.
> ...

gcc@gcc.gnu.org

[Jeffrey A Law]

On Wed, 2005-02-16 at 16:49 +0100, Theodore Papadopoulo wrote:
> On Wed, 2005-02-16 at 14:25 +0100, Richard Guenther wrote:
> > On Wed, 16 Feb 2005, Paul Schlie wrote:
> 
> > Yes, of course, but it is the C frontent that is producing
> > &a + (int *)-4, not me.  I'm just trying to work around this...
> > 
> > In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
> > conversion, but pointer_int_sum is already called with PLUS_EXPR.
> > build_unary_op unconditionally expands &x[y] to x+y, regardless
> > of the sign of y.  Of course the standard says that they are equal.
> > But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
> > we have no way to convert this back to &x[-1], as we loose the
> > sign information by the (int *) cast.
> 
> Reading this thread, I keep wondering why this cast to an (int*). It
> should be a simple int no ??  If the intent is to have both operands of
> the PLUS to have the same type then it might be a counter-example for
> this rule (but I do understand that it would require specific patterns
> for pointer addition which is fairly stupid in general)
The cast is to ensure that both operands of the PLUS_EXPR have
the same type.

I looked for a little while into fixing this by having a new
tree node (PLUS_POINTER_EXPR or whatever it was) which took a 
pointer and an integer.  The amount of work necessary to get
that going is mind-boggling.  I gave up.

jeff

gcc@gcc.gnu.org

[Paul Schlie]

> In fact, it is c-common.c:2289 that does -4  ->  (int *)-4
> conversion, but pointer_int_sum is already called with PLUS_EXPR.
> build_unary_op unconditionally expands &x[y] to x+y, regardless
> of the sign of y.  Of course the standard says that they are equal.
> But is &x[-1] == x + (int *)4*(int *)-1 ?  From this follows that
> we have no way to convert this back to &x[-1], as we loose the
> sign information by the (int *) cast.
> 
> How do the loop optimizers handle this - negative offsets by relying
> on unsigned pointer wrap-around?

Possibly more correct:

  &x[-1] == (int *)x + (int *)((size_t)4*(int)-1)

=> 

  &x[-1] == (int *)x - (int *)((size_t)4*(size_t)1)

Implying that in general:

  (unsigned)((unsigned)x * (signed)y)

=>

  -((unsigned)x * (unsigned)y)

not:

  +((unsigned)x * (unsigned)(signed)y)

Re: SVN Test Repo updated

[Per Bothner]

Daniel Berlin wrote:
Complete alphabetical order is not in the cards for diff, at least for
diffs involving server side (diffs that are client side are easily
sorted by filename).
This is because it would require losing the "streaminess" of the
protocol (unlike cvs, the client and the server in svn are really
seperate, and the client just gets a stream of results.  Sorting would
require at least holding all the directory entries in the server at
once, before sending them to the client, if not worse),
Huh?  I don't get this.  You sort filenames *in* the server *before*
you generate diffs.  And you do the sorting within each directory;
i.e. early before you do anything else.  What does the "streaming
protocol" have to do with this?  Dogenerate teh stream in order,
that's all?
How to do this depends on the internal data structures of the
repository, and I realize that the possibility of renames does
complicate those data structures.  But there has to be a data structure
and api to navigate the file hierarchy - a "tree walker".  That
tree walker should sort by filename before doing anything with
the contents of a directory.
Yes, the sorting does cost some time, but sorting a directory is
pretty fast.  You can do much better than quicksort: Put each filename
in one of 27 buckets, one for each of A/a to Z/z, and one for "other",
and the
as well as their being locale issues
We're talking about filenames for source code.  At least for gcc,
it's fine to hardcode a case-folding "code point" sort order.
Preferably, the sort algorithm should match 'ls'.  (Specifically
GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong.
It's especially ridiculous on a case-folding Mac, but I couldn't
convince the BSD peopel of that.)
(the server would have to know the client's locale
to sort the files so they appeared in the alphabetical order you
expect).
No problem.  The client's request can include the current LOCALE value.
However, I'm not sure that's derirable.  Obviously the charset and
language used for filenames cannot be client-dependent.  The sort
order could be client-dependent, but since it might not match the
server language, I don't think it makes sense.  If I'm a German
speaker working with repository containing English filenames, the
sort order should be English, regardless of my LOCALE.
In other words, so far the cost of trying to do it has
outweighed the benefit of having diffs appear in some well-specified
order.
Having output in a well-specified order is very important.  How else
would I be able to compare two 'diff' runs otherwise?  How would I
write a regression test for 'svn diff'?  Of course I can postprocess
the output, but it's much more convenient and efficient to just sort
each directory before diffing each file.
More generally, any listing that humans are expected to see should
be sorted.  If you put it in random order people will wonder if there
is a meaning to the order.  An 'ls' that doesn't by default sort the
output is obviously Wrong.
Now I'm not suggesting this is a show-stopper issue, or that you should
be responsible for fixing it.  But clearly, if svn output is not by
default in a predictable output, that is most definitely a serious
(but not critical) bug.  (It's ok to have a "don't sort" option to
speed things up, but it shouldn't be the default.)
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: SVN Test Repo updated

[Vincent Lefevre]

On 2005-02-16 09:41:13 -0800, Per Bothner wrote:
> Preferably, the sort algorithm should match 'ls'.

FYI, the way ls (from the coreutils) sorts the filenames is
locale-dependent. :(

> No problem.  The client's request can include the current LOCALE value.
> However, I'm not sure that's derirable.  Obviously the charset and
> language used for filenames cannot be client-dependent.  The sort
> order could be client-dependent, but since it might not match the
> server language, I don't think it makes sense.  If I'm a German
> speaker working with repository containing English filenames, the
> sort order should be English, regardless of my LOCALE.

I agree. With French locales, the "-" character is ignored for
sorting (with ls, but not specifically, AFAIK), so I got strange
results when sorting filenames of the form: -.

> Having output in a well-specified order is very important.  How else
> would I be able to compare two 'diff' runs otherwise? [...]

Output could also be unspecified, but reproducible. That would be
sufficient to compare diffs.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

ObjC++ Status ?

[Serguei Kouratov]

Hi,

Could somebody inform about status of ObjC++ branch ?
Recently I took CVS sources & built native MinGW compilers,
1. but version is 3.5.0 20040819 - very old !!!
2. and it produces internal compile error when I try to compile simplest ObjC
example with .mm extension:
#import 
#import 

@interface MyClass: Object
{
  int  val;
}

-(void)   print;

@end

@implementation MyClass; /// <<<--- Test.mm:13: internal compiler error...
-(void) print
{
  printf (" Hey\n");
}

@end

int main (int argc, char *argv[])
{
  MyClass  *myClass;

  myClass = [MyClass alloc];
  myClass = [myClass init];

  [myClass print];
  [myClass free];

  return 0;
}

The same file with .m extension works fine.

Serguei Kouratov

Re: SVN Test Repo updated

[Daniel Berlin]

On Wed, 2005-02-16 at 09:41 -0800, Per Bothner wrote:
> Daniel Berlin wrote:
> Huh?  I don't get this.  You sort filenames *in* the server *before*
> you generate diffs.  And you do the sorting within each directory;
> i.e. early before you do anything else.  What does the "streaming
> protocol" have to do with this?  Dogenerate teh stream in order,
> that's all?
> 
> How to do this depends on the internal data structures of the
> repository, and I realize that the possibility of renames does
> complicate those data structures.  But there has to be a data structure
> and api to navigate the file hierarchy - a "tree walker".  That
> tree walker should sort by filename before doing anything with
> the contents of a directory.

You assume the tree walker ever sees an entire directory at once, for
starters. I'm not sure it does. I may be wrong, i've not explored that
portion of the code in detail.
> 
> Yes, the sorting does cost some time, but sorting a directory is
> pretty fast.  You can do much better than quicksort: Put each filename
> in one of 27 buckets, one for each of A/a to Z/z, and one for "other",
> and the
> 

Patches welcome :)

I haven't looked in detail, but i don't believe it's near as simple as
you think, because the structure of how a diff happens isn't what you
think it is.
I believe someone is going to try to just store/walk the dirent hash in
a sorted order for now when possible, so that everything above the fs
level just gets handed this stuff in sorted order.


> No problem.  The client's request can include the current LOCALE value.
> However, I'm not sure that's derirable.  Obviously the charset and
> language used for filenames cannot be client-dependent.  The sort
> order could be client-dependent, but since it might not match the
> server language, I don't think it makes sense.  If I'm a German
> speaker working with repository containing English filenames, the
> sort order should be English, regardless of my LOCALE.

Protocol changes are no simple matter. We can't just arbitrarily break
the client/server protocol.
There needs to be a graceful fallback for older clients against newer
servers, and the reverse, at least until 2.0.

Anyway, i was just trying to throw you off track, because *I* have no
current plans to make diff output in sorted order :)

> 
> > In other words, so far the cost of trying to do it has
> > outweighed the benefit of having diffs appear in some well-specified
> > order.
> 
> Having output in a well-specified order is very important.  How else
> would I be able to compare two 'diff' runs otherwise?  How would I
> write a regression test for 'svn diff'?  Of course I can postprocess
> the output, but it's much more convenient and efficient to just sort
> each directory before diffing each file.
> 
> More generally, any listing that humans are expected to see should
> be sorted.  If you put it in random order people will wonder if there
> is a meaning to the order.  An 'ls' that doesn't by default sort the
> output is obviously Wrong.

It's not *random* order.
It's deterministic, and stable. It's just not sorted alphabetically.
Thus, you can compare and regression test svn diff output (which we
do) :)

> 
> Now I'm not suggesting this is a show-stopper issue, or that you should
> be responsible for fixing it.  But clearly, if svn output is not by
> default in a predictable output, that is most definitely a serious
> (but not critical) bug.  (It's ok to have a "don't sort" option to
> speed things up, but it shouldn't be the default.)

Again, patches are welcome :)
(I believe someone is working on it to some degree, soon)

gcc@gcc.gnu.org

[Paul Schlie]

Sorry, yes:

   &x[-1] == (int *)x + (int *)4*(int *)-1

would be correct/true, and probably
simplest; although equivalent to either:

   &x[-1] == (int *)x + (int *)((int)4*(int)-1)
or:
   &x[-1] == (int *)x + (int *)((size_t)4*(int)-1)
or:
   &x[-1] == (int *)x + (int *)((size_t)4*(size_t)-1)

Re: SVN Test Repo updated

[Andreas Schwab]

Per Bothner <[EMAIL PROTECTED]> writes:

> Preferably, the sort algorithm should match 'ls'.  (Specifically
> GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong.

The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE.  But then, BSD (at least the variant used in MacOSX) is way
behind current l10n standards.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: SVN Test Repo updated

[Per Bothner]

Andreas Schwab wrote:
Per Bothner <[EMAIL PROTECTED]> writes:

Preferably, the sort algorithm should match 'ls'.  (Specifically
GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong.

The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE.
If we're going to nit-pick. I guess I should have written "sort order"
rather than "sort algorithm".
Output from svn commands should be sorted by filename, using the
same sort order as 'ls'.  The collation to use (at least the
default collation) should be a repository property, not the
client's collation, though this is not very important.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: SVN Test Repo updated

[Per Bothner]

Daniel Berlin wrote:
You assume the tree walker ever sees an entire directory at once, for
starters.
It seems a reasonable assumption that such a tree walker exists or
could be written without too much pain.  I can imagine a tree walker
that iterates over file numbers (a la inodes), and that may be most
efficient for some operations.  But it's clearly wrong for producing
log/summary/diff output for humans.
Patches welcome :)
Duh.  I'm not going to start patching svn.  I'm reporting a bug.
I'm not saying anything about the priority of the bug.  I think it
should be reported as a formal bug, but I'm not going to do that myself
until I personally witness the buggy behavior, and I don't have
time to try out svn quite yet.
I haven't looked in detail, but i don't believe it's near as simple as
you think, because the structure of how a diff happens isn't what you
think it is.
I'm quite willing to believe some redesign may be needed to fix the bug.
I believe someone is going to try to just store/walk the dirent hash in
a sorted order for now when possible, so that everything above the fs
level just gets handed this stuff in sorted order.
I think that is what I'm proposing.
Protocol changes are no simple matter. We can't just arbitrarily break
the client/server protocol.
There needs to be a graceful fallback for older clients against newer
servers, and the reverse, at least until 2.0.
Hopefully the protocol is somewhat extensible?
In any case, using the client's LC_COLLATE may not be the right thing,
and it's certainly not important.
(I believe someone is working on it to some degree, soon)
Great.
As I said: I don't see this issue as a show-stopper for converting
gcc to svn.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Major regression on mainline

[Steve Kargl]

A binary search has led to the cause of a serious regression on
mainline with gfortran at *all optimization levels (ie., -O0, -O1
and -O2)*.  The problematic commit is

   2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>

PR mudflap/19319
* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
slot explicit.

PR c++/16405
* fold-const.c (fold_indirect_ref_1): Split out from...
(build_fold_indirect_ref): Here.
(fold_indirect_ref): New fn.
* tree.h: Declare it.
* gimplify.c (gimplify_compound_lval): Call fold_indirect_ref.
(gimplify_modify_expr_rhs): Likewise.
(gimplify_expr): Likewise.

troutmask:sgk[271] cvs update -D '2005-02-12 22:45' |& tee sgk.log
troutmask:sgk[274] grep -v "cvs update" sgk.log
C .cvsignore
P gcc/ChangeLog
P gcc/fold-const.c
P gcc/gimplify.c
P gcc/tree.h
M gcc/fortran/check.c
M gcc/fortran/intrinsic.c
M gcc/fortran/intrinsic.h
M gcc/fortran/resolve.c
M gcc/fortran/simplify.c
P gcc/testsuite/ChangeLog
U gcc/testsuite/gcc.dg/pr15784-1.c
U gcc/testsuite/gcc.dg/pr15784-2.c
U gcc/testsuite/gcc.dg/pr15784-3.c
M libgfortran/intrinsics/date_and_time.c

where the 6 gfortran changes do not cause the problem.  If I
use -D '2005-02-12 22:30', which eliminates the above cited
commit, I get a working gfortran.  Additionally, a 'gmake
check-gfortran' with or without this commit shows no new
regressions.

The regression is apparent with the test programs that come
with the implementation of BLAS that accompanies LAPACK from
ftp.netlib.org.  If I use the -D '2005-02-12 22:30' sources,
gfortran produces no failures with the BLAS test programs.
If I use the -D '2005-02-12 22:45' sources, which includes the
above cited commit, I get the following:

troutmask:sgk[280] grep -i fail testing/*out
testing/xblat2c.out: *** CTRMV  FAILED ON CALL NUMBER:
testing/xblat2c.out: *** CTBMV  FAILED ON CALL NUMBER:
testing/xblat2c.out: *** CTPMV  FAILED ON CALL NUMBER:
testing/xblat2c.out: *** CTRSV  FAILED ON CALL NUMBER:
testing/xblat2c.out: *** CTBSV  FAILED ON CALL NUMBER:
testing/xblat2c.out: *** CTPSV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTRMV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTBMV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTPMV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTRSV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTBSV  FAILED ON CALL NUMBER:
testing/xblat2d.out: *** DTPSV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STRMV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STBMV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STPMV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STRSV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STBSV  FAILED ON CALL NUMBER:
testing/xblat2s.out: *** STPSV  FAILED ON CALL NUMBER:
testing/xblat2z.out: *** ZHEMV  FAILED ON CALL NUMBER:
testing/xblat2z.out: *** ZHBMV  FAILED ON CALL NUMBER:
testing/xblat2z.out: *** ZHER   FAILED ON CALL NUMBER:
testing/xblat2z.out: *** ZHPR   FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CGEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CGEMM  FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CHEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CHEMM  FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CSYMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CSYMM  FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CTRMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CTRMM  FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CTRSM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CTRSM  FAILED ON CALL NUMBER:
testing/xblat3c.out: *** CHERK  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CSYRK  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CHER2K FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3c.out: *** CSYR2K FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3d.out: *** DGEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3d.out: *** DGEMM  FAILED ON CALL NUMBER:
testing/xblat3d.out: *** DTRMM  FAILED ON CALL NUMBER:
testing/xblat3d.out: *** DTRSM  FAILED ON CALL NUMBER:
testing/xblat3d.out: *** DSYRK  FAILED ON CALL NUMBER:
testing/xblat3s.out: *** SGEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3s.out: *** STRMM  FAILED ON CALL NUMBER:
testing/xblat3s.out: *** STRSM  FAILED ON CALL NUMBER:
testing/xblat3s.out: *** SSYR2K FAILED ON CALL NUMBER:
testing/xblat3z.out: *** ZGEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3z.out: *** ZGEMM  FAILED ON CALL NUMBER:
testing/xblat3z.out: *** ZHEMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3z.out: *** ZSYMM  FAILED THE TESTS OF ERROR-EXITS ***
testing/xblat3z.out: *** ZTRMM  FAILED THE TESTS

Re: Major regression on mainline

[Jason Merrill]

On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:

> A binary search has led to the cause of a serious regression on
> mainline with gfortran at *all optimization levels (ie., -O0, -O1
> and -O2)*.  The problematic commit is
>
>2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>
>
> PR mudflap/19319
> * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
> slot explicit.

I reverted this change shortly after the commit.  Have you tested again
with updated sources?

I plan to commit a corrected version today.

Jason

Re: ObjC++ Status ?

[Timothy J . Wood]

On Wednesday, February 16, 2005, at 10:03  AM, Serguei Kouratov wrote:
@implementation MyClass; /// <<<--- Test.mm:13: internal compiler 
error...
  Is the ';' even supposed to be allowed there?  Maybe the bug is that 
the non-ObjC++ compiler accepts this.

-tim

Re: Major regression on mainline

[Steve Kargl]

On Wed, Feb 16, 2005 at 05:44:44PM -0500, Jason Merrill wrote:
> On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> 
> > A binary search has led to the cause of a serious regression on
> > mainline with gfortran at *all optimization levels (ie., -O0, -O1
> > and -O2)*.  The problematic commit is
> >
> >2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>
> >
> > PR mudflap/19319
> > * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
> > slot explicit.
> 
> I reverted this change shortly after the commit.  Have you tested again
> with updated sources?
> 
> I plan to commit a corrected version today.
> 

I noticed the problem early yesterday morning and have since been
trying to determine the (quilty) commit.  A binary search and
make bootstrap can be a length process :-)  I'll update to HEAD
and see what happens.  Thanks for the note.

-- 
Steve

gcc-3.3-20050216 is now available

[gccadmin]

Snapshot gcc-3.3-20050216 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050216 

You'll find:

gcc-3.3-20050216.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.3-20050216.tar.bz2 C front end and core compiler

gcc-ada-3.3-20050216.tar.bz2  Ada front end and runtime

gcc-g++-3.3-20050216.tar.bz2  C++ front end and runtime

gcc-g77-3.3-20050216.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.3-20050216.tar.bz2 Java front end and runtime

gcc-objc-3.3-20050216.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.3-20050216.tar.bz2The GCC testsuite

Diffs from 3.3-20050209 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Major regression on mainline

[Jason Merrill]

On Wed, 16 Feb 2005 15:13:09 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:

> On Wed, Feb 16, 2005 at 05:44:44PM -0500, Jason Merrill wrote:
>> On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
>> 
>> > A binary search has led to the cause of a serious regression on
>> > mainline with gfortran at *all optimization levels (ie., -O0, -O1
>> > and -O2)*.  The problematic commit is
>> >
>> >2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>
>> >
>> > PR mudflap/19319
>> > * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
>> > slot explicit.
>> 
>> I reverted this change shortly after the commit.  Have you tested again
>> with updated sources?
>> 
>> I plan to commit a corrected version today.
>
> I noticed the problem early yesterday morning and have since been
> trying to determine the (quilty) commit.  A binary search and
> make bootstrap can be a length process :-)  I'll update to HEAD
> and see what happens.  Thanks for the note.

If it was still broken yesterday morning, it wouldn't have been the above
change, as I reverted it on Sunday.  That leaves the fold_indirect_ref
changes, which I reapplied on Monday.

Those changes are merely expanding INDIRECT_REF folding to occur during
gimplification.  My guess would be that the fortran front end is doing
something inappropriate with pointers, but it's hard to say without a
testcase.

Could someone on the fortran team take a look at this and/or point me at a
testcase I can just feed to the compiler to see the problem?

Jason

Re: Shipping gmp and mpfr with gcc-4.0?

[Marcin Dalecki]

During my efforts to compile the whole gcc with a C++ compiler I 
noticed that
the gmp library is somehow problematic with regard to this. The gmp.h 
header
is using the __cplusplus define at will not just to specify the linkage 
class of
the symbols provided there (extern "C"), but to define the C++ specific 
interface
as well. Like for example:

#if defined (__cplusplus)
#include/* for istream, ostream */
#endif
This happens even if one does tell gmp to not provide the C++ wrappers 
at all.
Disgusting isn't it?

x86_64 - 128 bit structs not targeted to TImode: MAX_FIXED_MODE_SIZE too small?

[Gary Funck]

Given,

struct shared_ptr_struct
  {
unsigned int phase  : 24;
unsigned short thread : 16;
void *addr;
  };

On the x86_64 (ie, Opteron[tm]) platform, GCC appears to designate the
underlying mode of this type as a BLKmode, instead of a TImode.  This
has implications in terms of the quality of the code that is generated
to copy and manipulate 128 bit structures (as defined in the example
above).

The decision to commit this type to a BLKmode value, originates
in this logic in mode_for_size():

  if (limit && size > MAX_FIXED_MODE_SIZE)
 return BLKmode;

On the x86 platform, there appears to be no target definition for
MAX_FIELD_SIZE. Thus, the default in stor-layout.c applies:

#ifndef MAX_FIXED_MODE_SIZE
#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
#endif

Other 64 bit targets define MAX_FIXED_MODE_SIZE along these lines
(some line wrapping may occur below):

config/i960/i960.h:#defineMAX_FIXED_MODE_SIZE GET_MODE_BITSIZE
(TImode)
config/ia64/ia64.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TImode)
config/mips/mips.h:#define MAX_FIXED_MODE_SIZE LONG_DOUBLE_TYPE_SIZE
config/sh/sh.h:#define MAX_FIXED_MODE_SIZE (TARGET_SH5 ? 128 : 64)

on MIPS, LONG_DOUBLE_TYPE_SIZE is defined as follows:

/* A C expression for the size in bits of the type `long double' on
   the target machine.  If you don't define this, the default is two
   words.  */
#define LONG_DOUBLE_TYPE_SIZE \
  (mips_abi == ABI_N32 || mips_abi == ABI_64 ? 128 : 64)

In the 'dev' tree, the s390 defines MAX_FIXED_MODE_SIZE as follows:

config/s390/s390.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE
(TARGET_64BIT ? TImode : DImode)

(Arguably, the s390 variant might be a better default value to be defined
in stor-layout.c)

I haven't tried making the suggested change to see if the x86_64 code
generator can fully support it.  Are there any technical reasons that
the x86_64 shouldn't target 128 bit structs into a long double (ie, two
64 bit registers)?

Re: Shipping gmp and mpfr with gcc-4.0?

[Marcin Dalecki]

On 2005-02-16, at 12:32, Vincent Lefevre wrote:
Do not use the MPFR version that comes with GMP. It is too old.
Remember that you can override the default by setting CFLAGS.
The documentation doesn't say this. The configure scripts don't check
for it.

Re: ObjC++ Status ?

[Marcin Dalecki]

On 2005-02-16, at 19:03, Serguei Kouratov wrote:
Could somebody inform about status of ObjC++ branch ?
The biggest obstacle to merging the current ObjC++ code from
apple-ppc-patch is the recent invention of objc_info field to the
struct lang_tree for C. There are some comments there but apparently
it's quite hard to deduce from the what actually to do about the
C++ code from them. I did try this recently out of self entertainment
and did give up after about 2 hours of experimenting. Just adding the
field for C++ results in a crashing C++ compiler...

Re: Accessing the subversion repository

[Marc Espie]

In article <[EMAIL PROTECTED]> you write:
>Daniel Berlin wrote:
>> I should note that svn treats it's remote connections as disposable, so
>> svn+ssh will probably connect more than once for things like remote
>> diffs.  So if it takes a while to authenticate, this may not be your
>> best bet if you are looking for blazing speed (as some seem to be :P).
>
>It would seem to be possible to use fsh to cache ssh connections for
>svn.  But I have not tried it with svn and have not worked out the
>exact client side svn configuration syntax.
>
>  http://www.lysator.liu.se/fsh/

Recent versions of openssh support multiple connections through one
single authentication token (`master' connection)

My .ssh/config looks like this:

Host cvs-base
Hostname cvs.host
ControlMaster yes
ControlPath ~/.ssh/openbsd-mux
Host cvs-fast
ControlMaster no
ControlPath ~/.ssh/openbsd-mux

and I use something like this for a cvs script:

#!/bin/sh
CVS_RSH=ssh
export CVS_RSH
test -e $HOME/.ssh/openbsd-mux && exec cvs -z3 -d cvs-fast:/cvs "$@"
exec cvs -z3 -d [EMAIL PROTECTED]:/cvs "$@"


No need for fsh or anything. Didn't this feature make it into portable 
openssh ?

Re: SVN Test Repo updated

[Marc Espie]

In article <[EMAIL PROTECTED]> you write:
>Complete alphabetical order is not in the cards for diff, at least for
>diffs involving server side (diffs that are client side are easily
>sorted by filename).
>This is because it would require losing the "streaminess" of the
>protocol (unlike cvs, the client and the server in svn are really
>seperate, and the client just gets a stream of results.  Sorting would
>require at least holding all the directory entries in the server at
>once, before sending them to the client, if not worse), as well as their
>being locale issues (the server would have to know the client's locale
>to sort the files so they appeared in the alphabetical order you
>expect).  In other words, so far the cost of trying to do it has
>outweighed the benefit of having diffs appear in some well-specified
>order.

Dare I say it ?
I don't want any locale behavior in a version control system.
Specifically because there are client/server issues, and you never
know which is which.  I've seen enough trouble with cvs timestamps.

If/when gcc switches to svn, please, please, please try very hard to
ensure that any time coming out of svn or going in is in UTC by default,
and that the user will have to push very hard to get local time.

I remember trying to find a bug by dichotomy, and having a real hard
time figuring out which parts of the log were in Mountain Time, which
were in GMT, how to convert between the two, while trying to actually
find that darn bug.

Re: RFC: Appropriate method for target-specific mode-substititutes in libgcc2

[James E Wilson]

Björn Haase wrote:
#ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
typedef float   DFtype  __attribute__ ((mode (DF)));
#else
typedef float   DFtype  
   __attribute__ ((mode (TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF)));
#endif
These libgcc2 functions really are tied to modes, not to types.  So if 
double is SFmode, gcc will never call one of the *df* functions for it. 
 Meanwhile, some targets that make double be SFmode also make long 
double be DFmode, and hence we do still need the *df* functions defined 
exactly as they are currently defined in order for the long double 
support to work.  Hence it would be very wrong to redefine the *df* 
functions to use mode (SF) instead of mode (DF) for any target.

If this is a simple matter of not being able to compile some of the 
functions in libgcc2.c, one possible solution would be to avoid 
compiling them.  You could use the trick used in arm/t-symbian, which is 
to put them in LIB1ASMFUNCS.

Otherwise, it isn't clear what the problem is, because libgcc2 has been 
using these types without apparent problem for a very long time.  If 
there is a problem, you need to be clearer about what exactly the 
problem is.  If the problem is one of the bigger modes, then we can add 
ifdefs to control when it is used.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Problem in porting GLIBC...

[Ian Lance Taylor]

[EMAIL PROTECTED] writes:

> At this stage we are trying to get the 'ld-2.2.5.so' working. We are
> facing problems in this. We are trying to run this on again on our own
> Linux kernel for ABACUS processor. The GOT & PLT generated through the GCC
> for ld-2.2.5.so is causing the problems.
> 
> At this moment we are into the main of the user test case. We have jumped
> on the User Entry through the LD.so
> 
> There must be some problem in the relocation and now we are unable to
> trace the flow as we are not having the debugger and we use to have  print
> statememts to debug the LD. Now it is not possible to use the print
> statements also.
> 
> Could you please give us some hint about how to proceed further.

You are in the black magic area.  If you have a simulator, you can use
that.  Otherwise, since you presumably have a working kernel, you can
usually hack print statements by using inline assembler to do a direct
invocation of the write system call.  If that doesn't work, the next
step is probably hand simulation of the instructions in the suspect
code.

Ian

Re: g++ compile-time error with template arguments in 4.0 CVS?

[Giovanni Bajo]

Benjamin Redelings I <[EMAIL PROTECTED]> wrote:

> I have a reduced testcase from BOOST that fails with yesterdays CVS
> (4.0.0 20050214 (experimental)), but compiles under 3.4.  I don't know
> if this is a bug in BOOST or in g++:
> 
> -- begin testcase
> template< typename T, T N >
> struct integral_c
> {
>static const T value = N;
> 
>typedef integral_c< T, static_cast((value + 1)) > next;
>//  typedef integral_c< T, static_cast((value - 1)) > prior;
> 
>//  operator T() const { return static_cast(this->value); }
> };
> --- end testcase
> % g++-cvs testcase.C
> c.C:6: error: template argument 2 is invalid
> 
> Note that simply replacing 'value' by 'N' make this compile.
> 
> The original error was obtained by including
> 
> The following error was recieved:
> 
> In file included from /usr/include/boost/config.hpp:35,
>   from /usr/include/boost/numeric/ublas/config.hpp:24,
>   from /usr/include/boost/numeric/ublas/matrix.hpp:20,
>   from a.C:1:
> /usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning
> "Unknown compiler version - please run the configure tests and report
> the results"
> /usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: template
> argument 2 is invalid
> /usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: template
> argument 2 is invalid
> 
> Please let me know if I should file a PR

Please add your testcase to PR19883 and mention that this is breaking boost.

Giovanni Bajo

Re: x86_64 - 128 bit structs not targeted to TImode: MAX_FIXED_MODE_SIZE too small?

[Michael Matz]

Hi,

On Wed, 16 Feb 2005, Gary Funck wrote:

> struct shared_ptr_struct
>   {
> unsigned int phase  : 24;
> unsigned short thread : 16;
> void *addr;
>   };
> 
> On the x86_64 (ie, Opteron[tm]) platform, GCC appears to designate the
> underlying mode of this type as a BLKmode, instead of a TImode.  This
> 
> I haven't tried making the suggested change to see if the x86_64 code
> generator can fully support it.  Are there any technical reasons that
> the x86_64 shouldn't target 128 bit structs into a long double (ie, two
> 64 bit registers)?

Ugh, good catch.  If changing MAX_FIXED_MODE_SIZE doesn't affect the ABI
(and I wouldn't know why it should) then we could change it.  (it
optimizes a simple test program copying and passing your structure 
around).


Ciao,
Michael.

Re: RFC: Appropriate method for target-specific mode-substititutes in libgcc2

[James E Wilson]

James E Wilson wrote:
Björn Haase wrote:
#ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
I see now that this is PR 19920.  This message would have made more 
sense if you had included that important info.

Anyways, I see that Richard Henderson has added a reasonable fix for it 
now along the lines I suggested, e.g. adding ifdefs to control when the 
bigger modes are used.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Major regression on mainline

[Steve Kargl]

On Wed, Feb 16, 2005 at 07:14:35PM -0500, Jason Merrill wrote:
> On Wed, 16 Feb 2005 15:13:09 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Feb 16, 2005 at 05:44:44PM -0500, Jason Merrill wrote:
> >> On Wed, 16 Feb 2005 14:34:59 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> >> 
> >> > A binary search has led to the cause of a serious regression on
> >> > mainline with gfortran at *all optimization levels (ie., -O0, -O1
> >> > and -O2)*.  The problematic commit is
> >> >
> >> >2005-02-13  Jason Merrill  <[EMAIL PROTECTED]>
> >> >
> >> > PR mudflap/19319
> >> > * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
> >> > slot explicit.
> >> 
> >> I reverted this change shortly after the commit.  Have you tested again
> >> with updated sources?
> >> 
> >> I plan to commit a corrected version today.
> >
> > I noticed the problem early yesterday morning and have since been
> > trying to determine the (quilty) commit.  A binary search and
> > make bootstrap can be a length process :-)  I'll update to HEAD
> > and see what happens.  Thanks for the note.
> 
> If it was still broken yesterday morning, it wouldn't have been the above
> change, as I reverted it on Sunday.  That leaves the fold_indirect_ref
> changes, which I reapplied on Monday.
> 
> Those changes are merely expanding INDIRECT_REF folding to occur during
> gimplification.  My guess would be that the fortran front end is doing
> something inappropriate with pointers, but it's hard to say without a
> testcase.
> 
> Could someone on the fortran team take a look at this and/or point me at a
> testcase I can just feed to the compiler to see the problem?

Bad news.  The problem is still present in HEAD, ie., source from
3 hours ago.   Even worse news is cutting down the BLAS test
program can be a chore.  I'll see what I can do.

To be clear, gfortran works fine with -D '2005-02-12 22:30' sources,
which excludes the above commit.  The -D '2005-02-12 22:45' sources
include the above commit and gfortran has a serious regression.  You
reverted the entire commit, then re-applied what portion of the
commit?  ChangeLog does not reflect any of these manipulations
with any kind of accurate date. 

-- 
Steve

Re: RFC: Appropriate method for target-specific mode-substititutesin libgcc2

[Paul Schlie]

> James E Wilson wrote:
> These libgcc2 functions really are tied to modes, not to types. So if double
> is SFmode, gcc will never call one of the *df* functions for it. Meanwhile,
> some targets that make double be SFmode also make long double be DFmode, and
> hence we do still need the *df* functions defined exactly as they are
> currently defined in order for the long double support to work. Hence it would
> be very wrong to redefine the *df* functions to use mode (SF) instead of mode
> (DF) for any target.

- yes you would think so, but in fact what libgcc2.h actually does is:

 ...
 #elif MIN_UNITS_PER_WORD > 1
 #define W_TYPE_SIZE (2 * BITS_PER_UNIT)
 #define WtypeHItype
 #define UWtypeUHItype
 #define HWtypeHItype
 #define UHWtypeUHItype
 #define DWtypeSItype
 #define UDWtypeUSItype
 #define __NW(a,b)__ ## a ## hi ## b
 #define __NDW(a,b)__ ## a ## si ## b
 ...
 #define __muldi3__NDW(mul,3)
 #define __divdi3__NDW(div,3)
 ...

(which is fairly odd at best, and simply wrong worst-case)

> If this is a simple matter of not being able to compile some of the functions
> in libgcc2.c, one possible solution would be to avoid compiling them. You
> could use the trick used in arm/t-symbian, which is to put them in
> LIB1ASMFUNCS.

- unfortunately, avoidance doesn't seem like a vote of confidence?

> Otherwise, it isn't clear what the problem is, because libgcc2 has been using
> these types without apparent problem for a very long time. If there is a
> problem, you need to be clearer about what exactly the problem is. If the
> problem is one of the bigger modes, then we can add ifdefs to control when it
> is used.

- fundamentally the problem is that libgcc is too fragile; when it works, it
works by a consequence of a series of hacks that end-up reasonably guessing
what the type-modes a particular target supports based on it's defined word
size, which in general has no warranted correlation to a target's defined
type sizes.

- the proper fix is likely simply applying the method Richard used to
correctly determine if a particular mode is required for a target based
on the targets defined type-sizes, and then conditionally defining the
corresponding functions for that mode based on it's known need, to the
remaining of libgcc2's implementation.

(which although relatively straight forward, most seem reluctant to
 consider touching something that is perceived to work, even if only
 by coincidence, if not actually avoiding it; this is what I believe
 Bjorn was volunteering to try to help to remedy in as painless way as
 possible, which suspect some if not many would welcome, I hope.)

Re: Major regression on mainline

[Jason Merrill]

On Wed, 16 Feb 2005 18:24:58 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:

> Bad news.  The problem is still present in HEAD, ie., source from
> 3 hours ago.   Even worse news is cutting down the BLAS test
> program can be a chore.  I'll see what I can do.
>
> To be clear, gfortran works fine with -D '2005-02-12 22:30' sources,
> which excludes the above commit.  The -D '2005-02-12 22:45' sources
> include the above commit and gfortran has a serious regression.  You
> reverted the entire commit, then re-applied what portion of the
> commit?  ChangeLog does not reflect any of these manipulations
> with any kind of accurate date. 

Yes, I just added a [reverted temporarily] note to the ChangeLog entry.  I
reapplied the portion marked c++/16405, which doesn't have the [reverted]
note on it.

I suspect that the problem is that the transformations fold_indirect_ref_1
is doing on arrays don't mix well with how fortran handles arrays.  Could
someone familiar with the fortran frontend take a look at that function?

Jason

PATCH for Re: website correction

[Gerald Pfeifer]

On Sun, 13 Feb 2005, Noah John wrote:
> Apologies if this is the wrong place to send this, but the bottom of the 
> page said send comments here.

This was, in fact, just the right thing to do, thanks!

> The link to Apple's website on the page
> "http://gcc.gnu.org/install/specific.html#powerpc-*-darwin*"; needs to be
> updated.  It reads: "http://developer.apple.com/tools/compilers.html";
> The new correct link is "http://developer.apple.com/darwin/projects/compiler/";

I just applied the following patch, and the web page should be updated 
within 24 hours.  In addition to mainline, I will also apply this patch
on the GCC 3.4 branch.

Gerald

2005-02-17  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Specific): Update link for Darwin-specific
tool binary site.

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.334
diff -u -3 -p -r1.334 install.texi
--- doc/install.texi16 Feb 2005 21:47:25 -  1.334
+++ doc/install.texi17 Feb 2005 03:43:18 -
@@ -3362,7 +3362,7 @@ PowerPC running Darwin (Mac OS X kernel)
 Pre-installed versions of Mac OS X may not include any developer tools,
 meaning that you will not be able to build GCC from source.  Tool
 binaries are available at
[EMAIL PROTECTED]://developer.apple.com/tools/compilers.html} (free
[EMAIL PROTECTED]://developer.apple.com/darwin/projects/compiler/} (free
 registration required).
 
 This version of GCC requires at least cctools-528.

Re: Major regression on mainline

[Steve Kargl]

On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
> On Wed, 16 Feb 2005 18:24:58 -0800, Steve Kargl <[EMAIL PROTECTED]> wrote:
> 
> > Bad news.  The problem is still present in HEAD, ie., source from
> > 3 hours ago.   Even worse news is cutting down the BLAS test
> > program can be a chore.  I'll see what I can do.
> >
> > To be clear, gfortran works fine with -D '2005-02-12 22:30' sources,
> > which excludes the above commit.  The -D '2005-02-12 22:45' sources
> > include the above commit and gfortran has a serious regression.  You
> > reverted the entire commit, then re-applied what portion of the
> > commit?  ChangeLog does not reflect any of these manipulations
> > with any kind of accurate date. 
> 
> Yes, I just added a [reverted temporarily] note to the ChangeLog entry.  I
> reapplied the portion marked c++/16405, which doesn't have the [reverted]
> note on it.
> 
> I suspect that the problem is that the transformations fold_indirect_ref_1
> is doing on arrays don't mix well with how fortran handles arrays.  Could
> someone familiar with the fortran frontend take a look at that function?
> 

Well, I looked at fold_indirect_ref_1 and the gfortran source.  I
have no idea what that function does nor the code path in gfortran
source that would lead to it.

I just ran the test programs for LAPACK itself on i386-*-freebsd,
and as I suspected there are numerous regressions with its testsuite.
Until this patch is reverted or the cause of the problems with gfortran
(are ada and java also effected?) are found and fix that almost all other
development on gfortran is useless because we can't perform any
meaningful tests. 

-- 
Steve