Re: Rant about ChangeLog entries and commit messages

[Andreas Schwab]

Nicholas Nethercote <[EMAIL PROTECTED]> writes:

> On Sun, 2 Dec 2007, Andreas Schwab wrote:
>
>>> | 2007-11-30  Jan Hubicka  <[EMAIL PROTECTED]>
>>> |
>>> | * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
>>> | flag.
>>>
>>> How could a newcomer guess why the gcc_force_collect flag needs to be
>>> reset?
>>
>> That is supposed to be written in a comment.
>
> Indeed.  Some advice I once wrote:  Often I see a commit with a log
> message that lovingly explains a small change made to fix a subtle
> problem, but adds no comments to the code.  Don't do this! Put that
> careful description in a comment, where people can actually see it.
> (Commit logs are basically invisible; even if they are auto-emailed to all
> developers, they are soon forgotten, and they don't benefit people not on
> the email list.)

Moreover, if you later look at a commit log you don't know whether it
still describes the current code, you have to carefully inspect the
later history whether there were any further refinements, for example.
A comment will be updated over time and is always (supposed to be) on
par with the code.

Andreas.

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

Re: Rant about ChangeLog entries and commit messages

[Andi Kleen]

Nicholas Nethercote <[EMAIL PROTECTED]> writes:

> Commit logs are basically invisible;

That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In fact in several editors these can be functions on hot
keys. Programming is hard enough as is without ignoring such valuable
information sources. Don't do it.

-Andi

Re: [Fwd: Re: FW: matrix linking]

[[EMAIL PROTECTED]]

Oliver.

Have you got a chance to take a look at the materials?
If yes, what do you think on it?

Yours sincerely,
George.

[EMAIL PROTECTED] ?:

Thank you for your reply, Oliver.

Briefly speaking the solution to the problems you have mentioned looks 
like this:
1. take a loot at the first picture here: 
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works 


2. Pointer 1, 2... are vptrs
3. The idea is that each module, library (.so) has a row of vptrs, 
when it is required to make a dynamic binding this row is going to be 
copied to the similar one, the new vptrs are applied to the new row of 
vptrs, the previous, old row is unchanged. Then the shift looks like 
incremental lock of integer value which is the version of this module 
(.so). So it means that these threads which execute the code inside 
the 'old module' they are unchanged, and the new code is going to be 
executed in case we will have got the new call to the functions of the 
module. It might have been said it does not answer the question, since 
there might be some loops which needs to be reloaded also, though I 
believe it does, since this tends more to the architecture than to 
linkage already :-)


This is quite brief and uncertain explanation. In reality it does not 
look like this. More details could have been found here: 
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works. 



I hope you will find worthy the reading.

In case of questions do not hesitate to ask.

Yours sincerely,
George.


Olivier Galibert ?:

On Fri, Nov 23, 2007 at 11:49:03AM +0300, [EMAIL PROTECTED] wrote:
[Changing the _vptr or C equivalent dynamically]
I would like the community would have considered the idea. I am 
ready to answer all the questions you might have.


Changing the virtual function pointer dynamically using a serializing
instruction is I'm afraid just the tip of the iceberb. Even
forgetting for a second that some architectures do not have
serializing instructions per se, there are some not-so-simple details
to take into account:

- the compiler can cache the vptr in a register, making your
serialization less than serialized suddently

- changing a group of functions is usually not enough. A component
version change usually means its internal representation of the state
changes. Which, in turn, means you need to serialize the object
(whatever the programming language) in the older version and
unserialize it in the newer, while deferring calls into the object
from any thread

- previous point means you also need to be able to know if any thread
is "inside" the object in order to have it get out before you do a
version change. Which in objects that use a somee of message fifo
for work dispatching may never happen in the first place

Dynamic vtpr binding is only the start of the solution.

OG.

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> Sorry, but again, this is not a good enough justification to me.
> We do a lot of things different than "The GNU Project".
> So do plenty of parts of the "official GNU project".
> They use different coding standards, bug tracking systems, version
> control systems, checkin policies, etc, than each other.

Yes, but none of those are visible other than to the development community.
People who obtain the source distributions of projects don't get to see
those things.  They DO see things like the ChangeLog format and coding
and documentation conventions and THOSE are the things that need to be
common among GNU projects.

In my view, ChangeLog is mostly "write-only" from a developer's
perspective.  It's a document that the GNU project requires us to produce
for the benefit of people who DON'T want access to our checkin-logs, bug
tracking information, and mailing lsits.  But for our own development
purposes, we use the above information much more than ChangeLog.

Re: volatile and R/M/W operations

[Richard Kenner]

