>> * While you now define _GLIBCXX_C_LOCALE_XPG7 in
>> config/locale/xpg7/c_locale.h, config/os/aix/ctype_configure_char.cc
>> still tests the previous _GLIBCXX_C_LOCALE_IEEE_2008.
>
> Arf, I've missed that. it might not be the last patch then.
> (I've made so much versions of it as I've tried
> * There are minor formatting issues:
>
> Should the linebreak in the extern inline definitions of strtof_l be
> after the return type, not before, matching GNU coding standards? It
> may well be that the C++ style is different, though.
>
> Unrelated whitespace changes in xpg7/ctype_memb
Hi Clement,
> Here is a better version of the patch.
> All tests are on Linux are passing. Few have been disabled as
> they are working only with GNU model.
> For AIX, few failures remains. I haven't XFAIL them yet, as I
> want to know if they AIX only or related to the model itself.
>
> A fe
Hi everyone,
Here is a better version of the patch.
All tests are on Linux are passing. Few have been disabled as
they are working only with GNU model.
For AIX, few failures remains. I haven't XFAIL them yet, as I
want to know if they AIX only or related to the model itself.
A few part stil
ave a declaration
>>present.
>
>Right, I wondered about this too.
I didn't work when I've tried. Maybe I've missed something. I'll check.
Thanks,
Clément
From: Rainer Orth
Sent: Friday, January 22, 2021 12:54 PM
To: Jonathan Wak
Hi Jonathan,
> On 22/01/21 12:04 +0100, Rainer Orth wrote:
>>why? I've just double-checked the OpenGroup pages: all of the functions
>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
>>revision of the -200
On 22/01/21 12:04 +0100, Rainer Orth wrote:
why? I've just double-checked the OpenGroup pages: all of the functions
listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
revision of the -2008 standard, not a new
On 22/01/21 09:57 +, CHIGOT, CLEMENT via Libstdc++ wrote:
Hi Rainer
> 3) POSIX 2017 and non-POSIX functions
> Many of the *_l functions being used in GNU or dragonfly models aren't
> POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
> However, there are really useful in t
Hi Clement,
>> > 3) POSIX 2017 and non-POSIX functions
>> > Many of the *_l functions being used in GNU or dragonfly models aren't
>> > POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
>> > However, there are really useful in the code, thus I've made a double
>> > implementatio
On 21/01/21 17:36 +0100, Rainer Orth wrote:
Hi Clement,
Here is a new version of the patch. I've tested on Linux and AIX.
There are still some tests failing but it starts having a good shape !Â
However, I have few questions:
1) locale.name and syscalls
just a terminology nit: none of those
Hi Rainer
> > 3) POSIX 2017 and non-POSIX functions
> > Many of the *_l functions being used in GNU or dragonfly models aren't
> > POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
> > However, there are really useful in the code, thus I've made a double
> > implementation based
Hi Clement,
> Here is a new version of the patch. I've tested on Linux and AIX.
> There are still some tests failing but it starts having a good shape !
> However, I have few questions:
>
> 1) locale.name and syscalls
just a terminology nit: none of those are syscalls.
> 3) POSIX 2017 and non-P
Hi everyone,
Here is a new version of the patch. I've tested on Linux and AIX.
There are still some tests failing but it starts having a good shape !
However, I have few questions:
1) locale.name and syscalls
locale.name() is returning a string having the description of each locale
category. It
Hi Clement,
>> OTOH, I wondered if it wouldn't be better to start from the GNU code
>> which is certainly known to work, rather than the DragonflyBSD one which
>> may well have bitrotten since most of the BSDs moved to LLVM. Then
>> again, it may not: Gerald tests on FreeBSD regularly. Perhaps a
> > However, is the C++ ABI not standard ? I don't have this test failing on
> > AIX, AFAIK. Strange.
>
> Not really: the ABI tests rely on symbol versioning, which is only
> available on Solaris and GNU ELF targets.
Maybe it's normal then.
> OTOH, I wondered if it wouldn't be better to start from
Hi Clement,
>> This alone makes the patch inacceptable in its present form: breaking
>> the libstdc++ ABI is a non-starter. However, I suspect this can be
>> avoided somehow.
> Thanks for having tried and I agree the patch isn't ready at all. I've just
> wanted to see how behave on other systems
Hi Rainer,
> This alone makes the patch inacceptable in its present form: breaking
> the libstdc++ ABI is a non-starter. However, I suspect this can be
> avoided somehow.
Thanks for having tried and I agree the patch isn't ready at all. I've just
wanted to see how behave on other systems and it s
Hi David,
>> I agree that #ifdef's are not the correct approach, but, if you enable
>> the fallbacks for Solaris, does everything then work? Are those
>> fallbacks portable and we solely need a better mechanism to enable
>> them on platforms that require them?
>
> it mostly compiles, with two cav
Hi David,
>> >> Presumably it could also be tested on GNU/Linux and Solaris, since
>> >> they implement the POSIX 2008 APIs needed.
>> >
>> > I'll give the patch a whirl on Solaris. However, we will need to
>> > distinguish between 11.3 (which is XPG6 only) and 11.4 (which support
>> > XPG7).
>>
On Tue, Jan 12, 2021 at 12:41 PM Rainer Orth
wrote:
>
> Hi Jonathan,
>
> >> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
> >>>Hi everyone,Â
> >>>
> >>>I've reworked the patch to merged dragonfly and AIX
> >>>models into the new one named "ieee_1003.1-2008".Â
> >>>It seems okay on the AIX part b
Hi Jonathan,
>> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
>>>Hi everyone,Â
>>>
>>>I've reworked the patch to merged dragonfly and AIX
>>>models into the new one named "ieee_1003.1-2008".Â
>>>It seems okay on the AIX part but if someone can test
>>>on Dragonfly and Freebsd I would be glad.Â
On 12/01/21 10:44 -0500, David Edelsohn wrote:
On Tue, Jan 12, 2021 at 10:25 AM Jonathan Wakely wrote:
On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
>Hi everyone,
>
>I've reworked the patch to merged dragonfly and AIX
>models into the new one named "ieee_1003.1-2008".
>It seems okay on the A
Hi Clement,
> I've reworked the patch to merged dragonfly and AIX
> models into the new one named "ieee_1003.1-2008".
> It seems okay on the AIX part but if someone can test
> on Dragonfly and Freebsd I would be glad. Configure
> needs to be regenerated, first.
>
> For now, I've used #ifdef insi
Hi Jonathan,
> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
>>Hi everyone,Â
>>
>>I've reworked the patch to merged dragonfly and AIX
>>models into the new one named "ieee_1003.1-2008".Â
>>It seems okay on the AIX part but if someone can test
>>on Dragonfly and Freebsd I would be glad. Config
On Tue, Jan 12, 2021 at 10:25 AM Jonathan Wakely wrote:
>
> On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
> >Hi everyone,
> >
> >I've reworked the patch to merged dragonfly and AIX
> >models into the new one named "ieee_1003.1-2008".
> >It seems okay on the AIX part but if someone can test
> >on
> >Hi everyone,Â
> >
> >I've reworked the patch to merged dragonfly and AIX
> >models into the new one named "ieee_1003.1-2008".Â
> >It seems okay on the AIX part but if someone can test
> >on Dragonfly and Freebsd I would be glad. Configure
> >needs to be regenerated, first.
>
> Presumably it
> And I don't know for the Changelog/Patch, how renamed
> files must be handled ? I've retrieved my git commit with
> "git format-patch --no-renames" and thus the Changelog
> is made of "Removed" and "New File". Is it okay or is there
> anything special to add ? I didn't find the answer quickly
On 12/01/21 15:14 +, CHIGOT, CLEMENT wrote:
Hi everyone,Â
I've reworked the patch to merged dragonfly and AIX
models into the new one named "ieee_1003.1-2008".Â
It seems okay on the AIX part but if someone can test
on Dragonfly and Freebsd I would be glad. Configure
needs to be regenerate
Hi everyone,
I've reworked the patch to merged dragonfly and AIX
models into the new one named "ieee_1003.1-2008".
It seems okay on the AIX part but if someone can test
on Dragonfly and Freebsd I would be glad. Configure
needs to be regenerated, first.
For now, I've used #ifdef inside the code
On Mon, Jan 11, 2021 at 10:56 AM CHIGOT, CLEMENT
wrote:
>
> >> Hi David, Clement,
> >>
> >>> The patch is local to libstdc++ AIX support, so I believe that I can
> >>> approve it.
> >>
> >>have you considered merging the dragonfly and aix trees? I'm asking
> >>because it seems prudent to try and
>> Hi David, Clement,
>>
>>> The patch is local to libstdc++ AIX support, so I believe that I can
>>> approve it.
>>
>>have you considered merging the dragonfly and aix trees? I'm asking
>>because it seems prudent to try and avoid creating more and more
>>almost-but-not-quite-similar configuratio
On 11/01/21 16:35 +0100, Rainer Orth wrote:
Hi David, Clement,
The patch is local to libstdc++ AIX support, so I believe that I can approve it.
have you considered merging the dragonfly and aix trees? I'm asking
because it seems prudent to try and avoid creating more and more
almost-but-not-
Hi Clement,
> Would "Skip if target = aix" be ok, especially for the few that I have
> absolutely no idea why they are failing ?
you should try to avoid such skips if at all possible. Should the tests
start to PASS in the future, either due to AIX changes or changes in
libstdc++, this would go u
Hi David, Clement,
> The patch is local to libstdc++ AIX support, so I believe that I can approve
> it.
have you considered merging the dragonfly and aix trees? I'm asking
because it seems prudent to try and avoid creating more and more
almost-but-not-quite-similar configurations (Solaris might
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] libstdc++: implement locale support for AIX
Caution! External email. Do not open attachments or click links, unless this
email comes from a known sender and you know the content is safe.
Hi, Clement
The patch is local to libstdc++ AIX support, so I
Hi, Clement
The patch is local to libstdc++ AIX support, so I believe that I can approve it.
libstdc++ loads the gcc testsuite target-supports.exp extensions. The
patch needs to update the libstdc++ testcases to require wchar32 or
utf-8 as appropriate to avoid the failures.
Thanks, David
On Mon
Hi everyone,
This patch adds a partial locale support in libstdc++
for AIX.
The message_members part isn't yet implemented.
The tests have been launched in AIX7.2 and AIX7.1.
There are a few new tests failing (~20), but most of them
weren't launched before and they don't seem too much
relate
37 matches
Mail list logo
