This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] symbol versioning fixups
Hi Jakub,
>On Thu, Jun 16, 2005 at 10:02:16AM +0200, Paolo Carlini wrote:
>
>
>>Hi Benjamin,
>>
>>
>>
>>>Here's the deal: the export list checking for 3.4.4 and 4.0.0 missed
>>>several new exported symbols. These symbols were given the default
>>>versioning, ie GLIBCXX_3.4, instead of what would be more accurate and
>>>appropriate, ie GLIBCXX_3.4.5.
>>>
>>>
>>>
>>>
>>can you possibly clarify the issues with size_t and char_traits::eq?
>>
>>
Thanks for your reply. Only a couple of minor observations (don't want
to add too much "noise" to this thread which touches technical issues
not really in my own area of competence).
>size_t is unsigned int on some targets and unsigned long int on other
>targets, mangled differently. When using __asm and .symver stuff,
>you use the mangled names and therefore must know whether to use j
>or m in the mangled names for size_t.
>
>
Makes sense, thanks. But I'm really puzzled that we are noticing this
for the *first* time: by chance? Because there is nothing special in
gcc-4.0.0 wrt size_t, definitely.
>Now, the problems in the patch I see ATM:
>1) you use _GLIBCXX_SIZE_T_IS_INT even for streamsize mangling,
> but as streamsize is ptrdiff_t, that looks wrong, there
> is no guarantee both are long or both are int.
> E.g. s390-linux has:
>#define __SIZE_TYPE__ long unsigned int
>#define __PTRDIFF_TYPE__ int
> and therefore the patch will not work on s390-linux
> IMHO you need similar configury for _GLIBCXX_PTRDIFF_T_IS_INT
> (and I'd rename _GLIBCXX_SIZE_T_IS_INT to
> _GLIBCXX_SIZE_T_IS_UINT, so that it is less confusing)
>
>
Yes, I also noticed that. In fact Benjamin wrote a "fixme" in a comment,
maybe hoped the s390 case didn't exist ;)
Paolo.
P.S. Still looking forward a little bit of clarification for the
char_traits::eq issue.