[Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc
SourceForge.net
noreply at sourceforge.net
Wed Mar 12 17:20:47 EST 2003
Bugs item #692878, was opened at 2003-02-25 08:27
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127
Category: None
Group: Platform Specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Rolf Ade (pointsman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: FASTCALL problem with Solars/gcc
Initial Comment:
Talking about 1.95.6 (of course, prior to that, the
FASTCALL macro was a noop, if I recall right).
I got two independend reports about compiler warnings,
while compiling expat with gcc under Solaris. The one
specified his gcc version (2.7.2.3) without saying the
exact Solaris Version, the other uses Solaris 2.6 and a
not specified gcc version. Both get plenty of similar
warning like this:
In file included from ../expat/xmlrole.h:14,
from ../expat/xmlrole.c:14:
../expat/xmltok.h:143: warning: `regparm' attribute
directive ignored
../expat/xmltok.h:144: warning: `regparm' attribute
directive ignored
../expat/xmltok.h:149: warning: `regparm' attribute
directive ignored
....
It seems, the FASTCALL macro in internal.h is the
source of the trouble.
rolf
----------------------------------------------------------------------
>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-12 20:20
Message:
Logged In: YES
user_id=290026
What about making all of these macros noop, but leaving
them there in case anyone wants to to tune Expat for their
own purposes? It was some effort to put them there in the
first place.
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-03-12 20:13
Message:
Logged In: YES
user_id=3066
The Mac OS X issue is why I didn't close this report.
I recall seeing a concrete but small speed improvement on
Linux, at least for whatever version of GCC I was using at the
time.
Given that the speedup was small, I'm currently inclined to
remove the FASTCALL/PTRCALL/PTRFASTCALL stuff
completely. I'll bring it up on expat-discuss and see if there
are any real objections; regardless of how careful we are to
enable it only where it's known to help, I expect the
maintenance nightmare to only get worse.
----------------------------------------------------------------------
Comment By: Rolf Ade (pointsman)
Date: 2003-03-12 19:51
Message:
Logged In: YES
user_id=13222
This will not fix the problem with gcc 3.1 on Mac OS X.
I'm sorry, I ball out, for this time. I'm preparing for a
release of an expat based package within the next days, and
it will come out with 1.95.6 but without the regparm stuff
(made it noop, as it was in 1.95.5).
Given the bad experience, I see two major ways at the moent:
o Revers the method: Instead of enabling this regparm stuff
for gcc as default and only disable it for plattforms with
know troubles, disable it per default and enable it only for
the plattforms, on which it is know to work and make at
least a small positiv (speed up) effect. This would be, as
far as I know, at the moment only linux (according to some
rumor results by Fred).
o Remove it.
rolf
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-03-12 18:15
Message:
Logged In: YES
user_id=3066
Committed fix for GCC on Solaris as lib/internal.h 1.5.
I think we really need to consider removing all this stuff
to avoid having constant portability problems. ;-(
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-07 09:28
Message:
Logged In: YES
user_id=290026
It seems "__attribute__ (regparm(3))" is legal in gcc 3.1.
The problem is rather that the function pointer
declaration syntax used on line 143 in xmltok.h
is not accepted by gcc 3.1.
Could you try:
1) define the PTRFASTCALL macro with extra
parentheses around
or
2) instead of the existing declaration, try this:
int PTRFASTCALL(*nameLength)(const ENCODING *,
const char *);
Itf that works, then I bet it won't work under other
versions of gcc, as luck will have it.
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-07 09:08
Message:
Logged In: YES
user_id=290026
It would be nice if the different versions of gcc could
agree on what syntax is legal!
----------------------------------------------------------------------
Comment By: Rolf Ade (pointsman)
Date: 2003-03-07 06:24
Message:
Logged In: YES
user_id=13222
More regparm fun. gcc 3.1 on Mac OSX:
../expat/xmltok.h:143: syntax error, found `*'
../expat/xmltok.h:143: illegal member declaration, missing
name, found `)'
../expat/xmltok.h:144: syntax error, found `*'
../expat/xmltok.h:144: illegal member declaration, missing
name, found `)'
../expat/xmltok.h:149: syntax error, found `*'
../expat/xmltok.h:149: illegal member declaration, missing
name, found `)'
cpp-precomp: warning: errors during smart preprocessing,
retrying in basic mode
In file included from ../expat/xmlrole.h:14,
from ../expat/xmlrole.c:14:
../expat/xmltok.h:143: warning: `regparm' attribute
directive ignored
../expat/xmltok.h:144: warning: `regparm' attribute
directive ignored
../expat/xmltok.h:149: warning: `regparm' attribute
directive ignored
../expat/xmltok.h:280: warning: `regparm' attribute
directive ignored
.
etc.
rolf
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-01 09:25
Message:
Logged In: YES
user_id=290026
Rolf,
In theory regparm(2 or 3) should improve speed since
it allows the compiler to choose passing parameters
in registers instead of on the stack.
The reason why this doesn't work on Windows is that
the MS compiler allows register passing to be combined
with stdcall only, not with cdecl. And for Expat purposes
it seems cdecl is way faster, so this overcompensates any
gain register passing with stdcall could give you.
However, with gcc it seems that regparm can be combined
with cdecl, or rather must be, since AFAIK stdcall doesn't
really exist on Linux.
----------------------------------------------------------------------
Comment By: Rolf Ade (pointsman)
Date: 2003-02-25 16:41
Message:
Logged In: YES
user_id=13222
Freds patch fixed the problem for both reporters:
"Works fine now {
uname -a
SunOS Develop 5.6 Generic_105181-32 sun4u sparc
gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.3/specs
gcc version 2.7.2.3
}"
and
"Works for me now as well (gcc v 2.8.1)"
Thanks!
rolf
----------------------------------------------------------------------
Comment By: Rolf Ade (pointsman)
Date: 2003-02-25 11:26
Message:
Logged In: YES
user_id=13222
I've handed the patched version to the original reporters.
Will report about the results (if I get answer).
Re regparm(2) instead of regparm(3). There isn't a value in
using regparm by itself. I think it only makes sense, to use
this, if it in deed speeds up things at least a little bit
(this seems not guaranteed, as Karls result on w32 shows).
If I recall right, Fred had measured a little speed up on
linux. I guess, it would be better, to find a volunteer,
which checks, if this compiler hints in fact makes a
measurable difference, before we try to play advanced tricks.
rolf
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2003-02-25 10:34
Message:
Logged In: YES
user_id=290026
This seems to affect older compilers?
Maybe a task for the build (autoconf?).
One could also try regparm(2) instead of regparm(3).
Assuming these compilers recognize regparm at all.
Karl
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-02-25 10:24
Message:
Logged In: YES
user_id=3066
I've attached a patch, but I can't test on an equivalent
environment to where you found the problem. It doesn't
break the build for Linux. ;-) If you could test this
patch to the lib/internal.h file from the CVS version of
Expat in the target environments, I'd appreciate knowing if
this fixes the problem.
Thanks!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=692878&group_id=10127
More information about the Expat-bugs
mailing list