Re: Expanding an ADDSI3 into 2 x ADDHI3 does not work

[Björn Haase]

> If I use:
> (define_expand "addsi"
>  [(set (match_operand:SI 0 "general_operand" "=g")
>(plus:SI (match_operand:SI 1 "general_operand" "g")
> (match_operand:SI 2 "general_operand" "g")))]
>   ""
>   "{
>   emit_insn (gen_addhi3 (custom_subword(operands[0], 0, SImode),
>
> custom_subword(operands[1], 0, SImode),
>
> custom_subword(operands[2], 0, SImode)));
>   emit_insn (gen_addhi3 (custom_subword(operands[0], 1, SImode),
>
> custom_subword(operands[1], 1, SImode),
>
> custom_subword(operands[2], 1, SImode)));
>   DONE;
>}" )
>
> the output becomes a mess of addqi, cmpqi, and branches.
Would it help to use (define_expand "addsi3" ...) instead of (define_expand 
"addsi" ...) ?

Yours,

Björn

Re: Porposal: Floating-Point Options

[Mirza]

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

If this option makes it into GCC, maybe it could be named -O3_unsafe. It 
would be (probably) default for 99% of projects out there to use this 
option alone (which is OK), so why not make their life easier. Just a 
thought.


mirza

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

[Eric Botcazou]

> I would be especially grateful for people testing this on primary hosts
> that are not linux. In particular, AIX and Solaris.

OK on Solaris 2.5.1 and 2.6, but not OK on Solaris 7, 8, 9 and 10:

FAIL: 27_io/basic_istream/ignore/wchar_t/1.cc (test for excess errors)
WARNING: 27_io/basic_istream/ignore/wchar_t/1.cc compilation failed to produce 
executable
FAIL: 27_io/basic_istream/ignore/wchar_t/2.cc (test for excess errors)
WARNING: 27_io/basic_istream/ignore/wchar_t/2.cc compilation failed to produce 
executable
FAIL: 27_io/basic_istream/ignore/wchar_t/7220.cc (test for excess errors)
WARNING: 27_io/basic_istream/ignore/wchar_t/7220.cc compilation failed to 
produce executable
FAIL: 27_io/basic_istream/peek/wchar_t/1.cc (test for excess errors)
WARNING: 27_io/basic_istream/peek/wchar_t/1.cc compilation failed to produce 
executable
FAIL: 27_io/basic_ostream/seekp/wchar_t/2346-fstream.cc (test for excess 
errors)
WARNING: 27_io/basic_ostream/seekp/wchar_t/2346-fstream.cc compilation failed 
to produce executable
FAIL: 27_io/basic_ostream/seekp/wchar_t/2346-sstream.cc (test for excess 
errors)
WARNING: 27_io/basic_ostream/seekp/wchar_t/2346-sstream.cc compilation failed 
to produce executable


