Re: [PATCH v6 0/4] P1689R5 support

2023-06-19 Thread Jason Merrill via Gcc
On 6/17/23 10:43, Ben Boeckel wrote: On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote: I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g. FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) Excess errors: /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-19 Thread Marc Glisse via Gcc
On Mon, 19 Jun 2023, 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) and GCC12 (or higher). On -O3 -mavx2 the former compiles above function to relu(float): vmaxss xmm0,

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

2023-06-19 Thread Jason Merrill via Gcc
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 and therefore all Unicode rejects

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

2023-06-19 Thread Jason Merrill via Gcc
On 5/12/23 10:24, Ben Boeckel wrote: On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: I notice that the actual flags are all -fdep-*, though some of them are -fdeps-* here, and the internal variables all seem to be fdeps_*. I lean toward harmonizing on "deps", I think. Done. I d

Re: Different ASM for ReLU function between GCC11 and GCC12

2023-06-19 Thread Jakub Jelinek via Gcc
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) and GCC12 (or higher). On > -O3 -mavx2 the former compiles above function to

Different ASM for ReLU function between GCC11 and GCC12

2023-06-19 Thread André Günther via Gcc
Hi, 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) and GCC12 (or higher). On -O3 -mavx2 the former compiles above function to relu(float): vmaxss xmm0, xmm0, DWORD PTR .LC0[rip] ret .LC0: .lo

Re: gcc tricore porting

2023-06-19 Thread Alexander Monakov via Gcc
On Mon, 19 Jun 2023, Mikael Pettersson via Gcc wrote: > (Note I'm reading the gcc mailing list via the Web archives, which > doesn't let me create "proper" replies. Oh well.) (there's a public-inbox instance at https://inbox.sourceware.org/gcc/ but some messages are not available there) Alexan

Re: gcc tricore porting

2023-06-19 Thread Joel Sherrill
On Mon, Jun 19, 2023, 10:36 AM Mikael Pettersson via Gcc wrote: > (Note I'm reading the gcc mailing list via the Web archives, which > doesn't let me > create "proper" replies. Oh well.) > > On Sun Jun 18 09:58:56 GMT 2023, wrote: > > Hi, this is my first time with open source development. I wor

Re: gcc tricore porting

2023-06-19 Thread Mikael Pettersson via Gcc
(Note I'm reading the gcc mailing list via the Web archives, which doesn't let me create "proper" replies. Oh well.) On Sun Jun 18 09:58:56 GMT 2023, wrote: > Hi, this is my first time with open source development. I worked in > automotive for 22 years and we (generally) were using tricore series

Re: gcc tricore porting

2023-06-19 Thread Michael Matz via Gcc
Hello, note that I know next to nothing about Tricore in particular, so take everything with grains of salt. Anyway: On Mon, 19 Jun 2023, Claudio Eterno wrote: > in your reply you mentioned "DSP". Do you want to use the DSP instructions > for final assembly? It's not a matter of me wanting or

Patch regarding addition of .symtab while generating object file from libiberty [WIP]

2023-06-19 Thread Rishi Raj via Gcc
Hi, I am working on the GSOC project "Bypass Assembler when generating LTO object files." So as a first step, I am adding .symtab along with __gnu_lto_slim symbol into it so that at a later stage, it can be recognized that this object file has been produced using -flto enabled. This patch is regard

Re: gcc tricore porting

2023-06-19 Thread Claudio Eterno via Gcc
Hi Michael in your reply you mentioned "DSP". Do you want to use the DSP instructions for final assembly? Michael, based on your experience, how much time is necessary to release this porting? And.. have you any idea about where to start? Ciao Claudio Il giorno lun 19 giu 2023 alle ore 16:16 Mich

Re: gcc tricore porting

2023-06-19 Thread Michael Matz via Gcc
Hello, On Mon, 19 Jun 2023, Richard Biener via Gcc wrote: > On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc > wrote: > > > > Hi, this is my first time with open source development. I worked in > > automotive for 22 years and we (generally) were using tricore series for > > these product

Re: gcc tricore porting

2023-06-19 Thread Richard Biener via Gcc
On Sun, Jun 18, 2023 at 12:00 PM Claudio Eterno via Gcc wrote: > > Hi, this is my first time with open source development. I worked in > automotive for 22 years and we (generally) were using tricore series for > these products. GCC doesn't compile on that platform. I left my work some > days ago a