Hi Joseph,
Would you mind having a look at this patch?
On Tue, Sep 16, 2025 at 08:56:49AM +0200, Alejandro Colomar wrote:
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index 2922d9e9839..77116169331 100644
> > --- a/gcc/doc/extend.texi
> > +
+0200
+++ /dev/fd/63 2025-09-28 09:59:12.842035857 +0200
@@ -1,4 +1,4 @@
-Test run by alx on Sat Sep 27 20:41:28 2025
+Test run by alx on Sat Sep 27 22:45:55 2025
Native configuration is x86_64-pc-linux-gnu
=== libatomic tests ===
~~~
Alejandro Colomar (3):
Rename i
Signed-off-by: Alejandro Colomar
---
gcc/c-family/c-warn.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index a771444184f..e5e3ef70710 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -3505,7 +3505,7
Rename warn_parm_array_mismatch() => warn_parms_array_mismatch().
This function acts on entire parameter declaration lists, and iterates
over them. Use plural in the name, to clarify that it acts on
parameters, not just on a single parameter.
Signed-off-by: Alejandro Colomar
---
gcc/c-fam
Not sure about moving the definition of ptr_spec.
Signed-off-by: Alejandro Colomar
---
gcc/c-family/c-warn.cc | 582 +
1 file changed, 294 insertions(+), 288 deletions(-)
diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index e5e3ef70710
This was regenerated with (slightly simplified):
$ make bootstrap && make html && cd gcc && make regenerate-opt-urls;
gcc/c-family/ChangeLog:
* c.opt.urls: Regenerate
Fixes: 33c35b7f4c18 (2025-09-26; "c, objc: Add
-Wmultiple-parameter-fwd-decl-lis
This was regenerated with (slightly simplified):
$ make bootstrap && make html && cd gcc && make regenerate-opt-urls;
Fixes: 33c35b7f4c18 (2025-09-26; "c, objc: Add
-Wmultiple-parameter-fwd-decl-lists")
gcc/c-family/ChangeLog:
* c.opt.urls: Re
ly
Cc: Mark Wielaard
Cc: Martin Uecker
Cc: Michael Kerrisk
Cc: Paul Eggert
Cc: Sam James
Cc: Siddhesh Poyarekar
Cc: Yann Droneaud
Signed-off-by: Alejandro Colomar
---
This is a resend of the same patch previously sent to gcc@.
gcc/c-family/c.opt | 4 ++--
gcc/doc/invoke.texi | 2 +-
2 f
Ping
On 2/18/23 00:05, Alejandro Colomar wrote:
> Link:
> <https://inbox.sourceware.org/gcc/3098fd18-9dbf-b4e9-bae5-62ec6fea7...@opteya.com/T/>
> Link: <https://github.com/shadow-maint/shadow/pull/649#discussion_r1108350066>
> Cc: Andreas Schwab
> Cc: David Malcolm
Hi Richard,
On 3/15/23 15:52, Richard Biener wrote:
> On Wed, Mar 15, 2023 at 3:30 PM Alejandro Colomar via Gcc-patches
> wrote:
>>
>> Ping
>
> -Wuse-after-free=3 was explicitly added to cover cases with a high
> false-positive rate. If you want to
> make that
Signed-off-by: Alejandro Colomar
---
man3/unsigned-__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/unsigned-__int128.3
diff --git a/man3/unsigned-__int128.3 b/man3/unsigned-__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/unsigned
Signed-off-by: Alejandro Colomar
---
man3/__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/__int128.3
diff --git a/man3/__int128.3 b/man3/__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/__int128.3
@@ -0,0 +1 @@
+.so man7
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 35 +++
1 file changed, 35 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 5f9aa648f..3cf3f0ec9 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types
Hi Michael,
I think this might be ready for a patch.
I'm done for today :-)
Cheers,
Alex
Alejandro Colomar (4):
system_data_types.7: Add '__int128'
__int128.3: New link to system_data_types(7)
system_data_types.7: Add 'unsigned __int128'
unsigne
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 40
1 file changed, 40 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e545aa1a0..5f9aa648f 100644
--- a/man7/system_data_types.7
+++ b/man7
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
---
Paul and David,
Thanks for your input!
Alex
man7/system_data_types.7 | 16
1 file changed, 16 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index
Hi Michael,
The 2/2 is a typo. This is a standalone patch.
Cheers,
Alex
On 2020-10-02 11:44, Alejandro Colomar wrote:
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
---
Paul and David,
Thanks for your input!
Alex
man7/system_data_types.7 | 11
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
---
Paul and David,
Thanks for your input!
Alex
man7/system_data_types.7 | 11 +++
1 file changed, 11 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 6451782db
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about generic function parameters and
return value
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul
Hi Michael,
As you asked, I squashed.
And added the POSIX.1-2008 note too. Thanks for that!
Cheers,
Alex
Alejandro Colomar (2):
system_data_types.7: Add 'void *'
void.3: New link to system_data_types(7)
man3/void.3 | 1 +
man7/system_data_ty
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 40
1 file changed, 40 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e545aa1a0..5f9aa648f 100644
--- a/man7/system_data_types.7
+++ b/man7
Hi Michael,
I fixed the stray '"' noticed by Florian.
Cheers,
Alex
Alejandro Colomar (4):
system_data_types.7: Add '__int128'
__int128.3: New link to system_data_types(7)
system_data_types.7: Add 'unsigned __int128'
unsigned-__int128.3: New
Signed-off-by: Alejandro Colomar
---
man3/unsigned-__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/unsigned-__int128.3
diff --git a/man3/unsigned-__int128.3 b/man3/unsigned-__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/unsigned
Signed-off-by: Alejandro Colomar
---
man3/__int128.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/__int128.3
diff --git a/man3/__int128.3 b/man3/__int128.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/__int128.3
@@ -0,0 +1 @@
+.so man7
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 35 +++
1 file changed, 35 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 5f9aa648f..3cf3f0ec9 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types
so, so let's call it v4).
Regards,
Alex
Alejandro Colomar (2):
system_data_types.7: Add 'void *'
void.3: New link to system_data_types(7)
man3/void.3 | 1 +
man7/system_data_types.7 | 80 +++-
2 files changed, 79 insertions(+),
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about generic function parameters and
return value
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Hi Paul,
On 2020-10-02 18:53, Paul Eggert wrote:
> On 10/2/20 8:14 AM, Alejandro Colomar wrote:
>
>> +.I void *
>
> GNU style is a space between "void" and "*", so this should be '.I
> "void\ *"', both here and elsewhere. The backsla
Hi Paul,
On 2020-10-02 19:52, Paul Eggert wrote:
Why describe __int128_t in these man pages at all? __int128_t is not a
property of either the kernel or of glibc, so it's out of scope.
Well, as I see it, [unsigned] __int128 is as good as [u]int64_t.
They are part of the C interface in Linux.
A
: malloc(3), memcmp(3), memcpy(3), memset(3)
See also the intptr_t and uintptr_t types in this page.
]]
Alejandro Colomar (2):
system_data_types.7: Add 'void *'
void.3: New link to system_data_types(7)
man3/void.3 | 1 +
man7/syst
Signed-off-by: Alejandro Colomar
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about generic function parameters and
return value
Reported-by: Paul Eggert
Reported-by: David Laight
Signed-off-by: Alejandro Colomar
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul
Hi Paul,
On 2020-10-02 21:54, Paul Eggert wrote:
> On 10/2/20 12:01 PM, Alejandro Colomar wrote:
>> If you propose not to document the stdint types either,
>
> This is not a stdint.h issue. __int128 is not in stdint.h and is not a
> system data type in any real sense; it&#
Hi Paul,
On 2020-10-02 22:14, Paul Eggert wrote:
> On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>
>> .I void *
>>
>> renders with a space in between.
>
> That's odd, as "man(7)" says "All of the arguments will be printed next
> to each ot
Hi Paul,
On 2020-10-02 22:19, Paul Eggert wrote:
> On 10/2/20 1:03 PM, Alejandro Colomar wrote:
>> I know it's not in stdint,
>> but I mean that it behaves as any other stdint type.
With caveats, of course.
>
> It doesn't. There's no portable way to use sc
Hi Michael and Branden,
On 2020-10-03 09:48, G. Branden Robinson wrote:
At 2020-10-03T09:10:14+0200, Michael Kerrisk (man-pages) wrote:
On 10/2/20 10:27 PM, Alejandro Colomar wrote:
On 2020-10-02 22:14, Paul Eggert wrote:
> On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>
>
On 10/3/20 9:48 AM, G. Branden Robinson wrote:
[...]
>> The "short" answer[1] is that I think Alex is correct; Paul's caution is
>> unwarranted and arises from confusion with the font alternation macros
>> of the man(7) macro package. Examples of the latter are .BI and .BR.
>> Those set their ev
wc -l;
Link:
<https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpa...@gmail.com/T/>
Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
Signed-off-by: Alejandro Colomar
Nacked-by: Alexei Starovoitov
Nacked-by: Greg Kroah-Hartman
Nacked-by: Daniel Borkmann
Acked-by:
Alexei,
On 8/24/22 20:55, Alejandro Colomar wrote:
> Link:
<https://lore.kernel.org/linux-man/20210423230609.13519-1-alx.manpa...@gmail.com/T/>
> Link: <https://lore.kernel.org/lkml/YZvIlz7J6vOEY+Xu@yuki/T/>
> Signed-off-by: Alejandro Colomar
> Nacked-by: Alexei
Hi Linux,
On 8/25/22 02:52, Linus Torvalds wrote:
On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
wrote:
I'm trying to be nice, and ask for review to make sure I'm not making
some big mistake by accident, and I get disrespect? No thanks.
You've been told multiple times
Hi Greg,
On 8/25/22 07:57, Greg Kroah-Hartman wrote:
On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
But from your side what do we have? Just direct NAKs without much
explanation. The only one who gave some explanation was Greg, and he
vaguely pointed to Linus's com
Hi Xi,
On 8/25/22 09:28, Xi Ruoyao wrote:
On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
wrote:
I don't know for sure, and I never pretended to say otherwise. But what
IMHO the kernel could do is to make the types compatible, by typedefing
to the same fundamental
Hi Linus,
(Oops, I mistyped you name in my previous reply; I'm on a roll for funny
typos this week it seems)
On 8/25/22 09:42, Linus Torvalds wrote:
On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
wrote:
This patch is not about kernel, but about the section 2 and 3 manual
pages,
On 8/25/22 09:44, Alejandro Colomar wrote:
Hi Greg,
On 8/25/22 07:57, Greg Kroah-Hartman wrote:
On Thu, Aug 25, 2022 at 01:36:10AM +0200, Alejandro Colomar wrote:
But from your side what do we have? Just direct NAKs without much
explanation. The only one who gave some explanation was Greg
Hello Daniel,
On 5/17/21 8:56 PM, Daniel Borkmann wrote:
On 5/16/21 11:16 AM, Alejandro Colomar (man-pages) wrote:
Signed-off-by: Alejandro Colomar
Discussion:
<https://lore.kernel.org/linux-man/6740a229-842e-b368-86eb-defc786b3...@gmail.com/T/>
Nacked-by: Alexei Starovoitov
Nac
x27;t very clear on how to use alignas() or
[[]]-style attributes, so the following link is useful in the case
of 'alignas()' and '[[gnu::aligned()]]':
<https://stackoverflow.com/q/67271825/6872717>
Signed-off-by: Alejandro Colomar
Cc: LKML
Cc: glibc
Cc: GCC
Cc: Alexei S
erent
alignment syntaxes:
__attribute__((aligned())), alignas(), and [[gnu::aligned()]]:
<https://stackoverflow.com/q/67271825/6872717>
Signed-off-by: Alejandro Colomar
Nacked-by: Alexei Starovoitov
Nacked-by: Greg Kroah-Hartman
Acked-by: Zack Weinberg
Cc: LKML
Cc: glibc
Cc: GCC
Cc: b
Reported-by: Heinrich Schuchardt
Signed-off-by: Alejandro Colomar
---
man2/cacheflush.2 | 24
1 file changed, 24 insertions(+)
diff --git a/man2/cacheflush.2 b/man2/cacheflush.2
index aba625721..7a2eed506 100644
--- a/man2/cacheflush.2
+++ b/man2/cacheflush.2
@@ -86,6
Reported-by: Heinrich Schuchardt
Signed-off-by: Alejandro Colomar
Cc: Martin Sebor
Cc: Dave Martin
---
v6:
- GCC has always exposed 'void *', as Martin Sebor noted.
It's Clang (and maybe others) that (following GCC's docs)
exposed 'char *&#
Hi David,
On 3/24/23 18:58, David Malcolm wrote:
> On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote:
>> Hi David,
>>
>> On 3/24/23 15:53, David Malcolm wrote:
>>> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-
>>> patches
&
Remove repeated word (typo).
Signed-off-by: Alejandro Colomar
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index fd3745c5608..cdfb25ff272 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
horter and more
portable C2x syntax, which hasn't been standardized yet, but is
already implemented in GCC, and available through either --std=c2x
or any of the --std=gnu... options.
Signed-off-by: Alejandro Colomar
---
man2/bpf.2 | 47 +++
1 file
ists.gnu.org/archive/html/groff/2022-11/msg00063.html>
Link:
<https://inbox.sourceware.org/gcc/36da94eb-1cac-5ae8-7fea-ec66160cf...@gmail.com/T/>
Acked-by: Doug McIlroy
Cc: "G. Branden Robinson"
Cc: Ralph Corderoy
Cc: Dave Kemper
Cc: Larry McVoy
Cc: Andrew Pinski
Cc: Jonath
Hi David,
On 3/24/23 15:53, David Malcolm wrote:
> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
> wrote:
>> Warn about the following:
>>
>> char s[3] = "foo";
>>
[...]
>> ---
>>
>> Hi,
>
> Hi Alex,
Hi Joseph,
On 4/26/21 7:19 PM, Joseph Myers wrote:
On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote:
Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'. Update those to use the shorter and more
portable C2x syntax, which hasn't been standa
LFB0:
.cfi_startproc
callfoo
movl%eax, %edx
movl$1, %eax
subl%edx, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Debian 10.2.1-6) 10.2.1 20210110"
.section .note.GNU-s
olving
> anything, really. Moreover, what are you doing with all the
> __{le,be}{16,32,64}
> types in uapi? Anyway, NAK for bpf.2 specifically, and the idea
generally..
>
I'm trying to clarify the manual pages as much as possible, by using
standard conventions and similar structu
Hi Florian,
On 5/4/21 9:45 PM, Florian Weimer wrote:
* Alejandro Colomar:
The thing is, in all of those threads, the only reasons to avoid
types in the kernel (at least, the only explicitly
mentioned ones) are (a bit simplified, but this is the general idea of
those threads):
* Possibly
handful of cases. Not much
of a problem. I'd keep those untouched.
Regards,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
On 5/15/21 9:01 PM, Alejandro Colomar wrote:
Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't. There are some using kernel
syntax '__u32'. Fix those.
Both the kernel and the standard types are 100% binary compatible,
and th
Ping
On 12/15/20 2:30 PM, Alejandro Colomar wrote:
> Reported-by: Heinrich Schuchardt
> Signed-off-by: Alejandro Colomar
> Cc: Martin Sebor
> Cc: Dave Martin
> ---
>
> v6:
> - GCC has always exposed 'void *', as Martin Sebor noted.
> It's Clang (an
follow it,
whenever possible. Any deviation from the standard (be it C or POSIX)
should have a very good reason to be; otherwise, it only creates confusion.
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
Senior SW Engineer; http://www.alejandro-colomar.es/
301 - 364 of 364 matches
Mail list logo
