This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fixinc regression for <math.h> with C++ on Solaris 9
Bruce Korb wrote:
> Gerald Pfeifer wrote:
>
>
>>which lead me to the following:
>>
>> revision 1.160
>> date: 2003/07/09 21:00:01; author: neroden; state: Exp; lines: +3 -2
>> * fixinc/inclhack.def (math_exception): Improve bypass and
comment.
>> * fixinc/fixincl.x: Rebuild.
>>
>>Index: inclhack.def
>
>
>>@@ -1692,7 +1693,7 @@ fix = {
>> hackname = math_exception;
>> files = math.h;
>> select = "struct exception";
>>- bypass = 'We have a problem when using C\+\+';
>>+ bypass = '__cplusplus';
>> c_fix = wrap;
>>
>> c_fix_arg = "#ifdef __cplusplus\n"
>
>
> Hmmm. Odd, that. The Sol 8 and 9 headers claim to be C++ aware
> (they use "__cplusplus"), yet they contain:
>
> struct exception { ...
>
> outside of the protection against C++. We need to back out that change
> and determine which headers (besides glibc) have the unprotected usage
> of struct exception.
>
>
>>>Just from inspection, there are *two* patches related to exceptions:
>>>
>>> sunos_matherr_decl and math_exception
>>>
>>>but I do not see how they could interact on the header in question.
>>>They should be re-ordered, though. It looks like the second fix would
>>>put a ``struct exception;'' in before the ``#ifdef __cplusplus'' thing.
>>>(The bypass clause should prevent the application of the fix on the
>>>header in question:
>>
>>Hmm, that one's definitely a bit too steep for me. :-)
>
>
> I'm trying to make the stuff accessible. I am referring to
> gcc/fixinc/tests/base/math.h:
>
>
>>#ifndef FIXINC_WRAP_MATH_H_SUNOS_MATHERR_DECL
>>#define FIXINC_WRAP_MATH_H_SUNOS_MATHERR_DECL 1
>>
>>struct exception; <<<<<<===== OOPS! comes from sunos_matherr_decl fix
>>#ifndef FIXINC_WRAP_MATH_H_MATH_EXCEPTION
>>#define FIXINC_WRAP_MATH_H_MATH_EXCEPTION 1
>>
>>#ifdef __cplusplus
>>#define exception __math_exception
>>#endif
Could that be the culprit? I'd be much happier if the struct exception;
was coming from fixincludes (in which case we have to do less
fixincluding) than if it's coming from bogus Solaris headers (in which
case we have to do more fixincluding).
Not having Solaris, of course, I can't actually tell....