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 - 317 of 317 matches
Mail list logo