Mail Archives: djgpp/2000/04/19/08:14:44
Eli Zaretskii wrote:
>I suggest to report this to the GCC maintainers.
I intend doing so once I've found out where and how I'm supposed to
report GCC bugs, and have checked the list of known bugs (wherever
that may be).
>The GCC docs does
>not mention this incompatibility, so it's either a documentation bug,
>or a GCC bug, if it is supposed to work.
>
>I suspect the former. In general, GCC maintainers will tell you that
>if you use switches that change the ABI, you should expect certain
>things to break. For example, there are some switches of this kind
>that break debugging.
Yes, it's probably not reasonable to expect it to work. But I think
it should at least simply ignore the regparm attribute when -pg is
used. (That this would slightly distort the profile is a minor issue,
since the profiling code itself distorts the profile.)
>> Of course, it's possible to work around it with something like
>>
>> #if defined __DJGPP__ && !defined PROFILING
>> #define REGPARM(n) __attribute__ ((regparm(n)))
>> #else
>> #define REGPARM(n)
>> #endif
>>
>> but then it's necessary to remember -DPROFILING in addition to -pg.
>
>If you are willing to live without regparm when profiling and profile
>code that doesn't use regparm, then why is this an issue? You could
>simply compile only some functions with -pg and leave those which use
>regparm without profiling instrumentation. Since regparm will
>ususally be limited to a well-defined small subset of your program, it
>shouldn't be too hard to decide how to compile each module.
I prefer the -DPROFILING solution because then I still get the
information about how many times the function is called (which
tends not to be obvious in my programs).
>I thought the issue was that you *wanted* to profile code _while_ it
>was using regparm (for obvious reasons).
Well, I would obviously prefer this (although the overhead of profiling
would probably mask any gain due to use of regparm anyway). But I'm
used to not being able to profile my actual code, because my programs
usually work faster with -fomit-frame-pointer, which has to be left off
during profiling. The issue was really that -pg doesn't even produce
a warning if used with regparm functions, it simply produces incorrect
code which will either cause a crash or (worse) cause the program
to run completely differently than it would normally, producing a
meaningless profile.
I've found that using regparm for selected functions does produce a
measurable (albeit small) speed-up, but this has to be measured by
means other than profiling.
S.
- Raw text -