[Expat-bugs] [ expat-Bugs-692878 ] FASTCALL problem with Solars/gcc

SourceForge.net noreply at sourceforge.net
Wed Mar 12 15:15:07 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: 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