> OK, sounds reasonable, but then I don't understand the logic behind
> avoiding this instruction sequence for the volatile case, this is
> two accesses at the bus level so what's the difference? 

There's no difference from that perspective.  The logic behind what's
generated is that instead of trying to do a case-by-case analysis of
what instruction combinations might actually be valid for volatile
memory (which could potentially be target-specific), GCC takes the
conservative approach of simply disabling all but trivial combinations
for volatile access.

[RFC] Introduce middle-end expressions on arrays

[Richard Guenther]

>From the last GCC Summit we learned about (Fortran) Frontend Based
Optimizations from Toon and it was suggested to tackle one issue by
promoting arrays to a first-class middle-end type.  Discussion with
Sebastian also reveals that this makes sense to ease the analysis
of the into-GRAPHITE transformation by not dropping information that
cannot be re-computed.


For example Fortran has the "load-before-store" semantics on its
vector operations, i.e. if the same array cell is accessed twice it is
first read, then written i.e. updated.  The scalarizer has to use
temporary arrays for ensuring this semantics, so for example for
"A = A + B" with A and B arrays, the
scalarizer creates a temporary buffer that will hold the intermediate
results of the addition before updating the array A: i.e. "T = A + B"
followed by "A = T".  This decompression of the memory use is easy to
perform (see the array privatization techniques for parallelization),
but the inverse operation, i.e. the compression is much more
difficult, as it has to analyze in IPA mode the uses of T: before
removing the initialization of T it has to ensure that there are no
other uses of T.

Another point for the motivation is that vector constructs should
survive till the point where GCC knows/uses information about the
vector target machine with using the vectorizer (as part of the
GRAPHITE framework) to create regular (optimized) scalar IL from
the array operations.


So this is a proposal to make this happen, allow statements and
expressions that operate on (multidimensional) arrays.

The first and maybe most important issue is that temporaries required
by either design issues of the IL or by optimizations are not going
to be cheap.  The second issue is the question of if (yes I'd say) and
when (very early I'd say) we want to lower statements / expressions
on arrays and generate loop constructs for them.


On the first issue, how to represent array expressions in the IL we
can take the pragmatic approach for now and merely try to make the
expressions survive until they get picked up by GRAPHITE (or other
to-be-invented special optimizers) but allow scalar optimizers to
operate on scalar parts of the expressions.  To avoid creating
temporaries of array type, which the gimplifier in its current form
cannot do for variable length types, we do not create full GIMPLE
form of array expressions, but retain GENERIC expressions in RHS.
With the very experimental prototype patch (that just was done to
experiment with forms of the IL) we would for example end up with

  float a[16];
  float b[16];
  float c[16];

  tmp = 0.0;
  a.1 = &a;
  b.2 = &b;
  c.3 = &c;
  n.4 = n; 
  D.1558 = (long unsigned int) n.4;
  D.1559 = D.1558 * 4;
  *a.1 = WITH_SIZE_EXPR <(*b.2 + *c.3) + tmp, D.1559>;
  D.1560 = a[0];
  return D.1560;

for the whole array expression C source

  float test5 (int n)
  {
float a[16];
float b[16];
float c[16];
float tmp = 0.0;
*(float (*)[n])&a = *(float (*)[n])&b + *(float (*)[n])&c + tmp;
return a[0];
  }

Ignore the WITH_SIZE_EXPR here, the point is that we have two
operations and three operands on the rhs, two arrays, one scalar.
CCP happily propagates 0.0 into the expression and if you do not
run SRA (which ICEs) you survive until expand, which of course has
no idea how to deal with this expression ;)

So we think this approach is sound if these expressions do not survive
for too long (that is, only until after out-of-GRAPHITE).


A different approach would be to only allow whole arrays as gimple
values and proceed with usual gimplification of expressions.  To
avoid to have to allocate memory for the array temporaries we could
represent them as pointers to (not yet) allocated storage like
for the above case

   float (* D.29)[n] = (float (*)[n])&a;
   float (* D.30)[n] = (float (*)[n])&b;
   float (* D.31)[n] = (float (*)[n])&c;
   float (* D.42)[n];
   D.42 = __builtin_vla_tmp_alloc (n * 4);
   *D.42 = *D.30 + *D.31;
   *D.29 = *D.42 + tmp;
   __builtin_vla_tmp_free (D.43);

where we still would have de-references of pointers to arrays als
gimple values as well.  This approach would also fit inserted
temporaries that are required for language semantic reasons.


On the second issue we are thinking of leveraging GRAPHITE which needs
to create scalar code out of its intermediate representation anyway to
do the lowering to scalar code.  Especially we do not want to force
expand to deal with the whole-array expressions.  But this is
obviously the issue which we can most easily post-pone until we can
do experiments.


There are two more aspects that need consideration.  First, if and if
yes, what kind of, tree codes we want to use for the operators.  It
would be possible to re-use PLUS_EXPR and MINUS_EXPR in general and
use MULT_EXPR and RDIV_EXPR for mixed array / scalar operands.  But
in the end I don't think this is desirable and certainly not sufficient
thinking of matrix multiplication, contraction and expansions.  So

Re: volatile and R/M/W operations

[Robert Dewar]

Richard Kenner wrote:

OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference? 


There's no difference from that perspective.  The logic behind what's
generated is that instead of trying to do a case-by-case analysis of
what instruction combinations might actually be valid for volatile
memory (which could potentially be target-specific), GCC takes the
conservative approach of simply disabling all but trivial combinations
for volatile access.


Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires it, but it is
definitely useful!)

