Re: Problem with recompute_tree_invarant_for_addr_expr

[Zdenek Dvorak]

Hello,

> On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote:
> > OK, I remembered.  I put
> > 
> > if (is_gimple_min_invariant (t))
> > 
> > or
> > 
> > if (is_gimple_val (t))
> >   {
> > shortcut;
> >   }
> > 
> > type constructs on some places in gimplification.
> 
> With an aim toward speeding up gimplification, I guess.  Any idea how
> much benefit you get from that?

not really.  The problem anyway is that it does not quite work even when
the decls with variable size are taken care of, as there are other
constructions with that ADDR_EXPR gets marked TREE_INVARIANT, but that
are not gimple.

Zdenek

> As for the original question, you could try modifying tree-nested.c to
> use a local routine for creating the ADDR_EXPRs of the frame object,
> and force TREE_INVARIANT on there.

Re: A Suggestion for Release Testing

[Matthew Sachs]

On Jun 13, 2005, at 19:49, Andrew Pinski wrote:


On Jun 13, 2005, at 10:36 PM, Matthew Sachs wrote:

I've been doing regular builds of Fink against Apple's branch,  
building our last release alongside our latest engineering build  
and comparing the two.  See:

http://cvs.sourceforge.net/viewcvs.py/fink/scripts/buildfink/
http://fink.opendarwin.org/build/2005-05-08/out/report.html


Yes Matt but the FSF mainline moves much faster than Apple's branch.


And that's why someone (possibly me, ideally someone with more  
hardware to spare) should do runs against FSF mainline.

MIPS Tri-arch Question

[Jim Gifford]

I just wanted to ask a question about the tri-arch setup for MIPS under 
IRIX.


Is this planned for libraries other than IRIX based shared libraries, 
will this capability be extended to the linux shared libraries?


--

Jim Gifford
[EMAIL PROTECTED]
[EMAIL PROTECTED]

About macro: SYMBOL_REF_SMALL_P

[ibanez]

I'm trying to trace the source code of gcc/mips.
It uses a SYMBOL_REF_SMALL_P macro,
According to the index of 'GNU Compiler Collection Internals',
it should be documented on section RTL representation-Access to Special
Operands but it's not.
How can I find it's document?

My english is very poor.
thank you for your reading :)



***Notification  of Sunplus Email Domain Change ***
Please kindly be informed that Sunplus  email domain will be changed from 
SUNPLUS.COM.TW to SUNPLUS.COM effective on 2005/7/1.
*

Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Andrew Haley]

Stuart Hastings writes:
 > Subject says it all.
 > 
 > IIUC, the SSE intrinsics are made available as functions because  
 > that's the least-broken way to support them in a target-agnostic  
 > compiler.  They're clearly intended to be fully inlined in normal  
 > usage.  And they're marked "inline," but not "always_inline."
 > 
 > Why?
 > 
 > Perhaps there's a usage model I'm unfamiliar with, where these are  
 > best left as callable (breakpoint-able?) functions.  But most usage  
 > I've seen is inside hand-crafted, time-critical loops, where the  
 > programmer wants the XYZ vector operation, and really doesn't want to  
 > see or know about the function body wrapper hiding a builtin.
 > 
 > I've received lots of ... comments about this here at Apple :-) .   
 > The latest suggests we return to a macro-based implementation because  
 > it avoids the step-into-intrinsicA-step-into-intrinsicB mental gear- 
 > changing as GDB faithfully follows the debug info.

You have the same problem with Java -- you're stepping through a Java
program, and all of a sudden you're inside the memory allocator.  What
we _really_ need is some way to tell gdb "I'm debugging my own
program, not the library" or somesuch.  Or, and this is less
desirable, some way to persuade gcc not to output debug info inside
some inlined functions, although I can't image how a priori you'd
decide which ones.

But macros are a Bad Thing for all kinds of reasons, and going from
inlines to macros is a major step backwards just to get rid of debug
information!

Andrew.

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Jan Hubicka]

> On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> > Or, if GAS can be told which mode it should be in via directives in
> > its input (.code32/.code64?), then we could add something like
> > 
> >  fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", 
> > asm_out_file);
> > 
> > to x86_file_start, and kill the spec hackery altogether.
> 
> I'm a fan of such directives.  I suspect that we'll have to keep
> the spec hackery for a while yet.  We don't usually force binutils
> upgrades with compiler upgrades...

Putting .code64 directive in the assembly file and compiling with gas
defualting to 32bit would result in 32bit elf image containing 64bit
assembly encoding (and will die horribly once we hit missing
relocations)

Honza
> 
> 
> r~

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Jan Hubicka]

> Richard Henderson <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> >> Or, if GAS can be told which mode it should be in via directives in
> >> its input (.code32/.code64?), then we could add something like
> >> 
> >>  fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", 
> >> asm_out_file);
> >> 
> >> to x86_file_start, and kill the spec hackery altogether.
> >
> > I'm a fan of such directives.  I suspect that we'll have to keep
> > the spec hackery for a while yet.  We don't usually force binutils
> > upgrades with compiler upgrades...
> 
> So I take it that such directives do not already exist?  Darn.

They exist:
  {"code16gcc", set_16bit_gcc_code_flag, CODE_16BIT},
  {"code16", set_code_flag, CODE_16BIT},
  {"code32", set_code_flag, CODE_32BIT},
  {"code64", set_code_flag, CODE_64BIT},

but they only switch ASM encoding, not the output ELF file format as
they are intended for stuff where you really mix 32bit and 64bit code,
such as in the boot loader.

Honza
> 
> zw

Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Mark Mitchell wrote:
> I'm all for more testing -- but I have a standard rant about it being
>  easier to run tests than to fix problems.  We actually have a wealth
> of known regressions -- some pretty serious -- in Bugzilla, and
> plenty more known bugs.  Most come from real problems reported by
> real users on real code.  So, it's not like we're running out of bugs
> to fix.

That's true, but several factors frustrate people who want to fix bugs.

Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323,
which was a matter of recent discussion on this list. Some rather
respectable people (e.g., Vincent Lefèvre) consider this a bug, and have
proposed solutions. Yet here's a quote from an earlier message by
Giovanni Bajo.

GB> You are mistaken, we think GCC isn't buggy about 323 because
GB> the C/C++ standards do not tell us to do better than this. If
GB> you have higher expectations about floating point and C/C++,
GB> you should file a bugreport against the C/C++ standards.

GB> Really, we can't make everybody happy. The best we can do is
GB> to adhere the international well-known ISO/ANSI standards.

The ISO Standard doesn't prevent GCC from being *better* than specified,
does it? Are we somehow breaking ISO compliance by doing math right? Is
it so wrong to try and fix a problem that frustrates many people and
makes GCC look bad?

With the attitude shown by Giovanni, there's really no point in
submitting a patch, is there? Dozens of people have reported this
problem, potential solutions exist, but any patch is going to be ignored
because the bug isn't considered a bug by the Powers That Be.

If I were to present a patch that implements the recomendations of the
Numerical C Extensions Group, would it be accepted or rejected (on the
subject alone; ignore for the moment potential technical bugs in the
submitted code)?

Documentation for the compiler itself is woefully inadequate for someone
"new". GCC may be old-hat to folks who've worked on it for years, but it
is very complex and foreign territory for most non-compiler experts.
Working on GCC requires a much broader knowledge than working on other
projects, and without some sort of tutorial or guidance, working on it
quickly becomes frustrating.

Here's an example: Building new targets and fixing some code generation
bugs involve changing the machine definitions, which are written in a
rather uncommon language. Frankly, I haven't figured out all the nuances
yet, mostly because I don't have the luxury of studying it, and I can't
find any clear and comprehensive documentation.

Gentoo provides a mentoring system for developers. This is far better
than GCC's "fix it yourself and send us the code" policy. There is no
gentle way to become involved in GCC; it's a sink-or-swim, trial by fire
environment. If I could get a half-dozen quick questions answered, and I
could submit a couple of patches that are lying about on my hard drive.

For that matter, Gentoo also has some very excellent IRC channels that
provide a lot of help, and usually *friendly* help at that. The GCC
mailing lists are useful, but there's nowhere to go and have a quick
chat about "this is confusing the heck out of me" or "how do I approach
this problem."

I have submitted patches; I have tried to help with various aspects of
GCC. I make no claim to having accomplished anything great, but I have
tried, and watched patches die of bit rot while being told that certain
bugs shouldn't be fixed.

Everything in life is a matter of give and take. People report bugs; you
want someone to fix the bugs -- perhaps GCC should be more welcoming and
helpful.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Andrew Pinski]

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote:


For that matter, Gentoo also has some very excellent IRC channels that
provide a lot of help, and usually *friendly* help at that. The GCC
mailing lists are useful, but there's nowhere to go and have a quick
chat about "this is confusing the heck out of me" or "how do I approach
this problem."


This is wrong, there is an IRC channel which talks about technical 
issues
deal with developing GCC (not with though but that should be in an 
UNIX/C/C++

IRC channel instead).

Thanks,
Andrew Pinski

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Andrew Pinski]

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote:


Here's an example: Building new targets and fixing some code generation
bugs involve changing the machine definitions, which are written in a
rather uncommon language. Frankly, I haven't figured out all the 
nuances

yet, mostly because I don't have the luxury of studying it, and I can't
find any clear and comprehensive documentation.


No you don't need to learn a new language. You need to learn RTL which 
is a
language yes but it is based on LISP.  Also some of the recent bugs are 
on
the tree level so you just need to know GIMPLE which is really just 
simple
expressions.  So I don't see why you are complaining because code 
generation
bugs should be just reported and let the powers at be fix them.  If you 
show
that it is a regression, then it will get a higher priority, than other 
bugs.


Again I have not seen a simple bug report from you recently; just a 
simple