/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/1.cc:66: undefined reference to `std::basic_istream >::ignore(int, long)'^M
collect2: ld returned 1 exit status^M
compiler exited with status 1


/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/2.cc:51: undefined reference to `std::basic_istream >::ignore(int, long)'^M
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/2.cc:51: undefined reference to `std::basic_istream >::ignore(int, long)'^M
collect2: ld returned 1 exit status^M
compiler exited with status 1


/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/7220.cc:45: undefined reference to `std::basic_istream >::ignore(int, long)'^M
/home/eric/cvs/gcc-4_0-branch/libstdc++-v3/testsuite/27_io/basic_istream/ignore\
/wchar_t/7220.cc:51: undefined reference to `std::basic_istream >::ignore(int, long)'^M
collect2: ld returned 1 exit status^M
compiler exited with status 1

and so on.

-- 
Eric Botcazou

The tree API

[ibanez]

Hello~ every one :)

I'm a new guy in gcc mailing list
I've been studying gcc for 2 months.
I read "GNU compiler collection internals" (for GCC 3.5.0?),
and I also trace the source code for target-mips.
My problem is there are so much symbol/function/API in gcc.
Some are documentated in the book but not all of them.
All I can do is modified it, rebuild and see what's happend.
This approach is not effective.
If there is a way to learn the gcc internal APIs "systematically"?






***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: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Wed, 2005-06-15 at 12:13 -0400, Scott Robert Ladd wrote:
> Richard Guenther wrote:
> > On 6/15/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> >>But an objection from one of the bugmasters *is* enough to keep people
> >>from presenting a patch.
> > 
> > How do you come to this conclusion?  From my experience this
> > is untrue - bugs get fixed because either someone feels resposible,
> > it's too easy to do, or someone has personal interest in getting the
> > bug fixed.  Negative or positive comments do not change this.
> 
> When a bugmaster posts a pejorative response, it strongly implies that
> any effort in patch will be rejected or ignored.
> 
> I know for a fact that several people have been chased away from working
> on GCC by the pithy attitudes of some GCC developers. 

Maybe you should start naming names, so we can take stock of the
problem.
Otherwise, it just sounds like you are blowing smoke :)
I know it may seem "impolite", but apparently these people are being
impolite and having what you see as a significant affect on GCC.

Therefore, i believe the embarrassment or whatever is outweighed by the
need to change.



> Mark has a valid concern: Why aren't bugs being fixed? One answer is:
> The GCC community is often less than welcoming, friendly, and helpful.

Again, please point to specific examples.

How do you  expect things to adapt and change if you won't give us
examples?

Re: Porposal: Floating-Point Options

[Robert Dewar]

Mirza wrote:

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

If this option makes it into GCC, maybe it could be named -O3_unsafe. It 
would be (probably) default for 99% of projects out there to use this 
option alone (which is OK), so why not make their life easier. Just a 
thought.


mirza


I would avoid the words safe and unsafe, because

a) they are technical terms in the realm of high integrity programming
b) they are unnecessarily emotive (who wants unsafe code?)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> Again, please point to specific examples.

GCC developers don't want examples.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 16 Jun 2005, Vincent Lefevre wrote:


On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:

Again, please point to specific examples.


GCC developers don't want examples.


I'm sorry to interrupt your trolling, but you'll note
1. I'm a GCC developer
2. I asked for specific examples

So you are quite clearly wrong, and being a troll.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-15 18:18:23 -0400, Andrew Pinski wrote:
> But if you look how old it is, it is before really any bugmaster
> started. Also a main developer, RTH, closed it and he has been
> working on GCC since before 1999.

I'm answering that since this is plainly wrong. Bug 21809 was
closed by yourself on 2005-05-29. This is not 1999!

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 14:03 +0200, Vincent Lefevre wrote:
> On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> > Again, please point to specific examples.
> 
> GCC developers don't want examples.
> 

I should also note that *you* seem to equate "disagreement with your
viewpoint" with "wrong", "obstinate", or "ignorant", which is not the
case.  Just because someone disagrees with your views on floating point
does not make them wrong, stupid, or people who don't want to listen.
It means they disagree with your viewpoint.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 14:08 +0200, Vincent Lefevre wrote:
> On 2005-06-15 18:18:23 -0400, Andrew Pinski wrote:
> > But if you look how old it is, it is before really any bugmaster
> > started. Also a main developer, RTH, closed it and he has been
> > working on GCC since before 1999.
> 
> I'm answering that since this is plainly wrong. Bug 21809 was
> closed by yourself on 2005-05-29. This is not 1999!

You deny that Bug 21809 is the same bug as Bug 323, which was closed in
1999?


Again, this is a place where you disagree that this should be considered
a "bug", but refuse to believe that reasonable people can disagree on
it.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Thursday 16 June 2005 14:03, Vincent Lefevre wrote:
> On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
> > Again, please point to specific examples.
>
> GCC developers don't want examples.

Perhaps not your examples, because your way of discussing so
far is not exactly a very constructive one.

Gr.
Steven

Re: Porposal: Floating-Point Options

[Mirza]

Robert Dewar wrote:


I would avoid the words safe and unsafe, because

a) they are technical terms in the realm of high integrity programming
b) they are unnecessarily emotive (who wants unsafe code?)


I agree, but term "unsafe" is less important then fact that developer 
will have only one gcc option to use in release mode. If he is doing 
something "special" (like math-related app) only _then_ he needs to 
learn and tune gcc options. Instead of O3_unsafe it can be O3_non_iso, 
O3_ni, O3ni ... whatever.


mirza

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Daniel Berlin wrote:
> Again, this is a place where you disagree that this
> should be considered
> a "bug", but refuse to believe that reasonable
> people can disagree on
> it.

Well, Vincent has given detailed explaination on his
views.

What do you mean by "reasonable" here?













___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Patrick McFarland]

On Thursday 16 June 2005 08:20 am, Daniel Berlin wrote:
> You deny that Bug 21809 is the same bug as Bug 323, which was closed in
> 1999?

No, clearly, its some form of time travel by aliens wanting to subvert GCC to 
their own evil purposes. Vincent is their leader.

I, for one, welcome our new Lefevrian overlords.

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgphvSAXgbsGB.pgp
Description: PGP signature

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 13:35 +0100, Haren Visavadia wrote:
> --- Daniel Berlin wrote:
> > Again, this is a place where you disagree that this
> > should be considered
> > a "bug", but refuse to believe that reasonable
> > people can disagree on
> > it.
> 
> Well, Vincent has given detailed explaination on his
> views.
> 
> What do you mean by "reasonable" here?

I mean people who understand the issues involved.
Again, Vincent refuses to believe that anybody who "truly" understands
the issues involved could come to any other conclusion than his.
However, this simply is not true.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-16 07:43:17 -0400, Daniel Berlin wrote:
| > Again, please point to specific examples.
| 
| GCC developers don't want examples.

Vincent -- 

   Yoir remark is inappropriate.  Obviously, Daniel is a GCC developer.
I guess you did not mean to be impolite to or annoy him?

-- Gaby

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

[Jakub Jelinek]

On Thu, Jun 16, 2005 at 10:56:52AM +0200, Eric Botcazou wrote:
> > I would be especially grateful for people testing this on primary hosts
> > that are not linux. In particular, AIX and Solaris.
> 
> OK on Solaris 2.5.1 and 2.6, but not OK on Solaris 7, 8, 9 and 10:

Can you please post output from
readelf -Ws libstdc++.so.6 \
  | sed -n '/\.symtab/,$d;/ UND /d;/\(GLOBAL\|WEAK\)/p' \
  | awk '{ if ($4 == "OBJECT") { printf "%s %s %s %s %s\n", $8, $4, $5, $6, $3 
} else { printf "%s %s %s %s\n", $8, $4, $5, $6 }}' \
  | LC_ALL=C sort -u

before and after the patch?
Thanks.

Jakub

Re: The tree API

[Rafael Espíndola]

On 6/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> 
> Hello~ every one :)
> 
> I'm a new guy in gcc mailing list
> I've been studying gcc for 2 months.
> I read "GNU compiler collection internals" (for GCC 3.5.0?),
> and I also trace the source code for target-mips.
> My problem is there are so much symbol/function/API in gcc.
> Some are documentated in the book but not all of them.
> All I can do is modified it, rebuild and see what's happend.
> This approach is not effective.
> If there is a way to learn the gcc internal APIs "systematically"?

I think that I can help since I am having the same problem :)

The best references that I can give you is the GCC Frontend HOWTO at
http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html. It is based on a
old gcc, but most of the tree structure still applies.

Two colleges and I are working on a minimal "hello world" front end
for gcc. You can find a alpha version at
http://ltc08.ic.unicamp.br/svn/scheme/branches/hello-world

I also recommend that you take a look at treelang. It is quite simpler
than the others frontends in gcc.

I hope this helps,
Rafael Ávila de Espíndola

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mark Hahn]

> > I'm answering that since this is plainly wrong. Bug 21809 was
> > closed by yourself on 2005-05-29. This is not 1999!
> 
> You deny that Bug 21809 is the same bug as Bug 323, which was closed in
> 1999?
> 
> Again, this is a place where you disagree that this should be considered
> a "bug", but refuse to believe that reasonable people can disagree on
> it.

the question then becomes whether GCC is helped or harmed by 
its current policy of unpredictable excess precision.

it's quite unfortunate that gcc responders feel so free to vent
their annoyance about this.  Pinski, for instance, is absurdly 
unhelpful in suggesting that the bug reporter just abandon x87.

again, the problem is well-understood: the lack of predictability of
when excess precision is retained by x87.  the problem is not EP or x87.

the only constructive comment in this thread so far has been that libm
might somehow rely on EP (ie can't use the _FPU_SET_CW workaround).
which code is this?  I'd guess it might be related to using series 
approximations, and the code could either set CW or accept 64b results.

regards, mark hahn.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> Maybe you should start naming names, so we can take stock of the
> problem.

Because of Acovea and my reviews of GCC (there are two more coming, one
in a print magazine), a lot of people write me privately. This happens
with commercial compilers as well... and combining those e-mails with
conversations in IRC and other mailing lists, I have ample evidence that
many people feel that the GCC developer community is not very welcoming.

Why do people write me? I've been doing compiler reviews, and working on
compilers (other than GCC), for more than 15 years. Perhaps people just
think they know me, and are more comfortable talking to a "person" who
has publicly expressed concerns similar to thiers.

I am not the only voice in these threads, though. Several people have
expressed feelings herein that are similar to mine.

> How do you  expect things to adapt and change if you won't give us
> examples?

We've made productive suggestions. People have cited specific examples.
For example,

1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.

2) A mentoring system could help bring along new GCC developers. I'm not
talking about hand-holding, I'm suggesting that having some place for
people to ask a few questions, one on one, to get over certain
conceptual humps.

3) To keep Steven's bloodpressure down, I suggest a new mailing list,
gcc-design, where engineers like myself can propose designs and concepts
without upsetting those who find such discussions annoying.

As it is, I now have enough information to proceed with a couple of
patches related to these dicussions. We'll see how it goes.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

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


1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.


But you don't see all the thank you emails I get too because they are
almost always in a private email.  And most of the time I don't close
a bug unless I am really really sure that the bug is invalid.  I usually
say "I think this is invalid".

There was a public thank you to me yesterday:
.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Scott Robert Ladd <[EMAIL PROTECTED]> writes:

| 2) A mentoring system could help bring along new GCC developers. I'm not
| talking about hand-holding, I'm suggesting that having some place for
| people to ask a few questions, one on one, to get over certain
| conceptual humps.

Such a place does exist, as mentioned in several messages.

-- Gaby

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

[Scott Robert Ladd]

Aaron W. LaFramboise wrote:
> Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
> the "Bicycle shed effect."
> 
> 

If I'm building a bicycle shed, I may want to talk with others who have
done so in the past, learning from the experience and gaining their
insights. Why did they use a certain type of construction? What sort of
storage did they build in? What worked and didn't work for someone else
who has already built a shed? What did they learn from their own work?
Any shed I build will be better for such discussions.

GCC's floating-point support can be improved by considering what people
want from their math in conjunction with the characteristics of
different systems. Discussions herein have clarified and expanded my
understanding of the issues.

> In all of the open source world I have seen, posting code is always better.

Better than what? Design? Analysis? Just because some people like to
nitpick doesn't mean there shouldn't be forethought to our work.

Be that as it may, one must work within the presiding culture, and if
design and analysis are frowned upon, it is directly to code that I will go.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Mark Hahn wrote:
> LKML is no different, except that it is probably somewhat more prominent,
> and has developed some immunity/bouncers (kernel janitors, etc).

Linux as has a vast body of educational material, including "kernel
newbies".

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Dan Kegel]

Scott Robert Ladd wrote:

I have ample evidence that
many people feel that the GCC developer community is not very welcoming.


I haven't found this to be the case.  Perhaps that's because
I try to control my urge to post frequently (oops, guess
I'm screwing up here!), and because I try hard to come
up with minimal test cases when I have problems to report.


1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.


Politeness is always a good idea.
However, if you poke a bear with a stick often enough,
he will growl.  If you tell a gcc developer over and over
he is wrong, for instance, I think it's understandable
for him to becom cross.

In any big project, there will always be developers who are sometimes
cross and impolite (e.g. certain library maintainers who shall
remain nameless) but do stellar work in general.
When you run into such a bear, it's best to just
grit your teeth, remain polite, and be thankful he's
contributing to the project.


2) A mentoring system could help bring along new GCC developers. I'm not
talking about hand-holding, I'm suggesting that having some place for
people to ask a few questions, one on one, to get over certain
conceptual humps.


What about the IRC channel mentioned earlier, posted
prominently at the top of http://gcc.gnu.org/wiki ?
And then there's the GCC summit, if you're really serious.


3) To keep Steven's bloodpressure down, I suggest a new mailing list,
gcc-design, where engineers like myself can propose designs and concepts
without upsetting those who find such discussions annoying.


I think what gets peoples' blood pressure up is
endless discussion about how they ought to do their
business.
- Dan

--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> 
> | 2) A mentoring system could help bring along new GCC developers. I'm not
> | talking about hand-holding, I'm suggesting that having some place for
> | people to ask a few questions, one on one, to get over certain
> | conceptual humps.
> 
> Such a place does exist, as mentioned in several messages.

The IRC channel? No one stated that it was for "newbie" questions. Given
that it wasn't very well documented on the web site, it appeared to be a
private channel for existing GCC developers.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Thursday 16 June 2005 16:39, Scott Robert Ladd wrote:
> Gabriel Dos Reis wrote:
> > Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> > | 2) A mentoring system could help bring along new GCC developers. I'm
> > | not talking about hand-holding, I'm suggesting that having some place
> > | for people to ask a few questions, one on one, to get over certain
> > | conceptual humps.
> >
> > Such a place does exist, as mentioned in several messages.
>
> The IRC channel? No one stated that it was for "newbie" questions. Given
> that it wasn't very well documented on the web site, it appeared to be a
> private channel for existing GCC developers.

Newbie GCC developers are also existing GCC developers.

Gr.
Steven

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Dan Kegel wrote:
> And then there's the GCC summit, if you're really serious.

I'd certainly love to attend, but can't afford it with the medical bills
we've accumulated. Hospitalizing both the primary bread-winners has a
dramatic affect on finances. ;)

> I think what gets peoples' blood pressure up is
> endless discussion about how they ought to do their
> business.

Try publishing a compiler review, and listen to the kibitzers. :)

I've been writing for publication all my adult life; just because people
don't like what you write (software or prose) is no reason to be rude.
They might actually have valid points...

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:13 -0400, Scott Robert Ladd wrote:
> Daniel Berlin wrote:
> > Maybe you should start naming names, so we can take stock of the
> > problem.
> 
> Because of Acovea and my reviews of GCC (there are two more coming, one
> in a print magazine), a lot of people write me privately. This happens
> with commercial compilers as well... and combining those e-mails with
> conversations in IRC and other mailing lists, I have ample evidence that
> many people feel that the GCC developer community is not very welcoming.

Again, *please* provide examples other than "The bugmasters are mean".

> I am not the only voice in these threads, though. Several people have
> expressed feelings herein that are similar to mine.

I've seen two people trolling this thread claiming that because gcc
doesn't agree with their viewpoint, they are wrong and unfriendly.

> 
> > How do you  expect things to adapt and change if you won't give us
> > examples?
> 
> We've made productive suggestions. People have cited specific examples.
> For example,
> 
> 1) Bugmasters could be less perfunctory and pejorative in their
> comments. Examples have been given.

I thought we were talking about the gcc developer community, not only
the bug reporting system?
You keep saying "the mailing lists are not very welcoming".
I've not seen any examples of this.

> 3) To keep Steven's bloodpressure down, I suggest a new mailing list,
> gcc-design, where engineers like myself can propose designs and concepts
> without upsetting those who find such discussions annoying.

You are more than free to post designs on gcc@ if you want. However, you
seem to interpret what appears to be constructive criticism as "not very
friendly" at times.

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

[Jonathan Wakely]

On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote:

> Aaron W. LaFramboise wrote:
> > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
> > the "Bicycle shed effect."
> > 
> > 
> 
> If I'm building a bicycle shed, I may want to talk with others who have
> done so in the past, learning from the experience and gaining their
> insights. Why did they use a certain type of construction? What sort of
> storage did they build in? What worked and didn't work for someone else
> who has already built a shed? What did they learn from their own work?
> Any shed I build will be better for such discussions.

You've completely missed the point (rather appropriately).  You're
*supposed* to be building a nuclear reactor, but have got preoccupied
discussing the colour of the bicycle shed in which the staff will park
their bikes.

That's what "bicycle shed painting" refers to.

> GCC's floating-point support can be improved by considering what people
> want from their math in conjunction with the characteristics of
> different systems. Discussions herein have clarified and expanded my
> understanding of the issues.
> 
> > In all of the open source world I have seen, posting code is always better.
> 
> Better than what? Design? Analysis? Just because some people like to
> nitpick doesn't mean there shouldn't be forethought to our work.

The point Aaron is making is that discussion of such topics very rarely
results in any useful design or analysis, because every Tom, Dick and
Harry pipes up to add their 2c, the majority of which are completely
irrelevant. (Look, I'm contributing to it, and I'm completely irrelevant
to the discussion).

If this thread had resulted in any useful design or analysis noone would
mind, but it's turned into a multi-headed beast covering the etiquette
of bugmasters, the names of vapourware compiler switches, and alien
invasion (though that was very funny). Oh, and whether PR323 is a bug,
of course.

The only remaining place this thread can go (before satisfying Godwin's
rule) is for the resident markov generator to correct you all by pointing
out that the linker on MMIX platforms uses UTF-8 for the symbol names.

(what do you mean it's not friday afternoon yet?)

jon

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Andrew Pinski <[EMAIL PROTECTED]> writes:

| On Jun 16, 2005, at 10:13 AM, Scott Robert Ladd wrote:
| 
| > 1) Bugmasters could be less perfunctory and pejorative in their
| > comments. Examples have been given.
| 
| But you don't see all the thank you emails I get too because they are
| almost always in a private email.  And most of the time I don't close
| a bug unless I am really really sure that the bug is invalid.  I usually
| say "I think this is invalid".

The issue is not whether a report is effectively an invalid bug.  The
issue is whether the reporter must be assumed an obscure ignorant
whose main ill wills are to fill up the GCC bug database, and as such
deserve a corresponding rudeness and must be fought.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> Again, *please* provide examples other than "The bugmasters are mean".

Don't invent quotes. I never said anyone was "mean." And other people
have provided explicitly links to germane bugs.

> You are more than free to post designs on gcc@ if you want. However, you
> seem to interpret what appears to be constructive criticism as "not very
> friendly" at times.

There's a difference between constructive criticism and condescension.

Be that as it may, I actually agree with Steven that this conversation
has reach the point of no return. You may have the last word.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:51 -0400, Scott Robert Ladd wrote:
> Dan Kegel wrote:
> > And then there's the GCC summit, if you're really serious.
> 
> I'd certainly love to attend, but can't afford it with the medical bills
> we've accumulated. Hospitalizing both the primary bread-winners has a
> dramatic affect on finances. ;)
> 
> > I think what gets peoples' blood pressure up is
> > endless discussion about how they ought to do their
> > business.
> 
> Try publishing a compiler review, and listen to the kibitzers. :)
> 
I've actually done this before, back in the BeOS days , of gcc vs
Metrowerks.  Kibitzers raise the same issues that many trolls on our
mailing lists do too. Strange, isn't it?

> I've been writing for publication all my adult life; just because people
> don't like what you write (software or prose) is no reason to be rude.
> They might actually have valid points...
> 

And it might be possible that in the past 5 years, endless discussion
has been had on most of these points, and the person positing the
viewpoint is not in any way raising new reasoning or anything else, they
just want to throw their same 2 cents in again and again and again and
again and again and again and again (which i'm sure you'll say is us
"not listening to the user community", which is not the case).

We've also had people write to other mailing lists and say "plesae
mail-bomb the gcc list so they'll listen to us"

If your whole "community is unfriendly" is about discussion of floating
point issues, than i'll just go away, because yes, over the past 8
years, we've become very unfriendly about the small number of people who
contend again and again that we should do it different, claiming simply
that any viewpoint than theirs is *wrong* and *bad* instead of "a
tradeoff that has been chosen".  And they are *not* particularly polite
about it.



> ..Scott

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

[Daniel Berlin]

On Thu, 2005-06-16 at 10:30 -0400, Scott Robert Ladd wrote:
> Aaron W. LaFramboise wrote:
> > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
> > the "Bicycle shed effect."
> > 
> > 
> 
> If I'm building a bicycle shed, I may want to talk with others who have
> done so in the past, learning from the experience and gaining their
> insights. Why did they use a certain type of construction? What sort of
> storage did they build in? What worked and didn't work for someone else
> who has already built a shed? What did they learn from their own work?
> Any shed I build will be better for such discussions.
> 
> GCC's floating-point support can be improved by considering what people
> want from their math in conjunction with the characteristics of
> different systems. Discussions herein have clarified and expanded my
> understanding of the issues.
> 
> > In all of the open source world I have seen, posting code is always better.
> 
> Better than what? Design? Analysis? Just because some people like to
> nitpick doesn't mean there shouldn't be forethought to our work.
> 
> Be that as it may, one must work within the presiding culture, and if
> design and analysis are frowned upon, it is directly to code that I will go.
Design and analysis is not frowned upon.
Endless design and analysis over minutae is.
Code and design can be revised.


> 
> ..Scott

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

[Robert Dewar]

On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote:

> Aaron W. LaFramboise wrote:

>> > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
>> > the "Bicycle shed effect."
>> >
>> > 


>
> If I'm building a bicycle shed, I may want to talk with others who have
> done so in the past, learning from the experience and gaining their
> insights. Why did they use a certain type of construction? What sort of
> storage did they build in? What worked and didn't work for someone else
> who has already built a shed? What did they learn from their own work?
> Any shed I build will be better for such discussions.

chuckle chuckle ...

The reference is of course to Parkinson's second law, that the discussion
time on an issue is in inverse proportion to its importance. I think
that in fact Scott has unwittingly provided a perfect reference for this
thread :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Daniel Berlin]

On Thu, 2005-06-16 at 10:58 -0400, Scott Robert Ladd wrote:
> Daniel Berlin wrote:
> > Again, *please* provide examples other than "The bugmasters are mean".
> 
> Don't invent quotes. I never said anyone was "mean." And other people
> have provided explicitly links to germane bugs.

Again, i'm looking for more than just the bug database here.

> > You are more than free to post designs on gcc@ if you want. However, you
> > seem to interpret what appears to be constructive criticism as "not very
> > friendly" at times.
> 
> There's a difference between constructive criticism and condescension.

The only time i've seen  condescension used is when the person posting
is not willing to actually understand the issues in the work they are
doing, or repeatedly ignore attempts to guide them.
> 
> Be that as it may, I actually agree with Steven that this conversation
> has reach the point of no return. You may have the last word.

Scott, you have repeatedly claimed unfriendlyness in the gcc developer
community, pointing only to our bug database, and private emails you get
from other people.

When people criticize your designs on gcc@, you seem to take it
personally, and call them unfriendly.

Nothing i have seen in my professional life of a developer tells me that
what you have received is more than just the regular mix of constructive
criticism, mixed with useless replies that inveitably occur that have
nothing to do with anything.

If you consider that "unfriendly", then you really need to get out of
the development business, because you need a thicker skin.

> ..Scott

Re: Porposal: Floating-Point Options

[Joseph S. Myers]

On Tue, 14 Jun 2005, Geoffrey Keating wrote:

> So, what I think you want to do is to add another flag under
> -ffast-math, perhaps called -fwiden-math, which specifically allows
> the compiler to compute values in a wider mode (that would be 80-bit
> x87 FP) even when ISO C doesn't allow it.  You would have this flag on
> by default on x86.

I suggest the name -fno-float-store, since -ffloat-store is the flag meant 
to yield better conformance with the standard requirements for excess 
precision (which only does so for explicit assignments at present).

Implementation outline: stop x86 back end from claiming to support 
float/double operations when it doesn't; teach C and C++ front ends to 
distinguish two types for an expression, the type used for computation 
(always long double for x87 floating point) and the logical type at the C 
language level; ensure that in conforming mode all conversions from long 
double to double or float are executed properly but in nonconforming mode 
allow them to be discarded; ensure that -ansi / -std=c89 / -std=c99 / ... 
enable -ffloat-store on platforms with excess precision.

A cast from double to double would look like (long double)(double)(long 
double value) (final type double) in the front end trees - an expression 
with semantic type double but represented as long double is converted to 
the range and precision of double, then back to long double for any 
further arithmetic in that expression but with the semantic type remaining 
as double.

-- 
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: GCC 4.0.1 Status (2005-06-13)

[Eric Botcazou]

> Can you please post output from
> readelf -Ws libstdc++.so.6 \
>
>   | sed -n '/\.symtab/,$d;/ UND /d;/\(GLOBAL\|WEAK\)/p' \
>   | awk '{ if ($4 == "OBJECT") { printf "%s %s %s %s %s\n", $8, $4, $5, $6,
>   | $3 } else { printf "%s %s %s %s\n", $8, $4, $5, $6 }}' \ LC_ALL=C sort
>   | -u
>
> before and after the patch?

Nice magic spell. :-)

The diff is attached.

-- 
Eric Botcazou
--- before.log  2005-06-16 10:06:25.009231000 -0500
+++ after.log   2005-06-16 10:06:46.519581000 -0500
@@ -5,6 +5,7 @@
 GLIBCXX_3.4.2 OBJECT GLOBAL DEFAULT 0
 GLIBCXX_3.4.3 OBJECT GLOBAL DEFAULT 0
 GLIBCXX_3.4.4 OBJECT GLOBAL DEFAULT 0
+GLIBCXX_3.4.5 OBJECT GLOBAL DEFAULT 0
 _ZGVNSt10moneypunctIcLb0EE2idE@@GLIBCXX_3.4 OBJECT WEAK DEFAULT 8
 _ZGVNSt10moneypunctIcLb1EE2idE@@GLIBCXX_3.4 OBJECT WEAK DEFAULT 8
 _ZGVNSt10moneypunctIwLb0EE2idE@@GLIBCXX_3.4 OBJECT WEAK DEFAULT 8
@@ -115,7 +116,8 @@
 _ZNK11__gnu_debug16_Error_formatter8_M_errorEv@@GLIBCXX_3.4 FUNC GLOBAL DEFAULT
 _ZNK11__gnu_debug19_Safe_iterator_base11_M_singularEv@@GLIBCXX_3.4 FUNC GLOBAL 
DEFAULT
 _ZNK11__gnu_debug19_Safe_iterator_base14_M_can_compareERKS0_@@GLIBCXX_3.4 FUNC 
GLOBAL DEFAULT
-_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
+_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw@@GLIBCXX_3.4.5 FUNC GLOBAL 
DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwj@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofEPKwjj@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofERKS2_j@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
@@ -125,7 +127,8 @@
 _ZNKSbIwSt11char_traitsIwESaIwEE13find_first_ofERKS2_j@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE13find_first_ofEwj@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE13get_allocatorEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
-_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEjjPKc@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
+_ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthEjjPKc@@GLIBCXX_3.4.5 FUNC 
GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE16find_last_not_ofEPKwj@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE16find_last_not_ofEPKwjj@@GLIBCXX_3.4 FUNC 
WEAK DEFAULT
 _ZNKSbIwSt11char_traitsIwESaIwEE16find_last_not_ofERKS2_j@@GLIBCXX_3.4 FUNC 
WEAK DEFAULT
@@ -174,7 +177,8 @@
 _ZNKSi6gcountEv@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSi6sentrycvbEv@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSo6sentrycvbEv@@GLIBCXX_3.4 FUNC WEAK DEFAULT
-_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4 FUNC WEAK DEFAULT
+_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5 FUNC GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSs12find_last_ofEPKcj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs12find_last_ofEPKcjj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs12find_last_ofERKSsj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
@@ -184,7 +188,8 @@
 _ZNKSs13find_first_ofERKSsj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs13find_first_ofEcj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs13get_allocatorEv@@GLIBCXX_3.4 FUNC WEAK DEFAULT
-_ZNKSs15_M_check_lengthEjjPKc@@GLIBCXX_3.4 FUNC WEAK DEFAULT
+_ZNKSs15_M_check_lengthEjjPKc@@GLIBCXX_3.4.5 FUNC GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSs16find_last_not_ofEPKcj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs16find_last_not_ofEPKcjj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
 _ZNKSs16find_last_not_ofERKSsj@@GLIBCXX_3.4 FUNC WEAK DEFAULT
@@ -331,21 +336,27 @@
 _ZNKSt13basic_filebufIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSt13basic_filebufIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSt13basic_fstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
-_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
+_ZNKSt13basic_fstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5 FUNC 
GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSt13basic_fstreamIwSt11char_traitsIwEE5rdbufEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
-_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
+_ZNKSt13basic_fstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4.5 FUNC 
GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSt13basic_istreamIwSt11char_traitsIwEE6gcountEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSt13basic_istreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSt13basic_ostreamIwSt11char_traitsIwEE6sentrycvbEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
 _ZNKSt13runtime_error4whatEv@@GLIBCXX_3.4 FUNC GLOBAL DEFAULT
 _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE5rdbufEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
-_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
+_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@@GLIBCXX_3.4.5 FUNC 
GLOBAL DEFAULT
[EMAIL PROTECTED] FUNC GLOBAL DEFAULT
 _ZNKSt14basic_ifstreamIwSt11char_traitsIwEE5rdbufEv@@GLIBCXX_3.4 FUNC WEAK 
DEFAULT
-_ZNKSt14basic_ifstreamIwSt11char_traitsIwEE7is_openEv@@GLIBCXX_3.4 FU

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Darn me all the heck. I said I wasn't going to say anything more... bad
Scott, bad Scott!

> again and again and again and again (which i'm sure you'll say is us
> "not listening to the user community", which is not the case).

I hate to disappoint you, but those words won't grace this message. I
understand the frustration.

> We've also had people write to other mailing lists and say "plesae
> mail-bomb the gcc list so they'll listen to us"

And I have a homeless guy in Berkeley who takes great satisfaction in
raking anything I do over the coals in various Usenet groups. We all
have our crosses to bear...

> ...we've become very unfriendly about the small number of people who
> contend again and again that we should do it different, claiming simply
> that any viewpoint than theirs is *wrong* and *bad* instead of "a
> tradeoff that has been chosen".  And they are *not* particularly polite
> about it.

My silly goal is to try an accomodate all viewpoints; providing a
solution for bug 323 (for infamous example) could remove an irritant for
all sides. Wouldn't that be a Good Thing?

..Scott
(Who really will shut up now, until he presents some code.)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Scott Robert Ladd <[EMAIL PROTECTED]> writes:

| > I think what gets peoples' blood pressure up is
| > endless discussion about how they ought to do their
| > business.
| 
| Try publishing a compiler review, and listen to the kibitzers. :)
| 
| I've been writing for publication all my adult life; just because people
| don't like what you write (software or prose) is no reason to be rude.
| They might actually have valid points...

Well, some of the GCC developers have been publishing in their adult
life too.  I guess, the real issue as far as GCC is concerned must be
somewhere else.  Reasonable people with fair technical backgrounds can
look at the same problems and come up with different conclusions. 

Sometimes, some people come to GCC developers with the assumptions
that they must be obscure ignorant and miles-of-code-writers-without-
thinking and as such are very willing to endlessly lecture them about
how ignorant they are and how they should do their jobs.  That can not
only irritate but also contribute to "blood pressure".  Furthermore,
it is also assumed that since people working on GCC earn part of their 
business on working on GCC, they de facto become slaves of the 
lecturer/manager-du-jour.  

That is not meant to excuse what you perceive to be rudeness, but to
point out that the communication channel works both ways.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Daniel Berlin wrote:
> If you consider that "unfriendly", then you really need to get out of
> the development business, because you need a thicker skin.

Oh, my skin's thick enough. And my skull, too. :) Perhaps there is
misinterpretation all around.

..Scott

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

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


Daniel Berlin wrote:

Again, *please* provide examples other than "The bugmasters are mean".


Don't invent quotes. I never said anyone was "mean." And other people
have provided explicitly links to germane bugs.


Four out of how many?
The explantion for all of those four:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
"
Note GCC does not know about the rounding mode, in fact the round mode 
is only changeable in C99
by the #pragma which GCC does not do right now and I thought that is a 
different PR already."


How could this be considered rude, I was just stating a fact.


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

"
Note neg just flips a bit so it is correct anyways and there is no loss 
of precession.


This also happens on ppc darwin, I don't know what to make of this.  A 
C person has to comment to say

something about this.
"

I said someone else has to comment on this, so I was saying I don't 
know for sure.


  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
Huh, there was no negative thing in there at all from me or either 
Wolfgang.
Maybe "This should be low priority, since we only accept invalid code. 
"  but Wolfgang

found a rejects valid case in about an hour.

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
This is the only one which was closed, in fact I still think it should 
be a warning

unconditional.

As you can see that from above, only one really shows the case and it 
was corrected

and JSM gave a better way of doing it.

-- Hitler (just to stop this thread)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Sometimes, some people come to GCC developers with the assumptions
> that they must be obscure ignorant and miles-of-code-writers-without-
> thinking and as such are very willing to endlessly lecture them about
> how ignorant they are and how they should do their jobs.

I have never considered GCC developers to be ignorant, and perhaps what
I perceive as "rudeness" is in fact frsutration accumulated over many
years. If anything, this is one of the brightest developer groups.

> That is not meant to excuse what you perceive to be rudeness, but to
> point out that the communication channel works both ways.

A good point. I shall attempt to be a bit less sensitive and more
understanding, on the assumption that others will return the favor.

..Scott

problemns confgire/build gcc/libstdc++ for ColdFire v4e

[Peter Barada]

I'm tyring to cross-build a linux toolchain for a ColdFire v4e, where
I have to pass -mcfv4e to the compiler to select the ColdFire v4e, as
well as the linker(to make sure it picks the right library), and I 
have this working for when building gcc-3.4.3 with --languages=c, but
when I try to build for --languages=c,c++, it fails while building
libstdc++.

What is the preferred method of configuring gcc such that options will
passed to the cross-compiler, as well as the linker when building libraries?

The reason I need to pass options is that the ColdFire is a variant of
the m68k, and needs options to select ColdFire specific behavior.

Thanks in advance!

-- 
Peter Barada
[EMAIL PROTECTED]

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

[Jakub Jelinek]

On Thu, Jun 16, 2005 at 05:10:49PM +0200, Eric Botcazou wrote:
> The diff is attached.

Except that
-_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEil@@GLIBCXX_3.4 FUNC GLOBAL 
DEFAULT
the diff just shows the expected 24 changes of @@GLIBCXX_3.4 symbols
to @GLIBCXX_3.4 + @@GLIBCXX_3.4.5 and 2 additions of symbols
to both @GLIBCXX_3.4 + @@GLIBCXX_3.4.5 (those 2 are what appeared
in GCC 3.4.4).
And that one should be fixed by the patch I posted, so Solaris
should be hopefully fine.

Jakub

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Andrew Pinski wrote:
> Four out of how many?

This can not be measured (ie unpredictable), unless
you suggesting you are 100% deterministic on every new
bug presented to you.







___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 08:20:20 -0400, Daniel Berlin wrote:
> You deny that Bug 21809 is the same bug as Bug 323, which was closed
> in 1999?

Yes: Bug 323 as originally reported is really invalid. The C standard
doesn't guarantee that y and y2 should exactly be the same value.
However bug 21809 (like *some* other bugs duplicated to bug 323) shows
a bug in the compiler, since a variable must not have a precision (or
range) larger than the one specified by the type. A fix is *possible*:
just store the value to memory after a cast or an assignment. Of
course, this wouldn't necessarily be efficient, but there could be
options to allow the compiler to have a non-comforming behavior. Or
the user could get a processor that behaves differently.

Dynamical extended precision is allowed by IEEE-754 and a part of
the specifications of the x86 processors. So, you can't say that
such processors are buggy.

On 2005-06-16 10:11:39 -0400, Mark Hahn wrote:
> the question then becomes whether GCC is helped or harmed by 
> its current policy of unpredictable excess precision.

BTW, unpredictability, such as in bug 323, is not a bug (according
to the C standard). This may be seen as a bad behavior and changing
this behavior would be a great improvement, but I don't complain
about it here when saying "bug".

> the only constructive comment in this thread so far has been that libm
> might somehow rely on EP (ie can't use the _FPU_SET_CW workaround).
> which code is this?  I'd guess it might be related to using series 
> approximations, and the code could either set CW or accept 64b results.

Or the code could be changed: glibc has code that is guaranteed to
work in double precision (modulo some bugs), since it is used on
processors that have no extended precision.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 08:12:24 -0400, Daniel Berlin wrote:
> I should also note that *you* seem to equate "disagreement with your
> viewpoint" with "wrong", "obstinate", or "ignorant", which is not the
> case.  Just because someone disagrees with your views on floating point
> does not make them wrong, stupid, or people who don't want to listen.
> It means they disagree with your viewpoint.

This is not my viewpoint, but what the C standard says.

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

Re: The tree API

[James A. Morrison]

Rafael Espíndola <[EMAIL PROTECTED]> writes:

> On 6/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > 
> > 
> > Hello~ every one :)
> > 
> > I'm a new guy in gcc mailing list
> > I've been studying gcc for 2 months.
> > I read "GNU compiler collection internals" (for GCC 3.5.0?),
> > and I also trace the source code for target-mips.
> > My problem is there are so much symbol/function/API in gcc.
> > Some are documentated in the book but not all of them.
> > All I can do is modified it, rebuild and see what's happend.
> > This approach is not effective.
> > If there is a way to learn the gcc internal APIs "systematically"?
> 
> I think that I can help since I am having the same problem :)
> 
> The best references that I can give you is the GCC Frontend HOWTO at
> http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html. It is based on a
> old gcc, but most of the tree structure still applies.

 Don't forget the GENERIC and GIMPLE documentation at
http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA
 
> Two colleges and I are working on a minimal "hello world" front end
> for gcc. You can find a alpha version at
> http://ltc08.ic.unicamp.br/svn/scheme/branches/hello-world
> 
> I also recommend that you take a look at treelang. It is quite simpler
> than the others frontends in gcc.
> 
> I hope this helps,
> Rafael Ávila de Espíndola
> 


-- 
Thanks,
Jim

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Vincent Lefevre wrote:


BTW, unpredictability, such as in bug 323, is not a bug (according
to the C standard). This may be seen as a bad behavior and changing
this behavior would be a great improvement, but I don't complain
about it here when saying "bug".


Everyone would agree that per se unnecessary non-determinism is a
bad thing. However, most people would also agree that poor performance
is a bad thing.

All this stuff about allowing extra precision is actually about
allowing efficient code.

Lacking in this discussion is a good quantitative measurement
over a reasonable set of benchmarks as to what eliminating the
excess precision in all cases would cost.

Note that just setting the precision to 64-bits is not enough if
you agree with Vincent that 32-bit float variables have to be
normalized on every assignment.

Data would help. Almost everyone will agree with eliminating the
extra precision if it has only a 3% impact, almost everyone
will disagree if it doubles execution time (I suspect the asnwer
is in that range :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[E. Weddington]

Scott Robert Ladd wrote:


1) Bugmasters could be less perfunctory and pejorative in their
comments. Examples have been given.

 




Quoting ESR these days is perhaps not really in vogue, but I've always 
found this document to be extremely helpful:



Specifically, this section:

which I think is very applicable both to bug comments as well as the gcc 
list and this thread in particular. ;-)



2) A mentoring system could help bring along new GCC developers. I'm not
talking about hand-holding, I'm suggesting that having some place for
people to ask a few questions, one on one, to get over certain
conceptual humps.
 



Geez, I've seen this happen many a time on the gcc list. Jim Wilson, in 
particular, I've noticed does a tremendous job in helping new people out 
by pointing them in the right direction (IMHO). Why should something new 
be created?


Anyway, I'll go back to lurking now.

Eric

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 10:11 AM, Mark Hahn wrote:


I'm answering that since this is plainly wrong. Bug 21809 was
closed by yourself on 2005-05-29. This is not 1999!


You deny that Bug 21809 is the same bug as Bug 323, which was closed 
in

1999?

Again, this is a place where you disagree that this should be 
considered

a "bug", but refuse to believe that reasonable people can disagree on
it.


the question then becomes whether GCC is helped or harmed by
its current policy of unpredictable excess precision.

it's quite unfortunate that gcc responders feel so free to vent
their annoyance about this.  Pinski, for instance, is absurdly
unhelpful in suggesting that the bug reporter just abandon x87.


Well abandoning x87 was a joke, I was trying to get the point across
that this is long standing "problem" with x87.  If you go and search
you will see this comes up every year since at least 1998 before
EGCS was officially GCC.

-- Pinski

build fails for 1st pass gcc 3.4.4 target=m68k-elf host=build=x86_64

[Thomas Brinker]

Hello!

I try to build a cross gcc3.4.4 but it fails:
Everything is vanilla, without patches.

__Configure_


[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build$ 
../gcc-3.4.4/configure --enable-languages=c --disable-libmudflap --disable-nls 
--target=m68k-elf --prefix=/opt/emlix/gcc-3.4.4-m68k-x86_64/
creating cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... m68k-unknown-elf
checking build system type... x86_64-unknown-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
*** This configuration is not supported in the following subdirectories:
 target-libstdc++-v3
(Any other directories should still work fine.)
checking for x86_64-unknown-linux-gnu-ar... no
checking for ar... ar
checking for x86_64-unknown-linux-gnu-as... no
checking for as... as
checking for x86_64-unknown-linux-gnu-dlltool... no
checking for dlltool... dlltool
checking for x86_64-unknown-linux-gnu-ld... no
checking for ld... ld
checking for x86_64-unknown-linux-gnu-nm... no
checking for nm... nm
checking for x86_64-unknown-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for x86_64-unknown-linux-gnu-windres... no
checking for windres... windres
checking for x86_64-unknown-linux-gnu-objcopy... no
checking for objcopy... objcopy
checking for x86_64-unknown-linux-gnu-objdump... no
checking for objdump... objdump
checking for m68k-elf-ar... m68k-elf-ar
checking for m68k-elf-as... m68k-elf-as
checking for m68k-elf-dlltool... no
checking for m68k-elf-ld... m68k-elf-ld
checking for m68k-elf-nm... m68k-elf-nm
checking for m68k-elf-ranlib... m68k-elf-ranlib
checking for m68k-elf-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
updating cache ./config.cache
creating ./config.status
creating Makefile

make_


[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build$ make
[...shorten...]
/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build/gcc/xgcc 
-B/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build/gcc/ 
-B/opt/emlix/gcc-3.4.4-m68k-x86_64//m68k-elf/bin/ 
-B/opt/emlix/gcc-3.4.4-m68k-x86_64//m68k-elf/lib/ -isystem 
/opt/emlix/gcc-3.4.4-m68k-x86_64//m68k-elf/include -isystem 
/opt/emlix/gcc-3.4.4-m68k-x86_64//m68k-elf/sys-include -O2  -DIN_GCC 
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g  
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. 
-I../../gcc-3.4.4/gcc -I../../gcc-3.4.4/gcc/. -I../../gcc-3.4.4/gcc/../include  
 -m68000 -DL_fixdfdi -c ../../gcc-3.4.4/gcc/libgcc2.c -o 
libgcc/m68000/_fixdfdi.o
../../gcc-3.4.4/gcc/libgcc2.c: In function `__fixdfdi':
../../gcc-3.4.4/gcc/libgcc2.c:1277: internal compiler error: in do_SUBST, at 
combine.c:447
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [libgcc/m68000/_fixdfdi.o] Error 1
make[2]: Leaving directory 
`/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory 
`/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build/gcc'
make: *** [all-gcc] Error 2

