| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
We currently list P2115R0 as implemented, but only the modules changes
had been done. This patch implements the linkage changes so that
unnamed unscoped enums will use the name of the first enumerator for
linkage purposes.
This is (strictly speaking) a breaking change, as code that previously
relied on unnamed enumerations being internal linkage may have overloads
using those types become exposed and clash with other functions in a
different TU that have been similarly exposed. As such this feature is
only implemented for C++20.
No ABI flag warning is provided, partly because C++20 is still an
experimental standard, but also because any affected functions could not
have been part of an ABI until this change anyway.
A number of testcases that are testing for behaviour of no-linkage types
are adjusted to use an enumeration with no values, so that the pre-C++20
and post-C++20 behaviour is equivalently tested.
In terms of implementation, I had originally considered adjusting the
DECL_NAME of the enum, as with 'name_unnamed_type', but this ended up
being more complicated as it had unwanted interactions with the existing
modules streaming and with name lookup and diagnostic messages. This
patch instead uses a new function to derive this case.
The standard says that ([dcl.enum] p11) such an enum "...is denoted, for
linkage purposes, by its underlying type and its first enumerator", so
we need to add a new mangling production as well to handle this.
PR c++/120503
PR c++/120824
gcc/cp/ChangeLog:
* cp-tree.h (TYPE_UNNAMED_P): Adjust for enums with enumerators
for linkage purposes.
(enum_with_enumerator_for_linkage_p): Declare.
* decl.cc (name_unnamed_type): Adjust assertions to handle enums
with enumerators for linkage purposes.
(grokdeclarator): Use a typedef name for enums with enumerators
for linkage purposes.
(enum_with_enumerator_for_linkage_p): New function.
(finish_enum_value_list): Reset type linkage for enums with
enumerators for linkage purposes.
* mangle.cc (write_unnamed_enum_name): New function.
(write_unqualified_name): Handle enums with enumerators for
linkage purposes.
* tree.cc (decl_linkage): Fixup unnamed enums.
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle32.C: Remove enumerator list.
* g++.dg/cpp0x/linkage2.C: Likewise.
* g++.dg/ext/vector26.C: Likewise.
* g++.dg/other/anon3.C: Likewise.
* g++.dg/abi/mangle83.C: New test.
* g++.dg/modules/enum-15_a.C: New test.
* g++.dg/modules/enum-15_b.C: New test.
include/ChangeLog:
* demangle.h (enum demangle_component_type): Add enumeration
DEMANGLE_COMPONENT_UNNAMED_ENUM.
libiberty/ChangeLog:
* cp-demangle.c (d_unnamed_enum): New function.
(d_unqualified_name): Call it.
(cplus_demangle_type): Handle unscoped unnamed types
(Ue, Ul, etc.)
(d_count_templates_scopes): Handle unnamed enums.
(d_find_pack): Likewise.
(d_print_comp_inner): Print unnamed enums.
* testsuite/demangle-expected: Add tests.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
This patch fixes a comment typo, whaever -> whatever, prompted by the
recent hae -> has typo fix.
2025-08-13 Jakub Jelinek <jakub@redhat.com>
* cp-demangle.c (d_encoding): Fix a comment typo, whaever -> whatever.
|
|
|
|
When the doubly-linked list tests were introduced, the tests were
printing the content of the list forward and backward. However, this
printing is not needed outside of debugging, and confuses people because
the output is not only composed of PASS: lines.
This patch disables the printing of the list content by default. If
one wants to re-enable it for debugging, he can set the macro DUMP_LIST
to 1.
libiberty/ChangeLog:
* testsuite/test-doubly-linked-list.c: disable debug logging on
stdout.
|
|
|
|
Those methods's implementation is relying on duck-typing at compile
time.
The structure corresponding to the node of a doubly linked list needs
to define attributes 'prev' and 'next' which are pointers on the type
of a node.
The structure wrapping the nodes and others metadata (first, last, size)
needs to define pointers 'first', and 'last' of the node's type, and
an integer type for 'size'.
Mutative methods can be bundled together and be declarable once via a
same macro, or can be declared separately. The merge sort is bundled
separately.
There are 3 types of macros:
1. for the declaration of prototypes: to use in a header file for a
public declaration, or as a forward declaration in the source file
for private declaration.
2. for the declaration of the implementation: to use always in a
source file.
3. for the invocation of the functions.
The methods can be declared either public or private via the second
argument of the declaration macros.
List of currently implemented methods:
- LINKED_LIST_*:
- APPEND: insert a node at the end of the list.
- PREPEND: insert a node at the beginning of the list.
- INSERT_BEFORE: insert a node before the given node.
- POP_FRONT: remove the first node of the list.
- POP_BACK: remove the last node of the list.
- REMOVE: remove the given node from the list.
- SWAP: swap the two given nodes in the list.
- LINKED_LIST_MERGE_SORT: a merge sort implementation.
include/ChangeLog:
* doubly-linked-list.h: New file.
libiberty/ChangeLog:
* Makefile.in: Add new header.
* testsuite/Makefile.in: Add new test.
* testsuite/test-doubly-linked-list.c: New test.
|
|
|
|
Fixes this error during build of fixincludes:
In function ‘byte_regex_compile’,
inlined from ‘xregcomp’ at ../libiberty/../../libiberty/regex.c:7973:11:
../libiberty/../../libiberty/regex.c:3477:29: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
3477 | str[c1] = '\0';
| ^
../libiberty/../../libiberty/regex.c: In function ‘xregcomp’:
../libiberty/../../libiberty/regex.c:3454:35: note: at offset 128 into destination object ‘str’ of size 128
3454 | unsigned char str[128]; /* Should be large enough. */
| ^
* regex.c (regex_compile): Don't write beyond array bounds when
collecting range expression.
|
|
|
|
This adds an implementation of memrchr to libiberty and arranges
to configure gcc to use it, if the host does not have it.
PR cobol/119283
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for host memrchr.
include/ChangeLog:
* libiberty.h (memrchr): New.
libiberty/ChangeLog:
* Makefile.in: Add memrchr build rules.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for memrchr.
* functions.texi: Document memrchr.
* memrchr.c: New file.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
|
|
Darwin and Solaris, at least, provide basename() in libc, but only
declare it in <libgen.h>. That library is not one of the set in
AC_INCLUDES_DEFAULT and so we fail the config test and fall back
to the libiberty-provided version. In itself, this is not an
issue; however, if we include <libgen.h> and libiberty.h in the same
TU we do then get a decl conflict.
PR other/119218
libiberty/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Append <libgen.h> to AC_INCLUDES_DEFAULT
when checking for the 'basename' decl.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
|
|
This patch adds a function ldirname to libiberty. It is implemented
in terms of lbasename. Basically, given a given pathname, the dirname
part is what is not the basename minus the last directory separator
separating the dirname with the basename.
include/ChangeLog
* libiberty.h (ldirname): New function declaration.
(dos_ldirname): Likewise.
(unix_ldirname): Likewise.
libiberty/ChangeLog
* ldirname.c: New file.
* Makefile.in (CFILES): Add ldirname.c.
(REQUIRED_OFILES): Add ldirname.$(objext).
(./ldirname.$(objext)): New rule.
* makefile.vms (OBJS): Add ldirname.obj.
* configure.com (FILES): Add ldirname.
|
|
|
|
|
|
Autoreconf-2.72 warns about obsolete macros. This patch aims at removing
the noise from a future upgrade to autoreconf-2.72 or later. This is in
no a way a complete patch allowing the upgrade to autoreconf-2.72.
- AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/
autoconf.html#index-AC_005fGNU_005fSOURCE-1
- AC_CONFIG_HEADER by AC_CONFIG_HEADERS
https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-
Macros.html#index-AM_005fCONFIG_005fHEADER
Those fixes were originally submitted in a patch series in binutils.
https://inbox.sourceware.org/binutils/878qthm6a0.fsf@gentoo.org/
libiberty/ChangeLog:
* configure: Regenerate.
* configure.ac: Fix autoupdate warnings.
|
|
libiberty/getopt.c file is defining _NO_PROTO, which causes
conflicting declarations for the functions in AIX header files
like stdio.h & stdlib.h.
Looks like _NO_PROTO define were added long back and conflicting
declarations were always present until C23 standard uncovered it.
Remove the block defining _NO_PROTO as both Tru64 UNIX (ex-OSF/1)
and AIX 3.2 is no more supported.
libiberty/ChangeLog:
* getopt.c: Remove _NO_PROTO block
|
|
|
|
The patch reuses the configuration for LTO from ix86 and adds the
aarch64 architecture to the list of supported COFF headers.
gcc/ChangeLog:
* config/aarch64/cygming.h (TARGET_ASM_LTO_START): New.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/cygming.h (TARGET_ASM_LTO_START): Update.
(TARGET_ASM_LTO_END): Likewise.
* config/i386/i386-protos.h (i386_pe_asm_lto_start): Delete.
(i386_pe_asm_lto_end): Likewise.
* config/mingw/winnt.cc (i386_pe_asm_lto_start): Rename
into ...
(mingw_pe_asm_lto_start): ... this.
(i386_pe_asm_lto_end): Rename into ...
(mingw_pe_asm_lto_end): ... this.
* config/mingw/winnt.h (mingw_pe_asm_lto_start): New.
(mingw_pe_asm_lto_end): Likewise.
libiberty/ChangeLog:
* simple-object-coff.c: Add aarch64.
|
|
|
|
Some of the function definitions used K&R style definitions (but not all).
This just moves them all to be ANSI C
Bootstrapped and tested on x86_64-linux-gnu.
libiberty/ChangeLog:
* testsuite/test-demangle.c (get_line): Change K&R style
definition into ANSI C90 definitions.
(fail): Likewise.
(main): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
|
|
These comment typos were found in the valgrind fork of libiberty
demangle code.
libiberty/ChangeLog:
* cplus-dem.c: Change preceeded to preceded.
include/ChangeLog:
* safe-ctype.h: Change accidently to accidentally.
|
|
|
|
cp-demangle.c does not build when CP_DEMANGLE_DEBUG is defined since
r13-2887-gb04208895fed34. This trivial patch fixes the issue.
libiberty/ChangeLog:
* cp-demangle.c (d_dump): Fix compilation when CP_DEMANGLE_DEBUG
is defined.
|
|
|
|
simple_object_elf_copy_lto_debug_section [PR116614]
cat abc.C
#define A(n) struct T##n {} t##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
E(1) E(2) E(3)
int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
The following patch fixes that. Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.
Yet, the fix isn't solely about removing the
if (new_i - 1 >= SHN_LORESERVE)
{
*err = ENOTSUP;
return "Too many copied sections";
}
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit. But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.
So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.
2024-09-07 Jakub Jelinek <jakub@redhat.com>
PR lto/116614
* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
comments.
(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
consistency.
(simple_object_elf_find_sections): Formatting fixes.
(simple_object_elf_fetch_attributes): Likewise.
(simple_object_elf_attributes_merge): Likewise.
(simple_object_elf_start_write): Likewise.
(simple_object_elf_write_ehdr): Likewise.
(simple_object_elf_write_shdr): Likewise.
(simple_object_elf_write_to_file): Likewise.
(simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for
new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
over .symtab_shndx sections, though emit those last and compute their
section content when processing associated .symtab sections. Handle
simple_object_internal_read failure even in the .symtab_shndx reading
case.
|
|
|
|
After the commit:
commit 5e1d530da87a6d2aa7e719744cb278e7e54a6623 (gcc-buildargv)
Date: Sat Feb 10 11:22:13 2024 +0000
libiberty/buildargv: handle input consisting of only white space
The function only_whitespace (in argv.c) was no longer being called.
Lets delete it.
There should be no user visible changes after this commit.
2024-07-29 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (only_whitespace): Delete.
|
|
|
|
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty function buildargv, when
the input is a string consisting only of white space.
What I observe is that if the input to buildargv is a string
containing only white space, then buildargv will return an argv list
containing a single empty argument, e.g.:
char **argv = buildargv (" ");
assert (*argv[0] == '\0');
assert (argv[1] == NULL);
We get the same output from buildargv if the input is a single space,
or multiple spaces. Other white space characters give the same
results.
This doesn't seem right to me, and in fact, there appears to be a work
around for this issue in expandargv where we have this code:
/* If the file is empty or contains only whitespace, buildargv would
return a single empty argument. In this context we want no arguments,
instead. */
if (only_whitespace (buffer))
{
file_argv = (char **) xmalloc (sizeof (char *));
file_argv[0] = NULL;
}
else
/* Parse the string. */
file_argv = buildargv (buffer);
I think that the correct behaviour in this situation is to return an
empty argv array, e.g.:
char **argv = buildargv (" ");
assert (argv[0] == NULL);
And it turns out that this is a trivial change to buildargv. The diff
does look big, but this is because I've re-indented a block. Check
with 'git diff -b' to see the minimal changes. I've also removed the
work around from expandargv.
When testing this sort of thing I normally write the tests first, and
then fix the code. In this case test-expandargv.c has sort-of been
used as a mechanism for testing the buildargv function (expandargv
does call buildargv most of the time), however, for this particular
issue the work around in expandargv (mentioned above) masked the
buildargv bug.
I did consider adding a new test-buildargv.c file, however, this would
have basically been a copy & paste of test-expandargv.c (with some
minor changes to call buildargv). This would be fine now, but feels
like we would eventually end up with one file not being updated as
much as the other, and so test coverage would suffer.
Instead, I have added some explicit buildargv testing to the
test-expandargv.c file, this reuses the test input that is already
defined for expandargv.
Of course, once I removed the work around from expandargv then we now
do always call buildargv from expandargv, and so the bug I'm fixing
would impact both expandargv and buildargv, so maybe the new testing
is redundant? I tend to think more testing is always better, so I've
left it in for now.
2024-07-16 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (buildargv): Treat input of only whitespace as an empty
argument list.
(expandargv): Remove work around for intput that is only
whitespace.
* testsuite/test-expandargv.c: Add new tests 10, 11, and 12.
Extend testing to call buildargv in more cases.
|
|
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour to the libiberty
function buildargv, and how it handles backslash escapes.
For reference, I've been mostly reading:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
The issues that I would like to fix are:
1. Backslashes within single quotes should not be treated as an
escape, thus: '\a' should split to \a, retaining the backslash.
2. Backslashes within double quotes should only act as an escape if
they are immediately before one of the characters $ (dollar),
` (backtick), " (double quote), ` (backslash), or \n (newline). In
all other cases a backslash should not be treated as an escape
character. Thus: "\a" should split to \a, but "\$" should split to
$.
3. A backslash-newline sequence should be treated as a line
continuation, both the backslash and the newline should be removed.
I've updated libiberty and also added some tests. All the existing
libiberty tests continue to pass, but I'm not sure if there is more
testing that should be done, buildargv is used within lto-wraper.cc,
so maybe there's some testing folk can suggest that I run?
2024-07-16 Andrew Burgess <aburgess@redhat.com>
libiberty/
* argv.c (buildargv): Backslashes within single quotes are
literal, backslashes only escape POSIX defined special characters
within double quotes, and backslashed newlines should act as line
continuations.
* testsuite/test-expandargv.c: Add new tests 7, 8, and 9.
|
|
|
|
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"auto" cases in this code are Ada (where the
encoded form could more easily be confused by ordinary programs) and
Java (which is long gone, but which also shared the C++ mangling and
thus was just an output style preference).
This patch also fixed another GDB bug, though of course that part
won't apply to the GCC repository.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276
libiberty
* cplus-dem.c (cplus_demangle): Try the D demangler with
"auto" format.
* testsuite/d-demangle-expected: Add --format=auto test.
|
|
Like in r12-7519-g027e30414492d50feb2854aff38227b14300dc4b, I've done
git grep -v 'long long\|optab optab\|template template\|double double' | grep ' \([a-zA-Z]\+\) \1 '
This is just part of the changes, mostly for non-gcc directories.
I'll try to get to the rest soon. Obviously, the above command also
finds cases which are correct as is and shouldn't be changed, so one
needs to manually inspect everything.
I'd hope most of it is pretty obvious, but the config/ and libstdc++-v3/
hunks include a tweak in a license wording, though other copies of the
similar license have the wording right.
2024-04-02 Jakub Jelinek <jakub@redhat.com>
* Makefile.tpl: Fix duplicated words; returns returns ->
returns.
config/
* lcmessage.m4: Fix duplicated words; can can -> can,
package package -> package.
libdecnumber/
* decCommon.c (decFinalize): Fix duplicated words in
comment; the the -> the.
libgcc/
* unwind-dw2-fde.c (struct fde_accumulator): Fix duplicated
words in comment; is is -> is.
libgfortran/
* configure.host: Fix duplicated words; the the -> the.
libgm2/
* configure.host: Fix duplicated words; the the -> the.
libgomp/
* libgomp.texi (OpenMP 5.2): Fix duplicated words; with with ->
with.
(omp_target_associate_ptr): Fix duplicated words; either either ->
either.
(omp_init_allocator): Fix duplicated words; be be -> be.
(omp_realloc): Fix duplicated words; is is -> is.
(OMP_ALLOCATOR): Fix duplicated words; other other -> other.
* priority_queue.h (priority_queue_multi_p): Fix duplicated words;
to to -> to.
libiberty/
* regex.c (byte_re_match_2_internal): Fix duplicated words in comment;
next next -> next.
* dyn-string.c (dyn_string_init): Fix duplicated words in comment;
of of -> of.
libitm/
* beginend.cc (GTM::gtm_thread::begin_transaction): Fix duplicated
words in comment; not not -> not to.
libobjc/
* init.c (duplicate_classes): Fix duplicated words in comment; in in
-> in.
* sendmsg.c (__objc_prepare_dtable_for_class): Fix duplicated words
in comment; the the -> the.
* encoding.c (objc_layout_structure): Likewise.
libstdc++-v3/
* acinclude.m4: Fix duplicated words; file file -> file can.
* configure.host: Fix duplicated words; the the -> the.
libvtv/
* vtv_rts.cc (vtv_fail): Fix duplicated words; to to -> to.
* vtv_fail.cc (vtv_fail): Likewise.
|
|
|
|
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
and needs to be < 0 to signal an error. However, the unix flavour of
this routine is returning the PID value set from the posix_spawn{p}.
This latter value is undefined per the manual pages for both Darwin
and Linux, and it seems Darwin, at least, sets the value to some
usually positive number (presumably the PID that would have been used
if the fork had succeeded).
The fix proposed here is to set the pid = -1 in the relevant error
paths.
PR other/113957
libiberty/ChangeLog:
* pex-unix.c (pex_unix_exec_child): Set pid = -1 in the error
paths, since that is used to signal an erroneous outcome for
the routine.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
|
|
The following removes the TBAA violation present in iterative_hash.
As we eventually LTO that it's important to fix. This also improves
code generation for the >= 12 bytes loop by using | to compose the
4 byte words as at least GCC 7 and up can recognize that pattern
and perform a 4 byte load while the variant with a + is not
recognized (not on trunk either), I think we have an enhancement bug
for this somewhere.
Given we reliably merge and the bogus "optimized" path might be
only relevant for archs that cannot do misaligned loads efficiently
I've chosen to keep a specialization for aligned accesses.
libiberty/
* hashtab.c (iterative_hash): Remove TBAA violating handling
of aligned little-endian case in favor of just keeping the
aligned case special-cased. Use | for composing a larger word.
|
|
|
|
When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux. That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
}
subfields = create_field (subfields, t,
- xasprintf (".fld[%lu].%s",
- (unsigned long) aindex,
+ xasprintf (".fld["
+ HOST_SIZE_T_PRINT_UNSIGNED
+ "].%s",
+ (fmt_size_t) aindex,
subname));
subfields->opt = nodot;
if (t == note_union_tp)
hunk in gengtype.cc. While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.
So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64. And also %Lf etc. for long double.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
and L modifier for fFgGeE.
|
|
|
|
https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal
The following patch attempts to implement what apparently clang++
implemented for explicit object member function mangling, but nobody
actually proposed in patch form in
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
2024-01-13 Jakub Jelinek <jakub@redhat.com>
gcc/cp/
* mangle.cc (write_nested_name): Mangle explicit object
member functions with H as per
https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal.
gcc/testsuite/
* g++.dg/abi/mangle79.C: New test.
include/
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
libiberty/
* cp-demangle.c (FNQUAL_COMPONENT_CASE): Add case for
DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
(d_dump): Handle DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
(d_nested_name): Parse H after N in nested name.
(d_count_templates_scopes): Handle
DEMANGLE_COMPONENT_XOBJ_MEMBER_FUNCTION.
(d_print_mod): Likewise.
(d_print_function_type): Likewise.
* testsuite/demangle-expected: Add tests for explicit object
member functions.
|
|
|
|
|
|
Tobias reported on IRC that the linker fails to build with GCC 4.8.5.
In configure I've tried to use everything actually used in the sha1.c
x86 hw implementation, but unfortunately I forgot about implicit function
declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define
and __get_cpuid function defined inline, but it didn't define
__get_cpuid_count, which compiled fine (and the configure test is
intentionally compile time only) due to implicit function declaration,
but then failed to link when linking the linker, because
__get_cpuid_count wasn't defined anywhere.
The following patch fixes that by using what autoconf uses in AC_CHECK_DECL
to make sure the functions are declared.
2023-12-05 Jakub Jelinek <jakub@redhat.com>
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): Verify __get_cpuid and
__get_cpuid_count are not implicitly declared.
* configure: Regenerated.
|
|
The recent warning patches broke Solaris bootstrap:
/vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types]
326 | pex_unix_wait,
| ^~~~~~~~~~~~~
/vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait')
While pex_funcs.wait expects a function returning pid_t, pex_unix_wait
currently returns int. However, on Solaris pid_t is long for 32-bit,
but int for 64-bit.
This patches fixes this by having pex_unix_wait return pid_t as
expected, and like every other variant already does.
Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and
x86_64-apple-darwin23.1.0.
2023-12-03 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libiberty:
* pex-unix.c (pex_unix_wait): Change return type to pid_t.
|
