When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono:
diff --git a/libstdc++-v3/include/std/chrono
b/
I could not find any entry in gcc's bugzilla for that. Perhaps my search
wasn't good enough.
On Sun, 5 Nov 2023 at 15:58, Marc Glisse wrote:
> On Sun, 5 Nov 2023, Cassio Neri wrote:
>
> > When year_month_day_last::day() was implemented, Dr. Matthias Kretz
> realised
&g
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's mathematically correct to replace the
d
ping.
On Sat, 25 Nov 2023 at 13:52, Cassio Neri wrote:
> The following invoke signed integer overflow (UB) [1]:
>
> month + months{MAX} // where MAX is the maximum value of months::rep
> month + months{MIN} // where MIN is the maximum value of months::rep
> month
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN is the maximum value of months::rep
month - months{MIN} // where MIN is the minimum value of months::rep
weekday + days {MAX}
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono:
---
libstdc++-v3/include/std/chrono | 24 +
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's mathematically correct to replace the
d
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono: Remove &1 from year_month_day_last::day().
-
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
libstdc++-v3/ChangeLog:
* include/std/chrono: Remove &1 from year_month_day_last::day(
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's correct to replace the divisibility che
The following has undefined behaviour (signed overflow) [1]:
weekday max{sys_days{days{numeric_limits::max()}}};
The issue is in this line when __n is very large and __n + 4 overflows:
return weekday(__n >= -4 ? (__n + 4) % 7 : (__n + 5) % 7 + 6);
In addition to fixing this bug, the new i
The current implementation calls __detail::__modulo which is relatively
expensive.
A better implementation is possible if we assume that x.ok() && y.ok() == true,
so that n = x.c_encoding() - y.c_encoding() is in [-6, 6]. In this case, it
suffices to return n >= 0 ? n : n + 7.
The above is allowe
The following functions invoke signed integer overflow (UB) for some extreme
values of days and months [1]:
weekday operator+(const weekday& x, const days& y); // #1
month operator+(const month& x, const months& y); // #2
For #1, the crux of the problem is that, in libstdc++, days::rep is i
weekday operator+(const weekday& x, const days& y); // #1
month operator+(const month& x, const months& y); // #2
For #1 the problem is that in libstdc++ days::rep is int64_t. Other
implementations use int32_t and cast operands to int64_t. Hence then perform
arithmetic operations without fea
The following functions invoke signed integer overflow (UB) for some extreme
values of days and months [1]:
weekday operator+(const weekday& x, const days& y); // #1
month operator+(const month& x, const months& y); // #2
For #1 the problem is that in libstdc++ days::rep is int64_t. Other
i
Actually, disregard this patch. I'm preparing a better one which also
tackles UB in
month - months{INT_MIN}
weekday - days{INT_MIN}
Best wishes,
Cassio.
On Sat, 18 Nov 2023, 00:19 Cassio Neri, wrote:
> The following functions invoke signed integer overflow (UB) for some
> extreme
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN is the maximum value of months::rep
month - months{MIN} // where MIN is the minimum value of months::rep
weekday + days {MAX}
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN is the maximum value of months::rep
month - months{MIN} // where MIN is the minimum value of months::rep
weekday + days {MAX}
Dear libstdc++ developers,
I developed a novel algorithm called Teju Jagua which finds the shortest
representation of a floating-point number. It can be used by std::to_chars
which currently uses Ryu.
IMHO, Teju Jagua is much simpler than Ryu and, according to my measurements,
for doubles, Teju J
Implement the template function teju_jagua which finds the shortest
representation of a floating-point number. The floating-point type is a
template parameter and the implementation is generic enough to handle all
floating-point types of interest, namely, IEEE 754, std::bfloat16_t,
x86 80-bit and I
rote:
>
>
> On Tue, 6 Aug 2024, 17:28 Andi Kleen, wrote:
>
>> Cassio Neri writes:
>>
>> > Implement the template function teju_jagua which finds the shortest
>> > representation of a floating-point number. The floating-point type is a
>> > tem
This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
h
This patch reimplements std::chrono::year_month_day::_M_days_since_epoch()
which calculates the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.2 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https
This patch reimplements std::chrono::year::is_leap(). Leap year check is
ubiquitously implemented (including here) as:
y % 4 == 0 && (y % 100 != 0 || y % 400 == 0).
The rationale being that testing divisibility by 4 first implies an earlier
return for 75% of the cases, therefore, avoiding th
This patch reimplements std::chrono::year_month_day_last:day() which yields the
last day of a particular month. The current implementation uses a look-up table
implemented as an unsigned[12] array. The new implementation instead
is based on
the fact that a month m in [1, 12], except for m == 2 (F
erformance. I'm glad the compiler
warned us. (Although I don't understand why I didn't get the warning.)
Thanks,
Cassio.
On Thu, Feb 25, 2021 at 11:56 AM Jonathan Wakely wrote:
>
> On 24/02/21 17:28 +, Jonathan Wakely wrote:
> >On 23/02/21 13:24 +, Cassio Ner
Simple change to std::chrono::year::is_leap. If a year is multiple of 100,
then it's divisible by 400 if and only if it's divisible by 16. The latter
allows for better code generation.
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/std/chrono:
diff --git a/libstdc++-v3/include
mp; _M_y % 4 == 0;
}
explicit constexpr
On Fri, May 21, 2021 at 7:05 PM Koning, Paul wrote:
>
>
>
> > On May 21, 2021, at 1:46 PM, Cassio Neri via Gcc-patches
> > wrote:
> >
> > Simple change to std::chrono::year::is_leap. If a year is multiple of
at I've committed. Tested x86_64-linux and powerpc64le-linux.
> >Pushed to trunk.
> >
> >
> >
>
> >commit b92d12d3fe3f1aa56d190d960e40c62869a6cfbb
> >Author: Cassio Neri
> >Date: Wed Jun 23 15:32:16 2021
> >
> >libstdc++: More ef
29 matches
Mail list logo