_Versions


[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc/gcc-3.4.4_build$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-linux/3.4.4/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 
--enable-shared --with-system-zlib --enable-nls --without-included-gettext 
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm 
--enable-java-awt=gtk --disable-werror x86_64-linux
Thread model: posix
gcc version 3.4.4 20050209 (prerelease) (Debian 3.4.3-9ubuntu4)

[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc$ uname -a
Linux lauch 2.6.11.7 #1 SMP Mon Jun 13 18:31:28 CEST 2005 x86_64 GNU/Linux

[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc$ echo $PATH
/opt/emlix/gcc-3.4.4-m68k-x86_64/bin/:[...shorten...]

[EMAIL PROTECTED]:/mnt/data/emlix/tbrinker/64bit-tc$ 
/opt/emlix/gcc-3.4.4-m68k-x86_64/bin/m68k-elf-ld -v
GNU ld version 2.16

__


Please CC me, I'm not on the list!

Best regards
Thomas

Re: build fails for 1st pass gcc 3.4.4 target=m68k-elf host=build=x86_64

[Andrew Pinski]

On Jun 16, 2005, at 12:34 PM, Thomas Brinker wrote:


Hello!

I try to build a cross gcc3.4.4 but it fails:
Everything is vanilla, without patches.


This looks like PR 22001: .

Thanks,
Andrew Pinski

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

On Jun 16, 2005, at 1:30 AM, Mike Stump wrote:


 Please try something like:
...
and let me know if it works.


Thank you, I will try it today.

Last night I unconditionally allowed multilibs and configured with

Compiler version: 4.1.0 20050615 (experimental)
Platform: powerpc-apple-darwin8.1.0
configure flags: --prefix=/pkgs/gcc-4.0-mainline  
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3  
--enable-languages=c,c++,f95,objc,obj-c++

BOOT_CFLAGS=-g -O2 -mdynamic-no-pic

There were many -m64 failures in some of the testsuites; e.g.,

=== g++ Summary for unix/-m64 ===

# of expected passes8438
# of unexpected failures1370
# of expected failures  60
# of unresolved testcases   68
# of unsupported tests  114
...
=== gfortran Summary for unix/-m64 ===

# of expected passes517
# of unexpected failures3320
# of unexpected successes   3
# of expected failures  9
# of untested testcases 1472
# of unsupported tests  17
...
=== objc Summary for unix/-m64 ===

# of expected passes493
# of unexpected failures576
# of unresolved testcases   533
# of unsupported tests  1

It seems that the 64-bit libgcc_s can't be found many times; a typical  
failure from the top of the c++ test suite looks like


Test Run By lucier on Wed Jun 15 21:35:15 2005
Native configuration is powerpc-apple-darwin8.1.0

=== g++ tests ===

Schedule of variations:
unix/-m64
unix

Running target unix/-m64
Using /pkgs/dejagnu/share/dejagnu/baseboards/unix.exp as board  
description file for target.
Using /pkgs/dejagnu/share/dejagnu/config/unix.exp as generic interface  
file for target.
Using  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/config/ 
default.exp as tool-and-target-specific interface file.
Running  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/g++.dg/bprob/ 
bprob.exp ...
set_ld_library_path_env_vars:  
ld_library_path=.:/Users/lucier/programs/gcc/gcc-mainline/objdir/ 
powerpc-apple-darwin8.1.0/ppc64/libstdc++-v3/src/.libs:/Users/lucier/ 
programs/gcc/gcc-mainline/objdir/gcc
ALWAYS_CXXFLAGS set to {additional_flags=-nostdinc++  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include/powerpc-apple-darwin8.1.0  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite}  
{ldflags=  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/src/.libs  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libiberty } additional_flags=-fmessage-length=0  
{ldflags=-multiply_defined suppress}
Executing on host:  
/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../g++  
-B/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../  
/Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/g++.dg/bprob/g++- 
bprob-1.C  -nostdinc++  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include/powerpc-apple-darwin8.1.0  
-I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/include  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward  
-I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite  
-fmessage-length=0  -g   -fprofile-arcs 
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libstdc++-v3/src/.libs  
-L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple- 
darwin8.1.0/ppc64/libiberty  -multiply_defined suppress -lm   -m64 -o  
/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/g++-bprob 
-1.x01(timeout = 300)

ld64 failed: library not found for -lgcc_s_ppc64^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld64 failed: library not found for -lgcc_s_ppc64^M
collect2: ld returned 1 exit status^M

even though

[descartes:gcc/gcc-mainline/objdir] lucier% find . -name 'libgcc_s*'
./gcc/libgcc_s.1.0.dylib
./gcc/libgcc_s.1.0.dylib.backup
./gcc/libgcc_s.dylib
./gcc/libgcc_s_ppc64.1.0.dylib
./gcc/libgcc_s_ppc64.1.0.dylib.backup
./gcc/libgcc_s_ppc64.dylib
...

Is the testsuite failing to set up to set the DYLD_LIBRARY_PATH  
appropriately?


Brad

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Roberto Bagnara]

Andrew Pinski wrote:
>
> On Jun 16, 2005, at 10:58 AM, Scott Robert Ladd wrote:
>
>> Daniel Berlin wrote:
>>
>>> Again, *please* provide examples other than "The bugmasters are mean".
>>
>>
>> Don't invent quotes. I never said anyone was "mean." And other people
>> have provided explicitly links to germane bugs.
>
>
> Four out of how many?
> The explantion for all of those four:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
> "
> Note GCC does not know about the rounding mode, in fact the round mode
> is only changeable in C99
> by the #pragma which GCC does not do right now and I thought that is a
> different PR already."
>
> How could this be considered rude, I was just stating a fact.

First, I would like to clarify I do not consider it rude.

But I do not consider it a good thing that, after this superficial comment
of yours, you did not even care to reply to my further arguments and question.
This is precisely the kind of behavior that frustrates me and, I guess,
frustrates most other bug reporters.

>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032
>
> "
> Note neg just flips a bit so it is correct anyways and there is no loss
> of precession.
>
> This also happens on ppc darwin, I don't know what to make of this.  A C
> person has to comment to say
> something about this.
> "
>
> I said someone else has to comment on this, so I was saying I don't know
> for sure.

You said something incorrect ("Note neg just flips a bit so it is correct
anyways and there is no loss of precession"), then again you failed to reply
to an explicit question and to further arguments I added.  You also failed
to reply when I pointed out, in another comment, that this was indeed
a regression from 3.3.  Then leaving the bug UNCONFIRMED for months...
OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.

>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
> Huh, there was no negative thing in there at all from me or either
> Wolfgang.
> Maybe "This should be low priority, since we only accept invalid code.
> "  but Wolfgang
> found a rejects valid case in about an hour.

That link was included by mistake, in fact.  I apologize.

>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
> This is the only one which was closed, in fact I still think it should
> be a warning
> unconditional.

As I said above, perhaps it is the word "bugmaster" that should be changed.
It is hard to believe that a master can advocate an unconditional,
architecture-dependent warning that a user cannot switch off without
switching of _all_ the other warnings and that can only be avoided
by writing non-portable code.  This concerning the substance.
Concerning the form, you closed the bug without even caring, again,
to address the points I raised and the explicit questions I have asked.

To summarize, why should I, simple user, spend hours investigating a
suspicious behavior of GCC when you, bugmaster,  take the liberties
of giving superficial and/or wrong answers without even apologizing,
of not answering altogether, of not looking at the standard documents,
of not even reading carefully what me and others write?  It is not
a matter of rudeness, but rather a matter of technical and social
carelessness.  Why you seem to feel an obligation to intervene
on bug reports for which you appear to have neither the competences
nor a willingness to obtaining them by careful consideration of
the issues that are brought to your attention and of the standards?

Now please do not tell me that you are a volunteer: we all are
volunteers here and we are all contributing to Free Software in
one way or another.  Being a volunteer is not an excuse for not
paying attention to the technical and human aspects of our
volunteer work.

> -- Hitler (just to stop this thread)

I don't believe that stopping the thread would solve the problem.
You probably want to say that continuing it would not solve it
either.  This is sad, if it means we have to live with it...
All the best,

Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 16, 2005, at 1:26 PM, Roberto Bagnara wrote:


First, I would like to clarify I do not consider it rude.

But I do not consider it a good thing that, after this superficial 
comment
of yours, you did not even care to reply to my further arguments and 
question.

This is precisely the kind of behavior that frustrates me and, I guess,
frustrates most other bug reporters.


This is not a superficial comment, my whole point with that comment
is that GCC does not __currently__ implement any other rounding mode
than the default one which is not what you want but hey it is what GCC
currently does.

You said something incorrect ("Note neg just flips a bit so it is 
correct
anyways and there is no loss of precession"), then again you failed to 
reply
to an explicit question and to further arguments I added.  You also 
failed

to reply when I pointed out, in another comment, that this was indeed
a regression from 3.3.  Then leaving the bug UNCONFIRMED for months...
OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.


That is because I said someone else needs to look into it (a C "lawyer"
person who is on the standards committee).  Also again GCC
__currently__ implements one rounding mode and this is current for that
rounding mode.  And actually neg does just a flip a bit according to the
standard.  Now rounding modes are weird and should be implemented in GCC
but __currently__ they are not have not been since day one before there
was a C standard.


For the last one, the warning is correct, yes and is actually useful for
most people.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

> 
> 
> On Jun 16, 2005, at 1:26 PM, Roberto Bagnara wrote:
> 
> > First, I would like to clarify I do not consider it rude.
> >
> > But I do not consider it a good thing that, after this superficial 
> > comment
> > of yours, you did not even care to reply to my further arguments and 
> > question.
> > This is precisely the kind of behavior that frustrates me and, I guess,
> > frustrates most other bug reporters.

Oh, only just people who file floating point "bugs" because that is the hardest
to get right in any compiler.

-- Pinski

x86-linux bootstrap broken on mainline?

[Laurent GUERBY]

stage1/xgcc -Bstage1/ 
-B/home/guerby/work/gcc/install/install-20050616T132922/i686-pc-linux-gnu/bin/ 
-c   -O2 -g -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-Wno-variadic-macros -Wold-style-definition -Werror -fno-common   
-DHAVE_CONFIG_H-I. -I. -I/home/guerby/work/gcc/version-head/gcc 
-I/home/guerby/work/gcc/version-head/gcc/. 
-I/home/guerby/work/gcc/version-head/gcc/../include 
-I/home/guerby/work/gcc/version-head/gcc/../libcpp/include  \
/home/guerby/work/gcc/version-head/gcc/config/i386/i386.c -o i386.o
/home/guerby/work/gcc/version-head/gcc/config/i386/i386.c: In function 
'ix86_expand_builtin':
/home/guerby/work/gcc/version-head/gcc/config/i386/i386.c:15127: internal 
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [i386.o] Error 1

It looks like the only patch between my last successful bootstrap and the 
current failure is
the following, am I alone in seeing this?

Laurent

$ cvs diff -u -D 'Wed Jun 15 21:20:45 UTC 2005' -D 'Thu Jun 16 11:26:54 UTC 
2005' ChangeLog
Index: ChangeLog
===
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 2.9159
retrieving revision 2.9161
diff -u -r2.9159 -r2.9161
--- ChangeLog   15 Jun 2005 20:13:04 -  2.9159
+++ ChangeLog   16 Jun 2005 10:31:51 -  2.9161
@@ -1,3 +1,59 @@
+2005-06-16  Jan Hubicka  <[EMAIL PROTECTED]>
+
+   * basic-block.h (rtl_bb_info): Break out head_, end_,
+   global_live_at_start, global_live_at_end from ...
+   (basic_block_def): ... here; update all references
+   (BB_RTL): New flag.
+   (init_rtl_bb_info): Declare.
+   * cfgexpand.c (expand_gimple_basic_block): Init bb info, set BB_RTL
+   flag.
+   * cfgrtl.c: Include ggc.h
+   (create_basic_block_structure): Init bb info.
+   (rtl_verify_flow_info_1): Check BB_RTL flag and rtl_bb_info pointer.
+   (init_rtl_bb_info): New function.
+   (rtl_merge_block, cfglayout_merge_block): Copy global_live_at_end here.
+   * cfghooks.c (merge_block): Do not copy global_live_at_end here.
+   * cfg.c (clear_bb_flags): Skip BB_RTL flag.
+   (dump_flow_info): Gueard global_live_* dumping.
+
+   * Makefile.in (cfg.o): Add new dependencies.
+   * basic-block.h (reorder_block_def): Kill
+   original/copy/duplicated/copy_number fields.
+   (BB_DUPLICATED): New flag.
+   (initialize_original_copy_tables, free_original_copy_tables,
+   set_bb_original, get_bb_original, set_bb_copy, get_bb_copy): New.
+   * cfg.c: Include hashtab.h and alloc-pool.h
+   (bb_original, bb_copy, original_copy_bb_pool): New static vars.
+   (htab_bb_copy_original_entry): New struct.
+   (bb_copy_original_hash, bb_copy_original_eq): New static functions.
+   (initialize_original_copy_tables, free_original_copy_tables,
+   set_bb_original, get_bb_original, set_bb_copy, get_bb_copy): New
+   global functions.
+   * cfghooks.c (duplicate_block): Update original/copy handling.
+   * cfglayout.c (fixup_reorder_chain): Likewise.
+   (cfg_layout_initialize): Initialize orignal_copy tables.
+   (cfg_layout_finalize): FInalize original_copy tables.
+   (can_copy_bbs_p): Use BB_DUPLICATED flag.
+   (copy_bbs): Likewise.
+   * cfgloopmanip.c (update-single_exits_after_duplication): Likewise.
+   (duplicate_loop_to_header_edge): Likewise; update handling of
+   copy_number.
+   (loop_version): Likewise.
+   * dominance.c (get_dominated_by_region): Use BB_DUPLICATED_FLAG.
+   * except.c (expand_resx_expr): Check that reg->resume is not set.
+   * loop-unroll.c (unroll_loop_constant_iterations,
+   unroll_loop_runtime_iterations, apply_opt_in_copies): Update
+   copy/original handling.
+   * loop-unwitch.c (unswitch_loop): Likewise.
+   * tree-cfg.c (create_bb): Do not initialize RBI.
+   (disband_implicit_edges): Do not kill RBI.
+   (add_phi_args_after_copy_bb): Use new original/copy mapping.
+   (add_phi_args_after_copy): Use BB_DUPLICATED flag.
+   (tree_duplicate_sese_region): Update original/copy handling.
+   * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Likewise.
+   * tree-ssa-loop-manip.c (copy_phi_node_args): Likewise.
+   * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Likewise.
+

Re: Porposal: Floating-Point Options

[Geoffrey Keating]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Tue, 14 Jun 2005, Geoffrey Keating wrote:
> 
> > So, what I think you want to do is to add another flag under
> > -ffast-math, perhaps called -fwiden-math, which specifically allows
> > the compiler to compute values in a wider mode (that would be 80-bit
> > x87 FP) even when ISO C doesn't allow it.  You would have this flag on
> > by default on x86.
> 
> I suggest the name -fno-float-store, since -ffloat-store is the flag meant 
> to yield better conformance with the standard requirements for excess 
> precision (which only does so for explicit assignments at present).

Although it does do some of this, -ffloat-store also has some rather nasty
side-effects, because of what it is actually documented to do:

> @item -ffloat-store
> @opindex ffloat-store
> Do not store floating point variables in registers, and inhibit other
> options that might change whether a floating point value is taken from a
> register or memory.

For instance, on powerpc, the flag should be a no-op, but
-ffloat-store is certainly not a no-op on powerpc.  Likewise, the flag
should be a no-op if SSE2 instructions are being used for arithmetic
(in fact, it should cause that to happen if the instructions are
available).

> Implementation outline: stop x86 back end from claiming to support 
> float/double operations when it doesn't; teach C and C++ front ends to 
> distinguish two types for an expression, the type used for computation 
> (always long double for x87 floating point) and the logical type at the C 
> language level; ensure that in conforming mode all conversions from long 
> double to double or float are executed properly but in nonconforming mode 
> allow them to be discarded; ensure that -ansi / -std=c89 / -std=c99 / ... 
> enable -ffloat-store on platforms with excess precision.

I think this is a good implementation outline, except that the flag
setting should not vary depending on the backend.  Users should be able
to say "I want FP without widening" or "I want FP and don't mind
widening" portably.

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

[Mark Mitchell]

Volker Reichelt wrote:

Hi Mark,

you wrote



Those who have been watching carefully will note that there is no sign of an 
actual
4.0.1 release.



since the branch has been frozen for quite sime time now, a lot of patches
for the 4.0 branch have piled up.

Given the facts that
a) we'll have another relaese candidate anyway
b) many of these patches have seen some testing on mainline
   (and some even on the 3.4 branch)
c) they fix regressions
   (some of them are even wrong-code like PR 21850)
d) the release would already be outdated otherwise
e) if problems showed up with the patches for users we could address
   them in 4.0.2 and not just 4.0.3

