On 6/14/20 11:41 AM, Xi Ruoyao via lfs-dev wrote:
On 2020-06-14 10:49 -0500, Bruce Dubbs via lfs-dev wrote:
On 6/14/20 8:35 AM, Pierre Labastie via lfs-dev wrote:
On Sun, 2020-06-14 at 15:15 +0200, Pierre Labastie via lfs-dev wrote:
I am currently testing whether moving iana-etc before gcc may allow
tests to pass, as reported by Joe Locash. If so, I'll commit it.
Hmm, having iana-etc does not change anything to the
"22_locale/time_get/..." failures, and there is still one
failure in experimental/net/internet/resolver, even with a real
/etc/host installed!
Some details about the 22_locale/time_get/..." failures in gcc's
libstdc++ tests.
They all revolve around two files in the same way:
libstdc++-v3/testsuite/22_locale/time_get/get_time/char/2.cc
libstdc++-v3/testsuite/22_locale/time_get/get_time/wchar_t/2.c
They both do:
iterator_type is_it20(iss);
tm time20;
errorstate = good;
tim_get.get_time(is_it20, end, iss, errorstate, &time20);
VERIFY( time20.tm_sec == time_bday.tm_sec );
VERIFY( time20.tm_min == time_bday.tm_min );
VERIFY( time20.tm_hour == time_bday.tm_hour );
VERIFY( errorstate == ios_base::eofbit );
The failure is in the last VERIFY macro.
I've tried to trace the logic of the tim_get.get_time function, but it's
complicated.
If that last VERIFY is commented out or changed to !=, then all the
time_get failures go away.
It's GCC PR71367:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367
Nice find. It looks like the test is actually doing it's job in
pointing out a problem. It does not seem like a priority to upstream
because it has languished for over a year.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
