The patch that introduced the weak_undefined effective-target keyword
and corresponding dg-add-options support

commit 378ec7b8
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Mar 23 00:45:05 2023 -0300

    [testsuite] test for weak_undefined support and add options

badly broke the affected tests on macOS like so:

ERROR: gcc.dg/addr_equal-1.c: unknown dg option: 89 for " dg-add-options 5 weak_undefined "
ERROR: gcc.dg/addr_equal-1.c: unknown dg option: 89 for " dg-add-options 5 weak_undefined "

add_options_for_weak_undefined tries to call an non-existant proc "89".
Even after fixing this by escaping the brackets, two tests still failed to
link since they lacked the corresponding calls do dg-add-options
weak_undefined.

Tested on x86_64-apple-darwin20.6.0 and i386-pc-solaris2.11.

2023-03-27  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc/testsuite:
	* lib/target-supports.exp (add_options_for_weak_undefined): Escape
	brackets.
	* gcc.dg/visibility-22.c: Add weak_undefined options.

	libgomp:
	* testsuite/libgomp.oacc-c-c++-common/routine-nohost-2.c: Add
	weak_undefined options.

Prevent any name mangling in HOST_EXTRA_OBJS_SYMBOL
such that the linker always finds it by that name.

Also add the .manifest file as an explicit
dependency in the make rule such that the
object gets re-built if it changes.

gcc/ChangeLog:

	* config.host: Pull in i386/x-mingw32-utf8 Makefile
	fragment and reference utf8rc-mingw32.o explicitly
	for mingw hosts.
	* config/i386/sym-mingw32.cc: prevent name mangling of
	stub symbol.
	* config/i386/x-mingw32-utf8: Make utf8rc-mingw32.o
	depend on manifest file explicitly.

Signed-off-by: Jonathan Yong <10walls@gmail.com>

This reverts commit 776a5bb5.

	PR rtl-optimization/109311
	* cfgcleanup.cc (bb_is_just_return): Revert previous change.

memmem is not POSIX so the system may lack it.  Then libiberty will
provide an implementation, but it's a "supplemental function" and not
declared in libiberty.h.  We need to declare the prototype to use it
then.

See libiberty doc at
https://gcc.gnu.org/onlinedocs/libiberty/Supplemental-Functions.html.

Tested by bootstrapping GCC in the following container environments on
x86_64-linux-gnu:

1. "Vanilla" system with memmem in Glibc.
2. memmem removed from string.h.
3. memmem removed from both string.h and libc.so.

For 3, also verified that memmem from libiberty is linked into fixincl
executable.

Ok for trunk?

fixincludes/ChangeLog:

	PR other/109293
	* configure.ac (AC_CHECK_DECLS): Add memmem.
	* configure: Regenerate.
	* config.h.in: Regenerate.
	* system.h (memmem): Declare if HAVE_DECL_MEMMEM is zero.

Prior to the removal of STABS support the gdwarf, gstabs, ... options
formed a cycle with their Negative(..) option attribute.  But that
didn't actually have any effect since most of the options also
are Joined or JoinedOrMissing for which there's no pruning of options
and so once ran into the set_debug_level diagnostics reporting
conflicting debug formats.

