Re: [RFC] Add stdckdint.h header for C23

On 6/12/23 23:28, Jakub Jelinek via Libc-alpha wrote: On Mon, Jun 12, 2023 at 09:51:02PM +, Joseph Myers wrote: On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote: I have looked at gnulib stdckdint.h and they are full of workarounds for various compilers, EDG doesn't do this, clang

[PATCH] Document that -fno-trampolines is for Ada only [PR100735]

The GCC manual's documentation of -fno-trampolines was apparently written from an Ada point of view. However, when I read it I understandably mistook it to say that -fno-trampolines also works for C, C++, etc. It doesn't: it is silently ignored for these languages, and I assume for any language

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

On 10/2/20 4:44 PM, Alejandro Colomar wrote: I know, they aren't perfect. But they are still very useful, and don't see a good reason to not document them. "aren't perfect" is an understatement More important, lots of things in GNU C are useful but shouldn't be documented in the man

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

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. It doesn't. There's no portable way to use scanf and printf on it. You can't reliably convert it to intmax_t. It doesn't have the associated _MIN and _MAX macros that

Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'

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 other without intervening spaces". I'd play it safe and quote the arg anyway. > %p works with any object pointer type

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

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's purely a compiler issue. Besides, do we start repeating the GCC manual too,

Re: [PATCH 1/4] system_data_types.7: Add '__int128'

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.

Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'

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 backslash prevents a line break. +Conversions from and to any other pointer type are done implicitly, +not requiring casts at

Re: Ping Re: Make max_align_t respect _Float128 [version 3]

On 09/19/2016 08:58 AM, Joseph Myers wrote: Ping. This patch is pending review. Thanks, the patch looks good to me. It should be safe for the uses of max_align_t that I know of (e.g., Emacs).

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 04:56 AM, Mark Wielaard wrote: I don't think there is anything valgrind can do to detect that compw really only depends on d[0] if the result is false. valgrind (with the default --partial-loads-ok=yes) could and should do the same thing with cmpw that it already does with cmpl.

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but uninitialised then it will just track the undefinedness complain later if such a value is used. I think the

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer calling it a defect, as most code I've seen

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 08:16 AM, Joseph Myers wrote: I don't think there's any such requirement in the case of flexible array members; if you use malloc to allocate a structure with a flexible array member, you can access as many trailing array elements as would fit within the allocated size, whether or

Re: Make max_align_t respect _Float128

On 08/26/2016 02:45 PM, Florian Weimer wrote: In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result. Hmm, well, in that case I suppose I should change Emacs to ignore max_align_t as well. Thanks for the heads-up.

Re: Make max_align_t respect _Float128

On 08/26/2016 01:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; It should be fine, though I would like

Re: [C/C++ PATCH] Implement -Wshift-negative-value (PR c/65179)

b8f4f998104e74fc2c4a3759317b5153e95db16e Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Fri, 8 May 2015 14:47:40 -0700 Subject: [PATCH] Avoid left-shift-into-sign-bit undefined behavior Problem reported by Joseph Myers in: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00704.html * localtime.c (detzcode

Re: [PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

(revision 210804) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-05-22 Paul Eggert egg...@cs.ucla.edu + + PR other/56955 + * doc/extend.texi (Function Attributes): Fix __attribute__ ((malloc)) + documentation; the old documentation didn't clearly state

[PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

/ChangeLog (revision 210629) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-05-20 Paul Eggert egg...@cs.ucla.edu + + PR other/56955 + * doc/extend.texi (Function Attributes): Fix __attribute__ ((malloc)) + documentation; the old documentation didn't clearly state the + constraints