Re: [RFC] Adding a new attribute to function param to mark it as constant

> On Wed, 4 Aug 2021 at 03:27, Segher Boessenkool > wrote: > > > > Hi! > > > > On Fri, Jul 23, 2021 at 04:23:42PM +0530, Prathamesh Kulkarni via Gcc wrote: > > > The constraint here is that, vshl_n intrinsics require that the > > > second arg (__b), > > > should be an immediate value. > > > > Some

atomic_load

It would be great if somebody could take a look at PR96159. It seems we do not do atomic accesses correctly when the alignment is insufficient for a lockfree access, but I think we should fall back to a library call in this case (as clang does). This is very unfortunate as it is an important f

Re: atomic_load

Am Sonntag, den 07.11.2021, 10:24 +0100 schrieb Florian Weimer: > * Martin Uecker via Gcc: > > > It would be great if somebody could take a look at > > PR96159. > > > > It seems we do not do atomic accesses correctly > > when the alignment is insufficient fo

Re: atomic_load

Am Montag, den 08.11.2021, 11:59 + schrieb Jonathan Wakely: > On Sun, 7 Nov 2021, 09:08 Martin Uecker wrote: > > > It would be great if somebody could take a look at > > PR96159. > > > > It seems we do not do atomic accesses correctly > > when the alignment is insufficient for a lockfree > >

Re: atomic_load

Am Sonntag, den 07.11.2021, 10:08 +0100 schrieb Martin Uecker: > It would be great if somebody could take a look at > PR96159. > > It seems we do not do atomic accesses correctly > when the alignment is insufficient for a lockfree > access, but I think we should fall back to a > library call in t

Re: atomic_load

Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou: > > This is a silent and dangerous incorrect code generation issue. > > Let's avoid this kind of FUD, please, builtins are low-level devices and > people must know what they are doing and be prepared for caveats. Sorry, I do not thin

Re: atomic_load

Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely: > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc wrote: > > Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou: > > > > This is a silent and dangerous incorrect code generation issue. > >

Re: atomic_load

Am Freitag, den 26.11.2021, 15:48 + schrieb Jonathan Wakely: > On Fri, 26 Nov 2021 at 15:41, Martin Uecker wrote: > > Am Freitag, den 26.11.2021, 09:24 + schrieb Jonathan Wakely: > > > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc > > > wrote: > &g

reordering of trapping operations and volatile

Hi Richard, I have a question regarding reodering of volatile accesses and trapping operations. My initial assumption (and hope) was that compilers take care to avoid creating traps that are incorrectly ordered relative to observable behavior. I had trouble finding examples, and my cursory gla

Re: reordering of trapping operations and volatile

Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener: > On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker > wrote: > > Hi Richard, thank you for your quick response! > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumpt

Re: reordering of trapping operations and volatile

Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou: > > Yes, although I think potentially trapping ops > > are not moved before calls (as this would be > > incorrect). So do you think it would be feasable > > to prevent this for volatile too? > > Feasible probably, but why would this b

Re: reordering of trapping operations and volatile

Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown: > On 08/01/2022 09:32, Martin Uecker via Gcc wrote: > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumption (and hope)

Re: reordering of trapping operations and volatile

Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote: > > > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial &g

Re: reordering of trapping operations and volatile

Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: > On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote: > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc > > >

Re: reordering of trapping operations and volatile

Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener: Hi Richard, > > > > For volatile, it seems this would need some tweaks. > > > > > > Yes, likewise when re-or

Re: reordering of trapping operations and volatile

Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener: > On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote: > > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener: > > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote: > > > > Am Montag, den 10.01.2022, 10:04 +0100 sc

Re: reordering of trapping operations and volatile

Am Donnerstag, den 13.01.2022, 16:45 + schrieb Michael Matz: > Hello, > > On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote: > > > > Handling all volatile accesses in the > > > very same way would be possible but quite some work I don't > > >

