Re: [PATCH v6 0/4] P1689R5 support
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.C:9:1: internal compiler error: Segmentation fault 0x19e2f3c crash_signal /home/jason/gt/gcc/toplev.cc:314 0x340f3f8 mkdeps::vec::size() const /home/jason/gt/libcpp/mkdeps.cc:57 0x340dc1f apply_vpath /home/jason/gt/libcpp/mkdeps.cc:194 0x340e08e deps_add_dep(mkdeps*, char const*) /home/jason/gt/libcpp/mkdeps.cc:318 0xea7b51 module_client::open_module_client(unsigned int, char const*, mkdeps*, void (*)(char const*), char const*) /home/jason/gt/gcc/cp/mapper-client.cc:291 0xef2ba8 make_mapper /home/jason/gt/gcc/cp/module.cc:14042 0xf0896c get_mapper(unsigned int, mkdeps*) /home/jason/gt/gcc/cp/module.cc:3977 0xf032ac name_pending_imports /home/jason/gt/gcc/cp/module.cc:19623 0xf03a7d preprocessed_module(cpp_reader*) /home/jason/gt/gcc/cp/module.cc:19817 0xe85104 module_token_cdtor(cpp_reader*, unsigned long) /home/jason/gt/gcc/cp/lex.cc:548 0xf467b2 cp_lexer_new_main /home/jason/gt/gcc/cp/parser.cc:756 0xfc1e3a c_parse_file() /home/jason/gt/gcc/cp/parser.cc:49725 0x11c5bf5 c_common_parse_file() /home/jason/gt/gcc/c-family/c-opts.cc:1268 Thanks. I missed a `nullptr` check before calling `deps_add_dep`. I think I got misled by `make check` returning a zero exit code even if there are failures. Aha! Patches 3 and 4 could also use testcases. Jason
Re: Different ASM for ReLU function between GCC11 and GCC12
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, xmm0, DWORD PTR .LC0[rip]
ret
.LC0:
.long 0
which is what I would naively expect and what also clang essentially does
(clang actually uses an xor before the maxss to get the zero). The latter,
however, compiles the function to
relu(float):
vxorps xmm1, xmm1, xmm1
vcmpltss xmm2, xmm1, xmm0
vblendvps xmm0, xmm1, xmm0, xmm2
ret
which looks like a missed optimisation. Does anyone know if there's a
reason for the changed behaviour?
With -fno-signed-zeros -ffinite-math-only, gcc-12 still uses max instead
of cmp+blend. So the first thing to check would be if both versions give
the same result on negative 0 and NaN.
--
Marc Glisse
Re: [PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF
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 such values. Signed-off-by: Ben Boeckel --- libcpp/charset.cc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libcpp/charset.cc b/libcpp/charset.cc index d7f323b2cd5..3b34d804cf1 100644 --- a/libcpp/charset.cc +++ b/libcpp/charset.cc @@ -1886,6 +1886,13 @@ cpp_valid_utf8_p (const char *buffer, size_t num_bytes) int err = one_utf8_to_cppchar (&iter, &bytesleft, &cp); if (err) return false; + + /* Additionally, Unicode declares that all codepoints above 0010 are +invalid because they cannot be represented in UTF-16. + +Reject such values.*/ + if (cp >= 0x10) + return false; } /* No problems encountered. */ return true;
Re: [PATCH v5 3/5] p1689r5: initial support
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 don't love the three separate options, but I suppose it's fine. I'd
prefer "target" instead of "output".
Done.
It should be possible to omit both -file and -target and get reasonable
defaults, like the ones for -MD/-MQ in gcc.cc:cpp_unique_options.
`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.
would at least do for `-fdeps-file` defaults? I don't know if there's a
reasonable default for `-fdeps-target=` though given that this command
line has no information about the object file that will be used (`-o` is
used for preprocessor output since we're leaning on `-E` here).
I would think it could default to %b.o?
I had quite a few more comments on the v5 patch that you didn't respond
to here or address in the v6 patch; did your mail client hide them from you?
Jason
Re: Different ASM for ReLU function between GCC11 and GCC12
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
Such reports should go into gcc.gnu.org/bugzilla/, not to the mailing list,
if you are convinced that loading the constant from memory is faster.
Another possibility is
vxorps xmm1, xmm1, xmm1
vmaxss xmm0, xmm0, xmm1
ret
which doesn't need to wait for the memory.
This changed with https://gcc.gnu.org/r12-7693
>
> relu(float):
> vmaxss xmm0, xmm0, DWORD PTR .LC0[rip]
> ret
> .LC0:
> .long 0
>
> which is what I would naively expect and what also clang essentially does
> (clang actually uses an xor before the maxss to get the zero). The latter,
> however, compiles the function to
>
> relu(float):
> vxorps xmm1, xmm1, xmm1
> vcmpltss xmm2, xmm1, xmm0
> vblendvps xmm0, xmm1, xmm0, xmm2
> ret
>
> which looks like a missed optimisation. Does anyone know if there's a
> reason for the changed behaviour?
Jakub
Different ASM for ReLU function between GCC11 and GCC12
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:
.long 0
which is what I would naively expect and what also clang essentially does
(clang actually uses an xor before the maxss to get the zero). The latter,
however, compiles the function to
relu(float):
vxorps xmm1, xmm1, xmm1
vcmpltss xmm2, xmm1, xmm0
vblendvps xmm0, xmm1, xmm0, xmm2
ret
which looks like a missed optimisation. Does anyone know if there's a
reason for the changed behaviour?
Andre
Re: gcc tricore porting
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) Alexander
Re: gcc tricore porting
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 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 and so I'll have some spare time in the next few months. I would > > like to know how difficult it is to port the tricore platform on gcc and > if > > during this process somebody can support me as tutor and... also if the > gcc > > team is interested in this item... > > https://github.com/volumit has a port of gcc + binutils + newlib + gdb > to Tricore, > and it's not _that_ ancient. I have no idea where it originates from > or how complete > it is, but I do know the gcc-4.9.4 based one builds with some tweaks. > https://github.com/volumit/package_494 says there is a port in process to > gcc 9. Perhaps digging in and assessing that would be a good start. > One question is whether that code has proper assignments on file for ultimate inclusion. That should be part of your assessment. --joel > I don't know anything more about it, I'm just a collector of > cross-compilers for > obscure / lost / forgotten / abandoned targets. > > /Mikael >
Re: gcc tricore porting
(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 for > these products. GCC doesn't compile on that platform. I left my work some > days ago and so I'll have some spare time in the next few months. I would > like to know how difficult it is to port the tricore platform on gcc and if > during this process somebody can support me as tutor and... also if the gcc > team is interested in this item... https://github.com/volumit has a port of gcc + binutils + newlib + gdb to Tricore, and it's not _that_ ancient. I have no idea where it originates from or how complete it is, but I do know the gcc-4.9.4 based one builds with some tweaks. I don't know anything more about it, I'm just a collector of cross-compilers for obscure / lost / forgotten / abandoned targets. /Mikael
Re: gcc tricore porting
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 not wanting, I have no stake in tricore. From a 20-second look at the Infineon architecture overview I've linked it looked like that some DSP instructions could be used for implementing normal floating point support, which of course would be desirable in a compiler supporting all of C (otherwise you'd have to resort to softfloat emulation). But I have no idea if the CPU and the DSP parts are interconnected enough (hardware wise) to make that feasible (or even required, maybe the CPU supports floating point itself already?). > Michael, based on your experience, how much time is necessary to release > this porting? Depending on experience in compilers in general and GCC in particular: anything between a couple weeks (fulltime) and a year. > And.. have you any idea about where to start? If you don't have an assembler and linker already, then with that. An assembler/linker is not part of GCC, but it relies on one. So look at binutils for this. Once binutils are taken care of: Richis suggestion is a good one: start with an existing port of a target with similar features as you intend to implement, and modify it according to your needs. After that works (say, you can compile a hello-world successfully): throw it away and restart a completely new target from scratch with everything you learned until then. (This is so that you don't start with all the cruft that the target you used as baseline comes with). It helps if you already have a toolchain that you can work against, but it's not required. You need to be familiar with some GCC internals, and the documentation coming with GCC is a good starting point: https://gcc.gnu.org/onlinedocs/gccint/ (the "Machine Description" chapter will be the important one, but for that you need to read a couple other chapters as well) There are a couple online resources about writing new targets for GCC. Stackoverflow refers to some. E.g. https://stackoverflow.com/questions/44904644/gcc-how-to-add-support-to-a-new-architecture refers to https://kristerw.blogspot.com/2017/08/writing-gcc-backend_4.html which is something not too old. For concrete questions this mailing list is a good place to ask. Good luck, Michael. > > Ciao > Claudio > > Il giorno lun 19 giu 2023 alle ore 16:16 Michael Matz ha > scritto: > > > 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 products. GCC doesn't compile on that platform. I left my work > > some > > > > days ago and so I'll have some spare time in the next few months. I > > would > > > > like to know how difficult it is to port the tricore platform on gcc > > and if > > > > during this process somebody can support me as tutor and... also if > > the gcc > > > > team is interested in this item... > > > > > > We welcome ports to new architectures. Quick googling doesn't find me > > > something like an ISA specification though so it's difficult to assess > > the > > > complexity of porting to that architecture. > > > > https://en.wikipedia.org/wiki/Infineon_TriCore > > > > https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111 > > > > CPU part looks like fairly regular 32bit RISC. DSP part seems quite > > normal as well. There even was once a GCC port to Tricore, version 3.3 > > from HighTec (now part of Infineon itself), but not even the wayback > > machine has the files for that anymore: > > > > > > https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html > > > > Given the age of that port it's probably better to start from scratch > > anyway :) (the current stuff from them/Infineon doesn't seem to be > > GCC-based anymore?) > > > > > > Ciao, > > Michael. > > > >
Patch regarding addition of .symtab while generating object file from libiberty [WIP]
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 regarding the same. Although I am still testing this patch, I
want general feedback on my code and design choice.
I have extended simple_object_wrtie_struct to hold a list of symbols (
similar to sections ). A function in simple-object.c to add symbols. I am
calling this function in lto-object.cc to add __gnu_lto_v1.
Right now, as we are only working on ELF support first, I am adding .symtab
in elf object files only.
Note:- I have added this patch on top of Jan's updated patch (
https://gcc.gnu.org/pipermail/gcc/2022-May/238670.html). I am pushing all
these changes to my GitHub repo:
https://github.com/rsh-raj/gcc/tree/patch-devel, so you can also view them
from there.
-Rishi
---
>From 5760ccce2f4ae8930a07e3d0d4e0d029737a44d8 Mon Sep 17 00:00:00 2001
From: rsh-raj
Date: Mon, 19 Jun 2023 19:42:50 +0530
Subject: [PATCH] Added .symtab support
---
gcc/lto-object.cc| 4 +-
include/simple-object.h | 10 +++
libiberty/simple-object-common.h | 18 +
libiberty/simple-object-elf.c| 130 +--
libiberty/simple-object.c| 32
5 files changed, 187 insertions(+), 7 deletions(-)
diff --git a/gcc/lto-object.cc b/gcc/lto-object.cc
index cb1c3a6cfb3..680977cb327 100644
--- a/gcc/lto-object.cc
+++ b/gcc/lto-object.cc
@@ -187,7 +187,9 @@ lto_obj_file_close (lto_file *file)
int err;
gcc_assert (lo->base.offset == 0);
-
+ /*Add __gnu_lto_slim symbol*/
+ if(flag_bypass_asm)
+simple_object_write_add_symbol (lo->sobj_w, "__gnu_lto_slim",1,1);
errmsg = simple_object_write_to_file (lo->sobj_w, lo->fd, &err);
if (errmsg != NULL)
{
diff --git a/include/simple-object.h b/include/simple-object.h
index 01f8a26f979..3a14184b12c 100644
--- a/include/simple-object.h
+++ b/include/simple-object.h
@@ -156,6 +156,11 @@ simple_object_start_write (simple_object_attributes
*attrs,
typedef struct simple_object_write_section_struct
simple_object_write_section;
+/* The type simple_object_symbol is a handle for a symbol
+ which is being written. */
+
+typedef struct simple_object_symbol_struct simple_object_symbol;
+
/* Add a section to SIMPLE_OBJECT. NAME is the name of the new
section. ALIGN is the required alignment expressed as the number
of required low-order 0 bits (e.g., 2 for alignment to a 32-bit
@@ -190,6 +195,11 @@ simple_object_write_add_data (simple_object_write
*simple_object,
extern const char *
simple_object_write_to_file (simple_object_write *simple_object,
int descriptor, int *err);
+/*Add a symbol to sobj struct which will be written to common in simple_
+object_write_to_file function*/
+extern void
+simple_object_write_add_symbol(simple_object_write *sobj, const char *name,
+size_t size, unsigned int align);
/* Release all resources associated with SIMPLE_OBJECT, including any
simple_object_write_section's that may have been created. */
diff --git a/libiberty/simple-object-common.h
b/libiberty/simple-object-common.h
index b9d10550d88..df99c9d85ac 100644
--- a/libiberty/simple-object-common.h
+++ b/libiberty/simple-object-common.h
@@ -58,6 +58,24 @@ struct simple_object_write_struct
simple_object_write_section *last_section;
/* Private data for the object file format. */
void *data;
+ /*The start of the list of symbols.*/
+ simple_object_symbol *symbols;
+ /*The last entry in the list of symbols*/
+ simple_object_symbol *last_symbol;
+};
+
+/*A symbol in object file being created*/
+struct simple_object_symbol_struct
+{
+ /*Next in the list of symbols attached to an
+ simple_object_write*/
+ simple_object_symbol *next;
+ /*The name of this symbol. */
+ char *name;
+ /* Symbol value */
+ unsigned int align;
+ /* Symbol size */
+ size_t size;
};
/* A section in an object file being created. */
diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
index eee07039984..cbba88186bd 100644
--- a/libiberty/simple-object-elf.c
+++ b/libiberty/simple-object-elf.c
@@ -787,9 +787,9 @@ simple_object_elf_write_ehdr (simple_object_write
*sobj, int descriptor,
++shnum;
if (shnum > 0)
{
- /* Add a section header for the dummy section and one for
- .shstrtab. */
- shnum += 2;
+ /* Add a section header for the dummy section,
+ .shstrtab, .symtab and .strtab. */
+ shnum += 4;
}
ehdr_size = (cl == ELFCLASS32
@@ -882,6 +882,51 @@ simple_object_elf_write_shdr (simple_object_write
*sobj, int descriptor,
errmsg, err);
}
+/* Write out an ELF Symbol*/
+
+static int
+simple_object_elf_write_symbol(simple_object_write *sobj, int descriptor,
+off_t offset, unsi
Re: gcc tricore porting
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 Michael Matz ha scritto: > 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 products. GCC doesn't compile on that platform. I left my work > some > > > days ago and so I'll have some spare time in the next few months. I > would > > > like to know how difficult it is to port the tricore platform on gcc > and if > > > during this process somebody can support me as tutor and... also if > the gcc > > > team is interested in this item... > > > > We welcome ports to new architectures. Quick googling doesn't find me > > something like an ISA specification though so it's difficult to assess > the > > complexity of porting to that architecture. > > https://en.wikipedia.org/wiki/Infineon_TriCore > > https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111 > > CPU part looks like fairly regular 32bit RISC. DSP part seems quite > normal as well. There even was once a GCC port to Tricore, version 3.3 > from HighTec (now part of Infineon itself), but not even the wayback > machine has the files for that anymore: > > > https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html > > Given the age of that port it's probably better to start from scratch > anyway :) (the current stuff from them/Infineon doesn't seem to be > GCC-based anymore?) > > > Ciao, > Michael. -- Claudio Eterno via colle dell'Assietta 17 10036 Settimo Torinese (TO)
Re: gcc tricore porting
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 products. GCC doesn't compile on that platform. I left my work some > > days ago and so I'll have some spare time in the next few months. I would > > like to know how difficult it is to port the tricore platform on gcc and if > > during this process somebody can support me as tutor and... also if the gcc > > team is interested in this item... > > We welcome ports to new architectures. Quick googling doesn't find me > something like an ISA specification though so it's difficult to assess the > complexity of porting to that architecture. https://en.wikipedia.org/wiki/Infineon_TriCore https://www.infineon.com/dgdl/TC1_3_ArchOverview_1.pdf?fileId=db3a304312bae05f0112be86204c0111 CPU part looks like fairly regular 32bit RISC. DSP part seems quite normal as well. There even was once a GCC port to Tricore, version 3.3 from HighTec (now part of Infineon itself), but not even the wayback machine has the files for that anymore: https://web.archive.org/web/20150205040416/http://www.hightec-rt.com:80/en/downloads/sources.html Given the age of that port it's probably better to start from scratch anyway :) (the current stuff from them/Infineon doesn't seem to be GCC-based anymore?) Ciao, Michael.
Re: gcc tricore porting
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 and so I'll have some spare time in the next few months. I would > like to know how difficult it is to port the tricore platform on gcc and if > during this process somebody can support me as tutor and... also if the gcc > team is interested in this item... We welcome ports to new architectures. Quick googling doesn't find me something like an ISA specification though so it's difficult to assess the complexity of porting to that architecture. If you know other embedded archs and can identify one with similar features and restrictions the easiest is to look at an existing port to such similar architecture. Richard. > Claudio > -- > Claudio Eterno > via colle dell'Assietta 17 > 10036 Settimo Torinese (TO)
