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
block,
> > > > > > right in block 181, which is:
> > > > > > if (mattyp.eq.2) goto else goto
> > > > > >
> > > > > > which is then further hoisted to block 173:
> > > > > > if (mattyp.eq.1) goto else goto
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 *
ts 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 (experimental) [master revision
r11-3343-g44135373fcdbe4019c5524ec3dff8e93d9ef113c] (GCC) testsuite on
arm-
nergy
> > > > > > > s(ii1+2,jj1+2)=s(ii1+2,jj1+2)+senergy
> > > > > > >
> > > > > > > Hoisting hoists loads w[0] .. w[8] from orthonl and senergy block,
> > > > > > > right in block 181,
t, and checking all of them isn't really
> practical. The duplication (and the sheer number of results) also
> make it more difficult to find results for targets other than arm-*.
> There are about 13,000 results for September and over 10,000 of those
> for arm-* alone. It's goo
> > +s23*(w(2,3)+w(3,2))+s33*w(3,3))*weight
> > > > > > > > s(ii1,jj1)=s(ii1,jj1)+senergy
> > > > > > > > s(ii1+1,jj1+1)=s(ii1+1,jj1+1)+senergy
> > > > > > > >
On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote:
> So that would give:
>
> Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf
>
> and hopefully free up some space at the end for the kind of thing
> you mention.
Even that 8.4.1 20200918 is redundant, r8-10517
On Wed, Sep 23, 2020 at 12:37:52PM +0200, Andreas Schwab wrote:
> On Sep 23 2020, Jakub Jelinek via Gcc wrote:
>
> > Even that 8.4.1 20200918 is redundant, r8-10517 uniquely and shortly
> > identifies both the branch and commit.
>
> But it requires a repository to ide
gt; > >
> > > > > > > > > followed by basic block:
> > > > > > > > >
> > > > > > > > > senergy=
> > > > > > > > > &(s11*w(1,1)+s12*(w(1,2)+w(2,1))
> > >
On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
wrote:
>
> On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote:
> > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote:
> >> So that would give:
> >>
> >> Results for 8.4.1 20200918 [r8-10517] on
On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc wrote:
>
> On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
> wrote:
> >
> > On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote:
> > > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wr
On Wed, Sep 23, 2020 at 02:42:01PM +0200, Dennis Luehring wrote:
> i've read that scoped template specalization is allowed in C++17
>
>
> clang supports it starting with release 7
>
> MSVC supports it with VS2017(i don't know what revision)
>
> Intel does not like it
Because CWG 727 isn't impl
Hi,
"Defining How to Split Instructions" in gccint states the following:
The preparation-statements are similar to those statements that are
specified for define_expand ... Unlike those in define_expand, however,
these statements must not generate any new pseudo-registers.
I see that there is co
eople.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/0latest/report-build-info.html
where it's more obvious what configurations are tested.
That looks awesome! The regression indicator looks especially
helpful. I really wish we had an overview like this for all
results. I've b
>>> didn't seem convenient (would be too long, and I fear modifying the
> >>> awk script)
> >>
> >> Without some indication of a difference in the title there's no way
> >> to know what result to look at, and checking all of them isn't
On Wed, 23 Sep 2020 at 14:33, David Edelsohn wrote:
>
> On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc
> wrote:
> >
> > On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
> > wrote:
> > >
> > > On 23/09/2020 11:20, Jakub Jelinek via Gcc wrot
On Wed, 23 Sep 2020 at 16:55, Christophe Lyon via Gcc wrote:
>
> On Wed, 23 Sep 2020 at 14:33, David Edelsohn wrote:
> >
> > On Wed, Sep 23, 2020 at 8:26 AM Christophe Lyon via Gcc
> > wrote:
> > >
> > > On Wed, 23 Sep 2020 at 12:26, Richard Earnshaw
&
0] .. w[8]
> > > > > > > > > > }
> > > > > > > > > > else
> > > > > > > > > >6 loops // load anisox
> > > > > > > > > >
> > > > > > > > > > foll
; > > > > >
> > > > > > > > > > > The hoisting region is:
> > > > > > > > > > > if(mattyp.eq.1) then
> > > > > > > > > > > 4 loops
> > > > > > > &g
g in the subject line, but that
> > >>> didn't seem convenient (would be too long, and I fear modifying the
> > >>> awk script)
> > >>
> > >> Without some indication of a difference in the title there's no way
> > >> to know w
I posted version 1 of the patches of the stuff needed to allow little endian
64-bit GCC on Linux to be configured to use long double.
As per the discussion in this thread, I did decide to keep things to two types
within the compiler. This means that an explicit __float128 or _Float128 will
use
Hello world,
for review of its patches, gfortran relies on a group of people
who can approve patches. Unfortuntately, many of them are not
active. Others, who have the capability and who have acted as
de facto approvers (without anybody minding) are missing.
This (somewhat overdue) patch rectif
On Fri, Sep 25, 2020 at 9:05 AM Erick Ochoa
wrote:
>
> Hi,
>
> I am working on an alias analysis using the points-to information
> generated during IPA-PTA. If we look at the varmap varinfo_t array in
> gcc/tree-ssa-struct.c, most of the constraint variable info structs
> co
-to information
> >> generated during IPA-PTA. If we look at the varmap varinfo_t array in
> >> gcc/tree-ssa-struct.c, most of the constraint variable info structs
> >> contain a non-null decl field which points to a valid tree in gimple
> >> (which is an SSA
'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()'
in my main.c to be able to use 'snitems()',
because I didn't have 'ptrdiff_t',
eventhough already includes .
I completely ignore the mechanisms behind system headers including
other system headers.
Moreover, I didn't find 'ptrdiff_t' defined in a
ignore the mechanisms behind system headers including
other system headers.
Moreover, I didn't find 'ptrdiff_t' defined in any of my systems headers
I used 'user@debian:/usr/include$ grep -rn ptrdiff_t'. Does GCC do magic?
What's the problem with that? How should I f
Hello Jonathan,
On 2020-09-25 16:48, Jonathan Wakely wrote:
> Do you really need to provide snitems?
>
> Users can use (ptrdiff_t)nitems if needed, can't they?
They can, but that adds casts in the code,
which makes longer lines that are somewhat harder to read.
To avoid that, users may sometimes
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
Hello Jonathan,
On 2020-09-25 16:48, Jonathan Wakely wrote:
Do you really need to provide snitems?
Users can use (ptrdiff_t)nitems if needed, can't they?
They can, but that adds casts in the code,
which makes longer lines that a
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
I have a similar number of ARRAY_SIZE() and ARRAY_SSIZE().
I could have '#define snitems(arr) ((ptrdiff_t)nitems(arr))' in my projects,
but is it really necessary?
The barrier for adding something to glibc headers should be a LOT
h
On 2020-09-25 19:39, Jonathan Wakely wrote:
> Yes, I'm aware of all the rationale. I already said that it makes
> sense in C++ where you have generic code. I am not convinced that it's
> necessary to add to when all it does is a cast from
> size_t to ptrdiff_t.
>
While I would prefer a signed
'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
Some BSDs a
Hi Nicolas,
Thanks for the feedback, the error still remains with gcc 10.2.0:
$ make
CROSS_COMPILE=/home/nfs/0day/gcc-10.2.0-nolibc/arc-elf/bin/arc-elf-
ARCH=arc M=drivers/net/can
WARNING: Symbol version dump ./Module.symvers
is missing; modules will have no dependencies and
'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
Some BSDs a
On Mon, Sep 28, 2020 at 04:38:51PM +, Joseph Myers wrote:
> On Thu, 24 Sep 2020, Michael Meissner wrote:
>
> > As per the discussion in this thread, I did decide to keep things to two
> > types
> > within the compiler. This means that an explicit __float128 or _Float128
> > will
> > use the
On Mon, Sep 28, 2020 at 05:07:55PM -0400, Michael Meissner wrote:
> On Mon, Sep 28, 2020 at 04:38:51PM +, Joseph Myers wrote:
> > On Thu, 24 Sep 2020, Michael Meissner wrote:
> >
> > > As per the discussion in this thread, I did decide to keep things to two
> > > types
> > > within the compil
Hi,
I was looking at the implementation of mstackalign in gcc (O2/O3) and it
looks like we generate code for mstackalign (i.e. generate instructions for
stack alignment) before pushing $rbp to stack/setting $rbp. In the
epilogue, we do the same in reverse order.
some_routine
On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote:
>
> Hello,
> I am trying to update me/honza-gcc-benchmark-branch to current trunk
> which I do by deleting it, recreating locally and pushing out.
>
> The problem is that the push fails witih:
>
> remote: *** The followin
Hi Michael,
I started with types.
I joined them by groups:
intN_t instead of having an entry for each int8_t, int16_t, ...
I think that way I could better explain the types, common things,
differences, and exceptions.
I'll wait until you review them to write about the remaining
types: [u]int_le
On Tue, Sep 29, 2020 at 11:11 AM Jan Hubicka wrote:
>
> > On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote:
> > >
> > > Hello,
> > > I am trying to update me/honza-gcc-benchmark-branch to current trunk
> > > which I do by deleting it, recreating loc
Hi Michael,
I made a mistake when sending the emails, and I only CCd linux-man
(and other lists) in PATCH 0/8. The rest were only sent to you.
Actually, I was playing with the --cc option in git format-patch.
I'm resending all of them as v2.
I fixed a typo in 5/8, while the rest are all identic
Signed-off-by: Alejandro Colomar
---
man3/intmax_t.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/intmax_t.3
diff --git a/man3/intmax_t.3 b/man3/intmax_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/intmax_t.3
@@ -0,0 +1 @@
+.so man7/system_data_ty
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 56
1 file changed, 56 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index fe6e90afe..e718b3c30 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 55
1 file changed, 55 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e718b3c30..2e7aca7d2 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 79
1 file changed, 79 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 2e7aca7d2..9b8244649 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/uintmax_t.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/uintmax_t.3
diff --git a/man3/uintmax_t.3 b/man3/uintmax_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uintmax_t.3
@@ -0,0 +1 @@
+.so man7/system_da
Signed-off-by: Alejandro Colomar
---
man3/int16_t.3 | 1 +
man3/int32_t.3 | 1 +
man3/int64_t.3 | 1 +
man3/int8_t.3 | 1 +
man3/intN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/int16_t.3
create mode 100644 man3/int32_t.3
create mode 100644 man3/int64_t.3
create mode
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 82
1 file changed, 82 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 9b8244649..2f21e6849 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/uint16_t.3 | 1 +
man3/uint32_t.3 | 1 +
man3/uint64_t.3 | 1 +
man3/uint8_t.3 | 1 +
man3/uintN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/uint16_t.3
create mode 100644 man3/uint32_t.3
create mode 100644 man3/uint64_t.3
cre
D'oh! Now I had a typo when CCing myself :(
a5,a5,%lo(.LANCHOR0)
addia0,a5,64
addia3,a5,128
addia4,a5,192
vfldv1,a5
vfldv3,a0
vfldv0,a3
vfldv2,a4
vfadd v1,v1,v3
vfmul v0,v0,v2
csrwvlen,a2 <----
addia5,a1,8
vfstv1,a1
vfstv0,a5
On Tue, Sep 29, 2020 at 12:55 PM 夏 晋 via Gcc wrote:
>
> Hi everyone,
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> ➜
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 a
Hi Michael,
On 2020-09-29 13:50, Michael Kerrisk (man-pages) wrote:
> Hi Alex
>
> On Tue, 29 Sep 2020 at 10:26, Alejandro Colomar
wrote:
>>
>> Hi Michael,
>>
>> I started with types.
>
> Good. I wanted those the other day :-), but then I saw they weren't in
> the page yet!
They were complica
xample we add a "sub" like:
vf32 sub = x3 - x4;
at this time, we need to add "0" (sub) to the dependency.
Is there a way that we can ignore the steps before the "vlen"? so that we can
make it more universal.
Best,
Jin
发件人: Richard Biene
On Mon, 28 Sep 2020 at 23:15, Joseph Myers wrote:
>
> On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
>
> > > I'm not sure which patch in the series is supposed to be implementing
> > > that, but C requires that long double and _Float128 are distinct types (
Hi Jim,
Thank you for your reply. I've tried the following code on GCC for RVV
extendsion, still met the same issue.
➜
vint16m1_t foo3(vint16m1_t a, vint16m1_t b){
vint16m1_t add = a+b;
vint16m1_t mul = a*b;
vsetvl_e8m1(32);
return add + mul;
}
the assembly is:
➜
foo3:
On Tue, Sep 29, 2020 at 9:46 PM Jim Wilson wrote:
>
> On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> > I tried to set the "vlen" after the add & multi, as shown in the following
> > code:
>
> > vf32 x3,x4;
> > void foo1(float16_t* input, floa
would be great!
I hope they add that to the language. When/if that happens, nitems()
could be `#define nitems(arr) _Lengthof(arr)` for std >= c2x.
In the meantime, I would add this macro to libc.
Maybe gcc could add such a great feature as an extension even before the
standard does...
(l = vsetvl_e32m8(n)) > 0; n -= l) {
> vx = vle32_v_f32m8(x);
> x += l;
> vy = vle32_v_f32m8(y);
> // vfmacc
> vy = a * vx + vy;
> vse32_v_f32m8(y, vy);
> y += l;
> }
> }
Ah, ok - that makes sense.
> We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> we are using for testing the vector support.
That doesn't seem to exist (but maybe it's just not on trunk yet).
Richard.
> Jim
ing,
and if so is it completely equivalent to '__int128'?
Is the GCC version correct?
There's no implementation where 'long long' is 128 bits yet, right?
Thanks,
Alex
Rendered output:
[[
__int128
A signed integer type of a fixed width of exactly 128 bits.
Accor
On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc wrote:
>
> Hi,
>
> I'm documenting the system data types in the man-pages,
> and I was writing now about these types.
>
> I'm showing below both the rendered output and the source I have right now.
>
> Wo
Hi Jonathan,
On 2020-10-01 11:57, Jonathan Wakely wrote:
> On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc
wrote:
>>
>> Hi,
>>
>> I'm documenting the system data types in the man-pages,
>> and I was writing now about these types.
>>
>>
Hi Michael,
Here are a few fixes (including one removing .br),
and then the remaining stdint types.
Cheers,
Alex
Alejandro Colomar (16):
malloc_get_state.3: ffix
system_data_types.7: srcfix
system_data_types.7: srcfix
system_data_types.7: srcfix
system_data_types.7: Add int_fastN_t fa
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index a653a7b11..a099c0250 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@
Signed-off-by: Alejandro Colomar
---
man3/malloc_get_state.3 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man3/malloc_get_state.3 b/man3/malloc_get_state.3
index f94efccf4..57781fd6b 100644
--- a/man3/malloc_get_state.3
+++ b/man3/malloc_get_state.3
@@ -29,7 +29,7 @@ malloc
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 105 ++-
1 file changed, 70 insertions(+), 35 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 9cf67ee6f..a653a7b11 100644
--- a/man7/system_data_types.7
+++ b/m
We used .br to force a simple line break (with no extra blank line)
after the tag.
Recently, we added .RS/.RS, and .RS comes just after the tag,
and I realized by accident that .RS already forces a simple line break.
Therefore, .br is completely redundant here, and can be removed.
This way we ge
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 79
1 file changed, 79 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 07de6417f..e3ebc2270 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/int_fast16_t.3 | 1 +
man3/int_fast32_t.3 | 1 +
man3/int_fast64_t.3 | 1 +
man3/int_fast8_t.3 | 1 +
man3/int_fastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/int_fast16_t.3
create mode 100644 man3/int_fast32_t.3
create mode
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 76
1 file changed, 76 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index a301c2309..07de6417f 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/uint_fast16_t.3 | 1 +
man3/uint_fast32_t.3 | 1 +
man3/uint_fast64_t.3 | 1 +
man3/uint_fast8_t.3 | 1 +
man3/uint_fastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/uint_fast16_t.3
create mode 100644 man3/uint_fast32_t.3
crea
Signed-off-by: Alejandro Colomar
---
man3/int_least16_t.3 | 1 +
man3/int_least32_t.3 | 1 +
man3/int_least64_t.3 | 1 +
man3/int_least8_t.3 | 1 +
man3/int_leastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/int_least16_t.3
create mode 100644 man3/int_least32_t.3
crea
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 72
1 file changed, 72 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e3ebc2270..0b8057087 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 75
1 file changed, 75 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 0b8057087..f768e87ba 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 65
1 file changed, 65 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index f768e87ba..2632436ed 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/uint_least16_t.3 | 1 +
man3/uint_least32_t.3 | 1 +
man3/uint_least64_t.3 | 1 +
man3/uint_least8_t.3 | 1 +
man3/uint_leastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/uint_least16_t.3
create mode 100644 man3/uint_least32_t.
Signed-off-by: Alejandro Colomar
---
man3/intptr_t.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/intptr_t.3
diff --git a/man3/intptr_t.3 b/man3/intptr_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/intptr_t.3
@@ -0,0 +1 @@
+.so man7/system_data_ty
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 68
1 file changed, 68 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 2632436ed..8884d3e18 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/uintptr_t.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/uintptr_t.3
diff --git a/man3/uintptr_t.3 b/man3/uintptr_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uintptr_t.3
@@ -0,0 +1 @@
+.so man7/system_da
On Thu, 1 Oct 2020 at 11:14, Alejandro Colomar wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 11:57, Jonathan Wakely wrote:
> > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc
> wrote:
> >>
> >> Hi,
> >>
> >> I'm documenting t
On Thu, 1 Oct 2020 at 11:25, Alejandro Colomar via Gcc wrote:
>
> Signed-off-by: Alejandro Colomar
> ---
> man7/system_data_types.7 | 76
> 1 file changed, 76 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system
l typedefs, rather than new types that are distinct from the
standard integer types. That seems like useful information.
Hi Jonathan,
I wasn't sure about how to word it.
In theory, they should be the fastest types; just that.
But then, for some reason, GCC decided that
int_fast8_t
Hi Jonathan,
On 2020-10-01 12:50, Jonathan Wakely wrote:
Ok, I thought that GCC is part of the GNU project, but I don't know how
much...
I'll use "When using GCC," :)
It is, but the GNU project is a large organisation, and has nothing to
say about non-standard types
ypes that are distinct from the
> > standard integer types. That seems like useful information.
> >
>
> Hi Jonathan,
>
> I wasn't sure about how to word it.
>
> In theory, they should be the fastest types; just that.
> But then, for some reason, GCC decided
Hi Michael,
I did it this way because then you have a clearly ordered list
of the commits, and in which order they go,
so I thought it might be easier for you (creating less conflicts).
And also, I can hold any more recent patches, such as __int128,
for when you finish applying the previous set,
On Thu, 1 Oct 2020 at 12:24, Alejandro Colomar wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 12:50, Jonathan Wakely wrote:
> >> Ok, I thought that GCC is part of the GNU project, but I don't know how
> >> much...
> >> I'll use "When using
Okay then :)
Thanks,
Alex
On 2020-10-01 13:50, Michael Kerrisk (man-pages) wrote:
Hi Alex,
On 10/1/20 1:41 PM, Alejandro Colomar wrote:
Hi Michael,
I did it this way because then you have a clearly ordered list
of the commits, and in which order they go,
so I thought it might be easier for
The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> Here is the rendered intmax_t:
>
> intmax_t
> Include: . Alternatively, .
>
> A signed integer type capable of representing any value of any
> signed integer type supported by the implementation.
On 2020-10-01 14:54, Szabolcs Nagy wrote:
The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
Here is the rendered intmax_t:
intmax_t
Include: . Alternatively, .
A signed integer type capable of representing any value of any
signed integer type supported by the
On Thu, 1 Oct 2020 at 14:22, Alejandro Colomar wrote:
>
>
>
> On 2020-10-01 14:54, Szabolcs Nagy wrote:
> > The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> >> Here is the rendered intmax_t:
> >>
> >> intmax_t
> >>Include: .
You get a nasty error like:
$ git push origin -d refs/users/redi/heads/calendar
remote: *** Update rejected by this repository's hooks.update-hook script
remote: *** (/git/gcc.git/hooks-bin/update_hook):
remote: *** fatal: bad object
remote: *** Traceback (
On 2020-10-01 13:27, Jonathan Wakely wrote:
How would you word that?
I gave a suggestion above.
Oops, I missed that.
Thanks,
Alex
This patches are the v2 of the patches 5 to 8 of a previous patchset:
https://lore.kernel.org/linux-man/886f5647-2911-951a-b62a-4f9b1ed88...@gmail.com/T/#t
Alejandro Colomar (4):
system_data_types.7: Add int_fastN_t family of types
int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 77
1 file changed, 77 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 4645ed5f4..c5d0b700d 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 80
1 file changed, 80 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c5d0b700d..c130b7256 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_t
Signed-off-by: Alejandro Colomar
---
man3/int_fast16_t.3 | 1 +
man3/int_fast32_t.3 | 1 +
man3/int_fast64_t.3 | 1 +
man3/int_fast8_t.3 | 1 +
man3/int_fastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/int_fast16_t.3
create mode 100644 man3/int_fast32_t.3
create mode
Signed-off-by: Alejandro Colomar
---
man3/uint_fast16_t.3 | 1 +
man3/uint_fast32_t.3 | 1 +
man3/uint_fast64_t.3 | 1 +
man3/uint_fast8_t.3 | 1 +
man3/uint_fastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/uint_fast16_t.3
create mode 100644 man3/uint_fast32_t.3
crea
Signed-off-by: Alejandro Colomar
---
man3/int_least16_t.3 | 1 +
man3/int_least32_t.3 | 1 +
man3/int_least64_t.3 | 1 +
man3/int_least8_t.3 | 1 +
man3/int_leastN_t.3 | 1 +
5 files changed, 5 insertions(+)
create mode 100644 man3/int_least16_t.3
create mode 100644 man3/int_least32_t.3
crea
2401 - 2500 of 10345 matches
Mail list logo