wouldn't it make sense to commit the pending patches?

It would be as if you froze the branch a week later ;-)


The point of a freeze is so that we stop changing things. :-)

However, I'm willing to consider specific patches for wrong-code 
regressions.  In particular, the patch for PR 21850 is OK.


Thanks,

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 12:12:26 -0400, Robert Dewar wrote:
> Everyone would agree that per se unnecessary non-determinism is a
> bad thing.

Yes, but not all people would agree on the meaning of "necessary"
(for performance? for security?).

> However, most people would also agree that poor performance
> is a bad thing.

Getting incorrect results is even worse. Anyway a bug isn't invalid
just because fixing it would make the code less efficient.

> All this stuff about allowing extra precision is actually about
> allowing efficient code.
> 
> Lacking in this discussion is a good quantitative measurement
> over a reasonable set of benchmarks as to what eliminating the
> excess precision in all cases would cost.

Why not compile benchmarks with options that allow to keep
extra precision?

Also fixing the bug would not necessarily make code less efficient.
2 solutions:
  * A diagnostic is sufficient.
  * Not declaring that the compiler is conforming to the C standard
would also be sufficient.

Whether this should be done by default or not could be discussed
later (the behavior could be different depending on FP-related
standard pragmas or options like -std=c99).

> Note that just setting the precision to 64-bits is not enough if
> you agree with Vincent that 32-bit float variables have to be
> normalized on every assignment.