this goes bonkers, this is what I want GCC to output will do.

Thanks,
Andrew Pinski

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Andrew Pinski]

On Jun 14, 2005, at 10:14 AM, Scott Robert Ladd wrote:


Gentoo provides a mentoring system for developers. This is far better
than GCC's "fix it yourself and send us the code" policy. There is no
gentle way to become involved in GCC; it's a sink-or-swim, trial by 
fire
environment. If I could get a half-dozen quick questions answered, and 
I

could submit a couple of patches that are lying about on my hard drive.


We don't do that, we request the source of the failing source and most 
of

the time say how to fix the original code if it was invalid code.

I have not seen one recent bug report from you so I don't understand why
you are complaining!

Thanks,
Andrew P

Porposal: Floating-Point Options

[Scott Robert Ladd]

To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.

-ffp-correct

This option focuses code generation on mathematical correctness,
portability, and consistency. No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason. Note that
this option can only go so far in ensuring portability, given that not
every system supports IEEE 754 floats.

-ffp-ieee754

To the best of our ability, assume and follow IEEE 754. Similar to the
above, but assuming IEEE floats and doubles. Note that IEEE 754 has been
undergoing some revision.

-ffp-balanced (default)

Balance correctness with speed, enabling performance optimizations that
may reduce portability or consistency, but which do not alter the
overall quality of results. Yeah, I know that's a bit fuzzy; formal
definition of such an option depends on categorizing existing FP code
generation (something I'm working on).

-ffp-damn-the-torpedoes-full-speed-ahead

Okay, maybe that should be something shorter, like -ffast-math or
-ffp-fast. This option enables dangerous hardware intrinsics, and
eschews all concerns about portability and consistency in the quest for
speed. The behavior is likely to be the same as the current -ffast-math.

Actually, I like *-ffp-damn-the-torpedoes-full-speed-ahead*. As
Stroustrup once said, if you're going to do somethimg ugly, it should
look ugly. ;)

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Andrew Pinski wrote:
> This is wrong, there is an IRC channel which talks about technical issues
> deal with developing GCC (not with though but that should be in an
> UNIX/C/C++ IRC channel instead).

Where?

A Google search on "GCC IRC" doesn't find much, and the few times I've
visited #gcc on FreeNode, it's been silent.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Andrew Pinski]

On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote:


Andrew Pinski wrote:
This is wrong, there is an IRC channel which talks about technical 
issues

deal with developing GCC (not with though but that should be in an
UNIX/C/C++ IRC channel instead).


Where?

A Google search on "GCC IRC" doesn't find much, and the few times I've
visited #gcc on FreeNode, it's been silent.


FreeNode is not the only IRC server.  irc.oftc.net is where #gcc is 
hosted.


-- Pinski

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Joseph S. Myers]

On Tue, 14 Jun 2005, Scott Robert Ladd wrote:

> If I were to present a patch that implements the recomendations of the
> Numerical C Extensions Group, would it be accepted or rejected (on the
> subject alone; ignore for the moment potential technical bugs in the
> submitted code)?

I don't know to what recommendations you refer (please give a URL).  I 
would consider a patch resolving issue 323 by implementing the C90/C99 
standard requirements for how excess precision works to be desirable.  
That is, excess precision should be explicitly modeled throughout the 
compiler (rather than the x86 back end pretending it can operate on float 
and double); not just assignments but also casts and function call and 
return should discard excess precision (including cast from a type to 
itself, etc.; and see also DR#318); and arithmetic on constants should use 
excess precision the same way as at runtime; this should all be enabled by 
-ansi / -std=c89 / -std=c99 and disabled by -fno-float-store.  This would 
allow predictable operation in accordance with the standards on processors 
where excess precision is natural.

I think changing the default precision must be a matter for -m options; 
these would also affect the ABI by changing the size of long double and 
libraries written to use long double in computations of functions for 
double would cease to work with a different precision.

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

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Andrew Pinski wrote:
>
> No you don't need to learn a new language. You need to learn RTL which is a
> language yes but it is based on LISP.  Also some of the recent bugs are on
> the tree level so you just need to know GIMPLE which is really just simple
> expressions.  So I don't see why you are complaining because code
> generation bugs should be just reported and let the powers at be fix them.

Didn't Mark just complain that people should spend more time fixing bugs
than expecting others to do it for them? Mark complains that we already
have too many unresolved bugs, and I tend to agree. If the current
developers are so busy, it seems logical that we need more developers,
not bug reporters. Wasn;t that the gist of Mark's polite rant?

And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as
well. I'm not saying that expectation is wrong, I am saying it is an
impediment to working on GCC.

In many ways, I see GCC as similar in model to the Red Cross. You have a
paid staff that handles the day-to-day business, and a horde of
volunteers who do much of the grunt work. The Red Cross provides
training and mentoring to bring people along. GCC and other free
software projects would do well to consider how non-technical volunteer
organizations succeed.

If there is a lack of people fixing bugs, don;t necessarily blame it on
people being lazy. Maybe being a volunteer GCC developer is more
difficult than it needs to be?

> Again I have not seen a simple bug report from you recently; just a simple
> this goes bonkers, this is what I want GCC to output will do.

I haven't filed many bug reports recently (though I have in the past)
because I didn't feel that the effort was justified by the result.

Not that I've given up entirely: I've recently asked about how certain
problems should be reported. For example, -floop-optimize2 is a
pessimism for many algorithms. Is that a bug, or simply a feature that
is not yet fully implemented?

..Scott

Re: Porposal: Floating-Point Options

[Robert Dewar]

Scott Robert Ladd wrote:

To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.

-ffp-correct

This option focuses code generation on mathematical correctness,
portability, and consistency. No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason. Note that
this option can only go so far in ensuring portability, given that not
every system supports IEEE 754 floats.


It is wrong, confusing, and provocative to call this correct, since
there is no justification for using this term, and it implies that
the current behavior of gcc is incorrect, which is not the case.
Choosing a good name for this is in fact not so easy


-ffp-ieee754

To the best of our ability, assume and follow IEEE 754. Similar to the
above, but assuming IEEE floats and doubles. Note that IEEE 754 has been
undergoing some revision.


754 (these days you really mean 854 or the corresponding ISO standard I
think) has little to say about mapping to high level languages, so it is
important to understand that appealing to this standard is necessary
but far from efficient.

Note that this could have disastrous effects on efficiency on the x86,
since it would require something similar to -fstore-float, since you
have to check range as well as precision to be strict IEEE.

For most people, the issue is avoiding the use of IEEE extended, and
mapping the precision as expected. Most people don't care if they get
the extended range that will fall out naturally. This gives a mode of
operation that has little or no speed penalty, unlike the full IEEE
adherence.


-ffp-balanced (default)

Balance correctness with speed, enabling performance optimizations that
may reduce portability or consistency, but which do not alter the
overall quality of results. Yeah, I know that's a bit fuzzy; formal
definition of such an option depends on categorizing existing FP code
generation (something I'm working on).


I would say this should be -ffp-standard, since it corresonds to normal
correct implementation of the C standard. I find the fuzziness you attempt
to introduce to be confusing here.


-ffp-damn-the-torpedoes-full-speed-ahead

Okay, maybe that should be something shorter, like -ffast-math or
-ffp-fast. This option enables dangerous hardware intrinsics, and
eschews all concerns about portability and consistency in the quest for
speed. The behavior is likely to be the same as the current -ffast-math.


You don't want to be too negative in choosing a name for this. fast-math
is quite fine. There are many people who are never going to do careful
error analysis on their fp code, and for whom fp is simply a crude
approximation of real arithmetic, and just how approximate it is,
they don't know and don't care much.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Andrew Pinski wrote:
> FreeNode is not the only IRC server.  irc.oftc.net is where #gcc is hosted.

You are ebing positively rude. Just because I mention FreeNode doesn't
mean I'm so ignorant as to be unaware of other servers.

Where is irc.oftc.net #gcc above documented?

..Scott

Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Daniel Jacobowitz]

[Redirecting off the misnamed gdb-discuss list; please use
[EMAIL PROTECTED] instead.]

On Tue, Jun 14, 2005 at 10:22:23AM +0100, Andrew Haley wrote:
> You have the same problem with Java -- you're stepping through a Java
> program, and all of a sudden you're inside the memory allocator.  What
> we _really_ need is some way to tell gdb "I'm debugging my own
> program, not the library" or somesuch.  Or, and this is less
> desirable, some way to persuade gcc not to output debug info inside
> some inlined functions, although I can't image how a priori you'd
> decide which ones.

It'd be better to handle this in gdb than in gcc, sure.  There's two
parts: better support for inline functions, which is already on the gdb
roadmap, and then some way of selecting which ones to ignore.  And for
that latter, I have no idea how it should look...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Diego Novillo]

On Tue, Jun 14, 2005 at 10:38:47AM -0400, Andrew Pinski wrote:
> 
> On Jun 14, 2005, at 10:34 AM, Scott Robert Ladd wrote:
> 
> >Andrew Pinski wrote:
> >>This is wrong, there is an IRC channel which talks about technical 
> >>issues
> >>deal with developing GCC (not with though but that should be in an
> >>UNIX/C/C++ IRC channel instead).
> >
> >Where?
> >
> >A Google search on "GCC IRC" doesn't find much, and the few times I've
> >visited #gcc on FreeNode, it's been silent.
> 
> FreeNode is not the only IRC server.  irc.oftc.net is where #gcc is 
> hosted.
> 
Now added to the wiki.


Diego.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Robert Dewar]

Scott Robert Ladd wrote:
 the gist of Mark's polite rant?


And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as
well. I'm not saying that expectation is wrong, I am saying it is an
impediment to working on GCC.


