[PATCH] cobol: Fix up cobol cross-compilation from 32-bit arches [PR119364]
Hi!
Right now it is not possible to even build cross-compilers from 32-bit
architectures to e.g. x86_64-linux or aarch64-linux, even from little-endian
ones.
The following patch attempts to fix that.
There were various issues seen e.g. trying to build i686-linux ->
x86_64-linux cross-compiler (so still 64-bit libgcobol, but the compiler
is 32-bit).
1) warning about >> 32 shift of size_t, on 32-bit arches size_t is 32-bit
and so the shift is UB; fixed by doing (new_size>>16)>>16 so that
it ors in >> 32 when new_size is 64-bit and 0 when it is 32-bit
2) enum cbl_field_attr_t was using size_t as underlying type, but has
various bitmasks which require full 64-bit type; changed this to uint64_t
underlying type and using unsigned long long in the structure; various
routines which operate with those attributes had to be changed also to
work with uint64_t instead of size_t
3) on i686-linux, config.h can #define _FILE_OFFSET_BITS 64 or similar
macros; as documented, those macros have to be defined before including
first C library header, but some sources included cobol-system.h which
includes config.h only after various other headers; this resulted in
link failures, as ino_t was sometimes unsigned long and sometines
unsigned long long, depending on whether config.h was included first or
not, and e.g. cobol_filename uses ino_t argument
4) lots of places used %ld or %lx *printf format specifers with size_t
arguments; that works only if size_t is unsigned long, but not when it
is unsigned int or unsigned long long or some other type; now while
ISO C99 has %zd or %zx to print size_t and C++14 includes C99 (or C11?),
while for the C++ headers the C++ compilers typically have full control
over it and so support everything in C++14 (e.g. libstdc++ in GCC 5.1+
or libc++ if not too old), for C library we are dependent on the system
C library (note, on the host for the compiler side). And not all hosts
support C99 in their C libraries; so instead of just changing it to
%zd or %zx, I'm changing it to what we use elsewhere in GCC,
HOST_SIZE_T_PRINT_{DEC,UNSIGNED,HEX_PURE} or GCC_PRISZ macros in the
*printf family format string and casts of the size_t arguments to
fmt_size_t. Note, if not using the C library *printf family (e.g. in
dbgmsg, sprintf, snprintf, fprintf, etc.) but the GCC diagnostic code
(e.g. err_msg, error, warning, yywarn, ...), then %zd/%zu is supported
and on the other side HOST_SIZE_T_PRINT_{DEC,UNSIGNED,HEX_PURE} etc.
macros shouldn't be used (for two reasons, because it is unnecessary
when %zd/%zu is guaranteed to be supported there because GCC has
control over that and more importantly because it breaks translations,
both extraction of the to be translated strings and we don't want to
have different messages, once with %lld, once with %ld, once with just %d
or %I64d depending on host, translators couldn't translate it all).
5) see above, there were already tons of %zd/%zu or %3zu etc. format
specifers in *printf format strings, this patch changes those too
6) I've noticed dbgmsg wasn't declared with printf attribute, which resulted
in bugs where format specifiers didn't match actually passed types of
arguments
The following patch passed bootstrap/regtest on x86_64-linux (including
cobol, make check-cobol is clean) and built fine also as i686-linux to
x86_64-linux cross, in that case I see a few test FAILures, but nothing
huge:
=== cobol Summary ===
# of expected passes2991
# of unexpected failures78
# of expected failures 6
The FAILs are:
FAIL: cobol.dg/group1/declarative_1.cob -O0 execution test
FAIL: FUNCTION_BIGGER-POINTER__2_.out output file test
FAIL: IBM_dialect_COMP_redefined_by_POINTER_as_64-bit.out output file test
FAIL: cobol.dg/group2/INSPECT_BACKWARD_simple_TALLYING.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_1.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_2.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_3.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_4.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_5-f.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_5-r.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_ISO_Example_5.cob -O0 execution test
FAIL: cobol.dg/group2/INSPECT_TALLYING_REPLACING_ISO_Example.cob -O0
execution test
FAIL: cobol.dg/group2/INSPECT_TRAILING.cob -O0 execution test
and can send the *.log/*.sum file if it helps, but I'd hope it can be
resolved incrementally because the patch is already way too big.
Ok for trunk?
2025-04-05 Jakub Jelinek
PR cobol/119364
libgcobol/
* valconv.cc (__gg__realloc_if_necessary): Use (new_size>>16)>>16;
instead of new_size>>32; to avoid warnings on 32-bit hosts.
* common-defs.h (enum cbl_field_attr_t): Use u
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Sun, 6 Apr 2025 at 12:58, Alexander Monakov wrote:
>
> On Fri, 4 Apr 2025, Ard Biesheuvel wrote:
>
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > into function prologues when profiling is enabled, to avoid GOT-based
> > indirect calls when a direct call would suffice.
> >
> > There are two problems with that change:
> > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> > whether or not a direct [PLT based] call is appropriate;
> > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> > does not emit the @PLT suffix, resulting in the wrong relocation to be
> > used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> >
> > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > account. This ensures that -mnop-mcount works as expected when emitting
> > the PLT based profiling calls.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> >
> > Signed-off-by: Ard Biesheuvel
> >
> > gcc/ChangeLog:
> >
> >* config/i386/i386.cc (x86_function_profiler): Take
> >ix86_direct_extern_access into account when generating calls
> >to __fentry__()
>
> Wrong changelog (reused from the earlier patch?)
> The entry should mention PR category/number.
>
Thanks,
How should I generate this PR, and this changelog?
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -23154,6 +23154,8 @@ x86_print_call_or_nop (FILE *file, const char
> > *target)
> >if (flag_nop_mcount || !strcmp (target, "nop"))
> > /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> > fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > + else if (!TARGET_PECOFF && flag_pic && flag_plt)
> > +fprintf (file, "1:\tcall\t%s@PLT\n", target);
>
> I guess this is written this way because the caller is supposed to handle the
> !flat_plt case, but then this should be an assert:
>
> else if (!TARGET_PECOFF && flag_pic)
>{
> gcc_assert (flat_plt);
> fprintf (file, "1:\tcall\t%s@PLT\n", target);
>}
>
I'll update this.
> Note that this patch touches only 64-bit codegen, -m32 will yield
> call *mcount@GOT as before (the previous patch also touched only 64-bit case).
>
I will mention this in the commit log.
Re: How to cherry-pick patches from the master branch to releases/gcc-14?
On 4/3/25 1:17 AM, Jin Ma wrote: Hi Jeff, I have some patches for XThreadVector that I would like to cherry-pick from the master branch to releases/gcc-14. I have "Write After Approval" permissions. Is there anything I need to do before proceeding with the cherry-pick, or could you assist me with it? Like changes to the trunk, we should get an ACK on cherry-picks to release branches. Commits related to XThreadVector that need to be cherry-picked from the master branch: d620499b3a24f14cfb98529640584e63d7eca149 8564d0948c72df0a66d7eb47e15c6ab43e9b25ce b9493e98da58c7689645b4ee1a2f653b86a5d758 ab24171d237a9138714f0e6d2bb38fd357ccaed9 3024b12f2cde5db3bf52b49b07e32ef3065929fb 580f571be6ce80aa71fb80e7b16e01824f088229 I reviewed that set and they all look like sensible bugfixes for a release branch or in one patch enabling more testing. So they're all OK for backporting into the gcc-14 branch. Go right ahead and cherry-pick them over. Thanks, Jeff
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Sun, 6 Apr 2025, Ard Biesheuvel wrote: > > Wrong changelog (reused from the earlier patch?) > > The entry should mention PR category/number. > > > > Thanks, > > How should I generate this PR, and this changelog? Piping the diff into 'contrib/mklog.py -b 119386' should do the trick (you'll have to fill the changelog template with the description of actual changes). Alexander
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Fri, 4 Apr 2025, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> __fentry__") updated the logic that emits mcount() / __fentry__() calls
> into function prologues when profiling is enabled, to avoid GOT-based
> indirect calls when a direct call would suffice.
>
> There are two problems with that change:
> - it relies on -mdirect-extern-access rather than -fno-plt to decide
> whether or not a direct [PLT based] call is appropriate;
> - for the PLT case, it falls through to x86_print_call_or_nop(), which
> does not emit the @PLT suffix, resulting in the wrong relocation to be
> used (R_X86_64_PC32 instead of R_X86_64_PLT32)
>
> Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> account. This ensures that -mnop-mcount works as expected when emitting
> the PLT based profiling calls.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
>
> Signed-off-by: Ard Biesheuvel
>
> gcc/ChangeLog:
>
>* config/i386/i386.cc (x86_function_profiler): Take
>ix86_direct_extern_access into account when generating calls
>to __fentry__()
Wrong changelog (reused from the earlier patch?)
The entry should mention PR category/number.
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -23154,6 +23154,8 @@ x86_print_call_or_nop (FILE *file, const char *target)
>if (flag_nop_mcount || !strcmp (target, "nop"))
> /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> + else if (!TARGET_PECOFF && flag_pic && flag_plt)
> +fprintf (file, "1:\tcall\t%s@PLT\n", target);
I guess this is written this way because the caller is supposed to handle the
!flat_plt case, but then this should be an assert:
else if (!TARGET_PECOFF && flag_pic)
{
gcc_assert (flat_plt);
fprintf (file, "1:\tcall\t%s@PLT\n", target);
}
Note that this patch touches only 64-bit codegen, -m32 will yield
call *mcount@GOT as before (the previous patch also touched only 64-bit case).
Alexander
>else
> fprintf (file, "1:\tcall\t%s\n", target);
> }
> @@ -23317,7 +23319,7 @@ x86_function_profiler (FILE *file, int labelno
> ATTRIBUTE_UNUSED)
> break;
> case CM_SMALL_PIC:
> case CM_MEDIUM_PIC:
> - if (!ix86_direct_extern_access)
> + if (!flag_plt)
> {
> if (ASSEMBLER_DIALECT == ASM_INTEL)
> fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
>
[Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs
Hi All,
As far as I can tell, the attached patch fixes the problems with the reduce
intrinsic. I would be grateful to the reporters if they would confirm that
this is the case.
The key to the fix appears in reduce_3.f90, which failed even with -m64.
Although it was not apparent from the tree dump, the scalar result was
going on the stack. Once it became larger than the word size, it pushed the
arguments out of alignment with the library prototype.
I took the opportunity to add character length checking to the library. I
think that it might be redundant and so might not appear in the submitted
version. Thus far, I have failed to trigger the errors because the frontend
seems to catch them all. reduce_c and reduce_scalar_c will look a lot
neater without them.
Harald has been enormously helpful in hunting out remaining problems and
providing fixes. These are woven into the patch.
Regtests on FC41/x86_64 - OK for mainline after confirmations from the
reporters?
Paul
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
index 8189d7a1c6f..858ffb1daeb 100644
--- a/gcc/fortran/iresolve.cc
+++ b/gcc/fortran/iresolve.cc
@@ -2417,7 +2417,7 @@ generate_reduce_op_wrapper (gfc_expr *op)
gfc_symbol *operation = op->symtree->n.sym;
gfc_symbol *wrapper, *a, *b, *c;
gfc_symtree *st;
- char tname[GFC_MAX_SYMBOL_LEN+1];
+ char tname[2 * GFC_MAX_SYMBOL_LEN + 2];
char *name;
gfc_namespace *ns;
gfc_expr *e;
@@ -2462,7 +2462,7 @@ generate_reduce_op_wrapper (gfc_expr *op)
a->attr.flavor = FL_VARIABLE;
a->attr.dummy = 1;
a->attr.artificial = 1;
- a->attr.intent = INTENT_INOUT;
+ a->attr.intent = INTENT_IN;
wrapper->formal = gfc_get_formal_arglist ();
wrapper->formal->sym = a;
gfc_set_sym_referenced (a);
@@ -2476,7 +2476,7 @@ generate_reduce_op_wrapper (gfc_expr *op)
b->attr.dummy = 1;
b->attr.optional= 1;
b->attr.artificial = 1;
- b->attr.intent = INTENT_INOUT;
+ b->attr.intent = INTENT_IN;
wrapper->formal->next = gfc_get_formal_arglist ();
wrapper->formal->next->sym = b;
gfc_set_sym_referenced (b);
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 8dd1c93dbdf..70f91f15ffd 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -6546,7 +6546,7 @@ add_argument_checking (stmtblock_t *block, gfc_symbol *sym)
message = _("Actual string length does not match the declared one"
" for dummy argument '%s' (%ld/%ld)");
}
- else if (fsym->as && fsym->as->rank != 0)
+ else if ((fsym->as && fsym->as->rank != 0) || fsym->attr.artificial)
continue;
else
{
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4b90b06fa0a..6ece39b218d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6753,12 +6753,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
gfc_intrinsic_sym *isym = expr && expr->rank ?
expr->value.function.isym : NULL;
- /* In order that the library function for intrinsic REDUCE be type and kind
- agnostic, the result is passed by reference. Allocatable components are
- handled within the OPERATION wrapper. */
- bool reduce_scalar = expr && !expr->rank && expr->value.function.isym
- && expr->value.function.isym->id == GFC_ISYM_REDUCE;
-
comp = gfc_get_proc_ptr_comp (expr);
bool elemental_proc = (comp
@@ -8596,16 +8590,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
else if (ts.type == BT_CHARACTER)
vec_safe_push (retargs, len);
}
- else if (reduce_scalar)
-{
- /* In order that the library function for intrinsic REDUCE be type and
- kind agnostic, the result is passed by reference. Allocatable
- components are handled within the OPERATION wrapper. */
- type = gfc_typenode_for_spec (&expr->ts);
- result = gfc_create_var (type, "sr");
- tmp = gfc_build_addr_expr (pvoid_type_node, result);
- vec_safe_push (retargs, tmp);
-}
gfc_free_interface_mapping (&mapping);
@@ -8821,14 +8805,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
gfc_add_expr_to_block (&se->pre, tmp);
}
}
- else if (reduce_scalar)
-{
- /* Even though the REDUCE intrinsic library function returns the result
- by reference, the scalar call passes the result as se->expr. */
- gfc_add_expr_to_block (&se->pre, se->expr);
- se->expr = result;
- gfc_add_block_to_block (&se->post, &post);
-}
else
{
/* For a function with a class array result, save the result as
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 6b55017bb89..6ffc3e0261e 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -3883,6 +3883,13 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr * expr)
append_args->quick_push (null_pointer_node);
}
}
+ /* Non-character scalar reduce returns a pointer to a result of size set by
+ the element
Re: [COMMITTED] Doc: Document _Bool type as C90 extension [PR118118]
* Sandra Loosemore:
> @@ -13698,6 +13699,17 @@ Forward-declaring an incomplete enum type without an
> explicit
> underlying type is supported as an extension in all GNU C dialects,
> but is not supported at all in GNU C++.
>
> +@node Boolean Type
> +@subsection Support for the @code{_Bool} Type
> +@cindex boolean type
> +@cindex @code{_Bool} keyword
> +
> +The C99 standard added @code{_Bool} as a C language keyword naming the
> +boolean type. As an extension, GNU C also recognizes @code{_Bool} in
> +C90 mode as well as with @option{-std=c99} and later.
I think with C23, _Bool is again a GNU extension.
> +GNU C++ does not support the @code{_Bool} keyword.
Maybe mention that including defines _Bool as a macro?
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Fri, Apr 4, 2025 at 9:00 AM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> __fentry__") updated the logic that emits mcount() / __fentry__() calls
> into function prologues when profiling is enabled, to avoid GOT-based
> indirect calls when a direct call would suffice.
>
> There are two problems with that change:
> - it relies on -mdirect-extern-access rather than -fno-plt to decide
> whether or not a direct [PLT based] call is appropriate;
> - for the PLT case, it falls through to x86_print_call_or_nop(), which
> does not emit the @PLT suffix, resulting in the wrong relocation to be
> used (R_X86_64_PC32 instead of R_X86_64_PLT32)
>
> Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> account. This ensures that -mnop-mcount works as expected when emitting
> the PLT based profiling calls.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
>
> Signed-off-by: Ard Biesheuvel
>
> gcc/ChangeLog:
>
>* config/i386/i386.cc (x86_function_profiler): Take
>ix86_direct_extern_access into account when generating calls
>to __fentry__()
I'm not a specialist in this part of the compiler, but all relevant
people took part in the (long) discussion in the PR and came to the
above consensus.
So, I'm rubber-stamping this patch OK.
Ard, are you able to commit the patch yourself, or I should commit it for you?
Thanks,
Uros.
New Swedish PO file for 'gcc' (version 15.1-b20250316)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-15.1-b20250316.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH] testsuite, cobol: Avoid adding duplicate libs.
Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
OK for trunk?
thanks
Iain
--- 8< ---
The discovered paths already include the multilib and so there is
no need to add an extra library to COBOL_UNDER_TEST. Doing so makes
a duplicate, which causes test fails on Darwin, where the linker warns
when duplicate libraries are provided on the link line.
gcc/testsuite/ChangeLog:
* lib/cobol.exp: Simplify the setting of COBOL_UNDER_TEST.
Signed-off-by: Iain Sandoe
---
gcc/testsuite/lib/cobol.exp | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
index a0eeb4e64e9..968e7f3bca3 100644
--- a/gcc/testsuite/lib/cobol.exp
+++ b/gcc/testsuite/lib/cobol.exp
@@ -163,7 +163,6 @@ proc cobol_init { args } {
global gcc_warning_prefix
global gcc_error_prefix
global TEST_ALWAYS_FLAGS
-global cobol_init_set_COBOL_UNDER_TEST
# We set LC_ALL and LANG to C so that we get the same error messages as
expected.
setenv LC_ALL C
@@ -179,24 +178,14 @@ proc cobol_init { args } {
setenv LANG C.ASCII
}
-# COBOL_UNDER_TEST as set below contains $specpath, which depends on
-# the used multilib config. Thus, its value may need to be reset;
-# that's tracked via gfortran_init_set_COBOL_UNDER_TEST.
-if { ![info exists COBOL_UNDER_TEST]
-|| [info exists cobol_init_set_COBOL_UNDER_TEST] } then {
+if ![info exists COBOL_UNDER_TEST] then {
if [info exists TOOL_EXECUTABLE] {
set COBOL_UNDER_TEST $TOOL_EXECUTABLE
} else {
if { [is_remote host] || ! [info exists TESTING_IN_BUILD_TREE] } {
- set COBOL_UNDER_TEST [transform gcobol]
+ set COBOL_UNDER_TEST [transform ga68]
} else {
- if [info exists TOOL_OPTIONS] {
- set specpath [get_multilibs ${TOOL_OPTIONS}]
- } else {
- set specpath [get_multilibs]
- }
- set cobol_init_set_COBOL_UNDER_TEST 1
- set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol
"$base_dir/../../gcobol -B$base_dir/../../ -B$specpath/libgcobol/.libs"
[findfile $base_dir/gcobol "$base_dir/gcobol -B$base_dir/" [transform gcobol]]]
+ set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol
"$base_dir/../../gcobol -B$base_dir/../../" [findfile $base_dir/gcobol
"$base_dir/gcobol -B$base_dir/" [transform gcobol]]]
}
}
}
--
2.39.2 (Apple Git-143)
Re: [PATCH] cobol, driver: Remove platform-specific options [PR119414].
> Am 06.04.2025 um 09:42 schrieb Iain Sandoe :
>
> Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
> OK for trunk?
Ok
Richard
> thanks
> Iain
>
> --- 8< ---
>
> As discussed in the PR, the options had been added during development
> to handle specific cases, they are no longer needed (and if they should
> become necessary, we will need to guard them such that individual
> platforms get the correct handling).
>
>PR cobol/119414
>
> gcc/cobol/ChangeLog:
>
>* gcobolspec.cc (append_rdynamic,
>append_allow_multiple_definition, append_fpic): Remove.
>(lang_specific_driver): Remove platform-specific command
>line option handling.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/cobol/gcobolspec.cc | 90 ++---
> 1 file changed, 3 insertions(+), 87 deletions(-)
>
> diff --git a/gcc/cobol/gcobolspec.cc b/gcc/cobol/gcobolspec.cc
> index 083223115ad..4df9f8dc37e 100644
> --- a/gcc/cobol/gcobolspec.cc
> +++ b/gcc/cobol/gcobolspec.cc
> @@ -126,41 +126,6 @@ add_arg_lib(const char *library, bool force_static
> ATTRIBUTE_UNUSED)
> #endif
> }
>
> -static void
> -append_rdynamic()
> - {
> - // This is a bit ham-handed, but I was in a hurry.
> - struct cl_decoded_option decoded = {};
> - decoded.opt_index = OPT_rdynamic;
> - decoded.orig_option_with_args_text = "-rdynamic";
> - decoded.canonical_option[0] = "-rdynamic";
> - decoded.canonical_option_num_elements = 1;
> - decoded.value = 1;
> - append_arg(decoded);
> - return;
> - }
> -
> -static void
> -append_allow_multiple_definition()
> - {
> - append_option (OPT_Wl_, "--allow-multiple-definition", 1);
> - return;
> - }
> -
> -static void
> -append_fpic()
> - {
> - // This is a bit ham-handed, but I was in a hurry.
> - struct cl_decoded_option decoded = {};
> - decoded.opt_index = OPT_rdynamic;
> - decoded.orig_option_with_args_text = "-fPIC";
> - decoded.canonical_option[0] = "-fPIC";
> - decoded.canonical_option_num_elements = 1;
> - decoded.value = 1;
> - append_arg(decoded);
> - return;
> - }
> -
> void
> lang_specific_driver (struct cl_decoded_option **in_decoded_options,
> unsigned int *in_decoded_options_count,
> @@ -188,8 +153,6 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
>
> bool saw_OPT_c = false;
> bool saw_OPT_shared = false;
> - bool saw_OPT_pic = false;
> - bool saw_OPT_PIC = false;
>
> bool verbose = false;
>
> @@ -197,9 +160,6 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
>
> bool need_libdl = (DL_LIBRARY[0] != '\0');
> bool need_libstdc = (STDCPP_LIBRARY[0] != '\0');
> - // bool need_libquadmath = (QUADMATH_LIBRARY[0] != '\0');
> - bool need_rdynamic= true;
> - bool need_allow_multiple_definition = true;
>
> // Separate flags for a couple of static libraries
> bool static_libgcobol = false;
> @@ -290,36 +250,10 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
> saw_OPT_shared = true;
> break;
>
> - case OPT_fpic:
> -saw_OPT_pic = true;
> -break;
> -
> - case OPT_fPIC:
> -saw_OPT_PIC = true;
> -break;
> -
> - case OPT_c:
> -// With this option, no libraries need be loaded
> +case OPT_c:
> +// Note -c specially.
> saw_OPT_c = true;
> -need_libgcobol = false;
> -need_libdl = false;
> -need_libstdc = false;
> -// need_libquadmath = false;
> -need_rdynamic= false;
> -break;
> -
> - case OPT_rdynamic:
> -need_rdynamic = false;
> -break;
> -
> - case OPT_Wl_:
> -if( strstr(decoded_options[i].orig_option_with_args_text,
> -"--allow-multiple-definitions") )
> - {
> - need_allow_multiple_definition = false;
> - }
> -break;
> -
> +// FALLTHROUGH
> case OPT_nostdlib:
> case OPT_nodefaultlibs:
> case OPT_r:
> @@ -330,8 +264,6 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
> need_libgcobol = false;
> need_libdl = false;
> need_libstdc = false;
> -// need_libquadmath = false;
> -need_rdynamic= false;
> break;
>
> case OPT_static_libgcobol:
> @@ -449,7 +381,6 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
> need_libgcobol = false;
> need_libdl = false;
> need_libstdc = false;
> -// need_libquadmath = false;
> }
>
> /* Second pass through arglist, transforming arguments as appropriate. */
> @@ -588,21 +519,6 @@ lang_specific_driver (struct cl_decoded_option
> **in_decoded_options,
> add_arg_lib(STDCPP_LIBRARY, static_in_general);
> }
>
> - if( saw_OPT_shared && !saw_OPT_pic && !saw_OPT_PIC )
> -{
> -append_fpic();
> -}
> -
> - if( need_rdynamic )
> -{
> -append_
[PATCH] cobol, driver: Remove platform-specific options [PR119414].
Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
OK for trunk?
thanks
Iain
--- 8< ---
As discussed in the PR, the options had been added during development
to handle specific cases, they are no longer needed (and if they should
become necessary, we will need to guard them such that individual
platforms get the correct handling).
PR cobol/119414
gcc/cobol/ChangeLog:
* gcobolspec.cc (append_rdynamic,
append_allow_multiple_definition, append_fpic): Remove.
(lang_specific_driver): Remove platform-specific command
line option handling.
Signed-off-by: Iain Sandoe
---
gcc/cobol/gcobolspec.cc | 90 ++---
1 file changed, 3 insertions(+), 87 deletions(-)
diff --git a/gcc/cobol/gcobolspec.cc b/gcc/cobol/gcobolspec.cc
index 083223115ad..4df9f8dc37e 100644
--- a/gcc/cobol/gcobolspec.cc
+++ b/gcc/cobol/gcobolspec.cc
@@ -126,41 +126,6 @@ add_arg_lib(const char *library, bool force_static
ATTRIBUTE_UNUSED)
#endif
}
-static void
-append_rdynamic()
- {
- // This is a bit ham-handed, but I was in a hurry.
- struct cl_decoded_option decoded = {};
- decoded.opt_index = OPT_rdynamic;
- decoded.orig_option_with_args_text = "-rdynamic";
- decoded.canonical_option[0] = "-rdynamic";
- decoded.canonical_option_num_elements = 1;
- decoded.value = 1;
- append_arg(decoded);
- return;
- }
-
-static void
-append_allow_multiple_definition()
- {
- append_option (OPT_Wl_, "--allow-multiple-definition", 1);
- return;
- }
-
-static void
-append_fpic()
- {
- // This is a bit ham-handed, but I was in a hurry.
- struct cl_decoded_option decoded = {};
- decoded.opt_index = OPT_rdynamic;
- decoded.orig_option_with_args_text = "-fPIC";
- decoded.canonical_option[0] = "-fPIC";
- decoded.canonical_option_num_elements = 1;
- decoded.value = 1;
- append_arg(decoded);
- return;
- }
-
void
lang_specific_driver (struct cl_decoded_option **in_decoded_options,
unsigned int *in_decoded_options_count,
@@ -188,8 +153,6 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
bool saw_OPT_c = false;
bool saw_OPT_shared = false;
- bool saw_OPT_pic = false;
- bool saw_OPT_PIC = false;
bool verbose = false;
@@ -197,9 +160,6 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
bool need_libdl = (DL_LIBRARY[0] != '\0');
bool need_libstdc = (STDCPP_LIBRARY[0] != '\0');
- // bool need_libquadmath = (QUADMATH_LIBRARY[0] != '\0');
- bool need_rdynamic= true;
- bool need_allow_multiple_definition = true;
// Separate flags for a couple of static libraries
bool static_libgcobol = false;
@@ -290,36 +250,10 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
saw_OPT_shared = true;
break;
- case OPT_fpic:
-saw_OPT_pic = true;
-break;
-
- case OPT_fPIC:
-saw_OPT_PIC = true;
-break;
-
- case OPT_c:
-// With this option, no libraries need be loaded
+ case OPT_c:
+// Note -c specially.
saw_OPT_c = true;
-need_libgcobol = false;
-need_libdl = false;
-need_libstdc = false;
-// need_libquadmath = false;
-need_rdynamic= false;
-break;
-
- case OPT_rdynamic:
-need_rdynamic = false;
-break;
-
- case OPT_Wl_:
-if( strstr(decoded_options[i].orig_option_with_args_text,
-"--allow-multiple-definitions") )
- {
- need_allow_multiple_definition = false;
- }
-break;
-
+// FALLTHROUGH
case OPT_nostdlib:
case OPT_nodefaultlibs:
case OPT_r:
@@ -330,8 +264,6 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
need_libgcobol = false;
need_libdl = false;
need_libstdc = false;
-// need_libquadmath = false;
-need_rdynamic= false;
break;
case OPT_static_libgcobol:
@@ -449,7 +381,6 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
need_libgcobol = false;
need_libdl = false;
need_libstdc = false;
-// need_libquadmath = false;
}
/* Second pass through arglist, transforming arguments as appropriate. */
@@ -588,21 +519,6 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
add_arg_lib(STDCPP_LIBRARY, static_in_general);
}
- if( saw_OPT_shared && !saw_OPT_pic && !saw_OPT_PIC )
-{
-append_fpic();
-}
-
- if( need_rdynamic )
-{
-append_rdynamic();
-}
-
- if( need_allow_multiple_definition && (n_infiles || n_outfiles) )
-{
-append_allow_multiple_definition();
-}
-
if( prior_main )
{
char ach[] = "\"-main\" without a source file";
--
2.39.2 (Apple Git-143)
Re: [PATCH] testsuite, cobol: Avoid adding duplicate libs.
> Am 06.04.2025 um 09:44 schrieb Iain Sandoe :
>
> Tested on x86_64, aarch64, powerpc64le - Linux; x86_64, aarch64 Darwin,
> OK for trunk?
Ok
Richard
> thanks
> Iain
>
> --- 8< ---
>
> The discovered paths already include the multilib and so there is
> no need to add an extra library to COBOL_UNDER_TEST. Doing so makes
> a duplicate, which causes test fails on Darwin, where the linker warns
> when duplicate libraries are provided on the link line.
>
> gcc/testsuite/ChangeLog:
>
>* lib/cobol.exp: Simplify the setting of COBOL_UNDER_TEST.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/testsuite/lib/cobol.exp | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> index a0eeb4e64e9..968e7f3bca3 100644
> --- a/gcc/testsuite/lib/cobol.exp
> +++ b/gcc/testsuite/lib/cobol.exp
> @@ -163,7 +163,6 @@ proc cobol_init { args } {
> global gcc_warning_prefix
> global gcc_error_prefix
> global TEST_ALWAYS_FLAGS
> -global cobol_init_set_COBOL_UNDER_TEST
>
> # We set LC_ALL and LANG to C so that we get the same error messages as
> expected.
> setenv LC_ALL C
> @@ -179,24 +178,14 @@ proc cobol_init { args } {
> setenv LANG C.ASCII
> }
>
> -# COBOL_UNDER_TEST as set below contains $specpath, which depends on
> -# the used multilib config. Thus, its value may need to be reset;
> -# that's tracked via gfortran_init_set_COBOL_UNDER_TEST.
> -if { ![info exists COBOL_UNDER_TEST]
> - || [info exists cobol_init_set_COBOL_UNDER_TEST] } then {
> +if ![info exists COBOL_UNDER_TEST] then {
>if [info exists TOOL_EXECUTABLE] {
>set COBOL_UNDER_TEST $TOOL_EXECUTABLE
>} else {
>if { [is_remote host] || ! [info exists TESTING_IN_BUILD_TREE] } {
> -set COBOL_UNDER_TEST [transform gcobol]
> +set COBOL_UNDER_TEST [transform ga68]
>} else {
> -if [info exists TOOL_OPTIONS] {
> -set specpath [get_multilibs ${TOOL_OPTIONS}]
> -} else {
> -set specpath [get_multilibs]
> -}
> -set cobol_init_set_COBOL_UNDER_TEST 1
> -set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol
> "$base_dir/../../gcobol -B$base_dir/../../ -B$specpath/libgcobol/.libs"
> [findfile $base_dir/gcobol "$base_dir/gcobol -B$base_dir/" [transform
> gcobol]]]
> +set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol
> "$base_dir/../../gcobol -B$base_dir/../../" [findfile $base_dir/gcobol
> "$base_dir/gcobol -B$base_dir/" [transform gcobol]]]
>}
>}
> }
> --
> 2.39.2 (Apple Git-143)
>
[PATCH 1/2] testsuite, cobol: Add libquadmath paths.
Even when we are using IEC 128b floating point, the quadmath library can
be pulled in 'as needed'.
gcc/testsuite/ChangeLog:
* lib/cobol.exp: Add libquadmath paths.
Signed-off-by: Iain Sandoe
---
gcc/testsuite/lib/cobol.exp | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
index 968e7f3bca3..6819b930bd1 100644
--- a/gcc/testsuite/lib/cobol.exp
+++ b/gcc/testsuite/lib/cobol.exp
@@ -122,6 +122,15 @@ proc cobol_link_flags { paths } {
}
append ld_library_path ":${gccpath}/libgcobol/.libs"
}
+ if { [file exists "${gccpath}/libquadmath/.libs/libquadmath.a"] ||
+[file exists "${gccpath}/libquadmath/.libs/libquadmath.${shlib_ext}"]
} {
+ if { $target_wants_B_option } {
+ append flags "-B${gccpath}/libquadmath/.libs "
+ } else {
+ append flags "-L${gccpath}/libquadmath/.libs "
+ }
+ append ld_library_path ":${gccpath}/libquadmath/.libs"
+ }
if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] ||
[file exists
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
if { $target_wants_B_option } {
--
2.39.2 (Apple Git-143)
[PATCH 0/2] libcobol: Allow the use of libquadmath for 128b FP.
This provides support for targets without Float128 in their libc/libm. It covers: * long double is 128b IEEE754 * _Float128 support is provided in libc * __float128 support is available and uses libquadmath. It has been tested as follows: x86_64-linux (with libc support, uses libc) x86_64-darwin (without libc support, uses libquadmath) aarch64-linux (with libc support, uses libc) aarch64-darwin (without libc support, uses libquadmath) powerpc64le (glibc-2.17 - without libc support, uses libquadmath) powerpc64le (glibc2.34 - with libc support) --with-long-double-format=ieee uses xxxieee128 --with-long-double-format=ibm uses xxxf128 Thanks to Jakub for the suggestion on handling the long double case. Most of the patch is mechanical - the tricky parts are really in the configuration. OK for trunk? thanks Iain Iain Sandoe (2): testsuite, cobol: Add libquadmath paths. libgcobol: Allow libgcobol to use libquadmath [PR119244]. gcc/testsuite/lib/cobol.exp | 9 + libgcobol/Makefile.am | 9 +- libgcobol/Makefile.in | 14 +- libgcobol/acinclude.m4 | 162 +++ libgcobol/config.h.in | 30 ++ libgcobol/configure | 527 +--- libgcobol/configure.ac | 41 ++- libgcobol/gfileio.cc| 1 + libgcobol/gmath.cc | 108 libgcobol/intrinsic.cc | 186 +++-- libgcobol/libgcobol-fp.h| 50 libgcobol/libgcobol.cc | 186 +++-- libgcobol/libgcobol.h | 10 +- libgcobol/libgcobol.spec.in | 2 +- 14 files changed, 1057 insertions(+), 278 deletions(-) create mode 100644 libgcobol/libgcobol-fp.h -- 2.39.2 (Apple Git-143)
[PATCH 2/2] libgcobol: Allow libgcobol to use libquadmath [PR119244].
Many of the changes are mechanical: 1. 'GCOB_FP128' in place of _Float128. 2. Using FP128_FUNC to represent the spelling of intrinsics. 3. Using GCOB_FP128_LITERAL() to choose the suffix for literals. This allows for: __float128 and 'q' as the suffix when libquadmath is configured. _Float128 / 'f128' when IEC-60559 is available in libc long double / 'l' when long double is ieee753 128b. Add libquadmath to libgcobol.spec and its dependencies where the platform needs it. PR cobol/119244 libgcobol/ChangeLog: * Makefile.am: Add support for libquadmath. * Makefile.in: Regenerate. * acinclude.m4: Add support for libquadmath. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Configure libquadmath support. * gmath.cc: Use GCOB_FP128 to represent the configured 128b floating point type. Use FP128_FUNC to represent the naming of intrinsics in the configure 128b floating point type. Render literals with GCOB_FP128_LITERAL. * intrinsic.cc: Likewise. * libgcobol.cc: Likewise. * libgcobol.h: Likewise. * libgcobol-fp.h: New file. * gfileio.cc: Include libgcobol-fp.h. * libgcobol.spec.in: Add libquadmath configure output. Signed-off-by: Iain Sandoe --- libgcobol/Makefile.am | 9 +- libgcobol/Makefile.in | 14 +- libgcobol/acinclude.m4 | 162 +++ libgcobol/config.h.in | 30 ++ libgcobol/configure | 527 +--- libgcobol/configure.ac | 41 ++- libgcobol/gfileio.cc| 1 + libgcobol/gmath.cc | 108 libgcobol/intrinsic.cc | 186 +++-- libgcobol/libgcobol-fp.h| 50 libgcobol/libgcobol.cc | 186 +++-- libgcobol/libgcobol.h | 10 +- libgcobol/libgcobol.spec.in | 2 +- 13 files changed, 1048 insertions(+), 278 deletions(-) create mode 100644 libgcobol/libgcobol-fp.h diff --git a/libgcobol/Makefile.am b/libgcobol/Makefile.am index 89d0519ed06..0a17d2077f1 100644 --- a/libgcobol/Makefile.am +++ b/libgcobol/Makefile.am @@ -46,7 +46,7 @@ libgcobol_la_SOURCES =\ WARN_CFLAGS = -W -Wall -Wwrite-strings -AM_CPPFLAGS = -I. -I$(srcdir) +AM_CPPFLAGS = -I. -I$(srcdir) $(LIBQUADINCLUDE) AM_CFLAGS = $(XCFLAGS) AM_CXXFLAGS = $(XCFLAGS) AM_CXXFLAGS += $(WARN_CFLAGS) @@ -62,9 +62,8 @@ endif # We want to link with the c++ runtime. libgcobol_la_LINK = $(CXXLINK) $(libgcobol_la_LDFLAGS) version_arg = -version-info $(LIBGCOBOL_VERSION) -libgcobol_la_LDFLAGS = $(LTLDFLAGS) $(LTLIBICONV) \ - $(extra_ldflags_libgcobol) $(LIBS) \ - $(version_arg) -libgcobol_la_DEPENDENCIES = libgcobol.spec +libgcobol_la_LDFLAGS = $(LTLDFLAGS) $(LIBQUADLIB) $(LTLIBICONV) \ + $(extra_ldflags_libgcobol) $(LIBS) $(version_arg) +libgcobol_la_DEPENDENCIES = libgcobol.spec $(LIBQUADLIB_DEP) endif BUILD_LIBGCOBOL diff --git a/libgcobol/Makefile.in b/libgcobol/Makefile.in index 88158cbf377..5fdc42c2a20 100644 --- a/libgcobol/Makefile.in +++ b/libgcobol/Makefile.in @@ -288,6 +288,10 @@ LIBGCOBOL_VERSION = @LIBGCOBOL_VERSION@ LIBICONV = @LIBICONV@ LIBM = @LIBM@ LIBOBJS = @LIBOBJS@ +LIBQUADINCLUDE = @LIBQUADINCLUDE@ +LIBQUADLIB = @LIBQUADLIB@ +LIBQUADLIB_DEP = @LIBQUADLIB_DEP@ +LIBQUADSPEC = @LIBQUADSPEC@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ @@ -317,6 +321,7 @@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ SPEC_LIBGCOBOL_DEPS = @SPEC_LIBGCOBOL_DEPS@ STRIP = @STRIP@ +USE_IEC_60559 = @USE_IEC_60559@ VERSION = @VERSION@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ @@ -402,7 +407,7 @@ gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) @BUILD_LIBGCOBOL_TRUE@ valconv.cc @BUILD_LIBGCOBOL_TRUE@WARN_CFLAGS = -W -Wall -Wwrite-strings -@BUILD_LIBGCOBOL_TRUE@AM_CPPFLAGS = -I. -I$(srcdir) +@BUILD_LIBGCOBOL_TRUE@AM_CPPFLAGS = -I. -I$(srcdir) $(LIBQUADINCLUDE) @BUILD_LIBGCOBOL_TRUE@AM_CFLAGS = $(XCFLAGS) @BUILD_LIBGCOBOL_TRUE@AM_CXXFLAGS = $(XCFLAGS) $(WARN_CFLAGS) \ @BUILD_LIBGCOBOL_TRUE@ -DIN_TARGET_LIBS -fno-strict-aliasing @@ -410,11 +415,10 @@ gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER) # We want to link with the c++ runtime. @BUILD_LIBGCOBOL_TRUE@libgcobol_la_LINK = $(CXXLINK) $(libgcobol_la_LDFLAGS) @BUILD_LIBGCOBOL_TRUE@version_arg = -version-info $(LIBGCOBOL_VERSION) -@BUILD_LIBGCOBOL_TRUE@libgcobol_la_LDFLAGS = $(LTLDFLAGS) $(LTLIBICONV) \ -@BUILD_LIBGCOBOL_TRUE@ $(extra_ldflags_libgcobol) $(LIBS) \ -@BUILD_LIBGCOBOL_TRUE@ $(version_arg) +@BUILD_LIBGCOBOL_TRUE@libgcobol_la_LDFLAGS = $(LTLDFLAGS) $(LIBQUADLIB) $(LTLIBICONV) \ +@BUILD_LIBGCOBOL_TRUE@ $(extra_ldflags_libgcobol) $(LIBS) $(version_arg) -@BUILD_LIBGCOBOL_TRUE@libgcobol_la_DEPENDENCIES = libgcobol.spec +@BUILD_LIBGCOBOL_TRUE@libgcobol_la_DEPENDENCIES = libgcobol.spec $(LIBQUADLIB_DEP) all: config.h $(MAKE) $(AM_MAKEFLAGS) all-am diff --git a/li
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Fri, Apr 4, 2025 at 12:01 AM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> __fentry__") updated the logic that emits mcount() / __fentry__() calls
> into function prologues when profiling is enabled, to avoid GOT-based
> indirect calls when a direct call would suffice.
>
> There are two problems with that change:
> - it relies on -mdirect-extern-access rather than -fno-plt to decide
> whether or not a direct [PLT based] call is appropriate;
> - for the PLT case, it falls through to x86_print_call_or_nop(), which
> does not emit the @PLT suffix, resulting in the wrong relocation to be
> used (R_X86_64_PC32 instead of R_X86_64_PLT32)
>
> Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> account. This ensures that -mnop-mcount works as expected when emitting
> the PLT based profiling calls.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
>
> Signed-off-by: Ard Biesheuvel
>
> gcc/ChangeLog:
>
>* config/i386/i386.cc (x86_function_profiler): Take
>ix86_direct_extern_access into account when generating calls
>to __fentry__()
> ---
> gcc/config/i386/i386.cc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index be5e27fc391..6be6ddcbb3c 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -23154,6 +23154,8 @@ x86_print_call_or_nop (FILE *file, const char *target)
>if (flag_nop_mcount || !strcmp (target, "nop"))
> /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> + else if (!TARGET_PECOFF && flag_pic && flag_plt)
> +fprintf (file, "1:\tcall\t%s@PLT\n", target);
>else
> fprintf (file, "1:\tcall\t%s\n", target);
> }
> @@ -23317,7 +23319,7 @@ x86_function_profiler (FILE *file, int labelno
> ATTRIBUTE_UNUSED)
> break;
> case CM_SMALL_PIC:
> case CM_MEDIUM_PIC:
> - if (!ix86_direct_extern_access)
> + if (!flag_plt)
Should ix86_force_load_from_GOT_p be extended to handle this?
> {
> if (ASSEMBLER_DIALECT == ASM_INTEL)
> fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
> --
> 2.49.0.504.g3bcea36a83-goog
>
--
H.J.
[patch,avr] Support 8-bit and 16-bit fixed-point ops on avrtiny
With a few changes, 8-bit and 16-bit fixed-point operations can be made work on the reduced core. Added as obvious. Johann -- AVRrc: Support 8-bit and 16-bit fixed-point arith in libgcc. With some minor changes, 8-bit and 16-bit fixed-point operations can be supported on the reduced core. libgcc/ * config/avr/t-avr (LIB1ASMFUNCS): Add (and remove from FUNCS_notiny): _mulhisi3, _umulhisi3, _mulqq3, _mulhq3, _muluhq3, _mulha3, _muluha3 _muluha3_round, _usmuluha3, _ssmulha3, _divqq3, _udivuqq3, _divqq_helper, _divhq3, _udivuhq3. _divha3 _udivuha3, _ssneg_2, _ssabs_1, _ssabs_2, _mask1, _ret, _roundqq3 _rounduqq3, _round_s2, _round_u2, _round_2_const, _addmask_2. * config/avr/lib1funcs.S (__umulhisi3, __mulhisi3): Make work on AVRrc. * config/avr/lib1funcs-fixed.S: Build 8-bit and 16-bit functions on AVRrc, too. AVRrc: Support 8-bit and 16-bit fixed-point arith in libgcc. With some minor changes, 8-bit and 16-bit fixed-point operations can be supported on the reduced core. libgcc/ * config/avr/t-avr (LIB1ASMFUNCS): Add (and remove from FUNCS_notiny): _mulhisi3, _umulhisi3, _mulqq3, _mulhq3, _muluhq3, _mulha3, _muluha3 _muluha3_round, _usmuluha3, _ssmulha3, _divqq3, _udivuqq3, _divqq_helper, _divhq3, _udivuhq3. _divha3 _udivuha3, _ssneg_2, _ssabs_1, _ssabs_2, _mask1, _ret, _roundqq3 _rounduqq3, _round_s2, _round_u2, _round_2_const, _addmask_2. * config/avr/lib1funcs.S (__umulhisi3, __mulhisi3): Make work on AVRrc. * config/avr/lib1funcs-fixed.S: Build 8-bit and 16-bit functions on AVRrc, too. diff --git a/libgcc/config/avr/lib1funcs-fixed.S b/libgcc/config/avr/lib1funcs-fixed.S index 278ee1b4a5d..4115589b570 100644 --- a/libgcc/config/avr/lib1funcs-fixed.S +++ b/libgcc/config/avr/lib1funcs-fixed.S @@ -31,14 +31,6 @@ ;; Fixed point library routines for AVR ;; -#if defined __AVR_TINY__ -#define __zero_reg__ r17 -#define __tmp_reg__ r16 -#else -#define __zero_reg__ r1 -#define __tmp_reg__ r0 -#endif - .section .text.libgcc.fixed, "ax", @progbits #ifndef __AVR_TINY__ @@ -251,6 +243,7 @@ DEFUN __fractsfusa ENDF __fractsfusa #endif /* L_fractsfusa */ +#endif /* ! AVR_TINY */ ;; For multiplication the functions here are called directly from ;; avr-fixed.md instead of using the standard libcall mechanisms. @@ -295,8 +288,14 @@ DEFUN __mulhq3 rol r25 brvs1f ;; Round +#ifndef __AVR_TINY__ sbrcr23, 7 adiwr24, 1 +#else +lsl r23 +adc r24, __zero_reg__ +adc r25, __zero_reg__ +#endif /* AVR_TINY? */ ret 1: ;; Overflow. TR 18037 requires (-1)^2 not to overflow ldi r24, lo8 (0x7fff) @@ -315,8 +314,14 @@ DEFUN __mulhq3 DEFUN __muluhq3 XCALL __umulhisi3 ;; Round +#ifndef __AVR_TINY__ sbrcr23, 7 adiwr24, 1 +#else +lsl r23 +adc r24, __zero_reg__ +adc r25, __zero_reg__ +#endif /* AVR_TINY? */ ret ENDF __muluhq3 #endif /* L_muluhq3 */ @@ -361,8 +366,14 @@ DEFUN __muluha3_round mov r25, r24 mov r24, r23 ;; Round +#ifndef __AVR_TINY__ sbrcr22, 7 adiwr24, 1 +#else +lsl r22 +adc r24, __zero_reg__ +adc r25, __zero_reg__ +#endif /* AVR_TINY? */ ret ENDF __muluha3_round #endif /* L_muluha3_round */ @@ -372,6 +383,8 @@ DEFUN __muluha3_round Fixed Multiplication 16.16 x 16.16 ***/ +#ifndef __AVR_TINY__ + ;; Bits outside the result (below LSB), used in the signed version #define GUARD __tmp_reg__ @@ -679,6 +692,8 @@ DEFUN __mulusa3_round #undef GUARD +#endif /* ! AVR_TINY */ + /*** Fixed unsigned saturated Multiplication 8.8 x 8.8 ***/ @@ -762,8 +777,14 @@ DEFUN __ssmulha3 ;; SS = 0 --> 0x7fff ldi C3, 0x7f ldi C2, 0xff +#ifndef __AVR_TINY__ sbrcSS, 7 adiwC2, 1 +#else +lsl SS +adc C2, __zero_reg__ +adc C3, __zero_reg__ +#endif /* AVR_TINY? */ ret ENDF __ssmulha3 #endif /* L_ssmulha3 */ @@ -778,6 +799,8 @@ DEFUN __ssmulha3 Fixed unsigned saturated Multiplication 16.16 x 16.16 ***/ +#ifndef __AVR_TINY__ + #define C0 18 #define C1 C0+1 #define C2 C0+2 @@ -883,6 +906,8 @@ DEFUN __ssmulsa3 #undef C7 #undef SS +#endif /* ! AVR_TINY */ + /*** Fractional Division 8 / 8 **
[PING^4][PATCH] Alpha: Fix base block alignment calculation regression
On Tue, 25 Feb 2025, Maciej W. Rozycki wrote:
> Address this issue by recursing into COMPONENT_REF tree nodes until the
> outermost one has been reached, which is supposed to be a MEM_REF one,
> accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha:
> Also use tree information to get base block alignment") regression.
Ping for:
Re: [COMMITTED] Doc: Document _Bool type as C90 extension [PR118118]
On 4/6/25 03:00, Florian Weimer wrote:
* Sandra Loosemore:
@@ -13698,6 +13699,17 @@ Forward-declaring an incomplete enum type without an
explicit
underlying type is supported as an extension in all GNU C dialects,
but is not supported at all in GNU C++.
+@node Boolean Type
+@subsection Support for the @code{_Bool} Type
+@cindex boolean type
+@cindex @code{_Bool} keyword
+
+The C99 standard added @code{_Bool} as a C language keyword naming the
+boolean type. As an extension, GNU C also recognizes @code{_Bool} in
+C90 mode as well as with @option{-std=c99} and later.
I think with C23, _Bool is again a GNU extension.
I checked this before writing that text. The draft document of the C23
standard I've been using as a reference (N3096) lists _Bool as an
alternate spelling for bool in section 6.4.1, "Keywords". So it's not
an extension, it's still part of the language, although a footnote says
it's an "obsolescent feature".
+GNU C++ does not support the @code{_Bool} keyword.
Maybe mention that including defines _Bool as a macro?
Hmmm, OK. I'd missed that in my experimenting to find out what worked
with which -std= options, and grepping the C++ front end code for _Bool.
I've pushed the attached patch with clarifications for both of these things.
-SandraFrom 05ceea81506c39d2b67cd70c6abc73cb3d03abd1 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sun, 6 Apr 2025 16:03:48 +
Subject: [COMMITTED] Doc: Further clarify support for _Bool type
gcc/ChangeLog
* doc/extend.texi (Boolean Type): Further clarify support for
_Bool in C23 and C++.
---
gcc/doc/extend.texi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 16ad83fc510..ae3357f83bf 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13814,7 +13814,13 @@ The C99 standard added @code{_Bool} as a C language keyword naming the
boolean type. As an extension, GNU C also recognizes @code{_Bool} in
C90 mode as well as with @option{-std=c99} and later.
-GNU C++ does not support the @code{_Bool} keyword.
+C23 added @code{bool} as the preferred name of the boolean type, but
+@code{_Bool} also remains a standard keyword in the language and is
+supported as such by GCC with @option{-std=c23}.
+
+GNU C++ does not support @code{_Bool} as a keyword, but including
+@code{} defines it as a macro in terms of standard C++'s
+@code{bool} type.
@node Variadic Macros
@subsection Macros with a Variable Number of Arguments.
--
2.34.1
Re: [PATCH] i386: Prefer PLT indirection for __fentry__ calls under -fPIC
On Sun, Apr 6, 2025 at 8:54 AM H.J. Lu wrote:
>
> On Fri, Apr 4, 2025 at 12:01 AM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > __fentry__") updated the logic that emits mcount() / __fentry__() calls
> > into function prologues when profiling is enabled, to avoid GOT-based
> > indirect calls when a direct call would suffice.
> >
> > There are two problems with that change:
> > - it relies on -mdirect-extern-access rather than -fno-plt to decide
> > whether or not a direct [PLT based] call is appropriate;
> > - for the PLT case, it falls through to x86_print_call_or_nop(), which
> > does not emit the @PLT suffix, resulting in the wrong relocation to be
> > used (R_X86_64_PC32 instead of R_X86_64_PLT32)
> >
> > Fix this by testing flag_plt instead of ix86_direct_extern_access, and
> > updating x86_print_call_or_nop() to take flag_pic and flag_plt into
> > account. This ensures that -mnop-mcount works as expected when emitting
> > the PLT based profiling calls.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
> >
> > Signed-off-by: Ard Biesheuvel
> >
> > gcc/ChangeLog:
> >
> >* config/i386/i386.cc (x86_function_profiler): Take
> >ix86_direct_extern_access into account when generating calls
> >to __fentry__()
> > ---
> > gcc/config/i386/i386.cc | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index be5e27fc391..6be6ddcbb3c 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -23154,6 +23154,8 @@ x86_print_call_or_nop (FILE *file, const char
> > *target)
> >if (flag_nop_mcount || !strcmp (target, "nop"))
> > /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
> > fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
> > + else if (!TARGET_PECOFF && flag_pic && flag_plt)
> > +fprintf (file, "1:\tcall\t%s@PLT\n", target);
> >else
> > fprintf (file, "1:\tcall\t%s\n", target);
> > }
> > @@ -23317,7 +23319,7 @@ x86_function_profiler (FILE *file, int labelno
> > ATTRIBUTE_UNUSED)
> > break;
> > case CM_SMALL_PIC:
> > case CM_MEDIUM_PIC:
> > - if (!ix86_direct_extern_access)
> > + if (!flag_plt)
>
> Should ix86_force_load_from_GOT_p be extended to handle this?
Never mind. !flag_plt is appropriate here. ix86_direct_extern_access doesn't
apply to function reference.
>
> > {
> > if (ASSEMBLER_DIALECT == ASM_INTEL)
> > fprintf (file, "1:\tcall\t[QWORD PTR
> > %s@GOTPCREL[rip]]\n",
> > --
> > 2.49.0.504.g3bcea36a83-goog
> >
>
Tests are missing.
--
H.J.
[PATCH v2] RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.
XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.
V2:
Change the value of dg-do in the test case from assemble to compile, and
remove the -save-temps option.
gcc/ChangeLog:
* config/riscv/vector.md: Disable vsext/vzext for XTheadVector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/vsext.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vzext.c: New test.
---
gcc/config/riscv/vector.md| 6 ++---
.../gcc.target/riscv/rvv/xtheadvector/vsext.c | 24 +++
.../gcc.target/riscv/rvv/xtheadvector/vzext.c | 24 +++
3 files changed, 51 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vsext.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vzext.c
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 8ee43cf0ce1..51eb64fb122 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -3939,7 +3939,7 @@ (define_insn "@pred__vf2"
(any_extend:VWEXTI
(match_operand: 3 "register_operand" " vr, vr"))
(match_operand:VWEXTI 2 "vector_merge_operand" " vu,
0")))]
- "TARGET_VECTOR"
+ "TARGET_VECTOR && !TARGET_XTHEADVECTOR"
"vext.vf2\t%0,%3%p1"
[(set_attr "type" "vext")
(set_attr "mode" "")])
@@ -3959,7 +3959,7 @@ (define_insn "@pred__vf4"
(any_extend:VQEXTI
(match_operand: 3 "register_operand" " vr, vr"))
(match_operand:VQEXTI 2 "vector_merge_operand" " vu,0")))]
- "TARGET_VECTOR"
+ "TARGET_VECTOR && !TARGET_XTHEADVECTOR"
"vext.vf4\t%0,%3%p1"
[(set_attr "type" "vext")
(set_attr "mode" "")])
@@ -3979,7 +3979,7 @@ (define_insn "@pred__vf8"
(any_extend:VOEXTI
(match_operand: 3 "register_operand" " vr, vr"))
(match_operand:VOEXTI 2 "vector_merge_operand" " vu,0")))]
- "TARGET_VECTOR"
+ "TARGET_VECTOR && !TARGET_XTHEADVECTOR"
"vext.vf8\t%0,%3%p1"
[(set_attr "type" "vext")
(set_attr "mode" "")])
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vsext.c
b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vsext.c
new file mode 100644
index 000..55db28304c7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vsext.c
@@ -0,0 +1,24 @@
+/* { dg-do compile { target { rv64 } } } */
+/* { dg-options "-march=rv64gc_xtheadvector -mabi=lp64d -O3" } */
+
+#include
+
+struct a
+{
+ int b[];
+} c (vint32m4_t), d;
+
+char e;
+char *f;
+
+void g ()
+{
+ int h;
+ vint32m4_t i;
+ vint8m1_t j = __riscv_vlse8_v_i8m1 (&e, d.b[3], h);
+ vint16m2_t k = __riscv_vwadd_vx_i16m2 (j, 0, h);
+ i = __riscv_vwmacc_vx_i32m4 (i, f[0], k, h);
+ c (i);
+}
+
+/* { dg-final { scan-assembler-not {th\.vsext\.vf2} } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vzext.c
b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vzext.c
new file mode 100644
index 000..fcb565991c6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vzext.c
@@ -0,0 +1,24 @@
+/* { dg-do compile { target { rv64 } } } */
+/* { dg-options "-march=rv64gc_xtheadvector -mabi=lp64d -O3" } */
+
+#include
+
+struct a
+{
+ int b[];
+} c (vuint32m4_t), d;
+
+char e;
+char *f;
+
+void g ()
+{
+ int h;
+ vuint32m4_t i;
+ vuint8m1_t j = __riscv_vlse8_v_u8m1 (&e, d.b[3], h);
+ vuint16m2_t k = __riscv_vwaddu_vx_u16m2 (j, 0, h);
+ i = __riscv_vwmaccu_vx_u32m4 (i, f[0], k, h);
+ c (i);
+}
+
+/* { dg-final { scan-assembler-not {th\.vzext\.vf2} } } */
--
2.25.1
Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs
Hi Paul,
shouldn't this be done in iresolve.cc to make other parts of gfortran benefit
from learning, that the sym is allocatable?
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -3883,6 +3883,13 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr *
expr) append_args->quick_push (null_pointer_node);
}
}
+ /* Non-character scalar reduce returns a pointer to a result of size set by
+ the element size of 'array'. Setting 'sym' allocatable ensures that the
+ result is deallocated at the appropriate time. */
+ else if (expr->value.function.isym->id == GFC_ISYM_REDUCE
+ && expr->rank == 0 && expr->ts.type != BT_CHARACTER)
+sym->attr.allocatable = 1;
+
gfc_conv_procedure_call (se, sym, expr->value.function.actual, expr,
append_args);
--- a/libgfortran/intrinsics/reduce.c
+++ b/libgfortran/intrinsics/reduce.c
@@ -83,8 +83,8 @@ reduce (parray *ret,
if (dim_present)
{
if ((*dim < 1) || (*dim > (GFC_INTEGER_4)array_rank))
- runtime_error ("DIM in REDUCE intrinsic is less than 0 or greater than
"
- "the rank of ARRAY");
+ runtime_error ("Mismatch between DIM in and the rank of ARRAY in the "
... DIM and the rank ... ???
+ "REDUCE intrinsic (%d/%d)", (int)*dim, array_rank);
dimen = (index_type) *dim;
}
else
...
if (masked && (ext != GFC_DESCRIPTOR_EXTENT (mask, i)))
- runtime_error ("shape mismatch between ARRAY and MASK in REDUCE "
- "intrinsic");
+ {
+ int mext = (int)GFC_DESCRIPTOR_EXTENT (mask, i);
+ runtime_error ("shape mismatch between ARRAY and MASK in REDUCE "
+"intrinsic (%d/%d)", (int)ext, mext);
size_t mext = ...
runtime_error ("... intrinsic (%zd/%d)", ext, mext);
%zd is for size_t and other size related variable-output. It might be more
precise. Just an idea.
Please check your Changelog for style. When I am not mistaken, then a . has to
be followed by two spaces. Or did this change? I like to use git gcc-verify on
my commit message. That points out some easy to spot oversights.
Besides those minor nits: Looks good to me. Ok to merge, when reports have
verified.
Thanks for the patch,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs
Hi Andre,
On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote:
> Hi Paul,
>
> shouldn't this be done in iresolve.cc to make other parts of gfortran
> benefit
> from learning, that the sym is allocatable?
>
> I'll give it a try. I was attempting to eliminate any wider side effects
by setting the temporary symbol to be allocatable. However, I suppose that,
by its nature, the only side effect is on other calls to scalar_reduce.
> --- a/libgfortran/intrinsics/reduce.c
> +++ b/libgfortran/intrinsics/reduce.c
> @@ -83,8 +83,8 @@ reduce (parray *ret,
>if (dim_present)
> {
>if ((*dim < 1) || (*dim > (GFC_INTEGER_4)array_rank))
> - runtime_error ("DIM in REDUCE intrinsic is less than 0 or greater
> than
> "
> - "the rank of ARRAY");
> + runtime_error ("Mismatch between DIM in and the rank of ARRAY in
> the "
>
> ... DIM and the rank ... ???
>
Yes, 0 < dim <= ARRAY->rank being asserted.
>
> + "REDUCE intrinsic (%d/%d)", (int)*dim, array_rank);
>dimen = (index_type) *dim;
> }
>else
>
> ...
>
>if (masked && (ext != GFC_DESCRIPTOR_EXTENT (mask, i)))
> - runtime_error ("shape mismatch between ARRAY and MASK in REDUCE "
> - "intrinsic");
> + {
> + int mext = (int)GFC_DESCRIPTOR_EXTENT (mask, i);
> + runtime_error ("shape mismatch between ARRAY and MASK in REDUCE "
> +"intrinsic (%d/%d)", (int)ext, mext);
>
> size_t mext = ...
> runtime_error ("... intrinsic (%zd/%d)", ext, mext);
>
> %zd is for size_t and other size related variable-output. It might be more
> precise. Just an idea.
>
OK
>
>
> Please check your Changelog for style. When I am not mistaken, then a .
> has to
> be followed by two spaces. Or did this change? I like to use git
> gcc-verify on
> my commit message. That points out some easy to spot oversights.
>
I have yet to test with gcc-verify. Being a Sunday, I had better things to
do than polish a gfortran patch that was going to await the reporters'
thumbs up before pushing :-)
>
> Besides those minor nits: Looks good to me. Ok to merge, when reports have
> verified.
>
> Thanks for the patch,
> Andre
>
Thanks for the review.
Paul
Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs
Hi Paul,
> > --- a/libgfortran/intrinsics/reduce.c
> > +++ b/libgfortran/intrinsics/reduce.c
> > @@ -83,8 +83,8 @@ reduce (parray *ret,
> >if (dim_present)
> > {
> >if ((*dim < 1) || (*dim > (GFC_INTEGER_4)array_rank))
> > - runtime_error ("DIM in REDUCE intrinsic is less than 0 or greater
> > than
> > "
> > - "the rank of ARRAY");
> > + runtime_error ("Mismatch between DIM in and the rank of ARRAY in
> > the "
> >
> > ... DIM and the rank ... ???
> >
>
> Yes, 0 < dim <= ARRAY->rank being asserted.
Sorry, for being imprecise, but I think there is an "in" too much in the
error message!
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.
On 4/3/25 12:32 AM, Jin Ma wrote: XThreadVector does not support the vsext/vzext instructions; however, due to the reuse of RVV optimizations, it may generate these instructions in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2'," we should disable these patterns. gcc/ChangeLog: * config/riscv/vector.md: Disable vsext/vzext for XTheadVector. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xtheadvector/vsext.c: New test. * gcc.target/riscv/rvv/xtheadvector/vzext.c: New test. Mostly OK. The only change we might need is removal of the "-save-temps" option in the testcase. I don't think that should be necessary, we certainly don't need it with other scan-asm tests. OK with the -save-temps removed. jeff
[PATCH] tailc: Extend the IPA-VRP workaround [PR119614]
Hi!
The IPA-VRP workaround in the tailc/musttail passes was just comparing
the singleton constant from a tail call candidate return with the ret_val.
This unfortunately doesn't work in the following testcase, where we have
[local count: 152205050]:
baz (); [must tail call]
goto ; [100.00%]
[local count: 762356696]:
_8 = foo ();
[local count: 1073741824]:
# _3 = PHI <0B(4), _8(6)>
return _3;
and in the unreduced testcase even more PHIs before we reach the return
stmt.
Normally when the call has lhs, whenever we follow a (non-EH) successor
edge, it calls propagate_through_phis and that walks the PHIs in the
destination bb of the edge and when it sees a PHI whose argument matches
that of the currently tracked value (ass_var), it updates ass_var to
PHI result of that PHI. I think it is theoretically dangerous that it
picks the first one, perhaps there could be multiple PHIs, so perhaps safer
would be walk backwards from the return value up to the call.
Anyway, this PR is about the IPA-VRP workaround, there ass_var is NULL
because the potential tail call has no lhs, but ret_var is not TREE_CONSTANT
but SSA_NAME with PHI as SSA_NAME_DEF_STMT. The following patch handles
it by pushing the edges we've walked through when ass_var is NULL into a
vector and if ret_var is SSA_NAME set to PHI result, it attempts to walk
back from the ret_var through arguments of PHIs corresponding to the
edges we've walked back until we reach a constant and compare that constant
against the singleton value as well.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-04-07 Jakub Jelinek
PR tree-optimization/119614
* tree-tailcall.cc (find_tail_calls): Remember edges which have been
walked through if !ass_var. Perform IPA-VRP workaround even when
ret_var is not TREE_CONSTANT, in that case check in a loop if it is
a PHI result and in that case look at the PHI argument from
corresponding edge in the edge vector.
* g++.dg/opt/pr119613.C: Change { c || c++11 } in obviously C++ only
test to just c++11.
* g++.dg/opt/pr119614.C: New test.
--- gcc/tree-tailcall.cc.jj 2025-04-04 20:52:34.450015821 +0200
+++ gcc/tree-tailcall.cc2025-04-05 14:50:50.106693562 +0200
@@ -920,6 +920,7 @@ find_tail_calls (basic_block bb, struct
auto_bitmap to_move_defs;
auto_vec to_move_stmts;
bool is_noreturn = gimple_call_noreturn_p (call);
+ auto_vec edges;
abb = bb;
agsi = gsi;
@@ -933,6 +934,8 @@ find_tail_calls (basic_block bb, struct
{
edge e = single_non_eh_succ_edge (abb);
ass_var = propagate_through_phis (ass_var, e);
+ if (!ass_var)
+ edges.safe_push (e);
abb = e->dest;
agsi = gsi_start_bb (abb);
}
@@ -1040,9 +1043,7 @@ find_tail_calls (basic_block bb, struct
/* If IPA-VRP proves called function always returns a singleton range,
the return value is replaced by the only value in that range.
For tail call purposes, pretend such replacement didn't happen. */
- if (ass_var == NULL_TREE
- && !tail_recursion
- && TREE_CONSTANT (ret_var))
+ if (ass_var == NULL_TREE && !tail_recursion)
if (tree type = gimple_range_type (call))
if (tree callee = gimple_call_fndecl (call))
if ((INTEGRAL_TYPE_P (type)
@@ -1052,9 +1053,43 @@ find_tail_calls (basic_block bb, struct
type)
&& useless_type_conversion_p (TREE_TYPE (ret_var), type)
&& ipa_return_value_range (val, callee)
- && val.singleton_p (&valr)
- && operand_equal_p (ret_var, valr, 0))
- ok = true;
+ && val.singleton_p (&valr))
+ {
+ tree rv = ret_var;
+ unsigned int i = edges.length ();
+ /* If ret_var is equal to valr, we can tail optimize. */
+ if (operand_equal_p (ret_var, valr, 0))
+ ok = true;
+ else
+ /* Otherwise, if ret_var is a PHI result, try to find out
+if valr isn't propagated through PHIs on the path from
+call's bb to SSA_NAME_DEF_STMT (ret_var)'s bb. */
+ while (TREE_CODE (rv) == SSA_NAME
+&& gimple_code (SSA_NAME_DEF_STMT (rv)) == GIMPLE_PHI)
+ {
+ tree nrv = NULL_TREE;
+ gimple *g = SSA_NAME_DEF_STMT (rv);
+ for (; i; --i)
+ {
+ if (edges[i - 1]->dest == gimple_bb (g))
+ {
+ nrv
+ = gimple_phi_arg_def_from_edge (g,
+ edges[i - 1]);
+ --i;
+ break;
+
Re: [PATCH] RISC-V: Do not lift up vsetvl if its VL is used [PR119547].
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-04-07 03:17
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Do not lift up vsetvl if its VL is used [PR119547].
Hi,
before lifting up a vsetvl (that saves VL in a register) to a block we
need to ensure that this register is not live in the block. Otherwise
we would overwrite the register. There is some conceptual similarity to
LCM's transparency property (or ANTLOC) which deals with overwriting
an expression's operands.
This patch checks in/out liveness of a block if there is not already
a reaching vsetvl definition into the block. If the VL register is live
we do not perform the lift.
This was found when running the OpenCV testsuite, see PR119547.
Regtested on rv64gcv_zvl512b but the CI will certainly more interesting this
time.
PR target/119547
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
Check whether VL of lift candidate conflicts with new block's
uses.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/autovec/pr119547.C: New test.
* g++.target/riscv/rvv/autovec/pr119547-2.C: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Adjust.
---
gcc/config/riscv/riscv-vsetvl.cc | 27 +++
.../g++.target/riscv/rvv/autovec/pr119547-2.C | 212 ++
.../g++.target/riscv/rvv/autovec/pr119547.C | 82 +++
.../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c | 4 +-
4 files changed, 323 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547.C
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 0ac2538f596..53b064e36a3 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -3022,6 +3022,33 @@ pre_vsetvl::earliest_fuse_vsetvl_info (int iter)
continue;
}
+ /* If we move a vsetvl into a new block we must ensure that it
+ does not write a register which is live in it.
+ General liveness doesn't give the full picture as we can
+ still have live registers due to AVL demands.
+ Therefore make sure that it's not just an AVL demand
+ that would be blocking the lift by querying M_REG_DEF_LOC.
+ */
+ if (new_curr_info.has_vl ())
+ {
+ rtx reg = new_curr_info.get_vl ();
+ unsigned int regno = REGNO (reg);
+ if (!bitmap_set_bit (m_reg_def_loc[eg->src->index], regno)
+ && (bitmap_bit_p (df_get_live_in (eg->src), regno)
+ || bitmap_bit_p (df_get_live_out (eg->src), regno)))
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file,
+" Cannot lift up vsetvl into bb %u. "
+"The VL operand would conflict with uses "
+"in the block:", eg->src->index);
+ curr_info.dump (dump_file, "");
+ }
+ continue;
+ }
+ }
+
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file,
diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
new file mode 100644
index 000..bab44b323ba
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
@@ -0,0 +1,212 @@
+/* { dg-do run } */
+/* { dg-require-effective-target riscv_v_ok } */
+/* { dg-options "-O3 -march=rv64gcv --param=logical-op-non-short-circuit=0" }
*/
+
+#include
+
+using v_uint8 = vuint8m2_t;
+using v_int8 = vint8m2_t;
+using v_uint16 = vuint16m2_t;
+using v_int16 = vint16m2_t;
+using v_uint32 = vuint32m2_t;
+using v_int32 = vint32m2_t;
+using v_uint64 = vuint64m2_t;
+using v_int64 = vint64m2_t;
+using v_float32 = vfloat32m2_t;
+using v_float64 = vfloat64m2_t;
+
+using uchar = unsigned char;
+using schar = signed char;
+using ushort = unsigned short;
+using uint = unsigned int;
+using uint64 = unsigned long int;
+using int64 = long int;
+
+struct Size
+{
+ int width;
+ int height;
+};
+
+template struct VTraits;
+
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m1 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m2 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m4 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m8 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e64m1 (); }
+ using lane_type = double;
+ static const int max_nlanes = 1024 / 64 * 2;
+};
+templat
[PATCH] LoongArch: Fix awk / sed usage for compatibility
Tested with nawk, mawk, and gawk.
gcc/ChangeLog:
* config/loongarch/genopts/gen-evolution.awk: remove
usage of "asort".
* config/loongarch/genopts/genstr.sh: replace sed with awk.
---
.../loongarch/genopts/gen-evolution.awk | 12 +++-
gcc/config/loongarch/genopts/genstr.sh| 57 ++-
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/gcc/config/loongarch/genopts/gen-evolution.awk
b/gcc/config/loongarch/genopts/gen-evolution.awk
index 142b658fe7a..507063bd50d 100644
--- a/gcc/config/loongarch/genopts/gen-evolution.awk
+++ b/gcc/config/loongarch/genopts/gen-evolution.awk
@@ -101,10 +101,18 @@ function gen_cpucfg_useful_idx()
idx_list[j++] = i+0
delete idx_bucket
-asort (idx_list)
+for (i = 1; i < j; i++) {
+t = i
+for (k = i + 1; k < j; k++)
+t = idx_list[k] < idx_list[t] ? k : t
+
+k = idx_list[t]
+idx_list[t] = idx_list[i]
+idx_list[i] = k
+}
print "static constexpr int cpucfg_useful_idx[] = {"
-for (i in idx_list)
+for (i = 1; i < j; i++)
printf(" %d,\n", idx_list[i])
print "};"
diff --git a/gcc/config/loongarch/genopts/genstr.sh
b/gcc/config/loongarch/genopts/genstr.sh
index 16c2edd4fa8..97517da40f4 100755
--- a/gcc/config/loongarch/genopts/genstr.sh
+++ b/gcc/config/loongarch/genopts/genstr.sh
@@ -51,18 +51,18 @@ along with GCC; see the file COPYING3. If not see
#define LOONGARCH_STR_H
EOF
-sed -e '/^$/n' -e 's@#.*$@@' -e '/^$/d' \
- -e 's@^\([^ \t]\+\)[ \t]*\([^ \t]*\)@#define \1 "\2"@' \
- loongarch-strings
+awk '/^#.*$/ { next } /^$/ { print; next }
+ { printf ("#define %s \"%s\"\n", $1, $2) }' \
+ loongarch-strings
echo
- # Generate the strings from isa-evolution.in.
- awk '{
- a=$3
- gsub(/-/, "_", a)
- print("#define OPTSTR_"toupper(a)"\t\""$3"\"")
- }' isa-evolution.in
+# Generate the strings from isa-evolution.in.
+awk '{
+ a=$3
+ gsub(/-/, "_", a)
+ print("#define OPTSTR_"toupper(a)"\t\""$3"\"")
+}' isa-evolution.in
echo
echo "#endif /* LOONGARCH_STR_H */"
@@ -73,18 +73,8 @@ EOF
# according to the key-value pairs defined in loongarch-strings.
gen_options() {
-
-sed -e '/^$/n' -e 's@#.*$@@' -e '/^$/d' \
- -e 's@^\([^ \t]\+\)[ \t]*\([^ \t]*\)@\1="\2"@' \
- loongarch-strings | { \
-
- # read the definitions
- while read -r line; do
- eval "$line"
- done
-
- # print a header
- cat << EOF
+# print a header
+cat << EOF
; Generated by "genstr" from the template "loongarch.opt.in"
; and definitions from "loongarch-strings" and "isa-evolution.in".
;
@@ -95,12 +85,25 @@ gen_options() {
;
EOF
- # make the substitutions
- sed -e 's@"@\\"@g' -e 's/@@\([^@]\+\)@@/${\1}/g' loongarch.opt.in | \
- while read -r line; do
- eval "echo \"$line\""
- done
-}
+# Generate loongarch.opt.
+awk 'BEGIN {
+delete strtab
+while (getline < "loongarch-strings" > 0) {
+if ($0 ~ /^#.*$/ || $0 ~ /^$/) continue
+strtab[$1] = $2
+}
+}
+{
+n = split($0, tmp, "@@")
+for (i = 2; i <= n; i += 2)
+tmp[i] = strtab[tmp[i]]
+
+for (i = 1; i <= n; i++)
+printf("%s", tmp[i])
+printf ("\n")
+
+}' loongarch.opt.in
+
# Generate the strings from isa-evolution.in.
awk '{
--
2.46.0
[PATCH] testsuite: arm: Tighten compile options for short-vfp-1.c [PR119556]
The previous version of this test required arch v6+ (for sxth), and
the number of vmov depended on the float-point ABI (where softfp
needed more of them to transfer floating-point values to and from
general registers).
With this patch we require arch v7-a, vfp FPU and -mfloat-abi=hard, we
also use -O2 to clean the generated code and convert
scan-assembler-times directives into check-function-bodies.
Tested on arm-none-linux-gnueabihf and several flavours of
arm-none-eabi.
gcc/testsuite/ChangeLog:
PR target/119556
* gcc.target/arm/short-vfp-1.c: Improve dg directives.
---
gcc/testsuite/gcc.target/arm/short-vfp-1.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
index f6866c4f601..418fc279af0 100644
--- a/gcc/testsuite/gcc.target/arm/short-vfp-1.c
+++ b/gcc/testsuite/gcc.target/arm/short-vfp-1.c
@@ -1,45 +1,75 @@
/* { dg-do compile } */
-/* { dg-require-effective-target arm_vfp_ok } */
-/* { dg-add-options arm_vfp } */
+/* { dg-require-effective-target arm_arch_v7a_fp_hard_ok } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_arch_v7a_fp_hard } */
+/* { dg-final { check-function-bodies "**" "" } } */
+/*
+** test_sisf:
+** vcvt.s32.f32(s[0-9]+), s0
+** vmovr0, \1 @ int
+** bx lr
+*/
int
test_sisf (float x)
{
return (int)x;
}
+/*
+** test_hisf:
+** vcvt.s32.f32(s[0-9]+), s0
+** vmov(r[0-9]+), \1 @ int
+** sxthr0, \2
+** bx lr
+*/
short
test_hisf (float x)
{
return (short)x;
}
+/*
+** test_sfsi:
+** vmov(s[0-9]+), r0 @ int
+** vcvt.f32.s32s0, \1
+** bx lr
+*/
float
test_sfsi (int x)
{
return (float)x;
}
+/*
+** test_sfhi:
+** vmov(s[0-9]+), r0 @ int
+** vcvt.f32.s32s0, \1
+** bx lr
+*/
float
test_sfhi (short x)
{
return (float)x;
}
+/*
+** test_hisi:
+** sxthr0, r0
+** bx lr
+*/
short
test_hisi (int x)
{
return (short)x;
}
+/*
+** test_sihi:
+** bx lr
+*/
int
test_sihi (short x)
{
return (int)x;
}
-
-/* { dg-final { scan-assembler-times {vcvt\.s32\.f32\ts[0-9]+, s[0-9]+} 2 } }
*/
-/* { dg-final { scan-assembler-times {vcvt\.f32\.s32\ts[0-9]+, s[0-9]+} 2 } }
*/
-/* { dg-final { scan-assembler-times {vmov\tr[0-9]+, s[0-9]+} 2 } } */
-/* { dg-final { scan-assembler-times {vmov\ts[0-9]+, r[0-9]+} 2 } } */
-/* { dg-final { scan-assembler-times {sxth\tr[0-9]+, r[0-9]+} 2 } } */
--
2.34.1
Re: [PATCH] cobol: Diagnose ignored SECTIONs [PR119632].
On Sun, Apr 06, 2025 at 08:52:53PM +0100, Iain Sandoe wrote:
> --- a/gcc/cobol/parse.y
> +++ b/gcc/cobol/parse.y
> @@ -6971,9 +6971,9 @@ section_kw: SECTION
> {
>if( $1 ) {
> if( *$1 == '-' ) {
> - error_msg(@1, "SECTION segment %s is negative", $1);
> + error_msg(@1, "SECTION segment %<%s%> is negative", $1);
%qs instead of %<%s%> ?
> } else {
> - cbl_unimplementedw("SECTION segment %s was ignored",
> $1);
> + error_msg(@1, "SECTION segment %<%s%> was ignored",
> $1);
Ditto?
Jakub
[PATCH] wwwdocs: projects/gomp: Make intro more general
I have *not* pushed this and am looking for review/approval. Primarily this broadens "for all GNU system variants" by "for a broad variety of systems", similar to our main page. Okay? Gerald --- htdocs/projects/gomp/index.html | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html index 97d14308..c84660bd 100644 --- a/htdocs/projects/gomp/index.html +++ b/htdocs/projects/gomp/index.html @@ -90,12 +90,10 @@ OpenMP and OpenACC are supported with GCC's C, C++ and Fortran compilers. https://www.openmp.org";>OpenMP for the C, C++, and Fortran compilers in the GNU -Compiler Collection and is further improving it. As part of the GNU Project, GOMP -simplifies parallel programming for all GNU system variants. This -effort operates in an open environment to attract developers and -ensure applicability across multiple architectures and -applications. +Compiler Collection and is further improving it. +GOMP simplifies parallel programming for a broad variety of systems. +This effort operates in an open environment to attract developers and +ensure applicability across multiple architectures and applications. Traditionally, programmers have used architecture-specific methods to effectively program tightly-parallelized -- 2.49.0
[PATCH] RISC-V: Do not lift up vsetvl if its VL is used [PR119547].
Hi,
before lifting up a vsetvl (that saves VL in a register) to a block we
need to ensure that this register is not live in the block. Otherwise
we would overwrite the register. There is some conceptual similarity to
LCM's transparency property (or ANTLOC) which deals with overwriting
an expression's operands.
This patch checks in/out liveness of a block if there is not already
a reaching vsetvl definition into the block. If the VL register is live
we do not perform the lift.
This was found when running the OpenCV testsuite, see PR119547.
Regtested on rv64gcv_zvl512b but the CI will certainly more interesting this
time.
PR target/119547
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
Check whether VL of lift candidate conflicts with new block's
uses.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/autovec/pr119547.C: New test.
* g++.target/riscv/rvv/autovec/pr119547-2.C: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Adjust.
---
gcc/config/riscv/riscv-vsetvl.cc | 27 +++
.../g++.target/riscv/rvv/autovec/pr119547-2.C | 212 ++
.../g++.target/riscv/rvv/autovec/pr119547.C | 82 +++
.../riscv/rvv/vsetvl/vlmax_switch_vtype-10.c | 4 +-
4 files changed, 323 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547.C
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 0ac2538f596..53b064e36a3 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -3022,6 +3022,33 @@ pre_vsetvl::earliest_fuse_vsetvl_info (int iter)
continue;
}
+ /* If we move a vsetvl into a new block we must ensure that it
+does not write a register which is live in it.
+General liveness doesn't give the full picture as we can
+still have live registers due to AVL demands.
+Therefore make sure that it's not just an AVL demand
+that would be blocking the lift by querying M_REG_DEF_LOC.
+*/
+ if (new_curr_info.has_vl ())
+ {
+ rtx reg = new_curr_info.get_vl ();
+ unsigned int regno = REGNO (reg);
+ if (!bitmap_set_bit (m_reg_def_loc[eg->src->index], regno)
+ && (bitmap_bit_p (df_get_live_in (eg->src), regno)
+ || bitmap_bit_p (df_get_live_out (eg->src), regno)))
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file,
+ " Cannot lift up vsetvl into bb %u. "
+ "The VL operand would conflict with uses "
+ "in the block:", eg->src->index);
+ curr_info.dump (dump_file, "");
+ }
+ continue;
+ }
+ }
+
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file,
diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
new file mode 100644
index 000..bab44b323ba
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/pr119547-2.C
@@ -0,0 +1,212 @@
+/* { dg-do run } */
+/* { dg-require-effective-target riscv_v_ok } */
+/* { dg-options "-O3 -march=rv64gcv --param=logical-op-non-short-circuit=0" }
*/
+
+#include
+
+using v_uint8 = vuint8m2_t;
+using v_int8 = vint8m2_t;
+using v_uint16 = vuint16m2_t;
+using v_int16 = vint16m2_t;
+using v_uint32 = vuint32m2_t;
+using v_int32 = vint32m2_t;
+using v_uint64 = vuint64m2_t;
+using v_int64 = vint64m2_t;
+using v_float32 = vfloat32m2_t;
+using v_float64 = vfloat64m2_t;
+
+using uchar = unsigned char;
+using schar = signed char;
+using ushort = unsigned short;
+using uint = unsigned int;
+using uint64 = unsigned long int;
+using int64 = long int;
+
+struct Size
+{
+ int width;
+ int height;
+};
+
+template struct VTraits;
+
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m1 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m2 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m4 (); }
+ using lane_type = int32_t;
+ static const int max_nlanes = 1024 / 32 * 2;
+};
+template <> struct VTraits
+{
+ static inline int vlanes () { return __riscv_vsetvlmax_e32m8 (); }
+ usi
[PATCH] cobol: Diagnose ignored SECTIONs [PR119632].
Tested on x86_64, aarch64 Linux/Darwin, powerpc64le Linux,
OK for trunk?
thanks
Iain
--- 8< ---
Instead of "sorry-ing" on an ignored SECTION this prints out
what failed and continues (we also quote the failed name to help
identify cases where it is empty).
PR cobol/119632
gcc/cobol/ChangeLog:
* parse.y: Do not sorry on a failed SECTION, print a
message and continue.
Signed-off-by: Iain Sandoe
---
gcc/cobol/parse.y | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/cobol/parse.y b/gcc/cobol/parse.y
index 3f282013a4a..7addccdc750 100644
--- a/gcc/cobol/parse.y
+++ b/gcc/cobol/parse.y
@@ -6971,9 +6971,9 @@ section_kw: SECTION
{
if( $1 ) {
if( *$1 == '-' ) {
- error_msg(@1, "SECTION segment %s is negative", $1);
+ error_msg(@1, "SECTION segment %<%s%> is negative", $1);
} else {
- cbl_unimplementedw("SECTION segment %s was ignored", $1);
+ error_msg(@1, "SECTION segment %<%s%> was ignored", $1);
}
}
}
--
2.39.2 (Apple Git-143)
Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs
On Sun, Apr 6, 2025 at 5:39 AM Paul Richard Thomas wrote: > > Hi All, > > As far as I can tell, the attached patch fixes the problems with the reduce > intrinsic. I would be grateful to the reporters if they would confirm that > this is the case. > > The key to the fix appears in reduce_3.f90, which failed even with -m64. > Although it was not apparent from the tree dump, the scalar result was going > on the stack. Once it became larger than the word size, it pushed the > arguments out of alignment with the library prototype. > > I took the opportunity to add character length checking to the library. I > think that it might be redundant and so might not appear in the submitted > version. Thus far, I have failed to trigger the errors because the frontend > seems to catch them all. reduce_c and reduce_scalar_c will look a lot neater > without them. > > Harald has been enormously helpful in hunting out remaining problems and > providing fixes. These are woven into the patch. > > Regtests on FC41/x86_64 - OK for mainline after confirmations from the > reporters? > > Paul > Verified on Fedora 41/x86-64 with -m32. -- H.J.
