> Ok, so it seems the fix is to reinstate the override in sol2.h,
> right?
This wouldn't change anything except for Solaris. The fix is probably to wipe
out the SVR4 definition (and consequently all definitions in config/sparc
since the remaining ones will duplicate the default).
--
Eric Botc
From: Eric Botcazou
Date: Wed, 21 Jan 2009 15:22:19 +0100
> > Obviously the GCC folks broke backwards compatibility with themselves.
> > So unless we find evidence that contradicts the wiki page you cite, I
> > think GCC needs to be fixed.
>
> Yes, the SVR4 definition used to be masked by that o
> Obviously the GCC folks broke backwards compatibility with themselves.
> So unless we find evidence that contradicts the wiki page you cite, I
> think GCC needs to be fixed.
Yes, the SVR4 definition used to be masked by that of the sol2.h file on
Solaris and is not anymore. But the SVR4 defini
> Date: Wed, 21 Jan 2009 15:08:47 +0400
>
> Hello,
>
> Eric and I discovered a discrepancy in the DWARF register numbering
> on SPARC for floating point registers. The problem is more visible
> on SPARC 64-bit because they are used for parameter passing, whether
> i0 is used on 32-bit SPARC. Co
Joel Brobecker writes:
> However, when I tried to find some kind of official document
> to confirm this numbering, I only found:
>
> http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering
>
> This is a wiki page, so I'm not sure how much we can trust the contents.
> However, it doe
Hello,
Eric and I discovered a discrepancy in the DWARF register numbering
on SPARC for floating point registers. The problem is more visible
on SPARC 64-bit because they are used for parameter passing, whether
i0 is used on 32-bit SPARC. Consider for instance the following code:
volatile r