with respect, I disagree, and I think you should invest the effort
before you hazard an opinion here. Compilers are complex beasts, and
all involve intermediate languages, and of course these intermediate
languages must be learned before you can do anything.


If there is a lack of people fixing bugs, don;t necessarily blame it on
people being lazy. Maybe being a volunteer GCC developer is more
difficult than it needs to be?


I think a lot of what happens is that easy bugs do get fixed. The ones
that don't are often complex, or ill-reported, and thus tend to require
a lot of knowledge to work on effectively.


I haven't filed many bug reports recently (though I have in the past)
because I didn't feel that the effort was justified by the result.

Not that I've given up entirely: I've recently asked about how certain
problems should be reported. For example, -floop-optimize2 is a
pessimism for many algorithms. Is that a bug, or simply a feature that
is not yet fully implemented?


This is a good example of something that likely can only be effectively
worked on by someone with a considerable amount of gcc knowledge.

Re: Porposal: Floating-Point Options

[Vincent Lefevre]

On 2005-06-14 10:32:57 -0400, Scott Robert Ladd wrote:
> To support different expectations, I suggest defining the following
> floating-point options for GCC. This is a conceptual overview; once
> there's a consensus the categories, I'll propose something more formal.
> 
> -ffp-correct
> 
> This option focuses code generation on mathematical correctness,
> portability, and consistency. No 80-bit long doubles, no fsin/fcos,
> making certain that comparison operators work within reason. Note that
> this option can only go so far in ensuring portability, given that not
> every system supports IEEE 754 floats.

Why no 80-bit long doubles if this has no effect on doubles?
And what about doubles? Remember that there are two problems:
one related to the internal precision and one related to the
type (precision and range).

I don't like the word "correct" here, since the correctness
depends very much on the context. Some applications may just
need a conforming C implementation, others just need an IEEE-754
conforming implementation, and others something stricter (e.g.
Java and related languages, which need more or less strict IEEE
double precision).

> -ffp-ieee754
> 
> To the best of our ability, assume and follow IEEE 754. Similar to
> the above, but assuming IEEE floats and doubles. Note that IEEE 754
> has been undergoing some revision.

This isn't clear. Also note that IEEE 754 allows extended precision.

> -ffp-balanced (default)
> 
> Balance correctness with speed, enabling performance optimizations that
> may reduce portability or consistency, but which do not alter the
> overall quality of results. Yeah, I know that's a bit fuzzy; formal
> definition of such an option depends on categorizing existing FP code
> generation (something I'm working on).

I disagree. The default should be a conforming C99 implementation.
Users who want speed should either use options that would produce
non-conforming code or use a processor that allows faster generated
code (e.g. a non-x86 one or one with SSE2 instructions).

> -ffp-damn-the-torpedoes-full-speed-ahead
> 
> Okay, maybe that should be something shorter, like -ffast-math or
> -ffp-fast. This option enables dangerous hardware intrinsics, and
> eschews all concerns about portability and consistency in the quest
> for speed. The behavior is likely to be the same as the current
> -ffast-math.

I think it would be simpler to think about individual compiler
"behaviors" related to floating-point code generation and group
them into classes later. I've said "behaviors", not "options",
since pragmas (standard or not) could be used to get different
behaviors.

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

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

[Daniel Jacobowitz]

On Tue, Jun 14, 2005 at 01:36:13PM +0200, Jan Hubicka wrote:
> They exist:
>   {"code16gcc", set_16bit_gcc_code_flag, CODE_16BIT},
>   {"code16", set_code_flag, CODE_16BIT},
>   {"code32", set_code_flag, CODE_32BIT},
>   {"code64", set_code_flag, CODE_64BIT},
> 
> but they only switch ASM encoding, not the output ELF file format as
> they are intended for stuff where you really mix 32bit and 64bit code,
> such as in the boot loader.

So, we would need different directives for this purpose.  I like the
idea, though it wouldn't help me in the short term.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Robert Dewar]

Scott Robert Ladd wrote:


The ISO Standard doesn't prevent GCC from being *better* than specified,
does it? Are we somehow breaking ISO compliance by doing math right? Is
it so wrong to try and fix a problem that frustrates many people and
makes GCC look bad?


No, but you are degrading performance unnecessarily by doing math to
conform to the Scott-Ladd standard, and we are not implementing SL C
we are implementing ISO C :-)

Of course it is perfectly reasonable to have well chosen options to
do more or less than the standard requires.


With the attitude shown by Giovanni, there's really no point in
submitting a patch, is there? Dozens of people have reported this
problem, potential solutions exist, but any patch is going to be ignored
because the bug isn't considered a bug by the Powers That Be.


It would be quite wrong to patch this unconditionally. The proper
patch would be one that provided a switch and a well defined semantics
for the switch, but this needs very careful design, and careful
review by people who understand fpt well.


If I were to present a patch that implements the recomendations of the
Numerical C Extensions Group, would it be accepted or rejected (on the
subject alone; ignore for the moment potential technical bugs in the
submitted code)?


Again, it would probably be better submitted under a switch. For
example on a machine like the Alpha, the impact of following these
recomendations is severe degradation of performance.


Documentation for the compiler itself is woefully inadequate for someone
"new". GCC may be old-hat to folks who've worked on it for years, but it
is very complex and foreign territory for most non-compiler experts.
Working on GCC requires a much broader knowledge than working on other
projects, and without some sort of tutorial or guidance, working on it
quickly becomes frustrating.


Compilers are complex beasts, I don't think you would expect to be able
to wade in and fix nuclear reactors without being somewhat of a nuclear
reactor expert. You can't expect to wade in and fix compilers without
being reasonably compiler literate. For those who are compiler literate,
GCC is certainly accessible. Sure, it could be made more accessible,
principally by adding more documentation. Patches to add correct useful
additional documentation are definitely welcome.


Here's an example: Building new targets and fixing some code generation
bugs involve changing the machine definitions, which are written in a
rather uncommon language. Frankly, I haven't figured out all the nuances
yet, mostly because I don't have the luxury of studying it, and I can't
find any clear and comprehensive documentation.


These definitions are actually very clear, certainly they could not
be written in some normal programming language since they are essentially
denotational semantic definitions, for which a language like C would be
perfectly horrible. You need to invest the effort to fully understand
the machine definition language before you can do anything in this
area, and it is hard to see how it could be otherwise.


Gentoo provides a mentoring system for developers. This is far better
than GCC's "fix it yourself and send us the code" policy. There is no
gentle way to become involved in GCC; it's a sink-or-swim, trial by fire
environment. If I could get a half-dozen quick questions answered, and I
could submit a couple of patches that are lying about on my hard drive.


There is no gentle way to become involved in any compiler, they are complex
beasts, and require a considerable investment of effort.


I have submitted patches; I have tried to help with various aspects of
GCC. I make no claim to having accomplished anything great, but I have
tried, and watched patches die of bit rot while being told that certain
bugs shouldn't be fixed.


I know of no bug (i.e. behavior non-conformant with ISO C) that someone
has said should not be fixed.


Everything in life is a matter of give and take. People report bugs; you
want someone to fix the bugs -- perhaps GCC should be more welcoming and
helpful.


ANything to make it more welcoming and helpful is of course desirable, but
I think you are expecting too much if you expect an artifact of this
inherent complexity to be easily accessible, especially to people without
reasonably comprehensive training (i.e. at least a familiarity with compilers
at the dragon book level, and reading some of the crucial papers in the area).

Re: Porposal: Floating-Point Options

[Vincent Lefevre]

On 2005-06-14 10:52:53 -0400, Robert Dewar wrote:
> Scott Robert Ladd wrote:
> >-ffp-correct
> >
> >This option focuses code generation on mathematical correctness,
> >portability, and consistency. No 80-bit long doubles, no fsin/fcos,
> >making certain that comparison operators work within reason. Note that
> >this option can only go so far in ensuring portability, given that not
> >every system supports IEEE 754 floats.
> 
> It is wrong, confusing, and provocative to call this correct, since
> there is no justification for using this term,

I agree with you on this point.

> and it implies that the current behavior of gcc is incorrect, which
> is not the case.

The current behavior of gcc is really incorrect, even if you blame
the design of the processor. And if you think that you don't want
to conform to the ISO C99 standard, then __STDC__ / __STDC_VERSION__
shouldn't be defined as indicating a conforming implementation.

> >-ffp-ieee754
> >
> >To the best of our ability, assume and follow IEEE 754. Similar to the
> >above, but assuming IEEE floats and doubles. Note that IEEE 754 has been
> >undergoing some revision.
> 
> 754 (these days you really mean 854 or the corresponding ISO
> standard I think)

No, not 854.

> has little to say about mapping to high level languages, so it is
> important to understand that appealing to this standard is necessary
> but far from efficient.

Why not efficient?

> Note that this could have disastrous effects on efficiency on the x86,
> since it would require something similar to -fstore-float, since you
> have to check range as well as precision to be strict IEEE.

IEEE 754 doesn't require that (unless by "strict" you mean no
extended precision anywhere). However the C standard does after
a cast or assignment.

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

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Robert Dewar wrote:
> Scott Robert Ladd wrote:
>> And to fix bugs, I'm expected to learn a variation on Lisp and GIMPLE as
>> well. I'm not saying that expectation is wrong, I am saying it is an
>> impediment to working on GCC.
> 
> with respect, I disagree, and I think you should invest the effort
> before you hazard an opinion here. Compilers are complex beasts, and
> all involve intermediate languages, and of course these intermediate
> languages must be learned before you can do anything.

Testing and bug reporting are ways people can contribute to GCC if they
haven't the time or knowledge to effect repairs themselves.

GCC isn't special; all areas of specialized knowledge have steep
learning curves, and I'm certain I could find applications that would
mystify GCC's illuminati.