Re: [Fwd: Re: FW: matrix linking]

[Olivier Galibert]

On Mon, Dec 03, 2007 at 04:16:17PM +0300, [EMAIL PROTECTED] wrote:
> Have you got a chance to take a look at the materials?
> If yes, what do you think on it?

Nope, sorry, too busy with other things.

  OG.

Re: gnat1 huge time

[Joel Sherrill]

Eric Botcazou wrote:

On the SPARC, this produced an executable I couldn't run
on the simulator.  It looked like the .text segment may
have increased enough to not fit in the simulator.



Weird.  The EH tables should probably not end up in .text.

  

RTEMS applications are statically linked with all
support libraries.  I wonder if it just make the
run-time larger.  I need to look at an executable in
more detail.

So this appears to work around the build time problem and
will let me continue to test the real changes I was working
on but I don't know that I like this as a permanent solution.



This setting should bring the Ada compiler on par with the C++ compiler as
far as the EH mechanism is concerned: same space overhead, same performance 
overhead.  Which EH mechanism do you use for C++ in RTEMS?


  

I have seen reports where people complained about the size
of embedded GNAT and GNAT/RTEMS executables and doubling
the code size just makes it worse.



It's a tradeoff between space and performance.  Certainly EH tables can be 
large and setjmp/longjmp EH might be better suited, albeit slower.


  

But this is progress and gives a real hint as to the underlying
problem.  Maybe it is enough for someone to fix it.



It's not really related to the problem though, which appears to be in DF.
But at least it makes it possible to reproduce it even on platforms where
it doesn't arise natively, by making the opposite change you made.

  

Is there a PR for this or do I need to try to file one?



No, I don't think there is one.

  

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> There are in fact, already programs that will generate GNU format
> changelogs from svn log (see http://ch.tudelft.nl/~arthur/svn2cl/)
> It would be very easy to run these as part of the release process.

Sure, but I think that's bad for this project since I support the idea
that the svn log should contain additional information that's not part
of what the GNU project wants in ChangeLog.

Re: Rant about ChangeLog entries and commit messages

[Daniel Berlin]

On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Sorry, but again, this is not a good enough justification to me.
> > We do a lot of things different than "The GNU Project".
> > So do plenty of parts of the "official GNU project".
> > They use different coding standards, bug tracking systems, version
> > control systems, checkin policies, etc, than each other.
>
> Yes, but none of those are visible other than to the development community.
> People who obtain the source distributions of projects don't get to see
> those things.  They DO see things like the ChangeLog format and coding
> and documentation conventions and THOSE are the things that need to be
> common among GNU projects.

Except they aren't, across large parts of the GNU project.

You may find it the same in the "traditional" parts of the GNU project
(IE coreutils, emacs, etc).
It's certainly not the same across any of the newer parts of the GNU project.

Re: volatile and R/M/W operations

[Richard Kenner]

> Right, but it would seem this is a good canididate for combination. This
> is especially true since often Volatile is used with the sense of Atomic
> in Ada, and it is not a bad idea to combine these in practice, giving an
> atomic update (right, nothing in the language requires it, but it is
> definitely useful!)

I don't disagree that "this" is a good candidate for combination, but
one problem is that by the time you're at that level, you don't easily have
the source correspondance you want.

E.g.,

y |= 2;

and

t1 = y | 2;
y = t1;

are very hard to tell apart at the RTL level.  Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.

>From a legacy perspective, it's dangerous to muck around much in this area.

As to Ada's Atomic, it's just implementation convenience that it's mapped
to GCC's volatile.  Most things that GCC's volatile implies aren't needed
for Ada's atomic (and it may even be the case that most of them aren't even
needed for Volatile in Ada).

