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
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
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
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 Mor
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 (...);
>> ...
>> }
>
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
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 subdi
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 g
> 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 Botca
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 i
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'
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
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
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. W
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
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
>
> 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
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++
18 matches
Mail list logo