Lowering the learning curve would bring in more GCC developers and get
bugs fixed faster. I know quite a few very bright people who find GCC's
current documentation inadquate and opaque, and the environment less
than inviting.

..Scott

copyright assignment

[Rafael Espíndola]

I am doing some work on a frontend for gcc. In the process I expect to
clean up treelang a little bit. Could you send me the relevant forms?
Thanks.

Rafael Ávila de Espíndola

Re: copyright assignment

[James A. Morrison]

 The form is here:
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html

 If you have any questions feel free to ask.


-- 
Thanks,
Jim

http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Robert Dewar wrote:
>> If I were to present a patch that implements the recomendations of the
>> Numerical C Extensions Group, would it be accepted or rejected (on the
>> subject alone; ignore for the moment potential technical bugs in the
>> submitted code)?

> Again, it would probably be better submitted under a switch. For
> example on a machine like the Alpha, the impact of following these
> recomendations is severe degradation of performance.

Agreed. I never said it should be a default option.

> Compilers are complex beasts, I don't think you would expect to be able
> to wade in and fix nuclear reactors without being somewhat of a nuclear
> reactor expert. You can't expect to wade in and fix compilers without
> being reasonably compiler literate. For those who are compiler literate,
> GCC is certainly accessible. Sure, it could be made more accessible,
> principally by adding more documentation. Patches to add correct useful
> additional documentation are definitely welcome.

That is exactly my point. Mark chastises people for talking about
testing, implying that we are lazy for not providing patches. Perhaps
some of us wish to contribute to GCC, but lacking the knowledge to patch
the compiler, we perform testing and make bug reports.

> These definitions are actually very clear, certainly they could not
> be written in some normal programming language since they are essentially
> denotational semantic definitions, for which a language like C would be
> perfectly horrible. You need to invest the effort to fully understand
> the machine definition language before you can do anything in this
> area, and it is hard to see how it could be otherwise.

Clear to you, but not to many other bright people. And I have *never*
said there is no requirement for learning, or even criticized the
language of the machine definition files. I am saying that Mark can't
complain about a lack of bug-fixers when big-fixing is non-trivial
(which I believe agrees with your point.)

> There is no gentle way to become involved in any compiler, they are complex
> beasts, and require a considerable investment of effort.

Nope. Gentleness comes in many forms, and includes being polite to
newbies, not condescending. Providing mentors to work with people on
specific questions would do wonders for teaching GCC internals.

> I know of no bug (i.e. behavior non-conformant with ISO C) that someone
> has said should not be fixed.

No, what they do is redefine the bug such that it is no longer a bug.
Certain U.S. Presidents are quite fond of this tactic, recategorizing
things to avoid dealing with them. Bug 323 is an example of how GCC does
this.

> ANything to make it more welcoming and helpful is of course desirable, but
> I think you are expecting too much if you expect an artifact of this
> inherent complexity to be easily accessible, especially to people without
> reasonably comprehensive training (i.e. at least a familiarity with
> compilers > at the dragon book level, and reading some of the crucial papers 
> in the
> area).

I don't deny that reality. Mark seems to feel that fixing bugs is as
easy as testing and bug reporting, and it is not. Yet people then
complain that people don't file enough bugs! It seems that no matter
what someone "outside" tries to contribute, it isn't "right".

If you want more people fixing bugs, it requires patience and respect.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Mark Mitchell]

Scott Robert Ladd wrote:


That is exactly my point. Mark chastises people for talking about
testing, implying that we are lazy for not providing patches.



I don't deny that reality. Mark seems to feel that fixing bugs is as
easy as testing and bug reporting, and it is not. 


Actually, I don't agree with either of the statements ascribed to me, 
and if I conveyed that sentiment, I apologize.  To be clear, I think 
testing, automated and otherwise, and bug reporting, and bug-mastering 
are all very valuable.  My point was simply that once you have the tests 
and bug reports, someone has to fix the bugs before the users see benefit.


CodeSourcery struggles with exactly the same problem; we have worked 
hard to set up some test automation for our ARM builds, and it's working 
well, but we're not (yet!) as disciplined as we want to be about 
analyzing and fixing the failures.  I think the reason is that the 
testing is something you work hard to set up once, and then, roughly 
speaking, you just sit back and let the computer work hard forever; the 
analysis/fixing is an ongoing project that requires people to work hard 
on a regular basis.


Once I get my automated GCC bug-fixing bot finished I am going to have 
an easy life.  Unfortunately, I use GCC to build the bot, and I'm 
getting an ICE in reload...


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Diego Novillo]

On Tue, Jun 14, 2005 at 09:01:04AM -0700, Mark Mitchell wrote:

> Once I get my automated GCC bug-fixing bot finished I am going to have 
> an easy life.  Unfortunately, I use GCC to build the bot, and I'm 
> getting an ICE in reload...
> 
I have a patch for that.  I'm sure the napking I wrote it on was
somewhere around here...

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Mark Mitchell wrote:
> Actually, I don't agree with either of the statements ascribed to me,
> and if I conveyed that sentiment, I apologize.

And I apologize for perhaps reading more into your statements than was
intended.

> My point was simply that once you have the tests
> and bug reports, someone has to fix the bugs before the users see benefit.

I wish I could do more, which is why I made (what I hoped were)
constructive suggestions for trying to get more people involved in
fixing bugs.

True, there are many lazy people who don't want to learn anything. I'm
more interested in attracting the people who, like myself, simply need
help getting around the more obscure corners of GCC. I still think that
Gentoo-style mentoring could be successful.

> Once I get my automated GCC bug-fixing bot finished I am going to have
> an easy life.  Unfortunately, I use GCC to build the bot, and I'm
> getting an ICE in reload...

Such software would make you rich beyond the dreams of avarice.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Richard Guenther]

On 6/14/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:

> I wish I could do more, which is why I made (what I hoped were)
> constructive suggestions for trying to get more people involved in
> fixing bugs.

For getting more people involved in fixing bugs they need those
bugs in plain C code (read: a testcase) presented to them, preferrably
with a (short) description what and why it is going wrong.

Useful suggestions about what one could do tend to be ignored or
end in endless back-and-forth mailings like this.  Especially if the
discussion is about such broad field as FP correctness.

It may also help to have bugs collected beyond a meta-bug
(such as 323 seems to be).

Also GCC is not the only player involved here, but glibc is as
well.

Take a break and come back with results of actual work done,
this impresses people a lot more than (repeated) ranting about
gcc development in general.

Richard.

Re: copyright assignment

[Florian Weimer]

* James A. Morrison:

>  The form is here:
> http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
>
>  If you have any questions feel free to ask.

It's better to request the current version from the FSF, see:

Re: Porposal: Floating-Point Options

[Russell Shaw]

Robert Dewar wrote:

Scott Robert Ladd wrote:


To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.

-ffp-correct

This option focuses code generation on mathematical correctness,
portability, and consistency. No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason. Note that
this option can only go so far in ensuring portability, given that not
every system supports IEEE 754 floats.


It is wrong, confusing, and provocative to call this correct, since
there is no justification for using this term, and it implies that
the current behavior of gcc is incorrect, which is not the case.
Choosing a good name for this is in fact not so easy


...

The original bug was about testing the equality of doubles. I think that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documentation.

RE: strange double comparison results with -O[12] on x86(-32)

[Dave Korn]

Original Message
>From: Robert Dewar
>Sent: 14 June 2005 00:41

> Dave Korn wrote:
> 
>>   ... or it's a bug in the libc/crt-startup, which is where the hardware
>> rounding mode is (or should be) set up ...
> 
> Well if you think that the operations should reflect IEEE 64-bit semantics
> (which is the only rationale for mucking with the rounding mode in the
> startup), then this is only an approximate fix, since the intermediate
> values still have excessive range, so you don't get infinities when
> expected.


  As it happens, I wrote 'rounding mode' when I meant to say 'hardware
precision setting'.


  Knowing my luck, I don't suppose this makes my statement any more correct,
but it may at least make it differently wrong! :)


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

Re: Porposal: Floating-Point Options

[Scott Robert Ladd]

Vincent Lefevre wrote:
> I don't like the word "correct" here, since the correctness
> depends very much on the context.

Good point.

> I disagree. The default should be a conforming C99 implementation.

I suppose I need to be consistent... ;) I've said in past threads, GCC
should default to -ansi -std=c99/c++98 -pedantic, and any deviation
should require specification of an option.

I have offered to make such a patch (in fact, I have one sitting
around), but the response was somewhat tepid.

> I think it would be simpler to think about individual compiler
> "behaviors" related to floating-point code generation and group
> them into classes later. I've said "behaviors", not "options",
> since pragmas (standard or not) could be used to get different
> behaviors.

Okay, the light went on. Must be the lingering effects of anaesthesia. :)

I need to do some thinking and studying.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Richard Guenther wrote:
> Take a break and come back with results of actual work done,
> this impresses people a lot more than (repeated) ranting about
> gcc development in general.

I have worked on GCC; not much, and probably trivial in your eyes,
but practical work nonetheless. To trivialize contributions is a great
way of driving away potential contributors.

I would like to improve floating-point in GCC; doing so scratches my
personal itch. My silly idea is to determine the best approach
*through discussion*.

..Scott

Re: Porposal: Floating-Point Options

[Russell Shaw]

Robert Dewar wrote:

Scott Robert Ladd wrote:


To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.

-ffp-correct

This option focuses code generation on mathematical correctness,
portability, and consistency. No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason. Note that
this option can only go so far in ensuring portability, given that not
every system supports IEEE 754 floats.


It is wrong, confusing, and provocative to call this correct, since
there is no justification for using this term, and it implies that
the current behavior of gcc is incorrect, which is not the case.
Choosing a good name for this is in fact not so easy


...

