Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
>
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing specific to main in this test, and
it doesn
On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> On 10/4/22 11:11, Ben Boeckel wrote:
> > This patch adds initial support for ISO C++'s [P1689R5][], a format
> > for
> > describing C++ module requirements and provisions based on the
> > source
> > code. This is required because compiling C
On Thu, Oct 13, 2022 at 07:03:24PM +0200, Arsen Arsenović wrote:
> @@ -1,10 +1,10 @@
> /* Check for "noreturn" warning in main. */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Wmissing-noreturn -ffreestanding" } */
> +/* { dg-options "-O2 -Wmissing-noreturn" } */
> extern void exit (int) _
On 10/13/22 13:02, Arsen Arsenović wrote:
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing sp
On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere? If not, then certain
> "warn for main" part should be removed or replaced...
Whoops, missed that comment. There is actually an equivalent test that
I overlooked (noreturn-1.c), so mayb
Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>The GNU Toolchain project leadership supports the proposal[1] to move the
>services for the GNU Toolchain to the Linux Foundation IT under the auspices of
>the Toolch
Hi,
I have a testcase (from real workloads) involving C++ atomics and trying
to understand the codegen (gcc 12) for RVWMO and x86.
It does mix atomics with non-atomics so not obvious what the behavior is
intended to be hence some explicit CC of subject matter experts
(apologies for that in adv
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have very strong opinions ;) I certainly can't
On Thu, 13 Oct 2022 at 20:31, Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some expli
On Thu, Oct 13, 2022 at 9:31 PM Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some ex
The generated code here is correct in both cases. In the RISC--V case, I
believe it is conservative, at a minimum, in that atomics should not imply
IO ordering. We had an earlier discussion, which seemed to have consensus
in favor of that opinion. I believe clang does not enforce IO ordering.
You
Hi Hans,
On 10/13/22 13:54, Hans Boehm wrote:
The generated code here is correct in both cases. In the RISC--V case,
I believe it is conservative, at a minimum, in that atomics should not
imply IO ordering. We had an earlier discussion, which seemed to have
consensus in favor of that opinion.
On 10/13/22 13:30, Uros Bizjak wrote:
OTOH, for x86 (same default toggles) there's no barriers at all.
_Z10bar_seqcstiPi:
endbr64
movlg(%rip), %eax
movl%eax, (%rsi)
movla(%rip), %eax
addl%edi, %eax
ret
Regardin
On 10/13/22 16:14, Arsen Arsenović wrote:
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
I was arguing that we don't need the new flag; there shouldn't be any
need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have ve
On Thu, Oct 13, 2022 at 11:14 PM Vineet Gupta wrote:
>
>
>
> On 10/13/22 13:30, Uros Bizjak wrote:
>
> OTOH, for x86 (same default toggles) there's no barriers at all.
>
> _Z10bar_seqcstiPi:
> endbr64
> movlg(%rip), %eax
> movl%eax, (%rsi)
> movl
On Thu, Oct 13, 2022 at 2:11 PM Vineet Gupta wrote:
> Hi Hans,
>
> On 10/13/22 13:54, Hans Boehm wrote:
>
> The generated code here is correct in both cases. In the RISC--V case, I
> believe it is conservative, at a minimum, in that atomics should not imply
> IO ordering. We had an earlier discus
Snapshot gcc-10-20221013 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20221013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
17 matches
Mail list logo
