On Fri, 28 Jan 2022 at 00:59, Martin Sebor wrote:
> In practice, I'd expect most calls to atomic functions to be made
> with constant memory models, and code like in the test case above
> to be uncommon, so I think the choice of warning at -O0 was
> the right one.
Some of us consider it a misfeatu
On 1/27/22 16:47, Andrew Pinski wrote:
On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functi
On Thu, Jan 27, 2022 at 3:47 PM Andrew Pinski wrote:
>
> On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
> wrote:
> >
> > Even with -Wno-system-headers enabled, the -Winvalid-memory-order
> > code tries to make sure calls to atomic functions with invalid
> > memory orders are diagnose
On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
wrote:
>
> Even with -Wno-system-headers enabled, the -Winvalid-memory-order
> code tries to make sure calls to atomic functions with invalid
> memory orders are diagnosed even though the C atomic functions
> are defined as macros in the
On 1/5/22 1:45 AM, Martin Liška wrote:
On 12/8/21 17:49, Martin Sebor via Gcc-patches wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
are defined
On 12/8/21 17:49, Martin Sebor via Gcc-patches wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
are defined as macros in the system header.
The wa
On 12/8/2021 9:49 AM, Martin Sebor via Gcc-patches wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
are defined as macros in the system header.
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586402.html
Besides PR 99612 this also fixes the false positive reported
recently in PR 103372.
On 12/8/21 9:49 AM, Martin Sebor wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls t
On 12/8/21 10:14 AM, Jonathan Wakely wrote:
On Wed, 8 Dec 2021 at 16:49, Martin Sebor wrote:
I don't anticipate this change to lead to the same fallout
because it's unlikely for GCC to synthesize invalid memory
orders out of thin air;
Agreed. I don't think we'll have the same kind of issues. 9
On Wed, 8 Dec 2021 at 16:49, Martin Sebor wrote:
> I don't anticipate this change to lead to the same fallout
> because it's unlikely for GCC to synthesize invalid memory
> orders out of thin air;
Agreed. I don't think we'll have the same kind of issues. 99% of uses
of memory orders just use the c
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic functions
are defined as macros in the system header.
The warning triggers at all optimization levels, including -O
11 matches
Mail list logo