The original bug was about testing the equality of doubles. I think that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documentation.

OTOH, maybe the equality operators should discard the excess precision, so
effectively implementing the error band anyway. Can't say more without reading
the relevant standards. If the equality operators did this, then it shouldn't
slow down any non-equality operators or anything else.

Re: Porposal: Floating-Point Options

[Vincent Lefevre]

On 2005-06-14 13:37:41 -0400, Scott Robert Ladd wrote:
> I suppose I need to be consistent... ;) I've said in past threads,
> GCC should default to -ansi -std=c99/c++98 -pedantic, and any
> deviation should require specification of an option.

You're not consistent here.

[from the gcc 4.0 man page]
  -std=
  Determine the language standard.  This option is currently only
  supported when compiling C or C++.  A value for this option must be
  provided; possible values are

  c89
  iso9899:1990
  ISO C90 (same as -ansi).

What you want is -std=c99/c++98 -pedantic.

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

Re: A Suggestion for Release Testing

[Devang Patel]

On Jun 14, 2005, at 1:01 AM, Matthew Sachs wrote:

And that's why someone (possibly me, ideally someone with more  
hardware to spare) should do runs against FSF mainline.


One thing to watch out is the APPLE LOCAL patches in back-end/code  
gen area, particularly related to alignment and other ABI issues. It  
may skew your results.


-
Devang

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[chris jefferson]

Scott Robert Ladd wrote:


Richard Guenther wrote:
 


Take a break and come back with results of actual work done,
this impresses people a lot more than (repeated) ranting about
gcc development in general.
   



I have worked on GCC; not much, and probably trivial in your eyes,
but practical work nonetheless. To trivialize contributions is a great
way of driving away potential contributors.

I would like to improve floating-point in GCC; doing so scratches my
personal itch. My silly idea is to determine the best approach
*through discussion*.

 

One thing I have come across, both in gcc and in other projects, is that 
often discussion is not the best option, but instead just writing some 
code is better.


It's very easy to have discussions go around in circles about if option 
a or option b is better, and which will lead to slowdowns, or intrusive 
changes, or whatever. It's very hard to know how well something will 
actually work, and if it will be possible, until it's actually been 
written. While it's briefly annoying to write code which then isn't used 
the first time you do it, I've quickly learned it's faster and easier 
than extensive discussions, and most good code will go through 3 or 4 
iterations before it finally settles, and need a whole bundle of tests 
writing, so writing an initial test version is not actually that big a 
time investment compared to the total amount of time something will 
take. Working code is also of course by far the most convincing argument 
:).


I have 4 completely different implementations of std::tr1::tuple lying 
around somewhere, obviously only one was actually used, but the only 
real way to know which would be best was to just write them and see how 
they looked and worked.


Chris

Re: MIPS Tri-arch Question

[Eric Christopher]

On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote:
> I just wanted to ask a question about the tri-arch setup for MIPS under 
> IRIX.
> 
> Is this planned for libraries other than IRIX based shared libraries, 
> will this capability be extended to the linux shared libraries?
> 
Short answer: it already has been.

Long answer:
Look at gcc/config/mips/linux64.h.

-eric

Re: Problems with collect2 on hpux

[Warren_Baird]

"John David Anglin" <[EMAIL PROTECTED]> wrote on 06/11/2005 12:39:32
PM:

> As far as I'm aware, collect2 doesn't strip linker options.  You can
> see more details about the link process using -Wl,-debug and -Wl,-v.

Nope - you are right - collect2 was a red-herring.

> It's not very nice that the shared library list for libstdc++.sl
> includes libgcc_s.sl in the GCC build directory.  I believe that the
> HP dynamic loader first looks for it there.  If that doesn't work,
> it strips off the basename of the library and tries the dynamic
> search path.

Yeah, I had to fix that problem first by going into the libstdc++ dir, and
doing a "make clean ; make LDFLAGS=-Wl,+s"

Wouldn't it make sense to do this by default?  Should I submit a patch to
do that?

> The above is an example why executables and shared libraries need
> to be relinked when installed on this target.  The problem with
> libgcc_s.sl is that it isn't a "libtool" library.  As a result,
> libtool doesn't know how to properly generate the dependencies for the
> link used during installation (i.e., generate the correct sequence
> of -L options).

It's not clear to me why relinking is required, if the -Wl,+s flag is used
everywhere...

I took a closer look at my libraries with chatr, and determined that the
problem was a thirdparty lib we were using that wasn't getting compiled
with -Wl,+s - and to make matters worse, was explicitly adding the full
path to libstdc++ on the link line - once I resolved those problems the
troubles went away.

Thanks for your help.

Warren

Build success for gcc 3.4.4 on alphaev68-dec-osf5.1 (CompaqTru64UNIX)

[Stefano Curtarolo, Ph.D.]

HP-Compaq ES45
Successful build of 3.4.3 for alphaev68-dec-osf5.1 (c,c++,f77,objc,ada).

[EMAIL PROTECTED]:#gcc -v

Reading specs from /usr/local/lib/gcc/alphaev68-dec-osf5.1/3.4.4/specs
Configured with: ./configure
--host=alphaev68-dec-osf5.1
--prefix=/usr/local
--enable-languages=c,c++,f77,objc,ada
--enable-version-specific-runtime-libs
--enable-shared
--enable-libgcj
--with-gc=simple
--enable-nls
--enable-interpreter
Thread model: posix
gcc version 3.4.4



Sincerely,
Stefano Curtarolo


--
Prof. Stefano Curtarolo
Assistant Professor of Materials Science
Duke University, Dept. Mechanical Engineering and Materials Science
144 Hudson Hall, Box 90300, Durham, NC  27708-0300
phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu
--

The chief enemy of creativity is "good" sense
-- Picasso

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

chris jefferson wrote:
> One thing I have come across, both in gcc and in other projects, is that
> often discussion is not the best option, but instead just writing some
> code is better.

There's a fine line between too much talk and not enough.

> It's very easy to have discussions go around in circles about if option
> a or option b is better, and which will lead to slowdowns, or intrusive
> changes, or whatever.

I'm more interested in "Does doing A make any sense?"

An example: In its formative stages, gfortran had a problem with certain
kinds of constants. Whether the problem needed to be solved depending on
how strictly one read the standard.

I simply went ahead and wrote a patch (actually, three of them), trying
to satisfy all sides involved. This resulted in long discussions of
whether the problem really *was* a problem or not. In the end, the
compiler was modified to behave as other Fortran 95s do (which was my
original suggestion, before people started quoting the standard), and I
wasted much of the time spent writing the original patch.

Had the problem been talked out in the beginning, I could have spent
more time working on an acceptable solution. This is one incident that
lead me to stop submitting patches; I have only so much time for GCC,
and am donating all of it out of my own pocket. Maybe others can afford
to do that, but I can't, after three months in the hospital followed by
an injury to my wife. If I'm going to contribute to GCC, it needs to be
something I know will be more than just a shot in the dark.

> While it's briefly annoying to write code which then isn't used
> the first time you do it, I've quickly learned it's faster and easier
> than extensive discussions, and most good code will go through 3 or 4
> iterations before it finally settles, and need a whole bundle of tests
> writing, so writing an initial test version is not actually that big a
> time investment compared to the total amount of time something will
> take. Working code is also of course by far the most convincing argument
> :).

Perhaps I'm too steeped in being an engineer, but in my experience,
quality upfront discussion saves a lot of time and produces better
results. I'd hate to build a bridge the way you suggest developing GCC.

..Scott

Re: MIPS Tri-arch Question

[Jim Gifford]

Eric Christopher wrote:


On Tue, 2005-06-14 at 01:04 -0700, Jim Gifford wrote:
 

I just wanted to ask a question about the tri-arch setup for MIPS under 
IRIX.


Is this planned for libraries other than IRIX based shared libraries, 
will this capability be extended to the linux shared libraries?


   


Short answer: it already has been.

Long answer:
Look at gcc/config/mips/linux64.h.

-eric

 

Hmm, doesn't seem to build a triarch libstdc++, will verify and post bug 
report if necessary..


Thanx Eric for the clarification.

--

Jim Gifford
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Laurent GUERBY]

On Tue, 2005-06-14 at 09:01 -0700, Mark Mitchell wrote:
> CodeSourcery struggles with exactly the same problem; we have worked 
> hard to set up some test automation for our ARM builds, and it's working 
> well, but we're not (yet!) as disciplined as we want to be about 
> analyzing and fixing the failures.