The following removes the remains of that cycle, which is a
Negative option from gdwarf to gdwarf-.  With RejectNegative
added the expected effect of -gdwarf-4 -gdwarf would be to
enable DWARF5 support (but this doesn't happen for some reason).
I think the more sensible behavior is that seen and implemented
in opts.cc, the more specific -gdwarf-4 determines the DWARF level
and a later or earlier -gdwarf becomes a no-op.  So the
Negative(..) annotation on gdwarf is just confusing.

	* common.opt (gdwarf): Remove Negative(gdwarf-).

The following adds RejectNegative to the gdwarf, gdwarf-, ggdb and gvms
options since the current behavior is to treat the negative variant
the same as the positive variant.  In particular -ggdb -gno-gdb
do not cancel, and plain -gno-dwarf will enable (dwarf!) debug output.

Rejecting the negative forms avoids interpreting sensible behavior
to combinations of options like -gdwarf-5 -gno-dwarf-3 and sticks to
the behavior that later -g options simply override earlier ones and
the only negative form is -g0.

	* common.opt (gdwarf): Add RejectNegative.
	(gdwarf-): Likewise.
	(ggdb): Likewise.
	(gvms): Likewise.

This patch has no effect on builds using reload of libgcc, newlib libc, my
own at-a-glance-testsuite and coremark.  That somewhat surprisingly
also goes for LRA builds, even with all CRIS reload_in_progress
augmented to include lra_in_progress.  I just noticed it when checking
because another port had a similar fix, where it mattered for LRA.

	* config/cris/constraints.md ("T"): Correct to
	define_memory_constraint.

The test-case gcc.target/cris/rld-legit1.c is a reduced
test-case that required defining LEGITIMIZE_RELOAD_ADDRESS
to stop the address from being decomposed into several insns
by reload.  Valid but suboptimal code was generated.

(Before implementing that hook for CRIS, the same test-case
also exposed a bug in reload, and a fix was committed to
avoid an ICE; see e.g. git r0-71992-gff0d9879ab0f30 and
related commits.  But, post-cc0, reload no longer handles
this test-case without LEGITIMIZE_RELOAD_ADDRESS helping and
there'd again an be ICE for CRIS (again: only if
LEGITIMIZE_RELOAD_ADDRESS is disabled).  There's a patch to
reload to fix that, at
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612039.html)

But, LRA also does not handle that test-case gracefully, and
like reload without LEGITIMIZE_RELOAD_ADDRESS for CRIS,
decomposes the address into a suboptimal (but valid)
sequence, about as messy as that from reload, and
gcc.target/cris/rld-legit1.c would regress for LRA.  There's
nothing equivalent to LEGITIMIZE_RELOAD_ADDRESS for LRA.
(Stepping through LRA, I can't find an obvious place where
to put such a hook.  Granted, I haven't seen this kind of
messy decomposition in other code, so I'm not insisting a
LEGITIMIZE_RELOAD_ADDRESS-like hook is a good idea.)

These new peephole2's are required to not regress
gcc.target/cris/rld-legit1.c with LRA enabled for CRIS.
They don't appear to otherwise make a difference for neither
libgcc, newlib libc, my own at-a-glance tests nor coremark,
for neither LRA nor reload.

	* config/cris/cris.md (BW2): New mode-iterator.
	(lra_szext_decomposed, lra_szext_decomposed_indirect_with_offset): New
	peephole2s.

This patch affects a post-reload define_split for CRIS that transforms
a condition-code-clobbering addition into a non-clobbering addition.
(A "two-operand" addition between registers is the only insn that has
both a condition-code-clobbering and a non-clobbering variant for
CRIS.)  Many more "add.d":s are replaced by non-condition-code-
clobbering "addi":s after this patch, but most of the transformations
don't matter.

CRIS with LRA generated code that exposed a flaw with the original
patch: it bailed too easily, on *any* insn using the result of the
addition.  To wit, more effort than simply applying reg_mentioned_p is
needed to inspect the user, in the code to avoid munging an insn
sequence that cmpelim is supposed to handle.

With this patch coremark score for CRIS (*with reload*) improves by
less than 0.01% (a single "nop" is eliminated in
core_state_transition, in an execution path that affects ~1/20 of all
of the 10240 calls).  However, the original cause for this patch is to
not regress gcc.target/cris/pr93372-44.c for LRA, where otherwise a
needless "cmpq" is emitted.  For CRIS with LRA, the performance effect
on coremark isn't even measurable, except by reducing the size of the
executable due to affecting non-called library code.

	* config/cris/cris.md ("*add<mode>3_addi"): Improve to bail only
	for possible eliminable compares.

	* config/cris/constraints.md ("R"): Remove unused constraint.

gcc/ChangeLog:

	PR gcov-profile/109297
	* gcov-tool.cc (merge_usage): Fix "subcomand" typo.
	(merge_stream_usage): Likewise.
	(overlap_usage): Likewise.

I realized I never added a testcase for the fix of this bug.  Now done
after verifying it still fails when reverting the fix.

	PR tree-optimization/54498
	* g++.dg/torture/pr54498.C: New testcase.

The following adds the testcase for the bug which was recently
fixed.

	PR tree-optimization/108357
	* gcc.dg/tree-ssa/pr108357.c: New testcase.

This patch adds missing mode specifiers for XTheadMemPair INSNs.

gcc/ChangeLog:
	PR target/109296
	* config/riscv/thead.md: Add missing mode specifiers.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

