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 5e1d530da8 (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.
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.
Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
https://github.com/itanium-cxx-abi/cxx-abi/pull/166
We need to mangle constraints to be able to distinguish between function
templates that only differ in constraints. From the latter link, we want to
use the template parameter mangling previously specified for lambdas to also
make explicit the form of a template parameter where the argument is not a
"natural" fit for it, such as when the parameter is constrained or deduced.
I'm concerned about how the latter link changes the mangling for some C++98
and C++11 patterns, so I've limited template_parm_natural_p to avoid two
cases found by running the testsuite with -Wabi forced on:
template <class T, T V> T f() { return V; }
int main() { return f<int,42>(); }
template <int i> int max() { return i; }
template <int i, int j, int... rest> int max()
{
int sub = max<j, rest...>();
return i > sub ? i : sub;
}
int main() { return max<1,2,3>(); }
A third C++11 pattern is changed by this patch:
template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
template <typename> struct A { };
int main() { f<A,int>(); }
I aim to resolve these with the ABI committee before GCC 14.1.
We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
(mangling references to dependent template-ids where the name is fully
resolved) as references to concepts in std:: will consistently run into this
area. This is why mangle-concepts1.C only refers to concepts in the global
namespace so far.
The library changes are to avoid trying to mangle builtins, which fails.
Demangler support and test coverage is not complete yet.
gcc/cp/ChangeLog:
* cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New.
(get_concept_check_template): Declare.
* constraint.cc (combine_constraint_expressions)
(finish_shorthand_constraint): Use UNKNOWN_LOCATION.
* pt.cc (convert_generic_types_to_packs): Likewise.
* mangle.cc (write_constraint_expression)
(write_tparms_constraints, write_type_constraint)
(template_parm_natural_p, write_requirement)
(write_requires_expr): New.
(write_encoding): Mangle trailing requires-clause.
(write_name): Pass parms to write_template_args.
(write_template_param_decl): Factor out from...
(write_closure_template_head): ...here.
(write_template_args): Mangle non-natural parms
and requires-clause.
(write_expression): Handle REQUIRES_EXPR.
include/ChangeLog:
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_CONSTRAINTS.
libiberty/ChangeLog:
* cp-demangle.c (d_make_comp): Handle
DEMANGLE_COMPONENT_CONSTRAINTS.
(d_count_templates_scopes): Likewise.
(d_print_comp_inner): Likewise.
(d_maybe_constraints): New.
(d_encoding, d_template_args_1): Call it.
(d_parmlist): Handle 'Q'.
* testsuite/demangle-expected: Add some constraint tests.
libstdc++-v3/ChangeLog:
* include/std/bit: Avoid builtins in requires-clauses.
* include/std/variant: Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle10.C: Disable compat aliases.
* g++.dg/abi/mangle52.C: Specify ABI 18.
* g++.dg/cpp2a/class-deduction-alias3.C
* g++.dg/cpp2a/class-deduction-alias8.C:
Avoid builtins in requires-clauses.
* g++.dg/abi/mangle-concepts1.C: New test.
* g++.dg/abi/mangle-ttp1.C: New test.
This patch
commit bf4f40cc31
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Nov 28 13:14:05 2023 +0100
libiberty: Use x86 HW optimized sha1
broke Solaris/x86 bootstrap with the native as:
libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go
ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ]
gccgo: fatal error: Killed signal terminated program go1
As is already done in a couple of other similar cases, this patches
disables hwcaps support for libiberty.
Initially, this didn't work because config/hwcaps.m4 uses target_os, but
didn't ensure it is defined.
Tested on i386-pc-solaris2.11 with as and gas.
2023-11-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
config:
* hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require
AC_CANONICAL_TARGET.
libiberty:
* configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke.
* configure, aclocal.m4: Regenerate.
* Makefile.in (COMPILE.c): Add HWCAP_CFLAGS.
Nick has approved this patch (+ small ld change to use it for --build-id=),
so I'm commiting it to GCC as master as well.
If anyone from ARM would be willing to implement it similarly with
vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
speedup on those hosts as well, the intent in sha1.c was that
sha1_hw_process_bytes, sha1_hw_process_block functions
would be defined whenever
defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
but the body of sha1_hw_process_block and sha1_choose_process_bytes
would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
the other arch support, similarly for any target attributes on
sha1_hw_process_block if needed.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
include/
* sha1.h (sha1_process_bytes_fn): New typedef.
(sha1_choose_process_bytes): Declare.
libiberty/
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
and cpuid.h.
(sha1_hw_process_bytes, sha1_hw_process_block,
sha1_choose_process_bytes): New functions.
* config.in: Regenerated.
* configure: Regenerated.
There is a new buildbot check that all autotool files are generated
with the correct versions (automake 1.15.1 and autoconf 2.69).
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
Correct one file that was generated with the wrong version.
libiberty/
* aclocal.m4: Rebuild.
Hi,
This patch implements pex_unix_exec_child using posix_spawn when
available.
This should especially benefit recent macOS (where vfork just calls
fork), but should have equivalent or faster performance on all
platforms.
In addition, the implementation is substantially simpler than the
vfork+exec code path.
Tested on x86_64-linux.
v2: Fix error handling (previously the function would be run twice in
case of error), and don't use a macro that changes control flow.
v3: Match file style for error-handling blocks, don't close
in/out/errdes on error, and check close() for errors.
libiberty/
* configure.ac (AC_CHECK_HEADERS): Add spawn.h.
(checkfuncs): Add posix_spawn, posix_spawnp.
(AC_CHECK_FUNCS): Add posix_spawn, posix_spawnp.
* aclocal.m4, configure, config.in: Rebuild.
* pex-unix.c [HAVE_POSIX_SPAWN] (pex_unix_exec_child): New function.
r13-4035 avoided a problem with overloading of constrained hidden friends by
checking satisfaction, but checking satisfaction early is inconsistent with
the usual late checking and can lead to hard errors, so let's not do that
after all.
We were wrongly treating the different instantiations of the same friend
template as the same function because maybe_substitute_reqs_for was failing
to actually substitute in the case of a non-template friend. But we don't
actually need to do the substitution anyway, because [temp.friend] says that
such a friend can't be the same as any other declaration.
After fixing that, instead of a redefinition error we got an ambiguous
overload error, fixed by allowing constrained hidden friends to coexist
until overload resolution, at which point they probably won't be in the same
ADL overload set anyway.
And we avoid mangling collisions by following the proposed mangling for
these friends as a member function with an extra 'F' before the name. I
demangle this by just adding [friend] to the name of the function because
it's not feasible to reconstruct the actual scope of the function since the
mangling ABI doesn't distinguish between class and namespace scopes.
PR c++/109751
gcc/cp/ChangeLog:
* cp-tree.h (member_like_constrained_friend_p): Declare.
* decl.cc (member_like_constrained_friend_p): New.
(function_requirements_equivalent_p): Check it.
(duplicate_decls): Check it.
(grokfndecl): Check friend template constraints.
* mangle.cc (decl_mangling_context): Check it.
(write_unqualified_name): Check it.
* pt.cc (uses_outer_template_parms_in_constraints): Fix for friends.
(tsubst_friend_function): Don't check satisfaction.
include/ChangeLog:
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_FRIEND.
libiberty/ChangeLog:
* cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_FRIEND.
(d_count_templates_scopes): Likewise.
(d_print_comp_inner): Likewise.
(d_unqualified_name): Handle member-like friend mangling.
* testsuite/demangle-expected: Add test.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-friend11.C: Now works. Add template.
* g++.dg/cpp2a/concepts-friend15.C: New test.
As discussed previously, a.out support is now quite deprecated, and in
some cases removed, in both Binutils itself and NetBSD, so this legacy
default makes little sense. `netbsdelf*` and `netbsdaout*` still work
allowing the user to be explicit about there choice. Additionally, the
configure script warns about the change as Nick Clifton requested.
One possible concern was the status of NetBSD on NS32K, where only a.out
was supported. But per [1] NetBSD has removed support, and if it were to
come back, it would be with ELF. The binutils implementation is
therefore marked obsolete, per the instructions in the last message.
With that patch and this one applied, I have confirmed the following:
--target=i686-unknown-netbsd
--target=i686-unknown-netbsdelf
builds completely
--target=i686-unknown-netbsdaout
properly fails because target is deprecated.
--target=vax-unknown-netbsdaout builds completely except for gas, where
the target is deprecated.
[1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
config/ChangeLog:
* picflag.m4: Simplify SHmedia NetBSD match by presuming ELF.
gcc/ChangeLog:
* configure: Regenerate.
libada/ChangeLog:
* configure: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
AR from older binutils doesn't work with --plugin and rc:
[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
./ar: no operation specified
[hjl@gnu-cfl-2 bin]$ ./ar --version
GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
ChangeLog:
* configure: Regenerated.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with
--plugin and rc before enabling --plugin.
config/ChangeLog:
* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with
--plugin and rc before enabling --plugin.
gcc/ChangeLog:
* configure: Regenerate.
libatomic/ChangeLog:
* configure: Regenerate.
libbacktrace/ChangeLog:
* configure: Regenerate.
libcc1/ChangeLog:
* configure: Regenerate.
libffi/ChangeLog:
* configure: Regenerate.
libgfortran/ChangeLog:
* configure: Regenerate.
libgm2/ChangeLog:
* configure: Regenerate.
libgomp/ChangeLog:
* configure: Regenerate.
libiberty/ChangeLog:
* configure: Regenerate.
libitm/ChangeLog:
* configure: Regenerate.
libobjc/ChangeLog:
* configure: Regenerate.
libphobos/ChangeLog:
* configure: Regenerate.
libquadmath/ChangeLog:
* configure: Regenerate.
libsanitizer/ChangeLog:
* configure: Regenerate.
libssp/ChangeLog:
* configure: Regenerate.
libstdc++-v3/ChangeLog:
* configure: Regenerate.
libvtv/ChangeLog:
* configure: Regenerate.
lto-plugin/ChangeLog:
* configure: Regenerate.
zlib/ChangeLog:
* configure: Regenerate.
[ This is my third attempt to add this configure option. The first
version was approved but it came too late in the development cycle.
The second version was also approved, but I had to revert it:
<https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607082.html>.
I've fixed the problem (by moving $(PICFLAG) from INTERNAL_CFLAGS to
ALL_COMPILERFLAGS). Another change is that since r13-4536 I no longer
need to touch Makefile.def, so this patch is simplified. ]
This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE. This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.
It is similar to the option --enable-host-shared, except that --e-h-s
won't add -shared to the linker flags whereas --e-h-p will add -pie.
It is different from --enable-default-pie because that option just
adds an implicit -fPIE/-pie when the compiler is invoked, but the
compiler itself isn't PIE.
Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH
regressions.
When building the compiler, the build process may use various in-tree
libraries; these need to be built with -fPIE so that it's possible to
use them when building a PIE. For instance, when --with-included-gettext
is in effect, intl object files must be compiled with -fPIE. Similarly,
when building in-tree gmp, isl, mpfr and mpc, they must be compiled with
-fPIE.
With this patch and --enable-host-pie used to configure gcc:
$ file gcc/cc1{,plus,obj,gm2} gcc/f951 gcc/lto1 gcc/cpp gcc/go1 gcc/rust1 gcc/gnat1
gcc/cc1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=98e22cde129d304aa6f33e61b1c39e144aeb135e, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1plus: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=859d1ea37e43dfe50c18fd4e3dd9a34bb1db8f77, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1obj: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1964f8ecee6163182bc26134e2ac1f324816e434, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1gm2: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a396672c7ff913d21855829202e7b02ecf42ff4c, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/f951: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=59c523db893186547ac75c7a71f48be0a461c06b, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/lto1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=084a7b77df7be2d63c2d4c655b5bbc3fcdb6038d, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cpp: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3503bf8390d219a10d6653b8560aa21158132168, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/go1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=988cc673af4fba5dcb482f4b34957b99050a68c5, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/rust1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b6a5d3d514446c4dcdee0707f086ab9b274a8a3c, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/gnat1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb11ccdc2c366fe3fe0980476bcd8ca19b67f9dc, for GNU/Linux 3.2.0, with debug_info, not stripped
I plan to add an option to link with -Wl,-z,now.
Bootstrapped on x86_64-pc-linux-gnu with --with-included-gettext
--enable-host-pie as well as without --enable-host-pie. Also tested
on a Debian system where the system gcc was configured with
--enable-default-pie.
Co-Authored by: Iain Sandoe <iain@sandoe.co.uk>
ChangeLog:
* configure.ac (--enable-host-pie): New check. Set PICFLAG after this
check.
* configure: Regenerate.
c++tools/ChangeLog:
* Makefile.in: Rename PIEFLAG to PICFLAG. Set LD_PICFLAG. Use it.
Use pic/libiberty.a if PICFLAG is set.
* configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG.
(--enable-host-pie): New check.
* configure: Regenerate.
fixincludes/ChangeLog:
* Makefile.in: Set and use PICFLAG and LD_PICFLAG. Use the "pic"
build of libiberty if PICFLAG is set.
* configure.ac:
* configure: Regenerate.
gcc/ChangeLog:
* Makefile.in: Set LD_PICFLAG. Use it. Set enable_host_pie.
Remove NO_PIE_CFLAGS and NO_PIE_FLAG. Pass LD_PICFLAG to
ALL_LINKERFLAGS. Use the "pic" build of libiberty if --enable-host-pie.
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this
check.
* configure: Regenerate.
* doc/install.texi: Document --enable-host-pie.
gcc/ada/ChangeLog:
* gcc-interface/Make-lang.in (ALL_ADAFLAGS): Remove NO_PIE_CFLAGS. Add
PICFLAG. Use PICFLAG when building ada/b_gnat1.o and ada/b_gnatb.o.
* gcc-interface/Makefile.in: Use pic/libiberty.a if PICFLAG is set.
Remove NO_PIE_FLAG.
gcc/m2/ChangeLog:
* Make-lang.in: New var, GM2_PICFLAGS. Use it.
gcc/d/ChangeLog:
* Make-lang.in: Remove NO_PIE_CFLAGS.
intl/ChangeLog:
* Makefile.in: Use @PICFLAG@ in COMPILE as well.
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
* configure: Regenerate.
libcody/ChangeLog:
* Makefile.in: Pass LD_PICFLAG to LDFLAGS.
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this
check.
* configure: Regenerate.
libcpp/ChangeLog:
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
* configure: Regenerate.
libdecnumber/ChangeLog:
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
* configure: Regenerate.
libiberty/ChangeLog:
* configure.ac: Also set shared when enable_host_pie.
* configure: Regenerate.
zlib/ChangeLog:
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check. Set PICFLAG after this check.
* configure: Regenerate.
Instantiations of templated conversion operators failed to demangle
for cases such as 'operator X<int>', but worked for 'operator X<int>
&', due to thinking the template instantiation of X was the
instantiation of the conversion operator itself.
libiberty/
* cp-demangle.c (d_print_conversion): Remove incorrect
template instantiation handling.
* testsuite/demangle-expected: Add testcases.
You are right, this is also a remnant of the old function design
that I completely missed. Here is the follow-up patch for that.
Thanks for pointing it out.
Costas
On Tue, 6 Jun 2023 at 04:12, Jeff Law <jeffreyalaw@gmail.com> wrote:
On 6/5/23 08:37, Costas Argyris via Gcc-patches wrote:
> writeargv can be simplified by getting rid of the error exit mode
> that was only relevant many years ago when the function used
> to open the file descriptor internally.
[ ... ]
Thanks. I've pushed this to the trunk.
You could (as a follow-up) simplify it even further. There's no need
for the status variable as far as I can tell. You could just have the
final return be "return 0;" instead of "return status;".
libiberty/
* argv.c (writeargv): Constant propagate "0" for "status",
simplifying the code slightly.
writeargv can be simplified by getting rid of the error exit mode
that was only relevant many years ago when the function used
to open the file descriptor internally.
0001-libiberty-writeargv-Simplify-function-error-mode.patch
From 1271552baee5561fa61652f4ca7673c9667e4f8f Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argyris@gmail.com>
Date: Mon, 5 Jun 2023 15:02:06 +0100
Subject: [PATCH] libiberty: writeargv: Simplify function error mode.
The goto-based error mode was based on a previous version
of the function where it was responsible for opening the
file, so it had to close it upon any exit:
https://inbox.sourceware.org/gcc-patches/20070417200340.GM9017@sparrowhawk.codesourcery.com/
(thanks pinskia)
This is no longer the case though since now the function
takes the file descriptor as input, so the exit mode on
error can be just a simple return 1 statement.
libiberty/
* argv.c (writeargv): Simplify & remove gotos.
Signed-off-by: Costas Argyris <costas.argyris@gmail.com>
pex-win32.c (win32_spawn): If the command line for CreateProcess
exceeds the 32k Windows limit, try to store it in a temporary
response file and call CreateProcess with @file instead (PR71850).
Signed-off-by: Costas Argyris <costas.argyris@gmail.com>
Signed-off-by: Jonathan Yong <10walls@gmail.com>
libiberty/ChangeLog:
* pex-win32.c (win32_spawn): Check command line length
and generate a response file if necessary.
(spawn_script): Adjust parameters.
(pex_win32_exec_child): Ditto.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