At AdaCore (I assume it's still the rule), a patch was allowed to be
committed only *after* a special run of the regression tester with CVS
source baseline + only your patch showed a clean run (it was all
automated so you just had to provide a clean patch to the system).

That cleans-up the area of who has to do the analysis, and it's on
a patch the person just wrote so no precious brain time wasted in
refocus and analysis of random failures. If the patch is judged correct
but triggering a latent bug somewhere else, the person that will work on
it will also start from a small set of triggering conditions so an
easier task overall.

This leaves:

- the problem of interaction of two patches committed the exact same day
that have a bad interaction, but this is quite rare even for GCC.

- if you don't have enough ressources to run simulators, platform
specific problems.

The only missing piece for such a setup to be workable for GCC in the
FSF framework is some dedicated computing ressources, plus someone to do
the script work.

Laurent

mudflap cache question

[Herman ten Brugge]

I just read the mudflap pdf file and wanted to know how the cache was 
implemented.
I looked at the code in mf-runtime.c and found the cache functions. The 
code for the

__mf_uncache_object looks strange to me however.
The code looks like:

static void
__mf_uncache_object (__mf_object_t *old_obj)
{
 /* Remove any low/high pointers for this object from the lookup cache.  */

 /* Can it possibly exist in the cache?  */
 if (LIKELY (old_obj->read_count + old_obj->write_count))
   {
 uintptr_t low = old_obj->low;
 uintptr_t high = old_obj->high;
 unsigned idx_low = __MF_CACHE_INDEX (low);
 unsigned idx_high = __MF_CACHE_INDEX (high);
 unsigned i;
 for (i = idx_low; i <= idx_high; i++)
   {
 struct __mf_cache *entry = & __mf_lookup_cache [i];
 /* NB: the "||" in the following test permits this code to
tolerate the situation introduced by __mf_check over
contiguous objects, where a cache entry spans several
objects.  */
 if (entry->low == low || entry->high == high)
   {
 entry->low = MAXPTR;
 entry->high = MINPTR;
   }
   }
   }
}

__MF_CACHE_INDEX(ptr) is (ptr >> 2) & 0x3ff at startup.

Suppose we have an old_obj->low of 0x1 and an old_obj->high of 
0x2. Then the
cache entries we look at is just entry 0. Which I believe is just wrong. 
Any pointer
between 0x1 and 0x2 must fill other cache entries. It gets even 
worse when
the old_obj->low = 0x1fff0 and object high is 0x2. Then we probably 
won't

invalidate any cache entry.
Should I write a bug report?

Herman.

Re: Porposal: Floating-Point Options

[Robert Dewar]

Russell Shaw wrote:


The original bug was about testing the equality of doubles. I think that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documentation.


That's often taught, but in fact there are many IEEE algorithms where it
makes perfectly good sense to test for absolute equality.


OTOH, maybe the equality operators should discard the excess precision, so
effectively implementing the error band anyway. Can't say more without 
reading
the relevant standards. If the equality operators did this, then it 
shouldn't

slow down any non-equality operators or anything else.


But it would, quite unnecessarily, slow down equality.

Re: Porposal: Floating-Point Options

[Robert Dewar]

Vincent Lefevre wrote:


has little to say about mapping to high level languages, so it is
important to understand that appealing to this standard is necessary
but far from efficient.



Why not efficient?


Oops, efficiency on the mind, I meant sufficient :-)

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Robert Dewar]

Scott Robert Ladd wrote:


I would like to improve floating-point in GCC; doing so scratches my
personal itch. My silly idea is to determine the best approach
*through discussion*.


Perfectly appropriate, and you are getting lots of discussion!

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Robert Dewar wrote:
> Scott Robert Ladd wrote:
>> I would like to improve floating-point in GCC; doing so scratches my
>> personal itch. My silly idea is to determine the best approach
>> *through discussion*.

> Perfectly appropriate, and you are getting lots of discussion!

And I'm burbling with joy!

Well, maybe not *that* enthused... :)

..Scott

Re: Porposal: Floating-Point Options

[Marcin Dalecki]

On 2005-06-14, at 16:32, Scott Robert Ladd wrote:


To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more  
formal.


-ffp-correct


Please define correct.


This option focuses code generation on mathematical correctness,
portability, and consistency.


Please define this. Please define mathematical correctness for a FPU  
implementation.
Preferable in formal terms. A Verilog file for example wold be fine.  
Don't forget
to perform *full* verification of the design to be. I mean in  
mathematical terms.

Seriously, I don't mind if this will take a tad bit of time.
Please lay down in esp. how GCC currently deviates from the  
principles in this statement.



No 80-bit long doubles, no fsin/fcos,
making certain that comparison operators work within reason.


Please give the definition of reason.

Note that this option can only go so far in ensuring portability,  
given that not

every system supports IEEE 754 floats.


Please give the distance for "so far". Preferable in metric terms.


-ffp-ieee754

To the best of our ability, assume and follow IEEE 754. Similar to the
above, but assuming IEEE floats and doubles. Note that IEEE 754 has  
been

undergoing some revision.


Note taken. I hence forth declare to have no abilities. Thus this  
goal is
immediately accomplished. Note that you can derive your own abilities  
from

this statement.


-ffp-balanced (default)


Yes. My iMac is already well balanced on the aluminum tadpole on  
which it sits.


Balance correctness with speed, enabling performance optimizations  
that

may reduce portability or consistency, but which do not alter the
overall quality of results.
Yeah, I know that's a bit fuzzy;


Yeah just a tad little bit... we can stop considering minor stuff  
like cache sizes

RAM latencies versus clock rate and all those other minor irrelevant
stuff which doesn't allow us to define a single only total optimum  
for the generated code.
You are right - this kind of nit-picking is really fully irrelevant  
for the

task at hand.


formal
definition of such an option depends on categorizing existing FP code
generation (something I'm working on).

-ffp-damn-the-torpedoes-full-speed-ahead


I just love cute references to military terms. I served myself  
proudly but

involuntarily in the ari. You know buddy. They just make me feel like...
actually like... oh dare memories.


Okay, maybe that should be something shorter,


How about:
-ffp-damn-I-have-no-clue

Nearly half the size - you see?


like -ffast-math or
-ffp-fast. This option enables dangerous hardware intrinsics,


Will it pose the danger for overheating my CPUs thermal throttling?
Perhaps it should be accompanied with an interactive question asserting
question at compiler run time then:

gcc -ffp-fast helloworld.c
ALLERT: The -ffp-fast option is dangerous. Are you sure to proceed  
[YES/NO]?:



and
eschews all concerns about portability and consistency in the quest  
for
speed. The behavior is likely to be the same as the current -ffast- 
math.


Actually, I like *-ffp-damn-the-torpedoes-full-speed-ahead*.


I love it too...

As Stroustrup once said, if you're going to do somethimg ugly, it  
should

look ugly. ;)


Yes! The road to success is paved with imitation. Success is always
reproducible and not accidental. And I'm sure Stroustrup was a better  
philosopher
then coder, since competence in one area automatically projects  
itself on

everything...

Re: Porposal: Floating-Point Options

[Marcin Dalecki]

On 2005-06-14, at 19:29, Russell Shaw wrote:


The original bug was about testing the equality of doubles. I think  
that's

just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum  
precision

specified in the compiler documentation.



To be a bit more precise: don't use the precision specified in the  
compiler
but the precision you expect for the overall algorithms numerical  
stability.

Libstdc++ versioning issues

[Mark Mitchell]

Benjamin --

Right now, the libstdc++ versioning/ABI situation is is all that stands 
between us and 4.0.1 RC2, now that Jakub has fixed the GLIBC miscompilation.


What is an ETA for additional information?  Am I correct in 
understanding, from your previous mail, that these problems occurred in 
4.0.0 as well?


Thanks,

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Bug in transparent union handling?

[Daniel Berlin]

It seems the structure aliasing patch exposed what appears to be a bug
in the C FE.

Our docs on transparent union say "@item transparent_union
This attribute, attached to a function parameter which is a union, means
that the corresponding argument may have the type of any union member,
but the argument is passed as if its type were that of the first union
member.  For more details see @xref{Type Attributes}.  You can also use
this attribute on a @code{typedef} for a union data type; then it
applies to all function parameters with that type.
"

However, given the following code:
struct s1 {
int x;
};

struct s2 {
int x;
};

union u1 {
struct s1 *xs1;
struct s2 *xs2;
} __attribute__ ((__transparent_union__));


extern void g(union u1 p);

void f() {
struct s1 addr;

g( (struct s2 *)&addr );
}


We generate:


f ()
{
  union u1 addr.0D.1248;
  union u1 addr.1D.1249;
  struct s1 addrD.1247;

  addr.1D.1249 = (union u1) &addrD.1247;
  addr.0D.1248 = addr.1D.1249;
  g (addr.0D.1248);
}


Note clearly that we are casting &addr (a pointer) to a union type (an
aggregate).  It's also not what the user actually wrote, nor what the
docs say (the docs imply it would be as if it was casted to a struct s1
*, the first member of the union).

This confuses the structure aliasing code, because it doesn't expect to
see an addressof operation casted to an aggregate.

Is this really supposed to look like this?

gcc-3.4-20050614 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050614 

You'll find:

gcc-3.4-20050614.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20050614.tar.bz2 C front end and core compiler

gcc-ada-3.4-20050614.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20050614.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20050614.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20050614.tar.bz2 Java front end and runtime

gcc-objc-3.4-20050614.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20050614.tar.bz2The GCC testsuite

Diffs from 3.4-20050607 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
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: Fixing Bugs (Was: A Suggestion for Release Testing)

[Giovanni Bajo]

Scott Robert Ladd <[EMAIL PROTECTED]> wrote:

> Consider, as an example, the bug/non-bug at http://gcc.gnu.org/PR323,
> which was a matter of recent discussion on this list. Some rather
> respectable people (e.g., Vincent Lefèvre) consider this a bug, and
> have proposed solutions. Yet here's a quote from an earlier message by
> Giovanni Bajo.
> [...]

First of all, I would consider polite to CC: me on the mail if you quote and
debate my statements.

> The ISO Standard doesn't prevent GCC from being *better* than
> specified, does it? Are we somehow breaking ISO compliance by doing
> math right? Is it so wrong to try and fix a problem that frustrates
> many people and makes GCC look bad?

Where exactly do I say that it is wrong to provide a patch that makes GCC
better in this regard? As a bugmaster, I just decided to consider this not a
bug, in the strictest meaning of "bug". If you want to file in Bugzilla an
enhancement proposal about adding options/modes about higher FPU precision, I
would not object.

Also, it seems you have the wrong belief that, if bug 323 were confirmed in
Bugzilla, a patch would automatically appear. I think the two events are
totally unrelated, especially for an issue which has been debated so much in
the past years, and where most people have already a formed opinion on the
matter.

> With the attitude shown by Giovanni, there's really no point in
> submitting a patch, is there? Dozens of people have reported this
> problem, potential solutions exist, but any patch is going to be
> ignored because the bug isn't considered a bug by the Powers That Be.

