Am Donnerstag, dem 27.03.2025 um 17:01 -0700 schrieb Bill Wendling via Gcc:
> On Tue, Mar 25, 2025 at 10:13 PM Martin Uecker wrote:
> > Am Dienstag, dem 25.03.2025 um 19:09 -0700 schrieb Bill Wendling:
> > > On Tue, Mar 18, 2025 at 3:04 PM Martin Uecker wrote:
> > > &g
Am Dienstag, dem 25.03.2025 um 19:09 -0700 schrieb Bill Wendling:
> On Tue, Mar 18, 2025 at 3:04 PM Martin Uecker wrote:
> >
>
> It seems clear that using "__self" is most likely going to be part of
> any solution we come up with. What we need to avoid is feature
Am Dienstag, dem 18.03.2025 um 14:03 -0700 schrieb Yeoul Na via Gcc:
>
> > On Mar 18, 2025, at 12:48 PM, Martin Uecker wrote:
> >
> > Am Dienstag, dem 18.03.2025 um 09:52 -0700 schrieb Yeoul Na via Gcc:
> > >
> > > > On Mar 18, 2025, at 12:16 AM, Mart
Am Dienstag, dem 18.03.2025 um 09:52 -0700 schrieb Yeoul Na via Gcc:
>
> > On Mar 18, 2025, at 12:16 AM, Martin Uecker wrote:
> >
> > When xp->ptr is accessed, the size expression
> > is evaluated and the lvalue which is formed at this point in
> > time gets
Am Montag, dem 17.03.2025 um 16:45 -0700 schrieb Yeoul Na via Gcc:
> >
> > > > On Mar 15, 2025, at 1:27 AM, Martin Uecker wrote:
...
> > > >
> > > > > > > > Anyway, a lot of this changes if we want to use the same
> > > >
Hi John,
(I changed gcc-patches to gcc)
Am Samstag, dem 15.03.2025 um 00:22 -0400 schrieb John McCall:
> > On 14 Mar 2025, at 15:18, Martin Uecker wrote:
> > > >
...
> > > > But let's rephrase my point a bit more precisely: One could take
> > > &
Am Samstag, dem 01.03.2025 um 16:52 +0300 schrieb Alexander Monakov:
> On Sat, 1 Mar 2025, Martin Uecker via Gcc wrote:
>
> > Sorry for being a bit slow. This is still not clear to me.
> >
> > In vect/pr65206.c the following loop can be vectorized
> >
Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
> >
> > I have one follow-up question: What is the reason
> > that we have stronger semantics for stores by default (i.e.
> > when not using
Am Freitag, dem 28.02.2025 um 20:21 +0100 schrieb Richard Biener:
>
> > Am 28.02.2025 um 20:02 schrieb Martin Uecker :
> >
> > Am Freitag, dem 28.02.2025 um 21:39 +0300 schrieb Alexander Monakov:
> > > > On Fri, 28 Feb 2025, Martin Uecker via Gcc wrote:
>
why data races for stores
are problematic?
Martin
Am Freitag, dem 28.02.2025 um 19:13 +0100 schrieb Martin Uecker:
> Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc:
> > On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote:
> > >
> > >
>
Am Freitag, dem 28.02.2025 um 08:18 +0100 schrieb Richard Biener via Gcc:
> On Fri, Feb 28, 2025 at 8:01 AM Martin Uecker wrote:
> >
> >
> > Hi all,
> >
> > one area where the Linux kernel people are unhappy with C's
> > memory model is where they n
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.
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
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
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
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
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
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
>
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
>
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 …..
> >
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
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
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
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;
>
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
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.
> >
> > Bot
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
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 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
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
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
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"
&
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
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
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
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
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
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-
(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
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
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
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:
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
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
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_qu
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
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
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 inco
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
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
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
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
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
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?
> >
> > (
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
> complic
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
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
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:
> &g
Am Montag, dem 18.03.2024 um 14:29 +0100 schrieb David Brown:
>
> On 18/03/2024 12:41, Martin Uecker wrote:
> >
> >
> > Hi David,
> >
> > Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown:
> > > Hi,
> > >
>
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+
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
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 w
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
Am Dienstag, dem 21.11.2023 um 02:30 + schrieb André Albergaria Coelho via
Gcc:
> Hello
>
> #include
>
> void func(char *ptr) {
> printf("\n%i",sizeof(ptr));
> }
>
> int main(void) {
> char arr[10];
> printf("\n Sizeof arr %i",sizeof(arr));
> func(arr);
>
> return
I think this is the same bug already filed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954
Martin
Am Mittwoch, dem 01.11.2023 um 09:11 +0100 schrieb Rene Kita:
> Since I'm unable to create an account to report a bug and got no reply
> from gcc-bugzilla-account-requ...@gcc.gnu.org I'll
Note that the C++ warning is for jumping over a declaration,
which is generally allowed in C but not in C++.
Martin
Am Donnerstag, dem 19.10.2023 um 13:49 +0200 schrieb Martin Uecker:
>
>
> GCC supports this as an extension.
>
> Mixing declarations and code is allowed
GCC supports this as an extension.
Mixing declarations and code is allowed in C99 and C23
will also allow placing labels before declarations and at
the end of a compound statement. GCC supports all this
also in earlier language modes.
See:
https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-
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
Am Montag, dem 18.09.2023 um 22:15 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 21:09, Martin Uecker wrote:
>
> > I do not understand why memcheck cares about the potential trap when
> > deciding to do the backwards transformation that combines the two
> > c
Am Montag, dem 18.09.2023 um 19:56 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 16:55, Richard Biener wrote:
>
> > What you could do is report the access only on the point of use of
> > the accessed value? (and disregard when the register holding the
> > value is re-used)
>
> Hi Richard
>
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
Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov:
> On Mon, 18 Sep 2023, Jakub Jelinek wrote:
>
> > Perhaps we should add some initial hammer approach for the pragma, like
> > if you ever use the pragma to turn it somewhere off, it is turned off
> > globally, or ditto per functio
Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote:
> >
> > Hi Florian,
> >
> > On Thu, 14 Sep 2023, Alexander Monakov wrote:
> >
> > >
> > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> > >
> > > > While
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:
(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
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
Am Montag, dem 14.08.2023 um 11:51 +0200 schrieb Alejandro Colomar via Gcc:
> Hi Richard,
>
> On 2023-08-14 08:41, Richard Biener wrote:
> > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc
> > wrote:
>
> [...]
>
> > > How about some -Wfam-sizeof-arithmetic that would not warn about ta
Am Mittwoch, dem 09.08.2023 um 14:37 +0200 schrieb Alejandro Colomar:
> Hi Martin!
>
> On 2023-08-09 14:03, Martin Uecker wrote:
>
> Regarding the issues you have with _Nonnull being a qualifier,
> I've been thinking about it for a long time and don't yet have
>
Hi Alejandro!
Am Mittwoch, dem 09.08.2023 um 12:42 +0200 schrieb Alejandro Colomar:
...
>
> As for when one would want to mean the first (size of array)
> but not _Nonnull: for a function where you may pass either
> an array (which should not be smaller than the size), or a
> sentinel NULL va
timization. I think
clang uses it for optimization.
Martin
> i've seen
> proposals like
> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
> but i haven't seen anything i can use yet, so you -- who do use GCC
> which aiui has something
Am Montag, dem 10.07.2023 um 22:16 +0200 schrieb Alejandro Colomar via Gcc:
> On 7/10/23 22:14, Alejandro Colomar wrote:
> > [CC += Andrew]
> >
> > Hi Xi, Andrew,
> >
> > On 7/10/23 20:41, Xi Ruoyao wrote:
> > > Maybe we should have a weaker version of nonnull which only performs the
> > > diagno
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
Am Mittwoch, dem 12.07.2023 um 15:23 +0200 schrieb Benjamin Priour via
Gcc:
> Hi David,
>
>
> Lately I've been working on adding a new state machine to keep track
> of
> ownership transfers
>
> and misuses, e.g. to warn about use-after-move, partial or shallow
> copy/move.
>
> I'm trying to sta
not need to discuss this now. I still very
much appreciate your input!
Note that I am involved with C standardization, but
TR 18307 precedes this.
Martin
Am Mittwoch, dem 05.07.2023 um 13:34 +0200 schrieb David Brown:
>
>
> On 05/07/2023 11:25, Martin Uecker wrote:
> > A
Am Mittwoch, dem 05.07.2023 um 12:17 +0200 schrieb Rafał Pietrak:
> Hi
>
> W dniu 5.07.2023 o 11:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
>
...
> >
> > > Then again, should you happen to fall onto an
> &
Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
> Hi,
>
> W dniu 5.07.2023 o 09:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> [---]
> > > And if it's so ... there is no mention of how does i
Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:
> On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
...
>
> In my personal opinion (which you are all free to disregard), named
> address spaces were an interesting idea that failed. I was
> enthusiastic
> about a number of the ex
Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> Hi,
>
> W dniu 5.07.2023 o 00:57, Martin Uecker pisze:
> > Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> []
> > >
> > > Yes. named address spac
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> >
> > I think a C++ class (or rather, class template) with inline functions is
> > the way to go here. gcc's optimiser will give good code, and the C++
> > class will let you get nice syntax to hide the messy details.
>
>
Am Mittwoch, dem 28.06.2023 um 17:49 +0100 schrieb Richard Earnshaw (lists):
> On 28/06/2023 17:07, Martin Uecker wrote:
> > Am Mittwoch, dem 28.06.2023 um 16:44 +0100 schrieb Richard Earnshaw (lists):
> > > On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote:
> > > >
Am Mittwoch, dem 28.06.2023 um 16:44 +0100 schrieb Richard Earnshaw (lists):
> On 28/06/2023 15:51, Rafał Pietrak via Gcc wrote:
> > Hi Martin,
> >
> > W dniu 28.06.2023 o 15:00, Martin Uecker pisze:
> > >
> > > Sounds like named address spaces to me:
&
Sounds like named address spaces to me:
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
Best,
Martin
Am Dienstag, dem 27.06.2023 um 14:26 +0200 schrieb Rafał Pietrak via Gcc:
> Hello everybody,
>
> I'm not quite sure if this is correct mailbox for this suggestion (may
> be "embed
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:
> > > >
> > &
> 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
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 standa
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
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;
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 A
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.
> >
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
> >
> >
> > >
> > > [...]
> > >
> >
1 - 100 of 168 matches
Mail list logo
