Explicitly enable altivec if it's supported. vect_int tests for
powerpc_altivec_ok, but without the explicit option, if altivec is not
enabled by default, we end up expecting vectorization that doesn't
occur.
for gcc/testsuite/ChangeLog
* gcc.dg/signbit-2.c: Add -maltivec if supported.
There was a typo in the attributes of the option
-param=vect-induction-float= for IntegerRange.
This fixes that typo.
Committed as obvious after a build/test.
gcc/ChangeLog:
PR tree-optimization/109427
* params.opt (-param=vect-induction-float=):
Fix option attribute typo for IntegerRange.
The overrider of proc unsupported in modules.exp had two problems
reported by Thomas Schwinge, even after Jakub Jelínek's fix:
- it remained in effect while running other dejagnu testsets
- it didn't quote correctly the argument list passed to it, which
caused test names to be surrounded by curly braces, as in:
UNSUPPORTED: {...}
This patch fixes both issues, obsoleting and reverting Jakub's change,
by dropping the overrider and renaming the saved proc back, and by
using uplevel's argument list splicing.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
for gcc/testsuite/ChangeLog
PR testsuite/108899
* g++.dg/modules/modules.exp (unsupported): Drop renaming.
Fix quoting.
This patch fixes an ICE if attempting to INCL or EXCL on an unknown
set. The fix was to correct an error format string. Also included in
the patch are patches to remove unused variables. The patch also
marks a variable as written in BuildAdr.
gcc/m2/ChangeLog:
PR modula2/109423
* gm2-compiler/M2Base.def (Unbounded): Remove.
* gm2-compiler/M2Error.def (ErrorAbort0): Add noreturn
attribute.
* gm2-compiler/M2Quads.mod (BuildInclProcedure): Correct
error format string.
(BuildExceptProcedure): Correct error format string.
(BuildAdrFunction): Call PutWriteQuad when taking the
address of a variable.
* gm2-libs-ch/SysExceptions.c (_M2_SysExceptions_init): Add
parameters.
* gm2-libs-ch/wrapc.c (_M2_wrapc_init): Add parameters.
* gm2-libs/DynamicStrings.mod (DumpStringInfo): Remove t.
(PopAllocationExemption): Remove f.
* gm2-libs/FIO.mod (BufferedWrite): Remove result.
* gm2-libs/FormatStrings.mod (Copy): Remove endpos and
afterperc.
(HandlePercent): Remove result.
* gm2-libs/Indexing.mod (RemoveIndiceFromIndex): Remove k.
* gm2-libs/M2Dependent.mod (CreateModule): Remove p0
and p1.
(DumpModuleData): Remove mptr.
(ConstructModules): Remove nulp.
* gm2-libs/RTExceptions.mod (PopHandler): Remove i.
* gm2-libs/RTint.mod (Listen): Remove b4s, b4m, afs
and afm.
* gm2-libs/SFIO.mod (ReadS): Remove c.
* gm2-libs/StringConvert.mod (doDecimalPlaces): Remove
whole and fraction.
gcc/testsuite/ChangeLog:
* gm2/pim/fail/setunknown.mod: New test.
PR modula2/109423
* gm2/pim/fail/setunknown2.mod: New test.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
At some point, <charconv> was added to the non-hosted bit of the C++17
block, which induced failures in many tests.
In addition, some tests also lacked a dg-require-effective-target hosted
tag.
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h (C++17): Don't double-include
<charconv>, once with wrong conditions.
* testsuite/18_support/96817.cc: Require hosted.
* testsuite/18_support/bad_exception/59392.cc: Ditto.
* testsuite/20_util/scoped_allocator/108952.cc: Ditto.
* testsuite/20_util/uses_allocator/lwg3527.cc: Ditto.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Ditto.
Supporting the debug mode in freestanding is a non-trivial job, so
instead, as a best-effort, enable assertions, which are light and easy.
libstdc++-v3/ChangeLog:
* include/bits/c++config: When __STDC_HOSTED__ is zero,
disable _GLIBCXX_DEBUG and, if it was set, enable
_GLIBCXX_ASSERTIONS.
* testsuite/lib/libstdc++.exp (check_v3_target_debug_mode):
Include <bits/c++config.h> when determining whether debug is
set, in order to inherit the logic from above
This test detects redefinitions by compiling stdc++.h and <version>, by
disabling the system_header pragma on the latter, to allow warnings in
it. Thanks Patrick Palka for the suggestion.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/versionconflict.cc: New test.
* include/std/version: Allow disabling the system_header pragma
via _GLIBCXX_TESTING_SYSHDR.
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*-*-*.
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.
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.
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.
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.
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.
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.
Indu Bhagat
Alexandre Oliva
Andrew Pinski
GCC Administrator
Gaius Mulley
Arsen Arsenović
John David Anglin
Jeff Law
Martin Jambor
Ju-Zhe Zhong
Jonathan Wakely
Li Xu
Hans-Peter Nilsson
Joseph Myers
Harald Anlauf
Jakub Jelinek
Marek Polacek
Stam Markianos-Wright
Andrew Stubbs
Rainer Orth
Richard Biener
Kewen Lin
Jason Merrill
Patrick Palka
Martin Liska
Cupertino Miranda
Haochen Gui
liuhongt