You seem to believe that a patch can be accepted in GCC only if it fixes a bug.
That is wrong: a valid patch can also add a new feature. While it is probably
hard to convince the Powers That Be (which, by the way, are surely not me) that
the default setting of GCC should be whatever Bug 323 requests, it is much much
easier that a patch adding a new command line option to request higher FP
accuracy be reviewed and accepted. Of course, people would have to *see* such a
patch. And nobody is blocking people from writing it.

I hope to have clarified my position.

Giovanni Bajo

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Fred Fish]

On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> better support for inline functions, which is already on the gdb
> roadmap

Where's the roadmap?  I'm just starting to look at this very issue
and would be good to know what is planned or in progress.

Thanks.

-Fred

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Daniel Jacobowitz]

[Redirecting off gdb-discuss again]

On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote:
> On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> > better support for inline functions, which is already on the gdb
> > roadmap
> 
> Where's the roadmap?  I'm just starting to look at this very issue
> and would be good to know what is planned or in progress.

I was being figurative :-)  We already know we need to do it.

I already have a 30% or so hack which handles creating inline function
frames.  It works well enough for simple backtraces.  But the symbol
table side of it is all rotten, so it's not very useful - segfaults a
lot.

I also have the first 20% or so of setting breakpoints on multiple
locations implemented, which is a necessary partner to that.  But
that's even less finished.

Ask me if you want either set of code.  The latest version of the
latter is in the gdb-patches archive from early this year.  I don't
think I ever posted the former - too gross.

If you want to work on anything without duplicating effort, it behooves
_you_ to discuss it on the mailing lists first.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Visual C++ style inline asms

[Mike Stump]

Any objections to adding Visual C++ style inline asms?

Re: Libstdc++ versioning issues

[Benjamin Kosnik]

> What is an ETA for additional information?  Am I correct in 
> understanding, from your previous mail, that these problems occurred in 
> 4.0.0 as well?

Hi Mark. Thanks for your patience.

I'm testing a patch that resolves the issue. I expect to have
additional details within 24 hrs, and will let you know details.

-benjamin

Re: Visual C++ style inline asms

[Andrew Pinski]

On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:


Any objections to adding Visual C++ style inline asms?


Didn't RTH objected the last time?

-- Pinski

Re: Visual C++ style inline asms

[Daniel Jacobowitz]

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> 
> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> 
> >Any objections to adding Visual C++ style inline asms?

Mike, you're going to get more useful feedback if you ask a question
with some details in it.  Not all of us use Microsoft compilers.

> Didn't RTH objected the last time?

You can find plenty of information about this in the archives.  I
recall Stan Shebs discussing it at length.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Visual C++ style inline asms

[Andi Kleen]

Mike Stump <[EMAIL PROTECTED]> writes:

> Any objections to adding Visual C++ style inline asms?

Doesn't that need support to parse assembly? (= essentially
a builtin assembler). How else would the compiler
know what registers are clobbered and where to put input/output
variables?

All compilers i've seen who supported that had builtin
assemblers. 

-Andi

Re: [Gdb-discuss] Re: x86 Q: why aren't the SSE intrinsics always_inline?

[Fred Fish]

On Tuesday 14 June 2005 21:17, Daniel Jacobowitz wrote:

> Ask me if you want either set of code.

Sure, I'd like to take a look at it.

> If you want to work on anything without duplicating effort, it behooves
> _you_ to discuss it on the mailing lists first.

Agreed.  I've just recently started looking at this issue for gdb and
so far am still just reading and tracing through the code that handles
frames since it has been a long time since I've worked in this area of
gdb.  Once I have a better handle on how things currently work I was
planning to post something to get a discussion going.

-Fred

PR 14814

[Giovanni Bajo]

Jeff,

g++.dg/tree-ssa/pr14814.C has been failing from the first day it was added. It
is unclear to me what happened in detail, but in the PR you suggest to XFAIL
the testcase. That would be fine: would you please take care of that?

Also, notice that there is a typo in the ChangeLog entry for this testcase. It
reads:

2005-05-17  Jeff Law  <...>

* g++.dg/tree-ssa/pr18414.C: New test.
* gcc.dg/tree-ssa/pr18414.C: New test.

while the correct PR number is "14814". Would you please also fix this?

Thanks,
Giovanni Bajo

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Scott Robert Ladd]

Giovanni Bajo wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> First of all, I would consider polite to CC: me on the mail if you quote and
> debate my statements.

I meant no offense, and thought that I *had* CC'd you on the message.

>>The ISO Standard doesn't prevent GCC from being *better* than
>>specified, does it? Are we somehow breaking ISO compliance by doing
>>math right? Is it so wrong to try and fix a problem that frustrates
>>many people and makes GCC look bad?
> 
> Where exactly do I say that it is wrong to provide a patch that makes GCC
> better in this regard? As a bugmaster, I just decided to consider this not a
> bug, in the strictest meaning of "bug". If you want to file in Bugzilla an
> enhancement proposal about adding options/modes about higher FPU precision, I
> would not object.

I've been suggesting various ways to enhance, or at better delineate,
floating-point in GCC. Once I've got a good idea of the best way to
approach this (and I've had some excellent feedback), I will indeed
submit a patch. I even have one started...

Given the number of "duplicate filings" associated with 323, I assumed
that filing another item on the topic would be ineffective.

> Also, it seems you have the wrong belief that, if bug 323 were confirmed in
> Bugzilla, a patch would automatically appear.

No; my objection is to having people's concerns flatly rejected. It is
not clear from reading the message on 323 that a "add an option" patch
would be considered.

If anything, I'm very pleased with the way people have handled the bugs
I've reported; all but one (or more than 20) have been fixed. Good stuff.

>>With the attitude shown by Giovanni, there's really no point in
>>submitting a patch, is there? Dozens of people have reported this
>>problem, potential solutions exist, but any patch is going to be
>>ignored because the bug isn't considered a bug by the Powers That Be.
> 
> You seem to believe that a patch can be accepted in GCC only if it fixes a 
> bug.

No, my experience is that a patch is only accepted if it has already
been approved, at least on a conceptual level. I've tried the "make a
patch without talking to anyone" approach, and wasted a lot of time.

> I hope to have clarified my position.

And I mine.

..Scott

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Gabriel Dos Reis]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

| Also, it seems you have the wrong belief that, if bug 323 were confirmed in
| Bugzilla, a patch would automatically appear. I think the two events are
| totally unrelated, especially for an issue which has been debated so much in
| the past years, and where most people have already a formed opinion on the
| matter.

That is untrue.  When something is considered not an issue, it is
usually hard to get a patch for it.

-- Gaby

RE: Visual C++ style inline asms

[Bobby McNulty]

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Mike Stump
>Sent: Tuesday, June 14, 2005 8:25 PM
>To: GCC Mailing List
>Subject: Visual C++ style inline asms

>Any objections to adding Visual C++ style inline asms?

This will greatly help us for those of us who want Visual C++ source to work
under GCC. I use both GCC and Visual Studio.

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Timothy J. Wood]

On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote:

I think a lot of what happens is that easy bugs do get fixed. The ones
that don't are often complex, or ill-reported, and thus tend to  
require

a lot of knowledge to work on effectively.


  One form of mentoring would be to _not_ have the core folks fixing  
the easy

bugs.  Throw those to the newbies with some pointers at where to look.
Eventually newbies get more and more experienced, and old-guard folks  
get more

available time to work on hard issues.

  I'm not saying this doesn't happen right now -- I don't know  
enough to make

that determination :)

-tim

Re: Porposal: Floating-Point Options

[Russell Shaw]

Robert Dewar wrote:

Russell Shaw wrote:

The original bug was about testing the equality of doubles. I think 
that's

just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documentation.


That's often taught, but in fact there are many IEEE algorithms where it
makes perfectly good sense to test for absolute equality.

OTOH, maybe the equality operators should discard the excess 
precision, so
effectively implementing the error band anyway. Can't say more without 
reading
the relevant standards. If the equality operators did this, then it 
shouldn't

slow down any non-equality operators or anything else.


But it would, quite unnecessarily, slow down equality.


But isn't equality broken if it doesn't work because of excess precision?

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Andrew Pinski]

On Jun 14, 2005, at 10:43 PM, Timothy J. Wood wrote:



On Jun 14, 2005, at 8:13 AM, Robert Dewar wrote:

I think a lot of what happens is that easy bugs do get fixed. The ones
that don't are often complex, or ill-reported, and thus tend to 
require

a lot of knowledge to work on effectively.


  One form of mentoring would be to _not_ have the core folks fixing 
the easy

bugs.  Throw those to the newbies with some pointers at where to look.
Eventually newbies get more and more experienced, and old-guard folks 
get more

available time to work on hard issues.


This is in fact how I started working on GCC, I started with some easy 
bugs

and moved my way up.  I also now a days reduce preprocessed source which
comes into GCC's bugzilla and CC the person who I think caused the 
regression.
So I look at every bug which comes in and knows when there is an easy 
one.


Maybe I should start a wiki page for bugs which might be easy to fix 
but that

will not be for this week.

-- Pinski

Re: GCC 4.0.1 Status (2005-06-13)

[R Hill]

Daniel Kegel wrote:

Scott Robert Ladd wrote:

Agreed. I've had mixed reports from folks over in the Gentoo universe
about glibc; perhaps this page might be of interest:

http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks


Hey Scott.

That page is pretty outdated.  AFAIK we haven't been experiencing glibc 
problems with 4.0 since prerelease.  Plus it mentions binutils 
2.16.90.0.1 which was booted from the tree very quickly due to an 
annoying --as-needed bug[1].


PS - Swing by the forum[2] if you get a chance. ;P

