Right, page 211 of the C++ standard (2003) explains when copy-ctor and
dtor are allowed to be optimized away. But the two circumstances are
both like this:
A is constructed; A is copy-constructed to B; A is destructed
Here A is a temporary object in some sense, and the standard allows
for directly
I wrote a simple test program that works just fine on my 64 bit system.
The problem must lie somewhere in the GNUStep libraries. Sorry about
the waste of bandwidth.
Thanks,
Jose.
Jose Quinteiro wrote:
> Please forgive me if I'm being dense, I'm very new to Objective-C.
>
> The problem was that
Please forgive me if I'm being dense, I'm very new to Objective-C.
The problem was that a class in GNUMail (PGPController) implemented a
method thusly:
- (NSString *) version
{
return @"v0.9.1";
}
That method is declared in the GNUMailBundle protocol. GNUMail would
segfault when the point
On Sep 11, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> That's a possibility, but I don't want to commit at this point. We can
> have a look at it when you submit it and decide. However, in general,
> introducing churn for the sake of a feature that will be off by default
> isn't something t
On 9/26/07, Jose Quinteiro <[EMAIL PROTECTED]> wrote:
> Hello,
>
> The getter/setter for version in Object.M gets/takes an int, and they
> eventually get/set the "version" field in struct objc_class. This
> field is declared as a long in objc/objc.h.
Why? Any change here will change the ABI so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you for a quick reply! :)
I was to do dynamic cpu dispatching code (which could also benefit
autovectorization). I'm checking out the trunk now.
I've already implemented an userland library to do cpu detection, and
the initialization hook goes
Hello,
The getter/setter for version in Object.M gets/takes an int, and they
eventually get/set the "version" field in struct objc_class. This
field is declared as a long in objc/objc.h.
I'm asking because I think this was causing a crash in GNUMail on 64-bit
systems. More detail:
https
Boehm, Hans wrote:
David -
If I understand this correctly, you added a sync instruction to most of
the __sync implementations on MIPS,
Correct. These primitives are new in GCC-4.3 for MIPS. My first
attempt was not entirely successful. I hope the revised version yields
better results.
"V. Karthik Kumar" <[EMAIL PROTECTED]> writes:
> I require help with some work i've been doing lately on gcc (4.2.1
> tree). I have managed to put some code in.
>
> Now, for function compilation, i require to invoke the i386 (as of
> now) backend multiple times and with different switches; one ti
On Wed, 2007-09-26 at 23:35 +0800, 吴曦 wrote:
> Thanks, it's the problem of pass_stack_adjustments.
pass_stack_adjustments isn't in gcc-4.2.x; it is only on mainline. But
the flow stuff you are using isn't on mainline anymore since the
dataflow merge. Maybe you are using a month or two old snapsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I require help with some work i've been doing lately on gcc (4.2.1
tree). I have managed to put some code in.
Now, for function compilation, i require to invoke the i386 (as of
now) backend multiple times and with different switches; one time wit
Richard Guenther wrote:
On 9/26/07, Ralf Lübben <[EMAIL PROTECTED]> wrote:
Hello,
maybe this is the better list to post the problem (see below).
This is off-topic here, gcc-help would be a more appropriate list.
True, but it appears to be a glibc problem, rather than one which can
On 9/26/07, Ralf Lübben <[EMAIL PROTECTED]> wrote:
> Hello,
>
> maybe this is the better list to post the problem (see below).
This is off-topic here, gcc-help would be a more appropriate list.
> Regards
> Ralf
>
> On Wednesday, 26. September 2007 18:23:34 Ralf Lübben wrote:
> > Ok,
> >
> > the p
Hello,
maybe this is the better list to post the problem (see below).
Regards
Ralf
On Wednesday, 26. September 2007 18:23:34 Ralf Lübben wrote:
> Ok,
>
> the problems seems to be the pow() function. If I use instead the function
> gsl_pow_int(double x, int n) from the gsl library the performance
I'm having a look at building GCC with OpenWatcom to reduce build
times. There seems to be something wrong with the build machinery:
$ diff -u {,build-i686-pc-linux-gnuaout/}libiberty/Makefile
--- libiberty/Makefile 2007-09-26 17:02:58.0 +0200
+++ build-i686-pc-linux-gnuaout/libiberty/
2007/9/26, Jim Wilson <[EMAIL PROTECTED]>:
> On Tue, 2007-09-25 at 15:13 +0800, 吴曦 wrote:
> > propagate_one_insn), I don't understand why GCC fails the computation
> > of liveness if there is no optimization flag :-(.
>
> There is probably something else happening with -O that is recomputing
> some
In version 1, the return type is "a_t", so a class construction is
required there (the caller will then destruct the returned object).
Construction and destruction can have side effects, so the compiler
would not drop them. For the following code,
template
inline a_t& append (a_t & a, b_t const& b
gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
I noticed the following code
=== version 1:
template
inline a_t append (a_t & a, b_t const& b) {
a.insert (a.end(), b.begin(), b.end());
return a;
}
=== version 2:
template
inline void append (a_t & a, b_t const& b) {
a.insert (a.end(), b.begin(
18 matches
Mail list logo
