gnu glibc
Hi, I am a Linux development enthusiast who sent you an email last time. After compiling glibc, I used make install to display nss_ Test2 cannot link the specified installation path to/usr
Re: gnu glibc
On Tue, 10 Oct 2023, 08:00 h3140067568--- via Gcc, wrote: > Hi, I am a Linux development enthusiast who sent you an email last time. > After compiling glibc, I used make install to display nss_ Test2 cannot > link the specified installation path to/usr > GCC and Glibc are separate projects with their own mailing lists. You should use the Glibc mailing list. > >
Documenting common C/C++ options
Currently, -fsigned-char and -funsigned-char are only documented as C language options, although they work for C++ as well (and Objective-C and Objective-C++, I assume, but I have not tested this). There does not seem to be a place for this kind of options in the manual. The options -fshort-enums and -fshort-wchar are documented under code-generation options, but this seems to be a bit of a stretch because (at least for -fshort-wchar), these too seem to be more about front-end behavior. What would be a good way to address this? Thanks, Florian
Re: Documenting common C/C++ options
On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > Currently, -fsigned-char and -funsigned-char are only documented as C > language options, although they work for C++ as well (and Objective-C > and Objective-C++, I assume, but I have not tested this). There does > not seem to be a place for this kind of options in the manual. > > The options -fshort-enums and -fshort-wchar are documented under > code-generation options, but this seems to be a bit of a stretch because > (at least for -fshort-wchar), these too seem to be more about front-end > behavior. > > What would be a good way to address this? > > Thanks, > Florian > All of these are ABI; so where ever it goes, it should be documented that changing them will potentially cause issues with any pre-compiled object files having different settings. R.
Re: Documenting common C/C++ options
On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > On 10/10/2023 10:47, Florian Weimer via Gcc wrote: >> Currently, -fsigned-char and -funsigned-char are only documented as C >> language options, although they work for C++ as well (and Objective-C >> and Objective-C++, I assume, but I have not tested this). There does >> not seem to be a place for this kind of options in the manual. >> >> The options -fshort-enums and -fshort-wchar are documented under >> code-generation options, but this seems to be a bit of a stretch because >> (at least for -fshort-wchar), these too seem to be more about front-end >> behavior. >> >> What would be a good way to address this? >> >> Thanks, >> Florian >> > > > All of these are ABI; so where ever it goes, it should be documented that > changing them will potentially cause issues with any pre-compiled object > files having different settings. > > R. And you can add -f[un]signed-bitfield to that list as well. R.
Re: Documenting common C/C++ options
* Richard Earnshaw: > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: >>> Currently, -fsigned-char and -funsigned-char are only documented as C >>> language options, although they work for C++ as well (and Objective-C >>> and Objective-C++, I assume, but I have not tested this). There does >>> not seem to be a place for this kind of options in the manual. >>> >>> The options -fshort-enums and -fshort-wchar are documented under >>> code-generation options, but this seems to be a bit of a stretch because >>> (at least for -fshort-wchar), these too seem to be more about front-end >>> behavior. >>> >>> What would be a good way to address this? >>> >>> Thanks, >>> Florian >>> >> >> >> All of these are ABI; so where ever it goes, it should be documented >> that changing them will potentially cause issues with any >> pre-compiled object files having different settings. > And you can add -f[un]signed-bitfield to that list as well. There's already a section for those ABI options that are like -fshort-enums: @node Code Gen Options @section Options for Code Generation Conventions Maybe we should move them over there. But that wasn't really the direction of my question. I was wondering where we should document a future C version of -fpermissive. Thanks, Florian
Re: Documenting common C/C++ options
On Tue, Oct 10, 2023 at 1:13 PM Florian Weimer via Gcc wrote: > > * Richard Earnshaw: > > > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > >>> Currently, -fsigned-char and -funsigned-char are only documented as C > >>> language options, although they work for C++ as well (and Objective-C > >>> and Objective-C++, I assume, but I have not tested this). There does > >>> not seem to be a place for this kind of options in the manual. > >>> > >>> The options -fshort-enums and -fshort-wchar are documented under > >>> code-generation options, but this seems to be a bit of a stretch because > >>> (at least for -fshort-wchar), these too seem to be more about front-end > >>> behavior. > >>> > >>> What would be a good way to address this? > >>> > >>> Thanks, > >>> Florian > >>> > >> > >> > >> All of these are ABI; so where ever it goes, it should be documented > >> that changing them will potentially cause issues with any > >> pre-compiled object files having different settings. > > > And you can add -f[un]signed-bitfield to that list as well. > > There's already a section for those ABI options that are like > -fshort-enums: > > @node Code Gen Options > @section Options for Code Generation Conventions > > Maybe we should move them over there. > > But that wasn't really the direction of my question. I was wondering > where we should document a future C version of -fpermissive. Options common to the C family are documented in 'C Dialect Options' which says "The following options control the dialect of C (or languages derived from C, such as C++, Objective-C and Objective-C++) that the compiler accepts:" the options usually specify when they do not apply to all of the above sibling languages (where it's not obvious). Richard. > Thanks, > Florian >
C89 question: Do we need to accept -Wint-conversion warnings
Are these code fragments valid C89 code? int i1 = 1; char *p1 = i; char c; char *p2 = &c; int i2 = p2; Or can we generate errors for them even with -std=gnu89? (It will still be possible to override this with -fpermissive or -Wno-int-conversion.) Thanks, Florian
RFD: doloop needs better support for nested loops
I'm working on implementing hardware loops for the CORE-V CV32E40P
https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/corev_hw_loop.html
This core supports nested hardware lops, but does not allow any other flow
control inside hardware loops. I found that our existing interfaces do not
allow sufficient control over when to emit doloop patterns, i.e. allowing
nested doloops while rejecting other flow control inside the loop.
TARGET_CAN_USE_DOLOOP_P does not get passed anything to look at the
individual loop. Most convenient would be the loop structure, although
that would cause tight coupling of the target port with the internal data
structures of the loop optimizers.
OTOH we already have a precedent with TARGET_PREDICT_DOLOOP_P .
TARGET_INVALID_WITHIN_DOLOOP is missing context. We neither know the loop
nesting depth, nor if any jump instruction under consideration is the final
branch to jump back to the loop latch. Actually, the seccond part is the
main problem for the CV32E40P: inner doloops that have been transformed
can be recognized as such, but un-transformed condjumps could either be
spaghetti code inside the loop or the final jump instruction of the loop.
The doloop_end pattern is also missing context to make meaningful decisions.
Although we know the label where the pattern is supposed to jump to,
we don't know where the original branch is. Even if we scan the insn
stream, this is ambigous, since there can be two (or more) nested doloop
candidates.
What we could do here is add optional arguments; there is precedence, e.g.
for the call pattern. The advantage of this approach is that ports that
are fine with the current interface need not be patched.
To make it possible to scritinze the control flow of the loop, the branch
at the end of the loop makes a good optional argument.
There is also the issue that loop setup is a bit more costly for large loops,
and it would be nice to weigh that against the iteration count. We had
information about the iteration count at TARGET_CAN_USE_DOLOOP_P, but
nothing to allow us to analyze the loop body. Although the port could
stash avay the iteration count into a globalvariable or machine_function
member, it would be more straightforward and robust to pass the information
together so that it can be considered in context.
Attached is an patch for an optional 3rd parameter to doloop_end .
2023-10-05 Joern Rennecke
gcc/
* doc/md.texi (doloop_end): Document oprional operand 2.
* loop-doloop.cc (doloop_optimize): Provide 3rd operand to
gen_doloop_end.
* target-insns.def (doloop_end): Add optional 3rd operand.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index ee46d96bf62..ba42ac3d425 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -544,7 +544,7 @@ riscv*)
extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o
riscv-shorten-memrefs.o riscv-selftests.o riscv-string.o"
extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
- extra_objs="${extra_objs} thead.o"
+ extra_objs="${extra_objs} thead.o corev.o"
d_target_objs="riscv-d.o"
extra_headers="riscv_vector.h"
target_gtfiles="$target_gtfiles
\$(srcdir)/config/riscv/riscv-vector-builtins.cc"
diff --git a/gcc/loop-doloop.cc b/gcc/loop-doloop.cc
index 4feb0a25ab9..d703cb5f2af 100644
--- a/gcc/loop-doloop.cc
+++ b/gcc/loop-doloop.cc
@@ -720,7 +720,8 @@ doloop_optimize (class loop *loop)
count = copy_rtx (desc->niter_expr);
start_label = block_label (desc->in_edge->dest);
doloop_reg = gen_reg_rtx (mode);
- rtx_insn *doloop_seq = targetm.gen_doloop_end (doloop_reg, start_label);
+ rtx_insn *doloop_seq = targetm.gen_doloop_end (doloop_reg, start_label,
+BB_END (desc->in_edge->src));
word_mode_size = GET_MODE_PRECISION (word_mode);
word_mode_max = (HOST_WIDE_INT_1U << (word_mode_size - 1) << 1) - 1;
@@ -737,7 +738,8 @@ doloop_optimize (class loop *loop)
else
count = lowpart_subreg (word_mode, count, mode);
PUT_MODE (doloop_reg, word_mode);
- doloop_seq = targetm.gen_doloop_end (doloop_reg, start_label);
+ doloop_seq = targetm.gen_doloop_end (doloop_reg, start_label,
+ BB_END (desc->in_edge->src));
}
if (! doloop_seq)
{
diff --git a/gcc/target-insns.def b/gcc/target-insns.def
index c4415d00735..962c5cc51d1 100644
--- a/gcc/target-insns.def
+++ b/gcc/target-insns.def
@@ -48,7 +48,7 @@ DEF_TARGET_INSN (casesi, (rtx x0, rtx x1, rtx x2, rtx x3, rtx
x4))
DEF_TARGET_INSN (check_stack, (rtx x0))
DEF_TARGET_INSN (clear_cache, (rtx x0, rtx x1))
DEF_TARGET_INSN (doloop_begin, (rtx x0, rtx x1))
-DEF_TARGET_INSN (doloop_end, (rtx x0, rtx x1))
+DEF_TARGET_INSN (doloop_end, (rtx x0, rtx x1, rtx opt2))
DEF_TARGET_INSN (eh
Re: RFD: doloop needs better support for nested loops
On Tue, Oct 10, 2023 at 2:43 PM Joern Rennecke wrote: > > I'm working on implementing hardware loops for the CORE-V CV32E40P > https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/corev_hw_loop.html > > This core supports nested hardware lops, but does not allow any other flow > control inside hardware loops. I found that our existing interfaces do not > allow sufficient control over when to emit doloop patterns, i.e. allowing > nested doloops while rejecting other flow control inside the loop. > > TARGET_CAN_USE_DOLOOP_P does not get passed anything to look at the > individual loop. Most convenient would be the loop structure, although > that would cause tight coupling of the target port with the internal data > structures of the loop optimizers. I don't think this would really be an issue, the loop structure is really part of the CFG structure nowadays. > OTOH we already have a precedent with TARGET_PREDICT_DOLOOP_P . > > TARGET_INVALID_WITHIN_DOLOOP is missing context. We neither know the loop > nesting depth, nor if any jump instruction under consideration is the final > branch to jump back to the loop latch. Actually, the seccond part is the > main problem for the CV32E40P: inner doloops that have been transformed > can be recognized as such, but un-transformed condjumps could either be > spaghetti code inside the loop or the final jump instruction of the loop. > > The doloop_end pattern is also missing context to make meaningful decisions. > Although we know the label where the pattern is supposed to jump to, > we don't know where the original branch is. Even if we scan the insn > stream, this is ambigous, since there can be two (or more) nested doloop > candidates. > What we could do here is add optional arguments; there is precedence, e.g. > for the call pattern. The advantage of this approach is that ports that > are fine with the current interface need not be patched. > To make it possible to scritinze the control flow of the loop, the branch > at the end of the loop makes a good optional argument. > > There is also the issue that loop setup is a bit more costly for large loops, > and it would be nice to weigh that against the iteration count. We had > information about the iteration count at TARGET_CAN_USE_DOLOOP_P, but > nothing to allow us to analyze the loop body. Although the port could > stash avay the iteration count into a globalvariable or machine_function > member, it would be more straightforward and robust to pass the information > together so that it can be considered in context. > > Attached is an patch for an optional 3rd parameter to doloop_end .
Clarification regarding various classes DIE's attribute value class
Hello,
I am working on a project to produce the LTO object file from the compiler
directly. So far, we have
correctly outputted .symtab along with various .debug sections. The only
thing remaining is to
correctly output attribute values and their corresponding values in the
.debug_info section. This is done by the output_die function in
dwarf2out.cc based on the value's class. However, the same
function is used in dwarf2out_finish as well as dwarf2out_early_finish, so
I suspect that not every value class is being used in dwarfout_early_finish
(mainly I am interested in -flto mode). As there is little documentation on
the same, I experimented by commenting out the various cases of value class
in output die. I found that the classes such as dw_val_class_addr,
dw_val_class_high_pc, and dw_val_class_vms_delta aren't being used during
the early_finish of LTO mode. I might be wrong, as my observation is based
on commenting out and testing a few pieces of code that might need to be
completed. So, can anyone please tell out of these 30 classes that are
relevant to dwarf2out_early_finish in LTO mode or at least point out some
documentation if it exists?
enum dw_val_class
{
dw_val_class_none,
dw_val_class_addr,
dw_val_class_offset,
dw_val_class_loc,
dw_val_class_loc_list,
dw_val_class_range_list,
dw_val_class_const,
dw_val_class_unsigned_const,
dw_val_class_const_double,
dw_val_class_wide_int,
dw_val_class_vec,
dw_val_class_flag,
dw_val_class_die_ref,
dw_val_class_fde_ref,
dw_val_class_lbl_id,
dw_val_class_lineptr,
dw_val_class_str,
dw_val_class_macptr,
dw_val_class_loclistsptr,
dw_val_class_file,
dw_val_class_data8,
dw_val_class_decl_ref,
dw_val_class_vms_delta,
dw_val_class_high_pc,
dw_val_class_discr_value,
dw_val_class_discr_list,
dw_val_class_const_implicit,
dw_val_class_unsigned_const_implicit,
dw_val_class_file_implicit,
dw_val_class_view_list,
dw_val_class_symview
};
--
Rishi
Register allocation cost question
Hi all, I'm trying to add a new register set to the GCN port, but I've hit a problem I don't understand. There are 256 new registers (each 2048 bit vector register) but the register file has to be divided between all the running hardware threads; if you can use fewer registers you can get more parallelism, which means that it's important that they're allocated in order. The problem is that they're not allocated in order. Somehow the IRA pass is calculating different costs for the registers within the class. It seems to prefer registers a32, a96, a160, and a224. The internal regno are 448, 512, 576, 640. These are not random numbers! They all have zero for the 6 LSB. What could cause this? Did I overrun some magic limit? What target hook might I have miscoded? I'm also seeing wrong-code bugs when I allow more than 32 new registers, but that might be an unrelated problem. Or the allocation is broken? I'm still analyzing this. If it matters, ... the new registers can't be used for general purposes, so I'm trying to set them up as a temporary spill destination. This means they're typically not busy. It feels like it shouldn't be this hard... :( Thanks in advance. Andrew
Re: C89 question: Do we need to accept -Wint-conversion warnings
On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc wrote: > Are these code fragments valid C89 code? > > int i1 = 1; > char *p1 = i; > > char c; > char *p2 = &c; > int i2 = p2; > > Or can we generate errors for them even with -std=gnu89? > > (It will still be possible to override this with -fpermissive or > -Wno-int-conversion.) > Given that C89 code is unlikely to be actively maintained, I think we should be permissive by default in that mode. People compiling with an old -std flag are presumably doing it to keep old code compiling, and it seems appropriate to respect that. I'm also (though less strongly) inclined to be permissive in C99 mode, and only introduce the new strictness by default for C11/C17 modes. Jason
Re: Documenting common C/C++ options
On Tue, Oct 10, 2023 at 7:12 AM Florian Weimer via Gcc wrote: > * Richard Earnshaw: > > > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > >>> Currently, -fsigned-char and -funsigned-char are only documented as C > >>> language options, although they work for C++ as well (and Objective-C > >>> and Objective-C++, I assume, but I have not tested this). There does > >>> not seem to be a place for this kind of options in the manual. > >>> > >>> The options -fshort-enums and -fshort-wchar are documented under > >>> code-generation options, but this seems to be a bit of a stretch > because > >>> (at least for -fshort-wchar), these too seem to be more about front-end > >>> behavior. > >>> > >>> What would be a good way to address this? > >>> > >>> Thanks, > >>> Florian > >>> > >> > >> > >> All of these are ABI; so where ever it goes, it should be documented > >> that changing them will potentially cause issues with any > >> pre-compiled object files having different settings. > > > And you can add -f[un]signed-bitfield to that list as well. > > There's already a section for those ABI options that are like > -fshort-enums: > > @node Code Gen Options > @section Options for Code Generation Conventions > > Maybe we should move them over there. > > But that wasn't really the direction of my question. I was wondering > where we should document a future C version of -fpermissive. > My permerror patch proposes moving it to the Warning Options node, right after -pedantic-errors. Jason
Re: C89 question: Do we need to accept -Wint-conversion warnings
On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote: > On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc > wrote: > > > Are these code fragments valid C89 code? > > > > int i1 = 1; > > char *p1 = i; > > > > char c; > > char *p2 = &c; > > int i2 = p2; > > > > Or can we generate errors for them even with -std=gnu89? > > > > (It will still be possible to override this with -fpermissive or > > -Wno-int-conversion.) > > > > Given that C89 code is unlikely to be actively maintained, I think we > should be permissive by default in that mode. People compiling with an old > -std flag are presumably doing it to keep old code compiling, and it seems > appropriate to respect that. Yeah, complete agreement here. > I'm also (though less strongly) inclined to be permissive in C99 mode, and > only introduce the new strictness by default for C11/C17 modes. Especially when the default is -std=gnu17 that can be an option as well. There might be some code in the wild compiled with -std=gnu99 or -std=c99 just because it wanted to use C99 features back 15-20 years ago and hasn't been adjusted since then, but it might be better to adjust that if needed and keep using those flags only when they are needed because the code isn't C11/C17/C2X ready. Jakub
Re: C89 question: Do we need to accept -Wint-conversion warnings
On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote: > Are these code fragments valid C89 code? > > int i1 = 1; > char *p1 = i; > > char c; > char *p2 = &c; > int i2 = p2; Implicit conversions between pointers and integers are not valid C89. ANSI C89, as adopted as FIPS PUB 160, is available from NIST: https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf -- Joseph S. Myers jos...@codesourcery.com
Re: C89 question: Do we need to accept -Wint-conversion warnings
* Jakub Jelinek: > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote: >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc >> wrote: >> >> > Are these code fragments valid C89 code? >> > >> > int i1 = 1; >> > char *p1 = i; >> > >> > char c; >> > char *p2 = &c; >> > int i2 = p2; >> > >> > Or can we generate errors for them even with -std=gnu89? >> > >> > (It will still be possible to override this with -fpermissive or >> > -Wno-int-conversion.) >> > >> >> Given that C89 code is unlikely to be actively maintained, I think we >> should be permissive by default in that mode. People compiling with an old >> -std flag are presumably doing it to keep old code compiling, and it seems >> appropriate to respect that. > > Yeah, complete agreement here. Okay. It helps with the test suite conversation because -std=gnu89 -w is available today, so I can post such patches separately. >> I'm also (though less strongly) inclined to be permissive in C99 mode, and >> only introduce the new strictness by default for C11/C17 modes. > > Especially when the default is -std=gnu17 that can be an option as well. > > There might be some code in the wild compiled with -std=gnu99 or -std=c99 just > because it wanted to use C99 features back 15-20 years ago and hasn't been > adjusted since then, but it might be better to adjust that if needed and keep > using those flags only when they are needed because the code isn't C11/C17/C2X > ready. Linux currently uses -std=gnu99 deliberately in a few places, I believe. It would be a shame if we defaulted to permissive mode over there. I would certainly prefer to restrict permissive mode to the C89/C90 language levels. We can have this discussion once I post my patch (which depends on Jason's permerror enhancement in several ways). Thanks, Florian
Re: C89 question: Do we need to accept -Wint-conversion warnings
* Joseph Myers: > On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote: > >> Are these code fragments valid C89 code? >> >> int i1 = 1; >> char *p1 = i; >> >> char c; >> char *p2 = &c; >> int i2 = p2; > > Implicit conversions between pointers and integers are not valid C89. > > ANSI C89, as adopted as FIPS PUB 160, is available from NIST: > https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf Thank you, this is helpful information. Florian
Re: Documenting common C/C++ options
* Jason Merrill: >> But that wasn't really the direction of my question. I was wondering >> where we should document a future C version of -fpermissive. > > My permerror patch proposes moving it to the Warning Options node, > right after -pedantic-errors. Yes, that should work. I'm basing my patches based on it. Thanks, Florian
Function multiversioning ABI issues
Hi, I've been looking into existing function multiversioning implementations (while working to add support for fmv in GCC on aarch64). It seems there are various inconsistencies among current implementations, and it's unclear to me which (if any) of these differences could be problematic. There's a list of observations of current behaviour at the end of the email. I've also seen the GCC documentation for the ifunc attribute [1]. This states that "the indirect function needs to be defined in the same translation unit as the resolver function". This is not how function multiversioning is currently implemented. Instead, the resolver functions are added to the translation units of every caller. What is the reason for the restriction specified in the documentation? Does this mean that current function multiversioning implementations are subtly broken when used across different translation units? On a related point - how important is the mangling of the symbols involved (for the function implementations, the resolver, and the symbol that will be resolved at load time)? We're not consistent about how we mangle these on any target - even the explicit mangling requirements in the aarch64 Beta specification [2] apply only to the function implementations, and make no mention of how the other symbols should be mangled. It seems to me that things would have been much simpler if the resolver were always in the same translation unit as the implementations, and the symbol that is resolved at run time used the original function symbol name. This would allow the mangling of the function versions and the resolver function to be a hidden implementation detail, with no need to specify it as part of an explicit or implicit ABI. It would add an explicit restriction that all function implementations must be in the same translation unit, but it seems that might be required for absolute correctness anyway. So, how much of this stuff matters? Is some of this stuff actually broken? Will we have horrible compatibility issues if we try to fix some of it? Thanks, Andrew (cc'd to Daniel Kiss and Pavel Iliin, who have been working on the aarch64 function multiversioning specification and LLVM implementation respectively.) --- Current behaviour: For all combinations of the following, I checked to see whether the compiler would emit a resolver function: a) GCC / Clang b) aarch64 / rs6000 / i386 c) target_clones attribute / target (or target_version) attribute d) function is fully implemented / function is just declared e) function is referenced / function is unreferenced Function multiversioning is not supported for rs6000 (power) in Clang. For aarch64, I used my WIP implementation in GCC. If the function was referenced, then the compiler always emitted a resolver. However, when the function is declared but not implemented, then GCC for rs6000 would emit a resolver that always used the default version. If the function was not referenced, then the compiler usually did not emit a resolver. The exceptions to this were both in GCC, with resolvers being emitted both for rs6000 when using an implemented function with target_clones, and for aarch64 (with my WIP patch) when using an implementations with target_version. There are also many discrepancies in the mangling used in the various symbol names: For the symbol that will be resolved at load time, Clang always uses the original name and append ".ifunc". GCC leaves the symbol name unchanged when using target_clones, but adds a second layer of C++ mangling when using target attribute versions. For the resolver function, the symbol name is always generated by appending ".resolver" to the original mangled function name. For the individual versions, the following changes are made: - Clang for i386 numbers the versions when using target_clones (by appending ".0", ".1", etc.). GCC used to share this behaviour, but the numbering was removed for GCC 12 (commit bfc9250e). - GCC for i386, when using target_clones, will substitute any non-alphanumeric character with "_" when formign the suffix. E.g, an "sse4.2" version of foo has a symbol name of "_Z3foov.sse4.2" using target attributes, but "_Z3foov.sse4_2" using target_clones. - GCC for rs6000 has no target-defined mangling for versions using the "target" attribute, so the compiler output will fail to assemble due to duplicate symbol names. However, there seem to be no errors or warnings to detect this at an earlier stage. (Incidentally, is there any specific documentation for rs6000 function multiversioning? I was surprised to discover during testing that the resolver was ignoring some of my function clones, until I found the list of supported multiversioning targets in rs6000_clone_map.) --- [1] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute [2] https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning
Re: C89 question: Do we need to accept -Wint-conversion warnings
On Tue, Oct 10, 2023 at 12:09 PM Florian Weimer via Gcc wrote: > * Jakub Jelinek: > > > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote: > >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc > > >> wrote: > >> > >> > Are these code fragments valid C89 code? > >> > > >> > int i1 = 1; > >> > char *p1 = i; > >> > > >> > char c; > >> > char *p2 = &c; > >> > int i2 = p2; > >> > > >> > Or can we generate errors for them even with -std=gnu89? > >> > > >> > (It will still be possible to override this with -fpermissive or > >> > -Wno-int-conversion.) > >> > > >> > >> Given that C89 code is unlikely to be actively maintained, I think we > >> should be permissive by default in that mode. People compiling with an > old > >> -std flag are presumably doing it to keep old code compiling, and it > seems > >> appropriate to respect that. > > > > Yeah, complete agreement here. > > Okay. It helps with the test suite conversation because -std=gnu89 -w > is available today, so I can post such patches separately. > > >> I'm also (though less strongly) inclined to be permissive in C99 mode, > and > >> only introduce the new strictness by default for C11/C17 modes. > > > > Especially when the default is -std=gnu17 that can be an option as well. > > > > There might be some code in the wild compiled with -std=gnu99 or > -std=c99 just > > because it wanted to use C99 features back 15-20 years ago and hasn't > been > > adjusted since then, but it might be better to adjust that if needed and > keep > > using those flags only when they are needed because the code isn't > C11/C17/C2X > > ready. > > Linux currently uses -std=gnu99 deliberately in a few places, I believe. > It would be a shame if we defaulted to permissive mode over there. I > would certainly prefer to restrict permissive mode to the C89/C90 > language levels. We can have this discussion once I post my patch > (which depends on Jason's permerror enhancement in several ways). > C99 is what POSIX assumes up to the next version which should be nearing release. It moves the baseline to C11. Also from a safety critical system viewpoint, C99 (and C++03) was still widely used. In fact the FACE Technical Standard gave only those language versions for application conformance purposes. C++11 and C++14 were very recently added as options in a corrigenda that was released in August. I know this isn't the primary focus for GCC but embedded isn't rare. >From an RTEMS perspective, the OS is primarily built as C11 but that was primarily done for access to the atomics defined there not in C99. So it isn't that the code "isn't ready" for a new language version, it may be because there are standards still based on older versions or the safety review process may not accommodate a newer version. It also could be as simple as the RTOS vendor does not recommend using it with their OS which has been through something like a flight qualification. --joel > > Thanks, > Florian > >
Re: Register allocation cost question
Hi Andrew, On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote: > I'm also seeing wrong-code bugs when I allow more than 32 new registers, > but that might be an unrelated problem. Or the allocation is broken? I'm > still analyzing this. It could be connected. both things should not happen. > If it matters, ... the new registers can't be used for general purposes, What does this mean? I think you mean they *can* be used for anything, you just don't want to (maybe it is slow)? If you make it allocatable registers, they *will* be allocated for anythin the compilers deems a good idea. > so I'm trying to set them up as a temporary spill destination. This > means they're typically not busy. It feels like it shouldn't be this > hard... :( So what did you do, put them later in the allocation order? Make their register_move_cost higher than for normal registers (but still below memory_move_cost)? Or what? TARGEt_SPILL_CLASS maybe? Segher
Re: [PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode
On 08/10/2023 15:59, Iain Sandoe wrote:
Hi François,
On 23 Sep 2023, at 21:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem in
libstdc++ testsuite.
testsuite: Add optional libstdc++ version namespace in expected diagnostic
When libstdc++ is build with --enable-symvers=gnu-versioned-namespace
diagnostics are
showing this namespace, currently __8.
gcc/testsuite/ChangeLog:
* testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add
optional
'__8' version namespace in expected diagnostic.
* testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C:
Likewise.
* testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C:
Likewise.
*
testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: Likewise.
* testsuite/g++.dg/coroutines/pr97438.C: Likewise.
* testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise.
Tested under Linux x86_64.
I'm contributing to libstdc++ so I already have write access.
Ok to commit ?
As author of the tests, this LGTM as a suitable fix for now (at least, once the
main
patch to fix versioned namespaces lands).
I just realized it was a "go", no ? Then why after the main patch ?
The "main patch" do not fix the versioned namespace. It just makes it
adopt the cxx11 abi.
This patch fixes a problem that is as old as the tests and that is
totally unrelated with the main one. I just wanted to improve the
situation so that versioned namespace mode do not look more buggy than
necessary when someone (like you) run those.
However, IMO, this could become quite painful as more g++ tests make use of std
headers
(which is not really optional for facilities like this that are tightly-coupled
between the FE and
the library).
For the future, it does seem that a more complete solution might be to
introduce a
testsuite-wide definition for the C++ versioned std:: introducer, so that we
can update it in one
place as the version changes.
So (as a thought experiment):
- we’d have something of the form “CXX_STD” as a tcl global
- we’d add the presence/absence of versioning to the relevant site.exp (which
means recognising the versioning choice also in the GCC configure)
- we’d migrate tests to using ${CXX_STD} instead of "std::__N” in matches
… I guess an alternative could be to cook up some alternate warning/error/etc
match functions that cater for arbitrary inline namespaces but that seems
like a much
more tricky and invasive testsuite change.
thoughts?
I considered amending gcc/testsuite/lib/prune.exp to simply remove the
version from the diagnostic. But the reply on why it was not working
scared me, so this patch.
https://gcc.gnu.org/pipermail/gcc/2023-September/242526.html
Re: Register allocation cost question
On 2023/10/10 11:11 PM, Andrew Stubbs wrote: > Hi all, > > I'm trying to add a new register set to the GCN port, but I've hit a > problem I don't understand. > > There are 256 new registers (each 2048 bit vector register) but the > register file has to be divided between all the running hardware > threads; if you can use fewer registers you can get more parallelism, > which means that it's important that they're allocated in order. > > The problem is that they're not allocated in order. Somehow the IRA pass > is calculating different costs for the registers within the class. It > seems to prefer registers a32, a96, a160, and a224. > > The internal regno are 448, 512, 576, 640. These are not random numbers! > They all have zero for the 6 LSB. > > What could cause this? Did I overrun some magic limit? What target hook > might I have miscoded? > > I'm also seeing wrong-code bugs when I allow more than 32 new registers, > but that might be an unrelated problem. Or the allocation is broken? I'm > still analyzing this. > > If it matters, ... the new registers can't be used for general purposes, > so I'm trying to set them up as a temporary spill destination. This > means they're typically not busy. It feels like it shouldn't be this > hard... :( Have you tried experimenting with REG_ALLOC_ORDER? I see that the GCN port currently isn't using this target macro. Chung-Lin
