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.
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,
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
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
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
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
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
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
(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
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
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
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
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
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
14 matches
Mail list logo