I agree. This would not fix the bug, but make it less visible.
This would thus be an improvement.

> Data would help. Almost everyone will agree with eliminating the
> extra precision if it has only a 3% impact, almost everyone
> will disagree if it doubles execution time (I suspect the asnwer
> is in that range :-)

What about having the choice?

Anyway, if the only reason is the performance, then the bug shouldn't
have been marked as INVALID (the SUSPENDED status is for such kind of
problems -- and SUSPENDED doesn't mean that the bug is resolved).

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 12:34:27 -0400, Andrew Pinski wrote:
> Well abandoning x87 was a joke, I was trying to get the point across
> that this is long standing "problem" with x87.  If you go and search
> you will see this comes up every year since at least 1998 before
> EGCS was officially GCC.

In the bug report, it didn't look at the joke. Anyway, one could also
say that floating-point arithmetic (not only binary one) is a long
standing problem. See for instance

  https://bugzilla.mozilla.org/show_bug.cgi?id=5856

and all the duplicates (and this one is really an invalid bug).

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 13:37:23 -0400, Andrew Pinski wrote:
> This is not a superficial comment, my whole point with that comment
> is that GCC does not __currently__ implement any other rounding mode
> than the default one which is not what you want but hey it is what GCC
> currently does.

Based on this comment, shouldn't the bug have been marked as NEW or
SUSPENDED?

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

Re: Porposal: Floating-Point Options

[Joseph S. Myers]

On Thu, 16 Jun 2005, Geoffrey Keating wrote:

> Although it does do some of this, -ffloat-store also has some rather nasty
> side-effects, because of what it is actually documented to do:
> 
> > @item -ffloat-store
> > @opindex ffloat-store
> > Do not store floating point variables in registers, and inhibit other
> > options that might change whether a floating point value is taken from a
> > register or memory.

But is this actually a useful thing for users to be able to control, other 
than for its effects in avoiding excess precision?  If not - if the real 
uses of it are for the same purpose as gcc.c-torture/execute/ieee/ieee.exp 
uses it on x86, x86_64 -m32 and m68k, to avoid excess precision - then we 
can just repurpose this option and make it a no-op on systems which 
naturally don't need excess precision, and users using -ffloat-store right 
now to avoid excess precision will find their code gets improved 
correctness.

-- 
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: Porposal: Floating-Point Options

[Menezes, Evandro]

> If this option makes it into GCC, maybe it could be named 
> -O3_unsafe.

How about the popular -fast?


-- 
___
Evandro MenezesAMD   Austin, TX

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Mike Stump]