In Fedora package build I've noticed a failure
/builddir/build/BUILD/gcc-13.0.1-20230324/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc: In function 'void test01()':
/builddir/build/BUILD/gcc-13.0.1-20230324/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc:41: warning: format '%lu' expects argument of type 'long unsigned int', but a
rgument 2 has type 'unsigned int' [-Wformat=]
FAIL: experimental/net/timer/waitable/dest.cc (test for excess errors)
Excess errors:
/builddir/build/BUILD/gcc-13.0.1-20230324/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc:41: warning: format '%lu' expects argument of type 'long unsigned int', but
+argument 2 has type 'unsigned int' [-Wformat=]
because we build with -Wformat.

The test uses %lu for size_t argument, which can be anything from unsigned
int to unsigned long long.  As for printf I'm not sure we can use %zu
portably and given the n == 1 assertion, I think the options are to kill
the printf, or cast to long.

2023-03-27  Jakub Jelinek  <jakub@redhat.com>

	* testsuite/experimental/net/timer/waitable/dest.cc: Avoid -Wformat
	warning if size_t is not unsigned long.

The original submission of AmpereOne (-mcpu=ampere1) costs occurred
prior to exhaustive testing of vectorizable workloads against
hardware.

Adjust the vector costs to achieve the best results and more closely
match the underlying hardware.

gcc/ChangeLog:

	* config/aarch64/aarch64.cc: Update vector costs for ampere1.

Co-Authored-By: Jiangning Liu <jiangning.liu@amperecomputing.com>
Co-Authored-By: Manolis Tsamis <manolis.tsamis@vrull.eu>

Fixes:
gcc/testsuite/lib/verify-sarif-file.py:10:27: Q000 Double quotes found but single quotes preferred

gcc/testsuite/ChangeLog:

	* lib/verify-sarif-file.py: Use apostrophes instead
	of double quotes.

For the testcase bb_is_just_return is on top of the profile, changing
it to walk BB insns backwards puts it off the profile.  That's because
in the forward walk you have to process possibly many debug insns
but in a backward walk you very likely run into control insns first.

	PR rtl-optimization/109237
	* cfgcleanup.cc (bb_is_just_return): Walk insns backwards.

The following makes lto-wrapper deal with non-combined debug
disabling / enabling option combinations properly.  Interestingly
-gno-dwarf also enables debug.

	PR lto/109263
	* lto-wrapper.cc (run_gcc): Parse alternate debug options
	as well, they always enable debug.

As PR109167 shows, it's unexpected to have two different
implementation ways for _mm_slli_si128 and _mm_bslli_si128,
as gcc/config/i386/emmintrin.h they should be the same.  So
this patch is to fix it accordingly.

	PR target/109167

gcc/ChangeLog:

	* config/rs6000/emmintrin.h (_mm_bslli_si128): Move the implementation
	from ...
	(_mm_slli_si128): ... here.  Change to call _mm_bslli_si128 directly.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr109167.c: New test.

As PR109082 shows, some uses of vec_sld in emmintrin.h don't
strictly guarantee the given shift count is in the range
0-15 (inclusive).  This patch is to make the argument
range constraint honored for those uses.

	PR target/109082

gcc/ChangeLog:

	* config/rs6000/emmintrin.h (_mm_bslli_si128): Check __N is not less
	than zero when calling vec_sld.
	(_mm_bsrli_si128): Return __A if __N is zero, check __N is bigger than
	zero when calling vec_sld.
	(_mm_slli_si128): Return __A if _imm5 is zero, check _imm5 is bigger
	than zero when calling vec_sld.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr109082.c: New test.

gcc/ChangeLog:

	* doc/generic.texi (OpenMP): Document OMP_SIMD, OMP_DISTRIBUTE,
	OMP_TASKLOOP, and OMP_LOOP with OMP_FOR.  Document how collapsed
	loops are represented and which fields are vectors.  Add
	documentation for OMP_FOR_PRE_BODY field.  Document internal
	form of non-rectangular loops and OMP_FOR_NON_RECTANGULAR.

	* tree.def (OMP_FOR): Make documentation consistent with the
	Texinfo manual, to fill some gaps and correct errors.

This reinstates FINAL_PRESCAN_INSN, and the calls in handle_move_double,
so that access to TLS variables with offset are properly handled.