Re: reordering of trapping operations and volatile

Am Freitag, den 14.01.2022, 14:15 + schrieb Michael Matz: > Hello, > > On Thu, 13 Jan 2022, Martin Uecker wrote: ... > > > I think to define this > > > all rigorously seems futile (you need a new > > > category between observable and UB), so it comes > > > down to compiler QoI on a case b

Re: reordering of trapping operations and volatile

Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely: > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote: > > > Hello, > > > > On Thu, 13 Jan 2022, Martin Uecker wrote: > > > > > > > > Handling all volatile accesses in the very same way would be > > > > > > possible but quite

Re: reordering of trapping operations and volatile

Am Samstag, den 15.01.2022, 16:33 + schrieb Jonathan Wakely: > On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote: > > > Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely: > > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, > > wrote: > > > > Hello, > > > > > > > > On Thu, 13

Re: reordering of trapping operations and volatile

Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning: > > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > > > On 1/14/22 07:58, Paul Koning via Gcc wrote: > > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc > > > > wrote: > > > > > > > > > ... > > > > But right now that's equ

Re: reordering of trapping operations and volatile

Am Dienstag, den 18.01.2022, 09:31 +0100 schrieb Richard Biener: > On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote: > > Hello, > > > > On Sat, 15 Jan 2022, Martin Uecker wrote: > > > > > > Because it interferes with existing optimisations. An explicit > > > > checkpoint has a clear me

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