On Jun 16, 2005, at 10:04 AM, Bradley Lucier wrote:

On Jun 16, 2005, at 1:30 AM, Mike Stump wrote:

 Please try something like:
...
and let me know if it works.


Thank you, I will try it today.


Actually, by try, I meant try your application.  :-)


Last night I unconditionally allowed multilibs and configured with



ld64 failed: library not found for -lgcc_s_ppc64


:-(

Is the testsuite failing to set up to set the DYLD_LIBRARY_PATH  
appropriately?


Don't worry about this, I think this won't hit the use of the tool,  
only the testing of the tool.


I see can't find share library problems on mainline on linux as well,  
so, certainly, there are issues there that have yet to be fixed.

Re: Porposal: Floating-Point Options

[Gabriel Dos Reis]

"Menezes, Evandro" <[EMAIL PROTECTED]> writes:

| > If this option makes it into GCC, maybe it could be named 
| > -O3_unsafe.
| 
| How about the popular -fast?

But, some transformations can both be valid and generate "faster"
code.  One of the confusions is that people tend to equate 
"fast" with "valid transformations within limited reach, that produce
faster code in that domain".  There is no need to conflate that confusion.


-- Gaby

Re: x86-linux bootstrap broken on mainline?

[Jan Hubicka]

> stage1/xgcc -Bstage1/ 
> -B/home/guerby/work/gcc/install/install-20050616T132922/i686-pc-linux-gnu/bin/
>  -c   -O2 -g -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings 
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wold-style-definition -Werror -fno-common   
> -DHAVE_CONFIG_H-I. -I. -I/home/guerby/work/gcc/version-head/gcc 
> -I/home/guerby/work/gcc/version-head/gcc/. 
> -I/home/guerby/work/gcc/version-head/gcc/../include 
> -I/home/guerby/work/gcc/version-head/gcc/../libcpp/include  \
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c -o i386.o
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c: In function 
> 'ix86_expand_builtin':
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c:15127: internal 
> compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [i386.o] Error 1
> 
> It looks like the only patch between my last successful bootstrap and the 
> current failure is
> the following, am I alone in seeing this?

Can I have backtrace?  Both patches was bootstrapped/regtested on i686
so everything shall be fine.  I am double checking now.  I also received
reports from memory tester so it's build apparently passed too.

Honza
> 
> Laurent
> 
> $ cvs diff -u -D 'Wed Jun 15 21:20:45 UTC 2005' -D 'Thu Jun 16 11:26:54 UTC 
> 2005' ChangeLog
> Index: ChangeLog
> ===
> RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
> retrieving revision 2.9159
> retrieving revision 2.9161
> diff -u -r2.9159 -r2.9161
> --- ChangeLog   15 Jun 2005 20:13:04 -  2.9159
> +++ ChangeLog   16 Jun 2005 10:31:51 -  2.9161
> @@ -1,3 +1,59 @@
> +2005-06-16  Jan Hubicka  <[EMAIL PROTECTED]>
> +
> +   * basic-block.h (rtl_bb_info): Break out head_, end_,
> +   global_live_at_start, global_live_at_end from ...
> +   (basic_block_def): ... here; update all references
> +   (BB_RTL): New flag.
> +   (init_rtl_bb_info): Declare.
> +   * cfgexpand.c (expand_gimple_basic_block): Init bb info, set BB_RTL
> +   flag.
> +   * cfgrtl.c: Include ggc.h
> +   (create_basic_block_structure): Init bb info.
> +   (rtl_verify_flow_info_1): Check BB_RTL flag and rtl_bb_info pointer.
> +   (init_rtl_bb_info): New function.
> +   (rtl_merge_block, cfglayout_merge_block): Copy global_live_at_end 
> here.
> +   * cfghooks.c (merge_block): Do not copy global_live_at_end here.
> +   * cfg.c (clear_bb_flags): Skip BB_RTL flag.
> +   (dump_flow_info): Gueard global_live_* dumping.
> +
> +   * Makefile.in (cfg.o): Add new dependencies.
> +   * basic-block.h (reorder_block_def): Kill
> +   original/copy/duplicated/copy_number fields.
> +   (BB_DUPLICATED): New flag.
> +   (initialize_original_copy_tables, free_original_copy_tables,
> +   set_bb_original, get_bb_original, set_bb_copy, get_bb_copy): New.
> +   * cfg.c: Include hashtab.h and alloc-pool.h
> +   (bb_original, bb_copy, original_copy_bb_pool): New static vars.
> +   (htab_bb_copy_original_entry): New struct.
> +   (bb_copy_original_hash, bb_copy_original_eq): New static functions.
> +   (initialize_original_copy_tables, free_original_copy_tables,
> +   set_bb_original, get_bb_original, set_bb_copy, get_bb_copy): New
> +   global functions.
> +   * cfghooks.c (duplicate_block): Update original/copy handling.
> +   * cfglayout.c (fixup_reorder_chain): Likewise.
> +   (cfg_layout_initialize): Initialize orignal_copy tables.
> +   (cfg_layout_finalize): FInalize original_copy tables.
> +   (can_copy_bbs_p): Use BB_DUPLICATED flag.
> +   (copy_bbs): Likewise.
> +   * cfgloopmanip.c (update-single_exits_after_duplication): Likewise.
> +   (duplicate_loop_to_header_edge): Likewise; update handling of
> +   copy_number.
> +   (loop_version): Likewise.
> +   * dominance.c (get_dominated_by_region): Use BB_DUPLICATED_FLAG.
> +   * except.c (expand_resx_expr): Check that reg->resume is not set.
> +   * loop-unroll.c (unroll_loop_constant_iterations,
> +   unroll_loop_runtime_iterations, apply_opt_in_copies): Update
> +   copy/original handling.
> +   * loop-unwitch.c (unswitch_loop): Likewise.
> +   * tree-cfg.c (create_bb): Do not initialize RBI.
> +   (disband_implicit_edges): Do not kill RBI.
> +   (add_phi_args_after_copy_bb): Use new original/copy mapping.
> +   (add_phi_args_after_copy): Use BB_DUPLICATED flag.
> +   (tree_duplicate_sese_region): Update original/copy handling.
> +   * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Likewise.
> +   * tree-ssa-loop-manip.c (copy_phi_node_args): Likewise.
> +   * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Likewise.
> +
> 

Re: x86-linux bootstrap broken on mainline?

[Jan Hubicka]

> stage1/xgcc -Bstage1/ 
> -B/home/guerby/work/gcc/install/install-20050616T132922/i686-pc-linux-gnu/bin/
>  -c   -O2 -g -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings 
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wold-style-definition -Werror -fno-common   
> -DHAVE_CONFIG_H-I. -I. -I/home/guerby/work/gcc/version-head/gcc 
> -I/home/guerby/work/gcc/version-head/gcc/. 
> -I/home/guerby/work/gcc/version-head/gcc/../include 
> -I/home/guerby/work/gcc/version-head/gcc/../libcpp/include  \
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c -o i386.o
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c: In function 
> 'ix86_expand_builtin':
> /home/guerby/work/gcc/version-head/gcc/config/i386/i386.c:15127: internal 
> compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [i386.o] Error 1
> 
> It looks like the only patch between my last successful bootstrap and the 
> current failure is
> the following, am I alone in seeing this?

Apparently the following patch
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00971.html
should fix your problem.  I got the dependencies wrong and this seem to
show up only in some memory configurations.  My apologizes for that!

Honza

Re: Fixing Bugs

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Wakely)  wrote on 16.06.05 in <[EMAIL PROTECTED]>:

> On Thu, Jun 16, 2005 at 10:30:03AM -0400, Scott Robert Ladd wrote:
>
> > Aaron W. LaFramboise wrote:
> > > Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
> > > the "Bicycle shed effect."
> > >
> > >  > > -PAINTING>
> >
> > If I'm building a bicycle shed, I may want to talk with others who have
> > done so in the past, learning from the experience and gaining their
> > insights. Why did they use a certain type of construction? What sort of
> > storage did they build in? What worked and didn't work for someone else
> > who has already built a shed? What did they learn from their own work?
> > Any shed I build will be better for such discussions.
>
> You've completely missed the point (rather appropriately).  You're
> *supposed* to be building a nuclear reactor, but have got preoccupied
> discussing the colour of the bicycle shed in which the staff will park
> their bikes.
>
> That's what "bicycle shed painting" refers to.

Actually, based on that FAQ entry, no, it doesn't.

Those are two different projects. It's not a shed as part of a reactor.

It's *not* about being distracted by unimportant details; it's about  
discussing easy projects to death and just rubberstamping hard projects.

Which does not seem to describe any current problem.

MfG Kai

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Robert Dewar]

Vincent Lefevre wrote:


What about having the choice?


That's fine, provided there are really well defined semantic
rules for what the options do, these options need designing
by people who are experts in floating-point semantics.


