Commit 0990d93d ("IBM Z: Use @PLT symbols for local functions in
64-bit mode") made GCC call both static and non-static functions and
load both static and non-static function addresses with the @PLT
suffix.  This made it difficult for linkers to distinguish calling and
address taking instructions [1].  It is currently assumed that the
R_390_PLT32DBL relocation, corresponding to the @PLT suffix, is used
only for calling, and the R_390_PC32DBL relocation, corresponding to
the empty suffix, is used only for address taking.

Linkers needs to make this distinction in order to decide whether to
ask ld.so to use canonical PLT entries.  Normally GOT entries in shared
objects contain addresses of the respective functions, with one notable
exception: when a no-pie executable calls the respective function and
also takes its address.  Such executables assume that all addresses are
known in advance, so they use addresses of the respective PLT entries.
For consistency reasons, all respective GOT entries in the process must
also use them.

When a linker sees that a no-pie executable both calls a function and
also takes its address, it creates a PLT entry and asks ld.so to
consider it canonical by setting the respective undefined symbol's
address, which is normally 0, to the address of this PLT entry.

Improve the situation by not using @PLT with larl.

Now that @PLT is not used with larl, also drop the 31-bit handling,
which was required because 31-bit PLT entries require %r12 to point to
the respective object's GOT, and this requirement is not satisfied when
calling them by pointer from another object.

Also drop the weak symbol handling, which was required because it is
not possible to load an undefined weak symbol address (0) using larl.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29655

gcc/ChangeLog:

	* config/s390/s390.cc (print_operand): Remove the no longer
	necessary 31-bit and weak symbol handling.
	* config/s390/s390.md (*movdi_64): Do not use @PLT with larl.
	(*movsi_larl): Likewise.
	(main_base_64): Likewise.
	(reload_base_64): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/s390/call-z10-pic-nodatarel.c: Adjust
	expectations.
	* gcc.target/s390/call-z10-pic.c: Likewise.
	* gcc.target/s390/call-z10.c: Likewise.
	* gcc.target/s390/call-z9-pic-nodatarel.c: Likewise.
	* gcc.target/s390/call-z9-pic.c: Likewise.
	* gcc.target/s390/call-z9.c: Likewise.

We currently emit an incorrect -Woverloaded-virtual warning upon the
following test case

=== cut here ===
struct A {
  virtual operator int() { return 42; }
  virtual operator char() = 0;
};
struct B : public A {
  operator char() { return 'A'; }
};
=== cut here ===

The problem is that when iterating over ovl_range (fns), warn_hidden
gets confused by the conversion operator marker, concludes that
seen_non_override is true and therefore emits a warning for all
conversion operators in A that do not convert to char, even if
-Woverloaded-virtual is 1 (e.g. with -Wall, the case reported).

A second set of problems is highlighted when -Woverloaded-virtual is 2.

First, with the same test case, since base_fndecls contains all
conversion operators in A (except the one to char, that's been removed
when iterating over ovl_range (fns)), we emit a spurious warning for
the conversion operator to int, even though it's unrelated.

Second, in case there are several conversion operators with different
cv-qualifiers to the same type in A, we rightfully emit a warning,
however the note uses the location of the conversion operator marker
instead of the right one; location_of should go over conv_op_marker.

This patch fixes all these by explicitly keeping track of (1) base
methods that are overriden, as well as (2) base methods that are hidden
but not overriden (and by what), and warning about methods that are in
(2) but not (1). It also ignores non virtual base methods, per
"definition" of -Woverloaded-virtual.

Co-authored-by: Jason Merrill <jason@redhat.com>

	PR c++/117114
	PR c++/109918

gcc/cp/ChangeLog:

	* class.cc (warn_hidden): Keep track of overloaded and of hidden
	base methods.
	* error.cc (location_of): Skip over conv_op_marker.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Woverloaded-virt1.C: Check that no warning is
	emitted for non virtual base methods.
	* g++.dg/warn/Woverloaded-virt10.C: New test.
	* g++.dg/warn/Woverloaded-virt11.C: New test.
	* g++.dg/warn/Woverloaded-virt12.C: New test.
	* g++.dg/warn/Woverloaded-virt13.C: New test.
	* g++.dg/warn/Woverloaded-virt5.C: New test.
	* g++.dg/warn/Woverloaded-virt6.C: New test.
	* g++.dg/warn/Woverloaded-virt7.C: New test.
	* g++.dg/warn/Woverloaded-virt8.C: New test.
	* g++.dg/warn/Woverloaded-virt9.C: New test.

When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI.  Punt in this case.

	PR tree-optimization/117113
	* gimple-loop-jam.cc (unroll_jam_possible_p): Detect when
	we cannot handle virtual SSA update.

	* gcc.dg/torture/pr117113.c: New testcase.

We currently ICE in checking mode with cxx_dialect < 17 on the following
valid code

=== cut here ===
struct X {
  X(const X&) {}
};
extern X x;
void foo () {
  new X[1]{x};
}
=== cut here ===

We trip on a gcc_checking_assert in cp_gimplify_expr due to a
TARGET_EXPR that is not TARGET_EXPR_ELIDING_P. As pointed by Jason, the
problem is that build_vec_init does not recognize that digest_init has
been called, and we end up calling the copy constructor twice.

This happens because the detection in build_vec_init assumes that BASE
is a reference to the array, while it's a pointer to its first element
here. This patch makes sure that the detection works in both cases.

	PR c++/114619

gcc/cp/ChangeLog:

	* init.cc (build_vec_init): Properly determine whether
	digest_init has been called.

gcc/testsuite/ChangeLog:

	* g++.dg/init/no-elide4.C: New test.

As mentioned in the PR, this pedwarni is desirable for the implicit or
explicit capturing of structured bindings in C++17, but in the case of
init-captures the initializer is just some expression and that can include
structured bindings.

So, the following patch limits the warning to non-explicit_init_p.

2025-02-04  Jakub Jelinek  <jakub@redhat.com>

	PR c++/118719
	* lambda.cc (add_capture): Only pedwarn about capturing structured
	binding if !explicit_init_p.

	* g++.dg/cpp1z/decomp63.C: New test.

r15-4317-ga6f4404689f12 tried to add support for widending optabs
for vec-mode -> scalar-mode but it misunderstood how FOR_EACH_MODE worked,
the limit in this case is not inclusive. Which means setting limit to from,
would cause the loop not be executed at all. This fixes by setting the
limit to be the next mode after from mode.

Note the original version that added the widening optabs for vec-mode -> scalar-mode
(https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665021.html) didn't have this
bug, only the second version with suggested change
(https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665068.html

) dud. The suggested
change missed this issue with FOR_EACH_MODE.

Bootstrapped and tested on x86_64-linux-gnu.

	PR middle-end/116926

gcc/ChangeLog:

	* optabs-query.cc (find_widening_optab_handler_and_mode): Fix
	limit for `vec-mode -> scalar-mode` case.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

gcc/fortran/ChangeLog:

	* arith.cc (arith_power): Handle modular arithmetic for
	BT_UNSIGNED.
	(eval_intrinsic):  Error for unsigned exponentiation with
	-pedantic.
	* expr.cc (gfc_type_convert_binary): Use type of first
	argument for unsigned exponentiation.
	* gfortran.texi: Mention arithmetic exponentiation.
	* resolve.cc (resolve_operator): Allow unsigned exponentiation.
	* trans-decl.cc (gfc_build_intrinsic_function_decls): Build
	declarations for unsigned exponentiation.
	* trans-expr.cc (gfc_conv_cst_uint_power): New function.
	(gfc_conv_power_op): Call it.  Handle unsigned exponentiation.
	* trans.h (gfor_fndecl_unsigned_pow_list):  Add declaration.

libgfortran/ChangeLog:

	* Makefile.am: Add files for unsigned exponentiation.
	* Makefile.in: Regenerate.
	* gfortran.map: Add functions for unsigned exponentiation.
	* generated/pow_m16_m1.c: New file.
	* generated/pow_m16_m16.c: New file.
	* generated/pow_m16_m2.c: New file.
	* generated/pow_m16_m4.c: New file.
	* generated/pow_m16_m8.c: New file.
	* generated/pow_m1_m1.c: New file.
	* generated/pow_m1_m16.c: New file.
	* generated/pow_m1_m2.c: New file.
	* generated/pow_m1_m4.c: New file.
	* generated/pow_m1_m8.c: New file.
	* generated/pow_m2_m1.c: New file.
	* generated/pow_m2_m16.c: New file.
	* generated/pow_m2_m2.c: New file.
	* generated/pow_m2_m4.c: New file.
	* generated/pow_m2_m8.c: New file.
	* generated/pow_m4_m1.c: New file.
	* generated/pow_m4_m16.c: New file.
	* generated/pow_m4_m2.c: New file.
	* generated/pow_m4_m4.c: New file.
	* generated/pow_m4_m8.c: New file.
	* generated/pow_m8_m1.c: New file.
	* generated/pow_m8_m16.c: New file.
	* generated/pow_m8_m2.c: New file.
	* generated/pow_m8_m4.c: New file.
	* generated/pow_m8_m8.c: New file.
	* m4/powu.m4: New file.

gcc/testsuite/ChangeLog:

	* gfortran.dg/unsigned_15.f90: Adjust error messages.
	* gfortran.dg/unsigned_43.f90: New test.
	* gfortran.dg/unsigned_44.f90: New test.

The following checks we have a scalar int shift mode before
enforcing it.  As AVR shows the mode can be a signed _Accum mode
as well.

	PR rtl-optimization/117611
	* combine.cc (simplify_shift_const_1): Bail if not
	scalar int mode.

	* gcc.dg/fixed-point/pr117611.c: New testcase.

When we process function types we strip volatile and const qualifiers
after building a simplified type variant (which preserves those).
The qualified type handling of both isn't really compatible, so avoid
bad interaction by swapping this, first dropping const/volatile
qualifiers and then building the simplified type thereof.

	PR lto/113207
	* ipa-free-lang-data.cc (free_lang_data_in_type): First drop
	const/volatile qualifiers from function argument types,
	then build a simplified type.

	* gcc.dg/pr113207.c: New testcase.

Modules makes some assumptions about types that currently aren't
fulfilled by the types created in contracts logic.  This patch ensures
that exporting inline functions using contracts works again with
modules.

	PR c++/108205

gcc/cp/ChangeLog:

	* contracts.cc (get_pseudo_contract_violation_type): Give names
	to generated FIELD_DECLs.
	(declare_handle_contract_violation): Mark contract_violation
	type as external linkage.
	(build_contract_handler_call): Ensure any builtin declarations
	created here aren't treated as attached to the current module.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/contracts-5_a.C: New test.
	* g++.dg/modules/contracts-5_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

'start_cleanup_fn' is not currently viable in modules, due to generating
functions relying on the 'start_cleanup_cnt' counter which is reset to 0
with each new TU.  This means that cleanup functions declared in a TU
will conflict with any imported cleanup functions.

This patch mitigates the problem by using the mangled name of the decl
we're destroying as part of the name of the function.  This should avoid
clashes unless the decls would have clashed anyway.

	PR c++/98893

gcc/cp/ChangeLog:

	* decl.cc (start_cleanup_fn): Make name from the mangled name of
	the passed-in decl.
	(register_dtor_fn): Pass decl to start_cleanup_fn.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/pr98893_a.H: New test.
	* g++.dg/modules/pr98893_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

For non-type parameter packs when unifying the arguments in
unify_pack_expansion it iterates over the associated packs of a param so
that when it recursively unifies the param with the arguments it knows
which targs have been populated with parameter pack arguments that it can
then collect up. This change adds a tree walk so that in the example above
it reaches ...A and adds it to the associated packs for ...B and therefore
knows it will have been set in targs in unify_pack_expansion and processes
it as per other pack arguments.

	PR c++/118265

gcc/cp/ChangeLog:

	* pt.cc (find_parameter_packs_r) <case TEMPLATE_PARM_INDEX>:
	Walk into the type of a parameter pack.

Signed-off-by: Adam J Ryan <gcc.gnu.org@ajryansolutions.co.uk>

Awaiters always need to have a coroutine state frame copy since
they persist across potential supensions.  It simplifies the later
analysis considerably to assign these early which we do when
building co_await expressions.

The cleanups in r15-3146-g47dbd69b1, unfortunately elided some of
processing used to cater for cases where the var created from an
xvalue, or is a pointer/reference type.

Corrected thus.

	PR c++/116506
	PR c++/116880

gcc/cp/ChangeLog:

	* coroutines.cc (build_co_await): Ensure that xvalues are
	materialised.  Handle references/pointer values in awaiter
	access expressions.
	(is_stable_lvalue): New.
	* decl.cc (cxx_maybe_build_cleanup): Handle null arg.

gcc/testsuite/ChangeLog:

	* g++.dg/coroutines/pr116506.C: New test.
	* g++.dg/coroutines/pr116880.C: New test.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Co-authored-by: Jason Merrill <jason@redhat.com>

The implementation of extended range-for temporaries in r15-3840 confused
coroutines, because await_statement_walker and the like get confused by the
EXPR_STMT into thinking that the whole for-loop is a single expression
statement and try to process it accordingly.  Fixing this seems to be a
simple matter of dropping the EXPR_STMT.

	PR c++/116914
	PR c++/117231
	PR c++/118470
	PR c++/118491

gcc/cp/ChangeLog:

	* semantics.cc (finish_for_stmt): Don't wrap the result of
	pop_stmt_list in EXPR_STMT.

gcc/testsuite/ChangeLog:

	* g++.dg/coroutines/coro-range-for1.C: New test.

	PR fortran/93289

gcc/fortran/ChangeLog:

	* decl.cc (gfc_set_constant_character_len): Downgrade different
	string lengths in character array constructor to legacy extension.

gcc/testsuite/ChangeLog:

	* gfortran.dg/unlimited_polymorphic_1.f03: Pad element in character
	array constructor to correct length.
	* gfortran.dg/char_array_constructor_5.f90: New test.

gcc/ChangeLog:

	* config/i386/i386.md (*sibcall_pop_memory):
	Disable for TARGET_INDIRECT_BRANCH_REGISTER
	* config/i386/predicates.md (call_insn_operand): Enable when
	"satisfies_constraint_Bw (op)" is true, instead of open-coding
	constraint here.
	(sibcall_insn_operand): Ditto with "satisfies_constraint_Bs (op)"

This patch fixes the dupq_* testsuite failures.  The tests were
introduced with r15-3669-ga92f54f580c3 (which was a nice improvement)
and Pengxuan originally had a follow-on patch to recognise INDEX
constants during vec_init.

I'd originally wanted to solve this a different way, using wildcards
when building a vector and letting vector_builder::finalize find the
best way of filling them in.  I no longer think that's the best
approach though.  Stepped constants are likely to be more expensive
than unstepped constants, so we should first try finding an unstepped
constant that is valid, even if it has a longer representation than
the stepped version.

This patch therefore uses a variant of Pengxuan's idea.

While there, I noticed that the (old) code for finding an unstepped
constant only tried varying one bit at a time.  So for index 0 in a
16-element constant, the code would try picking a constant from index 8,
4, 2, and then 1.  But since the goal is to create "fewer, larger,
repeating parts", it would be better to iterate over a bit-reversed
increment, so that after trying an XOR with 0 and 8, we try adding 4
to each previous attempt, then 2 to each previous attempt, and so on.
In the previous example this would give 8, 4, 12, 2, 10, 6, 14, ...

The test shows an example of this for 8 shorts.

gcc/
	* config/aarch64/aarch64.cc (aarch64_choose_vector_init_constant):
	New function, split out from...
	(aarch64_expand_vector_init_fallback): ...here.  Use a bit-
	reversed increment to find a constant index.  Add support for
	stepped constants.

gcc/testsuite/
	* gcc.target/aarch64/sve/acle/general/dupq_12.c: New test.

LRA does not correctly support hard-register input operands that
are clobbered.  This is needed to support millicode calls on hppa.
The operand setup is sometimes deleted.

This problem can be avoided by hiding hard-register input operands
using match_operand.  This also potentially allows for constraints
that specify the operand is both read and written.

2025-02-03  John David Anglin  <danglin@gcc.gnu.org>

gcc/ChangeLog:

	PR rtl-optimization/117248
	* config/pa/predicates.md (r25_operand): New predicate.
	(r26_operand): Likewise.
	* config/pa/pa.md: Use match_operand for r25 and r26 hard
	register operands in mult, div, udiv, mod and umod millicode
	patterns.

The first argument is supposed to be a type, not a decl.

	PR c++/79786
gcc/cp/
	* rtti.cc (emit_tinfo_decl): Fix DATA_ABI_ALIGNMENT invocation.

When we sink common stores in cselim or the sink pass we have to
make sure to not introduce overlapping lifetimes for abnormals
used in the ref.  The easiest is to avoid sinking stmts which
reference abnormals at all which is what the following does.

	PR tree-optimization/118717
	* tree-ssa-phiopt.cc (cond_if_else_store_replacement_1):
	Do not common stores referencing abnormal SSA names.
	* tree-ssa-sink.cc (sink_common_stores_to_bb): Likewise.

	* gcc.dg/torture/pr118717.c: New testcase.

v2: Remove extra {}

gcc/ChangeLog:

	* input.cc (check_line): New.
	(test_replacement): New function to test line caching.
	(input_cc_tests): Call test_replacement

While the input line cache size now tunable it's better if the compiler
auto tunes it. Otherwise large files needing random file access will
still have to search many lines to find the right lines.

Add support for allocating one line anchor per hundred input lines.
This means an overhead of ~235k per 1M input lines on 64bit, which
seems reasonable.

gcc/ChangeLog:

	PR preprocessor/118168
	* input.cc (file_cache_slot::get_next_line): Implement
	dynamic sizing of m_line_record based on input length.
	* params.opt: (param_file_cache_lines): Set to 0 to size
	dynamically.

With the new cache maintenance algorithm we don't need the
maximum number of lines anymore. Remove all the code for that.

gcc/ChangeLog:

	PR preprocessor/118168
	* input.cc (total_lines_num): Remove.
	(file_cache_slot::evict): Ditto.
	(file_cache_slot::create): Ditto.
	(file_cache_slot::set_content): Ditto.
	(file_cache_slot::file_cache_slot): Ditto.
	(file_cache_slot::dump): Ditto.

The input context file_cache maintains an array of anchors
to speed up accessing lines before the previous line.
The array has a fixed upper size and the algorithm relies
on the linemap reporting the maximum number of lines in the file
in advance to compute the position of each anchor in the cache.

This doesn't work for C which doesn't know the maximum number
of lines before the files has finished parsing. The code
has a fallback for this, but it is quite inefficient and
effectively defeats the cache, so many accesses have to
go through most of the input buffer to compute line
boundaries. For large files this can be very costly
as demonstrated in PR118168.

Use a different algorithm to maintain the cache without
needing the maximum number of lines in advance. When the cache
runs out of entries and the gap to the last line anchor gets
too large, prune every second entry in the cache. This maintains
even spacing of the line anchors without requiring the maximum
index.

For the original PR this moves the overhead of enabling
-Wmisleading-indentation to 32% with the default cache size.
With a 10k entry cache it becomes noise.

  cc1 -O0 -fsyntax-only mypy.c   -quiet  ran
    1.03 ± 0.05 times faster than cc1 -O0 -fsyntax-only  mypy.c   -quiet -Wmisleading-indentation --param=file-cache-lines=10000
    1.09 ± 0.08 times faster than cc1 -O0 -fsyntax-only  mypy.c   -quiet -Wmisleading-indentation --param=file-cache-lines=1000
    1.32 ± 0.07 times faster than cc1 -O0 -fsyntax-only  mypy.c   -quiet -Wmisleading-indentation

The code could be further optimized, e.g. use the vectorized
line search functions the preprocessor uses.

Also it seems the input cache always reads the whole file into
memory, so perhaps it should just be using file mmap if possible.

gcc/ChangeLog:

	PR preprocessor/118168
	* input.cc (file_cache_slot::get_next_line): Use new algorithm
	to maintain
	(file_cache_slot::read_line_num): Use binary search for lookup.

The input machinery to read the source code independent of the lexer
has a range of hard coded maximum array sizes that can impact performance.
Make them tunable.

input.cc is part of libcommon so it cannot direct access params
without a level of indirection.

gcc/ChangeLog:

	PR preprocessor/118168
	* input.cc (file_cache::tune): New function.
	* input.h (class file_cache): Make tunables non const.
	* params.opt: Add new tunables.
	* toplev.cc (toplev::main): Initialize input buffer context
	tunables.

This patch adds a new section to the gm2 documentation and new
corresponding testcode to the regression testsuite.

gcc/ChangeLog:

	PR modula2/117411
	* doc/gm2.texi (Exception handling): New section.
	(The ISO system module): Add description of COFF_T.
	(Assembler language): Tidy up last sentance.

gcc/testsuite/ChangeLog:

	PR modula2/117411
	* gm2/iso/run/pass/except9.mod: New test.
	* gm2/iso/run/pass/lazyunique.mod: New test.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

At the end of a sequence like:
 #pragma GCC push_options
 ...
 #pragma GCC pop_options

the handler for pop_options calls cl_optimization_compare() (as generated by
optc-save-gen.awk) to make sure that all global state has been restored to
the value it had prior to the push_options call. The verification is
performed for almost all entries in the global_options struct. This leads to
unexpected checking asserts, as discussed in the PR, in case the state of
warnings-related options has been intentionally modified in between
push_options and pop_options via a call to #pragma GCC diagnostic. Address
that by skipping the verification for CL_WARNING-flagged options.

gcc/ChangeLog:

	PR middle-end/115913
	* optc-save-gen.awk (cl_optimization_compare): Skip options with
	CL_WARNING flag.

gcc/testsuite/ChangeLog:

	PR middle-end/115913
	* c-c++-common/cpp/pr115913.c: New test.

Add a test for the target independent bug, PR rtl-optimization/111673.

	PR rtl-optimization/111673
	* gcc.target/i386/pr111673.c: New file.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Update

commit dd6247cb
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jan 31 12:29:04 2025 +0800

    x86: Handle TARGET_INDIRECT_BRANCH_REGISTER for -fno-plt

to change "if (TARGET_X32 ...)" back to "else if (TARGET_X32 ...)".

	PR target/118713
	* config/i386/i386-expand.cc (ix86_expand_call): Change "if
	(TARGET_X32 ...)" back to "else if (TARGET_X32 ...)".

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

This patch builds access to the gcc builtins clz, clzl, clzll,
ctz, ctzl and ctzll within m2builtins.cc.  The patch provides
modula2 api access to clz, clzll, ctz and ctzll though the
Builtins definition module.  This PR was raised because of
PR118689.

gcc/m2/ChangeLog:

	PR modula2/118703
	* gm2-gcc/m2builtins.cc (define_builtin_gcc): New function.
	(m2builtins_init): Call define_builtin_gcc.
	* gm2-libs/Builtins.def (clz): New procedure function.
	(clzll): Ditto.
	(ctz): Ditto.
	(ctzll): Ditto.
	* gm2-libs/Builtins.mod (clz): New procedure function.
	(clzll): Ditto.
	(ctz): Ditto.
	(ctzll): Ditto.
	* gm2-libs/cbuiltin.def (clz): New procedure function.
	(clzll): Ditto.
	(ctz): Ditto.
	(ctzll): Ditto.

gcc/testsuite/ChangeLog:

	PR modula2/118703
	* gm2/builtins/run/pass/testbitfns.mod: New test.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

If TARGET_INDIRECT_BRANCH_REGISTER is true, indirect call and jump should
use register, not memory.  Update Bs, Bw and Bz constraints to disable
indirect call over memmory if TARGET_INDIRECT_BRANCH_REGISTER true, change
x32 call over GOT slot to call over register and also disable sibcall
over memory.

gcc/

	PR target/118713
	* config/i386/constraints.md (Bs): Always disable if
	TARGET_INDIRECT_BRANCH_REGISTER is true.
	(Bw): Likewise.
	* config/i386/i386-expand.cc (ix86_expand_call): Force indirect
	call via register for x32 GOT slot call if
	TARGET_INDIRECT_BRANCH_REGISTER is true.
	* config/i386/i386-protos.h (ix86_nopic_noplt_attribute_p): New.
	* config/i386/i386.cc (ix86_nopic_noplt_attribute_p): Make it
	global.
	* config/i386/i386.md (*call_got_x32): Disable indirect call via
	memory for TARGET_INDIRECT_BRANCH_REGISTER.
	(*call_value_got_x32): Likewise.
	(*sibcall_value_pop_memory): Likewise.
	* config/i386/predicates.md (constant_call_address_operand):
	Return false if both TARGET_INDIRECT_BRANCH_REGISTER and
	ix86_nopic_noplt_attribute_p are true.

gcc/testsuite/

	PR target/118713
	* gcc.target/i386/pr118713-1-x32.c: New test.
	* gcc.target/i386/pr118713-1.c: Likewise.
	* gcc.target/i386/pr118713-2-x32.c: Likewise.
	* gcc.target/i386/pr118713-2.c: Likewise.
	* gcc.target/i386/pr118713-3-x32.c: Likewise.
	* gcc.target/i386/pr118713-3.c: Likewise.
	* gcc.target/i386/pr118713-4-x32.c: Likewise.
	* gcc.target/i386/pr118713-4.c: Likewise.
	* gcc.target/i386/pr118713-5-x32.c: Likewise.
	* gcc.target/i386/pr118713-5.c: Likewise.
	* gcc.target/i386/pr118713-6-x32.c: Likewise.
	* gcc.target/i386/pr118713-6.c: Likewise.
	* gcc.target/i386/pr118713-7-x32.c: Likewise.
	* gcc.target/i386/pr118713-7.c: Likewise.
	* gcc.target/i386/pr118713-8-x32.c: Likewise.
	* gcc.target/i386/pr118713-8.c: Likewise.
	* gcc.target/i386/pr118713-9-x32.c: Likewise.
	* gcc.target/i386/pr118713-9.c: Likewise.
	* gcc.target/i386/pr118713-10-x32.c: Likewise.
	* gcc.target/i386/pr118713-10.c: Likewise.
	* gcc.target/i386/pr118713-11-x32.c: Likewise.
	* gcc.target/i386/pr118713-11.c: Likewise.
	* gcc.target/i386/pr118713-12-x32.c: Likewise.
	* gcc.target/i386/pr118713-12.c: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Some SARIF files offload most of the properties within logical locations
in the results to an array of "cached" instances in
theRun.logicalLocations, so the information can be consolidated (and to
support the "parentIndex" property, which is PR 116176).

Support such files in sarif-replay.

gcc/ChangeLog:
	* libsarifreplay.cc (sarif_replayer::handle_run_obj): Pass run to
	handle_result_obj.
	(sarif_replayer::handle_result_obj): Add run_obj param and pass it
	to handle_location_object and handle_thread_flow_object.
	(sarif_replayer::handle_thread_flow_object): Add run_obj param and
	pass it to handle_thread_flow_location_object.
	(sarif_replayer::handle_thread_flow_location_object): Add run_obj
	param and pass it to handle_location_object.
	(sarif_replayer::handle_location_object): Add run_obj param and
	pass it to handle_logical_location_object.
	(sarif_replayer::handle_logical_location_object): Add run_obj
	param.  If the run_obj is non-null and has "logicalLocations",
	then use these "cached" logical locations if we see an "index"
	property, as per §3.33.3

gcc/testsuite/ChangeLog:
	* sarif-replay.dg/2.1.0-invalid/3.33.3-index-out-of-range.sarif:
	New test.
	* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Update expected
	output to reflect that we now find the function name for the
	events in the path.

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

...of derived real type.  It comes from an unexpected internal adjustment.

gcc/ada/
	PR ada/118712
	* sem_warn.adb (Check_References): Deal with small adjustments of
	references.

gcc/testsuite/
	* gnat.dg/warn33.adb: New test.
	* gnat.dg/warn33_pkg.ads: New helper.

Verify that -mstack-protector-guard=global works on x86.  Default stack
protector uses TLS.  -mstack-protector-guard=global uses a global variable,
__stack_chk_guard, instead of TLS.

	* gcc.target/i386/ssp-global.c: New file.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

[committed][PR tree-optimization/114277] Fix missed optimization for multiplication against boolean value

Andrew, Raphael and I have all poked at it in various ways over the last year
or so.  I think when Raphael and I first looked at it I sent us down a bit of
rathole.

In particular it's odd that we're using a multiply to implement a select and it
seemed like recognizing the idiom and rewriting into a conditional move was the
right path.  That looked reasonably good for the test, but runs into problems
with min/max detection elsewhere.

I think that initial investigation somewhat polluted our thinking.  The
regression can be fixed with a fairly simple match.pd pattern.

Essentially we want to handle

x * (x || b) -> x
x * !(x || b) -> 0

There's simplifications that can be made for "&&" cases, but I haven't seen
them in practice.  Rather than drop in untested patterns, I'm leaving that as a
future todo.

My original was two match.pd patterns.  Andrew combined them into a single
pattern.  I've made this conditional on GIMPLE as an earlier version that
simplified to a conditional move showed that when applied on GENERIC we could
drop an operand with a side effect which is clearly not good.

I've bootstrapped and regression tested this on x86.  I've also tested on the
various embedded targets in my tester.

	PR tree-optimization/114277
gcc/
	* match.pd (a * (a || b) -> a): New pattern.
	(a * !(a || b) -> 0): Likewise.

gcc/testsuite
	* gcc.target/i386/pr114277.c: New test.
	* gcc.target/riscv/pr114277.c: Likewise.

	Co-author:  Andrew Pinski <quic_apinski@quicinc.com>

compare_operand uses operand_equal_p under the hood, which e.g. for
INTEGER_CSTs will just match the values rather regardless of their types.
Now, in many comparing the type is redundant, if we have
  x_2 = y_3 + 1;
we've already compared the type for the lhs and also for rhs1, there won't
be any surprises on rhs2.
As noted in the PR, there are cases where the type of the operand is the
sole place of information and we don't want to ICF merge functions if the
types differ.
One case is stdarg functions, arguments passed to ..., it is different
if we pass 1, 1L, 1LL.
Another case are the K&R unprototyped functions (sure, gone in C23).
And yet another case are inline asm operands, "r" (1) is different from "r"
(1L) from "r" (1LL).

So, the following patch determines based on lack of fntype (e.g. for
internal functions), or on !prototype_p, or on stdarg_p (in that case
using number of named arguments) which arguments need to have type checked
and does that, plus compares types on inline asm operands (maybe it would be
enough to do that just for input operands but we have just a routine to
handle both and I didn't feel we need to differentiate).

Furthermore, I've noticed fntype{1,2} isn't actually compared if it is a
direct call (gimple_call_fndecl is non-NULL).  That is wrong too, we could
have
  void (*fn) (int, long long) = (void (*) (int, long long)) foo;
  fn (1, 1LL);
in one case and
  void (*fn) (long long, int) = (void (*) (long long, int)) foo;
  fn (1LL, 1);
in another, both folded into a direct call of foo with different
gimple_call_fntype.  Sure, one of them would be UB at runtime (or both), but
what if we ICF merge it into something that into the one UB at runtime
and the program actually calls the correct one only?

2025-02-01  Jakub Jelinek  <jakub@redhat.com>

	PR ipa/117432
	* ipa-icf-gimple.cc (func_checker::compare_asm_inputs_outputs):
	Also return_false if operands have incompatible types.
	(func_checker::compare_gimple_call): Check fntype1 vs. fntype2
	compatibility for all non-internal calls and assume fntype1 and
	fntype2 are non-NULL for those.  For calls to non-prototyped
	calls or for stdarg_p functions after the last named argument (if any)
	check type compatibility of call arguments.

	* gcc.c-torture/execute/pr117432.c: New test.
	* gcc.target/i386/pr117432.c: New test.