gcc:
	PR target/106282
	* config/m68k/m68k.h (FINAL_PRESCAN_INSN): Define.
	* config/m68k/m68k.cc (m68k_final_prescan_insn): Define.
	(handle_move_double): Call it before handle_movsi.
	* config/m68k/m68k-protos.h: Declare it.

gcc/testsuite:
	PR target/106282
	* gcc.target/m68k/tls-gd-off.c: New.
	* gcc.target/m68k/tls-ie-off.c: New.
	* gcc.target/m68k/tls-ld-off.c: New.
	* gcc.target/m68k/tls-ld-xtls-off.c: New.
	* gcc.target/m68k/tls-le-off.c: New.
	* gcc.target/m68k/tls-le-xtls-off.c: New.
	* gcc.target/m68k/tls-ld.c: Make pattern less strict.
	* gcc.target/m68k/tls-le.c: Likewise.

The following testcase is miscompiled on aarch64-linux.  match.pd
has a simplification for addsub, where it negates one of the vectors
in twice as large floating point element vector (effectively negating every
other element) and then doing addition.
But a requirement for that is that the permutation picks the right elements,
in particular 0, nelts+1, 2, nelts+3, 4, nelts+5, ...
The pattern tests this with sel.series_p (0, 2, 0, 2) check, which as
documented verifies that the even elements of the permutation mask are
identity, but doesn't say anything about the others.
The following patch fixes it by also checking that the odd elements
start at nelts + 1 with the same step of 2.

2023-03-26  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/109230
	* match.pd (fneg/fadd simplify): Verify also odd permutation indexes.

	* gcc.dg/pr109230.c: New test.

predict: Don't emit -Wsuggest-attribute=cold warning for functions which already have that attribute [PR105685]

In the following testcase, we predict baz to have cold
entry regardless of the user supplied attribute (as it call
unconditionally a cold function), but still issue
a -Wsuggest-attribute=cold warning despite it having that attribute
already.

The following patch avoids that.

2023-03-26  Jakub Jelinek  <jakub@redhat.com>

	PR ipa/105685
	* predict.cc (compute_function_frequency): Don't call
	warn_function_cold if function already has cold attribute.

	* c-c++-common/cold-2.c: New test.

This is another instance of what ce51e843 (and originally
05432288) addressed in a different part. We stopped shipping
granular tarballs years ago.

gcc/ChangeLog:

	* doc/install.texi: Remove anachronistic note
	related to languages built and separate source tarballs.

gcc/fortran/ChangeLog:

	PR fortran/104321
	* trans-decl.cc (gfc_conv_cfi_to_gfc): Remove dead code.

PR analyzer/109098 notes that the SARIF spec mandates that .sarif
files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively
assumes that the source files are UTF-8 encoded when quoting source
artefacts in the .sarif output, which can lead to us writing out
.sarif files with non-UTF-8 bytes in them (which break my reporting
scripts).

The root cause is that sarif_builder::maybe_make_artifact_content_object
was using maybe_read_file to load the file content as bytes, and
assuming they were UTF-8 encoded.

This patch reworks both overloads of this function (one used for the
whole file, the other for snippets of quoted lines) so that they go
through input.cc's file cache, which attempts to decode the input files
according to the input charset, and then encode as UTF-8.  They also
check that the result actually is UTF-8, for cases where the input
charset is missing, or incorrectly specified, and omit the quoted
source for such awkward cases.

Doing so fixes all of the cases I've encountered.

The patch adds a new:
  { dg-final { verify-sarif-file } }
directive to all SARIF test cases in the test suite, which verifies
that the output is UTF-8 encoded, and is valid JSON.  In particular
it verifies that when we complain about encoding problems, the .sarif
report we emit is itself correctly encoded.

gcc/ChangeLog:
	PR analyzer/109098
	* diagnostic-format-sarif.cc (read_until_eof): Delete.
	(maybe_read_file): Delete.
	(sarif_builder::maybe_make_artifact_content_object): Use
	get_source_file_content rather than maybe_read_file.
	Reject it if it's not valid UTF-8.
	* input.cc (file_cache_slot::get_full_file_content): New.
	(get_source_file_content): New.
	(selftest::check_cpp_valid_utf8_p): New.
	(selftest::test_cpp_valid_utf8_p): New.
	(selftest::input_cc_tests): Call selftest::test_cpp_valid_utf8_p.
	* input.h (get_source_file_content): New prototype.

