| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Merge up to r15-10483-gcc39aed963b5c6 (5 Nov 2025)
|
|
|
|
Fix a bug in the removal code of always false variants in metadirectives.
PR fortran/122570
gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_metadirective): Fix 'skip' of
never matchable metadirective variants.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/pr122570.f: New test.
|
|
|
|
|
|
When a label is matched in the first statement after the end of a metadirective
body, it is bound to the associated region. However this prevents it from being
referenced elsewhere.
This patch fixes it by rebinding such labels to the outer region. It also
ensures that labels defined in an outer region can be referenced in a
metadirective body.
PR fortran/122369
PR fortran/122508
gcc/fortran/ChangeLog:
* gfortran.h (gfc_rebind_label): Declare new function.
* parse.cc (parse_omp_metadirective_body): Rebind labels to the outer
region. Maintain a vector of metadirective regions.
(gfc_parse_file): Initialise it.
* parse.h (GFC_PARSE_H): Declare it.
* symbol.cc (gfc_get_st_label): Look for existing labels in outer
metadirective regions.
(gfc_rebind_label): Define new function.
(gfc_define_st_label): Accept duplicate labels in metadirective body.
(gfc_reference_st_label): Accept shared DO termination labels in
metadirective body.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/pr122369-1.f90: New test.
* gfortran.dg/gomp/pr122369-2.f90: New test.
* gfortran.dg/gomp/pr122369-3.f90: New test.
* gfortran.dg/gomp/pr122369-4.f90: New test.
* gfortran.dg/gomp/pr122508-1.f90: New test.
* gfortran.dg/gomp/pr122508-2.f90: New test.
(cherry picked from commit 7fa8420170b7a8ca40d7414ddcddaed425442cee)
|
|
This patch fixes the following bug:
If the right-hand side of an expression contains a target name
(i.e. "@"), and also contains a reference to a user-defined operator
that is directly visible because of a "use type" clause on a renaming of
the package where the operator is declared, the compiler gives an
incorrect error saying that the renamed package is not visible.
It turns out that setting Entity of resolved nodes is unnecessary
and wrong; the fix is to simply remove that code.
gcc/ada/ChangeLog:
PR ada/118208
* exp_ch5.adb
(Expand_Assign_With_Target_Names.Replace_Target):
Remove code setting Entity to Empty.
* sinfo.ads (Has_Target_Names):
Improve comment: add "@" to clarify what "target name"
means, and remove the content-free phrase "and must
be expanded accordingly."
|
|
When finding the minimal visibility of a template, any reference to a
dependent automatic variable will cause the instantiation to be marked
as internal linkage. However, when processing the template decl we
don't yet know whether that should actually be the case, as a given
instantiation may not require referencing the local decl in its
mangling.
This patch fixes the issue by checking for no-linkage decls first, in
which case we just constrain using the type of the entity. We can't use
a check for lk_external/lk_internal in the other cases, as
instantiations referring to internal types can still have external
linkage as determined by the language, but should still constrain the
visibility of any declarations that refer to them.
PR c++/122253
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): Don't mark no-linkage declarations
as VISIBILITY_ANON.
gcc/testsuite/ChangeLog:
* g++.dg/modules/internal-16.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit f062a6b7985fcee82e02b626aada4e0824850bd0)
|
|
|
|
ira_reg_equiv array
So another case where we're indexing into the ira_reg_equiv array without
checking bounds. I sincerely hope we're not playing wack-a-mole here, but two
failures in a couple months for the same core problem is worrisome.
Bootstrapped and regression tested on x86_64 and riscv64 as well as run through
all the embedded targets in my tester without regressions.
PR rtl-optimization/122321
gcc/
* lra-constraints.cc (update_equiv): Make sure REGNO is in
ira_reg_equiv before trying to update ira_reg_equiv.
gcc/testsuite/
* gcc.target/riscv/rvv/autovec/pr122321.c: New test.
(cherry picked from commit ac3eeb987ad04923ddc57a9dc9bd4ec98146a981)
|
|
The problem here is that when the backend folds the vset intrinsics,
it tries to keep the lhs of the new statement to be the same as the old statement
due to the check in gsi_replace. The problem is with a MEM_REF vset::fold was
unsharing the new lhs here and using the original lhs in the other new statement.
This meant the check in gsi_replace would fail.
This fixes that oversight by switching around which statement gets the unshared
version.
Note the comment in vset::fold was already correct just not matching the code:
/* Replace the call with two statements: a copy of the full tuple
to the call result, followed by an update of the individual vector.
The fold routines expect the replacement statement to have the
same lhs as the original call, so return the copy statement
rather than the field update. */
Changes since v1:
* v2: Fix testcase.
PR target/122270
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (vset::fold): Use the
unshare_expr for the statement that will be added seperately rather
the one which will be used for the replacement.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr122270-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
(cherry picked from commit 42f5f1004ff16ab25b97d3315a365614c68c6201)
|
|
|
|
This patch fixes a case where a 3 byte or 4 byte load from __flash1
uses __load_3/4 to read the value, which is wrong.
This only occured when the device has ELPM but not ELPMx (avr31).
PR target/122527
gcc/
* config/avr/avr.cc (avr_load_libgcc_p): Return false if
the address-space is not ADDR_SPACE_FLASH.
(avr_out_lpm_no_lpmx [addr=REG]): Handle sizes of 3 and 4 bytes.
(cherry picked from commit 0b2c031cca4017c5f87af519f0977b33b4bcb284)
|
|
Since the PR118012 work-around patch, there is an SImode insn also for
the non-MUL case, but there is no mulpsi3. This makes the middle-end
use the mulsi3 insn for 24-bit multipications like in:
__uint24 mul24 (__uint24 a, __uint24 b)
{
return a * b;
}
which will be compiled to:
mul24:
push r28 ; 34 [c=4 l=1] pushqi1/0
push r29 ; 35 [c=4 l=1] pushqi1/0
in r28,__SP_L__ ; 47 [c=4 l=2] *movhi/7
in r29,__SP_H__
sbiw r28,8 ; 48 [c=8 l=1] *addhi3/2
in __tmp_reg__,__SREG__ ; 38 [c=8 l=5] movhi_sp_r/2
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
/* prologue: function */
/* frame size = 8 */
/* stack size = 10 */
std Y+1,r22 ; 49 [c=4 l=1] movqi_insn/2
std Y+2,r23 ; 50 [c=4 l=1] movqi_insn/2
std Y+3,r24 ; 51 [c=4 l=1] movqi_insn/2
std Y+5,r18 ; 52 [c=4 l=1] movqi_insn/2
std Y+6,r19 ; 53 [c=4 l=1] movqi_insn/2
std Y+7,r20 ; 54 [c=4 l=1] movqi_insn/2
ldd r18,Y+1 ; 55 [c=4 l=1] movqi_insn/3
ldd r19,Y+2 ; 56 [c=4 l=1] movqi_insn/3
ldd r20,Y+3 ; 57 [c=4 l=1] movqi_insn/3
ldd r21,Y+4 ; 58 [c=4 l=1] movqi_insn/3
ldd r22,Y+5 ; 59 [c=4 l=1] movqi_insn/3
ldd r23,Y+6 ; 60 [c=4 l=1] movqi_insn/3
ldd r24,Y+7 ; 61 [c=4 l=1] movqi_insn/3
ldd r25,Y+8 ; 62 [c=4 l=1] movqi_insn/3
call __mulsi3 ; 33 [c=20 l=2] *mulsi3_call_pr118012
/* epilogue start */
adiw r28,8 ; 63 [c=8 l=1] *addhi3/2
in __tmp_reg__,__SREG__ ; 42 [c=8 l=5] movhi_sp_r/2
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
pop r29 ; 43 [c=4 l=1] popqi
pop r28 ; 44 [c=4 l=1] popqi
ret
where the expected code is simply:
mul24:
call __mulpsi3 ; 9 [c=20 l=2] call_value_insn/1
/* epilogue start */
ret ; 24 [c=0 l=1] return
The patch just allows the mulpsi3 insn for the non-MUL case, except for
AVR_TINY which passes the 2nd argument on the stack so no insn can be used.
The change might be beneficial even in the absence of PR118012 because
the __mulpsi3 footprint is leaner than a libcall.
PR tree-optimization/118012
PR tree-optimization/122505
gcc/
* config/avr/avr.md (mulpsi3): Also allow the insn condition
in the case where avropt_pr118012 && !AVR_TINY.
(*mulpsi3): Handle split for the !AVR_HAVE_MUL case.
(*mulpsi3-nomul.libgcc_split, *mulpsi3-nomul.libgcc): New insns.
(cherry picked from commit ad8de026441c3e57c4761b1c595ace92ed21c254)
|
|
The linker error in the PR is caused because when a static is defined
out of the class body, it doesn't yet have a definition and so
read_var_def (which would otherwise have noted it) never gets called.
This instead moves the responsibility for noting class-scope variables
to read_class_def.
PR c++/122421
gcc/cp/ChangeLog:
* module.cc (trees_in::read_var_def): Don't handle class-scope
variables anymore.
(trees_in::read_class_def): Handle them here instead.
gcc/testsuite/ChangeLog:
* g++.dg/modules/inst-6_a.C: New test.
* g++.dg/modules/inst-6_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit fd5c057c2d01346d69119f88ca94debf27842e4e)
|
|
|
|
PR fortran/114023
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_trans_pointer_assignment): Always set dtype
when remapping a pointer. For unlimited polymorphic LHS use
elem_len from RHS.
* trans-intrinsic.cc (gfc_conv_is_contiguous_expr): Extend inline
generated code for IS_CONTIGUOUS for pointer arguments to detect
when span differs from the element size.
gcc/testsuite/ChangeLog:
* gfortran.dg/is_contiguous_5.f90: New test.
(cherry picked from commit 3f8b6373f48af0eabbc2efe04df8f6856add3111)
|
|
Commit r16-518 introduced a change that fixed inquiry references of complex
arrays as argument to the TRANSFER intrinsic by forcing a temporary. The
solution taken however turned out not to be generalizable to component
references of nested derived-type arrays. A better way is the revert that
patch and force the generation of a temporary when the SOURCE expression is
a not simply-contiguous array.
PR fortran/122386
gcc/fortran/ChangeLog:
* dependency.cc (gfc_ref_needs_temporary_p): Revert r16-518.
* trans-intrinsic.cc (gfc_conv_intrinsic_transfer): Force temporary
for SOURCE not being a simply-contiguous array.
gcc/testsuite/ChangeLog:
* gfortran.dg/transfer_array_subref_2.f90: New test.
(cherry picked from commit 2febf3b968329aceeeea7805af98ed98a8c67e75)
|
|
This is used in template conversion operators to determine what type the
user requested.
PR c++/122381
gcc/cp/ChangeLog:
* module.cc (trees_out::core_vals): Write BASELINK_OPTYPE (aka
TREE_CHAIN).
(trees_in::core_vals): Read it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/convop-2_a.H: New test.
* g++.dg/modules/convop-2_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
(cherry picked from commit b466450c6d502557921f03527cc165fb3402aaa9)
|
|
|
|
For
SUBROUTINE a( j, b, c, d )
!GCC$ ATTRIBUTES noinline :: a
COMPLEX*16 b
COMPLEX*16 c( * ), d( * )
DO k = 1, j
c( k ) = - b * CONJG( d( k ) )
END DO
END
we incorrectly generate .IFN_COMPLEX_MUL instead of .IFN_COMPLEX_MUL_CONJ.
The issue happens because in the call to vect_validate_multiplication the
operand vectors are passed by reference and so the stripping of the NEGATE_EXPR
after matching modifies the input vector. If validation fail we flip the
operands and try again. But we've already stipped the negates and so if we
match we would match a normal multiply.
This fixes the API by marking the operands as const and instead pass an explicit
output vec that's to be used. This also reduces the number of copies we were
doing.
With this we now correctly detect .IFN_COMPLEX_MUL_CONJ. Weirdly enough I
couldn't reproduce this with any C example because they get reassociated
differently and always succeed on the first attempt. Fortran is easy to
trigger though so new fortran tests added.
gcc/ChangeLog:
PR tree-optimization/122408
* tree-vect-slp-patterns.cc (vect_validate_multiplication): Cleanup and
document interface.
(complex_mul_pattern::matches, complex_fms_pattern::matches): Update to
new interface.
gcc/testsuite/ChangeLog:
PR tree-optimization/122408
* gfortran.target/aarch64/pr122408_1.f90: New test.
* gfortran.target/aarch64/pr122408_2.f90: New test.
(cherry picked from commit c5fa3d4c88fc4f8799318e463c47941eb52b7546)
|
|
It is wrong that optimize from `if (cond) dest op= 1 << shift` to
`dest op= (cond ? 1 : 0) << shift` when `dest op 0 != dest`.
Like `and`, `mul` or `div`.
And in this optimization `mul` and `div` is optimized to shift.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_expand_conditional_move): Only allow valid binary
op when optimize conditional move.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/conditional-move-opt-1.c: Remove mul.
* gcc.target/loongarch/conditional-move-opt-2.c: Remove and.
* gcc.target/loongarch/conditional-move-opt-3.c: New test.
Co-Authored-By: Peng Fan <fanpeng@loongson.cn>
(cherry picked from commit 824eae920f0f64dd7687c969a2436b129161fdc9)
|
|
|
|
The current implementation of the fnmam4 instruction template requires
the third source operand to be assigned the same hard register as the
target operand, but the constraint is not documented in the instruction
manual or standard template definitions. The current constraint will
generate additional data dependencies and extra instructions.
gcc/ChangeLog:
* config/loongarch/lasx.md (fnma<mode>4): Remove.
* config/loongarch/lsx.md (fnma<mode>4): Remove.
* config/loongarch/simd.md (fnma<mode>4): Simplify and correct.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/fnmam4-vec.c: New test.
(cherry picked from commit 7811fb6fa35fd3c3694eba34fbfc992eed1d3e67)
|
|
|
|
|
|
Since a mem-initializer needs to be able to initialize any base class,
lookup for which is type-only, we in turn need to make mem-initializer-id
qualified name lookup type-only too.
PR c++/122192
gcc/cp/ChangeLog:
* parser.cc (cp_parser_mem_initializer_id): Pass class_type
instead of typename_type to cp_parser_class_name in the
nested-name-specifier case.
gcc/testsuite/ChangeLog:
* g++.dg/template/dependent-base6.C: Verify mem-initializer-id
qualified name lookup is type-only too.
Reported-by: Vincent X
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 97da8fece19caf0277c2be523520d09252821973)
|
|
The r13-6098 change to make TYPENAME_TYPE no longer always ignore
non-type bindings needs another exception: base-specifiers that are
represented as TYPENAME_TYPE, for which lookup must be type-only (by
[class.derived.general]/2). This patch fixes this by giving such
TYPENAME_TYPEs a tag type of class_type rather than typename_type so
that we treat them like elaborated-type-specifiers (another type-only
lookup situation).
PR c++/122192
gcc/cp/ChangeLog:
* decl.cc (make_typename_type): Document base-specifier as
another type-only lookup case.
* parser.cc (cp_parser_class_name): Propagate tag_type to
make_typename_type instead of hardcoding typename_type.
(cp_parser_base_specifier): Pass class_type instead of
typename_type as tag_type to cp_parser_class_name.
gcc/testsuite/ChangeLog:
* g++.dg/template/dependent-base6.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 49ddf362f0a7c1fdeb62f13a852a2fdec9d6fe6d)
|
|
|
|
This fixes a fallout of r16-4540-g80af807e52e4f4 that caused undefined
behaviour.
PR fortran/122439
gcc/fortran/ChangeLog:
* openmp.cc (gfc_resolve_omp_context_selector): Skip selectors that have
OMP_TRAIT_INVALID.
(cherry picked from commit b8a8bb30d950b49beeac17e3495ca78d67278cd7)
|
|
Testcase c-c++-common/gomp/attrs-metadirective-2.c failed in C++ when
OFFLOAD_TARGET_NAMES=nvptx-none. That was caused by label mangling being applied
to the use but not to the declaration.
This is now fixed by mangling the declaration as well.
PR c++/122378
gcc/cp/ChangeLog:
* parser.cc (cp_parser_label_declaration): Mangle label declaration in a
metadirective region.
(cherry picked from commit d9f720f2ce39b56e91209c0283049f8e0ae8e7fc)
|
|
The introduction in r14-3488-ga62c8324e7e31a of OMP_STRUCTURED_BLOCK (to
diagnose invalid intervening code) caused a regression rejecting the valid use
of the Fortran CONTINUE statement to end a collapsed loop.
This patch fixes the incorrect error checking in the OMP lowering pass. It also
fixes a check in the Fortran front end that erroneously rejects a similar
statement in an ordered loop.
Co-authored by: Tobias Burnus <tburnus@baylibre.com>
PR fortran/121452
gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_do): Allow CONTINUE as end statement of a
perfectly nested loop.
gcc/ChangeLog:
* omp-low.cc (check_omp_nesting_restrictions): Accept an
OMP_STRUCTURED_BLOCK in a collapsed simd region and in an ordered loop.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/pr121452-1.c: New test.
* c-c++-common/gomp/pr121452-2.c: New test.
* gfortran.dg/gomp/pr121452-1.f90: New test.
* gfortran.dg/gomp/pr121452-2.f90: New test.
* gfortran.dg/gomp/pr121452-3.f90: New test.
(cherry picked from commit 6b90d56d0c352a151efabe06f81d26faeeb9496f)
|
|
The ICE in the linked PR occurs because we first stream the lambda type
before its keyed decl has been streamed, but the key decl's type depends
on the lambda. And so when streaming the key decl to check for an
existing decl to merge with, merging the key decl itself crashes because
its type has only been partially streamed.
This patch fixes the issue by generalising the existing FIELD_DECL
handling to any class member using the outermost containing TYPE_DECL as
its key type. This way we can guarantee that the key decl has been
streamed before the lambda type is otherwise needed.
PR c++/122310
gcc/cp/ChangeLog:
* module.cc (get_keyed_decl_scope): New function.
(trees_out::get_merge_kind): Use it.
(trees_out::key_mergeable): Use it.
(maybe_key_decl): Key to the containing type for all members.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-12.h: New test.
* g++.dg/modules/lambda-12_a.H: New test.
* g++.dg/modules/lambda-12_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 8212abbeffa69f143808e126f40c67f3eb7e7844)
|
|
|
|
The following testcase ICEs in gcc 15 (and is at least latent in 12-14 too),
because the DEBUG_EXPR_DECL has incorrect mode. It has
TREE_TYPE (orig_use_lhs) type, but TYPE_MODE (type) rather than
TYPE_MODE (TREE_TYPE (orig_use_lhs)) where the two types are sometimes
the same, but sometimes different (same if !has_cast_debug_uses, different
otherwise).
Though, there wouldn't be the this issue if it used the proper API to create
the DEBUG_EXPR_DECL which takes care of everything. This is the sole
spot that doesn't use that API.
Doesn't affect the trunk because the code has been removed and replaced with
different stuff after the libstdc++ ABI change in r16-3474.
Before r15-5557 the mode has been always wrong because this was done only
for has_cast_debug_uses. And the bug has been introduced with r12-5490.
Enough archeology, while it could be fixed by changing the second
SET_DECL_MODE argument, I think it is better to use build_debug_expr_decl.
2025-10-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/122394
* tree-ssa-phiopt.cc (spaceship_replacement): Use
build_debug_expr_decl instead of manually building DEBUG_EXPR_DECL
and getting SET_DECL_MODE wrong.
* g++.dg/opt/pr122394.C: New test.
|
|
vector is not enabled
This is a RISC-V specific failure in the dwarf2 emitter. When vector is not
enabled riscv_convert_vector_chunks sets the riscv_vector_chunks poly_int to
[1, 0].
riscv_dwarf_poly_indeterminite_value pulls out that 0 coefficient and uses that
as FACTOR triggering a divide by zero here:
> /* Add COEFF * ((REGNO / FACTOR) - BIAS) to the value:
> add COEFF * (REGNO / FACTOR) now and subtract
> COEFF * BIAS from the final constant part. */
> constant -= coeff * bias;
> add_loc_descr (&ret, new_reg_loc_descr (regno, 0));
> if (coeff % factor == 0)
> coeff /= factor;
> else
> {
> int amount = exact_log2 (factor);
> gcc_assert (amount >= 0);
> add_loc_descr (&ret, int_loc_descriptor (amount));
> add_loc_descr (&ret, new_loc_descr (DW_OP_shr, 0, 0));
> }
Per Robin's recommendation this patch adjusts
riscv_dwarf_poly_indeterminite_value to never set FACTOR to 0, but instead
detect this case and adjust its value to 1.
That fixes the ICE and looks good across the board in my tester. Waiting on
pre-commit CI, of course.
PR target/120674
gcc/
* config/riscv/riscv.cc (riscv_dwarf_poly_indeterminite_value): Do not
set FACTOR to zero, for that case use one instead.
gcc/testsuite
* gcc.target/riscv/pr120674.c: New test.
(cherry picked from commit a92369a6be95c8df1525b02635b9e7c16fc3640e)
|
|
without gp [PR121604]
In PR121604 the problem was noted that currently the SVE intrinsics
infrastructure assumes that for any predicated operation that the GP is at the
first argument position which has a svbool_t or for a unary merging operation
that it's in the second position.
However you have intrinsics like fmov_lane which have an svbool_t but it's not
a GP.
You also have instructions like BRKB which work only on predicates so it
incorrectly determines the first operand to be the GP, while that's the
inactive lanes.
However during apply_predication we do have the information about where the GP
is. This patch re-organizes the code to record this information into the
function_instance such that folders have access to this information.
For functions that are outliers like pmov_lane we can now override the
availability of the intrinsics having a GP.
gcc/ChangeLog:
PR target/121604
* config/aarch64/aarch64-sve-builtins-shapes.cc (apply_predication):
Store gp_index.
(struct pmov_to_vector_lane_def): Mark instruction as has no GP.
* config/aarch64/aarch64-sve-builtins.h (function_instance::gp_value,
function_instance::inactive_values, function_instance::gp_index,
function_shape::has_gp_argument_p): New.
* config/aarch64/aarch64-sve-builtins.cc (gimple_folder::fold_pfalse):
Simplify code and use GP helpers.
gcc/testsuite/ChangeLog:
PR target/121604
* gcc.target/aarch64/sve/pr121604_brk.c: New test.
* gcc.target/aarch64/sve2/pr121604_pmov.c: New test.
Co-authored-by: Jennifer Schmitz <jschmitz@nvidia.com>
(cherry picked from commit d1965b1fd8938f35f78be503e36b98b406751e21)
|
|
Compile builtin-copysign-8b.c with -mtune=generic so that it passes with
$ make check-gcc RUNTESTFLAGS="i386.exp=builtin-copysign-8b.c --target_board='unix{-m64\ -march=cascadelake}'"
PR target/122323
* gcc.target/i386/builtin-copysign-8b.c: Add -mtune=generic.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 3ce0b19b87e9146c47343aab5088d144e739ce57)
|
|
Merge up to r15-10454-g898066855feccb (27th Oct 2025)
|
|
|
|
Although there's no possibility of ambiguity, Intel manual says the mnemonic
for DWORD-to-QWORD sign-extension operation should be MOVSXD. Some assemblers
(GNU AS, NASM) also overload MOVSX, but some others don't accept MOVSX (LLVM,
MASM, YASM in NASM mode) and require MOVSXD.
This mnemonic was introduced in r0-34259-g123bf9e3f4056d in 2001, and has not
been updated ever since.
gcc/ChangeLog:
PR target/119079
* config/i386/i386.md: Use `movsxd` to perform SI-to-DI extension in Intel
syntax.
Signed-off-by: LIU Hao <lh_mouse@126.com>
(cherry picked from commit 66b38349273525dfb86f0f74d6c928abdbf7154f)
|
|
On gcc-14, instead of 'movi\td[0-9]*,#0', we select
'mov\tz[0-9]*\.b,#0', and the testcase fails.
As in pfalse* tests, tolerate the difference.
for gcc/testsuite/ChangeLog
PR target/121599
* gcc.target/aarch64/sve2/pr121599.c: Tolerate alterate insn
selection.
(cherry picked from commit ba653cb0d26e004c10d20ebd9f009a0a823659b0)
|
|
|
|
In the testcase repeated invocations of a function showed an apparently
unstable interface. This was caused by trying to guess an (inappropriate)
interface of the external procedure after processing of the procedure
arguments in gfc_conv_procedure_call. The mis-guessed interface showed up
in subsequent uses of the procedure symbol in gfc_conv_procedure_call. The
solution is to check for an existing interface of an external procedure
before trying to wildly guess based on just the actual arguments.
PR fortran/122206
gcc/fortran/ChangeLog:
* trans-types.cc (gfc_get_function_type): Do not clobber an
existing procedure interface.
gcc/testsuite/ChangeLog:
* gfortran.dg/interface_abstract_6.f90: New test.
(cherry picked from commit c474a50b42ac3f7561f628916cf58810044986b3)
|
|
PR fortran/107968
gcc/fortran/ChangeLog:
* trans-io.cc (gfc_trans_transfer): Also scalarize I/O of section
of an array pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/implied_do_io_9.f90: New test.
(cherry picked from commit e3431c6fd4691d5a0c48ee78869e5f9a79f217c3)
|
|
|
|
The compiler overruns the source file buffer.
gcc/ada/
PR ada/118782
* styleg.adb (Is_Box_Comment): Also stop the loop at EOF.
|
|
This also reverts an unintentional change introduced by the initial fix.
gcc/ada/
PR ada/81087
* gnatlink.adb (Is_Prefix): Move around, streamline and return false
when the prefix is not strict.
(Gnatlink): Fix other instances of incorrect lower bound assumption.
|
|
Adjust gcc.target/i386/builtin-fabs-2.c to scan both (%rdi) and (%edi).
PR target/122323
* gcc.target/i386/builtin-fabs-2.c: Also scan (%edi)for x32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 77c8be11d85d9f204d2eb1ba3c5d0cbf3cbce277)
|
|
[PR122012]
After commit 51b85dfeb19652bf3e0aaec08828ba7cee1e641c, when the
pointer offset is a variable in the loop, the object size of the
pointer may also need to be reexamined.
Which make gcc_assert in the check_for_plus_in_loops failed.
gcc/ChangeLog:
PR tree-optimization/122012
* tree-object-size.cc (check_for_plus_in_loops): Skip check
for the variable offset
gcc/testsuite/ChangeLog:
PR tree-optimization/122012
* gcc.dg/torture/pr122012.c: New test.
Signed-off-by: Linsen Zhou <i@lin.moe>
(cherry picked from commit 82cefc4898d4ccabe76e28d6626b91ca9e998923)
|
