Jakub Jelinek [Tue, 19 Apr 2022 16:27:41 +0000 (18:27 +0200)]
c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]
The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor. replace_placeholders should be
run on the whole TARGET_EXPR slot.
So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).
2022-04-19 Jakub Jelinek <jakub@redhat.com>
PR c++/105256
* typeck2.c (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.
That is, support for cris-linux-gnu was removed in gcc-11, but
install.texi wasn't adjusted accordingly. Also, unfortunately the
developer-related sites are gone with no replacements. And, CRIS is
used in other chip series as well, but allude rather than list.
The generated manpages, info, pdf and html were sanity-checked.
gcc:
* doc/install.texi <CRIS>: Remove references to removed websites and
adjust for cris-*-elf being the only remaining toolchain.
(cherry picked from commit d2a0a5d4ad23f1974c72ef8abaa55c1707c0b27f)
Iain Sandoe [Mon, 7 Feb 2022 15:36:35 +0000 (15:36 +0000)]
Darwin, rs6000: Amend lo_sum use for forced constants [PR104117].
Two issues resulted in this PR, which manifests when we force a constant into
memory in LRA (in PIC code on Darwin). The presence of such forced constants
is quite dependent on other RTL optimisations, and it is easy for the issue to
become latent for a specific case.
First, in the Darwin-specific rs6000 backend code, we were not being careful
enough in rejecting invalid symbolic addresses. Specifically, when generating
PIC code, we require a SYMBOL_REF to be wrapped in an UNSPEC_MACHOPIC_OFFSET.
We now split the Darwin high/low selectors into two:
1. One that handles non-PIC addresses (kernel mode, mdynamic-no-pic).
2. One that handles PIC addresses and rejects SYMBOL_REFs unless they are
suitably wrapped in the MACHOPIC_OFFSET unspec.
The second case is handled by providing a new predicate (macho_pic_address)
that checks the requirements.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Co-authored-by: Vladimir Makarov <vmakarov@redhat.com>
PR target/104117
gcc/ChangeLog:
* config/rs6000/rs6000.c (darwin_rs6000_legitimate_lo_sum_const_p):
Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when
emitting PIC code.
(legitimate_lo_sum_address_p): Likewise.
(rs6000_legitimize_address): Do not apply the TLS processing to
Darwin.
* config/rs6000/darwin.md (@machopic_high_<mode>): New.
(@machopic_low_<mode>): New.
* config/rs6000/predicates.md (macho_pic_address): New.
Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].
This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality. The patch replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.
* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it. This would trigger PR88590
hence the work-around for that.
* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s. Likewise main exes.
* We remove all the gcc-4.2.1 era stubs machinery and workarounds.
* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.
* The unwinder now always comes from the system
- for Darwin9 from /usr/lib/libgcc_s.1.dylib
- for Darwin10 from /usr/lib/libSystem.dylib
- for Darwin11+ from /usr/lib/system/libunwind.dylib.
We still insert a shim on Darwin10 to fix an omitted unwind function, but
the underlying unwinder remains the system one.
* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib on affected system versions (avoiding the need to find
the DSO path); (2) we add and export the emutls functions from DSOs - this
makes a relatively small (20k) addition to a DSO. These can be backed out
when a proper fix for PR88590 is committed.
For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
stubs).
The replacement libgcc_s.1 forwards the symbols from the new SO.
In order to support DYLD_LIBRARY_PATH on systems (where it works)
we forward the libSystem unwinder symbols from 10.7+ and a
compiler-local version of the libgcc unwinder on earlier.
For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses.
For 10.7+ the behaviour will now actually be correct.
* config.host: Add weak emutls crt to the extra_parts.
(*-*-darwin*): Add logic to build a shared unwinder library for
Darwin8-10. Add shim declaration header to powerpc*-darwin builds.
* config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove
workaround.
* config/libgcc-libsystem.ver: Add exclude list for the system-
provided unwinder.
* config/t-slibgcc-darwin: Bump SO version, remove stubs code.
Build a legacy libgcc_s.1 and the supporting pieces (all FAT libs).
* config/t-darwin-ehs: Add dependencies to the shared unwinder
objects. Add dependency on unwind.h.
* config/t-darwin: Reorganise the EH fragments to place them for
inclusion in a shared EH lib. Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/i386/t-darwin: Build legacy libgcc_s.1.
* config/rs6000/t-darwin: Likewise.
* config/rs6000/t-darwin-ehs: Remove dependency on the powerpc end
file. Add darwin-fallback.o.
libgcc, emutls: Allow building weak definitions of the emutls functions.
In order to better support use of the emulated TLS between objects with
DSO dependencies and static-linked libgcc, allow a target to make weak
definitions.
Iain Sandoe [Fri, 14 Jun 2019 18:14:30 +0000 (19:14 +0100)]
Darwin: Revise handling of some driver opts.
[Fixes a regression in driver output with empty comand lines, also a pre-
requisite for fixes in PR80556]
Darwin has a user convenience feature where some linker options are exposed
at the driver level (so one can type '-all_load' instead of '-Wl,-all_load'
or '-Xlinker -all_load'). We retain this feature, but now these options are
all marked as 'Driver' and we process them as early as possible so that they
get allocated to the right toolchain command. There are a couple of special
cases where these driver opts are used multiple times, or to control
operations on more than one command (e.g. dynamiclib). These are handled
specially and we then add %<xxxx specs for the commands that _do not_ need
them. NOTE: the ordering of 'shared' and 'dynamiclib' is significant, hence
they are placed out of alphabetical order at the start. Likewise, we keep
a couple of cases where a negative option originally appeared after the
positive alternate, potentially overriding it.
When we report an error with %e, it seems necessary to strip the option
before doing so, otherwise it survives to the cc1 command line (%e does not
appear to abort the program before this).
Right now there is no mechanism to split up the 'variable portion' (%*) of
the matched spec string, so where we have some driver specs that take 2 or
3 arguments, these cannot be processed here, but are deferred until the
LINK_SPEC, where they are copied verbatim.
We have a 'safe' version of the macOS version string, that has been sanity-
checked and truncated to minor version. If the 'tiny' (3rd) portion of the
value is not significant, it is better to use the safe one in version-compare().
We were not wrapping all the default libraries in checks for whether
they should be used. We were also wasting a process launch calling
dsymutil for 'r' link lines (a NOP in practice). Order the checks
that exclude linking from most likely to occur, downwards.
We were pushing a spec value for weak_reference_mismatches unconditionally
which is not needed (the value was the default) and the side-effect of
this was that we appeared to need to drive a link command; leading to
unexpected diagnostics for cases where gcc was invoked with an empty
command line.
Also we were pushing flags for sysroot, os minimum version and controls
even if the command line was empty.
* config/darwin-driver.c (darwin_driver_init): Revise comments, handle
filelist and framework options in specs instead of code. Exit from the
option handling early if the command line is definitely enpty.
* config/darwin.h (SUBTARGET_DRIVER_SELF_SPECS): Update to handle link
specs that are really driver ones. Remove setting for the default content
of weak_reference_mismatches
(DARWIN_CC1_SPEC): Likewise.
(CPP_SPEC): Likewise.
(SYSROOT_SPEC): Append space.
(LINK_SYSROOT_SPEC): Remove most driver link specs.
(STANDARD_STARTFILE_PREFIX_2): Update link-related specs.
(STARTFILE_SPEC): Likewise.
(ASM_MMACOSX_VERSION_MIN_SPEC): Fix line wrap.
(ASM_SPEC): Update driver-related specs.
(ASM_FINAL_SPEC): Likewise.
(LINK_COMMAND_SPEC_A): Update 'r' handling to skip gomp and itm when r
or nodefaultlibs is given.
(DSYMUTIL_SPEC): Do not call dsymutil for '-r' link lines.
Update ordering of exclusions, remove duplicate 'v' addition
(collect2 will add this from the main command line).
* config/darwin.opt: Remove now unused option aliases.
* config/i386/darwin.h (EXTRA_ASM_OPTS): Ensure space after opt.
(ASM_SPEC): Update driver-related specs.
Iain Sandoe [Fri, 19 Nov 2021 15:52:29 +0000 (15:52 +0000)]
libstdc++, testsuite: Add a prune expression for external tool bug.
Depending on the permutation of CPU, OS version and shared/non-
shared library inclusion, we get can get warnings from the external
tools (ld64, dsymutil) which are not actually libstdc++ issues but
relate to the external tools themselves. This is already pruned
in the main testsuite, this adds it to the library.
Iain Sandoe [Fri, 12 Nov 2021 17:05:13 +0000 (17:05 +0000)]
configure, Darwin: Set appropriate defaults for host-shared.
Darwin x86_64 and aarch64 platforms are PIC (shared) by default,
and user-space code must be built in this mode. The patch
ensures that this is set correctly and applies a default when
--enable-host-shared is not set.
Iain Sandoe [Thu, 4 Nov 2021 09:37:14 +0000 (09:37 +0000)]
IPA: Provide a mechanism to register static DTORs via cxa_atexit.
For at least one target (Darwin) the platform convention is to
register static destructors (i.e. __attribute__((destructor)))
with __cxa_atexit rather than placing them into a list that is
run by some other mechanism.
This patch provides a target hook that allows a target to opt
into this and handling for the process in ipa_cdtor_merge ().
When the mode is enabled (dtors_from_cxa_atexit is set) we:
* Generate new CTORs to register static destructors with
__cxa_atexit and add them to the existing list of CTORs;
we then process the revised CTORs list.
* We sort the DTORs into priority and then TU order, this
means that they are registered in that order with
__cxa_atexit () and therefore will be run in the reverse
order.
* Likewise, CTORs are sorted into priority and then TU order,
which means that they will run in that order.
This matches the behavior of using init/fini (or
mod_init_func/mod_term_func) sections.
This also fixes a bug where Fortran needs a DTOR to be run to
close IO.
* config/darwin.h (TARGET_DTORS_FROM_CXA_ATEXIT): New.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Add TARGET_DTORS_FROM_CXA_ATEXIT hook.
* ipa.c (cgraph_build_static_cdtor_1): Return the built
function decl.
(build_cxa_atexit_decl): New.
(build_dso_handle_decl): New.
(build_cxa_dtor_registrations): New.
(compare_cdtor_tu_order): New.
(build_cxa_atexit_fns): New.
(ipa_cdtor_merge): If dtors_from_cxa_atexit is set,
process the DTORs/CTORs accordingly.
(pass_ipa_cdtor_merge::gate): Also run if
dtors_from_cxa_atexit is set.
* target.def (dtors_from_cxa_atexit): New hook.
Darwin : Make trampoline templates linker-visible.
For aarch64, the alignment of the LTRAMPn symbols matters.
Actually, the LTRAMPn symbols _are_ 8 byte aligned, but because
they are Local, the linker doesn't know that this guarantee can be met.
It assumes that they are not necessarily more aligned than the
containing section (ld64 atoms strike again).
The fix is to publish the trampoline symbol for the linker to access
directly - it can then see that the atom is suitably aligned.
Iain Sandoe [Fri, 11 Dec 2020 00:29:42 +0000 (00:29 +0000)]
Darwin, PPC : Fix R13 for PPC64.
We have a somewhat unusual situation in that for PPC64, R13 is
both reserved and callee-saved (it is used internally by the
pthreads implementation to contain pthread_self).
So add R13 to the fixed regs, but also keep it in the callee-
saved set.
gcc/ChangeLog:
* config/rs6000/darwin.h (FIXED_R13): Add for PPC64.
(FIRST_SAVED_GP_REGNO): Save from R13 even when it is one
of the fixed regs.
Darwin, crts: Build Darwin10 unwinder shim as a library.
We have a small unwinder shim that is only used for Darwin10
(and only then in quite specific cases). To avoid linking
this code for every executable or DSO, we can present the crt
as a convenience library (rather than a .o file).
Iain Sandoe [Thu, 19 Aug 2021 12:01:14 +0000 (13:01 +0100)]
Jit, testsuite: Amend expect processing to tolerate more platforms.
The current 'fixed_host_execute' implementation fails on Darwin
platforms for a number of reasons:
1/ If the sub-process spawn fails (e.g. because of missing or mal-
formed params); rather than reporting the fail output into the
match stream, as indicated by the expect manual, it terminates
the script.
- We fix this by (a) checking that the executable is valid as well
as existing (b) we put the spawn into a catch block and report
a failure.
2/ There is no recovery path at all for a buffer-full case (and we
do see buffer-full events with the default sizes).
- Added by the patch here, however it is not as sophisticated as
the methods used by dejagnu internally. Here we set the process
to be "nowait" and then close the connection - with the intent
that this will terminate the spawned process.
3/ The expect logic assumes that 'Totals:' is a valid indicator
for the end of the spawned process output. This is not true
even for the default dejagnu header (there are a number of
additional reporting lines after). In addition to this, there
are some tests that intentionally produce more output after
the totals report (and there are tests that do not use that
mechanism at all).
The effect is the we might arrive at the "wait" for the spawned
process to finish - but that process might not have completed
all its output. For Darwin, at least that causes a deadlock
between expect and the spawnee - the latter is doing a non-
cancellable write and the former is waiting for the latter to
terminate. For some reason this does not seem to affect Linux
perhaps the pty implementation allows the write(s) are able to
proceed even though there is no reader.
- This is fixed by modifying the loop termination condition to be
either EOF (which will be the 'correct' condition) or a timeout
which would represent an error either in the runtime or in the
parsing of the output. As added precautions, we only try to
wait if there is a correcly-spawned process, and we are also
specific about which process we are waiting for.
4/ Darwin appears to have a bug in either the tcl or termios
'cooking' code that ocassionally inserts an additional CR char
into the stream - thus '\n' => '\r\r\n' instead of '\r\n'. The
original program output is correct (it only contains a single
\n) - the additional character is being inserted somewhere in
the translations applied before the output reaches expect.
The logic of this expect implementation does not tolerate single
\r or \n characters (it will fail with a timeout or buffer-full
if that occurs).
- This is fixed by having a line-end match that is adjusted for
Darwin.
5/ The default buffer size does seem to be too small in some cases
noting that GCC uses 10000 as the match buffer size and the
default is 2000.
- Fixed by increasing the size to 8192.
6/ There is a somewhat arbitrary dumping of output where we match
^$prefix\tSOMETHING... and then process the something. This
essentially allows the match to start at any place in the buffer
following any collection of non-line-end chars.
- Fixed by amending the match for 'general' lines to accommodate
these cases, and reporting such lines to the log. At least this
should allow debugging of any cases where output that should be
recognized is being dropped.
Iain Sandoe [Thu, 26 Aug 2021 11:52:29 +0000 (12:52 +0100)]
configure: Avoid unnecessary constraints on executables for $build.
The executables for GCC's c-family compilers must be built with no-PIE
because they use PCH and the current model for this requires that the
exe is always lauched at the same address. Since the other language
compilers share code with the c-family this constraint is also applied
to them.
However, the executables that run on $build (generators, and parsers
for md and def files) need not have any such constraint they do not
consume PCH files.
This change simplifies the configuration and Makefile content by
removing the code enforcing no-PIE on these exes. This also fixes a
bootstrap issue with some Darwin versions and clang as the bootstrap
compiler, where -no-PIE causes the correct relocation model to be
switched off leading to invalid user-space code.
* Makefile.in: Remove variables related to applying no-PIE
to the exes on $build.
* configure: Regenerate.
* configure.ac: Remove configuration related to applying
no-PIE to the exes on $build.
libgcc, soft-float: Fix strong_alias macro use for Darwin.
Darwin does not support strong symbol aliases and a work-
around is provided in sfp-machine.h where a second function
is created that simply calls the original. However this
needs the arguments to the synthesized function to track
the mode of the original function.
So the fix here is to match known floating point modes from
the incoming function and apply the one found to the new
function args.
The matching is highly specific to the current set of modes
and will need adjusting should more cases be added.
* config/i386/sfp-machine.h (alias_SFtype
alias_DFtype, alias_TFtype): New.
(ALIAS_SELECTOR): New.
(strong_alias): Use __typeof and a _Generic selector to
provide the type to the synthesized function.
Darwin provides an implementation of sbrk, which is detected by
the configuration process. However, it is deprecated which leads
to build warnings. The malloc-based implementation is more
suitable. This patch removes sbrk from the functions searched
for Darwin.
Iain Sandoe [Mon, 15 Mar 2021 21:40:40 +0000 (21:40 +0000)]
testsuite, Darwin : Skip a test requiring strndup in libc.
Before Darwin11 there is no strndup in libc. This test fails with
warning output because of that - so skip it on these versions (since
they are not able to use strndup anyway).
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/strndup-1.c: Skip for Darwin versions
without strndup support in libc.
Iain Sandoe [Sat, 29 Aug 2020 21:05:30 +0000 (22:05 +0100)]
Darwin : Mark the mod init/term section starts with a linker-visible sym.
Some newer assemblers emit section start temp symbols for mod init and term
sections if there is no suitable symbol present already.
The temp symbols are linker visible and therefore appear in the symbol tables.
Since the temp symbol number can vary when debug is enabled, that causes
compare-debug fails. The solution is to provide a stable linker-visible
symbol.
Iain Sandoe [Thu, 5 Aug 2021 09:07:03 +0000 (10:07 +0100)]
JIT, testsuite, Darwin: Initial testsuite fixes.
The testsuite setup for jit is not compatible with Darwin since it
assumes that all targets support --export-dynamic.
- this is fixed by adding '-rdynamic' conditionally upon target
support for that (-rdynamic will be converted to the appropriate
linker option).
There is also an assumption that a suitable version of dejagnu.h
is present in some default include search path that is usable from
the testsuite. This is not the case for Darwin (dejagnu.h is not
installed, and would not, in general, be found in any default include
search path if installed via one of the main 'distros'). Also the
upstream dejagnu.h has a definition of 'wait()' that clashes with a
libc routines and therefore causes fails in the testsuite.
- This patch imports the header from dejagnu-1.6.2 and
* renames it to 'jit-dejagnu.h'
* patches it to avoid unused variable warnings and the clash
with the libc definition of wait ()
* In accordance with the advice in the expect man page, ensures
that the final output of the 'totals' print is stable.
* docs/examples/tut04-toyvm/toyvm.c: Include jit-dejagnu.h.
* docs/examples/tut04-toyvm/toyvm.cc: Likewise.
* jit-dejagnu.h: New file, imported from dejagnu-1.6.2 and
patched for this application.
gcc/testsuite/ChangeLog:
* jit.dg/harness.h: Include jit-dejagnu.h.
* jit.dg/jit.exp: Use -rdynamic conditionally on target
support, instead of unconditional -Wl,--export-dynamic.
Iain Sandoe [Thu, 5 Aug 2021 08:55:19 +0000 (09:55 +0100)]
Darwin, jit: Fix build [PR100613].
The generic unix build is not completely suitable for Darwin
platforms:
* It is a convention to encode the library versioning in the
binary and to have only one level of symlink for the installed
files. This needs to be applied to the installation too.
* The library needs to be built with its correct install name
so that two-level library naming works.
* The extension for shared libraries should be .dylib
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR jit/100613 - libgccjit should produce dylib on macOS
libiberty, Darwin : Fix simple-object LTO table for cross-endian case.
We encapsulate streamed IR in three special sections with a table
that describes their entries. The table is expected to be written
with native endianness for the target, but for cross-endian cross-
compilation the swapping was omitted. Fixed thus.
Iain Sandoe [Fri, 13 Aug 2021 19:20:04 +0000 (20:20 +0100)]
Darwin: Reset section names table at the end of compile.
For a single use (typical compile) this vector will be reclaimed
as GGC. For JIT this is not sufficient since it does not reset
the pointer to NULL (and thus we think the the vector is already
allocated when a context is reused).
The clears the vector and sets the pointer to NULL at the end
of object output.
Darwin, libcc1: Handle hosts with mdynamic-no-pic support.
The default for building host-side binaries for mdynamic-no-pic
hosts is to enable this. However, it is not compatible with
dynamic libraries, so must be switched off for libcc1.
Iain Sandoe [Sun, 13 Dec 2020 17:21:16 +0000 (17:21 +0000)]
Darwin, configury : Allow for specification and detection of dsymutil.
In order to enable DWARF versions > 2 we need a sufficiently modern
version of dsymutil (in addition to the assembler / linker). This
allows the user to configure a different path from the installed one.
In addition, there are several sources of dsymutil so we differentiate
these in order to be get accurate version information.
* configure.ac: Handle --with-dsymutil in the same way as we
do for the assembler and linker. (DEFAULT_DSYMUTIL): New.
Extract the type and version for the dsymutil configured or
found by the default searches.
* config.in: Regenerated.
* configure: Regenerated.
* collect2.c (do_dsymutil): Handle locating dsymutil in the
same way as for the assembler and linker.
* config/darwin.h (DSYMUTIL): Delete.
* gcc.c: Report a configured dsymutil correctly.
* exec-tool.in: Allow for dsymutil.
* doc/install.texi: Document --with-dsymutil.
ChangeLog:
* Makefile.def: Add dsymutil defs.
* Makefile.in: Regenerated.
* Makefile.tpl: Add dsymutil to flags.
* configure: Regenerated.
* configure.ac: Add dsymutil to target and build recipes.
There were two uses for the Darwin host config fragment:
The first is to arrange for targets that support mdynamic-no-pic
to be built with that enabled (since it makes a significant
difference to the compiler performance). We can be more specific
in the application of this, since it only applies to 32b hosts
plus powerpc64-darwin9.
The second was to work around a tool bug where -fno-PIE was not
propagated to the link stage. This second use is redundant,
since the buggy toolchain cannot bootstrap current GCC sources
anyway.
This makes the host fragment more specific and reduces the number
of toolchains for which it is included which reduces clutter in
configure lines.
Jakub Jelinek [Tue, 12 Apr 2022 07:19:11 +0000 (09:19 +0200)]
i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214]
The following testcase ICEs, because ix86_emit_i387_log1p attempts to
emit something like
if (cond)
some_code1;
else
some_code2;
and emits a conditional jump using emit_jump_insn (standard way in
the file) and an unconditional jump using emit_jump.
The problem with that is that if there is pending stack adjustment,
it isn't emitted before the conditional jump, but is before the
unconditional jump and therefore stack is adjusted only conditionally
(at the end of some_code1 above), which makes dwarf2 pass unhappy about it
but is a serious wrong-code even if it doesn't ICE.
This can be fixed either by emitting pending stack adjust before the
conditional jump as the following patch does, or by not using
emit_jump (label2);
and instead hand inlining what that function does except for the
pending stack adjustment, like:
emit_jump_insn (targetm.gen_jump (label2));
emit_barrier ();
In that case there will be no stack adjustment in the sequence and
it will be done later on somewhere else.
Jakub Jelinek [Tue, 12 Apr 2022 07:16:06 +0000 (09:16 +0200)]
builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.
This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.
2022-04-11 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/105211
* builtins.c (expand_builtin_int_roundingfn_2): If mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.
Jakub Jelinek [Mon, 11 Apr 2022 08:41:07 +0000 (10:41 +0200)]
c-family: Initialize ridpointers for __int128 etc. [PR105186]
The following testcase ICEs with C++ and is incorrectly rejected with C.
The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD
and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP
directives etc., like:
/* Save away the identifier that indicates which attribute
this is. */
identifier = (token->type == CPP_KEYWORD)
/* For keywords, use the canonical spelling, not the
parsed identifier. */
? ridpointers[(int) token->keyword]
: id_token->u.value;
identifier = canonicalize_attr_name (identifier);
I've tried to change those to use ridpointers only if non-NULL and otherwise
use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks
patch.
The following patch instead just initializes ridpointers for the __intNN
keywords. It can't be done earlier before we record_builtin_type as there
are 2 different spellings and if we initialize those ridpointers early, the
second record_builtin_type fails miserably.
2022-04-11 Jakub Jelinek <jakub@redhat.com>
PR c++/105186
* c-common.c (c_common_nodes_and_builtins): After registering __int%d
and __int%d__ builtin types, initialize corresponding ridpointers
entry.
Jakub Jelinek [Fri, 8 Apr 2022 07:14:44 +0000 (09:14 +0200)]
fold-const: Fix up make_range_step [PR105189]
The following testcase is miscompiled, because fold_truth_andor
incorrectly folds
(unsigned) foo () >= 0U && 1
into
foo () >= 0
For the unsigned comparison (which is useless in this case,
as >= 0U is always true, but hasn't been folded yet), previous
make_range_step derives exp (unsigned) foo () and +[0U, -]
range for it. Next we process the NOP_EXPR. We have special code
for unsigned to signed casts, already earlier punt if low or high
aren't representable in arg0_type or if it is a narrowing conversion.
For the signed to unsigned casts, I think if high is specified we
are still fine, as we punt for non-representable values in arg0_type,
n_high is then still representable and so was smaller or equal to
signed maximum and either low is not present (equivalent to 0U), or
low must be smaller or equal to high and so for unsigned exp
+[low, high] the signed exp +[n_low, n_high] will be correct.
Similarly, if both low and high aren't specified (always true or
always false), it is ok too.
But if we have for unsigned exp +[low, -] or -[low, -], using
+[n_low, -] or -[n_high, -] is incorrect. Because low is smaller
or equal to signed maximum and high is unspecified (i.e. unsigned
maximum), when signed that range is a union of +[n_low, -] and
+[-, -1] which is equivalent to -[0, n_low-1], unless low
is 0, in that case we can treat it as [-, -].
2022-04-08 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/105189
* fold-const.c (make_range_step): Fix up handling of
(unsigned) x +[low, -] ranges for signed x if low fits into
typeof (x).
Jakub Jelinek [Wed, 6 Apr 2022 16:42:52 +0000 (18:42 +0200)]
combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array [PR104985]
The testcase in the PR fails under valgrind on mips64 (but only Martin
can reproduce, I couldn't).
But the problem reported there is that SUBST_MODE remembers addresses
into the regno_reg_rtx array, then some splitter needs a new pseudo
and calls gen_reg_rtx, which reallocates the regno_reg_rtx array
and finally undo operation is done and dereferences the old regno_reg_rtx
entry.
The rtx values stored in regno_reg_rtx array seems to be created
by gen_reg_rtx only and since then aren't modified, all we do for it
is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does).
So, I think it is useless to use where.r for UNDO_MODE and store
®no_reg_rtx[regno] in struct undo, we can store just
regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of
pointer to pointer to REG) or could also store just the regno.
The following patch does the latter, and because SUBST_MODE no longer
needs to be a macro, changes all SUBST_MODE uses to subst_mode.
2022-04-06 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/104985
* combine.c (struct undo): Add where.regno member.
(do_SUBST_MODE): Rename to ...
(subst_mode): ... this. Change first argument from rtx * into int,
operate on regno_reg_rtx[regno] and save regno into where.regno.
(SUBST_MODE): Remove.
(try_combine): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever. For UNDO_MODE, use
regno_reg_rtx[undo->where.regno] instead of *undo->where.r.
(undo_to_marker): For UNDO_MODE, use regno_reg_rtx[undo->where.regno]
instead of *undo->where.r.
(simplify_set): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever.
Patrick Palka [Wed, 16 Feb 2022 17:41:35 +0000 (12:41 -0500)]
c++: treat NON_DEPENDENT_EXPR as not potentially constant [PR104507]
Here we're crashing from potential_constant_expression because it tries
to perform trial evaluation of the first operand '(bool)__r' of the
conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
cxx_eval_constant_expression ICEs on unsupported trees (of which CAST_EXPR
is one). The sequence of events is:
1. build_non_dependent_expr for the array subscript yields
NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2
2. cp_build_array_ref calls fold_non_dependent_expr on this subscript
(after this point, processing_template_decl is cleared)
3. during which, the COND_EXPR case of tsubst_copy_and_build calls
fold_non_dependent_expr on the first operand
4. during which, we crash from p_c_e_1 because it attempts trial
evaluation of the CAST_EXPR '(bool)__r'.
Note that even if this crash didn't happen, fold_non_dependent_expr
from cp_build_array_ref would still ultimately be one big no-op here
since neither constexpr evaluation nor tsubst handle NON_DEPENDENT_EXPR.
In light of this and of the observation that we should never see
NON_DEPENDENT_EXPR in a context where a constant expression is needed
(it's used primarily in the build_x_* family of functions), it seems
futile for p_c_e_1 to ever return true for NON_DEPENDENT_EXPR. And the
otherwise inconsistent handling of NON_DEPENDENT_EXPR between p_c_e_1,
cxx_evaluate_constexpr_expression and tsubst apparently leads to weird
bugs such as this one.
Patrick Palka [Tue, 8 Feb 2022 13:46:13 +0000 (08:46 -0500)]
c++: constrained auto in lambda using outer tparms [PR103706]
Here we're crashing during satisfaction of the lambda's placeholder type
constraints because the constraints depend on the template arguments
from the enclosing scope, which aren't part of the lambda's DECL_TI_ARGS.
This patch fixes this by making do_auto_deduction consider the
"regenerating" template arguments of a lambda for satisfaction,
mirroring what's done in satisfy_declaration_constraints.
PR c++/103706
gcc/cp/ChangeLog:
* constraint.cc (satisfy_declaration_constraints): Use
lambda_regenerating_args instead.
* cp-tree.h (lambda_regenerating_args): Declare.
* pt.c (lambda_regenerating_args): Define, split out from
satisfy_declaration_constraints.
(do_auto_deduction): Use lambda_regenerating_args to obtain the
full set of outer template arguments for satisfaction when
inside a lambda.
Patrick Palka [Fri, 28 Jan 2022 13:18:28 +0000 (08:18 -0500)]
c++: var tmpl w/ dependent constrained auto type [PR103341]
When deducing the type of a variable template (or templated static data
member) with a constrained auto type, we might need its template
arguments for satisfaction since the constraint could depend on them.
PR c++/103341
gcc/cp/ChangeLog:
* decl.c (cp_finish_decl): Pass the template arguments of a
variable template specialization or a templated static data
member to do_auto_deduction when the auto is constrained.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-class4.C: New test.
* g++.dg/cpp2a/concepts-var-templ2.C: New test.
Patrick Palka [Tue, 25 Jan 2022 20:04:49 +0000 (15:04 -0500)]
c++: deleted fn and noexcept inst [PR101532, PR104225]
Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions. This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.
To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.
PR c++/101532
PR c++/104225
gcc/cp/ChangeLog:
* decl2.c (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-template21.C: New test.
* g++.dg/cpp0x/nsdmi-template21a.C: New test.
Patrick Palka [Tue, 12 Apr 2022 16:58:18 +0000 (12:58 -0400)]
c++: requires-expr in pack expansion using pack [PR103105]
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts).
Then when hashing the resulting dependent specialization of A, we crash
from iterative_hash_template_arg since it deliberately doesn't handle
ARGUMENT_PACK_SELECT.
Like in r12-7102-gdb5f1c17031ad8, it seems the right fix here is to
resolve ARGUMENT_PACK_SELECT arguments before storing them into an
extra args tree (such as REQUIRES_EXPR).
PR c++/103105
gcc/cp/ChangeLog:
* pt.c (build_extra_args): Call preserve_args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires29.C: New test.
* g++.dg/cpp2a/concepts-requires29a.C: New test.
Patrick Palka [Tue, 8 Feb 2022 13:46:32 +0000 (08:46 -0500)]
c++: lambda in pack expansion using pack in constraint [PR103706]
Here when expanding the pack expansion pattern containing a constrained
lambda, the template argument for each Ts is an ARGUMENT_PACK_SELECT,
which we store inside the lambda's LAMBDA_EXPR_REGEN_INFO. Then during
satisfaction of the lambda's constraint C<Ts> the satisfaction cache
uses this argument as part of the key to the corresponding sat_entry, but
iterative_hash_template_arg and template_args_equal deliberately don't
handle ARGUMENT_PACK_SELECT.
Since it's wrong to preserve ARGUMENT_PACK_SELECT inside a hash table
due to its instability (as documented in iterative_hash_template_arg),
this patch helps make sure the satisfaction cache doesn't see such trees
by resolving ARGUMENT_PACK_SELECT arguments before adding them to
LAMBDA_EXPR_REGEN_INFO.
PR c++/103706
gcc/cp/ChangeLog:
* pt.c (preserve_args): New function.
(tsubst_lambda_expr): Use it when setting LAMBDA_EXPR_REGEN_INFO.
Jonathan Wakely [Thu, 27 Jan 2022 22:31:26 +0000 (22:31 +0000)]
libstdc++: Prevent -Wstringop-overread warning in std::deque [PR100516]
The compiler warns about the loop in deque::_M_range_initialize because
it doesn't know that the number of nodes has already been correctly
sized to match the size of the input. Use __builtin_unreachable to tell
it that the loop will never be entered if the number of elements is
smaller than a single node.
libstdc++-v3/ChangeLog:
PR libstdc++/100516
* include/bits/deque.tcc (_M_range_initialize<ForwardIterator>):
Add __builtin_unreachable to loop.
* testsuite/23_containers/deque/100516.cc: New test.
Peter Bergner [Tue, 12 Apr 2022 19:08:53 +0000 (14:08 -0500)]
rs6000: Handle pcrel sibcalls to longcall functions [PR104894]
Before PCREL in POWER10, we were not allowed to perform sibcalls to longcall
functions since callee's return would skip the TOC restore in the caller.
However, with PCREL we can now safely perform a sibling call to longcall
functions. The problem with the current code is that pcrel sibcall
branches to a PLT stub label even though -fno-plt was used. The solution
here is to check for a pcrel longcall and emit an inline plt stub in
that case.
This restores support for std::make_exception_ptr<E&> and for using
std::exception_ptr in C++98.
Because the new non-throwing implementation needs to use std::decay to
handle references the original throwing implementation is used for
C++98.
We also need to change the typeid expression so it doesn't yield the
dynamic type when the function parameter is a reference to a polymorphic
type. Otherwise the new exception object could be caught by any handler
matching the dynamic type, even though the actual exception object is
only a copy of the base class, sliced to the static type.
libstdc++-v3/ChangeLog:
PR libstdc++/103630
* libsupc++/exception_ptr.h (exception_ptr): Fix exception
specifications on inline definitions.
(make_exception_ptr): Decay the template parameter. Use typeid
of the static type.
* testsuite/18_support/exception_ptr/103630.cc: New test.
Jonathan Wakely [Tue, 22 Mar 2022 21:17:01 +0000 (21:17 +0000)]
libstdc++: Disable atomic wait for freestanding [PR105021]
We use either condition variables or futexes to implement atomic waits,
so we can't do it in freestanding. This is non-conforming, so should be
revisited later, probably by making freestanding atomic waiting
operations spin without ever blocking.
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/105021
* include/bits/atomic_base.h [!_GLIBCXX_HOSTED]: Do not include
<bits/atomic_wait.h> for freestanding.
Jonathan Wakely [Fri, 10 Dec 2021 11:44:29 +0000 (11:44 +0000)]
libstdc++: Guard mutex and condvar with gthreads macro [PR103638]
A mutex and condition variable is used for timed waits on atomics if
there is no "platform wait" (e.g. futex) supported. But the use of those
types wasn't guarded by the _GLIBCXX_HAS_GTHREADS macro, causing errors
for --disable-threads builds. This fix allows <atomic> to work on
targets with futexes but no gthreads.
libstdc++-v3/ChangeLog:
PR libstdc++/103638
* include/bits/atomic_timed_wait.h: Check _GLIBCXX_HAS_GTHREADS
before using std::mutex and std::__condvar.
Implement the changes from P2162R2 (as a DR for C++17).
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/90943
* include/std/variant (__cpp_lib_variant): Update value.
(__detail::__variant::__as): New helpers implementing the
as-variant exposition-only function templates.
(visit, visit<R>): Use __as to upcast the variant parameters.
* include/std/version (__cpp_lib_variant): Update value.
* testsuite/20_util/variant/visit_inherited.cc: New test.
Jason Merrill [Mon, 11 Apr 2022 17:06:05 +0000 (13:06 -0400)]
c++: operator new lookup [PR98249]
The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope. This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.
PR c++/98249
gcc/cp/ChangeLog:
* call.c (build_operator_new_call): Just look in ::.
Jason Merrill [Tue, 5 Apr 2022 20:02:04 +0000 (16:02 -0400)]
c++: -Wshadow=compatible-local type vs var [PR100608]
The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types. If only one is, they aren't compatible.
PR c++/100608
gcc/cp/ChangeLog:
* name-lookup.c (check_local_shadow): Use -Wshadow=local
if exactly one of 'old' and 'decl' is a type.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wshadow-compatible-local-3.C: New test.
Jason Merrill [Mon, 28 Mar 2022 02:31:51 +0000 (22:31 -0400)]
c++: elaborated-type-spec in requires-expr [PR101677]
We were failing to declare class S in the global namespace because we were
treating the requires-expression parameter scope as a normal block scope, so
the implicit declaration went there.
It seems to me that the requires parameter scope is more like a function
parameter scope (not least in the use of the word "parameter"), so let's
change the scope kind. But then we need to adjust the prohibition on
placeholders declaring implicit template parameters.
PR c++/101677
gcc/cp/ChangeLog:
* name-lookup.h (struct cp_binding_level): Add requires_expression
bit-field.
* parser.c (cp_parser_requires_expression): Set it.
(synthesize_implicit_template_parm): Check it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr67178.C: Adjust error.
* g++.dg/cpp2a/concepts-requires28.C: New test.
Jason Merrill [Fri, 25 Mar 2022 17:13:35 +0000 (13:13 -0400)]
c++: hash table ICE with variadic alias [PR105003]
For PR104008 we thought it might be enough to keep strip_typedefs from
removing this alias template specialization, but this PR demonstrates that
other parts of the compiler also need to know to consider it dependent.
So, this patch changes complex_alias_template_p to no longer consider
template parameters used when their only use appears in a pack expansion,
unless they are the parameter packs being expanded.
To do that I also needed to change it to use cp_walk_tree instead of
for_each_template_parm. It occurs to me that find_template_parameters
should probably also use cp_walk_tree, but I'm not messing with that now.
Jason Merrill [Sun, 27 Mar 2022 02:05:53 +0000 (22:05 -0400)]
c++: CTAD and member function references [PR103943]
More quirks of rewriting member references to dependent references for
CTAD. A reference to a member of dependent scope is definitely dependent.
And since r11-7044, tsubst_baselink builds a SCOPE_REF, so
tsubst_qualified_id should just use it.
Jason Merrill [Thu, 7 Apr 2022 02:20:49 +0000 (22:20 -0400)]
c++: nested generic lambda in DMI [PR101717]
We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a non-generic
lambda.
PR c++/101717
gcc/cp/ChangeLog:
* lambda.c (lambda_expr_this_capture): Check all enclosing
lambdas for completeness.
Patrick Palka [Wed, 12 Jan 2022 14:10:24 +0000 (09:10 -0500)]
libstdc++: Avoid overflow in bounds checks [PR103955]
We currently crash when the floating-point to_chars overloads are passed
a precision value near INT_MAX, ultimately due to overflow in the bounds
checks that verify the output range is large enough.
The simplest portable fix seems to be to replace bounds checks of the form
A >= B + C (where B + C may overflow) with the otherwise equivalent check
A >= B && A - B >= C, which is the approach this patch takes.
Before we could do this in __floating_to_chars_hex, there we first need
to track the unbounded "excess" precision (i.e. the number of trailing
fractional digits in the output that are guaranteed to be '0') separately
from the bounded "effective" precision (i.e. the number of significant
fractional digits in the output), like we do in __f_t_c_precision.
PR libstdc++/103955
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
Track the excess precision separately from the effective
precision. Avoid overflow in bounds check by splitting it into
two checks.
(__floating_to_chars_precision): Avoid overflow in bounds checks
similarly.
* testsuite/20_util/to_chars/103955.cc: New test.
Patrick Palka [Thu, 21 Oct 2021 01:34:23 +0000 (21:34 -0400)]
libstdc++: Implement LWG 3591-3592 changes to split_view
libstdc++-v3/ChangeLog:
* include/std/ranges (split_view::base): Add forward_range
constraint as per LWG 3591.
(split_view::begin, lazy_split_view::end): Also check
simpleness of _Pattern as per LWG 3592.
Patrick Palka [Thu, 21 Oct 2021 01:34:21 +0000 (21:34 -0400)]
libstdc++: Implement LWG 3535 changes to ranges::join_view
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust
criteria for returning bidirectional_iterator_tag as per LWG 3535.
(join_view::_Iterator::_S_iter_concept): Likewise.
Patrick Palka [Tue, 19 Oct 2021 22:07:05 +0000 (18:07 -0400)]
libstdc++: Implement LWG 3470 change to ranges::subrange
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h
(__detail::__uses_nonqualification_pointer_conversion): Define
and use it ...
(__detail::__convertible_to_nonslicing): ... here, as per LWG 3470.
* testsuite/std/ranges/subrange/1.cc: New test.
Patrick Palka [Tue, 19 Oct 2021 21:54:24 +0000 (17:54 -0400)]
libstdc++: Implement LWG 3523 changes to ranges::iota_view
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_Iterator): Befriend iota_view.
(iota_view::_Sentinel): Likewise.
(iota_view::iota_view): Add three overloads, each taking an
iterator/sentinel pair as per LWG 3523.
* testsuite/std/ranges/iota/iota_view.cc (test06): New test.
Vectorizer loop versioning tries to version outer loops if possible
but fails to check whether it can actually split the single exit
edge as it will do.
2022-04-12 Richard Biener <rguenther@suse.de>
PR tree-optimization/105226
* tree-vect-loop-manip.c (vect_loop_versioning): Verify
we can split the exit of an outer loop we choose to version.
The testcase was missing dg- before require-effective-target.
While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above. I suppose it
might be useful for some target variants.
for gcc/testsuite/ChangeLog
PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target. Prune warning about -mfloat128
possibly not being fully supported.
Kito Cheng [Mon, 11 Apr 2022 08:29:34 +0000 (16:29 +0800)]
RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator. [PR104853]
We migrate the default ISA spec version from 2.2 to 20191213, but those scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.
gcc/ChangeLog:
PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.
Kito Cheng [Tue, 20 Jul 2021 02:53:18 +0000 (10:53 +0800)]
RISC-V: Allow multi-lib build with different code model
--with-multilib-generator was only support for different ISA/ABI
combination, however code model is effect the code gen a lots it
should able to handled in multilib mechanism.
Adding `--cmodel=` option to `--with-multilib-generator` to generating
multilib combination with different code model.
E.g.
--with-multilib-generator="rv64ima-lp64--;--cmodel=medlow,medany"
will generate 3 multi-lib suppport:
1) rv64ima with lp64
2) rv64ima with lp64 and medlow code model
3) rv64ima with lp64 and medany code model
gcc/
* config/riscv/multilib-generator: Support code model option for
multi-lib.
* doc/install.texi: Add document of new option for
--with-multilib-generator.
Mikael Morin [Sun, 13 Mar 2022 21:22:55 +0000 (22:22 +0100)]
fortran: Separate associate character lengths earlier [PR104570]
This change workarounds an ICE in the evaluation of the character length
of an array expression referencing an associate variable; the code is
not prepared to see a non-scalar expression as it doesn’t initialize the
scalarizer.
Before this change, associate length symbols get a new gfc_charlen at
resolution stage to unshare them from the associate expression, so that
at translation stage it is a decl specific to the associate symbol that
is initialized, not the decl of some other symbol. This
reinitialization of gfc_charlen happens after expressions referencing
the associate symbol have been parsed, so that those expressions retain
the original gfc_charlen they have copied from the symbol.
At translation stage, the gfc_charlen for the associate symbol is setup
with the decl holding the actual length value, but the expressions have
retained the original gfc_charlen without any decl. So they need to
evaluate the character length, and this is where the ICE happens.
This change moves the reinitialization of gfc_charlen earlier at parsing
stage, so that at resolution stage the gfc_charlen can be retained as
it’s already not shared with any other symbol, and the expressions which
now share their gfc_charlen with the symbol are automatically updated
when the length decl is setup at translation stage. There is no need
any more to evaluate the character length as it has all the required
information, and the ICE doesn’t happen.
The first resolve.c hunk is necessary to avoid regressing on the
associate_35.f90 testcase.
PR fortran/104228
PR fortran/104570
gcc/fortran/ChangeLog:
* parse.c (parse_associate): Use a new distinct gfc_charlen if the
copied type has one whose length is not known to be constant.
* resolve.c (resolve_assoc_var): Reset charlen if it’s shared with
the associate target regardless of the expression type.
Don’t reinitialize charlen if it’s deferred.
Mikael Morin [Fri, 28 Jan 2022 21:00:57 +0000 (22:00 +0100)]
fortran: Unshare associate var charlen [PR104228]
PR104228 showed that character lengths were shared between associate
variable and associate targets. This is problematic when the associate
target is itself a variable and gets a variable to hold the length, as
the length variable is added (and all the variables following it in the chain)
to both the associate variable scope and the target variable scope.
This caused an ICE when compiling with -O0 -fsanitize=address.
This change forces the creation of a separate character length for the
associate variable. It also forces the initialization of the character
length variable to avoid regressing associate_32 and associate_47 tests.
PR fortran/104228
gcc/fortran/ChangeLog:
* resolve.c (resolve_assoc_var): Also create a new character
length for non-dummy associate targets.
* trans-stmt.c (trans_associate_var): Initialize character length
even if no temporary is used for the associate variable.
gcc/testsuite/ChangeLog:
* gfortran.dg/asan/associate_58.f90: New test.
* gfortran.dg/asan/associate_59.f90: New test.
Here, we're not finding the parameter pack inside the static_assert because
STATIC_ASSERT trees are tcc_exceptional, and we weren't explicitly walking
them in cp_walk_subtrees.
PR c++/99893
PR c++/103885
gcc/cp/ChangeLog:
* tree.c (cp_walk_subtrees) <case STATIC_ASSERT>: New case.
Richard Biener [Fri, 8 Apr 2022 11:13:29 +0000 (13:13 +0200)]
tree-optimization/105198 - wrong code with predictive commoning
When predictive commoning looks for a looparound PHI it tries
to match the entry value definition (a load) up with the appropriate
member of the chain. But it fails to consider stmts clobbering
the very same memory location inbetween the load and loop entry.
In theory we could be more clever on must aliases that would be
also picked up from a load (so not exactly stmt_kills_ref_p) and
use the stored value from that if it is an exact match. But we
currently have no way to propagate this information inside predcom.
2022-04-08 Richard Biener <rguenther@suse.de>
PR tree-optimization/105198
* tree-predcom.c (find_looparound_phi): Check whether
the found memory location of the entry value is clobbered
inbetween the value we want to use and loop entry.
Patrick Palka [Wed, 9 Mar 2022 23:48:52 +0000 (18:48 -0500)]
libstdc++: Avoid implicit narrowing from uint128_t [PR104859]
We need to be explicit about narrowing conversions from uint128_t since,
on targets that lack __int128, this type is defined as an integer-class
type that is only _explicitly_ convertible to the builtin integer types.
This issue was latent until r12-7563-ge32869a17b788b made the frontend
correctly reject explicit conversion functions during (dependent)
copy-initialization.
PR libstdc++/104859
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (__floating_to_chars_hex):
Be explicit when narrowing the shifted effective_mantissa,
since it may have an integer-class type.
Patrick Palka [Wed, 6 Apr 2022 15:46:25 +0000 (11:46 -0400)]
c++: make -Wctad-maybe-unsupported respect complain [PR105143]
We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during overload resolution in the second testcase.
PR c++/105143
gcc/cp/ChangeLog:
* pt.c (do_class_deduction): Check complain before attempting
to issue a -Wctad-maybe-unsupported warning.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nodiscard1.C: New test.
* g++.dg/warn/Wctad-maybe-unsupported4.C: New test.
Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).
As far as I can tell, this situation happens only when declaring a
constrained template friend within a non-template class (as in the
testcase), in which case the substitution would be a no-op anyway.
So this patch rearranges maybe_substitute_reqs_for to gracefully
handle missing DECL_TEMPLATE_INFO by just skipping the substitution.
PR c++/105064
gcc/cp/ChangeLog:
* constraint.cc (maybe_substitute_reqs_for): Don't assume
DECL_TEMPLATE_INFO is available.
Patrick Palka [Thu, 17 Feb 2022 13:35:23 +0000 (08:35 -0500)]
c++: double non-dep folding from finish_compound_literal [PR104565]
In finish_compound_literal, we perform non-dependent expr folding before
the call to check_narrowing ever since r9-5973. But ever since r10-7096,
check_narrowing also performs non-dependent expr folding of its own.
This double folding means tsubst will see non-templated trees during the
second folding, which causes a spurious error in the below testcase.
This patch removes the former folding operation; it seems obviated by
the latter one.
Patrick Palka [Thu, 3 Feb 2022 23:54:23 +0000 (18:54 -0500)]
c++: dependence of member noexcept-spec [PR104079]
Here a stale TYPE_DEPENDENT_P/_P_VALID value for f's function type
after replacing the type's DEFERRED_NOEXCEPT with the parsed dependent
noexcept-spec causes us to try to instantiate g's noexcept-spec ahead
of time (since it in turn appears non-dependent), leading to an ICE.
This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
fixup_deferred_exception_variants appropriately (as in
build_cp_fntype_variant).
That turns out to fix the testcase for C++17 but not for C++11/14,
because it's not until C++17 that a noexcept-spec is part of (and
therefore affects dependence of) the function type. Since dependence of
NOEXCEPT_EXPR is defined in terms of instantiation dependence, the most
appropriate fix for earlier dialects seems to be to make instantiation
dependence consider dependence of a noexcept-spec.
PR c++/104079
gcc/cp/ChangeLog:
* pt.c (value_dependent_noexcept_spec_p): New predicate split
out from ...
(dependent_type_p_r): ... here.
(instantiation_dependent_r): Use value_dependent_noexcept_spec_p
to consider dependence of a noexcept-spec before C++17.
* tree.c (fixup_deferred_exception_variants): Clear
TYPE_DEPENDENT_P_VALID.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept74.C: New test.
* g++.dg/cpp0x/noexcept74a.C: New test.
projects / thirdparty / gcc.git / log
