Re: [PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF

2023-06-20 Thread Ben Boeckel via Gcc
On Tue, Jun 20, 2023 at 21:16:40 +0200, Damien Guibouret wrote: > I think the comparison should be ">" instead of ">=" as 0x10 seems a > valid value (Unicode says value above 0x10 is invalid). > Other tests around same value in this file are using ">". Ah, good catch. I'll make a separate

Re: [PATCH v5 3/5] p1689r5: initial support

2023-06-20 Thread Ben Boeckel via Gcc
On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: > On 1/25/23 13:06, Ben Boeckel wrote: > > - header-unit information fields > > > > Header units (including the standard library headers) are 100% > > unsupported right now because the `-E` mechanism wants to import their > > BMIs. A new

Re: [PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF

2023-06-20 Thread Damien Guibouret
Le 19/06/2023 à 23:34, Jason Merrill a écrit : On 6/6/23 16:50, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. Pushed. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints an

Re: [PATCH v5 3/5] p1689r5: initial support

2023-06-20 Thread Ben Boeckel via Gcc
On Mon, Jun 19, 2023 at 17:33:58 -0400, Jason Merrill wrote: > On 5/12/23 10:24, Ben Boeckel wrote: > > `file` can be omitted (the `output_stream` will be used then). I *think* > > I see that adding: > > > > %{fdeps_file:-fdeps-file=%{!o:%b.ddi}%{o*:%.ddi%*}} > > %{!fdeps-file: but yes. > >

Announcing GCC Code of Conduct

2023-06-20 Thread Jason Merrill via Gcc
I am pleased to announce that the GCC Steering Committee has decided to adopt a Code of Conduct (https://gcc.gnu.org/conduct.html) for interactions in GCC project spaces, including mailing lists, bugzilla, and IRC. The vast majority of the time, the GCC community is a very civil, cooperative space

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-20 Thread Jakub Jelinek via Gcc
On Tue, Jun 20, 2023 at 03:03:19PM +, Michael Matz via Gcc wrote: > Hello, > > On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote: > > > ce1 pass results in emit_conditional_move with > > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84) > > operands in the GCC 11 case and

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-20 Thread Michael Matz via Gcc
Hello, On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote: > ce1 pass results in emit_conditional_move with > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84) > operands in the GCC 11 case and so is successfully matched by > ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax. >

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-20 Thread Jakub Jelinek via Gcc
On Tue, Jun 20, 2023 at 10:15:37AM +0200, Richard Biener wrote: > On Mon, Jun 19, 2023 at 9:45 PM Jakub Jelinek via Gcc wrote: > > > > On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote: > > > I noticed that a simple function like > > > auto relu( float x ) { > > > return x

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-20 Thread Richard Biener via Gcc
On Mon, Jun 19, 2023 at 9:45 PM Jakub Jelinek via Gcc wrote: > > On Mon, Jun 19, 2023 at 09:10:53PM +0200, André Günther via Gcc wrote: > > I noticed that a simple function like > > auto relu( float x ) { > > return x > 0.f ? x : 0.f; > > } > > compiles to different ASM using GCC11 (or lower)