Re: Rant about ChangeLog entries and commit messages
> 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. Unless there's a good reason _not_ to derive from a source, and there are several, most of which require a clean-room approach, or a simulation of it. I'm just now starting to move over to Subversion, and I'm sure it has the same ability, to publish CVS logs, though not via CVS itself. C-x v u :) -- Ctalk Home Page: http://www.ctalklang.org/
FW[0]:
E-Mail реклама Скоростные МегаСуперКачество! 648 6761
Re: Rant about ChangeLog entries and commit messages
> 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. I don't see one as "beating" the other because they have very different purposes. Sometimes you need one and sometimes you need the other. The purpose of COMMENTS is to help somebody understand the code as it stands at some point in time. In most cases, that means saying WHAT the code does and WHY (at some level) it does what it does. Once in a while, it also means saying why it DOESN'T do something, for example, if it might appear that there's a simpler way of doing what the code is doing now but it doesn't work for some subtle reason. But it's NOT appropriate to put into comments the historical remark that this code used to have a typo which caused a miscompilation at some specific place. However, the commit log IS the place for that sort of note. My view is that, in general, the comments are usually the most appropriate place to put information about how the code currently works and the commit log is generally the best place for information that contrasts how the code currently works with how it used to work and provides the motivation for making the change. But there are exceptions to both of those generalizations.
Re: Link tests after GCC_NO_EXECUTABLES
On Sat, Dec 01, 2007 at 11:34:47PM +0100, Rask Ingemann Lambertsen wrote: > Index: configure.ac > === > --- configure.ac (revision 130442) > +++ configure.ac (working copy) > AC_SUBST(CONFIGURE_GDB_TK) > AC_SUBST(GDB_TK) > AC_SUBST(INSTALL_GDB_TK) > +AC_SUBST(with_newlib) > > # Build module lists & subconfigure args. > AC_SUBST(build_configargs) That hunk is corrupt, it should look like this: Index: configure.ac === --- configure.ac(revision 130442) +++ configure.ac(working copy) @@ -2435,6 +2435,7 @@ AC_SUBST(CONFIGURE_GDB_TK) AC_SUBST(GDB_TK) AC_SUBST(INSTALL_GDB_TK) +AC_SUBST(with_newlib) # Build module lists & subconfigure args. AC_SUBST(build_configargs) -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
fw[1]:
[EMAIL PROTECTED] раскрутка Скоростные Мегакачественные 6Ч86З-8Ч
Re: Rant about ChangeLog entries and commit messages
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes: Diego> I'm not sure people will want to drop ChangeLogs anytime soon. I Diego> don't find them all that useful, but I *have* used them extensively Diego> when doing archeology. It gives you the initial thread to pull when Diego> finding out about changes. Yeah. They aren't incredibly useful, but they aren't useless, either. One thing they give you that 'svn annotate' does not is a record of when things were deleted. I use them this way on occasion. I have a few concerns about a change in this area. First, continuing to have good quality messages. Right now at the very least you get a (semi-) accurate record of what was touched. I've seen plenty of ChangeLog-less projects out there than end up with commits like "fixed a bug", or even worse. I suppose we'll need to review the commit messages just like we review ChangeLog entries now. That doesn't sound fun, but I suppose it won't be too much work. Second, whether it makes the process heavier: Diego> The only annoying issue with this proposal is that it forces the Diego> committer to fish out the message URL from the mailing lists, so Diego> perhaps we could make the check a warning instead of an error. This would be a big pain. Perhaps it wouldn't be so bad if the mail server added a URL to the header somewhere, so I could wait for the mail to come back and then look it up. The obvious alternative of hitting reload on the gcc web page is unattractive. Also it seems to me that this will make it a bit harder for developers without write access to get their patches checked in ... because it will mean even more work for whoever does the commit. Tom
Serious Bugs In Gcc Builds
Gentle People: I am writing to you today to document several serious build bugs in GCC releases gcc-3.4.6, gcc-4.0.4, and gcc-4.1.2. To be honest I have wasted several days of work on reflector interaction and attempts to work around these issues all to no avail! I have been unable to build a usable gcc on my Solaris 8 Sparc System! By the way don't bother flaming back at me I am way beyond this and thus impervious! Hopefully by fixing the issues documented below you will open up the GCC software to be usable by a larger audience of users. Issue 1) The configure and build scripts insist (read that fight to the death) on using the solaris linker (/usr/ccs/bin/ld) despite every effort to the contrary, and this of course causes errors. The following were my failed efforts to redirect it to the Gnu Linker (/opt/sfw/bin/gld): a) Providing explicit command line direction to configure. /export/home/tools/gcc/gcc-4.0.4/configure --with-gnu-ld --with-gnu-as --with-as=/opt/sfw/bin/as --with-ld=/opt/sfw/bin/ld b) Provide links in the object directory attempting to redirect it: ln -s /opt/sfw/bin/gld ld c) Provide links in the executable directory attempting to redirect it: ln -s gld ld d) Reordering the path so that the Gnu Tools would appear first. e) Removing the Solaris Linker from the path. Issue 2) Same as Issue 1 except for the Gnu assembler (/opt/sfw/bin/gas). Issue 3) After unzipping and untarring release gcc-4.1.2 I changed the owner (chown) and file mode (chmod) to values compatible with my environment. This caused build errors with make complaining of files being touched or changes which required a call to makeinfo, and a further complaint that makeinfo was missing. A subsequent test of makeinfo --version in the same shell as the attempted build indicated that makeinfo was present. Issue 4) What's In A Name? Or what the hell should we name it? When I down load and install various releases of GNU Bintools a tool like GNU Make is sometimes called gmake and sometimes called make. This causes confusion and thus errors in that the Gcc build scripts use make. I would suggest standardizing on the names to prevent confusion. To this end I would suggest that GNU Make always, always, always be called gmake and when you want to use GNU Make in your project that you type gmake. Issue 5) The build process is way to complicated for the average user to negotiate successfully. The user interface should be simplified to the following for a native compiler: ./configure gmake gmake install - A listing or the commands used in the various build attempts: ; ; Gcc Build gcc-3.4.6 ; ; Use gmake gls, gas - required! ; Using csh ; Changed $path in /root/.cshrc to put /opt/sfw/bin first to pick up ; GNU Tools first. cd /export/home/tools/gcc gunzip gcc-3.4.6.tar.gz tar -xvif gcc-3.4.6.tar ; -i -> Ignore directory checksum errors. mkdir gcc-3.4.6-obj chmod 777 gcc-3.4.6-obj cd gcc-3.4.6-obj ln -s /opt/sfw/bin/gmake make ln -s /opt/sfw/bin/gld ld ln -s /opt/sfw/bin/gas as /export/home/tools/gcc/gcc-3.4.6/configure --with-gnu-ld --with-gnu-as --with-as=/opt/sfw/bin/as --with-ld=/opt/sfw/bin/ld gmake DESTDIR=/export/home/tools/gcc/gcc-3.4.6-bin install ; ; Gcc Build gcc-4.0.4 ; ; Use gmake gls, gas - required! ; Using csh cd /export/home/tools/gcc gunzip gcc-4.0.4.tar.gz tar -xvif gcc-4.0.4.tar ; -i -> Ignore directory checksum errors. cd gcc-4.0.4-obj ln -s /opt/sfw/bin/gmake make ln -s /opt/sfw/bin/gld ld ln -s /opt/sfw/bin/gas as /export/home/tools/gcc/gcc-4.0.4/configure --with-gnu-ld --with-gnu-as --with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin gmake DESTDIR=/export/home/tools/gcc/gcc-4.0.4-bin install ; ; Gcc Build gcc-4.1.2 ; ; Use gmake gls, gas - required! ; Using csh cd gcc-4.1.2-obj ln -s /opt/sfw/bin/gmake make ln -s /opt/sfw/bin/gld ld ln -s /opt/sfw/bin/gas as /export/home/tools/gcc/gcc-4.1.2/configure --with-gnu-ld --with-gnu-as --with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin gmake DESTDIR=/export/home/tools/gcc/gcc-4.1.2-bin install
Clarification on section variable attribute usage
Hi,
Since at least 3.4, the GCC manual says:
Use the `section' attribute with an _initialized_ definition of a
_global_ variable, as shown in the example. GCC issues a warning
and otherwise ignores the `section' attribute in uninitialized
variable declarations.
but this doesn't seem correct.
For example the Linux kernel creates several data sections mainly for
parking data which are only used during boot time and freed at
runtime.
Taken from the kernel source code (drivers/acpi/tables.c), this is how
such variable is stated:
static int acpi_apic_instance __attribute__ ((__section__ (".init.data")));
When compiling the driver, no warning is issued _and_ the section
attribute is not ignored. So either the documentation is wrong or the
compiler is misbehaving.
Could anybody clarify this point ?
Thanks,
Franck
Re: Rant about ChangeLog entries and commit messages
On Mon, 2007-12-03 at 08:29 -0500, Richard Kenner 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. > > 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. Right. I don't necessarily want verbose ChangeLogs -- there are times I just want to know what changed and who changed it. That's nice and easy to extract from the ChangeLog. Sometimes I want to look at the code/comments. Obviously I go to the source to read those. Sometimes I want even more information for a particularly complex or controversial change -- in those cases I go back to the mailing list archives and review the discussion(s) leading to changes to the code. Each repository of information provides a different level of detail and each (IMHO) has its place/utility. Jeff
Bad offset to struct member in generated code
Hi,
I have a problem while porting gcc to a custom processor. Here is a
simplified example:
struct big_struct {
...
int a;
char b;
char c;
...
} testme;
char char_tmp;
int int_tmp;
int testit(void)
{
char_tmp = testme.c;
int_tmp = testme.a;
}
For the first line of code in testit(), gcc will load the address of
'testme.c' into a register, then do an indirect 8-bit load with an
offset of 0 to fetch the value of 'testme.c'. This is fine.
For the second line, gcc will reuse the same address register, and
generate an indirect 32-bit load with an offset of -5 to fetch the
value of 'testme.a'. But on our custom processor, the offsets of
indirect load instructions are scaled by the size of the data item.
So the assembly instruction generated for the second line is something
like "ld32 %r1, %r0, -5/4", which can not be translated by the
assembler.
So when accessing a data structure, we need gcc to always use a base
address that is a multiple of 4, to prevent this from happening.
So how do I tell gcc about this limitation of our architecture? Do I do
this somehow using the REG_MODE_OK_FOR_BASE_P or
GO_IF_MODE_DEPENDENT_ADDRESS macros in our architecture's .h file? I am
using the gcc 4.0.2 sources if that matters.
Thanks,
Paul
paulz at synopsys dot com
Re: Bad offset to struct member in generated code
"Paul Zimmerman" <[EMAIL PROTECTED]> writes: > For the second line, gcc will reuse the same address register, and > generate an indirect 32-bit load with an offset of -5 to fetch the > value of 'testme.a'. But on our custom processor, the offsets of > indirect load instructions are scaled by the size of the data item. > So the assembly instruction generated for the second line is something > like "ld32 %r1, %r0, -5/4", which can not be translated by the > assembler. > > So when accessing a data structure, we need gcc to always use a base > address that is a multiple of 4, to prevent this from happening. > > So how do I tell gcc about this limitation of our architecture? Do I do > this somehow using the REG_MODE_OK_FOR_BASE_P or > GO_IF_MODE_DEPENDENT_ADDRESS macros in our architecture's .h file? I am > using the gcc 4.0.2 sources if that matters. You need to fix this in GO_IF_LEGITIMATE_ADDRESS. It may help to look at thumb1_legitimate_address_p and thumb_legitimate_offset_p in config/arm/arm.c. Ian
