On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
wrote:
>
> On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Fri, 4 Sep 2020 at 17:08, Alexander Monakov wrote:
> > > >
> > > > > I obtained perf stat
[[ CC += LKML ]]
Thanks for all your input. I learned some C++ :)
The following code works for all C and C++ standards:
g++ --std={c++98, c++03, c++11, c++14, c++17, c++20}
gcc --std={c89, c99, c11, c18, c2x}
With `-Wall -Wextra -Werror -pedantic -Wno-vla -Wno-sizeof-pointer-div`.
It doesn't co
* Jonathan Wakely:
>># define array_length(arr) (std:size(arr))
>
> C++ programmers will not accept a macro for this.
I think we need a macro for C++98 support because there is no other way
to produce constant expression.
Note that this intended for C programs compiled in C++ mode. As pointe
On Tue, 22 Sep 2020 at 12:56, Richard Biener wrote:
>
> On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 21 Sep 2020 at 15:19, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Fri, 4 Sep 2020
On 22/09/20 11:10 +0200, Alejandro Colomar via Libstdc++ wrote:
[[ CC += LKML ]]
Thanks for all your input. I learned some C++ :)
The following code works for all C and C++ standards:
g++ --std={c++98, c++03, c++11, c++14, c++17, c++20}
gcc --std={c89, c99, c11, c18, c2x}
With `-Wall -Wextra -
* Jonathan Wakely:
> I don't see much point in using std::size here. If you're going to
> provide the alternative implementation for when std::size isn't
> defined, why not just use it always?
>
> template
> #if __cplusplus >= 201103L
> constexpr
> #endif
> inline std::size_t
> __array_length(cons
Thanks again for your improvements.
I think this might be ready for a patch already.
Any more thoughts?
Thanks,
Alex
#if defined(__cplusplus)
# include
# if __cplusplus >= 201103L
template
constexpr inline std::size_t
__array_length(const _Tp(&)[_Len]) __THROW
{
On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 22 Sep 2020 at 12:56, Richard Biener
> wrote:
> >
> > On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 21 Sep 2020 at 18:14, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 21 Sep
* Ville Voutilainen:
> Why should this be array_length and not __array_length? This is a
> vendor extension, so it should use
> a name that is reserved for such?
In general, we use __ for glibc internals that are not intended for
direct access by users. In some cases, we have non-__ identifiers
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11: _Static_assert()
- In C89, C99: Negative anonymous bitfield
- In C++: The template requires an array
'snitems()'
failures)
on some of the pages are different.
Can you help explain the differences? Is there a way to avoid
the duplication?
Thanks
Martin
Results for 11.0.0 20200922 (experimental) [master revision
r11-3343-g44135373fcdbe4019c5524ec3dff8e93d9ef113c] (GCC) testsuite on
arm-none-eabi Christophe
compute farm I have access to.
Christophe
> Thanks
> Martin
>
> Results for 11.0.0 20200922 (experimental) [master revision
> r11-3343-g44135373fcdbe4019c5524ec3dff8e93d9ef113c] (GCC) testsuite on
> arm-none-eabi Christophe LYON
>
> Results for 11.0.0 20200922 (exp
On Tue, 22 Sep 2020 at 16:36, Richard Biener wrote:
>
> On Tue, Sep 22, 2020 at 11:37 AM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 22 Sep 2020 at 12:56, Richard Biener
> > wrote:
> > >
> > > On Tue, Sep 22, 2020 at 7:08 AM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 21 Sep 2020
On Mon, Sep 21, 2020 at 02:47:51PM +0200, Alejandro Colomar wrote:
> [[ CC += libc-coord at lists.openwall.com ]]
I missed the beginning of this so perhaps it's already been discussed,
but I don't see how cdefs.h is a remotely reasonable place for this.
cdefs.h is included by all glibc headers and
On 22/09/20 12:25 -0400, Rich Felker wrote:
Is there really a reason to want a nonstandard macro like this to do
something that's already trivial to do in the base language and has a
standard idiom (sizeof x / sizeof *x)?
IMHO no.
On Tue, 22 Sep 2020 at 19:46, Jonathan Wakely via Libstdc++
wrote:
>
> On 22/09/20 12:25 -0400, Rich Felker wrote:
> >Is there really a reason to want a nonstandard macro like this to do
> >something that's already trivial to do in the base language and has a
> >standard idiom (sizeof x / sizeof *
it, and when the only form of presentation is as a running list,
it's too cumbersome to work with.
Martin
I think HJ generates several "running targets" in the same log, I run
them separately to benefit from the compute farm I have access to.
Christophe
Thanks
Martin
Resul
insn seqs:
s1:
__builtin_set_float_convert_mode(0);
r1 = __builtin_load(a1, a2);
r2 = __builtin_float_convert(r1);
__builtin_store(a3, r2);
__builtin_set_float_convert_mode(0);
s2:
__builtin_set_float_convert_mode(1);
r1 = __builtin_load(a1
18 matches
Mail list logo
