| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Due to recent, large changes in libstdc++, the feature test macros
declared in <version> got out of sync with the other headers that
possibly declare them.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Synchronize the definition block with...
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory):
... this one here. Also define the 202202L value, rather than
leaving it up to purely unique_ptr.h, so that the value is
synchronized across all headers.
(__gnu_debug::_Safe_iterator_base): Move into new conditional
block.
* include/std/memory (__cpp_lib_atomic_value_initialization):
Define on freestanding under the same conditions as in
atomic_base.h.
* include/std/version (__cpp_lib_robust_nonmodifying_seq_ops):
Also define on freestanding.
(__cpp_lib_to_chars): Ditto.
(__cpp_lib_gcd): Ditto.
(__cpp_lib_gcd_lcm): Ditto.
(__cpp_lib_raw_memory_algorithms): Ditto.
(__cpp_lib_array_constexpr): Ditto.
(__cpp_lib_nonmember_container_access): Ditto.
(__cpp_lib_clamp): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_constexpr_string): Ditto.
(__cpp_lib_sample): Ditto.
(__cpp_lib_lcm): Ditto.
(__cpp_lib_constexpr_iterator): Ditto.
(__cpp_lib_constexpr_char_traits): Ditto.
(__cpp_lib_interpolate): Ditto.
(__cpp_lib_constexpr_utility): Ditto.
(__cpp_lib_shift): Ditto.
(__cpp_lib_ranges): Ditto.
(__cpp_lib_move_iterator_concept): Ditto.
(__cpp_lib_constexpr_numeric): Ditto.
(__cpp_lib_constexpr_functional): Ditto.
(__cpp_lib_constexpr_algorithms): Ditto.
(__cpp_lib_constexpr_tuple): Ditto.
(__cpp_lib_constexpr_memory): Ditto.
|
|
2023-04-05 John David Anglin <danglin@gcc.gnu.org>
libstdc++-v3/ChangeLog:
* testsuite/22_locale/locale/cons/12658_thread-2.cc: Double
timeout factor on hppa*-*-*.
|
|
RTL structure of an insn
So as mentioned in the PR the underlying issue here is combine changes the form of an existing insn, but fails to force re-recognition. As a result other parts of the compiler blow up.
> /* Temporarily replace the set's source with the
> contents of the REG_EQUAL note. The insn will
> be deleted or recognized by try_combine. */
> rtx orig_src = SET_SRC (set); rtx orig_dest = SET_DEST (set); if (GET_CODE (SET_DEST (set)) == ZERO_EXTRACT)
> SET_DEST (set) = XEXP (SET_DEST (set), 0);
> SET_SRC (set) = note;
> i2mod = temp;
> i2mod_old_rhs = copy_rtx (orig_src);
> i2mod_new_rhs = copy_rtx (note);
> next = try_combine (insn, i2mod, NULL, NULL,
> &new_direct_jump_p, last_combined_insn);
> i2mod = NULL;
> if (next)
> {
> statistics_counter_event (cfun, "insn-with-note combine", 1);
> goto retry;
> } SET_SRC (set) = orig_src;
> SET_DEST (set) = orig_dest;
This code replaces the SET_SRC of an insn in the RTL stream with the contents of a REG_EQUAL note. So given an insn like this:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (ior:DI (reg:DI 200)
> (reg:DI 251))) "j.c":14:5 -1
> (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
> (nil)))
It replaces the (ior ...) with a (const_int ...). The resulting insn is passed to try_combine which will try to recognize it, then use it in a combination attempt. Recognition succeeds with the special define_insn_and_split pattern in the risc-v backend resulting in:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (const_int 25769803782 [0x600000006])) "j.c":14:5 177 {*mvconst_internal}
> (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
> (nil)))
This is as-expected. Now assume we were unable to combine anything, so try_combine returns NULL_RTX. The quoted code above restores SET_SRC (and SET_DEST) resulting in:
> (insn 122 117 127 2 (set (reg:DI 157 [ _46 ])
> (ior:DI (reg:DI 200)
> (reg:DI 251))) "j.c":14:5 177 {*mvconst_internal}
> (expr_list:REG_EQUAL (const_int 25769803782 [0x600000006])
> (nil)))
But this doesn't get re-recognized and we ICE later in LRA.
The fix is trivial, reset the INSN_CODE to force re-recognition in the case where try_combine fails.
PR target/108892
gcc/
* combine.cc (combine_instructions): Force re-recognition when
after restoring the body of an insn to its original form.
gcc/testsuite/
* gcc.c-torture/compile/pr108892.c: New test.
|
|
The millicode division and remainder routines trap division by zero.
The unwinder needs these directives to unwind divide by zero traps.
2023-04-05 John David Anglin <danglin@gcc.gnu.org>
libgcc/ChangeLog:
PR target/109374
* config/pa/milli64.S (RETURN_COLUMN): Define.
($$divI): Add CFI directives.
($$divU): Likewise.
($$remI): Likewise.
($$remU): Likewise.
|
|
PR 108959 shows one more example where undefined code with type
incompatible accesses to stuff passed in parameters can cause an ICE
because we try to create a VIEW_CONVERT_EXPR of mismatching sizes:
1. IPA-CP tries to push one type from above,
2. IPA-SRA (correctly) decides the parameter is useless because it is
only used to construct an argument to another function which does not
use it and so the formal parameter should be removed,
3. but the code reconciling IPA-CP and IPA-SRA transformations still
wants to perform the IPA-CP and overrides the built-in DCE of
useless statements and tries to stuff constants into them
instead, constants of a type with mismatching type and size.
This patch avoids the situation in IPA-SRA by purging the IPA-CP
results from any "aggregate" constants that are passed in parameters
which are detected to be useless. It also removes IPA value range and
bits information associated with removed parameters stored in the same
structure so that the useless information is not streamed later on.
gcc/ChangeLog:
2023-03-22 Martin Jambor <mjambor@suse.cz>
PR ipa/108959
* ipa-sra.cc (zap_useless_ipcp_results): New function.
(process_isra_node_results): Call it.
gcc/testsuite/ChangeLog:
2023-03-17 Martin Jambor <mjambor@suse.cz>
PR ipa/108959
* gcc.dg/ipa/pr108959.c: New test.
|
|
It's quite obvious that the order of vrsub SEW64 is wrong.
gcc/ChangeLog:
* config/riscv/vector.md: Fix incorrect operand order.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/bug-23.C: New test.
|
|
This was approved at the C++ meeting in February.
libstdc++-v3/ChangeLog:
* include/bits/regex.h (sub_match::swap): New function.
* testsuite/28_regex/sub_match/lwg3204.cc: New test.
|
|
PR 109399
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
(pass_vsetvl::compute_local_backward_infos): Update user vsetvl in local
demand fusion.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr109399.c: New test.
|
|
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.def: Fix typo.
* config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value): Ditto.
* config/riscv/vector-iterators.md: Ditto.
|
|
|
|
The line-break in the example looked odd, even more so with
a page-break in the middle of it, due to recently added text
in preceding pages.
* doc/md.texi (Including Patterns): Fix page break.
|
|
* gcc.pot: Regenerate.
|
|
gcc/fortran/ChangeLog:
PR fortran/104349
* expr.cc (check_restricted): Adjust check for valid variables in
restricted expressions: make no exception for module variables.
gcc/testsuite/ChangeLog:
PR fortran/104349
* gfortran.dg/der_charlen_1.f90: Adjust dg-patterns.
* gfortran.dg/pr104349.f90: New test.
|
|
I've missed one of my recent range-op-float.cc changes (likely the
r13-6967 one) caused
FAIL: libphobos.phobos/std/math/algebraic.d execution test
FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test
regressions, distilled into a C testcase below.
In the testcase, we have
!(u >= v)
condition where both u and v are results of fabs*, which guards
t1 = u u<= __FLT_MAX__;
and
t2 = v u<= __FLT_MAX__;
comparisons. From false u >= v where u and v have [0.0, +Inf] NAN
ranges we (incorrectly deduce that one of them is [nextafterf (0.0, 1.0), +Inf] NAN
and the other is [0.0, nextafterf (+Inf, 0.0)] NAN and from that deduce that
one of the comparisons is always true, because UNLE_EXPR with the maximum
representable number are false only if the value is +Inf and our ranges tell
that is not possible.
The bug is that the u >= v comparison determines a sensible range only when
it is true - we then know neither operand can be NAN and it behaves
correctly. But when the comparison is false, our current code gives
sensible answers only if the other op can't be NAN. If it can be NAN,
whenever it is NAN, the comparison is always false regardless of the other
value, so the other value needs to be VARYING.
Now, foperator_unordered_lt::op1_range etc. had code to deal with that
for op?.known_nan (), but as the testcase shows, it is enough if it may be a
NAN at runtime to make it VARYING.
So, the following patch replaces for all those BRS_FALSE cases of the normal
non-equality comparisons if (opOTHER.known_isnan ()) r.set_varying (type);
to do it also if maybe_isnan ().
For the unordered or ... comparisons, it is similar for BRS_TRUE. Those
comparisons are true whenever either operand is NAN, or if neither is NAN,
the corresponding normal comparison. So, if those comparisons are true
and other operand might be a NAN, we can't tell (VARYING), if it is false,
currently handling is correct.
2023-04-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/109386
* range-op-float.cc (foperator_lt::op1_range, foperator_lt::op2_range,
foperator_le::op1_range, foperator_le::op2_range,
foperator_gt::op1_range, foperator_gt::op2_range,
foperator_ge::op1_range, foperator_ge::op2_range): Make r varying for
BRS_FALSE case even if the other op is maybe_isnan, not just
known_isnan.
(foperator_unordered_lt::op1_range, foperator_unordered_lt::op2_range,
foperator_unordered_le::op1_range, foperator_unordered_le::op2_range,
foperator_unordered_gt::op1_range, foperator_unordered_gt::op2_range,
foperator_unordered_ge::op1_range, foperator_unordered_ge::op2_range):
Make r varying for BRS_TRUE case even if the other op is maybe_isnan,
not just known_isnan.
* gcc.c-torture/execute/ieee/pr109386.c: New test.
|
|
Here we're failing to detect a signed overflow with -O because match.pd,
since r8-1516, transforms
c = (a + 1) - (int) (short int) b;
into
c = (int) ((unsigned int) a + 4294946117);
wrongly eliding the overflow. This kind of problems is usually
avoided by using TYPE_OVERFLOW_SANITIZED in the appropriate place.
The first match.pd hunk in the patch fixes it. I've constructed
a testcase for each of the surrounding cases as well. Then I
noticed that fold_binary_loc/associate has the same problem, so I've
added a TYPE_OVERFLOW_SANITIZED there as well (it may be too coarse,
sorry). Then I found yet another problem, but instead of fixing it
now I've opened 109134. I could probably go on and find a dozen more.
PR sanitizer/109107
gcc/ChangeLog:
* fold-const.cc (fold_binary_loc): Use TYPE_OVERFLOW_SANITIZED
when associating.
* match.pd: Use TYPE_OVERFLOW_SANITIZED.
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/pr109107-1.c: New test.
* c-c++-common/ubsan/pr109107-2.c: New test.
* c-c++-common/ubsan/pr109107-3.c: New test.
* c-c++-common/ubsan/pr109107-4.c: New test.
|
|
From the initial merge of the MVE backend, the vcreate
intrinsic has had the vector lanes mixed up, compared
to the intended (as per the ACLE) definition. This is
also a discrepancy with clang:
https://godbolt.org/z/4n93e5aqj
This patches simply switches the operands around and
makes the tests more specific on the input registers
(I do not touch the output Q regs as they vary based
on softfp/hardfp or the input registers when the input
is a constant, since, in that case, a single register
is loaded with a constant and then the same register is
used twice as "vmov q0[2], q0[0], r2, r2" and the reg
num might not always be guaranteed).
gcc/ChangeLog:
* config/arm/mve.md (mve_vcvtq_n_to_f_<supf><mode>): Swap operands.
(mve_vcreateq_f<mode>): Swap operands.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/intrinsics/vcreateq_f16.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_f32.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_s16.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_s32.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_s64.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_s8.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_u16.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_u32.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_u64.c: Tighten test.
* gcc.target/arm/mve/intrinsics/vcreateq_u8.c: Tighten test.
|
|
The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Remove std::bad_exception from
example program.
* doc/html/manual/ext_demangling.html: Regenerate.
|
|
gcc/ChangeLog:
* config/gcn/gcn-valu.md (one_cmpl<mode>2<exec>): New.
|
|
The following patch unbreaks riscv bootstrap, where it previously failed
on -Werror=format-diag warning promoted to error.
Ok for trunk?
Or shall it say e.g.
"%<-march=%s%>: %<zfinx%> extension conflicts with %<f>"
?
Or say if the current condition is true, do
const char *ext = "zfinx";
if (subset_list->lookup ("zdinx"))
ext = "zdinx";
else if (subset_list->lookup ("zhinx"))
ext = "zhinx";
else if (subset_list->lookup ("zhinxmin"))
ext = "zhinxmin";
and
"%<-march=%s%>: %qs extension conflicts with %<f>", arch, ext
? Or do similar check for which extension to print against it,
const char *ext = "zfinx";
const char *ext2 = "f";
if (subset_list->lookup ("zdinx"))
{
ext = "zdinx";
if (subset_list->lookup ("d"))
ext2 = "d";
}
else if (subset_list->lookup ("zhinx"))
{
ext = "zhinx";
if (subset_list->lookup ("zfh"))
ext2 = "zfh";
}
else if (subset_list->lookup ("zhinxmin"))
{
ext = "zhinxmin";
if (subset_list->lookup ("zfhmin"))
ext2 = "zfhmin";
}
"%<-march=%s%>: %qs extension conflicts with %qs", arch, ext, ext2
?
2023-04-04 Jakub Jelinek <jakub@redhat.com>
PR target/109384
* common/config/riscv/riscv-common.cc (riscv_subset_list::parse):
Reword diagnostics about zfinx conflict with f, formatting fixes.
* gcc.target/riscv/arch-19.c: Expect a different message about zfinx
vs. f conflict.
|
|
libpthread has been folded into libc since Solaris 10 and replaced by a
filter on libc. Linking with libpthread thus only creates unnecessary
runtime overhead.
This patch thus removes linking with -lpthread if -pthread/-pthreads is
specified, thus getting rid of the libpthread dependency in libatomic,
libgdruntime, libgomp, libgphobos, and libitm.
Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11 (both Solaris 11.3 and 11.4).
2023-04-03 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* config/sol2.h (LIB_SPEC): Don't link with -lpthread.
|
|
When adjusting calls to reflect instrumentation we failed to handle
calls to aliases since they appear to have no body. Instead resort
to symtab node availability. The patch also avoids touching
internal function calls in a more obvious way (builtins might
have a body available).
profiledbootstrap & regtest running on x86_64-unknown-linux-gnu.
Honza - does this look OK?
PR tree-optimization/109304
* tree-profile.cc (tree_profiling): Use symtab node
availability to decide whether to skip adjusting calls.
Do not adjust calls to internal functions.
* gcc.dg/pr109304.c: New testcase.
|
|
As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness. Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back. To
get the permutation control vector for the rotation, it
makes use of lvsr and lvsl, but the element ordering is
different for BE and LE (like element 0 is the most
significant one on BE while the least significant one on
LE), this patch is to add consideration for BE and make
sure permutation control vectors for rotations are expected.
As tested, it helped to fix the below failures:
FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
FAIL: gcc.target/powerpc/pr89765-mc.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test
PR target/108807
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix gen
function for permutation control vector by considering big endianness.
|
|
The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.
This patch is to fix the handling with one more insn vpopcntb.
PR target/108699
gcc/ChangeLog:
* config/rs6000/altivec.md (*p9v_parity<mode>2): Rename to ...
(rs6000_vprtyb<mode>2): ... this.
* config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2 with
rs6000_vprtybv2di2.
(VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2.
(VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2.
* config/rs6000/vector.md (parity<mode>2 with VEC_IP): Expand with
popcountv16qi2 and the corresponding rs6000_vprtyb<mode>2.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for vpopcntb
to distinguish parity byte from parity.
* gcc.target/powerpc/pr108699.c: New test.
|
|
Here friend matching tries to find a matching non-template friend and fails,
so we mark the friend as a template specialization to be determined later.
Then cplus_decl_attributes tries again to find a matching function and gets
confused by DECL_TEMPLATE_INSTANTIATION without DECL_TEMPLATE_INFO. But it
doesn't make sense for find_last_decl to be trying to match anything with
DECL_USE_TEMPLATE set; those are matched elsewhere.
PR c++/107484
gcc/cp/ChangeLog:
* decl2.cc (find_last_decl): Return early if DECL_USE_TEMPLATE.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/friend25.C: New test.
|
|
I needed to check what was allowed in a define_split, but
had problems understanding what was meant by "Splitting of
jump instruction into sequence that over by another jump
instruction".
* doc/md.texi (Insn Splitting): Tweak wording for readability.
Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>
|
|
|
|
Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable template with deduced type before we
fully parsed its initializer.
PR c++/109300
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Diagnose ordinary auto deduction
with no initializer, instead of asserting.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ79.C: New test.
|
|
* sv.po: Update.
|
|
This patch removes an unused parameter 'module' from
DoVariableDeclaration in M2GCCDeclare.mod. It also removes unused
procedures from PHBuild.bnf.
gcc/m2/ChangeLog:
PR modula2/109388
* gm2-compiler/M2GCCDeclare.mod (DoVariableDeclaration):
Remove second parameter module. Adjust all callers to
remove the second parameter.
* gm2-compiler/PHBuild.bnf (CheckAndInsert): Remove.
(InStopSet): Remove.
(PeepToken): Remove.
(PushQualident): Remove.
(SimpleDes): Remove.
(ActualParameters): Remove.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
|
|
We are in the process of changing data structures holding information
about constants passed by reference and in aggregates to use unsigned
int offsets rather than HOST_WIDE_INT (which was selected simply
because that is what fell out of get_ref_base_and_extent at that time)
in order to conserve memory, especially at WPA time.
PR 109303 testcase discovers that we do not properly check that we
only create jump functions with offsets (plus sizes) that fit into the
smaller type. This patch adds the necessary check.
gcc/ChangeLog:
2023-03-30 Martin Jambor <mjambor@suse.cz>
PR ipa/109303
* ipa-prop.cc (determine_known_aggregate_parts): Check that the
offset + size will be representable in unsigned int.
gcc/testsuite/ChangeLog:
2023-03-30 Jakub Jelinek <jakub@redhat.com>
Martin Jambor <mjambor@suse.cz>
PR ipa/109303
* gcc.dg/pr109303.c: New test.
|
|
Recent Solaris 11.4 SRUs bundle zstd, but only the 64-bit libraries (no
idea why). Because of this, in 32-bit builds cc1 etc. fail to link with
undefined references to various ZSTD_* functions from lto-compress.o.
This happens because currently only the presence of <zstd.h> is
necessary to enable zstd support in lto-compress.cc etc.
This patch checks for libzstd first and disables zstd support if
missing.
Tested on sparc-sun-solaris2.11 with the system installation of zstd
(64-bit only) and a locally-compiled one (specified with --with-zstd).
2023-03-28 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* configure.ac (ZSTD_LIB): Move before zstd.h check.
Unset gcc_cv_header_zstd_h without libzstd.
* configure: Regenerate.
|
|
gcc/ChangeLog:
* doc/invoke.texi: Document new param.
|
|
gcc/
* doc/sourcebuild.texi (const_volatile_readonly_section): Document
new check_effective_target function.
|
|
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.def (vuint32m8_t): Fix typo.
(vfloat32m8_t): Likewise
|
|
gcc/testsuite/
PR target/102146
* gcc.target/powerpc/pr56605.c: Modify the match pattern for dump
scan.
|
|
gcc/ChangeLog:
* doc/md.texi: Document signbitm2.
|
|
|
|
Add hppa*-*-* to dg-additional-options list.
2023-04-02 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
PR target/109375
* gnat.dg/opt39.adb: Add hppa*-*-* to dg-additional-options list.
|
|
Test needs to be skipped if the target does not support atomic primitives.
2023-04-02 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
PR target/109376
* gnat.dg/prot7.adb: Skip on hppa.
|
|
This patch enables gm2 to pass -fmod= though to cc1gm2. It also
builds the libraries for m2/stage2/cc1gm2 with no named path and
full debugging.
gcc/m2/ChangeLog:
PR modula2/109336
* Make-lang.in (GM2_O): Set to -O0.
(GM2_LIBS): Remove target libraries and replace with build libs.
(BUILD-LIBS): New declaration.
(m2/gm2-libs/libgm2.a): New rule.
(m2/gm2-libs/%.o): New rule.
(m2/gm2-libs/choosetemp.o): New rule.
* gm2-compiler/M2ColorString.mod (append): Use ADR rather than
implicit conversion.
* gm2-compiler/M2Comp.mod (Compile): Add qprintf messages for when
a source file is not found. Improve comments and formatting.
* gm2-libs-ch/cgetopt.c (cgetopt_cgetopt_long): Remove
ansi-decl.h. Add getopt.h.
(cgetopt_cgetopt_long_only): Change cgetopt_ to getopt_.
* gm2spec.cc (lang_specific_driver): Do not skip -fmod=.
Remove comment.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
|
|
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek <jakub@redhat.com>
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
|
|
Vector mac instructions has LRA issue during high register pressure,
It will failed to reload when picked first alternative, because it will
require reload 2 input operands into same register as input operand,
so we adding an extra operand to generate one more move pattern to
relax such restricted constraint.
This path fix ICE of ternary intrinsic:
bug.C:144:2: error: unable to find a register to spill
144 | }
| ^
bug.C:144:2: error: this is the insn:
(insn 462 972 919 24 (set (reg/v:VNx8DI 546 [orig:192 var_10 ] [192])
(if_then_else:VNx8DI (unspec:VNx8BI [
(reg/v:VNx8BI 603 [orig:179 var_13 ] [179])
(const_int 13 [0xd])
(const_int 2 [0x2])
(const_int 0 [0]) repeated x2
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(plus:VNx8DI (mult:VNx8DI (reg/v:VNx8DI 605 [orig:190 var_6 ] [190])
(reg/v:VNx8DI 547 [orig:160 var_51 ] [160]))
(reg/v:VNx8DI 548 [orig:161 var_52 ] [161]))
(reg/v:VNx8DI 605 [orig:190 var_6 ] [190]))) "bug.C":131:48 4171 {*pred_maddvnx8di}
(expr_list:REG_DEAD (reg/v:VNx8DI 605 [orig:190 var_6 ] [190])
(expr_list:REG_DEAD (reg/v:VNx8BI 603 [orig:179 var_13 ] [179])
(expr_list:REG_DEAD (reg/v:VNx8DI 547 [orig:160 var_51 ] [160])
(expr_list:REG_DEAD (reg/v:VNx8DI 548 [orig:161 var_52 ] [161])
(nil))))))
gcc/ChangeLog:
* config/riscv/vector.md: Fix RA constraint.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/bug-19.C: New test.
* g++.target/riscv/rvv/base/bug-20.C: New test.
* g++.target/riscv/rvv/base/bug-21.C: New test.
* g++.target/riscv/rvv/base/bug-22.C: New test.
Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Co-authored-by: kito-cheng <kito.cheng@sifive.com>
|
|
We need to reset the AVL to 0 or 1 for scalar move for RV32 system,
For any non-zero AVL input, we set that to 1, and zero will keep as zero.
We are using wrong way (by andi with 1) before to achieve that, and it
will cause ICE with const_int, and also wrong behavior, so now we have
two code path, one for const_int and one for non-const_int.
bug.C:144:2: error: unrecognizable insn:
144 | }
| ^
(insn 684 683 685 26 (set (reg:SI 513)
(and:SI (const_int 4 [0x4])
(const_int 1 [0x1]))) "bug.C":115:47 -1
(nil))
andi a4,a4,1 ===> sgtu a4,a4,zero
vsetlvi tu vsetvli tu
vlse vlse
gcc/ChangeLog:
* config/riscv/riscv-protos.h (gen_avl_for_scalar_move): New function.
* config/riscv/riscv-v.cc (gen_avl_for_scalar_move): New function.
* config/riscv/vector.md: Fix scalar move bug.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/scalar_move-6.c: Adapt test.
* gcc.target/riscv/rvv/base/scalar_move-9.c: New test.
|
|
|
|
Here we're crashing during satisfaction for the NTTP 'C<B> auto V'
ultimately because convert_template_argument / unify don't pass all
outer template arguments to do_auto_deduction, and during satisfaction
we need to know all arguments. While these callers do pass some outer
arguments, they are only sufficient to properly substitute the
(level-lowered) 'auto' and are not necessarily the entire set.
Fortunately it seems these callers have access to the full set of outer
arguments via convert_template_argument's 'in_decl' parameter and
unify's 'tparms' parameter. So this patch adds a new parameter to
do_auto_deduction, used only during adc_unify deduction, through which
these callers can pass the enclosing (partially instantiated) template
and from which do_auto_deduction can obtain _all_ outer template
arguments for sake of satisfaction.
This patch also ensures that the 'in_decl' argument passed to
coerce_template_parms is always a TEMPLATE_DECL, which in turn allows us
to pass it as-is to do_auto_deduction; the only coerce_template_parms
caller that needed adjustment was tsubst_decl it seems.
PR c++/109160
gcc/cp/ChangeLog:
* cp-tree.h (do_auto_deduction): Add defaulted tmpl parameter.
* pt.cc (convert_template_argument): Pass 'in_decl' as 'tmpl' to
do_auto_deduction.
(tsubst_decl) <case VAR_/TYPE_DECL>: Pass 'tmpl' instead of 't' as
'in_decl' to coerce_template_parms.
(unify) <case TEMPLATE_PARM_INDEX>: Pass TPARMS_PRIMARY_TEMPLATE
as 'tmpl' to do_auto_deduction.
(do_auto_deduction): Document default arguments. Rename local
variable 'tmpl' to 'ctmpl'. Use 'tmpl' to obtain a full set of
template arguments for satisfaction in the adc_unify case.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-placeholder12.C: New test.
|
|
r13-995-g733a792a2b2e16 worked around the problem of (pointer to)
function NTTP arguments not always getting marked as odr-used, by
redundantly calling mark_used on the substituted ADDR_EXPR callee of a
CALL_EXPR. That is just a narrow workaround however, since it assumes
the function is later called, but the use as a template argument alone
should constitute an odr-use of the function (since template arguments
are an evaluated context, and we're really passing its address); we
shouldn't need to subsequently call or otherwise use the function NTTP
argument.
This patch fixes this in a more general way by walking the template
arguments of each specialization that's about to be instantiated and
redundantly calling mark_used on all entities used within. As before,
the call to mark_used as it worst a no-op, but it compensates for the
situation where the specialization was first formed in a template context
in which mark_used is inhibited.
Another approach would be to call mark_used whenever we substitute a
TEMPLATE_PARM_INDEX, but that would result in many more redundant calls
to mark_used compared to this approach. And as the second testcase
below illustrates, we also need to walk C++20 class NTTP arguments which
can be large and thus expensive to walk repeatedly. The change to
invalid_tparm_referent_p is needed to avoid incorrectly rejecting class
NTTP arguments containing function pointers as in the testcase.
(The third testcase is unrelated to this fix, but it helped rule out an
earlier approach I was considering and it seems we don't have existing
test coverage for this situation.)
PR c++/53164
PR c++/105848
gcc/cp/ChangeLog:
* pt.cc (invalid_tparm_referent_p): Accept ADDR_EXPR of
FUNCTION_DECL.
(instantiate_class_template): Call mark_template_arguments_used.
(tsubst_copy_and_build) <case CALL_EXPR>: Revert r13-995 change.
(mark_template_arguments_used): Define.
(instantiate_body): Call mark_template_arguments_used.
gcc/testsuite/ChangeLog:
* g++.dg/template/fn-ptr3a.C: New test.
* g++.dg/template/fn-ptr3b.C: New test.
* g++.dg/template/fn-ptr4.C: New test.
|
|
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (get_c_type_name): Fix "long_long"
type name to be "long long".
|
|
On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
> - there is a missing case (not handled in this patch) where both operands
> are known to be zeros, but not singleton zeros
This patch adds those cases.
2023-04-01 Jakub Jelinek <jakub@redhat.com>
* range-op-float.cc (foperator_equal::fold_range): If at least
one of the op ranges is not singleton and neither is NaN and all
4 bounds are zero, return [1, 1].
(foperator_not_equal::fold_range): In the same case return [0, 0].
|
|
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
> and so if maybe_isnan, they always return [0, 1]. Now, thinking about it,
> this is unnecessary pessimization, for the case where the ... block
> returns range_false (type) we actually could do it also if maybe_isnan (op1,
> op2), because if one or both operands are NAN, the comparison will be false,
> and if neither is NAN, the comparison will be also false. Will fix
> incrementally today.
Here it is.
1) the foperator_{,not_}equal::fold_range cases
- we have correctly first a case handling known_isnan on either operand,
return there range_false (type) - EQ, resp. range_true (type) - NE
- next we handle the singleton cases, maybe_isnan + singleton isn't
singleton, so these are ok
- there is a missing case (not handled in this patch) where both operands
are known to be zeros, but not singleton zeros
- there is some !maybe_isnan (op1, op2) handling which tries to prove
when the operands are certainly not equal and results in
range_false (type) - EQ, resp. range_true (type) - NE
- otherwise range_true_and_false (type)
Now, I think (and this patch implements it) that the !maybe_isnan (op1, op2)
check is unnecessary. If we prove that when ignoring maybe NANs, the
ranges don't intersect and so the comparison is always false for EQ or
always true for NE, if NANs can appear, it doesn't change anything on
that either, for EQ if NAN appears, the result is false like what we
proved for the finite ranges, for NE if NAN appears, the result is true
like what we proved for the finite ranges
2) foperator_{lt,le,gt,ge}::fold_range cases
- these have correctly known_isnan on either operand first and return
there range_false (type)
- then !maybe_isnan (op1, op2) condition guarded checks
- finally range_true_and_false (type) - so do that for
maybe_isnan (op1, op2)
Here in the !maybe_isnan (op1, op2) guarded code we have some condition
which results in range_true (type), another condition which results in
range_false (type) and otherwise range_true_and_false (type).
Now, the condition which results in range_false (type) can be IMHO done
also for the maybe_isnan (op1, op2) cases, because it is [0, 0]
if both operands are finite or [0, 0] if either operand is NAN.
3) finally, LTGT_EXPR wasn't handled at all. LTGT_EXPR is the inverse
comparision to UNEQ_EXPR, I believe both raise exceptions only if
either operand is sNaN, UNEQ_EXPR is true if both operands are
either equal or either of the operands is NAN, while LTGT_EXPR is
true if the operands compare either smaller or larger and is false if
either of the operands is NAN.
2023-04-01 Jakub Jelinek <jakub@redhat.com>
* range-op-float.cc (foperator_equal::fold_range): Perform the
non-singleton handling regardless of maybe_isnan (op1, op2).
(foperator_not_equal::fold_range): Likewise.
(foperator_lt::fold_range, foperator_le::fold_range,
foperator_gt::fold_range, foperator_ge::fold_range): Perform the
real_* comparison check which results in range_false (type)
even if maybe_isnan (op1, op2). Simplify.
(foperator_ltgt): New class.
(fop_ltgt): New variable.
(floating_op_table::floating_op_table): Handle LTGT_EXPR using
fop_ltgt.
* gcc.dg/torture/inf-compare-1.c: Add dg-additional-options
-fno-tree-dominator-opts -fno-tree-vrp.
* gcc.dg/torture/inf-compare-1-float.c: Likewise.
* gcc.dg/torture/inf-compare-2.c: Likewise.
* gcc.dg/torture/inf-compare-2-float.c: Likewise.
|
|
This PR got fixed with r13-137.
Add a testcase to make sure it doesn't reappear.
2023-04-01 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/109362
* gcc.target/i386/pr109362.c: New test.
|