One approach here would be to separate the properties we now consider part
of "volatile" (e.g., "can't remove dead load", "can't change access size",
"must keep same number of loads", etc.) into separate properties and test
those in places where we now test the "volatile" attribute.  That would
be a fairly straightforward but large and pervasive change.  It's not
clear it'd be worth the effort, but I'm curious what others think.

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Anyway, given that there have been objections to the patch generally,
>> I realise that the pre-approval is void.
>
> I think there's no controversy over the libstdc++ change, so let's put
> that in.  If nothing else, it makes the libstdc++ configury more
> self-consistent; if we decide to change the overall strategy, then we
> can do that all at once.

Well, Rask's patch would make the libstdc++ change unnecessary,
so it seems premature to change libstdc++ now.  (Not that I'm objecting
to anyone else doing it.  I'm just not comfortable doing it myself,
especially since, on its own, it doesn't affect any of "my" targets.)

Richard

Re: Rant about ChangeLog entries and commit messages

[Andi Kleen]

[EMAIL PROTECTED] (Richard Kenner) writes:
>
> Yes, but none of those are visible other than to the development community.
> People who obtain the source distributions of projects don't get to see
> those things.  They DO see things like the ChangeLog format and coding
> and documentation conventions and THOSE are the things that need to be
> common among GNU projects.

It would be probably reasonable these days to require of someone who
wants to do serious development to just download a SVN checkout
for that [or they can use svnweb on http://gcc.gnu.org]

-Andi

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> Except they aren't, across large parts of the GNU project.
> 
> You may find it the same in the "traditional" parts of the GNU project
> (IE coreutils, emacs, etc).
> It's certainly not the same across any of the newer parts of the GNU project.

Perhaps, but GCC has always been considered, like emacs, to be one of
the most central parts of the GCC project and I think it'd be very wrong
for us not follow their wishes in standardization areas.

Re: Rant about ChangeLog entries and commit messages

[Robert Kiesling]

[ Charset ISO-8859-1 unsupported, converting... ]
> On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > Sorry, but again, this is not a good enough justification to me.
> > > We do a lot of things different than "The GNU Project".
> > > So do plenty of parts of the "official GNU project".
> > > They use different coding standards, bug tracking systems, version
> > > control systems, checkin policies, etc, than each other.
> >
> > Yes, but none of those are visible other than to the development community.
> > People who obtain the source distributions of projects don't get to see
> > those things.  They DO see things like the ChangeLog format and coding
> > and documentation conventions and THOSE are the things that need to be
> > common among GNU projects.
> 
> Except they aren't, across large parts of the GNU project.
> 
> You may find it the same in the "traditional" parts of the GNU project
> (IE coreutils, emacs, etc).
> It's certainly not the same across any of the newer parts of the GNU project.

That's because, although the GNU project strictly - and correctly,
experience has shown - monitors its code base, with the propagation 
of the Free Software development model, newer Free Software 
contributors who maintain their code on sites like sourceforge.net,
are subject to commercial pressures that the older, ivory-tower
authors in general are shielded from.

It's impossible to convince someone who wants your "niche" for a
quickie IPO that maintaining code for more than two or three years 
is worth the investment.

-- 
Ctalk Home Page: http://www.ctalklang.org/

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> It would be probably reasonable these days to require of someone who
> wants to do serious development to just download a SVN checkout
> for that [or they can use svnweb on http://gcc.gnu.org]

I agree.  But I think the idea of the ChangeLog is for somewhere just short
of "serious development".  I'm not too far from being willing to agree
that ChangeLog is now hopelessly anachronistic (though I'm not there yet),
but feel that this is really an FSF issue, not a GCC one.

Re: Rant about ChangeLog entries and commit messages

[Diego Novillo]

On 12/02/07 05:05, Samuel Tardieu wrote:


Maybe we should consider dropping ChangeLogs and using better checkin
messages.


I'm not sure people will want to drop ChangeLogs anytime soon.  I don't 
find them all that useful, but I *have* used them extensively when doing 
archeology.  It gives you the initial thread to pull when finding out 
about changes.


What I *do* miss a lot is a an easier way to link from the ChangeLog 
entry into the email message explaining the whys and hows of a change. 
In this respect, the comment in the code is not enough.  The comment 
explains what the code does today, it does not (and should not) explain 
the history of that piece of code.  Otherwise, comments would soon grow 
to useless proportions.


The history is something one finds on the mailing lists.  So, my 
proposal is to add a commit-time check that makes sure that the commit 
message contains a URL to the message describing the change.  IIUC, such 
check shouldn't be hard to implement (Dan?)


I try to do that with fixed PRs.  When closing one, I usually add a link 
to the message explaining the fix.


The only annoying issue with this proposal is that it forces the 
committer to fish out the message URL from the mailing lists, so perhaps 
we could make the check a warning instead of an error.


Thoughts?


Diego.

Re: volatile and R/M/W operations

[Richard Kenner]

> > t1 = y | 2;
> > y = t1;
> > 
> > are very hard to tell apart at the RTL level.  Though it's clear that
> > a single instruction might best match the expect semantics of the former,
> > it's a lot less clear that it would for the latter.
> 
> I think it would still be OK for the latter, why not?

There was certainly a time when it would not, because a R/M/W cycle on
a device register meant a different thing that a read followed by a write
and the latter is more clearly what the above is supposed to represent.

Whether there is still such hardware around is another question, but
the point is that whether you or I THINK it would be OK really isn't
the issue when talking about legacy code.

Re: Rant about ChangeLog entries and commit messages

[Robert Dewar]

Robert Kiesling wrote:


That's because, although the GNU project strictly - and correctly,
experience has shown - monitors its code base, with the propagation 
of the Free Software development model, newer Free Software 
contributors who maintain their code on sites like sourceforge.net,

are subject to commercial pressures that the older, ivory-tower
authors in general are shielded from.

It's impossible to convince someone who wants your "niche" for a
quickie IPO that maintaining code for more than two or three years 
is worth the investment.


I don't treally understand this commment, we are talking about
improving the maintainability here, and what people are saying
is that some other parts of the project have already moved in
this direction.

Re: volatile and R/M/W operations

[Robert Dewar]

Richard Kenner wrote:

Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires it, but it is
definitely useful!)


I don't disagree that "this" is a good candidate for combination, but
one problem is that by the time you're at that level, you don't easily have
the source correspondance you want.

E.g.,

y |= 2;

and

t1 = y | 2;
y = t1;

are very hard to tell apart at the RTL level.  Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.


I think it would still be OK for the latter, why not?

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> I'm not sure people will want to drop ChangeLogs anytime soon.  I don't 
> find them all that useful, but I *have* used them extensively when doing 
> archeology.  It gives you the initial thread to pull when finding out 
> about changes.
> 
> What I *do* miss a lot is a an easier way to link from the ChangeLog 
> entry into the email message explaining the whys and hows of a change. 
> In this respect, the comment in the code is not enough.  The comment 
> explains what the code does today, it does not (and should not) explain 
> the history of that piece of code.  Otherwise, comments would soon grow 
> to useless proportions.

I agree completely with all of that.

How to reinterpret data in GIMPLE.

[Sjodin, Jan]

I would like to reinterpret (not convert/cast) a 32-bit integer to a
32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
correct way of doing this? 

The reinterpretation of a value is needed to optimize reads and writes
to unions. I modified the value numbering pass which worked fine, but
changing PRE to use a NOP_EXPR to change the type still resulted in a
conversion. It may be because of a bug somewhere else, but before doing
more work I would like to make sure that NOP_EXPR is the correct
operator. 

Thanks,
Jan

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Mon, Dec 03, 2007 at 04:07:35PM +, Richard Sandiford wrote:
> And I haven't yet looked at why the tests are failing.  I was just noting
> that they did.  It looks from PR21185 that Rask was seeing the same thing
> on mipsisa64-elf, and TBH, I was so unsurprised that they were failing that
> I hadn't even realised it was _supposed_ to work now.  I'll have a prod.

mips-core: 1 byte read to unmapped address 0x0 at 0x80021468
program stopped with signal 10.

There are 8456 such messages at slightly different addresses out of a total
of 8488 failures. And generally, on the targets with problems, the problems
seem to be in the simulation part (dejagnu, the simulator itself or the
linker script) rather than in GCC. For example, the special linker script
used for SPARC testing needs to be updated to handle .e.g. .rodata.*
sections so they don't collide with the .bss section.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Rant about ChangeLog entries and commit messages

[Bernd Schmidt]

Diego Novillo wrote:
> The history is something one finds on the mailing lists.  So, my
> proposal is to add a commit-time check that makes sure that the commit
> message contains a URL to the message describing the change.  IIUC, such
> check shouldn't be hard to implement (Dan?)

I'd much prefer the text from the mail message be repeated in the commit
log.  Removes one step of indirection both when writing and reading the log.

Of course, that way it's not something that can easily be enforced
automatically.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: How to reinterpret data in GIMPLE.

[Andrew Pinski]

On 12/3/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
> I would like to reinterpret (not convert/cast) a 32-bit integer to a
> 32-bit float in GIMPLE. Is using a NOP_EXPR with the wanted type the
> correct way of doing this?

You want to use the tree code called VIEW_CONVERT_EXPR.

Thanks,
Andrew Pinski

Re: Rant about ChangeLog entries and commit messages

[Ian Lance Taylor]

Bernd Schmidt <[EMAIL PROTECTED]> writes:

> Diego Novillo wrote:
> > The history is something one finds on the mailing lists.  So, my
> > proposal is to add a commit-time check that makes sure that the commit
> > message contains a URL to the message describing the change.  IIUC, such
> > check shouldn't be hard to implement (Dan?)
> 
> I'd much prefer the text from the mail message be repeated in the commit
> log.  Removes one step of indirection both when writing and reading the log.
> 
> Of course, that way it's not something that can easily be enforced
> automatically.

I would find the URL to be very useful, because it links to the
discussion.  Reasonably often the last e-mail message is something
like "Does this version look OK?"

Ian

Re: Rant about ChangeLog entries and commit messages

[Diego Novillo]

Bernd Schmidt wrote:


I'd much prefer the text from the mail message be repeated in the commit
log.  Removes one step of indirection both when writing and reading the log.


I guess that could work, but that wouldn't give a way into the history 
for the change.  Several times there is a post-mortem discussion on the 
patch, leading to more patches.



Diego.

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> I'd much prefer the text from the mail message be repeated in the commit
> log.  Removes one step of indirection both when writing and reading the log.

I would as well.  Especially if you're trying to scan a large part of
the log looking for something.  

Re: Rant about ChangeLog entries and commit messages

[Diego Novillo]

On 12/03/07 13:50, Richard Kenner wrote:
I guess that could work, but that wouldn't give a way into the history 
for the change.  Several times there is a post-mortem discussion on the 
patch, leading to more patches.


How about both?


Sure.


Diego.

Re: Rant about ChangeLog entries and commit messages

[Richard Kenner]

> I guess that could work, but that wouldn't give a way into the history 
> for the change.  Several times there is a post-mortem discussion on the 
> patch, leading to more patches.

How about both?

Re: Rant about ChangeLog entries and commit messages

[Tim Josling]

On Mon, 2007-12-03 at 13:58 -0500, Diego Novillo wrote:
> On 12/03/07 13:50, Richard Kenner wrote:
> >> I guess that could work, but that wouldn't give a way into the history 
> >> for the change.  Several times there is a post-mortem discussion on the 
> >> patch, leading to more patches.
> > 
> > How about both?
> 
> Sure.
> 
> 
> Diego.

Quite a few people are worried about verbose descriptions of changes
cluttering up the ChangeLog. Others (like me) would like a way easily to
find the discussions about the change, and would like a brief indication
in the ChangeLog of the context of the change. The FSF also has good
reasons for keeping solid records of who made what change.

So, how about this:

1. For a PR fix, continue to record the PR number and category.
Like this: 
  PR tree-optimization/32694

2. For all changes, a one-line record giving the context, plus the URL
of a key message in the email message trail, unless the intent is
plainly obvious such as bumping the version number.
Like this:
  Gimplification of Fortran front end. 
  http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00072.html   

3. Continue to record "who made what change".
Like this: 
   * config/xtensa/xtensa.c (xtensa_expand_prologue): Put a
REG_FRAME_RELATED_EXPR note on the last insn that sets up the stack
pointer or frame pointer.

This should satisfy everyone's needs.

This would by no means be the largest divergence from the FSF standards
by the GCC project. The use of languages other than C in the Ada front
end is non-compliant by my reading. The compliance of the rest of the
code to the FSF standards is spotty at times eg the garbage collection
code.

While this is a divergence from the FSF standards, it is a positive
change and no information is being lost.

It would be interesting to ask someone who was around at the time why
the guidelines were written as they were. They rationale may no longer
be relevant.

Tim Josling

Re: volatile and R/M/W operations

[Robert Dewar]

Richard Kenner wrote:

t1 = y | 2;
y = t1;

are very hard to tell apart at the RTL level.  Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.

I think it would still be OK for the latter, why not?


There was certainly a time when it would not, because a R/M/W cycle on
a device register meant a different thing that a read followed by a write
and the latter is more clearly what the above is supposed to represent.

Whether there is still such hardware around is another question, but
the point is that whether you or I THINK it would be OK really isn't
the issue when talking about legacy code.


What is interesting is whether this translation is appropriate for
modern Intel architecture chips, and as far as I know the answer
is yes.

Issue with fixincludes (?) and `limits.h'

[Thomas Schwinge]

Hello!

What is the reason for GCC (trunk version) installing the 
header file as `PREFIX/lib/gcc/*/*/include-fixed/limits.h' instead of
putting it into `PREFIX/lib/gcc/*/*/include/', which is what
gcc-4_2-branch and earlier have been doing?

The leads to a problem as follows.  You're about to bootstrap a cross
compiler from only source code.  You build cross binutils.  You build a
minimal bootstrapping GCC (``--with-sysroot=[...] --disable-shared
--disable-threads --without-headers --enable-languages=c''; ``make
all-gcc install-gcc all-target-libgcc install-target-libgcc'').  Then you
attemp to bootstrap the glibc which will eventually fail like this:

#v+
i586-pc-gnu-gcc [...] -I[glibc internal] -nostdinc -isystem [GCC 
target]/4.3.0/include -isystem [sysroot]/include [glibc stuff]
In file included from ../sysdeps/unix/bsd/bsd4.4/bits/socket.h:31,
 from [...]
../include/limits.h:125:26: error: limits.h: No such file or directory
#v-

Is this a GCC issue or should the glibc build system be adding a
``-isystem [GCC target]/4.3.0/include-fixed''?

#v+
$ find lib/gcc/*/*/ -name \*.h | sort
lib/gcc/i586-pc-gnu/4.3.0/include-fixed/limits.h
lib/gcc/i586-pc-gnu/4.3.0/include-fixed/syslimits.h
lib/gcc/i586-pc-gnu/4.3.0/include/ammintrin.h
lib/gcc/i586-pc-gnu/4.3.0/include/bmmintrin.h
lib/gcc/i586-pc-gnu/4.3.0/include/cpuid.h
[...]
lib/gcc/i586-pc-gnu/4.3.0/include/unwind.h
lib/gcc/i586-pc-gnu/4.3.0/include/varargs.h
lib/gcc/i586-pc-gnu/4.3.0/include/xmmintrin.h
lib/gcc/i586-pc-gnu/4.3.0/install-tools/gsyslimits.h
lib/gcc/i586-pc-gnu/4.3.0/install-tools/include/limits.h
#v-


Note that this can also be reproduced with a pseudo GNU/Linux to
GNU/Linux ``cross'' compiler, e.g., from `i686-pc-linux-gnu' to
`i586-pc-linux-gnu':

#v+
$ ../trunk-work/configure --target=i586-pc-linux-gnu --prefix=$(pwd).install 
--disable-nls --disable-shared --disable-threads --enable-languages=c 
--with-arch=i586
[...]
$ make all-gcc install-gcc
[...]
$ find $(pwd).install/lib/gcc/*/*/ -name \*.h | sort
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include-fixed/limits.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include-fixed/syslimits.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/ammintrin.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/bmmintrin.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/cpuid.h
[...]
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/unwind.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/varargs.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/include/xmmintrin.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/install-tools/gsyslimits.h
/home/thomas/tmp/source/gcc/trunk-work.build.install/lib/gcc/i586-pc-linux-gnu/4.3.0/install-tools/include/limits.h
#v-

Why is `limits.h' put into `include-fixed/'?  And what about this
`install-tools' directory which duplicates some of the files?


Regards,
 Thomas


signature.asc
Description: Digital signature

gcc-4.1-20071203 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 130587

You'll find:

gcc-4.1-20071203.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20071203.tar.bz2 C front end and core compiler

gcc-ada-4.1-20071203.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20071203.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20071203.tar.bz2  C++ front end and runtime

gcc-java-4.1-20071203.tar.bz2 Java front end and runtime

gcc-objc-4.1-20071203.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20071203.tar.bz2The GCC testsuite

Diffs from 4.1-20071126 are available in the diffs/ subdirectory.

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

Re: Issue with fixincludes (?) and `limits.h'

[Ian Lance Taylor]

Thomas Schwinge <[EMAIL PROTECTED]> writes:

> Is this a GCC issue or should the glibc build system be adding a
> ``-isystem [GCC target]/4.3.0/include-fixed''?

The latter.

http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html

Ian

Re: Issue with fixincludes (?) and `limits.h'

[Thomas Schwinge]

Hello!

On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > Is this a GCC issue or should the glibc build system be adding a
> > ``-isystem [GCC target]/4.3.0/include-fixed''?
> 
> The latter.
> 
> http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html

I will ping the glibc crew and put your patch into the glibc bugzilla,
for CVS HEAD and glibc-2_7-branch, OK?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Issue with fixincludes (?) and `limits.h'

[Ian Lance Taylor]

Thomas Schwinge <[EMAIL PROTECTED]> writes:

> Hello!
> 
> On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > Is this a GCC issue or should the glibc build system be adding a
> > > ``-isystem [GCC target]/4.3.0/include-fixed''?
> > 
> > The latter.
> > 
> > http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html
> 
> I will ping the glibc crew and put your patch into the glibc bugzilla,
> for CVS HEAD and glibc-2_7-branch, OK?

It's not my patch, but that sounds like a good plan.

Ian

Re: Issue with fixincludes (?) and `limits.h'

[Thomas Schwinge]

Hello!

On Mon, Dec 03, 2007 at 05:05:10PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > > Is this a GCC issue or should the glibc build system be adding a
> > > > ``-isystem [GCC target]/4.3.0/include-fixed''?
> > > 
> > > The latter.
> > > 
> > > http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html
> > 
> > I will ping the glibc crew and put your patch into the glibc bugzilla,
> > for CVS HEAD and glibc-2_7-branch, OK?
> 
> It's not my patch

Indeed.  Sorry.

> but that sounds like a good plan.




Regards,
 Thomas


signature.asc
Description: Digital signature

problems when move one pseudo reg to another (need help)

[r z]

Hello!
  Execuse me but I have something bothering me.
  I inserted a method into rest_of_compilation() (before calling
rest_of_handle_life()) to insert some new insn before insn were
translated to asm. But after my modification, when processing some
insn moving one pseudo reg to another pseudo reg(created by me), the
reg_overlap_mentioned_for_reload_p() method executed abort() at line
6341:
if (regno >= FIRST_PSEUDO_REGISTER)
{
if (reg_equiv_memory_loc[regno])
return refers_to_mem_for_reload_p (in);
else if (reg_equiv_constant[regno])
return 0;
abort ();
}

  By the way, I am using source code of gcc3.4.4.
  Could anyone give some help? I am new here. Thanks.
  (I will back again one day later after school)

appendix:
1. the insn with problem:
   (insn 59 24 60 0 (set (reg:SI 74)
(reg:SI 71)) -1 (nil)
(nil))
2. gdb backtrace after calling abort()
(gdb) backtrace
#0  fancy_abort (file=0x839ae65 "reload.c", line=6334,
function=0x8383600 "reg_overlap_mentioned_for_reload_p") at diagnostic.c:584
#1  0x0823d648 in reg_overlap_mentioned_for_reload_p (x=
0xb7cd15d0, in=0xb7cd15c0) at reload.c:6334
#2  0x0824917f in find_reloads (insn=0xb7ed6730, replace=0,
ind_levels=0, live_known=0,
reload_reg_p=0x84081c0) at reload.c:1721
#3  0x08254514 in reload (first=0xb7ed3240, global=0) at reload1.c:1459
#4  0x08274f58 in rest_of_handle_old_regalloc (decl=0xb7cabf30,
insns=0xb7ed3240)
at ./toplev.c:2295
#5  0x082765df in rest_of_compilation (decl=0xb7cabf30) at ./toplev.c:3457
#6  0x082b50e5 in tree_rest_of_compilation (fndecl=0xb7cabf30, nested_p=false)
at tree-optimize.c:168
#7  0x08059230 in c_expand_body_1 (fndecl=0xb7cabf30, nested_p=74) at
c-decl.c:6189
#8  0x082b6ad9 in cgraph_expand_function (node=0xb7c8d438) at cgraphunit.c:538
#9  0x082b7aac in cgraph_assemble_pending_functions () at cgraphunit.c:144
#10 0x082b8380 in cgraph_finalize_function (decl=0xb7cabf30,
nested=false) at cgraphunit.c:225
#11 0x0805f345 in finish_function () at c-decl.c:6146
#12 0x0804c76b in yyparse () at c-parse.y:385
#13 0x0804f57b in c_parse_file () at c-parse.y:3029
#14 0x0807e297 in c_common_parse_file (set_yydebug=0) at c-opts.c:1249
#15 0x08273b0e in toplev_main (argc=3, argv=0xbfc0b9f4) at ./toplev.c:1833
#16 0x0809e75e in main (argc=Cannot access memory at address 0x4a
) at main.c:35
(gdb)

Re: Rant about ChangeLog entries and commit messages

[Nicholas Nethercote]

On Mon, 3 Dec 2007, Andi Kleen wrote:


Commit logs are basically invisible;


That's just a (fixable) problem in your coding setup. In other
projects it is very common to use tools like cvs annotate / cvsps /
git blame / git log / etc. to find the reasons for why code is the way
it is. In fact in several editors these can be functions on hot
keys. Programming is hard enough as is without ignoring such valuable
information sources. Don't do it.


I didn't say you cannot or should not use these tools.  But a good comment 
on a piece of code sure beats a good commit message, which must be looked at 
separately, and can be fragmented over multiple commits, etc.


Nick