Anyway, if the only reason is the performance, then the bug shouldn't
have been marked as INVALID (the SUSPENDED status is for such kind of
problems -- and SUSPENDED doesn't mean that the bug is resolved).


As you well know, not everyone agrees this is a bug, and this does
not have to do with performance. Saying over and over again that you
think it is a bug does not make it so.

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

[Eric Botcazou]

> And that one should be fixed by the patch I posted, so Solaris
> should be hopefully fine.

Yup, OK everywhere.

-- 
Eric Botcazou

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

[Bradley Lucier]

It seems that the libtool command line may be wrong.  Here's a simple  
test.


[descartes:~/programs] lucier% cat conftest.c
int main2() { return 0;}
[descartes:~/programs] lucier% gcc -m64 -mcpu=970 -o conftest  
-dynamiclib conftest.c -v -save-temps

Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0-mainline  
--with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3  
--enable-languages=c,c++,objc,obj-c++,f95

Thread model: posix
gcc version 4.1.0 20050615 (experimental)
 /pkgs/gcc-4.0-mainline/libexec/gcc/powerpc-apple-darwin8.1.0/4.1.0/cc1  
-E -quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -m64  
-mcpu=970 -fpch-preprocess -o conftest.i

ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory  
"/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../ 
../../powerpc-apple-darwin8.1.0/include"

#include "..." search starts here:
#include <...> search starts here:
 /pkgs/gcc-4.0-mainline/include
 /pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
 /pkgs/gcc-4.0-mainline/libexec/gcc/powerpc-apple-darwin8.1.0/4.1.0/cc1  
-fpreprocessed conftest.i -fPIC -quiet -dumpbase conftest.c -m64  
-mcpu=970 -auxbase conftest -version -o conftest.s

GNU C version 4.1.0 20050615 (experimental) (powerpc-apple-darwin8.1.0)
compiled by GNU C version 4.1.0 20050615 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 856564be1b7d2e1a3d0c80ce3c26789d
 as -arch ppc64 -o conftest.o conftest.s
 /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load  
-weak_reference_mismatches non-weak -o conftest  
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/ppc64  
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../ 
../ppc64 conftest.o -lgcc_s_ppc64 -lgcc -lSystemStubs -lmx -lSystem

/usr/bin/libtool: can't locate file for: -lgcc_s_ppc64
/usr/bin/libtool: file: -lgcc_s_ppc64 is not an object file (not  
allowed in a library)


However, if I add by hand /pkgs/gcc-4.0-mainline/lib, where  
libgcc_s_ppc64.1.0.dylib is installed, to the link path to libtool, I  
get


[descartes:~/programs] lucier% /usr/bin/libtool -dynamic -arch_only  
ppc64 -noall_load -weak_reference_mismatches non-weak -o conftest  
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/ppc64  
-L/pkgs/gcc-4.0-mainline/lib/gcc/powerpc-apple-darwin8.1.0/4.1.0/../../ 
../ppc64 conftest.o -lgcc_s_ppc64 -lgcc -lSystemStubs -lmx -lSystem  
-L/pkgs/gcc-4.0-mainline/lib

[descartes:~/programs] lucier% file conftest
conftest: Mach-O 64-bit dynamically linked shared library ppc64
[descartes:~/programs] lucier% otool64 -L conftest
conftest:
conftest (compatibility version 0.0.0, current version 0.0.0)
/pkgs/gcc-4.0-mainline/lib/libgcc_s_ppc64.1.0.dylib  
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current  
version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.0.0)


Perhaps someone moved libgcc_s_ppc64.1.0.dylib but didn't change the  
script that builds the libtool command line to tell libtool where to  
find it?


Brad

gcc-4.0-20050616 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050616 

You'll find:

gcc-4.0-20050616.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20050616.tar.bz2 C front end and core compiler

gcc-ada-4.0-20050616.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20050616.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20050616.tar.bz2  C++ front end and runtime

gcc-java-4.0-20050616.tar.bz2 Java front end and runtime

gcc-objc-4.0-20050616.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20050616.tar.bz2The GCC testsuite

Diffs from 4.0-20050609 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
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.

basic VRP min/max range overflow question

[Paul Schlie]

Upon a potential integer overflow of either it's min or max range,
shouldn't the result be set to [min:type-min-value, max:type-max-value],
without the necessity of any further designations?

As this would seem to most accurately and simply represent the effective
bounds of an underflowed integer value constrained to an arbitrarily sized
integer type size for all targets I can think of, with the exception of
DSP's which tend to uniquely support saturating integer arithmetic, in
which case only the min or max range would be saturated correspondingly.

Major regression in 4.1.

[Steve Kargl]

Does this look familiar to anyone?  It certainly was happening
a few days ago.  Shouldn't a bootstrap and regression of all
frontend be required before someone checks in a patch to the
back-end?

Setting LD_LIBRARY_PATH to 
.:/usr/home/sgk/gcc/obj41/amd64-unknown-freebsd6.0/./libgfortran/.libs:/usr/home/sgk/gcc/obj41/gcc:.:/usr/home/sgk/gcc/obj41/amd64-unknown-freebsd6.0/./libgfortran/.libs:/usr/home/sgk/gcc/obj41/gcc
PASS: gfortran.dg/select_2.f90  -O2  execution test
Executing on host: /usr/home/sgk/gcc/obj41/gcc/testsuite/../gfortran 
-B/usr/home/sgk/gcc/obj41/gcc/testsuite/../ 
/usr/home/sgk/gcc/gcc41/gcc/testsuite/gfortran.dg/select_2.f90   -O3 
-fomit-frame-pointer   -pedantic-errors  
-L/usr/home/sgk/gcc/obj41/amd64-unknown-freebsd6.0/./libgfortran/.libs 
-L/usr/home/sgk/gcc/obj41/amd64-unknown-freebsd6.0/./libiberty  -lm   -o 
./select_2.exe(timeout = 300)
/usr/home/sgk/gcc/gcc41/gcc/testsuite/gfortran.dg/select_2.f90: In function 
'MAIN__':
/usr/home/sgk/gcc/gcc41/gcc/testsuite/gfortran.dg/select_2.f90:7: internal 
compiler error: in tree_verify_flow_info, at tree-cfg.c:3716
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/usr/home/sgk/gcc/gcc41/gcc/testsuite/gfortran.dg/select_2.f90: In function 
'MAIN__':
/usr/home/sgk/gcc/gcc41/gcc/testsuite/gfortran.dg/select_2.f90:7: internal 
compiler error: in tree_verify_flow_info, at tree-cfg.c:3716
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)

[Ranjit Mathew]

Hi,

  For two consecutive days, I have been unable to
build GCC mainline on i686-pc-linux-gnu:
- 8<
-
stage1/xgcc -Bstage1/ -B/home/ranmath/gcc/i686-pc-linux-gnu/bin/ -c  
-O2 -g -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werror-DHAVE_CONFIG_H
   -I. -Icp -I/home/ranmath/src/gcc/gcc-20050617/gcc
-I/home/ranmath/src/gcc/gcc-20050617/gcc/cp
-I/home/ranmath/src/gcc/gcc-20050617/gcc/../include
-I/home/ranmath/src/gcc/gcc-20050617/gcc/../libcpp/include/home/ranmath/src/gcc/gcc-20050617/gcc/cp/call.c
-o cp/call.o
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c: In function
'ix86_expand_vector_init':
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
error: insn does not satisfy its constraints:
(insn 367 343 378 4
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17047 (set
(reg:QI 138)
(const_int 0 [0x0])) 45 {*movqi_1} (nil)
(expr_list:REG_EQUIV (const_int 0 [0x0])
(nil)))
/home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
- 8<
-

I build with "--with-arch=pentium4 --disable-checking" and that
might explain why no one has apparently reported it yet. The
full configure invocation is:
- 8<
-
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
--with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
--with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
--with-arch=pentium4 --with-tune=pentium4 \
--disable-nls --disable-checking --disable-libmudflap \
--disable-debug --enable-threads=posix --enable-__cxa_atexit
- 8<
-

I use FSF GCC 3.4.4 for bootstrapping and FSF binutils
2.16.

Thanks,
Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: Regressions

[FX Coudert]

Jerry DeLisle wrote:
There appears to be numerous regression failures this evening.  I 
suppose these are back end related.


On i686-freebsd, i386-linux and x86_64-linux, I see failures for 
gfortran.dg/pr19657.f and gfortran.dg/select_2.f90 at -O3, 
gfortran.dg/vect/vect-2.f90 at -O. And gfortran.dg/vect/vect-5.f90, but 
that one is not new.


They were not present in 20050615, and appeared in 20050616. It is due 
to an ICE, at -O3:


O3.f: In function ‘MAIN__’:
O3.f:11: internal compiler error: in tree_verify_flow_info, at 
tree-cfg.c:3716


This is now known as PR 22100.

FX

Re: Regressions

[Steve Kargl]

On Fri, Jun 17, 2005 at 08:01:47AM +0200, FX Coudert wrote:
> Jerry DeLisle wrote:
> >There appears to be numerous regression failures this evening.  I 
> >suppose these are back end related.
> 
> On i686-freebsd, i386-linux and x86_64-linux, I see failures for 
> gfortran.dg/pr19657.f and gfortran.dg/select_2.f90 at -O3, 
> gfortran.dg/vect/vect-2.f90 at -O. And gfortran.dg/vect/vect-5.f90, but 
> that one is not new.
> 
> They were not present in 20050615, and appeared in 20050616. It is due 
> to an ICE, at -O3:
> 
> O3.f: In function ?MAIN__?:
> O3.f:11: internal compiler error: in tree_verify_flow_info, at 
> tree-cfg.c:3716
> 
> This is now known as PR 22100.
> 

I can confirm the problem on amd64-*-freebsd.  I is quite
annoying that someone would make a change to the backend
without testing it.

-- 
Steve