Andrew Haley-5 wrote:
>
> Angus writes:
> >
> > I have gcc 4.0.2 and 4.1.2 and in the one particular case if I use the
> > fastcall attribute valgrind reports a bunch of errors, and I get a
> > segmentation fault, for which fastcall is key. But I believe it is more
> than
> > just key, I believe the fastcall attribute to be the cause, since when
> I run
> > valgrind on my app w/out fastcall, or in a 64-bit environment, valgrind
> > doesn't report anything wrong.
> > I'm using the fastcall attribute in 3 places. One is this
> stand-alone
> > function, and the other two are pure virtual methods of a class. Oddly
> > enough, the pure virtuals aren't giving me any trouble at all (since
> I'm
> > very caseful to declare the overrides with like attributes). In all
> cases
> > the full attributes declaration is: __attribute__((const, nothrow,
> > fastcall)).
> > Could I be using fastcall wrong, or is it just a dangerous attribute
> to
> > work with?
>
> I wouldn't say it was dangerous, exactly. I suspect there is a
> problem soemewhere with your declarations, but until you give us a
> test case we won't know.
>
I figured out what the problem was. I forgot to include the header file
with the definition, so obviously there was no way for the function to know
that it was supposed to use the fastcall convention, but all the callers
did. It's very unlike me to omit the inclusion of the header, even though
for functions it is almost never necessary. But the one time it was
necessary, I didn't do it. Thanks.
--
View this message in context: http://www.nabble.com/Is-fastcall-broken--tf3995991.html#a11359697
Sent from the gcc - Help mailing list archive at Nabble.com.