... > > > >Whether or not you feel like the manpages are the best place to > > start that, I'll leave up to you! > > I'll try to defend the reasons to start this in the man-pages. > > This feature is mostly for documentation purposes, not being meaningful > for code at all (for some me

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On 9/3/22 14:47, Martin Uecker wrote: > [...] > > > GCC will warn if the bound is specified inconsistently between > > declarations and also emit warnings if it can see that a buffer > > which is passed is too sma

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Alejandro, Am Samstag, den 03.09.2022, 16:59 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On 9/3/22 16:35, Martin Uecker wrote: > > Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar: > > > Hi Martin, > > > > > > On 9/3/22 14:47, Martin Uecker wrote: > > > [...] > > > > >

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers: > On Thu, 10 Nov 2022, Joseph Myers wrote: > > > On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote: > > > > > I've shown the three kinds of prototypes that have been changed: > > > > > > - Normal VLA; nothing fancy except for t

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Donnerstag, den 10.11.2022, 23:19 + schrieb Joseph Myers: > On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote: > > > One problem with WG14 papers is that people put in too much, > > because the overhead is so high and the standard is not updated > > very often. It

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers: > On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote: > > > > Even a compiler extension requires the level of detail of specification > > > that you get with a WG14 paper (and the level of work on fin

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers: > On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > > > Since it's to be used as an rvalue, not as a lvalue, I guess a > > postfix-expression wouldn't be the right one. > > Several forms of postfix-expression are only rvalues. >

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar: > > On 11/13/22 14:33, Alejandro Colomar wrote: > > Hi Martin, > > > > On 11/13/22 14:19, Alejandro Colomar wrote: > > > > But there are not only syntactical problems, because > > > > also the type of the parameter might become re

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar: > Hi Martin, > > On 11/13/22 15:58, Martin Uecker wrote: > > Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar: > > > On 11/13/22 14:33, Alejandro Colomar wrote: > > > > On 11/13/22 14:19, Alejandro Colomar wrote: >

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Am Dienstag, dem 29.11.2022 um 16:53 + schrieb Jonathan Wakely: > On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote: > > > > On Tue, 29 Nov 2022, Michael Matz via Gcc wrote: > > > > > like.  But I'm generally doubtful of this whole feature within C > > > itself. > > > It serves a purpose in do

Re: Missed warning (-Wuse-after-free)

Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar > > [...] > > > > > I'm not convinced that it's useful to the end-user to warn about > > the > > "use of q itself" case. > > I didn't quote the standard because I couldn't find it.  I was > searching in C11, > and it seems th

Re: Missed warning (-Wuse-after-free)

Am Freitag, dem 17.02.2023 um 12:35 +0100 schrieb Alejandro Colomar: > Hi Martin, > > On 2/17/23 09:12, Martin Uecker wrote: > > Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar > > > > > > > > > > [...] > > > > > > > > > > > I'm not convinced that it's useful to the end-us

Re: Missed warning (-Wuse-after-free)

Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar: > Hi Martin, > > On 2/17/23 14:48, Martin Uecker wrote: > > > This new wording doesn't even allow one to use memcmp(3); > > > just reading the pointer value, however you do it, is UB. > > > > memcmp would not use the pointer value

Re: Missed warning (-Wuse-after-free)

Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn: > On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote: > > Hi Martin, > > > > On 2/23/23 20:57, Martin Uecker wrote: > > > Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar: > > > > Hi Martin, > > > > >

Re: Missed warning (-Wuse-after-free)

Am Freitag, dem 24.02.2023 um 02:42 +0100 schrieb Alex Colomar: > Hi Serge, Martin, > > On 2/24/23 02:21, Serge E. Hallyn wrote: > > > Does all this imply that the following is well defined behavior (and shall > > > print what one would expect)? > > > > > >    free(p); > > > > > >    (void) &p;

Re: Missed warning (-Wuse-after-free)

Am Freitag, dem 24.02.2023 um 03:01 + schrieb Peter Lafreniere: ... > > > Maybe it could do an exception for printing, that is, reading a pointer > > is not a problem in itself, a long as you don't compare it, but I'm not > > such an expert about this. > > One last thought: with the above st

Re: Missed warning (-Wuse-after-free)

Am Freitag, dem 24.02.2023 um 10:01 -0600 schrieb Serge E. Hallyn: > On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote: > > Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn: ... > > > > Yes, but one comment about terminology:. The C standard > > differentiates betw

Re: [wish] Flexible array members in unions

> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc wrote: > > > > On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote: > > > On Thu, 11 May 2023, Kees Cook via Gcc wrote: > > > > > > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote: > > > > > On 5/11/23 18:07, Alej

Re: [wish] Flexible array members in unions

Am Donnerstag, dem 18.05.2023 um 20:59 + schrieb Qing Zhao: > > > On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc wrote: > > > > > > > > > On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc > > > wrote: > > > > > > &

user branches

Hi all, is it still possible to have user branches in the repository? If so, how do I create one? Simply pushing to users/uecker/vla or something is rejected. Martin

Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.

Am Dienstag, dem 12.09.2023 um 11:25 +0200 schrieb Richard Biener via Gcc: > On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote: > > > > This is going to be an interesting discussion. > > > > In the upcoming GNU Tools Cauldron meeting the representation of complex > > numbers in GCC will be discus

Re: Question on -fwrapv and -fwrapv-pointer

(moved to gcc@) > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > > > > > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > > CLANG al

Re: Question on -fwrapv and -fwrapv-pointer

Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc: > On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc > wrote: > > > > > > > > (moved to gcc@) > > > > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:

Re: Question on -fwrapv and -fwrapv-pointer

Am Montag, dem 18.09.2023 um 10:47 +0200 schrieb Richard Biener via Gcc: > On Mon, Sep 18, 2023 at 10:17 AM Martin Uecker wrote: > > > > Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc: > > > On Sat, Sep 16, 2023 at 10:38 AM Martin Ueck

Re: Question on -fwrapv and -fwrapv-pointer

Am Mittwoch, dem 20.09.2023 um 13:40 -0700 schrieb Kees Cook via Gcc: > On Sat, Sep 16, 2023 at 10:36:52AM +0200, Martin Uecker wrote: > > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > > > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > > > > > > > > > > > > >

aliasing

Hi, can you please take a quick look at this? This is intended to align the C standard with existing practice with respect to aliasing by removing the special rules for "objects with no declared type" and making it fully symmetric and only based on types with non-atomic character types being abl

Re: aliasing

Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > Hi, > > > > can you please take a quick look at this? This is intended to align > > the C standard with existing practice with respect to aliasing by > > removing

Re: aliasing

ompilers might guarantee not to do type-based alias analysis > and thus view all types as "byte types" in this way. For gcc, there > could be a kind of reverse "may_alias" type attribute to create such types. > > > > There are a number of other features that

Re: aliasing

Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > On Mon, Mar 18, 2024 at 8:03 AM Martin Uecker wrote: > > > > > > > Let me give you an complication example made valid in C++: > > > > struct B { float x; float

Re: aliasing

efined, and somewhat > meaningless as a type name for a raw byte of memory or a minimal sized > unsigned integer. > > Of course most alternative names for bytes would be typedefs of > "unsigned char" and therefore work just the same way. But as noted > before, uint

Re: aliasing

Am Montag, dem 18.03.2024 um 14:21 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 12:56 PM Martin Uecker wrote: > > > > Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > > > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > > > On Mon, Mar 18, 2024 at 8

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Dienstag, dem 02.04.2024 um 13:28 -0700 schrieb Ian Lance Taylor via Gcc: > > On Tue, Apr 2, 2024 at 1:21 PM Paul Koning via Gcc wrote: > > > > > > > > Would it help to require (rather than just recommend) "don't use root > > > > except for the actual 'install' step" ? > > > > Seems reasonab

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 16:00 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker via Gcc wrote: > > > > > Seems reasonable, but note that it wouldn't make any difference to > > > > this attack. The liblzma library was mo

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 18:02 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker wrote: > > > The backdoor was hidden in a complicated autoconf script... > > Which itself had multiple layers and could just as well have been a > complicated cmake function. Don't m

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gcc: > Hello all, > > On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote: > > > My take a way is that software needs to become less complex. Do  > > > we really still need complex build systems such as autoconf? > > > > (

Re: Sourceware mitigating and preventing the next xz-backdoor

Am Samstag, dem 06.04.2024 um 15:00 +0200 schrieb Richard Biener: > On Fri, Apr 5, 2024 at 11:18 PM Andrew Sutton via Gcc wrote: > > > > > > > > > > > > > > > I think the key difference here is that Autotools allows arbitrarily > > > generated code to be executed at any time. More modern build

Re: Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Am Donnerstag, dem 18.04.2024 um 14:01 +0200 schrieb Tobias Burnus: > Hi Janne, > > Janne Blomqvist wrote: > > back when I was active I did think about this > > issue. IMHO the best of my ideas was to convert these into C++ > > templates. I haven't looked at libgfortran but I didn't find it probl

Re: strtol(3) with QChar arguments

Am Sonntag, dem 05.05.2024 um 15:13 +0200 schrieb Alejandro Colomar: > Hi Martin, > > I was wondering why C23 didn't use QChar for strtol(3). It has the same > problems that string functions have: a const input string and a > non-const output string (the endptr). I am not sure whether strtol was

Re: -Wcast-qual consistency with initialization conversion and double pointer types

I think it should not warn about: char *x; *(char * volatile *)&x; as this is regular qualifier adding and this is a bug in GCC. I would guess it looks at all qualifiers added at all level but should ignore the one on the first level. Martin Am Samstag, dem 15.06.2024 um 10:17 -0700 schrieb

check_qualified_type

I am trying to understand what check_qualified_type does exactly. The direct comparison of TYPE_NAMES seems incorrect for C and its use is c_update_type_canonical then causes PR114930 and PR115502. In the later function I think it is not really needed and I guess one could simply remove it, but

Re: check_qualified_type

Am Montag, dem 17.06.2024 um 08:01 +0200 schrieb Richard Biener via Gcc: > On Sun, 16 Jun 2024, Martin Uecker wrote: > > > > > > > I am trying to understand what check_qualified_type > > does exactly. The direct comparison of TYPE_NAMES seems incorrect > > for C and its use is c_update_type_cano

Re: -Wcast-qual consistency with initialization conversion and double pointer types

Am Montag, dem 17.06.2024 um 12:06 + schrieb Joseph Myers: > On Sun, 16 Jun 2024, Martin Uecker via Gcc wrote: > > > I think it should not warn about: > > > > char *x; > > *(char * volatile *)&x; > > > > as this is regular qualifier adding

Re: check_qualified_type

Am Montag, dem 17.06.2024 um 14:57 +0200 schrieb Jakub Jelinek: > On Mon, Jun 17, 2024 at 02:42:05PM +0200, Richard Biener wrote: > > > > > I am trying to understand what check_qualified_type > > > > > does exactly. The direct comparison of TYPE_NAMES seems incorrect > > > > > for C and its use is

Re: check_qualified_type

Am Montag, dem 17.06.2024 um 15:40 +0200 schrieb Jakub Jelinek: > On Mon, Jun 17, 2024 at 03:33:05PM +0200, Martin Uecker wrote: > > > I've done that and that was because build_qualified_type uses that > > > predicate, where qualified types created by build_qualified_type have > > > as TYPE_CANONIC

Re: Union initialization semantics

Am Mittwoch, dem 19.06.2024 um 13:59 +0100 schrieb Jonathan Wakely via Gcc: > On Wed, 19 Jun 2024 at 11:57, Alexander Monakov wrote: > > > > Hello, > > > > I vaguely remember there was a recent, maybe within last two months, > > discussion > > about semantics of union initialization where sizeo

Re: consistent unspecified pointer comparison

Am Donnerstag, dem 27.06.2024 um 13:02 -0400 schrieb Jason Merrill via Gcc: > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > proposes to require that repeated unspecified comparisons be > self-consistent, which does not match current behavior in either GCC > or Clang. The

Re: consistent unspecified pointer comparison

Am Donnerstag, dem 27.06.2024 um 12:05 -0700 schrieb Andrew Pinski via Gcc: > On Thu, Jun 27, 2024 at 11:57 AM Jason Merrill via Gcc > wrote: > > > > On Thu, Jun 27, 2024 at 2:38 PM Richard Biener > > wrote: > > > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > > > > > > > https:

Re: IFNDR on UB? [was: Straw poll on shifts with out of range operands]

Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via Gcc: ... > I.e. once UB becomes IFNDR, the dreaded time-travel optimizations can't > happen > anymore. Instead precondition checks bubble up because otherwise the program > is ill-formed. It is not clear to mean what you mea

Re: IFNDR on UB? [was: Straw poll on shifts with out of range operands]

Am Sonntag, dem 30.06.2024 um 05:03 +0200 schrieb Matthias Kretz: > On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote: > > Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via Gcc: > > > I.e. once UB becomes IFNDR, the dreaded time-travel optimizations can't > > > happen

Re: IFNDR on UB? [was: Straw poll on shifts with out of range operands]

(as suggested before by Martin Sebor) that causes the backend to emit an error in a very late pass when the __builtin_warning has not been removed during optimization. Then this would solve all my problems related to UB. Martin Am Sonntag, dem 30.06.2024 um 08:33 +0200 schrieb Martin Uecker via

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Am Freitag, dem 05.07.2024 um 16:37 +0200 schrieb Alejandro Colomar via Gcc: > [CC += linux-man@, since we're discussing an API documented there, and > the manual page would also need to be updated] > > Hi Xi, Jakub, > > On Fri, Jul 05, 2024 at 09:38:21PM GMT, Xi Ruoyao wrote: > > On Fri, 2024-

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Am Freitag, dem 05.07.2024 um 17:23 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Fri, Jul 05, 2024 at 05:02:15PM GMT, Martin Uecker wrote: > > > But when the thing gets non-trivial, as in strtol(3), GCC misses the > > > -Wrestrict diagnostic, as reported in > > >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Am Freitag, dem 05.07.2024 um 17:53 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Fri, Jul 05, 2024 at 05:34:55PM GMT, Martin Uecker wrote: > > > I've written functions that more closely resemble strtol(3), to show > > > that in the end they all share the same issue regarding const-ness: >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Am Freitag, dem 05.07.2024 um 17:24 +0100 schrieb Jonathan Wakely: > On Fri, 5 Jul 2024 at 17:02, Xi Ruoyao via Gcc wrote: > > > > On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: > > > At least, I hope there's consensus that while current GCC doesn't warn > > > about this, ideally it

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Am Freitag, dem 05.07.2024 um 21:28 +0200 schrieb Alejandro Colomar: ... > > > > Showing that you can contrive a case where a const char* restrict and > > > char** restrict can alias doesn't mean there's a problem with strtol. > > > > I think his point is that a const char* restrict and somethin

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Alejandro, if in caller it is known that endptr has access mode "write_only" then it can conclude that the content of *endptr has access mode "none", couldn't it? You also need to discuss backwards compatibility. Changing the type of those functions can break valid programs. You would need

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc: > Hi Martin, > > On Sun, Jul 07, 2024 at 09:15:23AM GMT, Martin Uecker wrote: > > > > Hi Alejandro, > > > > if in caller it is known that endptr has access mode "write_only" > > then it can conclude that the content of

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: ... > And then have it mean something strict, such as: The object pointed to > by the pointer is not pointed to by any other pointer; period. > > This definition is a

Re: WG14 paper for removing restrict from nptr in strtol(3)

Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > > ...

Re: Apply function attributes (e.g., [[gnu::access()]]) to pointees too

Am Donnerstag, dem 11.07.2024 um 11:35 +0200 schrieb Alejandro Colomar via Gcc: > Hi, > > I was wondering how we could extend attributes such as gnu::access() to > apply it to pointees too. Currently, there's no way to specify the > access mode of a pointee. > > Let's take for example strsep(3

Re: IFNDR on UB? [was: Straw poll on shifts with out of range operands]

Am Montag, dem 01.07.2024 um 15:19 +0200 schrieb Matthias Kretz: > On Sunday, 30 June 2024 08:33:35 GMT+2 Martin Uecker wrote: > > Am Sonntag, dem 30.06.2024 um 05:03 +0200 schrieb Matthias Kretz: > > > On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote: > > > > Am Samstag, dem 29.06.2024

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Am Freitag, dem 26.07.2024 um 23:49 +0200 schrieb Alejandro Colomar via Gcc: > On Fri, Jul 26, 2024 at 09:22:42PM GMT, Joseph Myers wrote: > > On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote: > > > > > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor > > > > replying

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Am Samstag, dem 27.07.2024 um 00:26 +0200 schrieb Alejandro Colomar: > On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote: > > > Maybe if GNU C compilers (GCC and Clang) add it first as an extension, > > > adding diagnostics, it would help. > > > > Both GCC and Clang already have such dia

Re: Promote -Wno-sizeof-array-argument to an error

Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > think there's any legitimate use sizeof() on such a parameter. I am a bit worried that it might prevent people from adding size informatio

Re: Spurious -Wsequence-point with auto

Am Freitag, dem 09.08.2024 um 01:10 +0200 schrieb Alejandro Colomar via Gcc: > Hi, > > I've seen some bogus warning in GCC that suggests that some use of auto > may cause undefined behavior (due to double evaluation). > > $ cat auto.c > #include > > int > main(void) > { > int i = 3; >

Re: stack arenas using alloca

Am Freitag, dem 23.08.2024 um 15:46 +1200 schrieb Michael Clark via Gcc: > On 8/23/24 15:24, Michael Clark wrote: > > On 8/15/24 06:24, Michael Clark wrote: > > > Hi Folks, > > > > > like I said this is crazy talk as alloca isn't even in the C standard. > > but VLAs are, and the current implement

Re: #pragma once behavior

There was a recent related proposal for C23. https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2896.htm See also the email by Linus Torvalds referenced in this paper. Note that this proposal was not adopted for ISO C23. I can't find when it was discussed, but IIRC the general criticism was t

Re: C23 status on cppreference

Am Mittwoch, dem 16.10.2024 um 13:27 +0200 schrieb Jakub Jelinek via Gcc: > Hi! > > https://en.cppreference.com/w/c/compiler_support > has a table with compiler support for C23. > I've added #embed and [[unsequenced]]/[[reproducible]] in there > yesterday, but am wondering about the accuracy of th

Re: VLA representation in GCC internals

Am Samstag, dem 09.11.2024 um 11:29 +0100 schrieb Alejandro Colomar via Gcc: > On Sat, Nov 09, 2024 at 09:38:45AM GMT, Martin Uecker wrote: > > Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc: > > > Hi Martin, > > > > > > I'm in the process of rebasing my __countof__ ch

Re: VLA representation in GCC internals

Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc: > Hi Martin, > > I'm in the process of rebasing my __countof__ changes after your patch > that fixes support for [*] and [0]. > > I should update the implementation of the following function: > > static bool >

Re: Handling C2Y zero-length operations on null pointers

Am Montag, dem 07.10.2024 um 15:14 + schrieb Qing Zhao: > > > On Oct 7, 2024, at 10:13, Jakub Jelinek via Gcc wrote: > > > > On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote: > > > * Joseph Myers: > > > > > > > The real question is how to achieve optimal warnings in the absenc

Re: Handling C2Y zero-length operations on null pointers

Am Dienstag, dem 12.11.2024 um 07:51 +0100 schrieb Martin Uecker: > Am Montag, dem 07.10.2024 um 15:14 + schrieb Qing Zhao: > > > > > On Oct 7, 2024, at 10:13, Jakub Jelinek via Gcc wrote: > > > > > > On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote: > > > > * Joseph Myers: > >

Re: examples of (so called) time-travel optimisations in GCC?

Am Samstag, dem 26.10.2024 um 18:55 +0200 schrieb Richard Biener via Gcc: > > > Am 26.10.2024 um 17:30 schrieb Iain Sandoe : > > > > Hi, > > > > The background here is that I made a trial implementation of P1494r4 - > > std::observable() - and want to produce testcases. > > > > —— so ….. > >

Re: 'defer' (n3199) concerns

Am Freitag, dem 08.11.2024 um 16:40 +0100 schrieb Alejandro Colomar via Gcc: > Hi JeanHeyd, > > I was involved this week in a fix for a bug I wrote some months ago > about a call to free(3) with a bad pointer. > > The simplest reproducer is: > > $ cat strsep_bad.c > #include >

commits and bugzilla

I just commited a bug fix and noticed that bugzilla was not automatically updated. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8af6c203f18b4fd736df9567926589d96f8e0b3 Did something change / break or did I do something wrong? Martin

missing features related to static chain

We have __builtin_call_with_static_chain, but I am missing builtins to get the address of the nested function itself (not of a trampoline) and the value one has to pass as static chain. Martin

memory model, READ_ONCE

Hi all, one area where the Linux kernel people are unhappy with C's memory model is where they now have to use the READ_ONCE, WRITE_ONCE macros. These are cases where they do not want a compiler to duplicate a load, e.g. to reload a value later because registers were not available to cache it.

Re: memory model, READ_ONCE

I have one follow-up question: What is the reason that we have stronger semantics for stores by default (i.e. when not using -fallow-store-data-races) than for reads given that the standard would allow more freedom. Only that for reads this is more difficult to have? Or other specific reasons w

  1   2   >