(Interestingly, the fixes in glibc-cvs seem to have been made in such a 
way that the new glibc won't be compilable by older versions of gcc, like gcc-3.4.4.

I guess the thinking is that everyone should be using the latest gcc?)
- Dan


Hmm, do you have a source for any more info?  I want to take a look at this.

--de.

[1]http://sources.redhat.com/bugzilla/show_bug.cgi?id=815
[2]http://forums.gentoo.org/viewtopic-t-327669.html

Re: Problems with collect2 on hpux

[John David Anglin]

> > It's not very nice that the shared library list for libstdc++.sl
> > includes libgcc_s.sl in the GCC build directory.  I believe that the
> > HP dynamic loader first looks for it there.  If that doesn't work,
> > it strips off the basename of the library and tries the dynamic
> > search path.
> 
> Yeah, I had to fix that problem first by going into the libstdc++ dir, and
> doing a "make clean ; make LDFLAGS=-Wl,+s"
> 
> Wouldn't it make sense to do this by default?  Should I submit a patch to
> do that?

This is mainly a libtool issue.  That's where the '+b" embedded path
option is set.  I'm not sure why +b was preferred to +s.

There are pros and cons to this.  Generally, it's not a good idea
to add unnecessary options, especially if the user can add them when
desired.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: Porposal: Floating-Point Options

[R Hill]

Marcin Dalecki wrote:


[snip]



If you don't have anything constructive to contribute to the discussion 
then feel free to not participate.  If you have objections then voice 
them appropriately or risk them being dismissed as bullshit baiting.


--de.

Re: Visual C++ style inline asms

[Richard Henderson]

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> >Any objections to adding Visual C++ style inline asms?
> 
> Didn't RTH objected the last time?

One has to do a less gross job of it than Red Hat did.  I suppose
I could be prodded into pulling out the code so that you can see
where the bar is.

You'll need and EXTREMELY large testsuite.  You'll find that the MS
documentation is useless, and you'll have to deduce the desired
semantics from customer code bases.  Presumably Apple can find 
large customers who will want this kind of thing and can arrange
to code exchanges in some way, if only NDA.  But if NDA, I expect
reduced test cases to make their way into our testsuite.

Expect to want to implement "naked" functions as well, because MS
does, and quite a lot of VC++ inline asm code expects to use them.
Expect me to barf on your shoes.

I don't recall if Darwin uses %ebx for pic code like ELF.  If you
do, expect to find that lots of user code expects to be able to
clobber it, because Windows doesn't do pic code at all, and so
reserves no such register.

I suspect that one could get quite a lot of milage out of parsing
the assembly code and turning most of it into straight GIMPLE, rather
than into ASM_EXPRs.  A great many examples of VC++ inline asms that
I've seen were completely and utterly trivial; the compiler could have
done a better job.  Of course there will be cases that you either
can't understand, or use instructions that don't map to an EXPR or a
builtin.  But I expect that more often than not, you can reduce the
inline asm block to one such insn, and expose all the rest of the
data movement to the compiler.



r~

Re: Bug in transparent union handling?

[Richard Henderson]

On Tue, Jun 14, 2005 at 07:59:53PM -0400, Daniel Berlin wrote:
> Is this really supposed to look like this?

Not really.  What's there is Good Enough (tm) if we immediately 
expand to rtl; the union will Just So Happen to have Pmode, and
so things will Just So Happen to work.

This needs to use a VIEW_CONVERT_EXPR, at minimum.  No doubt there
are other parts of transparent unions that need modification.


r~

req. help on merging instructions

[mohit . sharma]

Hello everbody,

Iam new to gcc and need some guidance.

Iam trying to merge the following two instructions

1. addu r2, r3,r4
2. ld   r5 ,mem(r2) # load from address calculated
in the prev. instruction


in to one single isntruction.

3. ldx  r5 , mem(r3(r4)) # indexed load.


I managed to do it with a define_peephole pattern
in the md file. But I want this to happen only in the case
when the last use of register r2 is in statement2 (i.e it isn't
live after stmt 2.)otherwise the r2 value would go incorrect

Please could any body suggest me how should I do this .

Can these kind of restrictions be imposed in the machine
descriptions.

Any links to some related text would also be useful.
Iam trying to impliment it in gcc-3.4.1

thanks in advance.
Mohit

Re: Porposal: Floating-Point Options

[Marcin Dalecki]

On 2005-06-15, at 06:19, R Hill wrote:


Marcin Dalecki wrote:


[snip]


If you don't have anything constructive to contribute to the  
discussion then feel free to not participate.  If you have  
objections then voice them appropriately or risk them being  
dismissed as bullshit baiting.


Sorry but I just got completely fed up by the references to "math" by  
the original post,
since the authors leak of basic experience in the area of numerical  
computation was

more then self evident.

Writing number crunching code without concern for numerical stability
is simply naive. Doing it leads you immediately to the fact that
this engagement makes your code *highly* platform specific, even in  
the case of
mostly innocent looking operations ("cancellation phenomenon" for  
example).
In view of those issues the problems discussed here: supposed  
"invalidity" of

the == operator, excess precision in the intel FPU implementation,
trigonometric function domain range, are completely irrelevant.
You will have to match your code anyway tightly for the actual FPU  
handbook.


Making the code generated by GCC somehow but not 100% compliant with  
some
idealistic standard, will just increase the scope of the analysis you  
will
have to face. And in esp. changing behavior between releases will  
just make

it even worser.

Only the following options would make sense:

1. An option to declare 100% IEEE compatibility if possible at all on  
the particular arch,

   since it's a well known reference.

2. An option to declare 100% FPU architecture exposure.

3. A set of highly target dependent options to control some well defined
   features of a particular architecture.
   (Rounding mode, controll, use of MMX or SSE[1234567] for example...)

Any kind of abstraction between point 1. and 2. and I would see  
myself analyzing the
assembler output to see what the compiler actually did anyway. Thus  
rendering the
reasons they got introduced futile. In fact this is nearly always  
anyway the "modus operandi",
if one is doing numerical computations. It's just about using the  
programming language
as kind of "short cut" assembler for writing the algorithms down and  
then disassembling
the code to see what one actually got - still quicker and less error  
prone then using

the assembler directly. Just some kind of Formula Translation Language.
I simply don't see how much can be done on behalf of the compiler  
with regard

to this.

And last but not least: Most of this isn't really interesting at the
compilation unit level at all. This is the completely uninteresting  
scope.

If anything one should discuss about the pragma
directive level, since this is where fine control of numerical
behavior happens in the world out there. The ability to say for example:

#pragma unroll 4 sturd 8

would be really of "infinite" more value then some fancy -fblah-blah.

Re: GCC 4.0.1 Status (2005-06-13)

[Daniel Kegel]

R Hill <[EMAIL PROTECTED]> wrote:
> Dan Kegel wrote:
(Interestingly, the fixes in glibc-cvs 
seem to have been made in such a way that 
the new glibc won't be compilable by older

versions of gcc, like gcc-3.4.4.
I guess the thinking is that everyone should be using the latest gcc?)


Hmm, do you have a source for any more info? I want to take a look at this.


For some reason, I wanted to be able to build glibc-2.3.5
with gcc-4.0.0, so I rustled up a bunch of little
patches to fix some of the most obvious build problems.
I was careful to allow building with either old or new
compiler.  For instance,
http://kegel.com/crosstool/current/patches/glibc-2.3.5/glibc-2.3.4-allow-gcc-4.0-arm.patch
did

-static Elf32_Addr
+#if __GNUC__ >= 4
+  auto inline Elf32_Addr
+#else
+  static inline Elf32_Addr
+#endif
+#if __GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)
+  __attribute ((always_inline))
+#endif

but glibc-cvs just did
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/arm/Attic/dl-machine.h.diff?r1=1.51&r2=1.52&cvsroot=glibc

-static Elf32_Addr
+  auto inline Elf32_Addr
+  __attribute ((always_inline))

That's what makes me think the glibc maintainers are more interested
in a clean source tree than building with old compilers.
(And I don't disagree with them; I was just surprised.)
- Dan

Re: About macro: SYMBOL_REF_SMALL_P

[Richard Sandiford]

[EMAIL PROTECTED] writes:
> I'm trying to trace the source code of gcc/mips.
> It uses a SYMBOL_REF_SMALL_P macro,
> According to the index of 'GNU Compiler Collection Internals',
> it should be documented on section RTL representation-Access to Special
> Operands but it's not.
> How can I find it's document?

I see what you mean...

-
@findex SYMBOL_REF_SMALL_P
@findex SYMBOL_FLAG_SMALL
@item SYMBOL_FLAG_SMALL
Set if the symbol is located in the small data section.
See @code{TARGET_IN_SMALL_DATA_P}.
-

(the point being that the itemised list only mentions SYMBOL_FLAG_SMALL,
not SYMBOL_REF_SMALL_P).  But the idea is that:

   SYMBOL_REF_SMALL_P (X)

is equivalent to:

   (SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_SMALL) != 0

where SYMBOL_FLAG_SMALL is as documented.  The same is true for
the other *_P macros.

Richard

Re: req. help on merging instructions

[Uros Bizjak]

Hello!

> Iam trying to merge the following two instructions

> 1. addu r2, r3,r4
> 2. ld   r5 ,mem(r2) # load from address calculated
> in the prev. instruction


> in to one single isntruction.

> 3. ldx  r5 , mem(r3(r4)) # indexed load.


> I managed to do it with a define_peephole pattern
> in the md file. But I want this to happen only in the case
> when the last use of register r2 is in statement2 (i.e it isn't
> live after stmt 2.)otherwise the r2 value would go incorrect

You could use peep2_reg_dead_p() or peep2_regno_dead_p() functions in
define_peephole constraints. There are many examples of their use in i386.md.

Uros.