Re: Mis-handled ColdFire submission?
Mike Stump wrote: Yeah, spending large amounts of time in stage2 and 3 does have disadvantages. I'd rather have people that have regressions spend a year at a time in stage2-3... :-( Maybe we should have trunk be stage1, and then snap over to a stage2 branch when the stage1 compiler is ready to begin stage2, and likewise, when the stage2 compiler is ready to go to stage3, it then snaps to the release branch. This gives a place for the preintegration of stage1 level work when ever that work is ready, without having to delay it for months at a time. [...] I've not spent much time thinking about this, this is just off the cuff, but, I thought I would post it as 9 months in stage2-3 seems like a long time to me. One contrary argument, I suppose, is the hypothesis that if there is always a stage-1 branch open, nobody will want to work on fixing the bugs rather than implementing new features. To some extent, the gfortran part of things could be considered a bit of an experiment about this -- your suggestion is not too far off of how gfortran was being developed, up until about the time 4.2 went into stage 3. My personal viewpoint isn't an especially good view of that data, since I haven't been working on the project that long, but in my limited experience it doesn't seem that working on stage-1 type things is being a remarkable limit on the amount of effort people put into fixing bugs, and the data that Steve Kargl posted as a year-end summary indicates at a rough glance that most of the people active on gfortran were active in fixing bugs. However, one thing I have definitely noticed is that keeping track of a number of active branches takes a fair bit of effort. Currently, most applicable patches get backported to 4.2, but I'm sure a number get overlooked (especially if they're not directly tracked in a PR), but 4.1 is at this stage pretty much stagnant. I'm not sure how this would translate to GCC, which has lots more people and is considerably more mature, but my guess is that it would take a significant bit of additional effort to keep all the bug-fixes distributed to all the relevant branches, and I'm not sure how much people would put in that extra effort. - Brooks
Re: Mis-handled ColdFire submission?
On Thu, Jan 11, 2007 at 02:35:40PM -0500, Peter Barada wrote: > > 28181 has been popping up over the last several years in various forms > (5373, 13803, 18421, 23695, etc). 5753, I guess. Yes, being a reload problem, it can become latent due to unrelated changes. It is important not to close the bug as fixed in that case. Which is what happened, unfortunately. -- Rask Ingemann Lambertsen
Re: RFC: Walways-true considered harmful
On Sat, Jan 13, 2007 at 04:08:18AM +, Manuel López-Ibáñez wrote:
> Much later, the warning was given a name, Walways-true [3], since the
> warning message said explicitly that something will always be true.
> However, Andrew Morton didn't want to get a warning just because the
> expression was always true. He wanted to be warned of using the
> address of a function where it makes more sense to call the function.
Also, while it will be good to warn about
if (func)
{
...
}
it'll be bad to warn about
if (timerstruct->callbackfunc)
{
...
timerstruct->callbackfunc (...);
...
}
so be careful when implementing such warnings.
--
Rask Ingemann Lambertsen
RE: RFC: Walways-true considered harmful
On 13 January 2007 12:55, Rask Ingemann Lambertsen wrote:
> On Sat, Jan 13, 2007 at 04:08:18AM +, Manuel López-Ibáñez wrote:
>
>> Much later, the warning was given a name, Walways-true [3], since the
>> warning message said explicitly that something will always be true.
>> However, Andrew Morton didn't want to get a warning just because the
>> expression was always true. He wanted to be warned of using the
>> address of a function where it makes more sense to call the function.
>
>Also, while it will be good to warn about
>
> if (func)
> {
> ...
> }
>
> it'll be bad to warn about
>
> if (timerstruct->callbackfunc)
> {
> ...
> timerstruct->callbackfunc (...);
> ...
> }
>
And equally bad to warn about
> if (func)
> {
> ...
func (...);
> ...
> }
Did you mean to limit it specifically to struct members?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: RFC: Walways-true considered harmful
On 13 January 2007 14:00, Dave Korn wrote:
> On 13 January 2007 12:55, Rask Ingemann Lambertsen wrote:
>
>>
>> if (func)
>> {
>> ...
>> }
>>
>> it'll be bad to warn about
>>
>> if (timerstruct->callbackfunc)
>> {
>> ...
>> timerstruct->callbackfunc (...);
>> ...
>> }
>>
>
> And equally bad to warn about
>
>> if (func)
>> {
>> ...
> func (...);
>> ...
>> }
Nope, hang on.. that first 'func' is an explicit function name, the second
two cases are meant to be variables... I don't see why it should be any
problem to only warn for explicit function names.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Invariant division
drizzle drizzle wrote: Hi Does gcc do an divison by constant optimization for any 16 bit architecture. Can anyone point me to where it does that ? Yes, in expmed.c (expand_divmod). Paolo
fat binaries for FSF gcc on Darwin?
I noticed that Apple's gcc compiler in MacOS X 10.4 creates fat binaries in /usr/lib rather than using a ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin gcc developers ever intend to replicate the use of fat binaries for FSF gcc (in gcc 4.3 perhaps) or will we always use separate subdirectories for 32-bit and 64-bit shared libraries? Jack
Re: fat binaries for FSF gcc on Darwin?
On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote: I noticed that Apple's gcc compiler in MacOS X 10.4 creates fat binaries in /usr/lib rather than using a ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin gcc developers ever intend to replicate the use of fat binaries for FSF gcc (in gcc 4.3 perhaps) or will we always use separate subdirectories for 32-bit and 64-bit shared libraries? All of that is done by a script that calls configure and post-processes the resultant builds with the exception of libgcc which is built fat in either place. -eric
Re: debugging capabilities on AIX ?
> The reaction varies with developer. AIX continues to use > xcoff/stabs. The feedback of AIX users to IBM sales representatives and > executives will determine the response. FYI Sun has switched to DWARF-2 by default in Studio 11. Just to put a bit of pressure on you. :-) -- Eric Botcazou
Re: RFC: Walways-true considered harmful
On 13/01/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: On Sat, Jan 13, 2007 at 04:08:18AM +, Manuel López-Ibáñez wrote: so be careful when implementing such warnings. That warning is already implemented in 4.2 and it is called Walways-true. You can play with it and fill a bug if you think that the warning is inappropriate in some cases. That is not what my original mail is about. Cheers, Manuel.
Re: Mis-handled ColdFire submission?
On Sat, 13 Jan 2007 00:38:48 -0800, Brooks Moses wrote: > One contrary argument, I suppose, is the hypothesis that if there is > always a stage-1 branch open, nobody will want to work on fixing the bugs > rather than implementing new features. That already happens, the stage-1 branch just isn't always the one at svn://gcc.gnu.org/svn/gcc/trunk. You basicly can't prevent people from implementing new features. It will inevitably be the case that some people will focus more on adding new features than on fixing bugs and vice versa. -- Rask Ingemann Lambertsen
Re: fat binaries for FSF gcc on Darwin?
Eric, So will FSF gcc on Darwin maintain the current 64-bit subdirectory or will it eventually migrate to using fat binaries as Apple gcc does? Jack On Sat, Jan 13, 2007 at 07:02:10AM -0800, Eric Christopher wrote: > > All of that is done by a script that calls configure and post-processes > the resultant builds with the exception of libgcc which is built fat > in either place. > > -eric
Re: Mis-handled ColdFire submission?
On Wed, 10 Jan 2007, Joe Buck wrote: > On Wed, Jan 10, 2007 at 02:56:48PM -0700, Tom Tromey wrote: >> The patch tracker would help with that. >> >> I noticed recently that contribute.html doesn't seem to mention the >> patch tracker. Is there a reason for this omission? > I guess no one submitted a patch to the web page yet (hint, hint). Late last year Daniel volunteered to write up a bit, I assume it just didn't pop to the head of his queue. Gerald
Re: Enforcing order of execution for function arguments
Actually, I was thinking about the case "g(a(), b());". Let's imagine the gimplified code (because of your change) looks like: t1 = a(); t2 = b(); g(t1, t2); Are we always sure that t1 and t2 will not be pushed again in the CALL_EXPR by further transformations? No, and that's a good thing. What you _would_ be sure of is that the generated code will behave *as-if* a() is executed before b(). Segher
Re: fat binaries for FSF gcc on Darwin?
On Jan 13, 2007, at 8:28 AM, Jack Howarth wrote: Eric, So will FSF gcc on Darwin maintain the current 64-bit subdirectory or will it eventually migrate to using fat binaries as Apple gcc does? Current is likely. -eric
compile time enforcement of exception specification
Hi, Will g++ ever add a compile time enforcement of the exception specification like the Java compiler does? I find the exception specification almost useless with out this functionality. Thanks, Bob Rossi
Re: compile time enforcement of exception specification
> > Hi, > > Will g++ ever add a compile time enforcement of the exception > specification like the Java compiler does? > > I find the exception specification almost useless with out this > functionality. The C++ standard ( 15.4/10) is very specific that the implemantion should not reject code just because of exception specification and calling other functions. -- pinski
Re: compile time enforcement of exception specification
On Sun, Jan 14, 2007 at 12:16:32AM -0500, Andrew Pinski wrote: > > > > Hi, > > > > Will g++ ever add a compile time enforcement of the exception > > specification like the Java compiler does? > > > > I find the exception specification almost useless with out this > > functionality. > > The C++ standard ( 15.4/10) is very specific that the implemantion should not > reject code just because of exception specification and calling other > functions. Do you have a link to the standard some where? Will g++ not implement compile time enforcement until a standard says it's OK to do so? This feature is obviously an improvement over doing nothing. Wouldn't an option to g++ be only helpful here? Thanks, Bob Rossi