gcc/testsuite/ChangeLog:
	PR analyzer/109098
	* c-c++-common/diagnostic-format-sarif-file-1.c: Add
	verify-sarif-file directive.
	* c-c++-common/diagnostic-format-sarif-file-2.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-3.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-4.c: Likewise.
	* c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: New
	test case, adapted from Wbidi-chars-1.c.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c:
	New test case.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-2.c:
	New test case.
	* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-3.c:
	New test case, adapted from cpp/Winvalid-utf8-1.c.
	* c-c++-common/diagnostic-format-sarif-file-valid-CP850.c: New
	test case, adapted from gcc.dg/diagnostic-input-charset-1.c.
	* gcc.dg/plugin/crash-test-ice-sarif.c: Add verify-sarif-file
	directive.
	* gcc.dg/plugin/crash-test-write-though-null-sarif.c: Likewise.
	* gcc.dg/plugin/diagnostic-test-paths-5.c: Likewise.
	* lib/scansarif.exp (verify-sarif-file): New procedure.
	* lib/verify-sarif-file.py: New support script.

libcpp/ChangeLog:
	PR analyzer/109098
	* charset.cc (cpp_valid_utf8_p): New function.
	* include/cpplib.h (cpp_valid_utf8_p): New prototype.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

gcc/ChangeLog:
	* doc/analyzer.texi (Debugging the Analyzer): Add notes on useful
	debugging options.
	(Special Functions for Debugging the Analyzer): Convert to a
	table, and rewrite in places.
	(Other Debugging Techniques): Add notes on how to compare two
	different exploded graphs.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

The PR109086 r13-6690 inline_string_cmp change to
      if (diff != result)
        emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go,  -O2 -g  (internal compiler error: in emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp as pure as other FEs,
so we ended up with
  __builtin_memcmp (whatever, whateverelse, somesize);
in the IL before expansion and the expansion ICEd on it.
As the builtin calls a library function which is pure or is inline expanded
as such, not marking it pure is an unnecessary pessimization from the FE
side, keeping such dead calls in the IL if they aren't needed will not help
anything.

The following patch fixes that.  Initially I've added just DECL_PURE_P to
it, but that unfortunately broke bootstrap, for __builtin_memcmp there is
also __builtin_memcmp_eq registered by the middle-end code if not registered
earlier and that one is registered with the usual flags (pure, nothrow,
leaf), so if __builtin_memcmp from FE was just pure, it would appear in the
IL as that it can raise exceptions and when folded into __builtin_memcmp_eq
all of sudden it couldn't and we'd ICE in verification.

I think tons of functions should have builtin_nothrow as well, but changing
that wasn't necessary for this fix.

2023-03-24  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/109258
	* go-gcc.cc (Gcc_backend): Add new static data members builtin_pure
	and builtin_nothrow.
	(Gcc_backend::Gcc_backend): Pass builtin_pure | builtin_nothrow for
	BUILT_IN_MEMCMP.
	(Gcc_backend::define_builtin): Handle builtin_pure and builtin_nothrow
	in flags.

gcc/fortran/ChangeLog:

	* expr.cc (free_expr0): Free also BOZ strings as part of an expression.

Here when resolving the implicit object for '&wrapped' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype(&wrapped) wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

	PR c++/106969

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
	and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

	* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
	C++98 mode.
	* g++.dg/lookup/this2.C: New test.

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Load-AcquirePC semantics similar to LDAPR,
which is less restrictive than what __ATOMIC_SEQ_CST requires.  This patch
fixes this and adds comments to make it easier to see which sequence is
used for each case.  Use a load/store exclusive loop for store to simplify
testing memory ordering is correct (it is slightly faster too).

libatomic/
	PR libgcc/108891
	* config/linux/aarch64/atomic_16.S: Fix libat_load_16_i1.
	Add comments describing the memory order.

libgomp/
	* libgomp.texi (Offload-Target Specifics): Grammar fix.

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the case
for partial ordering.

	PR c++/105481

gcc/cp/ChangeLog:

	* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.

Follow-up to commit 49d1a2f9
"OpenMP: Handle descriptors in target's firstprivate [PR104949]".

	PR fortran/104949
	libgomp/
	* target.c (gomp_map_vars_internal) <GOMP_MAP_FIRSTPRIVATE>: Add
	caveat/safeguard.